Motion Planning/Overview

Motion Planning
MoveIt! includes a variety of motion planners:
 * Sampling-based motion planners (implementations from [OMPL])
 * Search-based motion planners (implementations from SBPL)
 * Optimization-based motion planners (CHOMP)

Each motion planner exists in its own package and is integrated as a plugin for MoveIt!

In this section, you will learn how to integrate motion planning with your components.

The Planning Interface
The Planner class in the planning_interface component in moveit_core provides an abstract class implementation for motion planning. It exposes two solve methods. The first method, intended for most normal use, takes as input: And provides as output:
 * The planning scene - A representation of the environment that the robot is in and the state of the robot (see the Planning Scene documentation for more information).
 * The motion plan request - A representation of what the user wants the motion planner to do.
 * The motion plan response - The resulting answer from the motion planner.

The second solve method is intended for benchmarking and allows the motion planners to return a much more detailed response including the time that it took to carry out different planning steps.

The Motion Planning Request
The request to the motion planners is specified through a MotionPlanRequest message. The message allows for the specification of the following:


 * Workspace Parameters - This specifies the limits of the overall workspace that the planner should work in as a box in the world. The planner will attempt to keep the robot within this workspace at all times.
 * Current robot state - This can be an incremental specification and will replace joint values derived from the current state specified in the PlanningScene.
 * Goal - This is specified as a set of constraints. It can be used to specify either a joint space goal or a cartesian goal or a combination of both.
 * Path Constraints - These are constraints applied at every waypoint along the planned path of the robot.
 * Trajectory Constraints - Sometimes, the specified task may require the robot to follow a certain trajectory instead of going to a goal position. The corresponding constraints are specified in this part of the message.
 * Planner id - The name of the planner to use. If no name is specified, a default motion planner will be used.
 * Group name - The name of the group of joint to plan with (e.g. the right_arm of the PR2 robot).
 * Number of planning attempts - The number of times the planner should attempt to solve this problem. The shortest solution will always be reported.
 * Allowed planning time - The time allowed (in s) for planning

The planning request may look very complicated and daunting to fill out but don't worry. The preferred way to create a motion planning request is through a simpler API that will fill out most of the required parts of the request for you.

The Motion Planning Response
The motion plan response (MotionPlanResponse) encodes the result from the motion planner. It contains the following:
 * Robot state - The current robot state that the motion planner was working with
 * Group name - The name of the group that this plan is for
 * Robot trajectory - A solution trajectory, if found
 * Planning time - The total time that that planner took to plan this trajectory
 * Error code - A return code that encodes the reason that the planner may have failed. Always check this code BEFORE using the planned trajectory.

The Planning Pipeline
The Planning Pipeline performs three functions:
 * Automatically instantiates a planner plugin
 * Automatically instantiates a set of planning request adapters that allow for pre-processing of the planning request or post-processing of the plans themselves
 * Putting the planners and planning request adapters together in a serialized fashion

Plugin API
The primary interface to motion planning algorithms is through plugins. All types of planners implement the common Planner interface (mentioned above). The ROS plugin architecture is then used to find and choose a planner at runtime. This makes it easy to switch planners out at runtime if necessary. This interface to the motion planners is the most efficient one since there is no network communication involved. If the user needs to make changes to the planning scene before planning, this plugin-based approach is the recommended one.

ROS API
Based on the plugin interface, two other means of interacting with planners are defined through a ROS API: using actions (preferred) and service calls. The ROS API is offered by the move_group node. Wrappers for calling this ROS API are also available in the move_group interface.

Links

 * Back to Motion Planning