Prototype Real-time Operating System for UPDATE based on micro-ROS project
- Workload management: mapping event-based execution model in micro-ROS to fixed periodic scheduling scheme( in AUTOSAR) or server-based scheduling
- DDS resource management: DDS and network communication should be wrapped in a RTOS thread
- Event-trigger method: OS manages event trigger logic through OS Event Manager
- Intra/Inter Process Communication: Middleware should be able to choose intra-process, inter-process or remote-process communication automatically
- Low overhead DDS: use embeddedRTPS to replace XRCE-DDS, so that the microcontroller can act as a master node in the DDS network
- Reuse ROS2 and Posix-like API as much as possible
- Callback: is the minimal schedulable workload in ROS2. There are 5 types of callbacks in ROS2: timer, subscription, client, service and waitable callbacks. In this work, we only focus on the support of timer and subscription callbacks, and leave the other functionality support to future work. As mentioned before, a timer callback arrives periodically at a predefined rate, while subscription callbacks follow an event-triggered fashion.
- Node: is a collection of callback functions, organized by application programmers for modularity and composability.
- Topic: is used as a means of communication among different nodes. In ROS2, a node can publish its data to a topic, so that all nodes subscribed to that topic can receive the message. By default, ROS2 kernel provides two kinds of communication mechanisms. DDS provides both inter and intra-process communication. And the intra-process API which resides in ROS2 can provide more efficient intra-process communication.
- Chain:
- Optimized client-library for ROS concepts on microcontrollers The client-library of ROS 2 (rcl) includes the concepts of nodes, publishers/subscriptions, topics, client/service, node graph, lifecycle, actions, parameters etc. Micro-ROS brings all these core concepts onto microcontrollers along with the set of extensions and convenience functions (rclc) allowing implementation of common scheduling patterns from embedded systems. Together, rcl+rclc form a complete clientlibrary in micro-ROS.
- Flexible middleware, considering extremely resource-constraint environment ROS 2 is implemented with DDS as it middleware. Micro-ROS comes with a new DDS for extremely resource-constraint environment, called Micro XRCE-DDS, implemented by eProsima, meeting all the necessary requirements for embedded systems. Micro XRCE-DDS follows a client-server architecture, in which Micro XRCE-DDS Client, running on resource-constraint embedded devices connects to Micro XRCE-DDS Agent, running on larger processors. The Agent is responsible to route the information from clients to DDS world and vice versa.
- Indefectible integration with ROS 2 As explained in the last key feature, micro-ROS nodes running on microcontrollers seamlessly connects to the external ROS 2 system with the help of micro-ROS Agent running on that system. As a result, with the known ROS 2 tools and APIs, micro-ROS nodes could be accessed just as normal ROS nodes.
- Support on any POSIX-compliant RTOS Micro-ROS application can be built and ported on any RTOS such as FreeRTOS, NuttX, Zephyr with POSIX interface. In ROS 2 package, RTOS-specific tools are integrated with a few generic setup scripts that can be run through command line. During the firmware creation step, application developers can choose the RTOS and these scripts will build the framework.
A Executor Task is responsible for collecting the ready callbacks periodically and dispatching callbacks to other Slaver Tasks. So those functionalities should be designed in detail:
-
$Wait_{set}$ update strategy: - Callback dispatching policy:
A Slaver Task is used to fetch ready callback from Dual-buffer with respect to callback priority and execute the corresponding callback function.
- Callback fetching policy:
Each Slaver Task has a Dual-buffer, which is responsible for recording the dispatched callbacks to this Slaver Task. Specifically, a Dual-buffer consists of two FIFO buffers, one for Timer callbacks and the other for Subscription callbacks.
- 设置两条任务链，每条任务链包含一个Timer和两个Subscription，手动为Timer或Subscription对应的callback绑定优先级，设置任务链一内callback的优先级不高于10，任务链二内callback的优先级不低于10，示意图如下：
- 一共两个SlaverTask，设置Task2的优先级高于Task1，Task1处理优先级不高于10的callback，Task2处理优先级不低于10的callback。
- 利用FreeRTOS的队列机制，一个SlaverTask对应一个Dual-buffer，Dual-buffer中包含两个队列，一个队列存储Timer_callback，一个队列存储Subscription_callback，SlaverTask的每次循环，先看timer_queue是否为空，再看subscription_queue是否为空，如果两个队列都为空，则将自身挂起，ExecutorTask每次分发任务时会对SlaverTask进行判断，如果SlaverTask为挂起态，ExecutorTask会将SlaverTask设置为执行态。
- 将任务链一的定时器周期设置为5000ms，任务链二的定时器周期设置为2000ms，运行结果如下：
-
$Wait_{set}$ update strategy: Active$Wait_{set}$ update is the same with micro-ROS. - Callback dispatching policy: Simply put callbacks into different slaver tasks with different priority.
Timer buffer: high priority -> check first Subscriber buffer: low priority
Limitation of Current Implementation: priority in each callback class is not supported. So for each buffer, enqueue and dequeue are both FIFO.
- 每个publisher或subscription拥有一个专属ring_buffer；
- 创建的publisher或subscription依据topic_name连接在一起；
- publisher发布消息时，将消息发送到自己的ring_buffer中，根据注册表将消息复制到对应的所有subscription的ring_buffer中；
- 一个publisher可同时向多个subscription发布消息。
TODO
| RTOS | Platform | Version | Example | Others |
|---|---|---|---|---|
| FreeRTOS | ST Nucleo F446ZE | STM32CubeMX latest | freertos nucleo_f446ze |
micro-ROS utils for STM32CubeMX and STM32CubeIDE |