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

Fix for Quality of Service (QoS) settings incompatibility between Gazebo plugin and depthimage_to_laserscan package #74

Conversation

marcusvinicius178
Copy link

Hello Maintainers,

I've recently encountered an issue while using the depthimage_to_laserscan package in the context of the ROS2 Galactic distribution: https://answers.ros.org/question/417736/depth_image_to_laserscan-not-publishing-to-kinect_scan-topic-in-ros2-galactic/?answer=417845#post-id-417845

The problem arose due to a mismatch in the Quality of Service (QoS) settings between the Gazebo depth camera plugin publisher and the subscriber in the depthimage_to_laserscan package.

The Gazebo plugin uses a Best Effort QoS policy for publishing depth camera images, while the depthimage_to_laserscan package, by default, subscribes with a Reliable QoS policy. This mismatch was causing the depthimage_to_laserscan package to not receive any messages from the Gazebo publisher.

To fix this issue, I modified the QoS policy used by the depthimage_to_laserscan subscriber to Best Effort. This change aligns the QoS policy of the depthimage_to_laserscan package with that of the Gazebo publisher, thereby enabling successful communication.

I believe this fix is important as it allows the depthimage_to_laserscan package to function correctly with standard Gazebo plugins in newer ROS2 distributions like Galactic. This will benefit many developers and researchers who rely on this functionality for their projects and increase the overall compatibility of the package with the ROS2 ecosystem.

Thank you for considering my pull request. I look forward to your feedback.

@clalancette
Copy link
Contributor

So I don't think this is quite the right fix. In particular, I think the correct thing to do here is going to be to switch away from SystemDefaultsQoS to SensorDataQoS, and then also enable qos_override_parameters. See #75 for more discussion about it.

Because of that, and because we won't be doing any new updates to Foxy, I'm going to close this out. Thank you for the contribution!

@clalancette clalancette closed this Dec 7, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants