Add vehicle control command message to AD API

[xmfcx]

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

Right now Autoware publishes /control/command/control_cmd: autoware_control_msgs/msg/Control in control/vehicle_cmd_gate/src/vehicle_cmd_gate.cpp to control the vehicle.

This issue aims to instead, publish a standardized AD API message.

Purpose

Internal messaging API shouldn't affect how outside platforms (simulators, vehicles) interface with the Autoware.

While working on this task: #3677 (comment) I've realized we are using autoware_auto_control_msgs for the:

• https://github.com/tier4/scenario_simulator_v2
• https://github.com/tier4/AWSIM

And with @mitsudome-r 's guidance, agreed that it's a better idea to use the AD API interface to update them.

Possible approaches

Explained in Definition of done section below.

Definition of done

• Raise this in Planning and Control WG
• Create a new message for Autoware's final output for the control command.
  • Create the message in https://github.com/autowarefoundation/autoware_adapi_msgs
• Publish it in an appropriate part of https://github.com/autowarefoundation/autoware.universe/tree/main/system/default_ad_api
  • Create the PR in https://github.com/autowarefoundation/autoware.universe

[xmfcx]

cc. @TakaHoribe @takayuki5168 @mehmetdogru @brkay54 @isamu-takagi @yukkysaito @mitsudome-r @yamacir-kit

[isamu-takagi]

I think this should be defined in the component interface rather than AD API. See the abstract section in this page for details.

[xmfcx]

@isamu-takagi I see, @mitsudome-r do you have any comments?

To communicate with simulators, we can consider following options:

Options

Option A - Use autoware_msgs

Pros

• Consistency: Using autoware_msgs maintains consistency across the codebase and communication, making it easier for developers to understand and work with the system.

• Less Development Time and Resources: It requires less development time and resources compared to defining a new interface, as it uses already defined messages.

• Compatibility: There's less risk of compatibility issues as autoware_msgs are designed to work with Autoware.

Cons

• Dependency: If there are significant changes in the future versions of autoware_msgs or if they are deprecated, it might affect the simulator side.

• Versioning Complexity: If different versions of autoware_msgs are used in different parts of the project, it can cause confusion and potential errors.

• Possible Inefficiency: If autoware_msgs contains data fields or structures that aren't necessary for the particular simulator integration, it could introduce inefficiencies in communication.

Using autoware_msgs allows us to maintain consistency and avoid unnecessary work, provided we handle the versioning process correctly. This approach will involve the following steps:

• Define Autoware Messages: Review and finalize the definitions for autoware_msgs. This will serve as a standard interface for the project.
• Implement in the Code Base: Once the definitions are ready, start incorporating them into the code base.
• Document Versioning Process: Create a comprehensive document detailing the versioning process of autoware_msgs. This should include details on how to manage changes, update versions, and how the versioning impacts the overall system.
  • I will work on this as soon as possible.

Option B - Define a new interface

Pros

• Customization: A custom interface allows you to design a communication protocol that perfectly suits your specific requirements. This could include specific data types, frequency, and synchronization procedures that might not be possible with the existing autoware_msgs.

• Efficiency: A custom interface can be designed to be more efficient, avoiding unnecessary data or instructions that may be present in the autoware_msgs.

• Future Proofing: Creating a new interface that takes into account potential future needs can help prevent the need for significant changes down the line.

Cons

• Resource Intensive: Defining and implementing a new interface can be time-consuming and requires a good deal of resources and expertise.

• Compatibility Issues: If not designed carefully, a new interface could lead to compatibility issues with other parts of the system or with future updates to Autoware or the simulators.

• Maintenance: Any new interface will need maintenance, versioning, and potentially debugging over time, increasing the long-term workload.

• Learning Curve: There could be a learning curve for anyone needing to work with the new interface, which may slow down development initially.

• Testing: A new interface will require extensive testing to ensure reliable operation. This can take time and resources.

I find this to be a little bit overkill. If we version autoware_msgs better, we shouldn't need to do this.

Option C - Use OSI

OSI (Open Simulation Interface) is an option but for our resources, timelines and goals, it's too much of an additional complexity.

[isamu-takagi]

@xmfcx Thank you for the suggestion. I agree with "Option A - Use autoware_msgs" and suggest the following for the disadvantages. There are two features.

• Separate message package into public and private parts for each component.
• Separate message definition by rosidl and interface definition.

Dependency: If there are significant changes in the future versions of autoware_msgs or if they are deprecated, it might affect the simulator side.

The component interface is the public part of the messages for each component. The current update frequency is a little high, but ideally stability is required. You are concerned about the impact on the simulator, but changing the component interface will affect all implementation of that component such as vehicle drivers and sensor drivers. The simulator works as a kind of driver, so we don't need to think about the simulator specially. If the public part becomes clear, the update frequency should decrease. Mandatory changes are handled by type adaptation described later.

Possible Inefficiency: If autoware_msgs contains data fields or structures that aren't necessary for the particular simulator integration, it could introduce inefficiencies in communication.

This should be resolved by separating the public and private parts of the message. Unnecessary data should probably be moved to private messages. Since the simulator performs by replacing some components such as vehicle and sensing, it is necessary to support the same interface as those components.

Versioning Complexity: If different versions of autoware_msgs are used in different parts of the project, it can cause confusion and potential errors.

Message definitions by rosidl include a serialization layer. If you convert to JSON like rosbridge, you can communicate if the fields are the same, but if you are communicating with DDS using rclcpp or rclpy, communication cannot be guaranteed if messages of different versions are mixed because its binary format may not be the same.

One solution is to separate message definition/serialization by rosidl and interface definition using type adaptation. This way, we can safely use multiple versions of the interface because only the latest message is used for serialization even if the message type changes.

[xmfcx]

@isamu-takagi thanks for the comprehensive suggestion you've provided.

To start simple, I've created following issue:

One solution is to separate message definition/serialization by rosidl and interface definition using type adaptation.

I should investigate the type adaptation rep thoroughly and then I can also add my thoughts about your proposal.

Is it OK to write a simple converter-publisher node for now?

And we can consider your proposal in a new issue, where we can discuss about the versioning autoware_msgs.

• I will create this issue today.
  • Establish and document the versioning system for the autoware_msgs autoware-documentation#379

I am closing this issue for now, we can discuss versioning in detail in the new issue, you can also copy your message there.