Add packages for providing stable interfaces

[isamu-takagi]

Checklist

• I've read the contribution guidelines.
• I've searched other issues and no duplicate issues were found.
• I've agreed with the maintainers that I can plan this task.

Description

Add interface class. See https://github.com/orgs/autowarefoundation/discussions/3922 for background.

Purpose

Autoware uses ROS messages for the following two purposes, so we will make it possible to separate them.

• interface
• data transfer implementation

Possible approaches

Add type alias and interface class. Developers can use interface classes instead of ROS messages with the following changes.

- rclcpp::Subscription<std_msgs::msg::Header>::SharedPtr sub_;
- rclcpp::Publisher<std_msgs::msg::Header>::SharedPtr pub_;
+ rclcpp::Subscription<interface_pkg::time_stamp::RosType>::SharedPtr sub_;
+ rclcpp::Publisher<interface_pkg::time_stamp::RosType>::SharedPtr pub_;

- void callback(const std_msgs::msg::Header & msg)
- {
-   rclcpp::Time stamp = msg.header.stamp;
- }
+ void callback(const interface_pkg::time_stamp::RosType & msg)
+ {
+   interface_pkg::time_stamp::Interface interface(msg);
+   rclcpp::Time stamp = interface.get_stamp();
+ }

- void on_timer()
- {
-   std_msgs::msg::Header msg;
-   msg.header.stamp = now();
-   pub_->publish(msg);
- }
+ void on_timer()
+ {
+   interface_pkg::time_stamp::Interface interface;
+   interface.set_stamp(now());
+   pub_->publish(interface.to_msg());
+ }

The interface class has a pointer or reference to ROS message.

using RosType = std_msgs::msg::Header;

Class Interface
{
public:
   Interface(RosType & msg) : msg_(msg) {}
   void set_stamp(rclcpp::Time stamp) { msg_.header.stamp = stamp; }
   rclcpp::Time get_stamp() { return msg_.header.stamp; }

private:
  RosType & msg_;
};

Definition of done

• Add rclcpp wrapper library.
• Add rclpy wrapper library.
• Merge and remove component_interface_utils package.
• Merge and remove tier4_api_utils package.

[doganulus]

Hi @isamu-takagi, I am interested in this proposal as a third-party verification tool developer, which needs a well-defined interface specification for Autoware and simulators.

Would this proposal include a machine-readable declarative specification format for interfaces? Is there any pointer for any work done in that direction?

Do you prefer this issue for further discussion or the original discussion thread?

[isamu-takagi]

@doganulus Are you talking about a file listing topics and services such as following? If so, that is not the goal of this task. But I want that too, so let's create a new discussion.

{ type: subscription, name: /diagnostics }
{ type: publisher, name: /diagnostics_agg }

[doganulus]

Yes @isamu-takagi, such a file is what I meant. I thought it may be used for a config for third-party tools that interact with Autoware. I have a few technical concerns, like how to address dynamic topic names and the overhead in this case. But maybe your proposal will allow us to see better the landscape.

Finally, in the current form, you do require a third-party client tool to use rclcpp to communicate with Autoware and get the benefits in this proposal? Can a DDS client based on corresponding IDLs be equally good or not?

[isamu-takagi]

Finally, in the current form, you do require a third-party client tool to use rclcpp to communicate with Autoware and get the benefits in this proposal?

@doganulus I've added a diagram about the implementation to this task description. As shown in the diagram, to use versioned message you need to use the wrapper class that will be added in this task.

Can a DDS client based on corresponding IDLs be equally good or not?

I don't think it can provide the same functionality. The problem is that ROS topics and services only have one layer of data structures. This means that when the data structure is changed due to implementation reasons, the interface is also affected. So at least two data structures are required: an implementation and an interface.

It may be possible if you can customize serialization and deserialization of DDS client, but it would be difficult.

[doganulus]

I cannot say for sure without measuring but the overhead of all these conversions seems to be the weakest point of the proposal. Maybe your example implementation can give any hint on how serious it could be. Have you considered publishing twice for old and new interfaces? (this has the overhead of bandwidth but is limited to the transition period.)

Ok I see this: https://github.com/orgs/autowarefoundation/discussions/3922#discussioncomment-7325535

Double publishing is really prohibitive?

[isamu-takagi]

I think there are some mixed issues about messages, so I will create a thread in the original discussion to organize it.

[isamu-takagi]

@doganulus I considered it again here https://github.com/orgs/autowarefoundation/discussions/3922#discussioncomment-8886781. In conclusion, it seems better to provide an accessor class. This method is simpler and does not require copying the message.

I will create a new discussion about interface definition files later.

[doganulus]

@isamu-takagi Thank you very much for letting me know!

For interface definitions files, I have something in my mind similar to Zenoh's use of configuration files as here:
https://github.com/eclipse-zenoh/zenoh-plugin-dds/blob/2cd1424c1b15d1bf730b01c0c9110a3031dd5119/DEFAULT_CONFIG.json5#L44C1-L67C38

I like to configure our apps to listen to some specific subset of Autoware topics (possibly determined dynamically) so having stable interfaces is quite important.

[stale]

This pull request has been automatically marked as stale because it has not had recent activity.