De cero al deploy: Python, LeRobot, simuladores, ROS2, entrenamiento y transferencia sim-to-real. Las herramientas y técnicas para construir VLAs que funcionan.
6 módulos · ~18 h estimadas · Prerrequisito: Trilha 1
PyTorch, Transformers, Gymnasium
Recopilación, entrenamiento y deploy open-source
MuJoCo, Isaac Sim, PyBullet
Pub/sub, TF2, Nav2 y VLA
De las demostraciones a la política neuronal
De lo virtual a lo físico sin romper nada
Las herramientas que todo ingeniero VLA necesita dominar: del tensor al environment. PyTorch para autograd, HuggingFace para modelos preentrenados, Gymnasium para entornos estandarizados.
PyTorch es el framework de deep learning dominante en robótica y VLA. Los tensores son arrays multidimensionales con soporte nativo para GPU mediante CUDA. El sistema autograd calcula gradientes automáticamente, algo esencial para la backpropagation durante el entrenamiento de políticas.
Prácticamente todo VLA (OpenVLA, pi-0, ACT) está implementado en PyTorch. Sin dominar tensores, shapes y autograd, no puedes depurar entrenamientos, personalizar losses ni adaptar arquitecturas existentes.
torch.Tensor, device (cpu/cuda), dtype (float32/bfloat16), autograd y computational graph, nn.Module y forward(), optim.AdamW, mixed precision (torch.amp), torch.compile para optimización JIT.
Biblioteca que unifica el acceso a más de 300k modelos preentrenados mediante una API estandarizada. Para VLA, es crucial porque modelos como OpenVLA, SmolVLA y Qwen-VL se distribuyen mediante HuggingFace Hub con un pipeline de inferencia listo para usar.
HuggingFace Hub es el centro del ecosistema open-source de VLA. LeRobot aloja allí más de 58k datasets. Saber usar AutoModel, from_pretrained() y tokenizers es un requisito previo para cualquier trabajo práctico.
AutoModelForVision2Seq, AutoProcessor, from_pretrained(), model.generate(), LoRA/PEFT para fine-tune eficiente, datasets library, model cards, safetensors format, Hub API.
Gymnasium (sucesor de OpenAI Gym) define la interfaz estándar para entornos de RL: observation_space, action_space, step(), reset(). En robótica VLA, funciona como wrapper para simuladores y permite entrenar políticas con una interfaz consistente.
La API de Gymnasium es el contrato universal entre la política y el entorno. MuJoCo, Isaac Sim y PyBullet implementan esta interfaz. Entender obs/act/reward/done es fundamental para cualquier loop de entrenamiento.
gym.Env, observation_space (Box, Dict), action_space (Box continuo, Discrete), step() devuelve (obs, reward, terminated, truncated, info), VectorEnv para paralelismo, wrappers para transformaciones.
Los datos de robótica son trayectorias: secuencias de (observación, acción, recompensa) recopiladas mediante teleoperación o simulación. El formato RLDS (Google) y LeRobot Dataset estandarizan cómo almacenar y cargar estas trayectorias para un entrenamiento eficiente.
Los datos son el principal cuello de botella en robótica. Saber estructurar conjuntos de datos de trayectorias, aplicar aumento de datos (crop, color jitter) y usar DataLoaders con prefetch es esencial para lograr entrenamientos convergentes.
RLDS format (TFRecord), LeRobot Dataset (Parquet + video), torch.utils.data.DataLoader, num_workers, pin_memory, collate_fn para batches de trayectorias variables, data augmentation específica de robótica.
W&B es la plataforma estándar para rastrear experimentos de ML. Registra métricas (loss, success rate), hiperparámetros y artefactos (checkpoints), y permite comparar runs lado a lado. LeRobot tiene integración nativa con W&B.
Sin un seguimiento estructurado, los entrenamientos de VLA se convierten en una caja negra. Necesitas comparar ACT vs Diffusion Policy, distintas tasas de aprendizaje e identificar cuándo diverge el modelo. W&B hace que esto sea visual y reproducible.
wandb.init(), wandb.log(), wandb.config, Sweeps para búsqueda de hiperparámetros, Tables para visualizar trayectorias, model registry para control de versiones, integración con LeRobot mediante config YAML.
Docker crea contenedores para el entorno de desarrollo: las versiones exactas de Python, PyTorch, CUDA y las dependencias quedan fijas. En robótica, donde la combinación CUDA driver + PyTorch + MuJoCo puede fallar fácilmente, los contenedores son esenciales.
La reproducibilidad es uno de los mayores problemas de la investigación en robótica. Un Dockerfile garantiza que cualquiera pueda ejecutar tu entrenamiento. NVIDIA NGC y LeRobot ofrecen contenedores listos para usar.
Dockerfile multi-stage, nvidia-docker2 (GPU passthrough), NVIDIA NGC containers, docker-compose para múltiples servicios, volúmenes para datasets, devcontainers para VS Code, CI/CD con contenedores.
El framework open-source de HuggingFace que democratiza la robótica: recolección, entrenamiento y deploy. Con 12k stars en GitHub y más de 58k datasets, LeRobot es el punto de entrada más accesible para trabajar con VLA en la práctica.
LeRobot es el framework open-source de HuggingFace para robótica de extremo a extremo. Lanzado en 2024, ya tiene 12k stars en GitHub y más de 58k datasets en Hub. Abarca la recopilación de datos, el entrenamiento de políticas y el deploy en robots reales con una sola herramienta.
Es el camino más rápido desde cero hasta tener un robot funcionando. Antes de LeRobot, cada laboratorio tenía su pipeline ad hoc. Ahora existe un estándar de código abierto con una comunidad activa y documentación extensa.
pip install lerobot, lerobot/scripts/train.py, lerobot/scripts/record.py, clase LeRobotDataset, integración con HuggingFace Hub, modelo de contribución abierta, soporte para múltiples robots (SO-100, Koch, Aloha).
La teleoperación ocurre cuando una persona controla el robot a distancia para generar demostraciones. LeRobot graba de forma sincronizada los videos de las cámaras y las posiciones de los actuadores. Cada demostración se convierte en un episodio del dataset con marcas de tiempo alineadas.
La calidad y cantidad de los datos de demostración determinan directamente el éxito del entrenamiento. Saber preparar el setup de teleoperación, calibrar cámaras y grabar episodios consistentes es la base de todo.
Configuración líder-seguidor, calibración intrínseca/extrínseca de la cámara, grabación de episodios, lerobot record --robot-path, 50-100 episodios para tareas simples, filtrado de calidad de datos, replay para validación.
Las políticas son los modelos neuronales que mapean observaciones a acciones. LeRobot implementa varias: ACT (Action Chunking with Transformers) usa CVAE + transformer; Diffusion Policy usa eliminación iterativa de ruido; TDMPC combina planificación basada en modelos con dinámicas aprendidas.
Cada política tiene sus tradeoffs: ACT es rápido de entrenar, pero puede ser impreciso en tareas delicadas. Diffusion Policy genera acciones más suaves, pero es más lento durante la inferencia. Saber elegir la política adecuada para la tarea es crucial.
ACT: encoder CVAE + decoder transformer, action chunks de 100 steps. Diffusion Policy: DDPM con U-Net o transformer, 10-100 denoising steps. TDMPC: world model + planning. VQ-BeT: tokenización discreta de acciones.
LeRobot usa configs YAML para definir todo el pipeline de entrenamiento: política, dataset, hiperparámetros, dispositivo. Un solo comando (python lerobot/scripts/train.py) inicia el entrenamiento con logging automático en W&B y checkpoints periódicos.
La configuración YAML es el «contrato» del experimento. Saber ajustar learning rate, batch size, número de epochs y programación de checkpoints marca la diferencia entre un modelo que converge y uno 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 con DDP.
La evaluación en robótica es diferente de NLP: no basta con medir el loss en el validation set. Lo que importa es la success rate (% de episodios en los que se completó la tarea) y la generalización a objetos y posiciones nuevos. LeRobot integra la evaluación automática en simuladores.
Un modelo con una loss baja puede fallar en el robot real. Las métricas de éxito en simulación son el proxy más confiable antes del deploy. Saber configurar evaluaciones periódicas durante el entrenamiento acelera las iteraciones.
Tasa de éxito, puntuación de finalización parcial, evaluación fuera de distribución (OOD), evaluación de simulación mediante gym env, N_eval_episodes (típicamente 50), grabación de video de episodios, comparaciones con benchmarks (SIMPLER, LIBERO).
El despliegue consiste en transferir el checkpoint entrenado para controlar un robot real en tiempo real. LeRobot es compatible con robots accesibles como SO-100 (~$300) y Koch v1.1, que ejecutan inferencia en la propia laptop. El ciclo es: capturar un frame, inferir una acción, enviar un comando al actuador.
El deploy real es donde todo se pone a prueba de verdad. La latencia de la cámara, el ancho de banda del USB, el jitter del sistema operativo: todo importa. Saber diagnosticar problemas de deploy es la habilidad que distingue la simulación de la robótica real.
lerobot/scripts/control_robot.py, bucle de inferencia en tiempo real, presupuesto de latencia de la cámara, comunicación serial USB, límites de seguridad (velocidad máxima, umbral de fuerza), calibración posterior al deploy, iteración rápida de recopilación-entrenamiento-deploy.
Entrena robots sin romper nada: simulación física de alta fidelidad para VLA. MuJoCo a 2.7M steps/s, Isaac Sim con ray-tracing a 94k FPS y PyBullet para prototipado rápido.
MuJoCo (Multi-Joint dynamics with Contact) es un motor de física optimizado para simular el contacto entre cuerpos rígidos y articulaciones. Google DeepMind lo adquirió en 2021; ahora es de código abierto y procesa 2.7 millones de steps por segundo en CPU.
MuJoCo es el simulador estándar de la comunidad académica de robótica y RL. La mayoría de los benchmarks (dm_control, Gymnasium Robotics) se ejecuta en MuJoCo. Dominar MuJoCo es un requisito previo para reproducir papers y entrenar políticas VLA a escala.
MJCF (formato XML para modelos), qpos/qvel (estado generalizado), solver Newton/CG, contacto suave (soft contacts), integrador Euler semiimplícito, mujoco-py vs. mujoco (binding oficial), MJX (MuJoCo en JAX para GPU).
Isaac Sim es la plataforma de simulación robótica de NVIDIA, construida sobre Omniverse y PhysX 5. Ofrece renderizado fotorrealista con ray tracing en tiempo real y puede simular miles de robots en paralelo usando GPU, alcanzando 94k FPS.
Para una sim-to-real de alta fidelidad, la calidad visual del simulador importa mucho. Isaac Sim permite la aleatorización de dominio con texturas e iluminación realistas, lo que reduce la brecha entre la realidad y la simulación. Es el simulador elegido por NVIDIA para entrenar GR00T N1.
Omniverse USD (formato universal de escenas), PhysX 5 (física acelerada por GPU), Isaac Lab (framework de RL/IL), OmniGraph (lógica visual), RTX ray-tracing, Isaac Gym (predecesor, obsoleto), integración con ROS2 mediante bridge.
PyBullet es el wrapper de Python de Bullet Physics Engine. Con un simple pip install, tienes un simulador 3D con detección de colisiones, constraints y URDF loader. Ideal para crear prototipos rápidamente y enseñar.
La barrera de entrada es mínima: funciona en cualquier laptop sin GPU dedicada. Muchos tutoriales y cursos de RL usan PyBullet. Es la forma más rápida de poner en marcha un robot simulado con una política aprendida.
URDF (Unified Robot Description Format), p.loadURDF(), stepSimulation(), getJointState/setJointMotorControl2, pybullet_envs (Gymnasium wrappers), modo directo vs GUI, formas de colisión, restricciones.
Gazebo (ahora "Gz") es el simulador integrado al ecosistema ROS2. A diferencia de MuJoCo (enfocado en la investigación de RL), Gazebo simula sensores reales (LiDAR, cámaras depth, IMU) y se comunica con ROS2 de forma nativa mediante topics.
Si el deploy final usa ROS2, probar en Gazebo significa que el código del robot real y del simulado es prácticamente idéntico. Esto acelera enormemente el ciclo de desarrollo y reduce las sorpresas en el deploy.
SDF (Simulation Description Format), gz-sim (nuevo nombre), ros_gz_bridge, plugins de sensores (cámara, LiDAR, IMU), archivos de mundo, generar modelos mediante service, Gazebo Fuel (repositorio de modelos 3D), integración con MoveIt2.
Domain randomization es la técnica de variar aleatoriamente parámetros del simulador (texturas, iluminación, masas, fricción, colores) durante el entrenamiento para que la política aprenda a ser robusta ante las variaciones y se transfiera mejor al mundo real.
Sin domain randomization, las políticas entrenadas en simulación fallan catastróficamente en el mundo real porque se sobreajustan a los elementos visuales y a la física perfecta del simulador. Es la técnica que hizo posible el primer sim-to-real exitoso (OpenAI Rubik's Cube, 2019).
Aleatorización visual (texturas, colores, luz), aleatorización de la física (masa, fricción, damping), aleatorización de la dinámica, muestreo estructurado vs. uniforme, currículo de aleatorización (progresivo), ADR (Automatic Domain Randomization).
Sim-to-sim es la práctica de transferir una política entrenada en un simulador (p. ej., MuJoCo) a otro simulador (p. ej., Isaac Sim) como etapa intermedia antes del robot real. Si la política falla en otro simulador, fallará en el mundo real.
Es una validación económica y rápida. Probar en 2+ simuladores con físicas distintas revela las debilidades de la política antes de arriesgar hardware costoso. También permite aislar si el problema es visual o de dinámica.
Transferencia cross-simulator, brecha de fidelidad física entre simuladores, herramientas de conversión URDF/MJCF, estandarización de benchmarks (SIMPLER), evaluación estadística (N episodios, confidence intervals), depuración visual vs dinámica.
El sistema operativo de los robots: pub/sub, TF2, Nav2 e integración con VLA. ROS2 es el estándar de la industria para la robótica de producción.
ROS2 es el framework middleware estándar de la industria robótica. A diferencia de ROS1, usa DDS (Data Distribution Service) como capa de transporte, con QoS configurable, descubrimiento automático de nodos y comunicación en tiempo real sin un nodo maestro central.
Cualquier robot que llega a producción industrial usa ROS2. Es el «Linux de la robótica». Integrar un modelo VLA en ROS2 es obligatorio para un deploy real. Las distribuciones actuales (Humble LTS, Iron) son estables y tienen soporte hasta 2027+.
DDS (Fast-RTPS, Cyclone DDS), nodos (nodes), ejecutores (single-threaded vs multi-threaded), nodos de ciclo de vida, perfiles QoS (reliability, durability, history), sistema de compilación colcon, ament_cmake/ament_python.
Los tres patrones de comunicación en ROS2. Los topics son pub/sub asíncronos (streaming de datos, p. ej., imagen de la cámara). Los services son request/reply síncronos (p. ej., cambiar de modo). Las actions son tareas largas con feedback (p. ej., mover el brazo hasta una posición).
Elegir el patrón incorrecto causa errores sutiles: usar un topic donde debería haber una action significa perder información sobre el progreso; usar un service donde debería haber un topic bloquea el nodo. La inferencia de VLA suele publicar en un topic (alta frecuencia) y recibir comandos mediante una action.
Publisher/Subscriber (topic), Client/Server (service), ActionServer/ActionClient, interfaces msg/srv/action, mensajes personalizados, QoS para cada tipo, ros2 topic echo/pub para depurar, rqt_graph para visualizar.
TF2 (Transform Library 2) mantiene un árbol de transformaciones 3D entre todos los frames de referencia del robot (base_link, cámara, gripper, etc.) actualizado en tiempo real. Permite convertir coordenadas entre cualquier par de frames al instante.
VLA necesita saber dónde está la cámara con respecto al gripper y al mundo. Sin TF2, tendrías que calcular transformaciones manualmente en cada frame. TF2 lo hace automáticamente con un buffer temporal, esencial para la fusión de sensores.
Frames (base_link, odom, map, camera_link, tool0), transformaciones estáticas y dinámicas, tf2_ros::Buffer, lookupTransform(), URDF → robot_state_publisher → árbol TF, tf2_echo para depuración, rviz2 para visualizar.
Nav2 es el stack de navegación autónoma (planificación de rutas, obstacle avoidance, costmaps). MoveIt2 es el framework de manipulación (motion planning, cinemática inversa, collision avoidance). Juntos cubren la movilidad y la manipulación.
VLA puede generar acciones de alto nivel ("ve a la mesa"), pero Nav2/MoveIt2 ejecutan la planificación de una ruta segura. La combinación VLA (qué hacer) + Nav2/MoveIt2 (cómo llegar allí sin chocar) es el estándar para robots manipuladores móviles.
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.
El nodo de inferencia VLA en ROS2 es el componente que recibe imágenes y comandos de lenguaje mediante topics, ejecuta el modelo VLA (PyTorch/ONNX) y publica acciones para el controlador del robot. Funciona como un puente entre el mundo ROS2 y el mundo ML.
Integrar ML en ROS2 presenta desafíos únicos: GIL de Python, latencia de serialización, sincronización cámara-acción, gestión de memoria de GPU. Un nodo bien diseñado marca la diferencia entre 5 Hz y 50 Hz de inferencia.
nodo rclpy con callback de imagen, message_filters (sincronizar cámara + joint_states), ONNX Runtime para inferencia optimizada, TensorRT vía ROS2, búferes preasignados (evitar malloc), executor multihilo, nodos composables.
Los launch files en ROS2 (Python) orquestan el inicio de varios nodos con parámetros, remappings y condicionales. En producción, se combinan con systemd, Docker y monitoreo para garantizar que el sistema robótico se reinicie automáticamente después de fallas.
El despliegue de robótica en producción es ingeniería de sistemas, no solo ML. Un launch file bien estructurado con lifecycle management, health checks y restart policies es lo que diferencia una demo de un producto. Las empresas pagan un premium por esta experiencia.
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.
Cómo aprende el robot observando a humanos: de las demostraciones a la política neuronal. Behavior cloning, Action Chunking Transformers y Diffusion Policy son los 3 paradigmas dominantes.
Behavior cloning (BC) es la forma más simple de imitation learning: se recopilan demostraciones humanas (pares observación-acción) y se entrena una red neuronal supervisada para asignar acciones a observaciones. Es esencialmente una regresión sobre trayectorias.
BC es el baseline de toda la robótica VLA. Aunque es simple, funciona sorprendentemente bien con suficientes datos. OpenVLA, RT-2 y Octo usan variantes sofisticadas de BC como punto de partida. Entender sus limitaciones (distribution shift) es esencial.
Aprendizaje supervisado sobre pares (s,a), función de pérdida MSE/L1 para acciones continuas, desplazamiento de distribución (errores acumulativos), DAgger (Dataset Aggregation) para mitigar la deriva, cambio de covariables, horizonte de demostración frente a horizonte de ejecución.
ACT (Zhao et al., 2023) predice chunks de acciones futuras de una sola vez, en lugar de una acción a la vez. Un encoder CVAE genera un estilo latente y un decoder transformer genera K acciones futuras condicionadas por ese estilo y por la observación actual.
ACT resuelve dos problemas de BC: el temporal compounding error (al planificar K pasos por adelantado) y la multimodalidad (mediante CVAE). Es la política estándar de LeRobot y la base de ALOHA (brazos bimanuales de Google). Rendimiento de vanguardia con pocas demos.
Action chunking: predecir K acciones a la vez (K=100 típico). CVAE (Conditional Variational Autoencoder) para capturar múltiples modos. Temporal ensemble: promedio ponderado de chunks superpuestos. kl_weight (regularización del espacio latente).
Diffusion Policy (Chi et al., 2023) aplica modelos de difusión (como los de generación de imágenes) a la generación de trayectorias robóticas. Comienza con ruido gaussiano y, en T pasos de denoising condicionados por la observación, genera una trayectoria de acciones fluida y multimodal.
Diffusion Policy supera a BC y ACT en tareas con alta multimodalidad (p. ej., múltiples caminos válidos hacia el mismo objetivo). Es la base de la política S1 de GR00T N1 y de π0. Su capacidad para capturar distribuciones complejas de acciones es incomparable.
DDPM (Denoising Diffusion Probabilistic Models) aplicado a acciones, noise schedule, conditional denoising (observation-conditioned), U-Net vs transformer backbone, inference steps (DDIM para acelerar), horizonte de acción, observation horizon vs action horizon.
El ajuste fino adapta un modelo VLA preentrenado con datos generales (p. ej.: OpenVLA entrenado con Open X-Embodiment) a tu tarea y robot específicos usando un dataset mucho más pequeño. Es análogo al ajuste fino de LLM, pero con trayectorias robóticas.
Entrenar un VLA desde cero requiere millones de trayectorias. El fine-tuning de un modelo preentrenado solo necesita 50-200 demostraciones de tu configuración. OpenVLA 7B con fine-tuning supera a RT-2-X con 10x menos datos. Es el camino práctico para el 99% de los proyectos.
LoRA / QLoRA para eficiencia de memoria, programación de la tasa de aprendizaje (decaimiento coseno con calentamiento), backbone congelado vs. ajuste fino completo, mezcla de datasets (datos generales + específicos), olvido catastrófico, evaluación en tareas de validación.
El post-training con Reinforcement Learning aplica RL (PPO, GRPO) sobre una política inicializada mediante imitation learning. El robot mejora más allá de las demostraciones humanas al optimizar señales de recompensa automáticas. Analogía: RLHF para LLM, pero con recompensas físicas.
Qwen-VLA mostró una mejora de +24% en la tasa de éxito tras el post-training de RL con GRPO. El modelo supera las demostraciones humanas originales. Es la frontera actual del rendimiento: IL para el bootstrap, RL para la optimización.
GRPO (Group Relative Policy Optimization), PPO (Proximal Policy Optimization), diseño de recompensas para manipulación, recompensa dispersa basada en el éxito frente a recompensa densa, penalización KL (no desviarse demasiado del IL), eficiencia de muestras, RL online frente a offline.
La evaluación en robótica VLA mide la success rate (% de tareas completadas) en escenarios in-distribution (los mismos objetos del entrenamiento) y out-of-distribution (objetos, posiciones e iluminación nuevos). La OOD success rate es la métrica que realmente importa.
Un modelo con un 95% in-distribution puede tener un 30% OOD. Saber diseñar evaluaciones que prueben la generalización real evita sorpresas en el deploy. Benchmarks como SIMPLER y LIBERO estandarizan las comparaciones entre modelos.
Tasa de éxito (SR), SR OOD, métricas de finalización parcial, N_eval_episodes (50+), intervalos de confianza, benchmark SIMPLER, suite LIBERO, grabación de video de fallas, taxonomía de errores (falla de agarre, falla de alcance, colisión), estudios de ablación.
El puente más difícil: cómo transferir habilidades del simulador al robot real. Domain randomization, system identification y el ciclo real-to-sim-to-real.
La brecha entre simulación y realidad es la diferencia entre el comportamiento de un robot en el simulador y en el mundo real. Tiene tres fuentes: visual (texturas, iluminación), dinámica (fricción, masas, compliance) y sensorial (ruido de cámara, latencia, jitter). Una política perfecta en simulación puede fallar el 100% de las veces en el mundo real.
Ignorar el reality gap es el error más común de los principiantes. Entender sus fuentes permite elegir las técnicas adecuadas: domain randomization para el gap visual, system identification para el gap dinámico, sensor noise injection para el gap sensorial.
Brecha visual (renderizado vs. cámara real), brecha de dinámica (física simplificada vs. contacto real), brecha de sensores (sensores ideales vs. ruidosos), brecha de actuadores (control perfecto vs. juego mecánico y fricción), métricas de transferibilidad, tasa de éxito de sim-to-real.
Domain randomization varía sistemáticamente los parámetros del simulador (texturas, colores, posición de las luces, masas, coeficientes de fricción) en cada episodio. La política se ve obligada a generalizar porque nunca ve el mismo escenario dos veces.
Es la técnica de sim-to-real más robusta y más utilizada. OpenAI la usó para resolver el Rubik's Cube (2019), NVIDIA la usa en Isaac Lab, y todos los pipelines VLA modernos incluyen alguna forma de randomization. Sin esto, las políticas se sobreajustan a la apariencia de la simulación.
DR visual: texturas aleatorias, color de fondo, intensidad de la luz, posición de la cámara. DR de física: masa ±30%, fricción ±50%, damping, retraso de acción (1-3 pasos). ADR (Automatic Domain Randomization): aumenta los rangos automáticamente cuando el rendimiento se estabiliza.
La identificación de sistemas (sysid) es el proceso de medir los parámetros físicos reales del robot (masas, inercias, fricción, rigidez) y configurar el simulador para que coincidan. En lugar de aleatorizar todo, calibras la simulación para que sea lo más parecida posible a la realidad.
Domain randomization con rangos muy amplios puede degradar el rendimiento (la política se vuelve "mediocre en todo"). System identification permite usar rangos estrechos centrados en los valores reales, combinando lo mejor de ambos mundos: robustez + precisión.
Estimación de parámetros: registrar una trayectoria real y optimizar los parámetros de la simulación para minimizar el error. Optimización bayesiana para la identificación del sistema. Aprendizaje de física residual: red neuronal que aprende la diferencia entre la simulación y la realidad. Herramientas de calibración de simulación (edición de MuJoCo XML, configuración de Isaac Lab).
Sim-to-real transfer es el pipeline completo para llevar una política entrenada en simulación y hacerla funcionar en el robot real. Incluye: entrenamiento con DR/sysid en la simulación, validación sim-to-sim, deploy inicial con safety constraints e iteración con datos reales.
Es el cuello de botella de toda la robótica basada en aprendizaje. Dominar sim-to-real es la habilidad más valorada en la industria porque determina si meses de entrenamiento en simulación se traducen en rendimiento real o en horas de GPU desperdiciadas.
Progressive deployment: sim → sim-to-sim → real con límites de seguridad → real full. Suavizado de acciones (filtro de paso bajo en los comandos). Restricciones de seguridad (límites de fuerza, velocidad y área de trabajo). Adaptación en línea: ajustar la política con datos reales.
Real-to-sim-to-real es un ciclo iterativo: recopila datos en el robot real, usa esos datos para calibrar/mejorar el simulador, vuelve a entrenar la política en el simulador mejorado y vuelve a implementarla. Cada iteración mejora tanto el simulador como la política.
Un único pass de sim-to-real rara vez es suficiente. El ciclo iterativo es como se desarrollan los robots comerciales en la práctica. Figure, NVIDIA y Physical Intelligence ejecutan decenas de iteraciones real-to-sim-to-real antes de declarar un comportamiento «production-ready».
Volante de inercia de datos: más datos reales → mejor simulación → mejor política → más datos reales. Ajuste automático de la simulación con datos reales (simulación neuronal). Digital twin: réplica exacta de la configuración real en la simulación. Pipeline de continuous deployment: CI/CD para políticas robóticas.
Los hitos de sim-to-real: OpenAI resolvió el cubo de Rubik con una mano robótica Dexterous (2019) usando ADR a gran escala. NVIDIA entrena la locomoción de humanoides en Isaac Sim con 4096 entornos paralelos. Google RT-2 usó sim-to-real para validar tareas de manipulación.
Estos casos demuestran que la transferencia de simulación a realidad funciona para tareas extremadamente complejas. Las lecciones aprendidas (escala de aleatorización, importancia de los sensores táctiles, diseño de la recompensa) se aplican directamente a cualquier proyecto VLA.
OpenAI Rubik's: ADR con 200+ parámetros aleatorizados, 13K años de experiencia de simulación. Humanoide de NVIDIA: simulación masivamente paralela, PPO con 4096 envs, 45 min de tiempo de ejecución. Google RT-2: benchmark SIMPLER para validación en simulación. Lección: la escala de la simulación compensa.