What is domain randomization, and what a wider range costs in episodes
Randomization defines a distribution rather than a scene, so the range is a data decision. Widen it and the policy hedges; narrow it and the policy cannot transfer.
Domain randomization is a way of generating training experience. Instead of building one simulated environment that matches reality as closely as possible, you build a generator that produces many environments, varying whatever is uncertain: lighting, textures, object mass, surface friction, sensor noise, control delay. The policy trains across that spread and is expected to transfer because reality falls somewhere inside it.
The reframing that matters to anyone paying for the data: the deliverable is not a set of scenes. It is a distribution, and the distribution is defined by a configuration. Two simulated datasets with the same episode count and different ranges are different products.
The configuration is part of the dataset
In a real collection, the metadata says what was recorded: environment, device, speaker, conditions. In a randomized simulation, the equivalent is the sampling configuration — which parameters were varied, over what range and with what distribution, what was held fixed, and which seed produced the run.
That configuration is what makes the data reproducible and diagnosable. Without it, a policy that fails to transfer leaves no way to tell whether the real conditions sat outside the range, whether the range was so wide the policy hedged, or whether something was randomized that should have been constant.
So when simulation data is part of a purchase, ask for the configuration alongside the episodes, in a form that can be re-run. A simulator version number belongs there too, because an episode generated by two different versions of the physics engine is two different episodes.
What should not be randomized
The instinct is that more variation is safer. The opposite is closer to the truth, and the reason is that a policy learns to be invariant to whatever varies. Randomize something that is constant in deployment and you are teaching the model to ignore a cue it could have used.
The rule that follows: hold fixed everything that is fixed in the real setting, and randomize only what genuinely varies. If exposure is locked on the real camera, randomizing it across a wide band spends capacity on a condition that never occurs. If the table height is identical in every deployment, varying it adds nothing. If the object set is fixed, generating a distribution over object shapes is only useful if the deployment will actually meet new shapes.
The subtle version of this mistake is randomizing something that correlates with the task. If the target object is always the red one in deployment, and color is randomized during training, the policy may learn to treat color as noise and lose the cheapest cue available to it.
Where the ranges come from
Ranges should come from measurements of the real system rather than intuition about what might vary. That means measuring the actual spread of each parameter you intend to randomize — not the average, the spread — and setting the range to cover it with some margin.
The check that catches most mistakes is a coverage test rather than a success metric. Take held-out real scenes and ask whether their parameter values fall inside the randomized ranges. If a real scene sits outside the range on one axis, no amount of training will prepare the policy for it, because nothing like it was ever generated. This audit is cheap and it finds problems the success rate conceals.
The second check looks at the other end: is any part of the range physically impossible? A range that includes configurations the hardware cannot reach teaches the policy to handle a world that does not exist, and it does so using episodes that could have been spent on the real spread.
Wider is not free: the episode cost of a bigger range
There is a budget consequence that is easy to miss. Widening the range enlarges the space the policy has to cover, and covering a larger space takes more samples. The cost of a wider range is paid in episodes, and episodes cost compute and engineering time even when they are simulated.
That is the shape of the tradeoff. A narrow range trains faster and transfers only if reality sits inside it. A wide range covers more reality and needs more training to reach the same competence, and if it is too wide the policy never becomes competent at anything, because hedging is the rational response to a target that keeps moving.
The practical procedure is to start narrow, confirm the policy is genuinely competent in simulation, then widen gradually with the coverage test as the guide. Turning randomization up because transfer failed, without measuring anything, is a guess that spends the training budget while it is being tested.
What randomization cannot fix
Randomization adds variation within a model. It cannot repair a model that is wrong in kind. If the contact behavior of the material is not represented — cloth, rope, granular media, anything where the contact area changes continuously — then adding noise to the parameters produces a policy that is robustly wrong rather than one that transfers. The same applies to sensing that is not simulated faithfully, with tactile contact as the standard example.
The division of labor follows from that: simulate where the physics is well understood and perception is the hard part, and collect real episodes where contact is the hard part. For those portions, no configuration file substitutes for time on the hardware.
A useful last question for any simulation-heavy plan is what will be measured on the real system, and when. Until a policy has run on hardware, its success rate is a property of the simulator rather than of the robot.