ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | Q&A
Ask Your Question

Is it safe and efficient for several threads to share a single tf::TransformListener object?

asked 2019-01-23 05:02:35 -0600

AndreasGustavsson gravatar image

updated 2019-01-26 07:34:26 -0600

I am developing a multi-threaded ROS (kinetic/melodic) node that will rely on tf::TransformListener to wait until it is possible to perform transformations (using waitForTransform(...)), and then perform the transformations (using lookupTransform(...)), if the transform exists.

My question is whether or not it is safe and efficient for all threads to share a single tf::TransformListener object:

  • Is it safe for several threads to call methods on a single tf::TransformListener object simultaneously?
  • If a thread calls one of the above-mentioned methods, will any other thread be able to call the same (or another) method on the same tf::TransformListener object and run in parallel with the first thread, or will the second thread be blocked until the first thread has finished its call? Having the threads running in parallel, without blocking, is of high importance.
  • In case threads would block (then to avoid threads from blocking), would it be okay to have several tf::TransformListener objects running inside a single node (one listener for each thread inside the node)? My intuition says that the same transformation trees would be built and maintained for each thread, which I think seems very bad from an efficiency point of view.

I apologize for any duplicate posting (I was unable to find the answer in the forum) but would be grateful for any answer you could provide!

edit retag flag offensive close merge delete


The design docs at least mention the words "thread safe" (here).

gvdhoorn gravatar image gvdhoorn  ( 2019-01-23 05:13:02 -0600 )edit

1 Answer

Sort by ยป oldest newest most voted

answered 2019-01-23 05:47:59 -0600

tfoote gravatar image

updated 2019-01-23 12:37:18 -0600

It is safe and efficient to call any of the public API methods. This is how it was designed.

It is highly recommended to only have one TransformListener, with multiple threads querying it. On most systems the largest overhead of the tf system is subscribing to the transform data and storing the data.

There are a few mutexes around iterable data structures to protect them from being corrupted by simultaneous operations. Queries are quite fast and will not sit and wait unless you ask for a timeout. But when they're in the timeout period they will not block other threads to have access.

However, from your description it sounds like you should rethink your design and not use waitForTransform. If you're going to be waiting on lots of data you should use a tf2::MessageFilter Here's a tutorial

If you want more details on the design and efficiency see the tf paper

edit flag offensive delete link more



+100 for tf2::MessageFilter.

gvdhoorn gravatar image gvdhoorn  ( 2019-01-23 07:00:23 -0600 )edit

Thank you so much for the answer and tip, Tully (@tfoote). I have managed to redesigned the structure, which is now relying on tf2 and tf2::MessageFilter instead of tf. It's running great and the code actually looks much nicer!

AndreasGustavsson gravatar image AndreasGustavsson  ( 2019-02-05 03:51:35 -0600 )edit

That tutorial link solved a huge number of timing issues for me, because I haven't found an example of how to set up the TF2 buffer as a member variable anywhere else.

M@t gravatar image M@t  ( 2020-08-05 17:47:40 -0600 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools



Asked: 2019-01-23 05:02:35 -0600

Seen: 799 times

Last updated: Jan 26 '19