This architecture is a proposal by Tier IV. We thought a new Autoware architecture is required to accelerate the development of Autoware.
(Please also refer this presentation shared at AWF TSC in March 2020.)
We thought now it is difficult to improve Autoware.AI capabilities because of:
- No concrete architecture designed
- A lot of technical debt
- Tight coupling between modules
- Unclear responsibility of modules
The purpose of this proposal is to:
- Define a layered architecture
- Clarify the role of each module
- Simplify the interface between modules
By defining simplified interface between modules:
- Internal processing in Autoware becomes more transparent
- Joint development of developers becomes easier due to less interdependency between modules
- User's can easily replace a module with their own software component(e.g. localization) just by "wrapping" their software to adjust to Autoware interface
Note that the initial focus of this architecture design was solely on function of driving capability, and the following features are left as future work:
- Real-time processing
- HMI
- Fail safe
- Redundant system
- State monitoring system
When we designed the architecture, we have set the use case of Autoware to be last-one-mile travel.
An example would be the following:
Description: Travelling from to grocery store in the same city
Actors: User, Vehicle with Autoware installed (Autoware)
Assumption:
The environment is assumed to be
- urban or suburban area that is less than 1 km^2.
- fine weather
- Accurate HD map for the environment is available
Basic Flow:
- User: starts a browser and access Autoware page from phone. Press "Summon", and the app sends user’s GPS location to Autoware
- Autoware: plans the route to the user’s location, and show it on the user’s phone
- User: confirms the route and press “Engage”
- Autoware: starts driving autonomously to the requested location and pulls over to the side of the road
- User: rides on to the vehicle and press "Go Home"
- Autoware: Plans the route to the user’s location
- User: confirms the route and press “Engage”
- Autoware: Drives autonomously to user's home
To achieve the above use case, we set the functional requirement of the Autoware as following:
- Autoware can plan the route to the specified goal in the specified environment.
- Autoware can drive along the planned route without violation of traffic rules.
- (Nice to have) Autoware drives smooth driving for a comfortable ride with a limited jerk and acceleration.
The above requirements are broken down into detailed requirements, which are explained in each stack page.
Since Autoware is open source and is meant to be used/developed by anyone around the world, we also set some non-functional requirements for the architecture:
- Architecture is extensible for new algorithms without changing the interface
- Architecture is extensible to adapt to new traffic rules for different countries
- The role and interface of a module must be clearly defined
Here is an overview of this architecture.
This architecture consists of 6 stacks:
The details are explained in each page.