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:moveit [2015/06/01 14:34] – mpomarlan | tutorials:intermediate:moveit [2015/06/18 06:18] – [Setting up your system] mpomarlan | ||
---|---|---|---|
Line 3: | Line 3: | ||
**Description: | **Description: | ||
- | **Next Tutorial: | + | **Next Tutorial: |
===== Setting up your system ===== | ===== Setting up your system ===== | ||
Line 11: | Line 11: | ||
Fortunately, | Fortunately, | ||
- | You will also need the tutorial initialization code. Go to the src folder of your ROS workspace and check whether the cram_tutorials folder exists, and whether it contains cram_intermediate_tutorials. If not, retrieve this code [[https:// | + | You will also need the tutorial initialization code. Go to the src folder of your ROS workspace and check whether the cram_tutorials folder exists, and whether it contains cram_intermediate_tutorials. If not, retrieve this code [[https:// |
- | ===== Initializing | + | ===== Initializing cram_moveit ===== |
You will need three terminal tabs. In one of them, run | You will need three terminal tabs. In one of them, run | ||
Line 106: | Line 106: | ||
Play a bit with the robot in RViz: move one arm (remember to click Plan and Execute to make sure the movement actually happens!), then use joint-states to look at some joint on the arm and see that it changes. | Play a bit with the robot in RViz: move one arm (remember to click Plan and Execute to make sure the movement actually happens!), then use joint-states to look at some joint on the arm and see that it changes. | ||
- | === Moving the robot === | + | Another function you can use to get the current robot state is get-planning-scene-info. To get a robot state ROS message (as opposed to a list of name-value pairs), use the following: |
+ | |||
+ | <code lisp> | ||
+ | (second (first (get-planning-scene-info : | ||
+ | </ | ||
+ | |||
+ | ==== Moving the robot ==== | ||
But actually, you can ask the robot to move from CRAM as well. In the REPL window, try the following: | But actually, you can ask the robot to move from CRAM as well. In the REPL window, try the following: | ||
Line 140: | Line 146: | ||
And if you look at the RViz window you should see that this time the robot' | And if you look at the RViz window you should see that this time the robot' | ||
+ | |||
+ | So far all movement requests have involved a beneath-the-hood call to MoveIt!' | ||
+ | |||
+ | However, motion planning has its own problems; it often produces strange looking trajectories and takes an unpredictable amount of time to complete, usually several tenths of a second. Put another way, motion planning is often overkill for the task you want the robot to do. Perhaps you have some other, simpler method to generate some waypoints, for example, based on some features of the environment, | ||
+ | |||
+ | For such purposes, you can use the compute-cartesian-path function. Here's an example call: | ||
+ | |||
+ | <code lisp> | ||
+ | (move-link-pose " | ||
+ | (compute-cartesian-path "/ | ||
+ | (second (first (get-planning-scene-info : | ||
+ | " | ||
+ | " | ||
+ | (list tuti: | ||
+ | 0.1 | ||
+ | 1.5 | ||
+ | t | ||
+ | (roslisp: | ||
+ | </ | ||
+ | |||
+ | which you are encouraged to try in the REPL window. The snippet above first makes sure that the robot goes to a certain position, then issues a request to compute a cartesian path to another pose. get-planning-scene-info is another cram-moveit function that we'll look at in the next section, for now we're just using it here to retrieve the current robot state. | ||
+ | |||
+ | First, let's see what happened in the RViz window. Notice that the robot state hasn't changed yet- compute-cartesian-path simply computes a trajectory, it won't execute it. You can do that with execute-trajectory as described above. In order to see the generated trajectory, enable the "Loop animation" | ||
+ | |||
+ | Notice how the arm's wrist moves in a straight line between the start and endpoint. In general, compute-cartesian-path will generate trajectories that link the waypoints via linear motions in cartesian space; that is, the link you specify waypoints for will move in a line between them. | ||
+ | |||
+ | Let's now look at the return values provided by compute-cartesian-path. In the REPL window, you should see something like this | ||
+ | |||
+ | <code lisp> | ||
+ | ((" | ||
+ | | ||
+ | | ||
+ | </ | ||
+ | |||
+ | You can rely on the order of the named pairs in the response to always be the same (" | ||
+ | |||
+ | <code lisp> | ||
+ | (second (second (compute-cartesian-path "/ | ||
+ | (second (first (get-planning-scene-info : | ||
+ | " | ||
+ | " | ||
+ | (list tuti: | ||
+ | 0.1 | ||
+ | 1.5 | ||
+ | t | ||
+ | (roslisp: | ||
+ | </ | ||
+ | |||
+ | The third part of the return value (" | ||
+ | |||
+ | Now let's look at the parameters. The first one ("/ | ||
+ | |||
+ | The next parameter is a list of waypoints (represented by pose messages); in our example, there' | ||
+ | |||
+ | The next two parameters are maximum distance (in Cartesian space) between points on the generated trajectory (so the smaller this number, the more points on the generated trajectory), | ||
+ | |||
+ | Finally, we have a true/false value indicating whether trajectory generation should care about obstacle collisions, and a ROS message describing what other kinematic constraints the trajectory should satisfy. We'll look at constraints in more depth in the next tutorial. | ||
==== Forward and Inverse Kinematics ==== | ==== Forward and Inverse Kinematics ==== | ||
Line 293: | Line 356: | ||
compute-ik takes a link name, a planning group, and a pose as parameters. Link and pose are self explanatory; | compute-ik takes a link name, a planning group, and a pose as parameters. Link and pose are self explanatory; | ||
- | If the group name is not recognized MoveIt will signal an INVALID-GROUP-NAME error. If the pose is unreachable, | + | If the group name is not recognized MoveIt will signal an INVALID-GROUP-NAME error. If the pose is unreachable, |
Note that at this time MoveIt!' | Note that at this time MoveIt!' | ||
Line 305: | Line 368: | ||
You may use robot states different than the current one when, for example, you want to see whether the robot can reach a location on a table with the robot base placed at various positions around that table. | You may use robot states different than the current one when, for example, you want to see whether the robot can reach a location on a table with the robot base placed at various positions around that table. | ||
- | compute-ik will also account for collisions with objects in the environment, | + | compute-ik will also account for collisions with objects in the environment, |
+ | |||
+ | Sometimes you may want to tell MoveIt! to not do any collision checking during IK queries. You can do this by using the key parameter : | ||
+ | |||
+ | <code lisp> | ||
+ | (compute-ik link-name planning-group-name pose : | ||
+ | </ | ||
==== Manipulating the environment ==== | ==== Manipulating the environment ==== | ||
Line 405: | Line 474: | ||
when you want to clear the objects you've added to the MoveIt! planning scene from CRAM, but want to keep cram-moveit' | when you want to clear the objects you've added to the MoveIt! planning scene from CRAM, but want to keep cram-moveit' | ||
- | ==== Collision checking ==== | + | So far we've only written to MoveIt!' |
- | (Work in progress: MoveIt! offers | + | <code lisp> |
+ | (get-planning-scene-info : | ||
+ | </ | ||
+ | |||
+ | for which the response will look something like | ||
+ | |||
+ | <code lisp> | ||
+ | ((" | ||
+ | </ | ||
+ | |||
+ | Notice how the response is again a list of named pairs. What is in the list depends on the nature of the query. For a query like | ||
+ | |||
+ | <code lisp> | ||
+ | (get-planning-scene-info | ||
+ | </ | ||
+ | |||
+ | you will instead get as a response (assuming you still have the cube object in the planning scene) | ||
+ | |||
+ | <code lisp> | ||
+ | ((" | ||
+ | </ | ||
+ | |||
+ | so as you can see the partner for "world object names" is a list of object names. | ||
+ | |||
+ | Earlier in this tutorial we've also seen | ||
+ | |||
+ | <code lisp> | ||
+ | (get-planning-scene-info :robot-state T) | ||
+ | </ | ||
+ | |||
+ | which puts a pair formed | ||
+ | |||
+ | You can combine several queries about the planning scene into one: | ||
+ | |||
+ | <code lisp> | ||
+ | (get-planning-scene-info : | ||
+ | </ | ||
+ | |||
+ | and the response will be a concatenation of the responses of the individual queries: | ||
+ | |||
+ | <code lisp> | ||
+ | ((" | ||
+ | | ||
+ | </ | ||
+ | |||
+ | When you issue several queries in a get-planning-scene-info call, do NOT rely on the order of the pairs in the list; use the first element of the pair to identify it. The docstring for get-planning-scene-info will explain what queries are available and what responses they produce. | ||
== Next == | == Next == | ||
- | (coming soon) | + | We've mentioned the topic of obstacles and collisions, [[tutorials: |
+ |