The idea, explained
Step 1: identify what the simulator represents. A simulator may generate camera images and model dynamics—the rules governing how actions change a system over time. For a robot arm, dynamics include mass, friction, motor strength, delay and how objects react to contact. A policy is the rule the agent uses to choose an action from what it observes.
Step 2: locate the gap. Simulated textures may be cleaner, sensors less noisy and contact physics more predictable than reality. A strong learner can exploit those conveniences. It may score well by using a visual reflection that does not exist under factory lighting, or by relying on unrealistically precise friction. Higher visual fidelity can help, but realism alone does not guarantee that every important physical effect is modeled.
Step 3: randomize plausible causes of mismatch. During each training episode, change parameters such as lighting, texture, camera position, object size, friction, latency or sensor noise. The model must then find cues and actions that remain useful across many versions. In the original domain-randomization study, non-realistic randomized renderings supported transfer of an object-localization model to real robotic grasping. Randomization is therefore a robustness method, not a claim that the simulator has become reality.
Step 4: test the coverage assumption. Transfer is most plausible when the real environment falls within, or near, the range of simulated conditions. Randomizing friction from 0.4 to 0.8 does not prepare a controller for ice-like friction of 0.05. Ranges that are too narrow leave blind spots; ranges that are needlessly wide can make the learning problem harder and produce an overly cautious or weak policy.
Step 5: validate safely on hardware. Use held-out simulation conditions first, then controlled physical tests, monitoring failures and collecting real measurements. Those measurements can guide simulator calibration or revised randomization ranges. Success in simulation is evidence about the training environment, not proof of real-world safety.
Follow a worked example.
Suppose a warehouse team trains a camera-guided robot to pick a box. In one fixed simulator, the lamp brightness is 800 units, the camera is always level, box texture is identical, friction is 0.60 and action delay is zero. The policy reaches 99% simulated success, but only 58% over 100 controlled real picks. Failures cluster when shadows move and when the conveyor introduces delay.
The team creates a randomized training setup. For every episode it samples brightness from 500 to 1,100 units, camera tilt from minus 3 to plus 3 degrees, several box textures, friction from 0.45 to 0.75, sensor noise from 0% to 2% and action delay from 20 to 80 milliseconds. One episode might use brightness 620, tilt plus 2 degrees, friction 0.48 and a 70-millisecond delay; the next uses different values. The policy can no longer depend on one shadow edge or instantaneous motion.
After training, it scores 91% on held-out simulated combinations. The team then runs 100 guarded real picks and observes 86 successes. That is an improvement of 28 percentage points over the original 58%, but it is not deployment proof. The remaining failures occur on glossy wrapping absent from training, so the next investigation is whether measured glare can be represented and randomized without hiding other problems.
Where people get stuck
A common misconception is that adding maximum randomness automatically produces maximum robustness. Randomization must reflect meaningful uncertainty. If the training ranges omit a real condition, the model remains exposed; if they combine impossible extremes, training may waste capacity. Also, a high average score can conceal a dangerous subgroup of conditions. Report performance by lighting, surface, delay and other relevant slices, and keep real-world tests controlled.
Now try it yourself.
1. Check the core idea
A drone policy is trained with wind uniformly randomized from 0 to 20 kilometres per hour, but the planned site can experience 35-kilometre-per-hour gusts. Does domain randomization establish that the policy is ready, and what should the team do next?
Reveal the answer & reasoning
No. Training varied wind, but the tested range does not cover the stated 35-kilometre-per-hour condition, so robustness inside 0–20 cannot be extended by assumption. The team should first decide whether operation at 35 is required and safe. If it is, it should improve or calibrate the simulator for that regime, train and evaluate on appropriately chosen wind ranges, reserve separate held-out gust patterns for testing, and perform controlled physical validation under a safety plan. If safe evidence cannot be produced, the operational limit should remain below that condition.
Why this was added
The library covers training, overfitting and deployment monitoring, but it does not yet teach the distinct reality gap, simulator coverage assumption or domain-randomization workflow for physical AI.