diff --git a/_data/docs.yml b/_data/docs.yml index 750eb5c7..d42d175d 100644 --- a/_data/docs.yml +++ b/_data/docs.yml @@ -21,6 +21,7 @@ - title: Middleware docs: - concepts/middleware/Micro_XRCE-DDS + - concepts/middleware/memo_prof - concepts/middleware/rosserial - concepts/middleware/IoT diff --git a/_docs/concepts/middleware/Micro_XRCE-DDS/index.md b/_docs/concepts/middleware/Micro_XRCE-DDS/index.md index 44d17049..3094252e 100644 --- a/_docs/concepts/middleware/Micro_XRCE-DDS/index.md +++ b/_docs/concepts/middleware/Micro_XRCE-DDS/index.md @@ -4,6 +4,9 @@ permalink: /docs/concepts/middleware/Micro_XRCE-DDS/ redirect_from: /docs/concepts/middleware/ --- +This page is dedicated to describing the most salient features of [**Micro XRCE-DDS**](https://micro-xrce-dds.docs.eprosima.com/en/latest/index.html), +the default middleware implementation for micro-ROS' rmw layer. + **eProsima Micro XRCE-DDS** is an open-source wire protocol that implements the OMG DDS for e**X**tremely **R**esource **C**onstrained **E**nvironment standard ([DDS-XRCE](https://www.omg.org/spec/DDS-XRCE/)). The aim of the DDS-XRCE protocol is to provide access to the DDS Global-Data-Space from resource-constrained devices. This is achieved thanks to a **client-server** architecture, where low resource devices, called *XRCE Clients*, are connected to a server, called *XRCE Agent*, which acts on behalf of its clients in the DDS Global-Data-Space. @@ -15,41 +18,74 @@ Micro XRCE-DDS is composed by two main elements: * [Micro XRCE-DDS Agent](https://github.com/eProsima/Micro-XRCE-DDS-Agent): a **C++11 out-of-the-box application** which implements the XRCE Agent functionality. * [Micro XRCE-DDS Client](https://github.com/eProsima/Micro-XRCE-DDS-Client): a **C99 library** which implements the XRCE Client side functionality. -Apart of these, Micro XRCE-DDS uses other two components: +In addition, Micro XRCE-DDS uses other two components: * [Micro CDR](https://github.com/eProsima/Micro-CDR): a **de/serialization engine** used in the Client library. -* [Micro XRCE-DDS Gen](https://github.com/eProsima/Micro-XRCE-DDS-Gen): a **code generator tool** used for generating *Micro CDR* de/serialization function and Client apps examples from IDL sources. +* [Micro XRCE-DDS Gen](https://github.com/eProsima/Micro-XRCE-DDS-Gen): a **code generator tool** used for generating *Micro CDR* de/serialization functions and Client apps examples from IDL sources. ## Application -Micro XRCE-DDS is focused on microcontroller applications which require a publisher/subscriber architecture. +Micro XRCE-DDS is focused on microcontroller applications which require to access a publisher/subscriber architecture. Some examples of this kind of applications are those found in sensor networks, IoT or robotics. -On this last regard, some companies such as [Renesas](https://www.sensorsmag.com/iot-wireless/mcus-support-dds-xrce-protocol-for-ros-2) and [ROBOTIS](https://xelnetwork.readthedocs.io/en/latest/) are using Micro XRCE-DDS as the middleware solution. -Furthermore, the [micro-ROS](https://microros.github.io) project, whose target is to put ROS 2 onto microcontroller, has adopted Micro XRCE-DDS as the middleware layer. +Some companies such as [Renesas](https://www.sensorsmag.com/iot-wireless/mcus-support-dds-xrce-protocol-for-ros-2) and [ROBOTIS](https://xelnetwork.readthedocs.io/en/latest/) are using Micro XRCE-DDS as a middleware solution. +Furthermore, the [micro-ROS](https://microros.github.io) project, whose goal is to put ROS 2 onto microcontroller, has adopted Micro XRCE-DDS as its default middleware layer. ## Main Features ### Low Resource Consumption -As it was aforementioned, Micro XRCE-DDS is focused on microcontroller applications. Therefore, the design and implementation of this middleware have been carried out taking into account the memory restriction of this kind of devices. -Proof of this is the fact that Micro XRCE-DDS Client is completely dynamic memory free. -From the point of view of memory footprint, the [latest](https://github.com/eProsima/Micro-XRCE-DDS-Client/releases/tag/v1.0.1) version of this library has a memory consumption of less than **75 KB of Flash memory** and **2.5 KB of RAM** for a complete publisher and subscriber application. +As it was mentioned above, Micro XRCE-DDS is focused on microcontroller applications. Therefore, the design and implementation of this middleware have been carried out taking into account the memory constraints of this kind of devices. +A proof of this is the fact that the XRCE Client is completely dynamic memory free. +From the point of view of the memory footprint, the [latest](https://github.com/eProsima/Micro-XRCE-DDS-Client/releases/latest) version of this library has a memory consumption of less than **75 KB of Flash memory** and around **3 KB of RAM** for a complete publisher and subscriber application handling messages sizes on the order of 512 B. +For more detailed information on the memory consumption as a function of message size, entity number and internal memory management of the middleware library, please refer to the [Micro XRCE-DDS memory profiling](/docs/concepts/middleware/memo_prof/) section. +Moreover, this library is highly configurable thanks to a *profile* concept that enables to choose, add or remove some features in configuration time. That allows customizing the XRCE Client library size, if there are features that are not used. +There are several definitions for configuring and building the Client library at compile-time. +These definitions allow to create a version of the library according to the application requirements, and can be modified in the `client.config` file. +For incorporating the desired configuration, it is necessary to run the `cmake` command every time the definitions change. + +For more information on how to configure micro-ROS by opportunely tuning parameters either in the Micro XRCE-DDS library +orin its rmw implementation [`rmw_microxrcedds`](https://github.com/micro-ROS/rmw-microxrcedds), consult this [tutorial](/docs/tutorials/core/microxrcedds_rmw_configuration/) and the `rmw_microxrcedds` [README](https://github.com/micro-ROS/rmw-microxrcedds#rmw-micro-xrce-dds-implementation). ### Multi-Transport Support -In contrast to other IoT middleware such as MQTT and CoaP, which work over only a particular transport layer, XRCE support multiple transport protocol natively. +As part of the profiles discussed in the previous section, the user can choose between several transport layers to communicate the Clients with the Agent. +Indeed, in contrast to other IoT middleware such as MQTT and CoaP, which work over only a particular transport layer, XRCE supports multiple transport protocols natively. In particular, the latest version of Micro XRCE-DDS support: **UDP**, **TCP** and a custom **Serial** transport protocol. -Apart from this, Micro XRCE-DDS has a transport interface for both Agent and Client which allows to implement custom transport in an straight-forward manner. -This makes the port of Micro XRCE-DDS to different platforms and the addition of new transports a task that any user can undertake. +Apart from this, Micro XRCE-DDS has a transport interface for both Agent and Client which allows to implement custom transports in a straightforward manner. +This makes the port of Micro XRCE-DDS to different platforms and the addition of new transports a seamless task that any user can undertake. ### Multi-Platform Support -Micro XRCE-DDS Client support **Windows**, **Linux** and **NuttX** as embedded RTOS. -On the other hand, Micro XRCE-DDS Agent support Windows and Linux platform. +The XRCE Client supports **FreeRTOS**, **Zephyr** and **NuttX** as embedded RTOS. Moreover, it also runs on **Windows** and **Linux**. +On the other hand, the XRCE Agent supports **Windows** and **Linux**. + +### QoS support + +The XRCE Client library allows the user to use two different approaches for creating DDS entities in the XRCE Agent: + +* By XML (the default option) +* By reference + +When using the default option, users are enabled to create entities either in Reliable or Best-Effort mode, with the XML files written and stored on the Client side. But these QoS configurations may not fit some users' requirements. +For these cases, Micro XRCE-DDS allows to create entities directly on the Agent, where the user can write custom XML QoS as in DDS. +Each entity available on the Agent will be associated to a label, so that the Clients can to create the entities they need +for the communication by just referring to these labels. + +Additionally, using references will also reduce the memory consumption of the Client inside the MCU. +This is because the reference approach allows avoiding to build the parts of the code where XMLs are stored. + +Notice that this mechanism is inherited by micro-ROS which, as a consequence, will be able to leverage the same full set of QoS as ROS 2. +For a comprehensive review on how to use custom QoS in micro-ROS, please visit this [dedicated page](/docs/tutorials/core/create_dds_entities_by_ref/) in the tutorials section. + ## Other links * [Manual at Read the Docs](https://micro-xrce-dds.readthedocs.io/en/latest/) -* [GitHub](https://github.com/eProsima/Micro-XRCE-DDS) - +* [Micro XRCE-DDS on GitHub](https://github.com/eProsima/Micro-XRCE-DDS) +* [XRCE Client on GitHub](https://github.com/eProsima/Micro-XRCE-DDS-Client) +* [XRCE Agent on GitHub](https://github.com/eProsima/Micro-XRCE-DDS-Agent) +* [rmw_microxrcedds on GitHub](https://github.com/micro-ROS/rmw-microxrcedds) +* [Micro XRCE-DDS memory profiling](/docs/concepts/middleware/memo_prof/) +* [Middleware optimization tutorial](/docs/tutorials/core/microxrcedds_rmw_configuration/). +* [How to use custom QoS in micro-ROS](/docs/tutorials/core/create_dds_entities_by_ref/) diff --git a/_docs/concepts/middleware/memo_prof/agent.png b/_docs/concepts/middleware/memo_prof/agent.png new file mode 100644 index 00000000..70aab9c0 Binary files /dev/null and b/_docs/concepts/middleware/memo_prof/agent.png differ diff --git a/_docs/concepts/middleware/memo_prof/diagram.png b/_docs/concepts/middleware/memo_prof/diagram.png new file mode 100644 index 00000000..7d9435fb Binary files /dev/null and b/_docs/concepts/middleware/memo_prof/diagram.png differ diff --git a/_docs/concepts/middleware/memo_prof/index.md b/_docs/concepts/middleware/memo_prof/index.md new file mode 100644 index 00000000..f2babb09 --- /dev/null +++ b/_docs/concepts/middleware/memo_prof/index.md @@ -0,0 +1,131 @@ +--- +title: Micro XRCE-DDS memory profiling +permalink: /docs/concepts/middleware/memo_prof/ +redirect_from: /docs/concepts/middleware/ +--- + +## Abstract + +In this section, we analyze the memory footprint of the Micro XRCE-DDS Client and Agent libraries. In both cases, we consider an application of a given number of publishers and/or subscribers into/from topics of known size. + +As for the Client, we performed the measurements for an app running on the Real Time Operating System (RTOS) [FreeRTOS](https://www.freertos.org/) and on an [Olimex STM32-E407](https://www.olimex.com/Products/ARM/ST/STM32-E407/open-source-hardware) board, and connected by serial transport (UART) to a Micro XRCE-DDS Agent running on a Linux machine. + +As for the Agent, we performed the measurements for a lightweight Agent running on a Linux machine, communicating with a XRCE-DDS Client application running on the same host machine. + +Results show that the total memory consumption of the Client makes this library fit for the same class of low-range microcontrollers targeted by the rosserial protocol. +On the other hand, the lightweight version of the Agent is apt for being compiled on more performant systems only. + +# Table of contents + +* [Memory Profiling of the Micro XRCE-DDS Client on FreeRTOS](#memory-profiling-of-the-micro-xrce-dds-client-on-freertos) + * [Memory and Configurability](#memory-and-configurability) + * [Methodology](#methodology) + * [Results and Discussion](#results-and-discussion) +* [Memory Profiling of the Micro XRCE-DDS Agent on Linux](#memory-profiling-of-the-micro-xrce-dds-agent-on-linux) + * [Available Middleware Implementations for the Agent](#available-middleware-implementations-for-the-agent) + * [Methodology and Results](#methodology-and-results) + +## Memory Profiling of the Micro XRCE-DDS Client on FreeRTOS + +[Micro XRCE-DDS](https://micro-xrce-dds.docs.eprosima.com/en/latest/) target applications are low range Microcontroller Units (MCUs) with highly constrained memory resources, so that it becomes critical to assess the XRCE-DDS Client memory consumption with extreme precision to help users selecting the adequate platforms to develop their applications. + +In this section, we report on the memory footprint of the Micro XRCE-DDS Client library for two simple applications, one publishing and the other subscribing to topics of known size, running on the Real Time Operating System (RTOS) FreeRTOS and on an Olimex STM32-E407 board. The board running the Client is connected by serial transport (UART) at 115200 baud to a Micro XRCE-DDS Agent running on a Linux machine. + +This choice has been made since FreeRTOS provides memory management functionalities that easily allows to compute the stack memory used by a given program as the difference between the total allocated memory, known to the programmer, and the minimum stack left unused during the program execution. + +### Memory and Configurability + +Given the limited memory resources offered by the systems targeted by the XRCE-DDS library, the possibility to manipulate the memory size of the Client is key. This can be done at two different levels: + +* At configuration time: to fix the size of the executable code size, the library can be compiled enabling or disabling several profiles. Indeed, the +Client library follows a profile concept that enables to choose, add or remove some features in configuration time, thus allowing the user to customize its size. As we’ll see below, as part of these profiles one can choose for instance to communicate in reliable or best-effort mode. For more information, please refer to the [Client library documentation](https://micro-xrce-dds.docs.eprosima.com/en/latest/client.html#micro-xrce-dds-client-label). +* At run time: the Client library is both dynamic and static memory free, implying that all memory footprint depends only on how the stack grows during +the execution. The parameters that, together with the library functions, control the stack are the streams and the Maximum Transmission Unit (MTU). + * The MTU is transport-dependent, and it can be configured by the user. The selected value represents the maximum message size that can be sent received without fragmenting the message. The transport uses the MTU value to create an internal buffer, which is the memory block where the messages will be written and stored when interchanged. + * As for the streams, the user can define a maximum of 127 best-effort streams and 128 reliable streams, but for the majority of purposes, only one stream in either best effort or reliable mode is used. Moreover, reliable streams have a history associated, whose size can be tailored to fit the specific requirements of the application. In this case, the size of the stream corresponds to the total reserved memory for the stream, equal to the maximum message size times the associated history. In the best-effort case, no history is stored and the memory reserved for the stream equals the maximum message size. + +### Methodology + +In this section, we detail the methodology employed for the memory profiling. + +A Micro XRCE-DDS Client application is created with a varying number of either publishers or subscribers, associated with their own datawriters or datareaders. Moreover, each is associated with a topic of known size and with two streams, one for input and one for output messages. Finally, a minimum history size of 2 is used in the case of reliable communication. + +The MTU selected for the serial transport used by these applications has been fixed to 512 B, which in turn sets the size of the transport buffer. + +In order to provide a complete characterization of the memory consumption, the following parameters have been varied: + +* Creation mode: this is one of the profiles that can be configured at compile time. We have explored both XML and reference modes for the creation of the entities on the Agent on behalf of the Client. In the first case, entities are created according to an XML configuration file defined by the user on the Client app. In the second case, they are created directly on the Agent according to preconfigured reference entities known beforehand by the Agent, to which the Client simply refers. +* Stream types: best-effort vs reliable communication modes between the Client and the Agent. Best-effort streams send and receive data leaving the reliability to the transport layer, and the message size handled by a best-effort stream must be less or equal than the Maximum Transmission Unit (MTU) defined in the transport used. On the other hand, reliable streams perform the communication without loss regardless of the transport layer and allow message fragmentation to send and receive messages longer than the MTU. To avoid a loss of data, the reliable streams use additional messages to confirm the delivery, along with a history of the messages sent and received. As a result, best effort streams will consume fewer resources than reliable streams. +* Size of the topics, ranging between 0 and ~ 3 KB for the publisher (both best-effort and reliable) and for the reliable subscriber, and between 0 and ~ 400 B for the subscriber best-effort. The reason for the latter is that, given the absence of fragmentation in best-effort communication streams, the maximum message size that a best-effort subscriber can support equals the transport buffer size (or MTU), that we have fixed to 512 B. On the other hand, thanks to fragmentation, a reliable subscriber can receive a message of arbitrary size opportunely chunked in pieces of the size of the MTU. +* Number of publishers/subscribers, which is equivalent to changing the number of topics, since in our design of the set-up we have associated each publisher/subscriber with just one topic. + +The memory usage of a MCU by means of one such XRCE-DDS application is split into different chunks, each devoted to a different function: + +* Data buffer: This buffer stores the topic data before serialization. We don’t include it in our footprint as this memory is application specific and not related to the Micro XRCE-DDS Client operations. +* Output buffer: This buffer is the portion of memory dedicated to the allocation of the entity creation requests, plus that of the serialized topic in the case of publishers. Therefore, in this case its size will be equal to the maximum between these values, whereas in the case of a subscriber application it will equal the size of the created entity. Notice that the entity creation consumption critically depends on the creation mode. +* Input buffer: This buffer is used by subscriber applications to store data coming from the Agent, and by publishers in the case of reliable communication, to receive confirmation that all the information has been correctly received by the Agent. +* Transport buffer: This is equal to the MTU, fixed to 512 B in the present analysis. +* Stack usage: The stack is the memory consumed by the functions used by the program, when executing. Whilst the memory consumed by the buffers above, all stored in static memory, can be straightforwardly calculated by just analyzing the compiled binary objects, the stack is the chunk of memory we cannot know before running our application. In order to measure it, we make use of the FreeRTOS [uxTaskGetStackHighWaterMark()](https://www.freertos.org/uxTaskGetStackHighWaterMark.html) funcion. This function returns the amount of stack that remained unused when the XRCE-DDS task stack was at its greatest value. By subtracting this value to the total stack available (which is known), we thus obtain the stack peak used by our XRCE-DDS app. + +diagram +

+ Fig. 1: Illustrative diagram of the memory partition in the XRCE-DDS Client library. +

+ +Summarizing, we calculate the total memory usage of our XRCE-DDS app as the sum of the static memory used (which will in general be of the size of the output/input buffers plus the transport buffer) and of the stack used, calculated by means of the uxTaskGetStackHighWaterMark() function provided by FreeRTOS. + +## Results and Discussion + +* Publishers + +publishers consumption +

+ Fig. 2: Memory usage (in Bytes) of the XRCE-DDS Client as a function of topic size (in Bytes) and publishers number. +

+ +* Subscribers + +subscribers consumption +

+ Fig. 3: Memory usage (in Bytes) of the XRCE-DDS Client as a function of topic size (in Bytes) and subscribers number. +

+ +As it comes to light from these plots, no significant variability is shown among the instances considered. As for the publishers, all four cases follow the same trend. + +Notice that both for publishers and subscribers the curves are flat for small enough topic sizes (< 400 kB) when creation of entities happens by XML. Indeed, in these cases the size of the output buffer is determined by the buffer size needed for entities’ creation, and it only changes when the topic size exceeds that required by entities’ creation. + +Publishers/subscribers number is seen to not affect the measurements. This is expected for this specific experimental set-up because just one topic at a time is sent/received, and therefore the number of topics doesn’t enter the overall memory consumption. Notice however that, under a different configuration in which multiple topics are sent or received at the same time, the size of the memory buffer would grow accordingly. + +The difference observable between the publishers and subscribers’ memory footprint is due to the fact that a subscriber always needs two static-memory buffers: an output buffer to write and send subscription requests, and an input buffer to store the response to those requests, that is, the data coming from the Agent. + +## Memory Profiling of the Micro XRCE-DDS Agent on Linux + +The Micro XRCE-DDS Agent is at the moment only supported by standard Operating Systems such as Linux, Windows and Mac. However, more and more users are beginning to show an interest to port the Agent to a MCU, and compiling it on top of an RTOS. Since this task hasn’t been carried out yet, as a first step towards the exploration of such a scenario we have performed an analysis of the memory footprint of a lightweight version of the Agent on Linux. + +### Available Middleware Implementations for the Agent + +The Agent counts with three middleware implementations: FastMiddleware, FastDDSMiddleware and CedMiddleware (refer to this [link](https://micro-xrce-dds.docs.eprosima.com/en/latest/agent.html#fastmiddleware) in order to learn more). + +The FastMiddleware and FastDDSMiddleware use respectively eProsima Fast RTPS and eProsima Fast DDS, Cpp implementations of the RTPS (Real Time Publish Subscribe) protocol and of the DDS standard. These middlewares allow the Client to produce and consume data in the DDS Global Data Space. These Agents have the default behaviour described in the DDS-XRCE standard, that is, for each DDS-XRCE entity a DDS proxy entity is created, and the writing/reading actions produce publishing/subscribing operations in DDS. + +On the other hand, the CedMiddleware (Centralized Middleware) makes use of the Agent as a broker, that accepts connections and messages published from Clients, processes subscribe/unsubscribe requests, forwards messages that match other Clients’ subscriptions, and closes Clients’ connections. This Agent is much more lightweight than those with output to DDS, and is therefore the appropriate candidate for assessing the memory consumption of the lightest possible version of an Agent that could mediate a pseudo-p2p communication among Clients. + +### Methodology and Results + +We have investigated the memory consumption of an Agent communicating with a mock Client application on Linux that is publishing and subscribing to topics of known size. + +We have measured on the one hand the binary size of the compiled Agent, and then analyzed its heap and stack usage. For the latter, the number of pub/sub pairs has been varied from 1 to 32, with a single topic associated with each pair, and the topic size has been varied too, from 8 to 256 B. + +The binary size of the compiled Agent resulted to be 385 KB. + +As for the RAM memory, the tool that has been used for establishing the CedMiddleware memory footprint is [Valgrind](https://valgrind.org/), an instrumentation framework for building dynamic analysis tools. Specifically, we made use of [Massif](https://valgrind.org/docs/manual/ms-manual.html), a memory profiler which measures how much heap and stack memory a program uses. The reported measurements correspond to the memory peak resulting from the analysis provided by this tool. + +The total heap + stack consumption is plotted as a function of the topic size and number below. + +agent consumption +

+ Fig. 4: Memory usage (in KiloBytes) of the XRCE-DDS Agent as a function of topic size (in Bytes) and topics number. +

+ +We see from these results that for applications that involve around 10-15 pub/sub pairs (and equal number of topics), the memory consumption of the Agent could be compatible with cross-compilation and later execution into a mid-to-high range MCU with RAM memory on the order of ~ 300-400 KB and flash of less than 500 KB. This preliminary analysis therefore paves the way for the possibility to port the Ced Agent to RTOSes such as those already supported by the XRCE-DDS Client (Zephyr, NuttX and FreeRTOS) and thus bringing this component of the library to resource-constrained systems, as well. We mention that, to date, both the FastDDSMiddleware and the CedMiddleware Agents have been successfully ported to Raspberry Pis (RPis) on both Ubuntu and Raspbian and that several micro-ROS use-cases and demos already function with the Agent on a RPi. + diff --git a/_docs/concepts/middleware/memo_prof/overall_pub.png b/_docs/concepts/middleware/memo_prof/overall_pub.png new file mode 100644 index 00000000..2c2f275b Binary files /dev/null and b/_docs/concepts/middleware/memo_prof/overall_pub.png differ diff --git a/_docs/concepts/middleware/memo_prof/overall_sub.png b/_docs/concepts/middleware/memo_prof/overall_sub.png new file mode 100644 index 00000000..bbfb6bc7 Binary files /dev/null and b/_docs/concepts/middleware/memo_prof/overall_sub.png differ diff --git a/_docs/concepts/middleware/rosserial/index.md b/_docs/concepts/middleware/rosserial/index.md index 44d6463f..10adb298 100644 --- a/_docs/concepts/middleware/rosserial/index.md +++ b/_docs/concepts/middleware/rosserial/index.md @@ -1,5 +1,5 @@ --- -title: micro-ROS compared to rosserial +title: Micro XRCE-DDS compared to rosserial permalink: /docs/concepts/middleware/rosserial/ --- @@ -15,26 +15,24 @@ This rosserial-server can be used either in C++ or Python; meanwhile, the rosser This solution is commonly used to integrate hardware pieces within Robots using ROS. Rosserial, in those cases, acts as a bridge between hardware communication protocols and a ROS network. -## micro-ROS +## Micro XRCE-DDS -In the case of the new version of ROS, ROS 2, there was not a solution for such microcontroller-robot integrations. -But there is a project called micro-ROS bringing ROS2 to microcontrollers. -One of the capabilities of micro-ROS is the use of serial connection between a microcontroller and a ROS2 capable computer. +One of the capabilities of Micro XRCE-DDS is the use of serial connection between a microcontroller and a DDS/ROS 2 capable computer. Such a connection is possible thanks to the use of OMG's DDS-XRCE standard and a serial transport layer. -Micro-ROS solution follows the same client-server architecture as rosserial, as it is one of the most suitable architectural approaches when we speak of microcontroller communications. +This solution follows the same client-server architecture as rosserial, which it is one of the most suitable approaches when we speak of microcontroller communications. -This approach uses the concept of client-agent communication. -In this specific case, clients generate entities within the agent which will act on behalf of the clients on a DDS network (as ROS 2 has drifted into using DDS networks instead of the original ROS network). +The libraries in charge of implementing this architecture are the Client and the Agent. +Clients generate entities within the Agent which will act on behalf of the Clients on a DDS network. This usage, as you can see, resembles the one used by rosserial, but they have subtle differences in their implementations which we will expose in this article. -## micro-ROS vs rosserial +## Micro XRCE-DDS vs rosserial -Now that we have a quick view of rosserial and micro-ROS we will go on a comparison between them. +Now that we have a basic understanding of rosserial and Micro XRCE-DDS we will provide a comparison between them. -### micro-ROS (over Serial Transport) +### Micro XRCE-DDS over Serial Transport -micro-ROS, when communicating over serial transports (it allows communications over other transports such as UDP, TCP ...), uses a serial protocol with a predefined format. +Micro XRCE-DDS, when communicating over serial transports (it allows communications over other transports such as UDP, TCP ...), uses a serial protocol with a predefined format. This format is explained in the following frame dissection: ``` @@ -73,15 +71,14 @@ In contrast, this is the rosserial frame: * `PAYLOAD`: serialised message. * `MCRC`: message CRC. -As you can see comparing with the micro-ROS serial frame, it uses a completely different frame. +As you can see comparing with the Micro XRCE-DDS serial frame, it uses a completely different frame. ## Comparison The following table, summarises the key aspects of both implmentations: -| | micro-ROS-serial | rosserial | +| | Micro XRCE-DDS serial | rosserial | |:-|:-:|:-:| -| **ROS** | ROS 2 | ROS | | **API** | C/C++ | C++ | | **integrity** | [HDLC](https://en.wikipedia.org/wiki/High-Level_Data_Link_Control) framing | none | | **security** | [CRC-16-CCITT](https://en.wikipedia.org/wiki/Cyclic_redundancy_check) | vague CRC (% 256) | @@ -95,7 +92,7 @@ The following table, summarises the key aspects of both implmentations: _* Overhead is divided between framing, 7 B and that added by DDS-XRCE protocol 12 B._ -As exposed in this table, micro-ROS serial increases the number of memory operations but reduces in a great way the memory required for serial communications as it does not require a that the hardware buffer has the same size as the serialisation buffer. +As exposed in this table, Micro XRCE-DDS serial increases the number of memory operations but reduces in a great way the memory required for serial communications as it does not require that the hardware buffer has the same size as the serialisation buffer. This use of buffers reduces memory usage. -Also, the micro-ROS provide routing and reliability capabilities in contrast with rosserial. -micro-ROS protocol embraces standards for some of its parts, like the usage of standard CRC or a standard framing. +Also, Micro XRCE-DDS serial provides routing and reliability capabilities in contrast with rosserial. +The DDS-XRCE protocol embraces standards for some of its parts, like the usage of standard CRC or a standard framing.