Handling transforms in Autoware - Managed Transform Buffer proposal

[amadeuszsz]

Introduction

In ROS 2 we obtain transforms via:

// Traditional ROS 2 approach
tf2_ros::Buffer tf_buffer;
tf2_ros::TransformListener tf_listener(tf_buffer);

// On-demand transform lookup
geometry_msgs::msg::TransformStamped transform;
try {
    transform = tf_buffer.lookupTransform("target_frame", "source_frame", tf2::TimePointZero);
} catch (tf2::TransformException &ex) {
    RCLCPP_WARN(logger, "Transform lookup failed: %s", ex.what());
}

This might be sufficient for simple applications, but in complex robotics systems like Autoware, it might lead to performance bottlenecks. The reason is that this approach requires a tf2_ros::TransformListener instance for each node that needs to perform transform lookups. Each tf2_ros::TransformListener instance implicitly creates a node with a subscription to the /tf and /tf_static topics. This brings overhead - CPU usage increases, and each additional node requires a thread.

Managed Transform Buffer as it is now

The Managed Transform Buffer is a wrapper around the standard ROS 2 tf2_ros::Buffer & tf2_ros::TransformListener. Some time ago, we started using it mainly in the Sensing component.

Long story short: it reduced CPU utilization for the sensing component, but when trying to scale it up to the whole Autoware system, benchmarks showed a problem. It turned out that the implemented mechanism can increase CPU utilization due to DDS discovery. Therefore, we designed a new mechanism, benchmarked again, and came here with results.

Managed Transform Buffer redesign proposal

The new design boosts performance with the same principles in mind as the initial implementation of Managed Transform Buffer:

• Static transforms do not need a listener.
• Dynamic transforms can share the same TransformListener instance in a Composable Node Container.

The issue related to DDS discovery is mitigated by using a Static Transform Server - an additional node which exposes a service for Managed Transform Buffer use. How does it work?

Scenario A - request for static transform:

1. User-space node requests static transform.
2. Managed Transform Buffer requests Static Transform Server for transform.
3. Static Transform Server responds with transform and information that the transform is static.
4. Managed Transform Buffer caches the static transform and returns it to the user-space node. Next time, Managed Transform Buffer will return the cached static transform without requesting the Static Transform Server.

Scenario B - request for dynamic transform:

1. User-space node requests dynamic transform.
2. Managed Transform Buffer requests Static Transform Server for transform.
3. Static Transform Server responds with no transform and information that the transform is dynamic.
4. Managed Transform Buffer initializes tf2_ros::TransformListener & tf2_ros::Buffer or uses an existing one from the Composable Node Container. Next time, Managed Transform Buffer will directly call tf2_ros::Buffer for the transform without requesting the Static Transform Server.

Benchmark

In a sample scenario for Autoware:

• Managed Transform Buffer OFF - CPU usage 11.82, 70 transform_listener_impl_xxxxxxxxxxxx nodes.
• Managed Transform Buffer ON - CPU usage 11.47, 16 transform_listener_impl_xxxxxxxxxxxx nodes.

No latency changes were observed. Detailed analyze available in TIER IV INTERNAL LINK.

Effect on Autoware system

The upgraded version of Managed Transform Buffer will require an extra node to run in the background - Static Transform Server. It is a simple node that exposes a service for only the inner implementation of Managed Transform Buffer to request static transforms. Users don't need to interact with the server.

This node can be added to one of the launch files:

• autoware.launch.xml - always runs regardless of turned off subcomponents, but not running when the user runs a single component directly.
• tier4_autoware_api_component.launch.xml - risk of not running if the user sets launch_api to false.
• tier4_*_component.launch.xml - separate server for each component, but unnecessary overhead of multiple transform_listener_impl_xxxxxxxxxxxx.

Apart from the decision about Static Transform Server placement, there is a scenario when the user runs a single node by hand. Therefore, Managed Transform Buffer will have a suitable initialization mechanism:

• User-space node creates an instance of Managed Transform Buffer.
• Managed Transform Buffer constructor checks if the server is available for N milliseconds (timeout). If unavailable, it will fallback to the dynamic TF listener.
• Timeout can be set in Managed Transform Buffer constructor. In case of large systems, it can be overridden by tf_server_timeout_ms ROS parameter using Autoware's global_params.launch.py.

Summary

The Managed Transform Buffer slightly reduces CPU utilization and significantly reduces the number of running transform_listener_impl_xxxxxxxxxxxx nodes. The proposed approach for this feature integration would not affect OSS users, because:

• Standard implementation will always be available.
• Upgraded implementation will automatically fallback to the standard implementation if requirements are not met (no Static Transform Server available).

On top of that, the Managed Transform Buffer has a more handy API which avoids boilerplate code while handling transforms.

The proposed implementation source code - https://github.com/autowarefoundation/managed_transform_buffer/tree/feat/server-based-tf-buffer.

Looking forward to your comments!