🌉 Sim-to-Real: From Virtual to Physical
The toughest bridge in modern robotics: how to transfer skills from the simulator to the real robot. Domain randomization, system identification, and the real-to-sim-to-real loop that powers production robots from NVIDIA, Figure, and Physical Intelligence.
🔬 Reality Gap: Why Simulation ≠ Reality
O reality gap is the difference between a robot’s behavior in the simulator and in the real world. A policy that’s perfect in sim can fail 100% of the time in reality—and understanding why is the starting point for any solid sim-to-real approach.
🔍 Types of Gap
- ◆Visual gap: rendering vs. real camera—textures, lighting, reflections
- ◆Dynamics gap: simplified physics vs. real contact — friction, compliance
- ◆Sensor gap: ideal vs. noisy sensors — camera with jitter, IMU with drift
- ◆Actuator gap: perfect control vs. motor backlash and friction
⚠ Classic Errors
- ✗Ignore the reality gap and expect deployment to work right away
- ✗Train only with static textures and fixed lighting
- ✗Not adding sensor noise during training
- ✗Assume that low loss in simulation = good performance in the real world
🎲 Domain Randomization: Textures, Physics, Lighting
Domain randomization systematically varies the simulator parameters in each episode. The policy is forced to generalize because it never sees the same scenario twice — reality becomes just another "domain" the model has learned to handle.
💡 Why it works
OpenAI used domain randomization to solve the Rubik’s Cube with a Dexterous robotic hand (2019)—200+ randomized parameters, 13K years of simulated experience. NVIDIA uses it in Isaac Lab for humanoids. Without DR, policies overfit to the simulator’s appearance and fail catastrophically in the real world.
📋 Typical Domain Randomization Parameters
# 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 — What to randomize
- ✓ Surface textures and background color
- ✓ Light position, color, and intensity
- ✓ Camera position and angle
- ✓ Distractors: random objects in the scene
✗ Common errors with DR
- ✗ Ranges that are too broad: the policy becomes "mediocre at everything"
- ✗ Randomizing without measuring the resulting performance
- ✗ Ignore ADR — manually increasing ranges is slow
- ✗ Only randomize visuals, ignore dynamics
🔧 System Identification: Calibrating the Simulator
System identification (sysid) is the process of measuring the robot’s actual physical parameters—masses, inertias, friction, stiffness—and configuring the simulator to match them. Instead of randomizing everything, you calibrate the sim to be as close as possible to reality.
Real trajectory collection
Executes specific trajectories (sinusoidal, step) on the real robot and records positions, velocities, and torques at high frequency. This dataset will feed the optimization process.
Parameter optimization
Use Bayesian Optimization or gradient descent to find the sim parameters (masses, friction, damping) that minimize the difference between the real and simulated trajectories.
Residual physics learning
A neural network learns the residual difference between the calibrated sim and the real world — capturing effects that physical equations don’t model well, such as hysteresis and cable compliance.
⚡ DR + SysId: The Best of Both Worlds
Domain randomization with very wide ranges degrades performance. SysId lets you use narrow ranges focused on real values — the robustness of DR with the accuracy of sysid. Ideal pipeline: sysid first to calibrate the center, then DR for robustness around that center.
🚀 Sim-to-Real Transfer: Current Techniques
O complete sim-to-real transfer pipeline involves training with DR/sysid, sim-to-sim validation, progressive deployment with safety constraints, and iteration with real-world data. It's the bottleneck for all learning-based robotics.
✓ Robust pipeline
- ✓ Validate sim-to-sim before touching the real robot
- ✓ Progressive deployment: sim → sim-sim → real with safety limits → full real
- ✓ Action smoothing: low-pass filter on joint commands
- ✓ Safety constraints: force limits, velocity limits, workspace bounds
- ✓ Online adaptation: adjusting the policy with data collected in the real world
✗ Deployment errors
- ✗ Direct deployment without validation in simulation with OOD scenarios
- ✗ Maximum speed with no smooth ramp-up in the first steps
- ✗ Ignore camera latency and OS jitter in the control loop
- ✗ Not defining an emergency stop before the first real-world test
📋 Action Smoothing — Simple low-pass filter
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: The Complete Loop
A single sim-to-real pass is rarely enough. The real-to-sim-to-real loop is iterative: collect data on the real robot, use that data to calibrate and improve the simulator, retrain the policy in the improved sim, and deploy again. Each cycle improves both the sim and the policy.
🏭 How the industry does it
Figure, NVIDIA, and Physical Intelligence run dozens of iterations real-to-sim-to-real before declaring a behavior "production-ready". A single sim-to-real pass is always the starting point, never the finish line.
🏆 Success Stories: OpenAI, NVIDIA, Google
The sim-to-real milestones prove that the approach works for tasks of extreme complexity. Lessons learned from these projects apply directly to any VLA pipeline.
OpenAI Dexterous Hand — Rubik’s Cube
The founding milestone: a robotic hand solved a Rubik’s Cube with massive ADR.
NVIDIA Isaac Lab — Humanoid Locomotion
Massive parallel training in Isaac Sim for humanoid robots.
Google RT-2 — SIMPLER Benchmark
Validate VLAs in sim before deployment — strong correlation with real-world performance.
📚 Universal lessons from these projects
- ◆Simulation scale makes up for: more hours in simulation are rarely a waste of GPU time — they’re an investment in robustness.
- ◆Tactile sensors matter: for fine manipulation, vision alone is not enough — force feedback is critical.
- ◆Reward design is an art: a poorly specified reward in simulation results in catastrophic behavior in the real world.
- ◆Standardized benchmarks: SIMPLER and LIBERO enable reproducible comparisons of methods.
✅ Module Summary
Next track: Track 3 — Advanced
You completed the entire Technical Track. In Track 3 — Advanced — we explored cutting-edge architectures, training at massive scale, multi-task learning, and the foundation models defining the state of the art in VLAs.