feat: acceleration and transport layer

[knzo25]

Description

This is part of the series of PR related to autowarefoundation/autoware_universe#9722

List of PRs:

• feat(autoware_cuda_pointcloud_preprocessor): a cuda-accelerated pointcloud preprocessor autowarefoundation/autoware_universe#9454 (pointcloud preprocessing)
• feat(autoware_pointcloud_preprocessor): templated version of the pointcloud concatenation autowarefoundation/autoware_universe#10298 (concatenation - template refactor)
• feat(autoware_cuda_pointcloud_preprocessor): pointcloud concatenation autowarefoundation/autoware_universe#10300 (concatenation - cuda version)
• feat(autoware_lidar_centerpoint): added the cuda_blackboard to centerpoint autowarefoundation/autoware_universe#9453 (centerpoint)
• transfusion (TODO)
• feat(autoware_probabilistic_occupancy_grid_map): cuda accelerated implementation autowarefoundation/autoware_universe#9542 (OGM - the first implementation will be independent of the blackboard to ease the transition)
• feat: acceleration and transport layer #348 (aip_launcher)
• feat: acceleration and transport layer autowarefoundation/sample_sensor_kit_launch#111 (sample_sensor_kit_launch)

Depending on your machine and how many nodes are in a container, the following branch may also be required:
https://github.com/knzo25/launch_ros/tree/fix/load_composable_node
There seems to be a but in ROS where if you send too many services at once some will be lost and ros_launch can not handle that.

Related links

Parent Issue:

• Link

How was this PR tested?

The sensing/perception pipeline was tested until centerpoint for TIER IV's taxi using the logging simulator.

Notes for reviewers

The main branch that I used for development is feat/cuda_acceleration_and_transport_layer2.
However, the changes were too big so I split the PRs. That being said, development, if any will still be on that branch (and then cherrypicked to the respective PRs), and the review changes will be cherrypicked into the development branch.

Interface changes

An additional topic is added to perform type negotiation:
Example: input/pointcloud -> input/pointcloud and input/pointcloud/cuda

Effects on system behavior

Enabling this preprocessing in the launchers should provide a much reduced latency and cpu usage (at the cost of a higher GPU usage)

[knzo25]

Note: this PR will be kept as a draft until #337 it merged, at which point this PR will be reabsed

[knzo25]

The concatenated PR was merged, so after solving the conflicts and some recent changes, I am opening this PR 🙏

[mojomex]

Looking good! I left a few comments on readability/maintainability but that's all I think.
Is there a reason that x2(_gen2) is not covered?

[knzo25]

@mojomex
Thanks for the review. X2 Gen2 was not covered on purpose since it is very difficult to maintain a compatible version of all the PRs (XX1 is better in this sense). As soon as the universe PRs get merged and I can get an easy way to port and test it on X2 Gen2 I will sent the proper PR here

[knzo25]

@mojomex
Addressed all comments. I can not ask for a review since the previous comments were not added in the context of a require changes it seems

[mojomex]

I'd like the two container_name params to be merged but otherwise LGTM

[knzo25]

@mojomex
Addressed the last comment.
Since we are close to merging this, I left the cuda acceleration and shared containers as disabled.
To enable them, you just need to change the following settings:

<arg name="use_shared_container" default="false"/>
<arg name="use_cuda_preprocessor" default="false"/>

to

<arg name="use_shared_container" default="true"/>
<arg name="use_cuda_preprocessor" default="true"/>

in aip_xx1_launch/launch/lidar.launch.xml

[mojomex]

xx1-cuda.webm

Works up until concat. I had to shoehorn the new autoware_universe into pilot-auto.xx1 so I could not test everything (at least autoware_tensorrt_plugins did not build successfully).

Since this is not this PR's fault, I'd say LGTM.