The Sim-to-Real Gap: Why Policies Fail on Hardware

The gap is not mysterious, it is a list. Friction, actuator dynamics, timing, sensor noise structure, contact geometry and mass distribution account for almost every failure of a simulation-trained policy on hardware. Friction and actuator dynamics dominate manipulation failures; timing dominates locomotion failures, and it is the one most teams never model at all.

6mismatches that explain most failures

5 to 40 msreal control latency, usually simulated as zero

0.1 to 1.2plausible friction coefficient range for one surface pair

2 to 10 %mass error typical of a CAD-derived model

The six mismatches

What differs between simulation and hardware
Mismatch	Typical size	Symptom on hardware	Remedy
Friction	factor of 2 to 10	Objects slip or stick unexpectedly	Randomise widely, prefer form-fit grasps
Actuator dynamics	10 to 40 % torque error	Overshoot, oscillation, jerky motion	Model backlash, friction, torque limits
Control latency	5 to 40 ms	Instability, especially in balance	Inject latency into the simulator
Sensor noise structure	qualitatively different	Perception fails on shiny, dark or transparent surfaces	Replay real sensor data, not Gaussian noise
Contact geometry	1 to 5 mm	Grasps miss or collide	Randomise object pose and shape
Mass and inertia	2 to 10 %	Trajectory tracking error under load	Weigh parts, randomise the rest

Latency is the free win. Simulators typically deliver an observation and apply the action in the same step, which is a control loop with zero delay. Real systems have 5 ms to 40 ms between sensing and actuation. Adding that delay to the simulator costs almost nothing and eliminates a whole class of instability that otherwise appears only on hardware.

Randomise what you cannot measure

Domain randomisation is the standard remedy, and its logic is simple: if the policy must work across a broad span of friction values, the real value is somewhere in that range and the policy already handles it. The parameters worth randomising, in rough order of value for manipulation:

Friction coefficients, over at least a factor of three, because measurement is impractical and variation across parts is large.
Control latency, from zero to twice the expected value.
Object mass, plus or minus 20 %, and centre of mass position.
Object pose at the start of the episode, well beyond the expected placement error.
Actuator gains and torque limits, to cover warm and cold behaviour.
Lighting, texture and camera pose, if the policy uses images.

Randomising too little leaves a policy that works in the simulator only. Randomising too much produces a policy that is conservative and slow, because it has learned to handle a world far more hostile than the real one. Widening the range until performance in simulation just begins to degrade is a workable calibration.

Measure the gap rather than guessing

The most useful diagnostic is also the simplest: run the same trajectory in both, log the resulting states, and plot the divergence. This turns a vague sense that things do not transfer into a number that identifies which mismatch dominates.

Divergence that appears immediately points at actuator dynamics or latency.
Divergence that appears at first contact points at friction or contact geometry.
Divergence that grows slowly across a long trajectory points at mass and inertia error.
Divergence only under load points at torque limits or thermal derating.

What closing the gap costs

Effort against benefit for each remedy
Remedy	Engineering effort	Compute cost	Typical benefit
Inject control latency	2 to 8 hours	none	large for balance tasks
Randomise friction and mass	4 to 16 hours	2 to 5x training time	large for manipulation
Model actuator friction and backlash	3 to 10 days	1.2 to 2x	moderate to large
Replay real sensor data	1 to 3 weeks	1x	large for perception
Calibrate the simulator to the robot	1 to 2 weeks	1x	moderate
Collect real demonstrations instead	1 to 3 weeks	0.1 to 0.5x	removes the gap

Read the first row and the last row together. Latency injection is the cheapest fix available and is routinely skipped, while the last row is the reminder that the gap is optional: for many manipulation tasks, collecting real demonstrations costs less engineering than closing the simulation gap would.

The alternative nobody mentions

Real-world data avoids the gap entirely. An imitation policy trained on teleoperated demonstrations on the target robot has no sim-to-real problem, because there is no simulation. The cost is operator hours instead of GPU hours, and for manipulation tasks that ratio often favours real data.

Simulation earns its place where real data is dangerous, slow or impossible to collect: locomotion, dynamic manoeuvres, failure cases and any behaviour requiring millions of attempts. Choosing simulation for a task that a person could simply demonstrate three hundred times is a common and expensive mistake.

Frequently asked questions

Why do simulation-trained policies fail on real robots?

Six mismatches account for most cases: friction, actuator dynamics, control latency, sensor noise structure, contact geometry and mass distribution. Friction and actuator dynamics dominate manipulation, latency dominates balance.

What is the easiest gap to close?

Control latency. Simulators usually apply actions with zero delay while real systems have 5 ms to 40 ms. Injecting that delay into the simulator is nearly free and removes a whole class of instability.

How much should I randomise?

Widen each parameter range until performance in simulation just begins to degrade. Too little randomisation gives a policy that only works in simulation; too much gives a conservative, slow policy that has learned to survive a world harsher than reality.

How do I know which mismatch is hurting me?

Run the same trajectory in both and plot the divergence. Immediate divergence points at actuators or latency, divergence at first contact points at friction, and slow growth over a long trajectory points at mass and inertia error.

Is simulation always the right approach?

No. Imitation learning from teleoperated demonstrations on the target robot has no sim-to-real gap at all. Simulation earns its place for locomotion, dynamic manoeuvres and any behaviour needing millions of attempts or dangerous failures.

Sources

arXiv robotics preprints, sim-to-real transferPrimary literature on domain randomisation and the reality gap
MuJoCo documentationContact and friction model description, and its stated limitations
Gazebo documentationOpen Robotics, sensor and physics modelling options