feat(autoware_sample_designs): compose the AD API, system and vehicle components from design modules

[technolojin]

Description

Completes the AutowareSample reference system so every component is composed from design modules, and carries the launch side of the node design audit in autowarefoundation/autoware_universe#13298.

1. AD API split into adapi and api

The AD API is now composed from two modules instead of one wrapper:

• AdapiNodes.module — the default AD API implementation, one composable node per API domain (interface, localization, routing, autoware_state, diagnostics, fail_safe, heartbeat, …). It instantiates as the adapi component.
• AdapiHelpers.module — the RViz adaptors that turn poses and goals into API requests, plus the external RTC cooperate API. It instantiates as the api component and brings a new AdapiRtcController.node design.

The two names are not interchangeable. /adapi/node/* is a public name: the diagnostic graph configs and the planning_factor RViz plugin hard-code it, so the node component keeps adapi while the helper component takes api.

The AD API components also needed path: / handling — without it the 41 /api/* names exported as /adapi/api/*, which left the engage path dead in planning simulation. They are bound through system-level remaps in AutowareSample.system.yaml.

2. System component composed from design modules

New System.module (diagnostic graph, component state, MRM handling and host monitors, 12 instances) with SystemMonitor.module and ComponentStateMonitor.module underneath, plus two base:/remove: variants:

• System_sim.module — no host resource monitors.
• System_psim.module — no host resource monitors, reduced component state monitor (ComponentStateMonitor_psim.module drops the pointcloud map, NDT pose, obstacle pointcloud and traffic signal topic monitors).

Tier4SystemWrapper.node and the universe_system.parameter_set back it.

3. Vehicle component composed from design modules

New SampleVehicle.module in sample_vehicle_launch, composing SampleVehicleInterface.node with RawVehicleCmdConverter.node, replacing the SampleSystemVehicleWrapper launch wrapper.

4. Planning and control module connections

The inputs that the node design audit exposed as having no source are wired: the planning factor publishers and their eleven connections into ControlEvaluator, steering_status on the planning modules, the internal velocity limit path into the selector, the operation mode state, and the hazard lights selector input rename that follows autowarefoundation/autoware_universe#13342.

5. Service ports declared as clients

PerceptionE2ESimulation.module and PointcloudMapFilter.module declared service_pointcloud_map_diff as a subscriber; it is a service client. Correcting the port kind also fixed an E2E failure where the object_lanelet_filter could not load into pointcloud_container.

Related links

Parent Issue:

• Modularization of components #1939

Related:

The per-component node design PRs this branch is the launch counterpart of — the reference system below was built and run against all of them together:

• fix(autoware_goal_distance_calculator): declare the route input as a remap target autoware_universe#13333 (common), fix(autoware_geo_pose_projector): declare the map projector info input as a remap target autoware_universe#13334 (localization), fix(design): align the simulator node designs with the packages they describe autoware_universe#13335 (simulator), fix(design): align the vehicle node designs with the packages they build autoware_universe#13336 (vehicle), fix(design): align the sensing node designs with the packages they describe autoware_universe#13337 (sensing), fix(design): align the system node designs with the packages they describe autoware_universe#13338 (system), fix(design): align the perception node designs with the packages they describe autoware_universe#13339 (perception), fix(design): align the control node designs with the packages they describe autoware_universe#13340 (control), fix(design): align the evaluator node designs with the packages they describe autoware_universe#13341 (evaluator), fix(design): align the planning node designs with the packages they describe autoware_universe#13342 (planning)
• fix(design): align the node designs with the packages they describe autoware_universe#13298 — the umbrella those ten are split from
• fix(autoware_collision_detector): declare the operation mode state input as a remap target autoware_universe#13312 — the CollisionDetector fix, already merged
• fix(control, planning): connect the module inputs left without a source #1972 — the first eight commits of this branch are that PR's content; this PR supersedes and extends it
• fix(design): align the autoware_core node designs with the packages they describe autoware_core#1416 autoware core node updates

Dependencies

This PR cannot build on its own — the modules here instantiate node designs that live in other repositories. It needs, in autoware_core:

• fix(design): align the autoware_core node designs with the packages they describe autoware_core#1416 — GnssPoser gains the map_projector_info subscriber that SampleSensorKitGnss.module connects, and BehaviorVelocityPlanner gains the nine /planning/planning_factors/* publishers that BehaviorPlanning.module connects. Without it those two connections name ports that do not exist.
• Two further autoware_core changes that are not yet in a PR: the five AD API node designs in autoware_default_adapi / autoware_adapi_adaptors that AdapiNodes.module and AdapiHelpers.module instantiate, and the MotionVelocityPlanner planning factor publishers that MotionPlanning.module connects.

and in autoware_universe, the per-component PRs listed under Related links — in particular:

• fix(design): align the system node designs with the packages they describe autoware_universe#13338 carries the fifteen autoware_default_adapi_universe AD API designs plus ComponentStateMonitor, DiagnosticGraphAggregator and OperationModeAvailabilityConverter, which AdapiNodes.module and System.module resolve against.
• fix(design): align the control node designs with the packages they describe autoware_universe#13340 carries the OperationModeTransitionManager interfaces, #13342 the BehaviorPathPlanner planning factors, and #13335 the DummyDiagPublisher parameters.

How was this PR tested?

This branch is the launch side the node design changes were tested with, against a workspace carrying every dependency listed above: all ten autoware_universe component PRs, autowarefoundation/autoware_core#1416, and the two autoware_core changes that still need a PR.

• colcon build --packages-select autoware_sample_designs succeeds with zero warnings, and exports all four modes of the AutowareSample system: Runtime (27 launch files, 232 node entries), LoggingSimulation (27 / 216), PlanningSimulation (26 / 157) and E2ESimulation (25 / 202) — 107 generated launchers in total.
• The AutowareSample AD API wiring was confirmed live: 21 nodes plus the RTC controller, with every declared connection present.
• Planning simulation reaches autonomous mode; the engage path was verified live after the /api/* remaps went in.
• pre-commit run --files on every changed file passes (prettier, yamllint, sort/prettier package.xml).

Notes for reviewers

This is design metadata and launch composition only; no node source is touched.

The branch is stacked on #1972 — its first eight commits are that PR's content, rebased. Review this one as the superset, or #1972 first if you prefer the smaller step.

One known follow-up: ControlChecker.module drops the api_operation_mode_state → collision_detector.operation_mode_state link, which was a main-break fix from when the node design pinned that port with global:. Now that autowarefoundation/autoware_universe#13312 has made it a remap_target, the link can be restored; the node currently falls back to its default and still listens on /api/operation_mode/state, so behavior is unchanged either way.

Interface changes

None at the node level. The api / adapi component split changes which component a node is instantiated under, and the /api/* names are held in place by system-level remaps.

Effects on system behavior

None intended. All four AutowareSample modes deploy, and planning simulation reaches autonomous mode.

[github-actions]

Thank you for contributing to the Autoware project!

🚧 If your pull request is in progress, switch it to draft mode.

Please ensure:

• You've checked our contribution guidelines.
• Your PR follows our pull request guidelines.
• All required CI checks pass before marking the PR ready for review.