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

Herman Bruyninckx Herman.Bruyninckx at mech.kuleuven.be
Fri Sep 10 05:40:40 UTC 2010


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?
>
> 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' :-)

Herman

>
> Ivan Dryanovski
> Bill Morris
>

-- 
--
   K.U.Leuven, Mechanical Eng., Mechatronics & Robotics Research Group
     <http://people.mech.kuleuven.be/~bruyninc> Tel: +32 16 328056
   EURON Coordinator (European Robotics Research Network) <http://www.euron.org>
   Open Realtime Control Services <http://www.orocos.org>
   Associate Editor JOSER <http://www.joser.org>, IJRR <http://www.ijrr.org>



More information about the ros-users mailing list