Implementing Autoware Core #5365
Replies: 3 comments 8 replies
-
Autoware Core StepsAutoware Core Base ClassGoals for the v1:
Goals for the v2:
Porting Steps
|
Beta Was this translation helpful? Give feedback.
-
I have created the porting guideline with the following Google Doc. We can keep updating it as we do the development We can also created the spreadsheet to track the progress. |
Beta Was this translation helpful? Give feedback.
-
I'm currently working on package porting from Autoware.Universe to Autoware.Core. For example, I'm porting autoware_component_interface_specs package which contains dependencies to messages from tier4_autoware_msgs. Since we don't want to have any dependency on TIER IV repositories for Autoware.Core packages, I'm currently creating a simplified version of the package which only contains dependency to autoware_msgs (draft pr). However, I also want to keep the original package in Autoware.Universe so that the packages that currently depends on the package could still use the old API. When I made my PR, I initially thought of creating the new package in Autoware.Core as
Does anyone have any comments around naming? (maybe @xmfcx and @esteve?) |
Beta Was this translation helpful? Give feedback.
-
Proposal
As you might know, most of the Autoware packages currently exists in Autoware.Universe, which are meant for community maintained packages with varied code quality. We also have the Autoware.Core repository which are supposed to contain packages that maintained by the Autoware Foundation with stricter code quality requirements similar(or even better) to how we were doing in Autoware.Auto, but it has been sitting there without any packages for almost three years.
I think we are ready to start porting some of the packages into Autoware.Core because of the following reasons:
I know that people would have different expectations about Autoware.Core, but I would like Autoware.Core to have at least minimum sets of packages that is capable of driving in a simple ODD (such as AVP and Cargo Delivery ODD) without relying on Autoware.Universe packages within next year.
Design
I have discussed with @TakaHoribe and @youtalk, and here are the packages that I think would be a good packages to start with.
Ported Packages
Sensing
Localization
Map
Planning
Control
Porting Plan
We plan to port the above packages through two phases.
Phase 1
Contains the very minimum set of packages that makes Autoware.Core an autonomous driving software. The followings are the expected functions:
Phase 2
Contains enhance sensor fusion capabilities, recognizing dynamic objects, and supporting additional use cases like right and left turns at intersections. While this wouldn't be the absolute minimal configuration, these additions would enable a bit more complex driving scenarios like for cargo delivery use cases where route is fixed in a semi-closed environment. The followings are the expected functions added on top of Phase 1:
Here are the use cases that are not covered with the proposed packages
Some additional things that we should do for Autoware.Core
I am open to any comments and ideas.
Beta Was this translation helpful? Give feedback.
All reactions