A ROS 2 LiDAR topic can exist while a subscriber receives no measurements. Topic discovery and endpoint compatibility are separate checks. Before blaming the sensor, inspect the publisher’s offered QoS and the subscriber’s requested QoS, then test reception with a small, deliberately compatible consumer.
This guide focuses on a silent subscriber, rather than physical wiring, map accuracy or recording completeness. It is useful when one visualization or test tool receives data but another does not. The 2D LiDAR ROS 2 setup guide covers the broader bring-up process; here the question is whether two specific endpoints can exchange the intended messages.
Start with a stationary robot and a short diagnostic session. Save the topic name, message type, ROS distribution, driver revision and middleware implementation. Preserve the current settings before editing a launch file or subscription. A small recorded change is easier to assess than several guessed policy changes made at once.
Identify the exact endpoints
Use the resolved topic, not a name remembered from a sample configuration. A namespace, remapping rule or separate launch instance may change the actual name. The official ROS 2 topic tutorial documents inspection of topic types and endpoints. For a Jazzy installation, the following is a useful starting point:
ros2 topic list -t
ros2 topic info /scan --verbose
ros2 topic hz /scanReplace /scan with the actual topic. Record each publisher and subscriber separately. If several publishers use the same name, avoid assuming their policies are identical. Likewise, two subscribers can behave differently without any sensor change, because they may request different policies or process the stream differently.
Confirm the message type as well as the endpoint policies. The PointCloud2 definition describes a binary point-cloud layout. A consumer written for a planar scan or a custom packet message will not become a compatible point-cloud consumer merely because you assign it the same topic name.
Use the reliability compatibility matrix
The official QoS guide describes a request-versus-offer model. A best-effort publisher cannot satisfy a reliable subscription. A reliable publisher can connect to either reliability choice. Other compatibility policies must also match, so a passing reliability check is only one part of the investigation.
| Publisher offers | Subscriber requests | Reliability compatible? |
|---|---|---|
| Best effort | Best effort | Yes |
| Best effort | Reliable | No |
| Reliable | Best effort | Yes |
| Reliable | Reliable | Yes |
Write the observed pair in your test notes before changing it. If the publisher offers best effort and your consumer requests reliable, change the test consumer to a compatible request and repeat the short test. Do not immediately modify the driver that another working consumer already uses. Keep the change bounded to the endpoint you are investigating.
Check durability separately
A volatile publisher cannot satisfy a subscription requesting transient-local durability. A volatile subscription can receive new messages from a compatible transient-local publisher; receiving retained history requires the appropriate configuration on both sides. These rules are also in the QoS guide. Record durability alongside reliability rather than treating one as shorthand for the entire profile.
For a continuously updating sensor stream, ask what the application actually needs at startup. A current measurement, a retained historical sample and a configuration message serve different purposes. Review the producer’s documented behavior and the consumer’s requirements. Copying a profile from a different topic can create a connection problem that looks like hardware failure.
If the pair still fails after a compatibility correction, capture the full endpoint details and warnings. Deadline and liveliness settings may also matter in the deployment. Avoid turning every policy into a system default without documenting the result: that makes a successful test harder to reproduce on a different middleware or host.
Understand what a sensor-data profile actually requests
The Jazzy rclcpp QoS declarations document the sensor-data profile’s history, depth, reliability and durability choices. Inspect the installed version and the driver implementation instead of assuming all sensor publishers use it. A profile name is useful context; observed endpoint settings are stronger evidence for the connection you are testing.
The corresponding middleware QoS profile definitions provide the implementation-level baseline. Keep the source version with your evidence. The word “reliable” describes a transport policy, not a certification that the sensor, callbacks, application buffers and stored dataset preserve every measurement end to end.
Choose policy behavior around the consumer’s purpose. A live obstacle display and an offline evaluation recorder may have different priorities. Document the reason for the selected request and test it under the intended workload. Increasing queue depth is not a repair for incompatible endpoint policies, and a deeper queue should not be assumed to solve unrelated callback or host-load problems.
Test one minimal consumer before the full pipeline
Create a small reception test that uses the actual message type and explicitly records its requested policies. Observe whether callbacks occur and save a sample header when they do. Then compare that result with the failing application. A successful small consumer narrows the investigation; it does not prove the complete navigation or perception pipeline is correct.
Bring back one downstream component at a time. Check that a visualization uses the intended topic and frame. If messages are received but drawing fails, investigate transforms and timestamps rather than changing a compatible QoS pair. The ROS point-cloud tutorial helps separate reception from visualization.
If recording is the affected consumer, treat the recorder as another endpoint. The rosbag2 override guide documents topic-specific policy overrides for recording and playback. Verify the saved bag separately; a compatibility fix cannot reconstruct messages that were never stored.
Keep the fix reproducible
Save the original and revised endpoint policies, the exact launch or configuration change and the test result. Include one test with the expected working consumer and one with the formerly silent consumer. State whether the correction changed reliability, durability, topic selection or something else. Avoid a report that simply says “changed QoS and it worked.”
Repeat the test after restarting the application. Where deployment configuration is persistent, confirm it survives the normal reboot and startup sequence. Also repeat under the intended host workload. The result should demonstrate the connection and behavior you actually require, not only a successful moment on an idle development laptop.
For a robotics LiDAR project, retain these checks with the sensor and software acceptance records. The ROS 2 buying checklist provides requirements to confirm before committing to an integration. When asking LidarStar about driver requirements, provide the actual endpoints and revisions so the question can be evaluated without guessing.
Frequently asked questions
Does seeing a topic name prove that my subscriber receives it?
No. Verify endpoint compatibility and actual reception with the intended consumer.
Should every LiDAR subscriber request reliable delivery?
The request must be compatible with the producer and appropriate to the application. Inspect the offered policy before deciding.
Will a larger queue connect incompatible endpoints?
No. Correct the incompatible policies first, then assess buffering and processing behavior separately.
Why can RViz work while my own node is silent?
Compare their resolved topics, types and requested profiles. Two consumers can make different requests against the same publisher.
Does a successful compatibility test qualify navigation performance?
No. It establishes a bounded communication result. Timing, valid measurements, mounting, transforms and downstream behavior still require application-specific validation.
