SDKs de Robôs, ROS 2 e Ambientes de Simulação

Uma plataforma robótica de 2026 — humanoide ou quadrúpede — chega com três histórias de software que é preciso resolver antes de o seu próprio código correr. O SDK do fabricante, que fala com as articulações. O wrapper ROS 2, que fala com tudo o resto. E o simulador, que usa porque atirar um Unitree G1 EDU de $43k contra uma parede é uma forma cara de depurar uma gralha.

Estas três camadas não são intermutáveis. O SDK é de tempo real e proprietário. O ROS 2 é a língua franca que permite que o resto do código de robótica do mundo funcione com a sua plataforma. O simulador é onde faz o trabalho que não quer fazer no robô real — aprendizagem por reforço, geração de dados em grande escala, desenho de cenários, CI headless. A maioria das equipas investe de menos nas três.

Este artigo percorre o que cada camada oferece de facto em 2026, onde estão as fronteiras e que combinações vale a pena montar com o orçamento real de um laboratório de robótica. As plataformas de referência são as de R01 e R02. A computação de referência é a linha Kentino AI (4× ou 8× RTX 5090 ou RTX Pro 6000 Blackwell, host EPYC ou Xeon).

A camada do SDK — o que os fabricantes dão realmente

Todos os fabricantes de robôs credíveis fornecem um Software Development Kit. O nome é o mesmo; o conteúdo não. Eis o que vem mesmo na caixa.

Há duas distinções que contam mais do que todas as outras.

Aberto vs fechado. A Unitree, a Booster, a EngineAI e a DeepRobotics dão-lhe acesso ao nível da articulação. Pode enviar comandos de binário a 500 Hz ou 1 kHz diretamente para os atuadores. É disso que precisa para implementar políticas de RL, para investigação em locomoção personalizada e para tudo o que seja dinâmico. A Boston Dynamics e a ANYbotics mantêm o controlo das articulações fechado — recebe primitivas de alto nível (anda até aqui, sobe aquilo, manipula isto), o SDK expõe-nas como chamadas RPC e é o controlador da própria empresa que trata das articulações. É uma opção deliberada. A stack fechada é mais fiável e o software de autonomia é aquilo que está a pagar com os $74k–$200k. É também a stack errada se a sua investigação é em controlo de baixo nível.

Tempo real vs não. O Unitree SDK2 usa Cyclone DDS sobre uma interface de rede dedicada e dá-lhe um round-trip abaixo do milissegundo no ciclo das articulações. A stack da Booster é semelhante. O Spot SDK é gRPC sobre HTTP/2 — adequado para comandar um comportamento, inútil para fechar um ciclo de controlo a 1 kHz. Se o seu trabalho exige um ciclo abaixo dos 2 ms, a arquitetura pesa mais do que a linguagem.

Uma nota sobre a questão do Python. Todos os fabricantes oferecem bindings de Python. Nenhum deles é a linguagem em que corre o ciclo de controlo. O padrão é idêntico em todo o setor: C++ para o controlador de tempo real, Python para tudo o que está acima. Os SDK dos fabricantes refletem isso: os bindings de C++ expõem mais, correm mais depressa e são aqueles em que estão escritos os exemplos do próprio fabricante. Os bindings de Python são de primeira linha para o trabalho de alto nível e um wrapper para o percurso de baixo nível. Escolha C++ quando estiver a escrever o ciclo de controlo interno e Python para a orquestração, a ligação da perceção e a integração com o servidor de inferência.

ROS 2 — porque toda a gente normaliza para ele

O SDK nativo põe-no dentro do robô. O ROS 2 põe-no dentro do ecossistema.

Há três razões para todas as integrações sérias acabarem a falar ROS 2, mesmo quando o SDK do fabricante seria suficiente:

1. Interoperabilidade. A sua stack de perceção, o seu SLAM, a sua navegação, o seu planeador de manipulação, o seu teleop — todos têm implementações em ROS 2 mantidas por centenas de colaboradores. Nenhum deles fala nativamente o formato de tópicos DDS da Unitree. Basta envolver o SDK uma vez em mensagens ROS 2 e todo o ecossistema se abre.
2. Frotas multifabricante. No dia em que acrescentar um segundo robô de outro fabricante, a abordagem do SDK nativo desmorona-se. O ROS 2 é a única abstração que permite a um Spot, a um ANYmal e a um G1 partilhar o mesmo servidor de mapas, o mesmo grafo de tarefas e a mesma interface homem-máquina.
3. Contratação. As pessoas conhecem ROS 2. Não conhecem as convenções de nomes de tópicos DDS da Unitree. Uma equipa que constrói sobre ROS 2 pode recrutar à escala global. Uma equipa que constrói sobre uma stack proprietária não pode.

Estado das distribuições ROS 2, maio de 2026:

A leitura honesta. As implementações em produção ainda hoje correm Humble. O Humble é a LTS que os fabricantes visam — o unitree_ros2 da Unitree, a stack da Booster, o spot_ros2 da comunidade e o grid_map da ANYbotics têm todos ramos estáveis para Humble. O Jazzy é por onde devem começar as novas construções: tem mais três anos de vida LTS e as ferramentas de migração estão maduras. O Lyrical Luth é demasiado recente para um compromisso — dê-lhe até ao final de 2026 antes de montar um sistema de produção sobre ele.

Se está a iniciar um projeto em maio de 2026, vá de Jazzy. Se está a prolongar um que começou em 2023, fique no Humble até a próxima compra de robô obrigar à migração. Ignore o Iron e o Kilted por completo; as versões sem LTS são para quem quer acompanhar de perto as atualizações do Gazebo Harmonic e aceita o custo de manutenção.

A separação do ciclo de controlo

É esta a decisão de arquitetura que apanha a maioria das equipas desprevenida.

A separação do ciclo de controlo: em baixo a camada de tempo real em C++ do SDK, em cima a orquestração em Python sobre ROS 2, ligadas a 10–50 Hz por mensagens de estado DDS.

O ciclo de controlo fica no robô, em C++. A camada de alto nível corre em nós ROS 2, no processador de aplicações do robô (Jetson Orin AGX) ou, para trabalho mais pesado, no servidor de inferência externo (ver I01). As duas camadas comunicam a 10–50 Hz por DDS. Não partilham um processo.

Esta separação não é opcional. Um nó ROS 2 em Python não consegue fechar um ciclo de articulações a 1 kHz — só o garbage collector torna isso impossível. Tentar fazê-lo é o erro mais comum no primeiro ano de trabalho com humanoides. O SDK do fabricante existe precisamente para que não tenha de o fazer.

Quando precisa de um simulador (e quando não precisa)

Um simulador é obrigatório para quatro tipos de trabalho:

• Aprendizagem por reforço. Não é possível treinar uma política de locomoção de raiz num robô real. O robô partir-se-ia, quem o treina desistia e o custo seria obsceno. O RL acontece em simulação — milhões de episódios, milhares de ambientes em paralelo.
• Geração de dados em grande escala. Dados sintéticos para fine-tuning de VLM, compreensão de cenários, agarres de manipulação. As equipas na linha da frente (R09) geram centenas de milhares de cenários etiquetados numa noite.
• CI headless. Quer que cada git push verifique que o robô continua a andar. Fazê-lo em hardware é impraticável. Uma execução noturna em simulação que exercite a stack de locomoção e perceção já é viável.
• Desenho de ambientes. Planear um armazém, uma célula fabril, um laboratório — saber se o robô consegue navegá-lo antes de o construir.

Não precisa de um simulador para:

• Prototipagem inicial. Se está a escrever uma demonstração do tipo "fazer o robô acenar", o simulador é peso morto. Use o robô real.
• Manipulação simples. Levantar uma caixa, abrir uma gaveta. Nestas tarefas, o fosso entre simulação e realidade é muitas vezes maior do que o tempo que teria gasto a fazê-lo no robô real.
• Desenvolvimento de teleop. O objetivo do teleop é precisamente ter o humano no ciclo. A simulação não ajuda.
• Comportamentos pontuais. Tudo aquilo que vai executar duas vezes e deitar fora.

O erro que as equipas cometem é tratar o simulador como opção por defeito. Não é. É uma ferramenta para os quatro casos acima, mais o óbvio caso de segurança de "não quero destruir o robô real".

O leque de simuladores de 2026

Há quatro simuladores que contam para a robótica com pernas em 2026. Não são equivalentes e a escolha tem opinião.

Os números da coluna dos ambientes paralelos são práticos, não teóricos. Dependem da complexidade do modelo. Um braço Franka corre com contagens de paralelismo mais altas do que um humanoide de 41 graus de liberdade com mãos destras.

Isaac Sim e Isaac Lab — a aposta da NVIDIA

O Isaac Sim é o simulador fotorrealista e acelerado por GPU construído sobre a stack Omniverse. O Isaac Lab é a framework de aprendizagem robótica que assenta em cima dele. Juntos, são a resposta da NVIDIA a todas as perguntas sobre simulação em robótica.

O que faz bem:

• Renderização fotorrealista. Iluminação com ray tracing, materiais rigorosos, modelos de câmara realistas. Se a sua stack de perceção precisa de aprender o aspeto real do mundo, este é o único simulador que o entrega à escala.
• Física acelerada por GPU. Os ambientes paralelos vivem na memória da GPU. Uma única RTX 5090 corre milhares de instâncias de humanoides a centenas de passos de física por segundo.
• Isaac Lab. Uma framework de RL limpa, com suporte integrado para RSL RL, RL-Games, SKRL e Stable Baselines3. Os mais de 16 modelos de robô pré-construídos incluem o G1, o H1, o Spot, o ANYmal, o Franka e uma lista crescente de novidades.
• Integração com o GR00T. A stack de modelos fundacionais para humanoides da NVIDIA vive aqui. Se quer treinar uma política visão-linguagem-ação e implementá-la em várias plataformas, é este o caminho.

O que faz mal:

• A dor de instalar o Omniverse. O runtime do Omniverse é opinativo, pesado e pouco amigável para uma instalação Ubuntu por defeito. Conte com um dia a lutar com o launcher, o servidor Nucleus e a cache de assets antes da sua primeira simulação.
• Dependente da GPU. O Isaac Sim não corre em CPU. Não corre bem numa única 4090. A configuração de referência é uma 5090 no mínimo, de preferência uma Pro 6000 Blackwell, e um host EPYC para alimentar os dados.
• Opinativo. Os formatos de assets são USD. A física é PhysX. A renderização é RTX. Se quer outro motor de física, está no simulador errado.

A realidade da computação. Um servidor Kentino AI com 4× RTX 5090 corre treino de humanoides em Isaac Lab com desafogo — 4,000–8,000 ambientes paralelos, fotorrealismo completo a 30–60 FPS de renderização e convergência da política numa tarefa de locomoção em 6 a 24 horas. Com 8× 5090 escala em largura ou corre várias experiências em paralelo. A Pro 6000 Blackwell é a opção certa quando a memória é a restrição determinante (lotes maiores, bibliotecas de assets de humanoides maiores).

MuJoCo e MJX — a resposta que põe a física primeiro

O MuJoCo é o simulador de física da DeepMind. O MJX é a reescrita em XLA / JAX que corre o MuJoCo na GPU com batching completo. O MJWarp é um esforço conjunto mais recente entre a NVIDIA e a Google que escreve o MuJoCo em Warp e escala melhor em cenários ricos em contactos.

O que faz bem:

• Velocidade. Física pura de corpo rígido rica em contactos, escrita de raiz para a GPU. Numa única RTX 5090, o MJX corre milhares de ambientes de humanoides a um número de passos de física por segundo que o Isaac Sim não consegue igualar para a mesma complexidade de cenário.
• Determinismo. Mesma seed, mesma trajetória. RL reprodutível é uma funcionalidade.
• O apoio da DeepMind. Todos os grandes artigos de robótica da DeepMind dos últimos cinco anos usam MuJoCo. As bibliotecas de modelos (MuJoCo Menagerie) incluem o G1, o H1, o Spot, o ANYmal, o braço Franka e a Shadow Hand.
• Mais simples. Sem Omniverse, sem USD, sem Nucleus. Pip install e a correr.

O que faz mal:

• Renderização visual. O renderizador do MuJoCo é da era do OpenGL. Chega para visualizar, não serve para gerar dados fotorrealistas.
• Ecossistema de assets. Mais pequeno do que o do Isaac. As importações de URDF funcionam, mas o acabamento é inferior.
• Modelos de sensores. Os modelos de câmara, profundidade e LiDAR são básicos. Se a sua política depende de ruído de sensor realista, terá de construir esses modelos por si.

A realidade da computação. Uma única RTX 5090 corre 4,000–16,000 ambientes paralelos de humanoides em MJX, consoante a complexidade dos contactos. Um servidor Kentino AI com 4× 5090 consegue correr mais de 50,000 ambientes de humanoides em paralelo para RL de locomoção. É esta a conta que mantém a DeepMind e a maioria dos laboratórios académicos no MuJoCo para o ciclo interno do treino de políticas.

Gazebo Harmonic — o nativo do ROS 2

O Gazebo é o simulador open source que foi, durante duas décadas, a opção por defeito do ROS. O Gazebo Harmonic é a LTS atual e combina na perfeição com o ROS 2 Humble e Jazzy.

O que faz bem:

• Integração com ROS 2. De primeira linha. A ponte ros_gz faz com que os seus nós ROS 2 funcionem em simulação sem qualquer alteração.
• Aberto e gratuito. Sem licença, sem Omniverse, sem dependência da NVIDIA. Corre em CPU, em GPU AMD, em qualquer coisa.
• Certo para testes de integração. Quando o objetivo é "verificar que a stack de navegação e o planeador continuam a funcionar depois de uma refatorização", o Gazebo é a escolha certa.

O que faz mal:

• Lento. Física de thread único, renderização por software por defeito. Ambientes paralelos significam arrancar vários processos Gazebo. Não se treinam políticas de RL em Gazebo; fazem-se testes rápidos.
• Pouco amigo da GPU. Sem batching em GPU. Acrescentar aceleração à renderização ajuda, mas não altera o escalonamento de fundo.
• O fosso sim-to-real é pior. O modelo de contactos é menos rigoroso do que o do MuJoCo e os modelos de sensores são menos realistas do que os do Isaac.

A realidade da computação. O Gazebo corre no que tiver. O servidor Kentino AI é exagero para ele. Um portátil chega. A contrapartida é que, para qualquer carga de RL não trivial, em poucos dias o Gazebo fica pequeno.

Genesis — o candidato académico de alto débito

O Genesis é o simulador multi-institucional que surgiu no final de 2024 com afirmações ousadas sobre desempenho e desde então provou a maior parte delas. Contribuíram a CMU, Stanford, o MIT CSAIL, a NVIDIA e Tsinghua.

O que faz bem:

• Débito. O Genesis ultrapassa os 40 milhões de FPS numa única RTX 4090 numa carga de cinemática inversa com um Franka. Nos humanoides o número é mais baixo, mas ainda na ordem dos milhões. A arquitetura foi construída de raiz em torno da simulação massivamente paralela.
• Multifísica. Rígido, fluido, corpo mole, granular, MPM. Se a sua tarefa envolve algo que não seja contacto rígido (manipulação de deformáveis, verter líquidos, interação com granulados), o Genesis é o único simulador desta lista que o trata nativamente.
• Ferramentas generativas de cenários. O Genesis inclui geração de cenários por prompt. Descreve um ambiente em texto e recebe um cenário.

O que faz mal:

• Ecossistema mais recente. Menos modelos prontos, menos tutoriais e uma comunidade mais pequena do que a do MuJoCo ou do Isaac.
• Menos testado em sim-to-real. A física é rápida; se a transferência para hardware é tão boa como a do MuJoCo é algo que a comunidade ainda está a estabelecer.
• Lacunas na documentação. Habitual em projetos de investigação em rápida evolução.

Onde se encaixa em 2026. O Genesis é a escolha certa para RL de estilo académico, quando quer o máximo de débito de ambientes e está disposto a escrever mais código de ligação próprio. Para um pipeline sim-to-real de produção hoje, o MuJoCo ou o Isaac são a opção mais segura. Fique atento.

A realidade do sim-to-real, edição de 2026

O estado prático do sim-to-real em maio de 2026:

• A aleatorização de domínio é obrigatória. Não pode treinar com um único conjunto de parâmetros físicos e esperar transferência. Massa, atrito, atrasos dos motores, ruído dos sensores, latência — tudo isto é aleatorizado dentro de um intervalo durante o treino.
• O atraso de atuação pesa mais do que se admite. Os atuadores de um robô real têm 5–25 ms de atraso entre o comando e o binário. Uma simulação que corra sem esse atraso produz políticas que oscilam em hardware. Inclua o atraso na simulação desde o primeiro dia.
• O ruído dos sensores tem de ser injetado. Deriva da IMU, ruído da câmara, falhas do sensor de profundidade. Os artigos de 2026 que funcionam incluem tudo isto no treino.
• O treino com vários simuladores é a linha da frente. O PolySim e frameworks semelhantes treinam em MuJoCo + Isaac e, por vezes, Gazebo em simultâneo. Os primeiros resultados são bons. O custo em computação é 2–3× o do treino com um só simulador.
• Movimento de humanoides com carga continua difícil. Transportar uma carga, recuperar de um empurrão enquanto se carrega algo — nas plataformas de R01, estas tarefas ainda degradam 50–80% da simulação para a realidade.

Conte com dois terços do desempenho no mundo real a vir da simulação. Conte com o último terço a vir de afinação em hardware, identificação do sistema e depuração teimosa.

Receita concreta: G1 + ROS 2 Humble + Isaac Lab num servidor Kentino AI

Hardware:
  - Unitree G1 EDU (Jetson Orin AGX, 23–43 DOF)
  - Kentino AI 256 Turin Dual / 4× RTX 5090 / 1× RTX Pro 6000 Blackwell
    (a Pro 6000 para simulação, as 5090 para treino de políticas em lote)
  - AP Wi-Fi 6E, linha de vista para a área de trabalho
  - Switch 10 GbE, ligação por cabo do Kentino AI ao AP

Software no servidor Kentino AI:
  - Ubuntu 22.04, CUDA 13, Docker
  - Isaac Sim 5.x + Isaac Lab (runtime Omniverse, Nucleus local)
  - ROS 2 Humble (ou Jazzy, se estiver a começar de raiz hoje)
  - PyTorch 2.x, JAX, RSL RL
  - vLLM a servir um VLM para perceção de alto nível (ver I02)
  - MuJoCo + MJX como segundo simulador, para validação cruzada

Software no G1:
  - Unitree SDK2 (ciclo de controlo das articulações em C++)
  - unitree_ros2 (Humble) no Jetson
  - Nós ROS 2 personalizados: command_router, perception_relay
  - Cliente gRPC para o vLLM no servidor Kentino AI

Fluxo de trabalho:
  1. Treinar uma política de locomoção ou de corpo inteiro em Isaac Lab
     na Pro 6000 (mais de 4,000 instâncias G1 em paralelo, RSL RL).
  2. Validar a política em MJX (4× 5090 em lote) com diferentes
     seeds de aleatorização de domínio.
  3. Implementar a política via TorchScript no Jetson do G1, envolvida
     num nó ROS 2 que o ciclo de controlo do Unitree SDK2 invoca.
  4. Os comandos de alto nível em ROS 2 fluem do grafo de tarefas do
     laboratório através do command_router para a política.
  5. A perceção pesada (VLM) vive no servidor Kentino AI, alcançada por
     Wi-Fi 6E + gRPC.

O tempo total de arranque para uma equipa com experiência prévia em ROS 2 é de duas a três semanas. Para uma equipa a aprender ROS 2 de raiz, são dois a três meses. Planeie em conformidade. A parte da computação do servidor Kentino AI é a mais fácil.

A opinião honesta

Três opiniões, sem rodeios:

1. O ROS 2 é a camada de abstração certa. Os SDK nativos são necessários, mas não suficientes. Construa sobre o wrapper ROS 2 e trate o SDK do fabricante como um serviço que o wrapper consome. Ir pelo proprietário não lhe traz nada e custa-lhe o resto do ecossistema.
2. O Isaac Sim é o futuro, mas o presente é MuJoCo + ROS 2 para a maioria das equipas. Se o seu trabalho é RL em locomoção e manipulação destra, o MuJoCo / MJX é a opção mais barata, mais rápida e mais fácil de implementar. Se o seu trabalho é perceção fotorrealista, geração de dados em grande escala ou fine-tuning de modelos fundacionais do tipo VLA, o Isaac é a única escolha. A maioria dos laboratórios precisa dos dois, e o servidor Kentino AI tem folga para correr ambos.
3. Os laboratórios na linha da frente usam os quatro. O Isaac para a renderização e o pipeline de modelos fundacionais. O MuJoCo para o ciclo interno de RL. O Gazebo para os testes de integração em ROS 2. O Genesis para o trabalho de multifísica. Fingir que vai precisar só de um é como as equipas acabam a reescrever a sua stack um ano depois.

---

Este texto faz parte da Kentino Wiki, uma série de referência sobre computação de IA, robótica e os sistemas que as ligam. Comentários e correções são bem-vindos em info@kentino.com.