TILDE, message tracking framework across multiple nodes

[nabetetsu]

We are in the process of developing TILDE and would like to post it on Show & Tell for members' feedback and questions. (https://github.com/tier4/TILDE)
TILDE is a framework for tracking messages in a multiple nodes (In this text, I name it Path).As a first target, we are trying error handling of Path time-out.

Each node in Autoware is unable to retrieve information for nodes more than one hop away from itself. TILDE clarifies the causal relationship between nodes and input/output messages at multiple nodes that form a Path.
This allows us to answer questions such as, "Which sensor information was used to create the output in some node", "Which of the buffered messages was used", "What is the elapsed time of processing from one node to another," etc. and so on.

The way to clarify causality:

• Easy to infer causality = input data used to compute output data obviously, and no message buffering
• Causality needs to be specified explicitly = message buffering is performed
  • Example 1: concat_filter in Figure 1, saves multiple input messages to buffer queue so it needs to clarify the causal relationship between input messages and output messages.
  • Example 2: message_filters (internally buffering messages. We are working on a way to encapsulate this in the TILDE layer in the future)
  • Tip: This API can also be used for message flow construction in CARET (https://github.com/orgs/autowarefoundation/discussions/2630))
• As a limitation, Paths with a loop structure like the one in Figure 2 are excluded from the target

To use TILDE, we need to replace rclcpp::Node, create_subscription, and create_publisher to TILDE APIs such as tilde::Node, create_tilde_subscription, create_tilde_publisher.

By default, when a node outputs a message, TILDE assumes that the node uses the most recent message of each subscribed topic.
If you want to track message buffer, you need to call the explicit API to indicate the correspondence.

This is a conceptual sample code. You can see the full sample at TILDE/tilde_sample.
See relay_timer_with_buffer.cpp#L96 for explicit API.

class RelayTimerWithBuffer : public tilde::TildeNode
{
public:
  RelayTimerWithBuffer(...) {
    // create tilde subscription. Same signiture as rclcpp::Node::create_subscription
    sub_pc_ = this->create_tilde_subscription<PointCloud2>(...);

    // tilde subscriber. Same signiture as rclcpp::Node::create_publisher
    pub_pc_ = this->create_tilde_publisher<PointCloud2>(...)

    // timer callback using message buffer
    auto timer_callback =
       [this]() -> void
       {
           auto msg = read_from_message_buffer();

           // tilde explicit API
           pub_pc_->add_explicit_input_info(
             this->sub_pc_->get_topic_name(),
             msg->header.stamp);
        
           pub_pc_->publish(msg);
   }

private:
  rclcpp::Subscription<PointCloud2>::SharedPtr sub_pc_;
  tilde::TildePublisher<PointCloud2>::SharedPtr pub_pc_;  // TildePublisher
}; 

Below are the results of the Path elapsed time made in the PoC implementation. This Path is a flow from LiDAR input to vehicle_control.

The tree structure from output to sensor input is shown in the results:

• trajectory_follower takes /localization/twist and /planning/scenario_planning/trajectory as input
  • The respective latency are 5ms and 15 ms for ROS time (simulation time) and 3ms and 12 ms as diff of std::chrono::steady_clock.
• There is a concat filter( /sensing/lidar/concatenated/pointcloud ) leading to /planning/scenario_planning/trajectory
• CMD to vehicle (/control/trajectory_follower/lateral/control_cmd) is sent after 304 ms to 433 ms from sensor inputs.

Currently, in order to track messages, the information necessary for tracking is sent as a TILDE tracking topic at the same time as the original message. This tool can be run concurrently with Autoware to analyze this tracking message and observe the elapsed time of Autoware's Path during operation.

On the other hand, if the tracking information is exchanged via messages, we need to consider the increase in network traffic, ordering guarantees, etc., so we are thinking of eventually extending the messages to add the meta-information needed for message tracking. The ultimate goal is to be able to retrieve meta-information as output by the tool during runtime for each node.