Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision | ||
tutorials:intermediate:collisions_and_constraints [2015/06/05 09:03] – Added acm handling. mpomarlan | tutorials:intermediate:collisions_and_constraints [2015/06/05 13:20] – [Using kinematic constraints during planning] mpomarlan | ||
---|---|---|---|
Line 204: | Line 204: | ||
===== Constraint checking ===== | ===== Constraint checking ===== | ||
+ | |||
+ | 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 a glass full of water, in which case it shouldn' | ||
==== Primer to MoveIt! kinematic constraints ==== | ==== Primer to MoveIt! kinematic constraints ==== | ||
Line 258: | Line 260: | ||
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, | ||
+ | |||
+ | Let's 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.) | ||
+ | |||
+ | 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' | ||
+ | |||
+ | You can also define path constraints for **compute-cartesian-path** and **move-link-pose**, | ||
+ | |||
+ | == Next == | ||
+ | |||
+ | Coming soon! | ||
+ |