🌉 Sim-to-Real: Do Virtual ao Físico
A ponte mais difícil da robótica moderna: como transferir habilidades do simulador para o robô real. Domain randomization, system identification e o loop real-to-sim-to-real que alimenta os robôs de produção da NVIDIA, Figure e Physical Intelligence.
🔬 Reality Gap: Por que Simulação ≠ Realidade
O reality gap é a diferença entre o comportamento de um robô no simulador e no mundo real. Uma política perfeita em sim pode falhar 100% no real — e entender por quê é o ponto de partida de todo sim-to-real sólido.
🔍 Tipos de Gap
- ◆Visual gap: rendering vs câmera real — texturas, iluminação, reflexos
- ◆Dynamics gap: física simplificada vs contato real — atrito, compliance
- ◆Sensor gap: sensores ideais vs ruidosos — câmera com jitter, IMU com drift
- ◆Actuator gap: controle perfeito vs backlash e atrito nos motores
⚠ Erros Clássicos
- ✗Ignorar o reality gap e esperar que o deploy funcione direto
- ✗Treinar só com texturas estáticas e iluminação fixa
- ✗Não adicionar ruído de sensor durante o treinamento
- ✗Assumir que baixo loss em sim = boa performance no real
🎲 Domain Randomization: Texturas, Física, Luz
Domain randomization varia sistematicamente os parâmetros do simulador a cada episódio. A política é forçada a generalizar porque nunca vê o mesmo cenário duas vezes — a realidade se torna apenas mais um "domínio" que o modelo aprendeu a lidar.
💡 Por que funciona
A OpenAI usou domain randomization para resolver o Cubo de Rubik com mão robótica Dexterous (2019) — 200+ parâmetros randomizados, 13K years de experiência em sim. A NVIDIA usa em Isaac Lab para humanoides. Sem DR, políticas overfitam na aparência do simulador e falham catastroficamente no real.
📋 Parâmetros típicos de Domain Randomization
# Visual DR — randomiza aparência
visual_dr:
texture_randomization: true # texturas aleatórias em cada objeto
background_color: [0.1, 0.9] # range de luminosidade do fundo
light_intensity: [0.5, 1.5] # posição e intensidade das luzes
camera_position_noise: 0.02 # ruído na posição da câmera (m)
# Physics DR — randomiza dinâmica
physics_dr:
object_mass: [0.7, 1.3] # ±30% na massa dos objetos
friction_coefficient: [0.5, 1.5] # ±50% no coeficiente de atrito
joint_damping: [0.8, 1.2] # amortecimento das juntas
action_delay_steps: [1, 3] # delay de 1 a 3 steps nos comandos
# ADR — Automatic Domain Randomization
adr:
enabled: true
performance_threshold: 0.85 # aumenta ranges quando perf > 85%
range_increment: 0.05 # incremento gradual dos ranges
✓ Visual DR — O que randomizar
- ✓ Texturas de superfície e cor de fundo
- ✓ Posição, cor e intensidade das luzes
- ✓ Posição e ângulo da câmera
- ✓ Distractors: objetos aleatórios na cena
✗ Erros comuns com DR
- ✗ Ranges muito amplos: política fica "medíocre em tudo"
- ✗ Randomizar sem medir a performance resultante
- ✗ Ignorar ADR — aumentar ranges manualmente é lento
- ✗ Só randomizar visual, ignorar dinâmica
🔧 System Identification: Calibrar o Simulador
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.
Coleta de trajetórias reais
Executa trajetórias específicas (sinusoidais, step) no robô real e registra posições, velocidades e torques com alta frequência. Esse dataset vai alimentar a otimização.
Otimização de parâmetros
Usa Bayesian Optimization ou gradient descent para encontrar os parâmetros do sim (massas, fricções, damping) que minimizam a diferença entre trajetória real e simulada.
Residual physics learning
Uma rede neural aprende a diferença residual entre o sim calibrado e o real — capturando efeitos que equações físicas não modelam bem, como hysteresis e compliance de cabos.
⚡ DR + SysId: O Melhor dos Dois Mundos
Domain randomization com ranges muito amplos degrada performance. SysId permite usar ranges estreitos centrados nos valores reais — robustez de DR com a precisão de sysid. Pipeline ideal: sysid primeiro para calibrar o centro, DR depois para robustez ao redor desse centro.
🚀 Sim-to-Real Transfer: Técnicas Atuais
O pipeline completo de sim-to-real transfer envolve treinamento com DR/sysid, validação sim-to-sim, deploy progressivo com safety constraints e iteração com dados reais. É o gargalo de toda robótica baseada em aprendizado.
✓ Pipeline robusto
- ✓ Validar sim-to-sim antes de tocar o robô real
- ✓ Deploy progressivo: sim → sim-sim → real com safety limits → real full
- ✓ Action smoothing: filtro passa-baixa nos comandos de junta
- ✓ Safety constraints: force limits, velocity limits, workspace bounds
- ✓ Online adaptation: ajustar política com dados coletados no real
✗ Erros de deploy
- ✗ Deploy direto sem validação em sim com cenários OOD
- ✗ Velocidade máxima sem rampa suave nos primeiros passos
- ✗ Ignorar latência de câmera e jitter de OS no loop de controle
- ✗ Não definir emergency stop antes do primeiro teste real
📋 Action Smoothing — Filtro passa-baixa simples
class ActionSmoother:
"""Filtro EMA para suavizar comandos e evitar movimentos bruscos."""
def __init__(self, alpha: float = 0.7):
self.alpha = alpha # 0.7 = suave; 1.0 = sem filtro
self.prev_action = None
def __call__(self, raw_action):
if self.prev_action is None:
self.prev_action = raw_action
return raw_action
# Exponential Moving Average
smoothed = self.alpha * raw_action + (1 - self.alpha) * self.prev_action
self.prev_action = smoothed
return smoothed
# Uso no loop de controle
smoother = ActionSmoother(alpha=0.7)
while True:
obs = robot.get_observation()
raw_action = policy(obs)
safe_action = smoother(raw_action)
robot.execute(np.clip(safe_action, -v_max, v_max))
🔄 Real-to-Sim-to-Real: O Loop Completo
Um único pass de sim-to-real raramente é suficiente. O loop real-to-sim-to-real é iterativo: coleta dados no robô real, usa esses dados para calibrar e melhorar o simulador, re-treina a política no sim melhorado, e deploya novamente. Cada ciclo melhora tanto o sim quanto a política.
🏭 Como a indústria faz
Figure, NVIDIA e Physical Intelligence rodam dezenas de iterações real-to-sim-to-real antes de declarar um comportamento "production-ready". Um único pass de sim-to-real é sempre o ponto de partida, nunca o ponto de chegada.
🏆 Casos de Sucesso: OpenAI, NVIDIA, Google
Os marcos do sim-to-real provam que a abordagem funciona para tarefas de complexidade extrema. As lições aprendidas nesses projetos são diretamente aplicáveis a qualquer pipeline VLA.
OpenAI Dexterous Hand — Cubo de Rubik
O marco fundador: mão robótica resolvia Rubik's Cube com ADR massivo.
NVIDIA Isaac Lab — Locomotion de Humanoides
Treinamento paralelo massivo em Isaac Sim para robôs humanoides.
Google RT-2 — SIMPLER Benchmark
Validação de VLAs em sim antes do deploy — correlação alta com performance real.
📚 Lições universais desses projetos
- ◆Escala de sim compensa: mais horas em sim raramente é desperdiçar GPU — é investir em robustez.
- ◆Sensores táteis importam: para manipulação fina, só visão não é suficiente — feedback de força é crítico.
- ◆Design de reward é arte: reward mal especificado em sim resulta em comportamento catastrófico no real.
- ◆Benchmarks padronizados: SIMPLER e LIBERO permitem comparar métodos de forma reproduzível.
✅ Resumo do Módulo
Próxima trilha: Trilha 3 — Avançado
Você concluiu toda a Trilha Técnica. Na Trilha 3 — Avançado — mergulhamos em arquiteturas de última geração, treinamento em escala massiva, multi-task learning e os modelos foundation que estão definindo o estado da arte em VLAs.