Domain Randomization for Humanoids What to Vary and Why

Domain randomization trains a policy across simulated variations so the physical robot is less sensitive to modeling error. Humanoid work can vary mass, inertia, friction, joint damping, actuator strength, sensor noise, observation delay, terrain and external pushes. Broad ranges can make training unnecessarily hard, while narrow ranges can miss the physical robot.

A useful report states which parameters were randomized, the sampled ranges, whether parameters were correlated, and which perturbations were then tested on hardware. Simulation variation by itself does not establish sim-to-real transfer.

A nominal simulator receives distributions for uncertain physical and sensing parameters. Parallel environments sample combinations during training, after which the policy should be tested on held-out simulation conditions and then on the physical robot.

Randomization sits around the learned policy rather than replacing motor control or safety. Torque limits, collision handling, state estimation and emergency behavior still need robot-specific implementation and hardware validation.

Locomotion studies vary ground friction, center of mass and actuator response. Whole-body manipulation adds payload, hand contact, camera pose and tool inertia. Battery voltage and motor temperature are often omitted. The systems are not treated as interchangeable.

Mass and inertia affect balance and acceleration, friction and terrain affect contact and slip, and actuator strength and delay affect torque tracking. These variables interact, so a useful evaluation reports the sampled ranges and then tests the resulting policy on the physical robot.

Strong evidence includes repeated sessions or multiple robot units, because one favorable machine can hide manufacturing variation. Push recovery and payload changes are more informative than nominal walking. Real-system evidence is separated from simulation, internal testing, controlled public demonstrations, pilots and commercial deployment.

For domain randomization humanoid robots, the strongest report would name the exact version, task boundary, environment, control method, duration, trial count, intervention rate and recovery behavior. The current public record for Mass and inertia, Friction and terrain does not provide every field, so the article limits each conclusion to the documented setup.

Compare studies only when the randomized parameters, range widths, robot, task and physical test conditions are visible. Missing ranges or hardware trial counts stay undisclosed rather than being estimated.

Very wide distributions can reduce task performance because the policy must cover unrealistic combinations. Very narrow distributions can overfit the simulator. Measured hardware variation, payload tolerances and identified model error provide better range anchors than arbitrary multipliers.

Failures arise from impossible parameter combinations, missing correlations between physical quantities, camera randomization that conflicts with calibration and policies that become too conservative under excessive variation.

A report should also distinguish simulation robustness from real-robot transfer. Hardware trial count, intervention rules, recovery behavior and the exact policy checkpoint are needed before a sim-to-real result can be generalized.

Applications include locomotion across different floors, push recovery, payload variation and manipulation with uncertain contact. The physical test should match the uncertainty being randomized rather than reporting only nominal walking or one successful run.

For deployment, teams should keep independent torque, velocity and collision limits and record when the learned policy leaves the tested operating range.

Open work includes fitting parameter distributions from fleet logs, modeling correlations between parameters and detecting drift as actuators wear or payloads change. Useful reports should publish the sampled ranges, held-out simulation tests and physical-robot trials, including failures and recovery behavior.

Versioned sensor layouts, action spaces, control rates and hardware test conditions make later replications possible when the robot or simulator changes.