Wyatt Newman - A Systematic Approach to Learning Robot Programming with ROS

Part of the joy of working in academia is regular contact with bright and enthusiastic students. I want to thank my former advisees Chad Rockey and Eric Perko for dragging me into ROS back in 2010. Ive since converted from a ROS skeptic to a ROS evangelist. I am grateful for many students since, who have helped me in my conversion and in learning new ROS tricks, including Tony Yanick, Bill Kulp, Ed Venator, Der-Lin Chow, Devin Schwab, Neal Aungst, Tom Shkurti, TJ Pech, and Luc Bettaieb.

My thanks, also, to Prof. Sethu Vijayakumar and the Scottish Informatics and Computer Science Alliance for their support while I initiated lectures in ROS and the groundwork for this text at University of Edinburgh. Thanks as well to associates from U. Edinburgh, including Chris Swetenham, Vladimir Ivan and Michael Camilleri, who contributed ROS programming as teammates in the DARPA Robotics Challenge, teaching me additional ROS tricks in the process.

I am grateful for the support of the Hung Hing Ying family, whose foundation helped make possible my stay at the Unversity of Hong Kong as a Hung Hing Ying Distinguised Visiting Professor while organizing and working with the HKU DARPA Robotics Challenge team. This experience was a valuable immersion in ROS. My thanks as well to Kei Okada and his students from U. Tokyo for their contributions to our HKU team, including valuable insights and techniques in ROS.

My thanks to Randi Cohen, senior acquistions editor at Taylor and Francis, for encouraging and guiding the publication of this book. I also want to thank the reviewers, Dr. Craig Carignan of NASA Goddard Space Flight Center and U. Maryland and Prof. Juan Rojas at Guangdong University of Technology, for their valuable feedback.

Finally, I am grateful for the support of my wife, Peggy Gallagher, and daughters Clea and Alair Newman, for constant encouragement and assistance.

The success of ROS would not have been possible without the support of Google and the Open Source Robotics Foundation, as 0077ell as all of the many online contributors who created valuable ROS packages and online tutorials, as well as responded with answers to many posted ROS questions.

To my wife, Peggy, with thanks for her constant encouragement and support in this effort.

This introductory chapter will focus on the concept of nodes in ROS, starting with minimal examples. A few ROS tools will be introduced as well to help illuminate the behavior of ROS nodes. The simplest means of ROS communicationspublish and subscribewill be used here. Alternative communications means (services and action servers) will be deferred until .

Communications among nodes are at the heart of ROS. A node

is a ROS program that uses ROSs middleware for communications. A node can be launched independently of other nodes and in any order among launches of other nodes. Many nodes can run on the same computer, or nodes may be distributed across a network of computers. A node is useful only if it can communicate with other nodes and ultimately with sensors and actuators.

Communication among nodes uses the concepts of messages, topics, roscore, publishers and subscribers. (Services are also useful, and these are closely related to publishers and subscribers). All communications among nodes is serialized network communications. A publisher publishes a message, which is a packet of data that is interpretable using an associated key. Since each message is received as a stream of bits, it is necessary to consult the key (the message type description) to know how to parse the bits and reconstruct the corresponding data structure. A simple example of a message is

Float64, which is defined in the package std_msgs, which comes with ROS. The message type helps the publisher pack a floating-point number into the defined stream of 64 bits, and it also helps the subscriber interpret how to unpack the bitstream as a representation of a floating-point number.

A more complex example of a message is a twist, which consists of multiple fields describing three-dimensional translational and rotational velocities. Some messages also accommodate optional extras, such as time stamps and message identifier codes.

When data is published by a publisher node, it is made available to any interested subscriber nodes. Subscriber nodes must be able to make connections to the published data. Often, the published data originates from different nodes. This can happen because these publishers have changed due to software evolution or because some publisher nodes are relevant in some contexts and other nodes in other contexts. For example, a publisher node responsible for commanding joint velocities may be a stiff position controller, but in other scenarios a compliant-motion controller may be needed. This hand-off can occur by changing the node publishing the velocity commands. This presents the problem that the subscriber does not know who is publishing its input. In fact, the need to know what node is publishing complicates construction of large systems. This problem is addressed by the concept of a topic.

A topic may be introduced and various publishers may take turns publishing to that topic. Thus a subscriber only needs to know the name of a topic and does not need to know what node or nodes publish to that topic. For example, the topic for commanding velocities may be vel_cmd, and the robots low-level controller should subscribe to this named topic to receive velocity commands. Different publishers may be responsible for publishing velocity-command messages on this topic, whether these are nodes under experimentation or trusted nodes that are swapped in to address specific task needs.

Although creating the abstraction of a topic helps some, a publisher and a subscriber both need to know how to communicate via a topic. This is accomplished through communications middleware in ROS via the provided executable node roscore. The roscore node is responsible for coordinating communications, like an operator. Although there can be many ROS nodes distributed across multiple networked computers, there can be only one instance of roscore running, and the machine on which roscore runs establishes the master computer of the system.

A publisher node initiates a topic by informing roscore of the topic (and the corresponding message type). This is called advertising the topic. To accomplish this, the publisher instantiates an object of the class ros::Publisher. This class definition is part of the ROS distribution, and using publisher objects allows the designer to avoid having to write communications code. After instantiating a publisher object, the user code invokes the member function advertise and specifies the message type and declares the desired topic name. At this point, the user code can start sending messages to the named topic using the publisher member function publish, which takes as an argument the message to be published.

Since a publisher node communicates with roscore, roscore must be running before any ROS node is launched. To run roscore, open a terminal in Linux and enter roscore. The response to this command will be a confirmation started core services. It will also print the ROS_MASTER_URI, which is useful for informing nodes running on non-master computers how to reach roscore. The terminal running roscore will be dedicated to roscore, and it will be unavailable for other tasks. The roscore node should continue running as long as the robot is actively controlled (or as long as desired to access the robots sensors).