[WG RP] Autoware Reference Platform Definition Documentation

[sstrahm]

AUTOWARE REFERENCE PLATFORM

This document is presenting the intents of the Autoware Foundation (AWF) Reference Platform Working Group (RP-WG). This is a live document, providing to reader a view of the purpose, plan and orientation of the Working Group. This document has to be reviewed by all participants to the RP-WG and will be submitted to the Technical Steering Committee on regular basis.

DOCUMENT CONTENT

• Autoware Reference Platform Working Group (introduction and intents – done)

• Document Information (done)

• Use Cases and Configurations (draft for discussion)

• Features (to be done)

• Roadmap (to be done)

• Reference Software Platform (intents proposed)

• Reference Hardware Platform (draft for discussion)

AUTOWARE REFERENCE PLATFORM WORKING GROUP

In July 2019, AWF TSC launched the creation of Working Groups in order to focus technical topics and oversight them (Autoware working group: Call for participation). The Reference Platform WG (RP-WG) has been announced at the same time (Launching "Reference Platform" Autoware WG).

Co-leaded by Autocore and Kalray representatives, it is calling for participants to contribute to the different activities to be covered:

• Define the initial Reference Platform: hardware and software-wise

• Work on roadmap for alignment of hardware and software with Autoware.AI and Autoware.Auto

• Establish and maintain a roadmap longer term

• Contribute for hardware and software integration

The principles of the RP-WG can be summarized as being:

• Moving market to benefit from Autoware Eco-System
  • From Experimentation to Reference Implementation to Production
  • Autoware members have all bricks for Reference Implementation Step
  • Experimentation Step is on-going
  • Let’s move to Reference Implementation Step
  • Define it, plan it, make it
  • All Autoware members have a brick

(illustration of first contributors, RP-WG participants are NOT limited!)*

Blockquote The ultimate goal for AWF is to be able to present to its users a system that he can acquire and use for creating prototype vehicles and reduce his time to market for production. It will contain best in class compute platform, including accelerator capabilities to run in an optimized way the latest Autoware.Auto release.

Several intermediate steps prior achieving and maintaining this goal will be necessary. This is one of the purpose of this Working Group to define these steps and perform them.

DOCUMENT INFORMATION

Document Status : DRAFT

This is working document, regularly updates

Some parts are are under investigation, under discussion by the Working Group.

USE CASES & CONFIGURATIONS

REFERENCE CONFIGURATION

Draft:

Define four domains to functions:

1. P1 provide CAN/UART capability device drivers (ROS/ROS2) and sensor data synchronize.

2. P2 provide LVDS capability and CV/Fusion features for camera data.

3. P3 running autoware.ai stack.

4. P4 running autoware.auto stack.

About deployment of P1-P4:

1. Support different deployment strategy with different computer platform configuration.

2. You can put P1-P4 together in one powerful computer.

3. Can also deploy different features in different computer unit.

4. Generally, P1 should compatible vehicle network including AutoSAR Stack

5. If using multi boards solution, use ETH or TSN as network solution.

6. CNN accelerator can be a part of P2/P3/P4 as algorithm needs.

Opens:

• Sensors supported: need to discuss with community, need to know sensor configurations of different useage.
• Support boards: need to discuss with community.
  • Current Autoware.auto support IPC and Xavier. It’s nvidia GPU solution.
  • Heterogeneous solution: 96boards automotive and standalone accelerator (Autocore and Kalray)*

FEATURES

To be studied

Will be aligned with Autoware.AI (first) and Autoware.Auto features as suppoted by Hardware.

ROADMAP

To be studied

REFERENCE SOFTWARE PLATFORM

PRINCIPLES

The AWF Reference Platform will use Autoware Software.

Initial platform will rely on Autoware.AI and support Autoware.auto from early stage.

To be align roadmap SW/HW

REFERENCE HARDWARE PLATFORM

CURRENT AUTOWARE.AUTO CONFIGURATON

Demo/dev car configuration of our current autoware.auto development team(Apex)

1. Vehicle : Lexus 450 LH with the Pacmod 3.0DBW interface

2. Sensors :

3. 4 VLP-16(or comparable sensors, e.g. VLP-32C)

4. 16 Sonar sensors

5. 4 cameras(180 degree FOV)

6. Novatel GPS

7. ECUs :

8. Nvidia AGX Xavieraarch64 computer

9. Nuvorugged x86-64 desktop computer

FOR INFORMATION : KALRAY MPPA®

The Kalray MPPA (Massively Parallel Processors Array) is a Manycore architecture allowing to executing compute and acceleration algorithms in an optimized and low power consumption.

• Reference Accelerator Boards
  • PCIe boards with MPPA®2 Generation, MPPA®3 upcoming
  • Accelerator daughter board modules
• Reference Programming Software
  • CNN Inference Optimizer
  • CNN Inference Runtime Engine (additional algo support and growing)
  • Computer Vision OpenCV
  • OpenCL 1.2
• Hardware Integration
  • Intel and ARM hosts
• Software Integration
  • Additional Use Cases support (Companion, StandAlone)-to simplify System integration
  • Linux and Autoware Member RTOS supported

The integration with Autoware.AI consists as of today in offloading the following algorithms onto the MPPA

• Image Detector
  • CNN based object detection (car/person/…)
  • Autoware uses Darknet(YOLO networks)/SSD/RCNN project
  • SSD and Yolo V3 CNN have been tested within Autoware, using Kalray inference engine solution on MPPA®
  • Other CNN can also be used
• LiDAR Localization
  • Based on “NDT matching” algorithm from PCL library
  • Compute car coordinates by matching its LIDAR data to a precomputed map
  • Fully implemented on MPPA® (both initialization and runtime functions)

FOR INFORMATION : CURRENT APOLLO CONFIGURATON

Apollo 5.0 sensor configuration:

Hardware deployment:

[gbiggs]

For clarification, the reference software is the responsibility of the Autoware working group. This working group’s responsibility extends only as far as software drivers for ECU-specific hardware. For anything else, please coordinate with the Autoware working group.

[sstrahm]

Fully agreed @gbiggs, no confusion on this point.

[cheng.chen]

we proposal several different kinds of node (P1-P4) for below reasons:

1. considering next gen E/E arch of vehicle.
   • P1 could be a gateway device which support different connections and can support gerneral sensor message interface(driver).
   • P2 could be a smart camera which are used in current ADAS system. most of them are based on vision purpose SoC.
   • P3/P4 are general purpose computing unit.
   • different unit target different ASIL level in plan.
   • P1(Gateway) and P2(Smart Cam) target ASIL B.
   • P3/P4 should support hardware redundancy (as request) and has ASIL D decision maker unit(MCU) inside.
2. enhanced P1/P2 which can deploy some peception features will be benifical to HCP system’s algorithm optimzation. can left the optimize work to device provider.
   • for example, P1 can filter and fusion lidar data by dedicate hardware package accelerator.
3. if user are using x86 IPC, everything should be working fine and no difference.
4. Software requirements for Autoware WG:
   • code organization (repo split should be better, I think)
   • build standard message spec/definiation. it should be very useful for realization of special hardware/accelerator.