Using the correct QoS profile to subscribe to an existing topic

[deb0ch]

We stumbled upon this issue when implementing for Turtlebot3 a node that subscribes to its lidar.

We would just get nothing when subscribing using the default parameters: no data, no error. Nothing. ros2 topic echo /scan was displaying LaserScans alright.

The choosing of the correct QoS setting is not documented anywhere obvious (if not anywhere ?). It does not appear in any of the tutorials, and moreover I found online no copy/paste code example setting one other than the default, like sensor_data. We found out about QoS settings and their inter-compatibility by following Github issue trackers.

I believe this could be documented better so I'm opening this issue for reference.

[kscottz]

Good catch and thanks for submitting an issue. Let me get a handle on the documentation situation and we'll see what we can get done.

As a short term band-aid I can point you to this ROSCon talk and slides that should help elucidate things a bit. Perhaps @emersonknapp might be willing to write this considering he already has a body of work around it.

[emersonknapp]

A really excellent feature for the cli would be auto-qos (we're working on it for rosbag2 because this issue is equally confusing for users there) - I doubt at this point that we'd be able to get that in for Foxy though.

Something I could do in the short term to at least educate users would be to update https://index.ros.org/doc/ros2/Concepts/About-Quality-of-Service-Settings/ - @kscottz do you think that'd be the best place to update this information?

I was thinking -

• restructure the Overview a bit
• add the 3 new policies introduced in Dashing
• explain usage from the CLI tools

[kscottz]

@emersonknapp thanks for the update. That seems like a reasonable approach but I defer to @maryaB-osr opinion. If we're not going to have this directly fixed by foxy it might be worth noting the issue experienced above so google searches might direct people to the right place and the TL;DR on how to fix it.

[emersonknapp]

It's not a fix as much as an upgrade that would clear up confusion.

If the user does the following they'll successfully see the messages:

ros2 topic echo --qos-profile sensor_data /scan

This will be the most common case for the beginning ROS 2 user, is that the rmw_qos_profile_sensor_data is not compatible to Subscriptions that request the default qos (e.g. they do not specify).

[maryaB-osr]

@kscottz @emersonknapp All sounds good to me, please feel free to proceed. Thanks!

[ros-discourse]

This issue has been mentioned on ROS Discourse. There might be relevant details there:

https://discourse.ros.org/t/using-text-programming-robots-with-ros-advice/13262/9

[miguelvelezmj25]

What should be the quality of service to listen to /scan messages? That is, what should I put for qos in node.create_subscription(LaserScan, 'scan', chatter_callback, qos)

[emersonknapp]

If your subscription requests

rclcpp::QoS(rclcpp::KeepLast(n)).best_effort().durability_volatile()

It will be universally compatible with any publisher, even if you don't know what the publisher is offering - so that's always a safe choice.

Using that does mean that you won't receive reliable Reliability even if the publisher could provide it, however the SensorDataQoS preset offers best_effort, and it's likely your scan publisher is using that preset. For a more precise choice, you need to know what the Publisher is offering. I don't think the feature that prints that info was added into Eloquent, so it'll be easier to use in Foxy, where ros2 topic info tells you what QoS the publishers offer.

[emersonknapp]

Oh and as a heads up on the Wiki page, it's still on my plate to have it fully up to date in time for the Foxy release, so that means I'll be opening up the PR within the next week or two.

[ros-discourse]

This issue has been mentioned on ROS Discourse. There might be relevant details there:

https://discourse.ros.org/t/looking-for-a-consultant-experienced-in-ros2-docker-and-data-throughput-issues/19884/4