From 9c65d6b6eabaf8d1e5861590a91440b0b92a06c7 Mon Sep 17 00:00:00 2001 From: github-actions Date: Wed, 14 Dec 2022 03:14:04 +0000 Subject: [PATCH] Deployed 0c1c706 to latest with MkDocs 1.4.2 and mike 1.2.0.dev0 --- latest/search/search_index.json | 2 +- latest/sitemap.xml | 228 +++++++++--------- latest/sitemap.xml.gz | Bin 1191 -> 1192 bytes .../how-to-run-autoware/index.html | 9 + 4 files changed, 124 insertions(+), 115 deletions(-) diff --git a/latest/search/search_index.json b/latest/search/search_index.json index ba193d20..20f4d323 100644 --- a/latest/search/search_index.json +++ b/latest/search/search_index.json @@ -1 +1 @@ -{"config":{"indexing":"full","lang":["en"],"min_search_length":3,"prebuild_index":false,"separator":"[\\s\\-]+"},"docs":[{"location":"","text":"Open AD Kit Documentation # The latest version is 2.0, but it has not been officially released yet. About Open AD Kit # Open AD Kit aims to democratize autonomous drive (AD) systems by bringing the cloud and edge closer together. In doing so, Open AD Kit will lower the threshold for developing and deploying the Autoware software stack. For more details about the Open AD Kit project, its goals and details of the Autoware Foundation working group that oversees the project, refer to the Open AD Kit Working Group wiki . Open AD Kit documentation structure # Getting started # Start guide describes how to install, set up and run Autoware and its associated simulators on supported development platforms. System configuration describes the components that make up Open AD Kit in terms of the required hardware and software. Application example provides an actual application example for Open AD Kit that can be used as a reference for the development of other applications. Releases # version 2.0 Latest version 1.0","title":"Open AD Kit Documentation"},{"location":"#open-ad-kit-documentation","text":"The latest version is 2.0, but it has not been officially released yet.","title":"Open AD Kit Documentation"},{"location":"#about-open-ad-kit","text":"Open AD Kit aims to democratize autonomous drive (AD) systems by bringing the cloud and edge closer together. In doing so, Open AD Kit will lower the threshold for developing and deploying the Autoware software stack. For more details about the Open AD Kit project, its goals and details of the Autoware Foundation working group that oversees the project, refer to the Open AD Kit Working Group wiki .","title":"About Open AD Kit"},{"location":"#open-ad-kit-documentation-structure","text":"","title":"Open AD Kit documentation structure"},{"location":"#getting-started","text":"Start guide describes how to install, set up and run Autoware and its associated simulators on supported development platforms. System configuration describes the components that make up Open AD Kit in terms of the required hardware and software. Application example provides an actual application example for Open AD Kit that can be used as a reference for the development of other applications.","title":"Getting started"},{"location":"#releases","text":"version 2.0 Latest version 1.0","title":"Releases"},{"location":"version-1.0/","text":"Open AD Kit Documentation # The latest version is 2.0, but it has not been officially released yet. About Open AD Kit # Open AD Kit aims to democratize autonomous drive (AD) systems by bringing the cloud and edge closer together. In doing so, Open AD Kit will lower the threshold for developing and deploying the Autoware software stack. For more details about the Open AD Kit project, its goals and details of the Autoware Foundation working group that oversees the project, refer to the Open AD Kit Working Group wiki . Open AD Kit documentation structure # Getting started # Start guide describes how to install, set up and run Autoware and its associated simulators on supported development platforms. System configuration describes the components that make up Open AD Kit in terms of the required hardware and software. Application example provides an actual application example for Open AD Kit that can be used as a reference for the development of other applications.","title":"Introduction"},{"location":"version-1.0/#open-ad-kit-documentation","text":"The latest version is 2.0, but it has not been officially released yet.","title":"Open AD Kit Documentation"},{"location":"version-1.0/#about-open-ad-kit","text":"Open AD Kit aims to democratize autonomous drive (AD) systems by bringing the cloud and edge closer together. In doing so, Open AD Kit will lower the threshold for developing and deploying the Autoware software stack. For more details about the Open AD Kit project, its goals and details of the Autoware Foundation working group that oversees the project, refer to the Open AD Kit Working Group wiki .","title":"About Open AD Kit"},{"location":"version-1.0/#open-ad-kit-documentation-structure","text":"","title":"Open AD Kit documentation structure"},{"location":"version-1.0/#getting-started","text":"Start guide describes how to install, set up and run Autoware and its associated simulators on supported development platforms. System configuration describes the components that make up Open AD Kit in terms of the required hardware and software. Application example provides an actual application example for Open AD Kit that can be used as a reference for the development of other applications.","title":"Getting started"},{"location":"version-1.0/application-example/","text":"Application example # There is no application example of Open AD Kit version 1.0.","title":"Application example"},{"location":"version-1.0/application-example/#application-example","text":"There is no application example of Open AD Kit version 1.0.","title":"Application example"},{"location":"version-1.0/application-example/driverless-bus/","text":"Driverless bus # The content is a work in progress. This page provides a reference design for a passenger transportation system in the urban area. The reference design consists of the following structures: Introduction of Reference Design Concept of Operations Operational Concept Operational Environment Requirements System Requirements System Configuration Hardware Requirements Software Requirements Appendix","title":"Driverless bus"},{"location":"version-1.0/application-example/driverless-bus/#driverless-bus","text":"The content is a work in progress. This page provides a reference design for a passenger transportation system in the urban area. The reference design consists of the following structures: Introduction of Reference Design Concept of Operations Operational Concept Operational Environment Requirements System Requirements System Configuration Hardware Requirements Software Requirements Appendix","title":"Driverless bus"},{"location":"version-1.0/application-example/driverless-bus/appendix/","text":"Appendix # The content is a work in progress. What is ConOps and OpsCons? Hardware List","title":"Appendix"},{"location":"version-1.0/application-example/driverless-bus/appendix/#appendix","text":"The content is a work in progress. What is ConOps and OpsCons? Hardware List","title":"Appendix"},{"location":"version-1.0/application-example/driverless-bus/appendix/hardware-list/","text":"Hardware List # The content is a work in progress. This page should show applicable hardwares for the system.","title":"Hardware List"},{"location":"version-1.0/application-example/driverless-bus/appendix/hardware-list/#hardware-list","text":"The content is a work in progress. This page should show applicable hardwares for the system.","title":"Hardware List"},{"location":"version-1.0/application-example/driverless-bus/appendix/what-is-conops-and-opscon/","text":"What is ConOps and OpsCons? # Concept of Operations (ConOps) : \u201c... the ConOps describes the overall high-level concept of how the system will be used to meet stakeholder expectations, usually in a time-sequenced manner\u2026\u201d, source NASA Systems Engineering Handbook In short, it describes how the system achieves the user\u2019s mission with a picture and short sentences. Operational Concept (OpsCon) : \u201cThe operational concept is designed to give an overall picture of the operations using one or more specific systems, or set of related systems, in the organization\u2019s operational environment from the users\u2019 and operators\u2019 perspective.\u201d, source SEBoK In short, it describes: How the system achieves the mission using unique features/events/interactions Relationships between the system and other systems Benefits : Stakeholders can understand the system from the early stages of development In particular, developers who have different backgrounds or perspectives can gain the same understanding","title":"What is ConOps and OpsCons?"},{"location":"version-1.0/application-example/driverless-bus/appendix/what-is-conops-and-opscon/#what-is-conops-and-opscons","text":"Concept of Operations (ConOps) : \u201c... the ConOps describes the overall high-level concept of how the system will be used to meet stakeholder expectations, usually in a time-sequenced manner\u2026\u201d, source NASA Systems Engineering Handbook In short, it describes how the system achieves the user\u2019s mission with a picture and short sentences. Operational Concept (OpsCon) : \u201cThe operational concept is designed to give an overall picture of the operations using one or more specific systems, or set of related systems, in the organization\u2019s operational environment from the users\u2019 and operators\u2019 perspective.\u201d, source SEBoK In short, it describes: How the system achieves the mission using unique features/events/interactions Relationships between the system and other systems Benefits : Stakeholders can understand the system from the early stages of development In particular, developers who have different backgrounds or perspectives can gain the same understanding","title":"What is ConOps and OpsCons?"},{"location":"version-1.0/application-example/driverless-bus/concept-of-operations/","text":"Concept of Operations # Passenger Transportation System in the urban area # The system, under the surveillance of an in-car operator, will automatically transport passengers while following routes on public roads. The public roads have multiple lanes, traffic lights, and intersections; therefore the system will automatically change lanes and respond to traffic lights at intersections. The system will automatically stop at bus stops. The system is programmed to avoid colliding with objects that are detected on the road. The vehicle is programmed to either safely pass the object when possible, or to stop. While the vehicle is moving, the system automatically maintains a safe following distance and stays within the speed limit (i.e., adaptive cruise control).","title":"Concept of Operations"},{"location":"version-1.0/application-example/driverless-bus/concept-of-operations/#concept-of-operations","text":"","title":"Concept of Operations"},{"location":"version-1.0/application-example/driverless-bus/concept-of-operations/#passenger-transportation-system-in-the-urban-area","text":"The system, under the surveillance of an in-car operator, will automatically transport passengers while following routes on public roads. The public roads have multiple lanes, traffic lights, and intersections; therefore the system will automatically change lanes and respond to traffic lights at intersections. The system will automatically stop at bus stops. The system is programmed to avoid colliding with objects that are detected on the road. The vehicle is programmed to either safely pass the object when possible, or to stop. While the vehicle is moving, the system automatically maintains a safe following distance and stays within the speed limit (i.e., adaptive cruise control).","title":"Passenger Transportation System in the urban area"},{"location":"version-1.0/application-example/driverless-bus/hardware-requirements/","text":"Hardware Requirements # The content is a work in progress. Vehicle Requirements ECU Requirements Sensor Requirements LiDAR Requirements Camera Requirements Radar Requirements","title":"Hardware Requirements"},{"location":"version-1.0/application-example/driverless-bus/hardware-requirements/#hardware-requirements","text":"The content is a work in progress. Vehicle Requirements ECU Requirements Sensor Requirements LiDAR Requirements Camera Requirements Radar Requirements","title":"Hardware Requirements"},{"location":"version-1.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/","text":"ECU Requirements # This is a draft version. Overview # The requirements described in the following pages are determined based on a Tier IV project as a reference for now. This will be updated once the requirements for Open AD Kit was determined. Table of contents # High-level Architecture System Resource & Interface Performance and Data Bandwidth Requirements Hardware Requirements","title":"ECU Requirements"},{"location":"version-1.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/#ecu-requirements","text":"This is a draft version.","title":"ECU Requirements"},{"location":"version-1.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/#overview","text":"The requirements described in the following pages are determined based on a Tier IV project as a reference for now. This will be updated once the requirements for Open AD Kit was determined.","title":"Overview"},{"location":"version-1.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/#table-of-contents","text":"High-level Architecture System Resource & Interface Performance and Data Bandwidth Requirements Hardware Requirements","title":"Table of contents"},{"location":"version-1.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/high-level-arch/","text":"High-level Architecture # This is a draft version. Overview # The reference system consists of three parts of computing unit. Main Autoware 2D Perception Traffic Light Recognition Each unit can be implemented on separated hardware units (ECUs) and, if the hardware has sufficient system resource and performance, some units can also be integrated on a single hardware unit. Block Diagram #","title":"High-level Architecture"},{"location":"version-1.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/high-level-arch/#high-level-architecture","text":"This is a draft version.","title":"High-level Architecture"},{"location":"version-1.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/high-level-arch/#overview","text":"The reference system consists of three parts of computing unit. Main Autoware 2D Perception Traffic Light Recognition Each unit can be implemented on separated hardware units (ECUs) and, if the hardware has sufficient system resource and performance, some units can also be integrated on a single hardware unit.","title":"Overview"},{"location":"version-1.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/high-level-arch/#block-diagram","text":"","title":"Block Diagram"},{"location":"version-1.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/hw-requirements/","text":"Hardware Requirements # This is a draft version. Overview # This page describes sample requirements for hardware specification. NOTE: This type of hardware requirement should be differed depending on a target vehicle and changed by the industrial standard. It also needs to be determined during hardware design so might should be a part of the reference implementation. Reliability # Item Requirement Standard AEC-Q100 Environmental # Item Requirement Operating Temp e.g. -40 to 130 degree celsius Storage Temp Humidity Vibration Shock EMC Mechanical # Item Requirement Dimensions Weight Mounting Power # Item Requirement AC/DC input supply e.g. shall input 350V DC Power Consumption e.g. shall be less 600W Cooling # Item Requirement Liquid cooling","title":"Hardware Requirements"},{"location":"version-1.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/hw-requirements/#hardware-requirements","text":"This is a draft version.","title":"Hardware Requirements"},{"location":"version-1.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/hw-requirements/#overview","text":"This page describes sample requirements for hardware specification. NOTE: This type of hardware requirement should be differed depending on a target vehicle and changed by the industrial standard. It also needs to be determined during hardware design so might should be a part of the reference implementation.","title":"Overview"},{"location":"version-1.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/hw-requirements/#reliability","text":"Item Requirement Standard AEC-Q100","title":"Reliability"},{"location":"version-1.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/hw-requirements/#environmental","text":"Item Requirement Operating Temp e.g. -40 to 130 degree celsius Storage Temp Humidity Vibration Shock EMC","title":"Environmental"},{"location":"version-1.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/hw-requirements/#mechanical","text":"Item Requirement Dimensions Weight Mounting","title":"Mechanical"},{"location":"version-1.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/hw-requirements/#power","text":"Item Requirement AC/DC input supply e.g. shall input 350V DC Power Consumption e.g. shall be less 600W","title":"Power"},{"location":"version-1.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/hw-requirements/#cooling","text":"Item Requirement Liquid cooling","title":"Cooling"},{"location":"version-1.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/perf-data-bandwidth/","text":"Performance and Data Bandwidth Requirements # This is a draft version. Overview # This page describes required performance for the perception accelerators and data bandwidth on each sensor interface and network. Perception Accelerators # Functions Network Model Input resolution @ frame rate Required performance 3D Perception CenterPoint 55000 voxels x 20 points x 10 features @10FPS per LiDAR XX TOPS 2D Perception Yolov4 608x608@10FPS per Camera XX TOPS Traffic Light Recognition MobileNet v2 SSD Lite (Detection) MobileNet v2 (Classification) 300x300@10FPS 224x224@10FPS XX TOPS Data Bandwidth # Type Configurations Data type Data Bandwidth LiDAR Input Mid-range Point cloud 37 Mbps Short-range Point cloud 26 Mbps Camera Input Perception Camera YUV422 16bit 1920x1280 393 Mbps Traffic Light Recognition Camera YUV422 16bit 2880x1860 857 Mbps Inter- ECU 2D Perception to Main Autoware Recognition result & Compressed image data for logging 27 Mbps TLR to Main Autoware Recognition result & Compressed image data for logging 59 Mbps Logging Storage Mid-range LiDAR x 4 Short-range LiDAR x 4 Perception Camera x 6 (Compressed) Traffic Light Recognition Camera x 1 (Compressed) Main Autoware internat topics (272Mbps) 745 Mbps","title":"Performance and Data Bandwidth Requirements"},{"location":"version-1.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/perf-data-bandwidth/#performance-and-data-bandwidth-requirements","text":"This is a draft version.","title":"Performance and Data Bandwidth Requirements"},{"location":"version-1.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/perf-data-bandwidth/#overview","text":"This page describes required performance for the perception accelerators and data bandwidth on each sensor interface and network.","title":"Overview"},{"location":"version-1.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/perf-data-bandwidth/#perception-accelerators","text":"Functions Network Model Input resolution @ frame rate Required performance 3D Perception CenterPoint 55000 voxels x 20 points x 10 features @10FPS per LiDAR XX TOPS 2D Perception Yolov4 608x608@10FPS per Camera XX TOPS Traffic Light Recognition MobileNet v2 SSD Lite (Detection) MobileNet v2 (Classification) 300x300@10FPS 224x224@10FPS XX TOPS","title":"Perception Accelerators"},{"location":"version-1.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/perf-data-bandwidth/#data-bandwidth","text":"Type Configurations Data type Data Bandwidth LiDAR Input Mid-range Point cloud 37 Mbps Short-range Point cloud 26 Mbps Camera Input Perception Camera YUV422 16bit 1920x1280 393 Mbps Traffic Light Recognition Camera YUV422 16bit 2880x1860 857 Mbps Inter- ECU 2D Perception to Main Autoware Recognition result & Compressed image data for logging 27 Mbps TLR to Main Autoware Recognition result & Compressed image data for logging 59 Mbps Logging Storage Mid-range LiDAR x 4 Short-range LiDAR x 4 Perception Camera x 6 (Compressed) Traffic Light Recognition Camera x 1 (Compressed) Main Autoware internat topics (272Mbps) 745 Mbps","title":"Data Bandwidth"},{"location":"version-1.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/sys-resource-if/","text":"System Resource & Interface # This is a draft version. Overview # The following tables describe the required system resource and interface for each computing unit. Main Autoware Unit # Category Item Requirement Computing Resource CPU X86 8core/16thread @3.3GHz or more Memory Dual 16GB (Total 32GB), DDR4-2666 w/ ECC or more GPU 9.4 TFLOPS@FP32 or more Storage 256GB for System Volume 2TB for Logging data LiDAR 100BASE-TX, 1000BASE-T Interfaces IMU CAN or RS232C GNSS 100BASE-TX Vehicle CAN Inter- ECU (2D Perception/TLR) 1000BASE-T Power CPU TDP 80 W GPU TDP 110 W Total Max 250 W 2D Perception Unit # This table shows requirements for one camera. For multiple camera configurations, it requires more hardware units. If the hardware unit has sufficient system resource and performance, it can be integrated on a single hardware unit. Category Item Requirement Computing Resource CPU Arm v8.2 8core @2.26GHz or more Memory 32GB Low-Power Double Data Rate 4x or more GPU 30 TOPS or more Storage 32GB or more Interfaces Camera Gigabit Multimedia Serial Link 2 w/ frame sync trigger or 1000BASE-T (GigE Vision) Inter- ECU (Main Autoware) 1000BASE-T Power CPU TDP xxxW GPU TDP xxxW Total Max.xxxW Traffic Light Recognition Unit # This table shows requirements for one camera. For multiple camera configurations, it requires more hardware units. If the hardware unit has sufficient system resource and performance, it can be integrated on a single hardware unit. Category Item Requirement Computing Resource CPU Arm v8.2 8core @2.26GHz or more Memory 32GB Low-Power Double Data Rate 4x or more GPU 30 TOPS or more Storage 32GB or more Interfaces Camera Gigabit Multimedia Serial Link 2 w/ frame sync trigger or 1000BASE-T (GigE Vision) Inter- ECU (Main Autoware) 1000BASE-T Power CPU TDP xxxW GPU TDP xxxW Total Max.xxxW","title":"System Resource & Interface"},{"location":"version-1.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/sys-resource-if/#system-resource-interface","text":"This is a draft version.","title":"System Resource & Interface"},{"location":"version-1.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/sys-resource-if/#overview","text":"The following tables describe the required system resource and interface for each computing unit.","title":"Overview"},{"location":"version-1.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/sys-resource-if/#main-autoware-unit","text":"Category Item Requirement Computing Resource CPU X86 8core/16thread @3.3GHz or more Memory Dual 16GB (Total 32GB), DDR4-2666 w/ ECC or more GPU 9.4 TFLOPS@FP32 or more Storage 256GB for System Volume 2TB for Logging data LiDAR 100BASE-TX, 1000BASE-T Interfaces IMU CAN or RS232C GNSS 100BASE-TX Vehicle CAN Inter- ECU (2D Perception/TLR) 1000BASE-T Power CPU TDP 80 W GPU TDP 110 W Total Max 250 W","title":"Main Autoware Unit"},{"location":"version-1.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/sys-resource-if/#2d-perception-unit","text":"This table shows requirements for one camera. For multiple camera configurations, it requires more hardware units. If the hardware unit has sufficient system resource and performance, it can be integrated on a single hardware unit. Category Item Requirement Computing Resource CPU Arm v8.2 8core @2.26GHz or more Memory 32GB Low-Power Double Data Rate 4x or more GPU 30 TOPS or more Storage 32GB or more Interfaces Camera Gigabit Multimedia Serial Link 2 w/ frame sync trigger or 1000BASE-T (GigE Vision) Inter- ECU (Main Autoware) 1000BASE-T Power CPU TDP xxxW GPU TDP xxxW Total Max.xxxW","title":"2D Perception Unit"},{"location":"version-1.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/sys-resource-if/#traffic-light-recognition-unit","text":"This table shows requirements for one camera. For multiple camera configurations, it requires more hardware units. If the hardware unit has sufficient system resource and performance, it can be integrated on a single hardware unit. Category Item Requirement Computing Resource CPU Arm v8.2 8core @2.26GHz or more Memory 32GB Low-Power Double Data Rate 4x or more GPU 30 TOPS or more Storage 32GB or more Interfaces Camera Gigabit Multimedia Serial Link 2 w/ frame sync trigger or 1000BASE-T (GigE Vision) Inter- ECU (Main Autoware) 1000BASE-T Power CPU TDP xxxW GPU TDP xxxW Total Max.xxxW","title":"Traffic Light Recognition Unit"},{"location":"version-1.0/application-example/driverless-bus/introduction-of-reference-design/","text":"Introduction of Reference Design # Introduction # Autonomous driving technology # AWF aims to establish a sustainable ecosystem for autonomous driving to which various organizations and individuals can contribute in terms of development, and wherein society can enjoy the benefits. AWF offers open access to technologies contributing to autonomous driving. Autonomous driving requires a composite platform which integrates various software, cloud infrastructure and services in addition to the in-vehicle AD ( Autonomous Driving ) systems. There is a need for a horizontally collaborative development approach based on an open source platform that ensures a level of safety that satisfies society at a reasonable cost. In order to realize this, AWF is promoting (1) Autoware, an open source autonomous driving software, (2) AD System Reference Designs based on ODD ( Operational Design Domain \uff09categorization, and (3) Deep-tech R&D of AD systems. What can do with \"Reference Design\" as ecosystem? # With clear ODD classifications, everyone can understand where AD fits into complex real-world traffic environments. By presenting a suitable \"Reference Design\" for each ODD , AWF simplifies the preparation process in AD and lowers the difficulty threshold for demonstration and implementation.","title":"Introduction of Reference Design"},{"location":"version-1.0/application-example/driverless-bus/introduction-of-reference-design/#introduction-of-reference-design","text":"","title":"Introduction of Reference Design"},{"location":"version-1.0/application-example/driverless-bus/introduction-of-reference-design/#introduction","text":"","title":"Introduction"},{"location":"version-1.0/application-example/driverless-bus/introduction-of-reference-design/#autonomous-driving-technology","text":"AWF aims to establish a sustainable ecosystem for autonomous driving to which various organizations and individuals can contribute in terms of development, and wherein society can enjoy the benefits. AWF offers open access to technologies contributing to autonomous driving. Autonomous driving requires a composite platform which integrates various software, cloud infrastructure and services in addition to the in-vehicle AD ( Autonomous Driving ) systems. There is a need for a horizontally collaborative development approach based on an open source platform that ensures a level of safety that satisfies society at a reasonable cost. In order to realize this, AWF is promoting (1) Autoware, an open source autonomous driving software, (2) AD System Reference Designs based on ODD ( Operational Design Domain \uff09categorization, and (3) Deep-tech R&D of AD systems.","title":"Autonomous driving technology"},{"location":"version-1.0/application-example/driverless-bus/introduction-of-reference-design/#what-can-do-with-reference-design-as-ecosystem","text":"With clear ODD classifications, everyone can understand where AD fits into complex real-world traffic environments. By presenting a suitable \"Reference Design\" for each ODD , AWF simplifies the preparation process in AD and lowers the difficulty threshold for demonstration and implementation.","title":"What can do with \"Reference Design\" as ecosystem?"},{"location":"version-1.0/application-example/driverless-bus/operational-concept/","text":"Operational Concept # Operational Concept (OpsCon) of the Passenger Transportation System in the urban area is below: Daytime operation Nighttime operation Follow a route Let passengers on and off at bus stops Avoid collisions Set service route via HMI on the vehicle Interact with other vehicles on the public roads Interact with emergency vehicles Interact with traffic lights Operation mode Take over request to the operator Lane keeping and changing lanes Adaptive cruise control Predict pedestrian stepping into the road","title":"Operational Concept"},{"location":"version-1.0/application-example/driverless-bus/operational-concept/#operational-concept","text":"Operational Concept (OpsCon) of the Passenger Transportation System in the urban area is below: Daytime operation Nighttime operation Follow a route Let passengers on and off at bus stops Avoid collisions Set service route via HMI on the vehicle Interact with other vehicles on the public roads Interact with emergency vehicles Interact with traffic lights Operation mode Take over request to the operator Lane keeping and changing lanes Adaptive cruise control Predict pedestrian stepping into the road","title":"Operational Concept"},{"location":"version-1.0/application-example/driverless-bus/operational-concept/adaptive-cruise-control/","text":"Adaptive cruise control # The system automatically maintains a safe following distance and stays within the speed limit.","title":"Adaptive cruise control"},{"location":"version-1.0/application-example/driverless-bus/operational-concept/adaptive-cruise-control/#adaptive-cruise-control","text":"The system automatically maintains a safe following distance and stays within the speed limit.","title":"Adaptive cruise control"},{"location":"version-1.0/application-example/driverless-bus/operational-concept/avoid-collisions/","text":"Avoid collisions # When there are objects on the route, the system will automatically perform the following actions: a. The system automatically stops if there is surrounding traffic. b. The system automatically avoids the objects if there is no surrounding traffic.","title":"Avoid collisions"},{"location":"version-1.0/application-example/driverless-bus/operational-concept/avoid-collisions/#avoid-collisions","text":"When there are objects on the route, the system will automatically perform the following actions: a. The system automatically stops if there is surrounding traffic. b. The system automatically avoids the objects if there is no surrounding traffic.","title":"Avoid collisions"},{"location":"version-1.0/application-example/driverless-bus/operational-concept/daytime-operation/","text":"Daytime operation # Currently, the system does NOT operate in the daytime. In the future, the system will be able to operate during the daytime (9:30am - 3:30pm). The vehicle will be fully charged before the operation in the daytime. The operator connects the charger to the vehicle, and the vehicle is automatically charged.","title":"Daytime operation"},{"location":"version-1.0/application-example/driverless-bus/operational-concept/daytime-operation/#daytime-operation","text":"Currently, the system does NOT operate in the daytime. In the future, the system will be able to operate during the daytime (9:30am - 3:30pm). The vehicle will be fully charged before the operation in the daytime. The operator connects the charger to the vehicle, and the vehicle is automatically charged.","title":"Daytime operation"},{"location":"version-1.0/application-example/driverless-bus/operational-concept/follow-a-route/","text":"Follow a route # The system follows a route set on the public road while an in-car operator is in the autonomous driving vehicle of the system.","title":"Follow a route"},{"location":"version-1.0/application-example/driverless-bus/operational-concept/follow-a-route/#follow-a-route","text":"The system follows a route set on the public road while an in-car operator is in the autonomous driving vehicle of the system.","title":"Follow a route"},{"location":"version-1.0/application-example/driverless-bus/operational-concept/interact-with-emergency-vehicles/","text":"Interact with emergency vehicles # When the vehicle meets an emergency vehicle, an in-car operator performs the following actions: Promptly maneuvers the vehicle to the side of the road and stops Manually re-launches the system after the emergency vehicle passes by NOTE: The operator can use HMI (e.g., steering wheel or brake pedal) at any time to override the system control.","title":"Interact with emergency vehicles"},{"location":"version-1.0/application-example/driverless-bus/operational-concept/interact-with-emergency-vehicles/#interact-with-emergency-vehicles","text":"When the vehicle meets an emergency vehicle, an in-car operator performs the following actions: Promptly maneuvers the vehicle to the side of the road and stops Manually re-launches the system after the emergency vehicle passes by NOTE: The operator can use HMI (e.g., steering wheel or brake pedal) at any time to override the system control.","title":"Interact with emergency vehicles"},{"location":"version-1.0/application-example/driverless-bus/operational-concept/interact-with-other-vehicle-on-the-public-roads/","text":"Interact with other vehicles on the public roads # The service route uses public roads, so the system interacts with other vehicles and must obey all traffic laws. When the vehicle approaches an intersection, the system is programed to yield and take right of way with surrounding traffic, depending the actual situation and traffic laws.","title":"Interact with other vehicles on the public roads"},{"location":"version-1.0/application-example/driverless-bus/operational-concept/interact-with-other-vehicle-on-the-public-roads/#interact-with-other-vehicles-on-the-public-roads","text":"The service route uses public roads, so the system interacts with other vehicles and must obey all traffic laws. When the vehicle approaches an intersection, the system is programed to yield and take right of way with surrounding traffic, depending the actual situation and traffic laws.","title":"Interact with other vehicles on the public roads"},{"location":"version-1.0/application-example/driverless-bus/operational-concept/interact-with-traffic-lights/","text":"Interact with traffic lights # When the vehicle meets a traffic light, the system performs one of the following actions: Stop on a red light Stop on a yellow light Go straight, turn right, or turn left on a green light or arrow","title":"Interact with traffic lights"},{"location":"version-1.0/application-example/driverless-bus/operational-concept/interact-with-traffic-lights/#interact-with-traffic-lights","text":"When the vehicle meets a traffic light, the system performs one of the following actions: Stop on a red light Stop on a yellow light Go straight, turn right, or turn left on a green light or arrow","title":"Interact with traffic lights"},{"location":"version-1.0/application-example/driverless-bus/operational-concept/lane-keeping-and-changing-lanes/","text":"Lane keeping and changing lanes # The system stays the driving lane or changes lanes according to the route.","title":"Lane keeping and changing lanes"},{"location":"version-1.0/application-example/driverless-bus/operational-concept/lane-keeping-and-changing-lanes/#lane-keeping-and-changing-lanes","text":"The system stays the driving lane or changes lanes according to the route.","title":"Lane keeping and changing lanes"},{"location":"version-1.0/application-example/driverless-bus/operational-concept/let-passengers-on-and-off-at-bus-stops/","text":"Let passengers on and off at bus stops # The system stops at bus stops set by the in-car operator. The in-car operator manually opens and closes the door of the vehicle to let passengers on and off at bus stops due to the local government\u2019s request. After the in-car operator requests the system to depart, the system automatically resumes driving along the route.","title":"Let passengers on and off at bus stops"},{"location":"version-1.0/application-example/driverless-bus/operational-concept/let-passengers-on-and-off-at-bus-stops/#let-passengers-on-and-off-at-bus-stops","text":"The system stops at bus stops set by the in-car operator. The in-car operator manually opens and closes the door of the vehicle to let passengers on and off at bus stops due to the local government\u2019s request. After the in-car operator requests the system to depart, the system automatically resumes driving along the route.","title":"Let passengers on and off at bus stops"},{"location":"version-1.0/application-example/driverless-bus/operational-concept/nighttime-operation/","text":"Nighttime operation # During the nighttime (10pm - 1am), an in-car operator drives the vehicle from a parking lot to a start position and manually launches the autonomous driving system via HMI in the vehicle. The system starts moving automatically on a route set by the in-car operator. The in-car operator is while the system automatically operates.","title":"Nighttime operation"},{"location":"version-1.0/application-example/driverless-bus/operational-concept/nighttime-operation/#nighttime-operation","text":"During the nighttime (10pm - 1am), an in-car operator drives the vehicle from a parking lot to a start position and manually launches the autonomous driving system via HMI in the vehicle. The system starts moving automatically on a route set by the in-car operator. The in-car operator is while the system automatically operates.","title":"Nighttime operation"},{"location":"version-1.0/application-example/driverless-bus/operational-concept/operation-mode/","text":"Operation mode: Automatic/Manual # The in-car operator manually launches the autonomous driving system, which causes the system to start the autonomous driving. If the fail safe system in the vehicle detects malfunctions or the in-car operator presses the button on the fail safe system, the system automatically changes the operation mode from automatic to manual. Then the vehicle automatically stops.","title":"Operation mode: Automatic/Manual"},{"location":"version-1.0/application-example/driverless-bus/operational-concept/operation-mode/#operation-mode-automaticmanual","text":"The in-car operator manually launches the autonomous driving system, which causes the system to start the autonomous driving. If the fail safe system in the vehicle detects malfunctions or the in-car operator presses the button on the fail safe system, the system automatically changes the operation mode from automatic to manual. Then the vehicle automatically stops.","title":"Operation mode: Automatic/Manual"},{"location":"version-1.0/application-example/driverless-bus/operational-concept/predict-pedestrian-stepping-into-the-road/","text":"Predict pedestrian stepping into the road # The vehicle is programmed to detect pedestrians who may step into the road, and the vehicle decelerates in response.","title":"Predict pedestrian stepping into the road"},{"location":"version-1.0/application-example/driverless-bus/operational-concept/predict-pedestrian-stepping-into-the-road/#predict-pedestrian-stepping-into-the-road","text":"The vehicle is programmed to detect pedestrians who may step into the road, and the vehicle decelerates in response.","title":"Predict pedestrian stepping into the road"},{"location":"version-1.0/application-example/driverless-bus/operational-concept/set-service-route-via-HMI-on-the-vehicle/","text":"Set service route via HMI on the vehicle # The operator can set authorized service routes of the system via the Human Machine Interface ( HMI ) on the vehicle before the operation. The system can only accept a modified route while the vehicle is parked. NOTE: the service route cannot be changed without the authorization from the local government.","title":"Set service route via HMI on the vehicle"},{"location":"version-1.0/application-example/driverless-bus/operational-concept/set-service-route-via-HMI-on-the-vehicle/#set-service-route-via-hmi-on-the-vehicle","text":"The operator can set authorized service routes of the system via the Human Machine Interface ( HMI ) on the vehicle before the operation. The system can only accept a modified route while the vehicle is parked. NOTE: the service route cannot be changed without the authorization from the local government.","title":"Set service route via HMI on the vehicle"},{"location":"version-1.0/application-example/driverless-bus/operational-concept/take-over-request-to-the-operator/","text":"Take over request to the operator # When the system cannot judge whether it can move forward, the system sends a recommendation to hand over operation to the in-car operator. The operator is supposed to perform the following actions when requested by the system: Request to depart\uff08refer to Let passengers on and off at bus-stops \uff09 Avoid objects Detour","title":"Take over request to the operator"},{"location":"version-1.0/application-example/driverless-bus/operational-concept/take-over-request-to-the-operator/#take-over-request-to-the-operator","text":"When the system cannot judge whether it can move forward, the system sends a recommendation to hand over operation to the in-car operator. The operator is supposed to perform the following actions when requested by the system: Request to depart\uff08refer to Let passengers on and off at bus-stops \uff09 Avoid objects Detour","title":"Take over request to the operator"},{"location":"version-1.0/application-example/driverless-bus/operational-environment-requirement/","text":"Operational Environment Requirements # The content is a work in progress.","title":"Operational Environment Requirements"},{"location":"version-1.0/application-example/driverless-bus/operational-environment-requirement/#operational-environment-requirements","text":"The content is a work in progress.","title":"Operational Environment Requirements"},{"location":"version-1.0/application-example/driverless-bus/software-requirements/","text":"Software Requirements # The content is a work in progress. Operating System Requirements Kernel Module Requirements Middleware Requirements DDS Requirements Map Requirements Design docs of Autoware Autoware API Component Architecture Repository Configuration","title":"Software Requirements"},{"location":"version-1.0/application-example/driverless-bus/software-requirements/#software-requirements","text":"The content is a work in progress. Operating System Requirements Kernel Module Requirements Middleware Requirements DDS Requirements Map Requirements Design docs of Autoware Autoware API Component Architecture Repository Configuration","title":"Software Requirements"},{"location":"version-1.0/application-example/driverless-bus/software-requirements/autoware-api/","text":"Autoware API # Overview # Autoware API provides a long-term and stable operation protocol for autonomous driving vehicles, and clarifies how to support new sensors and vehicles and add new features. It also works as a framework for easy access to the functions of each component by developers of other components. Concept # There are two categories of Autoware API. One is Autoware AD API for operating the vehicle from outside the autonomous driving system such as Fleet Management System(FMS) and HMI for operators or passengers. The other is Autoware Component Interfaces for linking each internal component. Some external systems for evaluation or debugging purposes, such as simulator, are allowed access to Component Interfaces in addition to AD API. AD API Customization # For general usage, Autoware provides the default AD API implementations and configurations using Component Interfaces. If a special behavior is needed, the implementation can be modified as long as it satisfies the requirements of the specification. Component Interfaces Hierarchy # Autoware Component Interfaces have a hierarchical specification. The top-level architecture consists of several components, and each component has some options of the next-level architecture. Developers select one of them when implementing the component. The simplest next-level architecture is monolithic. This is an all-in-one and black box implementation, and is suitable for small group development, prototyping, and extremely complex functions. Others are just concepts and do not currently exist. However, these have advantages for large group development. Developers can combine their modules with other modules that adopt the same architecture. Interface Code Generation # For specification clarification and development efficiency, it is recommended to use the generated code by the defined interface. Developers may select the interface to use from the specification and refer the generated code in their program. This makes it easy to analyze the interface used by each program, which then can be applied to configuration automation and visualization.","title":"Autoware API"},{"location":"version-1.0/application-example/driverless-bus/software-requirements/autoware-api/#autoware-api","text":"","title":"Autoware API"},{"location":"version-1.0/application-example/driverless-bus/software-requirements/autoware-api/#overview","text":"Autoware API provides a long-term and stable operation protocol for autonomous driving vehicles, and clarifies how to support new sensors and vehicles and add new features. It also works as a framework for easy access to the functions of each component by developers of other components.","title":"Overview"},{"location":"version-1.0/application-example/driverless-bus/software-requirements/autoware-api/#concept","text":"There are two categories of Autoware API. One is Autoware AD API for operating the vehicle from outside the autonomous driving system such as Fleet Management System(FMS) and HMI for operators or passengers. The other is Autoware Component Interfaces for linking each internal component. Some external systems for evaluation or debugging purposes, such as simulator, are allowed access to Component Interfaces in addition to AD API.","title":"Concept"},{"location":"version-1.0/application-example/driverless-bus/software-requirements/autoware-api/#ad-api-customization","text":"For general usage, Autoware provides the default AD API implementations and configurations using Component Interfaces. If a special behavior is needed, the implementation can be modified as long as it satisfies the requirements of the specification.","title":"AD API Customization"},{"location":"version-1.0/application-example/driverless-bus/software-requirements/autoware-api/#component-interfaces-hierarchy","text":"Autoware Component Interfaces have a hierarchical specification. The top-level architecture consists of several components, and each component has some options of the next-level architecture. Developers select one of them when implementing the component. The simplest next-level architecture is monolithic. This is an all-in-one and black box implementation, and is suitable for small group development, prototyping, and extremely complex functions. Others are just concepts and do not currently exist. However, these have advantages for large group development. Developers can combine their modules with other modules that adopt the same architecture.","title":"Component Interfaces Hierarchy"},{"location":"version-1.0/application-example/driverless-bus/software-requirements/autoware-api/#interface-code-generation","text":"For specification clarification and development efficiency, it is recommended to use the generated code by the defined interface. Developers may select the interface to use from the specification and refer the generated code in their program. This makes it easy to analyze the interface used by each program, which then can be applied to configuration automation and visualization.","title":"Interface Code Generation"},{"location":"version-1.0/application-example/driverless-bus/software-requirements/component-architecture/","text":"Component architecture # Overview # The figure below is the overview of Autoware's component configuration (tentative). Autoware components # TODO(Tier IV): Write the details based on the following materials. Autoware.Auto autoware_auto_msgs Tier IV's proposal document Tier IV's proposal implementation Map # Inputs: Map file PointCloud map file Vector map file Outputs: Map data PointCloud map file Vector map file Sensing # Inputs: Raw sensor data GNSS IMU Camera LiDAR RADAR Estimated self motion To filter distortions Outputs: Preprocessed sensor data GNSS pose and doppler velocity IMU acceleration and angular velocity Camera image LiDAR PointCloud RADAR reflection Localization # Inputs: Preprocessed sensor data GNSS pose and doppler velocity IMU acceleration and angular velocity Camera image LiDAR PointCloud RADAR reflection Map data PointCloud map Vector map Outputs: Localized self pose Topic TF Estimated self motion Perception # Inputs: Localized self pose Estimated self motion Preprocessed sensor data Camera image LiDAR PointCloud RADAR reflection Outputs: Detected dynamic objects Detected traffic lights Filtered obstacle PointCloud Planning # Inputs: Localized pose Estimated self motion Outputs: Planned trajectory Planning status Control # Inputs: Localized self pose Estimated self motion Planner trajectory Vehicle sensor data velocity steering angle Outputs: Control commands High-level commands for easy usage Low-level commands for detailed controls Vehicle # Autoware to Vehicle # Inputs: Control commands Outputs: Raw vehicle control commands Vehicle to Autoware # Inputs: Raw vehicle sensor data (e.g. CAN) Outputs: Vehicle sensor data (Topic) System # Inputs: Each component output Outputs: System status MRM request","title":"Component architecture"},{"location":"version-1.0/application-example/driverless-bus/software-requirements/component-architecture/#component-architecture","text":"","title":"Component architecture"},{"location":"version-1.0/application-example/driverless-bus/software-requirements/component-architecture/#overview","text":"The figure below is the overview of Autoware's component configuration (tentative).","title":"Overview"},{"location":"version-1.0/application-example/driverless-bus/software-requirements/component-architecture/#autoware-components","text":"TODO(Tier IV): Write the details based on the following materials. Autoware.Auto autoware_auto_msgs Tier IV's proposal document Tier IV's proposal implementation","title":"Autoware components"},{"location":"version-1.0/application-example/driverless-bus/software-requirements/component-architecture/#map","text":"Inputs: Map file PointCloud map file Vector map file Outputs: Map data PointCloud map file Vector map file","title":"Map"},{"location":"version-1.0/application-example/driverless-bus/software-requirements/component-architecture/#sensing","text":"Inputs: Raw sensor data GNSS IMU Camera LiDAR RADAR Estimated self motion To filter distortions Outputs: Preprocessed sensor data GNSS pose and doppler velocity IMU acceleration and angular velocity Camera image LiDAR PointCloud RADAR reflection","title":"Sensing"},{"location":"version-1.0/application-example/driverless-bus/software-requirements/component-architecture/#localization","text":"Inputs: Preprocessed sensor data GNSS pose and doppler velocity IMU acceleration and angular velocity Camera image LiDAR PointCloud RADAR reflection Map data PointCloud map Vector map Outputs: Localized self pose Topic TF Estimated self motion","title":"Localization"},{"location":"version-1.0/application-example/driverless-bus/software-requirements/component-architecture/#perception","text":"Inputs: Localized self pose Estimated self motion Preprocessed sensor data Camera image LiDAR PointCloud RADAR reflection Outputs: Detected dynamic objects Detected traffic lights Filtered obstacle PointCloud","title":"Perception"},{"location":"version-1.0/application-example/driverless-bus/software-requirements/component-architecture/#planning","text":"Inputs: Localized pose Estimated self motion Outputs: Planned trajectory Planning status","title":"Planning"},{"location":"version-1.0/application-example/driverless-bus/software-requirements/component-architecture/#control","text":"Inputs: Localized self pose Estimated self motion Planner trajectory Vehicle sensor data velocity steering angle Outputs: Control commands High-level commands for easy usage Low-level commands for detailed controls","title":"Control"},{"location":"version-1.0/application-example/driverless-bus/software-requirements/component-architecture/#vehicle","text":"","title":"Vehicle"},{"location":"version-1.0/application-example/driverless-bus/software-requirements/component-architecture/#system","text":"Inputs: Each component output Outputs: System status MRM request","title":"System"},{"location":"version-1.0/application-example/driverless-bus/software-requirements/design-docs-of-autoware/","text":"Design docs of Autoware # In this section, we'll explain a couple of design documents of Autoware. The first one is about Autoware API . It defines two kinds of APIs for different developers. Autoware AD API for developers of external systems such as fleet management HMI , etc. AD means Autonomous Driving. Autoware Component Interface for developers of Autoware components such as Localization, Perception, etc. The second one is about the architecture of Autoware components. It explains the interface between Autoware components in detail. The last one is about the repository configuration of Autoware, which is currently used here . It explains why such a distributed structure is necessary.","title":"Design docs of Autoware"},{"location":"version-1.0/application-example/driverless-bus/software-requirements/design-docs-of-autoware/#design-docs-of-autoware","text":"In this section, we'll explain a couple of design documents of Autoware. The first one is about Autoware API . It defines two kinds of APIs for different developers. Autoware AD API for developers of external systems such as fleet management HMI , etc. AD means Autonomous Driving. Autoware Component Interface for developers of Autoware components such as Localization, Perception, etc. The second one is about the architecture of Autoware components. It explains the interface between Autoware components in detail. The last one is about the repository configuration of Autoware, which is currently used here . It explains why such a distributed structure is necessary.","title":"Design docs of Autoware"},{"location":"version-1.0/application-example/driverless-bus/software-requirements/repository-configuration/","text":"Repository configuration # Overview # This page shows the repository configuration of Autoware and its concepts. Warning Note: This figure is tentative. TODO: Add documentations repositories, WG repositories, and autoware.org. Concepts # Core/Universe architecture # Since Autoware is desired to be usable for production-level vehicles in the future, Autoware.Auto has been used strict merge criteria. However, since there is no specific requirements or specifications in Autonomous Driving, it's almost impossible to build a perfect product from the beginning. We need prototyping phases to build a high-quality product, so we're doing ODD -based developments. Then, doing every development in one branch causes slowing down of development speed or mixin of low-quality. Also, forcing such a strict rules for all contributors will make them discourage from sending PRs. Therefore, it's better to separate production level and high-quality code and prototyping level code. Specifically, we define Core/Universe for this. Core defines the interfaces of Autoware Both Core and Universe refer to the interface Core has high-quality code Universe has experimental level code With this, we aim to accomplish the following things. Contributors can feel free to send small PRs. We can keep high-quality for the Core code. We can rapidly build prototypes in Universe. We can develop a lot of extensions, including cutting-edge features, based on the interfaces. Definition of Core/Universe # Core Complete end-to-end autonomous driving framework Supports all current AWF ODDs Provides the definitions and the functionality for which other packages can extend Strict code and quality control Heavily managed by the AWF Stable base implementation Universe Additional packages built on top of Core Extends Autoware functionality beyond the AWF ODDs Completely dependent on Core functionality and message definitions Relaxed code and quality control Community managed Enables quick experimentation and prototype testing Repositories and roles # Although some repositories might be added in the future, these are enough for explaining the core concept. autowarefoundation/autoware This is a meta-repository that contains .repos files to construct a workspace. Since it's prospected to be forked by users, we don't put a lot of information here to avoid unnecessary differences. autowarefoundation/autoware_common This is a repository that contains ROS packages referenced in common by many repositories like libraries and utilities. In order to reduce the CI execution time, splitting that kind of packages from a big repository is a good practice. autowarefoundation/autoware.core This is a core repository that contains high-quality and stable ROS packages for Autonomous Driving. Although it's almost empty at this time, it will be implemented based on Autoware.Auto and Autoware.Universe during the next ODD project. autowarefoundation/autoware.universe This is a core repository that contains experimental but cutting-edge ROS packages for Autonomous Driving. autowarefoundation/autoware_launch This is a launch configuration repository that contains node configurations and their parameters. autowarefoundation/autoware-github-actions This is a repository for CI that contains reusable workflows of GitHub Actions . Since Autoware has a lot of repositories in total, making CI scripts DRY(Don't Repeat Yourself) is efficient. autowarefoundation/autoware-documentation This is a documentation repository for Autoware users and developers. Since Autoware Core/Universe has multiple repositories, preparing a central documentation repository is more user-friendly than writing distributed documentation in each repository. FAQ # Why don't use the meta-repository for documentation? # Since it's forked by many users, documentation changes would be noise during syncing repositories. Why autoware.org isn't enough for documentation? # Since Software Engineers can't maintain it easily, it's hard to write a lot of information and keep up-to-date. Why both autoware-documentation and autoware-reference-design (this site) are required? # It's for a kind of separation of concerns. Too much information on one site makes confusion. autoware-documentation is mainly for users. autoware-reference-design is for core developers.","title":"Repository configuration"},{"location":"version-1.0/application-example/driverless-bus/software-requirements/repository-configuration/#repository-configuration","text":"","title":"Repository configuration"},{"location":"version-1.0/application-example/driverless-bus/software-requirements/repository-configuration/#overview","text":"This page shows the repository configuration of Autoware and its concepts. Warning Note: This figure is tentative. TODO: Add documentations repositories, WG repositories, and autoware.org.","title":"Overview"},{"location":"version-1.0/application-example/driverless-bus/software-requirements/repository-configuration/#concepts","text":"","title":"Concepts"},{"location":"version-1.0/application-example/driverless-bus/software-requirements/repository-configuration/#coreuniverse-architecture","text":"Since Autoware is desired to be usable for production-level vehicles in the future, Autoware.Auto has been used strict merge criteria. However, since there is no specific requirements or specifications in Autonomous Driving, it's almost impossible to build a perfect product from the beginning. We need prototyping phases to build a high-quality product, so we're doing ODD -based developments. Then, doing every development in one branch causes slowing down of development speed or mixin of low-quality. Also, forcing such a strict rules for all contributors will make them discourage from sending PRs. Therefore, it's better to separate production level and high-quality code and prototyping level code. Specifically, we define Core/Universe for this. Core defines the interfaces of Autoware Both Core and Universe refer to the interface Core has high-quality code Universe has experimental level code With this, we aim to accomplish the following things. Contributors can feel free to send small PRs. We can keep high-quality for the Core code. We can rapidly build prototypes in Universe. We can develop a lot of extensions, including cutting-edge features, based on the interfaces.","title":"Core/Universe architecture"},{"location":"version-1.0/application-example/driverless-bus/software-requirements/repository-configuration/#definition-of-coreuniverse","text":"Core Complete end-to-end autonomous driving framework Supports all current AWF ODDs Provides the definitions and the functionality for which other packages can extend Strict code and quality control Heavily managed by the AWF Stable base implementation Universe Additional packages built on top of Core Extends Autoware functionality beyond the AWF ODDs Completely dependent on Core functionality and message definitions Relaxed code and quality control Community managed Enables quick experimentation and prototype testing","title":"Definition of Core/Universe"},{"location":"version-1.0/application-example/driverless-bus/software-requirements/repository-configuration/#repositories-and-roles","text":"Although some repositories might be added in the future, these are enough for explaining the core concept. autowarefoundation/autoware This is a meta-repository that contains .repos files to construct a workspace. Since it's prospected to be forked by users, we don't put a lot of information here to avoid unnecessary differences. autowarefoundation/autoware_common This is a repository that contains ROS packages referenced in common by many repositories like libraries and utilities. In order to reduce the CI execution time, splitting that kind of packages from a big repository is a good practice. autowarefoundation/autoware.core This is a core repository that contains high-quality and stable ROS packages for Autonomous Driving. Although it's almost empty at this time, it will be implemented based on Autoware.Auto and Autoware.Universe during the next ODD project. autowarefoundation/autoware.universe This is a core repository that contains experimental but cutting-edge ROS packages for Autonomous Driving. autowarefoundation/autoware_launch This is a launch configuration repository that contains node configurations and their parameters. autowarefoundation/autoware-github-actions This is a repository for CI that contains reusable workflows of GitHub Actions . Since Autoware has a lot of repositories in total, making CI scripts DRY(Don't Repeat Yourself) is efficient. autowarefoundation/autoware-documentation This is a documentation repository for Autoware users and developers. Since Autoware Core/Universe has multiple repositories, preparing a central documentation repository is more user-friendly than writing distributed documentation in each repository.","title":"Repositories and roles"},{"location":"version-1.0/application-example/driverless-bus/software-requirements/repository-configuration/#faq","text":"","title":"FAQ"},{"location":"version-1.0/application-example/driverless-bus/software-requirements/repository-configuration/#why-dont-use-the-meta-repository-for-documentation","text":"Since it's forked by many users, documentation changes would be noise during syncing repositories.","title":"Why don't use the meta-repository for documentation?"},{"location":"version-1.0/application-example/driverless-bus/software-requirements/repository-configuration/#why-autowareorg-isnt-enough-for-documentation","text":"Since Software Engineers can't maintain it easily, it's hard to write a lot of information and keep up-to-date.","title":"Why autoware.org isn't enough for documentation?"},{"location":"version-1.0/application-example/driverless-bus/software-requirements/repository-configuration/#why-both-autoware-documentation-and-autoware-reference-design-this-site-are-required","text":"It's for a kind of separation of concerns. Too much information on one site makes confusion. autoware-documentation is mainly for users. autoware-reference-design is for core developers.","title":"Why both autoware-documentation and autoware-reference-design (this site) are required?"},{"location":"version-1.0/application-example/driverless-bus/system-configuration/","text":"System Configuration # The content is a work in progress. This chapter should show the physical configuration of the system.","title":"System Configuration"},{"location":"version-1.0/application-example/driverless-bus/system-configuration/#system-configuration","text":"The content is a work in progress. This chapter should show the physical configuration of the system.","title":"System Configuration"},{"location":"version-1.0/application-example/driverless-bus/system-requirements/","text":"System Requirements # The content is a work in progress. This chapter should show requirements for the system of interest and its sub-systems. Parity Requirements","title":"System Requirements"},{"location":"version-1.0/application-example/driverless-bus/system-requirements/#system-requirements","text":"The content is a work in progress. This chapter should show requirements for the system of interest and its sub-systems. Parity Requirements","title":"System Requirements"},{"location":"version-1.0/application-example/driverless-bus/system-requirements/parity-requirements/","text":"Parity # Importance of the parity in the verification of autonomous driving systems # One of the most important points in the verification process of the autonomous driving system is the guaranteed level of the parity between the edge (onboard) and the cloud (CI /CD) environment. Various types of the parity and the information that is useful in the verification architecture taking the parity into consideration \u3000 are explained. Parity types # Device Parity # The parity of the hardware (machines). When using the public cloud, as the device variation available on the public cloud is generally limited, it is difficult to guarantee this device parity. CPU Architecture Parity # The parity of the processor implementation including the microservice architecture and the clock speed, etc. ISA Parity # The ISA (Instruction Set Architecture) Parity is different from the CPU Architecture Parity. It means the parity of the available register resource, instruction set, and the calculation functionality, where the processor implementation is abstracted. Runtime Parity # The Runtime Parity means the parity of the kernel module and the container runtime, where the built result at the application level is guaranteed to run flawlessly. However, depending on the implementation, some modules do not run even if the Runtime Parity is secured. For example, the object detection module which is optimized for a GPU model. Environment Parity # The Environment Parity means the parity of the network configuration, set of frameworks and libraries of the autonomous driving system applications. Parity and Cloud Native DevOps # In autonomous driving system verification, it is important to conduct the necessary tests by understanding what level of parity is guaranteed for the verification environment compared to the vehicle environment. On the other hand, in case that the public cloud is used as a cloud native environment, the Device Parity may not be fulfilled. Depending on the choice of the chip, the CPU Architecture Parity or the ISA Parity may not be met. It is crucial to conduct tests in the bench environment while improving the development experience by executing the sufficient number of tests in a short time period in a cloud native manner.","title":"Parity"},{"location":"version-1.0/application-example/driverless-bus/system-requirements/parity-requirements/#parity","text":"","title":"Parity"},{"location":"version-1.0/application-example/driverless-bus/system-requirements/parity-requirements/#importance-of-the-parity-in-the-verification-of-autonomous-driving-systems","text":"One of the most important points in the verification process of the autonomous driving system is the guaranteed level of the parity between the edge (onboard) and the cloud (CI /CD) environment. Various types of the parity and the information that is useful in the verification architecture taking the parity into consideration \u3000 are explained.","title":"Importance of the parity in the verification of autonomous driving systems"},{"location":"version-1.0/application-example/driverless-bus/system-requirements/parity-requirements/#parity-types","text":"","title":"Parity types"},{"location":"version-1.0/application-example/driverless-bus/system-requirements/parity-requirements/#device-parity","text":"The parity of the hardware (machines). When using the public cloud, as the device variation available on the public cloud is generally limited, it is difficult to guarantee this device parity.","title":"Device Parity"},{"location":"version-1.0/application-example/driverless-bus/system-requirements/parity-requirements/#cpu-architecture-parity","text":"The parity of the processor implementation including the microservice architecture and the clock speed, etc.","title":"CPU Architecture Parity"},{"location":"version-1.0/application-example/driverless-bus/system-requirements/parity-requirements/#isa-parity","text":"The ISA (Instruction Set Architecture) Parity is different from the CPU Architecture Parity. It means the parity of the available register resource, instruction set, and the calculation functionality, where the processor implementation is abstracted.","title":"ISA Parity"},{"location":"version-1.0/application-example/driverless-bus/system-requirements/parity-requirements/#runtime-parity","text":"The Runtime Parity means the parity of the kernel module and the container runtime, where the built result at the application level is guaranteed to run flawlessly. However, depending on the implementation, some modules do not run even if the Runtime Parity is secured. For example, the object detection module which is optimized for a GPU model.","title":"Runtime Parity"},{"location":"version-1.0/application-example/driverless-bus/system-requirements/parity-requirements/#environment-parity","text":"The Environment Parity means the parity of the network configuration, set of frameworks and libraries of the autonomous driving system applications.","title":"Environment Parity"},{"location":"version-1.0/application-example/driverless-bus/system-requirements/parity-requirements/#parity-and-cloud-native-devops","text":"In autonomous driving system verification, it is important to conduct the necessary tests by understanding what level of parity is guaranteed for the verification environment compared to the vehicle environment. On the other hand, in case that the public cloud is used as a cloud native environment, the Device Parity may not be fulfilled. Depending on the choice of the chip, the CPU Architecture Parity or the ISA Parity may not be met. It is crucial to conduct tests in the bench environment while improving the development experience by executing the sufficient number of tests in a short time period in a cloud native manner.","title":"Parity and Cloud Native DevOps"},{"location":"version-1.0/start-guide/","text":"Start guide # This page describes how to install, set up and run Autoware and its associated simulators on supported development platforms. Installation explains how to set up the development environment that are described in the System Configuration chapter. How to run Autoware shows how to run Autoware on the development platform that are set up in the Installation chapter. How to run simulators demonstrates how to run simulators that are set up in the Installation chapter.","title":"Start guide"},{"location":"version-1.0/start-guide/#start-guide","text":"This page describes how to install, set up and run Autoware and its associated simulators on supported development platforms. Installation explains how to set up the development environment that are described in the System Configuration chapter. How to run Autoware shows how to run Autoware on the development platform that are set up in the Installation chapter. How to run simulators demonstrates how to run simulators that are set up in the Installation chapter.","title":"Start guide"},{"location":"version-1.0/start-guide/how-to-run-autoware/","text":"How to run Autoware # This page explains how to run Autoware on the development platform that are set up in the Installation chapter . Minimum requirements # Developer Platform: TODO In-Vehicle Development Platform 1 : TODO Software Tool: TODO Container Image: TODO 1. Run Autoware on the developer platform # Run Autoware.Auto on AVA platform or PCU # Open terminal window for each module on you host. Access AVA platform or PCU via SSH in each terminal window. Find docker image id. docker image ls REPOSITORY TAG IMAGE ID CREATED SIZE public.ecr.aws/k7o9k6q7/tier4/autoware.auto open_ad_kit-autoware-auto-20211111234534-88ea1196cdc0-2zv2o 48a4503b4fe4 11 days ago 6.65GB You can find id such as 48a4503b4fe4 . Launch modules. Replace 48a4503b4fe4 with your docker image id. Terminal 1 (map) docker run --rm -it --net host -v ~/map:/map -v ~/cyclonedds:/etc/cyclonedds 48a4503b4fe4 /bin/bash -c \"export CYCLONEDDS_URI=file:///etc/cyclonedds/cyclonedds.xml; export RMW_IMPLEMENTATION=rmw_cyclonedds_cpp; source install/setup.bash; ros2 launch scenario_simulator_launch autoware_auto_mapping.launch.py map_path:=/map/kashiwanoha\" Terminal 2 (perception) docker run --rm -it --net host -v ~/cyclonedds:/etc/cyclonedds 48a4503b4fe4 /bin/bash -c \"export CYCLONEDDS_URI=file:///etc/cyclonedds/cyclonedds.xml; export RMW_IMPLEMENTATION=rmw_cyclonedds_cpp; source install/setup.bash; ros2 launch scenario_simulator_launch autoware_auto_perception.launch.py\" Terminal 3 (planning) docker run --rm -it --net host -v ~/cyclonedds:/etc/cyclonedds 48a4503b4fe4 /bin/bash -c \"export CYCLONEDDS_URI=file:///etc/cyclonedds/cyclonedds.xml; export RMW_IMPLEMENTATION=rmw_cyclonedds_cpp; source install/setup.bash; ros2 launch scenario_simulator_launch autoware_auto_planning.launch.py\" Terminal 4 (vehicle) docker run --rm -it --net host -v ~/cyclonedds:/etc/cyclonedds 48a4503b4fe4 /bin/bash -c \"export CYCLONEDDS_URI=file:///etc/cyclonedds/cyclonedds.xml; export RMW_IMPLEMENTATION=rmw_cyclonedds_cpp; source install/setup.bash; ros2 launch autoware_auto_launch autoware_auto_vehicle.launch.py\" 2. Run Autoware on the in-vehicle development platform # If you do NOT need a vehicle-edge platform, please skip this step. TODO 3. Run simulators on the development platform # Please refer to the How to run simulators section. This is optional if you do NOT need a vehicle-edge platform. \u21a9","title":"How to run Autoware"},{"location":"version-1.0/start-guide/how-to-run-autoware/#how-to-run-autoware","text":"This page explains how to run Autoware on the development platform that are set up in the Installation chapter .","title":"How to run Autoware"},{"location":"version-1.0/start-guide/how-to-run-autoware/#minimum-requirements","text":"Developer Platform: TODO In-Vehicle Development Platform 1 : TODO Software Tool: TODO Container Image: TODO","title":"Minimum requirements"},{"location":"version-1.0/start-guide/how-to-run-autoware/#1-run-autoware-on-the-developer-platform","text":"","title":"1. Run Autoware on the developer platform"},{"location":"version-1.0/start-guide/how-to-run-autoware/#run-autowareauto-on-ava-platform-or-pcu","text":"Open terminal window for each module on you host. Access AVA platform or PCU via SSH in each terminal window. Find docker image id. docker image ls REPOSITORY TAG IMAGE ID CREATED SIZE public.ecr.aws/k7o9k6q7/tier4/autoware.auto open_ad_kit-autoware-auto-20211111234534-88ea1196cdc0-2zv2o 48a4503b4fe4 11 days ago 6.65GB You can find id such as 48a4503b4fe4 . Launch modules. Replace 48a4503b4fe4 with your docker image id. Terminal 1 (map) docker run --rm -it --net host -v ~/map:/map -v ~/cyclonedds:/etc/cyclonedds 48a4503b4fe4 /bin/bash -c \"export CYCLONEDDS_URI=file:///etc/cyclonedds/cyclonedds.xml; export RMW_IMPLEMENTATION=rmw_cyclonedds_cpp; source install/setup.bash; ros2 launch scenario_simulator_launch autoware_auto_mapping.launch.py map_path:=/map/kashiwanoha\" Terminal 2 (perception) docker run --rm -it --net host -v ~/cyclonedds:/etc/cyclonedds 48a4503b4fe4 /bin/bash -c \"export CYCLONEDDS_URI=file:///etc/cyclonedds/cyclonedds.xml; export RMW_IMPLEMENTATION=rmw_cyclonedds_cpp; source install/setup.bash; ros2 launch scenario_simulator_launch autoware_auto_perception.launch.py\" Terminal 3 (planning) docker run --rm -it --net host -v ~/cyclonedds:/etc/cyclonedds 48a4503b4fe4 /bin/bash -c \"export CYCLONEDDS_URI=file:///etc/cyclonedds/cyclonedds.xml; export RMW_IMPLEMENTATION=rmw_cyclonedds_cpp; source install/setup.bash; ros2 launch scenario_simulator_launch autoware_auto_planning.launch.py\" Terminal 4 (vehicle) docker run --rm -it --net host -v ~/cyclonedds:/etc/cyclonedds 48a4503b4fe4 /bin/bash -c \"export CYCLONEDDS_URI=file:///etc/cyclonedds/cyclonedds.xml; export RMW_IMPLEMENTATION=rmw_cyclonedds_cpp; source install/setup.bash; ros2 launch autoware_auto_launch autoware_auto_vehicle.launch.py\"","title":"Run Autoware.Auto on AVA platform or PCU"},{"location":"version-1.0/start-guide/how-to-run-autoware/#2-run-autoware-on-the-in-vehicle-development-platform","text":"If you do NOT need a vehicle-edge platform, please skip this step. TODO","title":"2. Run Autoware on the in-vehicle development platform"},{"location":"version-1.0/start-guide/how-to-run-autoware/#3-run-simulators-on-the-development-platform","text":"Please refer to the How to run simulators section. This is optional if you do NOT need a vehicle-edge platform. \u21a9","title":"3. Run simulators on the development platform"},{"location":"version-1.0/start-guide/how-to-run-simulators/","text":"How to run simulators # This page describes how to run simulators that work on your local environment and the cloud environment. Scenario simulator verifies your planning algorithms. Logging simulator verifies your perception algorithms with ROSBAG data that are recorded beforehand. There are some limitations and issues for the simulators.","title":"How to run simulators"},{"location":"version-1.0/start-guide/how-to-run-simulators/#how-to-run-simulators","text":"This page describes how to run simulators that work on your local environment and the cloud environment. Scenario simulator verifies your planning algorithms. Logging simulator verifies your perception algorithms with ROSBAG data that are recorded beforehand. There are some limitations and issues for the simulators.","title":"How to run simulators"},{"location":"version-1.0/start-guide/how-to-run-simulators/limitations-and-issues/limitations-and-issues/","text":"Limitations and issues # Limitations # Simulation by using LGSVL is not supported because a map for scenario simulator ( kashiwanoha ) is not registered in LGSVL Simulator Content Store. Issues # The ego vehicle drives slowly. UC-001-0018-Kashiwa:1 failed with simulation timeout. The ego vehicle gets stuck after NPC crossed ahead of the ego vehicle. This might be caused by the slow driving.","title":"Limitations and issues"},{"location":"version-1.0/start-guide/how-to-run-simulators/limitations-and-issues/limitations-and-issues/#limitations-and-issues","text":"","title":"Limitations and issues"},{"location":"version-1.0/start-guide/how-to-run-simulators/limitations-and-issues/limitations-and-issues/#limitations","text":"Simulation by using LGSVL is not supported because a map for scenario simulator ( kashiwanoha ) is not registered in LGSVL Simulator Content Store.","title":"Limitations"},{"location":"version-1.0/start-guide/how-to-run-simulators/limitations-and-issues/limitations-and-issues/#issues","text":"The ego vehicle drives slowly. UC-001-0018-Kashiwa:1 failed with simulation timeout. The ego vehicle gets stuck after NPC crossed ahead of the ego vehicle. This might be caused by the slow driving.","title":"Issues"},{"location":"version-1.0/start-guide/how-to-run-simulators/logging-simulator/run-on-cloud-env/","text":"Run on the cloud platform # This page describes how to run the logging simulator on the cloud platform. The cloud platform, Web.Auto, is offered by TIER IV , and it is available for the Autoware Foundation members. Minimum requirements # Developer Platform: TODO In-Vehicle Development Platform 1 : TODO Software Tool: TODO Container Image: TODO Data Pipeline: TODO 1. Create your account on the cloud platform # If you already have access to Web.Auto, please skip this step. TODO 2. Set up a simulation on the cloud platform # TODO 3. Run the logging simulator on the cloud platform # TODO This is optional if you do NOT need a vehicle-edge platform. \u21a9","title":"Run on the cloud platform"},{"location":"version-1.0/start-guide/how-to-run-simulators/logging-simulator/run-on-cloud-env/#run-on-the-cloud-platform","text":"This page describes how to run the logging simulator on the cloud platform. The cloud platform, Web.Auto, is offered by TIER IV , and it is available for the Autoware Foundation members.","title":"Run on the cloud platform"},{"location":"version-1.0/start-guide/how-to-run-simulators/logging-simulator/run-on-cloud-env/#minimum-requirements","text":"Developer Platform: TODO In-Vehicle Development Platform 1 : TODO Software Tool: TODO Container Image: TODO Data Pipeline: TODO","title":"Minimum requirements"},{"location":"version-1.0/start-guide/how-to-run-simulators/logging-simulator/run-on-cloud-env/#1-create-your-account-on-the-cloud-platform","text":"If you already have access to Web.Auto, please skip this step. TODO","title":"1. Create your account on the cloud platform"},{"location":"version-1.0/start-guide/how-to-run-simulators/logging-simulator/run-on-cloud-env/#2-set-up-a-simulation-on-the-cloud-platform","text":"TODO","title":"2. Set up a simulation on the cloud platform"},{"location":"version-1.0/start-guide/how-to-run-simulators/logging-simulator/run-on-cloud-env/#3-run-the-logging-simulator-on-the-cloud-platform","text":"TODO This is optional if you do NOT need a vehicle-edge platform. \u21a9","title":"3. Run the logging simulator on the cloud platform"},{"location":"version-1.0/start-guide/how-to-run-simulators/scenario-simulator/run-on-cloud-env/","text":"Run on the cloud platform # This page describes how to run the scenario simulator on the cloud platform. The cloud platform, Web.Auto, is offered by TIER IV , and it is available for the Autoware Foundation members. Minimum requirements # Developer Platform: TODO In-Vehicle Development Platform 1 : TODO Software Tool: TODO Container Image: TODO Data Pipeline: TODO 1. Create your account on the cloud platform # If you already have access to Web.Auto, please skip this step. Cloud Native CI/CD Pipeline - Web.Auto # The CI/CD pipeline for the scenario simulation is available for the Autoware Foundation members. You can check the scenario simulation results on the CI/CD dashboard. This material describes the CI/CD pipeline in more details. Create an account with Tier IV account server ( https://account.tier4.jp/ ). Participate in an Autoware Foundation working group (Simulation, Autonomy Software, Operational Design DomainD, Open AD Kit) and report the Tier IV Account ID you created in 1. to the leader of your working group. Then you can login to the CI/CD dashboard and see the scenario simulation results. 2. Set up a simulation on the cloud platform # TODO 3. Run the scenario simulator on the cloud platform # TODO This is optional if you do NOT need a vehicle-edge platform. \u21a9","title":"Run on the cloud platform"},{"location":"version-1.0/start-guide/how-to-run-simulators/scenario-simulator/run-on-cloud-env/#run-on-the-cloud-platform","text":"This page describes how to run the scenario simulator on the cloud platform. The cloud platform, Web.Auto, is offered by TIER IV , and it is available for the Autoware Foundation members.","title":"Run on the cloud platform"},{"location":"version-1.0/start-guide/how-to-run-simulators/scenario-simulator/run-on-cloud-env/#minimum-requirements","text":"Developer Platform: TODO In-Vehicle Development Platform 1 : TODO Software Tool: TODO Container Image: TODO Data Pipeline: TODO","title":"Minimum requirements"},{"location":"version-1.0/start-guide/how-to-run-simulators/scenario-simulator/run-on-cloud-env/#1-create-your-account-on-the-cloud-platform","text":"If you already have access to Web.Auto, please skip this step.","title":"1. Create your account on the cloud platform"},{"location":"version-1.0/start-guide/how-to-run-simulators/scenario-simulator/run-on-cloud-env/#2-set-up-a-simulation-on-the-cloud-platform","text":"TODO","title":"2. Set up a simulation on the cloud platform"},{"location":"version-1.0/start-guide/how-to-run-simulators/scenario-simulator/run-on-cloud-env/#3-run-the-scenario-simulator-on-the-cloud-platform","text":"TODO This is optional if you do NOT need a vehicle-edge platform. \u21a9","title":"3. Run the scenario simulator on the cloud platform"},{"location":"version-1.0/start-guide/how-to-run-simulators/scenario-simulator/run-on-local-env/","text":"Run on your local environment # This page describes how to run the scenario simulator on the developer platform that is set up in the Installation chapter. Minimum requirements # Developer Platform: TODO In-Vehicle Development Platform 1 : TODO Software Tool: TODO Container Image: TODO Data Pipeline: TODO Run visualization and scenario simulator on the developer platform # Run Rviz. You already cloned Autoware.Auto repository, navigate to the cloned directory. Launch ADE. cd ~/adehome/AutowareAuto ade --rc .aderc-amd64-foxy-lgsvl start --update --enter Launch visualization in ADE. source /opt/AutowareAuto/setup.bash ros2 launch autoware_auto_launch autoware_auto_visualization.launch.py Find docker image id. docker image ls REPOSITORY TAG IMAGE ID CREATED SIZE registry.gitlab.com/autowarefoundation/autoware.auto/autowareauto/amd64/binary-foxy master 91512aa9e485 3 days ago 176MB registry.gitlab.com/autowarefoundation/autoware.auto/autowareauto/amd64/ade-foxy master 0d9978b7113d 4 days ago 5.74GB scenario_simulator open_ad_kit-autoware-auto-planning_sim_v2-20211111234534-88ea1196cdc0-2zv2o d766a256a8c3 11 days ago 5.95GB registry.gitlab.com/autowarefoundation/autoware.auto/ade-lgsvl/foxy 2021.3 077c172fa5b9 5 weeks ago 379MB You can find id such as d766a256a8c3 . Launch scenario simulator. Replace /home/foo with your home directory. Replace d766a256a8c3 with your docker image id. docker run --rm -it --net host -v /home/foo/scenario:/scenario -v /home/foo/cyclonedds:/etc/cyclonedds d766a256a8c3 /bin/bash -c \"export CYCLONEDDS_URI=file:///etc/cyclonedds/cyclonedds.xml; export RMW_IMPLEMENTATION=rmw_cyclonedds_cpp; source install/setup.bash; ros2 launch scenario_test_runner scenario_test_runner.launch.py sensor_model:=aip_xx1 vehicle_model:=lexus launch_autoware:=false architecture_type:=awf/auto scenario:=/scenario/scenario_e3b743e7-110c-4db6-b136-e5ffd5538315_2.yml\" Now you can see... DEMO Video This is optional if you do NOT need a vehicle-edge platform. \u21a9","title":"Run on your local environment"},{"location":"version-1.0/start-guide/how-to-run-simulators/scenario-simulator/run-on-local-env/#run-on-your-local-environment","text":"This page describes how to run the scenario simulator on the developer platform that is set up in the Installation chapter.","title":"Run on your local environment"},{"location":"version-1.0/start-guide/how-to-run-simulators/scenario-simulator/run-on-local-env/#minimum-requirements","text":"Developer Platform: TODO In-Vehicle Development Platform 1 : TODO Software Tool: TODO Container Image: TODO Data Pipeline: TODO","title":"Minimum requirements"},{"location":"version-1.0/start-guide/how-to-run-simulators/scenario-simulator/run-on-local-env/#run-visualization-and-scenario-simulator-on-the-developer-platform","text":"Run Rviz. You already cloned Autoware.Auto repository, navigate to the cloned directory. Launch ADE. cd ~/adehome/AutowareAuto ade --rc .aderc-amd64-foxy-lgsvl start --update --enter Launch visualization in ADE. source /opt/AutowareAuto/setup.bash ros2 launch autoware_auto_launch autoware_auto_visualization.launch.py Find docker image id. docker image ls REPOSITORY TAG IMAGE ID CREATED SIZE registry.gitlab.com/autowarefoundation/autoware.auto/autowareauto/amd64/binary-foxy master 91512aa9e485 3 days ago 176MB registry.gitlab.com/autowarefoundation/autoware.auto/autowareauto/amd64/ade-foxy master 0d9978b7113d 4 days ago 5.74GB scenario_simulator open_ad_kit-autoware-auto-planning_sim_v2-20211111234534-88ea1196cdc0-2zv2o d766a256a8c3 11 days ago 5.95GB registry.gitlab.com/autowarefoundation/autoware.auto/ade-lgsvl/foxy 2021.3 077c172fa5b9 5 weeks ago 379MB You can find id such as d766a256a8c3 . Launch scenario simulator. Replace /home/foo with your home directory. Replace d766a256a8c3 with your docker image id. docker run --rm -it --net host -v /home/foo/scenario:/scenario -v /home/foo/cyclonedds:/etc/cyclonedds d766a256a8c3 /bin/bash -c \"export CYCLONEDDS_URI=file:///etc/cyclonedds/cyclonedds.xml; export RMW_IMPLEMENTATION=rmw_cyclonedds_cpp; source install/setup.bash; ros2 launch scenario_test_runner scenario_test_runner.launch.py sensor_model:=aip_xx1 vehicle_model:=lexus launch_autoware:=false architecture_type:=awf/auto scenario:=/scenario/scenario_e3b743e7-110c-4db6-b136-e5ffd5538315_2.yml\" Now you can see... DEMO Video This is optional if you do NOT need a vehicle-edge platform. \u21a9","title":"Run visualization and scenario simulator on the developer platform"},{"location":"version-1.0/start-guide/installation/","text":"Installation # This page explains how to set up the development environment that are described in the System Configuration chapter. Minimum requirements # Developer Platform: AVA Platform or PCU Platform In-Vehicle Development Platform 1 : TODO Software Tool: Scenario simulator version x.x 2 Rviz version x.x 2 Container Image: Autoware.Auto for arm64 Scenario simulator for x86_64 2 The following diagram shows a minimum configuration of Open AD Kit. \"Your host machine\" will be replaced by the cloud development platform if you can use Web.Auto. 1. Set up the developer platform # The setup procedure depends on the developer platform. AVA Platform # Getting started with EWAOL Boot EWAOL via SSD Boot Extend rootfs partition PCU Platform # Getting started with PCU 2. Set up the in-vehicle platform # If you do NOT need a vehicle-edge platform, please skip this step. TODO 3. Install Autoware container images on the developer platform # AVA Platform # System setup on AVA Platform PCU Platform # System setup on PCU 4. Install Autoware container images on the in-vehicle platform # If you do NOT need a vehicle-edge platform, please skip this step. TODO 5. Set up software tools # If you can use the cloud development platform, please skip this step. AVA Platform # System setup on your host PCU Platform # System setup on your host 6. Run Autoware on the development platform # Please refer to the How to run Autoware section. This is unnecessary if you do NOT need a vehicle-edge platform. \u21a9 This is unnecessary if you can use the cloud development platform, Web.Auto. \u21a9 \u21a9 \u21a9","title":"Installation"},{"location":"version-1.0/start-guide/installation/#installation","text":"This page explains how to set up the development environment that are described in the System Configuration chapter.","title":"Installation"},{"location":"version-1.0/start-guide/installation/#minimum-requirements","text":"Developer Platform: AVA Platform or PCU Platform In-Vehicle Development Platform 1 : TODO Software Tool: Scenario simulator version x.x 2 Rviz version x.x 2 Container Image: Autoware.Auto for arm64 Scenario simulator for x86_64 2 The following diagram shows a minimum configuration of Open AD Kit. \"Your host machine\" will be replaced by the cloud development platform if you can use Web.Auto.","title":"Minimum requirements"},{"location":"version-1.0/start-guide/installation/#1-set-up-the-developer-platform","text":"The setup procedure depends on the developer platform.","title":"1. Set up the developer platform"},{"location":"version-1.0/start-guide/installation/#ava-platform","text":"Getting started with EWAOL Boot EWAOL via SSD Boot Extend rootfs partition","title":"AVA Platform"},{"location":"version-1.0/start-guide/installation/#pcu-platform","text":"Getting started with PCU","title":"PCU Platform"},{"location":"version-1.0/start-guide/installation/#2-set-up-the-in-vehicle-platform","text":"If you do NOT need a vehicle-edge platform, please skip this step. TODO","title":"2. Set up the in-vehicle platform"},{"location":"version-1.0/start-guide/installation/#3-install-autoware-container-images-on-the-developer-platform","text":"","title":"3. Install Autoware container images on the developer platform"},{"location":"version-1.0/start-guide/installation/#ava-platform_1","text":"System setup on AVA Platform","title":"AVA Platform"},{"location":"version-1.0/start-guide/installation/#pcu-platform_1","text":"System setup on PCU","title":"PCU Platform"},{"location":"version-1.0/start-guide/installation/#4-install-autoware-container-images-on-the-in-vehicle-platform","text":"If you do NOT need a vehicle-edge platform, please skip this step. TODO","title":"4. Install Autoware container images on the in-vehicle platform"},{"location":"version-1.0/start-guide/installation/#5-set-up-software-tools","text":"If you can use the cloud development platform, please skip this step.","title":"5. Set up software tools"},{"location":"version-1.0/start-guide/installation/#ava-platform_2","text":"System setup on your host","title":"AVA Platform"},{"location":"version-1.0/start-guide/installation/#pcu-platform_2","text":"System setup on your host","title":"PCU Platform"},{"location":"version-1.0/start-guide/installation/#6-run-autoware-on-the-development-platform","text":"Please refer to the How to run Autoware section. This is unnecessary if you do NOT need a vehicle-edge platform. \u21a9 This is unnecessary if you can use the cloud development platform, Web.Auto. \u21a9 \u21a9 \u21a9","title":"6. Run Autoware on the development platform"},{"location":"version-1.0/start-guide/installation/boot-ewaol/","text":"Boot EWAOL via SSD Boot # Overview # You need to use SSD enclosure case to flash yocto image to M.2 SSD directly. Get yocto image # Build yocto image with EWAOL by following the instructions Getting started with EWAOL , or Download the image from the website to your host machine; AVA Developer Platform Downloads \u2013 I-Pi SMARC ( Yocto with SOAFEE is preferred.) Flash yocto image # Remove M.2 SSD from AVA platform and flash yocto image to it directly. Remove M.2 SSD from AVA platform. Install M.2 SSD into a M.2 enclosure case. Plug it into your host machine. Then, show available block devices. lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT ... sdn 8:208 0 119.2G 0 disk \u251c\u2500sdn1 8:209 0 512M 0 part \u251c\u2500sdn2 8:210 0 1G 0 part /media/foo/7d00c690-db24-462d-8c8d-dce7bdf151d8 \u2514\u2500sdn3 8:211 0 117.8G 0 part Flush yocto image to M.2 SSD. For example sudo dd if=ewaol-image-docker-comhpc-20211022083723.rootfs.wic of=/dev/sdn bs=1M status=progress && sync Extend rootfs partition # You have to extend rootfs partition. Follow the instructions Extend rootfs partition Reinstall SSD # Remove M.2 SSD from enclosure case and install it into AVA platform, then turn it on. The following screen comes up, then login as root without password. EWAOL (Edge Workload Abstraction and Orchestration Layer) 0.1 comhpc tty1 comhpc login: You are able to access via SSH.","title":"Boot EWAOL via SSD Boot"},{"location":"version-1.0/start-guide/installation/boot-ewaol/#boot-ewaol-via-ssd-boot","text":"","title":"Boot EWAOL via SSD Boot"},{"location":"version-1.0/start-guide/installation/boot-ewaol/#overview","text":"You need to use SSD enclosure case to flash yocto image to M.2 SSD directly.","title":"Overview"},{"location":"version-1.0/start-guide/installation/boot-ewaol/#get-yocto-image","text":"Build yocto image with EWAOL by following the instructions Getting started with EWAOL , or Download the image from the website to your host machine; AVA Developer Platform Downloads \u2013 I-Pi SMARC ( Yocto with SOAFEE is preferred.)","title":"Get yocto image"},{"location":"version-1.0/start-guide/installation/boot-ewaol/#flash-yocto-image","text":"Remove M.2 SSD from AVA platform and flash yocto image to it directly. Remove M.2 SSD from AVA platform. Install M.2 SSD into a M.2 enclosure case. Plug it into your host machine. Then, show available block devices. lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT ... sdn 8:208 0 119.2G 0 disk \u251c\u2500sdn1 8:209 0 512M 0 part \u251c\u2500sdn2 8:210 0 1G 0 part /media/foo/7d00c690-db24-462d-8c8d-dce7bdf151d8 \u2514\u2500sdn3 8:211 0 117.8G 0 part Flush yocto image to M.2 SSD. For example sudo dd if=ewaol-image-docker-comhpc-20211022083723.rootfs.wic of=/dev/sdn bs=1M status=progress && sync","title":"Flash yocto image"},{"location":"version-1.0/start-guide/installation/boot-ewaol/#extend-rootfs-partition","text":"You have to extend rootfs partition. Follow the instructions Extend rootfs partition","title":"Extend rootfs partition"},{"location":"version-1.0/start-guide/installation/boot-ewaol/#reinstall-ssd","text":"Remove M.2 SSD from enclosure case and install it into AVA platform, then turn it on. The following screen comes up, then login as root without password. EWAOL (Edge Workload Abstraction and Orchestration Layer) 0.1 comhpc tty1 comhpc login: You are able to access via SSH.","title":"Reinstall SSD"},{"location":"version-1.0/start-guide/installation/extend-rootfs/","text":"Extend rootfs partition # Overview # The rootfs partition is created with 5.2GB, but the size is too short to run docker container. So we have to extend rootfs partition, or create new partition and assign the whole docker folder to the new partition. Here is the instruction how to extend rootfs partition Extend rootfs # Run gparted . You may get the following warning when you run gparted . Press Fix . Contents of storage after we flashed yocto image to M.2 SSD. Unmount partitions. To manipulate partitions, you need to unmount root and data partition. Right click root partition, then click Unmount . Unmount data partition as well. Move data partition to the end of storage. Right click data partition, then click Resize/Move . Drag the square to the right end. Then, click Resize/Move . Click OK . Extend rootfs partition to the end of disk. Right click root partition, then click Resize/Move . Extend the square to the right end. Then, click Resize/Move . Apply changes. Click check mark icon. Click Apply . You can get rootfs as follows.","title":"Extend rootfs partition"},{"location":"version-1.0/start-guide/installation/extend-rootfs/#extend-rootfs-partition","text":"","title":"Extend rootfs partition"},{"location":"version-1.0/start-guide/installation/extend-rootfs/#overview","text":"The rootfs partition is created with 5.2GB, but the size is too short to run docker container. So we have to extend rootfs partition, or create new partition and assign the whole docker folder to the new partition. Here is the instruction how to extend rootfs partition","title":"Overview"},{"location":"version-1.0/start-guide/installation/extend-rootfs/#extend-rootfs","text":"Run gparted . You may get the following warning when you run gparted . Press Fix . Contents of storage after we flashed yocto image to M.2 SSD. Unmount partitions. To manipulate partitions, you need to unmount root and data partition. Right click root partition, then click Unmount . Unmount data partition as well. Move data partition to the end of storage. Right click data partition, then click Resize/Move . Drag the square to the right end. Then, click Resize/Move . Click OK . Extend rootfs partition to the end of disk. Right click root partition, then click Resize/Move . Extend the square to the right end. Then, click Resize/Move . Apply changes. Click check mark icon. Click Apply . You can get rootfs as follows.","title":"Extend rootfs"},{"location":"version-1.0/start-guide/installation/getting-started-pcu/","text":"Getting started with PCU # Overview # Reference: PCU Setup Guide This instruction explains how to boot up Ubuntu on PCU and access it from host PC. If you are using onboard 64G EMMC as boot device, it's already been pre-installed with Ubuntu 20.04, and you can skip this step; If you would like to boot from SD card, you could either request a Micro SD card with pre-installed system or flash by yourself under instructions in below section. Ubuntu 20.04 is preferred. Hardware Setup # The minimum recommended External Micro SD card size is 64GB, and the speed should be at least class 10 A1, it is strongly recommended to use high speed SD card, e.g. class U3, A2. To boot from SD card, \"SW1\" should be set as: ON , and SD card should be plugged in. For blank SD card, the system image need to be flashed first using another PC. Get MPU image # Official images with recommended OS are available on PCU Resource Download page. Resource Download Page For PCU 2.0 hardware, please download the MPU image file for SD card as marked red to your local storage. Flash MPU image # To flash MPU image on SD card, you will need a PC with a micro SD card reader. This step could be done on either Windows or Linux PC with different flash tools. Linux will be used in this instruction as example: Insert card reader with target micro SD card to host PC. Find out device name for the SD card. sudo lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT ... sda 8:0 0 238.5G 0 disk \u251c\u2500sda1 8:1 0 512M 0 part /boot/efi \u2514\u2500sda2 8:2 0 238G 0 part / sdb 8:16 0 447.1G 0 disk \u251c\u2500sdb1 8:17 0 428.4G 0 part \u251c\u2500sdb2 8:18 0 513M 0 part \u2514\u2500sdb3 8:19 0 18.2G 0 part sdc 8:32 1 14.9G 0 disk \u2514\u2500sdc1 8:33 1 14.9G 0 part /media/adlink/B4A1-62CD In this case, sdc is the device name Flash image to SD card. sudo gzip -dc YOUR-DOWNLOAD-PATH/xxx.gz |sudo dd of=/dev/YOUR-DEVICE For example; sudo gzip -dc ~/Downloads/autocore-1046-ubuntu20.04-sd-pcu2.0-sw0.5.0-20201210.gz |sudo dd of=/dev/sdc Wait patiently until the flash process finishes, this may take up to half hour. Boot up. Now you can plug in the SD card to PCU and power up. The system should be ready to work. Connect To PCU via SSH # You could connect to PCU via SSh either by ethernet or serial port. The default username, password and IP address of PCU is as below: SSH through ethernet # Cable connection Connect host PC to RJ45 2 / RJ45 3 / RJ45 4 Eth port (Blue) on PCU board with Ethernet cable (GbE, need Cat.5e or above). Configure static IP for host PC You need to manually configure static IP for PC in order to connect with PCU, as there is no DHCP server running on PCU. The static IP should be different with PCU and within the same network segment. (e.g. 192.168.1.200) SSH login ssh user@192.168.1.239 SSH through Serial Port # Cable connection As an alternative, you could also choose to connect to PCU by micro USB (ttyUSB port in figure blow). ttyUSB Settings For Linux users, you could use \"cutecom\" to connect to PCU. sudo apt install cutecom cutecom Please set parameters as follows, Device shall be chosen based on your host PC. For other system users, the parameters are: Parameter Value Baudrate 115200 Data 8 Stop bit 1 Parity None Hardware flow control no Software flow control no Reset PCU and Login Press reset button and wait until login. ssh user@192.168.1.239 Check PCU public IP Address # Connect PCU to internet via RJ45 1 Eth port (Red), this Eth port is configured to obtain IP address automatically from DHCP by default. From section above, you can SSH connect to PCU, and you can look for IP address of the public ethernet port(fm1-mac5). ifconfig fm1-mac5 fm1-mac5: flags=4163 mtu 1500 inet 192.168.10.221 netmask 255.255.255.0 broadcast 192.168.10.255 inet6 fe80::204:7cff:fe2e:191 prefixlen 64 scopeid 0x20 ether 00:04:7c:2e:01:91 txqueuelen 1000 (Ethernet) RX packets 2806 bytes 3665212 (3.6 MB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 2238 bytes 175964 (175.9 KB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 device memory 0x1ae8000-1ae8fff You can find IP address of PCU such as 192.168.10.221 .","title":"Getting started with PCU"},{"location":"version-1.0/start-guide/installation/getting-started-pcu/#getting-started-with-pcu","text":"","title":"Getting started with PCU"},{"location":"version-1.0/start-guide/installation/getting-started-pcu/#overview","text":"Reference: PCU Setup Guide This instruction explains how to boot up Ubuntu on PCU and access it from host PC. If you are using onboard 64G EMMC as boot device, it's already been pre-installed with Ubuntu 20.04, and you can skip this step; If you would like to boot from SD card, you could either request a Micro SD card with pre-installed system or flash by yourself under instructions in below section. Ubuntu 20.04 is preferred.","title":"Overview"},{"location":"version-1.0/start-guide/installation/getting-started-pcu/#hardware-setup","text":"The minimum recommended External Micro SD card size is 64GB, and the speed should be at least class 10 A1, it is strongly recommended to use high speed SD card, e.g. class U3, A2. To boot from SD card, \"SW1\" should be set as: ON , and SD card should be plugged in. For blank SD card, the system image need to be flashed first using another PC.","title":"Hardware Setup"},{"location":"version-1.0/start-guide/installation/getting-started-pcu/#get-mpu-image","text":"Official images with recommended OS are available on PCU Resource Download page. Resource Download Page For PCU 2.0 hardware, please download the MPU image file for SD card as marked red to your local storage.","title":"Get MPU image"},{"location":"version-1.0/start-guide/installation/getting-started-pcu/#flash-mpu-image","text":"To flash MPU image on SD card, you will need a PC with a micro SD card reader. This step could be done on either Windows or Linux PC with different flash tools. Linux will be used in this instruction as example: Insert card reader with target micro SD card to host PC. Find out device name for the SD card. sudo lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT ... sda 8:0 0 238.5G 0 disk \u251c\u2500sda1 8:1 0 512M 0 part /boot/efi \u2514\u2500sda2 8:2 0 238G 0 part / sdb 8:16 0 447.1G 0 disk \u251c\u2500sdb1 8:17 0 428.4G 0 part \u251c\u2500sdb2 8:18 0 513M 0 part \u2514\u2500sdb3 8:19 0 18.2G 0 part sdc 8:32 1 14.9G 0 disk \u2514\u2500sdc1 8:33 1 14.9G 0 part /media/adlink/B4A1-62CD In this case, sdc is the device name Flash image to SD card. sudo gzip -dc YOUR-DOWNLOAD-PATH/xxx.gz |sudo dd of=/dev/YOUR-DEVICE For example; sudo gzip -dc ~/Downloads/autocore-1046-ubuntu20.04-sd-pcu2.0-sw0.5.0-20201210.gz |sudo dd of=/dev/sdc Wait patiently until the flash process finishes, this may take up to half hour. Boot up. Now you can plug in the SD card to PCU and power up. The system should be ready to work.","title":"Flash MPU image"},{"location":"version-1.0/start-guide/installation/getting-started-pcu/#connect-to-pcu-via-ssh","text":"You could connect to PCU via SSh either by ethernet or serial port. The default username, password and IP address of PCU is as below:","title":"Connect To PCU via SSH"},{"location":"version-1.0/start-guide/installation/getting-started-pcu/#ssh-through-ethernet","text":"Cable connection Connect host PC to RJ45 2 / RJ45 3 / RJ45 4 Eth port (Blue) on PCU board with Ethernet cable (GbE, need Cat.5e or above). Configure static IP for host PC You need to manually configure static IP for PC in order to connect with PCU, as there is no DHCP server running on PCU. The static IP should be different with PCU and within the same network segment. (e.g. 192.168.1.200) SSH login ssh user@192.168.1.239","title":"SSH through ethernet"},{"location":"version-1.0/start-guide/installation/getting-started-pcu/#ssh-through-serial-port","text":"Cable connection As an alternative, you could also choose to connect to PCU by micro USB (ttyUSB port in figure blow). ttyUSB Settings For Linux users, you could use \"cutecom\" to connect to PCU. sudo apt install cutecom cutecom Please set parameters as follows, Device shall be chosen based on your host PC. For other system users, the parameters are: Parameter Value Baudrate 115200 Data 8 Stop bit 1 Parity None Hardware flow control no Software flow control no Reset PCU and Login Press reset button and wait until login. ssh user@192.168.1.239","title":"SSH through Serial Port"},{"location":"version-1.0/start-guide/installation/getting-started-pcu/#check-pcu-public-ip-address","text":"Connect PCU to internet via RJ45 1 Eth port (Red), this Eth port is configured to obtain IP address automatically from DHCP by default. From section above, you can SSH connect to PCU, and you can look for IP address of the public ethernet port(fm1-mac5). ifconfig fm1-mac5 fm1-mac5: flags=4163 mtu 1500 inet 192.168.10.221 netmask 255.255.255.0 broadcast 192.168.10.255 inet6 fe80::204:7cff:fe2e:191 prefixlen 64 scopeid 0x20 ether 00:04:7c:2e:01:91 txqueuelen 1000 (Ethernet) RX packets 2806 bytes 3665212 (3.6 MB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 2238 bytes 175964 (175.9 KB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 device memory 0x1ae8000-1ae8fff You can find IP address of PCU such as 192.168.10.221 .","title":"Check PCU public IP Address"},{"location":"version-1.0/start-guide/installation/getting-started/","text":"Getting started with EWAOL # Overview # Reference: Project Quickstart \u2014 EWAOL documentation This instruction explain how to build yocto image with EWAOL on your host machine. If you are using AVA Developer Platform , you can also download built image from ADLINK's website, and you can skip this steps; AVA Developer Platform Downloads \u2013 I-Pi SMARC Yocto with SOAFEE is preferred. Build Host Setup # Install required packages for the build host by following The Yocto Project \u00ae 3.3.1 documentation . sudo apt-get install gawk wget git diffstat unzip texinfo gcc build-essential chrpath socat cpio python3 python3-pip python3-pexpect xz-utils debianutils iputils-ping python3-git python3-jinja2 libegl1-mesa libsdl1.2-dev pylint3 xterm python3-subunit mesa-common-dev Install the kas setup tool. sudo -H pip3 install kas Checkout the repository for AVA platform # ADLINK / meta-adlink-ampere git clone https://github.com/ADLINK/meta-adlink-ampere.git EWAOL / meta-ewaol cd meta-adlink-ampere git clone https://git.gitlab.arm.com/ewaol/meta-ewaol.git Build via kas kas build ComHpc.yml You should be careful of utilizing full CPU power during build. You can choose the way to boot EWAOL, SSD Boot(highly recommended) or USB Boot. SSD Boot (highly recommended) You need to use SSD enclosure case to flash yocto image to M.2 SSD directly. USB Boot You need to use 32GB USB, not 64GB USB to flash yocto image. Do not use 64GB USB because bios gets stuck due to EDK II bug.","title":"Getting started with EWAOL"},{"location":"version-1.0/start-guide/installation/getting-started/#getting-started-with-ewaol","text":"","title":"Getting started with EWAOL"},{"location":"version-1.0/start-guide/installation/getting-started/#overview","text":"Reference: Project Quickstart \u2014 EWAOL documentation This instruction explain how to build yocto image with EWAOL on your host machine. If you are using AVA Developer Platform , you can also download built image from ADLINK's website, and you can skip this steps; AVA Developer Platform Downloads \u2013 I-Pi SMARC Yocto with SOAFEE is preferred.","title":"Overview"},{"location":"version-1.0/start-guide/installation/getting-started/#build-host-setup","text":"Install required packages for the build host by following The Yocto Project \u00ae 3.3.1 documentation . sudo apt-get install gawk wget git diffstat unzip texinfo gcc build-essential chrpath socat cpio python3 python3-pip python3-pexpect xz-utils debianutils iputils-ping python3-git python3-jinja2 libegl1-mesa libsdl1.2-dev pylint3 xterm python3-subunit mesa-common-dev Install the kas setup tool. sudo -H pip3 install kas","title":"Build Host Setup"},{"location":"version-1.0/start-guide/installation/getting-started/#checkout-the-repository-for-ava-platform","text":"ADLINK / meta-adlink-ampere git clone https://github.com/ADLINK/meta-adlink-ampere.git EWAOL / meta-ewaol cd meta-adlink-ampere git clone https://git.gitlab.arm.com/ewaol/meta-ewaol.git Build via kas kas build ComHpc.yml You should be careful of utilizing full CPU power during build. You can choose the way to boot EWAOL, SSD Boot(highly recommended) or USB Boot. SSD Boot (highly recommended) You need to use SSD enclosure case to flash yocto image to M.2 SSD directly. USB Boot You need to use 32GB USB, not 64GB USB to flash yocto image. Do not use 64GB USB because bios gets stuck due to EDK II bug.","title":"Checkout the repository for AVA platform"},{"location":"version-1.0/start-guide/installation/system-setup-ava/","text":"System Setup on AVA platform # Overview # This instruction explains how to perform system setup for test execution on AVA platform. You need to copy docker images and necessary files. Access to AVA platform via SSH # ssh root@IP-ADDRESS For example; ssh root@192.168.10.27 Copy Autoware.Auto image to AVA platform # The docker image of Autoware.Auto is registered in GitLab Container Registry . Copy docker image to AVA platform. docker pull registry.gitlab.com/autowarefoundation/autoware.auto/autowareauto/arm64/openadkit-foxy:latest Copy necessary files to USB drive # Copy files related to map contents . Files are placed in the directory docs/Appendix/Open-AD-Kit-Start-Guide/map lanelet2_map.osm pointcloud_map.pcd global_map_center.pcd.yaml lanelet2_map_provider.osm.yaml map_publisher.param.yaml Copy files to your USB drive as the following directory structure. Copy configuration file of Cyclone DDS . In this test, we are using Cyclone DDS, so you also need to copy configuration file of Cyclone DDS. File is placed in the directory docs/Appendix/Open-AD-Kit-Start-Guide/cyclonedds cyclonedds.xml Copy the file to your USB drive as the following directory structure. Copy kernel configuration file for tuning kernel parameters. We have to reconfigure kernel parameters by using sysctl for system stability. File is placed in the directory docs/Appendix/Open-AD-Kit-Start-Guide/sysctl.d 60_cyclonedds.conf Copy the file to your USB root. Copy files from USB drive to AVA platform # Plug your USB drive into AVA platform and copy files Find USB device name. lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:16 1 28.9G 0 disk `-sda1 8:17 1 28.9G 0 part nvme0n1 259:0 0 119.2G 0 disk |-nvme0n1p1 259:1 0 256M 0 part |-nvme0n1p2 259:2 0 118G 0 part / `-nvme0n1p3 259:3 0 1G 0 part Mount USB driver and copy directory. mkdir -p /mnt/usb mount /dev/sda1 /mnt/usb cp -r /mnt/usb/* ~/ Move kernel configuration file to /etc/sysctl.d . mv ~/60_cyclonedds.conf /etc/sysctl.d Update kernel parameters. sysctl -p /etc/sysctl.d/60_cyclonedds.conf Modify cyclonedds.xml # You need to change the element NetworkInterfaceAddress to the network interface currently in use. Find network interface. ip addr 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: enP4p4s0: mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 00:11:22:33:44:55 brd ff:ff:ff:ff:ff:ff inet 192.168.10.27/24 brd 192.168.10.255 scope global dynamic enP4p4s0 valid_lft 332sec preferred_lft 332sec inet 192.168.10.13/24 brd 192.168.10.255 scope global secondary dynamic noprefixroute enP4p4s0 valid_lft 337sec preferred_lft 262sec inet6 fe80::34c:b6f7:b356:b7/64 scope link valid_lft forever preferred_lft forever inet6 fe80::230:64ff:fe1a:a65/64 scope link valid_lft forever preferred_lft forever 3: docker0: mtu 1500 qdisc noqueue state DOWN group default link/ether aa:bb:cc:dd:ee:ff brd ff:ff:ff:ff:ff:ff inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0 valid_lft forever preferred_lft forever You can find a network interface such as enP4p4s0 . Change the NetworkInterfaceAddress . vi ~/cyclonedds/cyclonedds.xml For example; cyclonedds.xml - lo + enP4p4s0 ","title":"System Setup on AVA platform"},{"location":"version-1.0/start-guide/installation/system-setup-ava/#system-setup-on-ava-platform","text":"","title":"System Setup on AVA platform"},{"location":"version-1.0/start-guide/installation/system-setup-ava/#overview","text":"This instruction explains how to perform system setup for test execution on AVA platform. You need to copy docker images and necessary files.","title":"Overview"},{"location":"version-1.0/start-guide/installation/system-setup-ava/#access-to-ava-platform-via-ssh","text":"ssh root@IP-ADDRESS For example; ssh root@192.168.10.27","title":"Access to AVA platform via SSH"},{"location":"version-1.0/start-guide/installation/system-setup-ava/#copy-autowareauto-image-to-ava-platform","text":"The docker image of Autoware.Auto is registered in GitLab Container Registry . Copy docker image to AVA platform. docker pull registry.gitlab.com/autowarefoundation/autoware.auto/autowareauto/arm64/openadkit-foxy:latest","title":"Copy Autoware.Auto image to AVA platform"},{"location":"version-1.0/start-guide/installation/system-setup-ava/#copy-necessary-files-to-usb-drive","text":"Copy files related to map contents . Files are placed in the directory docs/Appendix/Open-AD-Kit-Start-Guide/map lanelet2_map.osm pointcloud_map.pcd global_map_center.pcd.yaml lanelet2_map_provider.osm.yaml map_publisher.param.yaml Copy files to your USB drive as the following directory structure. Copy configuration file of Cyclone DDS . In this test, we are using Cyclone DDS, so you also need to copy configuration file of Cyclone DDS. File is placed in the directory docs/Appendix/Open-AD-Kit-Start-Guide/cyclonedds cyclonedds.xml Copy the file to your USB drive as the following directory structure. Copy kernel configuration file for tuning kernel parameters. We have to reconfigure kernel parameters by using sysctl for system stability. File is placed in the directory docs/Appendix/Open-AD-Kit-Start-Guide/sysctl.d 60_cyclonedds.conf Copy the file to your USB root.","title":"Copy necessary files to USB drive"},{"location":"version-1.0/start-guide/installation/system-setup-ava/#copy-files-from-usb-drive-to-ava-platform","text":"Plug your USB drive into AVA platform and copy files Find USB device name. lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:16 1 28.9G 0 disk `-sda1 8:17 1 28.9G 0 part nvme0n1 259:0 0 119.2G 0 disk |-nvme0n1p1 259:1 0 256M 0 part |-nvme0n1p2 259:2 0 118G 0 part / `-nvme0n1p3 259:3 0 1G 0 part Mount USB driver and copy directory. mkdir -p /mnt/usb mount /dev/sda1 /mnt/usb cp -r /mnt/usb/* ~/ Move kernel configuration file to /etc/sysctl.d . mv ~/60_cyclonedds.conf /etc/sysctl.d Update kernel parameters. sysctl -p /etc/sysctl.d/60_cyclonedds.conf","title":"Copy files from USB drive to AVA platform"},{"location":"version-1.0/start-guide/installation/system-setup-ava/#modify-cycloneddsxml","text":"You need to change the element NetworkInterfaceAddress to the network interface currently in use. Find network interface. ip addr 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: enP4p4s0: mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 00:11:22:33:44:55 brd ff:ff:ff:ff:ff:ff inet 192.168.10.27/24 brd 192.168.10.255 scope global dynamic enP4p4s0 valid_lft 332sec preferred_lft 332sec inet 192.168.10.13/24 brd 192.168.10.255 scope global secondary dynamic noprefixroute enP4p4s0 valid_lft 337sec preferred_lft 262sec inet6 fe80::34c:b6f7:b356:b7/64 scope link valid_lft forever preferred_lft forever inet6 fe80::230:64ff:fe1a:a65/64 scope link valid_lft forever preferred_lft forever 3: docker0: mtu 1500 qdisc noqueue state DOWN group default link/ether aa:bb:cc:dd:ee:ff brd ff:ff:ff:ff:ff:ff inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0 valid_lft forever preferred_lft forever You can find a network interface such as enP4p4s0 . Change the NetworkInterfaceAddress . vi ~/cyclonedds/cyclonedds.xml For example; cyclonedds.xml - lo + enP4p4s0 ","title":"Modify cyclonedds.xml"},{"location":"version-1.0/start-guide/installation/system-setup-host/","text":"System Setup on your host # Overview # This instruction explains how to perform system setup for test execution on your host. You need to copy docker images and necessary files, and checkout Autoware.Auto. Copy scenario simulator image to your host machine # The docker image of scenario simulator is registered in docker hub . Copy docker image to your host machine. docker pull tier4/scenario_simulator_v2:open_ad_kit-amd64-foxy Copy necessary files to your host machine # Copy scenario files for scenario simulator. Files are placed in the directory docs/Appendix/Open-AD-Kit-Start-Guide/scenario [Currently placed] UC-001-0001-Kashiwa:2 UC-001-0018-Kashiwa:1 Copy the scenario files to your home directory as the following directory structure. Copy configuration file of Cyclone DDS . You also need to copy cyclonedds.xml to your home directory. Copy kernel configuration file to /etc/sysctl.d . You also need to copy 60_cyclonedds.conf to /etc/sysctl.d directory in your host as well. cp 60_cyclonedds.conf /etc/sysctl.d Update kernel parameters. sysctl -p /etc/sysctl.d/60_cyclonedds.conf Modify cyclonedds.xml # You need to change the element NetworkInterfaceAddress to the network interface currently in use. Find network interface. ip addr 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: enp0s31f6: mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 66:77:88:99:aa:bb brd ff:ff:ff:ff:ff:ff inet 192.168.10.1/24 brd 192.168.10.255 scope global noprefixroute enp0s31f6 valid_lft forever preferred_lft forever inet6 fe80::f15d:4196:b777:6875/64 scope link noprefixroute valid_lft forever preferred_lft forever 3: wlp82s0: mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether cc:dd:ee:ff:00:01 brd ff:ff:ff:ff:ff:ff inet 192.168.0.28/24 brd 192.168.0.255 scope global dynamic noprefixroute wlp82s0 valid_lft 3137sec preferred_lft 3137sec inet6 fe80::f493:f223:dfcc:bd1b/64 scope link noprefixroute valid_lft forever preferred_lft forever 4: docker0: mtu 1500 qdisc noqueue state DOWN group default link/ether 23:45:67:89:ab:cd brd ff:ff:ff:ff:ff:ff inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0 valid_lft forever preferred_lft forever You can find a network interface such as enp0s31f6 . Change the NetworkInterfaceAddress . vi ~/cyclonedds/cyclonedds.xml For example; cyclonedds.xml - lo + enp0s31f6 Setup ADE # In general, Autoware.Auto runs by using the Agile Development Environment (ADE), so we need to install ADE. In this test, we use launch file placed in Autoware.Auto to run visualization quickly and easily. Install ADE on AVA platform by following the instructions; Installation \u2014 ADE 4.4.0dev documentation Download and setup ADE. wget https://gitlab.com/ApexAI/ade-cli/-/jobs/1341322852/artifacts/raw/dist/ade+aarch64 -O ade chmod +x ade mv ade /usr/bin/ Setup ADE home directory by following the instructions; Installation with ADE mkdir -p ~/adehome cd ~/adehome touch .adehome Checkout Autoware.Auto # Get Autoware.Auto on your host. cd ~/adehome git clone https://gitlab.com/autowarefoundation/autoware.auto/AutowareAuto.git","title":"System Setup on your host"},{"location":"version-1.0/start-guide/installation/system-setup-host/#system-setup-on-your-host","text":"","title":"System Setup on your host"},{"location":"version-1.0/start-guide/installation/system-setup-host/#overview","text":"This instruction explains how to perform system setup for test execution on your host. You need to copy docker images and necessary files, and checkout Autoware.Auto.","title":"Overview"},{"location":"version-1.0/start-guide/installation/system-setup-host/#copy-scenario-simulator-image-to-your-host-machine","text":"The docker image of scenario simulator is registered in docker hub . Copy docker image to your host machine. docker pull tier4/scenario_simulator_v2:open_ad_kit-amd64-foxy","title":"Copy scenario simulator image to your host machine"},{"location":"version-1.0/start-guide/installation/system-setup-host/#copy-necessary-files-to-your-host-machine","text":"Copy scenario files for scenario simulator. Files are placed in the directory docs/Appendix/Open-AD-Kit-Start-Guide/scenario [Currently placed] UC-001-0001-Kashiwa:2 UC-001-0018-Kashiwa:1 Copy the scenario files to your home directory as the following directory structure. Copy configuration file of Cyclone DDS . You also need to copy cyclonedds.xml to your home directory. Copy kernel configuration file to /etc/sysctl.d . You also need to copy 60_cyclonedds.conf to /etc/sysctl.d directory in your host as well. cp 60_cyclonedds.conf /etc/sysctl.d Update kernel parameters. sysctl -p /etc/sysctl.d/60_cyclonedds.conf","title":"Copy necessary files to your host machine"},{"location":"version-1.0/start-guide/installation/system-setup-host/#modify-cycloneddsxml","text":"You need to change the element NetworkInterfaceAddress to the network interface currently in use. Find network interface. ip addr 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: enp0s31f6: mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 66:77:88:99:aa:bb brd ff:ff:ff:ff:ff:ff inet 192.168.10.1/24 brd 192.168.10.255 scope global noprefixroute enp0s31f6 valid_lft forever preferred_lft forever inet6 fe80::f15d:4196:b777:6875/64 scope link noprefixroute valid_lft forever preferred_lft forever 3: wlp82s0: mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether cc:dd:ee:ff:00:01 brd ff:ff:ff:ff:ff:ff inet 192.168.0.28/24 brd 192.168.0.255 scope global dynamic noprefixroute wlp82s0 valid_lft 3137sec preferred_lft 3137sec inet6 fe80::f493:f223:dfcc:bd1b/64 scope link noprefixroute valid_lft forever preferred_lft forever 4: docker0: mtu 1500 qdisc noqueue state DOWN group default link/ether 23:45:67:89:ab:cd brd ff:ff:ff:ff:ff:ff inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0 valid_lft forever preferred_lft forever You can find a network interface such as enp0s31f6 . Change the NetworkInterfaceAddress . vi ~/cyclonedds/cyclonedds.xml For example; cyclonedds.xml - lo + enp0s31f6 ","title":"Modify cyclonedds.xml"},{"location":"version-1.0/start-guide/installation/system-setup-host/#setup-ade","text":"In general, Autoware.Auto runs by using the Agile Development Environment (ADE), so we need to install ADE. In this test, we use launch file placed in Autoware.Auto to run visualization quickly and easily. Install ADE on AVA platform by following the instructions; Installation \u2014 ADE 4.4.0dev documentation Download and setup ADE. wget https://gitlab.com/ApexAI/ade-cli/-/jobs/1341322852/artifacts/raw/dist/ade+aarch64 -O ade chmod +x ade mv ade /usr/bin/ Setup ADE home directory by following the instructions; Installation with ADE mkdir -p ~/adehome cd ~/adehome touch .adehome","title":"Setup ADE"},{"location":"version-1.0/start-guide/installation/system-setup-host/#checkout-autowareauto","text":"Get Autoware.Auto on your host. cd ~/adehome git clone https://gitlab.com/autowarefoundation/autoware.auto/AutowareAuto.git","title":"Checkout Autoware.Auto"},{"location":"version-1.0/start-guide/installation/system-setup-pcu/","text":"System Setup on PCU # Overview # This instruction explains how to perform system setup for test execution on PCU. You need to install Docker Engine, copy docker images and necessary files. Access to PCU via SSH # ssh user@IP-ADDRESS For example; ssh user@192.168.10.221 Copy Autoware.Auto image to PCU # NOTE : docker should be installed with post-installation steps. For instructions please refer to: Install Docker Engine on Ubuntu . Post-installation steps for Linux . The docker image of Autoware.Auto is registered in GitLab Container Registry . Copy docker image to PCU. docker pull registry.gitlab.com/autowarefoundation/autoware.auto/autowareauto/arm64/openadkit-foxy:latest Copy necessary files to local Downloads folder # Copy files related to map contents . Files are placed in the directory docs/Appendix/Open-AD-Kit-Start-Guide/map lanelet2_map.osm pointcloud_map.pcd global_map_center.pcd.yaml lanelet2_map_provider.osm.yaml map_publisher.param.yaml Copy files to your local folder (Downloads folder as example) as the following directory structure. Copy configuration file of Cyclone DDS . In this test, we are using Cyclone DDS, so you also need to copy configuration file of Cyclone DDS. File is placed in the directory docs/Appendix/Open-AD-Kit-Start-Guide/cyclonedds cyclonedds.xml Copy the file to your local folder as the following directory structure. Copy kernel configuration file for tuning kernel parameters. We have to reconfigure kernel parameters by using sysctl for system stability. File is placed in the directory docs/Appendix/Open-AD-Kit-Start-Guide/sysctl.d 60_cyclonedds.conf Copy the file to your local folder. Copy files from local folder to PCU # Connect your host PC with PCU through internet and copy files with SCP. Access to PCU via SSH For example; ssh user@192.168.10.221 Copy kernel configuration file to /etc/sysctl.d/ sudo scp USER-NAME@IP-ADDRESS:/home/USER-NAME/Downloads/60_cyclonedds.conf /etc/sysctl.d/ For example; sudo scp adlink@192.168.10.237:/home/adlink/Downloads/60_cyclonedds.conf /etc/sysctl.d/ Then type in the password of PCU (default password: user) and host PC as request. Update kernel parameters. sudo sysctl -p /etc/sysctl.d/60_cyclonedds.conf Copy map contents files and Cyclone DDS configuration file. sudo scp -r USER-NAME@IP-ADDRESS:/home/adlink/Downloads/map ~/ sudo scp -r USER-NAME@IP-ADDRESS:/home/adlink/Downloads/cyclonedds ~/ Modify cyclonedds.xml # You need to change the element NetworkInterfaceAddress to the network interface currently in use. Find network interface. ip addr 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: fm1-mac1: mtu 1500 qdisc mq master br0 state DOWN group default qlen 1000 link/ether 00:04:7c:2e:01:90 brd ff:ff:ff:ff:ff:ff inet6 fe80::204:7cff:fe2e:190/64 scope link valid_lft forever preferred_lft forever 3: fm1-mac5: mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 00:04:7c:2e:01:91 brd ff:ff:ff:ff:ff:ff inet 192.168.10.221/24 brd 192.168.10.255 scope global dynamic fm1-mac5 valid_lft 254392sec preferred_lft 254392sec inet6 fe80::204:7cff:fe2e:191/64 scope link valid_lft forever preferred_lft forever 4: fm1-mac6: mtu 1500 qdisc mq master br0 state DOWN group default qlen 1000 link/ether 00:04:7c:2e:01:90 brd ff:ff:ff:ff:ff:ff 5: fm1-sw: mtu 1500 qdisc mq master br0 state UP group default qlen 1000 link/ether 00:04:7c:2e:01:90 brd ff:ff:ff:ff:ff:ff inet6 fe80::204:7cff:fe2e:190/64 scope link valid_lft forever preferred_lft forever 6: fm1-mac10: mtu 1500 qdisc mq master br0 state DOWN group default qlen 1000 link/ether 00:04:7c:2e:01:90 brd ff:ff:ff:ff:ff:ff 7: sit0@NONE: mtu 1480 qdisc noop state DOWN group default qlen 1000 link/sit 0.0.0.0 brd 0.0.0.0 8: br0: mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether 00:04:7c:2e:01:90 brd ff:ff:ff:ff:ff:ff inet 192.168.1.239/24 brd 192.168.1.255 scope global br0 valid_lft forever preferred_lft forever inet6 fe80::204:7cff:fe2e:190/64 scope link valid_lft forever preferred_lft forever 9: docker0: mtu 1500 qdisc noqueue state DOWN group default link/ether 02:42:cb:aa:a6:9d brd ff:ff:ff:ff:ff:ff inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0 valid_lft forever preferred_lft forever You can find a network interface such as fm1-mac5 . Change the NetworkInterfaceAddress . sudo vi ~/cyclonedds/cyclonedds.xml For example; cyclonedds.xml - lo + fm1-mac5 ","title":"System Setup on PCU"},{"location":"version-1.0/start-guide/installation/system-setup-pcu/#system-setup-on-pcu","text":"","title":"System Setup on PCU"},{"location":"version-1.0/start-guide/installation/system-setup-pcu/#overview","text":"This instruction explains how to perform system setup for test execution on PCU. You need to install Docker Engine, copy docker images and necessary files.","title":"Overview"},{"location":"version-1.0/start-guide/installation/system-setup-pcu/#access-to-pcu-via-ssh","text":"ssh user@IP-ADDRESS For example; ssh user@192.168.10.221","title":"Access to PCU via SSH"},{"location":"version-1.0/start-guide/installation/system-setup-pcu/#copy-autowareauto-image-to-pcu","text":"NOTE : docker should be installed with post-installation steps. For instructions please refer to: Install Docker Engine on Ubuntu . Post-installation steps for Linux . The docker image of Autoware.Auto is registered in GitLab Container Registry . Copy docker image to PCU. docker pull registry.gitlab.com/autowarefoundation/autoware.auto/autowareauto/arm64/openadkit-foxy:latest","title":"Copy Autoware.Auto image to PCU"},{"location":"version-1.0/start-guide/installation/system-setup-pcu/#copy-necessary-files-to-local-downloads-folder","text":"Copy files related to map contents . Files are placed in the directory docs/Appendix/Open-AD-Kit-Start-Guide/map lanelet2_map.osm pointcloud_map.pcd global_map_center.pcd.yaml lanelet2_map_provider.osm.yaml map_publisher.param.yaml Copy files to your local folder (Downloads folder as example) as the following directory structure. Copy configuration file of Cyclone DDS . In this test, we are using Cyclone DDS, so you also need to copy configuration file of Cyclone DDS. File is placed in the directory docs/Appendix/Open-AD-Kit-Start-Guide/cyclonedds cyclonedds.xml Copy the file to your local folder as the following directory structure. Copy kernel configuration file for tuning kernel parameters. We have to reconfigure kernel parameters by using sysctl for system stability. File is placed in the directory docs/Appendix/Open-AD-Kit-Start-Guide/sysctl.d 60_cyclonedds.conf Copy the file to your local folder.","title":"Copy necessary files to local Downloads folder"},{"location":"version-1.0/start-guide/installation/system-setup-pcu/#copy-files-from-local-folder-to-pcu","text":"Connect your host PC with PCU through internet and copy files with SCP. Access to PCU via SSH For example; ssh user@192.168.10.221 Copy kernel configuration file to /etc/sysctl.d/ sudo scp USER-NAME@IP-ADDRESS:/home/USER-NAME/Downloads/60_cyclonedds.conf /etc/sysctl.d/ For example; sudo scp adlink@192.168.10.237:/home/adlink/Downloads/60_cyclonedds.conf /etc/sysctl.d/ Then type in the password of PCU (default password: user) and host PC as request. Update kernel parameters. sudo sysctl -p /etc/sysctl.d/60_cyclonedds.conf Copy map contents files and Cyclone DDS configuration file. sudo scp -r USER-NAME@IP-ADDRESS:/home/adlink/Downloads/map ~/ sudo scp -r USER-NAME@IP-ADDRESS:/home/adlink/Downloads/cyclonedds ~/","title":"Copy files from local folder to PCU"},{"location":"version-1.0/start-guide/installation/system-setup-pcu/#modify-cycloneddsxml","text":"You need to change the element NetworkInterfaceAddress to the network interface currently in use. Find network interface. ip addr 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: fm1-mac1: mtu 1500 qdisc mq master br0 state DOWN group default qlen 1000 link/ether 00:04:7c:2e:01:90 brd ff:ff:ff:ff:ff:ff inet6 fe80::204:7cff:fe2e:190/64 scope link valid_lft forever preferred_lft forever 3: fm1-mac5: mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 00:04:7c:2e:01:91 brd ff:ff:ff:ff:ff:ff inet 192.168.10.221/24 brd 192.168.10.255 scope global dynamic fm1-mac5 valid_lft 254392sec preferred_lft 254392sec inet6 fe80::204:7cff:fe2e:191/64 scope link valid_lft forever preferred_lft forever 4: fm1-mac6: mtu 1500 qdisc mq master br0 state DOWN group default qlen 1000 link/ether 00:04:7c:2e:01:90 brd ff:ff:ff:ff:ff:ff 5: fm1-sw: mtu 1500 qdisc mq master br0 state UP group default qlen 1000 link/ether 00:04:7c:2e:01:90 brd ff:ff:ff:ff:ff:ff inet6 fe80::204:7cff:fe2e:190/64 scope link valid_lft forever preferred_lft forever 6: fm1-mac10: mtu 1500 qdisc mq master br0 state DOWN group default qlen 1000 link/ether 00:04:7c:2e:01:90 brd ff:ff:ff:ff:ff:ff 7: sit0@NONE: mtu 1480 qdisc noop state DOWN group default qlen 1000 link/sit 0.0.0.0 brd 0.0.0.0 8: br0: mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether 00:04:7c:2e:01:90 brd ff:ff:ff:ff:ff:ff inet 192.168.1.239/24 brd 192.168.1.255 scope global br0 valid_lft forever preferred_lft forever inet6 fe80::204:7cff:fe2e:190/64 scope link valid_lft forever preferred_lft forever 9: docker0: mtu 1500 qdisc noqueue state DOWN group default link/ether 02:42:cb:aa:a6:9d brd ff:ff:ff:ff:ff:ff inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0 valid_lft forever preferred_lft forever You can find a network interface such as fm1-mac5 . Change the NetworkInterfaceAddress . sudo vi ~/cyclonedds/cyclonedds.xml For example; cyclonedds.xml - lo + fm1-mac5 ","title":"Modify cyclonedds.xml"},{"location":"version-1.0/start-guide/installation/images/boot-ewaol/","text":"","title":"Index"},{"location":"version-1.0/system-configuration/","text":"System configuration # TODO","title":"System configuration"},{"location":"version-1.0/system-configuration/#system-configuration","text":"TODO","title":"System configuration"},{"location":"version-2.0/","text":"Open AD Kit Documentation # The latest version is 2.0, but it has not been officially released yet. About Open AD Kit # Open AD Kit aims to democratize autonomous drive (AD) systems by bringing the cloud and edge closer together. In doing so, Open AD Kit will lower the threshold for developing and deploying the Autoware software stack. For more details about the Open AD Kit project, its goals and details of the Autoware Foundation working group that oversees the project, refer to the Open AD Kit Working Group wiki . Open AD Kit documentation structure # Getting started # Start guide describes how to install, set up and run Autoware and its associated simulators on supported development platforms. System configuration describes the components that make up Open AD Kit in terms of the required hardware and software. Application example provides an actual application example for Open AD Kit that can be used as a reference for the development of other applications. Releases # version 2.0 Latest version 1.0","title":"Introduction"},{"location":"version-2.0/#open-ad-kit-documentation","text":"The latest version is 2.0, but it has not been officially released yet.","title":"Open AD Kit Documentation"},{"location":"version-2.0/#about-open-ad-kit","text":"Open AD Kit aims to democratize autonomous drive (AD) systems by bringing the cloud and edge closer together. In doing so, Open AD Kit will lower the threshold for developing and deploying the Autoware software stack. For more details about the Open AD Kit project, its goals and details of the Autoware Foundation working group that oversees the project, refer to the Open AD Kit Working Group wiki .","title":"About Open AD Kit"},{"location":"version-2.0/#open-ad-kit-documentation-structure","text":"","title":"Open AD Kit documentation structure"},{"location":"version-2.0/#getting-started","text":"Start guide describes how to install, set up and run Autoware and its associated simulators on supported development platforms. System configuration describes the components that make up Open AD Kit in terms of the required hardware and software. Application example provides an actual application example for Open AD Kit that can be used as a reference for the development of other applications.","title":"Getting started"},{"location":"version-2.0/#releases","text":"version 2.0 Latest version 1.0","title":"Releases"},{"location":"version-2.0/application-example/","text":"Application example # This page shows application examples of Open AD Kit version 2.0. TODO","title":"Application example"},{"location":"version-2.0/application-example/#application-example","text":"This page shows application examples of Open AD Kit version 2.0. TODO","title":"Application example"},{"location":"version-2.0/application-example/driverless-bus/","text":"Driverless bus # The content is a work in progress. This page provides a reference design for a passenger transportation system in the urban area. The reference design consists of the following structures: Introduction of Reference Design Concept of Operations Operational Concept Operational Environment Requirements System Requirements System Configuration Hardware Requirements Software Requirements Appendix","title":"Driverless bus"},{"location":"version-2.0/application-example/driverless-bus/#driverless-bus","text":"The content is a work in progress. This page provides a reference design for a passenger transportation system in the urban area. The reference design consists of the following structures: Introduction of Reference Design Concept of Operations Operational Concept Operational Environment Requirements System Requirements System Configuration Hardware Requirements Software Requirements Appendix","title":"Driverless bus"},{"location":"version-2.0/application-example/driverless-bus/appendix/","text":"Appendix # The content is a work in progress. What is ConOps and OpsCons? Hardware List","title":"Appendix"},{"location":"version-2.0/application-example/driverless-bus/appendix/#appendix","text":"The content is a work in progress. What is ConOps and OpsCons? Hardware List","title":"Appendix"},{"location":"version-2.0/application-example/driverless-bus/appendix/hardware-list/","text":"Hardware List # The content is a work in progress. This page should show applicable hardwares for the system.","title":"Hardware List"},{"location":"version-2.0/application-example/driverless-bus/appendix/hardware-list/#hardware-list","text":"The content is a work in progress. This page should show applicable hardwares for the system.","title":"Hardware List"},{"location":"version-2.0/application-example/driverless-bus/appendix/what-is-conops-and-opscon/","text":"What is ConOps and OpsCons? # Concept of Operations (ConOps) : \u201c... the ConOps describes the overall high-level concept of how the system will be used to meet stakeholder expectations, usually in a time-sequenced manner\u2026\u201d, source NASA Systems Engineering Handbook In short, it describes how the system achieves the user\u2019s mission with a picture and short sentences. Operational Concept (OpsCon) : \u201cThe operational concept is designed to give an overall picture of the operations using one or more specific systems, or set of related systems, in the organization\u2019s operational environment from the users\u2019 and operators\u2019 perspective.\u201d, source SEBoK In short, it describes: How the system achieves the mission using unique features/events/interactions Relationships between the system and other systems Benefits : Stakeholders can understand the system from the early stages of development In particular, developers who have different backgrounds or perspectives can gain the same understanding","title":"What is ConOps and OpsCons?"},{"location":"version-2.0/application-example/driverless-bus/appendix/what-is-conops-and-opscon/#what-is-conops-and-opscons","text":"Concept of Operations (ConOps) : \u201c... the ConOps describes the overall high-level concept of how the system will be used to meet stakeholder expectations, usually in a time-sequenced manner\u2026\u201d, source NASA Systems Engineering Handbook In short, it describes how the system achieves the user\u2019s mission with a picture and short sentences. Operational Concept (OpsCon) : \u201cThe operational concept is designed to give an overall picture of the operations using one or more specific systems, or set of related systems, in the organization\u2019s operational environment from the users\u2019 and operators\u2019 perspective.\u201d, source SEBoK In short, it describes: How the system achieves the mission using unique features/events/interactions Relationships between the system and other systems Benefits : Stakeholders can understand the system from the early stages of development In particular, developers who have different backgrounds or perspectives can gain the same understanding","title":"What is ConOps and OpsCons?"},{"location":"version-2.0/application-example/driverless-bus/concept-of-operations/","text":"Concept of Operations # Passenger Transportation System in the urban area # The system, under the surveillance of an in-car operator, will automatically transport passengers while following routes on public roads. The public roads have multiple lanes, traffic lights, and intersections; therefore the system will automatically change lanes and respond to traffic lights at intersections. The system will automatically stop at bus stops. The system is programmed to avoid colliding with objects that are detected on the road. The vehicle is programmed to either safely pass the object when possible, or to stop. While the vehicle is moving, the system automatically maintains a safe following distance and stays within the speed limit (i.e., adaptive cruise control).","title":"Concept of Operations"},{"location":"version-2.0/application-example/driverless-bus/concept-of-operations/#concept-of-operations","text":"","title":"Concept of Operations"},{"location":"version-2.0/application-example/driverless-bus/concept-of-operations/#passenger-transportation-system-in-the-urban-area","text":"The system, under the surveillance of an in-car operator, will automatically transport passengers while following routes on public roads. The public roads have multiple lanes, traffic lights, and intersections; therefore the system will automatically change lanes and respond to traffic lights at intersections. The system will automatically stop at bus stops. The system is programmed to avoid colliding with objects that are detected on the road. The vehicle is programmed to either safely pass the object when possible, or to stop. While the vehicle is moving, the system automatically maintains a safe following distance and stays within the speed limit (i.e., adaptive cruise control).","title":"Passenger Transportation System in the urban area"},{"location":"version-2.0/application-example/driverless-bus/hardware-requirements/","text":"Hardware Requirements # The content is a work in progress. Vehicle Requirements ECU Requirements Sensor Requirements LiDAR Requirements Camera Requirements Radar Requirements","title":"Hardware Requirements"},{"location":"version-2.0/application-example/driverless-bus/hardware-requirements/#hardware-requirements","text":"The content is a work in progress. Vehicle Requirements ECU Requirements Sensor Requirements LiDAR Requirements Camera Requirements Radar Requirements","title":"Hardware Requirements"},{"location":"version-2.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/","text":"ECU Requirements # This is a draft version. Overview # The requirements described in the following pages are determined based on a Tier IV project as a reference for now. This will be updated once the requirements for Open AD Kit was determined. Table of contents # High-level Architecture System Resource & Interface Performance and Data Bandwidth Requirements Hardware Requirements","title":"ECU Requirements"},{"location":"version-2.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/#ecu-requirements","text":"This is a draft version.","title":"ECU Requirements"},{"location":"version-2.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/#overview","text":"The requirements described in the following pages are determined based on a Tier IV project as a reference for now. This will be updated once the requirements for Open AD Kit was determined.","title":"Overview"},{"location":"version-2.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/#table-of-contents","text":"High-level Architecture System Resource & Interface Performance and Data Bandwidth Requirements Hardware Requirements","title":"Table of contents"},{"location":"version-2.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/high-level-arch/","text":"High-level Architecture # This is a draft version. Overview # The reference system consists of three parts of computing unit. Main Autoware 2D Perception Traffic Light Recognition Each unit can be implemented on separated hardware units (ECUs) and, if the hardware has sufficient system resource and performance, some units can also be integrated on a single hardware unit. Block Diagram #","title":"High-level Architecture"},{"location":"version-2.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/high-level-arch/#high-level-architecture","text":"This is a draft version.","title":"High-level Architecture"},{"location":"version-2.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/high-level-arch/#overview","text":"The reference system consists of three parts of computing unit. Main Autoware 2D Perception Traffic Light Recognition Each unit can be implemented on separated hardware units (ECUs) and, if the hardware has sufficient system resource and performance, some units can also be integrated on a single hardware unit.","title":"Overview"},{"location":"version-2.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/high-level-arch/#block-diagram","text":"","title":"Block Diagram"},{"location":"version-2.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/hw-requirements/","text":"Hardware Requirements # This is a draft version. Overview # This page describes sample requirements for hardware specification. NOTE: This type of hardware requirement should be differed depending on a target vehicle and changed by the industrial standard. It also needs to be determined during hardware design so might should be a part of the reference implementation. Reliability # Item Requirement Standard AEC-Q100 Environmental # Item Requirement Operating Temp e.g. -40 to 130 degree celsius Storage Temp Humidity Vibration Shock EMC Mechanical # Item Requirement Dimensions Weight Mounting Power # Item Requirement AC/DC input supply e.g. shall input 350V DC Power Consumption e.g. shall be less 600W Cooling # Item Requirement Liquid cooling","title":"Hardware Requirements"},{"location":"version-2.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/hw-requirements/#hardware-requirements","text":"This is a draft version.","title":"Hardware Requirements"},{"location":"version-2.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/hw-requirements/#overview","text":"This page describes sample requirements for hardware specification. NOTE: This type of hardware requirement should be differed depending on a target vehicle and changed by the industrial standard. It also needs to be determined during hardware design so might should be a part of the reference implementation.","title":"Overview"},{"location":"version-2.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/hw-requirements/#reliability","text":"Item Requirement Standard AEC-Q100","title":"Reliability"},{"location":"version-2.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/hw-requirements/#environmental","text":"Item Requirement Operating Temp e.g. -40 to 130 degree celsius Storage Temp Humidity Vibration Shock EMC","title":"Environmental"},{"location":"version-2.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/hw-requirements/#mechanical","text":"Item Requirement Dimensions Weight Mounting","title":"Mechanical"},{"location":"version-2.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/hw-requirements/#power","text":"Item Requirement AC/DC input supply e.g. shall input 350V DC Power Consumption e.g. shall be less 600W","title":"Power"},{"location":"version-2.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/hw-requirements/#cooling","text":"Item Requirement Liquid cooling","title":"Cooling"},{"location":"version-2.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/perf-data-bandwidth/","text":"Performance and Data Bandwidth Requirements # This is a draft version. Overview # This page describes required performance for the perception accelerators and data bandwidth on each sensor interface and network. Perception Accelerators # Functions Network Model Input resolution @ frame rate Required performance 3D Perception CenterPoint 55000 voxels x 20 points x 10 features @10FPS per LiDAR XX TOPS 2D Perception Yolov4 608x608@10FPS per Camera XX TOPS Traffic Light Recognition MobileNet v2 SSD Lite (Detection) MobileNet v2 (Classification) 300x300@10FPS 224x224@10FPS XX TOPS Data Bandwidth # Type Configurations Data type Data Bandwidth LiDAR Input Mid-range Point cloud 37 Mbps Short-range Point cloud 26 Mbps Camera Input Perception Camera YUV422 16bit 1920x1280 393 Mbps Traffic Light Recognition Camera YUV422 16bit 2880x1860 857 Mbps Inter- ECU 2D Perception to Main Autoware Recognition result & Compressed image data for logging 27 Mbps TLR to Main Autoware Recognition result & Compressed image data for logging 59 Mbps Logging Storage Mid-range LiDAR x 4 Short-range LiDAR x 4 Perception Camera x 6 (Compressed) Traffic Light Recognition Camera x 1 (Compressed) Main Autoware internat topics (272Mbps) 745 Mbps","title":"Performance and Data Bandwidth Requirements"},{"location":"version-2.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/perf-data-bandwidth/#performance-and-data-bandwidth-requirements","text":"This is a draft version.","title":"Performance and Data Bandwidth Requirements"},{"location":"version-2.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/perf-data-bandwidth/#overview","text":"This page describes required performance for the perception accelerators and data bandwidth on each sensor interface and network.","title":"Overview"},{"location":"version-2.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/perf-data-bandwidth/#perception-accelerators","text":"Functions Network Model Input resolution @ frame rate Required performance 3D Perception CenterPoint 55000 voxels x 20 points x 10 features @10FPS per LiDAR XX TOPS 2D Perception Yolov4 608x608@10FPS per Camera XX TOPS Traffic Light Recognition MobileNet v2 SSD Lite (Detection) MobileNet v2 (Classification) 300x300@10FPS 224x224@10FPS XX TOPS","title":"Perception Accelerators"},{"location":"version-2.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/perf-data-bandwidth/#data-bandwidth","text":"Type Configurations Data type Data Bandwidth LiDAR Input Mid-range Point cloud 37 Mbps Short-range Point cloud 26 Mbps Camera Input Perception Camera YUV422 16bit 1920x1280 393 Mbps Traffic Light Recognition Camera YUV422 16bit 2880x1860 857 Mbps Inter- ECU 2D Perception to Main Autoware Recognition result & Compressed image data for logging 27 Mbps TLR to Main Autoware Recognition result & Compressed image data for logging 59 Mbps Logging Storage Mid-range LiDAR x 4 Short-range LiDAR x 4 Perception Camera x 6 (Compressed) Traffic Light Recognition Camera x 1 (Compressed) Main Autoware internat topics (272Mbps) 745 Mbps","title":"Data Bandwidth"},{"location":"version-2.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/sys-resource-if/","text":"System Resource & Interface # This is a draft version. Overview # The following tables describe the required system resource and interface for each computing unit. Main Autoware Unit # Category Item Requirement Computing Resource CPU X86 8core/16thread @3.3GHz or more Memory Dual 16GB (Total 32GB), DDR4-2666 w/ ECC or more GPU 9.4 TFLOPS@FP32 or more Storage 256GB for System Volume 2TB for Logging data LiDAR 100BASE-TX, 1000BASE-T Interfaces IMU CAN or RS232C GNSS 100BASE-TX Vehicle CAN Inter- ECU (2D Perception/TLR) 1000BASE-T Power CPU TDP 80 W GPU TDP 110 W Total Max 250 W 2D Perception Unit # This table shows requirements for one camera. For multiple camera configurations, it requires more hardware units. If the hardware unit has sufficient system resource and performance, it can be integrated on a single hardware unit. Category Item Requirement Computing Resource CPU Arm v8.2 8core @2.26GHz or more Memory 32GB Low-Power Double Data Rate 4x or more GPU 30 TOPS or more Storage 32GB or more Interfaces Camera Gigabit Multimedia Serial Link 2 w/ frame sync trigger or 1000BASE-T (GigE Vision) Inter- ECU (Main Autoware) 1000BASE-T Power CPU TDP xxxW GPU TDP xxxW Total Max.xxxW Traffic Light Recognition Unit # This table shows requirements for one camera. For multiple camera configurations, it requires more hardware units. If the hardware unit has sufficient system resource and performance, it can be integrated on a single hardware unit. Category Item Requirement Computing Resource CPU Arm v8.2 8core @2.26GHz or more Memory 32GB Low-Power Double Data Rate 4x or more GPU 30 TOPS or more Storage 32GB or more Interfaces Camera Gigabit Multimedia Serial Link 2 w/ frame sync trigger or 1000BASE-T (GigE Vision) Inter- ECU (Main Autoware) 1000BASE-T Power CPU TDP xxxW GPU TDP xxxW Total Max.xxxW","title":"System Resource & Interface"},{"location":"version-2.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/sys-resource-if/#system-resource-interface","text":"This is a draft version.","title":"System Resource & Interface"},{"location":"version-2.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/sys-resource-if/#overview","text":"The following tables describe the required system resource and interface for each computing unit.","title":"Overview"},{"location":"version-2.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/sys-resource-if/#main-autoware-unit","text":"Category Item Requirement Computing Resource CPU X86 8core/16thread @3.3GHz or more Memory Dual 16GB (Total 32GB), DDR4-2666 w/ ECC or more GPU 9.4 TFLOPS@FP32 or more Storage 256GB for System Volume 2TB for Logging data LiDAR 100BASE-TX, 1000BASE-T Interfaces IMU CAN or RS232C GNSS 100BASE-TX Vehicle CAN Inter- ECU (2D Perception/TLR) 1000BASE-T Power CPU TDP 80 W GPU TDP 110 W Total Max 250 W","title":"Main Autoware Unit"},{"location":"version-2.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/sys-resource-if/#2d-perception-unit","text":"This table shows requirements for one camera. For multiple camera configurations, it requires more hardware units. If the hardware unit has sufficient system resource and performance, it can be integrated on a single hardware unit. Category Item Requirement Computing Resource CPU Arm v8.2 8core @2.26GHz or more Memory 32GB Low-Power Double Data Rate 4x or more GPU 30 TOPS or more Storage 32GB or more Interfaces Camera Gigabit Multimedia Serial Link 2 w/ frame sync trigger or 1000BASE-T (GigE Vision) Inter- ECU (Main Autoware) 1000BASE-T Power CPU TDP xxxW GPU TDP xxxW Total Max.xxxW","title":"2D Perception Unit"},{"location":"version-2.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/sys-resource-if/#traffic-light-recognition-unit","text":"This table shows requirements for one camera. For multiple camera configurations, it requires more hardware units. If the hardware unit has sufficient system resource and performance, it can be integrated on a single hardware unit. Category Item Requirement Computing Resource CPU Arm v8.2 8core @2.26GHz or more Memory 32GB Low-Power Double Data Rate 4x or more GPU 30 TOPS or more Storage 32GB or more Interfaces Camera Gigabit Multimedia Serial Link 2 w/ frame sync trigger or 1000BASE-T (GigE Vision) Inter- ECU (Main Autoware) 1000BASE-T Power CPU TDP xxxW GPU TDP xxxW Total Max.xxxW","title":"Traffic Light Recognition Unit"},{"location":"version-2.0/application-example/driverless-bus/introduction-of-reference-design/","text":"Introduction of Reference Design # Introduction # Autonomous driving technology # AWF aims to establish a sustainable ecosystem for autonomous driving to which various organizations and individuals can contribute in terms of development, and wherein society can enjoy the benefits. AWF offers open access to technologies contributing to autonomous driving. Autonomous driving requires a composite platform which integrates various software, cloud infrastructure and services in addition to the in-vehicle AD ( Autonomous Driving ) systems. There is a need for a horizontally collaborative development approach based on an open source platform that ensures a level of safety that satisfies society at a reasonable cost. In order to realize this, AWF is promoting (1) Autoware, an open source autonomous driving software, (2) AD System Reference Designs based on ODD ( Operational Design Domain \uff09categorization, and (3) Deep-tech R&D of AD systems. What can do with \"Reference Design\" as ecosystem? # With clear ODD classifications, everyone can understand where AD fits into complex real-world traffic environments. By presenting a suitable \"Reference Design\" for each ODD , AWF simplifies the preparation process in AD and lowers the difficulty threshold for demonstration and implementation.","title":"Introduction of Reference Design"},{"location":"version-2.0/application-example/driverless-bus/introduction-of-reference-design/#introduction-of-reference-design","text":"","title":"Introduction of Reference Design"},{"location":"version-2.0/application-example/driverless-bus/introduction-of-reference-design/#introduction","text":"","title":"Introduction"},{"location":"version-2.0/application-example/driverless-bus/introduction-of-reference-design/#autonomous-driving-technology","text":"AWF aims to establish a sustainable ecosystem for autonomous driving to which various organizations and individuals can contribute in terms of development, and wherein society can enjoy the benefits. AWF offers open access to technologies contributing to autonomous driving. Autonomous driving requires a composite platform which integrates various software, cloud infrastructure and services in addition to the in-vehicle AD ( Autonomous Driving ) systems. There is a need for a horizontally collaborative development approach based on an open source platform that ensures a level of safety that satisfies society at a reasonable cost. In order to realize this, AWF is promoting (1) Autoware, an open source autonomous driving software, (2) AD System Reference Designs based on ODD ( Operational Design Domain \uff09categorization, and (3) Deep-tech R&D of AD systems.","title":"Autonomous driving technology"},{"location":"version-2.0/application-example/driverless-bus/introduction-of-reference-design/#what-can-do-with-reference-design-as-ecosystem","text":"With clear ODD classifications, everyone can understand where AD fits into complex real-world traffic environments. By presenting a suitable \"Reference Design\" for each ODD , AWF simplifies the preparation process in AD and lowers the difficulty threshold for demonstration and implementation.","title":"What can do with \"Reference Design\" as ecosystem?"},{"location":"version-2.0/application-example/driverless-bus/operational-concept/","text":"Operational Concept # Operational Concept (OpsCon) of the Passenger Transportation System in the urban area is below: Daytime operation Nighttime operation Follow a route Let passengers on and off at bus stops Avoid collisions Set service route via HMI on the vehicle Interact with other vehicles on the public roads Interact with emergency vehicles Interact with traffic lights Operation mode Take over request to the operator Lane keeping and changing lanes Adaptive cruise control Predict pedestrian stepping into the road","title":"Operational Concept"},{"location":"version-2.0/application-example/driverless-bus/operational-concept/#operational-concept","text":"Operational Concept (OpsCon) of the Passenger Transportation System in the urban area is below: Daytime operation Nighttime operation Follow a route Let passengers on and off at bus stops Avoid collisions Set service route via HMI on the vehicle Interact with other vehicles on the public roads Interact with emergency vehicles Interact with traffic lights Operation mode Take over request to the operator Lane keeping and changing lanes Adaptive cruise control Predict pedestrian stepping into the road","title":"Operational Concept"},{"location":"version-2.0/application-example/driverless-bus/operational-concept/adaptive-cruise-control/","text":"Adaptive cruise control # The system automatically maintains a safe following distance and stays within the speed limit.","title":"Adaptive cruise control"},{"location":"version-2.0/application-example/driverless-bus/operational-concept/adaptive-cruise-control/#adaptive-cruise-control","text":"The system automatically maintains a safe following distance and stays within the speed limit.","title":"Adaptive cruise control"},{"location":"version-2.0/application-example/driverless-bus/operational-concept/avoid-collisions/","text":"Avoid collisions # When there are objects on the route, the system will automatically perform the following actions: a. The system automatically stops if there is surrounding traffic. b. The system automatically avoids the objects if there is no surrounding traffic.","title":"Avoid collisions"},{"location":"version-2.0/application-example/driverless-bus/operational-concept/avoid-collisions/#avoid-collisions","text":"When there are objects on the route, the system will automatically perform the following actions: a. The system automatically stops if there is surrounding traffic. b. The system automatically avoids the objects if there is no surrounding traffic.","title":"Avoid collisions"},{"location":"version-2.0/application-example/driverless-bus/operational-concept/daytime-operation/","text":"Daytime operation # Currently, the system does NOT operate in the daytime. In the future, the system will be able to operate during the daytime (9:30am - 3:30pm). The vehicle will be fully charged before the operation in the daytime. The operator connects the charger to the vehicle, and the vehicle is automatically charged.","title":"Daytime operation"},{"location":"version-2.0/application-example/driverless-bus/operational-concept/daytime-operation/#daytime-operation","text":"Currently, the system does NOT operate in the daytime. In the future, the system will be able to operate during the daytime (9:30am - 3:30pm). The vehicle will be fully charged before the operation in the daytime. The operator connects the charger to the vehicle, and the vehicle is automatically charged.","title":"Daytime operation"},{"location":"version-2.0/application-example/driverless-bus/operational-concept/follow-a-route/","text":"Follow a route # The system follows a route set on the public road while an in-car operator is in the autonomous driving vehicle of the system.","title":"Follow a route"},{"location":"version-2.0/application-example/driverless-bus/operational-concept/follow-a-route/#follow-a-route","text":"The system follows a route set on the public road while an in-car operator is in the autonomous driving vehicle of the system.","title":"Follow a route"},{"location":"version-2.0/application-example/driverless-bus/operational-concept/interact-with-emergency-vehicles/","text":"Interact with emergency vehicles # When the vehicle meets an emergency vehicle, an in-car operator performs the following actions: Promptly maneuvers the vehicle to the side of the road and stops Manually re-launches the system after the emergency vehicle passes by NOTE: The operator can use HMI (e.g., steering wheel or brake pedal) at any time to override the system control.","title":"Interact with emergency vehicles"},{"location":"version-2.0/application-example/driverless-bus/operational-concept/interact-with-emergency-vehicles/#interact-with-emergency-vehicles","text":"When the vehicle meets an emergency vehicle, an in-car operator performs the following actions: Promptly maneuvers the vehicle to the side of the road and stops Manually re-launches the system after the emergency vehicle passes by NOTE: The operator can use HMI (e.g., steering wheel or brake pedal) at any time to override the system control.","title":"Interact with emergency vehicles"},{"location":"version-2.0/application-example/driverless-bus/operational-concept/interact-with-other-vehicle-on-the-public-roads/","text":"Interact with other vehicles on the public roads # The service route uses public roads, so the system interacts with other vehicles and must obey all traffic laws. When the vehicle approaches an intersection, the system is programed to yield and take right of way with surrounding traffic, depending the actual situation and traffic laws.","title":"Interact with other vehicles on the public roads"},{"location":"version-2.0/application-example/driverless-bus/operational-concept/interact-with-other-vehicle-on-the-public-roads/#interact-with-other-vehicles-on-the-public-roads","text":"The service route uses public roads, so the system interacts with other vehicles and must obey all traffic laws. When the vehicle approaches an intersection, the system is programed to yield and take right of way with surrounding traffic, depending the actual situation and traffic laws.","title":"Interact with other vehicles on the public roads"},{"location":"version-2.0/application-example/driverless-bus/operational-concept/interact-with-traffic-lights/","text":"Interact with traffic lights # When the vehicle meets a traffic light, the system performs one of the following actions: Stop on a red light Stop on a yellow light Go straight, turn right, or turn left on a green light or arrow","title":"Interact with traffic lights"},{"location":"version-2.0/application-example/driverless-bus/operational-concept/interact-with-traffic-lights/#interact-with-traffic-lights","text":"When the vehicle meets a traffic light, the system performs one of the following actions: Stop on a red light Stop on a yellow light Go straight, turn right, or turn left on a green light or arrow","title":"Interact with traffic lights"},{"location":"version-2.0/application-example/driverless-bus/operational-concept/lane-keeping-and-changing-lanes/","text":"Lane keeping and changing lanes # The system stays the driving lane or changes lanes according to the route.","title":"Lane keeping and changing lanes"},{"location":"version-2.0/application-example/driverless-bus/operational-concept/lane-keeping-and-changing-lanes/#lane-keeping-and-changing-lanes","text":"The system stays the driving lane or changes lanes according to the route.","title":"Lane keeping and changing lanes"},{"location":"version-2.0/application-example/driverless-bus/operational-concept/let-passengers-on-and-off-at-bus-stops/","text":"Let passengers on and off at bus stops # The system stops at bus stops set by the in-car operator. The in-car operator manually opens and closes the door of the vehicle to let passengers on and off at bus stops due to the local government\u2019s request. After the in-car operator requests the system to depart, the system automatically resumes driving along the route.","title":"Let passengers on and off at bus stops"},{"location":"version-2.0/application-example/driverless-bus/operational-concept/let-passengers-on-and-off-at-bus-stops/#let-passengers-on-and-off-at-bus-stops","text":"The system stops at bus stops set by the in-car operator. The in-car operator manually opens and closes the door of the vehicle to let passengers on and off at bus stops due to the local government\u2019s request. After the in-car operator requests the system to depart, the system automatically resumes driving along the route.","title":"Let passengers on and off at bus stops"},{"location":"version-2.0/application-example/driverless-bus/operational-concept/nighttime-operation/","text":"Nighttime operation # During the nighttime (10pm - 1am), an in-car operator drives the vehicle from a parking lot to a start position and manually launches the autonomous driving system via HMI in the vehicle. The system starts moving automatically on a route set by the in-car operator. The in-car operator is while the system automatically operates.","title":"Nighttime operation"},{"location":"version-2.0/application-example/driverless-bus/operational-concept/nighttime-operation/#nighttime-operation","text":"During the nighttime (10pm - 1am), an in-car operator drives the vehicle from a parking lot to a start position and manually launches the autonomous driving system via HMI in the vehicle. The system starts moving automatically on a route set by the in-car operator. The in-car operator is while the system automatically operates.","title":"Nighttime operation"},{"location":"version-2.0/application-example/driverless-bus/operational-concept/operation-mode/","text":"Operation mode: Automatic/Manual # The in-car operator manually launches the autonomous driving system, which causes the system to start the autonomous driving. If the fail safe system in the vehicle detects malfunctions or the in-car operator presses the button on the fail safe system, the system automatically changes the operation mode from automatic to manual. Then the vehicle automatically stops.","title":"Operation mode: Automatic/Manual"},{"location":"version-2.0/application-example/driverless-bus/operational-concept/operation-mode/#operation-mode-automaticmanual","text":"The in-car operator manually launches the autonomous driving system, which causes the system to start the autonomous driving. If the fail safe system in the vehicle detects malfunctions or the in-car operator presses the button on the fail safe system, the system automatically changes the operation mode from automatic to manual. Then the vehicle automatically stops.","title":"Operation mode: Automatic/Manual"},{"location":"version-2.0/application-example/driverless-bus/operational-concept/predict-pedestrian-stepping-into-the-road/","text":"Predict pedestrian stepping into the road # The vehicle is programmed to detect pedestrians who may step into the road, and the vehicle decelerates in response.","title":"Predict pedestrian stepping into the road"},{"location":"version-2.0/application-example/driverless-bus/operational-concept/predict-pedestrian-stepping-into-the-road/#predict-pedestrian-stepping-into-the-road","text":"The vehicle is programmed to detect pedestrians who may step into the road, and the vehicle decelerates in response.","title":"Predict pedestrian stepping into the road"},{"location":"version-2.0/application-example/driverless-bus/operational-concept/set-service-route-via-HMI-on-the-vehicle/","text":"Set service route via HMI on the vehicle # The operator can set authorized service routes of the system via the Human Machine Interface ( HMI ) on the vehicle before the operation. The system can only accept a modified route while the vehicle is parked. NOTE: the service route cannot be changed without the authorization from the local government.","title":"Set service route via HMI on the vehicle"},{"location":"version-2.0/application-example/driverless-bus/operational-concept/set-service-route-via-HMI-on-the-vehicle/#set-service-route-via-hmi-on-the-vehicle","text":"The operator can set authorized service routes of the system via the Human Machine Interface ( HMI ) on the vehicle before the operation. The system can only accept a modified route while the vehicle is parked. NOTE: the service route cannot be changed without the authorization from the local government.","title":"Set service route via HMI on the vehicle"},{"location":"version-2.0/application-example/driverless-bus/operational-concept/take-over-request-to-the-operator/","text":"Take over request to the operator # When the system cannot judge whether it can move forward, the system sends a recommendation to hand over operation to the in-car operator. The operator is supposed to perform the following actions when requested by the system: Request to depart\uff08refer to Let passengers on and off at bus-stops \uff09 Avoid objects Detour","title":"Take over request to the operator"},{"location":"version-2.0/application-example/driverless-bus/operational-concept/take-over-request-to-the-operator/#take-over-request-to-the-operator","text":"When the system cannot judge whether it can move forward, the system sends a recommendation to hand over operation to the in-car operator. The operator is supposed to perform the following actions when requested by the system: Request to depart\uff08refer to Let passengers on and off at bus-stops \uff09 Avoid objects Detour","title":"Take over request to the operator"},{"location":"version-2.0/application-example/driverless-bus/operational-environment-requirement/","text":"Operational Environment Requirements # The content is a work in progress.","title":"Operational Environment Requirements"},{"location":"version-2.0/application-example/driverless-bus/operational-environment-requirement/#operational-environment-requirements","text":"The content is a work in progress.","title":"Operational Environment Requirements"},{"location":"version-2.0/application-example/driverless-bus/software-requirements/","text":"Software Requirements # The content is a work in progress. Operating System Requirements Kernel Module Requirements Middleware Requirements DDS Requirements Map Requirements Design docs of Autoware Autoware API Component Architecture Repository Configuration","title":"Software Requirements"},{"location":"version-2.0/application-example/driverless-bus/software-requirements/#software-requirements","text":"The content is a work in progress. Operating System Requirements Kernel Module Requirements Middleware Requirements DDS Requirements Map Requirements Design docs of Autoware Autoware API Component Architecture Repository Configuration","title":"Software Requirements"},{"location":"version-2.0/application-example/driverless-bus/software-requirements/autoware-api/","text":"Autoware API # Overview # Autoware API provides a long-term and stable operation protocol for autonomous driving vehicles, and clarifies how to support new sensors and vehicles and add new features. It also works as a framework for easy access to the functions of each component by developers of other components. Concept # There are two categories of Autoware API. One is Autoware AD API for operating the vehicle from outside the autonomous driving system such as Fleet Management System(FMS) and HMI for operators or passengers. The other is Autoware Component Interfaces for linking each internal component. Some external systems for evaluation or debugging purposes, such as simulator, are allowed access to Component Interfaces in addition to AD API. AD API Customization # For general usage, Autoware provides the default AD API implementations and configurations using Component Interfaces. If a special behavior is needed, the implementation can be modified as long as it satisfies the requirements of the specification. Component Interfaces Hierarchy # Autoware Component Interfaces have a hierarchical specification. The top-level architecture consists of several components, and each component has some options of the next-level architecture. Developers select one of them when implementing the component. The simplest next-level architecture is monolithic. This is an all-in-one and black box implementation, and is suitable for small group development, prototyping, and extremely complex functions. Others are just concepts and do not currently exist. However, these have advantages for large group development. Developers can combine their modules with other modules that adopt the same architecture. Interface Code Generation # For specification clarification and development efficiency, it is recommended to use the generated code by the defined interface. Developers may select the interface to use from the specification and refer the generated code in their program. This makes it easy to analyze the interface used by each program, which then can be applied to configuration automation and visualization.","title":"Autoware API"},{"location":"version-2.0/application-example/driverless-bus/software-requirements/autoware-api/#autoware-api","text":"","title":"Autoware API"},{"location":"version-2.0/application-example/driverless-bus/software-requirements/autoware-api/#overview","text":"Autoware API provides a long-term and stable operation protocol for autonomous driving vehicles, and clarifies how to support new sensors and vehicles and add new features. It also works as a framework for easy access to the functions of each component by developers of other components.","title":"Overview"},{"location":"version-2.0/application-example/driverless-bus/software-requirements/autoware-api/#concept","text":"There are two categories of Autoware API. One is Autoware AD API for operating the vehicle from outside the autonomous driving system such as Fleet Management System(FMS) and HMI for operators or passengers. The other is Autoware Component Interfaces for linking each internal component. Some external systems for evaluation or debugging purposes, such as simulator, are allowed access to Component Interfaces in addition to AD API.","title":"Concept"},{"location":"version-2.0/application-example/driverless-bus/software-requirements/autoware-api/#ad-api-customization","text":"For general usage, Autoware provides the default AD API implementations and configurations using Component Interfaces. If a special behavior is needed, the implementation can be modified as long as it satisfies the requirements of the specification.","title":"AD API Customization"},{"location":"version-2.0/application-example/driverless-bus/software-requirements/autoware-api/#component-interfaces-hierarchy","text":"Autoware Component Interfaces have a hierarchical specification. The top-level architecture consists of several components, and each component has some options of the next-level architecture. Developers select one of them when implementing the component. The simplest next-level architecture is monolithic. This is an all-in-one and black box implementation, and is suitable for small group development, prototyping, and extremely complex functions. Others are just concepts and do not currently exist. However, these have advantages for large group development. Developers can combine their modules with other modules that adopt the same architecture.","title":"Component Interfaces Hierarchy"},{"location":"version-2.0/application-example/driverless-bus/software-requirements/autoware-api/#interface-code-generation","text":"For specification clarification and development efficiency, it is recommended to use the generated code by the defined interface. Developers may select the interface to use from the specification and refer the generated code in their program. This makes it easy to analyze the interface used by each program, which then can be applied to configuration automation and visualization.","title":"Interface Code Generation"},{"location":"version-2.0/application-example/driverless-bus/software-requirements/component-architecture/","text":"Component architecture # Overview # The figure below is the overview of Autoware's component configuration (tentative). Autoware components # TODO(Tier IV): Write the details based on the following materials. Autoware.Auto autoware_auto_msgs Tier IV's proposal document Tier IV's proposal implementation Map # Inputs: Map file PointCloud map file Vector map file Outputs: Map data PointCloud map file Vector map file Sensing # Inputs: Raw sensor data GNSS IMU Camera LiDAR RADAR Estimated self motion To filter distortions Outputs: Preprocessed sensor data GNSS pose and doppler velocity IMU acceleration and angular velocity Camera image LiDAR PointCloud RADAR reflection Localization # Inputs: Preprocessed sensor data GNSS pose and doppler velocity IMU acceleration and angular velocity Camera image LiDAR PointCloud RADAR reflection Map data PointCloud map Vector map Outputs: Localized self pose Topic TF Estimated self motion Perception # Inputs: Localized self pose Estimated self motion Preprocessed sensor data Camera image LiDAR PointCloud RADAR reflection Outputs: Detected dynamic objects Detected traffic lights Filtered obstacle PointCloud Planning # Inputs: Localized pose Estimated self motion Outputs: Planned trajectory Planning status Control # Inputs: Localized self pose Estimated self motion Planner trajectory Vehicle sensor data velocity steering angle Outputs: Control commands High-level commands for easy usage Low-level commands for detailed controls Vehicle # Autoware to Vehicle # Inputs: Control commands Outputs: Raw vehicle control commands Vehicle to Autoware # Inputs: Raw vehicle sensor data (e.g. CAN) Outputs: Vehicle sensor data (Topic) System # Inputs: Each component output Outputs: System status MRM request","title":"Component architecture"},{"location":"version-2.0/application-example/driverless-bus/software-requirements/component-architecture/#component-architecture","text":"","title":"Component architecture"},{"location":"version-2.0/application-example/driverless-bus/software-requirements/component-architecture/#overview","text":"The figure below is the overview of Autoware's component configuration (tentative).","title":"Overview"},{"location":"version-2.0/application-example/driverless-bus/software-requirements/component-architecture/#autoware-components","text":"TODO(Tier IV): Write the details based on the following materials. Autoware.Auto autoware_auto_msgs Tier IV's proposal document Tier IV's proposal implementation","title":"Autoware components"},{"location":"version-2.0/application-example/driverless-bus/software-requirements/component-architecture/#map","text":"Inputs: Map file PointCloud map file Vector map file Outputs: Map data PointCloud map file Vector map file","title":"Map"},{"location":"version-2.0/application-example/driverless-bus/software-requirements/component-architecture/#sensing","text":"Inputs: Raw sensor data GNSS IMU Camera LiDAR RADAR Estimated self motion To filter distortions Outputs: Preprocessed sensor data GNSS pose and doppler velocity IMU acceleration and angular velocity Camera image LiDAR PointCloud RADAR reflection","title":"Sensing"},{"location":"version-2.0/application-example/driverless-bus/software-requirements/component-architecture/#localization","text":"Inputs: Preprocessed sensor data GNSS pose and doppler velocity IMU acceleration and angular velocity Camera image LiDAR PointCloud RADAR reflection Map data PointCloud map Vector map Outputs: Localized self pose Topic TF Estimated self motion","title":"Localization"},{"location":"version-2.0/application-example/driverless-bus/software-requirements/component-architecture/#perception","text":"Inputs: Localized self pose Estimated self motion Preprocessed sensor data Camera image LiDAR PointCloud RADAR reflection Outputs: Detected dynamic objects Detected traffic lights Filtered obstacle PointCloud","title":"Perception"},{"location":"version-2.0/application-example/driverless-bus/software-requirements/component-architecture/#planning","text":"Inputs: Localized pose Estimated self motion Outputs: Planned trajectory Planning status","title":"Planning"},{"location":"version-2.0/application-example/driverless-bus/software-requirements/component-architecture/#control","text":"Inputs: Localized self pose Estimated self motion Planner trajectory Vehicle sensor data velocity steering angle Outputs: Control commands High-level commands for easy usage Low-level commands for detailed controls","title":"Control"},{"location":"version-2.0/application-example/driverless-bus/software-requirements/component-architecture/#vehicle","text":"","title":"Vehicle"},{"location":"version-2.0/application-example/driverless-bus/software-requirements/component-architecture/#system","text":"Inputs: Each component output Outputs: System status MRM request","title":"System"},{"location":"version-2.0/application-example/driverless-bus/software-requirements/design-docs-of-autoware/","text":"Design docs of Autoware # In this section, we'll explain a couple of design documents of Autoware. The first one is about Autoware API . It defines two kinds of APIs for different developers. Autoware AD API for developers of external systems such as fleet management HMI , etc. AD means Autonomous Driving. Autoware Component Interface for developers of Autoware components such as Localization, Perception, etc. The second one is about the architecture of Autoware components. It explains the interface between Autoware components in detail. The last one is about the repository configuration of Autoware, which is currently used here . It explains why such a distributed structure is necessary.","title":"Design docs of Autoware"},{"location":"version-2.0/application-example/driverless-bus/software-requirements/design-docs-of-autoware/#design-docs-of-autoware","text":"In this section, we'll explain a couple of design documents of Autoware. The first one is about Autoware API . It defines two kinds of APIs for different developers. Autoware AD API for developers of external systems such as fleet management HMI , etc. AD means Autonomous Driving. Autoware Component Interface for developers of Autoware components such as Localization, Perception, etc. The second one is about the architecture of Autoware components. It explains the interface between Autoware components in detail. The last one is about the repository configuration of Autoware, which is currently used here . It explains why such a distributed structure is necessary.","title":"Design docs of Autoware"},{"location":"version-2.0/application-example/driverless-bus/software-requirements/repository-configuration/","text":"Repository configuration # Overview # This page shows the repository configuration of Autoware and its concepts. Warning Note: This figure is tentative. TODO: Add documentations repositories, WG repositories, and autoware.org. Concepts # Core/Universe architecture # Since Autoware is desired to be usable for production-level vehicles in the future, Autoware.Auto has been used strict merge criteria. However, since there is no specific requirements or specifications in Autonomous Driving, it's almost impossible to build a perfect product from the beginning. We need prototyping phases to build a high-quality product, so we're doing ODD -based developments. Then, doing every development in one branch causes slowing down of development speed or mixin of low-quality. Also, forcing such a strict rules for all contributors will make them discourage from sending PRs. Therefore, it's better to separate production level and high-quality code and prototyping level code. Specifically, we define Core/Universe for this. Core defines the interfaces of Autoware Both Core and Universe refer to the interface Core has high-quality code Universe has experimental level code With this, we aim to accomplish the following things. Contributors can feel free to send small PRs. We can keep high-quality for the Core code. We can rapidly build prototypes in Universe. We can develop a lot of extensions, including cutting-edge features, based on the interfaces. Definition of Core/Universe # Core Complete end-to-end autonomous driving framework Supports all current AWF ODDs Provides the definitions and the functionality for which other packages can extend Strict code and quality control Heavily managed by the AWF Stable base implementation Universe Additional packages built on top of Core Extends Autoware functionality beyond the AWF ODDs Completely dependent on Core functionality and message definitions Relaxed code and quality control Community managed Enables quick experimentation and prototype testing Repositories and roles # Although some repositories might be added in the future, these are enough for explaining the core concept. autowarefoundation/autoware This is a meta-repository that contains .repos files to construct a workspace. Since it's prospected to be forked by users, we don't put a lot of information here to avoid unnecessary differences. autowarefoundation/autoware_common This is a repository that contains ROS packages referenced in common by many repositories like libraries and utilities. In order to reduce the CI execution time, splitting that kind of packages from a big repository is a good practice. autowarefoundation/autoware.core This is a core repository that contains high-quality and stable ROS packages for Autonomous Driving. Although it's almost empty at this time, it will be implemented based on Autoware.Auto and Autoware.Universe during the next ODD project. autowarefoundation/autoware.universe This is a core repository that contains experimental but cutting-edge ROS packages for Autonomous Driving. autowarefoundation/autoware_launch This is a launch configuration repository that contains node configurations and their parameters. autowarefoundation/autoware-github-actions This is a repository for CI that contains reusable workflows of GitHub Actions . Since Autoware has a lot of repositories in total, making CI scripts DRY(Don't Repeat Yourself) is efficient. autowarefoundation/autoware-documentation This is a documentation repository for Autoware users and developers. Since Autoware Core/Universe has multiple repositories, preparing a central documentation repository is more user-friendly than writing distributed documentation in each repository. FAQ # Why don't use the meta-repository for documentation? # Since it's forked by many users, documentation changes would be noise during syncing repositories. Why autoware.org isn't enough for documentation? # Since Software Engineers can't maintain it easily, it's hard to write a lot of information and keep up-to-date. Why both autoware-documentation and autoware-reference-design (this site) are required? # It's for a kind of separation of concerns. Too much information on one site makes confusion. autoware-documentation is mainly for users. autoware-reference-design is for core developers.","title":"Repository configuration"},{"location":"version-2.0/application-example/driverless-bus/software-requirements/repository-configuration/#repository-configuration","text":"","title":"Repository configuration"},{"location":"version-2.0/application-example/driverless-bus/software-requirements/repository-configuration/#overview","text":"This page shows the repository configuration of Autoware and its concepts. Warning Note: This figure is tentative. TODO: Add documentations repositories, WG repositories, and autoware.org.","title":"Overview"},{"location":"version-2.0/application-example/driverless-bus/software-requirements/repository-configuration/#concepts","text":"","title":"Concepts"},{"location":"version-2.0/application-example/driverless-bus/software-requirements/repository-configuration/#coreuniverse-architecture","text":"Since Autoware is desired to be usable for production-level vehicles in the future, Autoware.Auto has been used strict merge criteria. However, since there is no specific requirements or specifications in Autonomous Driving, it's almost impossible to build a perfect product from the beginning. We need prototyping phases to build a high-quality product, so we're doing ODD -based developments. Then, doing every development in one branch causes slowing down of development speed or mixin of low-quality. Also, forcing such a strict rules for all contributors will make them discourage from sending PRs. Therefore, it's better to separate production level and high-quality code and prototyping level code. Specifically, we define Core/Universe for this. Core defines the interfaces of Autoware Both Core and Universe refer to the interface Core has high-quality code Universe has experimental level code With this, we aim to accomplish the following things. Contributors can feel free to send small PRs. We can keep high-quality for the Core code. We can rapidly build prototypes in Universe. We can develop a lot of extensions, including cutting-edge features, based on the interfaces.","title":"Core/Universe architecture"},{"location":"version-2.0/application-example/driverless-bus/software-requirements/repository-configuration/#definition-of-coreuniverse","text":"Core Complete end-to-end autonomous driving framework Supports all current AWF ODDs Provides the definitions and the functionality for which other packages can extend Strict code and quality control Heavily managed by the AWF Stable base implementation Universe Additional packages built on top of Core Extends Autoware functionality beyond the AWF ODDs Completely dependent on Core functionality and message definitions Relaxed code and quality control Community managed Enables quick experimentation and prototype testing","title":"Definition of Core/Universe"},{"location":"version-2.0/application-example/driverless-bus/software-requirements/repository-configuration/#repositories-and-roles","text":"Although some repositories might be added in the future, these are enough for explaining the core concept. autowarefoundation/autoware This is a meta-repository that contains .repos files to construct a workspace. Since it's prospected to be forked by users, we don't put a lot of information here to avoid unnecessary differences. autowarefoundation/autoware_common This is a repository that contains ROS packages referenced in common by many repositories like libraries and utilities. In order to reduce the CI execution time, splitting that kind of packages from a big repository is a good practice. autowarefoundation/autoware.core This is a core repository that contains high-quality and stable ROS packages for Autonomous Driving. Although it's almost empty at this time, it will be implemented based on Autoware.Auto and Autoware.Universe during the next ODD project. autowarefoundation/autoware.universe This is a core repository that contains experimental but cutting-edge ROS packages for Autonomous Driving. autowarefoundation/autoware_launch This is a launch configuration repository that contains node configurations and their parameters. autowarefoundation/autoware-github-actions This is a repository for CI that contains reusable workflows of GitHub Actions . Since Autoware has a lot of repositories in total, making CI scripts DRY(Don't Repeat Yourself) is efficient. autowarefoundation/autoware-documentation This is a documentation repository for Autoware users and developers. Since Autoware Core/Universe has multiple repositories, preparing a central documentation repository is more user-friendly than writing distributed documentation in each repository.","title":"Repositories and roles"},{"location":"version-2.0/application-example/driverless-bus/software-requirements/repository-configuration/#faq","text":"","title":"FAQ"},{"location":"version-2.0/application-example/driverless-bus/software-requirements/repository-configuration/#why-dont-use-the-meta-repository-for-documentation","text":"Since it's forked by many users, documentation changes would be noise during syncing repositories.","title":"Why don't use the meta-repository for documentation?"},{"location":"version-2.0/application-example/driverless-bus/software-requirements/repository-configuration/#why-autowareorg-isnt-enough-for-documentation","text":"Since Software Engineers can't maintain it easily, it's hard to write a lot of information and keep up-to-date.","title":"Why autoware.org isn't enough for documentation?"},{"location":"version-2.0/application-example/driverless-bus/software-requirements/repository-configuration/#why-both-autoware-documentation-and-autoware-reference-design-this-site-are-required","text":"It's for a kind of separation of concerns. Too much information on one site makes confusion. autoware-documentation is mainly for users. autoware-reference-design is for core developers.","title":"Why both autoware-documentation and autoware-reference-design (this site) are required?"},{"location":"version-2.0/application-example/driverless-bus/system-configuration/","text":"System Configuration # The content is a work in progress. This chapter should show the physical configuration of the system.","title":"System Configuration"},{"location":"version-2.0/application-example/driverless-bus/system-configuration/#system-configuration","text":"The content is a work in progress. This chapter should show the physical configuration of the system.","title":"System Configuration"},{"location":"version-2.0/application-example/driverless-bus/system-requirements/","text":"System Requirements # The content is a work in progress. This chapter should show requirements for the system of interest and its sub-systems. Parity Requirements","title":"System Requirements"},{"location":"version-2.0/application-example/driverless-bus/system-requirements/#system-requirements","text":"The content is a work in progress. This chapter should show requirements for the system of interest and its sub-systems. Parity Requirements","title":"System Requirements"},{"location":"version-2.0/application-example/driverless-bus/system-requirements/parity-requirements/","text":"Parity # Importance of the parity in the verification of autonomous driving systems # One of the most important points in the verification process of the autonomous driving system is the guaranteed level of the parity between the edge (onboard) and the cloud (CI /CD) environment. Various types of the parity and the information that is useful in the verification architecture taking the parity into consideration \u3000 are explained. Parity types # Device Parity # The parity of the hardware (machines). When using the public cloud, as the device variation available on the public cloud is generally limited, it is difficult to guarantee this device parity. CPU Architecture Parity # The parity of the processor implementation including the microservice architecture and the clock speed, etc. ISA Parity # The ISA (Instruction Set Architecture) Parity is different from the CPU Architecture Parity. It means the parity of the available register resource, instruction set, and the calculation functionality, where the processor implementation is abstracted. Runtime Parity # The Runtime Parity means the parity of the kernel module and the container runtime, where the built result at the application level is guaranteed to run flawlessly. However, depending on the implementation, some modules do not run even if the Runtime Parity is secured. For example, the object detection module which is optimized for a GPU model. Environment Parity # The Environment Parity means the parity of the network configuration, set of frameworks and libraries of the autonomous driving system applications. Parity and Cloud Native DevOps # In autonomous driving system verification, it is important to conduct the necessary tests by understanding what level of parity is guaranteed for the verification environment compared to the vehicle environment. On the other hand, in case that the public cloud is used as a cloud native environment, the Device Parity may not be fulfilled. Depending on the choice of the chip, the CPU Architecture Parity or the ISA Parity may not be met. It is crucial to conduct tests in the bench environment while improving the development experience by executing the sufficient number of tests in a short time period in a cloud native manner.","title":"Parity"},{"location":"version-2.0/application-example/driverless-bus/system-requirements/parity-requirements/#parity","text":"","title":"Parity"},{"location":"version-2.0/application-example/driverless-bus/system-requirements/parity-requirements/#importance-of-the-parity-in-the-verification-of-autonomous-driving-systems","text":"One of the most important points in the verification process of the autonomous driving system is the guaranteed level of the parity between the edge (onboard) and the cloud (CI /CD) environment. Various types of the parity and the information that is useful in the verification architecture taking the parity into consideration \u3000 are explained.","title":"Importance of the parity in the verification of autonomous driving systems"},{"location":"version-2.0/application-example/driverless-bus/system-requirements/parity-requirements/#parity-types","text":"","title":"Parity types"},{"location":"version-2.0/application-example/driverless-bus/system-requirements/parity-requirements/#device-parity","text":"The parity of the hardware (machines). When using the public cloud, as the device variation available on the public cloud is generally limited, it is difficult to guarantee this device parity.","title":"Device Parity"},{"location":"version-2.0/application-example/driverless-bus/system-requirements/parity-requirements/#cpu-architecture-parity","text":"The parity of the processor implementation including the microservice architecture and the clock speed, etc.","title":"CPU Architecture Parity"},{"location":"version-2.0/application-example/driverless-bus/system-requirements/parity-requirements/#isa-parity","text":"The ISA (Instruction Set Architecture) Parity is different from the CPU Architecture Parity. It means the parity of the available register resource, instruction set, and the calculation functionality, where the processor implementation is abstracted.","title":"ISA Parity"},{"location":"version-2.0/application-example/driverless-bus/system-requirements/parity-requirements/#runtime-parity","text":"The Runtime Parity means the parity of the kernel module and the container runtime, where the built result at the application level is guaranteed to run flawlessly. However, depending on the implementation, some modules do not run even if the Runtime Parity is secured. For example, the object detection module which is optimized for a GPU model.","title":"Runtime Parity"},{"location":"version-2.0/application-example/driverless-bus/system-requirements/parity-requirements/#environment-parity","text":"The Environment Parity means the parity of the network configuration, set of frameworks and libraries of the autonomous driving system applications.","title":"Environment Parity"},{"location":"version-2.0/application-example/driverless-bus/system-requirements/parity-requirements/#parity-and-cloud-native-devops","text":"In autonomous driving system verification, it is important to conduct the necessary tests by understanding what level of parity is guaranteed for the verification environment compared to the vehicle environment. On the other hand, in case that the public cloud is used as a cloud native environment, the Device Parity may not be fulfilled. Depending on the choice of the chip, the CPU Architecture Parity or the ISA Parity may not be met. It is crucial to conduct tests in the bench environment while improving the development experience by executing the sufficient number of tests in a short time period in a cloud native manner.","title":"Parity and Cloud Native DevOps"},{"location":"version-2.0/start-guide/","text":"Start guide # This page describes how to install, set up and run Autoware and its associated simulators on supported development platforms. Installation explains how to set up the development environment that are described in the System Configuration chapter. How to run Autoware shows how to run Autoware on the development platform that are set up in the Installation chapter. How to run simulators demonstrates how to run simulators that are set up in the Installation chapter.","title":"Start guide"},{"location":"version-2.0/start-guide/#start-guide","text":"This page describes how to install, set up and run Autoware and its associated simulators on supported development platforms. Installation explains how to set up the development environment that are described in the System Configuration chapter. How to run Autoware shows how to run Autoware on the development platform that are set up in the Installation chapter. How to run simulators demonstrates how to run simulators that are set up in the Installation chapter.","title":"Start guide"},{"location":"version-2.0/start-guide/how-to-run-autoware/","text":"How to run Autoware # This page explains how to run Autoware on the development platform that are set up in the Installation chapter . Minimum requirements # Developer Platform: TODO In-Vehicle Development Platform 1 : TODO Software Tool: TODO Container Image: TODO 1. Run Autoware on the developer platform # Run Autoware.Auto on AVA platform or PCU or Xavier # Access AVA platform or PCU or Xavier via SSH. Deploy kubernetes clusters for Autoware. kubectl apply -f comhpc-deployments You can make sure deployments are deployed. root@comhpc:~# kubectl get deploy -o wide NAME READY UP-TO-DATE AVAILABLE AGE CONTAINERS IMAGES SELECTOR comhpc-control 1/1 1 1 15h comhpc ghcr.io/autowarefoundation/autoware-universe:galactic-20220728-prebuilt-cuda io.kompose.service=comhpc comhpc-api 1/1 1 1 15h comhpc ghcr.io/autowarefoundation/autoware-universe:galactic-20220728-prebuilt-cuda io.kompose.service=comhpc comhpc-planning 1/1 1 1 15h comhpc ghcr.io/autowarefoundation/autoware-universe:galactic-20220728-prebuilt-cuda io.kompose.service=comhpc comhpc-simulator 1/1 1 1 15h comhpc ghcr.io/autowarefoundation/autoware-universe:galactic-20220728-prebuilt-cuda io.kompose.service=comhpc comhpc-map 1/1 1 1 15h comhpc ghcr.io/autowarefoundation/autoware-universe:galactic-20220728-prebuilt-cuda io.kompose.service=comhpc comhpc-system 1/1 1 1 17h comhpc ghcr.io/autowarefoundation/autoware-universe:galactic-20220728-prebuilt-cuda io.kompose.service=comhpc comhpc-vehicle 1/1 1 1 17h comhpc ghcr.io/autowarefoundation/autoware-universe:galactic-20220728-prebuilt-cuda io.kompose.service=comhpc Please make sure all pods are running. root@comhpc:~# kubectl get pod -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES comhpc-control-58cb5b9dbd-fqckv 1/1 Running 0 104m 192.168.10.27 ava comhpc-api-7b588f7988-n4rb7 1/1 Running 0 103m 192.168.10.27 ava comhpc-planning-d964b9646-92rzc 1/1 Running 0 104m 192.168.10.27 ava comhpc-simulator-7f5b9fb97d-7kvqm 1/1 Running 0 104m 192.168.10.27 ava comhpc-map-7867476c98-mgrm5 1/1 Running 0 103m 192.168.10.27 ava comhpc-system-c5599d5b-xxhg2 1/1 Running 0 103m 192.168.10.27 ava comhpc-vehicle-9d6b5b9b8-k95q9 1/1 Running 0 103m 192.168.10.27 ava 2. Run Autoware on the in-vehicle development platform # If you do NOT need a vehicle-edge platform, please skip this step. TODO 3. Run simulators on the development platform # Please refer to the How to run simulators section. This is optional if you do NOT need a vehicle-edge platform. \u21a9","title":"How to run Autoware"},{"location":"version-2.0/start-guide/how-to-run-autoware/#how-to-run-autoware","text":"This page explains how to run Autoware on the development platform that are set up in the Installation chapter .","title":"How to run Autoware"},{"location":"version-2.0/start-guide/how-to-run-autoware/#minimum-requirements","text":"Developer Platform: TODO In-Vehicle Development Platform 1 : TODO Software Tool: TODO Container Image: TODO","title":"Minimum requirements"},{"location":"version-2.0/start-guide/how-to-run-autoware/#1-run-autoware-on-the-developer-platform","text":"","title":"1. Run Autoware on the developer platform"},{"location":"version-2.0/start-guide/how-to-run-autoware/#run-autowareauto-on-ava-platform-or-pcu-or-xavier","text":"Access AVA platform or PCU or Xavier via SSH. Deploy kubernetes clusters for Autoware. kubectl apply -f comhpc-deployments You can make sure deployments are deployed. root@comhpc:~# kubectl get deploy -o wide NAME READY UP-TO-DATE AVAILABLE AGE CONTAINERS IMAGES SELECTOR comhpc-control 1/1 1 1 15h comhpc ghcr.io/autowarefoundation/autoware-universe:galactic-20220728-prebuilt-cuda io.kompose.service=comhpc comhpc-api 1/1 1 1 15h comhpc ghcr.io/autowarefoundation/autoware-universe:galactic-20220728-prebuilt-cuda io.kompose.service=comhpc comhpc-planning 1/1 1 1 15h comhpc ghcr.io/autowarefoundation/autoware-universe:galactic-20220728-prebuilt-cuda io.kompose.service=comhpc comhpc-simulator 1/1 1 1 15h comhpc ghcr.io/autowarefoundation/autoware-universe:galactic-20220728-prebuilt-cuda io.kompose.service=comhpc comhpc-map 1/1 1 1 15h comhpc ghcr.io/autowarefoundation/autoware-universe:galactic-20220728-prebuilt-cuda io.kompose.service=comhpc comhpc-system 1/1 1 1 17h comhpc ghcr.io/autowarefoundation/autoware-universe:galactic-20220728-prebuilt-cuda io.kompose.service=comhpc comhpc-vehicle 1/1 1 1 17h comhpc ghcr.io/autowarefoundation/autoware-universe:galactic-20220728-prebuilt-cuda io.kompose.service=comhpc Please make sure all pods are running. root@comhpc:~# kubectl get pod -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES comhpc-control-58cb5b9dbd-fqckv 1/1 Running 0 104m 192.168.10.27 ava comhpc-api-7b588f7988-n4rb7 1/1 Running 0 103m 192.168.10.27 ava comhpc-planning-d964b9646-92rzc 1/1 Running 0 104m 192.168.10.27 ava comhpc-simulator-7f5b9fb97d-7kvqm 1/1 Running 0 104m 192.168.10.27 ava comhpc-map-7867476c98-mgrm5 1/1 Running 0 103m 192.168.10.27 ava comhpc-system-c5599d5b-xxhg2 1/1 Running 0 103m 192.168.10.27 ava comhpc-vehicle-9d6b5b9b8-k95q9 1/1 Running 0 103m 192.168.10.27 ava ","title":"Run Autoware.Auto on AVA platform or PCU or Xavier"},{"location":"version-2.0/start-guide/how-to-run-autoware/#2-run-autoware-on-the-in-vehicle-development-platform","text":"If you do NOT need a vehicle-edge platform, please skip this step. TODO","title":"2. Run Autoware on the in-vehicle development platform"},{"location":"version-2.0/start-guide/how-to-run-autoware/#3-run-simulators-on-the-development-platform","text":"Please refer to the How to run simulators section. This is optional if you do NOT need a vehicle-edge platform. \u21a9","title":"3. Run simulators on the development platform"},{"location":"version-2.0/start-guide/how-to-run-simulators/","text":"How to run simulators # This page describes how to run simulators that work on your local environment and the cloud environment. Scenario simulator verifies your planning algorithms. Logging simulator verifies your perception algorithms with ROSBAG data that are recorded beforehand. Troubleshooting Limitations and issues","title":"How to run simulators"},{"location":"version-2.0/start-guide/how-to-run-simulators/#how-to-run-simulators","text":"This page describes how to run simulators that work on your local environment and the cloud environment. Scenario simulator verifies your planning algorithms. Logging simulator verifies your perception algorithms with ROSBAG data that are recorded beforehand. Troubleshooting Limitations and issues","title":"How to run simulators"},{"location":"version-2.0/start-guide/how-to-run-simulators/limitations-and-issues/limitations-and-issues/","text":"Limitations and issues # Limitations # Issues #","title":"Limitations and issues"},{"location":"version-2.0/start-guide/how-to-run-simulators/limitations-and-issues/limitations-and-issues/#limitations-and-issues","text":"","title":"Limitations and issues"},{"location":"version-2.0/start-guide/how-to-run-simulators/limitations-and-issues/limitations-and-issues/#limitations","text":"","title":"Limitations"},{"location":"version-2.0/start-guide/how-to-run-simulators/limitations-and-issues/limitations-and-issues/#issues","text":"","title":"Issues"},{"location":"version-2.0/start-guide/how-to-run-simulators/logging-simulator/run-on-cloud-env/","text":"Run on the cloud platform # This page describes how to run the logging simulator on the cloud platform. The cloud platform, Web.Auto, is offered by TIER IV , and it is available for the Autoware Foundation members. Minimum requirements # Developer Platform: TODO In-Vehicle Development Platform 1 : TODO Software Tool: TODO Container Image: TODO Data Pipeline: TODO 1. Create your account on the cloud platform # If you already have access to Web.Auto, please skip this step. TODO 2. Set up a simulation on the cloud platform # TODO 3. Run the logging simulator on the cloud platform # TODO This is optional if you do NOT need a vehicle-edge platform. \u21a9","title":"Run on the cloud platform"},{"location":"version-2.0/start-guide/how-to-run-simulators/logging-simulator/run-on-cloud-env/#run-on-the-cloud-platform","text":"This page describes how to run the logging simulator on the cloud platform. The cloud platform, Web.Auto, is offered by TIER IV , and it is available for the Autoware Foundation members.","title":"Run on the cloud platform"},{"location":"version-2.0/start-guide/how-to-run-simulators/logging-simulator/run-on-cloud-env/#minimum-requirements","text":"Developer Platform: TODO In-Vehicle Development Platform 1 : TODO Software Tool: TODO Container Image: TODO Data Pipeline: TODO","title":"Minimum requirements"},{"location":"version-2.0/start-guide/how-to-run-simulators/logging-simulator/run-on-cloud-env/#1-create-your-account-on-the-cloud-platform","text":"If you already have access to Web.Auto, please skip this step. TODO","title":"1. Create your account on the cloud platform"},{"location":"version-2.0/start-guide/how-to-run-simulators/logging-simulator/run-on-cloud-env/#2-set-up-a-simulation-on-the-cloud-platform","text":"TODO","title":"2. Set up a simulation on the cloud platform"},{"location":"version-2.0/start-guide/how-to-run-simulators/logging-simulator/run-on-cloud-env/#3-run-the-logging-simulator-on-the-cloud-platform","text":"TODO This is optional if you do NOT need a vehicle-edge platform. \u21a9","title":"3. Run the logging simulator on the cloud platform"},{"location":"version-2.0/start-guide/how-to-run-simulators/scenario-simulator/run-on-cloud-env/","text":"Run on the cloud platform # This page describes how to run the scenario simulator on the cloud platform. The cloud platform, Web.Auto, is offered by TIER IV , and it is available for the Autoware Foundation members. Minimum requirements # Developer Platform: TODO In-Vehicle Development Platform 1 : TODO Software Tool: TODO Container Image: TODO Data Pipeline: TODO 1. Create your account on the cloud platform # If you already have access to Web.Auto, please skip this step. Cloud Native CI/CD Pipeline - Web.Auto # The CI/CD pipeline for the scenario simulation is available for the Autoware Foundation members. You can check the scenario simulation results on the CI/CD dashboard. This material describes the CI/CD pipeline in more details. Create an account with Tier IV account server ( https://account.tier4.jp/ ). Participate in an Autoware Foundation working group (Simulation, Autonomy Software, Operational Design DomainD, Open AD Kit) and report the Tier IV Account ID you created in 1. to the leader of your working group. Then you can login to the CI/CD dashboard and see the scenario simulation results. 2. Set up a simulation on the cloud platform # TODO 3. Run the scenario simulator on the cloud platform # TODO This is optional if you do NOT need a vehicle-edge platform. \u21a9","title":"Run on the cloud platform"},{"location":"version-2.0/start-guide/how-to-run-simulators/scenario-simulator/run-on-cloud-env/#run-on-the-cloud-platform","text":"This page describes how to run the scenario simulator on the cloud platform. The cloud platform, Web.Auto, is offered by TIER IV , and it is available for the Autoware Foundation members.","title":"Run on the cloud platform"},{"location":"version-2.0/start-guide/how-to-run-simulators/scenario-simulator/run-on-cloud-env/#minimum-requirements","text":"Developer Platform: TODO In-Vehicle Development Platform 1 : TODO Software Tool: TODO Container Image: TODO Data Pipeline: TODO","title":"Minimum requirements"},{"location":"version-2.0/start-guide/how-to-run-simulators/scenario-simulator/run-on-cloud-env/#1-create-your-account-on-the-cloud-platform","text":"If you already have access to Web.Auto, please skip this step.","title":"1. Create your account on the cloud platform"},{"location":"version-2.0/start-guide/how-to-run-simulators/scenario-simulator/run-on-cloud-env/#2-set-up-a-simulation-on-the-cloud-platform","text":"TODO","title":"2. Set up a simulation on the cloud platform"},{"location":"version-2.0/start-guide/how-to-run-simulators/scenario-simulator/run-on-cloud-env/#3-run-the-scenario-simulator-on-the-cloud-platform","text":"TODO This is optional if you do NOT need a vehicle-edge platform. \u21a9","title":"3. Run the scenario simulator on the cloud platform"},{"location":"version-2.0/start-guide/how-to-run-simulators/scenario-simulator/run-on-local-env/","text":"Run on your local environment # This page describes how to run the scenario simulator on the developer platform that is set up in the Installation chapter. Minimum requirements # Developer Platform: TODO In-Vehicle Development Platform 1 : TODO Software Tool: TODO Container Image: TODO Data Pipeline: TODO Run scenario simulator on the developer platform # Launch scenario simulator. rocker --x11 --home --network host --privileged ghcr.io/tier4/scenario_simulator_v2:galactic ros2 launch scenario_test_runner scenario_test_runner.launch.py scenario:=$HOME/Downloads/sample_data/t4v2.yaml architecture_type:=awf/universe launch_rviz:=true launch_autoware:=false record:=false timeout:=60.0 Please specify the path to your scenario file. scenario:=$ HOME/Downloads/sample_data/t4v2.yaml Now you can see... DEMO Video This is optional if you do NOT need a vehicle-edge platform. \u21a9","title":"Run on your local environment"},{"location":"version-2.0/start-guide/how-to-run-simulators/scenario-simulator/run-on-local-env/#run-on-your-local-environment","text":"This page describes how to run the scenario simulator on the developer platform that is set up in the Installation chapter.","title":"Run on your local environment"},{"location":"version-2.0/start-guide/how-to-run-simulators/scenario-simulator/run-on-local-env/#minimum-requirements","text":"Developer Platform: TODO In-Vehicle Development Platform 1 : TODO Software Tool: TODO Container Image: TODO Data Pipeline: TODO","title":"Minimum requirements"},{"location":"version-2.0/start-guide/how-to-run-simulators/scenario-simulator/run-on-local-env/#run-scenario-simulator-on-the-developer-platform","text":"Launch scenario simulator. rocker --x11 --home --network host --privileged ghcr.io/tier4/scenario_simulator_v2:galactic ros2 launch scenario_test_runner scenario_test_runner.launch.py scenario:=$HOME/Downloads/sample_data/t4v2.yaml architecture_type:=awf/universe launch_rviz:=true launch_autoware:=false record:=false timeout:=60.0 Please specify the path to your scenario file. scenario:=$ HOME/Downloads/sample_data/t4v2.yaml Now you can see... DEMO Video This is optional if you do NOT need a vehicle-edge platform. \u21a9","title":"Run scenario simulator on the developer platform"},{"location":"version-2.0/start-guide/how-to-run-simulators/troubleshooting/troubleshooting/","text":"Troubleshooting # Scenario simulator stacks with Simulator waiting for Autoware state to be Initializing # Workaround # Please restart kubernetes pods on the AVA Platform using the kubectl get deploy --output name | grep comhpc | xargs -n1 kubectl rollout restart","title":"Troubleshooting"},{"location":"version-2.0/start-guide/how-to-run-simulators/troubleshooting/troubleshooting/#troubleshooting","text":"","title":"Troubleshooting"},{"location":"version-2.0/start-guide/how-to-run-simulators/troubleshooting/troubleshooting/#scenario-simulator-stacks-with-simulator-waiting-for-autoware-state-to-be-initializing","text":"","title":"Scenario simulator stacks with Simulator waiting for Autoware state to be Initializing"},{"location":"version-2.0/start-guide/how-to-run-simulators/troubleshooting/troubleshooting/#workaround","text":"Please restart kubernetes pods on the AVA Platform using the kubectl get deploy --output name | grep comhpc | xargs -n1 kubectl rollout restart","title":"Workaround"},{"location":"version-2.0/start-guide/installation/","text":"Installation # This page explains how to set up the development environment that are described in the System Configuration chapter. The following contents are diverted from Open AD Kit version 1.0 . These contents will be updated for Open AD Kit version 2.0. Minimum requirements # Developer Platform: AVA Platform or PCU Platform or Xavier Platform In-Vehicle Development Platform 1 : TODO Software Tool: Scenario simulator version 0.6.5+ 2 Rviz version 8.5.1 2 Container Image: Autoware.Universe for arm64 Scenario simulator for x86_64 2 The following diagram shows a minimum configuration of Open AD Kit. \"Your host machine\" will be replaced by the cloud development platform if you can use Web.Auto. 1. Set up the developer platform # The setup procedure depends on the developer platform. AVA Platform # Getting started with EWAOL Boot EWAOL Extend rootfs partition PCU Platform # Getting started with PCU Xavier Platform # Getting started with Xavier 2. Set up the in-vehicle platform # If you do NOT need a vehicle-edge platform, please skip this step. TODO 3. Install Autoware container images on the developer platform # AVA Platform # System setup on AVA Platform PCU Platform # System setup on PCU Xavier Platform # System setup on Xavier Platform 4. Install Autoware container images on the in-vehicle platform # If you do NOT need a vehicle-edge platform, please skip this step. TODO 5. Set up software tools # If you can use the cloud development platform, please skip this step. AVA Platform # System setup on your host PCU Platform # System setup on your host Xavier Platform # System setup on your host 6. Run Autoware on the development platform # Please refer to the How to run Autoware section. 7. Advanced setup # The instructions how to install advanced software such as desktop environment and NVIDIA driver. AVA Platform # Advanced setup for AVA Platform This is unnecessary if you do NOT need a vehicle-edge platform. \u21a9 This is unnecessary if you can use the cloud development platform, Web.Auto. \u21a9 \u21a9 \u21a9","title":"Installation"},{"location":"version-2.0/start-guide/installation/#installation","text":"This page explains how to set up the development environment that are described in the System Configuration chapter. The following contents are diverted from Open AD Kit version 1.0 . These contents will be updated for Open AD Kit version 2.0.","title":"Installation"},{"location":"version-2.0/start-guide/installation/#minimum-requirements","text":"Developer Platform: AVA Platform or PCU Platform or Xavier Platform In-Vehicle Development Platform 1 : TODO Software Tool: Scenario simulator version 0.6.5+ 2 Rviz version 8.5.1 2 Container Image: Autoware.Universe for arm64 Scenario simulator for x86_64 2 The following diagram shows a minimum configuration of Open AD Kit. \"Your host machine\" will be replaced by the cloud development platform if you can use Web.Auto.","title":"Minimum requirements"},{"location":"version-2.0/start-guide/installation/#1-set-up-the-developer-platform","text":"The setup procedure depends on the developer platform.","title":"1. Set up the developer platform"},{"location":"version-2.0/start-guide/installation/#ava-platform","text":"Getting started with EWAOL Boot EWAOL Extend rootfs partition","title":"AVA Platform"},{"location":"version-2.0/start-guide/installation/#pcu-platform","text":"Getting started with PCU","title":"PCU Platform"},{"location":"version-2.0/start-guide/installation/#xavier-platform","text":"Getting started with Xavier","title":"Xavier Platform"},{"location":"version-2.0/start-guide/installation/#2-set-up-the-in-vehicle-platform","text":"If you do NOT need a vehicle-edge platform, please skip this step. TODO","title":"2. Set up the in-vehicle platform"},{"location":"version-2.0/start-guide/installation/#3-install-autoware-container-images-on-the-developer-platform","text":"","title":"3. Install Autoware container images on the developer platform"},{"location":"version-2.0/start-guide/installation/#ava-platform_1","text":"System setup on AVA Platform","title":"AVA Platform"},{"location":"version-2.0/start-guide/installation/#pcu-platform_1","text":"System setup on PCU","title":"PCU Platform"},{"location":"version-2.0/start-guide/installation/#xavier-platform_1","text":"System setup on Xavier Platform","title":"Xavier Platform"},{"location":"version-2.0/start-guide/installation/#4-install-autoware-container-images-on-the-in-vehicle-platform","text":"If you do NOT need a vehicle-edge platform, please skip this step. TODO","title":"4. Install Autoware container images on the in-vehicle platform"},{"location":"version-2.0/start-guide/installation/#5-set-up-software-tools","text":"If you can use the cloud development platform, please skip this step.","title":"5. Set up software tools"},{"location":"version-2.0/start-guide/installation/#ava-platform_2","text":"System setup on your host","title":"AVA Platform"},{"location":"version-2.0/start-guide/installation/#pcu-platform_2","text":"System setup on your host","title":"PCU Platform"},{"location":"version-2.0/start-guide/installation/#xavier-platform_2","text":"System setup on your host","title":"Xavier Platform"},{"location":"version-2.0/start-guide/installation/#6-run-autoware-on-the-development-platform","text":"Please refer to the How to run Autoware section.","title":"6. Run Autoware on the development platform"},{"location":"version-2.0/start-guide/installation/#7-advanced-setup","text":"The instructions how to install advanced software such as desktop environment and NVIDIA driver.","title":"7. Advanced setup"},{"location":"version-2.0/start-guide/installation/#ava-platform_3","text":"Advanced setup for AVA Platform This is unnecessary if you do NOT need a vehicle-edge platform. \u21a9 This is unnecessary if you can use the cloud development platform, Web.Auto. \u21a9 \u21a9 \u21a9","title":"AVA Platform"},{"location":"version-2.0/start-guide/installation/advanced-setup-setup-ava/","text":"Advanced setup for AVA Platform # Overview # This instruction explains how to install advanced software for AVA platform. Desktop environment(XFCE) NVIDIA driver NVIDIA Container Toolkit Checkout the repository for AVA platform # m5p3nc3r / meta-ewaol-machine git clone git@github.com:m5p3nc3r/meta-ewaol-machine.git -b kirkstone-dev Copy meta-ewaol-ext directory to the project root. cp -rf meta-ewaol-machine/meta-ewaol-ext ~/meta-adlink-ampere Download a missing patch in meta-ewaol-ext layer. wget -P ~/meta-adlink-ampere/meta-ewaol-ext/recipes-ewaol/recipes-container/nvidia-container-toolkit/files https://raw.githubusercontent.com/autowarefoundation/open-ad-kit-docs/main/docs/version-2.0/start-guide/installation/patch/0002-TEMPORARY-force-aarch64-rpm.patch Modify ava.yml . header: version: 1 includes: - repo: meta-ewaol - file: meta-ewaol-config/kas/baremetal.yml + file: meta-ewaol-config/kas/baremetal-sdk.yml repos: meta-ewaol: path: meta-ewaol meta-adlink-ampere: +meta-openembedded: + path: layers/meta-openembedded + layers: + meta-oe: + meta-gnome: + meta-multimedia: + meta-xfce: + +meta-ewaol-ext: + path: meta-ewaol-ext machine: ava bblayers_conf_header: base: | POKY_BBLAYERS_CONF_VERSION = \"2\" BBPATH = \"${TOPDIR}\" BBFILES ?= \"\" +local_conf_header: +meta-at: | + XSERVER:append = \" xserver-xorg-extension-glx xserver-xorg-module-libwfb xserver-xorg-module-exa\" + IMAGE_INSTALL:append = \" packagegroup-core-x11 packagegroup-xfce-extended acpid xf86-video-modesetting mesa-demos nvidia-container-toolkit\" + DISTRO_FEATURES:append = \" opengl x11 glx\" + PACKAGECONFIG:append:pn-xserver-xorg = \" xinerama\" + IMAGE_FEATURES:append =\" x11 x11-base\" + INSANE_SKIP:${PN}:append = \" already-stripped\" + FILES:${PN}:append =\" /usr/share/containers/oci/hooks.d/oci-nvidia-hook.json\" target: -- ewaol-baremetal-image +- ewaol-baremetal-sdk-image Build via kas. kas build ava.yml Flash yocto image # For example; sudo bmaptool copy --bmap build/tmp_baremetal/deploy/images/ava/ewaol-baremetal-sdk-image-ava.wic.bmap build/tmp_baremetal/deploy/images/ava/ewaol-baremetal-sdk-image-ava.wic.gz /dev/sdb Extend rootfs partition # Follow the instructions Extend rootfs partition . Boot your machine # You can see XFCE desktop. NVIDIA driver installation # Create the files required for compiling external modules. cd /usr/src/kernel make modules_prepare Check NVIDIA graphics card. lspci | grep -i nvidia You can find a NVIDIA graphics card such as GeForce RTX 3070 Ti . 000d:01:00.0 VGA compatible controller: NVIDIA Corporation GA104 [GeForce RTX 3070 Ti] (rev a1) 000d:01:00.1 Audio device: NVIDIA Corporation GA104 High Definition Audio Controller (rev a1) Open the URL in browser. Official Drivers NVIDIA Select your graphics card, then click SEARCH . Click DOWNLOAD . Copy link to the file. Download NVIDIA driver on AVA platform. For example; wget https://jp.download.nvidia.com/XFree86/aarch64/515.65.01/NVIDIA-Linux-aarch64-515.65.01.run chmod +x NVIDIA-Linux-aarch64-515.65.01.run Stop display manager to install NVIDIA driver. systemctl stop xserver-nodm Install NVIDIA driver. For example; ./NVIDIA-Linux-aarch64-515.65.01.run Building kernel module starts. Press to select Yes and then press . Press . Change display output from motherboard to GPU # You are using VGA, so switch to GPU . Turn off AVA platform Connect HDMI or Display Port from your graphics card to your monitor. Change display mode to HDMI or Display Port on your monitor if needed. Turn on AVA platform, then the desktop window will be shown via GPU . Confirm nvidia-docker works (Optional) # You can confirm nvidia-docker works by the following command. docker run --gpus all --rm nvidia/cuda-arm64:11.4.0-base nvidia-smi You can see the outputs like below. root@ava:~# docker run --gpus all --rm nvidia/cuda-arm64:11.4.0-base nvidia-smi Unable to find image 'nvidia/cuda-arm64:11.4.0-base' locally 11.4.0-base: Pulling from nvidia/cuda-arm64 55c604a74c4b: Pull complete 657fae4b9575: Pull complete b2cf3c1bfea9: Pull complete 71492f856142: Pull complete c74b3fce51ac: Pull complete Digest: sha256:625c8265d0f88d4250d48958113f1184f96db794fbe5d6d5cdd782f9916ec718 Status: Downloaded newer image for nvidia/cuda-arm64:11.4.0-base Thu Aug 25 23:17:40 2022 +-----------------------------------------------------------------------------+ | NVIDIA-SMI 515.65.01 Driver Version: 515.65.01 CUDA Version: 11.7 | |-------------------------------+----------------------+----------------------+ | GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC | | Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. | | | | MIG M. | |===============================+======================+======================| | 0 NVIDIA GeForce ... Off | 0000000D:01:00.0 On | N/A | | 0% 35C P8 18W / 290W | 234MiB / 8192MiB | 0% Default | | | | N/A | +-------------------------------+----------------------+----------------------+ +-----------------------------------------------------------------------------+ | Processes: | | GPU GI CI PID Type Process name GPU Memory | | ID ID Usage | |=============================================================================| +-----------------------------------------------------------------------------+","title":"Advanced setup for AVA Platform"},{"location":"version-2.0/start-guide/installation/advanced-setup-setup-ava/#advanced-setup-for-ava-platform","text":"","title":"Advanced setup for AVA Platform"},{"location":"version-2.0/start-guide/installation/advanced-setup-setup-ava/#overview","text":"This instruction explains how to install advanced software for AVA platform. Desktop environment(XFCE) NVIDIA driver NVIDIA Container Toolkit","title":"Overview"},{"location":"version-2.0/start-guide/installation/advanced-setup-setup-ava/#checkout-the-repository-for-ava-platform","text":"m5p3nc3r / meta-ewaol-machine git clone git@github.com:m5p3nc3r/meta-ewaol-machine.git -b kirkstone-dev Copy meta-ewaol-ext directory to the project root. cp -rf meta-ewaol-machine/meta-ewaol-ext ~/meta-adlink-ampere Download a missing patch in meta-ewaol-ext layer. wget -P ~/meta-adlink-ampere/meta-ewaol-ext/recipes-ewaol/recipes-container/nvidia-container-toolkit/files https://raw.githubusercontent.com/autowarefoundation/open-ad-kit-docs/main/docs/version-2.0/start-guide/installation/patch/0002-TEMPORARY-force-aarch64-rpm.patch Modify ava.yml . header: version: 1 includes: - repo: meta-ewaol - file: meta-ewaol-config/kas/baremetal.yml + file: meta-ewaol-config/kas/baremetal-sdk.yml repos: meta-ewaol: path: meta-ewaol meta-adlink-ampere: +meta-openembedded: + path: layers/meta-openembedded + layers: + meta-oe: + meta-gnome: + meta-multimedia: + meta-xfce: + +meta-ewaol-ext: + path: meta-ewaol-ext machine: ava bblayers_conf_header: base: | POKY_BBLAYERS_CONF_VERSION = \"2\" BBPATH = \"${TOPDIR}\" BBFILES ?= \"\" +local_conf_header: +meta-at: | + XSERVER:append = \" xserver-xorg-extension-glx xserver-xorg-module-libwfb xserver-xorg-module-exa\" + IMAGE_INSTALL:append = \" packagegroup-core-x11 packagegroup-xfce-extended acpid xf86-video-modesetting mesa-demos nvidia-container-toolkit\" + DISTRO_FEATURES:append = \" opengl x11 glx\" + PACKAGECONFIG:append:pn-xserver-xorg = \" xinerama\" + IMAGE_FEATURES:append =\" x11 x11-base\" + INSANE_SKIP:${PN}:append = \" already-stripped\" + FILES:${PN}:append =\" /usr/share/containers/oci/hooks.d/oci-nvidia-hook.json\" target: -- ewaol-baremetal-image +- ewaol-baremetal-sdk-image Build via kas. kas build ava.yml","title":"Checkout the repository for AVA platform"},{"location":"version-2.0/start-guide/installation/advanced-setup-setup-ava/#flash-yocto-image","text":"For example; sudo bmaptool copy --bmap build/tmp_baremetal/deploy/images/ava/ewaol-baremetal-sdk-image-ava.wic.bmap build/tmp_baremetal/deploy/images/ava/ewaol-baremetal-sdk-image-ava.wic.gz /dev/sdb","title":"Flash yocto image"},{"location":"version-2.0/start-guide/installation/advanced-setup-setup-ava/#extend-rootfs-partition","text":"Follow the instructions Extend rootfs partition .","title":"Extend rootfs partition"},{"location":"version-2.0/start-guide/installation/advanced-setup-setup-ava/#boot-your-machine","text":"You can see XFCE desktop.","title":"Boot your machine"},{"location":"version-2.0/start-guide/installation/advanced-setup-setup-ava/#nvidia-driver-installation","text":"Create the files required for compiling external modules. cd /usr/src/kernel make modules_prepare Check NVIDIA graphics card. lspci | grep -i nvidia You can find a NVIDIA graphics card such as GeForce RTX 3070 Ti . 000d:01:00.0 VGA compatible controller: NVIDIA Corporation GA104 [GeForce RTX 3070 Ti] (rev a1) 000d:01:00.1 Audio device: NVIDIA Corporation GA104 High Definition Audio Controller (rev a1) Open the URL in browser. Official Drivers NVIDIA Select your graphics card, then click SEARCH . Click DOWNLOAD . Copy link to the file. Download NVIDIA driver on AVA platform. For example; wget https://jp.download.nvidia.com/XFree86/aarch64/515.65.01/NVIDIA-Linux-aarch64-515.65.01.run chmod +x NVIDIA-Linux-aarch64-515.65.01.run Stop display manager to install NVIDIA driver. systemctl stop xserver-nodm Install NVIDIA driver. For example; ./NVIDIA-Linux-aarch64-515.65.01.run Building kernel module starts. Press to select Yes and then press . Press .","title":"NVIDIA driver installation"},{"location":"version-2.0/start-guide/installation/advanced-setup-setup-ava/#change-display-output-from-motherboard-to-gpu","text":"You are using VGA, so switch to GPU . Turn off AVA platform Connect HDMI or Display Port from your graphics card to your monitor. Change display mode to HDMI or Display Port on your monitor if needed. Turn on AVA platform, then the desktop window will be shown via GPU .","title":"Change display output from motherboard to GPU"},{"location":"version-2.0/start-guide/installation/advanced-setup-setup-ava/#confirm-nvidia-docker-works-optional","text":"You can confirm nvidia-docker works by the following command. docker run --gpus all --rm nvidia/cuda-arm64:11.4.0-base nvidia-smi You can see the outputs like below. root@ava:~# docker run --gpus all --rm nvidia/cuda-arm64:11.4.0-base nvidia-smi Unable to find image 'nvidia/cuda-arm64:11.4.0-base' locally 11.4.0-base: Pulling from nvidia/cuda-arm64 55c604a74c4b: Pull complete 657fae4b9575: Pull complete b2cf3c1bfea9: Pull complete 71492f856142: Pull complete c74b3fce51ac: Pull complete Digest: sha256:625c8265d0f88d4250d48958113f1184f96db794fbe5d6d5cdd782f9916ec718 Status: Downloaded newer image for nvidia/cuda-arm64:11.4.0-base Thu Aug 25 23:17:40 2022 +-----------------------------------------------------------------------------+ | NVIDIA-SMI 515.65.01 Driver Version: 515.65.01 CUDA Version: 11.7 | |-------------------------------+----------------------+----------------------+ | GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC | | Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. | | | | MIG M. | |===============================+======================+======================| | 0 NVIDIA GeForce ... Off | 0000000D:01:00.0 On | N/A | | 0% 35C P8 18W / 290W | 234MiB / 8192MiB | 0% Default | | | | N/A | +-------------------------------+----------------------+----------------------+ +-----------------------------------------------------------------------------+ | Processes: | | GPU GI CI PID Type Process name GPU Memory | | ID ID Usage | |=============================================================================| +-----------------------------------------------------------------------------+","title":"Confirm nvidia-docker works (Optional)"},{"location":"version-2.0/start-guide/installation/boot-ewaol/","text":"Boot EWAOL # Overview # You need to use SSD enclosure case to flash yocto image to M.2 SSD directly. Flash yocto image # Remove M.2 SSD from AVA platform and flash yocto image to it directly. Remove M.2 SSD from AVA platform. Install M.2 SSD into a M.2 enclosure case. Plug it into your host machine. Then, show available block devices. lsblk -p NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT ... /dev/sdb 8:0 0 119.2G 0 disk \u251c\u2500sdb1 8:1 0 512M 0 part \u251c\u2500sdb2 8:2 0 1G 0 part /media/foo/7d00c690-db24-462d-8c8d-dce7bdf151d8 \u2514\u2500sdb3 8:3 0 117.8G 0 part Flush yocto image to M.2 SSD. For example sudo bmaptool copy --bmap build/tmp_baremetal/deploy/images/ava/ewaol-baremetal-image-ava.wic.bmap build/tmp_baremetal/deploy/images/ava/ewaol-baremetal-image-ava.wic.gz /dev/sdb Extend rootfs partition # You have to extend rootfs partition. Follow the instructions Extend rootfs partition Reinstall SSD # Remove M.2 SSD from enclosure case and install it into AVA platform, then turn it on. The following screen comes up, then login as root without password. EWAOL (Edge Workload Abstraction and Orchestration Layer) v1.0 ava - ava login: You are able to access via SSH.","title":"Boot EWAOL"},{"location":"version-2.0/start-guide/installation/boot-ewaol/#boot-ewaol","text":"","title":"Boot EWAOL"},{"location":"version-2.0/start-guide/installation/boot-ewaol/#overview","text":"You need to use SSD enclosure case to flash yocto image to M.2 SSD directly.","title":"Overview"},{"location":"version-2.0/start-guide/installation/boot-ewaol/#flash-yocto-image","text":"Remove M.2 SSD from AVA platform and flash yocto image to it directly. Remove M.2 SSD from AVA platform. Install M.2 SSD into a M.2 enclosure case. Plug it into your host machine. Then, show available block devices. lsblk -p NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT ... /dev/sdb 8:0 0 119.2G 0 disk \u251c\u2500sdb1 8:1 0 512M 0 part \u251c\u2500sdb2 8:2 0 1G 0 part /media/foo/7d00c690-db24-462d-8c8d-dce7bdf151d8 \u2514\u2500sdb3 8:3 0 117.8G 0 part Flush yocto image to M.2 SSD. For example sudo bmaptool copy --bmap build/tmp_baremetal/deploy/images/ava/ewaol-baremetal-image-ava.wic.bmap build/tmp_baremetal/deploy/images/ava/ewaol-baremetal-image-ava.wic.gz /dev/sdb","title":"Flash yocto image"},{"location":"version-2.0/start-guide/installation/boot-ewaol/#extend-rootfs-partition","text":"You have to extend rootfs partition. Follow the instructions Extend rootfs partition","title":"Extend rootfs partition"},{"location":"version-2.0/start-guide/installation/boot-ewaol/#reinstall-ssd","text":"Remove M.2 SSD from enclosure case and install it into AVA platform, then turn it on. The following screen comes up, then login as root without password. EWAOL (Edge Workload Abstraction and Orchestration Layer) v1.0 ava - ava login: You are able to access via SSH.","title":"Reinstall SSD"},{"location":"version-2.0/start-guide/installation/extend-rootfs/","text":"Extend rootfs partition # Overview # The rootfs partition is not fully occupied on M.2 SSD, and the size is too short to run k3s clusters. So we have to extend rootfs partition. Here is the instruction how to extend rootfs partition Extend rootfs # Run gparted . You may get the following warning when you run gparted . Press Fix . Contents of storage after we flashed yocto image to M.2 SSD. Extend rootfs partition to the end of disk. Right click root partition, then click Resize/Move . Extend the square to the right end. Then, click Resize/Move . Apply changes. Click check mark icon. Click Apply . Click Close . You can get rootfs as follows.","title":"Extend rootfs partition"},{"location":"version-2.0/start-guide/installation/extend-rootfs/#extend-rootfs-partition","text":"","title":"Extend rootfs partition"},{"location":"version-2.0/start-guide/installation/extend-rootfs/#overview","text":"The rootfs partition is not fully occupied on M.2 SSD, and the size is too short to run k3s clusters. So we have to extend rootfs partition. Here is the instruction how to extend rootfs partition","title":"Overview"},{"location":"version-2.0/start-guide/installation/extend-rootfs/#extend-rootfs","text":"Run gparted . You may get the following warning when you run gparted . Press Fix . Contents of storage after we flashed yocto image to M.2 SSD. Extend rootfs partition to the end of disk. Right click root partition, then click Resize/Move . Extend the square to the right end. Then, click Resize/Move . Apply changes. Click check mark icon. Click Apply . Click Close . You can get rootfs as follows.","title":"Extend rootfs"},{"location":"version-2.0/start-guide/installation/getting-started-pcu/","text":"Getting started with PCU # Overview # Reference: PCU Setup Guide This instruction explains how to boot up Ubuntu on PCU and access it from host PC. If you are using onboard 64G EMMC as boot device, it's already been pre-installed with Ubuntu 20.04, and you can skip this step; If you would like to boot from SD card, you could either request a Micro SD card with pre-installed system or flash by yourself under instructions in below section. Ubuntu 20.04 is preferred. Hardware Setup # The minimum recommended External Micro SD card size is 64GB, and the speed should be at least class 10 A1, it is strongly recommended to use high speed SD card, e.g. class U3, A2. To boot from SD card, \"SW1\" should be set as: ON , and SD card should be plugged in. For blank SD card, the system image need to be flashed first using another PC. Get MPU image # Official images with recommended OS are available on PCU Resource Download page. Resource Download Page For PCU 2.0 hardware, please download the MPU image file for SD card as marked red to your local storage. Flash MPU image # To flash MPU image on SD card, you will need a PC with a micro SD card reader. This step could be done on either Windows or Linux PC with different flash tools. Linux will be used in this instruction as example: Insert card reader with target micro SD card to host PC. Find out device name for the SD card. sudo lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT ... sda 8:0 0 238.5G 0 disk \u251c\u2500sda1 8:1 0 512M 0 part /boot/efi \u2514\u2500sda2 8:2 0 238G 0 part / sdb 8:16 0 447.1G 0 disk \u251c\u2500sdb1 8:17 0 428.4G 0 part \u251c\u2500sdb2 8:18 0 513M 0 part \u2514\u2500sdb3 8:19 0 18.2G 0 part sdc 8:32 1 14.9G 0 disk \u2514\u2500sdc1 8:33 1 14.9G 0 part /media/adlink/B4A1-62CD In this case, sdc is the device name Flash image to SD card. sudo gzip -dc YOUR-DOWNLOAD-PATH/xxx.gz |sudo dd of=/dev/YOUR-DEVICE For example; sudo gzip -dc ~/Downloads/autocore-1046-ubuntu20.04-sd-pcu2.0-sw0.5.0-20201210.gz |sudo dd of=/dev/sdc Wait patiently until the flash process finishes, this may take up to half hour. Boot up. Now you can plug in the SD card to PCU and power up. The system should be ready to work. Connect To PCU via SSH # You could connect to PCU via SSh either by ethernet or serial port. The default username, password and IP address of PCU is as below: SSH through ethernet # Cable connection Connect host PC to RJ45 2 / RJ45 3 / RJ45 4 Eth port (Blue) on PCU board with Ethernet cable (GbE, need Cat.5e or above). Configure static IP for host PC You need to manually configure static IP for PC in order to connect with PCU, as there is no DHCP server running on PCU. The static IP should be different with PCU and within the same network segment. (e.g. 192.168.1.200) SSH login ssh user@192.168.1.239 SSH through Serial Port # Cable connection As an alternative, you could also choose to connect to PCU by micro USB (ttyUSB port in figure blow). ttyUSB Settings For Linux users, you could use \"cutecom\" to connect to PCU. sudo apt install cutecom cutecom Please set parameters as follows, Device shall be chosen based on your host PC. For other system users, the parameters are: Parameter Value Baudrate 115200 Data 8 Stop bit 1 Parity None Hardware flow control no Software flow control no Reset PCU and Login Press reset button and wait until login. ssh user@192.168.1.239 Check PCU public IP Address # Connect PCU to internet via RJ45 1 Eth port (Red), this Eth port is configured to obtain IP address automatically from DHCP by default. From section above, you can SSH connect to PCU, and you can look for IP address of the public ethernet port(fm1-mac5). ifconfig fm1-mac5 fm1-mac5: flags=4163 mtu 1500 inet 192.168.10.221 netmask 255.255.255.0 broadcast 192.168.10.255 inet6 fe80::204:7cff:fe2e:191 prefixlen 64 scopeid 0x20 ether 00:04:7c:2e:01:91 txqueuelen 1000 (Ethernet) RX packets 2806 bytes 3665212 (3.6 MB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 2238 bytes 175964 (175.9 KB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 device memory 0x1ae8000-1ae8fff You can find IP address of PCU such as 192.168.10.221 .","title":"Getting started with PCU"},{"location":"version-2.0/start-guide/installation/getting-started-pcu/#getting-started-with-pcu","text":"","title":"Getting started with PCU"},{"location":"version-2.0/start-guide/installation/getting-started-pcu/#overview","text":"Reference: PCU Setup Guide This instruction explains how to boot up Ubuntu on PCU and access it from host PC. If you are using onboard 64G EMMC as boot device, it's already been pre-installed with Ubuntu 20.04, and you can skip this step; If you would like to boot from SD card, you could either request a Micro SD card with pre-installed system or flash by yourself under instructions in below section. Ubuntu 20.04 is preferred.","title":"Overview"},{"location":"version-2.0/start-guide/installation/getting-started-pcu/#hardware-setup","text":"The minimum recommended External Micro SD card size is 64GB, and the speed should be at least class 10 A1, it is strongly recommended to use high speed SD card, e.g. class U3, A2. To boot from SD card, \"SW1\" should be set as: ON , and SD card should be plugged in. For blank SD card, the system image need to be flashed first using another PC.","title":"Hardware Setup"},{"location":"version-2.0/start-guide/installation/getting-started-pcu/#get-mpu-image","text":"Official images with recommended OS are available on PCU Resource Download page. Resource Download Page For PCU 2.0 hardware, please download the MPU image file for SD card as marked red to your local storage.","title":"Get MPU image"},{"location":"version-2.0/start-guide/installation/getting-started-pcu/#flash-mpu-image","text":"To flash MPU image on SD card, you will need a PC with a micro SD card reader. This step could be done on either Windows or Linux PC with different flash tools. Linux will be used in this instruction as example: Insert card reader with target micro SD card to host PC. Find out device name for the SD card. sudo lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT ... sda 8:0 0 238.5G 0 disk \u251c\u2500sda1 8:1 0 512M 0 part /boot/efi \u2514\u2500sda2 8:2 0 238G 0 part / sdb 8:16 0 447.1G 0 disk \u251c\u2500sdb1 8:17 0 428.4G 0 part \u251c\u2500sdb2 8:18 0 513M 0 part \u2514\u2500sdb3 8:19 0 18.2G 0 part sdc 8:32 1 14.9G 0 disk \u2514\u2500sdc1 8:33 1 14.9G 0 part /media/adlink/B4A1-62CD In this case, sdc is the device name Flash image to SD card. sudo gzip -dc YOUR-DOWNLOAD-PATH/xxx.gz |sudo dd of=/dev/YOUR-DEVICE For example; sudo gzip -dc ~/Downloads/autocore-1046-ubuntu20.04-sd-pcu2.0-sw0.5.0-20201210.gz |sudo dd of=/dev/sdc Wait patiently until the flash process finishes, this may take up to half hour. Boot up. Now you can plug in the SD card to PCU and power up. The system should be ready to work.","title":"Flash MPU image"},{"location":"version-2.0/start-guide/installation/getting-started-pcu/#connect-to-pcu-via-ssh","text":"You could connect to PCU via SSh either by ethernet or serial port. The default username, password and IP address of PCU is as below:","title":"Connect To PCU via SSH"},{"location":"version-2.0/start-guide/installation/getting-started-pcu/#ssh-through-ethernet","text":"Cable connection Connect host PC to RJ45 2 / RJ45 3 / RJ45 4 Eth port (Blue) on PCU board with Ethernet cable (GbE, need Cat.5e or above). Configure static IP for host PC You need to manually configure static IP for PC in order to connect with PCU, as there is no DHCP server running on PCU. The static IP should be different with PCU and within the same network segment. (e.g. 192.168.1.200) SSH login ssh user@192.168.1.239","title":"SSH through ethernet"},{"location":"version-2.0/start-guide/installation/getting-started-pcu/#ssh-through-serial-port","text":"Cable connection As an alternative, you could also choose to connect to PCU by micro USB (ttyUSB port in figure blow). ttyUSB Settings For Linux users, you could use \"cutecom\" to connect to PCU. sudo apt install cutecom cutecom Please set parameters as follows, Device shall be chosen based on your host PC. For other system users, the parameters are: Parameter Value Baudrate 115200 Data 8 Stop bit 1 Parity None Hardware flow control no Software flow control no Reset PCU and Login Press reset button and wait until login. ssh user@192.168.1.239","title":"SSH through Serial Port"},{"location":"version-2.0/start-guide/installation/getting-started-pcu/#check-pcu-public-ip-address","text":"Connect PCU to internet via RJ45 1 Eth port (Red), this Eth port is configured to obtain IP address automatically from DHCP by default. From section above, you can SSH connect to PCU, and you can look for IP address of the public ethernet port(fm1-mac5). ifconfig fm1-mac5 fm1-mac5: flags=4163 mtu 1500 inet 192.168.10.221 netmask 255.255.255.0 broadcast 192.168.10.255 inet6 fe80::204:7cff:fe2e:191 prefixlen 64 scopeid 0x20 ether 00:04:7c:2e:01:91 txqueuelen 1000 (Ethernet) RX packets 2806 bytes 3665212 (3.6 MB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 2238 bytes 175964 (175.9 KB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 device memory 0x1ae8000-1ae8fff You can find IP address of PCU such as 192.168.10.221 .","title":"Check PCU public IP Address"},{"location":"version-2.0/start-guide/installation/getting-started-xavier/","text":"Getting started with Xavier # Overview # Reference: Jetson AGX Xavier Developer Kit User Guide This instruction explains how to boot up Ubuntu on Xavier and access it from host PC. Connect To Xavier via SSH # Connect Xavier to internet, this network port is configured to obtain IP address automatically from DHCP by default. You can look for IP address of the public ethernet and connect to Xavier via SSH. ifconfig docker0: flags=4099 mtu 1500 inet 172.17.0.1 netmask 255.255.0.0 broadcast 172.17.255.255 ether 02:42:1c:6c:b1:ec txqueuelen 0 (Ethernet) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 eth0: flags=4099 mtu 1500 ether 48:b0:2d:2b:7a:a8 txqueuelen 1000 (Ethernet) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 eth1: flags=4163 mtu 1500 inet 192.168.10.46 netmask 255.255.252.0 broadcast 192.168.11.255 inet6 fe80::9fcb:8fc6:a1a4:c6d2 prefixlen 64 scopeid 0x20 ether 2c:16:db:a3:03:10 txqueuelen 1000 (Ethernet) RX packets 4946 bytes 6212659 (6.2 MB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 723 bytes 72036 (72.0 KB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 lo: flags=73 mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 inet6 ::1 prefixlen 128 scopeid 0x10 loop txqueuelen 1000 (Local Loopback) RX packets 218 bytes 20064 (20.0 KB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 218 bytes 20064 (20.0 KB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 rndis0: flags=4099 mtu 1500 ether 82:24:ce:68:6a:bd txqueuelen 1000 (Ethernet) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 usb0: flags=4099 mtu 1500 ether 82:24:ce:68:6a:bf txqueuelen 1000 (Ethernet) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 You can find IP address of Xavier such as 192.168.10.46 .","title":"Getting started with Xavier"},{"location":"version-2.0/start-guide/installation/getting-started-xavier/#getting-started-with-xavier","text":"","title":"Getting started with Xavier"},{"location":"version-2.0/start-guide/installation/getting-started-xavier/#overview","text":"Reference: Jetson AGX Xavier Developer Kit User Guide This instruction explains how to boot up Ubuntu on Xavier and access it from host PC.","title":"Overview"},{"location":"version-2.0/start-guide/installation/getting-started-xavier/#connect-to-xavier-via-ssh","text":"Connect Xavier to internet, this network port is configured to obtain IP address automatically from DHCP by default. You can look for IP address of the public ethernet and connect to Xavier via SSH. ifconfig docker0: flags=4099 mtu 1500 inet 172.17.0.1 netmask 255.255.0.0 broadcast 172.17.255.255 ether 02:42:1c:6c:b1:ec txqueuelen 0 (Ethernet) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 eth0: flags=4099 mtu 1500 ether 48:b0:2d:2b:7a:a8 txqueuelen 1000 (Ethernet) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 eth1: flags=4163 mtu 1500 inet 192.168.10.46 netmask 255.255.252.0 broadcast 192.168.11.255 inet6 fe80::9fcb:8fc6:a1a4:c6d2 prefixlen 64 scopeid 0x20 ether 2c:16:db:a3:03:10 txqueuelen 1000 (Ethernet) RX packets 4946 bytes 6212659 (6.2 MB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 723 bytes 72036 (72.0 KB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 lo: flags=73 mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 inet6 ::1 prefixlen 128 scopeid 0x10 loop txqueuelen 1000 (Local Loopback) RX packets 218 bytes 20064 (20.0 KB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 218 bytes 20064 (20.0 KB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 rndis0: flags=4099 mtu 1500 ether 82:24:ce:68:6a:bd txqueuelen 1000 (Ethernet) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 usb0: flags=4099 mtu 1500 ether 82:24:ce:68:6a:bf txqueuelen 1000 (Ethernet) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 You can find IP address of Xavier such as 192.168.10.46 .","title":"Connect To Xavier via SSH"},{"location":"version-2.0/start-guide/installation/getting-started/","text":"Getting started with EWAOL # Overview # Reference: Project Quickstart \u2014 EWAOL documentation This instruction explains how to build yocto image with EWAOL on your host machine. Build Host Setup # Install required packages for the build host by following The Yocto Project \u00ae 3.3.1 documentation . sudo apt-get install gawk wget git diffstat unzip texinfo gcc build-essential chrpath socat cpio python3 python3-pip python3-pexpect xz-utils debianutils iputils-ping python3-git python3-jinja2 libegl1-mesa libsdl1.2-dev pylint3 xterm python3-subunit mesa-common-dev Install the kas setup tool. sudo -H pip3 install kas Checkout the repository for AVA platform # ADLINK / meta-adlink-ampere git clone https://github.com/ADLINK/meta-adlink-ampere.git -b kirkstone EWAOL / meta-ewaol cd meta-adlink-ampere git clone https://git.gitlab.arm.com/ewaol/meta-ewaol.git -b v1.0 Replace virtualization with baremetal in ava.yml . header: version: 1 includes: - repo: meta-ewaol - file: meta-ewaol-config/kas/virtualization.yml + file: meta-ewaol-config/kas/baremetal.yml repos: meta-ewaol: path: meta-ewaol meta-adlink-ampere: machine: ava bblayers_conf_header: base: | POKY_BBLAYERS_CONF_VERSION = \"2\" BBPATH = \"${TOPDIR}\" BBFILES ?= \"\" target: - - ewaol-virtualization-image + - ewaol-baremetal-image Build via kas kas build ava.yml You should be careful of utilizing full CPU power during build.","title":"Getting started with EWAOL"},{"location":"version-2.0/start-guide/installation/getting-started/#getting-started-with-ewaol","text":"","title":"Getting started with EWAOL"},{"location":"version-2.0/start-guide/installation/getting-started/#overview","text":"Reference: Project Quickstart \u2014 EWAOL documentation This instruction explains how to build yocto image with EWAOL on your host machine.","title":"Overview"},{"location":"version-2.0/start-guide/installation/getting-started/#build-host-setup","text":"Install required packages for the build host by following The Yocto Project \u00ae 3.3.1 documentation . sudo apt-get install gawk wget git diffstat unzip texinfo gcc build-essential chrpath socat cpio python3 python3-pip python3-pexpect xz-utils debianutils iputils-ping python3-git python3-jinja2 libegl1-mesa libsdl1.2-dev pylint3 xterm python3-subunit mesa-common-dev Install the kas setup tool. sudo -H pip3 install kas","title":"Build Host Setup"},{"location":"version-2.0/start-guide/installation/getting-started/#checkout-the-repository-for-ava-platform","text":"ADLINK / meta-adlink-ampere git clone https://github.com/ADLINK/meta-adlink-ampere.git -b kirkstone EWAOL / meta-ewaol cd meta-adlink-ampere git clone https://git.gitlab.arm.com/ewaol/meta-ewaol.git -b v1.0 Replace virtualization with baremetal in ava.yml . header: version: 1 includes: - repo: meta-ewaol - file: meta-ewaol-config/kas/virtualization.yml + file: meta-ewaol-config/kas/baremetal.yml repos: meta-ewaol: path: meta-ewaol meta-adlink-ampere: machine: ava bblayers_conf_header: base: | POKY_BBLAYERS_CONF_VERSION = \"2\" BBPATH = \"${TOPDIR}\" BBFILES ?= \"\" target: - - ewaol-virtualization-image + - ewaol-baremetal-image Build via kas kas build ava.yml You should be careful of utilizing full CPU power during build.","title":"Checkout the repository for AVA platform"},{"location":"version-2.0/start-guide/installation/system-setup-ava/","text":"System Setup on AVA platform # Overview # This instruction explains how to perform system setup for test execution on AVA platform. Access to AVA platform via SSH # ssh root@IP-ADDRESS For example; ssh root@192.168.0.62 Download kubernetes yaml files # Autoware.Universe runs as k3s clusters in Open AD Kit, so please download kubernetes yaml files to deploy Autoware to AVA platform. Download. wget https://raw.githubusercontent.com/autowarefoundation/open-ad-kit-docs/main/docs/version-2.0/start-guide/installation/deployments/comhpc-deployments.zip Unzip it. unzip comhpc-deployments.zip -d comhpc-deployments You will see the following files are unzipped. Archive: comhpc-deployments.zip inflating: comhpc-api-deployment.yaml inflating: comhpc-control-deployment.yaml inflating: comhpc-map-deployment.yaml inflating: comhpc-persistent-volume.yaml inflating: comhpc-persistent-volume-claim.yaml inflating: comhpc-planning-deployment.yaml inflating: comhpc-simulator-deployment.yaml inflating: comhpc-system-deployment.yaml inflating: comhpc-vehicle-deployment.yaml Download map files # Download from Google Drive. wget \"https://drive.google.com/uc?export=download&id=1vWMLbmwJJE5tYO40ypCMxqtmgQPQxhiw&confirm=t&uuid=3d84d854-3dd2-4950-8cc8-248feeab547d\" -O sample_data.zip Unzip it. unzip sample_data.zip Move map directory from sample_data . mv sample_data/map/ ~/ You will see the following files are located. root@ava:~# ls -la ~/map total 61288 drwxrwxr-x 2 root root 4096 Aug 18 06:23 . drwx------ 6 root root 4096 Aug 18 06:23 .. -rw-r--r-- 1 root root 1841436 Aug 18 06:23 lanelet2_map.osm -rw-r--r-- 1 root root 60904720 Aug 18 06:23 pointcloud_map.pcd Download kernel configuration file for tuning kernel parameters # We have to reconfigure kernel parameters by using sysctl for system stability. Download. wget -P /etc/sysctl.d https://raw.githubusercontent.com/autowarefoundation/open-ad-kit-docs/main/docs/version-2.0/start-guide/installation/sysctl.d/60_cyclonedds.conf Update kernel parameters. sysctl -p /etc/sysctl.d/60_cyclonedds.conf Download configuration file of Cyclone DDS # In this test, we are using Cyclone DDS, so you also need to download configuration file of Cyclone DDS. Download cyclonedds.xml . wget -P ~/cyclonedds https://raw.githubusercontent.com/autowarefoundation/open-ad-kit-docs/main/docs/version-2.0/start-guide/installation/cyclonedds/cyclonedds.xml Modify cyclonedds.xml # You need to change the element NetworkInterfaceAddress to the network interface currently in use. Find network interface. You can find a network interface such as enP4p4s0 . root@comhpc:~# ip a 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: enP4p4s0: mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 00:30:64:1a:0a:65 brd ff:ff:ff:ff:ff:ff inet 192.168.0.62/24 brd 192.168.0.255 scope global dynamic enP4p4s0 valid_lft 3383sec preferred_lft 2933sec inet6 fe80::1ab4:7a14:28e:4e61/64 scope link valid_lft forever preferred_lft forever inet6 fe80::230:64ff:fe1a:a65/64 scope link valid_lft forever preferred_lft forever 3: sit0@NONE: mtu 1480 qdisc noop state DOWN group default qlen 1000 link/sit 0.0.0.0 brd 0.0.0.0 4: docker0: mtu 1500 qdisc noqueue state DOWN group default link/ether 02:42:4b:b2:ee:68 brd ff:ff:ff:ff:ff:ff inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0 valid_lft forever preferred_lft forever ... Change the NetworkInterfaceAddress . vi ~/cyclonedds/cyclonedds.xml For example; cyclonedds.xml - lo + enP4p4s0 ","title":"System Setup on AVA platform"},{"location":"version-2.0/start-guide/installation/system-setup-ava/#system-setup-on-ava-platform","text":"","title":"System Setup on AVA platform"},{"location":"version-2.0/start-guide/installation/system-setup-ava/#overview","text":"This instruction explains how to perform system setup for test execution on AVA platform.","title":"Overview"},{"location":"version-2.0/start-guide/installation/system-setup-ava/#access-to-ava-platform-via-ssh","text":"ssh root@IP-ADDRESS For example; ssh root@192.168.0.62","title":"Access to AVA platform via SSH"},{"location":"version-2.0/start-guide/installation/system-setup-ava/#download-kubernetes-yaml-files","text":"Autoware.Universe runs as k3s clusters in Open AD Kit, so please download kubernetes yaml files to deploy Autoware to AVA platform. Download. wget https://raw.githubusercontent.com/autowarefoundation/open-ad-kit-docs/main/docs/version-2.0/start-guide/installation/deployments/comhpc-deployments.zip Unzip it. unzip comhpc-deployments.zip -d comhpc-deployments You will see the following files are unzipped. Archive: comhpc-deployments.zip inflating: comhpc-api-deployment.yaml inflating: comhpc-control-deployment.yaml inflating: comhpc-map-deployment.yaml inflating: comhpc-persistent-volume.yaml inflating: comhpc-persistent-volume-claim.yaml inflating: comhpc-planning-deployment.yaml inflating: comhpc-simulator-deployment.yaml inflating: comhpc-system-deployment.yaml inflating: comhpc-vehicle-deployment.yaml","title":"Download kubernetes yaml files"},{"location":"version-2.0/start-guide/installation/system-setup-ava/#download-map-files","text":"Download from Google Drive. wget \"https://drive.google.com/uc?export=download&id=1vWMLbmwJJE5tYO40ypCMxqtmgQPQxhiw&confirm=t&uuid=3d84d854-3dd2-4950-8cc8-248feeab547d\" -O sample_data.zip Unzip it. unzip sample_data.zip Move map directory from sample_data . mv sample_data/map/ ~/ You will see the following files are located. root@ava:~# ls -la ~/map total 61288 drwxrwxr-x 2 root root 4096 Aug 18 06:23 . drwx------ 6 root root 4096 Aug 18 06:23 .. -rw-r--r-- 1 root root 1841436 Aug 18 06:23 lanelet2_map.osm -rw-r--r-- 1 root root 60904720 Aug 18 06:23 pointcloud_map.pcd","title":"Download map files"},{"location":"version-2.0/start-guide/installation/system-setup-ava/#download-kernel-configuration-file-for-tuning-kernel-parameters","text":"We have to reconfigure kernel parameters by using sysctl for system stability. Download. wget -P /etc/sysctl.d https://raw.githubusercontent.com/autowarefoundation/open-ad-kit-docs/main/docs/version-2.0/start-guide/installation/sysctl.d/60_cyclonedds.conf Update kernel parameters. sysctl -p /etc/sysctl.d/60_cyclonedds.conf","title":"Download kernel configuration file for tuning kernel parameters"},{"location":"version-2.0/start-guide/installation/system-setup-ava/#download-configuration-file-of-cyclone-dds","text":"In this test, we are using Cyclone DDS, so you also need to download configuration file of Cyclone DDS. Download cyclonedds.xml . wget -P ~/cyclonedds https://raw.githubusercontent.com/autowarefoundation/open-ad-kit-docs/main/docs/version-2.0/start-guide/installation/cyclonedds/cyclonedds.xml","title":"Download configuration file of Cyclone DDS"},{"location":"version-2.0/start-guide/installation/system-setup-ava/#modify-cycloneddsxml","text":"You need to change the element NetworkInterfaceAddress to the network interface currently in use. Find network interface. You can find a network interface such as enP4p4s0 . root@comhpc:~# ip a 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: enP4p4s0: mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 00:30:64:1a:0a:65 brd ff:ff:ff:ff:ff:ff inet 192.168.0.62/24 brd 192.168.0.255 scope global dynamic enP4p4s0 valid_lft 3383sec preferred_lft 2933sec inet6 fe80::1ab4:7a14:28e:4e61/64 scope link valid_lft forever preferred_lft forever inet6 fe80::230:64ff:fe1a:a65/64 scope link valid_lft forever preferred_lft forever 3: sit0@NONE: mtu 1480 qdisc noop state DOWN group default qlen 1000 link/sit 0.0.0.0 brd 0.0.0.0 4: docker0: mtu 1500 qdisc noqueue state DOWN group default link/ether 02:42:4b:b2:ee:68 brd ff:ff:ff:ff:ff:ff inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0 valid_lft forever preferred_lft forever ... Change the NetworkInterfaceAddress . vi ~/cyclonedds/cyclonedds.xml For example; cyclonedds.xml - lo + enP4p4s0 ","title":"Modify cyclonedds.xml"},{"location":"version-2.0/start-guide/installation/system-setup-host/","text":"System Setup on your host # Overview # This instruction explains how to perform system setup for test execution on your host. You need to copy docker images and necessary files. Download scenario simulator image to your host machine # The docker image of scenario simulator is registered in GitHub Container Registry Copy docker image to your host machine. docker pull ghcr.io/tier4/scenario_simulator_v2:galactic Install nvidia-docker2 & Rocker # In this test, we try to run rviz inside docker, so please install nvidia-docker2 & Rocker. This is quoted from Scenario testing framework for Autoware: Run on Docker If you have NVIDIA GPU (s) in your machine, you have to install nvidia-driver and nvidia-docker2. curl -s -L https://nvidia.github.io/nvidia-container-runtime/gpgkey | sudo apt-key add - curl -s -L https://nvidia.github.io/nvidia-container-runtime/ubuntu20.04/nvidia-container-runtime.list | \\ sudo tee /etc/apt/sources.list.d/nvidia-container-runtime.list sudo apt-get update sudo apt install -y nvidia-docker2 sudo systemctl restart docker.service Install Rocker sudo pip3 install git+https://github.com/osrf/rocker.git Download map and scenario files # Download from Google Drive. wget \"https://drive.google.com/uc?export=download&id=1vWMLbmwJJE5tYO40ypCMxqtmgQPQxhiw&confirm=t&uuid=3d84d854-3dd2-4950-8cc8-248feeab547d\" -O sample_data.zip Unzip it. unzip sample_data.zip Open the scenario file named t4v2.yaml in sample_data . Change the filepath of lanelet2_map.osm and pointcloud_map.pcd to your own directory. Download kernel configuration file for tuning kernel parameters # We have to reconfigure kernel parameters by using sysctl for system stability. Download. wget -P /etc/sysctl.d https://raw.githubusercontent.com/autowarefoundation/open-ad-kit-docs/main/docs/version-2.0/start-guide/installation/sysctl.d/60_cyclonedds.conf Update kernel parameters. sysctl -p /etc/sysctl.d/60_cyclonedds.conf Download configuration file of Cyclone DDS # In this test, we are using Cyclone DDS, so you also need to download configuration file of Cyclone DDS. Download cyclonedds.xml . wget -P ~/cyclonedds https://raw.githubusercontent.com/autowarefoundation/open-ad-kit-docs/main/docs/version-2.0/start-guide/installation/cyclonedds/cyclonedds.xml Modify cyclonedds.xml # You need to change the element NetworkInterfaceAddress to the network interface currently in use. Find network interface. ip addr 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: enp0s31f6: mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 66:77:88:99:aa:bb brd ff:ff:ff:ff:ff:ff inet 192.168.10.1/24 brd 192.168.10.255 scope global noprefixroute enp0s31f6 valid_lft forever preferred_lft forever inet6 fe80::f15d:4196:b777:6875/64 scope link noprefixroute valid_lft forever preferred_lft forever 3: wlp82s0: mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether cc:dd:ee:ff:00:01 brd ff:ff:ff:ff:ff:ff inet 192.168.0.28/24 brd 192.168.0.255 scope global dynamic noprefixroute wlp82s0 valid_lft 3137sec preferred_lft 3137sec inet6 fe80::f493:f223:dfcc:bd1b/64 scope link noprefixroute valid_lft forever preferred_lft forever 4: docker0: mtu 1500 qdisc noqueue state DOWN group default link/ether 23:45:67:89:ab:cd brd ff:ff:ff:ff:ff:ff inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0 valid_lft forever preferred_lft forever You can find a network interface such as enp0s31f6 . Change the NetworkInterfaceAddress . vi ~/cyclonedds/cyclonedds.xml For example; cyclonedds.xml - lo + enp0s31f6 ","title":"System Setup on your host"},{"location":"version-2.0/start-guide/installation/system-setup-host/#system-setup-on-your-host","text":"","title":"System Setup on your host"},{"location":"version-2.0/start-guide/installation/system-setup-host/#overview","text":"This instruction explains how to perform system setup for test execution on your host. You need to copy docker images and necessary files.","title":"Overview"},{"location":"version-2.0/start-guide/installation/system-setup-host/#download-scenario-simulator-image-to-your-host-machine","text":"The docker image of scenario simulator is registered in GitHub Container Registry Copy docker image to your host machine. docker pull ghcr.io/tier4/scenario_simulator_v2:galactic","title":"Download scenario simulator image to your host machine"},{"location":"version-2.0/start-guide/installation/system-setup-host/#install-nvidia-docker2-rocker","text":"In this test, we try to run rviz inside docker, so please install nvidia-docker2 & Rocker. This is quoted from Scenario testing framework for Autoware: Run on Docker If you have NVIDIA GPU (s) in your machine, you have to install nvidia-driver and nvidia-docker2. curl -s -L https://nvidia.github.io/nvidia-container-runtime/gpgkey | sudo apt-key add - curl -s -L https://nvidia.github.io/nvidia-container-runtime/ubuntu20.04/nvidia-container-runtime.list | \\ sudo tee /etc/apt/sources.list.d/nvidia-container-runtime.list sudo apt-get update sudo apt install -y nvidia-docker2 sudo systemctl restart docker.service Install Rocker sudo pip3 install git+https://github.com/osrf/rocker.git","title":"Install nvidia-docker2 & Rocker"},{"location":"version-2.0/start-guide/installation/system-setup-host/#download-map-and-scenario-files","text":"Download from Google Drive. wget \"https://drive.google.com/uc?export=download&id=1vWMLbmwJJE5tYO40ypCMxqtmgQPQxhiw&confirm=t&uuid=3d84d854-3dd2-4950-8cc8-248feeab547d\" -O sample_data.zip Unzip it. unzip sample_data.zip Open the scenario file named t4v2.yaml in sample_data . Change the filepath of lanelet2_map.osm and pointcloud_map.pcd to your own directory.","title":"Download map and scenario files"},{"location":"version-2.0/start-guide/installation/system-setup-host/#download-kernel-configuration-file-for-tuning-kernel-parameters","text":"We have to reconfigure kernel parameters by using sysctl for system stability. Download. wget -P /etc/sysctl.d https://raw.githubusercontent.com/autowarefoundation/open-ad-kit-docs/main/docs/version-2.0/start-guide/installation/sysctl.d/60_cyclonedds.conf Update kernel parameters. sysctl -p /etc/sysctl.d/60_cyclonedds.conf","title":"Download kernel configuration file for tuning kernel parameters"},{"location":"version-2.0/start-guide/installation/system-setup-host/#download-configuration-file-of-cyclone-dds","text":"In this test, we are using Cyclone DDS, so you also need to download configuration file of Cyclone DDS. Download cyclonedds.xml . wget -P ~/cyclonedds https://raw.githubusercontent.com/autowarefoundation/open-ad-kit-docs/main/docs/version-2.0/start-guide/installation/cyclonedds/cyclonedds.xml","title":"Download configuration file of Cyclone DDS"},{"location":"version-2.0/start-guide/installation/system-setup-host/#modify-cycloneddsxml","text":"You need to change the element NetworkInterfaceAddress to the network interface currently in use. Find network interface. ip addr 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: enp0s31f6: mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 66:77:88:99:aa:bb brd ff:ff:ff:ff:ff:ff inet 192.168.10.1/24 brd 192.168.10.255 scope global noprefixroute enp0s31f6 valid_lft forever preferred_lft forever inet6 fe80::f15d:4196:b777:6875/64 scope link noprefixroute valid_lft forever preferred_lft forever 3: wlp82s0: mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether cc:dd:ee:ff:00:01 brd ff:ff:ff:ff:ff:ff inet 192.168.0.28/24 brd 192.168.0.255 scope global dynamic noprefixroute wlp82s0 valid_lft 3137sec preferred_lft 3137sec inet6 fe80::f493:f223:dfcc:bd1b/64 scope link noprefixroute valid_lft forever preferred_lft forever 4: docker0: mtu 1500 qdisc noqueue state DOWN group default link/ether 23:45:67:89:ab:cd brd ff:ff:ff:ff:ff:ff inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0 valid_lft forever preferred_lft forever You can find a network interface such as enp0s31f6 . Change the NetworkInterfaceAddress . vi ~/cyclonedds/cyclonedds.xml For example; cyclonedds.xml - lo + enp0s31f6 ","title":"Modify cyclonedds.xml"},{"location":"version-2.0/start-guide/installation/system-setup-pcu/","text":"System Setup on PCU # Overview # This instruction explains how to perform system setup for test execution on PCU. You need to install Docker Engine, copy docker images and necessary files. Access to PCU via SSH # ssh user@IP-ADDRESS For example; ssh user@192.168.10.221 Copy Autoware.Auto image to PCU # NOTE : docker should be installed with post-installation steps. For instructions please refer to: Install Docker Engine on Ubuntu . Post-installation steps for Linux . The docker image of Autoware.Auto is registered in GitLab Container Registry . Copy docker image to PCU. docker pull registry.gitlab.com/autowarefoundation/autoware.auto/autowareauto/arm64/openadkit-foxy:latest Copy necessary files to local Downloads folder # Copy files related to map contents . Files are placed in the directory docs/Appendix/Open-AD-Kit-Start-Guide/map lanelet2_map.osm pointcloud_map.pcd global_map_center.pcd.yaml lanelet2_map_provider.osm.yaml map_publisher.param.yaml Copy files to your local folder (Downloads folder as example) as the following directory structure. Copy configuration file of Cyclone DDS . In this test, we are using Cyclone DDS, so you also need to copy configuration file of Cyclone DDS. File is placed in the directory docs/Appendix/Open-AD-Kit-Start-Guide/cyclonedds cyclonedds.xml Copy the file to your local folder as the following directory structure. Copy kernel configuration file for tuning kernel parameters. We have to reconfigure kernel parameters by using sysctl for system stability. File is placed in the directory docs/Appendix/Open-AD-Kit-Start-Guide/sysctl.d 60_cyclonedds.conf Copy the file to your local folder. Copy files from local folder to PCU # Connect your host PC with PCU through internet and copy files with SCP. Access to PCU via SSH For example; ssh user@192.168.10.221 Copy kernel configuration file to /etc/sysctl.d/ sudo scp USER-NAME@IP-ADDRESS:/home/USER-NAME/Downloads/60_cyclonedds.conf /etc/sysctl.d/ For example; sudo scp adlink@192.168.10.237:/home/adlink/Downloads/60_cyclonedds.conf /etc/sysctl.d/ Then type in the password of PCU (default password: user) and host PC as request. Update kernel parameters. sudo sysctl -p /etc/sysctl.d/60_cyclonedds.conf Copy map contents files and Cyclone DDS configuration file. sudo scp -r USER-NAME@IP-ADDRESS:/home/adlink/Downloads/map ~/ sudo scp -r USER-NAME@IP-ADDRESS:/home/adlink/Downloads/cyclonedds ~/ Modify cyclonedds.xml # You need to change the element NetworkInterfaceAddress to the network interface currently in use. Find network interface. ip addr 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: fm1-mac1: mtu 1500 qdisc mq master br0 state DOWN group default qlen 1000 link/ether 00:04:7c:2e:01:90 brd ff:ff:ff:ff:ff:ff inet6 fe80::204:7cff:fe2e:190/64 scope link valid_lft forever preferred_lft forever 3: fm1-mac5: mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 00:04:7c:2e:01:91 brd ff:ff:ff:ff:ff:ff inet 192.168.10.221/24 brd 192.168.10.255 scope global dynamic fm1-mac5 valid_lft 254392sec preferred_lft 254392sec inet6 fe80::204:7cff:fe2e:191/64 scope link valid_lft forever preferred_lft forever 4: fm1-mac6: mtu 1500 qdisc mq master br0 state DOWN group default qlen 1000 link/ether 00:04:7c:2e:01:90 brd ff:ff:ff:ff:ff:ff 5: fm1-sw: mtu 1500 qdisc mq master br0 state UP group default qlen 1000 link/ether 00:04:7c:2e:01:90 brd ff:ff:ff:ff:ff:ff inet6 fe80::204:7cff:fe2e:190/64 scope link valid_lft forever preferred_lft forever 6: fm1-mac10: mtu 1500 qdisc mq master br0 state DOWN group default qlen 1000 link/ether 00:04:7c:2e:01:90 brd ff:ff:ff:ff:ff:ff 7: sit0@NONE: mtu 1480 qdisc noop state DOWN group default qlen 1000 link/sit 0.0.0.0 brd 0.0.0.0 8: br0: mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether 00:04:7c:2e:01:90 brd ff:ff:ff:ff:ff:ff inet 192.168.1.239/24 brd 192.168.1.255 scope global br0 valid_lft forever preferred_lft forever inet6 fe80::204:7cff:fe2e:190/64 scope link valid_lft forever preferred_lft forever 9: docker0: mtu 1500 qdisc noqueue state DOWN group default link/ether 02:42:cb:aa:a6:9d brd ff:ff:ff:ff:ff:ff inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0 valid_lft forever preferred_lft forever You can find a network interface such as fm1-mac5 . Change the NetworkInterfaceAddress . sudo vi ~/cyclonedds/cyclonedds.xml For example; cyclonedds.xml - lo + fm1-mac5 ","title":"System Setup on PCU"},{"location":"version-2.0/start-guide/installation/system-setup-pcu/#system-setup-on-pcu","text":"","title":"System Setup on PCU"},{"location":"version-2.0/start-guide/installation/system-setup-pcu/#overview","text":"This instruction explains how to perform system setup for test execution on PCU. You need to install Docker Engine, copy docker images and necessary files.","title":"Overview"},{"location":"version-2.0/start-guide/installation/system-setup-pcu/#access-to-pcu-via-ssh","text":"ssh user@IP-ADDRESS For example; ssh user@192.168.10.221","title":"Access to PCU via SSH"},{"location":"version-2.0/start-guide/installation/system-setup-pcu/#copy-autowareauto-image-to-pcu","text":"NOTE : docker should be installed with post-installation steps. For instructions please refer to: Install Docker Engine on Ubuntu . Post-installation steps for Linux . The docker image of Autoware.Auto is registered in GitLab Container Registry . Copy docker image to PCU. docker pull registry.gitlab.com/autowarefoundation/autoware.auto/autowareauto/arm64/openadkit-foxy:latest","title":"Copy Autoware.Auto image to PCU"},{"location":"version-2.0/start-guide/installation/system-setup-pcu/#copy-necessary-files-to-local-downloads-folder","text":"Copy files related to map contents . Files are placed in the directory docs/Appendix/Open-AD-Kit-Start-Guide/map lanelet2_map.osm pointcloud_map.pcd global_map_center.pcd.yaml lanelet2_map_provider.osm.yaml map_publisher.param.yaml Copy files to your local folder (Downloads folder as example) as the following directory structure. Copy configuration file of Cyclone DDS . In this test, we are using Cyclone DDS, so you also need to copy configuration file of Cyclone DDS. File is placed in the directory docs/Appendix/Open-AD-Kit-Start-Guide/cyclonedds cyclonedds.xml Copy the file to your local folder as the following directory structure. Copy kernel configuration file for tuning kernel parameters. We have to reconfigure kernel parameters by using sysctl for system stability. File is placed in the directory docs/Appendix/Open-AD-Kit-Start-Guide/sysctl.d 60_cyclonedds.conf Copy the file to your local folder.","title":"Copy necessary files to local Downloads folder"},{"location":"version-2.0/start-guide/installation/system-setup-pcu/#copy-files-from-local-folder-to-pcu","text":"Connect your host PC with PCU through internet and copy files with SCP. Access to PCU via SSH For example; ssh user@192.168.10.221 Copy kernel configuration file to /etc/sysctl.d/ sudo scp USER-NAME@IP-ADDRESS:/home/USER-NAME/Downloads/60_cyclonedds.conf /etc/sysctl.d/ For example; sudo scp adlink@192.168.10.237:/home/adlink/Downloads/60_cyclonedds.conf /etc/sysctl.d/ Then type in the password of PCU (default password: user) and host PC as request. Update kernel parameters. sudo sysctl -p /etc/sysctl.d/60_cyclonedds.conf Copy map contents files and Cyclone DDS configuration file. sudo scp -r USER-NAME@IP-ADDRESS:/home/adlink/Downloads/map ~/ sudo scp -r USER-NAME@IP-ADDRESS:/home/adlink/Downloads/cyclonedds ~/","title":"Copy files from local folder to PCU"},{"location":"version-2.0/start-guide/installation/system-setup-pcu/#modify-cycloneddsxml","text":"You need to change the element NetworkInterfaceAddress to the network interface currently in use. Find network interface. ip addr 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: fm1-mac1: mtu 1500 qdisc mq master br0 state DOWN group default qlen 1000 link/ether 00:04:7c:2e:01:90 brd ff:ff:ff:ff:ff:ff inet6 fe80::204:7cff:fe2e:190/64 scope link valid_lft forever preferred_lft forever 3: fm1-mac5: mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 00:04:7c:2e:01:91 brd ff:ff:ff:ff:ff:ff inet 192.168.10.221/24 brd 192.168.10.255 scope global dynamic fm1-mac5 valid_lft 254392sec preferred_lft 254392sec inet6 fe80::204:7cff:fe2e:191/64 scope link valid_lft forever preferred_lft forever 4: fm1-mac6: mtu 1500 qdisc mq master br0 state DOWN group default qlen 1000 link/ether 00:04:7c:2e:01:90 brd ff:ff:ff:ff:ff:ff 5: fm1-sw: mtu 1500 qdisc mq master br0 state UP group default qlen 1000 link/ether 00:04:7c:2e:01:90 brd ff:ff:ff:ff:ff:ff inet6 fe80::204:7cff:fe2e:190/64 scope link valid_lft forever preferred_lft forever 6: fm1-mac10: mtu 1500 qdisc mq master br0 state DOWN group default qlen 1000 link/ether 00:04:7c:2e:01:90 brd ff:ff:ff:ff:ff:ff 7: sit0@NONE: mtu 1480 qdisc noop state DOWN group default qlen 1000 link/sit 0.0.0.0 brd 0.0.0.0 8: br0: mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether 00:04:7c:2e:01:90 brd ff:ff:ff:ff:ff:ff inet 192.168.1.239/24 brd 192.168.1.255 scope global br0 valid_lft forever preferred_lft forever inet6 fe80::204:7cff:fe2e:190/64 scope link valid_lft forever preferred_lft forever 9: docker0: mtu 1500 qdisc noqueue state DOWN group default link/ether 02:42:cb:aa:a6:9d brd ff:ff:ff:ff:ff:ff inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0 valid_lft forever preferred_lft forever You can find a network interface such as fm1-mac5 . Change the NetworkInterfaceAddress . sudo vi ~/cyclonedds/cyclonedds.xml For example; cyclonedds.xml - lo + fm1-mac5 ","title":"Modify cyclonedds.xml"},{"location":"version-2.0/start-guide/installation/system-setup-xavier/","text":"System Setup on Xavier platform # Overview # This instruction explains how to perform system setup for test execution on Xavier platform. Access to Xavier platform via SSH # ssh root@IP-ADDRESS For example; ssh nv@192.168.10.46 Copy Autoware Universe image to Xavier # NOTE : docker should be installed with post-installation steps. For instructions please refer to: Install Docker Engine on Ubuntu . Post-installation steps for Linux . The docker image of Autoware Universe for arm64 is registered in Autoware Foundation Container Registry . Copy docker image to Xavier. docker pull ghcr.io/autowarefoundation/autoware-universe:galactic-20220728-prebuilt-cuda K3s Installation # NOTE : K3s should be installed with following steps. For official instructions please refer to: Install K3s on Ubuntu . Install K3s. curl -sfL https://get.k3s.io | sh - Create directory. mkdir ~/.kube/ Copy config file sudo cp /etc/rancher/k3s/k3s.yaml ~/.kube/config Setting environment export KUBECONFIG=~/.kube/config Download kubernetes yaml files # Autoware.Universe runs as k3s clusters in Open AD Kit, so please download kubernetes yaml files to deploy Autoware to Xavier platform. Download. wget https://raw.githubusercontent.com/autowarefoundation/open-ad-kit-docs/main/docs/version-2.0/start-guide/installation/deployments/comhpc-deployments.zip Unzip it. unzip comhpc-deployments.zip -d comhpc-deployments You will see the following files are unzipped. Archive: comhpc-deployments.zip inflating: comhpc-api-deployment.yaml inflating: comhpc-control-deployment.yaml inflating: comhpc-map-deployment.yaml inflating: comhpc-persistent-volume.yaml inflating: comhpc-persistent-volume-claim.yaml inflating: comhpc-planning-deployment.yaml inflating: comhpc-simulator-deployment.yaml inflating: comhpc-system-deployment.yaml inflating: comhpc-vehicle-deployment.yaml Download map files # Download from Google Drive. wget \"https://drive.google.com/uc?export=download&id=1vWMLbmwJJE5tYO40ypCMxqtmgQPQxhiw&confirm=t&uuid=3d84d854-3dd2-4950-8cc8-248feeab547d\" -O sample_data.zip Unzip it. unzip sample_data.zip Move map directory from sample_data . mv sample_data/map/ ~/ You will see the following files are located. ls -la ~/map total 61288 drwxrwxr-x 2 root root 4096 Aug 18 06:23 . drwx------ 6 root root 4096 Aug 18 06:23 .. -rw-r--r-- 1 root root 1841436 Aug 18 06:23 lanelet2_map.osm -rw-r--r-- 1 root root 60904720 Aug 18 06:23 pointcloud_map.pcd Download kernel configuration file for tuning kernel parameters # We have to reconfigure kernel parameters by using sysctl for system stability. Download. wget -P /etc/sysctl.d https://raw.githubusercontent.com/autowarefoundation/open-ad-kit-docs/main/docs/version-2.0/start-guide/installation/sysctl.d/60_cyclonedds.conf Update kernel parameters. sysctl -p /etc/sysctl.d/60_cyclonedds.conf Download configuration file of Cyclone DDS # In this test, we are using Cyclone DDS, so you also need to download configuration file of Cyclone DDS. Download cyclonedds.xml . wget -P ~/cyclonedds https://raw.githubusercontent.com/autowarefoundation/open-ad-kit-docs/main/docs/version-2.0/start-guide/installation/cyclonedds/cyclonedds.xml Modify cyclonedds.xml # You need to change the element NetworkInterfaceAddress to the network interface currently in use. Find network interface. ip addr 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: dummy0: mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 0e:fa:61:5e:35:cd brd ff:ff:ff:ff:ff:ff 3: eth0: mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000 link/ether 48:b0:2d:2b:7a:a8 brd ff:ff:ff:ff:ff:ff 4: l4tbr0: mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 82:24:ce:68:6a:bd brd ff:ff:ff:ff:ff:ff 5: rndis0: mtu 1500 qdisc pfifo_fast master l4tbr0 state DOWN group default qlen 1000 link/ether 82:24:ce:68:6a:bd brd ff:ff:ff:ff:ff:ff 6: usb0: mtu 1500 qdisc pfifo_fast master l4tbr0 state DOWN group default qlen 1000 link/ether 82:24:ce:68:6a:bf brd ff:ff:ff:ff:ff:ff 7: eth1: mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 2c:16:db:a3:03:10 brd ff:ff:ff:ff:ff:ff inet 192.168.10.46/22 brd 192.168.11.255 scope global dynamic noprefixroute eth1 valid_lft 84077sec preferred_lft 84077sec inet6 fe80::9fcb:8fc6:a1a4:c6d2/64 scope link noprefixroute valid_lft forever preferred_lft forever 8: docker0: mtu 1500 qdisc noqueue state DOWN group default link/ether 02:42:0b:47:8f:45 brd ff:ff:ff:ff:ff:ff inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0 valid_lft forever preferred_lft forever You can find a network interface such as eth1 . Change the NetworkInterfaceAddress . vi ~/cyclonedds/cyclonedds.xml For example; cyclonedds.xml - lo + eth1 ","title":"System Setup on Xavier platform"},{"location":"version-2.0/start-guide/installation/system-setup-xavier/#system-setup-on-xavier-platform","text":"","title":"System Setup on Xavier platform"},{"location":"version-2.0/start-guide/installation/system-setup-xavier/#overview","text":"This instruction explains how to perform system setup for test execution on Xavier platform.","title":"Overview"},{"location":"version-2.0/start-guide/installation/system-setup-xavier/#access-to-xavier-platform-via-ssh","text":"ssh root@IP-ADDRESS For example; ssh nv@192.168.10.46","title":"Access to Xavier platform via SSH"},{"location":"version-2.0/start-guide/installation/system-setup-xavier/#copy-autoware-universe-image-to-xavier","text":"NOTE : docker should be installed with post-installation steps. For instructions please refer to: Install Docker Engine on Ubuntu . Post-installation steps for Linux . The docker image of Autoware Universe for arm64 is registered in Autoware Foundation Container Registry . Copy docker image to Xavier. docker pull ghcr.io/autowarefoundation/autoware-universe:galactic-20220728-prebuilt-cuda","title":"Copy Autoware Universe image to Xavier"},{"location":"version-2.0/start-guide/installation/system-setup-xavier/#k3s-installation","text":"NOTE : K3s should be installed with following steps. For official instructions please refer to: Install K3s on Ubuntu . Install K3s. curl -sfL https://get.k3s.io | sh - Create directory. mkdir ~/.kube/ Copy config file sudo cp /etc/rancher/k3s/k3s.yaml ~/.kube/config Setting environment export KUBECONFIG=~/.kube/config","title":"K3s Installation"},{"location":"version-2.0/start-guide/installation/system-setup-xavier/#download-kubernetes-yaml-files","text":"Autoware.Universe runs as k3s clusters in Open AD Kit, so please download kubernetes yaml files to deploy Autoware to Xavier platform. Download. wget https://raw.githubusercontent.com/autowarefoundation/open-ad-kit-docs/main/docs/version-2.0/start-guide/installation/deployments/comhpc-deployments.zip Unzip it. unzip comhpc-deployments.zip -d comhpc-deployments You will see the following files are unzipped. Archive: comhpc-deployments.zip inflating: comhpc-api-deployment.yaml inflating: comhpc-control-deployment.yaml inflating: comhpc-map-deployment.yaml inflating: comhpc-persistent-volume.yaml inflating: comhpc-persistent-volume-claim.yaml inflating: comhpc-planning-deployment.yaml inflating: comhpc-simulator-deployment.yaml inflating: comhpc-system-deployment.yaml inflating: comhpc-vehicle-deployment.yaml","title":"Download kubernetes yaml files"},{"location":"version-2.0/start-guide/installation/system-setup-xavier/#download-map-files","text":"Download from Google Drive. wget \"https://drive.google.com/uc?export=download&id=1vWMLbmwJJE5tYO40ypCMxqtmgQPQxhiw&confirm=t&uuid=3d84d854-3dd2-4950-8cc8-248feeab547d\" -O sample_data.zip Unzip it. unzip sample_data.zip Move map directory from sample_data . mv sample_data/map/ ~/ You will see the following files are located. ls -la ~/map total 61288 drwxrwxr-x 2 root root 4096 Aug 18 06:23 . drwx------ 6 root root 4096 Aug 18 06:23 .. -rw-r--r-- 1 root root 1841436 Aug 18 06:23 lanelet2_map.osm -rw-r--r-- 1 root root 60904720 Aug 18 06:23 pointcloud_map.pcd","title":"Download map files"},{"location":"version-2.0/start-guide/installation/system-setup-xavier/#download-kernel-configuration-file-for-tuning-kernel-parameters","text":"We have to reconfigure kernel parameters by using sysctl for system stability. Download. wget -P /etc/sysctl.d https://raw.githubusercontent.com/autowarefoundation/open-ad-kit-docs/main/docs/version-2.0/start-guide/installation/sysctl.d/60_cyclonedds.conf Update kernel parameters. sysctl -p /etc/sysctl.d/60_cyclonedds.conf","title":"Download kernel configuration file for tuning kernel parameters"},{"location":"version-2.0/start-guide/installation/system-setup-xavier/#download-configuration-file-of-cyclone-dds","text":"In this test, we are using Cyclone DDS, so you also need to download configuration file of Cyclone DDS. Download cyclonedds.xml . wget -P ~/cyclonedds https://raw.githubusercontent.com/autowarefoundation/open-ad-kit-docs/main/docs/version-2.0/start-guide/installation/cyclonedds/cyclonedds.xml","title":"Download configuration file of Cyclone DDS"},{"location":"version-2.0/start-guide/installation/system-setup-xavier/#modify-cycloneddsxml","text":"You need to change the element NetworkInterfaceAddress to the network interface currently in use. Find network interface. ip addr 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: dummy0: mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 0e:fa:61:5e:35:cd brd ff:ff:ff:ff:ff:ff 3: eth0: mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000 link/ether 48:b0:2d:2b:7a:a8 brd ff:ff:ff:ff:ff:ff 4: l4tbr0: mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 82:24:ce:68:6a:bd brd ff:ff:ff:ff:ff:ff 5: rndis0: mtu 1500 qdisc pfifo_fast master l4tbr0 state DOWN group default qlen 1000 link/ether 82:24:ce:68:6a:bd brd ff:ff:ff:ff:ff:ff 6: usb0: mtu 1500 qdisc pfifo_fast master l4tbr0 state DOWN group default qlen 1000 link/ether 82:24:ce:68:6a:bf brd ff:ff:ff:ff:ff:ff 7: eth1: mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 2c:16:db:a3:03:10 brd ff:ff:ff:ff:ff:ff inet 192.168.10.46/22 brd 192.168.11.255 scope global dynamic noprefixroute eth1 valid_lft 84077sec preferred_lft 84077sec inet6 fe80::9fcb:8fc6:a1a4:c6d2/64 scope link noprefixroute valid_lft forever preferred_lft forever 8: docker0: mtu 1500 qdisc noqueue state DOWN group default link/ether 02:42:0b:47:8f:45 brd ff:ff:ff:ff:ff:ff inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0 valid_lft forever preferred_lft forever You can find a network interface such as eth1 . Change the NetworkInterfaceAddress . vi ~/cyclonedds/cyclonedds.xml For example; cyclonedds.xml - lo + eth1 ","title":"Modify cyclonedds.xml"},{"location":"version-2.0/system-configuration/","text":"System configuration # TODO","title":"System configuration"},{"location":"version-2.0/system-configuration/#system-configuration","text":"TODO","title":"System configuration"}]} \ No newline at end of file +{"config":{"indexing":"full","lang":["en"],"min_search_length":3,"prebuild_index":false,"separator":"[\\s\\-]+"},"docs":[{"location":"","text":"Open AD Kit Documentation # The latest version is 2.0, but it has not been officially released yet. About Open AD Kit # Open AD Kit aims to democratize autonomous drive (AD) systems by bringing the cloud and edge closer together. In doing so, Open AD Kit will lower the threshold for developing and deploying the Autoware software stack. For more details about the Open AD Kit project, its goals and details of the Autoware Foundation working group that oversees the project, refer to the Open AD Kit Working Group wiki . Open AD Kit documentation structure # Getting started # Start guide describes how to install, set up and run Autoware and its associated simulators on supported development platforms. System configuration describes the components that make up Open AD Kit in terms of the required hardware and software. Application example provides an actual application example for Open AD Kit that can be used as a reference for the development of other applications. Releases # version 2.0 Latest version 1.0","title":"Open AD Kit Documentation"},{"location":"#open-ad-kit-documentation","text":"The latest version is 2.0, but it has not been officially released yet.","title":"Open AD Kit Documentation"},{"location":"#about-open-ad-kit","text":"Open AD Kit aims to democratize autonomous drive (AD) systems by bringing the cloud and edge closer together. In doing so, Open AD Kit will lower the threshold for developing and deploying the Autoware software stack. For more details about the Open AD Kit project, its goals and details of the Autoware Foundation working group that oversees the project, refer to the Open AD Kit Working Group wiki .","title":"About Open AD Kit"},{"location":"#open-ad-kit-documentation-structure","text":"","title":"Open AD Kit documentation structure"},{"location":"#getting-started","text":"Start guide describes how to install, set up and run Autoware and its associated simulators on supported development platforms. System configuration describes the components that make up Open AD Kit in terms of the required hardware and software. Application example provides an actual application example for Open AD Kit that can be used as a reference for the development of other applications.","title":"Getting started"},{"location":"#releases","text":"version 2.0 Latest version 1.0","title":"Releases"},{"location":"version-1.0/","text":"Open AD Kit Documentation # The latest version is 2.0, but it has not been officially released yet. About Open AD Kit # Open AD Kit aims to democratize autonomous drive (AD) systems by bringing the cloud and edge closer together. In doing so, Open AD Kit will lower the threshold for developing and deploying the Autoware software stack. For more details about the Open AD Kit project, its goals and details of the Autoware Foundation working group that oversees the project, refer to the Open AD Kit Working Group wiki . Open AD Kit documentation structure # Getting started # Start guide describes how to install, set up and run Autoware and its associated simulators on supported development platforms. System configuration describes the components that make up Open AD Kit in terms of the required hardware and software. Application example provides an actual application example for Open AD Kit that can be used as a reference for the development of other applications.","title":"Introduction"},{"location":"version-1.0/#open-ad-kit-documentation","text":"The latest version is 2.0, but it has not been officially released yet.","title":"Open AD Kit Documentation"},{"location":"version-1.0/#about-open-ad-kit","text":"Open AD Kit aims to democratize autonomous drive (AD) systems by bringing the cloud and edge closer together. In doing so, Open AD Kit will lower the threshold for developing and deploying the Autoware software stack. For more details about the Open AD Kit project, its goals and details of the Autoware Foundation working group that oversees the project, refer to the Open AD Kit Working Group wiki .","title":"About Open AD Kit"},{"location":"version-1.0/#open-ad-kit-documentation-structure","text":"","title":"Open AD Kit documentation structure"},{"location":"version-1.0/#getting-started","text":"Start guide describes how to install, set up and run Autoware and its associated simulators on supported development platforms. System configuration describes the components that make up Open AD Kit in terms of the required hardware and software. Application example provides an actual application example for Open AD Kit that can be used as a reference for the development of other applications.","title":"Getting started"},{"location":"version-1.0/application-example/","text":"Application example # There is no application example of Open AD Kit version 1.0.","title":"Application example"},{"location":"version-1.0/application-example/#application-example","text":"There is no application example of Open AD Kit version 1.0.","title":"Application example"},{"location":"version-1.0/application-example/driverless-bus/","text":"Driverless bus # The content is a work in progress. This page provides a reference design for a passenger transportation system in the urban area. The reference design consists of the following structures: Introduction of Reference Design Concept of Operations Operational Concept Operational Environment Requirements System Requirements System Configuration Hardware Requirements Software Requirements Appendix","title":"Driverless bus"},{"location":"version-1.0/application-example/driverless-bus/#driverless-bus","text":"The content is a work in progress. This page provides a reference design for a passenger transportation system in the urban area. The reference design consists of the following structures: Introduction of Reference Design Concept of Operations Operational Concept Operational Environment Requirements System Requirements System Configuration Hardware Requirements Software Requirements Appendix","title":"Driverless bus"},{"location":"version-1.0/application-example/driverless-bus/appendix/","text":"Appendix # The content is a work in progress. What is ConOps and OpsCons? Hardware List","title":"Appendix"},{"location":"version-1.0/application-example/driverless-bus/appendix/#appendix","text":"The content is a work in progress. What is ConOps and OpsCons? Hardware List","title":"Appendix"},{"location":"version-1.0/application-example/driverless-bus/appendix/hardware-list/","text":"Hardware List # The content is a work in progress. This page should show applicable hardwares for the system.","title":"Hardware List"},{"location":"version-1.0/application-example/driverless-bus/appendix/hardware-list/#hardware-list","text":"The content is a work in progress. This page should show applicable hardwares for the system.","title":"Hardware List"},{"location":"version-1.0/application-example/driverless-bus/appendix/what-is-conops-and-opscon/","text":"What is ConOps and OpsCons? # Concept of Operations (ConOps) : \u201c... the ConOps describes the overall high-level concept of how the system will be used to meet stakeholder expectations, usually in a time-sequenced manner\u2026\u201d, source NASA Systems Engineering Handbook In short, it describes how the system achieves the user\u2019s mission with a picture and short sentences. Operational Concept (OpsCon) : \u201cThe operational concept is designed to give an overall picture of the operations using one or more specific systems, or set of related systems, in the organization\u2019s operational environment from the users\u2019 and operators\u2019 perspective.\u201d, source SEBoK In short, it describes: How the system achieves the mission using unique features/events/interactions Relationships between the system and other systems Benefits : Stakeholders can understand the system from the early stages of development In particular, developers who have different backgrounds or perspectives can gain the same understanding","title":"What is ConOps and OpsCons?"},{"location":"version-1.0/application-example/driverless-bus/appendix/what-is-conops-and-opscon/#what-is-conops-and-opscons","text":"Concept of Operations (ConOps) : \u201c... the ConOps describes the overall high-level concept of how the system will be used to meet stakeholder expectations, usually in a time-sequenced manner\u2026\u201d, source NASA Systems Engineering Handbook In short, it describes how the system achieves the user\u2019s mission with a picture and short sentences. Operational Concept (OpsCon) : \u201cThe operational concept is designed to give an overall picture of the operations using one or more specific systems, or set of related systems, in the organization\u2019s operational environment from the users\u2019 and operators\u2019 perspective.\u201d, source SEBoK In short, it describes: How the system achieves the mission using unique features/events/interactions Relationships between the system and other systems Benefits : Stakeholders can understand the system from the early stages of development In particular, developers who have different backgrounds or perspectives can gain the same understanding","title":"What is ConOps and OpsCons?"},{"location":"version-1.0/application-example/driverless-bus/concept-of-operations/","text":"Concept of Operations # Passenger Transportation System in the urban area # The system, under the surveillance of an in-car operator, will automatically transport passengers while following routes on public roads. The public roads have multiple lanes, traffic lights, and intersections; therefore the system will automatically change lanes and respond to traffic lights at intersections. The system will automatically stop at bus stops. The system is programmed to avoid colliding with objects that are detected on the road. The vehicle is programmed to either safely pass the object when possible, or to stop. While the vehicle is moving, the system automatically maintains a safe following distance and stays within the speed limit (i.e., adaptive cruise control).","title":"Concept of Operations"},{"location":"version-1.0/application-example/driverless-bus/concept-of-operations/#concept-of-operations","text":"","title":"Concept of Operations"},{"location":"version-1.0/application-example/driverless-bus/concept-of-operations/#passenger-transportation-system-in-the-urban-area","text":"The system, under the surveillance of an in-car operator, will automatically transport passengers while following routes on public roads. The public roads have multiple lanes, traffic lights, and intersections; therefore the system will automatically change lanes and respond to traffic lights at intersections. The system will automatically stop at bus stops. The system is programmed to avoid colliding with objects that are detected on the road. The vehicle is programmed to either safely pass the object when possible, or to stop. While the vehicle is moving, the system automatically maintains a safe following distance and stays within the speed limit (i.e., adaptive cruise control).","title":"Passenger Transportation System in the urban area"},{"location":"version-1.0/application-example/driverless-bus/hardware-requirements/","text":"Hardware Requirements # The content is a work in progress. Vehicle Requirements ECU Requirements Sensor Requirements LiDAR Requirements Camera Requirements Radar Requirements","title":"Hardware Requirements"},{"location":"version-1.0/application-example/driverless-bus/hardware-requirements/#hardware-requirements","text":"The content is a work in progress. Vehicle Requirements ECU Requirements Sensor Requirements LiDAR Requirements Camera Requirements Radar Requirements","title":"Hardware Requirements"},{"location":"version-1.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/","text":"ECU Requirements # This is a draft version. Overview # The requirements described in the following pages are determined based on a Tier IV project as a reference for now. This will be updated once the requirements for Open AD Kit was determined. Table of contents # High-level Architecture System Resource & Interface Performance and Data Bandwidth Requirements Hardware Requirements","title":"ECU Requirements"},{"location":"version-1.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/#ecu-requirements","text":"This is a draft version.","title":"ECU Requirements"},{"location":"version-1.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/#overview","text":"The requirements described in the following pages are determined based on a Tier IV project as a reference for now. This will be updated once the requirements for Open AD Kit was determined.","title":"Overview"},{"location":"version-1.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/#table-of-contents","text":"High-level Architecture System Resource & Interface Performance and Data Bandwidth Requirements Hardware Requirements","title":"Table of contents"},{"location":"version-1.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/high-level-arch/","text":"High-level Architecture # This is a draft version. Overview # The reference system consists of three parts of computing unit. Main Autoware 2D Perception Traffic Light Recognition Each unit can be implemented on separated hardware units (ECUs) and, if the hardware has sufficient system resource and performance, some units can also be integrated on a single hardware unit. Block Diagram #","title":"High-level Architecture"},{"location":"version-1.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/high-level-arch/#high-level-architecture","text":"This is a draft version.","title":"High-level Architecture"},{"location":"version-1.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/high-level-arch/#overview","text":"The reference system consists of three parts of computing unit. Main Autoware 2D Perception Traffic Light Recognition Each unit can be implemented on separated hardware units (ECUs) and, if the hardware has sufficient system resource and performance, some units can also be integrated on a single hardware unit.","title":"Overview"},{"location":"version-1.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/high-level-arch/#block-diagram","text":"","title":"Block Diagram"},{"location":"version-1.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/hw-requirements/","text":"Hardware Requirements # This is a draft version. Overview # This page describes sample requirements for hardware specification. NOTE: This type of hardware requirement should be differed depending on a target vehicle and changed by the industrial standard. It also needs to be determined during hardware design so might should be a part of the reference implementation. Reliability # Item Requirement Standard AEC-Q100 Environmental # Item Requirement Operating Temp e.g. -40 to 130 degree celsius Storage Temp Humidity Vibration Shock EMC Mechanical # Item Requirement Dimensions Weight Mounting Power # Item Requirement AC/DC input supply e.g. shall input 350V DC Power Consumption e.g. shall be less 600W Cooling # Item Requirement Liquid cooling","title":"Hardware Requirements"},{"location":"version-1.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/hw-requirements/#hardware-requirements","text":"This is a draft version.","title":"Hardware Requirements"},{"location":"version-1.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/hw-requirements/#overview","text":"This page describes sample requirements for hardware specification. NOTE: This type of hardware requirement should be differed depending on a target vehicle and changed by the industrial standard. It also needs to be determined during hardware design so might should be a part of the reference implementation.","title":"Overview"},{"location":"version-1.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/hw-requirements/#reliability","text":"Item Requirement Standard AEC-Q100","title":"Reliability"},{"location":"version-1.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/hw-requirements/#environmental","text":"Item Requirement Operating Temp e.g. -40 to 130 degree celsius Storage Temp Humidity Vibration Shock EMC","title":"Environmental"},{"location":"version-1.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/hw-requirements/#mechanical","text":"Item Requirement Dimensions Weight Mounting","title":"Mechanical"},{"location":"version-1.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/hw-requirements/#power","text":"Item Requirement AC/DC input supply e.g. shall input 350V DC Power Consumption e.g. shall be less 600W","title":"Power"},{"location":"version-1.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/hw-requirements/#cooling","text":"Item Requirement Liquid cooling","title":"Cooling"},{"location":"version-1.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/perf-data-bandwidth/","text":"Performance and Data Bandwidth Requirements # This is a draft version. Overview # This page describes required performance for the perception accelerators and data bandwidth on each sensor interface and network. Perception Accelerators # Functions Network Model Input resolution @ frame rate Required performance 3D Perception CenterPoint 55000 voxels x 20 points x 10 features @10FPS per LiDAR XX TOPS 2D Perception Yolov4 608x608@10FPS per Camera XX TOPS Traffic Light Recognition MobileNet v2 SSD Lite (Detection) MobileNet v2 (Classification) 300x300@10FPS 224x224@10FPS XX TOPS Data Bandwidth # Type Configurations Data type Data Bandwidth LiDAR Input Mid-range Point cloud 37 Mbps Short-range Point cloud 26 Mbps Camera Input Perception Camera YUV422 16bit 1920x1280 393 Mbps Traffic Light Recognition Camera YUV422 16bit 2880x1860 857 Mbps Inter- ECU 2D Perception to Main Autoware Recognition result & Compressed image data for logging 27 Mbps TLR to Main Autoware Recognition result & Compressed image data for logging 59 Mbps Logging Storage Mid-range LiDAR x 4 Short-range LiDAR x 4 Perception Camera x 6 (Compressed) Traffic Light Recognition Camera x 1 (Compressed) Main Autoware internat topics (272Mbps) 745 Mbps","title":"Performance and Data Bandwidth Requirements"},{"location":"version-1.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/perf-data-bandwidth/#performance-and-data-bandwidth-requirements","text":"This is a draft version.","title":"Performance and Data Bandwidth Requirements"},{"location":"version-1.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/perf-data-bandwidth/#overview","text":"This page describes required performance for the perception accelerators and data bandwidth on each sensor interface and network.","title":"Overview"},{"location":"version-1.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/perf-data-bandwidth/#perception-accelerators","text":"Functions Network Model Input resolution @ frame rate Required performance 3D Perception CenterPoint 55000 voxels x 20 points x 10 features @10FPS per LiDAR XX TOPS 2D Perception Yolov4 608x608@10FPS per Camera XX TOPS Traffic Light Recognition MobileNet v2 SSD Lite (Detection) MobileNet v2 (Classification) 300x300@10FPS 224x224@10FPS XX TOPS","title":"Perception Accelerators"},{"location":"version-1.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/perf-data-bandwidth/#data-bandwidth","text":"Type Configurations Data type Data Bandwidth LiDAR Input Mid-range Point cloud 37 Mbps Short-range Point cloud 26 Mbps Camera Input Perception Camera YUV422 16bit 1920x1280 393 Mbps Traffic Light Recognition Camera YUV422 16bit 2880x1860 857 Mbps Inter- ECU 2D Perception to Main Autoware Recognition result & Compressed image data for logging 27 Mbps TLR to Main Autoware Recognition result & Compressed image data for logging 59 Mbps Logging Storage Mid-range LiDAR x 4 Short-range LiDAR x 4 Perception Camera x 6 (Compressed) Traffic Light Recognition Camera x 1 (Compressed) Main Autoware internat topics (272Mbps) 745 Mbps","title":"Data Bandwidth"},{"location":"version-1.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/sys-resource-if/","text":"System Resource & Interface # This is a draft version. Overview # The following tables describe the required system resource and interface for each computing unit. Main Autoware Unit # Category Item Requirement Computing Resource CPU X86 8core/16thread @3.3GHz or more Memory Dual 16GB (Total 32GB), DDR4-2666 w/ ECC or more GPU 9.4 TFLOPS@FP32 or more Storage 256GB for System Volume 2TB for Logging data LiDAR 100BASE-TX, 1000BASE-T Interfaces IMU CAN or RS232C GNSS 100BASE-TX Vehicle CAN Inter- ECU (2D Perception/TLR) 1000BASE-T Power CPU TDP 80 W GPU TDP 110 W Total Max 250 W 2D Perception Unit # This table shows requirements for one camera. For multiple camera configurations, it requires more hardware units. If the hardware unit has sufficient system resource and performance, it can be integrated on a single hardware unit. Category Item Requirement Computing Resource CPU Arm v8.2 8core @2.26GHz or more Memory 32GB Low-Power Double Data Rate 4x or more GPU 30 TOPS or more Storage 32GB or more Interfaces Camera Gigabit Multimedia Serial Link 2 w/ frame sync trigger or 1000BASE-T (GigE Vision) Inter- ECU (Main Autoware) 1000BASE-T Power CPU TDP xxxW GPU TDP xxxW Total Max.xxxW Traffic Light Recognition Unit # This table shows requirements for one camera. For multiple camera configurations, it requires more hardware units. If the hardware unit has sufficient system resource and performance, it can be integrated on a single hardware unit. Category Item Requirement Computing Resource CPU Arm v8.2 8core @2.26GHz or more Memory 32GB Low-Power Double Data Rate 4x or more GPU 30 TOPS or more Storage 32GB or more Interfaces Camera Gigabit Multimedia Serial Link 2 w/ frame sync trigger or 1000BASE-T (GigE Vision) Inter- ECU (Main Autoware) 1000BASE-T Power CPU TDP xxxW GPU TDP xxxW Total Max.xxxW","title":"System Resource & Interface"},{"location":"version-1.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/sys-resource-if/#system-resource-interface","text":"This is a draft version.","title":"System Resource & Interface"},{"location":"version-1.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/sys-resource-if/#overview","text":"The following tables describe the required system resource and interface for each computing unit.","title":"Overview"},{"location":"version-1.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/sys-resource-if/#main-autoware-unit","text":"Category Item Requirement Computing Resource CPU X86 8core/16thread @3.3GHz or more Memory Dual 16GB (Total 32GB), DDR4-2666 w/ ECC or more GPU 9.4 TFLOPS@FP32 or more Storage 256GB for System Volume 2TB for Logging data LiDAR 100BASE-TX, 1000BASE-T Interfaces IMU CAN or RS232C GNSS 100BASE-TX Vehicle CAN Inter- ECU (2D Perception/TLR) 1000BASE-T Power CPU TDP 80 W GPU TDP 110 W Total Max 250 W","title":"Main Autoware Unit"},{"location":"version-1.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/sys-resource-if/#2d-perception-unit","text":"This table shows requirements for one camera. For multiple camera configurations, it requires more hardware units. If the hardware unit has sufficient system resource and performance, it can be integrated on a single hardware unit. Category Item Requirement Computing Resource CPU Arm v8.2 8core @2.26GHz or more Memory 32GB Low-Power Double Data Rate 4x or more GPU 30 TOPS or more Storage 32GB or more Interfaces Camera Gigabit Multimedia Serial Link 2 w/ frame sync trigger or 1000BASE-T (GigE Vision) Inter- ECU (Main Autoware) 1000BASE-T Power CPU TDP xxxW GPU TDP xxxW Total Max.xxxW","title":"2D Perception Unit"},{"location":"version-1.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/sys-resource-if/#traffic-light-recognition-unit","text":"This table shows requirements for one camera. For multiple camera configurations, it requires more hardware units. If the hardware unit has sufficient system resource and performance, it can be integrated on a single hardware unit. Category Item Requirement Computing Resource CPU Arm v8.2 8core @2.26GHz or more Memory 32GB Low-Power Double Data Rate 4x or more GPU 30 TOPS or more Storage 32GB or more Interfaces Camera Gigabit Multimedia Serial Link 2 w/ frame sync trigger or 1000BASE-T (GigE Vision) Inter- ECU (Main Autoware) 1000BASE-T Power CPU TDP xxxW GPU TDP xxxW Total Max.xxxW","title":"Traffic Light Recognition Unit"},{"location":"version-1.0/application-example/driverless-bus/introduction-of-reference-design/","text":"Introduction of Reference Design # Introduction # Autonomous driving technology # AWF aims to establish a sustainable ecosystem for autonomous driving to which various organizations and individuals can contribute in terms of development, and wherein society can enjoy the benefits. AWF offers open access to technologies contributing to autonomous driving. Autonomous driving requires a composite platform which integrates various software, cloud infrastructure and services in addition to the in-vehicle AD ( Autonomous Driving ) systems. There is a need for a horizontally collaborative development approach based on an open source platform that ensures a level of safety that satisfies society at a reasonable cost. In order to realize this, AWF is promoting (1) Autoware, an open source autonomous driving software, (2) AD System Reference Designs based on ODD ( Operational Design Domain \uff09categorization, and (3) Deep-tech R&D of AD systems. What can do with \"Reference Design\" as ecosystem? # With clear ODD classifications, everyone can understand where AD fits into complex real-world traffic environments. By presenting a suitable \"Reference Design\" for each ODD , AWF simplifies the preparation process in AD and lowers the difficulty threshold for demonstration and implementation.","title":"Introduction of Reference Design"},{"location":"version-1.0/application-example/driverless-bus/introduction-of-reference-design/#introduction-of-reference-design","text":"","title":"Introduction of Reference Design"},{"location":"version-1.0/application-example/driverless-bus/introduction-of-reference-design/#introduction","text":"","title":"Introduction"},{"location":"version-1.0/application-example/driverless-bus/introduction-of-reference-design/#autonomous-driving-technology","text":"AWF aims to establish a sustainable ecosystem for autonomous driving to which various organizations and individuals can contribute in terms of development, and wherein society can enjoy the benefits. AWF offers open access to technologies contributing to autonomous driving. Autonomous driving requires a composite platform which integrates various software, cloud infrastructure and services in addition to the in-vehicle AD ( Autonomous Driving ) systems. There is a need for a horizontally collaborative development approach based on an open source platform that ensures a level of safety that satisfies society at a reasonable cost. In order to realize this, AWF is promoting (1) Autoware, an open source autonomous driving software, (2) AD System Reference Designs based on ODD ( Operational Design Domain \uff09categorization, and (3) Deep-tech R&D of AD systems.","title":"Autonomous driving technology"},{"location":"version-1.0/application-example/driverless-bus/introduction-of-reference-design/#what-can-do-with-reference-design-as-ecosystem","text":"With clear ODD classifications, everyone can understand where AD fits into complex real-world traffic environments. By presenting a suitable \"Reference Design\" for each ODD , AWF simplifies the preparation process in AD and lowers the difficulty threshold for demonstration and implementation.","title":"What can do with \"Reference Design\" as ecosystem?"},{"location":"version-1.0/application-example/driverless-bus/operational-concept/","text":"Operational Concept # Operational Concept (OpsCon) of the Passenger Transportation System in the urban area is below: Daytime operation Nighttime operation Follow a route Let passengers on and off at bus stops Avoid collisions Set service route via HMI on the vehicle Interact with other vehicles on the public roads Interact with emergency vehicles Interact with traffic lights Operation mode Take over request to the operator Lane keeping and changing lanes Adaptive cruise control Predict pedestrian stepping into the road","title":"Operational Concept"},{"location":"version-1.0/application-example/driverless-bus/operational-concept/#operational-concept","text":"Operational Concept (OpsCon) of the Passenger Transportation System in the urban area is below: Daytime operation Nighttime operation Follow a route Let passengers on and off at bus stops Avoid collisions Set service route via HMI on the vehicle Interact with other vehicles on the public roads Interact with emergency vehicles Interact with traffic lights Operation mode Take over request to the operator Lane keeping and changing lanes Adaptive cruise control Predict pedestrian stepping into the road","title":"Operational Concept"},{"location":"version-1.0/application-example/driverless-bus/operational-concept/adaptive-cruise-control/","text":"Adaptive cruise control # The system automatically maintains a safe following distance and stays within the speed limit.","title":"Adaptive cruise control"},{"location":"version-1.0/application-example/driverless-bus/operational-concept/adaptive-cruise-control/#adaptive-cruise-control","text":"The system automatically maintains a safe following distance and stays within the speed limit.","title":"Adaptive cruise control"},{"location":"version-1.0/application-example/driverless-bus/operational-concept/avoid-collisions/","text":"Avoid collisions # When there are objects on the route, the system will automatically perform the following actions: a. The system automatically stops if there is surrounding traffic. b. The system automatically avoids the objects if there is no surrounding traffic.","title":"Avoid collisions"},{"location":"version-1.0/application-example/driverless-bus/operational-concept/avoid-collisions/#avoid-collisions","text":"When there are objects on the route, the system will automatically perform the following actions: a. The system automatically stops if there is surrounding traffic. b. The system automatically avoids the objects if there is no surrounding traffic.","title":"Avoid collisions"},{"location":"version-1.0/application-example/driverless-bus/operational-concept/daytime-operation/","text":"Daytime operation # Currently, the system does NOT operate in the daytime. In the future, the system will be able to operate during the daytime (9:30am - 3:30pm). The vehicle will be fully charged before the operation in the daytime. The operator connects the charger to the vehicle, and the vehicle is automatically charged.","title":"Daytime operation"},{"location":"version-1.0/application-example/driverless-bus/operational-concept/daytime-operation/#daytime-operation","text":"Currently, the system does NOT operate in the daytime. In the future, the system will be able to operate during the daytime (9:30am - 3:30pm). The vehicle will be fully charged before the operation in the daytime. The operator connects the charger to the vehicle, and the vehicle is automatically charged.","title":"Daytime operation"},{"location":"version-1.0/application-example/driverless-bus/operational-concept/follow-a-route/","text":"Follow a route # The system follows a route set on the public road while an in-car operator is in the autonomous driving vehicle of the system.","title":"Follow a route"},{"location":"version-1.0/application-example/driverless-bus/operational-concept/follow-a-route/#follow-a-route","text":"The system follows a route set on the public road while an in-car operator is in the autonomous driving vehicle of the system.","title":"Follow a route"},{"location":"version-1.0/application-example/driverless-bus/operational-concept/interact-with-emergency-vehicles/","text":"Interact with emergency vehicles # When the vehicle meets an emergency vehicle, an in-car operator performs the following actions: Promptly maneuvers the vehicle to the side of the road and stops Manually re-launches the system after the emergency vehicle passes by NOTE: The operator can use HMI (e.g., steering wheel or brake pedal) at any time to override the system control.","title":"Interact with emergency vehicles"},{"location":"version-1.0/application-example/driverless-bus/operational-concept/interact-with-emergency-vehicles/#interact-with-emergency-vehicles","text":"When the vehicle meets an emergency vehicle, an in-car operator performs the following actions: Promptly maneuvers the vehicle to the side of the road and stops Manually re-launches the system after the emergency vehicle passes by NOTE: The operator can use HMI (e.g., steering wheel or brake pedal) at any time to override the system control.","title":"Interact with emergency vehicles"},{"location":"version-1.0/application-example/driverless-bus/operational-concept/interact-with-other-vehicle-on-the-public-roads/","text":"Interact with other vehicles on the public roads # The service route uses public roads, so the system interacts with other vehicles and must obey all traffic laws. When the vehicle approaches an intersection, the system is programed to yield and take right of way with surrounding traffic, depending the actual situation and traffic laws.","title":"Interact with other vehicles on the public roads"},{"location":"version-1.0/application-example/driverless-bus/operational-concept/interact-with-other-vehicle-on-the-public-roads/#interact-with-other-vehicles-on-the-public-roads","text":"The service route uses public roads, so the system interacts with other vehicles and must obey all traffic laws. When the vehicle approaches an intersection, the system is programed to yield and take right of way with surrounding traffic, depending the actual situation and traffic laws.","title":"Interact with other vehicles on the public roads"},{"location":"version-1.0/application-example/driverless-bus/operational-concept/interact-with-traffic-lights/","text":"Interact with traffic lights # When the vehicle meets a traffic light, the system performs one of the following actions: Stop on a red light Stop on a yellow light Go straight, turn right, or turn left on a green light or arrow","title":"Interact with traffic lights"},{"location":"version-1.0/application-example/driverless-bus/operational-concept/interact-with-traffic-lights/#interact-with-traffic-lights","text":"When the vehicle meets a traffic light, the system performs one of the following actions: Stop on a red light Stop on a yellow light Go straight, turn right, or turn left on a green light or arrow","title":"Interact with traffic lights"},{"location":"version-1.0/application-example/driverless-bus/operational-concept/lane-keeping-and-changing-lanes/","text":"Lane keeping and changing lanes # The system stays the driving lane or changes lanes according to the route.","title":"Lane keeping and changing lanes"},{"location":"version-1.0/application-example/driverless-bus/operational-concept/lane-keeping-and-changing-lanes/#lane-keeping-and-changing-lanes","text":"The system stays the driving lane or changes lanes according to the route.","title":"Lane keeping and changing lanes"},{"location":"version-1.0/application-example/driverless-bus/operational-concept/let-passengers-on-and-off-at-bus-stops/","text":"Let passengers on and off at bus stops # The system stops at bus stops set by the in-car operator. The in-car operator manually opens and closes the door of the vehicle to let passengers on and off at bus stops due to the local government\u2019s request. After the in-car operator requests the system to depart, the system automatically resumes driving along the route.","title":"Let passengers on and off at bus stops"},{"location":"version-1.0/application-example/driverless-bus/operational-concept/let-passengers-on-and-off-at-bus-stops/#let-passengers-on-and-off-at-bus-stops","text":"The system stops at bus stops set by the in-car operator. The in-car operator manually opens and closes the door of the vehicle to let passengers on and off at bus stops due to the local government\u2019s request. After the in-car operator requests the system to depart, the system automatically resumes driving along the route.","title":"Let passengers on and off at bus stops"},{"location":"version-1.0/application-example/driverless-bus/operational-concept/nighttime-operation/","text":"Nighttime operation # During the nighttime (10pm - 1am), an in-car operator drives the vehicle from a parking lot to a start position and manually launches the autonomous driving system via HMI in the vehicle. The system starts moving automatically on a route set by the in-car operator. The in-car operator is while the system automatically operates.","title":"Nighttime operation"},{"location":"version-1.0/application-example/driverless-bus/operational-concept/nighttime-operation/#nighttime-operation","text":"During the nighttime (10pm - 1am), an in-car operator drives the vehicle from a parking lot to a start position and manually launches the autonomous driving system via HMI in the vehicle. The system starts moving automatically on a route set by the in-car operator. The in-car operator is while the system automatically operates.","title":"Nighttime operation"},{"location":"version-1.0/application-example/driverless-bus/operational-concept/operation-mode/","text":"Operation mode: Automatic/Manual # The in-car operator manually launches the autonomous driving system, which causes the system to start the autonomous driving. If the fail safe system in the vehicle detects malfunctions or the in-car operator presses the button on the fail safe system, the system automatically changes the operation mode from automatic to manual. Then the vehicle automatically stops.","title":"Operation mode: Automatic/Manual"},{"location":"version-1.0/application-example/driverless-bus/operational-concept/operation-mode/#operation-mode-automaticmanual","text":"The in-car operator manually launches the autonomous driving system, which causes the system to start the autonomous driving. If the fail safe system in the vehicle detects malfunctions or the in-car operator presses the button on the fail safe system, the system automatically changes the operation mode from automatic to manual. Then the vehicle automatically stops.","title":"Operation mode: Automatic/Manual"},{"location":"version-1.0/application-example/driverless-bus/operational-concept/predict-pedestrian-stepping-into-the-road/","text":"Predict pedestrian stepping into the road # The vehicle is programmed to detect pedestrians who may step into the road, and the vehicle decelerates in response.","title":"Predict pedestrian stepping into the road"},{"location":"version-1.0/application-example/driverless-bus/operational-concept/predict-pedestrian-stepping-into-the-road/#predict-pedestrian-stepping-into-the-road","text":"The vehicle is programmed to detect pedestrians who may step into the road, and the vehicle decelerates in response.","title":"Predict pedestrian stepping into the road"},{"location":"version-1.0/application-example/driverless-bus/operational-concept/set-service-route-via-HMI-on-the-vehicle/","text":"Set service route via HMI on the vehicle # The operator can set authorized service routes of the system via the Human Machine Interface ( HMI ) on the vehicle before the operation. The system can only accept a modified route while the vehicle is parked. NOTE: the service route cannot be changed without the authorization from the local government.","title":"Set service route via HMI on the vehicle"},{"location":"version-1.0/application-example/driverless-bus/operational-concept/set-service-route-via-HMI-on-the-vehicle/#set-service-route-via-hmi-on-the-vehicle","text":"The operator can set authorized service routes of the system via the Human Machine Interface ( HMI ) on the vehicle before the operation. The system can only accept a modified route while the vehicle is parked. NOTE: the service route cannot be changed without the authorization from the local government.","title":"Set service route via HMI on the vehicle"},{"location":"version-1.0/application-example/driverless-bus/operational-concept/take-over-request-to-the-operator/","text":"Take over request to the operator # When the system cannot judge whether it can move forward, the system sends a recommendation to hand over operation to the in-car operator. The operator is supposed to perform the following actions when requested by the system: Request to depart\uff08refer to Let passengers on and off at bus-stops \uff09 Avoid objects Detour","title":"Take over request to the operator"},{"location":"version-1.0/application-example/driverless-bus/operational-concept/take-over-request-to-the-operator/#take-over-request-to-the-operator","text":"When the system cannot judge whether it can move forward, the system sends a recommendation to hand over operation to the in-car operator. The operator is supposed to perform the following actions when requested by the system: Request to depart\uff08refer to Let passengers on and off at bus-stops \uff09 Avoid objects Detour","title":"Take over request to the operator"},{"location":"version-1.0/application-example/driverless-bus/operational-environment-requirement/","text":"Operational Environment Requirements # The content is a work in progress.","title":"Operational Environment Requirements"},{"location":"version-1.0/application-example/driverless-bus/operational-environment-requirement/#operational-environment-requirements","text":"The content is a work in progress.","title":"Operational Environment Requirements"},{"location":"version-1.0/application-example/driverless-bus/software-requirements/","text":"Software Requirements # The content is a work in progress. Operating System Requirements Kernel Module Requirements Middleware Requirements DDS Requirements Map Requirements Design docs of Autoware Autoware API Component Architecture Repository Configuration","title":"Software Requirements"},{"location":"version-1.0/application-example/driverless-bus/software-requirements/#software-requirements","text":"The content is a work in progress. Operating System Requirements Kernel Module Requirements Middleware Requirements DDS Requirements Map Requirements Design docs of Autoware Autoware API Component Architecture Repository Configuration","title":"Software Requirements"},{"location":"version-1.0/application-example/driverless-bus/software-requirements/autoware-api/","text":"Autoware API # Overview # Autoware API provides a long-term and stable operation protocol for autonomous driving vehicles, and clarifies how to support new sensors and vehicles and add new features. It also works as a framework for easy access to the functions of each component by developers of other components. Concept # There are two categories of Autoware API. One is Autoware AD API for operating the vehicle from outside the autonomous driving system such as Fleet Management System(FMS) and HMI for operators or passengers. The other is Autoware Component Interfaces for linking each internal component. Some external systems for evaluation or debugging purposes, such as simulator, are allowed access to Component Interfaces in addition to AD API. AD API Customization # For general usage, Autoware provides the default AD API implementations and configurations using Component Interfaces. If a special behavior is needed, the implementation can be modified as long as it satisfies the requirements of the specification. Component Interfaces Hierarchy # Autoware Component Interfaces have a hierarchical specification. The top-level architecture consists of several components, and each component has some options of the next-level architecture. Developers select one of them when implementing the component. The simplest next-level architecture is monolithic. This is an all-in-one and black box implementation, and is suitable for small group development, prototyping, and extremely complex functions. Others are just concepts and do not currently exist. However, these have advantages for large group development. Developers can combine their modules with other modules that adopt the same architecture. Interface Code Generation # For specification clarification and development efficiency, it is recommended to use the generated code by the defined interface. Developers may select the interface to use from the specification and refer the generated code in their program. This makes it easy to analyze the interface used by each program, which then can be applied to configuration automation and visualization.","title":"Autoware API"},{"location":"version-1.0/application-example/driverless-bus/software-requirements/autoware-api/#autoware-api","text":"","title":"Autoware API"},{"location":"version-1.0/application-example/driverless-bus/software-requirements/autoware-api/#overview","text":"Autoware API provides a long-term and stable operation protocol for autonomous driving vehicles, and clarifies how to support new sensors and vehicles and add new features. It also works as a framework for easy access to the functions of each component by developers of other components.","title":"Overview"},{"location":"version-1.0/application-example/driverless-bus/software-requirements/autoware-api/#concept","text":"There are two categories of Autoware API. One is Autoware AD API for operating the vehicle from outside the autonomous driving system such as Fleet Management System(FMS) and HMI for operators or passengers. The other is Autoware Component Interfaces for linking each internal component. Some external systems for evaluation or debugging purposes, such as simulator, are allowed access to Component Interfaces in addition to AD API.","title":"Concept"},{"location":"version-1.0/application-example/driverless-bus/software-requirements/autoware-api/#ad-api-customization","text":"For general usage, Autoware provides the default AD API implementations and configurations using Component Interfaces. If a special behavior is needed, the implementation can be modified as long as it satisfies the requirements of the specification.","title":"AD API Customization"},{"location":"version-1.0/application-example/driverless-bus/software-requirements/autoware-api/#component-interfaces-hierarchy","text":"Autoware Component Interfaces have a hierarchical specification. The top-level architecture consists of several components, and each component has some options of the next-level architecture. Developers select one of them when implementing the component. The simplest next-level architecture is monolithic. This is an all-in-one and black box implementation, and is suitable for small group development, prototyping, and extremely complex functions. Others are just concepts and do not currently exist. However, these have advantages for large group development. Developers can combine their modules with other modules that adopt the same architecture.","title":"Component Interfaces Hierarchy"},{"location":"version-1.0/application-example/driverless-bus/software-requirements/autoware-api/#interface-code-generation","text":"For specification clarification and development efficiency, it is recommended to use the generated code by the defined interface. Developers may select the interface to use from the specification and refer the generated code in their program. This makes it easy to analyze the interface used by each program, which then can be applied to configuration automation and visualization.","title":"Interface Code Generation"},{"location":"version-1.0/application-example/driverless-bus/software-requirements/component-architecture/","text":"Component architecture # Overview # The figure below is the overview of Autoware's component configuration (tentative). Autoware components # TODO(Tier IV): Write the details based on the following materials. Autoware.Auto autoware_auto_msgs Tier IV's proposal document Tier IV's proposal implementation Map # Inputs: Map file PointCloud map file Vector map file Outputs: Map data PointCloud map file Vector map file Sensing # Inputs: Raw sensor data GNSS IMU Camera LiDAR RADAR Estimated self motion To filter distortions Outputs: Preprocessed sensor data GNSS pose and doppler velocity IMU acceleration and angular velocity Camera image LiDAR PointCloud RADAR reflection Localization # Inputs: Preprocessed sensor data GNSS pose and doppler velocity IMU acceleration and angular velocity Camera image LiDAR PointCloud RADAR reflection Map data PointCloud map Vector map Outputs: Localized self pose Topic TF Estimated self motion Perception # Inputs: Localized self pose Estimated self motion Preprocessed sensor data Camera image LiDAR PointCloud RADAR reflection Outputs: Detected dynamic objects Detected traffic lights Filtered obstacle PointCloud Planning # Inputs: Localized pose Estimated self motion Outputs: Planned trajectory Planning status Control # Inputs: Localized self pose Estimated self motion Planner trajectory Vehicle sensor data velocity steering angle Outputs: Control commands High-level commands for easy usage Low-level commands for detailed controls Vehicle # Autoware to Vehicle # Inputs: Control commands Outputs: Raw vehicle control commands Vehicle to Autoware # Inputs: Raw vehicle sensor data (e.g. CAN) Outputs: Vehicle sensor data (Topic) System # Inputs: Each component output Outputs: System status MRM request","title":"Component architecture"},{"location":"version-1.0/application-example/driverless-bus/software-requirements/component-architecture/#component-architecture","text":"","title":"Component architecture"},{"location":"version-1.0/application-example/driverless-bus/software-requirements/component-architecture/#overview","text":"The figure below is the overview of Autoware's component configuration (tentative).","title":"Overview"},{"location":"version-1.0/application-example/driverless-bus/software-requirements/component-architecture/#autoware-components","text":"TODO(Tier IV): Write the details based on the following materials. Autoware.Auto autoware_auto_msgs Tier IV's proposal document Tier IV's proposal implementation","title":"Autoware components"},{"location":"version-1.0/application-example/driverless-bus/software-requirements/component-architecture/#map","text":"Inputs: Map file PointCloud map file Vector map file Outputs: Map data PointCloud map file Vector map file","title":"Map"},{"location":"version-1.0/application-example/driverless-bus/software-requirements/component-architecture/#sensing","text":"Inputs: Raw sensor data GNSS IMU Camera LiDAR RADAR Estimated self motion To filter distortions Outputs: Preprocessed sensor data GNSS pose and doppler velocity IMU acceleration and angular velocity Camera image LiDAR PointCloud RADAR reflection","title":"Sensing"},{"location":"version-1.0/application-example/driverless-bus/software-requirements/component-architecture/#localization","text":"Inputs: Preprocessed sensor data GNSS pose and doppler velocity IMU acceleration and angular velocity Camera image LiDAR PointCloud RADAR reflection Map data PointCloud map Vector map Outputs: Localized self pose Topic TF Estimated self motion","title":"Localization"},{"location":"version-1.0/application-example/driverless-bus/software-requirements/component-architecture/#perception","text":"Inputs: Localized self pose Estimated self motion Preprocessed sensor data Camera image LiDAR PointCloud RADAR reflection Outputs: Detected dynamic objects Detected traffic lights Filtered obstacle PointCloud","title":"Perception"},{"location":"version-1.0/application-example/driverless-bus/software-requirements/component-architecture/#planning","text":"Inputs: Localized pose Estimated self motion Outputs: Planned trajectory Planning status","title":"Planning"},{"location":"version-1.0/application-example/driverless-bus/software-requirements/component-architecture/#control","text":"Inputs: Localized self pose Estimated self motion Planner trajectory Vehicle sensor data velocity steering angle Outputs: Control commands High-level commands for easy usage Low-level commands for detailed controls","title":"Control"},{"location":"version-1.0/application-example/driverless-bus/software-requirements/component-architecture/#vehicle","text":"","title":"Vehicle"},{"location":"version-1.0/application-example/driverless-bus/software-requirements/component-architecture/#system","text":"Inputs: Each component output Outputs: System status MRM request","title":"System"},{"location":"version-1.0/application-example/driverless-bus/software-requirements/design-docs-of-autoware/","text":"Design docs of Autoware # In this section, we'll explain a couple of design documents of Autoware. The first one is about Autoware API . It defines two kinds of APIs for different developers. Autoware AD API for developers of external systems such as fleet management HMI , etc. AD means Autonomous Driving. Autoware Component Interface for developers of Autoware components such as Localization, Perception, etc. The second one is about the architecture of Autoware components. It explains the interface between Autoware components in detail. The last one is about the repository configuration of Autoware, which is currently used here . It explains why such a distributed structure is necessary.","title":"Design docs of Autoware"},{"location":"version-1.0/application-example/driverless-bus/software-requirements/design-docs-of-autoware/#design-docs-of-autoware","text":"In this section, we'll explain a couple of design documents of Autoware. The first one is about Autoware API . It defines two kinds of APIs for different developers. Autoware AD API for developers of external systems such as fleet management HMI , etc. AD means Autonomous Driving. Autoware Component Interface for developers of Autoware components such as Localization, Perception, etc. The second one is about the architecture of Autoware components. It explains the interface between Autoware components in detail. The last one is about the repository configuration of Autoware, which is currently used here . It explains why such a distributed structure is necessary.","title":"Design docs of Autoware"},{"location":"version-1.0/application-example/driverless-bus/software-requirements/repository-configuration/","text":"Repository configuration # Overview # This page shows the repository configuration of Autoware and its concepts. Warning Note: This figure is tentative. TODO: Add documentations repositories, WG repositories, and autoware.org. Concepts # Core/Universe architecture # Since Autoware is desired to be usable for production-level vehicles in the future, Autoware.Auto has been used strict merge criteria. However, since there is no specific requirements or specifications in Autonomous Driving, it's almost impossible to build a perfect product from the beginning. We need prototyping phases to build a high-quality product, so we're doing ODD -based developments. Then, doing every development in one branch causes slowing down of development speed or mixin of low-quality. Also, forcing such a strict rules for all contributors will make them discourage from sending PRs. Therefore, it's better to separate production level and high-quality code and prototyping level code. Specifically, we define Core/Universe for this. Core defines the interfaces of Autoware Both Core and Universe refer to the interface Core has high-quality code Universe has experimental level code With this, we aim to accomplish the following things. Contributors can feel free to send small PRs. We can keep high-quality for the Core code. We can rapidly build prototypes in Universe. We can develop a lot of extensions, including cutting-edge features, based on the interfaces. Definition of Core/Universe # Core Complete end-to-end autonomous driving framework Supports all current AWF ODDs Provides the definitions and the functionality for which other packages can extend Strict code and quality control Heavily managed by the AWF Stable base implementation Universe Additional packages built on top of Core Extends Autoware functionality beyond the AWF ODDs Completely dependent on Core functionality and message definitions Relaxed code and quality control Community managed Enables quick experimentation and prototype testing Repositories and roles # Although some repositories might be added in the future, these are enough for explaining the core concept. autowarefoundation/autoware This is a meta-repository that contains .repos files to construct a workspace. Since it's prospected to be forked by users, we don't put a lot of information here to avoid unnecessary differences. autowarefoundation/autoware_common This is a repository that contains ROS packages referenced in common by many repositories like libraries and utilities. In order to reduce the CI execution time, splitting that kind of packages from a big repository is a good practice. autowarefoundation/autoware.core This is a core repository that contains high-quality and stable ROS packages for Autonomous Driving. Although it's almost empty at this time, it will be implemented based on Autoware.Auto and Autoware.Universe during the next ODD project. autowarefoundation/autoware.universe This is a core repository that contains experimental but cutting-edge ROS packages for Autonomous Driving. autowarefoundation/autoware_launch This is a launch configuration repository that contains node configurations and their parameters. autowarefoundation/autoware-github-actions This is a repository for CI that contains reusable workflows of GitHub Actions . Since Autoware has a lot of repositories in total, making CI scripts DRY(Don't Repeat Yourself) is efficient. autowarefoundation/autoware-documentation This is a documentation repository for Autoware users and developers. Since Autoware Core/Universe has multiple repositories, preparing a central documentation repository is more user-friendly than writing distributed documentation in each repository. FAQ # Why don't use the meta-repository for documentation? # Since it's forked by many users, documentation changes would be noise during syncing repositories. Why autoware.org isn't enough for documentation? # Since Software Engineers can't maintain it easily, it's hard to write a lot of information and keep up-to-date. Why both autoware-documentation and autoware-reference-design (this site) are required? # It's for a kind of separation of concerns. Too much information on one site makes confusion. autoware-documentation is mainly for users. autoware-reference-design is for core developers.","title":"Repository configuration"},{"location":"version-1.0/application-example/driverless-bus/software-requirements/repository-configuration/#repository-configuration","text":"","title":"Repository configuration"},{"location":"version-1.0/application-example/driverless-bus/software-requirements/repository-configuration/#overview","text":"This page shows the repository configuration of Autoware and its concepts. Warning Note: This figure is tentative. TODO: Add documentations repositories, WG repositories, and autoware.org.","title":"Overview"},{"location":"version-1.0/application-example/driverless-bus/software-requirements/repository-configuration/#concepts","text":"","title":"Concepts"},{"location":"version-1.0/application-example/driverless-bus/software-requirements/repository-configuration/#coreuniverse-architecture","text":"Since Autoware is desired to be usable for production-level vehicles in the future, Autoware.Auto has been used strict merge criteria. However, since there is no specific requirements or specifications in Autonomous Driving, it's almost impossible to build a perfect product from the beginning. We need prototyping phases to build a high-quality product, so we're doing ODD -based developments. Then, doing every development in one branch causes slowing down of development speed or mixin of low-quality. Also, forcing such a strict rules for all contributors will make them discourage from sending PRs. Therefore, it's better to separate production level and high-quality code and prototyping level code. Specifically, we define Core/Universe for this. Core defines the interfaces of Autoware Both Core and Universe refer to the interface Core has high-quality code Universe has experimental level code With this, we aim to accomplish the following things. Contributors can feel free to send small PRs. We can keep high-quality for the Core code. We can rapidly build prototypes in Universe. We can develop a lot of extensions, including cutting-edge features, based on the interfaces.","title":"Core/Universe architecture"},{"location":"version-1.0/application-example/driverless-bus/software-requirements/repository-configuration/#definition-of-coreuniverse","text":"Core Complete end-to-end autonomous driving framework Supports all current AWF ODDs Provides the definitions and the functionality for which other packages can extend Strict code and quality control Heavily managed by the AWF Stable base implementation Universe Additional packages built on top of Core Extends Autoware functionality beyond the AWF ODDs Completely dependent on Core functionality and message definitions Relaxed code and quality control Community managed Enables quick experimentation and prototype testing","title":"Definition of Core/Universe"},{"location":"version-1.0/application-example/driverless-bus/software-requirements/repository-configuration/#repositories-and-roles","text":"Although some repositories might be added in the future, these are enough for explaining the core concept. autowarefoundation/autoware This is a meta-repository that contains .repos files to construct a workspace. Since it's prospected to be forked by users, we don't put a lot of information here to avoid unnecessary differences. autowarefoundation/autoware_common This is a repository that contains ROS packages referenced in common by many repositories like libraries and utilities. In order to reduce the CI execution time, splitting that kind of packages from a big repository is a good practice. autowarefoundation/autoware.core This is a core repository that contains high-quality and stable ROS packages for Autonomous Driving. Although it's almost empty at this time, it will be implemented based on Autoware.Auto and Autoware.Universe during the next ODD project. autowarefoundation/autoware.universe This is a core repository that contains experimental but cutting-edge ROS packages for Autonomous Driving. autowarefoundation/autoware_launch This is a launch configuration repository that contains node configurations and their parameters. autowarefoundation/autoware-github-actions This is a repository for CI that contains reusable workflows of GitHub Actions . Since Autoware has a lot of repositories in total, making CI scripts DRY(Don't Repeat Yourself) is efficient. autowarefoundation/autoware-documentation This is a documentation repository for Autoware users and developers. Since Autoware Core/Universe has multiple repositories, preparing a central documentation repository is more user-friendly than writing distributed documentation in each repository.","title":"Repositories and roles"},{"location":"version-1.0/application-example/driverless-bus/software-requirements/repository-configuration/#faq","text":"","title":"FAQ"},{"location":"version-1.0/application-example/driverless-bus/software-requirements/repository-configuration/#why-dont-use-the-meta-repository-for-documentation","text":"Since it's forked by many users, documentation changes would be noise during syncing repositories.","title":"Why don't use the meta-repository for documentation?"},{"location":"version-1.0/application-example/driverless-bus/software-requirements/repository-configuration/#why-autowareorg-isnt-enough-for-documentation","text":"Since Software Engineers can't maintain it easily, it's hard to write a lot of information and keep up-to-date.","title":"Why autoware.org isn't enough for documentation?"},{"location":"version-1.0/application-example/driverless-bus/software-requirements/repository-configuration/#why-both-autoware-documentation-and-autoware-reference-design-this-site-are-required","text":"It's for a kind of separation of concerns. Too much information on one site makes confusion. autoware-documentation is mainly for users. autoware-reference-design is for core developers.","title":"Why both autoware-documentation and autoware-reference-design (this site) are required?"},{"location":"version-1.0/application-example/driverless-bus/system-configuration/","text":"System Configuration # The content is a work in progress. This chapter should show the physical configuration of the system.","title":"System Configuration"},{"location":"version-1.0/application-example/driverless-bus/system-configuration/#system-configuration","text":"The content is a work in progress. This chapter should show the physical configuration of the system.","title":"System Configuration"},{"location":"version-1.0/application-example/driverless-bus/system-requirements/","text":"System Requirements # The content is a work in progress. This chapter should show requirements for the system of interest and its sub-systems. Parity Requirements","title":"System Requirements"},{"location":"version-1.0/application-example/driverless-bus/system-requirements/#system-requirements","text":"The content is a work in progress. This chapter should show requirements for the system of interest and its sub-systems. Parity Requirements","title":"System Requirements"},{"location":"version-1.0/application-example/driverless-bus/system-requirements/parity-requirements/","text":"Parity # Importance of the parity in the verification of autonomous driving systems # One of the most important points in the verification process of the autonomous driving system is the guaranteed level of the parity between the edge (onboard) and the cloud (CI /CD) environment. Various types of the parity and the information that is useful in the verification architecture taking the parity into consideration \u3000 are explained. Parity types # Device Parity # The parity of the hardware (machines). When using the public cloud, as the device variation available on the public cloud is generally limited, it is difficult to guarantee this device parity. CPU Architecture Parity # The parity of the processor implementation including the microservice architecture and the clock speed, etc. ISA Parity # The ISA (Instruction Set Architecture) Parity is different from the CPU Architecture Parity. It means the parity of the available register resource, instruction set, and the calculation functionality, where the processor implementation is abstracted. Runtime Parity # The Runtime Parity means the parity of the kernel module and the container runtime, where the built result at the application level is guaranteed to run flawlessly. However, depending on the implementation, some modules do not run even if the Runtime Parity is secured. For example, the object detection module which is optimized for a GPU model. Environment Parity # The Environment Parity means the parity of the network configuration, set of frameworks and libraries of the autonomous driving system applications. Parity and Cloud Native DevOps # In autonomous driving system verification, it is important to conduct the necessary tests by understanding what level of parity is guaranteed for the verification environment compared to the vehicle environment. On the other hand, in case that the public cloud is used as a cloud native environment, the Device Parity may not be fulfilled. Depending on the choice of the chip, the CPU Architecture Parity or the ISA Parity may not be met. It is crucial to conduct tests in the bench environment while improving the development experience by executing the sufficient number of tests in a short time period in a cloud native manner.","title":"Parity"},{"location":"version-1.0/application-example/driverless-bus/system-requirements/parity-requirements/#parity","text":"","title":"Parity"},{"location":"version-1.0/application-example/driverless-bus/system-requirements/parity-requirements/#importance-of-the-parity-in-the-verification-of-autonomous-driving-systems","text":"One of the most important points in the verification process of the autonomous driving system is the guaranteed level of the parity between the edge (onboard) and the cloud (CI /CD) environment. Various types of the parity and the information that is useful in the verification architecture taking the parity into consideration \u3000 are explained.","title":"Importance of the parity in the verification of autonomous driving systems"},{"location":"version-1.0/application-example/driverless-bus/system-requirements/parity-requirements/#parity-types","text":"","title":"Parity types"},{"location":"version-1.0/application-example/driverless-bus/system-requirements/parity-requirements/#device-parity","text":"The parity of the hardware (machines). When using the public cloud, as the device variation available on the public cloud is generally limited, it is difficult to guarantee this device parity.","title":"Device Parity"},{"location":"version-1.0/application-example/driverless-bus/system-requirements/parity-requirements/#cpu-architecture-parity","text":"The parity of the processor implementation including the microservice architecture and the clock speed, etc.","title":"CPU Architecture Parity"},{"location":"version-1.0/application-example/driverless-bus/system-requirements/parity-requirements/#isa-parity","text":"The ISA (Instruction Set Architecture) Parity is different from the CPU Architecture Parity. It means the parity of the available register resource, instruction set, and the calculation functionality, where the processor implementation is abstracted.","title":"ISA Parity"},{"location":"version-1.0/application-example/driverless-bus/system-requirements/parity-requirements/#runtime-parity","text":"The Runtime Parity means the parity of the kernel module and the container runtime, where the built result at the application level is guaranteed to run flawlessly. However, depending on the implementation, some modules do not run even if the Runtime Parity is secured. For example, the object detection module which is optimized for a GPU model.","title":"Runtime Parity"},{"location":"version-1.0/application-example/driverless-bus/system-requirements/parity-requirements/#environment-parity","text":"The Environment Parity means the parity of the network configuration, set of frameworks and libraries of the autonomous driving system applications.","title":"Environment Parity"},{"location":"version-1.0/application-example/driverless-bus/system-requirements/parity-requirements/#parity-and-cloud-native-devops","text":"In autonomous driving system verification, it is important to conduct the necessary tests by understanding what level of parity is guaranteed for the verification environment compared to the vehicle environment. On the other hand, in case that the public cloud is used as a cloud native environment, the Device Parity may not be fulfilled. Depending on the choice of the chip, the CPU Architecture Parity or the ISA Parity may not be met. It is crucial to conduct tests in the bench environment while improving the development experience by executing the sufficient number of tests in a short time period in a cloud native manner.","title":"Parity and Cloud Native DevOps"},{"location":"version-1.0/start-guide/","text":"Start guide # This page describes how to install, set up and run Autoware and its associated simulators on supported development platforms. Installation explains how to set up the development environment that are described in the System Configuration chapter. How to run Autoware shows how to run Autoware on the development platform that are set up in the Installation chapter. How to run simulators demonstrates how to run simulators that are set up in the Installation chapter.","title":"Start guide"},{"location":"version-1.0/start-guide/#start-guide","text":"This page describes how to install, set up and run Autoware and its associated simulators on supported development platforms. Installation explains how to set up the development environment that are described in the System Configuration chapter. How to run Autoware shows how to run Autoware on the development platform that are set up in the Installation chapter. How to run simulators demonstrates how to run simulators that are set up in the Installation chapter.","title":"Start guide"},{"location":"version-1.0/start-guide/how-to-run-autoware/","text":"How to run Autoware # This page explains how to run Autoware on the development platform that are set up in the Installation chapter . Minimum requirements # Developer Platform: TODO In-Vehicle Development Platform 1 : TODO Software Tool: TODO Container Image: TODO 1. Run Autoware on the developer platform # Run Autoware.Auto on AVA platform or PCU # Open terminal window for each module on you host. Access AVA platform or PCU via SSH in each terminal window. Find docker image id. docker image ls REPOSITORY TAG IMAGE ID CREATED SIZE public.ecr.aws/k7o9k6q7/tier4/autoware.auto open_ad_kit-autoware-auto-20211111234534-88ea1196cdc0-2zv2o 48a4503b4fe4 11 days ago 6.65GB You can find id such as 48a4503b4fe4 . Launch modules. Replace 48a4503b4fe4 with your docker image id. Terminal 1 (map) docker run --rm -it --net host -v ~/map:/map -v ~/cyclonedds:/etc/cyclonedds 48a4503b4fe4 /bin/bash -c \"export CYCLONEDDS_URI=file:///etc/cyclonedds/cyclonedds.xml; export RMW_IMPLEMENTATION=rmw_cyclonedds_cpp; source install/setup.bash; ros2 launch scenario_simulator_launch autoware_auto_mapping.launch.py map_path:=/map/kashiwanoha\" Terminal 2 (perception) docker run --rm -it --net host -v ~/cyclonedds:/etc/cyclonedds 48a4503b4fe4 /bin/bash -c \"export CYCLONEDDS_URI=file:///etc/cyclonedds/cyclonedds.xml; export RMW_IMPLEMENTATION=rmw_cyclonedds_cpp; source install/setup.bash; ros2 launch scenario_simulator_launch autoware_auto_perception.launch.py\" Terminal 3 (planning) docker run --rm -it --net host -v ~/cyclonedds:/etc/cyclonedds 48a4503b4fe4 /bin/bash -c \"export CYCLONEDDS_URI=file:///etc/cyclonedds/cyclonedds.xml; export RMW_IMPLEMENTATION=rmw_cyclonedds_cpp; source install/setup.bash; ros2 launch scenario_simulator_launch autoware_auto_planning.launch.py\" Terminal 4 (vehicle) docker run --rm -it --net host -v ~/cyclonedds:/etc/cyclonedds 48a4503b4fe4 /bin/bash -c \"export CYCLONEDDS_URI=file:///etc/cyclonedds/cyclonedds.xml; export RMW_IMPLEMENTATION=rmw_cyclonedds_cpp; source install/setup.bash; ros2 launch autoware_auto_launch autoware_auto_vehicle.launch.py\" 2. Run Autoware on the in-vehicle development platform # If you do NOT need a vehicle-edge platform, please skip this step. TODO 3. Run simulators on the development platform # Please refer to the How to run simulators section. This is optional if you do NOT need a vehicle-edge platform. \u21a9","title":"How to run Autoware"},{"location":"version-1.0/start-guide/how-to-run-autoware/#how-to-run-autoware","text":"This page explains how to run Autoware on the development platform that are set up in the Installation chapter .","title":"How to run Autoware"},{"location":"version-1.0/start-guide/how-to-run-autoware/#minimum-requirements","text":"Developer Platform: TODO In-Vehicle Development Platform 1 : TODO Software Tool: TODO Container Image: TODO","title":"Minimum requirements"},{"location":"version-1.0/start-guide/how-to-run-autoware/#1-run-autoware-on-the-developer-platform","text":"","title":"1. Run Autoware on the developer platform"},{"location":"version-1.0/start-guide/how-to-run-autoware/#run-autowareauto-on-ava-platform-or-pcu","text":"Open terminal window for each module on you host. Access AVA platform or PCU via SSH in each terminal window. Find docker image id. docker image ls REPOSITORY TAG IMAGE ID CREATED SIZE public.ecr.aws/k7o9k6q7/tier4/autoware.auto open_ad_kit-autoware-auto-20211111234534-88ea1196cdc0-2zv2o 48a4503b4fe4 11 days ago 6.65GB You can find id such as 48a4503b4fe4 . Launch modules. Replace 48a4503b4fe4 with your docker image id. Terminal 1 (map) docker run --rm -it --net host -v ~/map:/map -v ~/cyclonedds:/etc/cyclonedds 48a4503b4fe4 /bin/bash -c \"export CYCLONEDDS_URI=file:///etc/cyclonedds/cyclonedds.xml; export RMW_IMPLEMENTATION=rmw_cyclonedds_cpp; source install/setup.bash; ros2 launch scenario_simulator_launch autoware_auto_mapping.launch.py map_path:=/map/kashiwanoha\" Terminal 2 (perception) docker run --rm -it --net host -v ~/cyclonedds:/etc/cyclonedds 48a4503b4fe4 /bin/bash -c \"export CYCLONEDDS_URI=file:///etc/cyclonedds/cyclonedds.xml; export RMW_IMPLEMENTATION=rmw_cyclonedds_cpp; source install/setup.bash; ros2 launch scenario_simulator_launch autoware_auto_perception.launch.py\" Terminal 3 (planning) docker run --rm -it --net host -v ~/cyclonedds:/etc/cyclonedds 48a4503b4fe4 /bin/bash -c \"export CYCLONEDDS_URI=file:///etc/cyclonedds/cyclonedds.xml; export RMW_IMPLEMENTATION=rmw_cyclonedds_cpp; source install/setup.bash; ros2 launch scenario_simulator_launch autoware_auto_planning.launch.py\" Terminal 4 (vehicle) docker run --rm -it --net host -v ~/cyclonedds:/etc/cyclonedds 48a4503b4fe4 /bin/bash -c \"export CYCLONEDDS_URI=file:///etc/cyclonedds/cyclonedds.xml; export RMW_IMPLEMENTATION=rmw_cyclonedds_cpp; source install/setup.bash; ros2 launch autoware_auto_launch autoware_auto_vehicle.launch.py\"","title":"Run Autoware.Auto on AVA platform or PCU"},{"location":"version-1.0/start-guide/how-to-run-autoware/#2-run-autoware-on-the-in-vehicle-development-platform","text":"If you do NOT need a vehicle-edge platform, please skip this step. TODO","title":"2. Run Autoware on the in-vehicle development platform"},{"location":"version-1.0/start-guide/how-to-run-autoware/#3-run-simulators-on-the-development-platform","text":"Please refer to the How to run simulators section. This is optional if you do NOT need a vehicle-edge platform. \u21a9","title":"3. Run simulators on the development platform"},{"location":"version-1.0/start-guide/how-to-run-simulators/","text":"How to run simulators # This page describes how to run simulators that work on your local environment and the cloud environment. Scenario simulator verifies your planning algorithms. Logging simulator verifies your perception algorithms with ROSBAG data that are recorded beforehand. There are some limitations and issues for the simulators.","title":"How to run simulators"},{"location":"version-1.0/start-guide/how-to-run-simulators/#how-to-run-simulators","text":"This page describes how to run simulators that work on your local environment and the cloud environment. Scenario simulator verifies your planning algorithms. Logging simulator verifies your perception algorithms with ROSBAG data that are recorded beforehand. There are some limitations and issues for the simulators.","title":"How to run simulators"},{"location":"version-1.0/start-guide/how-to-run-simulators/limitations-and-issues/limitations-and-issues/","text":"Limitations and issues # Limitations # Simulation by using LGSVL is not supported because a map for scenario simulator ( kashiwanoha ) is not registered in LGSVL Simulator Content Store. Issues # The ego vehicle drives slowly. UC-001-0018-Kashiwa:1 failed with simulation timeout. The ego vehicle gets stuck after NPC crossed ahead of the ego vehicle. This might be caused by the slow driving.","title":"Limitations and issues"},{"location":"version-1.0/start-guide/how-to-run-simulators/limitations-and-issues/limitations-and-issues/#limitations-and-issues","text":"","title":"Limitations and issues"},{"location":"version-1.0/start-guide/how-to-run-simulators/limitations-and-issues/limitations-and-issues/#limitations","text":"Simulation by using LGSVL is not supported because a map for scenario simulator ( kashiwanoha ) is not registered in LGSVL Simulator Content Store.","title":"Limitations"},{"location":"version-1.0/start-guide/how-to-run-simulators/limitations-and-issues/limitations-and-issues/#issues","text":"The ego vehicle drives slowly. UC-001-0018-Kashiwa:1 failed with simulation timeout. The ego vehicle gets stuck after NPC crossed ahead of the ego vehicle. This might be caused by the slow driving.","title":"Issues"},{"location":"version-1.0/start-guide/how-to-run-simulators/logging-simulator/run-on-cloud-env/","text":"Run on the cloud platform # This page describes how to run the logging simulator on the cloud platform. The cloud platform, Web.Auto, is offered by TIER IV , and it is available for the Autoware Foundation members. Minimum requirements # Developer Platform: TODO In-Vehicle Development Platform 1 : TODO Software Tool: TODO Container Image: TODO Data Pipeline: TODO 1. Create your account on the cloud platform # If you already have access to Web.Auto, please skip this step. TODO 2. Set up a simulation on the cloud platform # TODO 3. Run the logging simulator on the cloud platform # TODO This is optional if you do NOT need a vehicle-edge platform. \u21a9","title":"Run on the cloud platform"},{"location":"version-1.0/start-guide/how-to-run-simulators/logging-simulator/run-on-cloud-env/#run-on-the-cloud-platform","text":"This page describes how to run the logging simulator on the cloud platform. The cloud platform, Web.Auto, is offered by TIER IV , and it is available for the Autoware Foundation members.","title":"Run on the cloud platform"},{"location":"version-1.0/start-guide/how-to-run-simulators/logging-simulator/run-on-cloud-env/#minimum-requirements","text":"Developer Platform: TODO In-Vehicle Development Platform 1 : TODO Software Tool: TODO Container Image: TODO Data Pipeline: TODO","title":"Minimum requirements"},{"location":"version-1.0/start-guide/how-to-run-simulators/logging-simulator/run-on-cloud-env/#1-create-your-account-on-the-cloud-platform","text":"If you already have access to Web.Auto, please skip this step. TODO","title":"1. Create your account on the cloud platform"},{"location":"version-1.0/start-guide/how-to-run-simulators/logging-simulator/run-on-cloud-env/#2-set-up-a-simulation-on-the-cloud-platform","text":"TODO","title":"2. Set up a simulation on the cloud platform"},{"location":"version-1.0/start-guide/how-to-run-simulators/logging-simulator/run-on-cloud-env/#3-run-the-logging-simulator-on-the-cloud-platform","text":"TODO This is optional if you do NOT need a vehicle-edge platform. \u21a9","title":"3. Run the logging simulator on the cloud platform"},{"location":"version-1.0/start-guide/how-to-run-simulators/scenario-simulator/run-on-cloud-env/","text":"Run on the cloud platform # This page describes how to run the scenario simulator on the cloud platform. The cloud platform, Web.Auto, is offered by TIER IV , and it is available for the Autoware Foundation members. Minimum requirements # Developer Platform: TODO In-Vehicle Development Platform 1 : TODO Software Tool: TODO Container Image: TODO Data Pipeline: TODO 1. Create your account on the cloud platform # If you already have access to Web.Auto, please skip this step. Cloud Native CI/CD Pipeline - Web.Auto # The CI/CD pipeline for the scenario simulation is available for the Autoware Foundation members. You can check the scenario simulation results on the CI/CD dashboard. This material describes the CI/CD pipeline in more details. Create an account with Tier IV account server ( https://account.tier4.jp/ ). Participate in an Autoware Foundation working group (Simulation, Autonomy Software, Operational Design DomainD, Open AD Kit) and report the Tier IV Account ID you created in 1. to the leader of your working group. Then you can login to the CI/CD dashboard and see the scenario simulation results. 2. Set up a simulation on the cloud platform # TODO 3. Run the scenario simulator on the cloud platform # TODO This is optional if you do NOT need a vehicle-edge platform. \u21a9","title":"Run on the cloud platform"},{"location":"version-1.0/start-guide/how-to-run-simulators/scenario-simulator/run-on-cloud-env/#run-on-the-cloud-platform","text":"This page describes how to run the scenario simulator on the cloud platform. The cloud platform, Web.Auto, is offered by TIER IV , and it is available for the Autoware Foundation members.","title":"Run on the cloud platform"},{"location":"version-1.0/start-guide/how-to-run-simulators/scenario-simulator/run-on-cloud-env/#minimum-requirements","text":"Developer Platform: TODO In-Vehicle Development Platform 1 : TODO Software Tool: TODO Container Image: TODO Data Pipeline: TODO","title":"Minimum requirements"},{"location":"version-1.0/start-guide/how-to-run-simulators/scenario-simulator/run-on-cloud-env/#1-create-your-account-on-the-cloud-platform","text":"If you already have access to Web.Auto, please skip this step.","title":"1. Create your account on the cloud platform"},{"location":"version-1.0/start-guide/how-to-run-simulators/scenario-simulator/run-on-cloud-env/#2-set-up-a-simulation-on-the-cloud-platform","text":"TODO","title":"2. Set up a simulation on the cloud platform"},{"location":"version-1.0/start-guide/how-to-run-simulators/scenario-simulator/run-on-cloud-env/#3-run-the-scenario-simulator-on-the-cloud-platform","text":"TODO This is optional if you do NOT need a vehicle-edge platform. \u21a9","title":"3. Run the scenario simulator on the cloud platform"},{"location":"version-1.0/start-guide/how-to-run-simulators/scenario-simulator/run-on-local-env/","text":"Run on your local environment # This page describes how to run the scenario simulator on the developer platform that is set up in the Installation chapter. Minimum requirements # Developer Platform: TODO In-Vehicle Development Platform 1 : TODO Software Tool: TODO Container Image: TODO Data Pipeline: TODO Run visualization and scenario simulator on the developer platform # Run Rviz. You already cloned Autoware.Auto repository, navigate to the cloned directory. Launch ADE. cd ~/adehome/AutowareAuto ade --rc .aderc-amd64-foxy-lgsvl start --update --enter Launch visualization in ADE. source /opt/AutowareAuto/setup.bash ros2 launch autoware_auto_launch autoware_auto_visualization.launch.py Find docker image id. docker image ls REPOSITORY TAG IMAGE ID CREATED SIZE registry.gitlab.com/autowarefoundation/autoware.auto/autowareauto/amd64/binary-foxy master 91512aa9e485 3 days ago 176MB registry.gitlab.com/autowarefoundation/autoware.auto/autowareauto/amd64/ade-foxy master 0d9978b7113d 4 days ago 5.74GB scenario_simulator open_ad_kit-autoware-auto-planning_sim_v2-20211111234534-88ea1196cdc0-2zv2o d766a256a8c3 11 days ago 5.95GB registry.gitlab.com/autowarefoundation/autoware.auto/ade-lgsvl/foxy 2021.3 077c172fa5b9 5 weeks ago 379MB You can find id such as d766a256a8c3 . Launch scenario simulator. Replace /home/foo with your home directory. Replace d766a256a8c3 with your docker image id. docker run --rm -it --net host -v /home/foo/scenario:/scenario -v /home/foo/cyclonedds:/etc/cyclonedds d766a256a8c3 /bin/bash -c \"export CYCLONEDDS_URI=file:///etc/cyclonedds/cyclonedds.xml; export RMW_IMPLEMENTATION=rmw_cyclonedds_cpp; source install/setup.bash; ros2 launch scenario_test_runner scenario_test_runner.launch.py sensor_model:=aip_xx1 vehicle_model:=lexus launch_autoware:=false architecture_type:=awf/auto scenario:=/scenario/scenario_e3b743e7-110c-4db6-b136-e5ffd5538315_2.yml\" Now you can see... DEMO Video This is optional if you do NOT need a vehicle-edge platform. \u21a9","title":"Run on your local environment"},{"location":"version-1.0/start-guide/how-to-run-simulators/scenario-simulator/run-on-local-env/#run-on-your-local-environment","text":"This page describes how to run the scenario simulator on the developer platform that is set up in the Installation chapter.","title":"Run on your local environment"},{"location":"version-1.0/start-guide/how-to-run-simulators/scenario-simulator/run-on-local-env/#minimum-requirements","text":"Developer Platform: TODO In-Vehicle Development Platform 1 : TODO Software Tool: TODO Container Image: TODO Data Pipeline: TODO","title":"Minimum requirements"},{"location":"version-1.0/start-guide/how-to-run-simulators/scenario-simulator/run-on-local-env/#run-visualization-and-scenario-simulator-on-the-developer-platform","text":"Run Rviz. You already cloned Autoware.Auto repository, navigate to the cloned directory. Launch ADE. cd ~/adehome/AutowareAuto ade --rc .aderc-amd64-foxy-lgsvl start --update --enter Launch visualization in ADE. source /opt/AutowareAuto/setup.bash ros2 launch autoware_auto_launch autoware_auto_visualization.launch.py Find docker image id. docker image ls REPOSITORY TAG IMAGE ID CREATED SIZE registry.gitlab.com/autowarefoundation/autoware.auto/autowareauto/amd64/binary-foxy master 91512aa9e485 3 days ago 176MB registry.gitlab.com/autowarefoundation/autoware.auto/autowareauto/amd64/ade-foxy master 0d9978b7113d 4 days ago 5.74GB scenario_simulator open_ad_kit-autoware-auto-planning_sim_v2-20211111234534-88ea1196cdc0-2zv2o d766a256a8c3 11 days ago 5.95GB registry.gitlab.com/autowarefoundation/autoware.auto/ade-lgsvl/foxy 2021.3 077c172fa5b9 5 weeks ago 379MB You can find id such as d766a256a8c3 . Launch scenario simulator. Replace /home/foo with your home directory. Replace d766a256a8c3 with your docker image id. docker run --rm -it --net host -v /home/foo/scenario:/scenario -v /home/foo/cyclonedds:/etc/cyclonedds d766a256a8c3 /bin/bash -c \"export CYCLONEDDS_URI=file:///etc/cyclonedds/cyclonedds.xml; export RMW_IMPLEMENTATION=rmw_cyclonedds_cpp; source install/setup.bash; ros2 launch scenario_test_runner scenario_test_runner.launch.py sensor_model:=aip_xx1 vehicle_model:=lexus launch_autoware:=false architecture_type:=awf/auto scenario:=/scenario/scenario_e3b743e7-110c-4db6-b136-e5ffd5538315_2.yml\" Now you can see... DEMO Video This is optional if you do NOT need a vehicle-edge platform. \u21a9","title":"Run visualization and scenario simulator on the developer platform"},{"location":"version-1.0/start-guide/installation/","text":"Installation # This page explains how to set up the development environment that are described in the System Configuration chapter. Minimum requirements # Developer Platform: AVA Platform or PCU Platform In-Vehicle Development Platform 1 : TODO Software Tool: Scenario simulator version x.x 2 Rviz version x.x 2 Container Image: Autoware.Auto for arm64 Scenario simulator for x86_64 2 The following diagram shows a minimum configuration of Open AD Kit. \"Your host machine\" will be replaced by the cloud development platform if you can use Web.Auto. 1. Set up the developer platform # The setup procedure depends on the developer platform. AVA Platform # Getting started with EWAOL Boot EWAOL via SSD Boot Extend rootfs partition PCU Platform # Getting started with PCU 2. Set up the in-vehicle platform # If you do NOT need a vehicle-edge platform, please skip this step. TODO 3. Install Autoware container images on the developer platform # AVA Platform # System setup on AVA Platform PCU Platform # System setup on PCU 4. Install Autoware container images on the in-vehicle platform # If you do NOT need a vehicle-edge platform, please skip this step. TODO 5. Set up software tools # If you can use the cloud development platform, please skip this step. AVA Platform # System setup on your host PCU Platform # System setup on your host 6. Run Autoware on the development platform # Please refer to the How to run Autoware section. This is unnecessary if you do NOT need a vehicle-edge platform. \u21a9 This is unnecessary if you can use the cloud development platform, Web.Auto. \u21a9 \u21a9 \u21a9","title":"Installation"},{"location":"version-1.0/start-guide/installation/#installation","text":"This page explains how to set up the development environment that are described in the System Configuration chapter.","title":"Installation"},{"location":"version-1.0/start-guide/installation/#minimum-requirements","text":"Developer Platform: AVA Platform or PCU Platform In-Vehicle Development Platform 1 : TODO Software Tool: Scenario simulator version x.x 2 Rviz version x.x 2 Container Image: Autoware.Auto for arm64 Scenario simulator for x86_64 2 The following diagram shows a minimum configuration of Open AD Kit. \"Your host machine\" will be replaced by the cloud development platform if you can use Web.Auto.","title":"Minimum requirements"},{"location":"version-1.0/start-guide/installation/#1-set-up-the-developer-platform","text":"The setup procedure depends on the developer platform.","title":"1. Set up the developer platform"},{"location":"version-1.0/start-guide/installation/#ava-platform","text":"Getting started with EWAOL Boot EWAOL via SSD Boot Extend rootfs partition","title":"AVA Platform"},{"location":"version-1.0/start-guide/installation/#pcu-platform","text":"Getting started with PCU","title":"PCU Platform"},{"location":"version-1.0/start-guide/installation/#2-set-up-the-in-vehicle-platform","text":"If you do NOT need a vehicle-edge platform, please skip this step. TODO","title":"2. Set up the in-vehicle platform"},{"location":"version-1.0/start-guide/installation/#3-install-autoware-container-images-on-the-developer-platform","text":"","title":"3. Install Autoware container images on the developer platform"},{"location":"version-1.0/start-guide/installation/#ava-platform_1","text":"System setup on AVA Platform","title":"AVA Platform"},{"location":"version-1.0/start-guide/installation/#pcu-platform_1","text":"System setup on PCU","title":"PCU Platform"},{"location":"version-1.0/start-guide/installation/#4-install-autoware-container-images-on-the-in-vehicle-platform","text":"If you do NOT need a vehicle-edge platform, please skip this step. TODO","title":"4. Install Autoware container images on the in-vehicle platform"},{"location":"version-1.0/start-guide/installation/#5-set-up-software-tools","text":"If you can use the cloud development platform, please skip this step.","title":"5. Set up software tools"},{"location":"version-1.0/start-guide/installation/#ava-platform_2","text":"System setup on your host","title":"AVA Platform"},{"location":"version-1.0/start-guide/installation/#pcu-platform_2","text":"System setup on your host","title":"PCU Platform"},{"location":"version-1.0/start-guide/installation/#6-run-autoware-on-the-development-platform","text":"Please refer to the How to run Autoware section. This is unnecessary if you do NOT need a vehicle-edge platform. \u21a9 This is unnecessary if you can use the cloud development platform, Web.Auto. \u21a9 \u21a9 \u21a9","title":"6. Run Autoware on the development platform"},{"location":"version-1.0/start-guide/installation/boot-ewaol/","text":"Boot EWAOL via SSD Boot # Overview # You need to use SSD enclosure case to flash yocto image to M.2 SSD directly. Get yocto image # Build yocto image with EWAOL by following the instructions Getting started with EWAOL , or Download the image from the website to your host machine; AVA Developer Platform Downloads \u2013 I-Pi SMARC ( Yocto with SOAFEE is preferred.) Flash yocto image # Remove M.2 SSD from AVA platform and flash yocto image to it directly. Remove M.2 SSD from AVA platform. Install M.2 SSD into a M.2 enclosure case. Plug it into your host machine. Then, show available block devices. lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT ... sdn 8:208 0 119.2G 0 disk \u251c\u2500sdn1 8:209 0 512M 0 part \u251c\u2500sdn2 8:210 0 1G 0 part /media/foo/7d00c690-db24-462d-8c8d-dce7bdf151d8 \u2514\u2500sdn3 8:211 0 117.8G 0 part Flush yocto image to M.2 SSD. For example sudo dd if=ewaol-image-docker-comhpc-20211022083723.rootfs.wic of=/dev/sdn bs=1M status=progress && sync Extend rootfs partition # You have to extend rootfs partition. Follow the instructions Extend rootfs partition Reinstall SSD # Remove M.2 SSD from enclosure case and install it into AVA platform, then turn it on. The following screen comes up, then login as root without password. EWAOL (Edge Workload Abstraction and Orchestration Layer) 0.1 comhpc tty1 comhpc login: You are able to access via SSH.","title":"Boot EWAOL via SSD Boot"},{"location":"version-1.0/start-guide/installation/boot-ewaol/#boot-ewaol-via-ssd-boot","text":"","title":"Boot EWAOL via SSD Boot"},{"location":"version-1.0/start-guide/installation/boot-ewaol/#overview","text":"You need to use SSD enclosure case to flash yocto image to M.2 SSD directly.","title":"Overview"},{"location":"version-1.0/start-guide/installation/boot-ewaol/#get-yocto-image","text":"Build yocto image with EWAOL by following the instructions Getting started with EWAOL , or Download the image from the website to your host machine; AVA Developer Platform Downloads \u2013 I-Pi SMARC ( Yocto with SOAFEE is preferred.)","title":"Get yocto image"},{"location":"version-1.0/start-guide/installation/boot-ewaol/#flash-yocto-image","text":"Remove M.2 SSD from AVA platform and flash yocto image to it directly. Remove M.2 SSD from AVA platform. Install M.2 SSD into a M.2 enclosure case. Plug it into your host machine. Then, show available block devices. lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT ... sdn 8:208 0 119.2G 0 disk \u251c\u2500sdn1 8:209 0 512M 0 part \u251c\u2500sdn2 8:210 0 1G 0 part /media/foo/7d00c690-db24-462d-8c8d-dce7bdf151d8 \u2514\u2500sdn3 8:211 0 117.8G 0 part Flush yocto image to M.2 SSD. For example sudo dd if=ewaol-image-docker-comhpc-20211022083723.rootfs.wic of=/dev/sdn bs=1M status=progress && sync","title":"Flash yocto image"},{"location":"version-1.0/start-guide/installation/boot-ewaol/#extend-rootfs-partition","text":"You have to extend rootfs partition. Follow the instructions Extend rootfs partition","title":"Extend rootfs partition"},{"location":"version-1.0/start-guide/installation/boot-ewaol/#reinstall-ssd","text":"Remove M.2 SSD from enclosure case and install it into AVA platform, then turn it on. The following screen comes up, then login as root without password. EWAOL (Edge Workload Abstraction and Orchestration Layer) 0.1 comhpc tty1 comhpc login: You are able to access via SSH.","title":"Reinstall SSD"},{"location":"version-1.0/start-guide/installation/extend-rootfs/","text":"Extend rootfs partition # Overview # The rootfs partition is created with 5.2GB, but the size is too short to run docker container. So we have to extend rootfs partition, or create new partition and assign the whole docker folder to the new partition. Here is the instruction how to extend rootfs partition Extend rootfs # Run gparted . You may get the following warning when you run gparted . Press Fix . Contents of storage after we flashed yocto image to M.2 SSD. Unmount partitions. To manipulate partitions, you need to unmount root and data partition. Right click root partition, then click Unmount . Unmount data partition as well. Move data partition to the end of storage. Right click data partition, then click Resize/Move . Drag the square to the right end. Then, click Resize/Move . Click OK . Extend rootfs partition to the end of disk. Right click root partition, then click Resize/Move . Extend the square to the right end. Then, click Resize/Move . Apply changes. Click check mark icon. Click Apply . You can get rootfs as follows.","title":"Extend rootfs partition"},{"location":"version-1.0/start-guide/installation/extend-rootfs/#extend-rootfs-partition","text":"","title":"Extend rootfs partition"},{"location":"version-1.0/start-guide/installation/extend-rootfs/#overview","text":"The rootfs partition is created with 5.2GB, but the size is too short to run docker container. So we have to extend rootfs partition, or create new partition and assign the whole docker folder to the new partition. Here is the instruction how to extend rootfs partition","title":"Overview"},{"location":"version-1.0/start-guide/installation/extend-rootfs/#extend-rootfs","text":"Run gparted . You may get the following warning when you run gparted . Press Fix . Contents of storage after we flashed yocto image to M.2 SSD. Unmount partitions. To manipulate partitions, you need to unmount root and data partition. Right click root partition, then click Unmount . Unmount data partition as well. Move data partition to the end of storage. Right click data partition, then click Resize/Move . Drag the square to the right end. Then, click Resize/Move . Click OK . Extend rootfs partition to the end of disk. Right click root partition, then click Resize/Move . Extend the square to the right end. Then, click Resize/Move . Apply changes. Click check mark icon. Click Apply . You can get rootfs as follows.","title":"Extend rootfs"},{"location":"version-1.0/start-guide/installation/getting-started-pcu/","text":"Getting started with PCU # Overview # Reference: PCU Setup Guide This instruction explains how to boot up Ubuntu on PCU and access it from host PC. If you are using onboard 64G EMMC as boot device, it's already been pre-installed with Ubuntu 20.04, and you can skip this step; If you would like to boot from SD card, you could either request a Micro SD card with pre-installed system or flash by yourself under instructions in below section. Ubuntu 20.04 is preferred. Hardware Setup # The minimum recommended External Micro SD card size is 64GB, and the speed should be at least class 10 A1, it is strongly recommended to use high speed SD card, e.g. class U3, A2. To boot from SD card, \"SW1\" should be set as: ON , and SD card should be plugged in. For blank SD card, the system image need to be flashed first using another PC. Get MPU image # Official images with recommended OS are available on PCU Resource Download page. Resource Download Page For PCU 2.0 hardware, please download the MPU image file for SD card as marked red to your local storage. Flash MPU image # To flash MPU image on SD card, you will need a PC with a micro SD card reader. This step could be done on either Windows or Linux PC with different flash tools. Linux will be used in this instruction as example: Insert card reader with target micro SD card to host PC. Find out device name for the SD card. sudo lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT ... sda 8:0 0 238.5G 0 disk \u251c\u2500sda1 8:1 0 512M 0 part /boot/efi \u2514\u2500sda2 8:2 0 238G 0 part / sdb 8:16 0 447.1G 0 disk \u251c\u2500sdb1 8:17 0 428.4G 0 part \u251c\u2500sdb2 8:18 0 513M 0 part \u2514\u2500sdb3 8:19 0 18.2G 0 part sdc 8:32 1 14.9G 0 disk \u2514\u2500sdc1 8:33 1 14.9G 0 part /media/adlink/B4A1-62CD In this case, sdc is the device name Flash image to SD card. sudo gzip -dc YOUR-DOWNLOAD-PATH/xxx.gz |sudo dd of=/dev/YOUR-DEVICE For example; sudo gzip -dc ~/Downloads/autocore-1046-ubuntu20.04-sd-pcu2.0-sw0.5.0-20201210.gz |sudo dd of=/dev/sdc Wait patiently until the flash process finishes, this may take up to half hour. Boot up. Now you can plug in the SD card to PCU and power up. The system should be ready to work. Connect To PCU via SSH # You could connect to PCU via SSh either by ethernet or serial port. The default username, password and IP address of PCU is as below: SSH through ethernet # Cable connection Connect host PC to RJ45 2 / RJ45 3 / RJ45 4 Eth port (Blue) on PCU board with Ethernet cable (GbE, need Cat.5e or above). Configure static IP for host PC You need to manually configure static IP for PC in order to connect with PCU, as there is no DHCP server running on PCU. The static IP should be different with PCU and within the same network segment. (e.g. 192.168.1.200) SSH login ssh user@192.168.1.239 SSH through Serial Port # Cable connection As an alternative, you could also choose to connect to PCU by micro USB (ttyUSB port in figure blow). ttyUSB Settings For Linux users, you could use \"cutecom\" to connect to PCU. sudo apt install cutecom cutecom Please set parameters as follows, Device shall be chosen based on your host PC. For other system users, the parameters are: Parameter Value Baudrate 115200 Data 8 Stop bit 1 Parity None Hardware flow control no Software flow control no Reset PCU and Login Press reset button and wait until login. ssh user@192.168.1.239 Check PCU public IP Address # Connect PCU to internet via RJ45 1 Eth port (Red), this Eth port is configured to obtain IP address automatically from DHCP by default. From section above, you can SSH connect to PCU, and you can look for IP address of the public ethernet port(fm1-mac5). ifconfig fm1-mac5 fm1-mac5: flags=4163 mtu 1500 inet 192.168.10.221 netmask 255.255.255.0 broadcast 192.168.10.255 inet6 fe80::204:7cff:fe2e:191 prefixlen 64 scopeid 0x20 ether 00:04:7c:2e:01:91 txqueuelen 1000 (Ethernet) RX packets 2806 bytes 3665212 (3.6 MB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 2238 bytes 175964 (175.9 KB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 device memory 0x1ae8000-1ae8fff You can find IP address of PCU such as 192.168.10.221 .","title":"Getting started with PCU"},{"location":"version-1.0/start-guide/installation/getting-started-pcu/#getting-started-with-pcu","text":"","title":"Getting started with PCU"},{"location":"version-1.0/start-guide/installation/getting-started-pcu/#overview","text":"Reference: PCU Setup Guide This instruction explains how to boot up Ubuntu on PCU and access it from host PC. If you are using onboard 64G EMMC as boot device, it's already been pre-installed with Ubuntu 20.04, and you can skip this step; If you would like to boot from SD card, you could either request a Micro SD card with pre-installed system or flash by yourself under instructions in below section. Ubuntu 20.04 is preferred.","title":"Overview"},{"location":"version-1.0/start-guide/installation/getting-started-pcu/#hardware-setup","text":"The minimum recommended External Micro SD card size is 64GB, and the speed should be at least class 10 A1, it is strongly recommended to use high speed SD card, e.g. class U3, A2. To boot from SD card, \"SW1\" should be set as: ON , and SD card should be plugged in. For blank SD card, the system image need to be flashed first using another PC.","title":"Hardware Setup"},{"location":"version-1.0/start-guide/installation/getting-started-pcu/#get-mpu-image","text":"Official images with recommended OS are available on PCU Resource Download page. Resource Download Page For PCU 2.0 hardware, please download the MPU image file for SD card as marked red to your local storage.","title":"Get MPU image"},{"location":"version-1.0/start-guide/installation/getting-started-pcu/#flash-mpu-image","text":"To flash MPU image on SD card, you will need a PC with a micro SD card reader. This step could be done on either Windows or Linux PC with different flash tools. Linux will be used in this instruction as example: Insert card reader with target micro SD card to host PC. Find out device name for the SD card. sudo lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT ... sda 8:0 0 238.5G 0 disk \u251c\u2500sda1 8:1 0 512M 0 part /boot/efi \u2514\u2500sda2 8:2 0 238G 0 part / sdb 8:16 0 447.1G 0 disk \u251c\u2500sdb1 8:17 0 428.4G 0 part \u251c\u2500sdb2 8:18 0 513M 0 part \u2514\u2500sdb3 8:19 0 18.2G 0 part sdc 8:32 1 14.9G 0 disk \u2514\u2500sdc1 8:33 1 14.9G 0 part /media/adlink/B4A1-62CD In this case, sdc is the device name Flash image to SD card. sudo gzip -dc YOUR-DOWNLOAD-PATH/xxx.gz |sudo dd of=/dev/YOUR-DEVICE For example; sudo gzip -dc ~/Downloads/autocore-1046-ubuntu20.04-sd-pcu2.0-sw0.5.0-20201210.gz |sudo dd of=/dev/sdc Wait patiently until the flash process finishes, this may take up to half hour. Boot up. Now you can plug in the SD card to PCU and power up. The system should be ready to work.","title":"Flash MPU image"},{"location":"version-1.0/start-guide/installation/getting-started-pcu/#connect-to-pcu-via-ssh","text":"You could connect to PCU via SSh either by ethernet or serial port. The default username, password and IP address of PCU is as below:","title":"Connect To PCU via SSH"},{"location":"version-1.0/start-guide/installation/getting-started-pcu/#ssh-through-ethernet","text":"Cable connection Connect host PC to RJ45 2 / RJ45 3 / RJ45 4 Eth port (Blue) on PCU board with Ethernet cable (GbE, need Cat.5e or above). Configure static IP for host PC You need to manually configure static IP for PC in order to connect with PCU, as there is no DHCP server running on PCU. The static IP should be different with PCU and within the same network segment. (e.g. 192.168.1.200) SSH login ssh user@192.168.1.239","title":"SSH through ethernet"},{"location":"version-1.0/start-guide/installation/getting-started-pcu/#ssh-through-serial-port","text":"Cable connection As an alternative, you could also choose to connect to PCU by micro USB (ttyUSB port in figure blow). ttyUSB Settings For Linux users, you could use \"cutecom\" to connect to PCU. sudo apt install cutecom cutecom Please set parameters as follows, Device shall be chosen based on your host PC. For other system users, the parameters are: Parameter Value Baudrate 115200 Data 8 Stop bit 1 Parity None Hardware flow control no Software flow control no Reset PCU and Login Press reset button and wait until login. ssh user@192.168.1.239","title":"SSH through Serial Port"},{"location":"version-1.0/start-guide/installation/getting-started-pcu/#check-pcu-public-ip-address","text":"Connect PCU to internet via RJ45 1 Eth port (Red), this Eth port is configured to obtain IP address automatically from DHCP by default. From section above, you can SSH connect to PCU, and you can look for IP address of the public ethernet port(fm1-mac5). ifconfig fm1-mac5 fm1-mac5: flags=4163 mtu 1500 inet 192.168.10.221 netmask 255.255.255.0 broadcast 192.168.10.255 inet6 fe80::204:7cff:fe2e:191 prefixlen 64 scopeid 0x20 ether 00:04:7c:2e:01:91 txqueuelen 1000 (Ethernet) RX packets 2806 bytes 3665212 (3.6 MB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 2238 bytes 175964 (175.9 KB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 device memory 0x1ae8000-1ae8fff You can find IP address of PCU such as 192.168.10.221 .","title":"Check PCU public IP Address"},{"location":"version-1.0/start-guide/installation/getting-started/","text":"Getting started with EWAOL # Overview # Reference: Project Quickstart \u2014 EWAOL documentation This instruction explain how to build yocto image with EWAOL on your host machine. If you are using AVA Developer Platform , you can also download built image from ADLINK's website, and you can skip this steps; AVA Developer Platform Downloads \u2013 I-Pi SMARC Yocto with SOAFEE is preferred. Build Host Setup # Install required packages for the build host by following The Yocto Project \u00ae 3.3.1 documentation . sudo apt-get install gawk wget git diffstat unzip texinfo gcc build-essential chrpath socat cpio python3 python3-pip python3-pexpect xz-utils debianutils iputils-ping python3-git python3-jinja2 libegl1-mesa libsdl1.2-dev pylint3 xterm python3-subunit mesa-common-dev Install the kas setup tool. sudo -H pip3 install kas Checkout the repository for AVA platform # ADLINK / meta-adlink-ampere git clone https://github.com/ADLINK/meta-adlink-ampere.git EWAOL / meta-ewaol cd meta-adlink-ampere git clone https://git.gitlab.arm.com/ewaol/meta-ewaol.git Build via kas kas build ComHpc.yml You should be careful of utilizing full CPU power during build. You can choose the way to boot EWAOL, SSD Boot(highly recommended) or USB Boot. SSD Boot (highly recommended) You need to use SSD enclosure case to flash yocto image to M.2 SSD directly. USB Boot You need to use 32GB USB, not 64GB USB to flash yocto image. Do not use 64GB USB because bios gets stuck due to EDK II bug.","title":"Getting started with EWAOL"},{"location":"version-1.0/start-guide/installation/getting-started/#getting-started-with-ewaol","text":"","title":"Getting started with EWAOL"},{"location":"version-1.0/start-guide/installation/getting-started/#overview","text":"Reference: Project Quickstart \u2014 EWAOL documentation This instruction explain how to build yocto image with EWAOL on your host machine. If you are using AVA Developer Platform , you can also download built image from ADLINK's website, and you can skip this steps; AVA Developer Platform Downloads \u2013 I-Pi SMARC Yocto with SOAFEE is preferred.","title":"Overview"},{"location":"version-1.0/start-guide/installation/getting-started/#build-host-setup","text":"Install required packages for the build host by following The Yocto Project \u00ae 3.3.1 documentation . sudo apt-get install gawk wget git diffstat unzip texinfo gcc build-essential chrpath socat cpio python3 python3-pip python3-pexpect xz-utils debianutils iputils-ping python3-git python3-jinja2 libegl1-mesa libsdl1.2-dev pylint3 xterm python3-subunit mesa-common-dev Install the kas setup tool. sudo -H pip3 install kas","title":"Build Host Setup"},{"location":"version-1.0/start-guide/installation/getting-started/#checkout-the-repository-for-ava-platform","text":"ADLINK / meta-adlink-ampere git clone https://github.com/ADLINK/meta-adlink-ampere.git EWAOL / meta-ewaol cd meta-adlink-ampere git clone https://git.gitlab.arm.com/ewaol/meta-ewaol.git Build via kas kas build ComHpc.yml You should be careful of utilizing full CPU power during build. You can choose the way to boot EWAOL, SSD Boot(highly recommended) or USB Boot. SSD Boot (highly recommended) You need to use SSD enclosure case to flash yocto image to M.2 SSD directly. USB Boot You need to use 32GB USB, not 64GB USB to flash yocto image. Do not use 64GB USB because bios gets stuck due to EDK II bug.","title":"Checkout the repository for AVA platform"},{"location":"version-1.0/start-guide/installation/system-setup-ava/","text":"System Setup on AVA platform # Overview # This instruction explains how to perform system setup for test execution on AVA platform. You need to copy docker images and necessary files. Access to AVA platform via SSH # ssh root@IP-ADDRESS For example; ssh root@192.168.10.27 Copy Autoware.Auto image to AVA platform # The docker image of Autoware.Auto is registered in GitLab Container Registry . Copy docker image to AVA platform. docker pull registry.gitlab.com/autowarefoundation/autoware.auto/autowareauto/arm64/openadkit-foxy:latest Copy necessary files to USB drive # Copy files related to map contents . Files are placed in the directory docs/Appendix/Open-AD-Kit-Start-Guide/map lanelet2_map.osm pointcloud_map.pcd global_map_center.pcd.yaml lanelet2_map_provider.osm.yaml map_publisher.param.yaml Copy files to your USB drive as the following directory structure. Copy configuration file of Cyclone DDS . In this test, we are using Cyclone DDS, so you also need to copy configuration file of Cyclone DDS. File is placed in the directory docs/Appendix/Open-AD-Kit-Start-Guide/cyclonedds cyclonedds.xml Copy the file to your USB drive as the following directory structure. Copy kernel configuration file for tuning kernel parameters. We have to reconfigure kernel parameters by using sysctl for system stability. File is placed in the directory docs/Appendix/Open-AD-Kit-Start-Guide/sysctl.d 60_cyclonedds.conf Copy the file to your USB root. Copy files from USB drive to AVA platform # Plug your USB drive into AVA platform and copy files Find USB device name. lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:16 1 28.9G 0 disk `-sda1 8:17 1 28.9G 0 part nvme0n1 259:0 0 119.2G 0 disk |-nvme0n1p1 259:1 0 256M 0 part |-nvme0n1p2 259:2 0 118G 0 part / `-nvme0n1p3 259:3 0 1G 0 part Mount USB driver and copy directory. mkdir -p /mnt/usb mount /dev/sda1 /mnt/usb cp -r /mnt/usb/* ~/ Move kernel configuration file to /etc/sysctl.d . mv ~/60_cyclonedds.conf /etc/sysctl.d Update kernel parameters. sysctl -p /etc/sysctl.d/60_cyclonedds.conf Modify cyclonedds.xml # You need to change the element NetworkInterfaceAddress to the network interface currently in use. Find network interface. ip addr 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: enP4p4s0: mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 00:11:22:33:44:55 brd ff:ff:ff:ff:ff:ff inet 192.168.10.27/24 brd 192.168.10.255 scope global dynamic enP4p4s0 valid_lft 332sec preferred_lft 332sec inet 192.168.10.13/24 brd 192.168.10.255 scope global secondary dynamic noprefixroute enP4p4s0 valid_lft 337sec preferred_lft 262sec inet6 fe80::34c:b6f7:b356:b7/64 scope link valid_lft forever preferred_lft forever inet6 fe80::230:64ff:fe1a:a65/64 scope link valid_lft forever preferred_lft forever 3: docker0: mtu 1500 qdisc noqueue state DOWN group default link/ether aa:bb:cc:dd:ee:ff brd ff:ff:ff:ff:ff:ff inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0 valid_lft forever preferred_lft forever You can find a network interface such as enP4p4s0 . Change the NetworkInterfaceAddress . vi ~/cyclonedds/cyclonedds.xml For example; cyclonedds.xml - lo + enP4p4s0 ","title":"System Setup on AVA platform"},{"location":"version-1.0/start-guide/installation/system-setup-ava/#system-setup-on-ava-platform","text":"","title":"System Setup on AVA platform"},{"location":"version-1.0/start-guide/installation/system-setup-ava/#overview","text":"This instruction explains how to perform system setup for test execution on AVA platform. You need to copy docker images and necessary files.","title":"Overview"},{"location":"version-1.0/start-guide/installation/system-setup-ava/#access-to-ava-platform-via-ssh","text":"ssh root@IP-ADDRESS For example; ssh root@192.168.10.27","title":"Access to AVA platform via SSH"},{"location":"version-1.0/start-guide/installation/system-setup-ava/#copy-autowareauto-image-to-ava-platform","text":"The docker image of Autoware.Auto is registered in GitLab Container Registry . Copy docker image to AVA platform. docker pull registry.gitlab.com/autowarefoundation/autoware.auto/autowareauto/arm64/openadkit-foxy:latest","title":"Copy Autoware.Auto image to AVA platform"},{"location":"version-1.0/start-guide/installation/system-setup-ava/#copy-necessary-files-to-usb-drive","text":"Copy files related to map contents . Files are placed in the directory docs/Appendix/Open-AD-Kit-Start-Guide/map lanelet2_map.osm pointcloud_map.pcd global_map_center.pcd.yaml lanelet2_map_provider.osm.yaml map_publisher.param.yaml Copy files to your USB drive as the following directory structure. Copy configuration file of Cyclone DDS . In this test, we are using Cyclone DDS, so you also need to copy configuration file of Cyclone DDS. File is placed in the directory docs/Appendix/Open-AD-Kit-Start-Guide/cyclonedds cyclonedds.xml Copy the file to your USB drive as the following directory structure. Copy kernel configuration file for tuning kernel parameters. We have to reconfigure kernel parameters by using sysctl for system stability. File is placed in the directory docs/Appendix/Open-AD-Kit-Start-Guide/sysctl.d 60_cyclonedds.conf Copy the file to your USB root.","title":"Copy necessary files to USB drive"},{"location":"version-1.0/start-guide/installation/system-setup-ava/#copy-files-from-usb-drive-to-ava-platform","text":"Plug your USB drive into AVA platform and copy files Find USB device name. lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:16 1 28.9G 0 disk `-sda1 8:17 1 28.9G 0 part nvme0n1 259:0 0 119.2G 0 disk |-nvme0n1p1 259:1 0 256M 0 part |-nvme0n1p2 259:2 0 118G 0 part / `-nvme0n1p3 259:3 0 1G 0 part Mount USB driver and copy directory. mkdir -p /mnt/usb mount /dev/sda1 /mnt/usb cp -r /mnt/usb/* ~/ Move kernel configuration file to /etc/sysctl.d . mv ~/60_cyclonedds.conf /etc/sysctl.d Update kernel parameters. sysctl -p /etc/sysctl.d/60_cyclonedds.conf","title":"Copy files from USB drive to AVA platform"},{"location":"version-1.0/start-guide/installation/system-setup-ava/#modify-cycloneddsxml","text":"You need to change the element NetworkInterfaceAddress to the network interface currently in use. Find network interface. ip addr 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: enP4p4s0: mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 00:11:22:33:44:55 brd ff:ff:ff:ff:ff:ff inet 192.168.10.27/24 brd 192.168.10.255 scope global dynamic enP4p4s0 valid_lft 332sec preferred_lft 332sec inet 192.168.10.13/24 brd 192.168.10.255 scope global secondary dynamic noprefixroute enP4p4s0 valid_lft 337sec preferred_lft 262sec inet6 fe80::34c:b6f7:b356:b7/64 scope link valid_lft forever preferred_lft forever inet6 fe80::230:64ff:fe1a:a65/64 scope link valid_lft forever preferred_lft forever 3: docker0: mtu 1500 qdisc noqueue state DOWN group default link/ether aa:bb:cc:dd:ee:ff brd ff:ff:ff:ff:ff:ff inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0 valid_lft forever preferred_lft forever You can find a network interface such as enP4p4s0 . Change the NetworkInterfaceAddress . vi ~/cyclonedds/cyclonedds.xml For example; cyclonedds.xml - lo + enP4p4s0 ","title":"Modify cyclonedds.xml"},{"location":"version-1.0/start-guide/installation/system-setup-host/","text":"System Setup on your host # Overview # This instruction explains how to perform system setup for test execution on your host. You need to copy docker images and necessary files, and checkout Autoware.Auto. Copy scenario simulator image to your host machine # The docker image of scenario simulator is registered in docker hub . Copy docker image to your host machine. docker pull tier4/scenario_simulator_v2:open_ad_kit-amd64-foxy Copy necessary files to your host machine # Copy scenario files for scenario simulator. Files are placed in the directory docs/Appendix/Open-AD-Kit-Start-Guide/scenario [Currently placed] UC-001-0001-Kashiwa:2 UC-001-0018-Kashiwa:1 Copy the scenario files to your home directory as the following directory structure. Copy configuration file of Cyclone DDS . You also need to copy cyclonedds.xml to your home directory. Copy kernel configuration file to /etc/sysctl.d . You also need to copy 60_cyclonedds.conf to /etc/sysctl.d directory in your host as well. cp 60_cyclonedds.conf /etc/sysctl.d Update kernel parameters. sysctl -p /etc/sysctl.d/60_cyclonedds.conf Modify cyclonedds.xml # You need to change the element NetworkInterfaceAddress to the network interface currently in use. Find network interface. ip addr 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: enp0s31f6: mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 66:77:88:99:aa:bb brd ff:ff:ff:ff:ff:ff inet 192.168.10.1/24 brd 192.168.10.255 scope global noprefixroute enp0s31f6 valid_lft forever preferred_lft forever inet6 fe80::f15d:4196:b777:6875/64 scope link noprefixroute valid_lft forever preferred_lft forever 3: wlp82s0: mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether cc:dd:ee:ff:00:01 brd ff:ff:ff:ff:ff:ff inet 192.168.0.28/24 brd 192.168.0.255 scope global dynamic noprefixroute wlp82s0 valid_lft 3137sec preferred_lft 3137sec inet6 fe80::f493:f223:dfcc:bd1b/64 scope link noprefixroute valid_lft forever preferred_lft forever 4: docker0: mtu 1500 qdisc noqueue state DOWN group default link/ether 23:45:67:89:ab:cd brd ff:ff:ff:ff:ff:ff inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0 valid_lft forever preferred_lft forever You can find a network interface such as enp0s31f6 . Change the NetworkInterfaceAddress . vi ~/cyclonedds/cyclonedds.xml For example; cyclonedds.xml - lo + enp0s31f6 Setup ADE # In general, Autoware.Auto runs by using the Agile Development Environment (ADE), so we need to install ADE. In this test, we use launch file placed in Autoware.Auto to run visualization quickly and easily. Install ADE on AVA platform by following the instructions; Installation \u2014 ADE 4.4.0dev documentation Download and setup ADE. wget https://gitlab.com/ApexAI/ade-cli/-/jobs/1341322852/artifacts/raw/dist/ade+aarch64 -O ade chmod +x ade mv ade /usr/bin/ Setup ADE home directory by following the instructions; Installation with ADE mkdir -p ~/adehome cd ~/adehome touch .adehome Checkout Autoware.Auto # Get Autoware.Auto on your host. cd ~/adehome git clone https://gitlab.com/autowarefoundation/autoware.auto/AutowareAuto.git","title":"System Setup on your host"},{"location":"version-1.0/start-guide/installation/system-setup-host/#system-setup-on-your-host","text":"","title":"System Setup on your host"},{"location":"version-1.0/start-guide/installation/system-setup-host/#overview","text":"This instruction explains how to perform system setup for test execution on your host. You need to copy docker images and necessary files, and checkout Autoware.Auto.","title":"Overview"},{"location":"version-1.0/start-guide/installation/system-setup-host/#copy-scenario-simulator-image-to-your-host-machine","text":"The docker image of scenario simulator is registered in docker hub . Copy docker image to your host machine. docker pull tier4/scenario_simulator_v2:open_ad_kit-amd64-foxy","title":"Copy scenario simulator image to your host machine"},{"location":"version-1.0/start-guide/installation/system-setup-host/#copy-necessary-files-to-your-host-machine","text":"Copy scenario files for scenario simulator. Files are placed in the directory docs/Appendix/Open-AD-Kit-Start-Guide/scenario [Currently placed] UC-001-0001-Kashiwa:2 UC-001-0018-Kashiwa:1 Copy the scenario files to your home directory as the following directory structure. Copy configuration file of Cyclone DDS . You also need to copy cyclonedds.xml to your home directory. Copy kernel configuration file to /etc/sysctl.d . You also need to copy 60_cyclonedds.conf to /etc/sysctl.d directory in your host as well. cp 60_cyclonedds.conf /etc/sysctl.d Update kernel parameters. sysctl -p /etc/sysctl.d/60_cyclonedds.conf","title":"Copy necessary files to your host machine"},{"location":"version-1.0/start-guide/installation/system-setup-host/#modify-cycloneddsxml","text":"You need to change the element NetworkInterfaceAddress to the network interface currently in use. Find network interface. ip addr 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: enp0s31f6: mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 66:77:88:99:aa:bb brd ff:ff:ff:ff:ff:ff inet 192.168.10.1/24 brd 192.168.10.255 scope global noprefixroute enp0s31f6 valid_lft forever preferred_lft forever inet6 fe80::f15d:4196:b777:6875/64 scope link noprefixroute valid_lft forever preferred_lft forever 3: wlp82s0: mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether cc:dd:ee:ff:00:01 brd ff:ff:ff:ff:ff:ff inet 192.168.0.28/24 brd 192.168.0.255 scope global dynamic noprefixroute wlp82s0 valid_lft 3137sec preferred_lft 3137sec inet6 fe80::f493:f223:dfcc:bd1b/64 scope link noprefixroute valid_lft forever preferred_lft forever 4: docker0: mtu 1500 qdisc noqueue state DOWN group default link/ether 23:45:67:89:ab:cd brd ff:ff:ff:ff:ff:ff inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0 valid_lft forever preferred_lft forever You can find a network interface such as enp0s31f6 . Change the NetworkInterfaceAddress . vi ~/cyclonedds/cyclonedds.xml For example; cyclonedds.xml - lo + enp0s31f6 ","title":"Modify cyclonedds.xml"},{"location":"version-1.0/start-guide/installation/system-setup-host/#setup-ade","text":"In general, Autoware.Auto runs by using the Agile Development Environment (ADE), so we need to install ADE. In this test, we use launch file placed in Autoware.Auto to run visualization quickly and easily. Install ADE on AVA platform by following the instructions; Installation \u2014 ADE 4.4.0dev documentation Download and setup ADE. wget https://gitlab.com/ApexAI/ade-cli/-/jobs/1341322852/artifacts/raw/dist/ade+aarch64 -O ade chmod +x ade mv ade /usr/bin/ Setup ADE home directory by following the instructions; Installation with ADE mkdir -p ~/adehome cd ~/adehome touch .adehome","title":"Setup ADE"},{"location":"version-1.0/start-guide/installation/system-setup-host/#checkout-autowareauto","text":"Get Autoware.Auto on your host. cd ~/adehome git clone https://gitlab.com/autowarefoundation/autoware.auto/AutowareAuto.git","title":"Checkout Autoware.Auto"},{"location":"version-1.0/start-guide/installation/system-setup-pcu/","text":"System Setup on PCU # Overview # This instruction explains how to perform system setup for test execution on PCU. You need to install Docker Engine, copy docker images and necessary files. Access to PCU via SSH # ssh user@IP-ADDRESS For example; ssh user@192.168.10.221 Copy Autoware.Auto image to PCU # NOTE : docker should be installed with post-installation steps. For instructions please refer to: Install Docker Engine on Ubuntu . Post-installation steps for Linux . The docker image of Autoware.Auto is registered in GitLab Container Registry . Copy docker image to PCU. docker pull registry.gitlab.com/autowarefoundation/autoware.auto/autowareauto/arm64/openadkit-foxy:latest Copy necessary files to local Downloads folder # Copy files related to map contents . Files are placed in the directory docs/Appendix/Open-AD-Kit-Start-Guide/map lanelet2_map.osm pointcloud_map.pcd global_map_center.pcd.yaml lanelet2_map_provider.osm.yaml map_publisher.param.yaml Copy files to your local folder (Downloads folder as example) as the following directory structure. Copy configuration file of Cyclone DDS . In this test, we are using Cyclone DDS, so you also need to copy configuration file of Cyclone DDS. File is placed in the directory docs/Appendix/Open-AD-Kit-Start-Guide/cyclonedds cyclonedds.xml Copy the file to your local folder as the following directory structure. Copy kernel configuration file for tuning kernel parameters. We have to reconfigure kernel parameters by using sysctl for system stability. File is placed in the directory docs/Appendix/Open-AD-Kit-Start-Guide/sysctl.d 60_cyclonedds.conf Copy the file to your local folder. Copy files from local folder to PCU # Connect your host PC with PCU through internet and copy files with SCP. Access to PCU via SSH For example; ssh user@192.168.10.221 Copy kernel configuration file to /etc/sysctl.d/ sudo scp USER-NAME@IP-ADDRESS:/home/USER-NAME/Downloads/60_cyclonedds.conf /etc/sysctl.d/ For example; sudo scp adlink@192.168.10.237:/home/adlink/Downloads/60_cyclonedds.conf /etc/sysctl.d/ Then type in the password of PCU (default password: user) and host PC as request. Update kernel parameters. sudo sysctl -p /etc/sysctl.d/60_cyclonedds.conf Copy map contents files and Cyclone DDS configuration file. sudo scp -r USER-NAME@IP-ADDRESS:/home/adlink/Downloads/map ~/ sudo scp -r USER-NAME@IP-ADDRESS:/home/adlink/Downloads/cyclonedds ~/ Modify cyclonedds.xml # You need to change the element NetworkInterfaceAddress to the network interface currently in use. Find network interface. ip addr 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: fm1-mac1: mtu 1500 qdisc mq master br0 state DOWN group default qlen 1000 link/ether 00:04:7c:2e:01:90 brd ff:ff:ff:ff:ff:ff inet6 fe80::204:7cff:fe2e:190/64 scope link valid_lft forever preferred_lft forever 3: fm1-mac5: mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 00:04:7c:2e:01:91 brd ff:ff:ff:ff:ff:ff inet 192.168.10.221/24 brd 192.168.10.255 scope global dynamic fm1-mac5 valid_lft 254392sec preferred_lft 254392sec inet6 fe80::204:7cff:fe2e:191/64 scope link valid_lft forever preferred_lft forever 4: fm1-mac6: mtu 1500 qdisc mq master br0 state DOWN group default qlen 1000 link/ether 00:04:7c:2e:01:90 brd ff:ff:ff:ff:ff:ff 5: fm1-sw: mtu 1500 qdisc mq master br0 state UP group default qlen 1000 link/ether 00:04:7c:2e:01:90 brd ff:ff:ff:ff:ff:ff inet6 fe80::204:7cff:fe2e:190/64 scope link valid_lft forever preferred_lft forever 6: fm1-mac10: mtu 1500 qdisc mq master br0 state DOWN group default qlen 1000 link/ether 00:04:7c:2e:01:90 brd ff:ff:ff:ff:ff:ff 7: sit0@NONE: mtu 1480 qdisc noop state DOWN group default qlen 1000 link/sit 0.0.0.0 brd 0.0.0.0 8: br0: mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether 00:04:7c:2e:01:90 brd ff:ff:ff:ff:ff:ff inet 192.168.1.239/24 brd 192.168.1.255 scope global br0 valid_lft forever preferred_lft forever inet6 fe80::204:7cff:fe2e:190/64 scope link valid_lft forever preferred_lft forever 9: docker0: mtu 1500 qdisc noqueue state DOWN group default link/ether 02:42:cb:aa:a6:9d brd ff:ff:ff:ff:ff:ff inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0 valid_lft forever preferred_lft forever You can find a network interface such as fm1-mac5 . Change the NetworkInterfaceAddress . sudo vi ~/cyclonedds/cyclonedds.xml For example; cyclonedds.xml - lo + fm1-mac5 ","title":"System Setup on PCU"},{"location":"version-1.0/start-guide/installation/system-setup-pcu/#system-setup-on-pcu","text":"","title":"System Setup on PCU"},{"location":"version-1.0/start-guide/installation/system-setup-pcu/#overview","text":"This instruction explains how to perform system setup for test execution on PCU. You need to install Docker Engine, copy docker images and necessary files.","title":"Overview"},{"location":"version-1.0/start-guide/installation/system-setup-pcu/#access-to-pcu-via-ssh","text":"ssh user@IP-ADDRESS For example; ssh user@192.168.10.221","title":"Access to PCU via SSH"},{"location":"version-1.0/start-guide/installation/system-setup-pcu/#copy-autowareauto-image-to-pcu","text":"NOTE : docker should be installed with post-installation steps. For instructions please refer to: Install Docker Engine on Ubuntu . Post-installation steps for Linux . The docker image of Autoware.Auto is registered in GitLab Container Registry . Copy docker image to PCU. docker pull registry.gitlab.com/autowarefoundation/autoware.auto/autowareauto/arm64/openadkit-foxy:latest","title":"Copy Autoware.Auto image to PCU"},{"location":"version-1.0/start-guide/installation/system-setup-pcu/#copy-necessary-files-to-local-downloads-folder","text":"Copy files related to map contents . Files are placed in the directory docs/Appendix/Open-AD-Kit-Start-Guide/map lanelet2_map.osm pointcloud_map.pcd global_map_center.pcd.yaml lanelet2_map_provider.osm.yaml map_publisher.param.yaml Copy files to your local folder (Downloads folder as example) as the following directory structure. Copy configuration file of Cyclone DDS . In this test, we are using Cyclone DDS, so you also need to copy configuration file of Cyclone DDS. File is placed in the directory docs/Appendix/Open-AD-Kit-Start-Guide/cyclonedds cyclonedds.xml Copy the file to your local folder as the following directory structure. Copy kernel configuration file for tuning kernel parameters. We have to reconfigure kernel parameters by using sysctl for system stability. File is placed in the directory docs/Appendix/Open-AD-Kit-Start-Guide/sysctl.d 60_cyclonedds.conf Copy the file to your local folder.","title":"Copy necessary files to local Downloads folder"},{"location":"version-1.0/start-guide/installation/system-setup-pcu/#copy-files-from-local-folder-to-pcu","text":"Connect your host PC with PCU through internet and copy files with SCP. Access to PCU via SSH For example; ssh user@192.168.10.221 Copy kernel configuration file to /etc/sysctl.d/ sudo scp USER-NAME@IP-ADDRESS:/home/USER-NAME/Downloads/60_cyclonedds.conf /etc/sysctl.d/ For example; sudo scp adlink@192.168.10.237:/home/adlink/Downloads/60_cyclonedds.conf /etc/sysctl.d/ Then type in the password of PCU (default password: user) and host PC as request. Update kernel parameters. sudo sysctl -p /etc/sysctl.d/60_cyclonedds.conf Copy map contents files and Cyclone DDS configuration file. sudo scp -r USER-NAME@IP-ADDRESS:/home/adlink/Downloads/map ~/ sudo scp -r USER-NAME@IP-ADDRESS:/home/adlink/Downloads/cyclonedds ~/","title":"Copy files from local folder to PCU"},{"location":"version-1.0/start-guide/installation/system-setup-pcu/#modify-cycloneddsxml","text":"You need to change the element NetworkInterfaceAddress to the network interface currently in use. Find network interface. ip addr 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: fm1-mac1: mtu 1500 qdisc mq master br0 state DOWN group default qlen 1000 link/ether 00:04:7c:2e:01:90 brd ff:ff:ff:ff:ff:ff inet6 fe80::204:7cff:fe2e:190/64 scope link valid_lft forever preferred_lft forever 3: fm1-mac5: mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 00:04:7c:2e:01:91 brd ff:ff:ff:ff:ff:ff inet 192.168.10.221/24 brd 192.168.10.255 scope global dynamic fm1-mac5 valid_lft 254392sec preferred_lft 254392sec inet6 fe80::204:7cff:fe2e:191/64 scope link valid_lft forever preferred_lft forever 4: fm1-mac6: mtu 1500 qdisc mq master br0 state DOWN group default qlen 1000 link/ether 00:04:7c:2e:01:90 brd ff:ff:ff:ff:ff:ff 5: fm1-sw: mtu 1500 qdisc mq master br0 state UP group default qlen 1000 link/ether 00:04:7c:2e:01:90 brd ff:ff:ff:ff:ff:ff inet6 fe80::204:7cff:fe2e:190/64 scope link valid_lft forever preferred_lft forever 6: fm1-mac10: mtu 1500 qdisc mq master br0 state DOWN group default qlen 1000 link/ether 00:04:7c:2e:01:90 brd ff:ff:ff:ff:ff:ff 7: sit0@NONE: mtu 1480 qdisc noop state DOWN group default qlen 1000 link/sit 0.0.0.0 brd 0.0.0.0 8: br0: mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether 00:04:7c:2e:01:90 brd ff:ff:ff:ff:ff:ff inet 192.168.1.239/24 brd 192.168.1.255 scope global br0 valid_lft forever preferred_lft forever inet6 fe80::204:7cff:fe2e:190/64 scope link valid_lft forever preferred_lft forever 9: docker0: mtu 1500 qdisc noqueue state DOWN group default link/ether 02:42:cb:aa:a6:9d brd ff:ff:ff:ff:ff:ff inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0 valid_lft forever preferred_lft forever You can find a network interface such as fm1-mac5 . Change the NetworkInterfaceAddress . sudo vi ~/cyclonedds/cyclonedds.xml For example; cyclonedds.xml - lo + fm1-mac5 ","title":"Modify cyclonedds.xml"},{"location":"version-1.0/start-guide/installation/images/boot-ewaol/","text":"","title":"Index"},{"location":"version-1.0/system-configuration/","text":"System configuration # TODO","title":"System configuration"},{"location":"version-1.0/system-configuration/#system-configuration","text":"TODO","title":"System configuration"},{"location":"version-2.0/","text":"Open AD Kit Documentation # The latest version is 2.0, but it has not been officially released yet. About Open AD Kit # Open AD Kit aims to democratize autonomous drive (AD) systems by bringing the cloud and edge closer together. In doing so, Open AD Kit will lower the threshold for developing and deploying the Autoware software stack. For more details about the Open AD Kit project, its goals and details of the Autoware Foundation working group that oversees the project, refer to the Open AD Kit Working Group wiki . Open AD Kit documentation structure # Getting started # Start guide describes how to install, set up and run Autoware and its associated simulators on supported development platforms. System configuration describes the components that make up Open AD Kit in terms of the required hardware and software. Application example provides an actual application example for Open AD Kit that can be used as a reference for the development of other applications. Releases # version 2.0 Latest version 1.0","title":"Introduction"},{"location":"version-2.0/#open-ad-kit-documentation","text":"The latest version is 2.0, but it has not been officially released yet.","title":"Open AD Kit Documentation"},{"location":"version-2.0/#about-open-ad-kit","text":"Open AD Kit aims to democratize autonomous drive (AD) systems by bringing the cloud and edge closer together. In doing so, Open AD Kit will lower the threshold for developing and deploying the Autoware software stack. For more details about the Open AD Kit project, its goals and details of the Autoware Foundation working group that oversees the project, refer to the Open AD Kit Working Group wiki .","title":"About Open AD Kit"},{"location":"version-2.0/#open-ad-kit-documentation-structure","text":"","title":"Open AD Kit documentation structure"},{"location":"version-2.0/#getting-started","text":"Start guide describes how to install, set up and run Autoware and its associated simulators on supported development platforms. System configuration describes the components that make up Open AD Kit in terms of the required hardware and software. Application example provides an actual application example for Open AD Kit that can be used as a reference for the development of other applications.","title":"Getting started"},{"location":"version-2.0/#releases","text":"version 2.0 Latest version 1.0","title":"Releases"},{"location":"version-2.0/application-example/","text":"Application example # This page shows application examples of Open AD Kit version 2.0. TODO","title":"Application example"},{"location":"version-2.0/application-example/#application-example","text":"This page shows application examples of Open AD Kit version 2.0. TODO","title":"Application example"},{"location":"version-2.0/application-example/driverless-bus/","text":"Driverless bus # The content is a work in progress. This page provides a reference design for a passenger transportation system in the urban area. The reference design consists of the following structures: Introduction of Reference Design Concept of Operations Operational Concept Operational Environment Requirements System Requirements System Configuration Hardware Requirements Software Requirements Appendix","title":"Driverless bus"},{"location":"version-2.0/application-example/driverless-bus/#driverless-bus","text":"The content is a work in progress. This page provides a reference design for a passenger transportation system in the urban area. The reference design consists of the following structures: Introduction of Reference Design Concept of Operations Operational Concept Operational Environment Requirements System Requirements System Configuration Hardware Requirements Software Requirements Appendix","title":"Driverless bus"},{"location":"version-2.0/application-example/driverless-bus/appendix/","text":"Appendix # The content is a work in progress. What is ConOps and OpsCons? Hardware List","title":"Appendix"},{"location":"version-2.0/application-example/driverless-bus/appendix/#appendix","text":"The content is a work in progress. What is ConOps and OpsCons? Hardware List","title":"Appendix"},{"location":"version-2.0/application-example/driverless-bus/appendix/hardware-list/","text":"Hardware List # The content is a work in progress. This page should show applicable hardwares for the system.","title":"Hardware List"},{"location":"version-2.0/application-example/driverless-bus/appendix/hardware-list/#hardware-list","text":"The content is a work in progress. This page should show applicable hardwares for the system.","title":"Hardware List"},{"location":"version-2.0/application-example/driverless-bus/appendix/what-is-conops-and-opscon/","text":"What is ConOps and OpsCons? # Concept of Operations (ConOps) : \u201c... the ConOps describes the overall high-level concept of how the system will be used to meet stakeholder expectations, usually in a time-sequenced manner\u2026\u201d, source NASA Systems Engineering Handbook In short, it describes how the system achieves the user\u2019s mission with a picture and short sentences. Operational Concept (OpsCon) : \u201cThe operational concept is designed to give an overall picture of the operations using one or more specific systems, or set of related systems, in the organization\u2019s operational environment from the users\u2019 and operators\u2019 perspective.\u201d, source SEBoK In short, it describes: How the system achieves the mission using unique features/events/interactions Relationships between the system and other systems Benefits : Stakeholders can understand the system from the early stages of development In particular, developers who have different backgrounds or perspectives can gain the same understanding","title":"What is ConOps and OpsCons?"},{"location":"version-2.0/application-example/driverless-bus/appendix/what-is-conops-and-opscon/#what-is-conops-and-opscons","text":"Concept of Operations (ConOps) : \u201c... the ConOps describes the overall high-level concept of how the system will be used to meet stakeholder expectations, usually in a time-sequenced manner\u2026\u201d, source NASA Systems Engineering Handbook In short, it describes how the system achieves the user\u2019s mission with a picture and short sentences. Operational Concept (OpsCon) : \u201cThe operational concept is designed to give an overall picture of the operations using one or more specific systems, or set of related systems, in the organization\u2019s operational environment from the users\u2019 and operators\u2019 perspective.\u201d, source SEBoK In short, it describes: How the system achieves the mission using unique features/events/interactions Relationships between the system and other systems Benefits : Stakeholders can understand the system from the early stages of development In particular, developers who have different backgrounds or perspectives can gain the same understanding","title":"What is ConOps and OpsCons?"},{"location":"version-2.0/application-example/driverless-bus/concept-of-operations/","text":"Concept of Operations # Passenger Transportation System in the urban area # The system, under the surveillance of an in-car operator, will automatically transport passengers while following routes on public roads. The public roads have multiple lanes, traffic lights, and intersections; therefore the system will automatically change lanes and respond to traffic lights at intersections. The system will automatically stop at bus stops. The system is programmed to avoid colliding with objects that are detected on the road. The vehicle is programmed to either safely pass the object when possible, or to stop. While the vehicle is moving, the system automatically maintains a safe following distance and stays within the speed limit (i.e., adaptive cruise control).","title":"Concept of Operations"},{"location":"version-2.0/application-example/driverless-bus/concept-of-operations/#concept-of-operations","text":"","title":"Concept of Operations"},{"location":"version-2.0/application-example/driverless-bus/concept-of-operations/#passenger-transportation-system-in-the-urban-area","text":"The system, under the surveillance of an in-car operator, will automatically transport passengers while following routes on public roads. The public roads have multiple lanes, traffic lights, and intersections; therefore the system will automatically change lanes and respond to traffic lights at intersections. The system will automatically stop at bus stops. The system is programmed to avoid colliding with objects that are detected on the road. The vehicle is programmed to either safely pass the object when possible, or to stop. While the vehicle is moving, the system automatically maintains a safe following distance and stays within the speed limit (i.e., adaptive cruise control).","title":"Passenger Transportation System in the urban area"},{"location":"version-2.0/application-example/driverless-bus/hardware-requirements/","text":"Hardware Requirements # The content is a work in progress. Vehicle Requirements ECU Requirements Sensor Requirements LiDAR Requirements Camera Requirements Radar Requirements","title":"Hardware Requirements"},{"location":"version-2.0/application-example/driverless-bus/hardware-requirements/#hardware-requirements","text":"The content is a work in progress. Vehicle Requirements ECU Requirements Sensor Requirements LiDAR Requirements Camera Requirements Radar Requirements","title":"Hardware Requirements"},{"location":"version-2.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/","text":"ECU Requirements # This is a draft version. Overview # The requirements described in the following pages are determined based on a Tier IV project as a reference for now. This will be updated once the requirements for Open AD Kit was determined. Table of contents # High-level Architecture System Resource & Interface Performance and Data Bandwidth Requirements Hardware Requirements","title":"ECU Requirements"},{"location":"version-2.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/#ecu-requirements","text":"This is a draft version.","title":"ECU Requirements"},{"location":"version-2.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/#overview","text":"The requirements described in the following pages are determined based on a Tier IV project as a reference for now. This will be updated once the requirements for Open AD Kit was determined.","title":"Overview"},{"location":"version-2.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/#table-of-contents","text":"High-level Architecture System Resource & Interface Performance and Data Bandwidth Requirements Hardware Requirements","title":"Table of contents"},{"location":"version-2.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/high-level-arch/","text":"High-level Architecture # This is a draft version. Overview # The reference system consists of three parts of computing unit. Main Autoware 2D Perception Traffic Light Recognition Each unit can be implemented on separated hardware units (ECUs) and, if the hardware has sufficient system resource and performance, some units can also be integrated on a single hardware unit. Block Diagram #","title":"High-level Architecture"},{"location":"version-2.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/high-level-arch/#high-level-architecture","text":"This is a draft version.","title":"High-level Architecture"},{"location":"version-2.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/high-level-arch/#overview","text":"The reference system consists of three parts of computing unit. Main Autoware 2D Perception Traffic Light Recognition Each unit can be implemented on separated hardware units (ECUs) and, if the hardware has sufficient system resource and performance, some units can also be integrated on a single hardware unit.","title":"Overview"},{"location":"version-2.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/high-level-arch/#block-diagram","text":"","title":"Block Diagram"},{"location":"version-2.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/hw-requirements/","text":"Hardware Requirements # This is a draft version. Overview # This page describes sample requirements for hardware specification. NOTE: This type of hardware requirement should be differed depending on a target vehicle and changed by the industrial standard. It also needs to be determined during hardware design so might should be a part of the reference implementation. Reliability # Item Requirement Standard AEC-Q100 Environmental # Item Requirement Operating Temp e.g. -40 to 130 degree celsius Storage Temp Humidity Vibration Shock EMC Mechanical # Item Requirement Dimensions Weight Mounting Power # Item Requirement AC/DC input supply e.g. shall input 350V DC Power Consumption e.g. shall be less 600W Cooling # Item Requirement Liquid cooling","title":"Hardware Requirements"},{"location":"version-2.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/hw-requirements/#hardware-requirements","text":"This is a draft version.","title":"Hardware Requirements"},{"location":"version-2.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/hw-requirements/#overview","text":"This page describes sample requirements for hardware specification. NOTE: This type of hardware requirement should be differed depending on a target vehicle and changed by the industrial standard. It also needs to be determined during hardware design so might should be a part of the reference implementation.","title":"Overview"},{"location":"version-2.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/hw-requirements/#reliability","text":"Item Requirement Standard AEC-Q100","title":"Reliability"},{"location":"version-2.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/hw-requirements/#environmental","text":"Item Requirement Operating Temp e.g. -40 to 130 degree celsius Storage Temp Humidity Vibration Shock EMC","title":"Environmental"},{"location":"version-2.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/hw-requirements/#mechanical","text":"Item Requirement Dimensions Weight Mounting","title":"Mechanical"},{"location":"version-2.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/hw-requirements/#power","text":"Item Requirement AC/DC input supply e.g. shall input 350V DC Power Consumption e.g. shall be less 600W","title":"Power"},{"location":"version-2.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/hw-requirements/#cooling","text":"Item Requirement Liquid cooling","title":"Cooling"},{"location":"version-2.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/perf-data-bandwidth/","text":"Performance and Data Bandwidth Requirements # This is a draft version. Overview # This page describes required performance for the perception accelerators and data bandwidth on each sensor interface and network. Perception Accelerators # Functions Network Model Input resolution @ frame rate Required performance 3D Perception CenterPoint 55000 voxels x 20 points x 10 features @10FPS per LiDAR XX TOPS 2D Perception Yolov4 608x608@10FPS per Camera XX TOPS Traffic Light Recognition MobileNet v2 SSD Lite (Detection) MobileNet v2 (Classification) 300x300@10FPS 224x224@10FPS XX TOPS Data Bandwidth # Type Configurations Data type Data Bandwidth LiDAR Input Mid-range Point cloud 37 Mbps Short-range Point cloud 26 Mbps Camera Input Perception Camera YUV422 16bit 1920x1280 393 Mbps Traffic Light Recognition Camera YUV422 16bit 2880x1860 857 Mbps Inter- ECU 2D Perception to Main Autoware Recognition result & Compressed image data for logging 27 Mbps TLR to Main Autoware Recognition result & Compressed image data for logging 59 Mbps Logging Storage Mid-range LiDAR x 4 Short-range LiDAR x 4 Perception Camera x 6 (Compressed) Traffic Light Recognition Camera x 1 (Compressed) Main Autoware internat topics (272Mbps) 745 Mbps","title":"Performance and Data Bandwidth Requirements"},{"location":"version-2.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/perf-data-bandwidth/#performance-and-data-bandwidth-requirements","text":"This is a draft version.","title":"Performance and Data Bandwidth Requirements"},{"location":"version-2.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/perf-data-bandwidth/#overview","text":"This page describes required performance for the perception accelerators and data bandwidth on each sensor interface and network.","title":"Overview"},{"location":"version-2.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/perf-data-bandwidth/#perception-accelerators","text":"Functions Network Model Input resolution @ frame rate Required performance 3D Perception CenterPoint 55000 voxels x 20 points x 10 features @10FPS per LiDAR XX TOPS 2D Perception Yolov4 608x608@10FPS per Camera XX TOPS Traffic Light Recognition MobileNet v2 SSD Lite (Detection) MobileNet v2 (Classification) 300x300@10FPS 224x224@10FPS XX TOPS","title":"Perception Accelerators"},{"location":"version-2.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/perf-data-bandwidth/#data-bandwidth","text":"Type Configurations Data type Data Bandwidth LiDAR Input Mid-range Point cloud 37 Mbps Short-range Point cloud 26 Mbps Camera Input Perception Camera YUV422 16bit 1920x1280 393 Mbps Traffic Light Recognition Camera YUV422 16bit 2880x1860 857 Mbps Inter- ECU 2D Perception to Main Autoware Recognition result & Compressed image data for logging 27 Mbps TLR to Main Autoware Recognition result & Compressed image data for logging 59 Mbps Logging Storage Mid-range LiDAR x 4 Short-range LiDAR x 4 Perception Camera x 6 (Compressed) Traffic Light Recognition Camera x 1 (Compressed) Main Autoware internat topics (272Mbps) 745 Mbps","title":"Data Bandwidth"},{"location":"version-2.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/sys-resource-if/","text":"System Resource & Interface # This is a draft version. Overview # The following tables describe the required system resource and interface for each computing unit. Main Autoware Unit # Category Item Requirement Computing Resource CPU X86 8core/16thread @3.3GHz or more Memory Dual 16GB (Total 32GB), DDR4-2666 w/ ECC or more GPU 9.4 TFLOPS@FP32 or more Storage 256GB for System Volume 2TB for Logging data LiDAR 100BASE-TX, 1000BASE-T Interfaces IMU CAN or RS232C GNSS 100BASE-TX Vehicle CAN Inter- ECU (2D Perception/TLR) 1000BASE-T Power CPU TDP 80 W GPU TDP 110 W Total Max 250 W 2D Perception Unit # This table shows requirements for one camera. For multiple camera configurations, it requires more hardware units. If the hardware unit has sufficient system resource and performance, it can be integrated on a single hardware unit. Category Item Requirement Computing Resource CPU Arm v8.2 8core @2.26GHz or more Memory 32GB Low-Power Double Data Rate 4x or more GPU 30 TOPS or more Storage 32GB or more Interfaces Camera Gigabit Multimedia Serial Link 2 w/ frame sync trigger or 1000BASE-T (GigE Vision) Inter- ECU (Main Autoware) 1000BASE-T Power CPU TDP xxxW GPU TDP xxxW Total Max.xxxW Traffic Light Recognition Unit # This table shows requirements for one camera. For multiple camera configurations, it requires more hardware units. If the hardware unit has sufficient system resource and performance, it can be integrated on a single hardware unit. Category Item Requirement Computing Resource CPU Arm v8.2 8core @2.26GHz or more Memory 32GB Low-Power Double Data Rate 4x or more GPU 30 TOPS or more Storage 32GB or more Interfaces Camera Gigabit Multimedia Serial Link 2 w/ frame sync trigger or 1000BASE-T (GigE Vision) Inter- ECU (Main Autoware) 1000BASE-T Power CPU TDP xxxW GPU TDP xxxW Total Max.xxxW","title":"System Resource & Interface"},{"location":"version-2.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/sys-resource-if/#system-resource-interface","text":"This is a draft version.","title":"System Resource & Interface"},{"location":"version-2.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/sys-resource-if/#overview","text":"The following tables describe the required system resource and interface for each computing unit.","title":"Overview"},{"location":"version-2.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/sys-resource-if/#main-autoware-unit","text":"Category Item Requirement Computing Resource CPU X86 8core/16thread @3.3GHz or more Memory Dual 16GB (Total 32GB), DDR4-2666 w/ ECC or more GPU 9.4 TFLOPS@FP32 or more Storage 256GB for System Volume 2TB for Logging data LiDAR 100BASE-TX, 1000BASE-T Interfaces IMU CAN or RS232C GNSS 100BASE-TX Vehicle CAN Inter- ECU (2D Perception/TLR) 1000BASE-T Power CPU TDP 80 W GPU TDP 110 W Total Max 250 W","title":"Main Autoware Unit"},{"location":"version-2.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/sys-resource-if/#2d-perception-unit","text":"This table shows requirements for one camera. For multiple camera configurations, it requires more hardware units. If the hardware unit has sufficient system resource and performance, it can be integrated on a single hardware unit. Category Item Requirement Computing Resource CPU Arm v8.2 8core @2.26GHz or more Memory 32GB Low-Power Double Data Rate 4x or more GPU 30 TOPS or more Storage 32GB or more Interfaces Camera Gigabit Multimedia Serial Link 2 w/ frame sync trigger or 1000BASE-T (GigE Vision) Inter- ECU (Main Autoware) 1000BASE-T Power CPU TDP xxxW GPU TDP xxxW Total Max.xxxW","title":"2D Perception Unit"},{"location":"version-2.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/sys-resource-if/#traffic-light-recognition-unit","text":"This table shows requirements for one camera. For multiple camera configurations, it requires more hardware units. If the hardware unit has sufficient system resource and performance, it can be integrated on a single hardware unit. Category Item Requirement Computing Resource CPU Arm v8.2 8core @2.26GHz or more Memory 32GB Low-Power Double Data Rate 4x or more GPU 30 TOPS or more Storage 32GB or more Interfaces Camera Gigabit Multimedia Serial Link 2 w/ frame sync trigger or 1000BASE-T (GigE Vision) Inter- ECU (Main Autoware) 1000BASE-T Power CPU TDP xxxW GPU TDP xxxW Total Max.xxxW","title":"Traffic Light Recognition Unit"},{"location":"version-2.0/application-example/driverless-bus/introduction-of-reference-design/","text":"Introduction of Reference Design # Introduction # Autonomous driving technology # AWF aims to establish a sustainable ecosystem for autonomous driving to which various organizations and individuals can contribute in terms of development, and wherein society can enjoy the benefits. AWF offers open access to technologies contributing to autonomous driving. Autonomous driving requires a composite platform which integrates various software, cloud infrastructure and services in addition to the in-vehicle AD ( Autonomous Driving ) systems. There is a need for a horizontally collaborative development approach based on an open source platform that ensures a level of safety that satisfies society at a reasonable cost. In order to realize this, AWF is promoting (1) Autoware, an open source autonomous driving software, (2) AD System Reference Designs based on ODD ( Operational Design Domain \uff09categorization, and (3) Deep-tech R&D of AD systems. What can do with \"Reference Design\" as ecosystem? # With clear ODD classifications, everyone can understand where AD fits into complex real-world traffic environments. By presenting a suitable \"Reference Design\" for each ODD , AWF simplifies the preparation process in AD and lowers the difficulty threshold for demonstration and implementation.","title":"Introduction of Reference Design"},{"location":"version-2.0/application-example/driverless-bus/introduction-of-reference-design/#introduction-of-reference-design","text":"","title":"Introduction of Reference Design"},{"location":"version-2.0/application-example/driverless-bus/introduction-of-reference-design/#introduction","text":"","title":"Introduction"},{"location":"version-2.0/application-example/driverless-bus/introduction-of-reference-design/#autonomous-driving-technology","text":"AWF aims to establish a sustainable ecosystem for autonomous driving to which various organizations and individuals can contribute in terms of development, and wherein society can enjoy the benefits. AWF offers open access to technologies contributing to autonomous driving. Autonomous driving requires a composite platform which integrates various software, cloud infrastructure and services in addition to the in-vehicle AD ( Autonomous Driving ) systems. There is a need for a horizontally collaborative development approach based on an open source platform that ensures a level of safety that satisfies society at a reasonable cost. In order to realize this, AWF is promoting (1) Autoware, an open source autonomous driving software, (2) AD System Reference Designs based on ODD ( Operational Design Domain \uff09categorization, and (3) Deep-tech R&D of AD systems.","title":"Autonomous driving technology"},{"location":"version-2.0/application-example/driverless-bus/introduction-of-reference-design/#what-can-do-with-reference-design-as-ecosystem","text":"With clear ODD classifications, everyone can understand where AD fits into complex real-world traffic environments. By presenting a suitable \"Reference Design\" for each ODD , AWF simplifies the preparation process in AD and lowers the difficulty threshold for demonstration and implementation.","title":"What can do with \"Reference Design\" as ecosystem?"},{"location":"version-2.0/application-example/driverless-bus/operational-concept/","text":"Operational Concept # Operational Concept (OpsCon) of the Passenger Transportation System in the urban area is below: Daytime operation Nighttime operation Follow a route Let passengers on and off at bus stops Avoid collisions Set service route via HMI on the vehicle Interact with other vehicles on the public roads Interact with emergency vehicles Interact with traffic lights Operation mode Take over request to the operator Lane keeping and changing lanes Adaptive cruise control Predict pedestrian stepping into the road","title":"Operational Concept"},{"location":"version-2.0/application-example/driverless-bus/operational-concept/#operational-concept","text":"Operational Concept (OpsCon) of the Passenger Transportation System in the urban area is below: Daytime operation Nighttime operation Follow a route Let passengers on and off at bus stops Avoid collisions Set service route via HMI on the vehicle Interact with other vehicles on the public roads Interact with emergency vehicles Interact with traffic lights Operation mode Take over request to the operator Lane keeping and changing lanes Adaptive cruise control Predict pedestrian stepping into the road","title":"Operational Concept"},{"location":"version-2.0/application-example/driverless-bus/operational-concept/adaptive-cruise-control/","text":"Adaptive cruise control # The system automatically maintains a safe following distance and stays within the speed limit.","title":"Adaptive cruise control"},{"location":"version-2.0/application-example/driverless-bus/operational-concept/adaptive-cruise-control/#adaptive-cruise-control","text":"The system automatically maintains a safe following distance and stays within the speed limit.","title":"Adaptive cruise control"},{"location":"version-2.0/application-example/driverless-bus/operational-concept/avoid-collisions/","text":"Avoid collisions # When there are objects on the route, the system will automatically perform the following actions: a. The system automatically stops if there is surrounding traffic. b. The system automatically avoids the objects if there is no surrounding traffic.","title":"Avoid collisions"},{"location":"version-2.0/application-example/driverless-bus/operational-concept/avoid-collisions/#avoid-collisions","text":"When there are objects on the route, the system will automatically perform the following actions: a. The system automatically stops if there is surrounding traffic. b. The system automatically avoids the objects if there is no surrounding traffic.","title":"Avoid collisions"},{"location":"version-2.0/application-example/driverless-bus/operational-concept/daytime-operation/","text":"Daytime operation # Currently, the system does NOT operate in the daytime. In the future, the system will be able to operate during the daytime (9:30am - 3:30pm). The vehicle will be fully charged before the operation in the daytime. The operator connects the charger to the vehicle, and the vehicle is automatically charged.","title":"Daytime operation"},{"location":"version-2.0/application-example/driverless-bus/operational-concept/daytime-operation/#daytime-operation","text":"Currently, the system does NOT operate in the daytime. In the future, the system will be able to operate during the daytime (9:30am - 3:30pm). The vehicle will be fully charged before the operation in the daytime. The operator connects the charger to the vehicle, and the vehicle is automatically charged.","title":"Daytime operation"},{"location":"version-2.0/application-example/driverless-bus/operational-concept/follow-a-route/","text":"Follow a route # The system follows a route set on the public road while an in-car operator is in the autonomous driving vehicle of the system.","title":"Follow a route"},{"location":"version-2.0/application-example/driverless-bus/operational-concept/follow-a-route/#follow-a-route","text":"The system follows a route set on the public road while an in-car operator is in the autonomous driving vehicle of the system.","title":"Follow a route"},{"location":"version-2.0/application-example/driverless-bus/operational-concept/interact-with-emergency-vehicles/","text":"Interact with emergency vehicles # When the vehicle meets an emergency vehicle, an in-car operator performs the following actions: Promptly maneuvers the vehicle to the side of the road and stops Manually re-launches the system after the emergency vehicle passes by NOTE: The operator can use HMI (e.g., steering wheel or brake pedal) at any time to override the system control.","title":"Interact with emergency vehicles"},{"location":"version-2.0/application-example/driverless-bus/operational-concept/interact-with-emergency-vehicles/#interact-with-emergency-vehicles","text":"When the vehicle meets an emergency vehicle, an in-car operator performs the following actions: Promptly maneuvers the vehicle to the side of the road and stops Manually re-launches the system after the emergency vehicle passes by NOTE: The operator can use HMI (e.g., steering wheel or brake pedal) at any time to override the system control.","title":"Interact with emergency vehicles"},{"location":"version-2.0/application-example/driverless-bus/operational-concept/interact-with-other-vehicle-on-the-public-roads/","text":"Interact with other vehicles on the public roads # The service route uses public roads, so the system interacts with other vehicles and must obey all traffic laws. When the vehicle approaches an intersection, the system is programed to yield and take right of way with surrounding traffic, depending the actual situation and traffic laws.","title":"Interact with other vehicles on the public roads"},{"location":"version-2.0/application-example/driverless-bus/operational-concept/interact-with-other-vehicle-on-the-public-roads/#interact-with-other-vehicles-on-the-public-roads","text":"The service route uses public roads, so the system interacts with other vehicles and must obey all traffic laws. When the vehicle approaches an intersection, the system is programed to yield and take right of way with surrounding traffic, depending the actual situation and traffic laws.","title":"Interact with other vehicles on the public roads"},{"location":"version-2.0/application-example/driverless-bus/operational-concept/interact-with-traffic-lights/","text":"Interact with traffic lights # When the vehicle meets a traffic light, the system performs one of the following actions: Stop on a red light Stop on a yellow light Go straight, turn right, or turn left on a green light or arrow","title":"Interact with traffic lights"},{"location":"version-2.0/application-example/driverless-bus/operational-concept/interact-with-traffic-lights/#interact-with-traffic-lights","text":"When the vehicle meets a traffic light, the system performs one of the following actions: Stop on a red light Stop on a yellow light Go straight, turn right, or turn left on a green light or arrow","title":"Interact with traffic lights"},{"location":"version-2.0/application-example/driverless-bus/operational-concept/lane-keeping-and-changing-lanes/","text":"Lane keeping and changing lanes # The system stays the driving lane or changes lanes according to the route.","title":"Lane keeping and changing lanes"},{"location":"version-2.0/application-example/driverless-bus/operational-concept/lane-keeping-and-changing-lanes/#lane-keeping-and-changing-lanes","text":"The system stays the driving lane or changes lanes according to the route.","title":"Lane keeping and changing lanes"},{"location":"version-2.0/application-example/driverless-bus/operational-concept/let-passengers-on-and-off-at-bus-stops/","text":"Let passengers on and off at bus stops # The system stops at bus stops set by the in-car operator. The in-car operator manually opens and closes the door of the vehicle to let passengers on and off at bus stops due to the local government\u2019s request. After the in-car operator requests the system to depart, the system automatically resumes driving along the route.","title":"Let passengers on and off at bus stops"},{"location":"version-2.0/application-example/driverless-bus/operational-concept/let-passengers-on-and-off-at-bus-stops/#let-passengers-on-and-off-at-bus-stops","text":"The system stops at bus stops set by the in-car operator. The in-car operator manually opens and closes the door of the vehicle to let passengers on and off at bus stops due to the local government\u2019s request. After the in-car operator requests the system to depart, the system automatically resumes driving along the route.","title":"Let passengers on and off at bus stops"},{"location":"version-2.0/application-example/driverless-bus/operational-concept/nighttime-operation/","text":"Nighttime operation # During the nighttime (10pm - 1am), an in-car operator drives the vehicle from a parking lot to a start position and manually launches the autonomous driving system via HMI in the vehicle. The system starts moving automatically on a route set by the in-car operator. The in-car operator is while the system automatically operates.","title":"Nighttime operation"},{"location":"version-2.0/application-example/driverless-bus/operational-concept/nighttime-operation/#nighttime-operation","text":"During the nighttime (10pm - 1am), an in-car operator drives the vehicle from a parking lot to a start position and manually launches the autonomous driving system via HMI in the vehicle. The system starts moving automatically on a route set by the in-car operator. The in-car operator is while the system automatically operates.","title":"Nighttime operation"},{"location":"version-2.0/application-example/driverless-bus/operational-concept/operation-mode/","text":"Operation mode: Automatic/Manual # The in-car operator manually launches the autonomous driving system, which causes the system to start the autonomous driving. If the fail safe system in the vehicle detects malfunctions or the in-car operator presses the button on the fail safe system, the system automatically changes the operation mode from automatic to manual. Then the vehicle automatically stops.","title":"Operation mode: Automatic/Manual"},{"location":"version-2.0/application-example/driverless-bus/operational-concept/operation-mode/#operation-mode-automaticmanual","text":"The in-car operator manually launches the autonomous driving system, which causes the system to start the autonomous driving. If the fail safe system in the vehicle detects malfunctions or the in-car operator presses the button on the fail safe system, the system automatically changes the operation mode from automatic to manual. Then the vehicle automatically stops.","title":"Operation mode: Automatic/Manual"},{"location":"version-2.0/application-example/driverless-bus/operational-concept/predict-pedestrian-stepping-into-the-road/","text":"Predict pedestrian stepping into the road # The vehicle is programmed to detect pedestrians who may step into the road, and the vehicle decelerates in response.","title":"Predict pedestrian stepping into the road"},{"location":"version-2.0/application-example/driverless-bus/operational-concept/predict-pedestrian-stepping-into-the-road/#predict-pedestrian-stepping-into-the-road","text":"The vehicle is programmed to detect pedestrians who may step into the road, and the vehicle decelerates in response.","title":"Predict pedestrian stepping into the road"},{"location":"version-2.0/application-example/driverless-bus/operational-concept/set-service-route-via-HMI-on-the-vehicle/","text":"Set service route via HMI on the vehicle # The operator can set authorized service routes of the system via the Human Machine Interface ( HMI ) on the vehicle before the operation. The system can only accept a modified route while the vehicle is parked. NOTE: the service route cannot be changed without the authorization from the local government.","title":"Set service route via HMI on the vehicle"},{"location":"version-2.0/application-example/driverless-bus/operational-concept/set-service-route-via-HMI-on-the-vehicle/#set-service-route-via-hmi-on-the-vehicle","text":"The operator can set authorized service routes of the system via the Human Machine Interface ( HMI ) on the vehicle before the operation. The system can only accept a modified route while the vehicle is parked. NOTE: the service route cannot be changed without the authorization from the local government.","title":"Set service route via HMI on the vehicle"},{"location":"version-2.0/application-example/driverless-bus/operational-concept/take-over-request-to-the-operator/","text":"Take over request to the operator # When the system cannot judge whether it can move forward, the system sends a recommendation to hand over operation to the in-car operator. The operator is supposed to perform the following actions when requested by the system: Request to depart\uff08refer to Let passengers on and off at bus-stops \uff09 Avoid objects Detour","title":"Take over request to the operator"},{"location":"version-2.0/application-example/driverless-bus/operational-concept/take-over-request-to-the-operator/#take-over-request-to-the-operator","text":"When the system cannot judge whether it can move forward, the system sends a recommendation to hand over operation to the in-car operator. The operator is supposed to perform the following actions when requested by the system: Request to depart\uff08refer to Let passengers on and off at bus-stops \uff09 Avoid objects Detour","title":"Take over request to the operator"},{"location":"version-2.0/application-example/driverless-bus/operational-environment-requirement/","text":"Operational Environment Requirements # The content is a work in progress.","title":"Operational Environment Requirements"},{"location":"version-2.0/application-example/driverless-bus/operational-environment-requirement/#operational-environment-requirements","text":"The content is a work in progress.","title":"Operational Environment Requirements"},{"location":"version-2.0/application-example/driverless-bus/software-requirements/","text":"Software Requirements # The content is a work in progress. Operating System Requirements Kernel Module Requirements Middleware Requirements DDS Requirements Map Requirements Design docs of Autoware Autoware API Component Architecture Repository Configuration","title":"Software Requirements"},{"location":"version-2.0/application-example/driverless-bus/software-requirements/#software-requirements","text":"The content is a work in progress. Operating System Requirements Kernel Module Requirements Middleware Requirements DDS Requirements Map Requirements Design docs of Autoware Autoware API Component Architecture Repository Configuration","title":"Software Requirements"},{"location":"version-2.0/application-example/driverless-bus/software-requirements/autoware-api/","text":"Autoware API # Overview # Autoware API provides a long-term and stable operation protocol for autonomous driving vehicles, and clarifies how to support new sensors and vehicles and add new features. It also works as a framework for easy access to the functions of each component by developers of other components. Concept # There are two categories of Autoware API. One is Autoware AD API for operating the vehicle from outside the autonomous driving system such as Fleet Management System(FMS) and HMI for operators or passengers. The other is Autoware Component Interfaces for linking each internal component. Some external systems for evaluation or debugging purposes, such as simulator, are allowed access to Component Interfaces in addition to AD API. AD API Customization # For general usage, Autoware provides the default AD API implementations and configurations using Component Interfaces. If a special behavior is needed, the implementation can be modified as long as it satisfies the requirements of the specification. Component Interfaces Hierarchy # Autoware Component Interfaces have a hierarchical specification. The top-level architecture consists of several components, and each component has some options of the next-level architecture. Developers select one of them when implementing the component. The simplest next-level architecture is monolithic. This is an all-in-one and black box implementation, and is suitable for small group development, prototyping, and extremely complex functions. Others are just concepts and do not currently exist. However, these have advantages for large group development. Developers can combine their modules with other modules that adopt the same architecture. Interface Code Generation # For specification clarification and development efficiency, it is recommended to use the generated code by the defined interface. Developers may select the interface to use from the specification and refer the generated code in their program. This makes it easy to analyze the interface used by each program, which then can be applied to configuration automation and visualization.","title":"Autoware API"},{"location":"version-2.0/application-example/driverless-bus/software-requirements/autoware-api/#autoware-api","text":"","title":"Autoware API"},{"location":"version-2.0/application-example/driverless-bus/software-requirements/autoware-api/#overview","text":"Autoware API provides a long-term and stable operation protocol for autonomous driving vehicles, and clarifies how to support new sensors and vehicles and add new features. It also works as a framework for easy access to the functions of each component by developers of other components.","title":"Overview"},{"location":"version-2.0/application-example/driverless-bus/software-requirements/autoware-api/#concept","text":"There are two categories of Autoware API. One is Autoware AD API for operating the vehicle from outside the autonomous driving system such as Fleet Management System(FMS) and HMI for operators or passengers. The other is Autoware Component Interfaces for linking each internal component. Some external systems for evaluation or debugging purposes, such as simulator, are allowed access to Component Interfaces in addition to AD API.","title":"Concept"},{"location":"version-2.0/application-example/driverless-bus/software-requirements/autoware-api/#ad-api-customization","text":"For general usage, Autoware provides the default AD API implementations and configurations using Component Interfaces. If a special behavior is needed, the implementation can be modified as long as it satisfies the requirements of the specification.","title":"AD API Customization"},{"location":"version-2.0/application-example/driverless-bus/software-requirements/autoware-api/#component-interfaces-hierarchy","text":"Autoware Component Interfaces have a hierarchical specification. The top-level architecture consists of several components, and each component has some options of the next-level architecture. Developers select one of them when implementing the component. The simplest next-level architecture is monolithic. This is an all-in-one and black box implementation, and is suitable for small group development, prototyping, and extremely complex functions. Others are just concepts and do not currently exist. However, these have advantages for large group development. Developers can combine their modules with other modules that adopt the same architecture.","title":"Component Interfaces Hierarchy"},{"location":"version-2.0/application-example/driverless-bus/software-requirements/autoware-api/#interface-code-generation","text":"For specification clarification and development efficiency, it is recommended to use the generated code by the defined interface. Developers may select the interface to use from the specification and refer the generated code in their program. This makes it easy to analyze the interface used by each program, which then can be applied to configuration automation and visualization.","title":"Interface Code Generation"},{"location":"version-2.0/application-example/driverless-bus/software-requirements/component-architecture/","text":"Component architecture # Overview # The figure below is the overview of Autoware's component configuration (tentative). Autoware components # TODO(Tier IV): Write the details based on the following materials. Autoware.Auto autoware_auto_msgs Tier IV's proposal document Tier IV's proposal implementation Map # Inputs: Map file PointCloud map file Vector map file Outputs: Map data PointCloud map file Vector map file Sensing # Inputs: Raw sensor data GNSS IMU Camera LiDAR RADAR Estimated self motion To filter distortions Outputs: Preprocessed sensor data GNSS pose and doppler velocity IMU acceleration and angular velocity Camera image LiDAR PointCloud RADAR reflection Localization # Inputs: Preprocessed sensor data GNSS pose and doppler velocity IMU acceleration and angular velocity Camera image LiDAR PointCloud RADAR reflection Map data PointCloud map Vector map Outputs: Localized self pose Topic TF Estimated self motion Perception # Inputs: Localized self pose Estimated self motion Preprocessed sensor data Camera image LiDAR PointCloud RADAR reflection Outputs: Detected dynamic objects Detected traffic lights Filtered obstacle PointCloud Planning # Inputs: Localized pose Estimated self motion Outputs: Planned trajectory Planning status Control # Inputs: Localized self pose Estimated self motion Planner trajectory Vehicle sensor data velocity steering angle Outputs: Control commands High-level commands for easy usage Low-level commands for detailed controls Vehicle # Autoware to Vehicle # Inputs: Control commands Outputs: Raw vehicle control commands Vehicle to Autoware # Inputs: Raw vehicle sensor data (e.g. CAN) Outputs: Vehicle sensor data (Topic) System # Inputs: Each component output Outputs: System status MRM request","title":"Component architecture"},{"location":"version-2.0/application-example/driverless-bus/software-requirements/component-architecture/#component-architecture","text":"","title":"Component architecture"},{"location":"version-2.0/application-example/driverless-bus/software-requirements/component-architecture/#overview","text":"The figure below is the overview of Autoware's component configuration (tentative).","title":"Overview"},{"location":"version-2.0/application-example/driverless-bus/software-requirements/component-architecture/#autoware-components","text":"TODO(Tier IV): Write the details based on the following materials. Autoware.Auto autoware_auto_msgs Tier IV's proposal document Tier IV's proposal implementation","title":"Autoware components"},{"location":"version-2.0/application-example/driverless-bus/software-requirements/component-architecture/#map","text":"Inputs: Map file PointCloud map file Vector map file Outputs: Map data PointCloud map file Vector map file","title":"Map"},{"location":"version-2.0/application-example/driverless-bus/software-requirements/component-architecture/#sensing","text":"Inputs: Raw sensor data GNSS IMU Camera LiDAR RADAR Estimated self motion To filter distortions Outputs: Preprocessed sensor data GNSS pose and doppler velocity IMU acceleration and angular velocity Camera image LiDAR PointCloud RADAR reflection","title":"Sensing"},{"location":"version-2.0/application-example/driverless-bus/software-requirements/component-architecture/#localization","text":"Inputs: Preprocessed sensor data GNSS pose and doppler velocity IMU acceleration and angular velocity Camera image LiDAR PointCloud RADAR reflection Map data PointCloud map Vector map Outputs: Localized self pose Topic TF Estimated self motion","title":"Localization"},{"location":"version-2.0/application-example/driverless-bus/software-requirements/component-architecture/#perception","text":"Inputs: Localized self pose Estimated self motion Preprocessed sensor data Camera image LiDAR PointCloud RADAR reflection Outputs: Detected dynamic objects Detected traffic lights Filtered obstacle PointCloud","title":"Perception"},{"location":"version-2.0/application-example/driverless-bus/software-requirements/component-architecture/#planning","text":"Inputs: Localized pose Estimated self motion Outputs: Planned trajectory Planning status","title":"Planning"},{"location":"version-2.0/application-example/driverless-bus/software-requirements/component-architecture/#control","text":"Inputs: Localized self pose Estimated self motion Planner trajectory Vehicle sensor data velocity steering angle Outputs: Control commands High-level commands for easy usage Low-level commands for detailed controls","title":"Control"},{"location":"version-2.0/application-example/driverless-bus/software-requirements/component-architecture/#vehicle","text":"","title":"Vehicle"},{"location":"version-2.0/application-example/driverless-bus/software-requirements/component-architecture/#system","text":"Inputs: Each component output Outputs: System status MRM request","title":"System"},{"location":"version-2.0/application-example/driverless-bus/software-requirements/design-docs-of-autoware/","text":"Design docs of Autoware # In this section, we'll explain a couple of design documents of Autoware. The first one is about Autoware API . It defines two kinds of APIs for different developers. Autoware AD API for developers of external systems such as fleet management HMI , etc. AD means Autonomous Driving. Autoware Component Interface for developers of Autoware components such as Localization, Perception, etc. The second one is about the architecture of Autoware components. It explains the interface between Autoware components in detail. The last one is about the repository configuration of Autoware, which is currently used here . It explains why such a distributed structure is necessary.","title":"Design docs of Autoware"},{"location":"version-2.0/application-example/driverless-bus/software-requirements/design-docs-of-autoware/#design-docs-of-autoware","text":"In this section, we'll explain a couple of design documents of Autoware. The first one is about Autoware API . It defines two kinds of APIs for different developers. Autoware AD API for developers of external systems such as fleet management HMI , etc. AD means Autonomous Driving. Autoware Component Interface for developers of Autoware components such as Localization, Perception, etc. The second one is about the architecture of Autoware components. It explains the interface between Autoware components in detail. The last one is about the repository configuration of Autoware, which is currently used here . It explains why such a distributed structure is necessary.","title":"Design docs of Autoware"},{"location":"version-2.0/application-example/driverless-bus/software-requirements/repository-configuration/","text":"Repository configuration # Overview # This page shows the repository configuration of Autoware and its concepts. Warning Note: This figure is tentative. TODO: Add documentations repositories, WG repositories, and autoware.org. Concepts # Core/Universe architecture # Since Autoware is desired to be usable for production-level vehicles in the future, Autoware.Auto has been used strict merge criteria. However, since there is no specific requirements or specifications in Autonomous Driving, it's almost impossible to build a perfect product from the beginning. We need prototyping phases to build a high-quality product, so we're doing ODD -based developments. Then, doing every development in one branch causes slowing down of development speed or mixin of low-quality. Also, forcing such a strict rules for all contributors will make them discourage from sending PRs. Therefore, it's better to separate production level and high-quality code and prototyping level code. Specifically, we define Core/Universe for this. Core defines the interfaces of Autoware Both Core and Universe refer to the interface Core has high-quality code Universe has experimental level code With this, we aim to accomplish the following things. Contributors can feel free to send small PRs. We can keep high-quality for the Core code. We can rapidly build prototypes in Universe. We can develop a lot of extensions, including cutting-edge features, based on the interfaces. Definition of Core/Universe # Core Complete end-to-end autonomous driving framework Supports all current AWF ODDs Provides the definitions and the functionality for which other packages can extend Strict code and quality control Heavily managed by the AWF Stable base implementation Universe Additional packages built on top of Core Extends Autoware functionality beyond the AWF ODDs Completely dependent on Core functionality and message definitions Relaxed code and quality control Community managed Enables quick experimentation and prototype testing Repositories and roles # Although some repositories might be added in the future, these are enough for explaining the core concept. autowarefoundation/autoware This is a meta-repository that contains .repos files to construct a workspace. Since it's prospected to be forked by users, we don't put a lot of information here to avoid unnecessary differences. autowarefoundation/autoware_common This is a repository that contains ROS packages referenced in common by many repositories like libraries and utilities. In order to reduce the CI execution time, splitting that kind of packages from a big repository is a good practice. autowarefoundation/autoware.core This is a core repository that contains high-quality and stable ROS packages for Autonomous Driving. Although it's almost empty at this time, it will be implemented based on Autoware.Auto and Autoware.Universe during the next ODD project. autowarefoundation/autoware.universe This is a core repository that contains experimental but cutting-edge ROS packages for Autonomous Driving. autowarefoundation/autoware_launch This is a launch configuration repository that contains node configurations and their parameters. autowarefoundation/autoware-github-actions This is a repository for CI that contains reusable workflows of GitHub Actions . Since Autoware has a lot of repositories in total, making CI scripts DRY(Don't Repeat Yourself) is efficient. autowarefoundation/autoware-documentation This is a documentation repository for Autoware users and developers. Since Autoware Core/Universe has multiple repositories, preparing a central documentation repository is more user-friendly than writing distributed documentation in each repository. FAQ # Why don't use the meta-repository for documentation? # Since it's forked by many users, documentation changes would be noise during syncing repositories. Why autoware.org isn't enough for documentation? # Since Software Engineers can't maintain it easily, it's hard to write a lot of information and keep up-to-date. Why both autoware-documentation and autoware-reference-design (this site) are required? # It's for a kind of separation of concerns. Too much information on one site makes confusion. autoware-documentation is mainly for users. autoware-reference-design is for core developers.","title":"Repository configuration"},{"location":"version-2.0/application-example/driverless-bus/software-requirements/repository-configuration/#repository-configuration","text":"","title":"Repository configuration"},{"location":"version-2.0/application-example/driverless-bus/software-requirements/repository-configuration/#overview","text":"This page shows the repository configuration of Autoware and its concepts. Warning Note: This figure is tentative. TODO: Add documentations repositories, WG repositories, and autoware.org.","title":"Overview"},{"location":"version-2.0/application-example/driverless-bus/software-requirements/repository-configuration/#concepts","text":"","title":"Concepts"},{"location":"version-2.0/application-example/driverless-bus/software-requirements/repository-configuration/#coreuniverse-architecture","text":"Since Autoware is desired to be usable for production-level vehicles in the future, Autoware.Auto has been used strict merge criteria. However, since there is no specific requirements or specifications in Autonomous Driving, it's almost impossible to build a perfect product from the beginning. We need prototyping phases to build a high-quality product, so we're doing ODD -based developments. Then, doing every development in one branch causes slowing down of development speed or mixin of low-quality. Also, forcing such a strict rules for all contributors will make them discourage from sending PRs. Therefore, it's better to separate production level and high-quality code and prototyping level code. Specifically, we define Core/Universe for this. Core defines the interfaces of Autoware Both Core and Universe refer to the interface Core has high-quality code Universe has experimental level code With this, we aim to accomplish the following things. Contributors can feel free to send small PRs. We can keep high-quality for the Core code. We can rapidly build prototypes in Universe. We can develop a lot of extensions, including cutting-edge features, based on the interfaces.","title":"Core/Universe architecture"},{"location":"version-2.0/application-example/driverless-bus/software-requirements/repository-configuration/#definition-of-coreuniverse","text":"Core Complete end-to-end autonomous driving framework Supports all current AWF ODDs Provides the definitions and the functionality for which other packages can extend Strict code and quality control Heavily managed by the AWF Stable base implementation Universe Additional packages built on top of Core Extends Autoware functionality beyond the AWF ODDs Completely dependent on Core functionality and message definitions Relaxed code and quality control Community managed Enables quick experimentation and prototype testing","title":"Definition of Core/Universe"},{"location":"version-2.0/application-example/driverless-bus/software-requirements/repository-configuration/#repositories-and-roles","text":"Although some repositories might be added in the future, these are enough for explaining the core concept. autowarefoundation/autoware This is a meta-repository that contains .repos files to construct a workspace. Since it's prospected to be forked by users, we don't put a lot of information here to avoid unnecessary differences. autowarefoundation/autoware_common This is a repository that contains ROS packages referenced in common by many repositories like libraries and utilities. In order to reduce the CI execution time, splitting that kind of packages from a big repository is a good practice. autowarefoundation/autoware.core This is a core repository that contains high-quality and stable ROS packages for Autonomous Driving. Although it's almost empty at this time, it will be implemented based on Autoware.Auto and Autoware.Universe during the next ODD project. autowarefoundation/autoware.universe This is a core repository that contains experimental but cutting-edge ROS packages for Autonomous Driving. autowarefoundation/autoware_launch This is a launch configuration repository that contains node configurations and their parameters. autowarefoundation/autoware-github-actions This is a repository for CI that contains reusable workflows of GitHub Actions . Since Autoware has a lot of repositories in total, making CI scripts DRY(Don't Repeat Yourself) is efficient. autowarefoundation/autoware-documentation This is a documentation repository for Autoware users and developers. Since Autoware Core/Universe has multiple repositories, preparing a central documentation repository is more user-friendly than writing distributed documentation in each repository.","title":"Repositories and roles"},{"location":"version-2.0/application-example/driverless-bus/software-requirements/repository-configuration/#faq","text":"","title":"FAQ"},{"location":"version-2.0/application-example/driverless-bus/software-requirements/repository-configuration/#why-dont-use-the-meta-repository-for-documentation","text":"Since it's forked by many users, documentation changes would be noise during syncing repositories.","title":"Why don't use the meta-repository for documentation?"},{"location":"version-2.0/application-example/driverless-bus/software-requirements/repository-configuration/#why-autowareorg-isnt-enough-for-documentation","text":"Since Software Engineers can't maintain it easily, it's hard to write a lot of information and keep up-to-date.","title":"Why autoware.org isn't enough for documentation?"},{"location":"version-2.0/application-example/driverless-bus/software-requirements/repository-configuration/#why-both-autoware-documentation-and-autoware-reference-design-this-site-are-required","text":"It's for a kind of separation of concerns. Too much information on one site makes confusion. autoware-documentation is mainly for users. autoware-reference-design is for core developers.","title":"Why both autoware-documentation and autoware-reference-design (this site) are required?"},{"location":"version-2.0/application-example/driverless-bus/system-configuration/","text":"System Configuration # The content is a work in progress. This chapter should show the physical configuration of the system.","title":"System Configuration"},{"location":"version-2.0/application-example/driverless-bus/system-configuration/#system-configuration","text":"The content is a work in progress. This chapter should show the physical configuration of the system.","title":"System Configuration"},{"location":"version-2.0/application-example/driverless-bus/system-requirements/","text":"System Requirements # The content is a work in progress. This chapter should show requirements for the system of interest and its sub-systems. Parity Requirements","title":"System Requirements"},{"location":"version-2.0/application-example/driverless-bus/system-requirements/#system-requirements","text":"The content is a work in progress. This chapter should show requirements for the system of interest and its sub-systems. Parity Requirements","title":"System Requirements"},{"location":"version-2.0/application-example/driverless-bus/system-requirements/parity-requirements/","text":"Parity # Importance of the parity in the verification of autonomous driving systems # One of the most important points in the verification process of the autonomous driving system is the guaranteed level of the parity between the edge (onboard) and the cloud (CI /CD) environment. Various types of the parity and the information that is useful in the verification architecture taking the parity into consideration \u3000 are explained. Parity types # Device Parity # The parity of the hardware (machines). When using the public cloud, as the device variation available on the public cloud is generally limited, it is difficult to guarantee this device parity. CPU Architecture Parity # The parity of the processor implementation including the microservice architecture and the clock speed, etc. ISA Parity # The ISA (Instruction Set Architecture) Parity is different from the CPU Architecture Parity. It means the parity of the available register resource, instruction set, and the calculation functionality, where the processor implementation is abstracted. Runtime Parity # The Runtime Parity means the parity of the kernel module and the container runtime, where the built result at the application level is guaranteed to run flawlessly. However, depending on the implementation, some modules do not run even if the Runtime Parity is secured. For example, the object detection module which is optimized for a GPU model. Environment Parity # The Environment Parity means the parity of the network configuration, set of frameworks and libraries of the autonomous driving system applications. Parity and Cloud Native DevOps # In autonomous driving system verification, it is important to conduct the necessary tests by understanding what level of parity is guaranteed for the verification environment compared to the vehicle environment. On the other hand, in case that the public cloud is used as a cloud native environment, the Device Parity may not be fulfilled. Depending on the choice of the chip, the CPU Architecture Parity or the ISA Parity may not be met. It is crucial to conduct tests in the bench environment while improving the development experience by executing the sufficient number of tests in a short time period in a cloud native manner.","title":"Parity"},{"location":"version-2.0/application-example/driverless-bus/system-requirements/parity-requirements/#parity","text":"","title":"Parity"},{"location":"version-2.0/application-example/driverless-bus/system-requirements/parity-requirements/#importance-of-the-parity-in-the-verification-of-autonomous-driving-systems","text":"One of the most important points in the verification process of the autonomous driving system is the guaranteed level of the parity between the edge (onboard) and the cloud (CI /CD) environment. Various types of the parity and the information that is useful in the verification architecture taking the parity into consideration \u3000 are explained.","title":"Importance of the parity in the verification of autonomous driving systems"},{"location":"version-2.0/application-example/driverless-bus/system-requirements/parity-requirements/#parity-types","text":"","title":"Parity types"},{"location":"version-2.0/application-example/driverless-bus/system-requirements/parity-requirements/#device-parity","text":"The parity of the hardware (machines). When using the public cloud, as the device variation available on the public cloud is generally limited, it is difficult to guarantee this device parity.","title":"Device Parity"},{"location":"version-2.0/application-example/driverless-bus/system-requirements/parity-requirements/#cpu-architecture-parity","text":"The parity of the processor implementation including the microservice architecture and the clock speed, etc.","title":"CPU Architecture Parity"},{"location":"version-2.0/application-example/driverless-bus/system-requirements/parity-requirements/#isa-parity","text":"The ISA (Instruction Set Architecture) Parity is different from the CPU Architecture Parity. It means the parity of the available register resource, instruction set, and the calculation functionality, where the processor implementation is abstracted.","title":"ISA Parity"},{"location":"version-2.0/application-example/driverless-bus/system-requirements/parity-requirements/#runtime-parity","text":"The Runtime Parity means the parity of the kernel module and the container runtime, where the built result at the application level is guaranteed to run flawlessly. However, depending on the implementation, some modules do not run even if the Runtime Parity is secured. For example, the object detection module which is optimized for a GPU model.","title":"Runtime Parity"},{"location":"version-2.0/application-example/driverless-bus/system-requirements/parity-requirements/#environment-parity","text":"The Environment Parity means the parity of the network configuration, set of frameworks and libraries of the autonomous driving system applications.","title":"Environment Parity"},{"location":"version-2.0/application-example/driverless-bus/system-requirements/parity-requirements/#parity-and-cloud-native-devops","text":"In autonomous driving system verification, it is important to conduct the necessary tests by understanding what level of parity is guaranteed for the verification environment compared to the vehicle environment. On the other hand, in case that the public cloud is used as a cloud native environment, the Device Parity may not be fulfilled. Depending on the choice of the chip, the CPU Architecture Parity or the ISA Parity may not be met. It is crucial to conduct tests in the bench environment while improving the development experience by executing the sufficient number of tests in a short time period in a cloud native manner.","title":"Parity and Cloud Native DevOps"},{"location":"version-2.0/start-guide/","text":"Start guide # This page describes how to install, set up and run Autoware and its associated simulators on supported development platforms. Installation explains how to set up the development environment that are described in the System Configuration chapter. How to run Autoware shows how to run Autoware on the development platform that are set up in the Installation chapter. How to run simulators demonstrates how to run simulators that are set up in the Installation chapter.","title":"Start guide"},{"location":"version-2.0/start-guide/#start-guide","text":"This page describes how to install, set up and run Autoware and its associated simulators on supported development platforms. Installation explains how to set up the development environment that are described in the System Configuration chapter. How to run Autoware shows how to run Autoware on the development platform that are set up in the Installation chapter. How to run simulators demonstrates how to run simulators that are set up in the Installation chapter.","title":"Start guide"},{"location":"version-2.0/start-guide/how-to-run-autoware/","text":"How to run Autoware # This page explains how to run Autoware on the development platform that are set up in the Installation chapter . Minimum requirements # Developer Platform: TODO In-Vehicle Development Platform 1 : TODO Software Tool: TODO Container Image: TODO 1. Run Autoware on the developer platform # Run Autoware.Auto on AVA platform or PCU or Xavier # Access AVA platform or PCU or Xavier via SSH. Deploy kubernetes clusters for Autoware. kubectl apply -f comhpc-deployments You can make sure deployments are deployed. root@comhpc:~# kubectl get deploy -o wide NAME READY UP-TO-DATE AVAILABLE AGE CONTAINERS IMAGES SELECTOR comhpc-control 1/1 1 1 15h comhpc ghcr.io/autowarefoundation/autoware-universe:galactic-20220728-prebuilt-cuda io.kompose.service=comhpc comhpc-api 1/1 1 1 15h comhpc ghcr.io/autowarefoundation/autoware-universe:galactic-20220728-prebuilt-cuda io.kompose.service=comhpc comhpc-planning 1/1 1 1 15h comhpc ghcr.io/autowarefoundation/autoware-universe:galactic-20220728-prebuilt-cuda io.kompose.service=comhpc comhpc-simulator 1/1 1 1 15h comhpc ghcr.io/autowarefoundation/autoware-universe:galactic-20220728-prebuilt-cuda io.kompose.service=comhpc comhpc-map 1/1 1 1 15h comhpc ghcr.io/autowarefoundation/autoware-universe:galactic-20220728-prebuilt-cuda io.kompose.service=comhpc comhpc-system 1/1 1 1 17h comhpc ghcr.io/autowarefoundation/autoware-universe:galactic-20220728-prebuilt-cuda io.kompose.service=comhpc comhpc-vehicle 1/1 1 1 17h comhpc ghcr.io/autowarefoundation/autoware-universe:galactic-20220728-prebuilt-cuda io.kompose.service=comhpc Please make sure all pods are running. root@comhpc:~# kubectl get pod -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES comhpc-control-58cb5b9dbd-fqckv 1/1 Running 0 104m 192.168.10.27 ava comhpc-api-7b588f7988-n4rb7 1/1 Running 0 103m 192.168.10.27 ava comhpc-planning-d964b9646-92rzc 1/1 Running 0 104m 192.168.10.27 ava comhpc-simulator-7f5b9fb97d-7kvqm 1/1 Running 0 104m 192.168.10.27 ava comhpc-map-7867476c98-mgrm5 1/1 Running 0 103m 192.168.10.27 ava comhpc-system-c5599d5b-xxhg2 1/1 Running 0 103m 192.168.10.27 ava comhpc-vehicle-9d6b5b9b8-k95q9 1/1 Running 0 103m 192.168.10.27 ava 2. Run Autoware on the in-vehicle development platform # If you do NOT need a vehicle-edge platform, please skip this step. TODO 3. Run simulators on the development platform # Please refer to the How to run simulators section. 4. Run centerpoint object detection simultaneously on the development platform # Please refer to the tutorial This is optional if you do NOT need a vehicle-edge platform. \u21a9","title":"How to run Autoware"},{"location":"version-2.0/start-guide/how-to-run-autoware/#how-to-run-autoware","text":"This page explains how to run Autoware on the development platform that are set up in the Installation chapter .","title":"How to run Autoware"},{"location":"version-2.0/start-guide/how-to-run-autoware/#minimum-requirements","text":"Developer Platform: TODO In-Vehicle Development Platform 1 : TODO Software Tool: TODO Container Image: TODO","title":"Minimum requirements"},{"location":"version-2.0/start-guide/how-to-run-autoware/#1-run-autoware-on-the-developer-platform","text":"","title":"1. Run Autoware on the developer platform"},{"location":"version-2.0/start-guide/how-to-run-autoware/#run-autowareauto-on-ava-platform-or-pcu-or-xavier","text":"Access AVA platform or PCU or Xavier via SSH. Deploy kubernetes clusters for Autoware. kubectl apply -f comhpc-deployments You can make sure deployments are deployed. root@comhpc:~# kubectl get deploy -o wide NAME READY UP-TO-DATE AVAILABLE AGE CONTAINERS IMAGES SELECTOR comhpc-control 1/1 1 1 15h comhpc ghcr.io/autowarefoundation/autoware-universe:galactic-20220728-prebuilt-cuda io.kompose.service=comhpc comhpc-api 1/1 1 1 15h comhpc ghcr.io/autowarefoundation/autoware-universe:galactic-20220728-prebuilt-cuda io.kompose.service=comhpc comhpc-planning 1/1 1 1 15h comhpc ghcr.io/autowarefoundation/autoware-universe:galactic-20220728-prebuilt-cuda io.kompose.service=comhpc comhpc-simulator 1/1 1 1 15h comhpc ghcr.io/autowarefoundation/autoware-universe:galactic-20220728-prebuilt-cuda io.kompose.service=comhpc comhpc-map 1/1 1 1 15h comhpc ghcr.io/autowarefoundation/autoware-universe:galactic-20220728-prebuilt-cuda io.kompose.service=comhpc comhpc-system 1/1 1 1 17h comhpc ghcr.io/autowarefoundation/autoware-universe:galactic-20220728-prebuilt-cuda io.kompose.service=comhpc comhpc-vehicle 1/1 1 1 17h comhpc ghcr.io/autowarefoundation/autoware-universe:galactic-20220728-prebuilt-cuda io.kompose.service=comhpc Please make sure all pods are running. root@comhpc:~# kubectl get pod -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES comhpc-control-58cb5b9dbd-fqckv 1/1 Running 0 104m 192.168.10.27 ava comhpc-api-7b588f7988-n4rb7 1/1 Running 0 103m 192.168.10.27 ava comhpc-planning-d964b9646-92rzc 1/1 Running 0 104m 192.168.10.27 ava comhpc-simulator-7f5b9fb97d-7kvqm 1/1 Running 0 104m 192.168.10.27 ava comhpc-map-7867476c98-mgrm5 1/1 Running 0 103m 192.168.10.27 ava comhpc-system-c5599d5b-xxhg2 1/1 Running 0 103m 192.168.10.27 ava comhpc-vehicle-9d6b5b9b8-k95q9 1/1 Running 0 103m 192.168.10.27 ava ","title":"Run Autoware.Auto on AVA platform or PCU or Xavier"},{"location":"version-2.0/start-guide/how-to-run-autoware/#2-run-autoware-on-the-in-vehicle-development-platform","text":"If you do NOT need a vehicle-edge platform, please skip this step. TODO","title":"2. Run Autoware on the in-vehicle development platform"},{"location":"version-2.0/start-guide/how-to-run-autoware/#3-run-simulators-on-the-development-platform","text":"Please refer to the How to run simulators section.","title":"3. Run simulators on the development platform"},{"location":"version-2.0/start-guide/how-to-run-autoware/#4-run-centerpoint-object-detection-simultaneously-on-the-development-platform","text":"Please refer to the tutorial This is optional if you do NOT need a vehicle-edge platform. \u21a9","title":"4. Run centerpoint object detection simultaneously on the development platform"},{"location":"version-2.0/start-guide/how-to-run-simulators/","text":"How to run simulators # This page describes how to run simulators that work on your local environment and the cloud environment. Scenario simulator verifies your planning algorithms. Logging simulator verifies your perception algorithms with ROSBAG data that are recorded beforehand. Troubleshooting Limitations and issues","title":"How to run simulators"},{"location":"version-2.0/start-guide/how-to-run-simulators/#how-to-run-simulators","text":"This page describes how to run simulators that work on your local environment and the cloud environment. Scenario simulator verifies your planning algorithms. Logging simulator verifies your perception algorithms with ROSBAG data that are recorded beforehand. Troubleshooting Limitations and issues","title":"How to run simulators"},{"location":"version-2.0/start-guide/how-to-run-simulators/limitations-and-issues/limitations-and-issues/","text":"Limitations and issues # Limitations # Issues #","title":"Limitations and issues"},{"location":"version-2.0/start-guide/how-to-run-simulators/limitations-and-issues/limitations-and-issues/#limitations-and-issues","text":"","title":"Limitations and issues"},{"location":"version-2.0/start-guide/how-to-run-simulators/limitations-and-issues/limitations-and-issues/#limitations","text":"","title":"Limitations"},{"location":"version-2.0/start-guide/how-to-run-simulators/limitations-and-issues/limitations-and-issues/#issues","text":"","title":"Issues"},{"location":"version-2.0/start-guide/how-to-run-simulators/logging-simulator/run-on-cloud-env/","text":"Run on the cloud platform # This page describes how to run the logging simulator on the cloud platform. The cloud platform, Web.Auto, is offered by TIER IV , and it is available for the Autoware Foundation members. Minimum requirements # Developer Platform: TODO In-Vehicle Development Platform 1 : TODO Software Tool: TODO Container Image: TODO Data Pipeline: TODO 1. Create your account on the cloud platform # If you already have access to Web.Auto, please skip this step. TODO 2. Set up a simulation on the cloud platform # TODO 3. Run the logging simulator on the cloud platform # TODO This is optional if you do NOT need a vehicle-edge platform. \u21a9","title":"Run on the cloud platform"},{"location":"version-2.0/start-guide/how-to-run-simulators/logging-simulator/run-on-cloud-env/#run-on-the-cloud-platform","text":"This page describes how to run the logging simulator on the cloud platform. The cloud platform, Web.Auto, is offered by TIER IV , and it is available for the Autoware Foundation members.","title":"Run on the cloud platform"},{"location":"version-2.0/start-guide/how-to-run-simulators/logging-simulator/run-on-cloud-env/#minimum-requirements","text":"Developer Platform: TODO In-Vehicle Development Platform 1 : TODO Software Tool: TODO Container Image: TODO Data Pipeline: TODO","title":"Minimum requirements"},{"location":"version-2.0/start-guide/how-to-run-simulators/logging-simulator/run-on-cloud-env/#1-create-your-account-on-the-cloud-platform","text":"If you already have access to Web.Auto, please skip this step. TODO","title":"1. Create your account on the cloud platform"},{"location":"version-2.0/start-guide/how-to-run-simulators/logging-simulator/run-on-cloud-env/#2-set-up-a-simulation-on-the-cloud-platform","text":"TODO","title":"2. Set up a simulation on the cloud platform"},{"location":"version-2.0/start-guide/how-to-run-simulators/logging-simulator/run-on-cloud-env/#3-run-the-logging-simulator-on-the-cloud-platform","text":"TODO This is optional if you do NOT need a vehicle-edge platform. \u21a9","title":"3. Run the logging simulator on the cloud platform"},{"location":"version-2.0/start-guide/how-to-run-simulators/scenario-simulator/run-on-cloud-env/","text":"Run on the cloud platform # This page describes how to run the scenario simulator on the cloud platform. The cloud platform, Web.Auto, is offered by TIER IV , and it is available for the Autoware Foundation members. Minimum requirements # Developer Platform: TODO In-Vehicle Development Platform 1 : TODO Software Tool: TODO Container Image: TODO Data Pipeline: TODO 1. Create your account on the cloud platform # If you already have access to Web.Auto, please skip this step. Cloud Native CI/CD Pipeline - Web.Auto # The CI/CD pipeline for the scenario simulation is available for the Autoware Foundation members. You can check the scenario simulation results on the CI/CD dashboard. This material describes the CI/CD pipeline in more details. Create an account with Tier IV account server ( https://account.tier4.jp/ ). Participate in an Autoware Foundation working group (Simulation, Autonomy Software, Operational Design DomainD, Open AD Kit) and report the Tier IV Account ID you created in 1. to the leader of your working group. Then you can login to the CI/CD dashboard and see the scenario simulation results. 2. Set up a simulation on the cloud platform # TODO 3. Run the scenario simulator on the cloud platform # TODO This is optional if you do NOT need a vehicle-edge platform. \u21a9","title":"Run on the cloud platform"},{"location":"version-2.0/start-guide/how-to-run-simulators/scenario-simulator/run-on-cloud-env/#run-on-the-cloud-platform","text":"This page describes how to run the scenario simulator on the cloud platform. The cloud platform, Web.Auto, is offered by TIER IV , and it is available for the Autoware Foundation members.","title":"Run on the cloud platform"},{"location":"version-2.0/start-guide/how-to-run-simulators/scenario-simulator/run-on-cloud-env/#minimum-requirements","text":"Developer Platform: TODO In-Vehicle Development Platform 1 : TODO Software Tool: TODO Container Image: TODO Data Pipeline: TODO","title":"Minimum requirements"},{"location":"version-2.0/start-guide/how-to-run-simulators/scenario-simulator/run-on-cloud-env/#1-create-your-account-on-the-cloud-platform","text":"If you already have access to Web.Auto, please skip this step.","title":"1. Create your account on the cloud platform"},{"location":"version-2.0/start-guide/how-to-run-simulators/scenario-simulator/run-on-cloud-env/#2-set-up-a-simulation-on-the-cloud-platform","text":"TODO","title":"2. Set up a simulation on the cloud platform"},{"location":"version-2.0/start-guide/how-to-run-simulators/scenario-simulator/run-on-cloud-env/#3-run-the-scenario-simulator-on-the-cloud-platform","text":"TODO This is optional if you do NOT need a vehicle-edge platform. \u21a9","title":"3. Run the scenario simulator on the cloud platform"},{"location":"version-2.0/start-guide/how-to-run-simulators/scenario-simulator/run-on-local-env/","text":"Run on your local environment # This page describes how to run the scenario simulator on the developer platform that is set up in the Installation chapter. Minimum requirements # Developer Platform: TODO In-Vehicle Development Platform 1 : TODO Software Tool: TODO Container Image: TODO Data Pipeline: TODO Run scenario simulator on the developer platform # Launch scenario simulator. rocker --x11 --home --network host --privileged ghcr.io/tier4/scenario_simulator_v2:galactic ros2 launch scenario_test_runner scenario_test_runner.launch.py scenario:=$HOME/Downloads/sample_data/t4v2.yaml architecture_type:=awf/universe launch_rviz:=true launch_autoware:=false record:=false timeout:=60.0 Please specify the path to your scenario file. scenario:=$ HOME/Downloads/sample_data/t4v2.yaml Now you can see... DEMO Video This is optional if you do NOT need a vehicle-edge platform. \u21a9","title":"Run on your local environment"},{"location":"version-2.0/start-guide/how-to-run-simulators/scenario-simulator/run-on-local-env/#run-on-your-local-environment","text":"This page describes how to run the scenario simulator on the developer platform that is set up in the Installation chapter.","title":"Run on your local environment"},{"location":"version-2.0/start-guide/how-to-run-simulators/scenario-simulator/run-on-local-env/#minimum-requirements","text":"Developer Platform: TODO In-Vehicle Development Platform 1 : TODO Software Tool: TODO Container Image: TODO Data Pipeline: TODO","title":"Minimum requirements"},{"location":"version-2.0/start-guide/how-to-run-simulators/scenario-simulator/run-on-local-env/#run-scenario-simulator-on-the-developer-platform","text":"Launch scenario simulator. rocker --x11 --home --network host --privileged ghcr.io/tier4/scenario_simulator_v2:galactic ros2 launch scenario_test_runner scenario_test_runner.launch.py scenario:=$HOME/Downloads/sample_data/t4v2.yaml architecture_type:=awf/universe launch_rviz:=true launch_autoware:=false record:=false timeout:=60.0 Please specify the path to your scenario file. scenario:=$ HOME/Downloads/sample_data/t4v2.yaml Now you can see... DEMO Video This is optional if you do NOT need a vehicle-edge platform. \u21a9","title":"Run scenario simulator on the developer platform"},{"location":"version-2.0/start-guide/how-to-run-simulators/troubleshooting/troubleshooting/","text":"Troubleshooting # Scenario simulator stacks with Simulator waiting for Autoware state to be Initializing # Workaround # Please restart kubernetes pods on the AVA Platform using the kubectl get deploy --output name | grep comhpc | xargs -n1 kubectl rollout restart","title":"Troubleshooting"},{"location":"version-2.0/start-guide/how-to-run-simulators/troubleshooting/troubleshooting/#troubleshooting","text":"","title":"Troubleshooting"},{"location":"version-2.0/start-guide/how-to-run-simulators/troubleshooting/troubleshooting/#scenario-simulator-stacks-with-simulator-waiting-for-autoware-state-to-be-initializing","text":"","title":"Scenario simulator stacks with Simulator waiting for Autoware state to be Initializing"},{"location":"version-2.0/start-guide/how-to-run-simulators/troubleshooting/troubleshooting/#workaround","text":"Please restart kubernetes pods on the AVA Platform using the kubectl get deploy --output name | grep comhpc | xargs -n1 kubectl rollout restart","title":"Workaround"},{"location":"version-2.0/start-guide/installation/","text":"Installation # This page explains how to set up the development environment that are described in the System Configuration chapter. The following contents are diverted from Open AD Kit version 1.0 . These contents will be updated for Open AD Kit version 2.0. Minimum requirements # Developer Platform: AVA Platform or PCU Platform or Xavier Platform In-Vehicle Development Platform 1 : TODO Software Tool: Scenario simulator version 0.6.5+ 2 Rviz version 8.5.1 2 Container Image: Autoware.Universe for arm64 Scenario simulator for x86_64 2 The following diagram shows a minimum configuration of Open AD Kit. \"Your host machine\" will be replaced by the cloud development platform if you can use Web.Auto. 1. Set up the developer platform # The setup procedure depends on the developer platform. AVA Platform # Getting started with EWAOL Boot EWAOL Extend rootfs partition PCU Platform # Getting started with PCU Xavier Platform # Getting started with Xavier 2. Set up the in-vehicle platform # If you do NOT need a vehicle-edge platform, please skip this step. TODO 3. Install Autoware container images on the developer platform # AVA Platform # System setup on AVA Platform PCU Platform # System setup on PCU Xavier Platform # System setup on Xavier Platform 4. Install Autoware container images on the in-vehicle platform # If you do NOT need a vehicle-edge platform, please skip this step. TODO 5. Set up software tools # If you can use the cloud development platform, please skip this step. AVA Platform # System setup on your host PCU Platform # System setup on your host Xavier Platform # System setup on your host 6. Run Autoware on the development platform # Please refer to the How to run Autoware section. 7. Advanced setup # The instructions how to install advanced software such as desktop environment and NVIDIA driver. AVA Platform # Advanced setup for AVA Platform This is unnecessary if you do NOT need a vehicle-edge platform. \u21a9 This is unnecessary if you can use the cloud development platform, Web.Auto. \u21a9 \u21a9 \u21a9","title":"Installation"},{"location":"version-2.0/start-guide/installation/#installation","text":"This page explains how to set up the development environment that are described in the System Configuration chapter. The following contents are diverted from Open AD Kit version 1.0 . These contents will be updated for Open AD Kit version 2.0.","title":"Installation"},{"location":"version-2.0/start-guide/installation/#minimum-requirements","text":"Developer Platform: AVA Platform or PCU Platform or Xavier Platform In-Vehicle Development Platform 1 : TODO Software Tool: Scenario simulator version 0.6.5+ 2 Rviz version 8.5.1 2 Container Image: Autoware.Universe for arm64 Scenario simulator for x86_64 2 The following diagram shows a minimum configuration of Open AD Kit. \"Your host machine\" will be replaced by the cloud development platform if you can use Web.Auto.","title":"Minimum requirements"},{"location":"version-2.0/start-guide/installation/#1-set-up-the-developer-platform","text":"The setup procedure depends on the developer platform.","title":"1. Set up the developer platform"},{"location":"version-2.0/start-guide/installation/#ava-platform","text":"Getting started with EWAOL Boot EWAOL Extend rootfs partition","title":"AVA Platform"},{"location":"version-2.0/start-guide/installation/#pcu-platform","text":"Getting started with PCU","title":"PCU Platform"},{"location":"version-2.0/start-guide/installation/#xavier-platform","text":"Getting started with Xavier","title":"Xavier Platform"},{"location":"version-2.0/start-guide/installation/#2-set-up-the-in-vehicle-platform","text":"If you do NOT need a vehicle-edge platform, please skip this step. TODO","title":"2. Set up the in-vehicle platform"},{"location":"version-2.0/start-guide/installation/#3-install-autoware-container-images-on-the-developer-platform","text":"","title":"3. Install Autoware container images on the developer platform"},{"location":"version-2.0/start-guide/installation/#ava-platform_1","text":"System setup on AVA Platform","title":"AVA Platform"},{"location":"version-2.0/start-guide/installation/#pcu-platform_1","text":"System setup on PCU","title":"PCU Platform"},{"location":"version-2.0/start-guide/installation/#xavier-platform_1","text":"System setup on Xavier Platform","title":"Xavier Platform"},{"location":"version-2.0/start-guide/installation/#4-install-autoware-container-images-on-the-in-vehicle-platform","text":"If you do NOT need a vehicle-edge platform, please skip this step. TODO","title":"4. Install Autoware container images on the in-vehicle platform"},{"location":"version-2.0/start-guide/installation/#5-set-up-software-tools","text":"If you can use the cloud development platform, please skip this step.","title":"5. Set up software tools"},{"location":"version-2.0/start-guide/installation/#ava-platform_2","text":"System setup on your host","title":"AVA Platform"},{"location":"version-2.0/start-guide/installation/#pcu-platform_2","text":"System setup on your host","title":"PCU Platform"},{"location":"version-2.0/start-guide/installation/#xavier-platform_2","text":"System setup on your host","title":"Xavier Platform"},{"location":"version-2.0/start-guide/installation/#6-run-autoware-on-the-development-platform","text":"Please refer to the How to run Autoware section.","title":"6. Run Autoware on the development platform"},{"location":"version-2.0/start-guide/installation/#7-advanced-setup","text":"The instructions how to install advanced software such as desktop environment and NVIDIA driver.","title":"7. Advanced setup"},{"location":"version-2.0/start-guide/installation/#ava-platform_3","text":"Advanced setup for AVA Platform This is unnecessary if you do NOT need a vehicle-edge platform. \u21a9 This is unnecessary if you can use the cloud development platform, Web.Auto. \u21a9 \u21a9 \u21a9","title":"AVA Platform"},{"location":"version-2.0/start-guide/installation/advanced-setup-setup-ava/","text":"Advanced setup for AVA Platform # Overview # This instruction explains how to install advanced software for AVA platform. Desktop environment(XFCE) NVIDIA driver NVIDIA Container Toolkit Checkout the repository for AVA platform # m5p3nc3r / meta-ewaol-machine git clone git@github.com:m5p3nc3r/meta-ewaol-machine.git -b kirkstone-dev Copy meta-ewaol-ext directory to the project root. cp -rf meta-ewaol-machine/meta-ewaol-ext ~/meta-adlink-ampere Download a missing patch in meta-ewaol-ext layer. wget -P ~/meta-adlink-ampere/meta-ewaol-ext/recipes-ewaol/recipes-container/nvidia-container-toolkit/files https://raw.githubusercontent.com/autowarefoundation/open-ad-kit-docs/main/docs/version-2.0/start-guide/installation/patch/0002-TEMPORARY-force-aarch64-rpm.patch Modify ava.yml . header: version: 1 includes: - repo: meta-ewaol - file: meta-ewaol-config/kas/baremetal.yml + file: meta-ewaol-config/kas/baremetal-sdk.yml repos: meta-ewaol: path: meta-ewaol meta-adlink-ampere: +meta-openembedded: + path: layers/meta-openembedded + layers: + meta-oe: + meta-gnome: + meta-multimedia: + meta-xfce: + +meta-ewaol-ext: + path: meta-ewaol-ext machine: ava bblayers_conf_header: base: | POKY_BBLAYERS_CONF_VERSION = \"2\" BBPATH = \"${TOPDIR}\" BBFILES ?= \"\" +local_conf_header: +meta-at: | + XSERVER:append = \" xserver-xorg-extension-glx xserver-xorg-module-libwfb xserver-xorg-module-exa\" + IMAGE_INSTALL:append = \" packagegroup-core-x11 packagegroup-xfce-extended acpid xf86-video-modesetting mesa-demos nvidia-container-toolkit\" + DISTRO_FEATURES:append = \" opengl x11 glx\" + PACKAGECONFIG:append:pn-xserver-xorg = \" xinerama\" + IMAGE_FEATURES:append =\" x11 x11-base\" + INSANE_SKIP:${PN}:append = \" already-stripped\" + FILES:${PN}:append =\" /usr/share/containers/oci/hooks.d/oci-nvidia-hook.json\" target: -- ewaol-baremetal-image +- ewaol-baremetal-sdk-image Build via kas. kas build ava.yml Flash yocto image # For example; sudo bmaptool copy --bmap build/tmp_baremetal/deploy/images/ava/ewaol-baremetal-sdk-image-ava.wic.bmap build/tmp_baremetal/deploy/images/ava/ewaol-baremetal-sdk-image-ava.wic.gz /dev/sdb Extend rootfs partition # Follow the instructions Extend rootfs partition . Boot your machine # You can see XFCE desktop. NVIDIA driver installation # Create the files required for compiling external modules. cd /usr/src/kernel make modules_prepare Check NVIDIA graphics card. lspci | grep -i nvidia You can find a NVIDIA graphics card such as GeForce RTX 3070 Ti . 000d:01:00.0 VGA compatible controller: NVIDIA Corporation GA104 [GeForce RTX 3070 Ti] (rev a1) 000d:01:00.1 Audio device: NVIDIA Corporation GA104 High Definition Audio Controller (rev a1) Open the URL in browser. Official Drivers NVIDIA Select your graphics card, then click SEARCH . Click DOWNLOAD . Copy link to the file. Download NVIDIA driver on AVA platform. For example; wget https://jp.download.nvidia.com/XFree86/aarch64/515.65.01/NVIDIA-Linux-aarch64-515.65.01.run chmod +x NVIDIA-Linux-aarch64-515.65.01.run Stop display manager to install NVIDIA driver. systemctl stop xserver-nodm Install NVIDIA driver. For example; ./NVIDIA-Linux-aarch64-515.65.01.run Building kernel module starts. Press to select Yes and then press . Press . Change display output from motherboard to GPU # You are using VGA, so switch to GPU . Turn off AVA platform Connect HDMI or Display Port from your graphics card to your monitor. Change display mode to HDMI or Display Port on your monitor if needed. Turn on AVA platform, then the desktop window will be shown via GPU . Confirm nvidia-docker works (Optional) # You can confirm nvidia-docker works by the following command. docker run --gpus all --rm nvidia/cuda-arm64:11.4.0-base nvidia-smi You can see the outputs like below. root@ava:~# docker run --gpus all --rm nvidia/cuda-arm64:11.4.0-base nvidia-smi Unable to find image 'nvidia/cuda-arm64:11.4.0-base' locally 11.4.0-base: Pulling from nvidia/cuda-arm64 55c604a74c4b: Pull complete 657fae4b9575: Pull complete b2cf3c1bfea9: Pull complete 71492f856142: Pull complete c74b3fce51ac: Pull complete Digest: sha256:625c8265d0f88d4250d48958113f1184f96db794fbe5d6d5cdd782f9916ec718 Status: Downloaded newer image for nvidia/cuda-arm64:11.4.0-base Thu Aug 25 23:17:40 2022 +-----------------------------------------------------------------------------+ | NVIDIA-SMI 515.65.01 Driver Version: 515.65.01 CUDA Version: 11.7 | |-------------------------------+----------------------+----------------------+ | GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC | | Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. | | | | MIG M. | |===============================+======================+======================| | 0 NVIDIA GeForce ... Off | 0000000D:01:00.0 On | N/A | | 0% 35C P8 18W / 290W | 234MiB / 8192MiB | 0% Default | | | | N/A | +-------------------------------+----------------------+----------------------+ +-----------------------------------------------------------------------------+ | Processes: | | GPU GI CI PID Type Process name GPU Memory | | ID ID Usage | |=============================================================================| +-----------------------------------------------------------------------------+","title":"Advanced setup for AVA Platform"},{"location":"version-2.0/start-guide/installation/advanced-setup-setup-ava/#advanced-setup-for-ava-platform","text":"","title":"Advanced setup for AVA Platform"},{"location":"version-2.0/start-guide/installation/advanced-setup-setup-ava/#overview","text":"This instruction explains how to install advanced software for AVA platform. Desktop environment(XFCE) NVIDIA driver NVIDIA Container Toolkit","title":"Overview"},{"location":"version-2.0/start-guide/installation/advanced-setup-setup-ava/#checkout-the-repository-for-ava-platform","text":"m5p3nc3r / meta-ewaol-machine git clone git@github.com:m5p3nc3r/meta-ewaol-machine.git -b kirkstone-dev Copy meta-ewaol-ext directory to the project root. cp -rf meta-ewaol-machine/meta-ewaol-ext ~/meta-adlink-ampere Download a missing patch in meta-ewaol-ext layer. wget -P ~/meta-adlink-ampere/meta-ewaol-ext/recipes-ewaol/recipes-container/nvidia-container-toolkit/files https://raw.githubusercontent.com/autowarefoundation/open-ad-kit-docs/main/docs/version-2.0/start-guide/installation/patch/0002-TEMPORARY-force-aarch64-rpm.patch Modify ava.yml . header: version: 1 includes: - repo: meta-ewaol - file: meta-ewaol-config/kas/baremetal.yml + file: meta-ewaol-config/kas/baremetal-sdk.yml repos: meta-ewaol: path: meta-ewaol meta-adlink-ampere: +meta-openembedded: + path: layers/meta-openembedded + layers: + meta-oe: + meta-gnome: + meta-multimedia: + meta-xfce: + +meta-ewaol-ext: + path: meta-ewaol-ext machine: ava bblayers_conf_header: base: | POKY_BBLAYERS_CONF_VERSION = \"2\" BBPATH = \"${TOPDIR}\" BBFILES ?= \"\" +local_conf_header: +meta-at: | + XSERVER:append = \" xserver-xorg-extension-glx xserver-xorg-module-libwfb xserver-xorg-module-exa\" + IMAGE_INSTALL:append = \" packagegroup-core-x11 packagegroup-xfce-extended acpid xf86-video-modesetting mesa-demos nvidia-container-toolkit\" + DISTRO_FEATURES:append = \" opengl x11 glx\" + PACKAGECONFIG:append:pn-xserver-xorg = \" xinerama\" + IMAGE_FEATURES:append =\" x11 x11-base\" + INSANE_SKIP:${PN}:append = \" already-stripped\" + FILES:${PN}:append =\" /usr/share/containers/oci/hooks.d/oci-nvidia-hook.json\" target: -- ewaol-baremetal-image +- ewaol-baremetal-sdk-image Build via kas. kas build ava.yml","title":"Checkout the repository for AVA platform"},{"location":"version-2.0/start-guide/installation/advanced-setup-setup-ava/#flash-yocto-image","text":"For example; sudo bmaptool copy --bmap build/tmp_baremetal/deploy/images/ava/ewaol-baremetal-sdk-image-ava.wic.bmap build/tmp_baremetal/deploy/images/ava/ewaol-baremetal-sdk-image-ava.wic.gz /dev/sdb","title":"Flash yocto image"},{"location":"version-2.0/start-guide/installation/advanced-setup-setup-ava/#extend-rootfs-partition","text":"Follow the instructions Extend rootfs partition .","title":"Extend rootfs partition"},{"location":"version-2.0/start-guide/installation/advanced-setup-setup-ava/#boot-your-machine","text":"You can see XFCE desktop.","title":"Boot your machine"},{"location":"version-2.0/start-guide/installation/advanced-setup-setup-ava/#nvidia-driver-installation","text":"Create the files required for compiling external modules. cd /usr/src/kernel make modules_prepare Check NVIDIA graphics card. lspci | grep -i nvidia You can find a NVIDIA graphics card such as GeForce RTX 3070 Ti . 000d:01:00.0 VGA compatible controller: NVIDIA Corporation GA104 [GeForce RTX 3070 Ti] (rev a1) 000d:01:00.1 Audio device: NVIDIA Corporation GA104 High Definition Audio Controller (rev a1) Open the URL in browser. Official Drivers NVIDIA Select your graphics card, then click SEARCH . Click DOWNLOAD . Copy link to the file. Download NVIDIA driver on AVA platform. For example; wget https://jp.download.nvidia.com/XFree86/aarch64/515.65.01/NVIDIA-Linux-aarch64-515.65.01.run chmod +x NVIDIA-Linux-aarch64-515.65.01.run Stop display manager to install NVIDIA driver. systemctl stop xserver-nodm Install NVIDIA driver. For example; ./NVIDIA-Linux-aarch64-515.65.01.run Building kernel module starts. Press to select Yes and then press . Press .","title":"NVIDIA driver installation"},{"location":"version-2.0/start-guide/installation/advanced-setup-setup-ava/#change-display-output-from-motherboard-to-gpu","text":"You are using VGA, so switch to GPU . Turn off AVA platform Connect HDMI or Display Port from your graphics card to your monitor. Change display mode to HDMI or Display Port on your monitor if needed. Turn on AVA platform, then the desktop window will be shown via GPU .","title":"Change display output from motherboard to GPU"},{"location":"version-2.0/start-guide/installation/advanced-setup-setup-ava/#confirm-nvidia-docker-works-optional","text":"You can confirm nvidia-docker works by the following command. docker run --gpus all --rm nvidia/cuda-arm64:11.4.0-base nvidia-smi You can see the outputs like below. root@ava:~# docker run --gpus all --rm nvidia/cuda-arm64:11.4.0-base nvidia-smi Unable to find image 'nvidia/cuda-arm64:11.4.0-base' locally 11.4.0-base: Pulling from nvidia/cuda-arm64 55c604a74c4b: Pull complete 657fae4b9575: Pull complete b2cf3c1bfea9: Pull complete 71492f856142: Pull complete c74b3fce51ac: Pull complete Digest: sha256:625c8265d0f88d4250d48958113f1184f96db794fbe5d6d5cdd782f9916ec718 Status: Downloaded newer image for nvidia/cuda-arm64:11.4.0-base Thu Aug 25 23:17:40 2022 +-----------------------------------------------------------------------------+ | NVIDIA-SMI 515.65.01 Driver Version: 515.65.01 CUDA Version: 11.7 | |-------------------------------+----------------------+----------------------+ | GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC | | Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. | | | | MIG M. | |===============================+======================+======================| | 0 NVIDIA GeForce ... Off | 0000000D:01:00.0 On | N/A | | 0% 35C P8 18W / 290W | 234MiB / 8192MiB | 0% Default | | | | N/A | +-------------------------------+----------------------+----------------------+ +-----------------------------------------------------------------------------+ | Processes: | | GPU GI CI PID Type Process name GPU Memory | | ID ID Usage | |=============================================================================| +-----------------------------------------------------------------------------+","title":"Confirm nvidia-docker works (Optional)"},{"location":"version-2.0/start-guide/installation/boot-ewaol/","text":"Boot EWAOL # Overview # You need to use SSD enclosure case to flash yocto image to M.2 SSD directly. Flash yocto image # Remove M.2 SSD from AVA platform and flash yocto image to it directly. Remove M.2 SSD from AVA platform. Install M.2 SSD into a M.2 enclosure case. Plug it into your host machine. Then, show available block devices. lsblk -p NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT ... /dev/sdb 8:0 0 119.2G 0 disk \u251c\u2500sdb1 8:1 0 512M 0 part \u251c\u2500sdb2 8:2 0 1G 0 part /media/foo/7d00c690-db24-462d-8c8d-dce7bdf151d8 \u2514\u2500sdb3 8:3 0 117.8G 0 part Flush yocto image to M.2 SSD. For example sudo bmaptool copy --bmap build/tmp_baremetal/deploy/images/ava/ewaol-baremetal-image-ava.wic.bmap build/tmp_baremetal/deploy/images/ava/ewaol-baremetal-image-ava.wic.gz /dev/sdb Extend rootfs partition # You have to extend rootfs partition. Follow the instructions Extend rootfs partition Reinstall SSD # Remove M.2 SSD from enclosure case and install it into AVA platform, then turn it on. The following screen comes up, then login as root without password. EWAOL (Edge Workload Abstraction and Orchestration Layer) v1.0 ava - ava login: You are able to access via SSH.","title":"Boot EWAOL"},{"location":"version-2.0/start-guide/installation/boot-ewaol/#boot-ewaol","text":"","title":"Boot EWAOL"},{"location":"version-2.0/start-guide/installation/boot-ewaol/#overview","text":"You need to use SSD enclosure case to flash yocto image to M.2 SSD directly.","title":"Overview"},{"location":"version-2.0/start-guide/installation/boot-ewaol/#flash-yocto-image","text":"Remove M.2 SSD from AVA platform and flash yocto image to it directly. Remove M.2 SSD from AVA platform. Install M.2 SSD into a M.2 enclosure case. Plug it into your host machine. Then, show available block devices. lsblk -p NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT ... /dev/sdb 8:0 0 119.2G 0 disk \u251c\u2500sdb1 8:1 0 512M 0 part \u251c\u2500sdb2 8:2 0 1G 0 part /media/foo/7d00c690-db24-462d-8c8d-dce7bdf151d8 \u2514\u2500sdb3 8:3 0 117.8G 0 part Flush yocto image to M.2 SSD. For example sudo bmaptool copy --bmap build/tmp_baremetal/deploy/images/ava/ewaol-baremetal-image-ava.wic.bmap build/tmp_baremetal/deploy/images/ava/ewaol-baremetal-image-ava.wic.gz /dev/sdb","title":"Flash yocto image"},{"location":"version-2.0/start-guide/installation/boot-ewaol/#extend-rootfs-partition","text":"You have to extend rootfs partition. Follow the instructions Extend rootfs partition","title":"Extend rootfs partition"},{"location":"version-2.0/start-guide/installation/boot-ewaol/#reinstall-ssd","text":"Remove M.2 SSD from enclosure case and install it into AVA platform, then turn it on. The following screen comes up, then login as root without password. EWAOL (Edge Workload Abstraction and Orchestration Layer) v1.0 ava - ava login: You are able to access via SSH.","title":"Reinstall SSD"},{"location":"version-2.0/start-guide/installation/extend-rootfs/","text":"Extend rootfs partition # Overview # The rootfs partition is not fully occupied on M.2 SSD, and the size is too short to run k3s clusters. So we have to extend rootfs partition. Here is the instruction how to extend rootfs partition Extend rootfs # Run gparted . You may get the following warning when you run gparted . Press Fix . Contents of storage after we flashed yocto image to M.2 SSD. Extend rootfs partition to the end of disk. Right click root partition, then click Resize/Move . Extend the square to the right end. Then, click Resize/Move . Apply changes. Click check mark icon. Click Apply . Click Close . You can get rootfs as follows.","title":"Extend rootfs partition"},{"location":"version-2.0/start-guide/installation/extend-rootfs/#extend-rootfs-partition","text":"","title":"Extend rootfs partition"},{"location":"version-2.0/start-guide/installation/extend-rootfs/#overview","text":"The rootfs partition is not fully occupied on M.2 SSD, and the size is too short to run k3s clusters. So we have to extend rootfs partition. Here is the instruction how to extend rootfs partition","title":"Overview"},{"location":"version-2.0/start-guide/installation/extend-rootfs/#extend-rootfs","text":"Run gparted . You may get the following warning when you run gparted . Press Fix . Contents of storage after we flashed yocto image to M.2 SSD. Extend rootfs partition to the end of disk. Right click root partition, then click Resize/Move . Extend the square to the right end. Then, click Resize/Move . Apply changes. Click check mark icon. Click Apply . Click Close . You can get rootfs as follows.","title":"Extend rootfs"},{"location":"version-2.0/start-guide/installation/getting-started-pcu/","text":"Getting started with PCU # Overview # Reference: PCU Setup Guide This instruction explains how to boot up Ubuntu on PCU and access it from host PC. If you are using onboard 64G EMMC as boot device, it's already been pre-installed with Ubuntu 20.04, and you can skip this step; If you would like to boot from SD card, you could either request a Micro SD card with pre-installed system or flash by yourself under instructions in below section. Ubuntu 20.04 is preferred. Hardware Setup # The minimum recommended External Micro SD card size is 64GB, and the speed should be at least class 10 A1, it is strongly recommended to use high speed SD card, e.g. class U3, A2. To boot from SD card, \"SW1\" should be set as: ON , and SD card should be plugged in. For blank SD card, the system image need to be flashed first using another PC. Get MPU image # Official images with recommended OS are available on PCU Resource Download page. Resource Download Page For PCU 2.0 hardware, please download the MPU image file for SD card as marked red to your local storage. Flash MPU image # To flash MPU image on SD card, you will need a PC with a micro SD card reader. This step could be done on either Windows or Linux PC with different flash tools. Linux will be used in this instruction as example: Insert card reader with target micro SD card to host PC. Find out device name for the SD card. sudo lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT ... sda 8:0 0 238.5G 0 disk \u251c\u2500sda1 8:1 0 512M 0 part /boot/efi \u2514\u2500sda2 8:2 0 238G 0 part / sdb 8:16 0 447.1G 0 disk \u251c\u2500sdb1 8:17 0 428.4G 0 part \u251c\u2500sdb2 8:18 0 513M 0 part \u2514\u2500sdb3 8:19 0 18.2G 0 part sdc 8:32 1 14.9G 0 disk \u2514\u2500sdc1 8:33 1 14.9G 0 part /media/adlink/B4A1-62CD In this case, sdc is the device name Flash image to SD card. sudo gzip -dc YOUR-DOWNLOAD-PATH/xxx.gz |sudo dd of=/dev/YOUR-DEVICE For example; sudo gzip -dc ~/Downloads/autocore-1046-ubuntu20.04-sd-pcu2.0-sw0.5.0-20201210.gz |sudo dd of=/dev/sdc Wait patiently until the flash process finishes, this may take up to half hour. Boot up. Now you can plug in the SD card to PCU and power up. The system should be ready to work. Connect To PCU via SSH # You could connect to PCU via SSh either by ethernet or serial port. The default username, password and IP address of PCU is as below: SSH through ethernet # Cable connection Connect host PC to RJ45 2 / RJ45 3 / RJ45 4 Eth port (Blue) on PCU board with Ethernet cable (GbE, need Cat.5e or above). Configure static IP for host PC You need to manually configure static IP for PC in order to connect with PCU, as there is no DHCP server running on PCU. The static IP should be different with PCU and within the same network segment. (e.g. 192.168.1.200) SSH login ssh user@192.168.1.239 SSH through Serial Port # Cable connection As an alternative, you could also choose to connect to PCU by micro USB (ttyUSB port in figure blow). ttyUSB Settings For Linux users, you could use \"cutecom\" to connect to PCU. sudo apt install cutecom cutecom Please set parameters as follows, Device shall be chosen based on your host PC. For other system users, the parameters are: Parameter Value Baudrate 115200 Data 8 Stop bit 1 Parity None Hardware flow control no Software flow control no Reset PCU and Login Press reset button and wait until login. ssh user@192.168.1.239 Check PCU public IP Address # Connect PCU to internet via RJ45 1 Eth port (Red), this Eth port is configured to obtain IP address automatically from DHCP by default. From section above, you can SSH connect to PCU, and you can look for IP address of the public ethernet port(fm1-mac5). ifconfig fm1-mac5 fm1-mac5: flags=4163 mtu 1500 inet 192.168.10.221 netmask 255.255.255.0 broadcast 192.168.10.255 inet6 fe80::204:7cff:fe2e:191 prefixlen 64 scopeid 0x20 ether 00:04:7c:2e:01:91 txqueuelen 1000 (Ethernet) RX packets 2806 bytes 3665212 (3.6 MB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 2238 bytes 175964 (175.9 KB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 device memory 0x1ae8000-1ae8fff You can find IP address of PCU such as 192.168.10.221 .","title":"Getting started with PCU"},{"location":"version-2.0/start-guide/installation/getting-started-pcu/#getting-started-with-pcu","text":"","title":"Getting started with PCU"},{"location":"version-2.0/start-guide/installation/getting-started-pcu/#overview","text":"Reference: PCU Setup Guide This instruction explains how to boot up Ubuntu on PCU and access it from host PC. If you are using onboard 64G EMMC as boot device, it's already been pre-installed with Ubuntu 20.04, and you can skip this step; If you would like to boot from SD card, you could either request a Micro SD card with pre-installed system or flash by yourself under instructions in below section. Ubuntu 20.04 is preferred.","title":"Overview"},{"location":"version-2.0/start-guide/installation/getting-started-pcu/#hardware-setup","text":"The minimum recommended External Micro SD card size is 64GB, and the speed should be at least class 10 A1, it is strongly recommended to use high speed SD card, e.g. class U3, A2. To boot from SD card, \"SW1\" should be set as: ON , and SD card should be plugged in. For blank SD card, the system image need to be flashed first using another PC.","title":"Hardware Setup"},{"location":"version-2.0/start-guide/installation/getting-started-pcu/#get-mpu-image","text":"Official images with recommended OS are available on PCU Resource Download page. Resource Download Page For PCU 2.0 hardware, please download the MPU image file for SD card as marked red to your local storage.","title":"Get MPU image"},{"location":"version-2.0/start-guide/installation/getting-started-pcu/#flash-mpu-image","text":"To flash MPU image on SD card, you will need a PC with a micro SD card reader. This step could be done on either Windows or Linux PC with different flash tools. Linux will be used in this instruction as example: Insert card reader with target micro SD card to host PC. Find out device name for the SD card. sudo lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT ... sda 8:0 0 238.5G 0 disk \u251c\u2500sda1 8:1 0 512M 0 part /boot/efi \u2514\u2500sda2 8:2 0 238G 0 part / sdb 8:16 0 447.1G 0 disk \u251c\u2500sdb1 8:17 0 428.4G 0 part \u251c\u2500sdb2 8:18 0 513M 0 part \u2514\u2500sdb3 8:19 0 18.2G 0 part sdc 8:32 1 14.9G 0 disk \u2514\u2500sdc1 8:33 1 14.9G 0 part /media/adlink/B4A1-62CD In this case, sdc is the device name Flash image to SD card. sudo gzip -dc YOUR-DOWNLOAD-PATH/xxx.gz |sudo dd of=/dev/YOUR-DEVICE For example; sudo gzip -dc ~/Downloads/autocore-1046-ubuntu20.04-sd-pcu2.0-sw0.5.0-20201210.gz |sudo dd of=/dev/sdc Wait patiently until the flash process finishes, this may take up to half hour. Boot up. Now you can plug in the SD card to PCU and power up. The system should be ready to work.","title":"Flash MPU image"},{"location":"version-2.0/start-guide/installation/getting-started-pcu/#connect-to-pcu-via-ssh","text":"You could connect to PCU via SSh either by ethernet or serial port. The default username, password and IP address of PCU is as below:","title":"Connect To PCU via SSH"},{"location":"version-2.0/start-guide/installation/getting-started-pcu/#ssh-through-ethernet","text":"Cable connection Connect host PC to RJ45 2 / RJ45 3 / RJ45 4 Eth port (Blue) on PCU board with Ethernet cable (GbE, need Cat.5e or above). Configure static IP for host PC You need to manually configure static IP for PC in order to connect with PCU, as there is no DHCP server running on PCU. The static IP should be different with PCU and within the same network segment. (e.g. 192.168.1.200) SSH login ssh user@192.168.1.239","title":"SSH through ethernet"},{"location":"version-2.0/start-guide/installation/getting-started-pcu/#ssh-through-serial-port","text":"Cable connection As an alternative, you could also choose to connect to PCU by micro USB (ttyUSB port in figure blow). ttyUSB Settings For Linux users, you could use \"cutecom\" to connect to PCU. sudo apt install cutecom cutecom Please set parameters as follows, Device shall be chosen based on your host PC. For other system users, the parameters are: Parameter Value Baudrate 115200 Data 8 Stop bit 1 Parity None Hardware flow control no Software flow control no Reset PCU and Login Press reset button and wait until login. ssh user@192.168.1.239","title":"SSH through Serial Port"},{"location":"version-2.0/start-guide/installation/getting-started-pcu/#check-pcu-public-ip-address","text":"Connect PCU to internet via RJ45 1 Eth port (Red), this Eth port is configured to obtain IP address automatically from DHCP by default. From section above, you can SSH connect to PCU, and you can look for IP address of the public ethernet port(fm1-mac5). ifconfig fm1-mac5 fm1-mac5: flags=4163 mtu 1500 inet 192.168.10.221 netmask 255.255.255.0 broadcast 192.168.10.255 inet6 fe80::204:7cff:fe2e:191 prefixlen 64 scopeid 0x20 ether 00:04:7c:2e:01:91 txqueuelen 1000 (Ethernet) RX packets 2806 bytes 3665212 (3.6 MB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 2238 bytes 175964 (175.9 KB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 device memory 0x1ae8000-1ae8fff You can find IP address of PCU such as 192.168.10.221 .","title":"Check PCU public IP Address"},{"location":"version-2.0/start-guide/installation/getting-started-xavier/","text":"Getting started with Xavier # Overview # Reference: Jetson AGX Xavier Developer Kit User Guide This instruction explains how to boot up Ubuntu on Xavier and access it from host PC. Connect To Xavier via SSH # Connect Xavier to internet, this network port is configured to obtain IP address automatically from DHCP by default. You can look for IP address of the public ethernet and connect to Xavier via SSH. ifconfig docker0: flags=4099 mtu 1500 inet 172.17.0.1 netmask 255.255.0.0 broadcast 172.17.255.255 ether 02:42:1c:6c:b1:ec txqueuelen 0 (Ethernet) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 eth0: flags=4099 mtu 1500 ether 48:b0:2d:2b:7a:a8 txqueuelen 1000 (Ethernet) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 eth1: flags=4163 mtu 1500 inet 192.168.10.46 netmask 255.255.252.0 broadcast 192.168.11.255 inet6 fe80::9fcb:8fc6:a1a4:c6d2 prefixlen 64 scopeid 0x20 ether 2c:16:db:a3:03:10 txqueuelen 1000 (Ethernet) RX packets 4946 bytes 6212659 (6.2 MB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 723 bytes 72036 (72.0 KB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 lo: flags=73 mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 inet6 ::1 prefixlen 128 scopeid 0x10 loop txqueuelen 1000 (Local Loopback) RX packets 218 bytes 20064 (20.0 KB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 218 bytes 20064 (20.0 KB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 rndis0: flags=4099 mtu 1500 ether 82:24:ce:68:6a:bd txqueuelen 1000 (Ethernet) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 usb0: flags=4099 mtu 1500 ether 82:24:ce:68:6a:bf txqueuelen 1000 (Ethernet) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 You can find IP address of Xavier such as 192.168.10.46 .","title":"Getting started with Xavier"},{"location":"version-2.0/start-guide/installation/getting-started-xavier/#getting-started-with-xavier","text":"","title":"Getting started with Xavier"},{"location":"version-2.0/start-guide/installation/getting-started-xavier/#overview","text":"Reference: Jetson AGX Xavier Developer Kit User Guide This instruction explains how to boot up Ubuntu on Xavier and access it from host PC.","title":"Overview"},{"location":"version-2.0/start-guide/installation/getting-started-xavier/#connect-to-xavier-via-ssh","text":"Connect Xavier to internet, this network port is configured to obtain IP address automatically from DHCP by default. You can look for IP address of the public ethernet and connect to Xavier via SSH. ifconfig docker0: flags=4099 mtu 1500 inet 172.17.0.1 netmask 255.255.0.0 broadcast 172.17.255.255 ether 02:42:1c:6c:b1:ec txqueuelen 0 (Ethernet) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 eth0: flags=4099 mtu 1500 ether 48:b0:2d:2b:7a:a8 txqueuelen 1000 (Ethernet) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 eth1: flags=4163 mtu 1500 inet 192.168.10.46 netmask 255.255.252.0 broadcast 192.168.11.255 inet6 fe80::9fcb:8fc6:a1a4:c6d2 prefixlen 64 scopeid 0x20 ether 2c:16:db:a3:03:10 txqueuelen 1000 (Ethernet) RX packets 4946 bytes 6212659 (6.2 MB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 723 bytes 72036 (72.0 KB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 lo: flags=73 mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 inet6 ::1 prefixlen 128 scopeid 0x10 loop txqueuelen 1000 (Local Loopback) RX packets 218 bytes 20064 (20.0 KB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 218 bytes 20064 (20.0 KB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 rndis0: flags=4099 mtu 1500 ether 82:24:ce:68:6a:bd txqueuelen 1000 (Ethernet) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 usb0: flags=4099 mtu 1500 ether 82:24:ce:68:6a:bf txqueuelen 1000 (Ethernet) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 You can find IP address of Xavier such as 192.168.10.46 .","title":"Connect To Xavier via SSH"},{"location":"version-2.0/start-guide/installation/getting-started/","text":"Getting started with EWAOL # Overview # Reference: Project Quickstart \u2014 EWAOL documentation This instruction explains how to build yocto image with EWAOL on your host machine. Build Host Setup # Install required packages for the build host by following The Yocto Project \u00ae 3.3.1 documentation . sudo apt-get install gawk wget git diffstat unzip texinfo gcc build-essential chrpath socat cpio python3 python3-pip python3-pexpect xz-utils debianutils iputils-ping python3-git python3-jinja2 libegl1-mesa libsdl1.2-dev pylint3 xterm python3-subunit mesa-common-dev Install the kas setup tool. sudo -H pip3 install kas Checkout the repository for AVA platform # ADLINK / meta-adlink-ampere git clone https://github.com/ADLINK/meta-adlink-ampere.git -b kirkstone EWAOL / meta-ewaol cd meta-adlink-ampere git clone https://git.gitlab.arm.com/ewaol/meta-ewaol.git -b v1.0 Replace virtualization with baremetal in ava.yml . header: version: 1 includes: - repo: meta-ewaol - file: meta-ewaol-config/kas/virtualization.yml + file: meta-ewaol-config/kas/baremetal.yml repos: meta-ewaol: path: meta-ewaol meta-adlink-ampere: machine: ava bblayers_conf_header: base: | POKY_BBLAYERS_CONF_VERSION = \"2\" BBPATH = \"${TOPDIR}\" BBFILES ?= \"\" target: - - ewaol-virtualization-image + - ewaol-baremetal-image Build via kas kas build ava.yml You should be careful of utilizing full CPU power during build.","title":"Getting started with EWAOL"},{"location":"version-2.0/start-guide/installation/getting-started/#getting-started-with-ewaol","text":"","title":"Getting started with EWAOL"},{"location":"version-2.0/start-guide/installation/getting-started/#overview","text":"Reference: Project Quickstart \u2014 EWAOL documentation This instruction explains how to build yocto image with EWAOL on your host machine.","title":"Overview"},{"location":"version-2.0/start-guide/installation/getting-started/#build-host-setup","text":"Install required packages for the build host by following The Yocto Project \u00ae 3.3.1 documentation . sudo apt-get install gawk wget git diffstat unzip texinfo gcc build-essential chrpath socat cpio python3 python3-pip python3-pexpect xz-utils debianutils iputils-ping python3-git python3-jinja2 libegl1-mesa libsdl1.2-dev pylint3 xterm python3-subunit mesa-common-dev Install the kas setup tool. sudo -H pip3 install kas","title":"Build Host Setup"},{"location":"version-2.0/start-guide/installation/getting-started/#checkout-the-repository-for-ava-platform","text":"ADLINK / meta-adlink-ampere git clone https://github.com/ADLINK/meta-adlink-ampere.git -b kirkstone EWAOL / meta-ewaol cd meta-adlink-ampere git clone https://git.gitlab.arm.com/ewaol/meta-ewaol.git -b v1.0 Replace virtualization with baremetal in ava.yml . header: version: 1 includes: - repo: meta-ewaol - file: meta-ewaol-config/kas/virtualization.yml + file: meta-ewaol-config/kas/baremetal.yml repos: meta-ewaol: path: meta-ewaol meta-adlink-ampere: machine: ava bblayers_conf_header: base: | POKY_BBLAYERS_CONF_VERSION = \"2\" BBPATH = \"${TOPDIR}\" BBFILES ?= \"\" target: - - ewaol-virtualization-image + - ewaol-baremetal-image Build via kas kas build ava.yml You should be careful of utilizing full CPU power during build.","title":"Checkout the repository for AVA platform"},{"location":"version-2.0/start-guide/installation/system-setup-ava/","text":"System Setup on AVA platform # Overview # This instruction explains how to perform system setup for test execution on AVA platform. Access to AVA platform via SSH # ssh root@IP-ADDRESS For example; ssh root@192.168.0.62 Download kubernetes yaml files # Autoware.Universe runs as k3s clusters in Open AD Kit, so please download kubernetes yaml files to deploy Autoware to AVA platform. Download. wget https://raw.githubusercontent.com/autowarefoundation/open-ad-kit-docs/main/docs/version-2.0/start-guide/installation/deployments/comhpc-deployments.zip Unzip it. unzip comhpc-deployments.zip -d comhpc-deployments You will see the following files are unzipped. Archive: comhpc-deployments.zip inflating: comhpc-api-deployment.yaml inflating: comhpc-control-deployment.yaml inflating: comhpc-map-deployment.yaml inflating: comhpc-persistent-volume.yaml inflating: comhpc-persistent-volume-claim.yaml inflating: comhpc-planning-deployment.yaml inflating: comhpc-simulator-deployment.yaml inflating: comhpc-system-deployment.yaml inflating: comhpc-vehicle-deployment.yaml Download map files # Download from Google Drive. wget \"https://drive.google.com/uc?export=download&id=1vWMLbmwJJE5tYO40ypCMxqtmgQPQxhiw&confirm=t&uuid=3d84d854-3dd2-4950-8cc8-248feeab547d\" -O sample_data.zip Unzip it. unzip sample_data.zip Move map directory from sample_data . mv sample_data/map/ ~/ You will see the following files are located. root@ava:~# ls -la ~/map total 61288 drwxrwxr-x 2 root root 4096 Aug 18 06:23 . drwx------ 6 root root 4096 Aug 18 06:23 .. -rw-r--r-- 1 root root 1841436 Aug 18 06:23 lanelet2_map.osm -rw-r--r-- 1 root root 60904720 Aug 18 06:23 pointcloud_map.pcd Download kernel configuration file for tuning kernel parameters # We have to reconfigure kernel parameters by using sysctl for system stability. Download. wget -P /etc/sysctl.d https://raw.githubusercontent.com/autowarefoundation/open-ad-kit-docs/main/docs/version-2.0/start-guide/installation/sysctl.d/60_cyclonedds.conf Update kernel parameters. sysctl -p /etc/sysctl.d/60_cyclonedds.conf Download configuration file of Cyclone DDS # In this test, we are using Cyclone DDS, so you also need to download configuration file of Cyclone DDS. Download cyclonedds.xml . wget -P ~/cyclonedds https://raw.githubusercontent.com/autowarefoundation/open-ad-kit-docs/main/docs/version-2.0/start-guide/installation/cyclonedds/cyclonedds.xml Modify cyclonedds.xml # You need to change the element NetworkInterfaceAddress to the network interface currently in use. Find network interface. You can find a network interface such as enP4p4s0 . root@comhpc:~# ip a 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: enP4p4s0: mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 00:30:64:1a:0a:65 brd ff:ff:ff:ff:ff:ff inet 192.168.0.62/24 brd 192.168.0.255 scope global dynamic enP4p4s0 valid_lft 3383sec preferred_lft 2933sec inet6 fe80::1ab4:7a14:28e:4e61/64 scope link valid_lft forever preferred_lft forever inet6 fe80::230:64ff:fe1a:a65/64 scope link valid_lft forever preferred_lft forever 3: sit0@NONE: mtu 1480 qdisc noop state DOWN group default qlen 1000 link/sit 0.0.0.0 brd 0.0.0.0 4: docker0: mtu 1500 qdisc noqueue state DOWN group default link/ether 02:42:4b:b2:ee:68 brd ff:ff:ff:ff:ff:ff inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0 valid_lft forever preferred_lft forever ... Change the NetworkInterfaceAddress . vi ~/cyclonedds/cyclonedds.xml For example; cyclonedds.xml - lo + enP4p4s0 ","title":"System Setup on AVA platform"},{"location":"version-2.0/start-guide/installation/system-setup-ava/#system-setup-on-ava-platform","text":"","title":"System Setup on AVA platform"},{"location":"version-2.0/start-guide/installation/system-setup-ava/#overview","text":"This instruction explains how to perform system setup for test execution on AVA platform.","title":"Overview"},{"location":"version-2.0/start-guide/installation/system-setup-ava/#access-to-ava-platform-via-ssh","text":"ssh root@IP-ADDRESS For example; ssh root@192.168.0.62","title":"Access to AVA platform via SSH"},{"location":"version-2.0/start-guide/installation/system-setup-ava/#download-kubernetes-yaml-files","text":"Autoware.Universe runs as k3s clusters in Open AD Kit, so please download kubernetes yaml files to deploy Autoware to AVA platform. Download. wget https://raw.githubusercontent.com/autowarefoundation/open-ad-kit-docs/main/docs/version-2.0/start-guide/installation/deployments/comhpc-deployments.zip Unzip it. unzip comhpc-deployments.zip -d comhpc-deployments You will see the following files are unzipped. Archive: comhpc-deployments.zip inflating: comhpc-api-deployment.yaml inflating: comhpc-control-deployment.yaml inflating: comhpc-map-deployment.yaml inflating: comhpc-persistent-volume.yaml inflating: comhpc-persistent-volume-claim.yaml inflating: comhpc-planning-deployment.yaml inflating: comhpc-simulator-deployment.yaml inflating: comhpc-system-deployment.yaml inflating: comhpc-vehicle-deployment.yaml","title":"Download kubernetes yaml files"},{"location":"version-2.0/start-guide/installation/system-setup-ava/#download-map-files","text":"Download from Google Drive. wget \"https://drive.google.com/uc?export=download&id=1vWMLbmwJJE5tYO40ypCMxqtmgQPQxhiw&confirm=t&uuid=3d84d854-3dd2-4950-8cc8-248feeab547d\" -O sample_data.zip Unzip it. unzip sample_data.zip Move map directory from sample_data . mv sample_data/map/ ~/ You will see the following files are located. root@ava:~# ls -la ~/map total 61288 drwxrwxr-x 2 root root 4096 Aug 18 06:23 . drwx------ 6 root root 4096 Aug 18 06:23 .. -rw-r--r-- 1 root root 1841436 Aug 18 06:23 lanelet2_map.osm -rw-r--r-- 1 root root 60904720 Aug 18 06:23 pointcloud_map.pcd","title":"Download map files"},{"location":"version-2.0/start-guide/installation/system-setup-ava/#download-kernel-configuration-file-for-tuning-kernel-parameters","text":"We have to reconfigure kernel parameters by using sysctl for system stability. Download. wget -P /etc/sysctl.d https://raw.githubusercontent.com/autowarefoundation/open-ad-kit-docs/main/docs/version-2.0/start-guide/installation/sysctl.d/60_cyclonedds.conf Update kernel parameters. sysctl -p /etc/sysctl.d/60_cyclonedds.conf","title":"Download kernel configuration file for tuning kernel parameters"},{"location":"version-2.0/start-guide/installation/system-setup-ava/#download-configuration-file-of-cyclone-dds","text":"In this test, we are using Cyclone DDS, so you also need to download configuration file of Cyclone DDS. Download cyclonedds.xml . wget -P ~/cyclonedds https://raw.githubusercontent.com/autowarefoundation/open-ad-kit-docs/main/docs/version-2.0/start-guide/installation/cyclonedds/cyclonedds.xml","title":"Download configuration file of Cyclone DDS"},{"location":"version-2.0/start-guide/installation/system-setup-ava/#modify-cycloneddsxml","text":"You need to change the element NetworkInterfaceAddress to the network interface currently in use. Find network interface. You can find a network interface such as enP4p4s0 . root@comhpc:~# ip a 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: enP4p4s0: mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 00:30:64:1a:0a:65 brd ff:ff:ff:ff:ff:ff inet 192.168.0.62/24 brd 192.168.0.255 scope global dynamic enP4p4s0 valid_lft 3383sec preferred_lft 2933sec inet6 fe80::1ab4:7a14:28e:4e61/64 scope link valid_lft forever preferred_lft forever inet6 fe80::230:64ff:fe1a:a65/64 scope link valid_lft forever preferred_lft forever 3: sit0@NONE: mtu 1480 qdisc noop state DOWN group default qlen 1000 link/sit 0.0.0.0 brd 0.0.0.0 4: docker0: mtu 1500 qdisc noqueue state DOWN group default link/ether 02:42:4b:b2:ee:68 brd ff:ff:ff:ff:ff:ff inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0 valid_lft forever preferred_lft forever ... Change the NetworkInterfaceAddress . vi ~/cyclonedds/cyclonedds.xml For example; cyclonedds.xml - lo + enP4p4s0 ","title":"Modify cyclonedds.xml"},{"location":"version-2.0/start-guide/installation/system-setup-host/","text":"System Setup on your host # Overview # This instruction explains how to perform system setup for test execution on your host. You need to copy docker images and necessary files. Download scenario simulator image to your host machine # The docker image of scenario simulator is registered in GitHub Container Registry Copy docker image to your host machine. docker pull ghcr.io/tier4/scenario_simulator_v2:galactic Install nvidia-docker2 & Rocker # In this test, we try to run rviz inside docker, so please install nvidia-docker2 & Rocker. This is quoted from Scenario testing framework for Autoware: Run on Docker If you have NVIDIA GPU (s) in your machine, you have to install nvidia-driver and nvidia-docker2. curl -s -L https://nvidia.github.io/nvidia-container-runtime/gpgkey | sudo apt-key add - curl -s -L https://nvidia.github.io/nvidia-container-runtime/ubuntu20.04/nvidia-container-runtime.list | \\ sudo tee /etc/apt/sources.list.d/nvidia-container-runtime.list sudo apt-get update sudo apt install -y nvidia-docker2 sudo systemctl restart docker.service Install Rocker sudo pip3 install git+https://github.com/osrf/rocker.git Download map and scenario files # Download from Google Drive. wget \"https://drive.google.com/uc?export=download&id=1vWMLbmwJJE5tYO40ypCMxqtmgQPQxhiw&confirm=t&uuid=3d84d854-3dd2-4950-8cc8-248feeab547d\" -O sample_data.zip Unzip it. unzip sample_data.zip Open the scenario file named t4v2.yaml in sample_data . Change the filepath of lanelet2_map.osm and pointcloud_map.pcd to your own directory. Download kernel configuration file for tuning kernel parameters # We have to reconfigure kernel parameters by using sysctl for system stability. Download. wget -P /etc/sysctl.d https://raw.githubusercontent.com/autowarefoundation/open-ad-kit-docs/main/docs/version-2.0/start-guide/installation/sysctl.d/60_cyclonedds.conf Update kernel parameters. sysctl -p /etc/sysctl.d/60_cyclonedds.conf Download configuration file of Cyclone DDS # In this test, we are using Cyclone DDS, so you also need to download configuration file of Cyclone DDS. Download cyclonedds.xml . wget -P ~/cyclonedds https://raw.githubusercontent.com/autowarefoundation/open-ad-kit-docs/main/docs/version-2.0/start-guide/installation/cyclonedds/cyclonedds.xml Modify cyclonedds.xml # You need to change the element NetworkInterfaceAddress to the network interface currently in use. Find network interface. ip addr 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: enp0s31f6: mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 66:77:88:99:aa:bb brd ff:ff:ff:ff:ff:ff inet 192.168.10.1/24 brd 192.168.10.255 scope global noprefixroute enp0s31f6 valid_lft forever preferred_lft forever inet6 fe80::f15d:4196:b777:6875/64 scope link noprefixroute valid_lft forever preferred_lft forever 3: wlp82s0: mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether cc:dd:ee:ff:00:01 brd ff:ff:ff:ff:ff:ff inet 192.168.0.28/24 brd 192.168.0.255 scope global dynamic noprefixroute wlp82s0 valid_lft 3137sec preferred_lft 3137sec inet6 fe80::f493:f223:dfcc:bd1b/64 scope link noprefixroute valid_lft forever preferred_lft forever 4: docker0: mtu 1500 qdisc noqueue state DOWN group default link/ether 23:45:67:89:ab:cd brd ff:ff:ff:ff:ff:ff inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0 valid_lft forever preferred_lft forever You can find a network interface such as enp0s31f6 . Change the NetworkInterfaceAddress . vi ~/cyclonedds/cyclonedds.xml For example; cyclonedds.xml - lo + enp0s31f6 ","title":"System Setup on your host"},{"location":"version-2.0/start-guide/installation/system-setup-host/#system-setup-on-your-host","text":"","title":"System Setup on your host"},{"location":"version-2.0/start-guide/installation/system-setup-host/#overview","text":"This instruction explains how to perform system setup for test execution on your host. You need to copy docker images and necessary files.","title":"Overview"},{"location":"version-2.0/start-guide/installation/system-setup-host/#download-scenario-simulator-image-to-your-host-machine","text":"The docker image of scenario simulator is registered in GitHub Container Registry Copy docker image to your host machine. docker pull ghcr.io/tier4/scenario_simulator_v2:galactic","title":"Download scenario simulator image to your host machine"},{"location":"version-2.0/start-guide/installation/system-setup-host/#install-nvidia-docker2-rocker","text":"In this test, we try to run rviz inside docker, so please install nvidia-docker2 & Rocker. This is quoted from Scenario testing framework for Autoware: Run on Docker If you have NVIDIA GPU (s) in your machine, you have to install nvidia-driver and nvidia-docker2. curl -s -L https://nvidia.github.io/nvidia-container-runtime/gpgkey | sudo apt-key add - curl -s -L https://nvidia.github.io/nvidia-container-runtime/ubuntu20.04/nvidia-container-runtime.list | \\ sudo tee /etc/apt/sources.list.d/nvidia-container-runtime.list sudo apt-get update sudo apt install -y nvidia-docker2 sudo systemctl restart docker.service Install Rocker sudo pip3 install git+https://github.com/osrf/rocker.git","title":"Install nvidia-docker2 & Rocker"},{"location":"version-2.0/start-guide/installation/system-setup-host/#download-map-and-scenario-files","text":"Download from Google Drive. wget \"https://drive.google.com/uc?export=download&id=1vWMLbmwJJE5tYO40ypCMxqtmgQPQxhiw&confirm=t&uuid=3d84d854-3dd2-4950-8cc8-248feeab547d\" -O sample_data.zip Unzip it. unzip sample_data.zip Open the scenario file named t4v2.yaml in sample_data . Change the filepath of lanelet2_map.osm and pointcloud_map.pcd to your own directory.","title":"Download map and scenario files"},{"location":"version-2.0/start-guide/installation/system-setup-host/#download-kernel-configuration-file-for-tuning-kernel-parameters","text":"We have to reconfigure kernel parameters by using sysctl for system stability. Download. wget -P /etc/sysctl.d https://raw.githubusercontent.com/autowarefoundation/open-ad-kit-docs/main/docs/version-2.0/start-guide/installation/sysctl.d/60_cyclonedds.conf Update kernel parameters. sysctl -p /etc/sysctl.d/60_cyclonedds.conf","title":"Download kernel configuration file for tuning kernel parameters"},{"location":"version-2.0/start-guide/installation/system-setup-host/#download-configuration-file-of-cyclone-dds","text":"In this test, we are using Cyclone DDS, so you also need to download configuration file of Cyclone DDS. Download cyclonedds.xml . wget -P ~/cyclonedds https://raw.githubusercontent.com/autowarefoundation/open-ad-kit-docs/main/docs/version-2.0/start-guide/installation/cyclonedds/cyclonedds.xml","title":"Download configuration file of Cyclone DDS"},{"location":"version-2.0/start-guide/installation/system-setup-host/#modify-cycloneddsxml","text":"You need to change the element NetworkInterfaceAddress to the network interface currently in use. Find network interface. ip addr 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: enp0s31f6: mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 66:77:88:99:aa:bb brd ff:ff:ff:ff:ff:ff inet 192.168.10.1/24 brd 192.168.10.255 scope global noprefixroute enp0s31f6 valid_lft forever preferred_lft forever inet6 fe80::f15d:4196:b777:6875/64 scope link noprefixroute valid_lft forever preferred_lft forever 3: wlp82s0: mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether cc:dd:ee:ff:00:01 brd ff:ff:ff:ff:ff:ff inet 192.168.0.28/24 brd 192.168.0.255 scope global dynamic noprefixroute wlp82s0 valid_lft 3137sec preferred_lft 3137sec inet6 fe80::f493:f223:dfcc:bd1b/64 scope link noprefixroute valid_lft forever preferred_lft forever 4: docker0: mtu 1500 qdisc noqueue state DOWN group default link/ether 23:45:67:89:ab:cd brd ff:ff:ff:ff:ff:ff inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0 valid_lft forever preferred_lft forever You can find a network interface such as enp0s31f6 . Change the NetworkInterfaceAddress . vi ~/cyclonedds/cyclonedds.xml For example; cyclonedds.xml - lo + enp0s31f6 ","title":"Modify cyclonedds.xml"},{"location":"version-2.0/start-guide/installation/system-setup-pcu/","text":"System Setup on PCU # Overview # This instruction explains how to perform system setup for test execution on PCU. You need to install Docker Engine, copy docker images and necessary files. Access to PCU via SSH # ssh user@IP-ADDRESS For example; ssh user@192.168.10.221 Copy Autoware.Auto image to PCU # NOTE : docker should be installed with post-installation steps. For instructions please refer to: Install Docker Engine on Ubuntu . Post-installation steps for Linux . The docker image of Autoware.Auto is registered in GitLab Container Registry . Copy docker image to PCU. docker pull registry.gitlab.com/autowarefoundation/autoware.auto/autowareauto/arm64/openadkit-foxy:latest Copy necessary files to local Downloads folder # Copy files related to map contents . Files are placed in the directory docs/Appendix/Open-AD-Kit-Start-Guide/map lanelet2_map.osm pointcloud_map.pcd global_map_center.pcd.yaml lanelet2_map_provider.osm.yaml map_publisher.param.yaml Copy files to your local folder (Downloads folder as example) as the following directory structure. Copy configuration file of Cyclone DDS . In this test, we are using Cyclone DDS, so you also need to copy configuration file of Cyclone DDS. File is placed in the directory docs/Appendix/Open-AD-Kit-Start-Guide/cyclonedds cyclonedds.xml Copy the file to your local folder as the following directory structure. Copy kernel configuration file for tuning kernel parameters. We have to reconfigure kernel parameters by using sysctl for system stability. File is placed in the directory docs/Appendix/Open-AD-Kit-Start-Guide/sysctl.d 60_cyclonedds.conf Copy the file to your local folder. Copy files from local folder to PCU # Connect your host PC with PCU through internet and copy files with SCP. Access to PCU via SSH For example; ssh user@192.168.10.221 Copy kernel configuration file to /etc/sysctl.d/ sudo scp USER-NAME@IP-ADDRESS:/home/USER-NAME/Downloads/60_cyclonedds.conf /etc/sysctl.d/ For example; sudo scp adlink@192.168.10.237:/home/adlink/Downloads/60_cyclonedds.conf /etc/sysctl.d/ Then type in the password of PCU (default password: user) and host PC as request. Update kernel parameters. sudo sysctl -p /etc/sysctl.d/60_cyclonedds.conf Copy map contents files and Cyclone DDS configuration file. sudo scp -r USER-NAME@IP-ADDRESS:/home/adlink/Downloads/map ~/ sudo scp -r USER-NAME@IP-ADDRESS:/home/adlink/Downloads/cyclonedds ~/ Modify cyclonedds.xml # You need to change the element NetworkInterfaceAddress to the network interface currently in use. Find network interface. ip addr 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: fm1-mac1: mtu 1500 qdisc mq master br0 state DOWN group default qlen 1000 link/ether 00:04:7c:2e:01:90 brd ff:ff:ff:ff:ff:ff inet6 fe80::204:7cff:fe2e:190/64 scope link valid_lft forever preferred_lft forever 3: fm1-mac5: mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 00:04:7c:2e:01:91 brd ff:ff:ff:ff:ff:ff inet 192.168.10.221/24 brd 192.168.10.255 scope global dynamic fm1-mac5 valid_lft 254392sec preferred_lft 254392sec inet6 fe80::204:7cff:fe2e:191/64 scope link valid_lft forever preferred_lft forever 4: fm1-mac6: mtu 1500 qdisc mq master br0 state DOWN group default qlen 1000 link/ether 00:04:7c:2e:01:90 brd ff:ff:ff:ff:ff:ff 5: fm1-sw: mtu 1500 qdisc mq master br0 state UP group default qlen 1000 link/ether 00:04:7c:2e:01:90 brd ff:ff:ff:ff:ff:ff inet6 fe80::204:7cff:fe2e:190/64 scope link valid_lft forever preferred_lft forever 6: fm1-mac10: mtu 1500 qdisc mq master br0 state DOWN group default qlen 1000 link/ether 00:04:7c:2e:01:90 brd ff:ff:ff:ff:ff:ff 7: sit0@NONE: mtu 1480 qdisc noop state DOWN group default qlen 1000 link/sit 0.0.0.0 brd 0.0.0.0 8: br0: mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether 00:04:7c:2e:01:90 brd ff:ff:ff:ff:ff:ff inet 192.168.1.239/24 brd 192.168.1.255 scope global br0 valid_lft forever preferred_lft forever inet6 fe80::204:7cff:fe2e:190/64 scope link valid_lft forever preferred_lft forever 9: docker0: mtu 1500 qdisc noqueue state DOWN group default link/ether 02:42:cb:aa:a6:9d brd ff:ff:ff:ff:ff:ff inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0 valid_lft forever preferred_lft forever You can find a network interface such as fm1-mac5 . Change the NetworkInterfaceAddress . sudo vi ~/cyclonedds/cyclonedds.xml For example; cyclonedds.xml - lo + fm1-mac5 ","title":"System Setup on PCU"},{"location":"version-2.0/start-guide/installation/system-setup-pcu/#system-setup-on-pcu","text":"","title":"System Setup on PCU"},{"location":"version-2.0/start-guide/installation/system-setup-pcu/#overview","text":"This instruction explains how to perform system setup for test execution on PCU. You need to install Docker Engine, copy docker images and necessary files.","title":"Overview"},{"location":"version-2.0/start-guide/installation/system-setup-pcu/#access-to-pcu-via-ssh","text":"ssh user@IP-ADDRESS For example; ssh user@192.168.10.221","title":"Access to PCU via SSH"},{"location":"version-2.0/start-guide/installation/system-setup-pcu/#copy-autowareauto-image-to-pcu","text":"NOTE : docker should be installed with post-installation steps. For instructions please refer to: Install Docker Engine on Ubuntu . Post-installation steps for Linux . The docker image of Autoware.Auto is registered in GitLab Container Registry . Copy docker image to PCU. docker pull registry.gitlab.com/autowarefoundation/autoware.auto/autowareauto/arm64/openadkit-foxy:latest","title":"Copy Autoware.Auto image to PCU"},{"location":"version-2.0/start-guide/installation/system-setup-pcu/#copy-necessary-files-to-local-downloads-folder","text":"Copy files related to map contents . Files are placed in the directory docs/Appendix/Open-AD-Kit-Start-Guide/map lanelet2_map.osm pointcloud_map.pcd global_map_center.pcd.yaml lanelet2_map_provider.osm.yaml map_publisher.param.yaml Copy files to your local folder (Downloads folder as example) as the following directory structure. Copy configuration file of Cyclone DDS . In this test, we are using Cyclone DDS, so you also need to copy configuration file of Cyclone DDS. File is placed in the directory docs/Appendix/Open-AD-Kit-Start-Guide/cyclonedds cyclonedds.xml Copy the file to your local folder as the following directory structure. Copy kernel configuration file for tuning kernel parameters. We have to reconfigure kernel parameters by using sysctl for system stability. File is placed in the directory docs/Appendix/Open-AD-Kit-Start-Guide/sysctl.d 60_cyclonedds.conf Copy the file to your local folder.","title":"Copy necessary files to local Downloads folder"},{"location":"version-2.0/start-guide/installation/system-setup-pcu/#copy-files-from-local-folder-to-pcu","text":"Connect your host PC with PCU through internet and copy files with SCP. Access to PCU via SSH For example; ssh user@192.168.10.221 Copy kernel configuration file to /etc/sysctl.d/ sudo scp USER-NAME@IP-ADDRESS:/home/USER-NAME/Downloads/60_cyclonedds.conf /etc/sysctl.d/ For example; sudo scp adlink@192.168.10.237:/home/adlink/Downloads/60_cyclonedds.conf /etc/sysctl.d/ Then type in the password of PCU (default password: user) and host PC as request. Update kernel parameters. sudo sysctl -p /etc/sysctl.d/60_cyclonedds.conf Copy map contents files and Cyclone DDS configuration file. sudo scp -r USER-NAME@IP-ADDRESS:/home/adlink/Downloads/map ~/ sudo scp -r USER-NAME@IP-ADDRESS:/home/adlink/Downloads/cyclonedds ~/","title":"Copy files from local folder to PCU"},{"location":"version-2.0/start-guide/installation/system-setup-pcu/#modify-cycloneddsxml","text":"You need to change the element NetworkInterfaceAddress to the network interface currently in use. Find network interface. ip addr 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: fm1-mac1: mtu 1500 qdisc mq master br0 state DOWN group default qlen 1000 link/ether 00:04:7c:2e:01:90 brd ff:ff:ff:ff:ff:ff inet6 fe80::204:7cff:fe2e:190/64 scope link valid_lft forever preferred_lft forever 3: fm1-mac5: mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 00:04:7c:2e:01:91 brd ff:ff:ff:ff:ff:ff inet 192.168.10.221/24 brd 192.168.10.255 scope global dynamic fm1-mac5 valid_lft 254392sec preferred_lft 254392sec inet6 fe80::204:7cff:fe2e:191/64 scope link valid_lft forever preferred_lft forever 4: fm1-mac6: mtu 1500 qdisc mq master br0 state DOWN group default qlen 1000 link/ether 00:04:7c:2e:01:90 brd ff:ff:ff:ff:ff:ff 5: fm1-sw: mtu 1500 qdisc mq master br0 state UP group default qlen 1000 link/ether 00:04:7c:2e:01:90 brd ff:ff:ff:ff:ff:ff inet6 fe80::204:7cff:fe2e:190/64 scope link valid_lft forever preferred_lft forever 6: fm1-mac10: mtu 1500 qdisc mq master br0 state DOWN group default qlen 1000 link/ether 00:04:7c:2e:01:90 brd ff:ff:ff:ff:ff:ff 7: sit0@NONE: mtu 1480 qdisc noop state DOWN group default qlen 1000 link/sit 0.0.0.0 brd 0.0.0.0 8: br0: mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether 00:04:7c:2e:01:90 brd ff:ff:ff:ff:ff:ff inet 192.168.1.239/24 brd 192.168.1.255 scope global br0 valid_lft forever preferred_lft forever inet6 fe80::204:7cff:fe2e:190/64 scope link valid_lft forever preferred_lft forever 9: docker0: mtu 1500 qdisc noqueue state DOWN group default link/ether 02:42:cb:aa:a6:9d brd ff:ff:ff:ff:ff:ff inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0 valid_lft forever preferred_lft forever You can find a network interface such as fm1-mac5 . Change the NetworkInterfaceAddress . sudo vi ~/cyclonedds/cyclonedds.xml For example; cyclonedds.xml - lo + fm1-mac5 ","title":"Modify cyclonedds.xml"},{"location":"version-2.0/start-guide/installation/system-setup-xavier/","text":"System Setup on Xavier platform # Overview # This instruction explains how to perform system setup for test execution on Xavier platform. Access to Xavier platform via SSH # ssh root@IP-ADDRESS For example; ssh nv@192.168.10.46 Copy Autoware Universe image to Xavier # NOTE : docker should be installed with post-installation steps. For instructions please refer to: Install Docker Engine on Ubuntu . Post-installation steps for Linux . The docker image of Autoware Universe for arm64 is registered in Autoware Foundation Container Registry . Copy docker image to Xavier. docker pull ghcr.io/autowarefoundation/autoware-universe:galactic-20220728-prebuilt-cuda K3s Installation # NOTE : K3s should be installed with following steps. For official instructions please refer to: Install K3s on Ubuntu . Install K3s. curl -sfL https://get.k3s.io | sh - Create directory. mkdir ~/.kube/ Copy config file sudo cp /etc/rancher/k3s/k3s.yaml ~/.kube/config Setting environment export KUBECONFIG=~/.kube/config Download kubernetes yaml files # Autoware.Universe runs as k3s clusters in Open AD Kit, so please download kubernetes yaml files to deploy Autoware to Xavier platform. Download. wget https://raw.githubusercontent.com/autowarefoundation/open-ad-kit-docs/main/docs/version-2.0/start-guide/installation/deployments/comhpc-deployments.zip Unzip it. unzip comhpc-deployments.zip -d comhpc-deployments You will see the following files are unzipped. Archive: comhpc-deployments.zip inflating: comhpc-api-deployment.yaml inflating: comhpc-control-deployment.yaml inflating: comhpc-map-deployment.yaml inflating: comhpc-persistent-volume.yaml inflating: comhpc-persistent-volume-claim.yaml inflating: comhpc-planning-deployment.yaml inflating: comhpc-simulator-deployment.yaml inflating: comhpc-system-deployment.yaml inflating: comhpc-vehicle-deployment.yaml Download map files # Download from Google Drive. wget \"https://drive.google.com/uc?export=download&id=1vWMLbmwJJE5tYO40ypCMxqtmgQPQxhiw&confirm=t&uuid=3d84d854-3dd2-4950-8cc8-248feeab547d\" -O sample_data.zip Unzip it. unzip sample_data.zip Move map directory from sample_data . mv sample_data/map/ ~/ You will see the following files are located. ls -la ~/map total 61288 drwxrwxr-x 2 root root 4096 Aug 18 06:23 . drwx------ 6 root root 4096 Aug 18 06:23 .. -rw-r--r-- 1 root root 1841436 Aug 18 06:23 lanelet2_map.osm -rw-r--r-- 1 root root 60904720 Aug 18 06:23 pointcloud_map.pcd Download kernel configuration file for tuning kernel parameters # We have to reconfigure kernel parameters by using sysctl for system stability. Download. wget -P /etc/sysctl.d https://raw.githubusercontent.com/autowarefoundation/open-ad-kit-docs/main/docs/version-2.0/start-guide/installation/sysctl.d/60_cyclonedds.conf Update kernel parameters. sysctl -p /etc/sysctl.d/60_cyclonedds.conf Download configuration file of Cyclone DDS # In this test, we are using Cyclone DDS, so you also need to download configuration file of Cyclone DDS. Download cyclonedds.xml . wget -P ~/cyclonedds https://raw.githubusercontent.com/autowarefoundation/open-ad-kit-docs/main/docs/version-2.0/start-guide/installation/cyclonedds/cyclonedds.xml Modify cyclonedds.xml # You need to change the element NetworkInterfaceAddress to the network interface currently in use. Find network interface. ip addr 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: dummy0: mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 0e:fa:61:5e:35:cd brd ff:ff:ff:ff:ff:ff 3: eth0: mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000 link/ether 48:b0:2d:2b:7a:a8 brd ff:ff:ff:ff:ff:ff 4: l4tbr0: mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 82:24:ce:68:6a:bd brd ff:ff:ff:ff:ff:ff 5: rndis0: mtu 1500 qdisc pfifo_fast master l4tbr0 state DOWN group default qlen 1000 link/ether 82:24:ce:68:6a:bd brd ff:ff:ff:ff:ff:ff 6: usb0: mtu 1500 qdisc pfifo_fast master l4tbr0 state DOWN group default qlen 1000 link/ether 82:24:ce:68:6a:bf brd ff:ff:ff:ff:ff:ff 7: eth1: mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 2c:16:db:a3:03:10 brd ff:ff:ff:ff:ff:ff inet 192.168.10.46/22 brd 192.168.11.255 scope global dynamic noprefixroute eth1 valid_lft 84077sec preferred_lft 84077sec inet6 fe80::9fcb:8fc6:a1a4:c6d2/64 scope link noprefixroute valid_lft forever preferred_lft forever 8: docker0: mtu 1500 qdisc noqueue state DOWN group default link/ether 02:42:0b:47:8f:45 brd ff:ff:ff:ff:ff:ff inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0 valid_lft forever preferred_lft forever You can find a network interface such as eth1 . Change the NetworkInterfaceAddress . vi ~/cyclonedds/cyclonedds.xml For example; cyclonedds.xml - lo + eth1 ","title":"System Setup on Xavier platform"},{"location":"version-2.0/start-guide/installation/system-setup-xavier/#system-setup-on-xavier-platform","text":"","title":"System Setup on Xavier platform"},{"location":"version-2.0/start-guide/installation/system-setup-xavier/#overview","text":"This instruction explains how to perform system setup for test execution on Xavier platform.","title":"Overview"},{"location":"version-2.0/start-guide/installation/system-setup-xavier/#access-to-xavier-platform-via-ssh","text":"ssh root@IP-ADDRESS For example; ssh nv@192.168.10.46","title":"Access to Xavier platform via SSH"},{"location":"version-2.0/start-guide/installation/system-setup-xavier/#copy-autoware-universe-image-to-xavier","text":"NOTE : docker should be installed with post-installation steps. For instructions please refer to: Install Docker Engine on Ubuntu . Post-installation steps for Linux . The docker image of Autoware Universe for arm64 is registered in Autoware Foundation Container Registry . Copy docker image to Xavier. docker pull ghcr.io/autowarefoundation/autoware-universe:galactic-20220728-prebuilt-cuda","title":"Copy Autoware Universe image to Xavier"},{"location":"version-2.0/start-guide/installation/system-setup-xavier/#k3s-installation","text":"NOTE : K3s should be installed with following steps. For official instructions please refer to: Install K3s on Ubuntu . Install K3s. curl -sfL https://get.k3s.io | sh - Create directory. mkdir ~/.kube/ Copy config file sudo cp /etc/rancher/k3s/k3s.yaml ~/.kube/config Setting environment export KUBECONFIG=~/.kube/config","title":"K3s Installation"},{"location":"version-2.0/start-guide/installation/system-setup-xavier/#download-kubernetes-yaml-files","text":"Autoware.Universe runs as k3s clusters in Open AD Kit, so please download kubernetes yaml files to deploy Autoware to Xavier platform. Download. wget https://raw.githubusercontent.com/autowarefoundation/open-ad-kit-docs/main/docs/version-2.0/start-guide/installation/deployments/comhpc-deployments.zip Unzip it. unzip comhpc-deployments.zip -d comhpc-deployments You will see the following files are unzipped. Archive: comhpc-deployments.zip inflating: comhpc-api-deployment.yaml inflating: comhpc-control-deployment.yaml inflating: comhpc-map-deployment.yaml inflating: comhpc-persistent-volume.yaml inflating: comhpc-persistent-volume-claim.yaml inflating: comhpc-planning-deployment.yaml inflating: comhpc-simulator-deployment.yaml inflating: comhpc-system-deployment.yaml inflating: comhpc-vehicle-deployment.yaml","title":"Download kubernetes yaml files"},{"location":"version-2.0/start-guide/installation/system-setup-xavier/#download-map-files","text":"Download from Google Drive. wget \"https://drive.google.com/uc?export=download&id=1vWMLbmwJJE5tYO40ypCMxqtmgQPQxhiw&confirm=t&uuid=3d84d854-3dd2-4950-8cc8-248feeab547d\" -O sample_data.zip Unzip it. unzip sample_data.zip Move map directory from sample_data . mv sample_data/map/ ~/ You will see the following files are located. ls -la ~/map total 61288 drwxrwxr-x 2 root root 4096 Aug 18 06:23 . drwx------ 6 root root 4096 Aug 18 06:23 .. -rw-r--r-- 1 root root 1841436 Aug 18 06:23 lanelet2_map.osm -rw-r--r-- 1 root root 60904720 Aug 18 06:23 pointcloud_map.pcd","title":"Download map files"},{"location":"version-2.0/start-guide/installation/system-setup-xavier/#download-kernel-configuration-file-for-tuning-kernel-parameters","text":"We have to reconfigure kernel parameters by using sysctl for system stability. Download. wget -P /etc/sysctl.d https://raw.githubusercontent.com/autowarefoundation/open-ad-kit-docs/main/docs/version-2.0/start-guide/installation/sysctl.d/60_cyclonedds.conf Update kernel parameters. sysctl -p /etc/sysctl.d/60_cyclonedds.conf","title":"Download kernel configuration file for tuning kernel parameters"},{"location":"version-2.0/start-guide/installation/system-setup-xavier/#download-configuration-file-of-cyclone-dds","text":"In this test, we are using Cyclone DDS, so you also need to download configuration file of Cyclone DDS. Download cyclonedds.xml . wget -P ~/cyclonedds https://raw.githubusercontent.com/autowarefoundation/open-ad-kit-docs/main/docs/version-2.0/start-guide/installation/cyclonedds/cyclonedds.xml","title":"Download configuration file of Cyclone DDS"},{"location":"version-2.0/start-guide/installation/system-setup-xavier/#modify-cycloneddsxml","text":"You need to change the element NetworkInterfaceAddress to the network interface currently in use. Find network interface. ip addr 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: dummy0: mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 0e:fa:61:5e:35:cd brd ff:ff:ff:ff:ff:ff 3: eth0: mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000 link/ether 48:b0:2d:2b:7a:a8 brd ff:ff:ff:ff:ff:ff 4: l4tbr0: mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 82:24:ce:68:6a:bd brd ff:ff:ff:ff:ff:ff 5: rndis0: mtu 1500 qdisc pfifo_fast master l4tbr0 state DOWN group default qlen 1000 link/ether 82:24:ce:68:6a:bd brd ff:ff:ff:ff:ff:ff 6: usb0: mtu 1500 qdisc pfifo_fast master l4tbr0 state DOWN group default qlen 1000 link/ether 82:24:ce:68:6a:bf brd ff:ff:ff:ff:ff:ff 7: eth1: mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 2c:16:db:a3:03:10 brd ff:ff:ff:ff:ff:ff inet 192.168.10.46/22 brd 192.168.11.255 scope global dynamic noprefixroute eth1 valid_lft 84077sec preferred_lft 84077sec inet6 fe80::9fcb:8fc6:a1a4:c6d2/64 scope link noprefixroute valid_lft forever preferred_lft forever 8: docker0: mtu 1500 qdisc noqueue state DOWN group default link/ether 02:42:0b:47:8f:45 brd ff:ff:ff:ff:ff:ff inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0 valid_lft forever preferred_lft forever You can find a network interface such as eth1 . Change the NetworkInterfaceAddress . vi ~/cyclonedds/cyclonedds.xml For example; cyclonedds.xml - lo + eth1 ","title":"Modify cyclonedds.xml"},{"location":"version-2.0/system-configuration/","text":"System configuration # TODO","title":"System configuration"},{"location":"version-2.0/system-configuration/#system-configuration","text":"TODO","title":"System configuration"}]} \ No newline at end of file diff --git a/latest/sitemap.xml b/latest/sitemap.xml index 5283f8d5..0ceefed1 100644 --- a/latest/sitemap.xml +++ b/latest/sitemap.xml @@ -2,572 +2,572 @@ https://autowarefoundation.github.io/open-ad-kit-docs/latest/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-1.0/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-1.0/application-example/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-1.0/application-example/driverless-bus/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-1.0/application-example/driverless-bus/appendix/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-1.0/application-example/driverless-bus/appendix/hardware-list/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-1.0/application-example/driverless-bus/appendix/what-is-conops-and-opscon/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-1.0/application-example/driverless-bus/concept-of-operations/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-1.0/application-example/driverless-bus/hardware-requirements/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-1.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-1.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/high-level-arch/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-1.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/hw-requirements/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-1.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/perf-data-bandwidth/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-1.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/sys-resource-if/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-1.0/application-example/driverless-bus/introduction-of-reference-design/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-1.0/application-example/driverless-bus/operational-concept/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-1.0/application-example/driverless-bus/operational-concept/adaptive-cruise-control/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-1.0/application-example/driverless-bus/operational-concept/avoid-collisions/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-1.0/application-example/driverless-bus/operational-concept/daytime-operation/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-1.0/application-example/driverless-bus/operational-concept/follow-a-route/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-1.0/application-example/driverless-bus/operational-concept/interact-with-emergency-vehicles/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-1.0/application-example/driverless-bus/operational-concept/interact-with-other-vehicle-on-the-public-roads/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-1.0/application-example/driverless-bus/operational-concept/interact-with-traffic-lights/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-1.0/application-example/driverless-bus/operational-concept/lane-keeping-and-changing-lanes/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-1.0/application-example/driverless-bus/operational-concept/let-passengers-on-and-off-at-bus-stops/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-1.0/application-example/driverless-bus/operational-concept/nighttime-operation/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-1.0/application-example/driverless-bus/operational-concept/operation-mode/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-1.0/application-example/driverless-bus/operational-concept/predict-pedestrian-stepping-into-the-road/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-1.0/application-example/driverless-bus/operational-concept/set-service-route-via-HMI-on-the-vehicle/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-1.0/application-example/driverless-bus/operational-concept/take-over-request-to-the-operator/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-1.0/application-example/driverless-bus/operational-environment-requirement/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-1.0/application-example/driverless-bus/software-requirements/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-1.0/application-example/driverless-bus/software-requirements/autoware-api/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-1.0/application-example/driverless-bus/software-requirements/component-architecture/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-1.0/application-example/driverless-bus/software-requirements/design-docs-of-autoware/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-1.0/application-example/driverless-bus/software-requirements/repository-configuration/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-1.0/application-example/driverless-bus/system-configuration/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-1.0/application-example/driverless-bus/system-requirements/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-1.0/application-example/driverless-bus/system-requirements/parity-requirements/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-1.0/start-guide/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-1.0/start-guide/how-to-run-autoware/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-1.0/start-guide/how-to-run-simulators/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-1.0/start-guide/how-to-run-simulators/limitations-and-issues/limitations-and-issues/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-1.0/start-guide/how-to-run-simulators/logging-simulator/run-on-cloud-env/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-1.0/start-guide/how-to-run-simulators/scenario-simulator/run-on-cloud-env/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-1.0/start-guide/how-to-run-simulators/scenario-simulator/run-on-local-env/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-1.0/start-guide/installation/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-1.0/start-guide/installation/boot-ewaol/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-1.0/start-guide/installation/extend-rootfs/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-1.0/start-guide/installation/getting-started-pcu/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-1.0/start-guide/installation/getting-started/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-1.0/start-guide/installation/system-setup-ava/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-1.0/start-guide/installation/system-setup-host/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-1.0/start-guide/installation/system-setup-pcu/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-1.0/start-guide/installation/images/boot-ewaol/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-1.0/system-configuration/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-2.0/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-2.0/application-example/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-2.0/application-example/driverless-bus/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-2.0/application-example/driverless-bus/appendix/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-2.0/application-example/driverless-bus/appendix/hardware-list/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-2.0/application-example/driverless-bus/appendix/what-is-conops-and-opscon/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-2.0/application-example/driverless-bus/concept-of-operations/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-2.0/application-example/driverless-bus/hardware-requirements/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-2.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-2.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/high-level-arch/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-2.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/hw-requirements/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-2.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/perf-data-bandwidth/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-2.0/application-example/driverless-bus/hardware-requirements/ecu-requirements/sys-resource-if/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-2.0/application-example/driverless-bus/introduction-of-reference-design/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-2.0/application-example/driverless-bus/operational-concept/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-2.0/application-example/driverless-bus/operational-concept/adaptive-cruise-control/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-2.0/application-example/driverless-bus/operational-concept/avoid-collisions/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-2.0/application-example/driverless-bus/operational-concept/daytime-operation/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-2.0/application-example/driverless-bus/operational-concept/follow-a-route/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-2.0/application-example/driverless-bus/operational-concept/interact-with-emergency-vehicles/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-2.0/application-example/driverless-bus/operational-concept/interact-with-other-vehicle-on-the-public-roads/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-2.0/application-example/driverless-bus/operational-concept/interact-with-traffic-lights/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-2.0/application-example/driverless-bus/operational-concept/lane-keeping-and-changing-lanes/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-2.0/application-example/driverless-bus/operational-concept/let-passengers-on-and-off-at-bus-stops/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-2.0/application-example/driverless-bus/operational-concept/nighttime-operation/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-2.0/application-example/driverless-bus/operational-concept/operation-mode/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-2.0/application-example/driverless-bus/operational-concept/predict-pedestrian-stepping-into-the-road/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-2.0/application-example/driverless-bus/operational-concept/set-service-route-via-HMI-on-the-vehicle/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-2.0/application-example/driverless-bus/operational-concept/take-over-request-to-the-operator/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-2.0/application-example/driverless-bus/operational-environment-requirement/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-2.0/application-example/driverless-bus/software-requirements/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-2.0/application-example/driverless-bus/software-requirements/autoware-api/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-2.0/application-example/driverless-bus/software-requirements/component-architecture/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-2.0/application-example/driverless-bus/software-requirements/design-docs-of-autoware/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-2.0/application-example/driverless-bus/software-requirements/repository-configuration/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-2.0/application-example/driverless-bus/system-configuration/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-2.0/application-example/driverless-bus/system-requirements/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-2.0/application-example/driverless-bus/system-requirements/parity-requirements/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-2.0/start-guide/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-2.0/start-guide/how-to-run-autoware/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-2.0/start-guide/how-to-run-simulators/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-2.0/start-guide/how-to-run-simulators/limitations-and-issues/limitations-and-issues/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-2.0/start-guide/how-to-run-simulators/logging-simulator/run-on-cloud-env/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-2.0/start-guide/how-to-run-simulators/scenario-simulator/run-on-cloud-env/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-2.0/start-guide/how-to-run-simulators/scenario-simulator/run-on-local-env/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-2.0/start-guide/how-to-run-simulators/troubleshooting/troubleshooting/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-2.0/start-guide/installation/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-2.0/start-guide/installation/advanced-setup-setup-ava/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-2.0/start-guide/installation/boot-ewaol/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-2.0/start-guide/installation/extend-rootfs/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-2.0/start-guide/installation/getting-started-pcu/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-2.0/start-guide/installation/getting-started-xavier/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-2.0/start-guide/installation/getting-started/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-2.0/start-guide/installation/system-setup-ava/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-2.0/start-guide/installation/system-setup-host/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-2.0/start-guide/installation/system-setup-pcu/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-2.0/start-guide/installation/system-setup-xavier/ - 2022-12-07 + 2022-12-14 daily https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-2.0/system-configuration/ - 2022-12-07 + 2022-12-14 daily \ No newline at end of file diff --git a/latest/sitemap.xml.gz b/latest/sitemap.xml.gz index f1611bdb28cda34651fd12a869ae134979c972b5..cee7fb421f4ab5a39f25b62b377446f6d2a5d95a 100644 GIT binary patch literal 1192 zcmV;Z1XueXiwFpOKbd0!|8r?{Wo=<_E_iKh0PUO2ZsRr(fbaVhf$y}kL=SC|cyEjL z&|CWeG&z!pP$ZW>mi_h}%8u)zagj7mi*jfLaKum)=Yzx{seBJ#_LI5WL5SMf$JOWc z{pt>^bV}RdarN7;U)lGoFPl#fIhY9P4lCRExEfRPKX%hzGGd z6?XUQA6A=Bclap{9DiFr55~z&X(eJaA}2SC0KLmriG&?l4?2x`yVkCA9xM}zJ?X@h zld&@*K}_94SDLtNQN%Pkwc+=iv(NbR9acG&T~w2!umkh~zHOAy=J3#6lpMR-o%?$8 zUY|fS~6@U5}m1I=}=rkq#YXZY-{`81*nR z13NHG1UWV~mu%*C-&|vZgKE#P4}xtmx6E3lcJEvk#6!e_=yH(2bWekgwkbH3I5nU(f0_&;4&u>recHz_5|Ry9hS|YrT^ui{Dm?YNX&~E0XrRH zd6br|vc6{`m6KRZ&J*Ti%Y)O>^by9njA3Mi)3gtuG!C&Ia9x*z78V~9@XO$Wz+n4WbD#sHw2a%O z0x0HXCKPVXp`O+d5mNR{>;#!uM^}Xq@Va0te_r(@2Ao0Hm2~Rc&*A@jPmWjV$#Dvv z94F<;al)P)Z=T#+IMnFLak`!yZ=T!-v8cEqgku8FFrLTpZz z&Heg^)#lS3{p1dgzb!uxgHxN_OQde(l-w)>wr;XoCK|}PGpV1pYvUT{(Sp?QWD;nn zVl&8uF*OfO?&7jX8Pn+WM%)Vlp9S21M@>$37tK^JZHH~ZZyPPmaCm4gYK}u~&SSm# zs867QI2RCs^nNgExe{O$0Y|inb?B(3%HkS}-gG?- zxWfTtP<>@{$!4z4%{4YOskT64kg%oPG8>)hvvXMy50NUOn}R|xEe|%vrr`9XmNt}n z>24Tk4~n2MnvTiZ$B_4JGkjDhT&(Nr2}Q^IFa`Vt8( z56O)9#{!)%ik2P+H-m)Wri6SsPy(S!m0+g30j1K=QTjN*4tt~M%1Y))#-$#^GZmno zs0@DEQqS}VNnJsmK&2qtmY@u@%}I=@4ALSzA$nuG`km zX*nuuTaYPV1Ti_!n2*gbPEFHC80R{m$QY+-A5a^bVm;EnE(Ieky(Z|F$%W=$x1^(- zhxj6jG_OPqJEQQpsDqu6@Y63pKWFPx^5#n@$tRjrsMT_CLY>0t!8tZ|fgc*QI}@DE zCrFp4NjyMA*CwXlTf7|l^PNF@!>nsFNPx<0aqaWJDv$NxK8j+9J{w8^}qIR=Mvy7i};%VYLvK7NE3LVVB1)7pdF^P%-gvE zYVc}e6mH3(p7szC)8s+!B%4@!SA-Dox?l@`U(F~xT0xhUbjmx=5&wHnP88|M2@al| zVCBgP#-5z0p4?kFl<3I`zMh<@p4|*p%nViR#I{mrdcGoZ#xoiR#JS z4oF#^oT#4M4Nw&2$%*R8eKeWUJvmW5x!Y1H+mjR3llv$><#}?VdUEgOz{Qgj)sy=; zLZy3hqIz;~0#TwTC#om+ehx)?a-w>2H$_sYCnwl?a)PTTC#om+XBg#pa-w)oPB8G~ zMD^tU8IjUGIZ-{in{X(_lY1S96x_6>wB9?H{hYs)%VJQFEBLpeNxhR+p+31PrKm`P zg&!%n_>qE_ANi(m_i|@2Fp9Y3Pzy6c1t%j^Ffu}4A8R?&(|>YyxqJ}G&F?c3i@#rT F004W_P)z^; diff --git a/latest/version-2.0/start-guide/how-to-run-autoware/index.html b/latest/version-2.0/start-guide/how-to-run-autoware/index.html index e7387973..5f725c0f 100644 --- a/latest/version-2.0/start-guide/how-to-run-autoware/index.html +++ b/latest/version-2.0/start-guide/how-to-run-autoware/index.html @@ -1394,6 +1394,13 @@ 3. Run simulators on the development platform + + +
  • + + 4. Run centerpoint object detection simultaneously on the development platform + +
    • @@ -1466,6 +1473,8 @@

    2. Run Autoware o

    TODO

    3. Run simulators on the development platform#

    Please refer to the How to run simulators section.

    +

    4. Run centerpoint object detection simultaneously on the development platform#

    +

    Please refer to the tutorial