Latest News / May ‘24 / The Autoware Challenge 2024 will start in only a few days!

Past, Present and the Future of Autoware

Past, Present and the Future of Autoware

Autoware is a household name in the autonomous driving domain. Shinpei Kato started the Autoware project at Nagoya University in 2015, and it was released by the Autoware Foundation to democratize autonomous driving technology with the vision of “collaboratively building a better world in which anyone can enjoy the fruits of autonomous driving technology.”


The first version of the Autoware project was called Autoware.AI, based on the popular ROS1 middleware suite. It was the first-ever all-in-one open-source software for autonomous driving. As a result, it drew tremendous attention from autonomous driving ecosystem stakeholders and many independent developers, resulting in 5000+ stars on Autoware.AI’s Github repository.

The Autoware project especially gained traction when Udacity and TIER IV joined forces in 2016 to start a public autonomous driving contest, followed by the start of the Autoware Foundation in 2018, which resulted in the rapid growth of the member base from across the board in the autonomous driving ecosystem.

Autoware.AI has found widespread and international adoption as it was used by more than 100 companies and runs on more than 30 vehicles in more than 20 countries. Fun fact: Some of the heavily-funded autonomous technology companies used Autoware for concept validation before developing their proprietary technology. Some users preferred to use Autoware as a whole and some as a component integration for demo purposes.

CARMA uses Autoware to provide SAE level 2 and 3 automation capability

The Autoware.AI repository contained various packages covering critical aspects of autonomous driving technologies – sensing, perception, localization, mapping, planning and actuation. However, while it was successful in attracting many developers and contributors, it wasn’t easy to further improve the Autoware.AI project’s capabilities for several reasons:

  • The lack of a concrete software architecture design leads to a lot of built-up technical debt, such as tight coupling between modules and unclear module responsibility
  • Differing coding standards for each package, with shallow test coverage
  • No clear definition of the conditions under which an Autoware-enabled autonomous vehicle could operate, nor of the uses cases or situations supported.


From the lessons learned with the Autoware.AI project, a completely different development paradigm was structured for implementing Autoware.Auto, the ROS2 version of Autoware, or Autoware 2.0 – so to speak.

Compared to ROS1, ROS2 introduced modern software engineering best practices, including LifeCycle nodes, QoS settings for topics, and the concept of containerization.

Autoware.Auto is the second distribution of Autoware that is based on ROS2. As a part of the transition to ROS2, it was decided to avoid simply porting Autoware.AI from ROS1 to ROS2. Instead, the codebase was rewritten with proper software engineering practices, including defining targeted use cases and ODDs (e.g., Autonomous Valet Parking, Cargo Delivery, etc.), a well-defined software architecture, detailed design documents and test code.

Previously, in the Autoware.AI experience, different developers modified the packages without regard to coding standards, writing test code and proper documentation. Also, to incorporate new ROS2 features, the node design needed to be revisited. Therefore, a rewrite of the codebase was required.

To design the software architecture for autonomous driving, Autoware.Auto set a goal to determine what features are needed and what suitable interfaces between each component are necessary within the stack. In addition, development was based on setting incremental goals along the way rather than targeting a moonshot goal that would take many years to complete. That is why the Autoware.Auto implementation started with a minimal set of functionality.

With the Autoware.Auto project, two primary use cases were implemented with community and partner engagements.

First demo of the world’s first fully open-source autonomous vehicle stack

Demo for the operation of autonomous vehicles in the factory environment

Developing autonomous driving software within a concrete software architecture is imperative. From that perspective, Autoware.Auto project methodology proved its efficacy. However, the project was not entirely immune to various drawbacks. Continuous improvement is the very nature of an open-source project. Develop, test, learn and iterate the whole process. Here are the key findings about Autoware.Auto project after the implementation of the Autonomous Valet Parking and Cargo Delivery ODDs:

  • The barrier to entry for the new engineers was too high: Bringing high coding and testing standards to Autoware.Auto required substantial work to merge new features into the project, making it difficult for researchers and students to contribute to the development. As a consequence, most Autoware.Auto developers originated from member companies of the Autoware Foundation instead of a wide variety of contributors, making it extremely difficult to add state-of-the-art autonomous driving features from academic and scientific research to the project.
  • Changes to the large-scale architecture became overwhelmingly cumbersome: When it was necessary to re-architect the stack, including new features or optimizing some components, there was a significant overhead involved in keeping the main branch stable while ensuring every change satisfied the continuous integration requirements.


To address the shortcomings in developing with Autoware.Auto, the Autoware Foundation decided to create a new architecture paradigm called Autoware Core/Universe.

Autoware Core/Universe constellation idea

Autoware Core/Universe paradigm can be visualized as a constellation. Autoware Core is at the core of the architecture. It carries over the original policy of Autoware.Auto to be a stable and well-tested codebase. Alongside Autoware Core is a new concept called Autoware Universe, which acts as an extension of Autoware Core with the following benefits:

  • Users can easily replace an Autoware Core component with an Autoware Universe equivalent to use more advanced features, such as a novel localization or perception algorithm
  • Code quality requirements for Autoware Universe are more relaxed to make it easier for new developers, students and researchers to contribute, but still more strict than Autoware.AI
  • Any advanced features added to Autoware Universe that are useful for the broader Autoware community will be reviewed and considered for potential inclusion in the main Autoware Core codebase.

This way, the primary requirement of having a stable and safe autonomous driving system can be achieved while simultaneously enabling access to state-of-the-art features created by third-party contributors.

Complete end-to-end autonomous driving frameworkSupports all current Autoware ODDsProvides the definitions and functionality for which other packages can extendStrict code and quality controlHeavily managed by the AWFStable base implementationAdditional packages built on top of CoreExtends Autoware functionality beyond Autoware ODDsCompletely dependent on Core functionality and message definitionsRelaxed code and quality controlCommunity managedEnables quick experimentation and prototype testing

The new Autoware Core/Universe paradigm was initially proposed by TIER IV in 2020 at the Autoware Technical Steering Committee meeting.

According to this proposal, TIER IV would contribute to the base development platform for the Autoware Universe. The main idea behind this was to introduce a federated software development model into the Autoware Project. After a lengthy technical due diligence conducted by member companies, Autoware software architects and TIER IV, the Autoware Universe structure was formed and built.

Autoware Universe architecture was decided to be the architecture applied to the planned implementation of the Bus ODD in 2022.

The Bus ODD development efforts are continuing on two fronts:

  1. A premium member, ITRI from Taiwan, is working towards a public road bus service demonstration
  2. A premium member, Leo Drive from Turkey, is working towards a university campus service demonstration in partnership with Anadolu Isuzu.

Once the on-vehicle testing is completed in both efforts, the codebase will be reviewed, refactored and ported into the Autoware Core.

Autoware Universe development plan in conjunction with the Bus ODD. Also, migration plans from Universe to Core

If you want to find out more details about how the Core/Universe structure differs from Autoware.AI and Autoware.Auto, please refer to the Autoware documentation.


The decision to transition from Autoware.AI and Autoware.Auto paradigm to the Autoware Core/Universe paradigm required some housekeeping tasks on the Autoware projects on Github, messaging on the Autoware website and, in general, Autoware community policies.

Some of the critical considerations included:

  • Many Autoware contributors continued to see Aıtoware.AI as the main codebase and were unaware of Autoware Core/Universe (or Autoware.Auto, for that matter)
  • Autoware.AI will reach EOL by the end of 2022
  • It was imperative to enable all users to transition to Autoware Core/Universe smoothly
  • Autoware.AI and Autoware Core/Universe repositories were maintained in different GitHub organizations
  • Having multiple repositories and organizations is confusing for the developer community
  • Having multiple platforms makes announcements to the community more complex

To alleviate the shortcomings of having multiple repositories and organizations, some swift actions were planned:

  1. Improve the brand recognition of Autoware Core/Universe:
  2. Improving the Autoware Foundation website
  3. Informing and educating the Autoware developer community via blogs and events
  4. Working on demonstrations to gain attraction
  5. Improving documentation
  6. Merging the GitHub organizations and meta-repositories
  7. Phase 1: Put links to Autoware Core/Universe in the README of Autoware-AI and also post information about this migration plan (COMPLETED)
  8. Phase 2: Transfering all core repositories from Autoware.AI to the Autoware Foundation to unify the organization (COMPLETED)
  9. Phase 3: Archiving Autoware.AI repositories after reaching EOL

You can read it here if you want to learn more about the process.

Phase 2 – Merging the organizations

Phase 3 – Archiving Autoware.AI repositories after EOL (end of 2022)


  • Autoware Discord – where the Autoware community meets
  • ROS Discourse – major announcements are made in the Autoware category
  • Autoware Wiki – provides a dedicated area for each Working Group
  • GitHub Projects – track the current projects within the Autoware Foundation
  • GitHub Discussions – meeting minutes, feature requests, design discussions, announcements, show and tell and Q&A