Differences

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

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
tutorials:intermediate:collisions_and_constraints [2015/06/05 12:08] – [Using kinematic constraints during planning] mpomarlantutorials:intermediate:collisions_and_constraints [2015/06/18 06:25] (current) – [Allowed Collision Matrix] mpomarlan
Line 194: Line 194:
 </code> </code>
  
-A similar effect can be achieved by removing and readding the cube to the planning scene like so: +NOTE: MoveIt! will NOT remove entries in the allowed collision matrix when an object is removed from the planning scene. For clean removal, you should remember to do this yourself.
- +
-<code lisp> +
-(remove-collision-object "cube") +
-(add-collision-object "cube" tuti:*pose-cube*) +
-</code> +
- +
-because MoveIt! will also remove acm entries associated to a removed object (TODO: or will, once a pull request is merged.)+
  
 ===== Constraint checking ===== ===== Constraint checking =====
Line 265: Line 258:
 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 286:
                                                                                                     :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 296:
 (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.+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 checking, which 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 a 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 file. Notice 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 ==