# Can someone explain geometry_msgs as used for robot arm poses e.g.?

I'm trying to work with a robot arm, and struggling to find anything to explain in detail how anything works. I have gone through the ROS documentation tutorials, and the PR2 moveit tutorial for example. Pose goals are used but never explained.

What do position and orientation variables refer to in this context? Position and orientation of what relative to what? What does the origin refer to, where is it specified and how is it retrieved?

The robot I'm working with has 7 joint angles. Are poses and joint specifications redundant, or can they be used together? It seems from my specification that both are simultaneously significant, though I would think the joint angles completely specify the position. Again, what does a pose goal position and orientation mean for a robot arm determined by 7 joint angles?

Thanks! -Jason

P.S. If you are thinking that I just don't know enough about robotics or ROS to understand, please be so kind as to direct me to where I can find information sufficient to actually LEARN (I'm an ECE PhD btw).

Originally posted by japalmer29 on ROS Answers with karma: 11 on 2017-07-11

Post score: 1

What do position and orientation variables refer to in this context? Position and orientation of what relative to what? What does the origin refer to, where is it specified and how is it retrieved?

geometry_msgs/Pose is a 6D Cartesian pose, relative to 'nothing' - or whatever the sender and receiver agree upon out of band. The comment in the message definition:

A representation of pose in free space, composed of position and orientation.

geometry_msgs/PoseStamped is also a 6D Cartesian pose, but the message includes a header, which include a frame_id field which allows the sender to specify to what the pose is relative. Again, the comment in the message definition:

A Pose with reference coordinate frame and timestamp

Note that this header also includes a stamp field, so not only is a PoseStamped explicit wrt its space dimension, but also the time dimension.

The robot I'm working with has 7 joint angles. Are poses and joint specifications redundant, or can they be used together? It seems from my specification that both are simultaneously significant, though I would think the joint angles completely specify the position. Again, what does a pose goal position and orientation mean for a robot arm determined by 7 joint angles?

There are no messages to specify "joint specifications" in geometry_msgs, so I think you are referring to sensor_msgs/JointState here. In that case, yes: a 7 element vector with joint angles would completely define a robot pose, but only in joint space or in the robots local frame (whatever that is) after FK.

As to "are they redundant": sort-of, but I'm not sure I see a problem there: sensor_msgs/JointState is typically used to report joint angles coming from a sensor of sorts. It's obviously all in joint space. geometry_msgs/Pose can be used to report measurements - such as coming from a localisation framework fi - but is typically just used to store 6D poses.

One area where they would both appear would be in MoveIt, where you can specify joint space goals as well as Cartesian goals to plan to. But in those cases you only ever specify one or the other, never together - as one would expect.

Edit:

I don't understand the 4d orientation vector for example. I guess this is a quaternion?

Have you seen the msg documentation? From here:

Point position
Quaternion orientation


So, yes. orientation is of type Quaternion. In the linked documentation, clicking on the Quaternion typename then gets you to here:

This represents an orientation in free space in quaternion form.

So a Pose is a Point and a Quaternion combined, which together specify the 6D Cartesian pose of a link in free space. I don't know how to make this more clear.

I don't know what it supposed to be being oriented by this quaternion. The robot base, or "body"? I know how to set a pose goal for the robot arm, but I have no idea which part is being positioned or oriented!

That is completely dependent on what you made the defined end effector or planning link (or whatever nomenclature the motion planning framework that you are using uses). That would be independent of the definition of these messages.

The messages define a pose. How it gets used is up to the component consuming those messages.

Finally: the message spec defines how the data should be structured and to a certain extend, what its semantics are. Not what the data should be used for, or how a component must interpret it. So that will always depend on the usage specification that the consuming component gives you. Example: a motion planning component might state that it accepts Pose messages on a certain topic and that it will make the curently active end effector follow the messages that it receives. The messages themselves will then not contain any reference to that end effector, but they will express the target pose of the end effector.

Originally posted by gvdhoorn with karma: 86574 on 2017-07-11

This answer was ACCEPTED on the original site

Post score: 0

Comment by gvdhoorn on 2017-07-11:
As to whether there is documentation about all this: there might be, but I haven't looked.

Comment by japalmer29 on 2017-07-11:
Thanks very much for your reply. I'm ordering a couple of ROS programming books and a Robotics textbook which will hopefully help, though it would be really nice if there were an online tutorial, e.g. in MoveIt, that explained what the pose variables mean when specifying the PR2 arm pose goal e.g.

Comment by japalmer29 on 2017-07-11:
I don't understand the 4d orientation vector for example. I guess this is a quaternion? I don't know what it supposed to be being oriented by this quaternion. The robot base, or "body"? I know how to set a pose goal for the robot arm, but I have no idea which part is being positioned or oriented!

Comment by gvdhoorn on 2017-07-11:
Note that I focused on the use of Poses in manipulation contexts, as that was what you seem to be doing as well. In reality Pose messages are used in many different applications, from UAVs to mobile bases to things that have nothing to do with robots whatsoever. As a 'pose' is basically a ..

Comment by gvdhoorn on 2017-07-11:
.. mathematical concept, that is all possible without having change anything to the msg itself.