In this tutorial, we will be talking about ROS namespaces which allow to combine nodes in ways unplanned by developers. This is actually what all ROS is about: allow building systems by connecting nodes, often developed by third parties according to your needs. This is possible thanks to a flexible node naming system. As usual, we will illustrate presented concepts with concrete examples that you can run on your own machine. As a prerequisite, you only need to be familiar with the basic concepts of ROS introduced in a previous post.
View Running Nodes Using rqt_graph
Every ROS application is a graph of nodes typically connected through some topics. We illustrate this idea by the example of turtle simulator. First start the ROS infrastructure is running by evaluating in a terminal the command:
Now, start the turtle simulator node by evaluating in a new terminal:
rosrun turtlesim turtlesim_node
As a result, a simulator window opens. It looks like the one shown by Figure 1, except may be the turtle colors and shape that are different on each launch. On the terminal you’ll see two information lines similar to the ones blow. The [INFO] tag is followed by a time stamp ([<seconds since epoch>.<nano_seconds>]), and then a log about the node name (/turtlesim) and the turtle initial position.
[INFO] [1374406333.186210549]: Starting turtlesim with node name /turtlesim
[INFO] [1374406333.192485241]: Spawning turtle [turtle1] at x=[5.544445], y=[5.544445], theta=[0.000000]
Figure 1: The TurtleSim Simulator Window
To make the turtle move, launch a driver node by evaluating in another terminal:
rosrun turtlesim draw_square
Figure 2: rqt_graph Shows Nodes and Their Connections Through Topics
As a result, you’ll get the window shown by Figure 2. Ellipses represent nodes while arrows represent connexions through topics. We can see that the /turtlesim node (that is visualized by the graphical turtle in Figure 1) is the publisher of the /turtle1/pose topic that provides the current pose of the turtle . The unique subscriber of this topic is the /draw_square node. The second arrow corresponds to the /turtle1/command_velocity topic. It is used by the /draw_square node to send velocity commands to /turtlesim.
One Driver for Two simulated Turtles
Suppose now that we want to have two turtle simulations running side by side, both driven by the same driver (e.g. draw_square). The naive approach consisting in running yet another turtlesim_node does not work. Instead, the first turtle simulation terminates with a warning log ([WARN] tag) as below. It states that the new simulation node replaces the first one.
[WARN] [1374671981.742213033]: Shutdown request received.
[WARN] [1374671981.742445480]: Reason given for shutdown: [new node registered with same name]
To avoid name conflicts, you need to provide a different node name for the second turtle simulator. The rosrun command does allow to assign a different name to the node by evaluating the following command line. The value assigned to the __name parameter (here turtlesim2) is the replacement for the default node name.
rosrun turtlesim turtlesim_node __name:=turtlesim2
Figure 3: Nodes of two turtle simulators sharing a single driver
Figure 3 shows the graph displayed by rqt_graph once you hit the update button. The arrows refer to connections between nodes. To actually see the topics, select the “Nodes/Topics (active)” item in the drop down list of rqt_graph. The result is shown on Figure 4. Topics are represented as rectangles nested into the turtle1 box. If you hover the mouse over a topic, it gets color highlight, as well as connected nodes.
Figure 4: Displaying Topics in rqt_graph
Now it’s time to introduce the concept of namespace. A namespace can be viewed as a directory which contents are items of different names. These items can be nodes, topics, or even other namespaces. Indeed, namespaces can be organized in hierarchies of arbitrary depth.
In the examples above, you already have been dealing with two namespaces. There is the root namespace, referred by a forward slash “/“. The root namespace of Figure 4 includes four items. Three of them are nodes (draw_square, turtlesim, and turtlesim2) while the fourth is the turtle1 namespace. The turtle1 namespace includes two items which are both topics: command_velocity and pose.
To talk to each other, nodes need to refer to same topics. In the previous examples, we used the default topic names. This was ok for our toy scenario. But, sometimes you need to make nodes use topics with different names. A typical example is a system where different sub-systems are similar.
Two Turtle Simulators Driven by Different Drivers
We illustrate the concept of namespace with two turtle simulators driven by two instances of the draw_square driver. Each simulator and is driven by a dedicated driver. Thus, we need to ensure that nodes have different names. We also need to ensure that within each simulation, nodes talk using different topics.
The renaming facility provided by rosrun does allow to avoid collisions. However, it result into multiple long command lines. A better solution is use roslaunch. It requires writing a XML file that contains all information about nodes to launch and their namespaces. The XML listing below allows running side by side two turtle simulation nodes driven by two different draw_square nodes.
<launch> <group ns="sim1"> <node name="turtle" pkg="turtlesim" type="turtlesim_node"/> <node name="controller" pkg="turtlesim" type="draw_square"/> </group> <group ns="sim2"> <node name="turtle" pkg="turtlesim" type="turtlesim_node"/> <node name="controller" pkg="turtlesim" type="draw_square"/> </group> </launch>
The XML format for roslaunch provides tags for defining nodes. By changing the name argument we can have different instances of the same node type of a given package running side by side. In our example, we kept the names identical. But, we wrapped nodes inside group tags. Each group is mapped to a different namespace by setting the ns argument.
Time to launch all nodes by evaluating the following single command line. We assume that the twoTurtleSimulations.launch file with the XML code above is in the folder where the command line is evaluated.
Note that roslaunch takes care of everything. No need to run roscore! Still, if you have already lauched roscore, it will work just fine. Anyway, rqt_graph will display the set of nodes and connexions as shown by Figure 5.
Figure 5: Two namespaces wrapping identical nodes and topi