ROS: an open-source Robot Operating System

Morgan Quigley∗ , Brian Gerkey† , Ken Conley† , Josh Faust† , Tully Foote† ,
Jeremy Leibs‡ , Eric Berger† , Rob Wheeler† , Andrew Ng∗
∗ Computer Science Department, Stanford University, Stanford, CA
† Willow Garage, Menlo Park, CA
‡ Computer Science Department, University of Southern California

Abstract— This paper gives an overview of ROS, an open-

source robot operating system. ROS is not an operating system
in the traditional sense of process management and scheduling;
rather, it provides a structured communications layer above
the host operating systems of a heterogenous compute cluster.
In this paper, we discuss how ROS relates to existing robot
software frameworks, and briefly overview some of the available
application software which uses ROS.

I. INTRODUCTION Fig. 1. A typical ROS network configuration

Writing software for robots is difficult, particularly as the
scale and scope of robotics continues to grow. Different
types of robots can have wildly varying hardware, making service robots as part of the STAIR project [2] at Stanford
code reuse nontrivial. On top of this, the sheer size of the University1 and the Personal Robots Program [3] at Willow
required code can be daunting, as it must contain a deep Garage,2 but the resulting architecture is far more general
stack starting from driver-level software and continuing up than the service-robot and mobile-manipulation domains.
through perception, abstract reasoning, and beyond. Since the The philosophical goals of ROS can be summarized as:
required breadth of expertise is well beyond the capabilities • Peer-to-peer
of any single researcher, robotics software architectures must • Tools-based
also support large-scale software integration efforts. • Multi-lingual
To meet these challenges, many robotics researchers, in- • Thin
cluding ourselves, have previously created a wide variety • Free and Open-Source
of frameworks to manage complexity and facilitate rapid To our knowledge, no existing framework has this same
prototyping of software for experiments, resulting in the set of design criteria. In this section, we will elaborate these
many robotic software systems currently used in academia philosophies and shows how they influenced the design and
and industry [1]. Each of these frameworks was designed for implementation of ROS.
a particular purpose, perhaps in response to perceived weak-
nesses of other available frameworks, or to place emphasis A. Peer-to-Peer
on aspects which were seen as most important in the design A system built using ROS consists of a number of pro-
process. cesses, potentially on a number of different hosts, connected
ROS, the framework described in this paper, is also the at runtime in a peer-to-peer topology. Although frameworks
product of tradeoffs and prioritizations made during its de- based on a central server (e.g., CARMEN [4]) can also re-
sign cycle. We believe its emphasis on large-scale integrative alize the benefits of the multi-process and multi-host design,
robotics research will be useful in a wide variety of situations a central data server is problematic if the computers are
as robotic systems grow ever more complex. In this paper, connected in a heterogenous network.
we discuss the design goals of ROS, how our implementation
For example, on the large service robots for which ROS
works towards them, and demonstrate how ROS handles
was designed, there are typically several onboard computers
several common use cases of robotics software development.
connected via ethernet. This network segment is bridged
II. DESIGN GOALS via wireless LAN to high-power offboard machines that
are running computation-intensive tasks such as computer
We do not claim that ROS is the best framework for vision or speech recognition (Figure 1). Running the central
all robotics software. In fact, we do not believe that such server either onboard or offboard would result in unnecessary
a framework exists; the field of robotics is far too broad
for a single solution. ROS was designed to meet a specific 1 [Link]

set of challenges encountered when developing large-scale 2 [Link]

traffic flowing across the (slow) wireless link, because many C. Tools-based
message routes are fully contained in the subnets either In an effort to manage the complexity of ROS, we have
onboard or offboard the robot. In contrast, peer-to-peer opted for a microkernel design, where a large number of
connectivity, combined with buffering or “fanout” software small tools are used to build and run the various ROS com-
modules where necessary, avoids the issue entirely. ponents, rather than constructing a monolithic development
The peer-to-peer topology requires some sort of lookup and runtime environment.
mechanism to allow processes to find each other at runtime. These tools perform various tasks, e.g., navigate the source
We call this the name service, or master, and will describe code tree, get and set configuration parameters, visualize
it in more detail shortly. the peer-to-peer connection topology, measure bandwidth
utilization, graphically plot message data, auto-generate doc-
B. Multi-lingual umentation, and so on. Although we could have implemented
When writing code, many individuals have preferences for core services such as a global clock and a logger inside
some programming languages above others. These prefer- the master module, we have attempted to push everything
ences are the result of personal tradeoffs between program- into separate modules. We believe the loss in efficiency is
ming time, ease of debugging, syntax, runtime efficiency, more than offset by the gains in stability and complexity
and a host of other reasons, both technical and cultural. For management.
these reasons, we have designed ROS to be language-neutral. D. Thin
ROS currently supports four very different languages: C++,
Python, Octave, and LISP, with other language ports in As eloquently described in [5], most existing robotics
various states of completion. software projects contain drivers or algorithms which could
be reusable outside of the project. Unfortunately, due to
The ROS specification is at the messaging layer, not any
a variety of reasons, much of this code has become so
deeper. Peer-to-peer connection negotiation and configura-
entangled with the middleware that it is difficult to “extract”
tion occurs in XML-RPC, for which reasonable implemen-
its functionality and re-use it outside of its original context.
tations exist in most major languages. Rather than provide
To combat this tendency, we encourage all driver and
a C-based implementation with stub interfaces generated
algorithm development to occur in standalone libraries that
for all major languages, we prefer instead to implement
have no dependencies on ROS. The ROS build system
ROS natively in each target language, to better follow the
performs modular builds inside the source code tree, and
conventions of each language. However, in some cases it is
its use of CMake makes it comparatively easy to follow this
expedient to add support for a new language by wrapping
“thin” ideology. Placing virtually all complexity in libraries,
an existing library: the Octave client is implemented by
and only creating small executables which expose library
wrapping the ROS C++ library.
functionality to ROS, allows for easier code extraction and
To support cross-language development, ROS uses a sim-
reuse beyond its original intent. As an added benefit, unit
ple, language-neutral interface definition language (IDL) to
testing is often far easier when code is factored into libraries,
describe the messages sent between modules. The IDL uses
as standalone test programs can be written to exercise various
(very) short text files to describe fields of each message,
features of the library.
and allows composition of messages, as illustrated by the
ROS re-uses code from numerous other open-source
complete IDL file for a point cloud message:
projects, such as the drivers, navigation system, and sim-
Header header ulators from the Player project [6], vision algorithms from
Point32[] pts OpenCV [7], and planning algorithms from OpenRAVE [8],
ChannelFloat32[] chan among many others. In each case, ROS is used only to expose
various configuration options and to route data into and out of
Code generators for each supported language then generate the respective software, with as little wrapping or patching
native implementations which “feel” like native objects, and as possible. To benefit from the continual community im-
are automatically serialized and deserialized by ROS as provements, the ROS build system can automatically update
messages are sent and received. This saves considerable source code from external repositories, apply patches, and
programmer time and errors: the previous 3-line IDL file so on.
automatically expands to 137 lines of C++, 96 lines of
Python, 81 lines of Lisp, and 99 lines of Octave. Because the E. Free and Open-Source
messages are generated automatically from such simple text The full source code of ROS is publicly available. We
files, it becomes easy to enumerate new types of messages. believe this to be critical to facilitate debugging at all levels
At time of writing, the known ROS-based codebases contain of the software stack. While proprietary environments such
over four hundred types of messages, which transport data as Microsoft Robotics Studio [9] and Webots [10] have
ranging from sensor feeds to object detections to maps. many commendable attributes, we feel there is no substitute
The end result is a language-neutral message processing for a fully open platform. This is particularly true when
scheme where different languages can be mixed and matched hardware and many levels of software are being designed
as desired. and debugged in parallel.
 ROS is distributed under the terms of the BSD license, Although the topic-based publish-subscribe model is a
which allows the development of both non-commercial and flexible communications paradigm, its “broadcast” routing
commercial projects. ROS passes data between modules scheme is not appropriate for synchronous transactions,
using inter-process communications, and does not require which can simplify the design of some nodes. In ROS, we
that modules link together in the same executable. As such, call this a service, defined by a string name and a pair
systems built around ROS can use fine-grain licensing of of strictly typed messages: one for the request and one for
their various components: individual modules can incorpo- the response. This is analogous to web services, which are
rate software protected by various licenses ranging from GPL defined by URIs and have request and response documents
to BSD to proprietary, but license “contamination” ends at of well-defined types. Note that, unlike topics, only one node
the module boundary. can advertise a service of any particular name: there can only
be one service called ”classify image”, for example, just as
III. N OMENCLATURE there can only be one web service at any given URI.
The fundamental concepts of the ROS implementation are
IV. U SE C ASES
nodes, messages, topics, and services,
Nodes are processes that perform computation. ROS is In this section, we will describe a number of common
designed to be modular at a fine-grained scale: a system scenarios encountered when using robotic software frame-
is typically comprised of many nodes. In this context, the works. The open architecture of ROS allows for the creation
term “node” is interchangable with “software module.” Our of a wide variety of tools; in describing the ROS approach
use of the term “node” arises from visualizations of ROS- to these use cases, we will also be introducing a number of
based systems at runtime: when many nodes are running, it the tools designed to be used with ROS.
is convenient to render the peer-to-peer communications as A. Debugging a single node
a graph, with processes as graph nodes and the peer-to-peer When performing robotics research, often the scope of
links as arcs. the investigation is limited to a well-defined area of the
Nodes communicate with each other by passing messages. system, such as a node which performs some type of
A message is a a strictly typed data structure. Standard planning, reasoning, perception, or control. However, to get
primitive types (integer, floating point, boolean, etc.) are a robotic system up and running for experiments, a much
supported, as are arrays of primitive types and constants. larger software ecosystem must exist. For example, to do
Messages can be composed of other messages, and arrays of vision-based grasping experiments, drivers must be running
other messages, nested arbritrarily deep. for the camera(s) and manipulator(s), and any number of
A node sends a message by publishing it to a given topic, intermediate processing nodes (e.g., object recognizers, pose
which is simply a string such as “odometry” or “map.” A detectors, trajectory planners) must also be up and running.
node that is interested in a certain kind of data will subscribe This adds a significant amount of difficulty to integrative
to the appropriate topic. There may be multiple concurrent robotics research.
publishers and subscribers for a single topic, and a single ROS is designed to minimize the difficulty of debugging
node may publish and/or subscribe to multiple topics. In in such settings, as its modular structure allows nodes
general, publishers and subscribers are not aware of each undergoing active development to run alongside pre-existing,
others’ existence. well-debugged nodes. Because nodes connect to each other
The simplest communications are along pipelines: at runtime, the graph can be dynamically modified. In the
previous example of vision-based grasping, a graph with
perhaps a dozen nodes is required to provide the infras-
microphone
tructure. This “infrastructure” graph can be started and left
running during an entire experimental session. Only the
speech recognition
node(s) undergoing source code modification need to be
periodically restarted, at which time ROS silently handles
the graph modifications. This can result in a massive increase
dialog manager in productivity, particularly as the robotic system becomes
more complex and interconnected.
To emphasize, altering the graph in ROS simply amounts
speech synthesis
to starting or stopping a process. In debugging settings, this
is typically done at the command line or in a debugger. The
speaker ease of inserting and removing nodes from a running ROS-
based system is one of its most powerful and fundamental
features.

However, graphs are usually far more complex, often con- B. Logging and playback
taining cycles and one-to-many or many-to-many connec- Research in robotic perception is often done most con-
tions. veniently with logged sensor data, to permit controlled
comparisons of various algorithms and to simplify the ex- get tedious. To allow for “packaged” functionality such as a
perimental procedure. ROS supports this approach by pro- navigation system, ROS provides a tool called roslaunch,
viding generic logging and playback functionality. Any ROS which reads an XML description of a graph and instantiates
message stream can be dumped to disk and later replayed. the graph on the cluster, optionally on specific hosts. The
Importantly, this can all be done at the command line; it end-user experience of launching the navigation system then
requires no modification of the source code of any pieces of boils down to
software in the graph.
roslaunch [Link]
For example, the following network graph could be
quickly set up to collect a dataset for visual-odometry and a single Ctrl-C will gracefully close all five processes.
research: This functionality can also significantly aid sharing and reuse
of large demonstrations of integrative robotics research, as
the set-up and tear-down of large distributed systems can be
robot camera easily replicated.
D. Collaborative Development
Due to the vast scope of robotics and artificial intelligence,
logger visualizer collaboration between researchers is necessary in order to
build large systems. To support collaborative development,
the ROS software system is organized into packages. Our
definition of “package” is deliberately open-ended: a ROS
The resulting message dump can be played back into a package is simply a directory which contains an XML file
different graph, which contains the node under development: describing the package and stating any dependencies.
A collection of ROS packages is a directory tree with ROS
packages at the leaves: a ROS package repository may thus
logger vision research visualizer contain an arbitrarily complex scheme of subdirectories. For
example, one ROS repository has root directories including
“nav,” “vision,” and “motion planning,” each of which con-
tains many packages as subdirectories.
As before, node instantiation can be performed simply by ROS provides a utility called rospack to query and
launching a process; it can be done at the command line, in inspect the code tree, search dependencies, find packages
a debugger, from a script, etc. by name, etc. A set of shell expansions called rosbash is
To facilitate logging and monitoring of systems distributed provided for convenience, accelerating command-line navi-
across many hosts, the rosconsole library builds upon the gation of the system.
Apache project’s log4cxx system to provide a convenient The rospack utility is designed to support simultane-
and elegant logging interface, allowing printf-style diag- ous development across multiple ROS package repositories.
nostic messages to be routed through the network to a single Environment variables are used to define the roots of local
stream called rosout. copies of ROS package repositories, and rospack crawls
C. Packaged subsystems the package trees as necessary. Recursive builds, supported
by the rosmake utility, allow for cross-package library
Some areas of robotics research, such as indoor robot
dependencies.
navigation, have matured to the point where “out of the
The open-ended nature of ROS packages allows for great
box” algorithms can work reasonably well. ROS leverages
variation in their structure and purpose: some ROS packages
the algorithms implemented in the Player project to provide
wrap existing software, such as Player or OpenCV, au-
a navigation system, producing this graph:
tomating their builds and exporting their functionality. Some
packages build nodes for use in ROS graphs, other packages
provide libraries and standalone executables, and still others
robot laser map
provide scripts to automate demonstrations and tests. The
packaging system is meant to partition the building of ROS-
based software into small, manageable chunks, each of which
localization
can be maintained and developed on its own schedule by its
own team of developers.
planner
At time of writing, several hundred ROS packages exist
across several publicly-viewable repositories, and hundreds
more likely exist in private repositories at various institutions
and companies. The ROS core is distributed as its own
Although each node can be run from the command line, re- package repository in Sourceforge:
peatedly typing the commands to launch the processes could [Link]
However, the ros repository includes only the base ROS topic, and service names, without requiring any modification
communications infrastructure and graph-management tools. to the code of the node or cluster. The following graph
Software which actually builds robotic systems using ROS shows a hierarchical multi-robot control system constructed
is provided in a second repository, also on Sourceforge: by simply instantiating multiple navigation stacks, each in
[Link] their own namespace:
This repository contains many useful tools and libraries, such
as those discussed in this paper.
E. Visualization and Monitoring
While designing and debugging robotics software, it often
becomes necessary to observe some state while the system
is running. Although printf is a familiar technique for
debugging programs on a single machine, this technique can
be difficult to extend to large-scale distributed systems, and
can become unwieldly for general-purpose monitoring.
Instead, ROS can exploit the dynamic nature of the
connectivity graph to “tap into” any message stream on
the system. Furthermore, the decoupling between publishers
and subscribers allows for the creation of general-purpose
visualizers. Simple programs can be written which subscribe
to a particular topic name and plot a particular type of data,
such as laser scans or images. However, a more powerful
concept is a visualization program which uses a plugin
architecture: this is done in the rviz program, which is
distributed with ROS. Visualization panels can be dynami- The previous graph was automatically generated by the
cally instantiated to view a large variety of datatypes, such rxgraph tool, which can inspect and monitor any ROS
as images, point clouds, geometric primitives (such as object graph at runtime. Its output renders nodes as ovals, topics as
recognition results), render robot poses and trajectories, etc. squares, and connectivity as arcs.
Plugins can be easily written to display more types of data.
A native ROS port is provided for Python, a dynamically-
typed language supporting introspection. Using Python, a G. Transformations
powerful utility called rostopic was written to filter
messages using expressions supplied on the command line, Robotic systems often need to track spatial relationships
resulting in an instantly customizable “message tap” which for a variety of reasons: between a mobile robot and some
can convert any portion of any data stream into a text stream. fixed frame of reference for localization, between the various
These text streams can be piped to other UNIX command- sensor frames and manipulator frames, or to place frames on
line tools such as grep, sed, and awk, to create complex target objects for control purposes.
monitoring tools without writing any code. To simplify and unify the treatment of spatial frames,
Similarly, a tool called rxplot provides the functionality a transformation system has been written for ROS, called
of a virtual oscilloscope, plotting any variable in real-time as tf. The tf system constructs a dynamic transformation
a time series, again through the use of Python introspection tree which relates all frames of reference in the system.
and expression evaluation. As information streams in from the various subsystems of
the robot (joint encoders, localization algorithms, etc.), the
F. Composition of functionality tf system can produce streams of transformations between
In ROS, a “stack” of software is a cluster of nodes that nodes on the tree by constructing a path between the desired
does something useful, as was illustrated in the navigation nodes and performing the necessary calculations.
example. As previously described, ROS is able to instantiate For example, the tf system can be used to easily generate
a cluster of nodes with a single command, once the cluster point clouds in a stationary “map” frame from laser scans
is described in an XML file. However, sometimes multiple received by a tilting laser scanner on a moving robot. As
instantiations of a cluster are desired. For example, in multi- another example, consider a two-armed robot: the tf system
robot experiments, a navigation stack will be needed for can stream the transformation from a wrist camera on one
each robot in the system, and robots with humanoid torsos robotic arm to the moving tool tip of the second arm of the
will likely need to instantiate two identical arm controllers. robot. These types of computations can be tedious, error-
ROS supports this by allowing nodes and entire roslaunch prone, and difficult to debug when coded by hand, but the
cluster-description files to be pushed into a child namespace, tf implementation, combined with the dynamic messaging
thus ensuring that there can be no name collisions. Essen- infrastructure of ROS, allows for an automated, systematic
tially, this prepends a string (the namespace) to all node, approach.
 V. C ONCLUSION
We have designed ROS to support our philosophy of
modular, tools-based software development. We anticipate
that its open-ended design can be extended and built upon by
others to build robot software systems which can be useful
to a variety of hardware platforms, research settings, and
runtime requirements.
ACKNOWLEDGEMENTS
We thank the fledgeling ROS user community for their
feedback and contributions, especially Rosen Diankov (au-
thor of the ROS Octave library) and Bhaskara Marthi (author
of the ROS LISP library).
R EFERENCES
[1] J. Kramer and M. Scheutz, “Development environments for au-
tonomous mobile robots: A survey,” Autonomous Robots, vol. 22,
no. 2, pp. 101–132, 2007.
[2] M. Quigley, E. Berger, and A. Y. Ng, “STAIR: Hardware and Software
Architecture,” in AAAI 2007 Robotics Workshop, Vancouver, B.C,
August, 2007.
[3] K. Wyobek, E. Berger, H. V. der Loos, and K. Salisbury, “Towards a
personal robotics development platform: Rationale and design of an
intrinsically safe personal robot,” in Proc. of the IEEE Intl. Conf. on
Robotics and Automation (ICRA), 2008.
[4] M. Montemerlo, N. Roy, and S. Thrun, “Perspectives on standardiza-
tion in mobile robot programming: The Carnegie Mellon Navigation
(CARMEN) Toolkit,” in Proc. of the IEEE/RSJ Intl. Conf. on Intelli-
gent Robots and Systems (IROS), Las Vegas, Nevada, Oct. 2003, pp.
2436–2441.
[5] A. Makarenko, A. Brooks, and T. Kaupp, in Proc. of the IEEE/RSJ
Intl. Conf. on Intelligent Robots and Systems (IROS), Nov. 2007.
[6] R. T. Vaughan and B. P. Gerkey, “Reusable robot code and the
Player/Stage Project,” in Software Engineering for Experimental
Robotics, ser. Springer Tracts on Advanced Robotics, D. Brugali, Ed.
Springer, 2007, pp. 267–289.
[7] G. Bradski and A. Kaehler, Learning OpenCV, Sep. 2008.
[8] R. Diankov and J. Kuffner, “The robotic busboy: Steps towards
developing a mobile robotic home assistant,” in Intelligent Autonomous
Systems, vol. 10, 2008.
[9] J. Jackson, “Microsoft robotics studio: A technical introduction,” in
IEEE Robotics and Automation Magazine, Dec. 2007, [Link]
[Link]/en-us/robotics.
[10] O. Michel, “Webots: a powerful realistic mobile robots simulator,” in
Proc. of the Second Intl. Workshop on RoboCup. Springer-Verlag,
1998.