Create a messages_adapter package

[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

Create a package that will enable Autoware to convert given messages from autoware_msgs to autoware_auto_msgs. And publish them.

• The topic names and types can be configured.

Follow up from:

• Add vehicle control command message to AD API #3787
• refactor(autoware_auto_control_msgs): replace autoware_auto_control_msgs with autoware_control_msgs #3677 (comment)
• refactor(autoware_auto_control_msgs): replace autoware_auto_control_msgs with autoware_control_msgs #3674

Purpose

Helps resolving

• refactor(autoware_auto_control_msgs): replace autoware_auto_control_msgs with autoware_control_msgs #3674
• Simulators still use the old messages.
  • https://github.com/tier4/scenario_simulator_v2
  • https://github.com/tier4/AWSIM
• This package will act as an adapter between old autoware_auto_msgs and the new autoware_msgs
• This will give simulators time to adapt to the new message types.

Possible approaches

• The topic names and types are provided by the parameters.

Definition of done

• Create the package
• It has the functionality to convert from:
  • autoware_auto_control_msgs to autoware_control_msgs
  • More issues can be created to add more messages.

[xmfcx]

Which one should we go with?

• Option A: Spawning a new adapter node for each message.
• Option B: Having a single node that can subscribe and publish multiple messages.

Option A

Pros

• Adapters can be integrated into composable node containers, reducing the copy/network cost.
• Each message is handled by a separate node, allowing for better isolation and fault tolerance.
• Easier to debug and troubleshoot issues since each node is responsible for a single message.

Cons

• Increased node count, which may impact system resource utilization and scalability.
• Requires additional management and coordination overhead for managing multiple nodes.
• Potential increase in network overhead due to the communication between multiple adapter nodes.

Option B

Pros

• Only a single node needs to be managed, reducing management overhead.
• Simplified system architecture with fewer nodes to deploy and maintain.
• Potentially lower network overhead since communication is concentrated in a single node.

Cons

• It cannot be integrated into composable node containers, leading to increased copy/network cost.
• Lack of isolation between messages may increase the risk of failure propagation.
• Debugging and troubleshooting can be more challenging as multiple messages are handled within a single node.

Additional Considerations

• Option C: Implement a hybrid approach where a limited number of adapter nodes are used, each handling a group of related messages. This can strike a balance between system scalability and resource utilization, allowing for better control over the number of nodes while maintaining some level of isolation and fault tolerance.
• Evaluate the expected message load and processing requirements to determine if the increased node count in Option A will significantly impact system performance and resource consumption.

I think Option A is a safer option to go with. Can anyone comment on the potential drawbacks of having too many nodes running at a time? Even if they are composable nodes in containers?

cc. @isamu-takagi @mitsudome-r @wep21

[isamu-takagi]

@xmfcx I prefer Option A. Considering the load on the system, the impact of other processes is greater, so I think it's better to give priority to ease of use for now. It's not too hard to merge the separate nodes into one if someone needs it.

[isamu-takagi]

Can anyone comment on the potential drawbacks of having too many nodes running at a time? Even if they are composable nodes in containers?

@xmfcx I've heard that in rare cases, when there is too many nodes, MaxAutoParticipantIndex needs to be increased for Cyclone DDS, but I don't know the specifics. At least the I have never had a problem by number of nodes is large.

[xmfcx]

Thank you @isamu-takagi san, I will implement it with Option A then.