The stretch goals for Beta 1 (due in mid-December) include rostopic. rostopic is a faily vital tool when developing with ROS, and is probably one of the most-used tools in the ROS-based robot developer’s toolkit. However, there are some challenges in developing rostopic for ROS 2, particularly the
rostopic list command.
In ROS 1, rostopic can easily go off and get the list of known topics from the master, because the master Knows All. This approach is not so straight forward in ROS 2. The use of distributed discovery in DDS means that, by default, no one knows for certain the entire state of the DDS network. Furthermore, when a new participant starts up, it has absolutely no knowledge of the state of the network (beyond what may be hard-coded in) and has to wait for the discovery process to being producing results. This process may be very quick for things on the local machine, but for remote computers it is likely to take a significant time.
If we implement
rostopic list by making it start up, wait for a given length of time, then print the result, there is a good chance that it will not give a complete picture of the ROS graph and so will not be a useful tool.
The purpose of this topic is to decide how to implement rostopic such that it provides the same rapid response as ROS 1, while dealing with the distributed nature of the graph in ROS2, and with as complete information as possible given the limitations of distributed discovery.
To get right into it, my proposal is:
- A daemon is started by something, e.g. roslaunch, or on system start up, or when starting the terminal and sourcing setup.bash, or some kind of
- This daemon’s job is to listen for changes in the graph. It records all changes and stores the current state of the graph. The recent work on listening for graph changes by @wjwwood would be used.
- The daemon provides a ROS topic on a well-known topic, e.g.
/ros/topics(based on the idea that the
/rosnamespace is reserved for infrastructure topics). Connecting to this topic will provide the current state of the graph.
- This topic probably needs to be a service to avoid wasting resources broadcasting something only needed intermittently.
- If it is a service, there is still value in having a topic that broadcasts on change for long-running tools to listen to.
- It may be worth considering having a separate domain for the infrastructure topics.
- Each computer being used should run a copy of the daemon so that connecting to it does not involve traversing the network and so is fast.
rostopic listcommand, upon starting, connects to the daemon’s topic, gets the current graph info, and prints it out.
- If rostopic cannot find the expected topic, then it prints a warning, then waits a configurable length of time (with a suitable default), running the DDS discovery process and listening for graph information. After the time limit it prints the result.
- If you see that warning, you should understand that something is broken in your ROS system.
- This is a downside of the daemon approach: It is a single point of failure for the rostopic functionality.
- The daemon can also provide the same information over any other useful protocols. One particularly useful one would be a REST service, so that tools could connect and get the information without needing to use DDS or potentially be a part of the ROS graph. For example, a web-based tool.
The daemon mentioned above could be easily extended to also provide information for rosnode, rosservice, and similar commands.
If we use the above approach, I would like to fix the ROS topics provided by the deamon as well as any other protocol interfaces/ports, and data formats (e.g. YAML) so that they are useful by other tools and tool implementors, such as rviz and rqt_graph.
There has also been work done on rostopic and friends by the fine folks at Erle Robotics:
Their implementation I think uses a listener waiting for information to pour in on a specific topic. However rather than trying to summarise their work myself, it would be great if @vmayoral could drop by and give us a description himself.