ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

When should I send geometric information over a topic as opposed to TF?

asked 2011-11-07 11:39:44 -0500

mmwise gravatar image

updated 2012-01-29 04:10:57 -0500

joq gravatar image

Please help in writing up a ROS best practice.

edit retag flag offensive close merge delete

4 Answers

Sort by ยป oldest newest most voted

answered 2011-12-09 03:39:02 -0500

bhaskara gravatar image

Some cases when tf is less suitable:

  • The coordinate frames naturally form a graph rather than a tree (e.g., a slam graph).
  • There is frequent reparenting of frames (e.g., a robot which is localized w.r.t. a changing local frame rather than a global one)
  • The transformations include additional information such as uncertainty estimates not present in the TF message type.
  • For efficiency, in situations where there are a large number of frames, most of which are only of interest to a few subscribers.
edit flag offensive delete link more



answered 2011-12-09 04:53:39 -0500

KruseT gravatar image

Suitable for: Robot joints, links, Sensor coordinate frames, and any other coordinate system that is going to be used as reference.

Not suitable for: Very noisy data.

Also consider: Using a topic rather than tf means you can more easily record / replay the data with rosbag/rxbag, as well as transfer the data between multiple robots.

edit flag offensive delete link more


"more easily record/replay"?? All tf data is simply published on the /tf topic. You will have to "rosparam set use_sim_time true" to get most nodes to deal with TF data from the past, but recording/replaying that data isn't very difficult.
fergs gravatar image fergs  ( 2011-12-09 16:04:48 -0500 )edit

answered 2011-12-16 05:03:29 -0500

Nick Armstrong-Crews gravatar image

In my experience, I find tf useful for real-time, single-estimation data; this breaks down when you want one to apply a correction to a geometric relationship in the past (like when a loop closure occurs during SLAM, and you want to use this new information to update the entire robot's path history), or when you have a couple things estimating the same transform (like odometry and laser scan matching, or two robots looking at the same thing). There are some ways to make tf do what you want in these cases, but they don't exhibit the same simplicity and elegance that tf shows for the real-time, single-estimation case.

Multi-robot tf over wifi, as others mentioned, won't work like you want it to out of the box. But a fairly lightweight fix is to use multiple /tf topics, say /robot_model_bandwidth_hog/tf and /i_wanna_communicate_these_few_transforms_to_other_robots/tf

edit flag offensive delete link more



answered 2011-12-10 00:42:57 -0500

If you for example just want to monitor the estimated position of an autonomous robot, using tf can mean significant overhead. Tf can easily consume bandwidth in the order of hundreds of kB/s, which can choke up connections in constrained scenarios (like RoboCup, where you have thousands of people/hundreds of teams/1-2 dozen leagues competing for Wi-Fi). An optional lower update rate tf topic for displaying the robot model in rviz for example could make sense for such situations.

edit flag offensive delete link more


Question Tools


Asked: 2011-11-07 11:39:44 -0500

Seen: 747 times

Last updated: Dec 16 '11