Revision history [back]

Everyone has a different definition of what exactly "realtime" means (hard, soft, generally "fast" enough, etc) so its difficult to answer as posed.

However, lookupTransform has a timeout value (e.g. if can't be found within a period returns failure so it doesn't block to control loop) https://docs.ros2.org/foxy/api/tf2_ros/classtf2__ros_1_1BufferClient.html. So in some definitions of the word, yes, I think it can be called in a realtime control loop since you can set the timeout such that TF queries never block the loop to miss a scheduled update (though obviously if you timeout and don't have a valid transform, then that cycle would not be able to compute its value properly).

Because you're requesting information from an arbitrary frame to an arbitrary frame, I don't think anyone can say for 100% certainty in 100% of cases that you'll receive a response in under N nanoseconds because you could be transforming the data between 1 reference frame (easy) or 1,000,000 reference frames in the transformation tree. But assuming you're working with a "normal" situation, I see no reason why the latency would be insufficient for real-time use (depending on your definition or requirements).

However, if you're instead asking if anyone's certified TF2 as "real-time", the answer is a clear no.

I think it should be pretty trivial for you to come to the conclusion though. If you set up your TF tree + publish TF updates sufficiently fast, you should be able to just make a simple while true loop and query your transform of interest and measure the time to find it. If its under your real-time schedule, then you're probably OK for soft real-time requirements with some proper error handling.