The site is read-only. Please transition to use Robotics Stack Exchange
| ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange |
 | 1 | initial version |
Short answer: The ROS 2 daemon fulfils the same role that the master fills in ROS 1. However, unlike ROS 1, it is not required, but an optimisation. ROS 2 nodes can function without it, unlike ROS 1 nodes which cannot function without the master.
Long answer:
DDS (the underlying communications middleware used by ROS 2 in its default configuration) has a discovery protocol. This is used to provide a decentralised way for nodes to find each other, rather than having to use a master as ROS 1 did. It works very well, but it also takes longer than the approach of using a master does, because every new node that starts has to send out a broadcast looking for other nodes and wait for responses to come in, as well as collecting hellos from other nodes that may arrive over time. The result is that knowing the existence and location on the network of other nodes is not a single-request thing any more, it takes time to build up the knowledge. That time grows longer if you have a more complex network involved. It is also difficult to know when you have found all nodes that are currently in existence.
This is a significant drawback for nodes that want to start up, quickly perform some task, then shut down. An excellent example of these sorts of nodes is the short-life node created by ros2 topic pub to send out some data when you run that command. You don't want it to sit around for 30 seconds collecting node hello broadcasts before doing what you asked it to. You could cut down the time it waits, but the shorter you have it wait, the less of the existing node graph it will find, which means your ros2 topic pub data might not go to every node that is actually listening to that topic.
The solution is the ROS 2 daemon. This is a node that sits around all day just listening to discovery protocol traffic and making a record of which nodes are alive and where they are. Then, when a new node wants to know where other nodes are, it can bypass its own DDS discovery process and contact the ROS 2 daemon on a known port and ask it for the graph information.
The nice thing about this scheme is that a new node still performs its standard DDS discovery process, so if the ROS 2 daemon does not exist, then it will still be able to find other new nodes and function properly. This is a significant difference from ROS 1, where if the master does not exist your node simply cannot function. Similarly, if the new node starts very shortly after the ROS 2 daemon, then the daemon won't yet have cached much information about existing nodes. However in this case as well the new node can still find the missing information from its DDS discovery process, so it is robust to that potential problem as well. This is different from ROS 1 where if you restarted the master after it died, any new nodes would function but they would have no way of finding nodes that were around before the master was restarted.
ROS Answers is licensed under Creative Commons Attribution 3.0 Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.
