When our system is running, we might have several nodes and many more topics publishing messages amongst each other. We might also have nodes providing actions or services. For large systems, it is important to have tools that let us see what is running at a given time. ROS provides basic but very powerful tools with this goal in mind, from the CLI to GUI applications.

Listing nodes, topics, services, and parameters from our perspective, we should start with the most basic level of introspection. We are going to see how to obtain the list of nodes running and topics and services available at a given time:

We recommend that you go back to Chapter 2, ROS Architecture and Concepts, to see how these commands also allow us to obtain the message type sent by a particular topic, as well as its fields, using rosmsg show.

Any of these commands can be combined with regular bash commands, such as grep, to look for the desired nodes, topics, services, or parameters. For example, action goal topics can be found using the following command:

$ rostopic list | grep goal

The grep command looks for text or patterns in a list of files or the standard output.

Additionally, ROS provides several GUIs for you to play with topics and services. First, rqt_top shows the nodes running in an interface, similar to a table of processes (ToP), which allows us to rapidly see all the nodes and resources they are using. For the following screenshot, we have used the REEM simulation with the navigation stack running as an example:

On the other hand, rqt_topic provides us with information about topics, including publishers, subscribers, the publishing rate, and messages published. You can view the message fields and select the topics you want to subscribe to in order to analyze their bandwidth and rate (Hz) and see the latest message published; note that latched topics do not usually publish continuously, so you will not see any information about them. The following screenshot shows this:

Similarly, rqt_publisher allows us to manage multiple instances of rostopic pub commands in a single interface. It also supports Python expressions for the published messages and fixed values. In the following screenshot, we will see two example topics being published (we will see the messages using rostopic echo <topic> in two different terminals):

Note that rqt_service_caller does the same thing for multiple instances of rosservice call commands. In the following screenshot, we will call the /move_base/NavfnROS/make_plan service, which is where we have to set up the request; for empty services, this is not needed, due to the /global_localization service from the /amcl node. After clicking on the Call button, we will obtain the response message. For this example, we have used the REEM simulation with the navigation stack running:

Inspecting the node's graph online with rqt_graph

The current state of an ROS session can be shown as a directed graph where the nodes running are the graph nodes and the edges are the publisher-subscriber connections amongst these nodes through the topics. This graph is drawn dynamically by rqt_graph:

$ rosrun rqt_graph rqt_graph

In order to illustrate how to inspect the nodes, topics, and services with rqt_graph, we are going to run the example4 and example5 nodes simultaneously with the following launch file:

$ roslaunch chapter3_tutorials example4_5.launch

The example4 node publishes in two different topics and calls a service. Meanwhile, example5 subscribes to those topics and also has the service server to attend the request queries and provide the response. Once the nodes are running, we have the node's topology, as shown in the following screenshot:

In this screenshot, we have the nodes example4 and example5 connected by the topics temp and accel. Since Hide Debug is selected, we do not see the ROS server node rosout as well as the rosout topic that publishes the logging messages for the diagnostic aggregator in the server as we did previously. We can deselect this option to show the debug nodes/topics so that the ROS server is shown, as well as the rqt_graph node itself (see the following screenshot). It is useful to hide these nodes for larger systems because it simplifies the graph. Additionally, with ROS Kinetic, the nodes in the same namespace are grouped - for example, the image pipeline nodes:

When there is a problem in the system, the nodes appear in red all the time (not just when we move the mouse over them). In those cases, it is useful to select All Topics to also show unconnected topics. This usually shows misspelled topic names that break connections among nodes.

When running nodes on different machines, rqt_graph shows its great high-level debugging capabilities, as it shows whether the nodes see each other from one machine to the other, enumerating the connections.

Finally, we can enable statistics to see the message rate and bandwidth represented in the topic edge, with the rate written and the line width. We must set this parameter before running rqt_graph in order to have this information available:

$ rosparam set enable_statistics true

But this is not the only thing we need to do to enable statistics. To be able to get the desired information, the rqt_topic utility needs to be launched and the appropriate topics need to be ticked. It should also be noted that the parameter might need to be enabled before the relevant nodes are launched.