Using the motion planning functionalityWARNING: Since V-REP release 3.3.0, a plugin wrapping the OMPL library is available. It is highly recommended to use the path planning API functions offered by that plugin, instead of using this old built-in path/motion planning functionality, since the plugin/OMPL approach is much more flexible and scalable. The following documentation is deprecated. Before setting-up a motion planning task, make sure you have understood how the motion planning module operates. Following are the different items that should be prepared in order to create a functional motion planning task object:
In order to create an empty motion planning task, you need to specify which joints are part of the manipulator. This typically does not include gripper joints or other auxiliary joint. The joints should be part of the same kinematic chain. Select the joints from base to tip, then in the motion planning dialog, click Add new object. Rename the added object appropriately in order to quickly recognize to which manipulator it relates. [Serial manipulator with 3 joints (DoF)]
Each motion planning task requires an associated IK group in order to be operational. The IK group should contain exactly one IK element, which defines a kinematic chain involving the same joints as specified in previous step. Make sure to correctly define the base of the IK element (which should be the base of the manipulator), and its constraints (that are normally expressed relative to the specified base): [IK group definition for the motion planning task] The IK group should use an undamped resolution method (i.e. the pseudo inverse method), which means that the IK element should not be overconstrained. In order to test the created IK group, you should: Test the created IK group by running the simulation and changing the position/orientation of the target: the manipulator's end-effector should follow the target in a stable and robust way (given that the target is reachable and not in a singular pose). If this is not the case, then you have not correctly defined your IK group/element. Revert the temporary changes, then set the IK group into explicit handling mode. Make sure the IK element is still active (Element is active). In the motion planning dialog, set the IK group you just created as the Associated IK group item. Watch out for warnings in red, in that dialog section.
When motion planning needs to take into account potential collisions between the manipulator and the environment, or potential manipulator self-collisions, then you can specify collision entities: Collision detection will be performed only at the calculated path nodes, and what can happen is that the manipulator seems to jump over an obstacle: [Manipulator jumping over the obstacle] To avoid above problem, one can reduce the distance D (in configuration space) used in the simFindMpPath API function, or use a minimum distance calculation (with an appropriate threshold) instead of a simple collision detection. It is important that your manipulator collision entities are correctly defined, otherwise your manipulator could be in a state of constant collision, and no motion planning path will be calculated. For verification, you can always temporarily specify the same collision entities (or minimum distance entities) in the collision detection dialog or minimum distance calculation dialog. [Ill-defined self-collision: slight intersections between consecutive links (shown in green) put the manipulator in a state of constant collision] You should also be aware that if your manipulator grasps an object that was initially an obstacle (e.g. a cup), then the manipulator will be in a state of constant collision with that object, and any further motion planning calculation will fail. At that point you have two options:
Following additional parameters can also be adjusted, in order to optimize the created motion planning object:
Once your motion planning object is fully defined, you can use it via appropriate API function calls. Following pseudo-code represents the logical sequence, but can be very slow (remember that the path simplification usually takes the longest to compute): 1. Starting with a manipulator start configuration, we want the end-effector to move without collisions to a specific goal pose. 2. Search for a goal configuration that matches the goal pose (simGetConfigForTipPose). 3. Search for a path between the start and goal configurations (simFindMpPath). 4. Simplify the found path (simSimplifyMpPath). 5. Repeat above steps 2-4 n times. 6. Select the shortest calculated path. Following pseudo-code represents the practical sequence, most often used: 1. Starting with a manipulator start configuration, we want the end-effector to move without collisions to a specific goal pose. 2. Search for a goal configuration that matches the goal pose (simGetConfigForTipPose). 3. Search for a path between the start and goal configurations (simFindMpPath). 4. Repeat above steps 2 & 3 n times. 5. Select the shortest calculated path, and simplify it (simSimplifyMpPath). For a practical exemple, refer to the child scripts attached to objects Mico and Jaco, in the demo scene motionPlanningAndGraspingDemo.ttt. Recommended topics |