Design and Use Paradigms for Gazebo, An

Open-Source Multi-Robot Simulator

Nathan Koenig, Andrew Howard
Robotics Research Labs, University of Southern California
Los Angeles, CA 90089-0721, USA
Email: [email protected], [email protected]

Abstract— Simulators have played a critical role in robotics ulation is controllable, from lighting conditions to friction
research as tools for quickly and efficiently testing new coefficients.
concepts, strategies, and algorithms. To date, most simulators Following the principles established by Player and Stage,
have been restricted to 2D worlds, and few of have matured
to the point where they are both highly capable and easily Gazebo is completely open source and freely available (a
adaptable. Gazebo is designed to fill this niche by creating major advantage over most commercially available pack-
a 3D dynamic multi-robot environment capable of recreating ages). As a result, Gazebo has an active base of contributers
the complex worlds that will be encountered by the next gen- who are rapidly evolving the package to meet their ever-
eration of mobile robots. Its open source status, fine grained changing needs.
control, and high fidelity place Gazebo in a unique position to
become more than just a stepping stone between the drawing Gazebo offers a rich environment to quickly develop
board and real hardware: data visualization, simulation of and test multi-robot systems in new and interesting ways.
remote environments, and even reverse engineering of black- It is an effective, scalable, and simple tool that has also
box systems are all possible applications. potential for opening the field of robotics research to a
Gazebo is developed in cooperation with the Player wider community; thus, for example, Gazebo is being
and Stage projects [1], [2], [3], and is available from
http://playerstage.sourceforge.net/gazebo/ consider for use in undergraduate teaching.
gazebo.html. This paper describes the basic architecture of the Gazebo
package, and illustrates its use and extensibility through a
I. I NTRODUCTION number of user case-studies. We also give some attention
to future directions for this package.
The Player and Stage projects have been in development
since 2001, during which time they have experienced II. P LAYER AND S TAGE
wide spread usage in both academia and industry. Player
networked device server, and Stage is a simulator for large Gazebo has been developed from the ground up to be
populations of mobile robots in complex 2D domains. A fully compatible with the Player device server. The hard-
natural complement for these two projects is a high fidelity ware simulated in Gazebo is designed to accurately reflect
outdoor dynamics simulator; this has taken form in the the behavior of its physical counterpart. As a result, a client
Gazebo project. program sees an identical interface to a real and simulated
The necessity of Gazebo has been partially realized robot. This feature allows Gazebo to be seamlessly inserted
with the recent addition of number of all-terrain robotic into the development process of a robotic system.
platforms at the Robotics Research Labs at the University Even though it is compatible with Player, Gazebo is
of Southern California. While Stage is quite capable of not meant as a replacement for the Stage simulator. The
simulating the interactions between robots in indoor en- complexity of simulating rigid body dynamics coupled with
vironments, the need for a simulator capable of modeling a 3D environment can severely tax even a high performance
outdoor environments and providing realistic sensor feed- computer. This has the effect of limiting Gazebo to the
back have become apparent. Gazebo, therefore, is designed domain a few robots, currently on the order of 10. On the
to accurately reproduce the dynamic environments a robot other hand, Stage provides a robust and efficient simulator
may encounter. All simulated objects have mass, velocity, for projects that require large robot populations or do not
friction, and numerous other attributes that allow them to require the full capabilities of Gazebo.
behave realistically when pushed, pulled, knocked over, or
III. R ELATED W ORK
carried. These actions can be used as integral parts of an
experiment, such as construction or foraging. Gazebo is far from being the only choice for a 3D
The robots themselves are dynamic structures composed dynamics simulator. It is however one of the few that
of rigid bodies connected via joints. Forces, both angular attempts to create realistic worlds for the robots rather than
and linear, can be applied to surfaces and joints to generate just human users. As more advanced sensors are developed
locomotion and interaction with an environment. The world and incorporated into Gazebo the line between simulation
itself is described by landscapes, extruded buildings, and and reality will continue to blur, but accuracy in terms of
other user created objects. Almost every aspect of the sim- robot sensors and actuators will remain an overriding goal.
 Gazebo World

*
Shared Memory
Client Interface Model
Data/Cmds 0,1 0..n
ands
Comm

* 1..n

Data
Joint Body
*
Sensor
Hinge Slider Box Ray

Ball and Socket Universal

Camera Laser
Plane Sphere
Odometer
Hinge 2−axis Cylinder

Open Dynamics Engine Open Scene Graph

Fig. 1. General Structure of Gazebo components

A few notable systems include COSIMIR [4], developed IV. A RCHITECTURE

at Festo. This is a commercial package primarily designed
Gazebo’s architecture has progressed through a couple
for industrial simulation of work flows with robotic sys-
iterations during which we learned how to best create a
tems, but is also applicable to robotic research. COSIMIR
simple tool for both developers and end users. We realized
has advanced modeling and physical simulation capabil-
from the start that a major feature of Gazebo should be
ities that go well beyond the capabilities of Gazebo. It
the ability to easily create new robots, actuators, sensors,
incorporates many types of grippers, the ability to program
and arbitrary objects. As a result, Gazebo maintains a
movement in non-robotic models such as assembly lines,
simple API for addition of these objects,which we term
and has tools for analysis of the simulated systems. Another
models, and the necessary hooks for interaction with client
commercial package is Webots [5] created by Cyberbotics.
programs. A layer below this API resides the third party
Webots allows for the creation of robots using a library of
libraries that handle both the physics simulation and visu-
predefined actuators and sensors. When system testing in
alization. The particular libraries used were chosen based
the simulator is complete, a user can transfer their code to
on their open source status, active user base, and maturity.
real robots. The principle purpose of Webots is research
This architecture is graphically depicted in Figure 1.
and development. Cyberbotics is also developing a Player
The World represents the set of all models and environ-
interface for compatibility with a wider range of devices.
mental factors such as gravity and lighting. Each model
is composed of at least one body and any number of
joints and sensors. The third party libraries interface with
Darwin2K [6] and OpenSim [7] represent two open Gazebo at the lowest level. This prevents models from
source robot simulators developed along similar lines as becoming dependent on specific tools that may change in
Gazebo. Darwin 2K was created by Chris Leger at Carnegie the future. Finally, client commands are received and data
Mellon University as a tool for his work on evolution- returned through a shared memory interface. A model can
ary robotics. This simulator accurately models motor and have many interfaces for functions involving, for example,
gear heads in fine detail while providing stress estimates control of joints and transmission of camera images.
on structural bodies. Darwin2K has a strong focus on
evolutionary synthesis, design, and optimization and still A. Physics Engine
remains a capable general purpose simulator for dynamic The Open Dynamics Engine [8], created by Russel
systems. OpenSim, under development by David Jung, is Smith is a widely used physics engine in the open source
a generic open source robot simulator similar in design community. Its is designed to simulate the dynamics
an purpose to Gazebo. This simulator makes use of the and kinematics associated with articulated rigid bodies.
same third party software packages as Gazebo, and has This engine includes many features such as numerous
some attractive features for constructing and debugging joints, collision detection, mass and rotational functions,
articulated joint chains. and many geometries including arbitrary triangle meshes
 Cylinder

Final Model

Box

Hinge Joint
Fig. 2. Pioneer2 AT construction. Actual Pioneer 2AT shown for comparison.

(Figure 6). Gazebo utilizes these features by providing a lines. Each body has an assigned mass, friction, bounce
layer of abstraction situated between ODE and Gazebo factor, and rendering properties such as color, texture,
models. This layer allows easy creation of both normal transparency, etc.
and abstract objects such as laser rays and ground planes Joints provide the mechanism to connect bodies together
while maintaining all the functionality provided by ODE. to form kinematic and dynamic relationships. A variety
With this internal abstraction, it is possible to replace of joints are available including hinge joints for rotation
the underlying physics engine, should a better alternative along one or two axis, slider joints for translation along a
become available. single axis, ball and socket joints, and universal joints for
rotation about two perpendicular joints. Besides connecting
B. Visualization
two bodies together, these joints can act like motors. When
A well designed simulator usual provides some form a force is applied to a joint, the friction between the
of user interface, and Gazebo requires one that is both connected body and other bodies cause motion. However,
sophisticated and fast. The heart of Gazebo lies in its ability special care needs to be taken when connecting many joints
to simulate dynamics, and this requires significant work on in a single model as both the model and simulation can
behalf of the user’s computer. A slow and cumbersome user easily loose stability if incorrect parameters are chosen.
interface would only detract from the simulator’s primary Interfaces provide the means by which client programs
purpose. To account for this, the Open Scene Graph[9] can access and control models. Commands sent over an
library was chosen as the default visualization tool. interface can instruct a model to move joints, change the
As the name implies, Open Scene Graph implements configuration of associated sensors, or request sensor data.
a standard scene graph that is both fast and robust. The The interfaces do not place restrictions on a model, thereby
project was first started by Don Burns in 1998 and has allowing the model to interpret the commands in anyway
since grown to become an adept tool. The scene graph uses it sees fit.
OpenGL as its rendering library, and implements a light-
2) Sensors: A robot can’t perform useful tasks without
weight wrapper around it. The benefits of the Open Scene
sensors. A sensor in Gazebo is an abstract device lacking
Graph library to Gazebo include a simplified interface to
a physical representation. It only gains embodiment when
OpenGL, fast rendering environment, the ability to import
incorporated into a model. This feature allows for the reuse
and export many data formats.
of sensors in numerous models thereby reducing code and
C. The World confusion.
A complete environment is essentially a collection of There currently are three sensor implementations includ-
models and sensors. The ground and buildings represent ing an odometer, scanning laser range finder, and a camera.
stationary models while robots and other objects are dy- Odometry is easily accessible through integration of the
namic. Sensors remain separate from the dynamic simula- distance traveled. The scanning laser range finder utilizes
tion since they only collect data, or emit data if it is an 361 rays to simulate scans and has been incorporated
active sensor. into a model representing the Sick LMS200. Finally, the
The following is a brief description of each general camera in Gazebo is fairly simple as its only requirement
component involved in the simulator. is to render a scene from the perspective of the model its
1) Models, Bodies, and Joints: A model is any object attached to.
that maintains a physical representation. This encompasses 3) External Interfaces: Gazebo is generally used in
anything from simple geometry to complex robots. Models conjunction with Player. The Player device server treats
are composed of at least one rigid body, zero or more joints Gazebo as a normal device capable of sending and re-
and sensors, and interfaces to facilitate the flow of data. ceiving data. From the users point of view, the models
Bodies represent the basic building blocks of a model. simulated in Gazebo are the same as there real counterparts.
Their physical representation take the form of geometric A second key advantage to this approach is that one can
shapes chosen from boxes, spheres, cylinders, planes, and use abstract drivers inside a simulation. For example, it
 Fig. 3. Above is a hand-drawn 2d map, the 3D extrusion created from the 2D map, and finally the laser generated map of the real environment.

is possible to use Player’s VFH (Vector Field Histogram) The first case increased the efficiency at which a complete
[10] or AMCL (Adaptive Monte-Carlo Localization) [11] robot system is built, another used Gazebo for greater
interchangeably between real and simulated environments. safety while demonstrating a useful technique at reverse
The interface to Gazebo is not limited to Player alone. engineering a robot system, and the final two demonstrate
The low-level library provides a mechanism for any third- the use of Gazebo in developing and refining new algo-
party robot device server (Player or otherwise) to interface rithms.
with Gazebo. Going even further, a connection to the the
library is not even necessary since Gazebo can be run A. Morphology and Control
independently for rapid model and sensor development. The development of new robotic architectures involve a
Currently the Gazebo library offers hooks to set wheel chicken and egg problem. Is it better to develop a control
velocities, read data from a laser range finder, retrieve system to match the hardware, or the hardware to match
images from a camera, and insert simple objects into the the required controller? A solution to this problem is rapid
environment at runtime. This data is communicated through prototyping where new iterations of both hardware and
shared memory for speed and efficiency. software are developed and tested in unison. This has the
benefit of revealing the strengths and weakness in both
D. Construction of Models parts with minimal loss of time and effort when mistakes
Currently, models are created by hand. The process occur. Prototyping of this nature has long been used in
starts with choosing the appropriate bodies and joints the software domain, but still remains expensive and slow
necessary to build an accurate model in both appearance in hardware. Gazebo solves this problem by providing
and functionality. Following Figure 2, we will use the means to easily change the robot’s morphology while also
construction of the Pioneer2 AT model as an example. The modifying its software systems.
entire set of bodies for this model encompass four cylinders This design principle was realized in a recent project
for the wheels and a rectangular box body. [12] at USC. The task involved the creation of a six legged
The next step attaches the bodies together using joints. walking robot that learned various gaits. The process of
The end result is a complete physical representation of our designing and building the hardware alone would have
model. For the Pioneer2 AT, each wheel has a single axis consumed numerous months. Instead Gazebo reduced the
of rotation. Hinge joints match this requirement perfectly. time frame down to less than two months, during which
They are connected to the sides of the rectangular base and time both the physical structure and software were modified
the wheels such that the axis of rotation allows for proper and tested in parallel. Clearly, use of this feature allows
wheel spin. developers to easily move from basic concepts to real
Our Pioneer2 AT model now only lacks an interface working systems in a short period of time.
for user control. A few functions provided by the Gazebo
library resolve this issue, and allow a user to apply velocity B. Reverse Engineering
changes to the wheels and retrieve odometric data. The A recent addition to the Robotics Research Labs at USC
Pioneer2 AT model is noticeably missing the onboard has been a Segway RMP. This is a physically powerful
sonar. This is due to the current lack of a sonar sensor device initially intended to transport humans that has been
in Gazebo. modified to be a robot platform. Over rough terrain, this
robot will sometimes topple, and is therefore quite danger-
V. C ASE S TUDIES ous to both people and the expensive hardware mounted on
Although still a young application, Gazebo has been it. A method to avoid undue damage during software devel-
used in many interesting ways that have been unavailable opment involves rigorous testing in simulation. However,
in other simulators. These techniques can be generally creating a realistic model of the Segway RMP offers unique
characterized by an improved robot development process. challenges. In order to move, the Segway RMP it must tilt
 after which the real maps were ported back into Gazebo
for further off-line experiments.
As a result, the development time of the algorithms
employed was greatly reduced. Gazebo made it possible to
continue experimentation in the environment even after the
physical robots were deployed. In this case a simple sketch
map created a sufficient testing environment, however
greater accuracy can be achieved with access to terrain
data. Elevation information collected from satellites, or
other means, can be imported along with relevant structures
to further blur the line between simulation and the real
Fig. 4. Above is a real Segway RMP and its model in Gazebo below.
world. All of this culminates in the ability of Gazebo
to reduce development and test time, and even allow
experiments to virtually take place in almost any part of
forward or back to gain acceleration (it is essentially an
the world.
inverse pendulum). This tilting affects the interactions it
has with the world and particularly the data received from D. Algorithm Design
any on-board sensors. It is therefore imperative that any The design and implementation of new algorithms can
model used to simulate the Segway RMP must accurately be a difficult task that become particularly acute with
reflect these characteristics. the lack of a convenient test environment. In situations
To overcome this problem, Marin Kobilarov reverse such as this, Gazebo’s sensory realism can play a time
engineered the controller used on-board the Segway RMP. saving role. Traditionally, development of new algorithms
This was accomplished by extensively testing the angles either required custom simulators or direct testing on
of inclination at various accelerations. The results from the hardware; Gazebo’s realistic environments and simple
these tests were used to tune a controller in Gazebo that interface can drastically reduce the turn around time from
now successfully models the characteristics of the real a conceptual stage to functional system.
Segway RMP (see Figure 4). This technique was used in the creation of a new sensing
Reverse engineering is a common practice when trying device; a visual bar code reader. The purpose of this
to understand how black-box systems operate. In this device was to identify uniquely marked objects in arbitrary
case it was necessary as a safety precaution. In other environments (a black and white bar code system was
situations it may simply be impossible to have a control chosen based on its simplicity, Figure 5). Gazebo was used
scheme specified. In the case of human-robot or even robot- as the sole test platform, and a visual barcode detector
animal interaction, models can only be created through was rapidly developed and tested. Following satisfactory
observations of their behaviors. Gazebo in turn provides an performance in Gazebo, the system ran unmodified on
effective mechanism to implement and test these derived a real robot with near identical results. This algorithm
models. has since been proved robust in a wide range of real
environments.
C. New Environments
Many environments in which robots operate are either
well studied or carefully constructed. Deploying robots in
a never before encountered world may cause unforeseen,
and possibly negative, side effects. Lighting conditions,
reflective surfaces, and odd objects can all play an effect on
how a robot operates. A strategy of online testing can be
extremely slow and tedious. Time can be spent much more
productively by testing and modifying the robot controllers
offline in preparation for the real experiments.
The fine grained control of Gazebo, the ability to ex- Fig. 5. A sample bar-code fiducial for visual object recognition.
trude 2D images into 3D structures, and terrain generation
(Figure 6) allow for the unique ability to hand create
rough outlines of a new environment. This technique was VI. L IMITATIONS
recently realized and employed by Andrew Howard, and Gazebo has a number of important limitations. While
demonstrated in Figure 3. When moving into a new envi- it is designed as an outdoor simulator, the fidelity of this
ronment, he first used a sketch of the test site to extruded simulation is limited; for example, physics models of soil,
a model in Gazebo. This simulated environment was then sand, grass, and other pliable surfaces normally found in
used as one of test environments during the development of nature are well beyond the scope of this project. Added
his exploration and mapping algorithms. These algorithms to this list of have-nots are deformable objects, fluid and
were later successfully deployed in the real environment, thermal dynamics. These features are currently lacking in
Gazebo due to their complexity, although some may be
added as the need arises.
Distributed computation tops the list of more useful
features missing from Gazebo. The amount of computation
involved while running such an intensive simulation would
greatly benefit from distributed computation. This has the
possibility of becoming a reality in the future, but currently
presents practical problems due to the used of a monolithic
dynamics engine.

VII. C ONCLUSION AND F UTURE W ORK

This paper has explained the design principles of Gazebo

and its applicability to the development process of real
world robotics. Our software has deliberately maintained
a simple yet powerful interface to the underlying physics
engine and rendering capabilities while retaining com-
Fig. 6. Terrain and Pioneer2 AT robots.
patibility with the Player and Stage initiatives. This has
resulted in a quick and easy adoption of Gazebo by many
people, and has the potential to be used in ways never [3] R. T. Vaughan, B. P. Gerkey, and A. Howard, “On device
before seen in a simulator. abstractions for portable, reusable robot code,” in IEEE/RSJ
There however remains much work to be done. While International Conference on Intelligent Robots and Systems, Las
Vegas, Nevada, U.S.A, Oct 2003, pp. 2121–2427, (Also Technical
the breadth of robot models has grown rapidly, sensor Report CRES-03-009). [Online]. Available: http://cres.usc.edu/
implementations remain relatively few, primarily due to im- cgi-bin/print˙pub˙details.pl?pubid=346
plementation complexity. Features such as programmable [4] http://www.festo.com.
[5] http://www.cyberbotics.com.
objects (doors, elevators, lights) and multi-level image [6] C. Leger, Darwin2K: An Evolutionary Approach to AUtomated
extrusion will add even more realism and increase the Design for Robotics. Kluwer Academic Publishers, Aug 2000.
domains in which Gazebo is applicable. Finally, real-time [7] http://opensimulator.sourceforge.net/.
[8] http://opende.sourceforge.net/.
interaction will eventually provide mechanisms for on-the- [9] http://openscenegraph.org/.
fly alterations to test scenarios through addition of user [10] I. Ulrich and J. Borenstein, “Vfh*: Local obstable avoidance
specified forces and commands. with look-ahead verification,” in IEEE International Conference on
Robotics and Automation, San Francisco, CA, Apr 2000, pp. 2505–
In the relatively short life span of Gazebo, we have 2511.
seen adaption and contributions from other universities and [11] D. Fox, “KLD-sampling: Adaptive particle filters,” in Advances in
creative uses of Gazebo as not just a simulator but also a Neural Information Processing Systems 14. MIT Press, 2001.
[12] http://www-robotics.usc.edu/˜dshell/hex/hex.html.
safety device. It is our hope that this simulator will continue
to provide a valuable tool for current researchers, and also
inspire people who lack expensive hardware to perform
new and interesting experiments.

ACKNOWLEDGMENTS

The authors would like to thank Dylan Shell, Gabriel

Sibley, and Marin Kobilarov for their creative use of
Gazebo. Many thanks also to the excellent contributions
from Pranav Srivastava at the University of Pennsylvania.

R EFERENCES

[1] B. P. Gerkey, R. T. Vaughan, and A. Howard, “The player/stage

project: Tools for multi-robot and distributed sensor systems,” in
Proceedings of the International Conference on Advanced Robotics,
Coimbra, Portugal, Jul 2003, pp. 317–323. [Online]. Available:
http://cres.usc.edu/cgi-bin/print˙pub˙details.pl?pubid=288
[2] B. P. Gerkey, R. T. Vaughan, K. Støy, A. Howard, G. Sukhatme,
and M. J. Matarić, “Most valuable player: A robot device server
for distributed control,” in IEEE/RSJ International Conference on
Intelligent Robots and Systems, 2001, pp. 1226 – 1231, (Also
appears in Proceedings of the Second International Workshop on
Infrastructure for Agents, MAS, and Scalable MAS at Autonomous
Agents 2001, Montreal, Canada, May 29, 2001). [Online].
Available: http://cres.usc.edu/cgi-bin/print˙pub˙details.pl?pubid=91