[ros-users] Design decisions behind libTF...?

[Bill Morris]

On Fri, 2010-09-10 at 10:17 +0200, Adolfo Rodríguez Tsouroukdissian
wrote: 
> Maybe in aerial robotics there is a different convention for naming
> orientations and angular rates, but that does not make it _wrong_ to
> call it differently in other application domains. In fact, it is not
> uncommon in the general robotics literature to use the terms roll,
> pitch and yaw  to refer to a specific Euler/fixed angle combination
> (c.f. Section 2.8 of Craig's Introduction to Robotics, citation below,
> for an example). The important thing is to document unambiguously the
> used conventions.

This is one of those cases where the correctness is irrelevant. Both
usages are common which is a mess, but having guidelines or best
practices that describe reasonable defaults will help developers avoid
these situation where users download a navigation algorithm from ros.org
and find out the hard way that yaw has more that one meaning.

I have my personal preferences but realistically if I were to create a
best practices page I would state something like:

----
The terms "yaw", "pitch" or "roll" are commonly used to denote both the
orientation and the angular velocity. This usage should be avoided to
prevent confusion and a postfix should be added to specify if it is an
angle or a rate of change.

BAD GOOD
Ground Aerial
----------------------------------
yaw yaw_angle heading
yaw_rate yaw_rate
pitch pitch_angle elevation
pitch_rate pitch_rate
roll roll_angle bank_angle
roll_rate roll_rate

The usage of "y", "p" and "r" are acceptable when a function accepts
both angles and rates as inputs.

These conventions should be used in both documentation and in variable
naming to prevent confusion and accidents.
----


As a side note, pre-robotics, in aviation and I believe in nautical
usage, the terms heading and yaw were used to disambiguate orientation
and rate of change in orientation.