Dados Sintéticos para Políticas de Robôs: Onde a Simulação Ajuda

A cada poucos meses, alguém percebe que gravar cinquenta episódios manualmente é lento e pergunta se um simulador poderia produzi-los. É uma pergunta justa. A resposta honesta tem três partes: dados gerados ajudam, não substituem as gravações reais, e a proporção entre esses dois fatos depende inteiramente do tipo de dados sintéticos que você se refere.

Esta página detalha o que o trabalho publicado realmente mediu, o que você pode executar hoje em um braço de baixo custo como o SO-100, e onde a lacuna sim-para-real consome os ganhos. A versão curta, antes dos detalhes: os sistemas que relatam os maiores multiplicadores multiplicam um pequeno conjunto de demonstrações humanas reais. Eles não eliminam a necessidade delas.

Quatro coisas diferentes são chamadas de dados sintéticos

Antes de comparar números, vale a pena separar as famílias, porque um artigo que relata um multiplicador de 100x e um artigo que relata um ganho de sucesso de 5 pontos estão frequentemente descrevendo o mesmo pipeline de diferentes perspectivas. O fio condutor é que algo no conjunto de dados LeRobot foi produzido por uma máquina em vez de gravado a partir de um braço físico. O que difere é qual parte.

Apenas os três primeiros são dados sintéticos no sentido que este artigo aborda. O quarto vale a pena mencionar porque é incluído na mesma conversa e é de longe o item mais barato da lista. Se você ainda não ativou as aumentações que seu treinador oferece, faça isso antes de instalar um simulador.

O que os números publicados realmente dizem

Aqui está a base de evidências, com os números conforme as fontes os apresentam, em vez de como os comunicados de imprensa os resumem. Cada linha abaixo provém de um artigo ou página de projeto lida em 23 de agosto de 2026.

O padrão em cada ablação honesta é o mesmo. Dados sintéticos ampliam a cobertura a baixo custo. Não cria informações sobre sua garra, folga do servo, iluminação ou altura da mesa que não estivessem presentes nas demonstrações reais em algum lugar. Se sua política falha porque o efetor final fecha meio segundo atrasado, nenhuma quantidade de variação simulada o corrige. Isso é um problema de temporização da garra nas gravações reais.

Uma descoberta do MimicGen vale a pena ser levada para suas próprias sessões de gravação, pois vai contra o conselho usual. O projeto gerou dois conjuntos de dados no Square D2, um semeado com 10 demonstrações de um operador humano de melhor qualidade e outro com 10 demonstrações de um operador de pior qualidade, ambos retirados do conjunto de dados robomimic multi-humano Square. As políticas treinadas em cada um alcançaram resultados comparáveis, o que os autores interpretaram como um sinal de que, no regime de dados em larga escala, a qualidade dos dados pode não importar tanto. Leia com atenção, essa é uma afirmação sobre as dez demonstrações iniciais, não sobre seus cinquenta episódios reais. Significa que um conjunto inicial um pouco desorganizado não é o que está entre você e um conjunto de dados gerado utilizável. Não significa que os episódios reais nos quais você co-treina possam ser desorganizados, porque esses são os que carregam as informações que o simulador não possui.

A lacuna sim-para-real, concretamente

A lacuna é geralmente discutida como uma única quantidade, o que não é útil. São pelo menos cinco incompatibilidades separadas, e elas têm tamanhos diferentes em um braço de hobby de 110 a 150 EUR do que em um Franka.

• Contato e atrito. O Isaac Lab afirma claramente que, dado o mesmo hardware e a mesma versão do Isaac Sim e do PhysX, a simulação é reproduzível, mas que os resultados variam entre diferentes configurações de hardware devido à precisão de ponto flutuante e erros de arredondamento, e que o PhysX não garante determinismo para nenhuma cena com corpos não rígidos, como tecido ou corpos moles.
• Atuação. Um servo de barramento Feetech STS3215 operando a 7.4 V cede sob carga, tem folga e muda de comportamento à medida que aquece. O modelo MJCF para o SO-101 empresta seus parâmetros de motor de um projeto não relacionado, em vez de identificá-los em seu braço.
• Renderização. Ruído da câmera, rolling shutter, autoexposição e a tonalidade exata da sua mesa não estão na renderização. Esta é a metade da lacuna que o Cosmos-Transfer1 foi construído para fechar: seu fluxo de trabalho de aumento robótico mapeia um exemplo sintético de robótica para múltiplos exemplos realistas a partir de segmentação, profundidade ou condicionamento de borda.
• Sincronização. Um simulador avança a uma taxa fixa. Um loop de controle real não, e o próprio modelo custa de 20 a 485 ms por etapa de ação, dependendo de qual você escolheu. Veja latência de inferência.
• Estatísticas de objetos. Cenas simuladas são amostradas de uma distribuição que alguém escreveu. Sua mesa de cozinha não é.

O que um SO-100 simulado realmente sabe sobre o seu braço

Esta é a parte que decide se algo do que foi dito acima vale o seu fim de semana, e a primeira surpresa é que o SO-100 e o SO-101 não são igualmente atendidos. O repositório SO-ARM100 do TheRobotStudio mantém seus ativos de simulação em Simulation/. A pasta SO100 contém um único arquivo URDF e nada mais. A pasta SO101 contém arquivos URDF e MuJoCo: scene.xml, so101_new_calib.xml, so101_old_calib.xml, os URDFs correspondentes e um joints_properties.xml. Se você quer um modelo físico em vez de uma cadeia cinemática, você quer os arquivos SO-101.

Foram gerados com o plugin onshape-to-robot a partir de um modelo CAD projetado no Onshape, o que significa que a cinemática e as malhas visuais são tão boas quanto o CAD. A dinâmica é outra história, e o README do próprio repositório é franco sobre três coisas. As malhas de colisão da base foram removidas devido a um comportamento de colisão problemático durante a simulação e o planejamento. As propriedades do motor STS3215 são adaptadas do projeto Open Duck Mini em vez de medidas em um SO-101. E a convenção do gripper LeRobot, onde 0 é totalmente fechado e 100 é totalmente aberto, ainda não está explicitamente refletida nos arquivos URDF e MuJoCo. Cada um desses é um ponto onde uma política treinada puramente nesse modelo se comportará de forma diferente na sua mesa.

Randomização de domínio, e o que ela não corrige

A resposta padrão para a lacuna é parar de tentar igualar a realidade e, em vez disso, treinar em uma distribuição ampla o suficiente para que a realidade se encaixe nela. Tobin e colegas mostraram a versão forte disso em 2017: um detector de objetos treinado apenas em imagens simuladas com texturas aleatórias não realistas, sem nenhum pré-treinamento em imagens reais, localizou objetos reais com uma precisão de 1,5 cm e permaneceu robusto a distratores e oclusões parciais.

Isaac Lab expõe a mesma ideia que os termos de evento que você anexa a uma configuração de ambiente. Estes são os controles, pelos seus nomes de função reais em isaaclab.envs.mdp, para que você possa lê-los em vez de adivinhar.

Aqui está o limite, e é aquele em que as pessoas tropeçam. A randomização amplia a distribuição que a política viu dentro do modelo que você construiu. Ela não pode introduzir um efeito físico que o simulador não represente. Se o PhysX não está modelando a folga e a queda térmica dos seus servos STS3215, randomizar a rigidez deles não ensina nada à política sobre folga. É por isso que um braço que contrai e depois cede sob uma política treinada em simulação não é um problema de orçamento de randomização. É um problema de modelagem.

O caminho manual: gerando dados no Isaac Lab

Isaac Gym é um software legado. A própria página da NVIDIA é intitulada "Isaac Gym - Agora Descontinuado" e afirma que os desenvolvedores podem baixá-lo e continuar a usá-lo, mas que não é mais suportado, apontando para o Isaac Lab em vez disso. Se você quiser o histórico, cobrimos ambos: e . Para novos trabalhos em 2026, comece com o Isaac Lab.

1. 1
   Instalar Isaac Sim e Isaac Lab

   A página de instalação do pip afirma que as instruções são para Isaac Sim 5.X, que requer Python 3.11. O clone do código-fonte fornece os scripts necessários para os próximos passos.

   bash

   pip install "isaacsim[all,extscache]==5.1.0" \
       --extra-index-url https://pypi.nvidia.com
   
   git clone https://github.com/isaac-sim/IsaacLab.git --branch main
   cd IsaacLab
   sudo apt install cmake build-essential
   ./isaaclab.sh --install
   
   # smoke test
   ./isaaclab.sh -p scripts/tutorials/00_sim/create_empty.py

2. 2
   Gravar cerca de dez demonstrações humanas

   A documentação do Isaac Lab é específica: cerca de 10 demonstrações bem-sucedidas são necessárias para que os passos seguintes tenham êxito. Suas dicas são igualmente específicas. Mantenha as demonstrações curtas, siga um caminho direto em vez de se mover ao longo de eixos arbitrários, e não pause, pois não é óbvio para uma política por que e quando pausar.

   bash

   ./isaaclab.sh -p scripts/tools/record_demos.py \
       --task Isaac-Stack-Cube-Franka-IK-Rel-v0 \
       --device cpu \
       --teleop_device spacemouse \
       --dataset_file ./datasets/dataset.hdf5 \
       --num_demos 10

3. 3
   Anotar os limites das subtarefas

   Mimic divide as demonstrações de entrada em subtarefas para que possa re-sincronizar e re-direcionar os segmentos. A flag --auto faz isso sem intervenção humana para tarefas que definem anotação automática; sem ela, você pausa com B, continua com N e marca um limite com S. Observe que o ID da tarefa ganha um sufixo -Mimic.

   bash

   ./isaaclab.sh -p scripts/imitation_learning/isaaclab_mimic/annotate_demos.py \
       --device cpu \
       --task Isaac-Stack-Cube-Franka-IK-Rel-Mimic-v0 \
       --auto \
       --input_file ./datasets/dataset.hdf5 \
       --output_file ./datasets/annotated_dataset.hdf5

4. 4
   Gerar o conjunto de dados multiplicado

   Este é o passo que transforma 10 em 1000. Mimic aplica um critério booleano de sucesso a cada candidato e mantém apenas aqueles que completaram a tarefa, então a contagem de saída é menor que a contagem de tentativas. A documentação indica que a taxa de sucesso do candidato pode ser tão alta quanto 70 por cento em casos simples e abaixo de 1 por cento para tarefas difíceis e robôs complexos: cerca de 50 por cento para o empilhamento de cubos Franka, e 65 a 80 por cento para o GR1T2 pick and place, onde 1000 demonstrações levam de 18 a 40 minutos (19 minutos em uma RTX ADA 6000 a 80 por cento).

   bash

   ./isaaclab.sh -p scripts/imitation_learning/isaaclab_mimic/generate_dataset.py \
       --device cpu \
       --num_envs 10 \
       --generation_num_trials 1000 \
       --headless \
       --input_file ./datasets/annotated_dataset.hdf5 \
       --output_file ./datasets/generated_dataset.hdf5

5. 5
   Converter HDF5 para um conjunto de dados LeRobot

   Tudo acima produz HDF5 no formato robomimic, e o núcleo do Isaac Lab não inclui um conversor LeRobot próprio: sua documentação apenas diz que você pode converter o conjunto de dados gerado para o formato LeRobot. Dois projetos fornecem o conversor real. IsaacLab-Arena fornece um direcionado ao GR00T, totalmente impulsionado por uma configuração YAML, e LeIsaac fornece seu próprio par para a rota SO-101 (veja abaixo).

   bash

   # IsaacLab-Arena, GR00T LeRobot format
   python isaaclab_arena_gr00t/lerobot/convert_hdf5_to_lerobot.py \
       --yaml_file isaaclab_arena_gr00t/lerobot/config/gr1_manip_config.yaml

Por que as tentativas de geração falham e o que mudar

Uma taxa de sucesso candidata que oscila entre 70 por cento e menos de 1 por cento não é um mistério, e o Isaac Lab documenta as armadilhas comuns em vez de deixar você adivinhar. Cada uma delas é algo que você controla no momento da gravação, e é por isso que vale a pena ler esta lista antes de gravar as dez demonstrações iniciais, em vez de depois da primeira execução de geração decepcionante.

• Demonstrações muito longas. Um horizonte de tempo mais longo é mais difícil para uma política aprender. Comece perto do primeiro objeto e minimize o movimento.
• Demonstrações não são suaves. Movimentos irregulares são difíceis para uma política decifrar, e hardware de teleoperação melhor fornece dados melhores: a documentação afirma claramente que um SpaceMouse supera um teclado.
• Pausas. Pausas são difíceis de aprender, porque não é óbvio para uma política por que e quando pausar. Mantenha o movimento fluido.
• Muitas subtarefas. Mais subtarefas significam mais junções entre segmentos de trajetória, o que resulta em movimento menos suave e uma taxa de sucesso de geração mais baixa. Anote os limites onde o braço é improvável de colidir com qualquer coisa.
• Sem ruído de ação. O ruído de ação torna as políticas resultantes mais robustas.
• Gravação cortada muito justa. Se a gravação parar no quadro exato em que o termo de sucesso é acionado, ele pode não ser reativado durante a reprodução. Deixe um buffer no final.
• Reprodução não determinística. A física no Isaac Lab não é deterministicamente reproduzível em env.reset, então algumas demonstrações humanas falham na reprodução. Colete mais do que você precisa e mantenha as que sobrevivem à anotação. Tudo o que chega a um arquivo HDF5 gerado por Mimic é uma demonstração bem-sucedida e pode ser usado para treinamento, mesmo que a reprodução falhe posteriormente.

A etapa de interpolação entre segmentos de subtarefas unidos tem seu próprio ajuste, e o número de etapas de interpolação necessárias escala com a velocidade de movimento do robô e a amplitude da distribuição de reinicialização do objeto. Uma tarefa complexa com uma grande distribuição de reinicialização deixa lacunas maiores entre os segmentos, o que exige mais etapas de interpolação para resultar em movimento contínuo. Se seus vídeos gerados mostrarem o braço cambaleando entre as fases, esse é o parâmetro a ser observado antes de culpar as demonstrações iniciais.

O mesmo pipeline em um SO-101, com o braço líder real

Este é o interessante para quem lê esta página, pois é o único pipeline aberto que coloca um dentro do Isaac Lab e permite que você o controle com o braço líder físico que você já possui. LeIsaac, versão 0.4.0 no momento da escrita, é o playground oficial de simulação de aprendizado por imitação integrado ao EnvHub da LeRobot. Sua tabela de compatibilidade lista três combinações funcionais; a mais recente combina Isaac Sim 5.1 com Isaac Lab v2.3.0, CUDA 12.8, PyTorch 2.7.0 e Python 3.11, e a documentação recomenda Isaac Sim 5.0 ou mais recente para placas da série 50.

git clone https://github.com/LightwheelAI/leisaac.git --recursive
conda create -n leisaac python=3.11 && conda activate leisaac
conda install -c "nvidia/label/cuda-12.8.1" cuda-toolkit
pip install -U torch==2.7.0 torchvision==0.22.0 \
  --index-url https://download.pytorch.org/whl/cu128
pip install "isaacsim[all,extscache]==5.1.0" --extra-index-url https://pypi.nvidia.com
sudo apt install cmake build-essential
cd leisaac/dependencies/IsaacLab && ./isaaclab.sh --install && cd ../..
pip install -e source/leisaac
pip install -e "source/leisaac[lerobot]"
pip install numpy==1.26.0

Com isso configurado, o braço líder em /dev/ttyACM0 controla o seguidor simulado e grava diretamente em HDF5. O é o mesmo que você já conhece da gravação real, apenas o seguidor é um corpo rígido no PhysX.

python scripts/environments/teleoperation/teleop_se3_agent.py \
    --task=LeIsaac-SO101-PickOrange-v0 \
    --teleop_device=so101leader \
    --port=/dev/ttyACM0 \
    --num_envs=1 \
    --device=cuda \
    --enable_cameras \
    --record \
    --dataset_file=./datasets/dataset.hdf5

A maioria desses IDs também existe como uma variante -Direct-v0, e python scripts/environments/list_envs.py imprime a lista atual. Você também pode pular completamente o desvio HDF5 e escrever no formato LeRobot durante a teleoperação adicionando três flags. Duas ressalvas vêm da própria documentação: o gravador pula automaticamente os primeiros 5 frames de cada episódio para evitar instabilidade dos estados iniciais, e isso pode causar pequenos atrasos na teleoperação, o que é exatamente o tipo de coisa que altera sutilmente o caráter de suas demonstrações. Ele também só salva episódios que a tarefa marcou como bem-sucedidos.

python scripts/environments/teleoperation/teleop_se3_agent.py \
    --task=LeIsaac-SO101-PickOrange-v0 \
    --teleop_device=so101leader \
    --port=/dev/ttyACM0 \
    --num_envs=1 --device=cuda --enable_cameras --record \
    --use_lerobot_recorder \
    --lerobot_dataset_repo_id=<your-user>/<dataset-name> \
    --lerobot_dataset_fps=30

A etapa de multiplicação é então executada nessas gravações. LeIsaac envolve Isaac Lab Mimic em quatro comandos, porque Mimic generaliza trajetórias a partir de poses do efetuador final e do objeto: converter as ações do espaço articular para ações baseadas em IK, anotar, gerar e depois converter de volta para o espaço articular.

python scripts/mimic/eef_action_process.py \
  --input_file ./datasets/mimic-lift-cube-example.hdf5 \
  --output_file ./datasets/processed_mimic-lift-cube-example.hdf5 \
  --to_ik --headless

python scripts/mimic/annotate_demos.py --device cuda \
  --task LeIsaac-SO101-LiftCube-Mimic-v0 \
  --input_file ./datasets/processed_mimic-lift-cube-example.hdf5 \
  --output_file ./datasets/annotated_mimic-lift-cube-example.hdf5 \
  --enable_cameras

python scripts/mimic/generate_dataset.py --device cuda \
  --num_envs 1 --generation_num_trials 10 \
  --input_file ./datasets/annotated_mimic-lift-cube-example.hdf5 \
  --output_file ./datasets/generated_mimic-lift-cube-example.hdf5 \
  --enable_cameras

python scripts/mimic/eef_action_process.py \
  --input_file ./datasets/generated_mimic-lift-cube-example.hdf5 \
  --output_file ./datasets/final_generated_mimic-lift-cube-example.hdf5 \
  --to_joint --headless

Em seguida, converta para LeRobot. Este é o passo onde a regra de formato da plataforma se torna um desafio, e o LeIsaac por acaso fornece exatamente os dois conversores de que você precisa: isaaclab2lerobot.py escreve LeRobot v2, que é o que os carregadores GR00T aceitam, e isaaclab2lerobotv3.py escreve v3 para Pi0.5, SmolVLA e ACT.

pip install lerobot==0.3.3
pip install numpy==1.26.0

python scripts/convert/isaaclab2lerobot.py \
    --task_name=LeIsaac-SO101-PickOrange-v0 \
    --repo_id=<your-user>/so101_pick_orange_sim \
    --hdf5_root=./datasets \
    --hdf5_files=dataset.hdf5

Duas rotas para uma política treinada

Modelos de mundo de vídeo: a camada mais recente e a menos medida

A ideia por trás do DreamGen é que um modelo generativo de vídeo, adaptado à incorporação do robô alvo, pode imaginar episódios plausíveis em cenas que você nunca visitou. O pipeline tem quatro estágios: ajuste fino do modelo de mundo de vídeo, geração de vídeos de robôs sintéticos fotorrealistas, recuperação de sequências de pseudo-ação com um modelo de ação latente ou um modelo de dinâmica inversa, e então o treinamento da política do robô com o resultado. O repositório GR00T-dreams da NVIDIA implementa exatamente isso.

O resultado principal é real e merece ser levado a sério: dados de teleoperação de apenas uma única tarefa de pegar e colocar em um ambiente produziram 22 novos comportamentos em um humanoide, tanto em ambientes vistos quanto não vistos. A ressalva é igualmente real e reside na terceira etapa.

O co-treinamento é a receita que realmente mostra ganhos

Se você tirar uma lição operacional da literatura, que seja esta. O estudo de co-treinamento sim-e-real (Maddukuri e colegas, 2025) buscou encontrar uma receita simples para usar dados de simulação para resolver tarefas de manipulação robótica baseadas em visão, em dois domínios, um braço robótico e um humanoide, e sua conclusão é que você treina em uma mistura. Dados de simulação melhoraram o desempenho de tarefas no mundo real em uma média de 38 por cento, e o artigo é explícito que isso se manteve mesmo com diferenças notáveis entre a simulação e os dados do mundo real.

Essa última cláusula importa mais do que os 38 por cento. Significa que a simulação não precisa ser um gêmeo digital perfeito para ser útil, desde que os dados reais estejam na mistura para ancorá-la. A transferência apenas por simulação é o caminho caro: o mesmo artigo afirma que treinar uma política exclusivamente em simulação e transferi-la para o mundo real frequentemente exige um esforço humano substancial para preencher a lacuna da realidade. O co-treinamento evita a maior parte desse esforço ao nunca pedir à política para fechar a lacuna por conta própria.

Praticamente, nesta plataforma, o co-treinamento significa uma coisa: coloque ambos os conjuntos de episódios no mesmo conjunto de dados LeRobot com chaves de câmera consistentes, ordem de juntas consistente e unidades consistentes, então execute um ajuste fino normal. Não há um controle de peso de mistura no formulário de treinamento. Se você quiser uma proporção de 3:1 de simulação para real, você expressa isso pela quantidade de episódios de cada um que você coloca no conjunto de dados.

A vitória mais barata da simulação não são dados de treinamento

É avaliação. Executar dezenas de testes reais por tarefa para comparar dois é um dia de tempo de braço, e o braço se desvia entre os testes. O SIMPLER (Li e colegas, 2024) construiu ambientes simulados cujo propósito é pontuar políticas reais em vez de treiná-las, e então mediu o quão bem o ranking da simulação prevê o real. Um único ambiente SIMPLER renderiza a 3.500 passos de simulação por segundo em uma RTX 4090 de consumidor com resolução de 640 por 512, o que, sob uma frequência de simulação de 500 Hz, representa um aumento de velocidade de 7x em relação à avaliação real.

Essas são médias de três grupos de tarefas do Google Robot para seis pontos de verificação de código aberto comuns: três pontos de verificação RT-1 em diferentes estágios de treinamento, RT-1-X, RT-2-X e Octo-Base. O lado real não tem uma contagem uniforme de testes, o que vale a pena saber antes de citá-lo: 75 testes para pegar lata de Coca-Cola, 60 para mover para perto, 54 para as tarefas de abrir e fechar gaveta e 27 para a tarefa mais longa de gaveta e maçã. A comparação com o MSE de validação é a parte útil. A seleção de modelos por perda de validação classifica esses pontos de verificação mal, e um Pearson r de 0.924 sob correspondência visual significa que se um ponto de verificação pontua melhor no SIMPLER, ele muito provavelmente pontua melhor no banco de testes. Esse é um placar repetível de um dia para o outro, e não exige que você acredite em nada sobre a transferência de treinamento sim-para-real.

Se você quiser o contexto mais amplo sobre o que esses números de benchmark dizem e não dizem sobre um , escrevemos isso separadamente em .

Onde esta plataforma não o ajuda

Ser claro sobre os limites economiza o tempo de todos. AY-Robots é uma plataforma de gravação, treinamento e serviço. Não possui simulador.

• Sem Isaac Lab, sem MimicGen, sem modelo de mundo, sem autoria de cena. Se você quer dados gerados, você os gera em outro lugar e traz o resultado.
• Os treinadores consomem conjuntos de dados LeRobot e nada mais. Uma exportação de simulador precisa ser convertida antes de ser uma entrada, e precisa ser a versão correta: v2.0 ou v2.1 para GR00T N1.5 e N1.7, v3.0 para Pi0.5, SmolVLA e ACT.
• O ponto de entrada de fine-tuning do GR00T é uma CLI tyro que não expõe nenhuma seed, então as execuções do GR00T não são reproduzíveis bit-a-bit. Se você está executando uma ablação cuidadosa sim-versus-real, essa é uma limitação real. A seed padrão do próprio lerobot é 1000, e os formulários ACT, SmolVLA e Pi0.5 expõem um campo de seed.
• A acumulação de gradiente é aplicada apenas para os dois treinadores GR00T. Para Pi0.5 e SmolVLA o campo existe no formulário, mas o lerobot 0.5.1 não possui tal flag, então não faz nada.
• A inferência precisa estar próxima dos servos para tarefas rápidas. O loop de controle é de 20 a 485 ms por passo de ação dependendo do modelo, e adicionar viagens de ida e volta pela internet pública transforma uma política funcional em uma hesitante. A inferência remota é viável para pick-and-place lento, não para movimento reativo rápido.

Um orçamento que você pode defender

Coloque os dois caminhos lado a lado com os números que cada um realmente publica, e a decisão geralmente se toma sozinha para um projeto de tarefa única em um braço de baixo custo.

Para uma primeira política em um SO-100, grave. O passo a passo de gravação e a primeira execução de treinamento levam você a um checkpoint servido pelo preço de um café, e você terá a metade real de qualquer futura mistura de co-treinamento. Recorra ao simulador quando tiver uma linha de base funcional e uma falha de generalização específica que possa nomear, como uma política que só funciona em uma configuração.

Uma receita que respeita as evidências

1. 1
   Grave a linha de base real primeiro

   30 episódios para SmolVLA, 50 para ACT, GR00T N1.7 e Pi0.5. Treine uma vez. Tudo o que essa política falhar é a sua especificação para os dados sintéticos.

2. 2
   Nomeie a falha de generalização

   Pose do objeto? Iluminação? Altura da mesa? Distratores? Uma formulação diferente da instrução? Dados sintéticos são bons em exatamente um desses por vez, e inúteis se você não conseguir dizer qual.

3. 3
   Escolha a família mais barata que o cubra

   Variação de pose e layout: multiplicação de trajetória. Iluminação e textura: aumento de imagem primeiro, modelo de mundo segundo. Cenas totalmente novas: rollouts de física, e aceite o custo de modelagem.

4. 4
   Gere, depois descarte agressivamente

   As tentativas de geração falham, e a taxa de sucesso de candidatos do Isaac Lab varia de 70 por cento a menos de 1 por cento, dependendo da tarefa. Mantenha apenas as trajetórias bem-sucedidas e que completam a tarefa, e observe uma amostra como vídeo antes de confiar no lote.

   bash

   python scripts/mimic/generate_dataset.py --device cuda \
       --num_envs 8 --generation_num_trials 500 \
       --input_file ./datasets/annotated.hdf5 \
       --output_file ./datasets/generated.hdf5 --enable_cameras

5. 5
   Co-treine, não substitua

   Mescle os episódios gerados com os reais em um único conjunto de dados LeRobot com chaves de câmera e ordenação de juntas idênticas. O valor de 38 por cento é um valor de co-treinamento.

6. 6
   Avalie no braço real, e somente lá

   A avaliação simulada é um bom sinal de classificação (Pearson r 0.924 na configuração de correspondência visual do SIMPLER), mas não é o teste de aceitação. Execute o checkpoint na bancada antes de acreditar nele.

Se você preferir começar por uma lista de verificação para as próprias gravações reais, o guia de coleta de dados cobre o posicionamento da câmera, o agrupamento de ações implicações e os modos de falha que tornam um conjunto de dados de aprendizado por imitação inutilizável. Detalhes sobre o formato em si estão em a documentação do conjunto de dados, e o lado dos hiperparâmetros em a documentação de treinamento.