Hi,

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.

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.

Ivan Dryanovski
Bill Morris