Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionLast revisionBoth sides next revision | ||
tutorials:intermediate:moveit [2015/06/03 13:03] – Added info about compute-cartesian-path mpomarlan | tutorials:intermediate:moveit [2016/07/19 13:23] – [Moving the robot] gkazhoya | ||
---|---|---|---|
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 23: | Line 23: | ||
In another tab, run | In another tab, run | ||
- | < | + | < |
- | roslaunch | + | roslaunch |
</ | </ | ||
Line 31: | Line 31: | ||
Finally, in the last tab run the roslisp REPL. Once it has started up, type the following at its command prompt: | Finally, in the last tab run the roslisp REPL. Once it has started up, type the following at its command prompt: | ||
- | <code lisp>(swank:operate-on-system-for-emacs | + | <code lisp> |
- | + | CL-USER> (ros-load:load-system "cram_intermediate_tutorial" | |
- | (in-package :moveit) | + | CL-USER> |
- | + | CL-USER> (in-package : | |
- | (tuti: | + | </ |
- | This will load the tutorial code (and its dependencies, | + | This will load the tutorial code (and its dependencies, |
- | For now, tuti: | + | For now, '' |
<code lisp> | <code lisp> | ||
- | (roslisp: | + | (roslisp: |
- | (moveit: | + | (cram-moveit: |
</ | </ | ||
Line 84: | Line 84: | ||
</ | </ | ||
- | Notice that it's a list of lists (joint-name joint-values), | + | Notice that it's a list of lists '' |
<code lisp> | <code lisp> | ||
Line 104: | Line 104: | ||
</ | </ | ||
- | 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 '' |
+ | |||
+ | Another function you can use to get the current robot state is '' | ||
+ | |||
+ | <code lisp> | ||
+ | (second (first (get-planning-scene-info : | ||
+ | </ | ||
==== Moving the robot ==== | ==== Moving the robot ==== | ||
Line 116: | Line 122: | ||
and look in the RViz window for a reaction. After some planning time, usually a fraction of a second, the robot' | and look in the RViz window for a reaction. After some planning time, usually a fraction of a second, the robot' | ||
- | The parameters to move-link-pose are, in order, a link name, a planning group, and a pose-stamped object representing the pose to move to. The pose is something you will typically define yourself in your programs; either hard-coded (as in this tutorial) or through some generation process like [[tutorials: | + | The parameters to '' |
- | Link names and planning groups are found in the *.srdf file for the robot you're working with. For this tutorial, this is the default *.srdf file in the pr2_moveit_config package. You can run MoveIt! with other robots as well ([[http:// | + | Link names and planning groups are found in the '' |
Sometimes you just want to know a trajectory between a robot' | Sometimes you just want to know a trajectory between a robot' | ||
Line 124: | Line 130: | ||
<code lisp> | <code lisp> | ||
(multiple-value-bind (start-robot-state-p planned-trajectory-p) | (multiple-value-bind (start-robot-state-p planned-trajectory-p) | ||
- | (plan-link-movement " | + | |
- | | + | (setf tuti: |
- | | + | (setf tuti: |
</ | </ | ||
Line 153: | Line 159: | ||
" | " | ||
" | " | ||
- | tuti: | + | |
0.1 | 0.1 | ||
1.5 | 1.5 | ||
t | 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. | 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" | + | 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 | 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> | <code lisp> | ||
- | ((" | + | ((" |
+ | (" | ||
+ | (" | ||
</ | </ | ||
Line 183: | Line 193: | ||
(roslisp: | (roslisp: | ||
</ | </ | ||
+ | |||
+ | The third part of the return value (" | ||
Now let's look at the parameters. The first one ("/ | Now let's look at the parameters. The first one ("/ | ||
Line 356: | 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 456: | 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: |
+ |