This page is currently outdated and has been replaced by the motion planners stack page. For tutorials on using the motion planners for creating motion plans for the PR2 robot in simulation, have a look at the arm navigation tutorials page.

Overview

This page documents the design and structure of the motion planning software stack. This collection of software integrates motion planning with environment and robot models, and collision checking. While the algorithms and structures described here are general, they are most often used to control high-DOF systems, such as robot arms.

Planning for a mobile base could be done with the software described here, but we usually use the special-purpose navigation stack (http://pr.willowgarage.com/pr-docs/ros-packages/move_base/html/index.html).

Motion Planning Diagram

Documentation

Motion planning libraries

• ompl

  • This library implements a series of sampling-based motion planning algorithms: RRT, LazyRRT, EST, SBL, KPIECE

• sbpl

  • This library implements a series of grid-based search algorithms

Planning models and environments

• planning_models

  • This is a library where robot models used for planning are defined. For example, a kinematic model that can do forward kinematics and construct a configuration space for a robot.

• collision_space

  • This is a library that allows performing collision checking for a robot in a changing environment. It can be aware of a robot model defined in planning_models and also performs self collision checking. In terms of speed of collision tests, the ODE backend of this library can perform about 4800 collision tests per second if there are 10000 points that do not collide all around the robot (hardly a realistic case), with self collision included. Removing the self collision test brings the number of checks per second to about 4900.

• planning_environment

  • This is a library that instantiates available robot models (from planning_models) and collision environments (from collision_space) based on ROS parameters. In addition, there exist state monitors for certain models (the kinematic model, for example) and certain environments. These state monitors subscribe to the relevant ROS topics and maintain state. Kinematic constraint evaluation, path and state validity checking is possible as well.

ROS interface to planning libraries

• ompl_planning

  • This node implements the ROS interface for the ompl library

• sbpl_arm_planner

  • This node implements the ROS interface for the sbpl library

• chomp_motion_planner

  • This library implements CHOMP - a motion planner based on trajectory optimization.

Motion planning scenarios

Kinematic arm planning

• move_arm

  • This node represents the user interface to arm planning and is implemented as an action.

    # The goal state for the model to plan for. The state is not necessarily explicit.
    # The goal is considered achieved if all the constraints are satisfied.
    # An explicit state can be specified by setting joint constraints to a specific value.
    motion_planning_msgs/KinematicConstraints goal_constraints
    
    # The set of constraints that need to be satisfied by the entire solution path.
    motion_planning_msgs/KinematicConstraints path_constraints
    
    # The set of allowed contacts
    motion_planning_msgs/AcceptableContact[] contacts
    ---
    ---
    int32 mode
    int32 PLANNING=1
    int32 MOVING=2
    
    duration time_to_completion

    The definition of the constraints used in this message is in the motion_planning_msgs package. When it receives a goal request, this action sends a request to a running motion planning node by calling a service. The service that is expected to exist is:

    • plan_kinematic_path, with definition in MotionPlan.srv in motion_planning_msgs.

    Once move_arm has made its request to the motion planner, it may receive a path, as response. move_arm then sends this path to a trajectory controller for the arm and monitors its execution. If the path becomes invalid (for instance, new obstacles appear), the arm is stopped and a new plan is requested. The state of the world is also monitored, so if sensor data becomes stale, the state of the arm is considered invalid, so no motion is performed. This behaviour is executed in a loop until the action is completed or preempted.