Path and motion planning

INFO: The old path/motion planning functionality is still functional for backward compatibility and available if you click here, but it is recommended not to use it anymore.

V-REP offers path/motion planning functionality via a plugin wrapping the OMPL library. The plugin is courtesy of Federico Ferri.

Following points should be considered when preparing a path/motion planning task:

  • Decide of a start and goal state. When the path planning object is a serial manipulator, a goal pose (or end-effector position/orientation) is often provided instead of a goal state. In that case function simGetConfigForTipPose can be used to find one or several goal states that satisfy the provided goal pose.
  • Create a path planning task with simExtOMPL_createTask.
  • Select an algorithm with simExtOMPL_setAlgorithm.
  • Create the required state space, which can be composed as a compound object: simExtOMPL_createStateSpace and simExtOMPL_setStateSpace.
  • Specify which entities are not allowed to collide with simExtOMPL_setCollisionPairs.
  • Specify the start and goal state with simExtOMPL_setStartState and simExtOMPL_setGoalState.
  • Compute one or several paths with simExtOMPL_compute.
  • Destroy the path planning task with simExtOMPL_destroyTask.
  • Often, path planning is used in combination with inverse kinematics: in a pick-and-place task for instance, the final approach should usually be a straight-line path, which can be generated with simGenerateIkPath.
  • Above procedure is the regular approach, which sometimes lacks flexibility. Additionally, following callback functions can be set-up:

  • simExtOMPL_setStateValidationCallback
  • simExtOMPL_setProjectionEvaluationCallback
  • simExtOMPL_setGoalCallback
  • The path provided by simExtOMPL_compute is usually just one path among an infinite number of other possible paths, and there is no guarantee that the returned path is the optimal solution. For that reason it is common to compute several different paths, then to select the better one (e.g. the shorter one).

    In a similar way, if the goal state had to be computed from a goal pose, then several goal states are usually tested, since not all goal states might be reachable or close enough (in terms of state space distance). A common practice is to first find several goal states, then order them according their state space distance to the start state. Then perform path planning calculations to the closest goal state, then to the next closest goal state, etc., until a satisfactory path was found.

    Make sure to refer to following demo scenes for additional details:

  • scenes/ik_fk_simple_examples/8-computingJointAnglesForRandomPoses.ttt
  • scenes/3DoFHolonomicPathPlanning.ttt
  • scenes/6DoFHolonomicPathPlanning.ttt
  • motionPlanningDemo1
  • motionPlanningAndGraspingDemo.ttt

  • Recommended topics

  • The OMPL plugin API functions