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

Debug incompatible QoS #1

Closed
tudoroancea opened this issue Nov 5, 2023 · 1 comment
Closed

Debug incompatible QoS #1

tudoroancea opened this issue Nov 5, 2023 · 1 comment
Assignees
Labels
bug Something isn't working

Comments

@tudoroancea
Copy link
Owner

Sometimes, QoS policy incompatibilities arise when using foxglove bridge. When it happens, we cannot visualize the corresponding data on foxglove studio, whether it is coming from a ros bag/mcap or live publishers.

My bests guess for the moment: if foxglove bridge creates a subscriber on a certain topic, it will (supposedly) check the QoS policies of the other subscribers and will use the same one. If the foxglove bridge is already running when we launch our nodes, it could start before the others and use wrong QoS profiles.

Relevant parts of foxglove bridge source code:
choice of the QoS profile and PR where it was introduced

@tudoroancea tudoroancea added the bug Something isn't working label Nov 5, 2023
@tudoroancea tudoroancea self-assigned this Nov 5, 2023
@tudoroancea
Copy link
Owner Author

Thanks to this post I managed that in our case, the subscriber related to the line plots of Foxglove studio is the one selecting the incompatible policy (in this case durability that is set to TransientLocal instead of Volatile)

achim-k pushed a commit to foxglove/ros-foxglove-bridge that referenced this issue Dec 12, 2023
### Public-Facing Changes

Solved bug with incompatible QoS policies

### Description

Fixes the following
[issue](tudoroancea#1)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
Status: Done
Development

No branches or pull requests

1 participant