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

Revision history [back]

click to hide/show revision 1
initial version

What you're requesting/suggesting is a bit of an anti-pattern. As you can see from your own answer it's relatively simple to implement. There's an issue that you have to precompile it with all datatypes known which doesn't scale well, to be completely generic.

But the question is whether you should be doing this. The design of the tf system is setup such that you communicate data in it's original raw format and transform it prior to use into the coordinate frame of choice for your algorithm. This avoids inherent degredation of the data through multiple floating point transformations. Similarly, you lose potentially valuable semantic information about the sampling process. Such as the origin of a point cloud from a sensor. For example a native point cloud from a sensor can be used to ray trace and clear closer obstacles.

And there's also significant costs to putting an intermediate node in the middle incurring potentially doubling the costs of sending and receiving the data. And in most cases the computational cost to transform the data is much lower than the cost to transmit it, thus having each consumer transform it is more efficient.

The other challenge with trying to "pre-transform" the data is that you have to all agree on the coordinate transform into which it is most useful. A simple example of a navigation system, may want the point clouds to be represented in the odometry frame for the local planner, but the map frame for the global planner. The most efficient way to deal with that is to send it the point cloud from the sensor and let them both transform it into whatever frame they are parameteraized to use. The navigation user can reconfigure it to a potentially application specific frame w/o effecting anything else on the system. It looks nice on a system diagram to avoid a potential "extra transform", but until that's actually diagnosed as your bottle neck I'd strongly recommend against trying to use it generically. The abstraction of not expecting data to arrive in any specific frame is very valuable when doing system integration.