ros / geometry2

A set of ROS packages for keeping track of coordinate transforms.
190 stars 278 forks source link

No way of distinguishing extrapolation to the future from extrapolation to the past #350

Open cosama opened 5 years ago

cosama commented 5 years ago

I have an application, where I might have some initial lookups that would require extrapolation to the past. These lookups could just be ignored and the program should move on to the next value to look up. However, subsequent lookups should wait until the transform is available (if an extrapolation to the future would be required).

I don't really see a way of achieving such a behavior in python, except for maybe using a can_transform call with the return_debug_tuple=True flag and then parsing the message. Seems not a really good way of getting this done.

In C++ I could probably use a message_filter, however, these are not available in python (if you ask me python thus is still not really a first-class-citizen).

Is there any other way of doing this, or can we add a mechanism that gives finer control over ExtrapolationException?

tfoote commented 5 years ago

The ExtrapolationException could be extended to have subclasses for future or past. Though we need to be careful as sometimes data is inconsistent and some transform data could be in the future and some in the past if the transform requested spans multiple links. So there would probalby need to be a third type.

As an intermediate workaround you could use _getLatestCommonTime and compare your queried timestamp as a first order heuristic. It's a backwards compatibility API that's not recommended, but if you plan to migrate to more expressive exceptions it would be fine to use in the intermediate timeframe.

cosama commented 5 years ago

getLatestCommonTime was exactly what I was looking for. I literally spend hours digging through the code and didn't see that one. Thanks for pointing that out.

I used the return_debug_tuble=True flag and filtered the error message. That seemed to work too, but as I said probably not optimal either.