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
With ROS 2, there is a long-running daemon in the background that stores information about the ROS graph to provide faster responses to queries, e.g. the list of node names, without having to discovery every other peer in the network. The daemon is automatically started when the relevant command-line tools are used for the first time.
With rmw_zenoh, we expect users to run the zenohd router which largely does the same above. However, there are issues with the zenohd router and daemon coexisting (mostly related to graph cache queries).
For example, if a user runs ros2 topic list without the zenohd router running, the process will check indefinitely for a router until one is started. Once the command exists, and if one kills the router, running ros2 topic list again will instantly return the topics from the daemon's cache. However in such scenarios we would like the cli tool to look for a router first before returning results from a cache.
Starting a discussion on how to manage such scenarios.
We had a bit of a discussion about this at the Waffle meeting today. Some notes:
People were somewhat opposed to getting rid of the daemon, because it makes rmw_zenoh look "different" than other RMWs.
One suggestion was to couple the lifetimes of the ROS 2 daemon and the Zenoh router. That would probably mean that when we launched the Zenoh router, we would also launch the ROS 2 daemon at the same time, and if one died they both die.
Another suggestion was to just replace the ROS 2 daemon with the Zenoh router. There are a couple of major problems with that approach:
The protocol between the ROS 2 daemon the ros2cli tools is XMLRPC. So we'd have to have some kind of "wrapper" around the Zenoh router that converted XMLRPC calls into something that the Zenoh router understands.
The ROS 2 daemon doesn't always run. It is only started when certain ros2cli commands are invoked. In contrast, the Zenoh router is required and needs to be running at all times for rmw_zenoh to succeed, so it has different lifetime requirements.
I would love to see zenohd automatically stop the ros2 daemon if it had been started with another rmw. These issues can be hard to track down if you read past the section in the readme.
With ROS 2, there is a long-running daemon in the background that stores information about the ROS graph to provide faster responses to queries, e.g. the list of node names, without having to discovery every other peer in the network. The daemon is automatically started when the relevant command-line tools are used for the first time.
With
rmw_zenoh
, we expect users to run thezenohd
router which largely does the same above. However, there are issues with thezenohd
router and daemon coexisting (mostly related to graph cache queries).For example, if a user runs
ros2 topic list
without thezenohd
router running, the process will check indefinitely for a router until one is started. Once the command exists, and if one kills the router, runningros2 topic list
again will instantly return the topics from the daemon's cache. However in such scenarios we would like the cli tool to look for a router first before returning results from a cache.Starting a discussion on how to manage such scenarios.
rmw
API to selectively enable/disable certain "features" including the daemon.rcl
,rclpy
andros2cli
such that these features are checked and only start the daemon if configured to do so.The text was updated successfully, but these errors were encountered: