AI and Robot Learning
Domain Randomisation: The Trick That Makes Simulation Work
Randomise the parameters you cannot measure so reality becomes one sample from the training distribution. What to randomise, how wide, and the failure mode of overdoing it.
Instead of modelling reality accurately, randomise every parameter you cannot measure so that the real world becomes one sample from the distribution the policy trained on. Done well it turns an unusable simulator into a viable training environment. Done carelessly it produces a policy that is conservative, slow and still fails, because the training distribution was wide in the wrong directions.
Why it works
A policy trained on one fixed simulated world learns the specifics of that world, including its exact friction value and its exact latency. Reality differs on every one of those, so the policy meets a situation it has never seen. Randomising forces the policy to find a strategy that succeeds across the whole span, and a strategy that works for friction between 0.2 and 0.9 necessarily works for the real value of 0.45.
The mechanism is the same as data augmentation in vision, applied to physics. It does not make the simulator accurate; it makes accuracy unnecessary.
What to randomise, and how wide
| Parameter | Useful range | Matters for |
|---|---|---|
| Friction coefficient | 0.2 to 1.2 | Grasping, locomotion traction |
| Object mass | ±20 to 40 % | Manipulation dynamics |
| Centre of mass offset | ±10 to 30 mm | Carrying, handover |
| Control latency | 0 to 2x expected | Balance, force control |
| Actuator gain | ±20 to 50 % | Tracking accuracy |
| Torque limit | ±10 to 30 % | Thermal derating on hardware |
| Object pose at reset | 2 to 5x expected error | Perception robustness |
| Camera pose | ±20 to 50 mm, ±5 degrees | Mounting tolerance |
| Lighting and texture | wide | Visual policies only |
| Sensor noise | 1 to 3x measured | State estimation |
The failure mode of overdoing it
A policy trained across an excessively hostile distribution learns the most conservative strategy that survives all of it. Symptoms are recognisable on hardware:
- Excessive grip force, because the policy has trained against friction values that require it.
- Slow, hesitant motion, because it has trained against latencies and torque limits far worse than the real robot.
- Refusal to commit to a grasp, hovering and re-approaching, because it has trained against pose errors much larger than reality.
- Worse average performance than a narrower policy, on the actual robot.
The calibration that works: widen each range until performance in simulation just begins to degrade, then stop. A policy that scores 95 % across a wide distribution typically outperforms one that scores 99 % across a narrow one, but a policy that scores 60 % across an absurd distribution outperforms neither.
What randomisation costs in training time
| Setup | Environment steps to converge | Relative wall clock | Real-world success |
|---|---|---|---|
| No randomisation | 10 to 30 M | 1.0x | very low |
| Visual only | 20 to 50 M | 1.5 to 2x | low to moderate |
| Physics only | 40 to 120 M | 3 to 5x | moderate to good |
| Physics and visual | 80 to 300 M | 5 to 10x | good |
| Excessively wide | 200 M to 1 B | 10 to 30x | moderate, conservative behaviour |
The bottom row is the trap: it costs the most and does not deliver the best result. That cost profile is also why GPU simulators with thousands of parallel environments changed the field, since 300 million steps at 5x real time in one environment is impractical and routine across 4,000.
Adaptive alternatives
- Automatic domain randomisation widens ranges progressively as the policy masters the current distribution, which finds the boundary rather than guessing it.
- System identification first. Measure what can be measured, such as mass, link lengths and latency, and randomise only the rest. Narrower distributions train faster and produce less conservative policies.
- Real-world fine-tuning. A short fine-tune on the physical robot after simulation training collapses the remaining gap and is far cheaper than training from scratch on hardware.
The second point is the most underused. Teams frequently randomise mass over 40 % when a kitchen scale would have given the value to within a gram, and every unnecessary randomised dimension costs sample efficiency.
Frequently asked questions
What is domain randomisation?
Deliberately varying simulation parameters that cannot be measured accurately, so that the trained policy must succeed across the whole span. Reality then becomes one sample from the training distribution rather than an unseen case.
Which parameters matter most?
Friction, control latency, object mass and pose for manipulation; friction, terrain and actuator dynamics for locomotion. Visual parameters such as lighting and texture matter only for policies that consume images.
Can you randomise too much?
Yes. An excessively wide distribution produces conservative behaviour: excessive grip force, slow motion and hesitant approaches, because the policy learned to survive a world harsher than the real one.
How wide should each range be?
Widen until performance in simulation just begins to degrade, then stop. As a starting point, friction over a factor of three, mass at plus or minus 20 % to 40 %, and latency from zero to twice the expected value.
Is measuring better than randomising?
Where measurement is practical, yes. Mass, link lengths and latency can be measured directly, and every dimension removed from the randomisation improves sample efficiency and produces a less conservative policy.
Sources
- arXiv robotics preprints, domain randomisation and sim-to-realPrimary literature on randomisation ranges and automatic curricula
- MuJoCo documentationPhysics parameters available for randomisation and their meaning
- Gazebo documentationOpen Robotics, sensor and physics model configuration