API Overview

The class ownership diagram above shows the relationship between the essential base classes in OMPL. For example, SpaceInformation owns a StateSpace; Planner does not own SpaceInformation, although a Planner does know about the SpaceInformation, and uses provided functionality. Users are encouraged to use the SimpleSetup class (ompl::geometric::SimpleSetup or ompl::control::SimpleSetup). With this class, it is only necessary to instantiate a ompl::base::StateSpace object, a ompl::control::ControlSpace object (when planning with differential constraints, i.e, planning with controls), and a ompl::base::StateValidityChecker object. Many common state spaces have already been implemented as derived StateSpace classes. See a list here.

The ompl::base::StateValidityChecker is problem-specific, so no default implementation is available. See this document for more information on state validity checking. For more advanced definitions of goals, see this document.

Doxygen-generated documentation

Thread safety: All static, non-member or const member functions are thread safe. Calling member functions that are not const in multiple threads simultaneously is unsafe and locks should be used.

Memory management: For all base classes Class, a ClassPtr type is defined as well. ClassPtr is in fact a boost shared pointer for Class :
class Class;

typedef boost::shared_ptr<Class> ClassPtr;

The code above is generated by the ClassForward macro defined in ompl/util/ClassForward.h:
ClassForward(Class);

Often the user is required to operate with *Ptr variables, in order to ensure all memory is freed at the termination of the program without explicitly calling delete. For some classes internal to the library, a C-style pointer is maintained instead of the *Ptr variable to avoid cyclic dependencies (which prevent memory de-allocation).