Domain randomisation

Domain randomisation varies the simulation’s physical parameters during training so the policy depends on no single set of them.

microduck_rl randomises four quantities per environment:

Randomised	Why it
Battery voltage	A full duck and a nearly flat one deliver different torque
Voltage sag under load	Voltage collapses when several servos pull at once, and the gait feels it
Command delay	The real control path has latency; the policy must tolerate it
Friction magnitude	Unit-to-unit variation and wear

The implementation is FrictionDRBamActuator in src/mjlab_microduck/actuator/.

Not the same as adding noise

This is the distinction that matters most:

Randomising physics means each parallel environment holds a different robot — this one runs at higher voltage, that one with more friction. The policy has to find a control strategy that holds across the whole distribution.

Adding Gaussian noise to observations means the robot is the same and the readings jitter. The policy learns to ignore noise, not to cope with a different machine.

The second is useful for sensor noise, and does nothing for the core sim2real problem: the gap between simulation and hardware is not noise, it is a systematic shift in parameters.

The cost

Wider randomisation buys robustness and lowers peak performance — the policy has to leave headroom for the worst case. How wide is an experiment, not a value to maximise.