Hardware & control
Control latency
Control latency is the elapsed time between a relevant event or observation and the physical effect of the resulting robot command. It can include sensor exposure and transport, preprocessing, policy inference, network transfer, controller scheduling, actuator response, and communication back to a human operator. The measured boundary must be stated because each component has a different latency.
Also known as: robot control latency, control delay
Updated
Latency is a duration, not a rate
Control frequency says how often a loop aims to update. Latency says how long information or a command takes to travel through that loop. A 100 Hz scheduler can still act on an observation that is 80 ms old, and a low-frequency policy can have short computation latency between its scheduled updates.
The boundary matters. Inference latency measures model computation. Command latency may run from policy output to controller receipt. Observation-to-actuation latency includes sensing, processing and physical response. Teleoperation also has feedback latency from robot sensors to the operator.
Delay changes the state at execution
RT-1 treated inference time as part of a real-time control budget. As models, cameras or networks become slower, the world can move between observation and action.
Delay-Aware Diffusion Policy describes this observation-execution gap explicitly: an action selected for the sensed state can arrive after that state has changed. Asynchronous inference can prevent idle pauses, but it does not make the underlying observation fresh.
Average latency hides dangerous variation
Jitter changes delay from one cycle to the next. Occasional high-percentile latency or packet loss can be more harmful than a stable average because controllers and operators cannot compensate consistently. Teleoperation research also treats time-varying delay as a stability problem.
A dataset or system report should state timestamp locations, one-way or round-trip measurement, mean and percentile latency, jitter, clock synchronisation and each known component. Operator input, sent command, controller receipt and measured motion should remain separate when the collection system can record them.
Sources
Related terms
Hardware & control
Control frequency
Control frequency is the rate, usually expressed in hertz, at which a robot control loop reads state, updates its controller or policy, and issues commands. A robot can contain several nested loops at different rates, so policy frequency, actuator-control frequency, sensor sampling rate, and dataset frame rate should not be assumed to be identical.
Models & learning
Asynchronous inference
Asynchronous inference is a deployment pattern that overlaps robot action execution with prediction of a later action chunk. A robot client consumes queued actions while a policy process or server evaluates a newer observation, then merges or replaces the remaining queue when the new chunk arrives. The pattern reduces idle inference gaps but does not remove latency, stale observations or safety constraints.
Hardware & control
Feedback control
Feedback control is a closed-loop control method that measures a system’s current output or state, compares it with a target and adjusts the command using the resulting error. In robotics, feedback can correct joint, end-effector, balance or force errors as new sensor measurements arrive.
Data & collection
Teleoperation
Teleoperation is real-time human control of a robot from a remote or mediated interface. For humanoid training-data collection, the operator’s inputs are mapped to robot motions while cameras, proprioception, commands and outcomes are recorded, producing embodied demonstrations in the robot’s own observation and action spaces.
Data & collection
Data synchronisation
Data synchronisation is the process of placing sensor, state, action, annotation, and outcome records on a common timeline so samples that describe the same physical instant or transition can be matched. It requires trustworthy timestamps or trigger relationships and an explicit rule for handling streams with different rates, delays, dropped samples, and clock offsets.