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.
tudoroancea
commented
10 months ago
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