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

Jack O'Quin jack.oquin at gmail.com
Fri Sep 10 13:22:25 UTC 2010

On Fri, Sep 10, 2010 at 2:21 AM, Bill Morris <morris at ee.ccny.cuny.edu> wrote:
> On Fri, 2010-09-10 at 07:40 +0200, Herman Bruyninckx wrote:
>> On Thu, 9 Sep 2010, Ivan Dryanovski wrote:
>> > On the topic of TF's we have had 2 ideas floating around the lab, so I
>> > will raise them in this thread.
>> >
>> > First, it would be useful to have a tutorial explaining the convention
>> > of naming frames. I've come across "/base_link", "base_footprint",
>> > "odom", "odom_combined", "world", "map", "nav" etc. I have the feeling
>> > that the general answer to questions like this seems to be "Use
>> > whatever names work for you" and that's understandable, but some
>> > standardization could be useful, especially for groups working on
>> > similar robots. We were debating the naming system of our frames for
>> > the quadrotor, trying to fit in concepts such as global gps maps and
>> > local building maps, and we found trying to reuse the current frame
>> > names for the pr2 may not be optimal. A reoccurring problem is that
>> > ground robots use East-North-Up frames, while aircraft use
>> > North-East-Down for navigation.
>> What is the exact problem in this case?
> One of our problems has been ordering the TFs correctly.
> Previously we have been using gmapping to generate a 2D pose estimate
> with an input of projected 2D laser scans and a heading estimate
> provided by a gyro and a compass. gmapping accepts a transform from the
> laser to the base of the robot. In the near term we would like to be
> able to perform co-operative tasks with aircraft and ground robots.
> Given the following:
> gmapping provides a map of discovered local areas and wants
>  East-North-Up
> gyro may be in North-East-Down, ENU or something else depending on how
>  it's mounted
> compass is in NED  East = 90 degrees with magnetic deviation
> laser is relative to the base (base_link?) of the robot
> aircraft should be using NED internally for the controller so that
>  a positive pitch tilts the nose up. Also headings may need to be
>  magnetic or true.
> GPS is basically NED with no magnetic deviation
> Aircraft Maps are NED
> Ground robot controller has X=fwd, Y=left, Z=up
> 2D map of a building floor plan could be ENU or NED
> The problem is how do you efficiently stack the above transforms so that
> both robots can use the same 2D/3D discovered map and global world map
> if each TF can only have one parent.
> My proposed solution was that the ground robot (and everything else)
> should be rewritten to support NED since at least magnetic north would
> be oriented correctly. Some people in the lab disagreed with that
> approach.

My understanding of the current ROS tf package is that it handles this
problem fairly well under the covers due to using quaternions to
represent orientation. IIUC, the quaternion representation is
unambiguous, unlike the many and various roll, pitch and yaw

The main difficulty I have with quaternions is that I lack an
intuitive feel for them, so I need to translate them into some
familiar form of roll, pitch and yaw in order to picture what's going

The current tf release has only a few primitives for translating RPY
to and from a quaternion. Perhaps a richer, well-documented set with
descriptive names like tf::createQuaternionFromAeronauticRPY() might

Then, your aircraft could define the map transforms using NED, and
ground vehicles could generate equivalent ENU representations, where
needed, both working from and with the same underlying TF

> I would be happy to find a page that explains what base_link, world,
> odom and etc mean, as opposed to what I think they mean.

I second this suggestion. I "think" I know what they mean, but I sure
could be wrong.

> It would also be swell if we could come to a consensus for default names
> and a good default tf tree configuration that covers most cases from GPS
> map to indoor local map for aircraft and ground robots. This would allow
> researchers to build navigation and mapping algorithms with some
> expectation that available datasets might be in the same format.


> It would also be nice if we could all agree that yaw, pitch, and roll
> are not angles but angular rates. The names of the angles are heading,
> elevation and bank angle, as per "Quaternions and Rotation Sequences" by
> Jack B. Kuipers page 85. That however would probably require fixing this
> page which is just a disaster but sort of explains the scope of the
> problem. http://en.wikipedia.org/wiki/Talk:Yaw,_pitch,_and_roll

Given the 24 different meanings of roll, pitch and yaw, I suspect the
best we can do is clearly define which meaning we intend within a
given application domain.

More information about the ros-users mailing list