Migrate `tier4_xxx_launcher` from autoware_universe into autoware_launch

[paulsohn]

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

I created a PR first before filing an issue.

• chore: remove tier4 launchers from universe (migrate to autoware_launch) autoware_universe#12001
• chore: import tier4 launchers from universe autoware_launch#1740

The goal is simple: blindly move all tier4_xxx_launchers from autoware_universe launch/ into autoware_launch repository tier4_universe_launch/ directory.

This is motivated from #6721 (comment) , to centralize all launch files into one place. While autoware_launch_v2 and autoware system designer take some time to apply, I would like to suggest what we can and should do right now.

⚠️ non-goals for this task

• ❌ Refactor any content of the launch files or packages, including renaming. (The only changes will be the package location.)
• ❌ Make tier4_xxx_launch packages private or remove them. (tier4_xxx_launch will be still available, but in autoware_launch repo.)
• ❌ Migrate all tier4-prefixed packages such as tier4_dummy_object_rviz_plugin (only tier4_xxx_launch with launch/ will be affected)
• ❌ Apply all suggestions from @xmfcx in New launch package: autoware_launch_v2 #6721 (comment) , for example...
  • ❌ Migrate every launch files from autoware_universe to autoware_launch. (Thin wrapper launchers will not be migrated.)
  • ❌ Put all migrated launch files into autoware_launch package. (They will be in autoware_launch repository, but in different packages.)

I am not saying that these non-goals shouldn't be considered; it just can be done AFTER the migration.

TIER IV internal docs

Purpose

As a TIER IV engineer and an unintentional Autoware enthusiast, I recently faced a very frustrating issue that autowarefoundation/autoware_universe#10541 restricted one of the model names that my team wants to use. I suggested a partial revert as in autowarefoundation/autoware_universe#12005 and waiting for review.

Pondering on the fundamental solution of this issue, I concluded that tier4_xxx_launch should not be in autoware_universe, but in autoware_launch because:

1. From AWF perspective,

• it obviously depends on TIER IV system topology, business logic and usecase. While TIER IV can provide an example case as a set of launchers, AWF should be as unbiased as possible and allow users an option to customize or dismiss the example, to support all Autoware users not limited to TIER IV.
• Concerns for nodes (functionality) and launchers (how to use the functionality; system topology, input verification and business logic) are not properly separated for now.

2. From TIER IV perspective,

• We are using AWF core and universe, while for autoware_launch we have our own, modified version.
• Even TIER IV ourselves fail to launch Autoware because of the inflexible TIER IV launcher rules. To circumvent this, we have to fork another autoware_universe to fix only launchers (because of the project visibility scope) and sync with the upstream which takes more cost than using common universe and just maintaining autoware_launch.
• We need our business logic totally under our control, and the appropriate location is autoware_launch. Once tier4_xxx_launchers are migrated into AWF autoware_launch, we can pull the changes into ours and modify it to meet our own business requirements.

I am confident that migrating tier4 launchers is beneficial for both AWF and TIER IV.

Possible approaches

As we recently done on autowarefoundation/autoware_tools#329 , we can create a PR preserving history. Additionally, we can rewrite the commit message so that (#NN) can be properly replaced as (autowarefoundation/autoware_universe#NN), and merge commit is plausible.

PRs are ready, except for DCO.

• chore: remove tier4 launchers from universe (migrate to autoware_launch) autoware_universe#12001 - DCO check seems not working correctly, but I expected either success or fail. I can't see the DCO check details, so I need help resolving this.
• chore: import tier4 launchers from universe autoware_launch#1740

In case tier4 launchers get additional updates in the meantime, I've provided a reproducible way to generate the latest migration PR branch from your local.

Since this is a simple and blind migration, we won't have a downtime, and the expected work time is less than an hour (being maximally pessimistic; I actually expect < 10min).
NO PR FREEZE PERIOD other than that is required.
Still, it might be beneficial to announce to everyone for about a week beforehand.

For open PR support, first list all PRs including launch/ changes:

$ gh pr list --repo autowarefoundation/autoware_universe --state open --json number,title,files \
  --jq '[.[] | select(any(.files[]; .path | startswith("launch/")))] | unique_by(.number) | .[] | {number, title}'

Say, the last autoware_universe commit hash that contains tier4_xxx_launch files was a1b2c3 (In the current PR, it is 02cae8) and the first autoware_launch commit hash that contains tier4_xxx_launch files was d4e5f6. We can guide each PR owner to:

1. sync their PR branch with a1b2c3.
2. checkout autoware_launch at d4e5f6, cut the launch directory from autoware_universe and paste into autoware_launch.
3. Create another PR for autoware_launch.

Definition of done

autowarefoundation/autoware_universe#12001 (or an equivalent one) and autowarefoundation/autoware_launch#1740 (or an equivalent one) are both merged without loss of launch file updates in the meantime, and simulator for the new version builds and works as before. All open PRs with tier4_xxx_launcher changes are properly guided or announced to open another PR for autoware_launch.

[paulsohn]

I got an internal feedback from @technolojin that some functionalities (not TIER IV business logic) requires multiple nodes from both core and universe, and his team wants to keep multi-node functional launchers in universe. I think this 'multi-node functional launchers' can be regarded as the same layer of thin wrapper launchers.

So we have two conflicting directions after migration:

• move multi-node functional launchers (if there was one included in tier4_xxx_launch) back to universe (suggested by @technolojin )
• migrate all remaining launcher files including thin wrappers into autoware_launch (suggested by @xmfcx )

The post-migration direction is worthy to be discussed, however I want to declare this as beyond the scope of this migration task.

[mitsudome-r]

Regarding migration, I would like to at least rename the package name from tier4_xxx_launch to just autoware_xxx_launch.

[paulsohn]

@mitsudome-r
I am considering renaming is beyond this task scope, and can be done after blind migration.
I also think tier4_xxx_launch is an appropriate name because it potentially contain actual TIER IV business logic. If we want to rename into autoware_xxx_launch, then we need more discussion to clarify which is TIER IV dependent and which is not.

[mitsudome-r]

I also think tier4_xxx_launch is an appropriate name because it potentially contain actual TIER IV business logic.

Packages under autoware_foundation/autoware_launch shouldn't involve TIER IV's business logic. It should be a reference to all the users in general. TIER IV should create their own fork of the repo and have their logic maintained in the fork.

[paulsohn]

Packages under autoware_foundation/autoware_launch shouldn't involve TIER IV's business logic.

@mitsudome-r Same for autoware_foundation/autoware_universe. But in reality, it does involve.

• feat(tier4_perception_launch): added bevfusion to the launchers autoware_universe#10541
• https://star4.slack.com/archives/CRUE57C30/p1769738010081309?thread_ts=1769140996.406339&cid=CRUE57C30

The boundary is currently unclear that which is reference and which is TIER IV's business logic, so people accidentally add TIER IV's business logic into universe which end users can't modify easily. That's what I meant for 'potentially'.

So yes, I totally agree that TIER IV's business logic should be confined to their own fork, but keeping launchers in autoware_launch at least give an option to override if TIER IV specific configuration is accidentally added to the launcher and end users are not happy with it. Of course, that accidental PR should be reconsidered or reverted as well, but at this moment we need a clear separation of concern.

We can just admit at this moment that tier4_xxx_launch might contain TIER IV's business logic (as the current status, not should-be), and then discuss which configurations are appropriate for universal reference and which are not. After that we will eventually get something we can call autoware_xxx_launch. Right now is not a good timing for renaming.

[xmfcx]

Let's move the entire universe launch folder from autoware_universe to autoware_launch first.
That folder is not a light wrapper.
Then we can modify its name.

[paulsohn]

The above command to find relevant PRs was incomplete; I should've realized that 5 or 6 was too few. Here is the improved version. On 2026/02/04 01:30 UTC, we have 12 non-stale PRs related to launchers we are migrating:

$ gh pr list --repo autowarefoundation/autoware_universe --state open --limit 3000 --json number,title,files,labels \
  --jq '[.[] | select(any(.files[]; .path | startswith("launch/"))) | select(all(.labels[]; .name != "status:stale"))] | unique_by(.number) | .[] | {number, title}'
{"number":11574,"title":"feat(lidar_marker_localizer): extend lidar-marker localization to enhance flexibility and debugging capabilities"}
{"number":11701,"title":"feat(lidar_marker_localizer): road surface lidar marker extension"}
{"number":11709,"title":"fix(lidar_marker_localizer): unintended implementation fixes"}
{"number":11758,"title":"feat(tier4_perception_launch): add cuda_ground_segmentation_launch option"}
{"number":11768,"title":"feat(feature_environment_recognizer)!: add feature environment recognizer based on polygon area of LL2"}
{"number":11810,"title":"feat(fault_injection): modify the mechanism for changing Diagnostics"}
{"number":11831,"title":"feat(tier4_autoware_api_launch): remove tier4 api adapter"}
{"number":11905,"title":"feat!: remove ROS 2 Galactic codes"}
{"number":11970,"title":"fix(synchronized_grid_map_fusion): enable synchronized_grid_map_fusion as occupancy_grid_map_method option"}
{"number":11999,"title":"feat(lidar_marker_localizer): add pcd input validator to lidar marker localizer"}
# {"number":12001,"title":"feat: remove tier4 launchers from universe (migrate to autoware_launch)"}
{"number":12003,"title":"feat(lidar_marker_localizer): average intensity guard on lidar marker localizer"}
{"number":12004,"title":"feat(steer_offset_estimator): implement calibration logic"}

12 is still doable though.

There are also 9 stale PRs:

{"number":6241,"title":"feat(map): add differential lanelet loading"}
{"number":6393,"title":"feat(behavior_path_planner): revise behavior planner to work with dynamic lanelets"}
{"number":8711,"title":"refactor(yabloc)!: prefix package and namespace with autoware"}
{"number":10008,"title":"refactor: remove CUDA-dependent packages"}
{"number":10751,"title":"feat(simulator_launch): add an option to disable to launch occupancy grid map"}
{"number":11292,"title":"feat(waypoint_maker, scenario_gate): introduce Waypoint Following scenario with Scenario Gate integration"}
{"number":11449,"title":"feat(dummy_perception_pub): apply agnocast"}
{"number":11450,"title":"feat(surround_obstacle_checker): apply agnocast"}
{"number":11451,"title":"feat(aeb): apply agnocast"}

[xmfcx]

• The announcement post is made: `autoware_universe/launch` folder is moved under `autoware_launch` #6780

[paulsohn]

One addition: I must update CODEOWNERS.

• https://github.com/autowarefoundation/autoware_universe/blob/main/.github/CODEOWNERS#L50-L59 will be removed (for obvious reason).
• Equivalent lines will be added in autoware_launch repository, but with tier4_universe_launch/ directory.