Implementing Autoware Core

[mitsudome-r]

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:

• We have more demands about having a better code quality (relevant discussions: 1, 2, 3 ).
• We have finished porting autoware_auto_msgs to autoware_msgs, which are meant to be Autoware.Core interface
• We have finished Bus ODD last year, and the core packages for autonomous driving capabilities should have enough features to be ported to Autoware.Core

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

• gnss_driver: Out of scope. It's okay to use what is available through apt.
• lidar_driver: Out of scope. It's okay to use what is available through apt.
• pointcloud_preprocessor: Point cloud processing package. Although there are multiple filters, we start with few selected modules. It might be easier to port if we separate the packages by making them into plugins.
• crop_box_filter: A filter that removes point clouds in specific areas. It removes the point clouds that hit the vehicle itself.

Localization

• gnss_poser: Outputs position in the map coordinate system from GNSS output.
• ekf_localizer: Smooths and estimates the localization output using a vehicle motion model. If there are multiple inputs, it integrates them.

Map

• map_projection_loader: Reads a YAML file and outputs the map coordinate system.
• map_loader: Reads a lanelet2 file and outputs a lanelet map in a ROS message.

Planning

• mission_planner: Calculates the route from the self-position to the goal. Recently, it has become complex due to various APIs, route changes, and MRM support, so simplification and function separation are necessary.
• path_loader: Retrieves the path on the route from the centerline (or pre-registered route) from lanelets. In Autoware.Universe, the behavior_path_planner plays the same role, but it’s too complex to port, so we'll create a simplified version.
• behavior_velocity_planner: A package that manages plugins that control vehicle speed at the behavior level.
• behavior_velocity_stopline_module: A plugin for behavior velocity that temporarily stops at stop lines.
• motion_velocity_planner: A package that manages plugins that control vehicle speed at the motion level.
• motion_velocity_planner_obstacle_stop_module: A plugin for motion velocity that stops in front of obstacles. In Universe, obstacle_stop_planner or obstacle_cruise_planner play the same role. These should be pluginized and integrated.
• motion_velocity_smoother: A module that plans the final vehicle speed. Since there are several algorithms, we’ll either port or create the simplest one.

Control

• pure_pursuit: Calculates the steering angle and acceleration to follow the target trajectory. In Universe, there is a pure_pursuit loaded in trajectory_follower, but it’s become quite complex, so we’ll simplify it and include it in the core.

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:

• Localization using GNSS.
• Generating trajectory from a single lane in Lanelet2 Map (e.g., maps created from manual drive).
• Driving at a constant speed along the centerline of a mapped route to the goal.
• Stopping at stop lines
• Stopping in front of obstacles

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:

• Right and left turns at intersections and merging in low-speed areas using detection_area
• Improved localization accuracy through fusion with the IMU.
• Improved object recognition with euclidean_cluster to enable the recognition of dynamic objects.

Here are the use cases that are not covered with the proposed packages

• Localization in areas where GNSS is unavailable (e.g., urban environments).
• Automatic trajectory generation based on vehicle kinematics.
• Use cases such as lane changes, avoidance, entering intersections or pedestrian crossings.
• Driving at medium speeds (above 20 km/h).

Some additional things that we should do for Autoware.Core

• Look into past work done for Autoware.Core
  • There is a closed PR which was meant for base class. We should finish that first.
• Write a better design documents for each packages with test codes
• Design CI for integration testing

I am open to any comments and ideas.

[xmfcx]

Autoware Core Steps

Autoware Core Base Class

• feat: add autoware_control_center and autoware_node autoware.core#84

Goals for the v1:

• Lifecycle
• Register/Deregister
  • List potential cases that are handled
• Heartbeat monitoring
  • Error/Warning/Healthy states are part of the heartbeat
• Basic ACC features
  • Report faulty nodes

Goals for the v2:

• Monitored subscribers
• Utilization of lifecycle states/transitions
• More ACC features
  • GUI interface
  • Input expected nodes
  • ...

Porting Steps

• Move the packages from universe to core as they are
  • Prefix them with autoware_ first
• Create a new autoware_core_launch package within autoware.core repository
• ACC and AN v1 will finish by they are done
• Make the core packages use AN and ACC base classes
• Add smoke tests

[mitsudome-r]

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.

[mitsudome-r]

I'm currently working on package porting from Autoware.Universe to Autoware.Core.
However, some packages needs to refactoring and require a simpler version of the package in Autoware.Core rather than doing a pure porting.

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 autoware_core_component_interface_specs, but I had some feedback internally in TIER IV that it would be better to keep it as autoware_component_interface_specs in Autoware.Core and rename the one in Autoware.Universe as autoware_universe_component_interface_specs. Here are the reasons:

• It would be confusing to have the mix of packages with autoware_core_ prefix and autoware_ prefix within Autoware.Core repository.
• Autoware.Core is the "official" packages maintained by AWF, and Universe is extension for Core. It makes more sense to rename the package in Autoware.Universe if there needs a duplicate (extension) package over Core package.
• Due to above reasons, it would be better to keep the core package name simple with autoware_ prefix and have extension/experimental packages in Autoware.Universe to name it autoware_universe_.

Does anyone have any comments around naming? (maybe @xmfcx and @esteve?)

[mitsudome-r]

For the namespace, if we want to keep it separate between the core package and universe package, we could make the universe one to autoware::universe_component_interface_specs instead of autoware::universe::component_interface_specs by treating "universe_component_interface_specs" as the package name and "autoware" as the project namespace. I think that would be more consistent with the rule we decided.

[xmfcx]

To me, that would be too many namespaces. Since the package name is different already, why not have it as autoware::universe_component_interface_specs namespace? Otherwise, all the universe packages would have needed to have the ::universe namespace.

Sorry, re-reading it, you have suggested the same thing.

[cyn-liu]

Hi
We should take a long-term view of this problem. If package autoware_component_interface_specs in Universe and Core implement the same function, why keep the two same packages?

@mitsudome-r san said:

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.

If the ultimate goal is that all packages no longer use dependencies on TIER IV repositories, then why not replace all TIER IV repositories dependencies in Universe first, and then port the packages to Core?
I am now moving tier4_planning_msgs to autoware_planning_msgs, and next I will replace all tier4_planning_msgs in the Universe. autowarefoundation/autoware_msgs#114, If I follow your proposal, shouldn't I do this work?

If packages autoware_univers_xxx and autoware_xxx coexist, Autoware will be very bloated in the future, and the dependencies between various packages will be confusing.

Have a nice day！

[mitsudome-r]

Approach 1
Treating universe as a sub-project

• rename all packages with autoware_universe_ prefix
• rename all namespace with autoware::universe::package_name

Pros: We have unified namespace and package name prefix for packages in Autoware.Universe
Cons: We have to go through the package renaming again for all the packages in Autoware.Universe

Approach 2
Treating "duplicate" name package as a extension package over core package

• add _universe as suffix as a new package name for only the duplicate packages that exists both in Core and Universe
• rename the namespace of the package with autoware::package_name_universe

Pros: We can only focus on renaming the duplicate packages
Cons: We have inconsistency for the packages that has no duplication

[mitsudome-r]

At least from yesterday's Software WG call, we are planning to go with Approach 2 since we don't really see much benefits with Approach 1 with consideration of efforts required for changing all the packages in Universe.