You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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)
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
The text was updated successfully, but these errors were encountered: