Authors:
(1) Tobias Betz, Technical University of Munich, Germany;
(2) Long Wen, Technical University of Munich, Germany;
(3) Fengjunjie Pan, Technical University of Munich, Germany;
(4) Gemb Kaljavesi, Technical University of Munich, Germany;
(5) Alexander Zuepke, Technical University of Munich, Germany;
(6) Andrea Bastoni, Technical University of Munich, Germany;
(7) Marco Caccamo, Technical University of Munich, Germany;
(8) Alois Knoll, Technical University of Munich, Germany;
(9) Johannes Betz, Technical University of Munich, Germany. Authors: Authors: (1) Tobias Betz, Technical University of Munich, Germany; (2) Long Wen, Technical University of Munich, Germany; (3) Fengjunjie Pan, Technical University of Munich, Germany; (4) Gemb Kaljavesi, Technical University of Munich, Germany; (5) Alexander Zuepke, Technical University of Munich, Germany; (6) Andrea Bastoni, Technical University of Munich, Germany; (7) Marco Caccamo, Technical University of Munich, Germany; (8) Alois Knoll, Technical University of Munich, Germany; (9) Johannes Betz, Technical University of Munich, Germany. Table of Links Abstract and I. Introduction Abstract and I. Introduction II. Related Work II. Related Work III. Microservice Architecture for an Autonomous Driving Software III. Microservice Architecture for an Autonomous Driving Software IV. Experiments IV. Experiments V. Results V. Results VI. Discussion VI. Discussion VII. Conclusion, Acknowledgments, and References VII. Conclusion, Acknowledgments, and References III. MICROSERVICE ARCHITECTURE FOR AN AUTONOMOUS DRIVING SOFTWARE Following the paradigms of software-definedness, the microservice architecture for autonomous driving software is designed to enhance the modularity of the software, enabling efficient development and corresponding software deployment. The core of our architecture is a base image that forms the basic building block for the individual module containers. Specialized containers implementing dedicated functionalities are derived from the base image. The base image can also be used for development as it has the requirements for building the complete code. The base image includes essential installations such as ROS 2 and optional libraries like cuda, cuDNN, and TensorRT, which are not necessarily required by every specialized module. The advantages of using a single base image are manifolds. The configuration and installation of all packages can be centralized using a multi-step process that relies on, e.g., Ansible roles, rosdep installation, and manual configuration. This also simplifies the management of cross-package dependencies, facilitates freezing packages to specific versions, and avoids introducing incompatibilities between (updated) packages and our code.[1] Once configured, the base image rarely needs to be rebuilt. Fig. 2 depicts the build and deployment process of the microservice architecture. We divided the Autoware software into eight dedicated containers based on the functional modules in the software. The containers are sensing, perception, localization, map, planning, control, vehicle, and system. Each container consists of multiple ROS 2 nodes, as shown in Table I. In our architecture, the entire ROS 2 launch structure of Autoware was restructured with the separation of individual modules. The centralized launch package, which listed all packages as dependencies, was split into individual launch packages for each module (with only the needed dependencies). As a result, each module can be built and launched individually. The former central launch package included all launch parameters. In contrast, in our architecture, a separate package was created to contain these launch parameters, which are accessible by the module launch files. Additionally, we integrated the launch parameters to be located outside the containers and mounted during the startup of the respective containers. This approach provides the advantage that changes affecting several module containers, such as the vehicle model, only need to be modified in one location, ensuring consistent parameters for all modules. We developed a continuous integration (CI) pipeline for building custom module containers that ensures compatibility with both x86 and aarch64 architectures by using cloud-native hardware resources. The CI pipeline consists of several stages that enable both the creation of the entire software and the targeted creation of individual modules. This approach offers efficiency advantages, eliminating the need to rebuild all containers for each code change. Additionally, it facilitates selective updates and maintenance via a CI pipeline-based multi-stage testing process. Initially, unit tests are conducted, followed by modular tests in which several functions and their interactions are assessed. Due to the modular container structure, a test does not have to be executed repeatedly, but only within the respective container module. We utilize the CI cloud infrastructure to store our built containers in the container registry. The built containers can be seamlessly deployed on both simulation infrastructure and actual vehicles, offering a flexible deployment strategy. Compared to a monolithic architecture, our microservice architecture improves the development and deployment of the software. During development, the software developer only needs to handle the dependencies related to the respective functionality. The building of the software is automatized in the cloud, and the deployment is simplified. This development and deployment workflow of the microservice architecture is successfully used in real vehicle projects [7], [26]. This paper is available on arxiv under CC by 4.0 Deed (Attribution 4.0 International) license. This paper is available on arxiv under CC by 4.0 Deed (Attribution 4.0 International) license. available on arxiv [1] Managing dependencies in ROS 2 is particularly complex and manual optimization, as well as package updates, quickly become a daunting task.

Part of HackerNoon's growing list of open-source research papers, promoting free access to academic material.

Modular Design Is Solving Autonomous Driving's Biggest Challenges

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

A Real-World Latency Study of Microservice Architectures in Autonomous Driving

From AI To IoT: How Technology Developments Are Redefining The Driving Experience

A Real-World Latency Study of Microservice Architectures in Autonomous Driving

12 Methods of Improving Your Monolith Before Making the Jump to Microservices

3 Architectural Design Patterns for Software Development

A Real-World Latency Study of Microservice Architectures in Autonomous Driving

From AI To IoT: How Technology Developments Are Redefining The Driving Experience

A Real-World Latency Study of Microservice Architectures in Autonomous Driving

12 Methods of Improving Your Monolith Before Making the Jump to Microservices

3 Architectural Design Patterns for Software Development

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps