# When using TF API in a plugin, can I specify the topic from which to listen to the transformations?

For example the tf::TransformListener::transformPose method uses transformations published on /tf topic to compute a given pose in different coordinate frame. But I would like this method to take the transformations published on different topic and do the same. How can I do that?

The motivation for this is to trick the clock over-sensitive tf package to keep working even though there are two sources of /clock messages that are not synchronized. The clocks are not synchronized because each of them is coming from different simulation that was started at different time and runs at different speed. As long as there is one /tf topic, it might get a message from one simulation with timestamp 2:14 and after that a message from the other simulation with a timestamp 1:52 or so, and it will throw the jump back in time error.

So I was thinking if I remap the /tf from the first simulation onto /sim1/tf and the other /sim2/tf and then make the plugins take the transformations from their respective topic, it might work.

edit retag close merge delete

The motivation for this is to trick the clock over-sensitive tf package [..]

"over sensitive"? TF is essentially tracking spatio-temporal data. How is it going to do that properly without taking time into account?

( 2019-06-11 09:29:49 -0600 )edit

@gvdhoorn yes, I understand why people need it this way, but I would happily use tf functionality without the time checking. And whatever message comes last, just use it. Or at least allow for some interval where the time is close enough.

( 2019-06-11 09:40:36 -0600 )edit

That would be disabling some of the core parts of TF. I don't think that would be supported.

It's not time checking, it's using time to interpolate data it doesn't have. If you have conflicting sources of time -- essentially multiple time-dimensions -- that becomes very difficult.

( 2019-06-11 09:48:31 -0600 )edit

If you'd like your nodes to just completely ignore a clock topic, then you could just remap it such that none of the messages on the 'other' clock topic are ever seen by your node.

This will of course not mean that the results of TF transformation and/or lookups make any sense, but that would be what I believe you are asking for.

( 2019-06-11 09:49:47 -0600 )edit
2

Seeing all your other questions, I believe the proper way to approach this would be to write a Gazebo plugin that is able to control the simulation based on an external clock.

This has been asked on the Gazebo Answers forum: Using an external simulation clock.

It could be that an implementation of this already exists somewhere. You'd just have to find it.

Otherwise you'd have to write one.

Anything else would -- I believe -- basically come down to hacks or workarounds.

( 2019-06-11 09:52:16 -0600 )edit

Sort by » oldest newest most voted

TF will accept transform data out of order. Remapping /tf will not resolve your problem of having two clocks that are not synchronized.

You should not be publishing multiple clocks that are not synchronized. The /clock topic is designed to be an authoritative source of time. And time has certain semantics such as being monotonic. If you jump from 2:14 to 1:52 anything that's keeping a time history of data needs to reset as any data collected in the last 22 seconds is now in the future and thus invalid. This usually happens when you're playing back a bag file and you loop, or you've reset your simulation to an earlier point in time. The TF libraries are principaled and this is something that they need to respond to. Anything else with state should be clearing their state when time jumps backwards too.

I suggest reading a little bit more about the Clock at http://wiki.ros.org/Clock

Your multiple sources of time will also screw up any timers that are active in the system. On a running system you can't have two different timelines active. The most common way to resolve this sort of issue is to coordinate your simulators to run in lock step. The simplest way to do that is to pick the one that goes slower and have it publish the /clock and have the other one wait for it to step forward.

more

The simplest way to do that is to pick the one that goes slower and have it publish the /clock and have the other one wait for it to step forward.

Thing is: Gazebo doesn't support this. Which is really rather unfortunate, as running multiple Gazebo simulations isn't even that uncommon. It also excludes Gazebo from being integrated into co-simulation setups easily.

( 2019-06-11 10:01:37 -0600 )edit