To appear in: IEEE Robotics & Automation Magazine, December 2012.
1
The Open Motion Planning Library
Ioan A. Şucan, Member, IEEE, Mark Moll, Member, IEEE, and Lydia E. Kavraki, Senior Member, IEEE
Abstract—We describe the Open Motion Planning Library
(OMPL), a new library for sampling-based motion planning,
which contains implementations of many state-of-the-art planning algorithms. The library is designed in a way that allows
the user to easily solve a variety of complex motion planning
problems with minimal input. OMPL facilitates the addition
of new motion planning algorithms and it can be conveniently
interfaced with other software components. A simple graphical
user interface (GUI) built on top of the library, a number
of tutorials, demos and programming assignments have been
designed to teach students about sampling-based motion planning. Finally, the library is also available for use through the
Robot Operating System (ROS).
Index Terms—motion planning, sampling-based planning,
robotics software, OMPL, ROS, open source robotics, teaching
robotics
R
I. I NTRODUCTION
Early results have shown the motion planning problem to
be PSPACE-complete [9], and existing complete algorithms
are difficult to implement and computationally intractable.
For this reason, more recent efforts focus on approaches with
weaker completeness guarantees. One of these approaches
is that of sampling-based motion planning, which has been
used successfully to solve difficult planning problems for
robots of practical interest. Many sampling-based algorithms
are probabilistically complete: a solution will eventually be
found with probability 1 if one exists, but the non-existence
of a solution cannot be reported (see, e.g., [10]–[13]).
Many of the core concepts in sampling-based motion
planning are relatively easy to explain, but implementing
sampling-based motion planning algorithms in a generic
way is non-trivial. This paper describes the Open Motion
Planning Library (OMPL, http://ompl.kavrakilab.org), an
open source C++ implementation of many sampling-based
algorithms (such as the Probabilistic Roadmap Method
(PRM) [14], Rapidly-expanding Random Trees (RRT) [15],
Kinodynamic Planning by Interior-Exterior Cell Exploration
(KPIECE) [16] and many more) and the core low-level data
structures that are commonly used. OMPL includes Python
bindings that expose almost all functionality to Python users.
This library is aimed at three different audiences:
OBOTIC devices are steadily becoming a significant
part of our daily lives. Search and rescue robots, service
robots, surgical robots and autonomous cars are examples of
robots most of us are familiar with. Being able to find paths
(motion plans) efficiently for such robots is critical for a
number of real-world applications (Figure 1). For example,
in urban search-and-rescue settings a small robot may need
to find paths through rubble and semi-collapsed buildings
• motion planning researchers,
to locate survivors. In domestic settings it would be useful
• robotics educators, and
if a robot could, e.g., put away kids’ toys, fold the laundry,
• end users in the robotics industry.
and load the dishwasher. Motion planning also plays an
increasingly important role in robot-assisted surgery. For Below, we will characterize the needs of these different
example, before a flexible needle is inserted or an incision is audiences.
made, a path can be computed that minimizes the chance of
Within the robotics community, it is often challenging
hurting vital organs. More generally, motion planning is the to demonstrate that a new motion planning algorithm is
problem of finding a continuous path that connects a given an improvement over existing methods according to some
start state of a robotic system to a given goal region for that metric. First, it is a substantial amount of work for a
system, such that the path satisfies a set of constraints (e.g., researcher to implement not only the new algorithm, but also
collision avoidance, bounded forces, bounded acceleration). one or more state-of-the-art motion planning algorithms to
This paper describes an open source software library for compare against. Ideally, implementations of low-level data
motion planning, designed for research, educational and structures and subroutines used by these algorithms (e.g.,
industrial applications.
proximity data structures) are shared, so that only differences
Although most of the work done towards the development of the high-level algorithm are measured. Second, for an
of algorithms that solve the motion planning problem comes accurate comparison, one needs a known set of benchmark
from robotics and artificial intelligence [1]–[3], the problem problems. Finally, collecting various performance metrics for
can be viewed more abstractly as search in continuous spaces. several planners with different parameter settings, running
As such, the applications of motion planning extend beyond on several benchmark problems and storing them in a way
robotics to fields such as computational biology [4]–[7] and that facilitates easy analysis afterwards is a non-trivial task.
computer-aided verification [8], among others.
We as developers of planning algorithms have run into the
issues above many times. We designed OMPL to help with
I. Şucan is with Willow Garage, Menlo Park, CA 94025. M. Moll and
L. Kavraki are with the Department of Computer Science at Rice University, all these issues, and make it easier to try out new ideas.
Houston, TX 77005, USA. Email: {isucan,mmoll,kavraki}@rice.edu. This Moreover, the library is designed in a way that facilitates
work was performed when I. Şucan was with the Department of Computer
contributions from other motion planning researchers and
Science, Rice University.
Manuscript received xxxxxx; revised xxxxxx.
provides benchmarking capabilities to easily compare new
2
(a)
(b)
(c)
Fig. 1. Real world applications of motion planning. (a) An urban search-and-rescue robot from Carnegie Mellon University’s Biorobotics Lab. (b)
The HERB robot from Carnegie Mellon University’s Personal Robotics Lab picking up a bottle. (c) A PR2 robot folding laundry in UC Berkeley’s
Robotics Learning Lab. Images used with permission from Prof. Choset, Prof. Srinivasa, and Prof. Abbeel, respectively.
planners against all other planners implemented in OMPL
(see Box 1). We have developed a streamlined process
that gives contributing researchers appropriate credit and
minimizes the burden of writing code that satisfies our
library’s application programmers interface (API). At the
same time, our aim is to make such contributions easily
available to users of OMPL. This is achieved by releasing
the code under the Berkeley Software Distribution (BSD)
license (one of the least restrictive Open Source licenses),
releasing frequent updates, and making the code available
through a public repository. To foster a community of OMPL
users and developers we have set up a mailing list, blog,
and a Facebook page.
For robotics educators, we have designed a series of
exercises/projects around OMPL aimed at undergraduate
students. These exercises help students realize what the
complexity of motion planning means in practice, develop
an understanding of how sampling-based motion planning
algorithms work, and learn to evaluate the performance of
planners. We have also designed open-ended projects for
undergraduate and graduate students. OMPL is structured to
have a clear mapping between the motion planning concepts
used in the literature and the classes that are defined in
the implementation. The separation between abstract base
classes that only specify the interface and derived classes
that implement the specified functionality also helps students
understand general concepts in motion planning before
focusing on details.
From the beginning, OMPL was intended to be useful in
practical applications. This requires that planning algorithms
can solve motion planning problems for systems with many
degrees of freedom at interactive speeds. An additional
requirement is the ability to cleanly integrate OMPL with
other software components on a robot, such as perception,
kinematics, control, etc. Through a collaboration with Willow
Garage, OMPL is integrated within ROS [17] and serves as
the motion planning back-end for the arm planning software
stack. The availability of OMPL in ROS makes it easy for
end users in the robotics industry to stay up-to-date with
advances in sampling-based motion planning.
The rest of the paper is organized as follows. Section II
gives some background on sampling-based motion planning and existing software packages for motion planning.
Sections III and IV include an overview and lower level
details about OMPL. Integration with other software systems
is described in Section V, and finally, a discussion is in
Section VI.
II. BACKGROUND
There has been much work done towards both algorithm
development and software development for motion planning.
This paper only discusses aspects pertaining to samplingbased motion planning.
A. Sampling-based Motion Planning: Definitions
Sampling-based motion planning algorithms relaxed completeness guarantees and demonstrated that many interesting
problems can be solved efficiently in practice, despite the
the theoretically high complexity of the problem [2], [3].
The fundamental idea of sampling-based motion planning
is to approximate the connectivity of the search space with
a graph structure. The search space is sampled in a variety
of ways, and selected samples end up as the vertices of
the approximating graph. Edges in the approximating graph
denote valid path segments.
There are two key considerations in the construction of
the graph approximation: the probability distribution used
for sampling states and the strategy for generating edges. An
enormous amount of research has been performed towards
the development of efficient algorithms that account for these
issues [18].
We will not go into the details of various samplingbased motion planning algorithms, as such details can be
found elsewhere [2], [3]. Instead, we describe the common
components sampling-based algorithms typically depend on,
as these relate to the implementations of such algorithms:
• State space Points in the state space (or configuration
space) fully describe the state of the system being
planned for. For a free-flying rigid body, the state space
consists of all translations and rotations, while for a
3
Box 1: Benchmarking with OMPL
benchmark problems and report performance metrics for
various planners on those problems.
(sec.)
A seemingly simple but often ignored part of motion planning
software is benchmarking planning code. OMPL includes
benchmarking capabilities (through a class called Benchmark) that can be simply dropped in and applied to existing
planning contexts. In very simple terms, a Benchmark
object runs a number of planners multiple times on a
user specified planning context. Although simple, this code
automatically keeps track of all the used settings and takes
all the possible measurements during planning (currently,
tens of parameters are recorded for every single motion
plan). The recorded information is logged and can be postprocessed using a Python script included with OMPL. The
script can produce MySQL databases with all experiment
data so that the user can write their own queries later
on, but it can also automatically generate plots for all
of the performance metrics. For real- and integer-valued
measurements it generates box plots: plots that include
information about the median, confidence intervals and
outliers. An example is shown in the figure on the right.
For binary-valued measurements it generates bar plots.
A more elaborate example of what can be done with the
Benchmark class can be found at http://plannerarena.org,
a web site currently being developed to establish standard
Figure S1. A sample box plot generated by OMPL’s benchmark script.
manipulator with n rotational joints the state space can com) provides commercial motion planning software for
be modeled by an n-dimensional torus.
academic research and industrial applications. In 2007, our
• Control
space A control space represents a group released the Object-Oriented Programming System
parametrization of the space of controls. This is only for Motion Planning (OOPSMP) [20], which is no longer
required for systems with dynamics. For most systems maintained.
of practical interest, one can think of the control space
for a system with m controls simply as a subset of Rm .
For geometric planning no controls are used.
Another software package that is complementary to
• Sampler A sampler is needed to generate different
OMPL is OpenRAVE [21]. OpenRAVE is open source,
states from the state space. For control-based systems,
actively developed, and it is widely used. It is important
a separate sampler is needed for sampling different
to understand the difference in design philosophy behind
controls. Some planning algorithms (e.g., [12], [16])
OMPL and OpenRAVE. OpenRAVE is designed to be a
only require a control sampler and do not need a state
complete package for robotics. It includes, among other
sampler.
things: geometry representation, collision checking, grasp
• State validity checker A state validity checker is a
planning, forward and inverse kinematics for several robots,
routine that distinguishes the valid part of the state space
controllers, motion planning algorithms, simulated sensors,
from the invalid part of the state space. For example,
visualization tools, etc. OMPL, on the other hand, was
a state validity checker can check for collisions and
designed to focus completely on sampling-based motion
whether velocities and accelerations are within certain
planning with a clear mapping between theoretical concepts
bounds.
in the literature and abstract classes in the implementation.
• Local planner When planning with controls, the local
This high level of abstraction makes it easy to integrate
planner is a means of computing the evolution of the
OMPL with a variety of front-ends and other libraries. Some
robotic system forward (and sometimes backward) in
integration examples are described in Section V. To some
time. When planning solely under geometric constraints,
extent, the integration with ROS [17] gives a user many of
the local planner often performs interpolation between
OpenRAVE’s features that are purposefully not included in
states in the state space.
OMPL. It may also be possible to use OMPL as a motion
planning plugin in OpenRAVE. As a result of the narrower
B. Software Packages for Motion Planning
focus in OMPL, we have been able to spend more resources
Several other packages for motion planning are available. on implementing a much broader variety of sampling-based
Some, such as the Motion Strategies Library (MSL, http: algorithms than what is currently available in OpenRAVE,
//msl.cs.uiuc.edu), the Motion Planning Kit (MPK, http:// as well as benchmarking capabilities to facilitate a thorough
robotics.stanford.edu/∼mitul/mpk), and VIZMO++ [19] are comparison of existing and future sampling-based motion
no longer maintained. KineoWorks (http://www.kineocam. planners.
4
only when planning with differential constraints
ControlSampler
Implements sampling of controls
for a specific ControlSpace.
DirectedControlSampler
Sample controls that take the
system towards a desired state.
ControlSpace
Represents the control
space the planner uses to
represent inputs to the
system being planned for.
StateSpace
Represents the state space in
which planning is performed;
implements topology-specific
functions: distance, interpolation, state (de)allocation.
ProjectionEvaluator
StatePropagator
Computes projections from
states of a specific StateSpace to a low-dimensional
Euclidean space.
Returns the state obtained
by applying a control to
some arbitrary initial state.
MotionValidator
Provides the ability to check
the validity of path segments
using the interpolation
provided by the StateSpace.
SpaceInformation
Provides routines typically used
by motion planners; combines
the functionality of classes it
depends on.
StateValidityChecker
Decides whether a given state
from a specific StateSpace
is valid.
Path
ValidStateSampler
Representation of a path;
used to represent a solution
to a planning problem.
Provides the ability to sample
valid states.
SimpleSetup
Planner
Solves a motion
planning problem.
StateSampler
Implements uniform and
Gaussian sampling of states
for a specific StateSpace
Provides a simple way
of setting up all needed
classes without limiting
functionality.
ProblemDefinition
Specifies the instance of the
planning problem; requires
definition of start states and a
goal.
Goal
Representation
of a goal.
User must instantiate this class.
User code
User must instantiate this class unless SimpleSetup is used.
User can instantiate this class, but defaults are provided.
A
B A is owned by B.
Fig. 2. Overview of OMPL structure. Class names correspond to well understood concepts in sampling-based motion planning. More detailed
documentation is available at http://ompl.kavrakilab.org.
C. Relationship to Other Robotics Software
III. C ONCEPTUAL OVERVIEW OF OMPL
OMPL is intended for use in research and education, as
There have also been many efforts to create robot well as in industry. For this reason, the main design criteria
simulators such as Player/Stage [22], Player/Gazebo [23], for OMPL were:
Webots [24], and MORSE [25]. Microsoft Robotics Devela) Clarity of concepts: OMPL was designed to consist
oper Studio [26] also contains a robot simulator. Typically, of a set of components as indicated in Figure 2, such that
such simulators do not include motion planning algorithms, each component corresponds to known concepts in samplingbut they can provide a controlled simulated environment to based motion planning.
test motion planners in various environments, on various
b) Efficiency: OMPL has been implemented entirely
robots with different sensing and communication capabilities. in C++ and is thread-safe.
They often simulate the dynamics of the world (including
c) Simple integration with other software packages:
the robots themselves) using physics engines such as Bullet To facilitate the integration with other software libraries,
(http://bulletphysics.org) and the Open Dynamics Engine OMPL offers abstract interfaces that can be implemented by
(http://ode.org), among others.
the “host” software package. Furthermore, the dependencies
Hardware platforms typically require complex software of OMPL are minimal: only the Boost C++ libraries are
configurations and use various forms of middleware to required. Optionally, OMPL can be compiled with Python
accommodate this requirement (e.g., ROS [17], Orocos bindings, which facilitates integration with Python modules.
d) Straightforward integration of external contributions:
(http://www.orocos.org), OpenRTM-aist [27], OPRoS [28],
Yarp [29]). Such software systems typically include their We strive for minimalist API constraints for planning
own visualization system, collision checking, etc. OMPL fits algorithms, so that new contributions can be easily integrated.
naturally and easily into such systems as it only provides
As opposed to all other existing motion planning softsampling-based motion planning and its abstract interface ware libraries, OMPL does not include a representation
should be able to accommodate a variety of low-level of workspaces or of robots; as a result, it also does not
implementations.
include a collision checker or any means of visualization.
5
OMPL is reduced to only motion planning algorithms. The construct a CompoundStateSpace with the two arms and
advantage of this minimalist approach is that it allows us the mobile base as sub-state spaces. An arm typically has a
to design a library that can be used for generic search number of rotational joints and can be modeled by either
in high-dimensional continuous spaces subject to complex a RealVectorStateSpace (if the joints have limits) or a
constraints. Instead of defining valid states as collision-free, CompoundStateSpace with copies of SO(2). The state space
which would require a specific geometric representation for the base can simply be SE(2) (the space rigid body
of the environment and robot as well as support for a transformations in the plane).
State spaces optionally include specifications of prospecific collision checker, OMPL leaves the definition of
state validity completely up to the user (or the software jections to Euclidean spaces (ProjectionEvaluator). Lowpackage in which OMPL is integrated; see Section II-C). dimensional Euclidean projections are used by several
This gives the user enormous design freedom: the user can sampling-based planning algorithms (e.g., KPIECE [16],
defer collision checking to a physics engine, write a state SBL [30], EST [12]) to guide their search for a feasible
sampler that constructs only valid states, or define state path, as it is much easier to keep track of coverage (i.e.,
validity in completely arbitrary ways that may or may not which areas have been sufficiently explored and which areas
should be explored further) in such low-dimensional spaces.
depend on geometry.
In addition to states and state spaces, some algorithms
To make OMPL as easy to use as possible, various paramin
OMPL require a means to represent controls. Control
eters needed for tuning sampling-based motion planners are
spaces
(ControlSpace) mirror the structure of state spaces
automatically computed. The user has the option to override
and
provide
functionality specific to controls, so that planning
defaults, but that is not a requirement.
algorithms can be implemented in a generic way. The only
available implementations of control spaces are the Euclidean
IV. I MPLEMENTATION OF C ORE C ONCEPTS
space and a space for discrete modes, because so far there
Below we will give an overview of the implementation
has not been a need for control spaces with more complex
of the core motion planning concepts in OMPL. Figure 2
topologies. However, the API allows one to define such
gives a high-level overview of the main classes and their
control spaces.
relationships. We will use the following notation. Classes
are written in a sans-serif font (e.g., StateSpace), while B. State Validation and Propagation
methods and functions are written in a monospaced font
Whether a state is valid or not depends on the planning
(e.g., isSatisfied()). For conciseness, the arguments to
context.
In many cases state validity simply means that a
methods and functions are omitted.
robot is not in collision with any obstacles, but in general
any condition on a state can be used. In OMPL.app (see
A. States, Controls, and Spaces
section V-A) we have predefined a state validity checker for
To maximize the range of application for the included rigid body motion planning. We have also implemented
planning algorithms, OMPL represents the search spaces, i.e., a state validity checker that uses the Open Dynamics
the state spaces (StateSpace), in a generic way. State spaces Engine (see Box 2). If these built-in state validity checkers
include operations on states such as distance evaluation, test cannot be used for the system of interest, a user needs to
for equality, interpolation, as well as memory management implement their own. Based on a given state validity checker,
for states: (de)allocation and copying. Additionally, each state a default MotionValidator is constructed that checks whether
space has its own storage format for states, which is not the interpolation between two states at a certain resolution
exposed outside the implementation of the state space itself. produces states that are all valid. However, it possible to plug
To operate on states, the planning algorithms implemented in in a different MotionValidator. For example, one might want
OMPL rely only on the generic functionality offered by state to add support for continuous collision checking, which can
spaces. This approach enables planning algorithms in OMPL adaptively check for collisions and provide exact guarantees
to be applicable to any state spaces that may be defined, as for state validity [31].
long as the expected generic functionality is provided.
For planning with controls a user needs to specify how
Furthermore, OMPL includes a means of combining state the system evolves when certain controls are applied for
spaces using the class CompoundStateSpace. A combined some period of time starting from a given state. This is
state space implements the functionality of a regular state called state propagation in OMPL. In the simplest case, a
space on top of the corresponding functionality from the state propagator is essentially a lightweight wrapper around
maintained set of state spaces. This allows trivial construction a numerical integrator for systems of the form q̇ = f (q, u),
of more complex state spaces from simpler ones. For example where q is a state vector and u a vector of controls. To
SE3StateSpace (the space of rigid body transformations facilitate planning for such systems, we have implemented
in 3D) is just a combination of SO3StateSpace (the generic support for ODE solvers and we have integrated
space of rotations) and RealVectorStateSpace (the space Boost.Odeint [32], a new library for solving ODEs. Given a
of translations). Instances of CompoundStateSpace can be user-provided function that implements f (q, u) for the system
constructed at run time, which is necessary for constructing of interest, OMPL can plan for such systems. Alternatively,
a state space from an input file specification, as is done, one can use variational integrators [33], or a physics engine
for example, in ROS. For a mobile manipulator one could to perform state propagation.
6
Box 2: Motion Planning Using a Physics Engine
OMPL has built-in support for using the Open Dynamics
Engine (ODE) physics engine. Support for other physics
engines such as Bullet is planned for a future release. We
expect that the approach described below can be followed
for these physics engines (and others) as well.
The ODE state space consists of the state spaces of
the robot and any movable objects in the environment. The
user specifies which joints are controlled by the planner and
maps those to a ControlSpace. The user can also specify
which collisions are allowed (e.g., contact with the support
plane) and which ones are not (such as driving into a wall).
This simple setup allows one to plan for systems that are
difficult to describe with differential equations. The user does
not need to worry about all the different possible contact
modes that occur when a car drives off a ramp (Figure S2)
or when a robot pushes one or more obstacles (Figure S3).
C. Samplers
Figure S2. A car-like robot driving off a ramp.
Figure S3. A yellow car needs to push obstacles to get to its goal.
means to generate controls is also necessary. This functionalThe fundamental operation that sampling-based planners ity is attained using control samplers, which are implemented
perform is sampling the space that is explored. Additionally, as part of the control spaces (ControlSpace) they represent.
when considering controls in the planning process, sampling Additionally, a notion of direction is also important in some
planners: controls that take the system towards a particular
controls may be performed as well.
To support sampling functionality, OMPL includes four state are desired, rather than simply random controls. This
types of samplers: state space samplers (StateSampler), functionality is achieved through the use of directed control
valid state samplers (ValidStateSampler), control sam- samplers (derived from the DirectedControlSampler class).
plers (ControlSampler), and directed control samplers
D. Goal Representations
(DirectedControlSampler).
State space samplers are implemented as part of the
OMPL uses a hierarchical representation of goals. In
StateSpace they can sample, since they need to be aware the most general case, a Goal can be defined by an
of the structure of the states in that space. For instance, isSatisfied() function that when given a state, reports
uniformly sampling 3D orientations is dependent on their whether that state is a goal state or not. While this very
parametrization. Three sampling distributions are imple- general implicit representation is possible, it offers planners
mented by every state space sampler: uniform, Gaussian no indication of how to reach the goal region. For this reason,
and uniform in the vicinity of a specified point. This first isSatisfied() optionally reports a heuristic distance to
sampler is necessary to sample over the entire space, while the goal region, which is not required to be a metric.
the latter two are used for sampling states near a previously
GoalRegion is a refinement of the general Goal representagenerated state. This is the most basic level of sampling.
tion, one that explicitly specifies the distance to the goal using
Previous work has shown that the strategy used for a distanceGoal() function. The isSatisfied() funcsampling valid states in the state space significantly influ- tion is then defined to return true when distanceGoal()
ences runtime of many planning algorithms [34]. Valid state reports distances smaller than a user set threshold. Goalsamplers provide the interface for implementing different Region is still a very general representation but allows
sampling strategies. The probability distribution of these planners to bias their search towards the goal. A refinesamplers depends on the algorithm used and is not imposed ment of GoalRegion is GoalSampleableRegion, one which
as part of the API. The implementation of valid state samplers additionally allows drawing samples from the goal region.
relies on the existence of a state space sampler and a state GoalState and GoalStates are concrete implementations of
validator (StateValidityChecker). A common approach to GoalSampleableRegion.
For practical applications it is often possible to sample
constructing valid state samplers is to repeatedly call a state
space sampler until the state validator returns true. Several the goal region, but the sampling process may be relatively
valid state samplers have been implemented in OMPL: e.g., slow (e.g., when using numerical inverse kinematics solvers).
a uniform valid state sampler (UniformValidStateSampler), For this reason a refinement of GoalStates is defined as
two samplers (GaussianValidStateSampler, ObstacleBased- well: GoalLazySamples. This refinement continuously draws
ValidStateSampler) that generate valid samples near invalid samples in a separate sampling thread, and allows planners
ones (which is often helpful in finding paths through narrow to draw samples from the goal region without waiting, after
at least one sample has been produced by the sampling
passages [35], [36]).
When considering controls in the planning process, a thread.
7
E. Planning Algorithms
computing reasonable default settings that depend on the
planning context. If a user decides to choose their own
planner, or set their own parameters, OMPL allows the user
to do so completely—no parameters are hidden.
OMPL includes two types of motion planners: ones that
do not consider controls when planning and ones that do.
If a planning algorithm can be used to plan both types of
motions, with and without controls (e.g., RRT [15]), two
V. I NTEGRATION WITH OTHER ROBOTICS S OFTWARE
separate implementations are provided for that algorithm,
one for each type of computed motion. This choice was made
It is straightforward to integrate OMPL with other robotics
for efficiency reasons. With additional levels of abstraction software. Below we will present two case studies that
in the implementation it would have been possible to avoid highlight different use cases.
separate implementations [20]. The downside would have
been that the implementation of planners would have had to
follow a strict structure, which makes the implementation A. OMPL.app: A Graphical User Interface for OMPL
of new algorithms more difficult and possibly less efficient.
We have created a graphical front-end for OMPL called
For purely geometric planning (i.e., controls are not OMPL.app. This front-end was created for three reasons:
considered), the solution path is constructed from a finite set
1) to provide novice users (such as students in a robotics
of segments, and each segment is computed by interpolation
class) with an easy-to-use interface to play with several
between a pair of sampled states (PathGeometric). Several
motion planning algorithms and apply them to several
geometric planning algorithms are implemented in OMPL,
example rigid body motion planning problems,
including KPIECE [16], bidirectional KPIECE, bidirectional
2) to demonstrate the integration of OMPL with thirdlazy KPIECE, RRT [15], RRT-connect [37], lazy RRT,
party libraries for collision checking and loading of
SBL [30], EST [12], and PRM [14]. The “lazy” variants listed
3D meshes, and a GUI toolkit, and
above defer state validity checking in the manner described
3) to allow for easy benchmarking of new and existing
in [38]. In addition, there are multi-threaded versions of
planners on rigid body motion planning problems using
RRT and SBL.
a command line tool (see Box 1).
When controls are considered, the solution path is con- We will elaborate on these reasons below.
structed from a sequence of controls (PathControl). ControlThe graphical interface of OMPL.app is shown in Figure 4.
based planners are typically used when motion plans need A user can load meshes that represent the environment and
to respect differential constraints as well. Several algorithms a robot, define start and goal states, and click on the “Solve”
for planning with differential constraints are implemented button to obtain a solution. If a solution is found, it is
in OMPL as well, including KPIECE, SyCLoP [39], EST, played back by animating the robot along the found path.
and RRT.
F. An Example
Figure 3 shows the complete code necessary for planning
the motion of a rigid body between two states in Python.
The corresponding C++ code would look almost identical.
The steps taken in the code are: instantiate the space to plan
in (SE(3), line 6), create a simple planning context (using
SimpleSetup, line 13), specify a function that distinguishes
valid states (lines 15–16), specify the input start and goal
states (lines 18–26), and finally, compute the solution (line
27). The SimpleSetup class initializes instantiations of the
core motion planning classes shown in Figure 2 with
reasonable defaults, which can be overridden by the user if
desired.
Essentially, the execution of the code can be reduced to
three simple steps: (1) specify the space in which planning
is to be performed, (2) specify what constitutes a valid
state, and (3) specify the input start and goal states. Such
simple specifications are desirable for many users who simply
want motion planning to work, without having to select
problem specific parameters, or different sampling strategies,
different planners, etc. This capability is made possible by
OMPL’s automatic computation of planning parameters. In
the example above, a planner is automatically selected based
on the specification of the goal and the space to plan in.
The selected planner is then automatically configured by
Fig. 3. Solving a motion planning problem with OMPL in Python. A C++
implementation would look almost identical.
1
2
3
4
def isStateValid(state):
# Some arbitrary condition on the state
# (typically collision checking)
return state.getX() < .6
5
6
7
8
9
10
11
space = SE3StateSpace()
# set the state space bounds
bounds = ob.RealVectorBounds(3)
bounds.setLow(-1)
bounds.setHigh(1)
space.setBounds(bounds)
12
13
14
15
16
ss = SimpleSetup(space)
# specify user-defined callback function
ss.setStateValidityChecker(
ob.StateValidityCheckerFn(isStateValid))
17
18
19
20
21
22
23
24
start = State(space)
goal = State(space)
# we can pick random start states...
start.random()
goal.random
# ... or set specific values
start().setX(.5)
25
26
27
28
29
ss.setStartAndGoalStates(start, goal)
solved = ss.solve(1.0)
if solved:
print ss.getSolutionPath()
8
Fig. 4. The OMPL.app graphical interface. A solution path for a free-flying
UFO robot is shown. The red dots indicate the positions of sampled states.
The GUI is also a useful tool to prepare motion planning
problems for benchmarking. The GUI can save the complete
specification of a problem to a simple text file. The user
can then add a list of planner names to this file, planner
parameter settings, as well as the number of runs per planner,
a time limit for each run, etc. This configuration file can be
given as input to a simple command line program that can
perform the actual benchmarking. Usually, the total time
required to get statistically significant benchmark results is
too long for interactive use for all but the simplest problems,
which is why the benchmarking is not directly accessible
from the GUI.
It should be relatively straightforward for an experienced
programmer to use a different input file parser, a different
collision checking library, or different GUI toolkit by
mimicking the structure of the OMPL.app library.
By unchecking the “Animate” button, several states along B. Integration with ROS
the path are shown simultaneously. It is also possible to
We expect that many end users in industry and robotics
show the states that were explored by the planner, which research will use OMPL through its ROS interface. This
can be helpful in tuning planner parameters or selecting the interface was created by Sachin Chitta and Ioan Şucan and
appropriate planning algorithm for a particular problem. By provides ROS specific implementations for the abstract base
default, the program assumes that a user wants to plan for classes OMPL defines. We describe the steps an end-user
a free-flying 3D rigid body (i.e., the state space is SE(3)), would need to take to plan motions for a given robot that
but one can also plan in SE(2). We have also predefined runs ROS. The PR2 from Willow Garage will be used in
a number of common robot types that require controls: a the scenario described below, but the steps are in fact not
blimp, a quadrotor, a simple kinematic car, a Reeds-Shepp specific to the PR2, and apply to any robot that can run
car, a Dubins car, and a second-order car. For each robot ROS.
type the appropriate planners can be selected in the “Planner”
If a user wants to plan motions for a PR2, they first
tab (otherwise a default one will be automatically selected). need to create a model of the geometry and kinematics
Once a planner is chosen, its parameters can be tuned, if of the PR2. Within ROS there is a standard for storing
desired. Finally, the user can adjust the bounding box for the such a model called the Unified Robot Description Format
robot’s position. By default this is the bounding box of the (URDF, see http://ros.org/wiki/urdf). This XML-based format
environment mesh. We have included a number of common combines kinematic information with references to files
benchmark problems, which allow users to develop a basic containing meshes of the different robot components. For the
understanding of which types of problems are hard to solve. PR2 and many other robots URDF files already exist (see
The OMPL.app program is also an illustrative example http://www.ros.org/wiki/Robots). It is often not desirable,
for software developers who want to integrate with third- nor necessary, to plan for all degrees of freedom listed
party libraries or their own code. OMPL.app consists of in a URDF file simultaneously. The second step therefore
three parts: (1) a C++ library that contains the bindings consists of defining one or more groups of joints. Information
to third-party libraries, (2) a set of command line demos about the joints to plan for is taken from the URDF and
that highlight significant features of this library, and (3) the a StateSpace representation for OMPL is constructed. The
GUI itself. The library adds functionality to load meshes in meshes indicated by the URDF document are used to
a wide variety of formats using the Open Asset Importer construct a StateValidityChecker class. On top of these
Library (Assimp, http://assimp.sf.net). Users can thus create classes, a SimpleSetup class can also be defined, thus making
models of environments and robots in programs such as it possible to solve planning problems. The user can also
SolidWorks, 3ds Max, Blender, and SketchUp, and use them define parameters specific to different planning algorithms,
in OMPL.app. A large collection of models is also available but there is no requirement to do so. A configuration wizard
through the Google 3D Warehouse. The OMPL.app library included in ROS can make the setup easier. The third step
also adds collision checking support using the PQP library is to define motion planning problems for the PR2. This
[40] and FCL library [41]. The internal representation of can be done in a variety of ways: directly calling planning
geometry is decoupled from the graphical rendering, so that functions, using ROS-specific APIs or through visualization
the collision checking can also be used in non-graphical tools such as shown in Figure 5.
applications. The user interface is written completely in
Above we have described a very basic workflow of
Python. The code consists almost completely of creating the planning paths using OMPL in ROS. The ROS-OMPL
user interface elements, connecting them with the appropriate interface has many more advanced features. First, motion
library function calls, and displaying the results.
planning problems do not necessarily need to be specified
9
Fig. 5. With the ROS rviz visualizer robot poses can be easily configured,
using OMPL to find feasible paths between poses.
by the user, but can be specified programmatically (e.g.,
as part of a sense-plan-act loop in conjunction with other
components in ROS). Second, different types of state space
parameterizations are possible: (a) joint-space representations
of the robot, where the robot’s degrees of freedom are
compounded into different state spaces: Rn for sequences
of single degree of freedom joints with joint limits, SO(2)
for continuous joints, SE(2) for robots moving in plane
and SE(3) for robots moving in space; (b) work-space
representations of the robot, where for example, the pose
of an arm’s end-effector is represented as an SE(3) state,
and the interpolation capability of the SE(3) state space
is overridden to use inverse kinematics. Third, the ROS
interface allows the user to specify complex constraints such
as keeping transported objects upright or keeping them within
view. Generating states that are in the desired goal region is
done in parallel with the execution of the rest of the planning
algorithm. The interface also automatically incorporates the
geometry of attached objects during planning by attaching
carried objects to the kinematic model of the robot.
The ROS interface to OMPL allows users to interact with
motion planners in a simple manner. Only the set of joints
the user wants to plan for (usually grouped and referred to
by the name of the group) and a specification of the goal
are needed. The goal can be specified, e.g., as a bounding
box in the joint space, or a desired link pose. We believe
that this functionality will allow for the widespread use of
OMPL in a broad variety of settings.
VI. D ISCUSSION
We have described OMPL, an open source general-purpose
library for sampling-based motion planning. Thanks to its
integration with ROS it can be used on a wide variety
of hardware platforms, and currently serves as the motion
planning backend for the ROS manipulation software stack
(also known as MoveIt! in future releases of ROS [42]).
However, OMPL does not depend on ROS, and can be used
independently. OMPL.app includes a graphical front-end for
OMPL and serves as an example of how OMPL can be
integrated with third-party libraries.
One of the target applications of OMPL is in robotics education. The graphical front-end provides a gentle introduction
to the complexity of motion planning: without writing any
code students can solve motion planning problems using
different planners, vary the parameters used for planning,
and perform extensive benchmarking experiments. Through
many demo programs and tutorials students should be able
to get quickly up to speed, and be able to develop, e.g., new
planning algorithms or alternate implementations of abstract
APIs.
We encourage contributions from other researchers. In
fact, we are already working with other research groups
on incorporating their algorithms into OMPL. Within our
own group OMPL has proven to be useful for performing
conformational search for macromolecular ensembles. Here,
its generality has paid off significantly. We are able to use
Rosetta—a standard molecular modeling package—to create
a new state space for molecules, and use Rosetta’s sampling
capabilities while performing a search for biophysically
plausible configurations of molecules using OMPL.
The long-term success depends on adoption and support by
the robotics community. Through the continued development
in our group and contributions from others, we expect OMPL
to become a very useful tool for motion planning researchers,
users in the robotics industry, and students who want to learn
more about sampling-based motion planning.
ACKNOWLEDGMENTS
This work is supported in part by Willow Garage and NSF
CCLI Grant DUE #0920721 and Grant NSF IIS 0713623.
Willow Garage was instrumental in initiating and supporting
this effort. The development of OMPL has also benefited
from previous efforts by the Kavraki lab at Rice University to
develop a motion planning software package, in particular the
Object-Oriented System for Motion Planning (OOPSMP).
We are indebted to all other Kavraki lab members, past
and present, for providing code, inspiration, and feedback.
Previous work by Erion Plaku, Kostas Bekris and Andrew
Ladd in particular has been influential in the design of OMPL.
The authors would also like to thank Sachin Chitta and Gil
Jones from Willow Garage for the development of the ROS
bindings for OMPL and helpful discussions.
R EFERENCES
[1] J.-C. Latombe, Robot Motion Planning.
Boston, MA: Kluwer
Academic Publishers, 1991.
[2] H. Choset, K. M. Lynch, S. Hutchinson, G. Kantor, W. Burgard,
L. E. Kavraki, and S. Thrun, Principles of Robot Motion: Theory,
Algorithms, and Implementations. MIT Press, 2005.
[3] S. M. LaValle, Planning Algorithms. Cambridge University Press,
2006. [Online]. Available: http://msl.cs.uiuc.edu/planning/
[4] S. Thomas, X. Tang, L. Tapia, and N. M. Amato, “Simulating protein
motions with rigidity analysis,” J Comput Biol, vol. 14, no. 6, pp.
839–855, 2007.
[5] B. Raveh, A. Enosh, O. Schueler-Furman, and D. Halperin, “Rapid
sampling of molecular motions with prior information constraints,”
PLoS Comput Biol, vol. 5, no. 2, p. e1000295, Feb 2009.
10
[6] J. Cortés, S. Barbe, M. Erard, and T. Siméon, “Encoding molecular
motions in voxel maps,” IEEE/ACM Trans. Comp. Biology and
Bioinformatics, vol. 8, no. 2, pp. 557–563, Apr. 2010.
[7] N. Haspel, M. Moll, M. L. Baker, W. Chiu, and L. E. Kavraki, “Tracing
conformational changes in proteins,” BMC Structural Biology, vol. 10,
no. Suppl. 1, p. S1, 2010.
[8] E. Plaku, L. E. Kavraki, and M. Y. Vardi, “Hybrid systems: from
verification to falsification by combining motion planning and discrete
search,” Formal Methods in System Design, vol. 34, pp. 157–182,
2009.
[9] J. Canny, The Complexity of Robot Motion Planning. Cambridge,
MA: MIT Press, 1988.
[10] L. E. Kavraki, J.-C. Latombe, R. Motwani, and P. Raghavan,
“Randomized query processing in robot path planning,” in Proc. 27th
annual ACM symposium on Theory of Computing (STOC), 1995, pp.
353–362.
[11] J. Barraquand, L. E. Kavraki, J.-C. Latombe, R. Motwani, T.-Y. Li,
and P. Raghavan, “A random sampling scheme for path planning,”
Intl. J. of Robotics Research, vol. 16, no. 6, pp. 759–774, 1997.
[12] D. Hsu, J.-C. Latombe, and R. Motwani, “Path planning in expansive
configuration spaces,” Intl. J. of Computational Geometry and
Applications, vol. 9, no. 4-5, pp. 495–512, 1999.
[13] A. M. Ladd and L. E. Kavraki, “Measure theoretic analysis of
probabilistic path planning,” IEEE Trans. on Robotics and Automation,
vol. 20, no. 2, pp. 229–242, Apr. 2004.
[14] L. E. Kavraki, P. Švestka, J.-C. Latombe, and M. H. Overmars, “Probabilistic roadmaps for path planning in high-dimensional configuration
spaces,” IEEE Trans. on Robotics and Automation, vol. 12, no. 4, pp.
566–580, Aug. 1996.
[15] S. M. LaValle and J. J. Kuffner, “Randomized kinodynamic planning,”
Intl. J. of Robotics Research, vol. 20, no. 5, pp. 378–400, May 2001.
[16] I. A. Şucan and L. E. Kavraki, “A sampling-based tree planner for
systems with complex dynamics,” IEEE Trans. on Robotics, vol. 28,
no. 1, pp. 116–131, 2012.
[17] M. Quigley, K. Conley, B. Gerkey, J. Faust, T. Foote, J. Leibs,
R. Wheeler, and A. Y. Ng, “ROS: an open-source Robot Operating
System,” in ICRA Workshop on Open Source Software, 2009.
[18] I. A. Şucan and L. E. Kavraki, “On the implementation of single-query
sampling-based motion planners,” in IEEE Intl. Conf. on Robotics
and Automation, may 2010, pp. 2005–2011.
[19] A. V. Estrada, J. M. Lien, and N. M. Amato, “VIZMO++: a
visualization, authoring, and educational tool for motion planning,”
in Proc. 2006 IEEE Intl. Conf. on Robotics and Automation, 2006,
pp. 727–732.
[20] E. Plaku, K. E. Bekris, and L. E. Kavraki, “OOPS for motion planning:
An online open-source programming system,” in Proc. 2007 IEEE Intl.
Conf. on Robotics and Automation, Rome, Italy, 2007, pp. 3711–3716.
[21] R. Diankov, “Automated construction of robotic manipulation
programs,” Ph.D. dissertation, Carnegie Mellon University,
Robotics Institute, August 2010. [Online]. Available: http:
//www.programmingvision.com/rosen diankov thesis.pdf
[22] B. Gerkey, R. Vaughan, and A. Howard, “The Player/Stage project:
Tools for multi-robot and distributed sensor systems,” in Proc. 11th
Intl. Conf. on Advanced Robotics, 2003, pp. 317–323.
[23] N. Koenig and A. Howard, “Design and use paradigms for Gazebo,
an open-source multi-robot simulator,” in Proc. 2004 IEEE/RSJ Intl.
Conf. on Intelligent Robots and Systems, 2004, pp. 2149–2154.
[24] O. Michel, “WebotsTM : Professional mobile robot simulation,” Intl.
J. of Advanced Robotic Systems, vol. 1, no. 1, pp. 39–42, 2004.
[Online]. Available: http://www.cyberbotics.com/
[25] G. Echeverria, N. Lassabe, A. Degroote, and S. Lemaignan, “Modular
open robots simulation engine: MORSE,” in IEEE Intl. Conf. on
Robotics and Automation, 2011.
[26] Microsoft Robotics Developer Studio. [Online]. Available: http:
//www.microsoft.com/robotics
[27] N. Ando, T. Suehiro, and T. Kotoku, “A software platform for
component based RT-system development: OpenRTM-aist,” in Intl.
Conf. Simulation, Modeling, and Programming for Autonomous Robots
(SIMPAR). Springer, 2008, pp. 87–98.
[28] C. Jang, S. Lee, S. Jung, B. Song, R. Kim, S. Kim, and C. Lee,
“OPRoS: A new component-based robot software platform,” ETRI
journal, vol. 32, no. 5, pp. 646–656, 2010.
[29] G. Metta, P. Fitzpatrick, and L. Natale, “YARP: yet another robot
platform,” Intl. J. Advanced Robotics Systems, vol. 3, no. 1, pp. 43–48,
2006.
[30] G. Sánchez and J.-C. Latombe, “A single-query bi-directional probabilistic roadmap planner with lazy collision checking,” in The Tenth
International Symposium on Robotics Research, 2001, pp. 403–417.
[31] S. Redon, A. Kheddar, and S. Coquillart, “Fast continuous collision
detection between rigid bodies,” Computer Graphics Forum, vol. 21,
no. 3, pp. 279–287, 2002.
[32] K. Ahnert and M. Mulansky, “Odeint – solving ordinary differential
equations in C++,” in Proc. AIP Conf. on Numerical Analysis and
Applied Mathematics (ICNAAM), vol. 1389, 2011, pp. 1586–1589.
[33] E. R. Johnson and T. D. Murphey, “Scalable variational integrators
for constrained mechanical systems in generalized coordinates,” IEEE
Trans. on Robotics, vol. 25, no. 6, pp. 1249 –1261, Dec. 2009.
[Online]. Available: http://trep.sourceforge.net
[34] D. Hsu, J.-C. Latombe, and H. Kurniawati, “On the probabilistic
foundations of probabilistic roadmap planning,” Intl. J. of Robotics
Research, vol. 25, no. 7, pp. 627–643, 2006.
[35] N. Amato, O. Bayazit, L. Dale, C. Jones, and D. Vallejo, “OBPRM: An
obstacle-based PRM for 3D workspaces,” in Robotics: The Algorithmic
Perspective, P. K. Agarwal, L. E. Kavraki, and M. T. Mason, Eds.
A.K. Peters, 1999, pp. 155–168.
[36] V. Boor, M. H. Overmars, and A. F. van der Stappen, “The Gaussian
sampling strategy for probabilistic roadmap planners,” in Proc. 1999
IEEE Intl. Conf. on Robotics and Automation, 1999, pp. 1018–1023.
[37] J. Kuffner and S. M. LaValle, “RRT-Connect: An efficient approach
to single-query path planning,” in Proc. 2000 IEEE Intl. Conf. on
Robotics and Automation, San Francisco, CA, Apr. 2000, pp. 995–
1001.
[38] R. Bohlin and L. E. Kavraki, “Path planning using lazy PRM,” in Proc.
2000 IEEE Intl. Conf. on Robotics and Automation, San Francisco,
CA, 2000, pp. 521–528.
[39] E. Plaku, L. Kavraki, and M. Vardi, “Motion planning with dynamics
by a synergistic combination of layers of planning,” IEEE Trans. on
Robotics, vol. 26, no. 3, pp. 469–482, jun. 2010.
[40] E. Larsen, S. Gottschalk, M. C. Lin, and D. Manocha, “Fast distance
queries with rectangular swept sphere volumes,” in IEEE Intl. Conf.
on Robotics and Automation, 2000, pp. 3719–3726.
[41] J. Pan, S. Chitta, and D. Manocha, “FCL: A general purpose library
for collision and proximity queries,” in IEEE Intl. Conf. on Robotics
and Automation, Minneapolis, Minnesota, May 2012.
[42] S. Chitta, I. Şucan, and S. Cousins, “Moveit!” IEEE Robotics
Automation Magazine, vol. 19, no. 1, pp. 18–19, Mar. 2012.
Ioan A. Şucan, Department of Computer Science, Rice
University, Houston, TX. Currently with Willow Garage,
Menlo Park, CA. isucan@willowgarage.com
Mark Moll, Department of Computer Science, Rice University, Houston, TX. mmoll@rice.edu
Lydia E. Kavraki, Department of Computer Science, Rice
University, Houston, TX. kavraki@rice.edu