ROS 2 Quality of Service (QoS)

The Reliability policy determines whether the middleware guarantees message delivery. It offers two settings:

• RELIABLE: Ensures all messages are delivered, using retransmission protocols similar to TCP. This is critical for command and control or safety-critical data but adds latency and overhead.
• BEST_EFFORT: Attempts to deliver messages but may drop them under network congestion or overload, similar to UDP. This is suitable for high-frequency sensor data (e.g., camera images) where occasional loss is acceptable to maintain low latency and high throughput. Mismatched reliability policies between a publisher and subscriber will prevent them from connecting.

The Durability policy controls whether messages are stored for late-joining subscribers. Its two modes are:

• VOLATILE: Messages are not retained. A subscriber joining after a message is published will never receive it. This is the default and minimizes memory usage.
• TRANSIENT_LOCAL: The publisher maintains a history of messages (depth configurable by the History policy). A new subscriber will receive the last N messages in the history upon connection. This is essential for state data, like a robot's current transform or operational mode, where a new node needs the latest known value immediately. For example, a transform broadcaster would use TRANSIENT_LOCAL durability so a newly launched navigation node instantly knows the robot's position.

The Deadline policy defines the maximum expected period between successive messages on a topic. It is specified as a duration (e.g., 100ms).

• The publisher promises to send messages at least this frequently.
• The subscriber expects to receive messages at least this frequently. If the deadline is violated (a message is late), a callback is triggered in both the publisher and subscriber, allowing the system to take corrective action, such as logging a warning or entering a safe state. This policy is fundamental for building real-time systems where timing guarantees are required, enabling detection of stalled sensor streams or slow control loops.

The Liveliness policy provides a mechanism to detect if a publishing node has failed or become unresponsive. It has two components:

• Liveliness Lease Duration: The maximum time a publisher can go without asserting its liveliness.
• Liveliness Kind: AUTOMATIC (asserted by the library on publication) or MANUAL_BY_TOPIC (must be manually asserted by the node). If a publisher fails to assert its liveliness within the lease duration, it is considered "not alive," and all its connections are severed. Subscribers are notified of this change in liveliness status. This is crucial for system health monitoring, ensuring that a failed perception node does not cause a planner to operate on dangerously stale data.

The History policy dictates how messages are stored in the queue when the processing node cannot keep up. It works in tandem with a Depth value.

• KEEP_LAST: Maintains a circular buffer of the last N messages (where N is the depth). When the queue is full, the oldest message is discarded to make room for the new one.
• KEEP_ALL: Attempts to store all messages until they are processed. This can lead to unbounded memory growth if the subscriber is slower than the publisher. The Depth setting is critical for managing resource usage. For a high-frequency LiDAR topic, a small depth (e.g., 1-5) with KEEP_LAST ensures the system always processes the most recent scan, dropping older ones to prevent backlog and latency spikes.

ROS 2 provides predefined QoS Profiles that bundle policies for common use cases, simplifying configuration.

• SENSOR_DATA: Uses BEST_EFFORT reliability, VOLATILE durability, and a small KEEP_LAST history depth. Optimized for high-bandwidth, loss-tolerant streams like camera images or point clouds.
• SERVICES_DEFAULT: Uses RELIABLE reliability and VOLATILE durability. The standard profile for request-response services where every message must be delivered.
• PARAMETER_EVENTS: Uses RELIABLE reliability and VOLATILE durability. Ensures parameter update notifications are reliably delivered.
• SYSTEM_DEFAULT: The baseline profile, typically RELIABLE and VOLATILE. Developers can create custom profiles to match specific subsystem requirements, such as a CONTROL profile with strict deadlines and transient-local durability for actuator commands.

A ROS Topic is a named bus over which nodes exchange asynchronous, many-to-many messages using a publish-subscribe communication model. It is the primary channel where QoS policies are applied.

• Publish-Subscribe Pattern: Publishers send messages to a topic; subscribers receive messages from that topic.
• Asynchronous Communication: Publishers and subscribers operate independently.
• QoS Binding: When a publisher or subscriber is created, it must specify a QoS profile. Communication only occurs between entities whose QoS profiles are compatible (e.g., a RELIABLE publisher cannot send data to a BEST_EFFORT subscriber if durability settings mismatch).

A ROS 2 Executor is a processing engine within a node that manages the execution of subscriptions, service servers, timers, and action servers. It works in tandem with QoS to manage how incoming data is processed.

• Callback Scheduling: The executor 'spins', checking for new data on subscriptions and invoking the corresponding user-defined callback functions.
• QoS Interaction: The executor's threading model (single-threaded, multi-threaded) affects how it handles messages, especially under deadline or liveliness QoS policies.
• Backpressure Management: With a BEST_EFFORT reliability policy and a slow subscriber, the executor's queue can fill, leading to dropped messages. A RELIABLE policy, combined with proper executor tuning, ensures delivery but may increase latency.

A ROS Message is a strictly typed data structure, defined in a .msg file, that is serialized and deserialized when publishing to topics or calling services. QoS policies govern the transmission of these serialized messages.

• Strict Typing: Messages have defined fields (e.g., std_msgs/Header header, float64 data).
• Serialization: Converted to a binary format for transmission over the network.
• QoS Impact: Policies like deadline define the required frequency of message arrival. The size and complexity of the message type directly impact performance under policies like history (how many messages are kept) and reliability (how they are delivered).

A ROS 2 Lifecycle Node is a managed node that follows a well-defined state machine (Unconfigured, Inactive, Active, Finalized). This management works alongside QoS to ensure predictable system startup and error recovery.

• State Management: Transitions include configure, activate, deactivate, and cleanup.
• QoS Coordination: Publishers/Subscribers within a lifecycle node are typically created during configure and activated during activate. This prevents a node from receiving data (governed by QoS) before it is fully initialized.
• System Robustness: Combined with liveliness QoS, lifecycle states allow the system to detect when a critical component has failed and entered an error state, triggering safe shutdown or recovery procedures.

A ROS 2 Domain ID is a network segmentation integer (set via the ROS_DOMAIN_ID environment variable) that isolates ROS 2 graphs. It is a foundational network-level isolation mechanism, distinct from but complementary to QoS.

• Network Segmentation: Nodes with different Domain IDs cannot discover or communicate with each other, even on the same physical network.
• Use Case: Used to run multiple independent robot systems on the same network without interference.
• Relation to QoS: While Domain ID provides hard isolation, QoS policies manage the quality of communication within a domain. For example, within domain 0, you can have a high-frequency, BEST_EFFORT sensor stream and a low-frequency, RELIABLE command stream coexisting.