Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Last revision Both sides next revision
tutorials:intermediate:collisions_and_constraints [2015/06/05 13:20]
mpomarlan [Using kinematic constraints during planning]
tutorials:intermediate:collisions_and_constraints [2015/06/08 13:26]
mpomarlan Collision check resolution info for constrained planning requests.
Line 265: Line 265:
 From the previous part of the tutorial, we should have a running REPL with the cram moveit tutorial loaded and initialized,​ an RViz window showing a PR2 and an environment containing only a cube (which is now an obstacle: robot links are not allowed to collide with it), and MoveIt! running in the background. From the previous part of the tutorial, we should have a running REPL with the cram moveit tutorial loaded and initialized,​ an RViz window showing a PR2 and an environment containing only a cube (which is now an obstacle: robot links are not allowed to collide with it), and MoveIt! running in the background.
  
-Let's try a simple motion plan request, in which we ask the robot to move from one pose around the cube to another:+cram-moveit also allows you to define path constraints for **compute-cartesian-path**,​ **move-link-pose**,​ as well as imposing constraints for state validity checking, but for the example below we will issue a planning request with constraints. 
 + 
 +Let'​s ​first try a simple motion plan request, in which we ask the robot to move from one pose around the cube to another:
  
 <code lisp> <code lisp>
Line 291: Line 293:
                                                                                                     :w 1.0)                                                                                                     :w 1.0)
                                                                      :​link_name "​r_wrist_roll_link"​                                                                      :​link_name "​r_wrist_roll_link"​
-                                                                     :​absolute_x_axis_tolerance 0.001 +                                                                     :​absolute_x_axis_tolerance 0.01 
-                                                                     :​absolute_y_axis_tolerance 0.001 +                                                                     :​absolute_y_axis_tolerance 0.01 
-                                                                     :​absolute_z_axis_tolerance 0.001+                                                                     :​absolute_z_axis_tolerance 0.01
                                                                      :​weight 1.0))))                                                                      :​weight 1.0))))
 (plan-link-movement "​r_wrist_roll_link"​ "​right_arm"​ tuti:​*pose-right* :​start-robot-state rs-mid ​ (plan-link-movement "​r_wrist_roll_link"​ "​right_arm"​ tuti:​*pose-right* :​start-robot-state rs-mid ​
Line 301: Line 303:
 (We leave some tolerance in the axis to help the sampler; a too strict constraint may be impossible to satisfy anyway.) (We leave some tolerance in the axis to help the sampler; a too strict constraint may be impossible to satisfy anyway.)
  
-Now look in the RViz window. You should ​see that the planned path keeps the end effector in the same orientation while it moves around ​the cube. (Author'​s ​note: actually, there seems to be a MoveIt! ​bug here as the trajectory it returns is invalid-it always attempts ​to pass through ​the cubeBug report in progress.)+Unfortunately,​ if you try the code above, and assuming you've made //no changes// to the pr2_moveit_config package, you will see an error signal in the REPL window, and if you look in the RViz window ​you'​ll ​see that the planned path attempts to pass through ​the cube. What happened? 
 + 
 +There is a solution however-- look below. 
 + 
 +==== A note about MoveIt!'​s ​collision checking ==== 
 + 
 +MoveIt! does not do continuous collision checkingwhich means, instead, that it chooses some points along a robot trajectory segment and does collision checking on them. Usually this won't affect you, unless you work with very narrow objects and/or constraints.  
 + 
 +Narrow objects are a problem because the poses MoveIt! chooses to check along a trajectory segment may just miss the object, even if, in fact, the trajectory passes through the object. Kinematic constraints seem to be a problem for a more complicated reason: ​there tends to be more space, and longer segments, between samples produced by constrained samplers.  
 + 
 +There is tradeoff between increasing the resolution of the collision checks along a trajectory segment and planning time. Sadly, ​MoveIt! ​doesn'​t yet have a way for you to set the resolution at run-time.  
 + 
 +For the example above to work, you will have to close move_group, go to pr2_moveit_config/​config and edit the ompl_planning.yaml fileNotice that each planning group has a variable longest_valid_segment_fraction. Set its value to 0.005 (rather than the original 0.05), then rerun the pr2_moveit_config/​launch/​demo.launch file.
  
-You can also define path constraints ​for **compute-cartesian-path** ​and **move-link-pose**, as well as imposing constraints for state validity checking.+From the REPL, rerun the lisp code we tried above, ​for sending a constrained plan request. This time you should receive a multi-value consisting of a robot state and a robot trajectory as answer-- and the trajectory is a valid solution. You can also observe it in RViz (remember to enable Loop Animation from the Planned Path submenu on the left): notice how the planned path keeps the end effector in the same orientation while it moves around the cube
  
 == Next == == Next ==