From 36d4a85982c29c3ef70cefab2050997712f5e8f2 Mon Sep 17 00:00:00 2001 From: "Luetkebohle Ingo (CR/AEX3)" Date: Mon, 15 Oct 2018 13:22:13 +0200 Subject: [PATCH 1/5] Fix my name --- articles/embedded.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/articles/embedded.md b/articles/embedded.md index 62889fbcd..9578c7ed4 100644 --- a/articles/embedded.md +++ b/articles/embedded.md @@ -4,7 +4,7 @@ title: Embedded ROS 2.0 abstract: This article captures requirements, design ideas and related works on a tiny ROS 2.0 stack for microcontrollers. published: true -author: 'In alphabetic order: [Adam Dąbrowski](https://github.com/adamdbrw), [Borja Outerelo](https://github.com/BorjaOuterelo), [Ingo Luetkebohle](https://github.com/iluetkeb), [Ralph Lange](https://github.com/ralph-lange), [Víctor Mayoral Vilches](https://github.com/vmayoral), ... and many more from Embedded ROS 2 Interest Group. Please feel free to add your name.' +author: 'In alphabetic order: [Adam Dąbrowski](https://github.com/adamdbrw), [Borja Outerelo](https://github.com/BorjaOuterelo), [Ingo Lütkebohle](https://github.com/iluetkeb), [Ralph Lange](https://github.com/ralph-lange), [Víctor Mayoral Vilches](https://github.com/vmayoral), ... and many more from Embedded ROS 2 Interest Group. Please feel free to add your name.' --- {:toc} From 3d6bc3507a59451c2c3837d200abe3729a04b674 Mon Sep 17 00:00:00 2001 From: "Luetkebohle Ingo (CR/AEX3)" Date: Mon, 15 Oct 2018 13:34:24 +0200 Subject: [PATCH 2/5] Reformat requirements as table. Call it "wishlist" instead of requirements. --- articles/embedded.md | 27 +++++++++++---------------- 1 file changed, 11 insertions(+), 16 deletions(-) diff --git a/articles/embedded.md b/articles/embedded.md index 9578c7ed4..a44b56a76 100644 --- a/articles/embedded.md +++ b/articles/embedded.md @@ -21,28 +21,23 @@ While standard ROS 2 can run on Linux-class embedded devices, smaller microcontr This article documents requirements, design ideas and related works on this undertaking. -## Requirements +## Wishlist -In this section, we first describe basic requirements to the embedded ROS stack -- as a basis for discussion. This list shall be detailed by the feedback of the community. +Ab initio, a number of things would be great to have. Feel free to add stuff ;-) -* **Seamless integration with ROS 2:** The embedded ROS 2 stack shall integrate seamlessly with standard ROS 2 stacks and nodes running on stronger microprocessors. For a standard ROS 2 node, communication (topics, services) from and to software running on the embedded ROS 2 stack should be transparent. The same should hold for other core concepts such as parameters, graph introspection, and run-time reconfiguration by the node lifecycle. - -* **Portability of ROS 2-based software:** The embedded ROS 2 stack shall resemble or directly use the ROS 2 API -- more precisely the rclcpp API -- to facilitate porting standard ROS 2 nodes to MCUs. - -* **Support of a broad spectrum of device classes and RTOS:** The embedded ROS 2 stack shall support a broad range of MCU device classes, starting from a few tens kilobyte of RAM. This implies suitable abstractions to be able to adapt the stack to specific hardware features/mechanisms as well as to replace modules or layers with optimized implementations. - - Similarly, the stack shall be adaptable to different RTOS (e.g., NuttX, FreeRTOS, Zephyr) and provide abstractions with regard to the application software to facilitate porting application components to between RTOSs. - -* **Support of prevalent communication technologies:** To cover the broad range of use-cases for MCUs in robotics, the embedded ROS 2 stack shall be usable with the default ROS 2 middleware standard DDS, simple (custom) serial communication protocols just as common wireless technologies like Bluetooth Low Energy - -* **High Modularity:** The embedded ROS 2 stack shall be highly modular, not only to allow for adaptation to specific hardware features and different RTOS, but also to allow the integration with existing frameworks and to be able to create customized sub-stacks. For example, it shall be usable in the style of rosserial, thus bringing basically the message serialization to the MCU only. Similarly, it should be possible to derive a sub-stack that provides node graph features and publish/subscribe but no parameters and services, and so on. - -* **MCU-specific core functionalities and mechanisms:** Finally, the embedded ROS 2 stack shall include novel core functionalities and mechanisms that are specific for MCUs. These include power management functionalities and mechanisms for static initialization and memory management. +| Key | Title | Description | +|-----|-------|-------------| +| R-SEAMLESS | **Seamless integration with ROS 2** | The embedded ROS 2 stack shall integrate seamlessly with standard ROS 2 stacks and nodes running on stronger microprocessors. For a standard ROS 2 node, communication (topics, services) from and to software running on the embedded ROS 2 stack should be transparent. The same should hold for other core concepts such as parameters, graph introspection, and run-time reconfiguration by the node lifecycle.| +| R-PORTABILITY | **Portability of ROS 2-based software** | The embedded ROS 2 stack shall resemble or directly use the ROS 2 API -- more precisely the rclcpp API -- to facilitate porting standard ROS 2 nodes to MCUs. | +| R-DEVICES | **Support of a broad spectrum of device classes** | The embedded ROS 2 stack shall support a broad range of MCU device classes, starting from a few tens kilobyte of RAM. This implies suitable abstractions to be able to adapt the stack to specific hardware features/mechanisms as well as to replace modules or layers with optimized implementations.| +| R-RTOS | **Support of a broad spectrum of RTOS(s)** | Similarly, the stack shall be adaptable to different RTOS (e.g., NuttX, FreeRTOS, Zephyr) and provide abstractions with regard to the application software to facilitate porting application components to between RTOSs.| +| R-MW | **Support of prevalent communication technologies** | To cover the broad range of use-cases for MCUs in robotics, the embedded ROS 2 stack shall be usable with the default ROS 2 middleware standard DDS, simple (custom) serial communication protocols just as common wireless technologies like Bluetooth Low Energy | +| R-MODULARITY | **High Modularity** | The embedded ROS 2 stack shall be highly modular, not only to allow for adaptation to specific hardware features and different RTOS, but also to allow the integration with existing frameworks and to be able to create customized sub-stacks. For example, it shall be usable in the style of rosserial, thus bringing basically the message serialization to the MCU only. Similarly, it should be possible to derive a sub-stack that provides node graph features and publish/subscribe but no parameters and services, and so on. +| R-MCU-SPEC | **MCU-specific core functionalities and mechanisms** | Finally, the embedded ROS 2 stack shall include novel core functionalities and mechanisms that are specific for MCUs. These include power management functionalities and mechanisms for static initialization and memory management.| In the EU project OFERA, we compiled a longer list of requirements to an embedded ROS 2 stack, which might serve as a good basis for the discussion. Please see Section 5 in [ofera.eu/deliverables/D1.7_Requirements.pdf](http://ofera.eu/deliverables/D1.7_Requirements.pdf). - ## Prior and on-going works ### ROS2-based approaches From 778a574fd4d9ae9b88b2382b0814dc63723727b1 Mon Sep 17 00:00:00 2001 From: "Luetkebohle Ingo (CR/AEX3)" Date: Mon, 15 Oct 2018 14:19:04 +0200 Subject: [PATCH 3/5] also mark the items as 'wish' (with a w), instead of 'r' for requirement --- articles/embedded.md | 17 +++++++++-------- 1 file changed, 9 insertions(+), 8 deletions(-) diff --git a/articles/embedded.md b/articles/embedded.md index a44b56a76..a2fbf3e90 100644 --- a/articles/embedded.md +++ b/articles/embedded.md @@ -23,17 +23,18 @@ This article documents requirements, design ideas and related works on this unde ## Wishlist -Ab initio, a number of things would be great to have. Feel free to add stuff ;-) +A number of things that would be great to have, lets call it a wishlist... Feel free to add stuff ;-) | Key | Title | Description | |-----|-------|-------------| -| R-SEAMLESS | **Seamless integration with ROS 2** | The embedded ROS 2 stack shall integrate seamlessly with standard ROS 2 stacks and nodes running on stronger microprocessors. For a standard ROS 2 node, communication (topics, services) from and to software running on the embedded ROS 2 stack should be transparent. The same should hold for other core concepts such as parameters, graph introspection, and run-time reconfiguration by the node lifecycle.| -| R-PORTABILITY | **Portability of ROS 2-based software** | The embedded ROS 2 stack shall resemble or directly use the ROS 2 API -- more precisely the rclcpp API -- to facilitate porting standard ROS 2 nodes to MCUs. | -| R-DEVICES | **Support of a broad spectrum of device classes** | The embedded ROS 2 stack shall support a broad range of MCU device classes, starting from a few tens kilobyte of RAM. This implies suitable abstractions to be able to adapt the stack to specific hardware features/mechanisms as well as to replace modules or layers with optimized implementations.| -| R-RTOS | **Support of a broad spectrum of RTOS(s)** | Similarly, the stack shall be adaptable to different RTOS (e.g., NuttX, FreeRTOS, Zephyr) and provide abstractions with regard to the application software to facilitate porting application components to between RTOSs.| -| R-MW | **Support of prevalent communication technologies** | To cover the broad range of use-cases for MCUs in robotics, the embedded ROS 2 stack shall be usable with the default ROS 2 middleware standard DDS, simple (custom) serial communication protocols just as common wireless technologies like Bluetooth Low Energy | -| R-MODULARITY | **High Modularity** | The embedded ROS 2 stack shall be highly modular, not only to allow for adaptation to specific hardware features and different RTOS, but also to allow the integration with existing frameworks and to be able to create customized sub-stacks. For example, it shall be usable in the style of rosserial, thus bringing basically the message serialization to the MCU only. Similarly, it should be possible to derive a sub-stack that provides node graph features and publish/subscribe but no parameters and services, and so on. -| R-MCU-SPEC | **MCU-specific core functionalities and mechanisms** | Finally, the embedded ROS 2 stack shall include novel core functionalities and mechanisms that are specific for MCUs. These include power management functionalities and mechanisms for static initialization and memory management.| +| W-SEAMLESS | **Seamless integration with ROS 2** | The embedded ROS 2 stack shall integrate seamlessly with standard ROS 2 stacks and nodes running on stronger microprocessors. For a standard ROS 2 node, communication (topics, services) from and to software running on the embedded ROS 2 stack should be transparent. The same should hold for other core concepts such as parameters, graph introspection, and run-time reconfiguration by the node lifecycle.| +| W-PORTABILITY | **Portability of ROS 2-based software** | The embedded ROS 2 stack shall resemble or directly use the ROS 2 API -- more precisely the rclcpp API -- to facilitate porting standard ROS 2 nodes to MCUs. | +| W-DEVICES | **Support of a broad spectrum of device classes** | The embedded ROS 2 stack shall support a broad range of MCU device classes, starting from a few tens kilobyte of RAM. This implies suitable abstractions to be able to adapt the stack to specific hardware features/mechanisms as well as to replace modules or layers with optimized implementations.| +| W-RTOS | **Support of a broad spectrum of RTOS(s)** | Similarly, the stack shall be adaptable to different RTOS (e.g., NuttX, FreeRTOS, Zephyr) and provide abstractions with regard to the application software to facilitate porting application components to between RTOSs.| +| W-MW | **Support of prevalent communication technologies** | To cover the broad range of use-cases for MCUs in robotics, the embedded ROS 2 stack shall be usable with the default ROS 2 middleware standard DDS, simple (custom) serial communication protocols just as common wireless technologies like Bluetooth Low Energy | +| W-MODULARITY | **High Modularity** | The embedded ROS 2 stack shall be highly modular, not only to allow for adaptation to specific hardware features and different RTOS, but also to allow the integration with existing frameworks and to be able to create customized sub-stacks. For example, it shall be usable in the style of rosserial, thus bringing basically the message serialization to the MCU only. Similarly, it should be possible to derive a sub-stack that provides node graph features and publish/subscribe but no parameters and services, and so on. +| W-CONTROL | **Support control-oriented applications** | MCUs are great for control, and micro-ROS should be as well. This usually means hard real-time performance with low jitter and small response times. | +| W-MCU-SPEC | **MCU-specific core functionalities and mechanisms** | Finally, the embedded ROS 2 stack shall include novel core functionalities and mechanisms that are specific for MCUs. These include power management functionalities and mechanisms for static initialization and memory management.| In the EU project OFERA, we compiled a longer list of requirements to an embedded ROS 2 stack, which might serve as a good basis for the discussion. Please see Section 5 in [ofera.eu/deliverables/D1.7_Requirements.pdf](http://ofera.eu/deliverables/D1.7_Requirements.pdf). From 1f9efd9ef9f1ed57f6cf32bb19af2b8b5dd0ab9d Mon Sep 17 00:00:00 2001 From: "Luetkebohle Ingo (CR/AEX3)" Date: Mon, 15 Oct 2018 14:19:21 +0200 Subject: [PATCH 4/5] initial questions and actions --- articles/embedded.md | 31 +++++++++++++++++++++++++++++++ 1 file changed, 31 insertions(+) diff --git a/articles/embedded.md b/articles/embedded.md index a2fbf3e90..8decad55e 100644 --- a/articles/embedded.md +++ b/articles/embedded.md @@ -38,6 +38,37 @@ A number of things that would be great to have, lets call it a wishlist... Feel In the EU project OFERA, we compiled a longer list of requirements to an embedded ROS 2 stack, which might serve as a good basis for the discussion. Please see Section 5 in [ofera.eu/deliverables/D1.7_Requirements.pdf](http://ofera.eu/deliverables/D1.7_Requirements.pdf). +## Questions + +To determine how feasible that is, and to come up with the actual requirements and/or design, a few questions come to mind. I've cross-referenced them to the relevant wishlist items (most of the there's more than one -- this suggests areas where trade-offs may be required, or alternatives pursued). + +| Key | Related Wish | Question | +|-----|-------------|----------| +| Q-RTOS | W-RTOS, W-PORTABILITY | Which RTOS(s) do we use as the basis? | +| Q-BUILD | W-RTOS, W-PORTABILITY | How do we handle the RTOS(s) respective build-systems? | +| Q-LANG | W-PORTABILITY | Which language should be used, and at what spec level? | +| Q-API | W-PORTABILITY, W-MODULARITY | How should the API look in general?| +| Q-PERF | W-PORTABILITY, W-DEVICES, W-CONTROL | What are the performance implications of the API?| +| Q-MIDDLEWARE | W-MW | Which communication/middleware technology is used?| +| Q-MCU-SPEC | W-DEVICES, W-MCU-SPEC, W-CONTROL | Which MCU-specific features do we offer in the external API?| + +## Actions + +> *TODO: Maybe don't call this action, but "fact finding" or the like?* + +To answer these questions, both the OFERA EU project as well as several others have already undertaken or are planning exploratory work. + +*Meta-Note*: Please only add a short description here, linking to more detailed pages if necessary. + +| Key | Related Question | Action | Description | Links | +|-----|------------------|--------|-------------|-------| +| A-RTOS | Q-RTOS | RTOS Proof-of-Concept | Provide a proof-of-concept RTOS. In the OFERA project, we chose NuttX, because it is largely POSIX compatible and thus eases porting. There are also experiments based on RIOT and FreeRTOS | TODO | +| A-BUILD-META | Q-BUILD | Meta-Build | Explores a meta-build approach to transform ROS 2 CMakeLists.txt to RTOS-specific build instructions. | TODO | +| A-BUILD-NUTTX | Q-BUILD | NuttX-specific build | OFERA has integrated (parts of) micro-ROS directly as an app in the NuttX build. |TODO | +| A-BUILD-ANDROID | Q-BUILD | Arduino Build | Robotis has explored building all the libraries using the Arduino IDE. This required some manual changes and thus does not scale, but can get you off the ground. | TODO | +| A-NUTTX-LIBCXX | Q-LANG | C++11/higher support for NuttX | Build libxx from the LLVM project on NuttX, as a pre-requisite to building rclcpp. | TODO | +| A-PERF-RCLCPP-RESOURCE | Q-PERF | Determine resource use of rclcpp | | TODO | + ## Prior and on-going works From 0d98ce23098b2661524b342c3c373896084430ec Mon Sep 17 00:00:00 2001 From: "Luetkebohle Ingo (CR/AEX3)" Date: Tue, 16 Oct 2018 07:05:25 +0200 Subject: [PATCH 5/5] Do not use continuation words in the table. Split 'MCU-SPEC'. Fix ANDROID->ARDUINO --- articles/embedded.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/articles/embedded.md b/articles/embedded.md index 8decad55e..f7bca61db 100644 --- a/articles/embedded.md +++ b/articles/embedded.md @@ -29,12 +29,13 @@ A number of things that would be great to have, lets call it a wishlist... Feel |-----|-------|-------------| | W-SEAMLESS | **Seamless integration with ROS 2** | The embedded ROS 2 stack shall integrate seamlessly with standard ROS 2 stacks and nodes running on stronger microprocessors. For a standard ROS 2 node, communication (topics, services) from and to software running on the embedded ROS 2 stack should be transparent. The same should hold for other core concepts such as parameters, graph introspection, and run-time reconfiguration by the node lifecycle.| | W-PORTABILITY | **Portability of ROS 2-based software** | The embedded ROS 2 stack shall resemble or directly use the ROS 2 API -- more precisely the rclcpp API -- to facilitate porting standard ROS 2 nodes to MCUs. | -| W-DEVICES | **Support of a broad spectrum of device classes** | The embedded ROS 2 stack shall support a broad range of MCU device classes, starting from a few tens kilobyte of RAM. This implies suitable abstractions to be able to adapt the stack to specific hardware features/mechanisms as well as to replace modules or layers with optimized implementations.| -| W-RTOS | **Support of a broad spectrum of RTOS(s)** | Similarly, the stack shall be adaptable to different RTOS (e.g., NuttX, FreeRTOS, Zephyr) and provide abstractions with regard to the application software to facilitate porting application components to between RTOSs.| +| W-DEVICES | **Support of a broad spectrum of device classes** | The embedded ROS 2 stack shall support a broad range of MCU device classes, starting from a few tens kilobyte of RAM. | +| W-RTOS | **Support of a broad spectrum of RTOS(s)** | The stack shall be adaptable to different RTOS (e.g., NuttX, FreeRTOS, Zephyr) and provide abstractions with regard to the application software to facilitate porting application components to between RTOSs.| | W-MW | **Support of prevalent communication technologies** | To cover the broad range of use-cases for MCUs in robotics, the embedded ROS 2 stack shall be usable with the default ROS 2 middleware standard DDS, simple (custom) serial communication protocols just as common wireless technologies like Bluetooth Low Energy | -| W-MODULARITY | **High Modularity** | The embedded ROS 2 stack shall be highly modular, not only to allow for adaptation to specific hardware features and different RTOS, but also to allow the integration with existing frameworks and to be able to create customized sub-stacks. For example, it shall be usable in the style of rosserial, thus bringing basically the message serialization to the MCU only. Similarly, it should be possible to derive a sub-stack that provides node graph features and publish/subscribe but no parameters and services, and so on. +| W-MODULARITY | **High Modularity** | The embedded ROS 2 stack shall be highly modular, not only to allow for adaptation to specific hardware features and different RTOS, but also to allow the integration with existing frameworks and to be able to create customized sub-stacks. For example, it shall be usable in the style of rosserial, thus bringing basically the message serialization to the MCU only. Similarly, it should be possible to derive a sub-stack that provides node graph features and publish/subscribe but no parameters and services, and so on. | | W-CONTROL | **Support control-oriented applications** | MCUs are great for control, and micro-ROS should be as well. This usually means hard real-time performance with low jitter and small response times. | -| W-MCU-SPEC | **MCU-specific core functionalities and mechanisms** | Finally, the embedded ROS 2 stack shall include novel core functionalities and mechanisms that are specific for MCUs. These include power management functionalities and mechanisms for static initialization and memory management.| +| W-POWER | **Make low-power modes possible** | MCUs are often used in battery-powered applications, and/or in applications with a large amount of standby time. Therefore, the stack should make it easily possible to save power. | +| W-STATIC | **Use static initialization** | Static initialization is less error-prone, easier to analyze, and shifts memory usage from RAM to flash. It is a requirement for going to very small resource use. | In the EU project OFERA, we compiled a longer list of requirements to an embedded ROS 2 stack, which might serve as a good basis for the discussion. Please see Section 5 in [ofera.eu/deliverables/D1.7_Requirements.pdf](http://ofera.eu/deliverables/D1.7_Requirements.pdf). @@ -47,10 +48,9 @@ To determine how feasible that is, and to come up with the actual requirements a | Q-RTOS | W-RTOS, W-PORTABILITY | Which RTOS(s) do we use as the basis? | | Q-BUILD | W-RTOS, W-PORTABILITY | How do we handle the RTOS(s) respective build-systems? | | Q-LANG | W-PORTABILITY | Which language should be used, and at what spec level? | -| Q-API | W-PORTABILITY, W-MODULARITY | How should the API look in general?| -| Q-PERF | W-PORTABILITY, W-DEVICES, W-CONTROL | What are the performance implications of the API?| +| Q-API | W-PORTABILITY, W-MODULARITY, W-STATIC, W-POWER | How should the API look in general?| +| Q-PERF | W-PORTABILITY, W-DEVICES, W-CONTROL, W-STATIC | What are the performance implications of the API?| | Q-MIDDLEWARE | W-MW | Which communication/middleware technology is used?| -| Q-MCU-SPEC | W-DEVICES, W-MCU-SPEC, W-CONTROL | Which MCU-specific features do we offer in the external API?| ## Actions @@ -65,7 +65,7 @@ To answer these questions, both the OFERA EU project as well as several others h | A-RTOS | Q-RTOS | RTOS Proof-of-Concept | Provide a proof-of-concept RTOS. In the OFERA project, we chose NuttX, because it is largely POSIX compatible and thus eases porting. There are also experiments based on RIOT and FreeRTOS | TODO | | A-BUILD-META | Q-BUILD | Meta-Build | Explores a meta-build approach to transform ROS 2 CMakeLists.txt to RTOS-specific build instructions. | TODO | | A-BUILD-NUTTX | Q-BUILD | NuttX-specific build | OFERA has integrated (parts of) micro-ROS directly as an app in the NuttX build. |TODO | -| A-BUILD-ANDROID | Q-BUILD | Arduino Build | Robotis has explored building all the libraries using the Arduino IDE. This required some manual changes and thus does not scale, but can get you off the ground. | TODO | +| A-BUILD-ARDUINO | Q-BUILD | Arduino Build | Robotis has explored building all the libraries using the Arduino IDE. This required some manual changes and thus does not scale, but can get you off the ground. | TODO | | A-NUTTX-LIBCXX | Q-LANG | C++11/higher support for NuttX | Build libxx from the LLVM project on NuttX, as a pre-requisite to building rclcpp. | TODO | | A-PERF-RCLCPP-RESOURCE | Q-PERF | Determine resource use of rclcpp | | TODO |