Conteúdo detalhado
🕳️ O reality gap: física, sensor, atuador, aparência
O reality gap é a divergência sistemática entre o comportamento do simulador e o do mundo físico. Uma política que aprende a explorar imperfeições do simulador — atrito idealizado, contato perfeito, sensores sem ruído — performa brilhantemente em sim e falha no hardware. Mapear as quatro fontes do gap é o primeiro passo para fechá-lo.
🌐 Gap de física
Modelos de contato (Coulomb idealizado), atrito, restituição, corpos rígidos vs deformáveis, cabos e tecidos. Onde a manipulação fina mais sofre.
📷 Gap de sensor
Renderização vs imagem real: iluminação, reflexos, motion blur, ruído de RGB-D, distorção de lente. A visão é a maior fonte de gap zero-shot.
⚙️ Gap de atuador
Atraso de comando, backlash, limites de torque, dinâmica de motores e ganhos de controlador que o sim simplifica ou ignora.
🎨 Gap de aparência
Texturas, cores e materiais que não batem com objetos reais; o domínio onde randomização visual ataca diretamente.
📊 Dados de pesquisa
- 99% → ~30% — queda típica de success rate de uma política sim-only transferida naïve ao real sem mitigação.
- 10.000×+ — vantagem de throughput de coleta em sim GPU-paralela (Isaac Lab) vs teleoperação real.
- Visão domina — em manipulação, o gap visual costuma exceder o gap dinâmico como causa de falha.
Reality gap
Divergência sim↔real.
Contact dynamics
Física de toque difícil de simular.
Sensor noise
Ruído real ausente no sim.
Actuation delay
Latência de comando→torque.
🎲 Domain Randomization: textura, luz, massa, atrito, delays
A domain randomization (DR) inverte o problema: em vez de tornar o sim perfeito, torna-o variável o bastante para que o mundo real pareça apenas mais uma amostra da distribuição de treino. Se a política viu 10.000 variações de atrito, luz e massa, o atrito real cai dentro do que ela já domina. É a técnica mais robusta e barata para transfer zero-shot.
✓ Fazer
- ✓Randomizar física (massa, atrito, damping) E visão (texturas, luz, câmera) juntas.
- ✓Usar Automatic DR (ADR): ampliar faixas só quando a política dá conta — currículo automático.
- ✓Randomizar delays de atuador e ruído de observação, não só aparência.
- ✓Centrar as faixas no valor real medido (sysID) e abrir em torno dele.
✗ Evitar
- ✗Randomizar tão forte que a tarefa fica impossível e a política colapsa numa conduta conservadora inútil.
- ✗Só DR visual e esquecer dinâmica — política linda que escorrega no real.
- ✗Faixas centradas fora do real: você cobre o lugar errado.
- ✗Achar que DR substitui qualquer dado real — ele reduz, não elimina.
# Pseudo-DR por episódio (Isaac Lab / MuJoCo)
def randomize(env):
env.friction = U(0.4, 1.2) # atrito
env.mass_scale = U(0.8, 1.2) # massa do objeto
env.light_dir = sample_sphere() # direção de luz
env.texture = random_texture() # aparência
env.act_delay = randint(0, 3) # atraso de atuador (steps)
env.obs_noise = N(0, 0.01) # ruído de sensor
return env # o real vira "mais uma amostra" disso⚡ Dica prática
Comece estreito e use ADR para expandir as faixas automaticamente conforme a política melhora. DR fixo e largo demais desde o início mata o sinal de aprendizado; DR adaptativo encontra a borda do treinável.
Visual DR
Texturas, luz, câmera.
Dynamics DR
Massa, atrito, delays.
ADR
Currículo automático de faixas.
Zero-shot
Real sem fine-tuning.
🔀 Domain Adaptation: alinhar features sim/real
Quando o gap visual é grande demais para cobrir só com ruído, a domain adaptation entra: em vez de tornar a política invariante por força bruta, aproxima-se ativamente a distribuição de features de sim e real. Técnicas adversariais alinham embeddings; modelos como RCAN traduzem imagens reais para um "canônico" de sim antes de inferir.
💡 DR vs Adaptation — quando usar cada um
DR é proativa e não precisa de dados reais: cobre incerteza às cegas. Adaptation é reativa e usa dados reais (rotulados ou não) para fechar o gap residual. Na prática, a receita forte é DR + um pouco de adaptation/real-in-the-loop.
Pense em DR como "preparar para todo clima" e adaptation como "ajustar a roupa ao clima de hoje".
Adversarial feature alignment
Um discriminador tenta distinguir features sim de real; o encoder aprende a torná-las indistinguíveis.
Pixel-level translation (RCAN)
Mapeia imagens reais → canônico sim, removendo variação irrelevante antes da política.
Real-in-the-loop
Injeta amostras reais (sem rótulo de ação) no treino para ancorar o encoder no domínio físico.
Domain adaptation
Alinhar distribuições.
Feature alignment
Embeddings indistinguíveis.
RCAN
Real→canônico de sim.
Real-in-the-loop
Dado real ancora encoder.
🪞 System identification e digital twins
DR cobre incerteza; system identification (sysID) a reduz na origem. Medindo o robô real — massas, centros de inércia, atrito de juntas, latência de controle — você calibra o simulador para reproduzir o hardware específico. O resultado é um digital twin: um gêmeo digital fiel que serve de campo de treino e de banco de testes seguro.
📊 O que um digital twin destrava
- Treino seguro — explorar políticas arriscadas sem quebrar hardware caro.
- DR melhor — faixas centradas no valor real medido, não chutadas.
- Debug — reproduzir uma falha real no twin e dissecá-la quadro a quadro.
- Pré-deploy — validar updates de política antes de irem ao robô físico.
# sysID: ajustar parâmetros do sim ao real por otimização
real_traj = record(robot, commands) # dados do hardware
def loss(theta):
sim_traj = simulate(commands, params=theta)
return mse(sim_traj, real_traj) # quão próximo o twin está
theta_star = minimize(loss, init=spec_sheet) # calibra massa/atrito/delay
# theta_star = simulador que "vira" o robô realSysID
Calibrar sim ao real.
Digital twin
Gêmeo digital fiel.
Calibração
Massa, atrito, latência.
Pré-deploy
Validar no twin antes.
🧪 Co-treino sim+real e fine-tuning com poucas demos
A receita prática dominante em 2026 não é "sim OU real" — é co-treino. O sim fornece cobertura barata (milhões de variações), e um punhado de demonstrações reais fornece fidelidade final. Misturar ~95% sim + ~5% real, ou fazer um fine-tuning curto no real, costuma superar qualquer dos dois isolados.
Pré-treino em sim com DR
Política robusta a variação ampla; aprende habilidade geral a custo quase zero.
Co-treino misto
Batches combinam sim e real; o real ancora o domínio sem perder a cobertura do sim.
Fine-tuning real final
Poucas demos reais (LoRA/ajuste curto) calibram a política ao robô-alvo específico.
⚡ Dica prática
Demos reais são caras — gaste-as onde o sim é mais fraco: contato fino, materiais deformáveis, oclusões. Não desperdice teleoperação reproduzindo o que o sim já cobre bem (movimentos em espaço livre).
Co-training
Mistura sim+real.
Sample efficiency
Poucas demos reais bastam.
Fine-tuning
Ajuste curto no robô-alvo.
95/5
Mix típico sim/real.
📏 Avaliação honesta: medir transfer, não overfit ao sim
O erro mais comum em sim-to-real é confundir sim-score com capacidade real. Uma política que sobe a 99% em sim diz pouco sobre o hardware. A única métrica que conta para deploy é o success rate no robô físico, medido sob variação que a política não viu, com protocolos honestos.
✓ Fazer
- ✓Reportar success rate real em condições held-out (objetos/posições novas).
- ✓Rodar N trials suficientes e dar intervalo de confiança.
- ✓Comparar sim-score vs real-score para quantificar o gap remanescente.
✗ Evitar
- ✗Anunciar capacidade com base só no número do simulador.
- ✗Avaliar no mesmo cenário e seed do treino (overfit disfarçado).
- ✗Esconder a variância: 3 trials de sorte não são evidência.
💡 A métrica que importa
O sim2real gap = (sim-score − real-score). Reduzi-lo é o objetivo de todo o módulo. Um número de sim alto com gap grande significa que você otimizou o lugar errado — e só descobre isso medindo no real.
Real success rate
Única métrica de deploy.
Held-out
Variação não vista.
Sim2real gap
Sim-score − real-score.
Variância
IC sobre N trials.
✅ Resumo do módulo
Próximo módulo
3.2 — Humanoides: Figure, Tesla, Unitree, GR00T. Onde o sim-to-real encontra os corpos de propósito geral.