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
Heavy sensor topics (cameras, lidars) interfere with the clock publisher by introducing delays since they share the same single threaded spinner.
The issue can be addressed with a dedicated bridge instance with qos and node name overrides, but given the importance of the clock topic it makes sense to create a dedicated node to simplify usage of the bridge.
The text was updated successfully, but these errors were encountered:
It is possible to have a separate bridge (I.e, a separate process) for the clock node with its own QOS setting, but having better defaults would be great. @asherikov are you interested in working on this?
Hi, it looks like adding a dedicated node requires the least amount of work, otherwise the bridge would require significant refactoring: custom settings for a specific topic, multithreaded spinning, etc. I have solved my problems with a dedicated instance of the bridge, so I am currently not interested in working on a better solution.
Hello, I've been investigating poor performance of the /clock topic and noticed a couple of issues:
The issue can be addressed with a dedicated bridge instance with qos and node name overrides, but given the importance of the clock topic it makes sense to create a dedicated node to simplify usage of the bridge.
The text was updated successfully, but these errors were encountered: