Detailed content
🕳️ The reality gap: physics, sensor, actuator, appearance
O reality gap is the systematic divergence between simulator behavior and the physical world's behavior. A policy that learns to exploit simulator imperfections—idealized friction, perfect contact, noise-free sensors—performs brilliantly in simulation and fails on hardware. Mapping the four sources understanding the gap is the first step toward closing it.
🌐 Physics gap
Contact models (idealized Coulomb), friction, restitution, rigid vs. deformable bodies, cables, and fabrics. Where fine manipulation suffers most.
📷 Sensor gap
Rendering vs. real images: lighting, reflections, motion blur, RGB-D noise, lens distortion. Vision is the biggest source of the zero-shot gap.
⚙️ Actuator gap
Command latency, backlash, torque limits, motor dynamics, and controller gains that the sim simplifies or ignores.
🎨 Appearance gap
Textures, colors, and materials that don’t match real objects; the domain where visual randomization directly targets the problem.
📊 Research data
- 99% → ~30% — typical drop in success rate for a sim-only policy transferred naïvely to the real world without mitigation.
- 10.000×+ — data collection throughput advantage in GPU-parallel sim (Isaac Lab) versus real-world teleoperation.
- Vision dominates — in manipulation, the visual gap often exceeds the dynamics gap as a cause of failure.
Reality gap
Sim↔real divergence.
Contact dynamics
Contact physics is difficult to simulate.
Sensor noise
Real-world noise missing from the sim.
Actuation delay
Command→torque latency.
🎲 Domain Randomization: texture, lighting, mass, friction, delays
A domain randomization (DR) reverses the problem: instead of making the sim perfect, it makes it variable enough that the real world looks like just another sample from the training distribution. If the policy has seen 10,000 variations in friction, light, and mass, real-world friction falls within what it already handles. It’s the most robust and affordable technique for transfer zero-shot.
✓ Do
- ✓Randomize physics (mass, friction, damping) AND vision (textures, lighting, camera) together.
- ✓Use Automatic DR (ADR): expand ranges only when the policy can handle them — automatic curriculum.
- ✓Randomize actuator delays and observation noise, not just appearance.
- ✓Center the ranges on the actual measured value (sysID) and expand around it.
✗ Avoid
- ✗Randomize so aggressively that the task becomes impossible and the policy collapses into useless conservative behavior.
- ✗Only visual DR and ignoring dynamics — a beautiful policy that slips in the real world.
- ✗Ranges centered outside the real distribution: you're covering the wrong area.
- ✗Thinking DR replaces all real data—it reduces the need, but doesn’t eliminate it.
# 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
⚡ Practical tip
Start narrow and use ADR to expand the ranges automatically as the policy improves. A fixed, overly wide DR from the start kills the learning signal; adaptive DR finds the edge of what’s trainable.
Visual DR
Textures, lighting, camera.
Dynamics DR
Mass, friction, delays.
ADR
Automatic track curriculum.
Zero-shot
Real, with no fine-tuning.
🔀 Domain Adaptation: align sim/real features
When the visual gap is too large to cover with noise alone, the domain adaptation comes in: instead of making the policy invariant by brute force, actively brings the distribution closer to features of sim and real. Adversarial techniques align embeddings; models such as RCAN translate real images into a sim "canonical" form before inferring.
💡 DR vs. adaptation — when to use each
DR is proactive and needs no real data: it covers uncertainty blindly. Adaptation is reactive and uses real data (labeled or unlabeled) to close the residual gap. In practice, the strong recipe is DR + a little adaptation/real-in-the-loop.
Think of DR as "preparing for every kind of weather" and adaptation as "adjusting your clothes to today’s weather."
Adversarial feature alignment
A discriminator tries to distinguish sim features from real ones; the encoder learns to make them indistinguishable.
Pixel-level translation (RCAN)
Maps real images → canonical sim, removing irrelevant variation before the policy.
Real-in-the-loop
Injects real samples (without action labels) into training to anchor the encoder in the physical domain.
Domain adaptation
Align distributions.
Feature alignment
Indistinguishable embeddings.
RCAN
Real → canonical sim.
Real-in-the-loop
Real data anchors the encoder.
🪞 System identification and digital twins
DR covers uncertainty; system identification (sysID) reduces it at the source. By measuring the real robot—masses, centers of inertia, joint friction, control latency—you calibrate the simulator to reproduce the specific hardware. The result is a digital twin: a faithful digital twin that serves as a training ground and a safe test bench.
📊 What a digital twin unlocks
- Safe training — explore risky policies without breaking expensive hardware.
- Better DR — ranges centered on the actual measured value, not guessed.
- Debug — reproduce a real failure in the twin and dissect it frame by frame.
- Pre-deploy — validate policy updates before they go to the physical robot.
# 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
Calibrate sim to reality.
Digital twin
Faithful digital twin.
Calibration
Mass, friction, latency.
Pre-deploy
Validate on the twin first.
🧪 Sim+real co-training and fine-tuning with few demos
The dominant practical recipe in 2026 isn't "sim OR real"—it's co-training. The sim provides coverage inexpensive (millions of variations), and a handful of real demonstrations provides fidelity final. Mixing ~95% sim + ~5% real, or doing a short fine-tuning run on real data, usually outperforms either one alone.
Pre-training in simulation with DR
Policy robust to wide variation; learns a general skill at near-zero cost.
Mixed co-training
Batches combine simulation and real data; real data anchors the domain without losing simulation coverage.
Final real-world fine-tuning
A few real demos (LoRA/short fine-tuning) calibrate the policy to the specific target robot.
⚡ Practical tip
Real demos are expensive—spend them where sim is weakest: fine contact, deformable materials, occlusions. Don’t waste teleoperation reproducing what sim already covers well (free-space motions).
Co-training
Mix sim + real.
Sample efficiency
A few real demos are enough.
Fine-tuning
Brief tuning on the target robot.
95/5
Typical sim/real mix.
📏 Honest evaluation: measure transfer, not overfitting to the sim
The most common mistake in sim-to-real is confusing sim-score with real capability. A policy that reaches 99% in simulation says little about the hardware. The only metric that matters for deployment is success rate on the physical robot, measured under variation the policy hasn't seen, using honest protocols.
✓ Do
- ✓Report success rate real under held-out conditions (new objects/positions).
- ✓Run enough trials (N) and provide a confidence interval.
- ✓Compare sim-score vs real-score to quantify the gap remaining.
✗ Avoid
- ✗Announcing capabilities based only on the simulator score.
- ✗Evaluating in the same scenario and seed as training (disguised overfitting).
- ✗Hide the variance: 3 lucky trials are not evidence.
💡 The metric that matters
O sim2real gap = (sim score − real score). Reducing it is the goal of the entire module. A high sim score with a large gap means you optimized the wrong place — and only find out by measuring in the real world.
Real success rate
Only deployment metric.
Held-out
Unseen variation.
Sim2real gap
Sim score − real score.
Variance
CI over N trials.
✅ Module summary
Next module
3.2 — Humanoids: Figure, Tesla, Unitree, GR00T. Where sim-to-real meets general-purpose bodies.