PTENES
← Back to Track 3 MODULE 3.1

🌉 Sim-to-Real: Domain Randomization and Transfer

How to train a policy on millions of simulated episodes—cheap, safe, and infinitely parallelizable—and still get it to work on the physical robot, where friction is real and the camera has noise.

6
Topics
~45
Minutes
Advanced
Level
Theory
Type

Detailed content

SIMULATION N parallel environments · approximate physics DOMAIN RANDOMIZATION REAL 1 robot · true physics · real noise
1

🕳️ 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.

2

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

3

🔀 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."

A

Adversarial feature alignment

A discriminator tries to distinguish sim features from real ones; the encoder learns to make them indistinguishable.

B

Pixel-level translation (RCAN)

Maps real images → canonical sim, removing irrelevant variation before the policy.

C

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.

4

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

5

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

1

Pre-training in simulation with DR

Policy robust to wide variation; learns a general skill at near-zero cost.

2

Mixed co-training

Batches combine simulation and real data; real data anchors the domain without losing simulation coverage.

3

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.

6

📏 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

✓
The reality gap has 4 sources — physics, sensor, actuator, appearance; map them before mitigating them.
✓
Domain randomization — makes the real world "just another sample"; ADR finds the edge of what can be trained.
✓
Adaptation + sysID + digital twin — reduce the gap at its source instead of just covering it.
✓
Sim + real co-training — Cheap coverage + real-world fidelity beats either alone.
✓
Honest evaluation — only the real held-out success rate counts; sim score is misleading.

Next module

3.2 — Humanoids: Figure, Tesla, Unitree, GR00T. Where sim-to-real meets general-purpose bodies.