tf lookup & stream server

10 views
Skip to first unread message

Paul Mathieu

unread,
Jan 11, 2014, 8:13:59 PM1/11/14
to ros-s...@googlegroups.com
Hi all,

Not so long ago, I have overheard that some people had performance related problems with ROS, and that tf was responsible for a significant part of it. One of the main issues was that even for a one-time transform lookup, a full TfListener was implemented, resulting in substantial memory, cpu and network overhead.
A quick fix for that was to have a lookup_transform service. Because I prefer asynchronous processes, I coded a small tool that leveraged actionlib to achieve the same goal, only to recently discover that this was already implemented into tf2 in a nearly identical way.

In my frenzy though, I went further and implemented a tf streamer, with C++ and Python client interfaces. The basic idea is that for non-critical parts of the code, a single topic containing one or more transforms sent at a regular pace (~10Hz) would be enough. The stream server utilises an actionlib interface for the control API, and regular topics for the streaming of transforms.

Because it is quite small, I was thinking about maybe submitting it for integration into tf2. Before that, I'd like to ask around if something else already does that, or if it is worth submitting at all.
The code has not been published yet (company rules...), but I should be able to convince my managers to open-source it if some of you are interested.

Any thoughts?

Thanks,

Paul

Tully Foote

unread,
Feb 10, 2014, 6:55:48 PM2/10/14
to ros-s...@googlegroups.com
Hi Paul, 

That's definitely something that would be useful in general. As you mentioned the remote action based API for querying is built into tf2's design. 

I think that the streaming approach is valuable. An action based API is probably good for controlling the stream. Possibly using the feedback topic as the stream. For optimization I have envisioned this sort of tool taking a list of frame_id's and a frequency. And then actually rebuilding a composite spanning tree for all the frame_ids of interest with only a single hop between any of them so as to remove any unnecessary frame's from the transmission. 

I think this can be a simple standalone package which would potentially be merged into the geometry_experimental tree. 

Tully


--
You received this message because you are subscribed to the Google Groups "ROS tf Special Interest Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ros-sig-tf+...@googlegroups.com.
To post to this group, send email to ros-s...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ros-sig-tf/e096d95f-4a33-41bf-96e8-ad532165fefe%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Reply all
Reply to author
Forward
0 new messages