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

[Bill Morris]

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.

> > Second, we think it could be really useful if some filtering mechanism
> > is built in tf to accommodate conflicting or partial tf's being
> > published (like 1 frame having 2 parents). I'm not sure exactly how
> > this can be achieved, but one idea is to add covariance information to
> > each tf, and treat them in the same way that robot_pose_ekf treats
> > Pose messages. Currently, If I want to have different parts of the
> > system contribute different pose components for the same frame, I need
> > to publish those as Pose messages, assemble them somewhere, and then
> > publish a tf. Perhaps there can be "hard" tf's, which work in the way
> > current transforms do, and "soft" tf's, which are run through a filter
> > if there are conflicts. It might also be a way of solving the "4-bar
> > link" problem that someone raised earlier on the mailing list. This
> > shift from deterministic to probabilistic paradigm would probably
> > require an overhaul of the whole tf mechanism, but the advantages are
> > obvious.
> 
> The name standardisation and the probabilistic version of frames are,
> indeed, two very useful improvements. And yes, we need real
> _standardisation_ if we want to scale code up to 'world domination' :-)

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.

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