chore(tier4_perception_launch): perception launcher refactoring

[technolojin]

Description

The perception has many launch options, such as perception_mode, lidar_detection_model, use_*, and so on.
As result, it is very difficult to trace the perception pipeline, such as which SW component is used, which topic is published from where.

• Structure of the perception launch style

  1. Parameters: parameter arguments, mainly the parameter file paths
  2. Pipeline junctions: arguments that determine the pipeline structure
  3. External interfaces: topic names of inputs from outside and outputs of the module
  4. Internal interfaces: inter-connecting topic names, inputs and outputs of sub modules
  5. Sub modules: actual launcher of SW modules

• Module update

  1. Module means a group of nodes consisting the (perception) pipeline
  2. Detectors and mergers were defined as modules in previous refactoring
  3. object filters and validator, pointcloud map filter were newly separated as modules
  4. the detection launcher and the merger modules will call the filter modules

Tests performed

Manually tested in a local environment with the following variants.

• camera_lidar_radar_fusion pointpainting
• camera_lidar_radar_fusion centerpoint
• camera_lidar_fusion pointpainting
• camera_lidar_fusion centerpoint
• camera_lidar_fusion apollo
• radar
• lidar centerpoint centerpoint_tiny
• lidar centerpoint centerpoint

Effects on system behavior

Not applicable.

Interface changes

Not applicable.

Pre-review checklist for the PR author

The PR author must check the checkboxes below when creating the PR.

• I've confirmed the contribution guidelines.
• The PR follows the pull request guidelines.

In-review checklist for the PR reviewers

The PR reviewers must check the checkboxes below before approval.

• The PR follows the pull request guidelines.

Post-review checklist for the PR author

The PR author must check the checkboxes below before merging.

• There are no open discussions or they are tracked via tickets.

After all checkboxes are checked, anyone who has write access can merge the PR.

[miursh]

I think it would be beneficial to avoid using default values in lower-level launch files.
To be specific:

• tier4_perception_component.launch.xml: Define parameters that are likely to change here, in this central launch file.
• perception.launch.xml: Avoid using default arguments. Only parameters that are difficult to specify in tier4_perception_component.launch.xml should be provided here.
• Subsequent Launch Files: Avoid using default arguments in launch files called from perception.launch.xml

This is just my suggestion. What are your thoughts on this approach?

[technolojin]

I think it would be beneficial to avoid using default values in lower-level launch files. To be specific:

* tier4_perception_component.launch.xml: Define parameters that are likely to change here, in this central launch file.

* perception.launch.xml: Avoid using default arguments. Only parameters that are difficult to specify in tier4_perception_component.launch.xml should be provided here.

* Subsequent Launch Files: Avoid using default arguments in launch files called from tier4_perception_component.launch.xml.

This is just my suggestion. What are your thoughts on this approach?

@miursh
I agree. I am one of the user that suffer from the hidden default values.
However, this PR is already large and I consumed a lot of time in the testing.
Can I fix that point in a separated PR?

[technolojin]

@miursh
I created a PR #7440 to answer your suggestion.

[YoshiRi]

Thanks! LGTM