generating quaternions from roll, pitch and yaw

[Jack O'Quin]

Can anyone direct me to some code for generating ROS-style quaternions
from vehicle roll, pitch and yaw angles?

[James Bowman]

There's Python code in tf in src/tf/transformations.py, function
quaternion_from_euler().

Post by Jack O'Quin
Can anyone direct me to some code for generating ROS-style quaternions
from vehicle roll, pitch and yaw angles?
--
 joq
------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
ros-users mailing list
https://lists.sourceforge.net/lists/listinfo/ros-users

[Jack O'Quin]

Post by James Bowman
There's Python code in tf in src/tf/transformations.py, function
quaternion_from_euler().

Thanks!

Now, if I can just figure out which of the 24 axis sequences our GPS uses...
:-/

[Tully Foote]

If you're looking for c++ methods I've started a summary at
http://www.ros.org/wiki/tf/RotationMethods The kdl and eigen methods are
not filled out yet but they will be soon.

Tully

Post by Jack O'Quin

Post by James Bowman
There's Python code in tf in src/tf/transformations.py, function
quaternion_from_euler().

Thanks!
Now, if I can just figure out which of the 24 axis sequences our GPS uses...
:-/
--
joq
------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
ros-users mailing list
https://lists.sourceforge.net/lists/listinfo/ros-users

[Jack O'Quin]

Post by Tully Foote
If you're looking for c++ methods I've started a summary at
http://www.ros.org/wiki/tf/RotationMethods  The kdl and eigen methods are
not filled out yet but they will be soon.

Thanks! That's very helpful. The transformations.py script was a big
help already.

Fortunately, my GPS device (Applanix POS-LV) has excellent
documentation. From it, I was able to conclude that the device uses
what ROS calls "rzyx".

According to Wikipedia, this is a fairly standard definition for
aerospace applications: +z is down, and +y points towards the
starboard wing. They also use +x = North, +y = East, and +z = down
for the global reference frame. This is somewhat upside-down from the
"usual" robotics coordinates: local +z = up; +y = left; and global +x
= East; +y = North; +z = up.

http://en.wikipedia.org/wiki/Tait-Bryan_angles

I have not had time to write the code, yet. But, given the
information provided, it looks fairly straightforward. It is
interesting that the problem is not with the quaternions, but with the
ill-defined terms "roll, pitch and yaw". I've used them for several
years without realizing how ambiguous they were (24 different
meanings, arrgh!).

Your efforts are worthwhile, I think. I am probably not the only one
ignorant about the math of this stuff. It does not help that so many
different groups seem to have their own idiosyncratic notation and
"standards". A few clear examples can go a long way.

At some point, I want to figure out how to use the GPS error
ellipsoids to estimate the Odometry msg covariance matrices. That
looks challenging, but not strictly necessary for now. The message
interface sets the covariances to zero, as if the values were not
random variables (which they are, of course).

[Tully Foote]

Hi Jack,
All 24 conventions as well as problems with singularities are why we chose
quaternions over using euler angles as our primary representation.

I've tried to capture the conventions we're using in ROS on this page
http://www.ros.org/wiki/tf/CoordinateFrameConventions

Just for reference in ROS we have standardized on X forward Y left, Z up.
And if you're not using quaternions we're standardizing on fixed axis
rotations about XYZ called roll pitch yaw respectively.

Tully

Post by Jack O'Quin

Post by Tully Foote
If you're looking for c++ methods I've started a summary at
http://www.ros.org/wiki/tf/RotationMethods The kdl and eigen methods

are

Post by Tully Foote
not filled out yet but they will be soon.

Thanks! That's very helpful. The transformations.py script was a big
help already.
Fortunately, my GPS device (Applanix POS-LV) has excellent
documentation. From it, I was able to conclude that the device uses
what ROS calls "rzyx".
According to Wikipedia, this is a fairly standard definition for
aerospace applications: +z is down, and +y points towards the
starboard wing. They also use +x = North, +y = East, and +z = down
for the global reference frame. This is somewhat upside-down from the
"usual" robotics coordinates: local +z = up; +y = left; and global +x
= East; +y = North; +z = up.
http://en.wikipedia.org/wiki/Tait-Bryan_angles
I have not had time to write the code, yet. But, given the
information provided, it looks fairly straightforward. It is
interesting that the problem is not with the quaternions, but with the
ill-defined terms "roll, pitch and yaw". I've used them for several
years without realizing how ambiguous they were (24 different
meanings, arrgh!).
Your efforts are worthwhile, I think. I am probably not the only one
ignorant about the math of this stuff. It does not help that so many
different groups seem to have their own idiosyncratic notation and
"standards". A few clear examples can go a long way.
At some point, I want to figure out how to use the GPS error
ellipsoids to estimate the Odometry msg covariance matrices. That
looks challenging, but not strictly necessary for now. The message
interface sets the covariances to zero, as if the values were not
random variables (which they are, of course).
--
joq

[Jack O'Quin]

Post by Tully Foote
Hi Jack,
 All 24 conventions as well as problems with singularities are why we chose
quaternions over using euler angles as our primary representation.

I like the quaternions, just need to figure out how to work with them.

Post by Tully Foote
I've tried to capture the conventions we're using in ROS on this page
http://www.ros.org/wiki/tf/CoordinateFrameConventions
Just for reference in ROS we have standardized on X forward Y left, Z up.
And if you're not using quaternions we're standardizing on fixed axis
rotations about XYZ called roll pitch yaw respectively.

Those are the definitions we already use, because of player/stage.
Our GPS uses the "aerospace standard" where X is forward, Y is right
and Z is down. But, I can deal with that.
#include <tf/transform_broadcaster.h>

geometry_msgs::Quaternion odom_quat;
odom_quat.setRPY(roll, pitch, yaw);

That would have been nice, but does not work because the geometry_msgs
class does not define the setRPY() mutator. I was confused by the
difference between a tf::Quaternion and a geometry_msgs::Quaternion.
After reading the header definitions, I came up with this approach,
which does seem to work (pending further testing).

// translate roll, pitch and yaw into a Quaternion
tf::Quaternion q;
q.setRPY(roll, pitch, yaw);
geometry_msgs::Quaternion odom_quat;
tf::quaternionTFToMsg(q, odom_quat);

Is there a cleaner way to handle this?

[Tully Foote]

Jack,

Post by Jack O'Quin
#include <tf/transform_broadcaster.h>
geometry_msgs::Quaternion odom_quat;
odom_quat.setRPY(roll, pitch, yaw);
That would have been nice, but does not work because the geometry_msgs
class does not define the setRPY() mutator. I was confused by the
difference between a tf::Quaternion and a geometry_msgs::Quaternion.
After reading the header definitions, I came up with this approach,
which does seem to work (pending further testing).
// translate roll, pitch and yaw into a Quaternion
tf::Quaternion q;
q.setRPY(roll, pitch, yaw);
geometry_msgs::Quaternion odom_quat;
tf::quaternionTFToMsg(q, odom_quat);
Is there a cleaner way to handle this?

Unfortunately not with the current design. Messages in ROS do not have
methods defined on them besides the basic accessors. This is a conscious
decision to keep consistency across all different language implementations.
This means that a python user and a C++ user see the same interface.

There are a few convenience functions (mostly useful for the 2d usages) in
tf which may be expanded in the future, but they need to go through a review
phase. For now there are the following functions:
tf::Quaternion tf::createIdentityQuaternion();
tf::Quaternion tf::createQuaternionFromYaw(double yaw);
geometry_msgs::Quaternion tf::createQuaternionMsgFromYaw(double yaw);
double tf::getYaw(tf::Quaternion);
double tf::getYaw(geometry_msgs::Quaternion);

Tully

[Jack O'Quin]

Jack,

Post by Jack O'Quin
#include <tf/transform_broadcaster.h>
 geometry_msgs::Quaternion odom_quat;
 odom_quat.setRPY(roll, pitch, yaw);
That would have been nice, but does not work because the geometry_msgs
class does not define the setRPY() mutator.  I was confused by the
difference between a tf::Quaternion and a geometry_msgs::Quaternion.
After reading the header definitions, I came up with this approach,
which does seem to work (pending further testing).
 // translate roll, pitch and yaw into a Quaternion
 tf::Quaternion q;
 q.setRPY(roll, pitch, yaw);
 geometry_msgs::Quaternion odom_quat;
 tf::quaternionTFToMsg(q, odom_quat);
Is there a cleaner way to handle this?

Unfortunately not with the current design.  Messages in ROS do not have
methods defined on them besides the basic accessors.  This is a conscious
decision to keep consistency across all different language implementations.
This means that a python user and a C++ user see the same interface.

That's what I figured. No one would want the message interface
encumbered in that way.

What I have is not so bad. My only reason for pointing it out was
that it took some digging to figure out what to do. An example or two
on the wiki could have helped (if findable).

There are a few convenience functions (mostly useful for the 2d usages) in
tf which may be expanded in the future, but they need to go through a review
tf::Quaternion  tf::createIdentityQuaternion();
tf::Quaternion tf::createQuaternionFromYaw(double yaw);
geometry_msgs::Quaternion tf::createQuaternionMsgFromYaw(double yaw);
double tf::getYaw(tf::Quaternion);
double tf::getYaw(geometry_msgs::Quaternion);

I saw those. It would have helped me to have had something like
createQuaternionFromRPY() and createQuaternionMsgFromRPY().

Obviously, these suffer from the 24-fold ambiguities I have learned to
fear when dealing with Euler angles. But, clearly documented, they
could be of considerable assistance to people porting code from other
frameworks.

Thanks again for you assistance in this matter, Tully.

[Jack O'Quin]

Post by Tully Foote
I've tried to capture the conventions we're using in ROS on this page
http://www.ros.org/wiki/tf/CoordinateFrameConventions
Just for reference in ROS we have standardized on X forward Y left, Z up.
And if you're not using quaternions we're standardizing on fixed axis
rotations about XYZ called roll pitch yaw respectively.

Don't all those angles use the right-hand rule about their respective
axes of rotation?

+roll is to the right (i.e. starboard wing down, port wing up)
+pitch would be nose-down (which seems odd somehow)
+yaw is to the left

[Jack O'Quin]

Post by Jack O'Quin

Post by Tully Foote
I've tried to capture the conventions we're using in ROS on this page
http://www.ros.org/wiki/tf/CoordinateFrameConventions
Just for reference in ROS we have standardized on X forward Y left, Z up.
And if you're not using quaternions we're standardizing on fixed axis
rotations about XYZ called roll pitch yaw respectively.

Don't all those angles use the right-hand rule about their respective
axes of rotation?
 +roll is to the right (i.e. starboard wing down, port wing up)
 +pitch would be nose-down (which seems odd somehow)
 +yaw is to the left

Also, how is the "angular" Vector3 of the Twist msg defined? (This
is imbedded in the Odometry msg.)

I presume that angular.x is roll velocity in radians per second
(direction defined above). Similarly, angular.y would be pitch
(rad/s) and angular.z would be yaw (rad/s).

Don't these angular velocities suffer from the same 24 interpretations
as the transform angles? If so, which interpretation is implied?
Would it be better (and more consistent) to define angular velocities
using the first derivative of the orientation Quaternion?

[Eric Berger]

Angular velocity is actually a well-defined vector quantity which
doesn't depend on any ordering between axes or have any singularities,
and so doesn't have the same problems as orientation representations.
The length of the vector tells you the speed of rotation, and the
direction tells you the axis around which it rotates.

You are correct that they are measured in radians/sec.

--Eric

Post by Jack O'Quin

Post by Tully Foote
I've tried to capture the conventions we're using in ROS on this page
http://www.ros.org/wiki/tf/CoordinateFrameConventions
Just for reference in ROS we have standardized on X forward Y left, Z up.
And if you're not using quaternions we're standardizing on fixed axis
rotations about XYZ called roll pitch yaw respectively.

Don't all those angles use the right-hand rule about their respective
axes of rotation?
 +roll is to the right (i.e. starboard wing down, port wing up)
 +pitch would be nose-down (which seems odd somehow)
 +yaw is to the left

Also, how is the "angular" Vector3 of the Twist msg defined?   (This
is imbedded in the Odometry msg.)
I presume that angular.x is roll velocity in radians per second
(direction defined above).  Similarly, angular.y would be pitch
(rad/s) and angular.z would be yaw (rad/s).
Don't these angular velocities suffer from the same 24 interpretations
as the transform angles?  If so, which interpretation is implied?
Would it be better (and more consistent) to define angular velocities
using the first derivative of the orientation Quaternion?
--
 joq
------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
ros-users mailing list
https://lists.sourceforge.net/lists/listinfo/ros-users

[Jack O'Quin]

Post by Eric Berger
Angular velocity is actually a well-defined vector quantity which
doesn't depend on any ordering between axes or have any singularities,
and so doesn't have the same problems as orientation representations.
The length of the vector tells you the speed of rotation, and the
direction tells you the axis around which it rotates.

Thanks! I appreciate your patience with my ignorance.

Post by Eric Berger
You are correct that they are measured in radians/sec.

So, is Twist relative to the vehicle's frame of reference, while Pose
is in the odometry frame?

[Wim Meeussen]

Post by Jack O'Quin
So, is Twist relative to the vehicle's frame of reference, while Pose
is in the odometry frame?

If you're talking about the Odometry message
<http://www.ros.org/doc/api/nav_msgs/html/msg/Odometry.html>, the
twist represents the motion of the child_frame_id, represented in the
reference frame of the child_frame_id.

So, if your odometry message defines frame_id = odometry_frame, and
child_frame_id = vehicle_frame, then the twist represents the velocity
of the vehicle in the vehicle's reference frame.

Wim

[Jack O'Quin]

Post by Wim Meeussen

Post by Jack O'Quin
So, is Twist relative to the vehicle's frame of reference, while Pose
is in the odometry frame?

If you're talking about the Odometry message
<http://www.ros.org/doc/api/nav_msgs/html/msg/Odometry.html>, the
twist represents the motion of the child_frame_id, represented in the
reference frame of the child_frame_id.
So, if your odometry message defines frame_id = odometry_frame, and
child_frame_id = vehicle_frame, then the twist represents the velocity
of the vehicle in the vehicle's reference frame.

Yes, that is exactly what I was asking. Thanks.

I missed that comment through looking in the wrong place. Sorry for the noise.

[Tully Foote]

Two clarifications below:

I saw those. It would have helped me to have had something like
createQuaternionFromRPY() and createQuaternionMsgFromRPY().

Obviously, these suffer from the 24-fold ambiguities I have learned to
fear when dealing with Euler angles. But, clearly documented, they
could be of considerable assistance to people porting code from other
frameworks.

These APIs use fixed axis notation which does not suffer from the 24x
ambiguities. For sequence does not matter.

Post by Jack O'Quin
Don't all those angles use the right-hand rule about their respective
axes of rotation?
+roll is to the right (i.e. starboard wing down, port wing up)
+pitch would be nose-down (which seems odd somehow)
+yaw is to the left

That's correct All systems are right handed.

Tully