Autoware Universe ➡️ `autoware_universe_awf` ➕ `autoware_universe_community`

[xmfcx]

flowchart TB
    subgraph core["🏗️ Core Autoware"]
        direction TB
        AC(["autoware_core"])
        AM(["autoware_msgs"])
        AIM(["autoware_internal_msgs"])
        AAM(["autoware_adapi_msgs"])
        AU(["autoware_utils"])
    end

    subgraph awf["🟠 AWF Universe"]
        direction TB
        AUA(["autoware_universe_awf"])
        T4M(["tier4_autoware_msgs"])
        LLH(["llh_converter"])
        NEB(["nebula"])
        AT(["autoware_tools"])
    end

    subgraph community["🟢 Community Universe"]
        direction TB
        AUC(["autoware_universe_community"])

        subgraph pkgs["📦 Community Packages"]
            direction LR
            CP1(["autoware_livox_tag_filter"])
            CP2(["community_pkg_2"])
            CP3(["community_pkg_n..."])
        end
    end

    subgraph index_infra["🔍 Autoware Universe Index"]
        direction TB

        subgraph index_repos["Index Repositories"]
            AIR(["autoware_index_repositories<br><i>distribution YAML</i>"])
            AI(["autoware_index<br><i>website</i>"])
        end

        subgraph ci["⚙️ CI / GitHub Actions"]
            direction LR
            CIACT(["autoware-index-github-actions"])
            BV["Build Validation"]
            COMPAT["Compatibility Checks"]
            META["Metadata Generation"]
        end

        subgraph metadata["📊 Index Metadata"]
            direction LR
            VER["Latest Working Version"]
            TESTS["Test Links"]
            TAGS["Package Tags"]
            DEPS["Dependencies"]
            DISTROS["Supported ROS 2 Distros"]
        end
    end

    subgraph user_tools["🧰 User Tools"]
        direction LR
        RM(["Repo-Maker Tool"])
        REPOS(["universe-community.repos"])
    end

    subgraph tags["🏷️ Package Tag Categories"]
        direction TB
        subgraph auto["Autonomy Pipeline"]
            direction LR
            T_SENS["sensing"]
            T_PERC["perception"]
            T_MAP["map"]
            T_LOC["localization"]
            T_PLAN["planning"]
            T_CTRL["control"]
            T_VEH["vehicle"]
        end
        subgraph infra["Infrastructure & Support"]
            direction LR
            T_LIB["common-library"]
            T_API["api"]
            T_INT["interface"]
            T_LAUNCH["launcher"]
            T_DRV["driver"]
        end
        subgraph devops["Development & Operations"]
            direction LR
            T_TEST["testing"]
            T_VIS["visualization"]
            T_TOOL["tool"]
            T_SIM["simulator"]
        end
    end

    %% Core relationships
    AM --> AC
    AIM --> AC
    AAM --> AC
    AU --> AC
    AC -- depends on --> AUA
    T4M --> AUA
    LLH --> AUA
    NEB --> AUA

    %% AWF to community
    AUA --> AUC
    AUA --> AT
    AC --> AUC

    %% Community packages
    AUC --> CP1 & CP2 & CP3
    CP1 -. "✅" .-> CP2

    %% CI pipeline
    CIACT --> BV & COMPAT & META
    CP1 & CP2 & CP3 -. "tested by" .-> CIACT
    META -. "generates" .-> VER & TESTS & TAGS & DEPS & DISTROS

    %% Index scraping
    VER & TESTS & TAGS & DEPS & DISTROS -. "scraped by" .-> AI
    AIR -. "registry for" .-> AUC
    AI -. "displays" .-> AIR

    %% User tools
    AI -- "browse & select" --> RM
    RM -- "generates" --> REPOS

    %% Tags feed into index
    TAGS -. "categorized by" .-> tags

    %% Styles
    AC:::Rose
    AM:::Rose
    AIM:::Rose
    AAM:::Rose
    AU:::Rose

    AUA:::Peach
    T4M:::Peach
    LLH:::Peach
    NEB:::Peach
    AT:::Peach

    AUC:::Aqua
    CP1:::Aqua
    CP2:::Aqua
    CP3:::Aqua

    CIACT:::Violet
    BV:::Violet
    COMPAT:::Violet
    META:::Violet

    AI:::Blue
    AIR:::Blue
    VER:::Blue
    TESTS:::Blue
    TAGS:::Blue
    DEPS:::Blue
    DISTROS:::Blue

    RM:::Amber
    REPOS:::Amber

    classDef Rose stroke-width:1px, stroke-dasharray:none, stroke:#FF5978, fill:#FFDFE5, color:#8E2236
    classDef Peach stroke-width:1px, stroke-dasharray:none, stroke:#FBB35A, fill:#FFEFDB, color:#8F632D
    classDef Aqua stroke-width:1px, stroke-dasharray:none, stroke:#46EDC8, fill:#DEFFF8, color:#378E7A
    classDef Violet stroke-width:1px, stroke-dasharray:none, stroke:#A855F7, fill:#F3E8FF, color:#6B21A8
    classDef Blue stroke-width:1px, stroke-dasharray:none, stroke:#3B82F6, fill:#DBEAFE, color:#1E3A8A
    classDef Amber stroke-width:1px, stroke-dasharray:none, stroke:#F59E0B, fill:#FEF3C7, color:#92400E

    style core fill:#FFF5F5,stroke:#FF5978,stroke-width:2px,rx:12
    style awf fill:#FFF8F0,stroke:#FBB35A,stroke-width:2px,rx:12
    style community fill:#F0FFF8,stroke:#46EDC8,stroke-width:2px,rx:12
    style pkgs fill:#E6FFF5,stroke:#46EDC8,stroke-width:1px,stroke-dasharray:5 5,rx:8
    style index_infra fill:#EFF6FF,stroke:#3B82F6,stroke-width:2px,rx:12
    style index_repos fill:#DBEAFE,stroke:#3B82F6,stroke-width:1px,stroke-dasharray:5 5,rx:8
    style ci fill:#F3E8FF,stroke:#A855F7,stroke-width:1px,stroke-dasharray:5 5,rx:8
    style metadata fill:#DBEAFE,stroke:#3B82F6,stroke-width:1px,stroke-dasharray:5 5,rx:8
    style user_tools fill:#FFFBEB,stroke:#F59E0B,stroke-width:2px,rx:12
    style tags fill:#F9FAFB,stroke:#9CA3AF,stroke-width:2px,rx:12
    style auto fill:#F0FFF4,stroke:#10B981,stroke-width:1px,rx:8
    style infra fill:#FFF7ED,stroke:#F97316,stroke-width:1px,rx:8
    style devops fill:#EEF2FF,stroke:#6366F1,stroke-width:1px,rx:8

Loading

Autoware Universe ➡️ autoware_universe_awf ➕ autoware_universe_community

Current issues

• We have a repo called autoware_universe but there are other "Universe" packages outside awf github org.
• Not all packages in autoware_universe are needed by many configurations. Certain use cases need certain packages from it.
  • Yet users pull and build all of them even if they don't need them.
• Too many leaf packages in autoware_universe.
• We don't have visibility (and tests, build checks) for packages outside awf github org.
• Previous discussion: Pipeline to support individual packages as part of Autoware ecosystem #6621

Proposed solution

• Introducing Autoware Universe Community Packages!
• Rename autoware_universe to autoware_universe_awf.
• Allow placing new Autoware Universe Community Packages into autoware_universe_community.

Autoware Universe Index

• We'll have an index similar to https://index.ros.org/?search_packages=true
• We provide a GitHub actions workflow suite for these repositories.
  • Users register their repositories to the Autoware Universe Index.
  • This suite periodically runs and tests these repositories against latest Autoware release and creates metadata.
  • This metadata is periodically scraped by the Autoware Universe Index.
• Index columns
  • Latest working autoware version
  • Latest test links
  • Package tags
  • Dependencies
  • Supported ROS 2 distributions
• We also create a Autoware Universe Index repo-maker tool in the site?
  • Users check multiple Autoware Universe Index repositories, download universe-community.repos file.

Autoware Universe Community Package Tags

Nothing here is mutually exclusive.

Autonomy pipeline

• sensing
• perception
• map
• localization
• planning
• control
• vehicle

Infrastructure & support

• common-library (middleware, shared libs, utils, math, helpers)
• api (external integration, RPC, REST, DDS bridges, etc.)
• interface (message definitions, schemas, contracts)
• launcher (launch files, configs, parameters)
• driver (hardware, vendor SDKs, sensors, actuators)

Development & operations

• testing
• visualization
• tool
• simulator

Definition of done

• Extract a package from autoware_universe out as the first community package.
  • sensing/livox/autoware_livox_tag_filter is the package. It is a small C++ package with minimal dependencies. Good fit.
  • Experimenting here: https://github.com/autowarefoundation/autoware_livox_tag_filter
• Add CI workflows to validate build and autoware compatibility
  • Simplify the docker images Simplify the docker images and workflows #6852
• Add CI workflows to generate metadata for the autoware_index to scrap.
• Put these workflows to https://github.com/autowarefoundation/autoware-index-github-actions and refer from there.
• Create the autoware_index repository. (Needs its own issue)
  • Probably need 2 repositories:
    1. autoware_index_repositories similar to: https://github.com/ros/rosdistro/blob/master/humble/distribution.yaml
    2. autoware_index which will host the website similar to: https://github.com/ros-infrastructure/rosindex

Timeline

gantt
    title Autoware Universe Community – Project Timeline
    dateFormat YYYY-MM-DD
    axisFormat %b %d

    section Phase 1: Foundation
        Rename autoware_universe → autoware_universe_awf          :a1, 2026-03-01, 7d
        Extract autoware_livox_tag_filter as first community pkg  :a2, after a1, 14d
        Draft CI workflow requirements                            :a3, after a2, 10d

    section Phase 2: CI & Tooling
        Build CI – build validation & compatibility checks        :b1, 2026-04-01, 14d
        Build CI – metadata generation for index scraping         :b2, after b1, 11d
        Package workflows into autoware-index-github-actions      :b3, after b2, 5d

    section Phase 3: Index Infrastructure
        Create autoware_index_repositories repo                   :c1, 2026-05-01, 14d
        Create autoware_index repo & deploy website               :c2, after c1, 17d

    section Phase 4: Community Launch
        Beta testing with early community packages                :d1, 2026-06-01, 14d
        Build repo-maker tool                                     :d2, after d1, 7d
        Public announcement & open registration                   :d3, after d2, 9d

    section Phase 5: Stabilization
        Onboard additional community packages                     :e1, 2026-07-01, 31d
        Refine testing cadence & iterate on index                 :e2, 2026-07-01, 31d

Loading

timeline
    title Autoware Universe Community – Milestone Timeline

    section March 2026 – Foundation
        Week 1 : Rename autoware_universe to autoware_universe_awf
        Week 2–3 : Extract autoware_livox_tag_filter as first community package
                  : Finalize repo structure and conventions
        Week 4 : Draft CI workflow requirements and begin implementation

    section April 2026 – CI & Tooling
        Week 1–2 : Build CI workflows for build validation
                  : Autoware compatibility checks
        Week 3–4 : CI workflows for metadata generation
                  : Package into autoware-index-github-actions
                  : Document usage for contributors

    section May 2026 – Index Infrastructure
        Week 1–2 : Create autoware_index_repositories repo
                  : Define registration process and distribution YAML
        Week 3–4 : Create autoware_index website
                  : Index columns: version, tests, tags, deps, distros

    section June 2026 – Community Launch
        Week 1–2 : Beta testing with early community packages
                  : Iterate on CI and index from feedback
        Week 3 : Build repo-maker tool for universe-community.repos
        Week 4 : Public announcement and open registration

    section July 2026+ – Stabilization & Growth
        Ongoing : Onboard additional community packages
                : Refine periodic testing and scraping cadence
                : Gather feedback and iterate on index UI and tags

Loading

Phase 1: Foundation (March 2026)

Dates	Milestone	Details
Mar 1–7	Rename repository	Rename autoware_universe → autoware_universe_awf
Mar 8–21	First community package	Extract autoware_livox_tag_filter as the first community package; finalize repo structure and conventions
Mar 22–31	CI planning	Draft CI workflow requirements and begin implementation

Phase 2: CI & Tooling (April 2026)

Dates	Milestone	Details
Apr 1–14	Build validation CI	Build and test CI workflows for build validation and Autoware compatibility checks
Apr 15–25	Metadata CI	Build CI workflows for metadata generation (for index scraping)
Apr 26–30	Package & document	Package workflows into autoware-index-github-actions; document usage for community contributors

Phase 3: Index Infrastructure (May 2026)

Dates	Milestone	Details
May 1–14	Index repositories	Create autoware_index_repositories repo (distribution YAML, registration process)
May 15–31	Index website	Create autoware_index repo and deploy initial website with index columns (working version, test links, tags, dependencies, supported distros)

Phase 4: Community Launch (June 2026)

Dates	Milestone	Details
Jun 1–14	Beta testing	Beta testing with early community packages; iterate on CI and index based on feedback
Jun 15–21	Repo-maker tool	Build the repo-maker tool (users select packages → download universe-community.repos)
Jun 22–30	Public launch	Public announcement and open registration for community packages

Phase 5: Stabilization & Growth (July 2026+)

Dates	Milestone	Details
Jul 1+	Onboarding	Onboard additional community packages
Jul 1+	Refinement	Refine periodic testing and metadata scraping cadence
Jul 1+	Iteration	Gather feedback and iterate on the index UI and tagging system

[amadeuszsz]

@xmfcx

Thank for detailed explanation.

I'm only a bit confused about autoware_core role here as there were some goals behind migrations of packages from autoware_universe. What if we could consider:

• autoware_core as autoware_universe_awf
• autoware_universe as autoware_universe_community
  ?

Probably I'm missing something, so please help me understand why we couldn't achieve same goals with 2 "main" repositories instead of 3.

[xmfcx]

@amadeuszsz Thanks for the question! A key clarification: autoware_universe_community is not a repository. It's a conceptual folder representing independently maintained packages registered in the Autoware Index.

The end goal is to progressively hollow out autoware_universe_awf:

• Critical, tightly coupled packages migrate into autoware_core
• Leaf packages (loosely coupled, independently useful) move out into the Autoware Index as community packages, each in their own repo

autoware_universe / autoware_universe_awf is essentially a transitional repository that shrinks over time as packages graduate to one of those two destinations.

So to directly answer your question: yes, the target state is effectively two "homes" (core + index), but we need the transition repo to avoid a big-bang migration that would break everything at once.

Autoware Universe was always meant to be community driven. But as you may have witnessed over past few years, it wasn't quite like that. Like we have to decide and discuss with the TIER IV and AWF before adding in more and more packages to avoid inflating the repository.

But with Autoware Index and Autoware Universe Community, the initial Core / Universe concept will achieve its goal.

[paulsohn]

Overall I agree with the overall changes, especially the idea of Autoware index(buildfarm).
Considering how long does the universe PR CI check run, and how many packages and codeowners are affected for one convention change (linter / formatter update, jazzy support etc) I like to see the universe split.

---

While this issue is mostly for universe, as you mentioned launcher, I want to express an opinion for how autoware_launch would be like in the future. To put it simple, I think it is a better choice for both TIER IV and AWF that TIER IV discontinues direct (PR-level) contribution on the community launcher.
Alternatively, TIER IV can release the company specialized version of launcher to the community (which copyright goes to the company), and the 'community launcher' could be something that generalizes TIER IV released (and verified) version of launcher.

Currently, TIER IV is maintaining an AWF launcher fork: https://github.com/tier4/autoware_launch
and we perform our daily test on synced launcher on AWF upstream plus TIER IV specialized differences. Thus, unlike core or universe, the launcher we test is not identical to the latest AWF version. This layered structure causes several disadvantages for both parties:

• For AWF: it is hard to maintain its 'TIER IV-neutral' state because there are too many PRs with TIER IV specialized requirements.
• For TIER IV: as a TIER IV engineer, we really suffer from resolving merge conflicts from upstream, or silent discrepancy between upstream updates and TIER IV diff. Some might say we can merge cleanly for many cases, but this shouldn't be how we develop a safety-critical system.
  • Also due to the deep layered structure (AWF autoware_launch -> TIER IV common autoware_launch -> TIER IV reference design autoware_launch) there are several conflicts of interest; we had some PRs that "one of our reference design needs this feature, but we don't want it in common launcher or other models. But since the PR is opened against AWF, as for AWF side we don't have any good reason to reject this."
  • Needless to say that theoretically a third-party contributor outside TIER IV can submit a PR that TIER IV does not want to sync.

Unlike individual ROS 2 nodes and platforms which represents a feature and can be 'unbiased' in some sense, the launcher represents the entire system, the vehicle, that reflects a certain usecase, the stakeholder's intent and requirements, business logics, which can never be unbiased nor neutral.
So instead of maintaining two versions of launchers and leave the entire decision whether it belongs to AWF or not to the individual TIER IV contributors, we would like to see them focusing on the company requirements, release more reliable version of launchers, and then AWF community can accept the released TIER IV launcher as a model case (the actual policy for AWF is beyond the scope of our discussion), adapt it to be applicable to more neutral usecase. We TIER IV try our best to be as neutral as possible, just as in 'best effort' QoS.

DISCLAIMER: all of my opinions in this reply (and likely throughout this thread) is my personal opinion as a TIER IV engineer. I DO NOT REPRESENT any official opinions nor decisions of TIER IV.

[sasakisasaki]

@paulsohn Thank you very much for sharing your idea. As my quick idea for autoware_launch, perhaps having two autoware_launchs as follows might be one of the choices? Sorry if this my comment makes you confused!

Proposal for autoware_launch Package

Current Situation

• The GitHub repository autowarefoundation/autoware_launch provides the base launch files which can be used for tutorials such as planning simulation, logging simulation, and so on.
• The GitHub repository tier4/autoware_launch is maintained for internal TIER IV usage to adapt Autoware to specific vehicle platforms.
• Thus, we have two autoware_launch packages: tutorial level and integration level.

Proposal

• Reposition the current autowarefoundation/autoware_launch as a sample launch package, analogous to sample_sensor_kit. For instance, it could be distributed under the package name sample_autoware_launch.
• Use tier4/autoware_launch for real vehicle integration example which is well-tested for integration beyond the sample scope.
• Because autoware_launch is determined by the hardware configuration, it is better to have a unique autoware_launch for each hardware platform. Therefore, on the Autoware Foundation side, a sample_autoware_launch should exist for sample_vehicle, and each organization should have a vehicle-specific autoware_launch for the vehicles it owns. These separate autoware_launch packages should ideally coexist independently without affecting one another.

[paulsohn]

@sasakisasaki As we discussed in private communication, I agree with your idea to have two launchers: one toy-level AWF official which is minimally maintained, and one real vehicle-oriented one showcased and verified from TIER IV.

We can further discuss on the minor touch. For the proposed sample_autoware_launch, I think it should mostly depend on autoware core, and if necessary a minimal bit of the suggested autoware_universe_awf if any.
Currently we already have autoware_core_launch, so how about just using it with minimal updates, instead of creating a new one from scratch?

---

I started to feel like this discussion is worthy to have a separate thread.
Before that, let me elaborate on why a real-vehicle launcher cannot be maintained by AWF itself, as it is still partially relevant to the OP:

• If the universe splitting plan from OP is accomplished, then many universe nodes and features would be spun out from 'AWF official' scope. Then, the 'AWF official launcher' itself will be pointless, as it will get new restrictions: to use only the minimal AWF-external packages, or sync all AWF-external, frequently updated packages from AWF side. This is far from acheivable.
  • Think about the Open Robotics. Are they shipping the 'official universal ROS launcher for any robots'? No. Analogously, if Autoware aims to be an ecosystem, it should allow multiple usecases, not a single usecase trying (pretending) to be universal but actually tightly coupled with TIER IV interest and convention. Automotive driving system is indeed a narrower category of robots but still there are lots of variants.
  • AWF Autoware will then (1) officially support autoware_core_launch and (2) showcase one TIER IV autoware_launch (should be renamed into tier4_autoware_launch or whatever) as the integration of latest autoware universe.
  • Showcasing launcher from other companies / individuals should be also welcomed from the AWF stance.
• Universal autoware_launch is not fully testable; no individual party, even AWF itself, should be imposed of the responsibility to provide real vehicle and testing environment, to take a risk for testing a system that the tester's intention is not fully reflected. Besides, we are building a safety critical system.
• Consequently, TIER IV should be a primary partener of AWF to own their configuration and take the entire responsibility to guarantee sanity of the system we showcase. As this is showcased, TIER IV should try to maintain their launcher to be universal, but it should be best-effort - we can't compromise the system consistency, reliability and safetiness because of the 'universality' which can't be even well-defined.

[mitsudome-r]

@paulsohn

I started to feel like this discussion is worthy to have a separate thread.

This is issue is not related to launch system so I agree with making a separate discussion thread.

[mitsudome-r]

@sasakisasaki Maybe you can just copy your comment and post as a new discussion topic.

[sasakisasaki]

@mitsudome-r Thank you! I created as the separated discussion 👍