Jumper: Como Treinar um Robô Caranguejo em Simulação em 2026

Olá HaWkers, um robô em formato de caranguejo apareceu entre os projetos de robótica em alta: o Jumper, da KingKong Robotics. A documentação descreve um corpo com 22 graus de liberdade e um conjunto aberto de ferramentas para criar aparência, treinar movimentos e montar cenas. O detalhe decisivo é outro: a própria equipe distingue o que já funciona no simulador do que ainda precisa ser comprovado na máquina física.

Você gostaria de experimentar robótica sem comprar um robô e sem confundir uma animação convincente com um teste de hardware? Neste guia, vamos percorrer o fluxo reproduzível do projeto, entender como uma política de movimento é treinada e definir verificações antes de confiar em uma demonstração.

O que o Jumper realmente oferece

O repositório principal reúne o modelo do robô, tarefas de treino, scripts de execução e um controlador que pode ser empacotado para diferentes ambientes. Segundo o guia oficial do projeto, o treino usa MuJoCo, MuJoCo Warp, mjlab e rsl_rl. A ideia é produzir uma política: um programa que recebe observações do estado do robô e escolhe ações para seus motores. Na simulação, isso permite ensaiar locomoção e outros movimentos antes de pensar no barramento real de servos.

Existe também o projeto separado jumper-design, voltado a aparências e cenários. Seus arquivos .skin e .map têm papéis diferentes de uma política de controle. Uma pele visual não altera magicamente o comportamento do robô, e um cenário importado para reprodução não vira automaticamente um ambiente de treino. Essa distinção evita uma leitura comum de vídeos de demonstração: ver um robô em um cenário bonito não prova que a mesma sequência foi treinada naquele cenário nem executada no dispositivo físico.

A ficha de hardware publicada pela equipe especifica dimensões de 400 × 400 × 200 mm, um processador Rockchip RK3576, sensores e 22 servos táteis. Esses são dados declarados pelos autores para o hardware. Se você só pretende estudar o software, nenhum desses componentes precisa estar na sua mesa. O ponto de partida é o modelo digital e uma máquina capaz de executar Python e o simulador.

Por que a simulação vem antes do robô físico

Treinar por tentativa e erro diretamente em uma máquina com juntas, bateria e partes móveis custa tempo e pode danificar componentes. No simulador, uma tarefa define observações, ações, condições de término e uma função de recompensa. Uma política aprende a maximizar essa recompensa ao longo de muitas tentativas. Não há garantia de que um movimento estável no modelo será igualmente estável sobre um piso real: atrito, folgas mecânicas, atrasos e leituras de sensores mudam.

O Jumper é interessante porque expõe essa passagem entre mundos como parte do fluxo, em vez de esconder o problema. O tutorial oficial acompanha treino, reprodução, exportação e empacotamento. Ele alerta que uma ordem incorreta de juntas ou um controle com escala diferente pode gerar um programa que executa sem erro aparente, mas move o robô de modo errado. A validação, portanto, precisa olhar para resultados e contratos de controle, não só para o código de saída do processo.

Se você acompanha a discussão mais ampla sobre modelos que representam ambientes físicos, vale conectar este experimento ao artigo sobre world models e simulação do mundo real. Aqui o foco é mais concreto: uma tarefa de locomoção, um simulador específico e limites documentados para a transferência ao hardware.

Prepare um ambiente que você consiga reproduzir

O guia de instalação do projeto pede Python de 3.10 a 3.13. Ele diferencia máquinas NVIDIA, que podem usar o caminho de GPU, das demais, que usam MuJoCo nativo na CPU. O comando abaixo cria um ambiente isolado e instala as dependências do próprio repositório para uma experiência inicial em CPU. Faça isso em uma cópia de trabalho dedicada; o download de bibliotecas de aprendizado de máquina pode ser grande.

# Crie e ative um ambiente Python isolado no projeto.
git clone https://github.com/KingKongRobotics/jumper.git
cd jumper
python3 -m venv .venv
source .venv/bin/activate

# Instale PyTorch para CPU e o pacote local em modo editável.
python -m pip install torch torchvision
python -m pip install -e .

Não substitua o último comando por uma instalação avulsa de mjlab ou rsl_rl. O projeto mantém cópias próprias dessas bibliotecas dentro de rl/, e o modo editável configura os caminhos esperados pelos scripts. Se a máquina tiver GPU NVIDIA, siga o ramo específico do documento oficial para escolher a versão adequada do PyTorch; copiar uma linha de instalação de outra placa pode criar um ambiente que importa as bibliotecas e falha apenas ao inicializar CUDA.

Antes de treinar, confira se a lista de tarefas carrega e se o simulador está acessível. O primeiro comando, segundo a documentação, foi desenhado para listar as tarefas sem importar todo o conjunto pesado de dependências. O segundo verifica a instalação local do MuJoCo. Falhas aqui são mais fáceis de investigar do que um treino interrompido depois de baixar pacotes e criar logs.

# Confira o registro de tarefas antes de gastar tempo com treino.
python scripts/train.py --list

# Confirme que o MuJoCo instalado pode ser importado.
python -c 'import mujoco; from mujoco import rollout; print(mujoco.__version__)'

Treine uma tarefa pequena e leia o resultado

O repositório fornece tarefas com nomes como jumper.flat, jumper.tripod, jumper.jump e jumper.dance. Para começar em uma máquina sem CUDA, o teste rápido recomendado pelos autores usa o backend nativo, CPU, 64 ambientes paralelos e três iterações. Esse teste confirma que o pipeline básico executa; três iterações não ensinam uma marcha confiável nem demonstram qualidade da política.

# Faça um teste curto do pipeline em CPU, sem abrir visualizador.
python scripts/train.py --task jumper.flat \
  --backend native --device cpu --num_envs 64 \
  --max-iterations 3 --headless

Observe o backend indicado no início da execução, as iterações concluídas e a ausência de erro. A recompensa média pode começar negativa; isso, sozinho, não significa que a instalação falhou. Se o processo encerrar por falta de memória, reduza --num_envs: no backend nativo, cada ambiente mantém estruturas de simulação próprias. O número de ambientes é uma escolha de capacidade da máquina, não uma pontuação de qualidade.

Depois do teste curto, você pode executar uma tarefa de locomoção por mais tempo e reproduzir um checkpoint. O guia do projeto mostra jumper.tripod como exemplo de treino e scripts/play.py para reprodução. A política aprendida depende de configuração, semente, hardware e duração; não copie um número de recompensa de outra máquina como se fosse uma meta universal.

# Treine uma marcha em CPU; ajuste os ambientes à memória disponível.
python scripts/train.py --task jumper.tripod \
  --backend native --device cpu --num_envs 64

# Reproduza a tarefa com o checkpoint gerado pelo fluxo do projeto.
python scripts/play.py --task jumper.tripod

O que medir além de uma animação bonita

Uma demonstração visual é útil, mas não resume o comportamento de uma política. Comece verificando se o robô mantém estabilidade em diferentes pisos e condições iniciais, se recupera de pequenas perturbações e se as ações respeitam os limites esperados. Registre a configuração da tarefa, o checkpoint usado e o cenário de reprodução. Sem essas informações, fica difícil comparar duas execuções e descobrir se uma mudança ajudou ou apenas produziu um vídeo favorável.

O tutorial do Jumper recomenda ler o resultado de cada etapa, inclusive mensagens de empacotamento. O fluxo inclui quadros de referência que permitem comparar a saída de uma política em ambientes diferentes. Quando observações ou alvos divergem, a causa pode estar na ordem das juntas, na escala do controle ou no caminho de inferência. Um pacote que abre no navegador e responde ao teclado ainda precisa dessas verificações antes de ser associado a um controlador físico.

Você pode criar uma pequena ficha de experimento com informações que já estão ao seu alcance: tarefa, backend, número de ambientes, máquina usada, checkpoint e critérios observados. Não invente uma taxa de sucesso se não executou uma bateria de testes. Escreva “não medido” quando faltar evidência; isso é mais útil do que transformar uma percepção visual em porcentagem. Para uma equipe, essa disciplina evita que um vídeo de demonstração vire uma promessa de produto.

Aparências, cenas e pacotes de movimento são coisas distintas

O jumper-design aceita descrições de aparência e cenário, mas um arquivo visual precisa ser verificado como pacote. O guia rápido oficial fornece comandos para instalar o projeto, baixar ativos via Git LFS e validar um mapa de exemplo. O exemplo abaixo é uma rota separada do treino de políticas: ele testa a estrutura de um arquivo .map já existente no repositório de design.

# Em outro diretório, prepare as ferramentas de aparência e cena.
git lfs install
git clone https://github.com/KingKongRobotics/jumper-design.git
cd jumper-design
git lfs pull
python3 -m pip install -e '.[sim,dev]'

# Valide a estrutura e a compatibilidade de um mapa incluído no projeto.
python scripts/shellflow.py verify-package \
  library/maps/park-pump-track.map \
  --profile robots/jumper/profile.json

Esse verificador examina a declaração do pacote, sua integridade e compatibilidade com o perfil informado. Você pode acrescentar --mujoco para testar o carregamento no simulador, conforme o guia. Mesmo assim, o resultado não substitui uma inspeção visual nem um teste de encaixe físico. Tratar essas etapas como evidências diferentes é essencial: pacote válido, modelo carregável, cena legível e robô seguro são quatro afirmações distintas.

O repositório principal também descreve pacotes .app para políticas treinadas, controles e arquivos de referência. A extensão não deve ser confundida com um aplicativo convencional de celular. Nesse fluxo, ela representa um arquivo transportável que precisa ser construído e verificado segundo o contrato do projeto. O tutorial mostra etapas específicas para navegador e placa, com dependências adicionais de Rust e ferramentas de compilação; vale segui-lo integralmente quando você passar do laboratório local para a distribuição.

Onde termina a evidência de hardware

Aqui está a distinção que mais importa para avaliar o Jumper com honestidade. O estado do projeto documentado pela equipe afirma que treino, simulação, exportação e verificações de pacotes no host estão implementados. O mesmo texto registra que a inferência RKNN ainda não tinha sido verificada na placa e que o loop do controlador não havia acionado o barramento de motores ao vivo. Portanto, não é correto descrever o repositório como prova de que toda política treinada já roda no robô físico.

A documentação de implantação propõe verificações antes de tocar no barramento, incluindo modo seco e comparação com quadros de referência. São barreiras úteis, mas também não são uma certificação universal de segurança. Mesmo com uma comparação numérica consistente, a máquina física traz quedas, colisões, aquecimento e limites de energia que uma reprodução em tela não elimina. Quem tiver acesso ao protótipo deve obedecer às instruções de hardware dos responsáveis e testar em ambiente controlado.

Para quem não tem o robô, isso não diminui o valor educacional do projeto. Pelo contrário: a separação explícita entre simulação e mundo físico permite aprender a fazer perguntas melhores. Qual parte é um modelo? Qual parte é uma medição? O que foi executado no navegador, no computador e na placa? Em robótica, saber localizar essas fronteiras é tão importante quanto gerar um movimento interessante.

Um roteiro responsável para continuar

Comece por uma tarefa simples e registre o ambiente em que ela foi executada. Depois, altere apenas uma variável por vez: número de ambientes, tempo de treino ou configuração do cenário. Compare o comportamento de maneira repetível e guarde o checkpoint usado. Quando a locomoção parecer estável, leia o tutorial de empacotamento e confira seus testes de referência antes de pensar em implantação. Você terá uma sequência de evidências, não apenas uma coleção de comandos que terminaram sem erro.

O mesmo método vale para outros projetos de robótica aberta. Uma licença acessível e um vídeo envolvente despertam interesse, mas a pergunta técnica continua: quais capacidades foram reproduzidas, em qual ambiente e com quais limites conhecidos? No Jumper, a documentação oferece um caminho para responder sem comprar hardware logo de início. Use esse caminho para experimentar, aprender e relatar resultados com precisão.

Bora pra cima! 🦅

📚 Quer Acompanhar o Que Vem Por Aí?

Este artigo cobriu o Jumper e o treino de movimentos em simulação, mas o ecossistema muda toda semana e nem tudo vira artigo aqui.

No X eu compartilho o que estou testando, os bastidores dos projetos e as novidades que aparecem antes de virarem post.

Me Segue Lá

👉 Seguir @jeffbruchado no X

💡 Conteúdo diário sobre desenvolvimento, carreira e as ferramentas que eu realmente uso