Reference: OpenRAVE::PlannerBase
In OpenRAVE, the basic purpose of a planner is to find a trajectory starting at some initial configuration that reaches a goal condition while satisfying various navigation constraints. All planners are assumed to be geometric in nature (ie, not planning in the space of policies that depend on sensor data). Planners can have any configuration space defined by using the OpenRAVE::PlannerBase::PlannerParameters structure. A planner should never use the raw joint values functions defined in KinBody.
The usage of a planner is simple:
All the information defining a planning problem should be specified in PlannerBase::PlannerParameters. PlannerParameters
tries to cover most of the common data like distance metrics, sampling distributions, initial and goal configurations. However there are many different types of inputs to a planner, so it is impossible to cover everything with one class. Instead, PlannerParameters
has a very flexible and safe way to extend its parameters without destroying compatibility with a particular planner or user of the planner. This is enabled by the serialization to XML capabilities of PlannerParameters
will produce something in the form of
<PlannerParameters> <initialconfig>2</initialconfig> </PlannerParameters>
Furthermore PlannerParameters can read such an XML file given an input stream
istream is; is >> *params;
Using XML as a medium, it is easy to exchange data across different derivations of PlannerParameters without much effort. To add new parameters for planners to take advantage of
As long as the user of the planner passes a PlannerParameters
that can serialize to the same format of data that the planner expects, the data will be passed. This allows the planner and the caller of PlanPath to use different PlannerParameters
. definitions without any conflicts.
This is a simple call to a birrt planner, let activegoal hold the goal configuration and activejoints hold indices to the robot joints interested to plan for.
In order to speed up computations further, planners can use the CO_ActiveDOFs collision checker option, which only focuses collision on the currently moving links in the robot. If using the robot active DOF, before calling the planner, the user should insert this statement:
Here is how to derive from a PlannerParameters class in order to introduce new parameters.
Most planners do their computation iteratively, and they take lots of computation time. It is very frequent for a user to want to early-terminate the planner, or tell it to return the best solution it has founds immediately. Users might also want to visualize the planning process without getting into the internals of the planner. In order to do this, OpenRAVE allows users to register callbacks via OpenRAVE::PlannerBase::RegisterPlanCallback. Planner developers should always call OpenRAVE::PlannerBase::_CallCallbacks inside their planning loop and process the input correctly.
Examples of planners are:
Planner should be able to query sensor information from the Robot like its current camera image etc. Planner should be compatible with Robot presented; some hand-shaking should happen between the two during InitPlan function.
Path smoothing/optimization can be regarded as a post-processing step to planners. "Path optimization" algorithms take in an existing trajectory and filter it using the existing constraints of the planner. In fact, functionality there is no difference between a "path optimization" planner and a regular planner besides the fact that a trajectory is used as input. Because PlannerBase::PlanPath already has a trajectory as an argument, this does not cause any major API changes to the infrastructure.
However, the PlannerParameters structure had to reflect what 'path optimization' algorithm to use for post processing the trajectory. This is now reflected in the PlannerParameters::_sPostProcessingPlanner and PlannerParameters::_sPostProcessingParameters arguments. By default, this is the default "linear shortcut" path optimizer. There is also a helper function in PlannerBase to help users easily call the post-processing step:
Please take a look at how the default RRT algorithms are now structured.
Planner post-processing actually allows users to chain planners in the same way that filters are chained, all through specifying planner parameters. Of course, users can continue to smooth in planners without relying on this framework. However, explicit control of path smoothing allows custom parameter to be easily specified.