← All Explainers articles

Explainers

Sim-to-Real (Sim2Real)

Sim-to-real (often written Sim2Real) refers to both the technique and the core challenge of training a robot control policy inside a physics simulator — where trial and error is cheap, fast, and safe — and then deploying that trained model onto real robot hardware.
Published: 2026-07-068 min read

01Definition

Sim-to-real (often written Sim2Real) refers to both the technique and the core challenge of training a robot control policy inside a physics simulator — where trial and error is cheap, fast, and safe — and then deploying that trained model onto real robot hardware.

02The reality gap

The central difficulty is the "reality gap": simulated physics, sensor noise, and materials never perfectly match the real world, so a policy that works flawlessly in simulation can fail the moment it meets real friction, real lighting, or a real object's actual weight.

SIMULATION

Training environment

Trial and error is cheap, fast, and safe — but physics, sensor noise, and materials are only an approximation of the real thing.

REAL HARDWARE

Deployment environment

Real friction, real lighting, and a real object's actual weight — none of which the policy has experienced in exactly this form before.

03Two ways to close the gap

There are two main, complementary ways to close that gap. Domain randomization trains a policy across many varied simulated conditions instead of one fixed environment, so it becomes robust to variation rather than overfitting to one simulator's exact quirks. System identification takes the opposite approach: instead of varying the simulator, it carefully calibrates the simulator's parameters — friction, mass, motor response — against real measurements, so a single, more accurate simulation is closer to the truth from the start. Many real sim-to-real pipelines use both together.

APPROACH 1

Domain randomization

Vary the simulator's textures, lighting, and physics parameters on every training run, so the policy becomes robust to variation rather than one exact setup.

APPROACH 2

System identification

Calibrate the simulator's parameters against real-world measurements, so a single, more accurate simulation is closer to the truth from the start.

04Example: OpenAI Dactyl

OpenAI demonstrated domain randomization with Dactyl, a robot hand trained entirely in simulation using a technique called Automatic Domain Randomization (ADR), which automatically increases the difficulty of that randomization as training progresses. The resulting policy solved a Rubik's Cube one-handed on real hardware — and kept working even when a researcher perturbed the hand with a stuffed giraffe, a disturbance it had never seen during training.

1Train in simulation, randomizing textures/lighting/physics (ADR)
2Deploy the trained policy on real hardware
3Policy stays robust to disturbances never seen in training

OpenAI — Solving Rubik's Cube with a Robot Hand

05Related terms

06FAQ

Q.If the simulator were more accurate, would the reality gap disappear?

A.Not entirely — no simulator perfectly matches real-world physics, sensor noise, and materials. Higher fidelity helps (that's what system identification is for), but domain randomization is used precisely because it makes a policy robust to variation instead of betting on ever-closer simulation accuracy alone.

Q.What exactly gets randomized in domain randomization?

A.Visual properties like textures and lighting, and physical properties like friction, mass, and object dimensions — varied on every training run so the learned policy doesn't overfit to one simulator's exact settings.

Q.Should a team pick domain randomization or system identification?

A.They're not mutually exclusive — many pipelines calibrate the simulator with system identification first to get a reasonably accurate baseline, then layer domain randomization on top so the policy also tolerates whatever calibration error remains.