ROS 2 Quality of Service is a set of delivery and timing policies negotiated between publishers and subscriptions. The useful profile depends on what the data means when it is missing, late, duplicated or stale. Selecting Reliable for every topic can increase queueing without making robot behavior safe.
Continuous camera or lidar samples often favor freshness and bounded queues, while configuration state may need delivery to late joiners. A robot command needs acknowledgement, validity and timeout semantics beyond transport reliability. Separate the application contract from the DDS mechanism that carries it.
Read this with the ROS 2 real-time control guide and ROS 2 DDS security guide. Test the selected profile on the actual ROS distribution, RMW implementation, network and executor configuration.
Choose from the consequence of stale or missing data
For every topic, state the production rate, maximum useful age, acceptable loss, whether a late subscriber needs previous data and what the consumer should do when updates stop. These requirements are clearer than starting from a predefined sensor-data or services profile.
A lost image may be harmless if the next frame arrives promptly. A delayed velocity command can be dangerous if it remains valid after the operator releases the control. A missing map revision may leave the robot inconsistent. Design the application response before choosing transport settings.
Understand QoS as a policy bundle
Reliability controls whether delivery is retried. History and depth control retained samples. Durability controls whether stored samples can reach a late joiner. Deadline, lifespan and liveliness expose different timing or endpoint conditions. One profile is the combination of these choices and their durations.
Defaults can vary by ROS API, profile and middleware. Record effective endpoint policies at runtime rather than trusting a YAML file alone. The current ROS 2 QoS concepts documentation describes policy semantics and requested-versus-offered compatibility.
| Policy | Question answered | Common risk | Evidence |
|---|---|---|---|
| Reliability | Retry or permit loss? | Backlog under loss | Delivered and aged samples |
| History and depth | How many samples wait? | Queue latency | Depth and callback age |
| Durability | Do late joiners get stored data? | Stale transient state | Restart behavior |
| Deadline or lifespan | When is timing invalid? | Silent stale use | Events and rejection |
| Liveliness | Is the writer considered alive? | False health inference | Lease and application heartbeat |
Compatibility follows requested and offered policies
A publisher offers a level of service and a subscription requests one. Some combinations communicate and others do not. Reliability is directional: a reliable publisher can satisfy a best-effort request, while a best-effort publisher cannot satisfy a reliable request. Durability has a similar requested-versus-offered relationship.
Discovery does not guarantee useful exchange. Compare topic name, type, domain, namespace, security permissions and every relevant QoS policy. Use endpoint-info tools to inspect both sides. Treat a compatibility warning as evidence, but confirm actual data flow and timing.
Reliable delivery can trade freshness for completion
Reliable transport retries lost data according to middleware behavior and resource limits. On a congested or lossy link, retries and a slow reader can delay newer samples. The robot may receive every retained message yet act on observations that are no longer current.
Measure source timestamp, receive time and consumption time. Bound the queue and define whether old samples should be discarded. Reliable can be appropriate for events, state transitions or low-rate commands, but it does not provide an end-to-end acknowledgement that a robot executed the intended action.
Best effort can be correct for continuous sensors
Best Effort avoids retransmission and can preserve flow when a new sample will soon replace a lost one. It is often useful for high-rate cameras, lidar and telemetry over constrained links. The choice is still task dependent: a low-rate safety-relevant measurement cannot be dismissed as just a sensor topic.
Use a small Keep Last depth when only the newest state matters, and verify that callbacks keep pace. Detect dropped sequences and excessive age so degraded data is visible. A smooth visualization does not prove that the estimator received the required temporal pattern.
| Data class | Starting profile | Application rule | Stress test |
|---|---|---|---|
| High-rate camera | Best Effort, small depth | Use newest valid frame | Loss and bandwidth pressure |
| Robot state estimate | Task-specific reliability | Reject excessive age | Slow consumer and CPU load |
| Discrete mode change | Reliable | Confirm applied state | Restart and duplicate delivery |
| Velocity command | Reliable or Best Effort by design | Short validity plus watchdog | Link loss and delayed packets |
| Static configuration | Reliable plus transient local if needed | Version and validate | Late joiner and replacement |
Robot commands need validity and acknowledgement
Transport reliability only indicates middleware delivery behavior. It does not prove that the receiving controller accepted, applied or completed a command. Include command identity, creation time, validity interval, operating mode and any required sequence or epoch in the application protocol.
For streaming commands, use a receiver-side watchdog that moves to a defined state when fresh valid input stops. For goals or transactions, return explicit acceptance, progress and completion. After reconnection, reject commands from an earlier session rather than replaying a retained queue.
History and depth can create hidden latency
Keep Last with depth N retains a bounded number of samples. Keep All attempts to retain every sample within resource limits. If the consumer is slower than the publisher, a deep queue can transform compute overload into steadily increasing data age instead of an obvious drop.
Plot queue occupancy and age at callback start. Test with blocked callbacks, CPU contention and bursty publishers. If every sample must be processed, size resources and backpressure explicitly; if only the latest state matters, drain or overwrite old work instead of pretending depth solves throughput.
Durability defines restart and late-joiner behavior
Transient Local durability lets a writer retain samples for compatible late subscribers while the writer remains available. This can suit maps, calibration state or a latched configuration. It can also deliver obsolete information after a process restart if versioning and lifecycle semantics are weak.
Test publisher-before-subscriber and subscriber-before-publisher order, writer restart, reader restart and configuration replacement. Attach a version, timestamp and validity domain to retained state. Do not use durability as a substitute for a persistent source of truth when recovery across host failure is required.
Timing policies expose different failures
Deadline describes the expected interval between samples and can produce events when the contract is missed. Lifespan limits how long a sample remains eligible for delivery. Liveliness tracks whether a publisher is considered alive under the selected lease and assertion model. None automatically defines a safe robot reaction.
Connect each event to application logic and observability. A deadline miss may request degraded operation, while command expiration may force a stop. A living process can publish invalid data, so combine middleware events with range checks, timestamps and an application heartbeat where needed.
Tune transport only after confirming semantics
DDS implementations expose transport, discovery, socket and memory settings that affect behavior. The ROS 2 DDS tuning guide covers platform considerations, but vendor knobs cannot repair an incompatible profile or a callback that takes longer than the publication period.
First establish endpoint compatibility and application age limits. Then capture packet loss, retransmission, queue occupancy, callback scheduling and CPU load on one timeline. Change one layer at a time and retain the exact RMW, DDS vendor and configuration in the test record.
Recording and playback need their own QoS plan
A recorder is another subscription and must be compatible with publishers. Playback becomes another publisher whose profile must match readers. A bag can contain messages yet fail to reproduce transient state, deadlines or the exact delivery pattern seen during the original run.
Inspect recorded metadata, override profiles where justified and test the target replay topology. The rosbag2 source and documentation should be read for the deployed branch. Record source timestamps and configuration so offline evaluation does not confuse replay timing with physical timing.
Validate with controlled failure injection
Test nominal load, packet loss, delay, reordering, bandwidth pressure, a slow subscription, a blocked executor, publisher restart, subscriber restart and disappearing endpoints. Measure received sequence, sample age, queue depth, deadline events, liveliness events and robot response.
Publish a topic contract beside the interface definition. It should make a deployment reproducible and prevent a future node from silently changing communication behavior.
- Document rates, age limits and loss tolerance.
- Record effective publisher and subscription policies.
- Measure sample age rather than delivery count alone.
- Test network, executor and restart failures.
- Version QoS with the topic's application semantics.
Frequently asked questions
Should every sensor topic use Best Effort?
No. The correct policy depends on sample rate, replacement behavior, loss tolerance and the consequence of missing data.
Does Reliable guarantee that a command executes?
No. It concerns middleware delivery. The application needs acceptance, validity, watchdog and completion semantics.
Will different reliability settings always prevent connection?
No. Compatibility is directional: a reliable offer can satisfy a best-effort request, but a best-effort offer cannot satisfy a reliable request.
Does a larger queue depth prevent data loss?
It may retain more samples, but it can also increase latency and exhaust resources when the consumer is slow.
Why is a topic late even when QoS is compatible?
Transport congestion, callback scheduling, locks, CPU load, serialization and deep queues can delay consumption after compatibility is established.
QoS Behavior and Safety Boundary
QoS behavior depends on ROS distribution, RMW implementation, DDS vendor, operating system, network and executor design. Validate the complete application; middleware settings alone are not a safety function.