Tiangong Ultra: o que devs podem aprender com o recorde

O robô chinês que quebrou o recorde de Bolt — e o que isso significa para quem constrói software

Quando vi a notícia no Terra.com.br sobre o Tiangong Ultra correndo os 100 metros em 8,64 segundos, minha primeira reação não foi admiração — foi curiosidade técnica. Um humanoide atingir ~42 km/h não é só um feito esportivo, é uma demonstração de que o pipeline de controle de locomoção bíbpede atingiu um nível de maturidade que, até dois anos atrás, parecia coisa de paper acadêmico.

Na minha experiência com sistemas de controle e visão computacional, sei o quanto é difícil manter equilíbrio dinâmico em terreno variável. O Tiangong não é “rápido” no sentido humano — é preciso. São coisas completamente diferentes, e entender essa diferença é o que separa quem lê manchete de quem entende o que está acontecendo por baixo dos motores.

O que é o Tiangong Ultra, de verdade

O Tiangong Ultra foi desenvolvido pelo Beijing Innovation Center of Human Robotics e é a evolução de uma plataforma apresentada em 2024. Ele tem 1,63m de altura, pesa cerca de 43kg e roda em hardware proprietário com módulos de torque articulado de alto desempenho. Diferente de humanoides como o Atlas da Boston Dynamics, que dependem de modelos hidráulicos pesados, o Tiangong usa atuadores elétricos com densidade de torque otimizada para corrida contínua.

O detalhe técnico que ninguém comenta: a corrida inteira é regida por um controlador de equilíbrio em malha fechada rodando em alta frequência — tipicamente acima de 1 kHz. Cada milissegundo, os sensores IMU (unidade de medida inercial) nos quadris e torso enviam dados de orientação, e o controlador ajusta torque em cada junta para manter o centro de massa dentro do polígono de apoio. É essentially a mesma lógica de um drone estabilizando no ar, só que agora no chão e com restrições de contato muito piores.

Por que 42 km/h é diferente de “correr como Bolt”

Segundo o Terra.com.br, o professor Jung Moon-hyun, da Universidade Nacional de Chungnam, destacou que se trata de um avanço notável — mas as diferenças técnicas entre a corrida humana e a robótica são profundas.

Bolt correu os 100m em Berlim (2009) com tempo de reação de 0,146s saindo dos blocos, aproveitando a força horizontal inicial gerada pelos pés contra os blocos. Humanóides não usam blocos de largada. Eles começam com os dois pés apoiados e precisam gerar tração zero — qualquer erro e tombam para trás. Por isso, os primeiros metros de um robô são sempre os mais lentos.

O Tiangong atinge velocidade máxima via um padrão de marcha chamado dynamic walking with aerial phase — existe um momento em que ambos os pés estão fora do chão, coisa que humanóides até então só conseguiam em velocidade de caminhada. Isso exige controle preditivo, não apenas reativo.

A lacuna real: percepção e decisão

A matéria do Terra cita que robôs ainda têm deficiências em percepção e tomada de decisão. Isso é o ponto que mais me interessa como dev. Em pista reta, sem obstáculos, com piso perfeito e vento controlado, o hardware vence. Mas coloque uma cadeira no caminho, uma poça d’água, ou uma multidão em movimento — e o cenário muda completamente.

Os melhores sistemas atuais usam fusão de sensores (câmeras estéreo + LiDAR + IMU + encoders de junta) para construir um mapa 3D do entorno em tempo real. O gargalo não é mais processamento — chips como o Jetson Orin e o Qualcomm RB5 já dão conta. O gargalo é o software de decisão: qual ação tomar em milissegundos quando o ambiente muda?

Aqui entra machine learning, reinforcement learning e, cada vez mais, modelos de fundação visuais (VLM) que conseguem raciocinar sobre cenas. Estamos vendo a convergência entre robótica clássica e IA generativa — e é aí que devs como nós temos oportunidade real.

Na Prática: simulando um controlador de equilíbrio simples

Para entender como funciona a malha de controle que mantém um bípede de pé, vale a pena implementar um protótipo simplificado. Não chega nem perto da complexidade real, mas mostra o coração da ideia: um PID controller consumindo dados de um sensor IMU simulado e ajustando a inclinação do torso.

import numpy as np

class SimpleBalanceController:
 """
 Controlador PID simples para manter o torso ereto.
 Inspirado na lógica de equilíbrio usada em humanoides.
 """
 def __init__(self, kp=25.0, ki=0.5, kd=8.0, target_angle=0.0):
 self.kp = kp # ganho proporcional
 self.ki = ki # ganho integral
 self.kd = kd # ganho derivativo
 self.target = target_angle
 self.integral = 0.0
 self.last_error = 0.0
 self.dt = 0.001 # 1 kHz, frequência típica de controle humanoide

 def update(self, measured_angle, measured_velocity):
 error = self.target - measured_angle
 self.integral += error * self.dt
 derivative = -measured_velocity # taxa de variação do ângulo

 # Lei de controle PID
 output = (self.kp * error +
 self.ki * self.integral +
 self.kd * derivative)

 # Saturação (limite de torque do atuador)
 output = np.clip(output, -50.0, 50.0)
 self.last_error = error
 return output

# Simulação: robô recebe um empurrão e precisa se equilibrar
controller = SimpleBalanceController()
angle = 0.15 # 0.15 rad de inclinação inicial (~8.6°)
velocity = 0.0

print("tempo(ms) | ângulo(°) | torque")
for t in range(0, 500, 50):
 torque = controller.update(angle, velocity)
 # Modelo simplificado de dinâmica: M*θ'' = -mg*sin(θ) + torque
 g = 9.81
 angular_acc = (-g * np.sin(angle)) + torque * 0.1
 velocity += angular_acc * controller.dt * 50 # passo de 50ms
 angle += velocity * controller.dt * 50
 print(f"{t:8d} | {np.degrees(angle):9.3f} | {torque:6.2f}")

Esse código é didático, mas a versão real envolve modelos dinâmicos completos (inverse dynamics, ZMP — Zero Moment Point, captura de pontos), filtros de Kalman para fusão sensorial e otimização em tempo real. Se quiser ir além, vale estudar a biblioteca pinocchio para cinemática e o framework MuJoCo para simulação física.

Comparativo: como os principais humanoides se posicionam

Repare: o Tiangong ganha em velocidade pura, mas perde em versatilidade. O Atlas é mais lento, mas pula entre plataformas, faz backflips e se adapta a caos. A corrida pelo “humanóide definitivo” ainda está aberta.

Erros Comuns ao trabalhar com locomoção bíbpede

Na minha experiência com projetos de robótica e simulação, vejo devs cometendo estes erros:

• Ignorar a fase de simulação. Testar diretamente em hardware real queima motores e quebra peças caras. Sempre passe pelo MuJoCo, Isaac Sim ou PyBullet antes.
• Confundir precisão com frequência. Um sensor de 16 bits a 100Hz é pior que um de 12 bits a 1kHz para controle de equilíbrio. Sample rate importa mais que resolução em malhas rápidas.
• Tunar PID no achismo. Use métodos sistemáticos como Ziegler-Nichols ou, melhor ainda, autotuning com reinforcement learning em simulação.
• Esquecer o modelo de atrito. O chão não é perfeitamente rígido. Modelos de contato compliant (soft contact) fazem diferença brutal no realismo da simulação.
• Subestimar o tempo real. Algoritmos academicamente elegantes часто não rodam a 1 kHz em hardware embarcado. Profile sempre.

O que isso muda para quem programa

Pra nós, devs, a mensagem prática é: o mercado de software para robótica está explodindo. Não é mais necessário comprar hardware de R$ 1M para começar — plataformas como Unitree, Open Dynamic Robot Initiative e até o LEGO Mindstorms em menor escala permitem prototipar. Frameworks como ROS 2, Drake e o recém-lançado LeRobot da Hugging Face abstraem a complexidade de baixo nível.

Se você trabalha com Python, C++ ou Rust, tem espaço. Se trabalha com visão computacional, mais ainda. A stack mais quente do momento combina ROS 2 + PyTorch + CUDA + ONNX Runtime rodando em Jetson Orin ou RTX com TensorRT.

FAQ — Perguntas que devs realmente fazem

1. Qual a diferença entre locomoção bípede de robôs e a de humanos em termos de software?

Humanos usam modelos internos aprendidos (cerebelo + córtex motor) com redundância enorme. Robôs usam modelos matemáticos explícitos (ZMP, MPC — Model Predictive Control) com redundância mínima. Por isso, robôs são eficientes em tarefas repetitivas, mas frágeis quando o ambiente muda fora do esperado.

2. Dá pra rodar o controle do Tiangong em hardware comercial?

Não exatamente — os atuadores e o controlador proprietário são custom. Mas é possível replicar a lógica em plataformas como Unitree H1 usando ROS 2 e o SDK oficial. A controladora aberta não existe ainda, mas comunidades como Open Dynamic Robot Initiative disponibilizam designs de referência.

3. Qual linguagem domina em robotics hoje?

C++ para tempo real e controle de baixo nível. Python para tudo que envolve ML, planejamento e prototipagem. Rust está crescendo em middlewares por questões de segurança de memória, especialmente em ROS 2 (que tem bindings oficiais).

4. Como começar a estudar locomoção bípede sem hardware caro?

Instale o MuJoCo (agora open source via DeepMind), baixe o modelo do Unitree H1 ou Cassie, e brinque com o python-quadruped e o drake. Você consegue resultados de simulação publicáveis em meses, não anos.

5. O Tiangong Ultra realmente “aprendeu” a correr ou foi programado?

Ambos. A política de controle base é clássica (model-based), mas ajustes finos — especialmente a transição para a fase aérea — envolvem reinforcement learning treinado em simulação e transferido para o real (sim-to-real). É exatamente o pipeline que o Google DeepMind popularizou com o Dreamer e que a NVIDIA replica com Isaac Lab.

Esse caso do Tiangong Ultra é um divisor de águas não pelo tempo em si, mas pelo que ele sinaliza: a fronteira entre pesquisa acadêmica e produto comercial em robótica bíbpede está se estreitando rápido. Quem trabalha com software tem uma janela curta pra entrar nesse mercado antes que ele se consolide em torno de poucos players.

Se quiser trocar ideia sobre ROS 2, controle de locomoção ou sim-to-real, deixa nos comentários ou me chama direto. É um campo riquíssimo pra quem vem de backend, visão computacional ou ML.

Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.