TF on multiple robots gets crowded
I have been running experiments with a team of four KUKA youBots communicating via ROS over WiFi. I have observed that the /tf topic is crowded with a lot of transforms not of interest to most of the TF consumers. By the design of TF, all transforms are broadcast globally, and it's up to each ROS node to sort through them and find the ones it is interested in. Are there any plans to implement partial TF sharing according to the hierarchy, perhaps by a publish/subscribe model---maybe hidden from users within the TF library?
For example, suppose robot1 broadcasts the frame of each joint in its arm as well as the fingers, wheel orientations, etc. These transforms are of interest to processes onboard robot1 and to rviz running on a workstation. But robot2-4 do not care about most of these transforms. They only want to know the basic position of the robot (i.e. /robot1/base_link) for collision avoidance purposes.
How big an impact are these excess TF messages? Let's say we have 2 ROS nodes on each robot that use the tf library. There are 5 arm joints, 2 fingers, and 4 wheel positions = 11 frames that no other robot cares about. There are 3 other robots. Since it's a managed WiFi network, each message must go up to the AP and then down to the neighboring robots. By default, all these frames are broadcast at 20 Hz. So that is 2311220 = 2640 WiFi messages per second. We have observed severe WiFi lag, which was significantly attenuated by turning off transmission of the arm joints and dropping broadcast rates on the rest. However, this is not a desirable solution in the long run.
I can imagine a robot-local TF bus on a topic, say /robot1/tf. A TF server running on robot1 would maintain a list of transforms of interest to others. Thus, it would send only /robot1/base_link to the topics /robot2/tf, robot3/tf, etc. and to the global /tf for rviz. Thus, we could run high-speed mobile manipulation loops on robot1 while sending only 2420 = 160 WiFi messages per second, plus 11*20 = 220 WiFi messages destined for rviz (thus not essential to the experiment).
Is anything like this in the works? I realize that network topology is a complex topic, but the current solution appears inadequate for all but the simplest multi-robot installations. Thank you!
-ross