From 0b494f61509bca296b38be175238c5dc5c1218f6 Mon Sep 17 00:00:00 2001 From: mitsudome-r Date: Tue, 8 Feb 2022 22:59:55 +0900 Subject: [PATCH 1/5] docs: add high level autoware design document Signed-off-by: mitsudome-r --- docs/design/index.md | 58 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 58 insertions(+) diff --git a/docs/design/index.md b/docs/design/index.md index 805aa962cc6..9574b2efe97 100644 --- a/docs/design/index.md +++ b/docs/design/index.md @@ -1,3 +1,58 @@ +# Introduction + +Autoware is the world’s first open-source software for autonomous driving systems. The value of Autoware is two-fold. The technology developers of autonomous driving systems can create new components based on Autoware. The service operators of autonomous driving systems, on the other hand, can select appropriate technology components with Autoware. This is enabled by the microautonomy architecture that modularizes its software stack into the core and universe subsystems (modules). + +Note that a module and a component are orthogonal to each other. In general, a module is a unit of functions that can be loaded and unloaded, while a component is a unit of functions that is a part of the system. So the module can be developed using multiple components and the component can be developed using multiple modules. + +The core module contains basic runtimes and technology components that satisfy the basic functionality and capability of sensing, computing, and actuation required for autonomous driving systems. The universe modules are extensions to the core module that can be provided by the technology developers to enhance the functionality and capability of sensing, computing, and actuation. In general, AWF develops and maintains the core module with their architects and leading members through their working groups. Note that AWF may also provide their own universe module through their projects. A key feature of the microautonomy architecture is that the universe modules can be contributed to by any organization and individual. That is, you can even create your universe and make it available for the Autoware community and ecosystem. AWF is responsible for quality control of the universe modules through their development process. As a result, there are multiple types of the universe modules - some are verified and validated by AWF and others are not. It is up to the users of Autoware which universe modules are selected and integrated to build their end applications. + +The interface design is the most essential piece of the microautonomy architecture, which is classified into internal and external interfaces. The Component Interface is designed for the technology components in a universe module to communicate with those in other modules, including the core module, within Autoware internally. The AD API, on the other hand, is designed for the applications of Autoware to access the technology components in the core and universe modules of Autoware externally. Designing solid interfaces, the microautonomy architecture is made possible with our partners, and at the same time is made feasible for our partners. + +A grand challenge of the microautonomy architecture is to achieve real-time capability, which guarantees all the technology components activated in the system to predictably meet timing constraints (given deadlines). In general, it is difficult, if not impossible, to tightly estimate the worst-case execution times (WCETs) of components. In addition, it is also difficult, if not impossible, to tightly estimate the end-to-end latency of components connected by a DAG. Autonomous driving systems based on the microautonomy architecture, therefore, must be designed to be fail-safe but not never-fail. We accept that the timing constraints may be violated (the given deadlines may be missed) as far as the overrun is taken into account. The overrun handlers are two-fold: (i) platform-defined and (ii) user-defined. The platform-defined handler is implemented as part of the platform by default, while the user-defined handler can overwrite it or add a new handler to the system. This is what we call “fail-safe” on a timely basis. + +Requirements and Roadmap + +Goals: +- All open-source. +- Use case driven. +- Real-time (predictable) framework with overrun handling. +- Code quality. + +Non-goals: +- Accuracy of components + +# Architecture + +Core and Universe. + +Autoware provides the runtimes and technology components by open-source software. The runtimes are based on the Robot Operating System (ROS). The technology components are provided by contributors, which include, but are not limited to: + - Sensing + - Camera Component + - LiDAR Component + - RADAR Component + - GNSS Component + - Computing + - Localization Component + - Perception Component + - Planning Component + - Control Component + - Logging Component + - System Monitoring Component + - Actuation + - DBW Component + - Tools + - Simulator Component + - Mapping Component + - Remote Component + - ML Component + - Annotation Component + - Calibration Component + + +# Concern, Assumption, and Limitation + +The downside of the microautonomy architecture is that the computational performance of end applications is sacrificed due to its data path overhead attributed to functional modularity. In other words, the trade-off characteristic of the microautonomy architecture exists between computational performance and functional modularity. This trade-off problem can be solved technically by introducing real-time capability. This is because autonomous driving systems are not really designed to be real-fast, that is, low-latency computing is nice-to-have but not must-have. The must-have feature for autonomous driving systems is that the latency of computing is predictable, that is, the systems are real-time. As a whole, we can compromise computational performance to an extent that is predictable enough to meet the given timing constraints of autonomous driving systems, often referred to as deadlines of computation. + # Design !!! warning @@ -11,3 +66,6 @@ ## AD API ## Configuration management + +# Conclusion + From a06fce34ddcfa8a020e5416974b7228421431284 Mon Sep 17 00:00:00 2001 From: "pre-commit-ci[bot]" <66853113+pre-commit-ci[bot]@users.noreply.github.com> Date: Tue, 8 Feb 2022 14:02:44 +0000 Subject: [PATCH 2/5] ci(pre-commit): autofix --- docs/design/index.md | 45 ++++++++++++++++++++++---------------------- 1 file changed, 23 insertions(+), 22 deletions(-) diff --git a/docs/design/index.md b/docs/design/index.md index 9574b2efe97..116a9bc2ec3 100644 --- a/docs/design/index.md +++ b/docs/design/index.md @@ -13,12 +13,14 @@ A grand challenge of the microautonomy architecture is to achieve real-time capa Requirements and Roadmap Goals: + - All open-source. - Use case driven. - Real-time (predictable) framework with overrun handling. - Code quality. Non-goals: + - Accuracy of components # Architecture @@ -26,28 +28,28 @@ Non-goals: Core and Universe. Autoware provides the runtimes and technology components by open-source software. The runtimes are based on the Robot Operating System (ROS). The technology components are provided by contributors, which include, but are not limited to: - - Sensing - - Camera Component - - LiDAR Component - - RADAR Component - - GNSS Component - - Computing - - Localization Component - - Perception Component - - Planning Component - - Control Component - - Logging Component - - System Monitoring Component - - Actuation - - DBW Component - - Tools - - Simulator Component - - Mapping Component - - Remote Component - - ML Component - - Annotation Component - - Calibration Component +- Sensing + - Camera Component + - LiDAR Component + - RADAR Component + - GNSS Component +- Computing + - Localization Component + - Perception Component + - Planning Component + - Control Component + - Logging Component + - System Monitoring Component +- Actuation + - DBW Component +- Tools + - Simulator Component + - Mapping Component + - Remote Component + - ML Component + - Annotation Component + - Calibration Component # Concern, Assumption, and Limitation @@ -68,4 +70,3 @@ The downside of the microautonomy architecture is that the computational perform ## Configuration management # Conclusion - From 585e66c5cd166c5276c1f67df2591ffb747f054e Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?M=2E=20Fatih=20C=C4=B1r=C4=B1t?= Date: Thu, 24 Mar 2022 13:14:33 +0300 Subject: [PATCH 3/5] docs: improve on the design document MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: M. Fatih Cırıt ci(pre-commit): autofix rearrange headers add suggestions, remove icons --- .../autoware-concepts/core-and-universe.svg | 4 ++ docs/design/autoware-concepts/index.md | 39 +++++++++++++++++- docs/design/index.md | 41 ++++--------------- 3 files changed, 50 insertions(+), 34 deletions(-) create mode 100644 docs/design/autoware-concepts/core-and-universe.svg diff --git a/docs/design/autoware-concepts/core-and-universe.svg b/docs/design/autoware-concepts/core-and-universe.svg new file mode 100644 index 00000000000..a90eac03d2e --- /dev/null +++ b/docs/design/autoware-concepts/core-and-universe.svg @@ -0,0 +1,4 @@ + + + +
Autoware
Autoware
Core
Core
Universe
Universe
Map Server
Map Server
Sensor Drivers
Sensor Drivers
Perception
Perception
Localization
Localization
Planning
Planning
Control
Control
Vehicle Interface
Vehicle Interface
User Interface
User Interface
Prediction
Prediction
Map Server
Map Server
Sensor Drivers
Sensor Drivers
Perception
Perception
Localization
Localization
Planning
Planning
Control
Control
Vehicle Interface
Vehicle Interface
User Interface
User Interface
Prediction
PredictionText is not SVG - cannot display \ No newline at end of file diff --git a/docs/design/autoware-concepts/index.md b/docs/design/autoware-concepts/index.md index 9c0d4c4d235..1c13ad3d65d 100644 --- a/docs/design/autoware-concepts/index.md +++ b/docs/design/autoware-concepts/index.md @@ -1,5 +1,40 @@ # Autoware concepts -!!! warning +Autoware is the world’s first open-source software for autonomous driving systems. Autoware provides value for both The technology developers of autonomous driving systems can create new components based on Autoware. The service operators of autonomous driving systems, on the other hand, can select appropriate technology components with Autoware. This is enabled by the microautonomy architecture that modularizes its software stack into the core and universe subsystems (modules). - Under Construction +## Microautonomy architecture + +Autoware uses a [pipeline architecture](http://www.cs.sjsu.edu/~pearce/modules/patterns/distArch/pipeline.htm) to enable the development of autonomous driving systems. The pipeline architecture used in Autoware consists of components similar to [three-layer-architecture](http://www.flownet.com/gat/papers/tla.pdf). And they run in parallel. The components are designed to be extensible and reusable. And we call it microautonomy architecture. + +![core-and-universe.svg](core-and-universe.svg) + +### The core module + +The Core module contains basic runtimes and technology components that satisfy the basic functionality and capability of sensing, computing, and actuation required for autonomous driving systems. AWF develops and maintains the Core module with their architects and leading members through their working groups. + +### The universe module + +The Universe modules are extensions to the Core module that can be provided by the technology developers to enhance the functionality and capability of sensing, computing, and actuation. AWF provides the base Universe module to extend from. A key feature of the microautonomy architecture is that the Universe modules can be contributed to by any organization and individual. That is, you can even create your Universe and make it available for the Autoware community and ecosystem. AWF is responsible for quality control of the Universe modules through their development process. As a result, there are multiple types of the Universe modules - some are verified and validated by AWF and others are not. It is up to the users of Autoware which Universe modules are selected and integrated to build their end applications. + +## Interface design + +The interface design is the most essential piece of the microautonomy architecture, which is classified into internal and external interfaces. The Component Interface is designed for the technology components in a universe module to communicate with those in other modules, including the core module, within Autoware internally. The AD API, on the other hand, is designed for the applications of Autoware to access the technology components in the core and universe modules of Autoware externally. Designing solid interfaces, the microautonomy architecture is made possible with our partners, and at the same time is made feasible for our partners. + +## Challenges + +A grand challenge of the microautonomy architecture is to achieve real-time capability, which guarantees all the technology components activated in the system to predictably meet timing constraints (given deadlines). In general, it is difficult, if not impossible, to tightly estimate the worst-case execution times (WCETs) of components. + +In addition, it is also difficult, if not impossible, to tightly estimate the end-to-end latency of components connected by a DAG. Autonomous driving systems based on the microautonomy architecture, therefore, must be designed to be fail-safe but not never-fail. We accept that the timing constraints may be violated (the given deadlines may be missed) as far as the overrun is taken into account. The overrun handlers are two-fold: (i) platform-defined and (ii) user-defined. The platform-defined handler is implemented as part of the platform by default, while the user-defined handler can overwrite it or add a new handler to the system. This is what we call “fail-safe” on a timely basis. + +## Requirements and roadmap + +Goals: + +- All open-source. +- Use case driven. +- Real-time (predictable) framework with overrun handling. +- Code quality. + +Non-goals: + +- Accuracy of components diff --git a/docs/design/index.md b/docs/design/index.md index 116a9bc2ec3..a45723aa88f 100644 --- a/docs/design/index.md +++ b/docs/design/index.md @@ -1,29 +1,6 @@ -# Introduction +# Autoware's Design -Autoware is the world’s first open-source software for autonomous driving systems. The value of Autoware is two-fold. The technology developers of autonomous driving systems can create new components based on Autoware. The service operators of autonomous driving systems, on the other hand, can select appropriate technology components with Autoware. This is enabled by the microautonomy architecture that modularizes its software stack into the core and universe subsystems (modules). - -Note that a module and a component are orthogonal to each other. In general, a module is a unit of functions that can be loaded and unloaded, while a component is a unit of functions that is a part of the system. So the module can be developed using multiple components and the component can be developed using multiple modules. - -The core module contains basic runtimes and technology components that satisfy the basic functionality and capability of sensing, computing, and actuation required for autonomous driving systems. The universe modules are extensions to the core module that can be provided by the technology developers to enhance the functionality and capability of sensing, computing, and actuation. In general, AWF develops and maintains the core module with their architects and leading members through their working groups. Note that AWF may also provide their own universe module through their projects. A key feature of the microautonomy architecture is that the universe modules can be contributed to by any organization and individual. That is, you can even create your universe and make it available for the Autoware community and ecosystem. AWF is responsible for quality control of the universe modules through their development process. As a result, there are multiple types of the universe modules - some are verified and validated by AWF and others are not. It is up to the users of Autoware which universe modules are selected and integrated to build their end applications. - -The interface design is the most essential piece of the microautonomy architecture, which is classified into internal and external interfaces. The Component Interface is designed for the technology components in a universe module to communicate with those in other modules, including the core module, within Autoware internally. The AD API, on the other hand, is designed for the applications of Autoware to access the technology components in the core and universe modules of Autoware externally. Designing solid interfaces, the microautonomy architecture is made possible with our partners, and at the same time is made feasible for our partners. - -A grand challenge of the microautonomy architecture is to achieve real-time capability, which guarantees all the technology components activated in the system to predictably meet timing constraints (given deadlines). In general, it is difficult, if not impossible, to tightly estimate the worst-case execution times (WCETs) of components. In addition, it is also difficult, if not impossible, to tightly estimate the end-to-end latency of components connected by a DAG. Autonomous driving systems based on the microautonomy architecture, therefore, must be designed to be fail-safe but not never-fail. We accept that the timing constraints may be violated (the given deadlines may be missed) as far as the overrun is taken into account. The overrun handlers are two-fold: (i) platform-defined and (ii) user-defined. The platform-defined handler is implemented as part of the platform by default, while the user-defined handler can overwrite it or add a new handler to the system. This is what we call “fail-safe” on a timely basis. - -Requirements and Roadmap - -Goals: - -- All open-source. -- Use case driven. -- Real-time (predictable) framework with overrun handling. -- Code quality. - -Non-goals: - -- Accuracy of components - -# Architecture +## Architecture Core and Universe. @@ -51,22 +28,22 @@ Autoware provides the runtimes and technology components by open-source software - Annotation Component - Calibration Component -# Concern, Assumption, and Limitation +## Concern, Assumption, and Limitation The downside of the microautonomy architecture is that the computational performance of end applications is sacrificed due to its data path overhead attributed to functional modularity. In other words, the trade-off characteristic of the microautonomy architecture exists between computational performance and functional modularity. This trade-off problem can be solved technically by introducing real-time capability. This is because autonomous driving systems are not really designed to be real-fast, that is, low-latency computing is nice-to-have but not must-have. The must-have feature for autonomous driving systems is that the latency of computing is predictable, that is, the systems are real-time. As a whole, we can compromise computational performance to an extent that is predictable enough to meet the given timing constraints of autonomous driving systems, often referred to as deadlines of computation. -# Design +## Design !!! warning Under Construction -## Autoware concepts +### Autoware concepts -## Component interfaces +### Component interfaces -## AD API +### AD API -## Configuration management +### Configuration management -# Conclusion +## Conclusion From 6ea145431a7d1d5cc4f78063963d5d261cea3fda Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?M=2E=20Fatih=20C=C4=B1r=C4=B1t?= Date: Thu, 24 Mar 2022 13:26:53 +0300 Subject: [PATCH 4/5] Apply suggestions from code review MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Kenji Miyake <31987104+kenji-miyake@users.noreply.github.com> Signed-off-by: M. Fatih Cırıt --- docs/design/autoware-concepts/index.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/design/autoware-concepts/index.md b/docs/design/autoware-concepts/index.md index 1c13ad3d65d..d1a3bcb1662 100644 --- a/docs/design/autoware-concepts/index.md +++ b/docs/design/autoware-concepts/index.md @@ -8,11 +8,11 @@ Autoware uses a [pipeline architecture](http://www.cs.sjsu.edu/~pearce/modules/p ![core-and-universe.svg](core-and-universe.svg) -### The core module +### The Core module The Core module contains basic runtimes and technology components that satisfy the basic functionality and capability of sensing, computing, and actuation required for autonomous driving systems. AWF develops and maintains the Core module with their architects and leading members through their working groups. -### The universe module +### The Universe module The Universe modules are extensions to the Core module that can be provided by the technology developers to enhance the functionality and capability of sensing, computing, and actuation. AWF provides the base Universe module to extend from. A key feature of the microautonomy architecture is that the Universe modules can be contributed to by any organization and individual. That is, you can even create your Universe and make it available for the Autoware community and ecosystem. AWF is responsible for quality control of the Universe modules through their development process. As a result, there are multiple types of the Universe modules - some are verified and validated by AWF and others are not. It is up to the users of Autoware which Universe modules are selected and integrated to build their end applications. From da9bea90ba905f4073ae1fb2209d9766c61b2c03 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?M=2E=20Fatih=20C=C4=B1r=C4=B1t?= Date: Thu, 24 Mar 2022 14:19:38 +0300 Subject: [PATCH 5/5] more updates based on the meeting discussions MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: M. Fatih Cırıt --- docs/design/autoware-concepts/index.md | 18 +++++++----------- 1 file changed, 7 insertions(+), 11 deletions(-) diff --git a/docs/design/autoware-concepts/index.md b/docs/design/autoware-concepts/index.md index d1a3bcb1662..c5e0a45163b 100644 --- a/docs/design/autoware-concepts/index.md +++ b/docs/design/autoware-concepts/index.md @@ -4,13 +4,13 @@ Autoware is the world’s first open-source software for autonomous driving syst ## Microautonomy architecture -Autoware uses a [pipeline architecture](http://www.cs.sjsu.edu/~pearce/modules/patterns/distArch/pipeline.htm) to enable the development of autonomous driving systems. The pipeline architecture used in Autoware consists of components similar to [three-layer-architecture](http://www.flownet.com/gat/papers/tla.pdf). And they run in parallel. The components are designed to be extensible and reusable. And we call it microautonomy architecture. +Autoware uses a [pipeline architecture](http://www.cs.sjsu.edu/~pearce/modules/patterns/distArch/pipeline.htm) to enable the development of autonomous driving systems. The pipeline architecture used in Autoware consists of components similar to [three-layer-architecture](http://www.flownet.com/gat/papers/tla.pdf). And they run in parallel. There are 2 main modules: the Core and the Universe. The components in these modules are designed to be extensible and reusable. And we call it microautonomy architecture. ![core-and-universe.svg](core-and-universe.svg) ### The Core module -The Core module contains basic runtimes and technology components that satisfy the basic functionality and capability of sensing, computing, and actuation required for autonomous driving systems. AWF develops and maintains the Core module with their architects and leading members through their working groups. +The Core module contains basic runtimes and technology components that satisfy the basic functionality and capability of sensing, computing, and actuation required for autonomous driving systems. AWF develops and maintains the Core module with their architects and leading members through their working groups. Anyone can contribute to the Core but the PR(Pull Request) acceptance criteria is more strict compared to the Universe. ### The Universe module @@ -18,7 +18,7 @@ The Universe modules are extensions to the Core module that can be provided by t ## Interface design -The interface design is the most essential piece of the microautonomy architecture, which is classified into internal and external interfaces. The Component Interface is designed for the technology components in a universe module to communicate with those in other modules, including the core module, within Autoware internally. The AD API, on the other hand, is designed for the applications of Autoware to access the technology components in the core and universe modules of Autoware externally. Designing solid interfaces, the microautonomy architecture is made possible with our partners, and at the same time is made feasible for our partners. +The interface design is the most essential piece of the microautonomy architecture, which is classified into internal and external interfaces. The component interface is designed for the components in a Universe module to communicate with those in other modules, including the Core module, within Autoware internally. The AD(Autonomous Driving) API, on the other hand, is designed for the applications of Autoware to access the technology components in the Core and Universe modules of Autoware externally. Designing solid interfaces, the microautonomy architecture is made possible with our partners, and at the same time is made feasible for our partners. ## Challenges @@ -30,11 +30,7 @@ In addition, it is also difficult, if not impossible, to tightly estimate the en Goals: -- All open-source. -- Use case driven. -- Real-time (predictable) framework with overrun handling. -- Code quality. - -Non-goals: - -- Accuracy of components +- All open-source +- Use case driven +- Real-time (predictable) framework with overrun handling +- Code quality