Contenido detallado
🕳️ La brecha con la realidad: física, sensor, actuador, apariencia
O brecha entre la simulación y la realidad es la divergencia sistemática entre el comportamiento del simulador y el del mundo físico. Una política que aprende a aprovechar las imperfecciones del simulador —fricción idealizada, contacto perfecto, sensores sin ruido— tiene un rendimiento brillante en simulación y falla en el hardware. Mapear las cuatro fuentes del gap es el primer paso para cerrarlo.
🌐 Brecha de física
Modelos de contacto (Coulomb idealizado), fricción, restitución, cuerpos rígidos y deformables, cables y telas. Donde más sufre la manipulación fina.
📷 Brecha de sensores
Renderizado vs. imagen real: iluminación, reflejos, desenfoque de movimiento, ruido de RGB-D, distorsión de lente. La visión es la mayor fuente de brecha en zero-shot.
⚙️ Brecha del actuador
Retardo de comando, backlash, límites de torque, dinámica de motores y ganancias del controlador que el simulador simplifica o ignora.
🎨 Brecha de apariencia
Texturas, colores y materiales que no coinciden con objetos reales; el dominio al que la aleatorización visual apunta directamente.
📊 Datos de investigación
- 99% → ~30% — caída típica del success rate de una política sim-only transferida de forma ingenua al entorno real sin mitigación.
- 10.000×+ — ventaja en el throughput de recolección en simulación con GPU paralela (Isaac Lab) frente a la teleoperación real.
- La visión domina — en manipulación, la brecha visual suele superar la brecha dinámica como causa de fallas.
Brecha de realidad
Divergencia sim↔real.
Contact dynamics
Física del tacto difícil de simular.
Sensor noise
Falta ruido real en la simulación.
Actuation delay
Latencia de comando→torque.
🎲 Domain Randomization: textura, luz, masa, fricción, delays
A domain randomization (DR) invierte el problema: en vez de hacer que la simulación sea perfecta, la hace lo bastante variable para que el mundo real parezca solo otra muestra de la distribución de entrenamiento. Si la política vio 10.000 variaciones de fricción, luz y masa, la fricción real queda dentro de lo que ya domina. Es la técnica más robusta y económica para transfer zero-shot.
✓ Hacer
- ✓Aleatorizar física (masa, fricción, damping) Y visión (texturas, luz, cámara) juntas.
- ✓Usar Automatic DR (ADR): amplía los rangos solo cuando la política pueda manejarlos — currículo automático.
- ✓Aleatorizar retrasos del actuador y ruido de observación, no solo la apariencia.
- ✓Centrar los rangos en el valor real medido (sysID) y ampliarlos a su alrededor.
✗ Evitar
- ✗Aleatorizar con tanta intensidad que la tarea se vuelve imposible y la política colapsa en una conducta conservadora inútil.
- ✗Solo DR visual y olvidar la dinámica: una política hermosa que se resbala en el mundo real.
- ✗Franjas centradas fuera de la realidad: cubres el lugar equivocado.
- ✗Creer que DR sustituye cualquier dato real: lo reduce, no lo 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
⚡ Consejo práctico
Empieza con un alcance reducido y usa ADR para ampliar los rangos automáticamente a medida que mejora la política. Un DR fijo y demasiado amplio desde el inicio elimina la señal de aprendizaje; el DR adaptativo encuentra el límite de lo entrenable.
Visual DR
Texturas, luz, cámara.
Aleatorización de dinámica
Masa, fricción, retrasos.
ADR
Currículo automático de pistas.
Zero-shot
Real sin fine-tuning.
🔀 Domain Adaptation: alinear features sim/real
Cuando la brecha visual es demasiado grande para cubrirla solo con ruido, la domain adaptation entra: en lugar de volver la política invariante a la fuerza bruta, se aproxima activamente la distribución de funciones de sim y realidad. Las técnicas adversariales alinean embeddings; modelos como RCAN traducen imágenes reales a un "canónico" de simulación antes de inferir.
💡 DR vs Adaptation: cuándo usar cada uno
DR es proactiva y no necesita datos reales: cubre la incertidumbre a ciegas. Adaptation es reactiva y usa datos reales (etiquetados o no) para cerrar la brecha residual. En la práctica, la receta sólida es DR + un poco de adaptación/real-in-the-loop.
Piensa en DR como "prepararse para cualquier clima" y en adaptation como "ajustar la ropa al clima de hoy".
Adversarial feature alignment
Un discriminador intenta distinguir las características de sim de las de real; el encoder aprende a hacerlas indistinguibles.
Pixel-level translation (RCAN)
Mapea imágenes reales → canónico de simulación, eliminando variaciones irrelevantes antes de la política.
Real en el ciclo
Inyecta muestras reales (sin etiquetas de acción) en el entrenamiento para anclar el encoder al dominio físico.
Adaptación de dominio
Alinear distribuciones.
Alineación de características
Embeddings indistinguibles.
RCAN
Real→canónico de simulación.
Real en el ciclo
Los datos reales anclan el encoder.
🪞 Identificación del sistema y gemelos digitales
DR cubre la incertidumbre; identificación del sistema (sysID) la reduce desde el origen. Al medir el robot real —masas, centros de inercia, fricción de las articulaciones, latencia de control— calibras el simulador para reproducir el hardware específico. El resultado es un gemelo digital: un gemelo digital fiel que sirve como campo de entrenamiento y banco de pruebas seguro.
📊 Qué habilita un digital twin
- Entrenamiento seguro — explorar políticas arriesgadas sin romper hardware costoso.
- Mejor DR — rangos centrados en el valor real medido, no estimados al azar.
- Depuración — reproducir un fallo real en el twin y analizarlo cuadro por cuadro.
- Predeploy — validar las actualizaciones de política antes de que lleguen al robot 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ô real
SysID
Calibrar la simulación con el mundo real.
Gemelo digital
Gemelo digital fiel.
Calibración
Masa, fricción, latencia.
Predeploy
Validar primero en el twin.
🧪 Coentrenamiento sim+real y fine-tuning con pocas demos
La receta práctica dominante en 2026 no es «sim O real»: es coentrenamiento. La simulación proporciona cobertura económica (millones de variaciones), y un puñado de demostraciones reales proporciona fidelidad final. Combinar ~95% sim + ~5% real, o hacer un fine-tuning corto con datos reales, suele superar cualquiera de las dos opciones por separado.
Preentrenamiento en simulación con DR
Política robusta ante una amplia variación; aprende una habilidad general a un costo casi nulo.
Coentrenamiento mixto
Los batches combinan simulación y mundo real; el mundo real ancla el dominio sin perder la cobertura de la simulación.
Fine-tuning final real
Unas pocas demos reales (LoRA/ajuste breve) calibran la política para el robot objetivo específico.
⚡ Consejo práctico
Las demostraciones reales son costosas: úsalas donde la simulación es más débil: contacto fino, materiales deformables, oclusiones. No desperdicies teleoperación reproduciendo lo que la simulación ya cubre bien (movimientos en espacio libre).
Co-training
Mezcla simulación y mundo real.
Eficiencia de muestreo
Bastan pocas demos reales.
Fine-tuning
Ajuste breve en el robot objetivo.
95/5
Mezcla típica de simulación y mundo real.
📏 Evaluación honesta: medir la transferencia, no el sobreajuste a la simulación
El error más común en sim-to-real es confundir sim-score con capacidad real. Una política que alcanza el 99% en simulación dice poco sobre el hardware. La única métrica que cuenta para el deploy es el tasa de éxito en el robot físico, medido con variaciones que la política no ha visto, mediante protocolos honestos.
✓ Hacer
- ✓Reportar la tasa de éxito real en condiciones held-out (objetos/posiciones nuevos).
- ✓Ejecuta suficientes trials de N y calcula el intervalo de confianza.
- ✓Comparar sim-score vs real-score para cuantificar gap restante.
✗ Evitar
- ✗Anunciar capacidad basándose solo en el número del simulador.
- ✗Evalúa en el mismo escenario y seed del entrenamiento (overfit disfrazado).
- ✗Ocultar la varianza: 3 trials afortunados no son evidencia.
💡 La métrica que importa
O sim2real gap = (puntuación en sim − puntuación en el mundo real). Reducirlo es el objetivo de todo el módulo. Una puntuación alta en sim con una brecha grande significa que optimizaste el entorno equivocado — y solo lo descubres al medir en el mundo real.
Tasa de éxito real
Única métrica de deploy.
Held-out
Variación no vista.
Sim2real gap
Sim-score − real-score.
Varianza
IC sobre N trials.
✅ Resumen del módulo
Próximo módulo
3.2 — Humanoides: Figure, Tesla, Unitree, GR00T. Donde la transferencia de simulación a la realidad se encuentra con los cuerpos de propósito general.