Path and motion planning

CoppeliaSim 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 sim.getConfigForTipPose can be used to find one or several goal states that satisfy the provided goal pose.
  • Create a path planning task with simOMPL.createTask.
  • Select an algorithm with simOMPL.setAlgorithm.
  • Create the required state space, which can be composed as a compound object: simOMPL.createStateSpace and simOMPL.setStateSpace.
  • Specify which entities are not allowed to collide with simOMPL.setCollisionPairs.
  • Specify the start and goal state with simOMPL.setStartState and simOMPL.setGoalState.
  • Compute one or several paths with simOMPL.compute.
  • Destroy the path planning task with simOMPL.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 sim.generateIkPath.
  • Above procedure is the regular approach, which sometimes lacks flexibility. Additionally, following callback functions can be set-up:

  • simOMPL.setStateValidationCallback
  • simOMPL.setProjectionEvaluationCallback
  • simOMPL.setGoalCallback
  • The path provided by simOMPL.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