Robot Motion Planning 1
A variety of motion planners are included in moveit.
- Sampling-based motion planner: OMPL
- Search-Based Motion Planner: SBPL
- Optimization-based motion planner: CHOMP
Each motion planner is in its own package and is integrated in moveit as a plugin. Next, learn how to integrate the motion planner into our planning task.
Planning Interface
The planning_interface component in moveit_core provides a planning class that provides an abstract class implementation for motion planning. It provides two methods, the first method most people use, takes the following as input:
- Planning scene, planning scene. It represents the environment in which the robot is located and the pose of the robot.
- motion plan request, motion plan request. Indicates what the user wants the planner to do.
and gives the following output
- Motion planning response, motion plan response. That is, the result of motion planning.
The second workaround is intended for benchmarking and allows motion planners to return more detailed responses, including the time it takes to perform different planning steps.
The Motion Planning Request
A request is made to the motion planner through a MotionPlanRequest message, which needs to specify the following information:
- Workspace Parameters, Workspace Parameters. Sets limits for the entire workspace in which planners should work around the world. The planner will always try to keep the robot in this workspace.
- Current robot state, Current robot state. This can be an incremental specification and will supersede the union value derived from the current state specified in the PlanningScene.
- Goal, Goal. This is specified as a set of constraints. It can be used to specify a joint space objective or a Cartesian objective or a combination of both.
- Path constraints, Path Constraints. These are constraints applied at each point on the robot's planned path.
- Planner ID, Planner id. The name of the planner to use, if there is no name the default planner will be used.
- Planning group name, Group name. The name of the joint group to be planned.
- Number of planning attempts. The number of times the planner has attempted to solve the problem, returning the shortest path.
- Allowed planning time. Timing in seconds.
The planning requirements may seem complicated and daunting, but don't worry. The preferred way to create an exercise plan request is through a simpler API to fill out most of the required parts of the request.
The Motion Planning Response
The motion planning responses obtained from the motion planner mainly include the following:
- Robot state, Robot state. The current state of the robot on which the motion planner works.
- Group name, Group name. The name of the robot joint group to be planned.
- Robot trajectory, Robot trajectory. If found, return the resulting robot trajectory.
- Planning time. Planning time. The total time used by the planner.
- Error code, Error code. If the plan fails, the reason for the failure is returned.
The Planning Pipeline
The planning process performs three functions:
- Automatically instantiate a planner plugin.
- Automatically instantiates a set of plan request adapters, allowing plan requests to be pre-processed or post-processed to the plan itself.
- Combine the planner and plan request adapter in a serialized fashion.
set up
Setting up the planning process (Code API) is very simple. It only requires input:
- an instance of the robot model
- the parameter name on the ROS parameter server to specify the motion planner to use
- the parameter name on the ROS parameter server to specify the list of planning adapters to use The
following is a code example
planning_pipeline::PlanningPipelinePtr planning_pipeline(new planning_pipeline::PlanningPipeline(robot_model, "planning_plugin", "planning_adapters")); specify motion planner
The motion planner is specified in the planning_plugin of the ROS parameter server. Here we are going to use the planner in OMPL so that the lines we need in our startup file are the following
<param name="planning_plugin" value="ompl_interface_ros/OMPLPlanner" />Note that this parameter must be defined within the private namespace of the node instantiated by the planning process. Reference example
Specifies the planning request adapter
Scheduled request adapters are specified as a set of space-separated names (strings). An example is given below, where we specify two adapters: (1) the "AddTimeParameterization" adapter runs on the planned trajectory and adds time parameterization to it; (b) the "FixStartStateBounds" adapter at the start state of the motion plan request and fix any joint values that might be slightly out of range.
<param name="planning_adapters" value="default_planner_request_adapters/AddTimeParameterization default_planner_request_adapters/FixStartStateBounds" />planning
planning_pipeline->generatePlan(planning_scene, req, res);Plugin API Plugin API
The main interface to motion planning algorithms is through plugins. All types of planners implement the common Planner interface (described above). The planner is then found and selected at runtime using the ROS plugin architecture. This makes it easy to switch plans at runtime when needed. Since no network communication is involved, the interface to the motion planner is the most efficient one. This plugin-based approach is recommended if the user needs to make changes to the planning scene prior to planning.
The #ROS API
is based on the plugin interface, and two other ways of interacting with the planner are defined through the ROS API: using actions (preferred) and service calls. The ROS API is provided by the move_group node. A wrapper to call this ROS API is also available in the move_group interface .
