Glossary

Fictionlab > Glossary > QoS (Quality of Service)

QoS (Quality of Service)

QoS (Quality of Service) – definition

Quality of Service (QoS) is a set of communication policies that defines how ROS 2 nodes exchange data through the underlying middleware, typically a Data Distribution Service (DDS) implementation. QoS controls delivery guarantees, queue behaviour, message persistence, timing expectations, and publisher liveness.

In mobile robotics, QoS determines whether a UGV receives sensor measurements, velocity commands, localisation data, maps, and safety-relevant status messages in a usable form. It does not improve perception, localisation, or network bandwidth by itself. It defines how the middleware behaves when messages are delayed, dropped, produced faster than they are consumed, or when nodes join the system after a publisher has started.

ROS 2 QoS is based on the OMG DDS specification. ROS 2 client libraries expose DDS QoS policies through APIs such as rclcpp::QoS, rclpy.qos.QoSProfile, and predefined profiles including sensor-data and service profiles. Source: ROS 2 Quality of Service settings documentation and OMG Data Distribution Service specification.

Why QoS matters on mobile UGV platforms

A mobile robot usually publishes data streams with different technical requirements. A LiDAR scan can be large and frequent, while a command velocity message is small but time-sensitive. Applying one QoS profile to every topic can cause incompatible endpoints, queue growth, stale commands, or unnecessary retransmissions.

On Leo Rover and Raph Rover, QoS must be selected for the transport path between onboard compute, external sensors, remote workstations, and ROS 2 nodes. Leo Rover commonly uses an onboard Raspberry Pi compute unit, so excessive reliable traffic or oversized queues can consume CPU time, memory, and wireless bandwidth. Raph Rover may carry larger sensor payloads and additional compute hardware, but its ROS 2 network still requires compatible publisher and subscriber QoS profiles.

UGV data type Typical ROS 2 topic Common QoS direction Reason
LiDAR or depth data /scan, /points Best effort, keep last New measurements are usually more useful than retransmitted old measurements.
Wheel odometry and IMU /odom, /imu/data Best effort or reliable, keep last The choice depends on link quality and estimator requirements.
Velocity command /cmd_vel Reliable, shallow history, short lifespan where supported Commands should arrive, but stale commands must not remain actionable.
Static map or configuration /map, /robot_description Reliable, transient local Late-joining nodes may need the most recently published state.

Core ROS 2 QoS policies

A QoS profile is composed of individual policies. ROS 2 publishers offer a profile and subscriptions request one. Communication starts only when the requested profile is compatible with the offered profile.

  • History defines whether DDS stores the last N samples (KEEP_LAST) or attempts to retain all samples (KEEP_ALL), subject to middleware resource limits.
  • Depth is the queue size used with KEEP_LAST. A depth of 10 retains up to 10 unread samples per applicable queue.
  • Reliability is RELIABLE or BEST_EFFORT. Reliable delivery requests retransmission of lost samples. Best-effort delivery does not.
  • Durability is VOLATILE or TRANSIENT_LOCAL. Transient-local publishers retain samples for late-joining compatible subscribers.
  • Deadline defines the maximum expected interval between samples. Missing the interval can trigger a deadline event. It is not a latency guarantee.
  • Lifespan defines how long a sample remains valid after publication. Expired samples are not delivered.
  • Liveliness defines how a publisher asserts that it is alive, with an associated lease duration.

ROS 2 documentation defines the default profile as reliable reliability, volatile durability, keep-last history, and depth 10. The predefined sensor-data profile uses best-effort reliability, volatile durability, keep-last history, and depth 5. Source: ROS 2 QoS settings.

QoS compatibility rules

DDS applies a request-versus-offered model. The subscriber requests a minimum quality level, while the publisher offers a level. The publisher must satisfy the subscriber request for endpoints to match.

For reliability, a reliable publisher can communicate with both reliable and best-effort subscribers. A best-effort publisher cannot satisfy a reliable subscriber. For durability, a transient-local publisher can satisfy a volatile subscriber, while a volatile publisher cannot satisfy a transient-local subscriber. Incompatible QoS often appears as a ROS 2 warning stating that no messages will be received.

ros2 topic info /scan --verbose
ros2 topic echo /scan --qos-reliability best_effort
ros2 topic echo /map --qos-durability transient_local

The first command displays publishers, subscriptions, message type, and endpoint QoS information. It should be used when a node discovers a topic but receives no messages.

QoS configuration for sensor and navigation stacks

A ROS 2 navigation stack on Leo Rover or Raph Rover can include a LiDAR driver, IMU driver, wheel odometry source, robot localisation filter, SLAM node, and Nav2 nodes. QoS must be checked across each connection, not only at the sensor driver.

The following YAML fragment illustrates a sensor-oriented subscription profile. It is appropriate when a consumer can tolerate dropped frames and should process the latest available measurement.

scan_subscription:
  history: keep_last
  depth: 5
  reliability: best_effort
  durability: volatile

For example, a LiDAR driver may publish sensor_msgs/msg/LaserScan on /scan with best-effort QoS. A SLAM or navigation node configured to require reliable delivery will not connect to that publisher. The correct solution is normally to configure compatible QoS, not to assume that topic names alone establish communication.

Reliable transport is not automatically preferable for wireless UGV operation. On a lossy Wi-Fi link, retransmissions can increase delay and consume bandwidth. Best-effort delivery can be more suitable for high-rate perception streams where the next scan supersedes a missing scan. Command, state-transition, and configuration channels require separate engineering decisions based on failure handling and acceptable staleness.

ROS 1 and ROS 2 differences

ROS 1 used transport-specific mechanisms such as TCPROS and UDPROS. It did not expose the DDS-style QoS policy model used by ROS 2. ROS 1 queue sizes controlled local buffering, but they did not provide the ROS 2 reliability, durability, deadline, lifespan, or liveliness policy set.

When using ROS 2 distributions such as Humble on Leo Rover, communication is typically DDS-based through a selected ROS middleware implementation. Exact defaults and available middleware behaviour should be verified against the ROS 2 distribution documentation and the selected RMW implementation. Source: ROS 2 Humble QoS documentation.

See also