[ROS2] QOS profile options and subscribing problem

[Myzhar]

I'm testing RQT on ROS2 Crystal Clemmys and I noticed that I cannot subscribe image topics using the rqt_image_view plugin.

The problem is due to QOS settings since I'm not publishing the Image topics using the default values:
https://index.ros.org/doc/ros2/Concepts/About-Quality-of-Service-Settings/#qos-compatibilities

In order for a connection to be made, all of the policies that affect compatibility must be compatible. That is, even if a publisher-subscriber pair has compatible reliability QoS profiles, if they have incompatible durability QoS profiles a connection will not be made, and vice-versa.

I think that each GUI plugin should provide a way to set the QoS setting to be used for each topic that can be subscribed.

[anaelle-sw]

Hi, I encounter the same kind of problem here.

System:
ROS2 Foxy, and running the demo world from gazebo_ros_pkgs gazebo_ros_ray_sensor_demo.world.
(I have also noticed the same issue showing up on Eloquent and Dashing, either with this demo world or with custom sensors.)

Description:
The topics for sensors' feedback (laserscan, range, etc) are available on rqt, and I can suscribe to them via the topic monitor pannel. But no message is received by rqt, while messages are actually published on the topics. This can be checked either with ros2 topic echo command line or on rviz2.
I think this is due to QOS profiles compatibility since, while using rviz2, the topics profiles have to be changed from reliable to best effort in order to visualize the sensors' feedback. So I agree it would be nice to be able to change QOS profiles from rqt GUI.

[good0613]

Hi, I also have same issue.
System:

• ROS2 foxy and with gazebo camera demo world;

gazebo --verbose /opt/ros/foxy/share/gazebo_plugins/worlds/gazebo_ros_camera_demo.world &
rviz2&

Add topic /demo_cam/camera1/image_raw to rviz2 --> no image is displayed.

Description:

• topic is being published with following command;

ros2 topic hz /demo_cam/camera1/image_raw

As @anaelle-sw mentioned, it's same on gazebo_ros_ray_sensor_demo.world; No scan data on rviz2...

Thanks.

[LouisChen1905]

Any idea on how to fix it? @dirk-thomas

[dirk-thomas]

Imo the options are:

• introspecte the graph and use the QoS matching existing endpoints or
• a configuration option to choose the QoS setting per plugin (if a plugin uses multiple topics potentially for each topic separately)

[jacobperron]

FWIW, as of ROS Galactic, there exists a feature to enable configuration QoS with ROS parameters:
https://index.ros.org/doc/ros2/Releases/Release-Galactic-Geochelone/#externally-configure-qos-at-start-up

I suggest we enable this feature for rqt plugins.

[808brick]

Just as an FYI if people are confused, when they are talking about changing the QoS policies in RViz, they mean through the options in the side panel here:

[808brick]

I know Quality of Service can be confusing to some people, so in case you run into an issue of not being able to have your nodes subscribe to Gazebo plugin publishers, you can use the ros2 topic info /topic_name --verbose command to view the QoS configuration of the Publishers and Subscribers of that topic.

To configure QoS properly in Python, for example in a subscriber, you can use the following:

qos_policy = rclpy.qos.QoSProfile(reliability=rclpy.qos.ReliabilityPolicy.BEST_EFFORT,
                                          history=rclpy.qos.HistoryPolicy.KEEP_LAST,
                                          depth=1)
self.sub = self.create_subscription(Image, topic,
                                    self.subscriber_callback, qos_profile=qos_policy)

The above is a subscriber I made to retrieve images from my gazebo simulation using the libgazebo_ros_camera.so plugin.

Hopefully this helps someone else down the line.

[andreasBihlmaier]

This issue still persists today, e.g. with galactic.

When trying to use the most straightforward combination of a Gazebo camera plugin (libgazebo_ros_camera.so) and rqt image view, one will not see the camera images, rather one will get the following message from rqt:

[WARN] [...] [rqt_gui_cpp_node_2726]: New publisher discovered on topic '/camera/image_raw', offering incompatible QoS. No messages will be sent to it. Last incompatible policy: RELIABILITY_QOS_POLICY

I'd consider that there is something broken in the ROS2 ecosystem, if this simple use case doesn't work.
The same goes for rviz. Although it now has QoS parameters (Depth, History, Reliability, Durability) exposed in the UI, it feels wrong for users having to fiddle with them when using default settings everywhere.

Likely two things are required to fix this:

• Agree on the default policy for sensor_msgs/Image and use this everywhere (Gazebo plugins, rviz, rqt)
• Expose QoS parameters everywhere (in UI, in configuration file or through environment parameters)

Edit: Just realized that this effects all rqt plugins, even general-purpose ones such as Topic Monitor ... this is really unpleasant.

[goekce]

FWIW, as of ROS Galactic, there exists a feature to enable configuration QoS with ROS parameters: https://index.ros.org/doc/ros2/Releases/Release-Galactic-Geochelone/#externally-configure-qos-at-start-up

Updated link: https://docs.ros.org/en/foxy/Releases/Release-Galactic-Geochelone.html#externally-configure-qos-at-start-up

I had thought that this feature can be used to change the QoS of every node after startup – I was wrong. As @jacobperron pointed out, it has to be enabled:

I suggest we enable this feature for rqt plugins.

---

I also looked if QoS of libgazebo_ros_camera.so is configurable. It seems to be hardcoded:

https://github.com/ros-simulation/gazebo_ros_pkgs/blob/205755685f77300a27d16c9739b1e397e30811d9/gazebo_plugins/src/gazebo_ros_camera.cpp#L185-L204

---

Another workaround could be to republish the topic with the suitable QoS setting for rqt.

---

I hope that this problem is ultimately resolved by automatically setting the QoS setting of the consumer. As far as I remember this is not wanted by design though and ROS enforces the developer to think about QoS. At least in case of rqt this can be done automatically as @dirk-thomas pointed out above. For example ros2 doctor can already check for QoS incompatibilities.

The straightforward and easy approach is to make rqt configurable, but manually configuring QoS settings after firing up rviz2 or rqt is counter-intuitive and time-consuming, especially for ROS beginners.

[jacobperron]

FWIW, I think you can reconfigure all of the default gazebo_ros plugins via XML (in the URDF/SDF) since Foxy. Here is a link to some documentation:
https://github.com/ros-simulation/gazebo_ros_pkgs/blob/205755685f77300a27d16c9739b1e397e30811d9/gazebo_ros/include/gazebo_ros/qos.hpp#L61-L120

---

Another option is to dynamically select the QoS based on the publisher. Here is a related issue to add a common API to support such a feature in ROS 2: ros2/rclcpp#1868

[m2-farzan]

Thanks for the hint, @jacobperron

I added the <qos> tag to the <plugin> tag of my camera like this:

<plugin name="camera_plugin" filename="libgazebo_ros_camera.so">
    <ros>
        <namespace>camera</namespace>
        <qos>
            <topic name="/camera/${side}/image_raw">
                <publisher>
                    <reliability>reliable</reliability>
                </publisher>
            </topic>
        </qos>
    </ros>
    <camera_name>${side}</camera_name>
    <frame_name>camera_${side}_link_optical</frame_name>
    <hack_baseline>0.2</hack_baseline>
</plugin>

It solved the qos compatibility problem with rqt.

[jacobperron]

I just noticed that even if we enable the QoS overrides feature, we won't actually be able to use it for C++ plugins since we're not parsing CLI arguments (#262).

[rosiakpiotr]

This issue was opened on beginning of 2019, we have almost 2024 and still no resolution? Any updates?

[ros-discourse]

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

https://discourse.ros.org/t/new-rep-2003-sensor-data-and-map-qos-settings/35758/10

[karl-schulz]

This issue was opened on beginning of 2019, we have almost 2024 and still no resolution? Any updates?

Pretty sure it has been fixed by images being subscribed as BEST_EFFORT now.
See ros-visualization/rqt_image_view#67