Control Decimation

The number of physics-engine steps that run for every single action a policy outputs.

A physics engine needs a very small timestep (usually a few milliseconds) to stay numerically stable, but a policy network doesn't need to, and often can't, output actions that fast. Control decimation is the setting that lets a policy output one action while the simulator advances that action (or the PD targets computed from it) forward for N consecutive physics steps; N is called the decimation. Both Isaac Lab and legged_gym use this parameter, and the duration of one environment step equals the physics timestep times the decimation. Choosing it involves a tradeoff: too large, and the policy reacts too slowly; too small, and training compute is wasted, and it may no longer match the real robot's control frequency, widening the sim-to-real gap. When deployed to a real robot, the policy generally runs at that same frequency, while the low-level motor PD control runs at a much higher frequency underneath it.

Examplelegged_gym defaults to a 0.005-second physics timestep with decimation = 4, so the policy outputs an action every 0.02 seconds — 50 Hz control — while the joint PD controller executes within 200 Hz physics steps.

Also called

decimation, physics-to-control frequency ratio

Related

Simulation Timestep · Control Frequency · Policy Inference Frequency · Proportional-Derivative Control · Substeps · NVIDIA Isaac Lab

Sources

Isaac Lab API: isaaclab.envs（ManagerBasedEnvCfg.decimation）
legged_gym: legged_robot_config.py