PTENES
Start / Technical / Module 2.6
MODULE 2.6

🌉 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.

🖥 Simulator Domain Randomization Physics + Visual + Sensor Isaac Sim / MuJoCo trained policy 🌉 Sim-to-Real SysId · DR · Action Smoothing Safety Constraints Progressive Deployment sim → sim-sim → real limited → real deployment 🤖 Real Robot Real-world data collected real-to-sim feedback Data Flywheel real-to-sim: real data refines the simulator Iterative loop: each cycle improves both simulation and policy
6
Topics
~55 min
Duration
Advanced
Level
Technical
Type
1

🔬 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
📊
Transferability
Metrics
🎯
Success Rate
Sim-to-Real
📷
Sensor Noise
Injection
⚙
Actuator
Backlash Model
2

🎲 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
3

🔧 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.

1

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.

2

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.

3

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.

4

🚀 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))
5

🔄 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.

🤖 Real Robot collects data real episodes 🔧 Calibrate Sim sysid + neural sim digital twin update 🖥 Sim ↑ re-trains policy massive parallel new policy deployed → collects more data → flywheel accelerates Each iteration: more accurate sim + better policy
🌀
Data Flywheel
data → sim → policy
🧠
Neural Sim
automatic sim tuning
👥
Digital Twin
exact replica of the setup
🔁
Robotic CI/CD
continuous deployment

🏭 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.

6

🏆 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.

2019

OpenAI Dexterous Hand — Rubik’s Cube

The founding milestone: a robotic hand solved a Rubik’s Cube with massive ADR.

ADR: 200+ randomized parameters · 13,000 years of sim experience · Tactile sensor essential
2023

NVIDIA Isaac Lab — Humanoid Locomotion

Massive parallel training in Isaac Sim for humanoid robots.

PPO with 4096 parallel envs · 45 min wall-clock to convergence · foundation for GR00T N1
2024

Google RT-2 — SIMPLER Benchmark

Validate VLAs in sim before deployment — strong correlation with real-world performance.

SIMPLER + LIBERO standardize comparisons · sim as a reliable proxy · data scale pays off

📚 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

✓
The reality gap has 4 dimensions — visual, dynamics, sensor, and actuator. Each requires specific mitigation techniques.
✓
Domain randomization + SysId — the combination is more powerful than either technique alone: sysid calibrates the center, DR covers the uncertainty around it.
✓
Progressive, safety-first deployment — sim → sim-sim → limited real-world → full real-world. Action smoothing and force limits are mandatory.
✓
Real-to-sim-to-real is iterative — the data flywheel is what distinguishes amateur robotics projects from production industrial robots.

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.