A ROS 2 topic can exist and still deliver nothing

Separate discovery from delivery

Finding a topic establishes that the graph can report it. It does not prove that a particular subscriber receives samples, runs its callback or uses the result. Write down which of those observations is actually missing.

Inspect the topic's full name, message type and each endpoint's effective QoS profile. The ROS 2 topic-information tool offers verbose endpoint details; compare the running system with the intended configuration. Keep the ROS distribution and middleware implementation in the test record, because defaults and available behaviour may differ.

Also check whether the publisher is producing messages now. A discovered but idle publisher is a different case from an active publisher that cannot match a subscriber. Choose a controlled stream with a sequence field so progress is visible without relying on the payload changing.

Sources: [2]

Read reliability in the right direction

ROS 2 uses an offered-versus-requested compatibility model. The publisher offers behaviour; the subscriber requests what it will accept. The settings need to be compatible, which does not always mean identical.

For reliability, a best-effort publisher cannot satisfy a subscriber requesting reliable delivery. A reliable publisher can match a subscriber accepting best effort. Treat the following table as a check of reliability alone.

Every other policy affecting compatibility must also pass. For example, changing reliability will not repair an incompatible durability requirement. A single green cell is not an end-to-end communication test.

Sources: [1]

Choose the policy from the data's purpose

A live visualisation may value the newest sensor sample more than recovering every missed sample. ROS 2's sensor-data profile reflects that trade-off with best-effort reliability and a smaller queue. That makes it a candidate for some sensor streams, not a universal setting for every topic.

A retained configuration or map has a different use: a late subscriber may need previously published state. Humble documents transient-local durability for this purpose, with compatible publisher and subscriber settings. A volatile subscriber matched to a transient-local publisher receives new messages, without the same historical-data behaviour.

Write the consumer's requirement first: acceptable age, whether loss is tolerable, whether historical samples are useful, and what happens after a restart. Commands with side effects need their own application semantics. A transport setting cannot decide whether replaying a command is appropriate.

Sources: [1]

Check the observer as well as the application

A command-line echo or frequency tool creates another subscriber. Its behaviour is evidence about that observer, not automatically about the application you are diagnosing. Compare its QoS with the target subscriber before interpreting a successful echo as proof that the application must work.

The Humble topic tutorial notes that reported frequency is the tool's received rate and can be affected by resources and QoS. If the tool sees 20 Hz while the application misses callbacks, inspect the application's own reception and callback timing.

Track acquisition, reception and callback execution separately where possible. Once messages are arriving, investigate executor load, callback duration and queue behaviour. Increasing queue depth without measuring age can hide overload behind a growing backlog.

Sources: [2]

Make the mismatch reproducible

Use a simulation or isolated test namespace with no connection to actuators. Create a known best-effort publisher and a reliable subscriber, keeping the remaining policies compatible. Predict no matching delivery. Then change only the subscriber's reliability to best effort and check that samples arrive.

Repeat with a reliable publisher and each subscriber reliability setting. Record matching events, received sequence numbers and timestamps. The compatibility table predicts which pairs may connect; it does not promise zero loss or bounded latency under every runtime condition.

Next, test late joining and restart behaviour separately from the reliability matrix. Confirm whether historical samples should appear and whether the first usable observation meets the consumer's age requirement. Use incompatible-QoS event callbacks where the selected implementation supports them.

Keep the smallest failing configuration and the corrected one together. The useful result is a demonstrable interface contract: which endpoint offers what, which endpoint accepts it, and what the application actually receives.

Sources: [1]