Engineering resource
ROS 2 Sensor-to-Actuator Latency Budget Calculator
Allocate a ROS 2 timing path across sampling, transport, inference and actuation. Compare stage observations with your budget and export a CSV.
A controller can run at its configured rate while acting on old observations. Build a timing budget from the event or acquisition timestamp to the physical response, including the time spent waiting between components. Use the calculator to record allocations and identify assumptions that still need evidence.
This tool accompanies the sensor-to-actuator timing-budget guide. All initial values are illustrative allocations. They are not Jetson measurements, ROS 2 performance claims or recommended limits for a particular robot.
Define what your clock starts measuring
When the path starts at a physical event, a periodically sampling sensor may wait up to one sample period before acquisition begins, assuming it does not skip a sample. Enable the sampling allowance for that case. If your path starts at the acquisition timestamp, disable it and account for exposure, readout and driver delay in the first stage.
Enter an upper-bound allocation for each sequential stage. Each duration must appear only once. For a system with parallel branches, build a budget for each required path and analyze their synchronization separately. Summing overlapping spans would count time twice.
Build the timing budget
Interpret the result as a design record
The default calculation is 1000/30 + (3+2+12+1+2+4) + 2 + 10 = 69.33 ms. The 10.67 ms headroom is the part of the deadline not yet allocated. A non-negative result establishes arithmetic consistency for the supplied assumptions; it does not prove that the implementation meets them.
Optional observations let you compare each stage against its allocation. A sample maximum is evidence about the captured workload, not a worst-case execution-time guarantee. The sum of separate stage maxima is also not the maximum observed end-to-end duration. Preserve synchronized end-to-end traces to make that claim.
The ROS 2 real-time systems introduction explains why timing requirements need bounded behavior rather than low average latency. Add scheduling, blocking and resource contention to the investigation when an allocation is exceeded.
Keep freshness and command validity separate
The calculator does not configure middleware or reject stale commands. Define the observation-age and command-age rules at their consuming boundaries, and specify the response to missed deadlines or lost communication. Use ROS 2 clock domains to establish timestamp meaning and clock conversion, and command validation for admission to the actuator-facing path.
The CSV export is generated in your browser. It records allocations, optional observations, allowances and headroom; the entered timing values are not included in analytics events. Retain the hardware/software configuration, workload and trace location alongside it. Continue with Robotics Architecture & Safety or Jetson & ROS 2 Engineering for the wider architecture.