Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
tutorials:intermediate:collisions_and_constraints [2015/06/05 09:03] – Added acm handling. mpomarlan | tutorials:intermediate:collisions_and_constraints [2015/06/18 06:25] (current) – [Allowed Collision Matrix] mpomarlan | ||
---|---|---|---|
Line 194: | Line 194: | ||
</ | </ | ||
- | A similar effect can be achieved by removing and readding | + | 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> | + | ===== Constraint checking ===== |
- | (remove-collision-object " | + | |
- | (add-collision-object " | + | |
- | </ | + | |
- | because MoveIt! will also remove acm entries associated | + | Sometimes motion must satisfy more requirements than just getting from A to B without bumping into anything. Suppose, for example, that the robot is carrying |
- | + | ||
- | ===== Constraint checking ===== | + | |
==== Primer to MoveIt! kinematic constraints ==== | ==== Primer to MoveIt! kinematic constraints ==== | ||
Line 258: | Line 253: | ||
If the target radius is on the order of machine epsilon or smaller, the constraint is considered perfectly satisfied. | If the target radius is on the order of machine epsilon or smaller, the constraint is considered perfectly satisfied. | ||
+ | |||
+ | ==== Using kinematic constraints during planning ==== | ||
+ | |||
+ | From the previous part of the tutorial, we should have a running REPL with the cram moveit tutorial loaded and initialized, | ||
+ | |||
+ | cram-moveit also allows you to define path constraints for **compute-cartesian-path**, | ||
+ | |||
+ | 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> | ||
+ | (plan-link-movement " | ||
+ | </ | ||
+ | |||
+ | (Note the use of the &key parameter start-robot-state to plan a motion from a state that might not be the robot' | ||
+ | |||
+ | Run that plan request a few times and watch the path taken by the end effector in RViz. You'll notice that the planner has no objection to rotating the gripper in various ways; it hasn't been told not to do it. | ||
+ | |||
+ | So let's do just that: | ||
+ | |||
+ | <code lisp> | ||
+ | (defvar or-con nil) | ||
+ | (setf or-con | ||
+ | (roslisp: | ||
+ | : | ||
+ | | ||
+ | : | ||
+ | : | ||
+ | : | ||
+ | :x 0.0 | ||
+ | :y 0.0 | ||
+ | :z 0.0 | ||
+ | :w 1.0) | ||
+ | : | ||
+ | : | ||
+ | : | ||
+ | : | ||
+ | : | ||
+ | (plan-link-movement " | ||
+ | : | ||
+ | </ | ||
+ | |||
+ | (We leave some tolerance in the axis to help the sampler; a too strict constraint may be impossible to satisfy anyway.) | ||
+ | |||
+ | Unfortunately, | ||
+ | |||
+ | There is a solution however-- look below. | ||
+ | |||
+ | ==== A note about MoveIt!' | ||
+ | |||
+ | 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' | ||
+ | |||
+ | For the example above to work, you will have to close move_group, go to pr2_moveit_config/ | ||
+ | |||
+ | 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 == | ||
+ | |||
+ | Coming soon! | ||
+ |