Quality of Service is the set of policies that tune how ROS 2 delivers each message stream — reliable or best-effort, latched or not — and the number-one reason a running publisher and subscriber sometimes exchange nothing at all.
Quality of Service is a set of dials on each ROS 2 data stream that control how it's delivered — guaranteed like a TCP download, or fast-and-lossy like live video. If a publisher and subscriber set these dials differently, they may never connect.
🎯 Quick challenge
A common cause of "publisher and subscriber both running but no messages" in ROS 2 is…
Here's a ROS 2 mystery that stumps nearly every beginner: the publisher is running, the subscriber is running, ros2 topic list shows the topic — and no messages arrive. The culprit is almost always Quality of Service.
What it is
Because ROS 2 runs on DDS, every topic has a QoS profile — a set of policies controlling how messages are delivered. A publisher and a subscriber only connect if their profiles are compatible. Mismatch them and DDS quietly refuses to link them, with no error and no data.
Profiles must match to connect
QoS is negotiated per connection. If reliability or durability don't line up, the link never forms — the silent failure that trips up newcomers.
The policies that matter
Reliability — RELIABLE (retransmit until delivered, like TCP) vs BEST_EFFORT (fire and forget, like UDP). A best-effort publisher won't match a reliable subscriber. Sensor streams use best-effort; commands use reliable.
Durability — VOLATILE (only future messages) vs TRANSIENT_LOCAL (latch the last message so late-joining subscribers still receive it). This is how /map and /tf_static reach nodes that start afterward.
History & depth — KEEP_LAST with a queue size N, or KEEP_ALL — your buffer against bursts.
Deadline & Liveliness — contracts that let a node detect "I've stopped hearing from this publisher," the basis of failure detection.
Doing it right
The practical advice: don't hand-roll QoS. ROS 2 ships presets — SensorDataQoS() (best-effort, shallow queue) for high-rate sensor feeds, SystemDefaultsQoS() and reliable defaults for commands and services. Match a subscriber's QoS to the publisher it's reading. When debugging a dead topic, checking QoS compatibility should be the very first step.
Why it matters
QoS is the price and the power of ROS 2's DDS foundation — it lets a robot prioritize a safety command over a dropped video frame, but it also introduces the most common "why is nothing working?" trap. Understanding it is essential to building reliable ROS 2 systems.
