Follow,Star Public Account Number, don’t miss the wonderful content
Some of my readers should be working on ROS-related tasks, today I will share a micro (lightweight) ROS based on FreeRTOS.
1. About ROS
ROS: Robot Operating System, that is, Robot Operating System.
Unlike ordinary OS, ROS is mainly aimed at robots, based on the operating system, providing a series of libraries and tools to help software developers create robot application software. It provides many functions such as hardware abstraction, device drivers, library functions, visualization, messaging, and package management. ROS follows the BSD open source license.
The designers of ROS describe ROS as “ROS = Plumbing + Tools + Capabilities + Ecosystem”, that is, ROS is a collection of communication mechanisms, tool packages, high-level skills for robots, and robot ecosystems.
2. micro-ROS
The micro-ROS mentioned in this article is a lightweight ROS system optimized based on ROS2, which provides most of the attractive tools and features of the fully deployed ROS 2 ecosystem and has excellent capabilities for embedded and low-resource devices, capable of running on MCU hardware platforms.
Traditionally, even if robots contain many ROS, ROS still stays at the boundary of microcontrollers. They are usually integrated with tools like ROS-serial in the old version of ROS through serial protocols.
Wouldn’t it be great to have all the features of ROS2 and the same API in microcontrollers? That’s exactly what micro-ROS provides – the ROS development ecosystem embedded within the robotic system. micro-ROS allows developers to run ROS 2 nodes close to the hardware level. This makes all hardware peripherals available to the application, allowing it to interact directly with low-level buses such as SPI or I²C to interface with sensors and actuators.
Micro-ROS is a set of layered libraries that can directly reuse ROS 2 libraries or adapt them to the capabilities and needs of resource-constrained devices. Specifically, if we turn to the ROS 2 architecture, the layers maintained by micro-ROS are the ROS Client Library (RCL) and the ROS Middleware Interface (RMW). Similarly, RCLCPP is a C++ abstraction layer on top of RCL, which can be used by micro-ROS application components even though most directly interface with RCL. This layer provides additional functionality with respect to ROS 2 in RCLC, which is a library written in C99, where functionalities similar to those provided by RCLCPP, such as convenience functions or executors, are specifically designed and developed to fit microcontrollers.
Typically, ROS is a system running on top of Linux systems, while this micro-ROS system runs on FreeROS.
This makes micro-ROS compatible with most embedded platforms at both hardware and software levels.
However, the final composition of the micro-ROS architecture is the RMW implementation, which is based on a middleware library called Micro XRCE-DDS. Micro XRCE-DDS is a C/C++ implementation of the DDS-XRCE (DDS for Extreme Resource-Constrained Environments) protocol defined and maintained by the Object Management Group (OMG).
As the name suggests, DDS-XRCE is a wired protocol that allows the introduction of a data-centric publisher-subscriber DDS model into the embedded world. DDS-XRCE relies on a client-server architecture, where the client is a lightweight entity written in C99 that can run on low-resource devices, while the proxy (C++ 11 application) acts as a bridge between the client and the DDS world. The DDS-XRCE protocol is responsible for passing requests and messages between these two entities. Accordingly, the proxy is able to communicate with the DDS global data space via standard DDS wired protocols. In the DDS world, the proxy represents the client by communicating with other DDS participants. This communication is coordinated by the client proxy, which is capable of interacting with all standard DDS entities through a simulated DDS application. The proxy keeps the state of the client in its memory, so that even if the proxy disconnects, it can survive. The communication between the proxy and the client follows a request-response pattern, which is bi-directional and based on operations and responses.
3. Why Choose FreeRTOS?
Due to their lightweight nature, XRCE-DDS client libraries and microROS are easy to run on top of real-time operating systems, allowing them to meet the strict timing requirements posed by their typical target applications, which involve tasks that require deadlines or deterministic responses.
Specifically, FreeRTOS has become one of the first RTOS supported by the micro-ROS project and is thus integrated into its software stack. This allows the reuse of all tools and implementations provided by the FreeRTOS community and partners. Since the micro-ROS software stack is modular, the expectation is to swap software entities.
FreeRTOS is an ideal choice for developing micro ROS and Micro XRCE-DDS applications. First, it provides an independent solution for many different architectures and development tools, written in a very clear and transparent manner, and has a very large user base, ensuring that a large number of FreeRTOS users will be able to integrate their applications with the micro-ROS application. Moreover, it is known for being a highly reliable RTOS. Crucially, FreeRTOS has minimal ROM, RAM, and processing overhead. Typically, the size of the RTOS kernel binary image ranges from 6K to 12K bytes. Since there is competition for resources with the RTOS, this memory is ideal when minimizing the memory footprint of micro-ROS applications on MCUs.
In the following, we will discuss several features provided by FreeRTOS and how micro-ROS takes advantage of them to optimize the required functionalities of the different libraries that make up its stack.
4. Tasks and Scheduler
FreeRTOS provides a minimal set of task entities that, together with the use of the scheduler, provide the necessary tools to achieve determinism in applications. The micro-ROS client libraries (RCL, RCLC, and RCLCPP) access the resources of the RTOS to control scheduling and power management mechanisms, thus providing developers with the possibility to optimize applications.
There are two types of tasks provided by FreeRTOS: standard tasks and idle tasks. The former are created by the user and can be regarded as applications on the RTOS. Crucially, integrating micro-ROS applications into the RTOS as one of these tasks with a given priority. The idle task, on the other hand, is a lower-priority task that only enters the running mode when no other tasks are running. Since microROS is primarily aimed at low-power and IoT devices, these idle tasks and related idle hooks are very suitable for enabling deep sleep states in MCUs. Since the stateless XRCE-DDS client is implemented as middleware in micro-ROS, these deep sleep states may be memory volatile, meaning that due to the connection-oriented middleware wired protocol, deep sleep modes can be used without RAM persistence.
Using the FreeRTOS scheduler, micro-ROS is able to manage the priorities of its main tasks and the tasks responsible for the transport layer. Typically, tasks responsible for the network stack or serial interface must take precedence over micro-ROS applications.
5. Memory Management
One of the most anticipated features provided by FreeRTOS (which is of great interest to micro-ROS developers and users) is the ability to manage the stack and create static stacks. When dealing with the creation of tasks in micro-ROS, stack allocation is typically a critical design decision. FreeRTOS allows fine-grained management of stack sizes, which in turn allows programmers to know how much stack memory is being used during program execution or, for example, determine whether stack memory allocation is in static or dynamic memory, thus determining how to help correctly use memory in MCUs, which is a valuable resource in embedded systems. Crucially, heavy stack usage tasks can be provided for microROS and allocated static stacks to prevent future heap and other task initialization issues.
In this regard, it is worth mentioning that these memory management tools provide an ideal framework for benchmarking the memory footprint of micro-ROS and XRCE-DDS. Specifically, a thorough stack consumption analysis has been conducted to assess the memory consumption of the XRCE-DDS client. The stack is a block of memory that is unknown to the programmer before running the application. To measure it, the FreeRTOS uxTaskGetStackHighWaterMark() function can be used, which returns the amount of unused stack when the XRCE-DDS task stack reaches its maximum during execution. By subtracting this value from the total stack, the peak stack used by the XRCE-DDS application can be obtained. The results obtained by this method are summarized in the report published here.
We also note that since a pluggable dynamic memory management method is used in FreeRTOS, micro-ROS can complete the required interfaces for managing memory. In this way, functions such as calloc() or realloc() have been implemented using heap_4 as a reference. These functions have been wrapped before feeding into the micro-ROS memory management API to analyze dynamic memory consumption.
Similar to the static memory situation, FreeRTOS’s interchangeable dynamic memory management method makes it particularly easy to perform dynamic memory profiling analysis in embedded systems. Indeed, while in other RTOSs, dynamic (de)allocation capabilities are hidden deep within the RTOS or standard libraries, in FreeRTOS, they are exposed to users and easy to customize, thus simplifying the process of handling and controlling dynamic memory usage.
6. Transport Resources
Similar to the way the client support library accesses specific primitives and functionalities of FreeRTOS (such as scheduling mechanisms), the middleware implementation Micro XRCE-DDS requires access to the transport and timing resources of the RTOS to operate properly. Regarding IP transport, in the specific case of FreeRTOS, Micro XRCE-DDS uses the lwIP attachment implemented on this RTOS. lwIP (Lightweight IP) is a widely used open-source TCP/IP stack designed for embedded systems, aimed at reducing resource usage while still providing a complete TCP stack. This makes the use of lwIP particularly suitable for embedded systems and resource-constrained environments targeted by micro-ROS.
In addition to the TCP/IP stack, lwIP has several other important components, such as network interfaces, operating system emulation layers, buffers, and memory management parts. The operating system emulation layer and network interface allow the network stack to be ported to the operating system as it provides a common interface between lwIP code and the operating system kernel.
The integration of FreeRTOS with lwIP is designed from the ground up, with standard and familiar interfaces (Berkeley sockets), and with thread safety, designed to make it as easy to use as possible. Moreover, it can keep buffer management in the portable layer.
Note that the XRCE-DDS client also supports FreeRTOS + TCP network stack. FreeRTOS + TCP is the official FreeRTOS extension library for TCP/IP stack protocol support.
Efforts have also been made to make FreeRTOS + TCP compatible with micro-ROS. This includes support for TCP and UDP connections, which rely on the FreeRTOS + TCP API to achieve the abstraction layer required by the micro XRCE-DDS Client API to be able to communicate with the proxy using these protocols.
Additionally, there is the possibility of using FreeRTOS’s timing measurement capabilities, allowing the XRCE-DDS library to perform time-based tasks, thus making the implementation invisible to the user.
7. Posix Extensions
Another significant reason that allows FreeRTOS to be seamlessly and profitably integrated into micro-ROS is the availability of POSIX extensions. The Portable Operating System Interface (POSIX) is a set of standards specified by the IEEE Computer Society for maintaining compatibility between operating systems. The FreeRTOS Labs provides a FreeRTOS + POSIX layer that implements a subset of the POSIX API.
Indeed, although the micro-ROS middleware has lower POSIX dependencies (only the clock_gettime() function), the entire micro-ROS stack has higher dependencies related to functionalities and type definitions. Additionally, since one of the fundamental principles of the micro-ROS project is to port or reuse code from ROS 2, which is natively coded in Linux (mainly POSIX-compliant operating systems), a certain degree of RTOS that is compatible with Linux is used. POSIX is clearly beneficial as it requires minimal effort to port the code.
To this end, functions like sleep() and usleep() are used. The POSIX type definition dependencies of micro-ROS rely on certain structures that are undefined in the FreeRTOS kernel, such as struct timeval or struct timespec. Some standard type definition and structure files, such as type.h, signal.h, or unistd.h, are also needed to define.
As for errno.h, although it is not implemented in the FreeRTOS + POSIX layer, for compilation purposes, micro-ROS must include some unavailable definitions.
By using the FreeRTOS + FAT library, these definitions should be reconstructed in the micro-ROS stack to ensure full compatibility with FreeRTOS + POSIX. This way, advanced micro-ROS features that depend on file system support, such as logging mechanisms, can be fully supported.
8. Tutorial
How to create and run the first micro-ROS application on the FreeRTOS using the Olimex STM32-E407 evaluation board:
(Public account does not support external links, please copy the link to the browser to open)
9. Finally
In summary, FreeRTOS provides a lightweight and ideal RTOS for running Micro-ROS applications, as it offers a wide range of required functionalities, and in fact, all modular layers that make up the Micro-ROS stack use these functionalities at different levels.
As the user base of micro-ROS and FreeRTOS rapidly expands and compelling use cases surge, it is expected that further integration of micro-ROS with FreeRTOS and the libraries provided by FreeRTOS + will occur in the near future.
Among them, leveraging the FreeRTOS + FAT library seems particularly desirable to add a virtual file system component that allows visualization and management of logging operations just like in a fully deployed ROS 2 ecosystem.
Further utilization of the memory management tools described in the dedicated section is also envisioned to extend the memory profiling of the XRCE-DDS client, thus providing similar analysis for the micro-ROS client.
Another future action planned for the micro-ROS project is to adopt the certified version of FreeRTOS, SafeRTOS.
Last but not least, it seems worth mentioning two very successful cases of hardware integration related to the typical target applications of FreeRTOS and micro-ROS, namely the powerful Crazyflie 2.1 drone and the hardware of the ESP32 MCU. In fact, Crazyflie software can take advantage of several tools and features provided by FreeRTOS. Examples of demonstrations of microROS applications related to this MAV work with FreeRTOS can be understood here. As for the second hardware that integrates natively with FreeRTOS and provides ready-made Wi-Fi antenna and Bluetooth functionality, the latest micro ROS port has been done on that system.
For more content, please refer to:
What Internet of Things Operating Systems Are There in China, Who Dominates?
How to Avoid Buffer Overflow Caused by Standard C Library?
Command Line Compilation and Download of ARM Compilation Tools keil and IAR
Long pressto go to the public account included in the pictureto follow