ROS nodes and ROS Master

One of the primary purposes of ROS is to facilitate communication between the ROS modules called nodes. These nodes represent the executable code and the code can reside entirely on one computer, or nodes can be distributed between computers or between computers and robots. The advantage of this distributed structure is that each node can control one aspect of a system. One node can capture and output camera images, and another node can control a robot's manipulator in response to the camera view. We will see that the turtlesim simulator has two nodes that are created when turtlesim is executed.

The ROS site http://www.ros.org/core-components/ describes the communication and robot-specific features of ROS. Here, we will explore some of the main components of a ROS system including ROS nodes and the ROS Master. It is important for you to understand the ROS nodes and Master, so they will be defined later through discussions and examples.

ROS nodes

Basically, nodes are processes that perform some action. The nodes themselves are really software modules but with the capability to register with the ROS Master node and communicate with other nodes in the system. The ROS design idea is that each node is an independent module that interacts with other nodes using the ROS communication capability.

The nodes can be created in various ways. From a terminal window a node can be created directly by typing a command after the command prompt, as shown in the examples to follow. Alternatively, nodes can be created as part of a program written in Python or C++. In this book, we will use both the ROS commands in a terminal window and Python programs to create nodes.

Nodes can publish and nodes can subscribe

One of the strengths of ROS is that a particular task, such as controlling a wheeled mobile robot, can be separated into a series of simpler tasks. The tasks can include the perception of the environment using a camera or laser scanner, map making, planning a route, monitoring the battery level of the robot's battery, and controlling the motors driving the wheels of the robot. Each of these actions might consist of a ROS node or series of nodes to accomplish the specific tasks.

A node can independently execute code to perform its task but can communicate with other nodes by sending or receiving messages. The messages can consist of data, or commands, or other information necessary for the application.

Some nodes provide information for other nodes, as a camera feed would do, for example. Such a node is said to publish information that can be received by other nodes. The information in ROS is called a topic, which will be explained later. Continuing with the camera example, the camera node can publish the image on the camera/image_raw topic.

Image data from the camera/image_raw topic can be used by a node that shows the image on the computer screen. The node that receives the information is said to subscribe to the topic being published, in this case camera/image_raw.

In some cases, a node can both publish and subscribe to one or more topics. A number of examples later in the book will demonstrate this functionality.

ROS Master

The ROS nodes are typically small and independent programs that can run concurrently on several systems. Communication is established between the nodes by the ROS Master. The ROS Master provides naming and registration services to the nodes in the ROS system. It tracks publishers and subscribers to the topics. The role of the Master is to enable individual ROS nodes to locate one another. The most often used protocol for connection is the standard Transmission Control Protocol/Internet Protocol (TCP/IP) or Internet Protocol called TCPROS in ROS. Once these nodes are able to locate one another, they can communicate with each other peer-to-peer.

One responsibility of the Master is to keep track of nodes when new nodes are executed and come into the system. Thus, the Master provides a dynamic allocation of connections. The nodes cannot communicate however, until the Master notifies the nodes of each others' existence. A simple example is shown at: http://wiki.ros.org/Master.

Invoking the ROS Master using roscore

roscore is a collection of nodes and programs that you must have running for ROS nodes to communicate. After it is launched, roscore will start the following:

• A ROS Master
• A ROS Parameter Server
• A rosout logging node

The roscore command starts ROS and creates the Master so that nodes can register with the Master. You can view the ROS tutorial for roscore at http://wiki.ros.org/roscore.

Issue the following command to start the Master in a new terminal window and observe the output:

$ roscore

The output of the preceding command is as follows:

... logging to /home/harman/.ros/log/94248b4a-3f05-11e5-b5ce-00197d37ddd2/roslaunch-Laptop-M1210-2322.log
Checking log directory for disk usage. This may take awhile.
Press Ctrl-C to interrupt
Done checking log file disk usage. Usage is <1GB.
started roslaunch server http://Laptop-M1210:46614/
ros_comm version 1.11.13
SUMMARY
========
PARAMETERS
 * /rosdistro: indigo
 * /rosversion: 1.11.13
NODES
auto-starting new master
process[master]: started with pid [2334]
ROS_MASTER_URI=http://Laptop-M1210:11311/
setting /run_id to 94248b4a-3f05-11e5-b5ce-00197d37ddd2
process[rosout-1]: started with pid [2347]
started core service [/rosout]

In the preceding screen output, you will see information about the computer, parameters that list the name (indigo) and version number of the ROS distribution, and other information. The Master is defined by its Uniform Resource Identifier (URI). This identifies the location of the Master; in this case, it is running on the laptop and is used to execute the roscore command.

Parameter Server

The Parameter Server is a shared dictionary of parameters that nodes store and retrieve at runtime. The Parameter Server runs inside the Master and parameters are globally viewable so that nodes can access the parameters.

In the preceding screen output from the roscore command, the parameters associated with the Master are as follows:

* /rosdistro: indigo
* /rosversion: 1.11.13

Indigo is the ROS distribution release that we are using. As Indigo is changed or packages are added, numbered versions such as 1.11.13 are released. Issuing the roscore command is a way to determine the release of ROS running on your computer.

Whenever ROS is executing, it is possible to list the nodes that are active and the topics that are used for communication. We will explore the information in the roscore output in more detail by invoking useful ROS terminal commands.

ROS commands to determine the nodes and topics

Three commands used extensively in ROS are as follows:

• roscore to start the Master and allow nodes to communicate
• rosnode list to list the active nodes
• rostopic list to list the topics associated with ROS nodes

After the roscore command is executed, the terminal window used to execute roscore must remain active, but it can be minimized. In another terminal window, the rosnode list command will cause a list of the ROS nodes that are active to be displayed on the screen. After the command for roscore is executed, only one node rosout will be listed as an active node if you type the following command:

$ rosnode list

The output of the preceding command is as follows:

/rosout

In the second terminal window, list the active topics by typing:

$ rostopic list

The output of the preceding command is as follows:

/rosout
/rosout_agg

Notice that the /rosout node and the /rosout topic have the same designation. In ROS terms, the rosout node subscribes to the /rosout topic. All the active nodes publish their debug messages to the /rosout topic. We will not be concerned with these messages here; however, they can be useful to debug a program. For some explanation, refer to the ROS wiki at http://wiki.ros.org/rosout.

The rosout node is connected to every other active node in the system. The /rosout_agg topic receives messages also, but just from the rosout node so it does not have to connect to all of the nodes and thus saves time at system startup.

The rostopic and rosnode terminal commands have a number of options that will be demonstrated by various examples in this book.

Tip

Most of the ROS commands have help screens that are usually helpful. Type the following command for the command options:

$ rosnode -h

For more detailed usage, use the subcommand name, for example:

$ rosnode list –h

will list the subcommands and the options for the rosnode command.

There are a number of other important ROS terminal commands that you should know. They are introduced and explained using the turtlesim simulator in the upcoming section.