Control rate is the frequency, in hertz, at which actions are sent to the robot's actuators: the inverse of the control period Δt. It is a property of the robot and recording setup, not of the model. A dataset recorded at 30 fps trains a policy whose actions are spaced 1/30 s apart, and the policy should be deployed at that rate. The ALOHA setup in the ACT paper (Zhao et al., 2023) teleoperated and recorded at 50 Hz; LeRobot's recording examples for the SO-101 use 30 fps.
With action chunking, control rate and model call rate come apart. The π0 paper (Black et al., 2024) ran its 50 Hz robots by calling the model "every 0.5 seconds (after executing 25 actions)": a 50 Hz control rate from a 2 Hz call rate. This matrix stores the two separately. control_rate_hz is executed actions per second after chunking; inference_hz is model calls per second. Neither may be derived from the other without stating the number of actions executed per call.
The deployment rate should match the training data. If a policy trained on 30 fps data is run at 50 Hz, each chunk plays back faster than the motion it imitates, which changes the dynamics the policy was trained on.
A common misconception is that a high control rate makes a policy reactive at that rate. A SmolVLA chunk executed open-loop at 30 Hz reacts to new observations only when the next chunk arrives; reactivity is bounded by inference latency and the execution horizon, and is improved by async inference. Rate matters for demonstrations too: in the ACT paper's user study, cutting teleoperation from 50 Hz to 5 Hz caused "a 62% slowdown in completion time".