The Robot Operating System (ROS) is a framework for writing robot software. It is a collection of tools, libraries, and conventions that aim to simplify the task of creating complex and robust robot behavior across a wide variety of robotic platforms.
Why? Because creating truly robust, general-purpose robot software is hard. From the robot’s perspective, many problems that seem trivial to humans can actually encompass wild variations between instances of tasks and environments.
Consider a simple “fetch an item” task, where an office-assistant robot is instructed to retrieve a stapler. First, the robot must understand the request, either verbally or through some other modality, such as a web interface, email, or even SMS. Then, the robot must start some sort of planner to coordinate the search for the item, which will likely require navigating through various rooms in a building, perhaps including elevators and doors. Once arriving in a room, the robot must search desks cluttered with similarly sized objects (since all handheld objects are roughly the same size) and find a stapler. The robot must then retrace its steps and deliver the stapler to the desired location. Each of those subproblems can have arbitrary numbers of complicating factors. And this was a relatively simple task!
Dealing with real-world variations in complex tasks and environments is so difficult that no single individual, laboratory, or institution can hope to build a complete system from scratch. As a result, ROS was built from the ground up to encourage collaborative robotics software development. For example, in the “fetch a stapler” problem, one organization might have experts in mapping indoor environments and could contribute a complex yet easy-to-use system for producing indoor maps. Another group might have expertise in using maps to robustly navigate indoor environments. Yet another group might have discovered a particular computer vision approach that works well for recognizing small objects in clutter. ROS includes many features specifically designed to simplify this type of large-scale collaboration.
ROS is a large project that has many ancestors and contributors. The need for an open collaboration framework was felt by many people in the robotics research community. Various projects at Stanford University in the mid-2000s involving integrative, embodied AI, such as the STanford AI Robot (STAIR) and the Personal Robots (PR) program, created in-house prototypes of the types of flexible, dynamic software systems described in this book. In 2007, Willow Garage, Inc., a nearby robotics incubator, provided significant resources to extend these concepts much further and create well-tested implementations. The effort was boosted by countless researchers who contributed their time and expertise to the core of ROS and its fundamental software packages. Throughout, the software was developed in the open using the permissive BSD open source license, and it gradually became widely used in the robotics research community.
From the start, ROS was being developed at multiple institutions and for multiple robots. At first, this seemed like a headache, since it would have been far simpler for all contributors to place their code on the same servers. Ironically, over the years, this has emerged as one of the great strengths of the ROS ecosystem: any group can start their own ROS code repository on their own servers, and they will maintain full ownership and control of it. They don’t need anyone’s permission. If they choose to make their repository publicly visible, they can receive the recognition and credit they deserve for their achievements and benefit from specific technical feedback and improvements like all open source software projects.
The ROS ecosystem now consists of tens of thousands of users worldwide, working in domains ranging from tabletop hobby projects to large industrial automation systems.
All software frameworks impose their development philosophies on their contributors directly or indirectly, through their idioms and common practices. Broadly speaking, ROS follows the Unix philosophy of software development in several key aspects. This tends to make ROS feel “natural” for developers coming from a Unix background but somewhat “cryptic” at first for those who have primarily used graphical development environments on Windows or Mac OS X. The following paragraphs describe several philosophical aspects of ROS:
ROS systems consist of numerous small computer programs that connect to one another and continuously exchange messages. These messages travel directly from one program to another; there is no central routing service. Although this makes the underlying “plumbing” more complex, the result is a system that scales better as the amount of data increases.
As demonstrated by the enduring architecture of Unix, complex software systems can be created from many small, generic programs. Unlike many other robotics software frameworks, ROS does not have a canonical integrated development and runtime environment. Tasks such as navigating the source code tree, visualizing the system interconnections, graphically plotting data streams, generating documentation, logging data, etc. are all performed by separate programs. This encourages the creation of new, improved implementations, since (ideally) they can be exchanged for implementations better suited for a particular task domain. Recent versions of ROS allow many of these tools to be composed into single processes for efficiency or to create coherent interfaces for operators or debugging, but the principle remains the same: the individual tools themselves are relatively small and generic.
The ROS conventions encourage contributors to create standalone libraries and then wrap those libraries so they can send and receive messages to and from other ROS modules. This extra layer is intended to allow the reuse of software outside of ROS for other applications, and it greatly simplifies the creation of automated tests using standard continuous integration tools.
The core of ROS is released under the permissive BSD license, which allows commercial and noncommercial use. ROS passes data between modules using interprocess communication (IPC), which means that systems built using ROS can have fine-grained licensing of their various components. Commercial systems, for example, often have several closed source modules communicating with a large number of open source modules. Academic and hobby projects are often fully open source. Commercial product development is often done completely behind a firewall. All of these use cases, and more, are common and perfectly valid under the ROS license.
Although ROS has been made to work on a wide variety of systems, in this book we will be using Ubuntu Linux, a popular and relatively user-friendly Linux distribution. Ubuntu provides an easy-to-use installer that allows computers to dual-boot between the operating system they were shipped with (typically Windows or Mac OS X) and Ubuntu itself. That being said, it is important to back up your computer before installing Ubuntu, in case something unexpected happens and the drive is completely erased in the process.
Although there are virtualization environments such as VirtualBox and VMware that allow Linux to run concurrently with a host operating system such as Windows or Mac OS X, the simulator used in this book is rather compute- and graphics-intensive, and might be overly sluggish in a virtualized environment. As such, we recommend running Ubuntu Linux natively by following the instructions on the Ubuntu website.
Ubuntu Linux can be downloaded freely from http://ubuntu.com. The remainder of this book assumes that ROS is being run on Ubuntu 14.04 LTS, also known as Ubuntu Trusty Tahr, and will use the ROS Indigo distribution.
The ROS installation steps require a few shell commands that involve some careful typing. These can be either hand-copied from the following block (note that the first command has been broken across lines to fit the page margins; you can enter this on a single line, without the backslashes), or copied and pasted from the ROS wiki. The following commands will add ros.org to the system’s list of software sources, download and install the ROS packages, and set up the environment and ROS build tools:
user@hostname$ sudo sh -c \ 'echo "deb http://packages.ros.org/ros/ubuntu trusty main" > \ /etc/apt/sources.list.d/ros-latest.list' user@hostname$ wget http://packages.ros.org/ros.key -O - | sudo apt-key add - user@hostname$ sudo apt-get update user@hostname$ sudo apt-get install ros-indigo-desktop-full python-rosinstall user@hostname$ sudo rosdep init user@hostname$ rosdep update user@hostname$ echo "source /opt/ros/indigo/setup.bash" >> ~/.bashrc user@hostname$ source ~/.bashrc
That seems like a gnarly block of shell commands! Some of them are indeed a bit unusual, but others will be commonly used when using ROS and other large software packages on Ubuntu systems. In particular, the
apt-get command is a commonly used command on Ubuntu Linux distributions (among others), and it will be used frequently throughout the book to install additional software packages. This command will install the desired software package(s) requested on the command line, as well as their dependencies, and their dependencies’ dependencies, and so on. If you’d rather use a graphical application to install and manage your Ubuntu package files, you can install
synaptic. Of course, you might have to do this on the command line:
user@hostname$ sudo apt-get install synaptic
The last two lines of the installation sequence add the ROS environment setup script, setup.bash, to the current and future shells on this system. This means that commands and shell scripts provided by ROS, such as the many command-line tools described in future chapters, are now accessible to the shell interpreters on this system. Without those two lines, users would have to manually source the /opt/ros/indigo/setup.bash file for each command shell they opened. Adding the ROS setup.bash file to the user’s ~/.bashrc ensures that this step happens automatically for all future command shells.
Throughout the book, we will refer to various operating system features as “POSIX,” such as “POSIX processes,” “POSIX environment variables,” and so on. This is meant to indicate that much of ROS is written with portability in mind between POSIX-compliant systems, such as Linux or Mac OS X. That being said, in this book we will be focusing specifically on Ubuntu Linux, since it is a popular Linux distribution for the desktop and since the ROS build farm produces easy-to-install binaries for Ubuntu.
This chapter has provided a high-level overview of ROS and its guiding philosophical ideas. ROS is a framework for developing robotics software. The software is structured as a large number of small programs that rapidly pass messages to one another. This paradigm was chosen to encourage the reuse of robotics software outside the particular robot and environment that drove its creation. Indeed, this loosely coupled structure allows for the creation of generic modules that are applicable to broad classes of robot hardware and software pipelines, facilitating code sharing and reuse among the global robotics community.