Potential TF2 Buffer Timer Interface / Message Filters Design Issue

[SteveMacenski]

Required Info:

• Operating System: Linux
• Installation type: Binaries
• Version or commit hash: All in Foxy and newer
• DDS implementation: N/A
• Client library (if applicable): rclcpp

Description

We're running into a bit of an issue in ros-navigation/navigation2#2483 with @gezp. The TF2 buffer needs a timer interface in order to create timers in waitForTransform for message filter's tf2_ros subscriber. However, that timer interface is created off of our application's node that could be blocked from running by a long running service/action call or topic callback.

That would yield lots of unsavory error messages when that transforms either failed to be found or timed out because the the timer was never actually called since it's being blocked by another part of the application (at least, I believe that would happen, else that introduces a really nasty blockage while the entire message filter locks up waiting for the timer to run after a service call).

Tracking down the code:

• https://github.com/ros2/geometry2/blob/ros2/tf2_ros/src/buffer.cpp#L193 uses the timer interface we give it deriving from our application's node
• https://github.com/ros2/geometry2/blob/ros2/tf2_ros/include/tf2_ros/message_filter.h#L426 uses waitForTransform within the message filter
• add is called every time a new message is thrown into the filter https://github.com/ros2/geometry2/blob/ros2/tf2_ros/include/tf2_ros/message_filter.h#L576 and could cause the chain above to execute if the transform is not immediately available.

So we wanted to get some design advice about how to prevent this reaction or understand more about this design if the issue I describe is somehow inaccurate. The only solution I see is to somehow isolate TF2 from the application's execution, but not sure how to do that with the timer interface requirement to use message filters. It seems to me like this should be handled internally rather than creating this external interface if it is not possible to use a non-node derived timer interface which can be triggered completely independently from the application's code.

Given TF's importance within the ROS ecosystem, it seems to me that TF should be running largely independently from the application. #442 takes a good step there making sure that TF2 is spinning independent of the node by adding a separate callback group and spinning it within TF. This feels like another place that needs some attention since it is too closely coupled with the application's execution in a very subtle way that could cause real headaches for users of message filters or waitForTransform.

So open questions:

• Can TF create its own separate timer interface to use internally by default (and an option to set another if you like, similar to the default of spin_thread to true)?
• Can TF stick the timers into separate callback groups (or the appropriate mechanics for timers) to trigger separately from the applications execution (similar to the changes in Reduce transform listener nodes #442)?