Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[ROS2] QOS profile options and subscribing problem #187

Open
Myzhar opened this issue Jan 17, 2019 · 15 comments
Open

[ROS2] QOS profile options and subscribing problem #187

Myzhar opened this issue Jan 17, 2019 · 15 comments

Comments

@Myzhar
Copy link

Myzhar commented Jan 17, 2019

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
Copy link

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
Copy link

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
Copy link

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

@dirk-thomas
Copy link
Contributor

dirk-thomas commented Aug 26, 2020

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
Copy link
Contributor

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
Copy link

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:

image

@808brick
Copy link

808brick commented Mar 30, 2021

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
Copy link

andreasBihlmaier commented Dec 26, 2021

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
Copy link

goekce commented Feb 9, 2022

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
Copy link
Contributor

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
Copy link

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
Copy link
Contributor

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
Copy link

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

@ros-discourse
Copy link

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
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests