diff --git a/assets/contributors.csv b/assets/contributors.csv index fb076e489e..1d0b48cc52 100644 --- a/assets/contributors.csv +++ b/assets/contributors.csv @@ -82,4 +82,5 @@ Odin Shen,Arm,odincodeshen,odin-shen-lmshen,, Avin Zarlez,Arm,AvinZarlez,avinzarlez,,https://www.avinzarlez.com/ Shuheng Deng,Arm,,,, Yiyang Fan,Arm,,,, +Julien Jayat,Arm,,,, Geremy Cohen,Arm,geremyCohen,geremyinanutshell,, diff --git a/content/install-guides/cyclonedds.md b/content/install-guides/cyclonedds.md new file mode 100644 index 0000000000..fe6b121e86 --- /dev/null +++ b/content/install-guides/cyclonedds.md @@ -0,0 +1,105 @@ +--- +additional_search_terms: +- linux +- automotive + + +layout: installtoolsall +minutes_to_complete: 20 +author: Odin Shen +multi_install: false +multitool_install_part: false +official_docs: https://cyclonedds.io/ +test_images: +- ubuntu:latest +test_maintenance: true +title: Cyclone DDS +tool_install: true +weight: 1 +--- + +The [Eclipse Cyclone DDS](https://cyclonedds.io/) is an open-source implementation of the Data Distribution Service ([DDS](https://en.wikipedia.org/wiki/Data_Distribution_Service)) standard, designed for high-performance, real-time, and scalable communication in autonomous systems, robotics, industrial IoT, and aerospace applications. +It is part of the Eclipse Foundation and is widely used in ROS 2 as a key middleware for inter-process communication. + +## Before you begin + +ROS2 is available for Linux, macOS and Windows. +This article provides a quick solution to install Cyclone DDS on Linux. + +Confirm you are using an Arm machine by running: + +```bash +uname -m +``` + +The output should be: + +```output +aarch64 +``` + +If you see a different result, you are not using an Arm computer running 64-bit Linux. + +Also, you need install following before building Cyclone DDS: + +- C Compiler (i.e. GCC). +- GIT. +- CMAKE (3.7 or later). +- OpenSSL (1.1 or later) + +## How do I build Cyclone DDS on Arm? + +We will install Cyclone DDS from source code. +Clone the GitHub link and create a build folder. + +```bash +git clone https://github.com/eclipse-cyclonedds/cyclonedds.git +``` + +Once download, you can build and install Cyclone DDS on Linux. +In order to verify the installation, we enable `BUILD_EXAMPLES` and `BUILD_TESTING` for further testing. + +```bash +cd cyclonedds +mkdir build +cmake -DBUILD_EXAMPLES=ON -DBUILD_TESTING=ON -DCMAKE_INSTALL_PREFIX= .. +cmake --build . +cmake --build . --target install +``` + +{{% notice Note %}} +The two cmake --build commands might require being executed with sudo depending on the . +{{% /notice %}} + + +## Quick test on Cyclone DDS + +After success build up the code, you are able to use Cyclone DDS now. +To verify the installation, you can run the Hello World example on cyclonedds/build/bin folder. + +Open two terminals and move to the cyclonedds/build/bin/ directory and in each terminal run: + +{{< tabpane code=true >}} + {{< tab header="Publisher" language="bash">}} + cd cyclonedds/build/bin/ + ./HelloworldPublisher + {{< /tab >}} + {{< tab header="Subscriber" language="bash">}} + cd cyclonedds/build/bin/ + ./HelloworldSubscriber + {{< /tab >}} +{{< /tabpane >}} + +If you observe the following message from each of terminal, it's mean Cyclone DDS has been successfully installed on Arm machine. +You are now ready to use Cyclone DDS. + +{{< tabpane code=true >}} + {{< tab header="Publisher" language="log">}} + === [Publisher] Waiting for a reader to be discovered ... + === [Publisher] Writing : Message (1, Hello World) + {{< /tab >}} + {{< tab header="Subscriber" language="log">}} + === [Subscriber] Waiting for a sample ... + === [Subscriber] Received : Message (1, Hello World) + {{< /tab >}} +{{< /tabpane >}} diff --git a/content/install-guides/ros2.md b/content/install-guides/ros2.md new file mode 100644 index 0000000000..ed1c4fe4ec --- /dev/null +++ b/content/install-guides/ros2.md @@ -0,0 +1,133 @@ +--- +additional_search_terms: +- linux +- cloud + + +layout: installtoolsall +minutes_to_complete: 30 +author: Odin Shen +multi_install: false +multitool_install_part: false +official_docs: https://www.ros.org/blog/getting-started/ +test_images: +- ubuntu:latest +test_maintenance: true +title: ROS2 +tool_install: true +weight: 1 +--- + +The Robot Operating System [ROS](https://www.ros.org/) is a set of software libraries and tools for building robot applications. +ROS 2 is the latest version, designed to enhance security, improve distributed system communication, and support real-time performance, addressing some of the limitations of ROS 1. + +## Before you begin + +ROS2 is available for Ubuntu Linux 22.04, 24.04 and Windows 11. + +This article provides a quick solution to install ROS2 for Ubuntu on Arm. + +Confirm you are using an Arm machine by running: + +```bash +uname -m +``` + +The output should be: + +```output +aarch64 +``` + +If you see a different result, you are not using an Arm computer running 64-bit Linux. + +## How do I Install ROS2 for Ubuntu on Arm? + +We will install ROS 2 using APT. +By default, the Ubuntu package lists do not include ROS 2, so you need to manually execute the setup first. + +```bash +sudo apt update +sudo apt install curl -y +sudo curl -sSL https://raw.githubusercontent.com/ros/rosdistro/master/ros.key -o /usr/share/keyrings/ros-archive-keyring.gpg +echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/ros-archive-keyring.gpg] http://packages.ros.org/ros2/ubuntu $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/ros2.list > /dev/null +``` + +There are two of distros (Jazzy Jalisco and Humble Hawksbill) can be installed depended on your Ubuntu version. +For Ubuntu Linux 24.04, you should use Jazzy Jalisco. +For Ubuntu Linux 22.04, you should use Humble Hawksbill. + +{{< tabpane code=true >}} + {{< tab header="Ubuntu 24.04" language="bash">}} + sudo apt update + sudo apt install ros-jazzy-desktop + sudo apt install ros-jazzy-ros-base + source /opt/ros/jazzy/setup.bash + {{< /tab >}} + {{< tab header="Ubuntu 22.04" language="bash">}} + sudo apt update + sudo apt install ros-humble-desktop + sudo apt install ros-humble-ros-base + sudo apt install ros-dev-tools + source /opt/ros/humble/setup.bash + {{< /tab >}} +{{< /tabpane >}} + +Confirm the version `ros2` is installed by using printenv: + +```bash +printenv ROS_DISTRO +``` +The output should print either `jazzy` or `humble`, depending on your Ubuntu version. + + +## Quick test on ROS2 + +In one terminal run a `talker`: + +```bash +ros2 run demo_nodes_cpp talker +``` + +The output will continue to be similar to the one shown below, indicating that ROS 2 is publishing the “hello world” string along with a sequence number. + +```output +[INFO] [1741389626.338343545] [talker]: Publishing: 'Hello World: 1' +[INFO] [1741389627.338329328] [talker]: Publishing: 'Hello World: 2' +[INFO] [1741389628.338317118] [talker]: Publishing: 'Hello World: 3' +[INFO] [1741389629.338322551] [talker]: Publishing: 'Hello World: 4' +[INFO] [1741389630.338318200] [talker]: Publishing: 'Hello World: 5' +[INFO] [1741389631.338334884] [talker]: Publishing: 'Hello World: 6' +[INFO] [1741389629.338322551] [talker]: Publishing: 'Hello World: 7' +[INFO] [1741389630.338318200] [talker]: Publishing: 'Hello World: 8' +[INFO] [1741389631.338334884] [talker]: Publishing: 'Hello World: 9' +... +``` + +Then, open another terminal source the setup file and then run `listener`: +{{< tabpane code=true >}} + {{< tab header="Ubuntu 24.04" language="bash">}} + source /opt/ros/jazzy/setup.bash + ros2 run demo_nodes_cpp listener + {{< /tab >}} + {{< tab header="Ubuntu 22.04" language="bash">}} + source /opt/ros/humble/setup.bash + ros2 run demo_nodes_cpp listener + {{< /tab >}} +{{< /tabpane >}} + +If you see "I heard [Hello World: ]" in second terminal shown below, it's mean your ROS2 has been successfully installed. +You are now ready to use ROS2. + +```output +[INFO] [1741389927.137762134] [listener]: I heard: [Hello World: 1] +[INFO] [1741389928.125120177] [listener]: I heard: [Hello World: 2] +[INFO] [1741389929.125042010] [listener]: I heard: [Hello World: 3] +[INFO] [1741389930.125046472] [listener]: I heard: [Hello World: 4] +[INFO] [1741389931.125055785] [listener]: I heard: [Hello World: 5] +[INFO] [1741389932.125434760] [listener]: I heard: [Hello World: 6] +[INFO] [1741389933.125044887] [listener]: I heard: [Hello World: 7] +[INFO] [1741389934.125124370] [listener]: I heard: [Hello World: 8] +[INFO] [1741389935.125036222] [listener]: I heard: [Hello World: 9] +... +``` diff --git a/content/learning-paths/automotive/openadkit1_container/1_sdv_soafee.md b/content/learning-paths/automotive/openadkit1_container/1_sdv_soafee.md new file mode 100644 index 0000000000..d375374966 --- /dev/null +++ b/content/learning-paths/automotive/openadkit1_container/1_sdv_soafee.md @@ -0,0 +1,57 @@ +--- +title: Software-Defined Vehicle (SDV) and SOAFEE +weight: 2 + +### FIXED, DO NOT MODIFY +layout: learningpathall +--- + +## Introduction to Software-Defined Vehicles + +In recent years, the automotive industry has been undergoing a transformation driven by software, with the concept of the Software-Defined Vehicle (SDV) emerging as a key paradigm for the future of intelligent cars. As the number of Electronic Control Units (ECUs) increases and vehicle systems become more complex, the traditional hardware-driven development approach is no longer sufficient. To improve development efficiency and product quality, automotive software development is shifting toward a Shift-Left approach, accelerating validation and deployment processes. + +## The Evolution of Software-Defined Vehicles + +The core idea of SDV is to make software the primary differentiating factor of a vehicle, enabling continuous feature updates via Over-The-Air (OTA) technology. This approach allows manufacturers to shorten development cycles while continuously improving safety and performance after a vehicle is released. Moreover, SDV promotes the adoption of Service-Oriented Architecture (SOA), enabling modular and scalable software that integrates seamlessly with cloud services. + +However, this transition introduces new challenges, particularly in software development and validation. The traditional V-model development process struggles to meet SDV demands since defects are often detected late in development, leading to costly fixes. As a result, Shift-Left has become a crucial strategy to address these challenges. + +One useful Arm Automotive [landing page](https://www.arm.com/markets/automotive/software-defined-vehicles) that you can read. + +## Shift-Left: Detecting Issues Early to Enhance Development Efficiency + +Shift-Left refers to moving testing, validation, and security assessments earlier in the development process to reduce costs and improve reliability. In the SDV context, this means incorporating software architecture design, virtual testing, and automated validation in the early stages to ensure the final product meets safety and performance requirements. + +The key benefits of Shift-Left include: + +- Reduced Development Costs: Early defect detection minimizes time and resources spent on late-stage fixes. + +- Accelerated Development: Continuous Integration and Continuous Deployment (CI/CD) speed up software releases. + +- Improved System Reliability: Simulation and virtual testing enhance software quality and safety. + +However, Shift-Left requires appropriate tools and frameworks to support its implementation; otherwise, it can increase testing complexity. This is where SOAFEE (Scalable Open Architecture for Embedded Edge) plays a critical role. + +Check this [blog](https://newsroom.arm.com/blog/automotive-virtual-platforms) understand how to use virtual platforms enable the automotive industry to accelerate the silicon and software development process through virtual prototyping. + +## SOAFEE: A Standardized Solution for SDV Development + +SOAFEE, an open architecture initiative led by Arm and industry partners, aims to provide a unified framework for software-defined vehicles. It leverages cloud-native technologies and is optimized for embedded environments, enabling developers to adopt modern DevOps workflows to accelerate software development. + +SOAFEE addresses several key challenges: + +- Consistent Development Environment: A standardized abstraction layer allows developers to build and test software across different hardware platforms. + +- Support for Virtualization and Containerization: Enables software testing in virtual machines or containers, facilitating flexible deployment and updates. + +- Enhanced Security and Functional Safety Testing: Built-in security mechanisms and best practices ensure reliability across different use cases. + +With SOAFEE, developers can more effectively adopt Shift-Left methodologies, reducing development bottlenecks and improving software quality. Furthermore, SOAFEE promotes smoother collaboration between different suppliers, fostering an ecosystem for SDV software development. + +As the Software-Defined Vehicle paradigm gains traction, the automotive industry is transitioning toward a software-driven future. To meet the demands of rapid iteration and high-quality standards, development teams must adopt a Shift-Left approach, shifting testing and validation earlier to minimize costs and risks. However, this transition requires the right tools and frameworks, and SOAFEE emerges as the ideal solution to address these challenges. + +With the adoption of SOAFEE, automotive software development will become more standardized and efficient, enabling companies to realize the vision of SDVs faster while delivering a safer, smarter, and more flexible vehicle experience. + +Visit [SOAFEE](https://www.soafee.io/) website to find more detail. + +In the following sections, you will explore a Shift-Left demonstration example that leverages SOAFEE to enable early deployment of autonomous driving software before the hardware is ready. diff --git a/content/learning-paths/automotive/openadkit1_container/2_automotive_softwares.md b/content/learning-paths/automotive/openadkit1_container/2_automotive_softwares.md new file mode 100644 index 0000000000..a9fa5775f6 --- /dev/null +++ b/content/learning-paths/automotive/openadkit1_container/2_automotive_softwares.md @@ -0,0 +1,54 @@ +--- +title: Essential Automotive Software Technologies +weight: 3 + +### FIXED, DO NOT MODIFY +layout: learningpathall +--- + +Before diving into the Deep Dive section of this learning path, I would like to first introduce a few essential software technologies that you need to understand. + +## Robot Operating System 2 (ROS 2) + +Robot Operating System 2 (ROS 2) is an open-source robotics middleware designed to provide a flexible, scalable, and real-time capable framework for robot development. It builds upon the foundations of ROS 1, addressing limitations in distributed computing, security, and multi-robot collaboration. ROS 2 is widely used in autonomous systems, industrial automation, and research applications. + +Key Features of ROS 2: +- **Cross-Platform Support**: Runs on Linux, Windows, and real-time operating systems (RTOS), ensuring flexibility in deployment. + +- **Real-Time Capabilities**: Uses Data Distribution Service (DDS) for efficient inter-process communication, enabling real-time performance. + +- **Enhanced Security & Reliability**: Provides encrypted communication, deterministic scheduling, and built-in fault tolerance. + +- **Multi-Robot & Distributed System Support**: Enables large-scale robotic systems and cloud-based robotics applications. + +- **Modular and Scalable Architecture**: Uses a node-based system where different components operate independently. + +Applications of ROS 2: + +- ROS 2 is used in autonomous vehicles, robotic arms, drones, and medical robots. It supports simulation tools like Gazebo and integrates with AI frameworks for advanced robotics applications. + +- ROS 2’s enhanced performance and flexibility make it a crucial enabler for the future of robotics, providing developers with a powerful platform for building intelligent, autonomous systems. + +Arm’s computing platform fully supports ROS 2 operations. You can use this [link](/install-guides/ros2/) to learn how to install it on an Arm-based machine. + +## Autoware Open AD Kit + +The [Open AD Kit](https://autoware.org/open-ad-kit/), the first SOAFEE blueprint, is a collaborative initiative within the [Autoware](https://autoware.org/) and SOAFEE ecosystems. Developed with contributions from Autoware Foundation members and alliance partners, its goal is to enable Autoware as a fully software-defined platform. + +The Autoware Foundation hosts Autoware, the world’s leading open-source autonomous driving project. + +Autoware, built on ROS, features a modular AD stack with well-defined interfaces and APIs for perception, localization, planning, and control. It supports diverse sensors and hardware, enabling adaptability across vehicle types and applications, from research to commercial deployment. + +Committed to democratizing AD technology, Autoware fosters collaboration among industry, researchers, and developers. By promoting open standards and innovation, the foundation accelerates autonomous driving adoption while ensuring safety, scalability, and real-world usability, driving the future of autonomous mobility through open-source development and ecosystem synergy. + +The Open AD Kit Blueprint has evolved through multiple iterations of containerized Autoware software. It supports both cloud and edge deployments in physical and virtual environments, with OTA updates enabling seamless software upgrades. +The Open AD Kit project continues to be developed at the Open AD Kit working group, and the following are the main goals and principles of the collaborative project: +• Introducing modern cloud-native development and deployment methodologies for the Autoware use +• Introducing mixed-critical orchestration, paving the way for safety and certifiability +• Enabling validation using virtual prototyping platforms to achieve shift-left paradigms +• Providing a consistent production environment to deploy Autoware using hardware abstraction technologies to enable hardware-agnostic solutions + +The Open AD Kit Blueprint has been widely adopted by many ecosystem players to develop their own custom-flavored implementations. The blueprint provides a practical and demonstrable example of building SDV applications, particularly in the autonomous driving domain. Additionally, it serves as a model for creating SOAFEE blueprints, fostering a dynamic ecosystem around them. + +In the following sessions, you will learn how to use the OpenAD Kit autonomous driving simulation environment to run SOAFEE within container and facilitate communication through ROS 2. + diff --git a/content/learning-paths/automotive/openadkit1_container/3_setup_openadkit.md b/content/learning-paths/automotive/openadkit1_container/3_setup_openadkit.md new file mode 100644 index 0000000000..d4c6997760 --- /dev/null +++ b/content/learning-paths/automotive/openadkit1_container/3_setup_openadkit.md @@ -0,0 +1,110 @@ +--- +title: Setup OpenAD Kit +weight: 4 + +### FIXED, DO NOT MODIFY +layout: learningpathall +--- + +## Execute Autoware Open AD Kit on Arm platform + +Leveraging the high-performance computing power of Arm Neoverse CPUs and its comprehensive software ecosystem, you can run automotive software simulations on any Neoverse computing platforms. + +This learning path can be seamlessly deployed in two type of development environments: Arm Cloud Instances and On-Premise servers. +This example has been tested on [AWS EC2](https://aws.amazon.com/ec2/) and [Ampere Altra workstation](https://www.ipi.wiki/products/ampere-altra-developer-platform), allowing you to choose the most suitable setup based on your needs. + +## Installation + +This learning path requires Docker to run OpenAD Kit. +You can refer to [here](https://learn.arm.com/install-guides/docker/) to learn how to install Docker on an Arm platform. + +First, verify whether Docker is installed on your development environment by running: + +```bash +docker --version +``` + +If Docker is installed, it will display version information similar to the output below: + +```output +Docker version 27.2.0, build 3ab4256 +``` + +Clone the demo repository using: + +```bash +git clone https://github.com/autowarefoundation/openadkit_demo.autoware.git +``` + +The project is containerized within three Docker images, so you do not need to install additional software. + + +## Understanding the Open AD Kit Demo Packages + +The Open AD Kit demo consists of three core components: `simulator`, `planning-control`, and `visualizer`, each serving a distinct function. + +### Simulator: Generating the Scenario + +The simulator is responsible for creating a virtual driving environment to test and validate autonomous driving functionalities. It can simulate various driving scenarios, road conditions, and traffic situations, providing a realistic testbed for planning and control modules. + +The Key Functions of Simulator are: + +- Simulates autonomous driving environments +- Generates sensor data (LiDAR, cameras, radar, IMU) +- Publishes vehicle state information (position, speed, heading) via ROS 2 topics for other components to process. +- Feeds data to planning-control for trajectory planning +- Acts as a data source for visualizer to render the simulation + +Interaction with Other Components +- Provides vehicle states and sensor data to planning-control +- Acts as the primary data source for visualizer + +It is an example to starts a new Docker container named `simulator`, ensuring it runs in interactive mode with a terminal and is automatically removed upon stopping, while using a predefined Docker image pulled from the GitHub Container Registry. + +```bash +docker run --name simulator --rm -it ghcr.io/autowarefoundation/demo-packages:simulator +``` + +### Planning-Control + +The planning-control module is responsible for path planning and vehicle control. It uses data from the simulator to determine the optimal path and send control commands (steering, acceleration, braking) back to the simulator. + +The Key Functions of Planning-Control: +- Receives sensor data and map information from simulator +- Computes motion planning and generates optimal trajectories +- Generates control commands (steering, acceleration, braking) and sends them to the simulator for execution in the virtual environment. +- Acts as the decision-making unit for vehicle movement + +Interaction with Other Components +- Receives sensor inputs and vehicle states from simulator +- Sends planned trajectories and control commands back to simulator +- Feeds trajectory and control data to visualizer for display + +This command starts a new Docker container named `planning-control`, ensuring it runs in interactive mode with a terminal and is automatically removed upon stopping, while using a predefined Docker image pulled from the GitHub Container Registry. Additionally, it connects to the host network to enable seamless ROS 2 communication with other components, such as the simulator and visualizer. + +```bash +docker run --name planning-control --rm -it --network host ghcr.io/autowarefoundation/demo-packages:planning-control +``` + +### Visualizer + +The visualizer provides real-time visualization of the simulation, including vehicle movement, planned trajectories, sensor outputs, and the driving environment. It enables developers to analyze and debug system behavior visually. + +The Key Functions of Visualizer: +- Subscribes to ROS topics from simulator and planning-control +- Displays vehicle position, planned trajectories, and sensor readings +- Uses RViz & VNC for rendering visual outputs +- Supports remote access via Ngrok or VNC + +Interaction with Other Components +- Receives sensor and vehicle state data from simulator +- Receives planned trajectories and control commands from planning-control +- Presents a visual representation of all ROS 2 topic data + +This command starts a new Docker container named `visualizer`, ensuring it runs in interactive mode with a terminal and is automatically removed upon stopping. It maps port 6080 from the container to the host, enabling remote visualization via a web browser, allowing users to view real-time simulation data using VNC-based visualization tools. + +```bash +docker run --name visualizer --rm -it -p 6080:6080 ghcr.io/autowarefoundation/demo-packages:visualizer +``` + +After gaining a basic understanding of OpenAD Kit, the next section will guide you you through running three containers simultaneously on a single physical machine. diff --git a/content/learning-paths/automotive/openadkit1_container/4_run_openadkit.md b/content/learning-paths/automotive/openadkit1_container/4_run_openadkit.md new file mode 100644 index 0000000000..b2d9eaa649 --- /dev/null +++ b/content/learning-paths/automotive/openadkit1_container/4_run_openadkit.md @@ -0,0 +1,174 @@ +--- +title: Open AD Kit Demo +weight: 5 + +### FIXED, DO NOT MODIFY +layout: learningpathall +--- + +## Execute Autoware Open AD Kit by Docker Compose + +Open AD Kit leverages Docker Compose technology to integrate all container initialization and corresponding configurations, allowing you to start with all the settings from the previous session without any modifications. + +That said, we can still gain a deeper understanding of the system by examining the `docker/docker-compose.yml` file. + +The script first starts the Visualizer service in detached mode, followed by the continuous execution of Planning & Simulation. The detailed ROS commands are defined in the docker/docker-compose.yml file. + + +### Visualizer Configuration + +Similar to the example in the previous session, this Docker Compose service configures and runs a visualization tool (Visualizer) within a Docker container. It renders real-time simulation data using RViz and allows remote access via VNC and Ngrok. + +The `visualizer` service maps: + +- **volume `./etc/simulation:/autoware/scenario-sim`** + + The volume mapping `./etc/simulation:/autoware/scenario-sim` mounts a local directory (./etc/simulation) to a specific path inside the container (/autoware/scenario-sim). This means that files stored in the ./etc/simulation directory on the host machine will be accessible from inside the container at /autoware/scenario-sim. + +- **Port `6080:6080`** + + In the Autoware visualization environment, the 6080:6080 port mapping is used to enable web-based VNC remote desktop access, allowing users to interact with tools like Rviz directly from their browser without needing an external VNC client. + + Inside the container, VNC is enabled via the `VNC_ENABLED=true` environment variable, ensuring that the VNC server is running. The VNC server listens on port 6080, making it accessible through a web-based interface, which simplifies remote monitoring and control of autonomous driving simulations, improving development and testing efficiency. + + Enable VNC-based remote visualization to interact with the Autoware environment remotely. + To access the visualization interface: + - On the same machine, open: `http://localhost:6080` + - From another device, use: `http://:6080` + +```yml + visualizer: + image: ghcr.io/autowarefoundation/demo-packages:visualizer + container_name: visualizer + volumes: + - ./etc/simulation:/autoware/scenario-sim + ports: + - 6080:6080 + - 5999:5999 + environment: + - ROS_DOMAIN_ID=88 + - VNC_ENABLED=true + - RVIZ_CONFIG=/autoware/scenario-sim/rviz/scenario_simulator.rviz + - NGROK_AUTHTOKEN=${NGROK_AUTHTOKEN} + - NGROK_URL=${NGROK_URL} +``` + + +### Planning-Control Module +The second Docker Compose service defines the `planning-control` module within a simulation environment. The planning-control container is responsible for Motion planning, Trajectory generation, Vehicle control + +One key aspect to mention is the depends_on directive. +To ensure that planning-control receives sensor data from the simulator, use depends_on to make sure the simulator service starts before planning-control begins execution. + +ROS2 command: +The command starts the planning_simulator.launch.xml launch file, which initializes the motion planning module: +- map_path:=/autoware/scenario-sim/map → Loads the simulation map. +- vehicle_model:=sample_vehicle → Uses a predefined vehicle model for testing. +- sensor_model:=sample_sensor_kit → Loads sensor configurations for perception. +- scenario_simulation:=true → Enables scenario-based simulation. +- rviz:=false → Disables RViz visualization inside this container. +- perception/enable_traffic_light:=false → Disables traffic light recognition for this test. + + +```yml + planning-control: + image: ghcr.io/autowarefoundation/demo-packages:planning-control + container_name: planning-control + depends_on: + - simulator + volumes: + - ./etc/simulation:/autoware/scenario-sim + - $CONF_FILE:/opt/autoware/share/autoware_launch/config/planning/scenario_planning/lane_driving/behavior_planning/behavior_path_planner/autoware_behavior_path_static_obstacle_avoidance_module/static_obstacle_avoidance.param.yaml + - $COMMON_FILE:/opt/autoware/share/autoware_launch/config/planning/scenario_planning/common/common.param.yaml + environment: + - ROS_DOMAIN_ID=88 + - RMW_IMPLEMENTATION=rmw_cyclonedds_cpp + command: > + ros2 launch autoware_launch planning_simulator.launch.xml + map_path:=/autoware/scenario-sim/map + vehicle_model:=sample_vehicle + sensor_model:=sample_sensor_kit + scenario_simulation:=true + rviz:=false + perception/enable_traffic_light:=false +``` + +### Simulator Module + +The final Docker Compose service defines the `simulator` module. The simulator is responsible for creating a virtual driving environment, generating sensor data, and providing vehicle state information to other components such as planning-control and visualizer. + +Maps local directory (./etc/simulation) to /autoware/scenario-sim inside the container. + +ROS2 command: +The following command starts the scenario_test_runner.launch.py launch file, initializing the Autoware simulation: + +- scenario:=/autoware/scenario-sim/scenario/yield_maneuver_demo.yaml → Specifies the scenario configuration file. +- sensor_model:=sample_sensor_kit → Uses a predefined sensor configuration. +- vehicle_model:=sample_vehicle → Uses a sample vehicle model. +- global_frame_rate:=20 → Sets the simulation frame rate to 20 FPS. +- launch_rviz:=false → Prevents RViz from launching in the container. + +```yml + simulator: + image: ghcr.io/autowarefoundation/demo-packages:simulator + container_name: simulator + volumes: + - ./etc/simulation:/autoware/scenario-sim + environment: + - ROS_DOMAIN_ID=88 + - RMW_IMPLEMENTATION=rmw_cyclonedds_cpp + command: > + ros2 launch scenario_test_runner scenario_test_runner.launch.py + record:=false + scenario:=/autoware/scenario-sim/scenario/yield_maneuver_demo.yaml + sensor_model:=sample_sensor_kit + vehicle_model:=sample_vehicle + initialize_duration:=90 + global_timeout:=$TIMEOUT + global_frame_rate:=20 + launch_autoware:=false + launch_rviz:=false +``` + +### Execute Planning Visualizer Demo + +To start the Planning Visualizer Demo, execute the following script: + +```bash +./docker/run.sh +``` + +This Bash script sets up environment variables and orchestrates the execution of Open AD Kit's visualizer, planning-control, and simulator using the previously mentioned Docker Compose setup. The script runs in a loop, continuously testing two different planning configurations: CONF_FILE_FAIL and CONF_FILE_PASS. + +Once the script starts successfully, you will see a similar output. +You can then use your browser to monitor the simulation data in real-time. + +![img1 alt-text#center](vnc_address.png "Figure 1: Execute run.sh") + +Now you can use the browser to access visualization at the above's URLs: +In this example is http://34.244.98.151:6080/vnc.html + +{{% notice Note %}} +Ensure that the server allows your IP address and port 6080 to connect. +{{% /notice %}} + +To access the visualizer: +1. Open a web browser and go to: `http://:6080/vnc.html` +2. Click **Connect** on the VNC login screen. +![img2 alt-text#center](openadkit_connect.jpg "Figure 2: Connect VNC") +3. Enter the default VNC password: **"openadkit"**. +![img3 alt-text#center](openadkit_passwd.jpg "Figure 3: Input VNC password") + +You are now entered the OpenAD Kit simulation environment. + +This demo will continuously repeat the two scenarios. +- **fail_static_obstacle_avoidance.param.yaml**: In the first scenario, the vehicle remains stationary behind the obstacle. +- **pass_static_obstacle_avoidance.param.yaml**: In the second scenario, the vehicle is permitted to change lanes to maneuver around the obstacle. + +The vehicle starts from a stationary position, moves along the road, and stops when there is a vehicle ahead, waiting for the obstruction to clear before proceeding. + +After each simulation run, it will automatically restart after 90 seconds. You can use the mouse to adjust different viewing angles for observation. + +![img4 alt-text#center](openadkit_1.gif "Figure 4: Simulation") + +Congratulations! You have successfully executed the OpenAD Kit demo. diff --git a/content/learning-paths/automotive/openadkit1_container/_index.md b/content/learning-paths/automotive/openadkit1_container/_index.md new file mode 100644 index 0000000000..ce979389a8 --- /dev/null +++ b/content/learning-paths/automotive/openadkit1_container/_index.md @@ -0,0 +1,49 @@ +--- +title: Deploying Mixed-Criticality Autonomous Driving software using Arm containers + +minutes_to_complete: 60 + +who_is_this_for: This is an introductory topic for automotive developers, aimed at helping them accelerate autonomous driving software development before the automotive computing hardware board is fully ready. + +learning_objectives: + - Introduction to the SOAFEE architecture and its role in supporting Shift-Left software development strategies to optimize the autonomous driving development process. + - Overview of the Autoware OpenADKit simulation environment. + - Running containerized workloads on Arm Neoverse V3AE with Docker, supporting execution on both cloud-based and on-premise servers. + - Exploring advanced configurations and future development prospects. +prerequisites: + - An Arm-based Neoverse cloud instance, or a local Arm Neoverse Linux computer with at least 16 CPUs and 32GB of RAM. + - Familiarity with Docker operation. + +author: Odin Shen + +### Tags +skilllevels: Introductory +subjects: Containers and Virtualization +armips: + - Neoverse V3AE +tools_software_languages: + - Python + - Docker + - ROS2 +operatingsystems: + - Linux + + +further_reading: + - resource: + title: ROS2 installation + link: https://learn.arm.com/install-guides/ros2/ + type: documentation + - resource: + title: AutoWare OpenAD Kit deom project + link: https://github.com/autowarefoundation/openadkit_demo.autoware/ + type: documentation + + + +### FIXED, DO NOT MODIFY +# ================================================================================ +weight: 1 # _index.md always has weight of 1 to order correctly +layout: "learningpathall" # All files under learning paths have this same wrapper +learning_path_main_page: "yes" # This should be surfaced when looking for related content. Only set for _index.md of learning path content. +--- diff --git a/content/learning-paths/automotive/openadkit1_container/_next-steps.md b/content/learning-paths/automotive/openadkit1_container/_next-steps.md new file mode 100644 index 0000000000..c3db0de5a2 --- /dev/null +++ b/content/learning-paths/automotive/openadkit1_container/_next-steps.md @@ -0,0 +1,8 @@ +--- +# ================================================================================ +# FIXED, DO NOT MODIFY THIS FILE +# ================================================================================ +weight: 21 # Set to always be larger than the content in this path to be at the end of the navigation. +title: "Next Steps" # Always the same, html page title. +layout: "learningpathall" # All files under learning paths have this same wrapper for Hugo processing. +--- diff --git a/content/learning-paths/automotive/openadkit1_container/openadkit_1.gif b/content/learning-paths/automotive/openadkit1_container/openadkit_1.gif new file mode 100644 index 0000000000..fcca8aa007 Binary files /dev/null and b/content/learning-paths/automotive/openadkit1_container/openadkit_1.gif differ diff --git a/content/learning-paths/automotive/openadkit1_container/openadkit_connect.jpg b/content/learning-paths/automotive/openadkit1_container/openadkit_connect.jpg new file mode 100644 index 0000000000..c1a1e1923c Binary files /dev/null and b/content/learning-paths/automotive/openadkit1_container/openadkit_connect.jpg differ diff --git a/content/learning-paths/automotive/openadkit1_container/openadkit_passwd.jpg b/content/learning-paths/automotive/openadkit1_container/openadkit_passwd.jpg new file mode 100644 index 0000000000..7f1916bd02 Binary files /dev/null and b/content/learning-paths/automotive/openadkit1_container/openadkit_passwd.jpg differ diff --git a/content/learning-paths/automotive/openadkit1_container/vnc_address.png b/content/learning-paths/automotive/openadkit1_container/vnc_address.png new file mode 100644 index 0000000000..9e31a4b4ea Binary files /dev/null and b/content/learning-paths/automotive/openadkit1_container/vnc_address.png differ