Glossary

Fictionlab > Glossary > Latency

Latency

Latency – definition

Latency is the time delay between an event at one point in a robotic system and the corresponding result at another point. In mobile robotics, it is usually measured from sensor acquisition, command publication, or a physical state change to the moment when the relevant data or action becomes available to another component.

For an unmanned ground vehicle (UGV), latency is not a single property. It is the sum of delays introduced by sensors, drivers, middleware, compute nodes, operating-system scheduling, network transport, motor controllers, and actuators. A LiDAR scan may be published late, a ROS 2 subscriber may process it late, or a velocity command may reach the drivetrain late. These cases require different measurements and mitigations.

A simplified end-to-end latency model is:

T_end-to-end =
T_acquisition +
T_sensor_processing +
T_driver +
T_transport +
T_queue +
T_compute +
T_actuator_controller +
T_mechanical_response

Latency is expressed in seconds or milliseconds. It must be distinguished from throughput, update rate, and jitter. A node can publish data at a high frequency while still producing old data. In autonomous navigation, the age of the data used for a decision is often more important than the nominal topic frequency.

Latency in ROS 2 communication

ROS 2 commonly uses a Data Distribution Service (DDS)-based middleware implementation. The observed delay between a publisher and subscriber therefore depends on ROS 2 executor scheduling, middleware configuration, Quality of Service (QoS) policies, serialization, network transport, and subscriber workload. ROS 2 does not define one universal latency value for a topic.

The following timestamps are commonly used when analysing a ROS 2 data path:

Timestamp Meaning Typical source
t_capture Physical sensor measurement time Sensor hardware clock or driver
header.stamp Message timestamp assigned by the driver or processing node Message header, when provided by the message type
t_receive Time at which the subscriber callback begins Application instrumentation
t_command Time at which a motion command is published or sent to a controller geometry_msgs/msg/Twist publisher or motor-controller interface
t_response Time at which wheel motion or odometry confirms a response Motor controller, encoder, or odometry node

If clocks are synchronized, sensor-to-callback latency can be estimated as T = t_receive - t_capture. Without clock synchronization, this calculation can be invalid, particularly when a sensor, an onboard computer, and an external workstation use different clocks.

ROS 2 nodes can obtain time through the ROS time abstraction. A message header.stamp is assigned by the publishing node or driver and may therefore reflect the node’s selected time source. The use_sim_time parameter changes the time source used by nodes and must not be confused with synchronized wall-clock time. Source: ROS 2 documentation, About Time.

Key latency metrics for UGV systems

A useful latency assessment reports both central tendency and variation. Reporting only an average can hide occasional delays that cause navigation failures, stale obstacle data, or oscillatory control behaviour.

The following metrics are appropriate for Leo Rover and Raph Rover integration tests:

  • Mean latency: arithmetic average across a measurement interval.
  • Median latency: robust central value when occasional outliers occur.
  • Maximum latency: highest observed delay during the test.
  • Percentile latency: for example, the 95th or 99th percentile. It shows tail behaviour better than the mean.
  • Jitter: variation in latency between samples. A practical definition is the standard deviation or percentile spread of measured delay.
  • Data age: the elapsed time between measurement and use by a planner, controller, or perception algorithm.

IEEE Std 2700-2017 defines terminology for sensor performance parameters and provides a reference vocabulary for describing sensor characteristics. It should be used together with the relevant manufacturer specification, because a sensor data sheet may define latency at a different point in its internal processing chain. Source: IEEE Std 2700-2017.

QoS, queues, and stale data

QoS settings can affect whether a ROS 2 system prioritizes delivery, availability, or freshness. The reliable reliability policy may retransmit lost samples, while best_effort permits loss. Retransmission can increase delivery delay on an unreliable network. For high-rate sensor streams, an application may prefer a fresh sample over delayed historical samples.

Queue depth is also important. With a keep-last history policy, queued messages can be processed after they are no longer useful for local control. A depth of one limits backlog, but it can discard samples when a subscriber cannot keep up. The correct choice depends on the safety function, sensor rate, processor load, and algorithm requirements.

ROS 2 QoS policies are specified in the ROS 2 documentation. Source: ROS 2 documentation, Quality of Service settings.

# Inspect the type, publishers, subscribers, and offered QoS profiles
ros2 topic info /scan --verbose

# Observe message rate. This measures frequency, not end-to-end latency.
ros2 topic hz /scan

# Display message headers when the publisher provides them
ros2 topic echo /scan --field header

Latency in navigation and perception

SLAM, obstacle avoidance, and local planning depend on consistent timing between LiDAR, IMU, wheel odometry, depth cameras, and transforms. A delayed transform can prevent a node from transforming a scan into the required frame at the scan timestamp. A delayed image can make a detected obstacle appear behind its actual position when the UGV is moving.

ROS coordinate-frame conventions are described by REP 105. Mobile robots commonly use map, odom, and base_link frames. Transform timestamps must represent the time of the associated pose, rather than only the time when a message was published. Source: REP 105 – Coordinate Frames for Mobile Platforms.

For a differential-drive UGV, command latency also affects closed-loop motion. If a controller acts on delayed pose feedback, its effective control loop includes additional phase delay. This can reduce tracking accuracy and may require lower controller gains, a lower maximum speed, or better state estimation.

Latency considerations for Leo Rover and Raph Rover

Leo Rover configurations commonly use an onboard Raspberry Pi compute unit. ROS 2 support and supported distributions depend on the installed Leo Rover software image and integrated hardware. Its compute budget must be shared by drivers, perception nodes, navigation, logging, and system services. High-resolution camera pipelines, point-cloud processing, containerized workloads, and software visualization can increase CPU, memory, storage, and network contention. Leo Rover is not autonomous out of the box, so latency must be evaluated after the selected sensor and navigation stack are integrated.

Raph Rover is intended for larger payloads and can carry more demanding sensor and compute configurations. This does not remove latency constraints. A larger payload may add sensors, network links, and processing stages, making timestamp discipline and end-to-end profiling more important.

For both platforms, measure the complete path from a sensor or command source to the physical effect. For example, measure LiDAR capture to obstacle-costmap update, or /cmd_vel publication to encoder-confirmed wheel response. Testing only ROS topic delivery omits driver, controller, and mechanical delays.

Practical measurement approach

Software timestamps are suitable for profiling ROS 2 nodes, but they may not expose sensor exposure time or actuator response. External instrumentation is required when a physical end-to-end measurement is needed.

  • Record sensor timestamps and receive timestamps in the same clock domain where possible.
  • Use rosbag2 to record relevant topics, including sensor data, /tf, /odom, and /cmd_vel.
  • Monitor CPU load, memory pressure, thermal throttling, packet loss, and Wi-Fi signal quality during tests.
  • Use a hardware trigger, LED, photodiode, oscilloscope, or high-speed camera to validate camera-to-actuator delay.
  • Test under representative terrain, payload, speed, and network conditions.

Repeat measurements after changing ROS 2 distributions, middleware implementations, QoS profiles, kernel settings, sensor drivers, or container configuration. Latency is a property of the integrated system, not of a single component specification.

See also