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 Tel: +32 16 328056 EURON Coordinator (European Robotics Research Network) Open Realtime Control Services Associate Editor JOSER , IJRR