De zero a deploy: Python, LeRobot, simuladores, ROS2, treinamento e transferência sim-to-real. As ferramentas e técnicas para construir VLAs que funcionam.
6 módulos · ~18 h estimadas · Pré-requisito: Trilha 1
PyTorch, Transformers, Gymnasium
Coleta, treino e deploy open-source
MuJoCo, Isaac Sim, PyBullet
Pub/sub, TF2, Nav2 e VLA
De demonstrações à política neural
Do virtual ao físico sem quebrar
As ferramentas que todo engenheiro VLA precisa dominar: do tensor ao environment. PyTorch para autograd, HuggingFace para modelos pré-treinados, Gymnasium para ambientes padronizados.
PyTorch é o framework de deep learning dominante em robótica e VLA. Tensores são arrays multidimensionais com suporte nativo a GPU via CUDA. O sistema autograd calcula gradientes automaticamente, essencial para backpropagation durante treinamento de políticas.
Praticamente todo VLA (OpenVLA, pi-0, ACT) é implementado em PyTorch. Sem dominar tensores, shapes e autograd, você não consegue debugar treinamentos, customizar losses ou adaptar arquiteturas existentes.
torch.Tensor, device (cpu/cuda), dtype (float32/bfloat16), autograd e computational graph, nn.Module e forward(), optim.AdamW, mixed precision (torch.amp), torch.compile para otimização JIT.
Biblioteca que unifica o acesso a 300k+ modelos pré-treinados via API padronizada. Para VLA, é crucial porque modelos como OpenVLA, SmolVLA e Qwen-VL são distribuídos via HuggingFace Hub com pipeline de inferência pronto.
O HuggingFace Hub é o centro do ecossistema open-source de VLA. LeRobot hospeda 58k+ datasets lá. Saber usar AutoModel, from_pretrained() e tokenizers é pré-requisito para qualquer trabalho prático.
AutoModelForVision2Seq, AutoProcessor, from_pretrained(), model.generate(), LoRA/PEFT para fine-tune eficiente, datasets library, model cards, safetensors format, Hub API.
Gymnasium (sucessor do OpenAI Gym) define a interface padrão para ambientes de RL: observation_space, action_space, step(), reset(). Em robótica VLA, serve como wrapper para simuladores e permite treinar políticas com interface consistente.
A API Gymnasium é o contrato universal entre política e ambiente. MuJoCo, Isaac Sim e PyBullet todos implementam essa interface. Entender obs/act/reward/done é fundamental para qualquer loop de treinamento.
gym.Env, observation_space (Box, Dict), action_space (Box contínuo, Discrete), step() retorna (obs, reward, terminated, truncated, info), VectorEnv para paralelismo, wrappers para transformações.
Dados de robótica são trajetórias: sequências de (observação, ação, reward) coletadas por teleoperação ou simulação. O formato RLDS (Google) e LeRobot Dataset padronizam como armazenar e carregar essas trajetórias para treinamento eficiente.
Dados são o gargalo número um em robótica. Saber estruturar datasets de trajetórias, fazer data augmentation (crop, color jitter) e usar DataLoaders com prefetch é essencial para treinos que convergem.
RLDS format (TFRecord), LeRobot Dataset (Parquet + vídeo), torch.utils.data.DataLoader, num_workers, pin_memory, collate_fn para batches de trajetórias variáveis, data augmentation específica de robótica.
W&B é a plataforma padrão para rastrear experimentos de ML. Registra métricas (loss, success rate), hiperparâmetros, artefatos (checkpoints) e permite comparar runs lado a lado. LeRobot tem integração nativa com W&B.
Sem tracking estruturado, treinamentos de VLA viram caixa preta. Você precisa comparar ACT vs Diffusion Policy, diferentes learning rates, e identificar quando o modelo diverge. W&B torna isso visual e reproduzível.
wandb.init(), wandb.log(), wandb.config, Sweeps para hyperparameter search, Tables para visualizar trajetórias, model registry para versionamento, integração LeRobot via config YAML.
Docker containeriza o ambiente de desenvolvimento: versões exatas de Python, PyTorch, CUDA e dependências ficam fixas. Em robótica, onde a combinação CUDA driver + PyTorch + MuJoCo pode quebrar facilmente, containers são essenciais.
Reprodutibilidade é um dos maiores problemas em pesquisa de robótica. Um Dockerfile garante que qualquer pessoa consiga rodar seu treinamento. NVIDIA NGC e LeRobot fornecem containers prontos.
Dockerfile multi-stage, nvidia-docker2 (GPU passthrough), NVIDIA NGC containers, docker-compose para multi-serviço, volumes para datasets, devcontainers para VS Code, CI/CD com containers.
O framework open-source do HuggingFace que democratiza robótica: coleta, treino e deploy. Com 12k stars no GitHub e 58k+ datasets, LeRobot é o ponto de entrada mais acessível para VLA prático.
LeRobot é o framework open-source da HuggingFace para robótica end-to-end. Lançado em 2024, já tem 12k stars no GitHub e 58k+ datasets no Hub. Cobre coleta de dados, treinamento de políticas e deploy em robôs reais com uma única ferramenta.
É o caminho mais rápido de zero a robô funcionando. Antes do LeRobot, cada lab tinha seu pipeline ad-hoc. Agora existe um padrão open-source com comunidade ativa e documentação extensa.
pip install lerobot, lerobot/scripts/train.py, lerobot/scripts/record.py, LeRobotDataset class, HuggingFace Hub integration, modelo de contribuição aberta, suporte a múltiplos robôs (SO-100, Koch, Aloha).
Teleoperação é quando um humano controla o robô remotamente para gerar demonstrações. O LeRobot grava sincronizadamente vídeo das câmeras e posições dos atuadores. Cada demonstração vira um episódio no dataset com timestamps alinhados.
Qualidade e quantidade dos dados de demonstração determinam diretamente o sucesso do treinamento. Saber montar o setup de teleoperação, calibrar câmeras e gravar episódios consistentes é a base de tudo.
Leader-follower setup, calibração de câmera intrínseca/extrínseca, episode recording, lerobot record --robot-path, 50-100 episódios para tarefas simples, data quality filtering, replay para validação.
Políticas são os modelos neurais que mapeiam observações para ações. LeRobot implementa várias: ACT (Action Chunking with Transformers) usa CVAE + transformer, Diffusion Policy usa denoising iterativo, TDMPC combina model-based planning com learned dynamics.
Cada política tem tradeoffs: ACT é rápido de treinar mas pode ser impreciso em tarefas finas. Diffusion Policy gera ações mais suaves mas é mais lento na inferência. Saber escolher a política certa para a tarefa é crucial.
ACT: CVAE encoder + transformer decoder, action chunks de 100 steps. Diffusion Policy: DDPM com U-Net ou transformer, 10-100 denoising steps. TDMPC: world model + planning. VQ-BeT: tokenização discreta de ações.
LeRobot usa configs YAML para definir toda a pipeline de treinamento: política, dataset, hiperparâmetros, device. Um único comando (python lerobot/scripts/train.py) lança o treino com logging automático em W&B e checkpoints periódicos.
A config YAML é o "contrato" do experimento. Saber ajustar learning rate, batch size, número de epochs e scheduling de checkpoints é a diferença entre um modelo que converge e um que diverge.
Hydra config system, policy.yaml + env.yaml, training_steps, eval_freq, checkpoint_freq, resume_from_checkpoint, GPU memory management (gradient accumulation, mixed precision), multi-GPU com DDP.
Avaliação em robótica é diferente de NLP: não basta medir loss no validation set. O que importa é success rate (% de episódios onde a tarefa foi completada) e generalização para objetos/posições novas. LeRobot integra avaliação automática em simuladores.
Um modelo com loss baixo pode falhar no robô real. Métricas de sucesso em simulação são o proxy mais confiável antes do deploy. Saber configurar avaliação periódica durante o treino acelera iterações.
Success rate, partial completion score, out-of-distribution (OOD) evaluation, sim evaluation via gym env, N_eval_episodes (tipicamente 50), video recording de episódios, benchmark comparisons (SIMPLER, LIBERO).
Deploy é transferir o checkpoint treinado para controlar um robô real em tempo real. LeRobot suporta robôs acessíveis como SO-100 (~$300) e Koch v1.1, rodando inferência no próprio laptop. O loop é: capturar frame, inferir ação, enviar comando ao atuador.
O deploy real é onde tudo é testado de verdade. Latência de câmera, USB bandwidth, jitter do sistema operacional, tudo importa. Saber diagnosticar problemas de deploy é a habilidade que separa simulação de robótica real.
lerobot/scripts/control_robot.py, real-time inference loop, camera latency budgeting, USB serial communication, safety limits (velocidade máxima, force threshold), calibração pós-deploy, iteração rápida coleta-treino-deploy.
Treinar robôs sem quebrar nada: simulação física de alta fidelidade para VLA. MuJoCo a 2.7M steps/s, Isaac Sim com ray-tracing a 94k FPS, e PyBullet para prototipagem rápida.
MuJoCo (Multi-Joint dynamics with Contact) é um motor de física otimizado para simulação de contato entre corpos rígidos e articulações. Adquirido pelo Google DeepMind em 2021, agora é open-source e processa 2.7 milhões de steps por segundo em CPU.
MuJoCo é o simulador padrão da comunidade acadêmica de robótica e RL. A maioria dos benchmarks (dm_control, Gymnasium Robotics) roda em MuJoCo. Dominar MuJoCo é pré-requisito para reproduzir papers e treinar políticas VLA em escala.
MJCF (formato XML para modelos), qpos/qvel (estado generalizado), solver Newton/CG, contato suave (soft contacts), integrador semi-implícito Euler, mujoco-py vs mujoco (binding oficial), MJX (MuJoCo em JAX para GPU).
Isaac Sim é a plataforma de simulação robótica da NVIDIA construída sobre Omniverse e PhysX 5. Oferece renderização fotorrealística com ray-tracing em tempo real e pode simular milhares de robôs em paralelo usando GPU, atingindo 94k FPS.
Para sim-to-real de alta fidelidade, a qualidade visual do simulador importa muito. Isaac Sim permite domain randomization com texturas e iluminação realistas, reduzindo o reality gap. É o simulador escolhido pela NVIDIA para treinar GR00T N1.
Omniverse USD (formato universal de cena), PhysX 5 (GPU-accelerated physics), Isaac Lab (framework de RL/IL), OmniGraph (lógica visual), RTX ray-tracing, Isaac Gym (predecessor, deprecado), integração com ROS2 via bridge.
PyBullet é o wrapper Python do Bullet Physics Engine. Com um simples pip install, você tem um simulador 3D com detecção de colisão, constraints e URDF loader. Ideal para prototipagem rápida e ensino.
A barreira de entrada é mínima: funciona em qualquer laptop sem GPU dedicada. Muitos tutoriais e cursos de RL usam PyBullet. É o caminho mais rápido para ter um robô simulado rodando uma política aprendida.
URDF (Unified Robot Description Format), p.loadURDF(), stepSimulation(), getJointState/setJointMotorControl2, pybullet_envs (Gymnasium wrappers), direct vs GUI mode, collision shapes, constraints.
Gazebo (agora "Gz") é o simulador integrado ao ecossistema ROS2. Diferente de MuJoCo (focado em pesquisa RL), Gazebo simula sensores reais (LiDAR, câmeras depth, IMU) e se comunica com ROS2 via topics nativamente.
Se o deploy final usa ROS2, testar em Gazebo significa que o código do robô real e do simulado é praticamente idêntico. Isso acelera enormemente o ciclo de desenvolvimento e reduz surpresas no deploy.
SDF (Simulation Description Format), gz-sim (novo nome), ros_gz_bridge, sensor plugins (câmera, LiDAR, IMU), world files, spawn models via service, Gazebo Fuel (repositório de modelos 3D), integração MoveIt2.
Domain randomization é a técnica de variar aleatoriamente parâmetros do simulador (texturas, iluminação, massas, fricção, cores) durante o treinamento para que a política aprenda a ser robusta a variações e transfira melhor para o mundo real.
Sem domain randomization, políticas treinadas em simulação falham catastroficamente no mundo real porque overfitam nos visuais e na física perfeita do simulador. É a técnica que viabilizou o primeiro sim-to-real bem-sucedido (OpenAI Rubik's Cube, 2019).
Visual randomization (texturas, cores, luz), physics randomization (massa, fricção, damping), dynamics randomization, structured vs uniform sampling, curriculum de randomização (progressiva), ADR (Automatic Domain Randomization).
Sim-to-sim é a prática de transferir uma política treinada em um simulador (ex: MuJoCo) para outro simulador (ex: Isaac Sim) como etapa intermediária antes do robô real. Se a política falha em outro sim, vai falhar no real.
É uma validação barata e rápida. Testar em 2+ simuladores com físicas diferentes revela fragilidades da política antes de arriscar hardware caro. Também permite isolar se o problema é visual ou de dinâmica.
Cross-simulator transfer, physics fidelity gap entre simuladores, URDF/MJCF conversion tools, benchmark standardization (SIMPLER), avaliação estatística (N episódios, confidence intervals), debugging visual vs dinâmico.
O sistema operacional dos robôs: pub/sub, TF2, Nav2 e integração com VLA. ROS2 é o padrão da indústria para robótica de produção.
ROS2 é o framework middleware padrão da indústria robótica. Diferente do ROS1, usa DDS (Data Distribution Service) como camada de transporte, oferecendo QoS configurável, descoberta automática de nós e comunicação real-time sem master node central.
Qualquer robô que vai para produção industrial usa ROS2. É o "Linux da robótica". Integrar um modelo VLA em ROS2 é obrigatório para deploy real. As distribuições atuais (Humble LTS, Iron) são estáveis e suportadas até 2027+.
DDS (Fast-RTPS, Cyclone DDS), nós (nodes), executores (single-threaded vs multi-threaded), lifecycle nodes, QoS profiles (reliability, durability, history), colcon build system, ament_cmake/ament_python.
Os três padrões de comunicação em ROS2. Topics são pub/sub assíncronos (streaming de dados, ex: imagem da câmera). Services são request/reply síncronos (ex: mudar modo). Actions são tarefas longas com feedback (ex: mover braço até posição).
Escolher o padrão errado causa bugs sutis: usar topic onde deveria ser action significa perder feedback de progresso; usar service onde deveria ser topic bloqueia o nó. VLA inference tipicamente publica em topic (alta frequência) e recebe comandos via action.
Publisher/Subscriber (topic), Client/Server (service), ActionServer/ActionClient, msg/srv/action interfaces, custom messages, QoS para cada tipo, ros2 topic echo/pub para debug, rqt_graph para visualizar.
TF2 (Transform Library 2) mantém uma árvore de transformações 3D entre todos os frames de referência do robô (base_link, câmera, gripper, etc) atualizada em tempo real. Permite converter coordenadas entre qualquer par de frames instantaneamente.
VLA precisa saber onde a câmera está em relação ao gripper e ao mundo. Sem TF2, você teria que calcular transformações manualmente a cada frame. TF2 faz isso automaticamente com buffer temporal, essencial para fusão de sensores.
Frames (base_link, odom, map, camera_link, tool0), static vs dynamic transforms, tf2_ros::Buffer, lookupTransform(), URDF → robot_state_publisher → TF tree, tf2_echo para debug, rviz2 para visualizar.
Nav2 é o stack de navegação autônoma (planejamento de caminho, obstacle avoidance, costmaps). MoveIt2 é o framework de manipulação (motion planning, cinemática inversa, collision avoidance). Juntos cobrem mobilidade e manipulação.
VLA pode gerar ações de alto nível ("vá até a mesa"), mas Nav2/MoveIt2 executam o planejamento de caminho seguro. A combinação VLA (o quê fazer) + Nav2/MoveIt2 (como chegar lá sem colidir) é o padrão para robôs mobile manipulators.
Nav2: BT (Behavior Trees), costmap2d, planner/controller servers, recovery behaviors. MoveIt2: SRDF, planning scene, OMPL planners (RRT*, PRM), servo (real-time control), grasp planning, pick-and-place pipeline.
O nó de inferência VLA em ROS2 é o componente que recebe imagens e comandos de linguagem via topics, roda o modelo VLA (PyTorch/ONNX), e publica ações para o controlador do robô. Funciona como uma ponte entre o mundo ROS2 e o mundo ML.
Integrar ML em ROS2 tem desafios únicos: GIL do Python, latência de serialização, sincronização câmera-ação, gerenciamento de GPU memory. Um nó bem arquitetado é a diferença entre 5 Hz e 50 Hz de inferência.
rclpy node com callback de imagem, message_filters (sincronizar câmera + joint_states), ONNX Runtime para inferência otimizada, TensorRT via ROS2, pre-allocated buffers (evitar malloc), executor multi-thread, composable nodes.
Launch files em ROS2 (Python) orquestram a inicialização de múltiplos nós com parâmetros, remappings e condicionais. Em produção, combinam com systemd, Docker e monitoramento para garantir que o sistema robótico reinicie automaticamente após falhas.
Deploy de robótica em produção é engenharia de sistemas, não só ML. Um launch file bem estruturado com lifecycle management, health checks e restart policies é o que separa um demo de um produto. Empresas pagam premium por essa expertise.
LaunchDescription, Node(), ComposableNodeContainer, lifecycle_node (configure/activate/deactivate), parameters YAML, launch arguments, event handlers, ros2 launch logging, systemd unit files, Docker + ROS2, rosbag2 para replay.
Como o robô aprende assistindo humanos: das demonstrações à política neural. Behavior cloning, Action Chunking Transformers e Diffusion Policy são os 3 paradigmas dominantes.
Behavior cloning (BC) é a forma mais simples de imitation learning: coleta-se demonstrações humanas (pares observação-ação), e treina-se uma rede neural supervisionada para mapear observações a ações. É essencialmente regressão sobre trajetórias.
BC é o baseline de toda robótica VLA. Apesar de simples, funciona surpreendentemente bem com dados suficientes. OpenVLA, RT-2 e Octo usam variantes sofisticadas de BC como ponto de partida. Entender suas limitações (distribution shift) é essencial.
Supervised learning sobre (s,a) pares, MSE/L1 loss para ações contínuas, distribution shift (compounding errors), DAgger (Dataset Aggregation) para mitigar drift, covariate shift, horizon de demonstração vs horizon de execução.
ACT (Zhao et al., 2023) prediz chunks de ações futuras de uma vez, em vez de uma ação por vez. Um encoder CVAE gera um estilo latente, e um decoder transformer gera K ações futuras condicionadas nesse estilo e na observação atual.
ACT resolve dois problemas de BC: o temporal compounding error (ao planejar K passos à frente) e a multimodalidade (via CVAE). É a política padrão do LeRobot e a base do ALOHA (braços bimanuais do Google). Performance estado da arte com poucos demos.
Action chunking: predizer K ações de uma vez (K=100 típico). CVAE (Conditional Variational Autoencoder) para capturar modos múltiplos. Temporal ensemble: média ponderada de chunks sobrepostos. kl_weight (regularização do latente).
Diffusion Policy (Chi et al., 2023) aplica modelos de difusão (como os de geração de imagem) à geração de trajetórias robóticas. Começa com ruído gaussiano e, em T passos de denoising condicionados na observação, gera uma trajetória de ações suave e multimodal.
Diffusion Policy supera BC e ACT em tarefas com alta multimodalidade (ex: múltiplos caminhos válidos para o mesmo objetivo). É a base da política S1 do GR00T N1 e do π0. A capacidade de capturar distribuições complexas de ações é incomparável.
DDPM (Denoising Diffusion Probabilistic Models) aplicado a ações, noise schedule, conditional denoising (observation-conditioned), U-Net vs transformer backbone, inference steps (DDIM para acelerar), horizon de ação, observation horizon vs action horizon.
Fine-tuning adapta um modelo VLA pré-treinado em dados gerais (ex: OpenVLA treinado em Open X-Embodiment) para sua tarefa e robô específicos usando um dataset muito menor. Análogo ao fine-tuning de LLMs, mas com trajetórias robóticas.
Treinar um VLA do zero requer milhões de trajetórias. Fine-tuning de um modelo pré-treinado precisa de apenas 50-200 demonstrações do seu setup. OpenVLA 7B fine-tuned supera RT-2-X com 10x menos dados. É o caminho prático para 99% dos projetos.
LoRA / QLoRA para eficiência de memória, learning rate schedule (cosine decay com warmup), frozen backbone vs full fine-tune, dataset mixing (dados gerais + específicos), catastrophic forgetting, evaluation on holdout tasks.
Reinforcement Learning post-training aplica RL (PPO, GRPO) sobre uma política inicializada por imitation learning. O robô melhora além das demos humanas ao otimizar reward signals automáticos. Analogia: RLHF para LLMs, mas com rewards físicos.
Qwen-VLA mostrou +24% de melhoria em success rate após RL post-training com GRPO. O modelo supera as demonstrações humanas originais. É a fronteira atual de performance: IL para bootstrap, RL para otimização.
GRPO (Group Relative Policy Optimization), PPO (Proximal Policy Optimization), reward shaping para manipulação, success-based sparse reward vs dense reward, KL penalty (não divergir muito do IL), sample efficiency, online vs offline RL.
Avaliação em robótica VLA mede success rate (% de tarefas completadas) em cenários in-distribution (mesmos objetos do treino) e out-of-distribution (objetos, posições e iluminação novos). OOD success rate é a métrica que realmente importa.
Um modelo com 95% in-distribution pode ter 30% OOD. Saber projetar avaliações que testam generalização real evita surpresas no deploy. Benchmarks como SIMPLER e LIBERO padronizam comparações entre modelos.
Success rate (SR), OOD SR, partial completion metrics, N_eval_episodes (50+), confidence intervals, SIMPLER benchmark, LIBERO suite, video recording de falhas, error taxonomy (grasp fail, reach fail, collision), ablation studies.
A ponte mais difícil: como transferir habilidades do simulador para o robô real. Domain randomization, system identification e o loop real-to-sim-to-real.
O reality gap é a diferença entre o comportamento de um robô no simulador e no mundo real. Vem de três fontes: visual (texturas, iluminação), dinâmica (atrito, massas, compliance) e sensorial (ruído de câmera, latência, jitter). Uma política perfeita em sim pode falhar 100% no real.
Ignorar o reality gap é o erro mais comum de iniciantes. Entender suas fontes permite escolher as técnicas certas: domain randomization para o gap visual, system identification para o gap dinâmico, sensor noise injection para o gap sensorial.
Visual gap (rendering vs câmera real), dynamics gap (física simplificada vs contato real), sensor gap (sensores ideais vs ruidosos), actuator gap (controle perfeito vs backlash e atrito), transferability metrics, sim-to-real success rate.
Domain randomization varia sistematicamente os parâmetros do simulador (texturas, cores, posição de luzes, massas, coeficientes de atrito) a cada episódio. A política é forçada a generalizar porque nunca vê o mesmo cenário duas vezes.
É a técnica de sim-to-real mais robusta e mais usada. OpenAI usou para resolver Rubik's Cube (2019), NVIDIA usa em Isaac Lab, e todos os pipelines VLA modernos incluem alguma forma de randomization. Sem isso, políticas overfitam na aparência do sim.
Visual DR: texturas random, cor de fundo, intensidade de luz, posição de câmera. Physics DR: massa ±30%, fricção ±50%, damping, action delay (1-3 steps). ADR (Automatic Domain Randomization): aumenta ranges automaticamente quando performance estabiliza.
System identification (sysid) é o processo de medir os parâmetros físicos reais do robô (massas, inércias, atrito, rigidez) e configurar o simulador para matchá-los. Em vez de randomizar tudo, você calibra o sim para ser o mais próximo possível do real.
Domain randomization com ranges muito amplos pode degradar a performance (a política fica "medíocre em tudo"). System identification permite usar ranges estreitos centrados nos valores reais, combinando o melhor dos dois mundos: robustez + precisão.
Parameter estimation: gravar trajetória real, otimizar parâmetros do sim para minimizar erro. Bayesian optimization para sysid. Residual physics learning: rede neural que aprende a diferença entre sim e real. Sim calibration tools (MuJoCo XML editing, Isaac Lab config).
Sim-to-real transfer é o pipeline completo de levar uma política treinada em simulação para funcionar no robô real. Inclui: treinamento com DR/sysid no sim, validação sim-to-sim, deploy inicial com safety constraints, iteração com dados reais.
É o gargalo de toda robótica baseada em aprendizado. Dominar sim-to-real é a habilidade mais valorizada na indústria porque determina se meses de treinamento em sim se traduzem em performance real ou em desperdício de GPU hours.
Progressive deployment: sim → sim-to-sim → real com safety limits → real full. Action smoothing (filtro passa-baixa nos comandos). Safety constraints (force limits, velocity limits, workspace bounds). Online adaptation: ajustar política com dados do real.
Real-to-sim-to-real é um loop iterativo: coleta dados no robô real, usa esses dados para calibrar/melhorar o simulador, re-treina a política no sim melhorado, e deploya novamente. Cada iteração melhora tanto o sim quanto a política.
Um único pass de sim-to-real raramente é suficiente. O loop iterativo é como robôs comerciais são desenvolvidos na prática. Figure, NVIDIA e Physical Intelligence rodam dezenas de iterações real-to-sim-to-real antes de declarar um comportamento "production-ready".
Data flywheel: mais dados reais → sim melhor → política melhor → mais dados reais. Sim tuning automático com dados reais (neural sim). Digital twin: réplica exata do setup real no sim. Continuous deployment pipeline: CI/CD para políticas robóticas.
Os marcos do sim-to-real: OpenAI resolveu o cubo de Rubik com mão robótica Dexterous (2019) usando ADR massivo. NVIDIA treina locomotion de humanoides em Isaac Sim com 4096 ambientes paralelos. Google RT-2 usou sim-to-real para validação de tarefas de manipulação.
Esses casos demonstram que sim-to-real funciona para tarefas extremamente complexas. As lições aprendidas (escala de randomization, importância de sensores táteis, design de reward) são diretamente aplicáveis a qualquer projeto VLA.
OpenAI Rubik's: ADR com 200+ parâmetros randomizados, 13K years de experiência sim. NVIDIA humanoid: massively parallel sim, PPO com 4096 envs, 45 min wall-clock. Google RT-2: SIMPLER benchmark para validação sim. Lição: escala de sim compensa.