Latency Budget¶
This page documents the latency controls that are visible in the repository and the deploy-side measurements you need before hardware bring-up. Treat numeric budgets as robot-specific measurements, not UniLab defaults.
Latency Surfaces In Repo¶
Surface |
Repo evidence |
What it covers |
|---|---|---|
One-step action delay |
Manager action term |
Executes the previous action instead of the current action. |
Observation history |
Per-term |
Per-term history for selected observation terms. |
Obs history ordering |
|
Per-term oldest-first flatten for actor observations. |
Action Latency¶
For Manager-Based tasks that enable action latency, the action manager applies the previous action when the flag is enabled. Keep this in the selected task owner YAML instead of adding deploy-only behavior later.
env:
actions:
joint_pos:
simulate_action_latency: true
Observation Lag And History¶
Observation width is the sum of dim * history_length over the declared actor
terms, not something a hardware runtime may guess. Terms carrying
history_length are flattened oldest-first within each term while other terms
stay single-step.
Do not lag command/reference terms unless the training owner did so.
Deploy-Side Measurements¶
Record these per policy tick in the hardware runtime:
policy_input_timestampsource timestamps for each sensor or estimator channel
policy_output_timestampactuator command send timestamp
the action vector before and after clamp / smoothing
Compare the observation vector against a sim rollout built from the same task owner YAML. If the measured pipeline needs filtering or buffering, encode the matching behavior in the task owner and retrain, rather than adding it only on the deploy side.
Symptoms Of Mismatch¶
Contact oscillation after enabling torque.
Action saturation during the first few policy ticks.
Velocity tracking drift even when the ONNX input width and observation layout match.
See also¶
src/unilab/managers/event_manager.py