feat: acceleration and transport layer

[knzo25]

Description

This PR is part of a series of PRs that aim to accelerate the Sensing/Perception pipeline through an appropriate use of CUDA.

List of PRs:

• feat(autoware_cuda_pointcloud_preprocessor): a cuda-accelerated pointcloud preprocessor autowarefoundation/autoware.universe#9454 (pointcloud preprocessing)
• feat(autoware_pointcloud_preprocessor): cuda-accelerated pointcloud concatenation autowarefoundation/autoware.universe#9455 (concatenation)
• feat(autoware_lidar_centerpoint): added the cuda_blackboard to centerpoint autowarefoundation/autoware.universe#9453 (centerpoint)
• transfusion (TODO)
• OGM (TODO)
• feat: acceleration and transport layer #348 (aip_launcher)
• feat: acceleration and transport layer autowarefoundation/sample_sensor_kit_launch#111 (sample_sensor_kit_launch)

To use these branches, the following additions to the autoware.repos are necessary:

  vendor/cuda_blackboard:
    type: git
    url: git@github.com:knzo25/cuda_blackboard.git
    version: main
  vendor/negotiated:
    type: git
    url: https://github.com/osrf/negotiated.git
    version: master

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_layer.
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?

[mojomex]

The two branches differ only in their package, plugin and extra_params. The rest of the code could be merged into one to prevent future contributors from only modifying the one they're concerned about

[mojomex]

This was already the case before this PR, but this launch file is spaghetti code, making it very hard to understand at a glance what is going on.

Especially with the kind of multiplexed code of CUDA/non-CUDA, I'd suggest factoring out into a few functions like these:

def make_cuda_pointcloud_preprocessor(distortion_corrector_params, ring_outlier_params, vehicle_info, mirror_info) -> ComposableNode:
  ...

def make_vehicle_cropbox_filter(vehicle_info) ->ComposableNode:
  ...

[mojomex]

lidar_container_name, pointcloud_container_name and use_pointcloud_container could be confusing for users, how about for example container_name and use_shared_container, with the appropriate description=?

[mojomex]

Also, are users always expected to use a shared container when using CUDA?