Book Image

ROS Robotics By Example, Second Edition - Second Edition

By : Carol Fairchild, Lentin Joseph, Dr. Thomas L. Harman
Book Image

ROS Robotics By Example, Second Edition - Second Edition

By: Carol Fairchild, Lentin Joseph, Dr. Thomas L. Harman

Overview of this book

ROS is a robust robotics framework that works regardless of hardware architecture or hardware origin. It standardizes most layers of robotics functionality from device drivers to process control and message passing to software package management. But apart from just plain functionality, ROS is a great platform to learn about robotics itself and to simulate, as well as actually build, your first robots. This does not mean that ROS is a platform for students and other beginners; on the contrary, ROS is used all over the robotics industry to implement flying, walking and diving robots, yet implementation is always straightforward, and never dependent on the hardware itself. ROS Robotics has been the standard introduction to ROS for potential professionals and hobbyists alike since the original edition came out; the second edition adds a gradual introduction to all the goodness available with the Kinetic Kame release. By providing you with step-by-step examples including manipulator arms and flying robots, the authors introduce you to the new features. The book is intensely practical, with space given to theory only when absolutely necessary. By the end of this book, you will have hands-on experience on controlling robots with the best possible framework.
Table of Contents (18 chapters)
ROS Robotics By Example Second Edition
Credits
About the Authors
About the Reviewer
www.PacktPub.com
Customer Feedback
Preface
Index

ROS nodes, topics, and messages


Here we will explore some of the main components of ROS. One of the primary purposes of ROS is to facilitate communication between the ROS nodes. These nodes represent the executable code. 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.

For example, one node can capture the images from a camera and send the images to another node for processing. After processing the image, the second node can send a control signal to a third node for controlling a robotic manipulator in response to the camera view.

The main mechanism used by ROS nodes to communicate is by sending and receiving messages. The messages are organized into specific categories called topics. Nodes may publish messages on a particular topic or subscribe to a topic to receive information.

ROS nodes

Basically, nodes are processes that perform some computation or task. The nodes themselves are really software processes 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 independent and interacts with other nodes using the ROS communication capability. The Master node is described in the ROS Master section to follow.

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 a series of nodes to accomplish the specific tasks.

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

ROS topics

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. A topic defines the types of messages that will be sent concerning that topic.

The nodes that transmit data publish the topic name and the type of message to be sent. The actual data is published by the node. A node can subscribe to a topic and transmitted messages on that topic are received by the node subscribing.

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.

ROS messages

ROS messages are defined by the type of message and the data format. The ROS package named std_msgs, for example, has messages of type String which consist of a string of characters. Other message packages for ROS have messages used for robot navigation or robotic sensors. The turtlesim package has its own set of messages that pertain to the simulation.

We will see in the section, Turtlesim – the first ROS robot simulation that the turtlesim simulator has two nodes that are created when turtlesim is executed. Turtlesim has relatively few topics and messages so it is ideal for the initial study of ROS.

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, topics, and messages as they are involved in almost every ROS activity.

ROS Master

The ROS nodes are typically independent programs that can run concurrently on several systems. The ROS Master provides naming and registration services to the nodes in the ROS system. It tracks publishers and subscribers to the topics. Communication is established between the nodes by the ROS Master.

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 other's existence. A simple example is shown at http://wiki.ros.org/Master.

Invoking the ROS Master using roscore

roscore starts processes that you must have running in order for ROS nodes to communicate. When it executes, roscore will start the following:

  • A ROS Master

  • A ROS Parameter Server

  • A rosout logging node

The roscore command 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/linux/.ros/log/9c3776b4-09cd-11e7-bb39-1866da2351d7/roslaunch-D158-45929-29790.log
Checking log directory for disk usage. This may take a while.
Press Ctrl-C to interrupt
Done checking log file disk usage. Usage is <1GB.

started roslaunch server http://D158-45929:34807/
ros_comm version 1.12.7


SUMMARY
========

PARAMETERS
 * /rosdistro: kinetic
 * /rosversion: 1.12.7

NODES

auto-starting new master
process[master]: started with pid [29802]
ROS_MASTER_URI=http://D158-45929:11311/

setting /run_id to 9c3776b4-09cd-11e7-bb39-1866da2351d7
process[rosout-1]: started with pid [29815]
started core service [/rosout]

In the preceding screen output, you will see information about the computer, parameters that list the name (kinetic) 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 workstation 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: kinetic
* /rosversion: 1.12.7

Kinetic is the ROS distribution release that we are using. As Kinetic is changed or packages are added, numbered versions such as 1.12.7 are released. Issuing the roscore command is a way to determining the version 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 active 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 an 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.

Note

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

This 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.