Skip to content
GitLab
  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
    • Switch to GitLab Next
  • Sign in / Register
  • AutowareAuto AutowareAuto
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 236
    • Issues 236
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
  • Merge requests 22
    • Merge requests 22
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Releases
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Autoware Foundation
  • Autoware.Auto
  • AutowareAutoAutowareAuto
  • Issues
  • #1421
Closed
Open
Created Dec 08, 2021 by M. Fatih Cırıt@xmfcx☃Owner

Discussion: Bus ODD Software Architecture

Architecture Refresh

Higher Level Architecture

Entire Architecture Graph v0.2
Entire Architecture Graph v0.1

You can also get the vectorized version from the diagrams.net link:

  • v0.2
  • v0.1

Rationale

For the Bus ODD(Operational Design Domain) requirements to be realized, we will refresh the architecture of the Autoware. With Core and Universe repositories coming, there is the need for a higher level module definitions.

The expected inputs and outputs of these high level modules should be defined thoroughly to enable development around a unified core.

This should also make it easier for new developers to understand the code-base and make it simpler for them to contribute.

Modules (v0.1)

I've created the draft architecture to start from. I've also added basic expectations from the modules.

We should also go over the existing messages finalize the interface between these modules. We have a nice message structure defined in Autoware.Auto but we should go over these to enable connections to potential new modules. And deprecate the messages/fields that aren't/won't be used.

Drivers

Drivers are the gateway between the raw sensory information and the ROS2 messaging system. They take inputs in various formats such as Serial, TCP/UDP, CANBUS and output ROS2 messages.

Driver Outputs

name format
Camera Images sensor_msgs/msg/Image.msg
Lidar Point Cloud sensor_msgs/msg/PointCloud2.msg
Radar Point Cloud sensor_msgs/msg/PointCloud2.msg
GNSS Message sensor_msgs/msg/NavSatFix.msg
INS Message sensor_msgs/msg/Imu.msg
Perception

Perception module is expected to perform 3 main tasks:

  1. Providing downsampled, combined point cloud to the localization stack for scan matching purposes
  2. Providing 3D obstacle and object detections/predictions to the planning stack
  3. Maintaining a Traffic Light Recognition server that calculates what the given traffic light color is.

Perception Inputs

name format
Camera Images Defined in Drivers
Lidar Point Cloud Defined in Drivers
Radar Point Cloud Defined in Drivers
Vehicle Kinematic State Defined in Localization
Traffic Light Query Defined in Planning

Perception Outputs

name format
Combined Point Cloud sensor_msgs/msg/PointCloud2.msg
3D Object Predictions autoware_auto_perception_msgs/msg/PredictedObjects.idl
Traffic Light Response Finalized version of autoware_auto_msgs!16 (diffs) which would be autoware_auto_perception_msgs/msg/TrafficSignalArray.idl
Localization

Localization Inputs

name format
Camera Images Defined in Drivers
Lidar Point Cloud Defined in Drivers
Radar Point Cloud Defined in Drivers
GNSS Message Defined in Drivers
INS Message Defined in Drivers
Vehicle Odometry Defined in Vehicle Interface

Localization Outputs

name format
Vehicle Kinematic State (A new message that combines a Header, PoseWithCovariance and TwistWithCovariance)
TF Output transformations to ROS2 TF tree
Planning

Planning Inputs

name format
3D Object Predictions Defined in Perception
Traffic Light Response Defined in Perception
Vehicle Kinematic State Defined in Localization
Lanelet2 Map Defined in Map Server
Engagement Response Defined in User Interface

Planning Outputs

name format
Traffic Light Query A new message that conveys the global pose/size information of one or multiple traffic lights and their ids to perception stack
Trajectory autoware_auto_planning_msgs/msg/Trajectory.idl
Vehicle Signal Commands A lot of messages in https://gitlab.com/autowarefoundation/autoware.auto/autoware_auto_msgs/-/tree/master/autoware_auto_vehicle_msgs/msg :)
Engagement Request A new message that requests for a certain routine to be approved from the user (start the drive, lane change)
Control

This is the simplest module in terms of connectivity. Control is easy right?

Control Inputs

name format
Vehicle Kinematic State Defined in Localization
Trajectory Defined in Planning

Control Outputs

name format
Vehicle Control Command autoware_auto_vehicle_msgs/msg/VehicleControlCommand.idl
Vehicle Interface

Vehicle Interface also talks to the vehicle in a specific protocol defined by the vehicle. And acts as the gateway between the ROS2 messaging system and the vehicle.

Vehicle Interface Inputs

name format
Vehicle Control Command Defined in Control
Vehicle Signal Commands Defined in Planning

Vehicle Interface Outputs

name format
Vehicle Signal Reports A lot of messages in https://gitlab.com/autowarefoundation/autoware.auto/autoware_auto_msgs/-/tree/master/autoware_auto_vehicle_msgs/msg :P
Vehicle Odometry autoware_auto_vehicle_msgs/msg/VehicleOdometry.idl
User Interface

User Interface Inputs

name format
Engagement Request Defined in Planning
Lanelet2 Map Defined in Map Server

User Interface Outputs

name format
Engagement Response A new message that defines the response by the user that approves or rejects the request for a certain routine
Goal Pose sensor_msgs/msg/NavSatFix.msg
Map Server

Map Server reads the Lanelet2 map from the disk and publishes it for other nodes to use for navigation.

It also takes in the current position info of the vehicle, reads the feature map around the vehicle from the disk and publishes the for localization module to use.

User Interface Outputs

name format
Feature Map sensor_msgs/msg/PointCloud2.msg
Lanelet2 Map autoware_auto_mapping_msgs/msg/HADMapBin.idl

References

The AVP Demo Architecture: https://autowarefoundation.gitlab.io/autoware.auto/AutowareAuto/avpdemo.html

Edited Dec 15, 2021 by M. Fatih Cırıt
Assignee
Assign to
Time tracking