Micro-ROS

Micro-ROS is specifically designed for resource-constrained devices like ARM Cortex-M or ESP32 microcontrollers. It provides a minimal-footprint client library that implements the essential ROS 2 communication patterns (publish/subscribe, services, actions) while offloading complex tasks like discovery and serialization to a more powerful companion processor running the Micro-ROS Agent. This architecture allows developers to write standard ROS 2 nodes that execute deterministically on hardware with as little as < 100 KB of RAM and < 1 MB of Flash memory.

A core component enabling deterministic behavior is the rclc Executor, a C-language client library executor for Micro-ROS. Unlike the more general-purpose executors in standard ROS 2, the rclc Executor provides:

• Static memory allocation to avoid non-deterministic heap operations.
• User-defined trigger conditions for precise callback scheduling.
• Explicit spin semantics that integrate seamlessly with real-time operating system (RTOS) task loops. This allows developers to build hard real-time control loops where sensor reading, computation, and actuator command callbacks are guaranteed to execute within strict, predictable time constraints.

Micro-ROS nodes do not communicate directly over DDS. Instead, they connect via a lightweight serial protocol (e.g., UART, SPI, or UDP) to a Micro-ROS Agent running on a Linux-based companion computer (e.g., a Raspberry Pi or the robot's main computer). The Agent acts as a bridge, performing these critical functions:

• Translating the serial protocol to/from standard ROS 2/DDS messages.
• Handling node discovery and lifecycle management for the embedded nodes.
• Managing the Quality of Service (QoS) policies between the microcontrollers and the broader ROS 2 graph. This separation allows the microcontroller to remain simple and deterministic while the Agent handles the complexity of the ROS 2 ecosystem.

Micro-ROS is not an OS itself; it is designed to run atop industry-standard Real-Time Operating Systems that provide the necessary threading, scheduling, and IPC primitives. It offers official support and integration layers for:

• FreeRTOS: The most common RTOS for embedded systems.
• Zephyr RTOS: A scalable, secure RTOS popular for connected devices.
• NuttX RTOS: A POSIX-compliant RTOS often used in aerospace. This RTOS integration provides the foundational deterministic task scheduling and inter-process communication mechanisms that Micro-ROS leverages to guarantee the timely execution of its callbacks and communication tasks.

Despite its small size, Micro-ROS maintains full semantic compatibility with the ROS 2 middleware layer. This means:

• Micro-ROS nodes can publish and subscribe to topics on the main ROS 2 network as first-class participants.
• They can provide and call services and actions, enabling bidirectional, task-oriented communication.
• They support a subset of ROS 2 Quality of Service (QoS) policies, such as Reliable vs. Best Effort delivery and Volatile vs. Transient Local durability, allowing communication behavior to be tuned for control vs. telemetry data. This compatibility ensures that low-level sensor and actuator hardware can be integrated into a larger robotic system using the same tools and paradigms as high-level perception or planning nodes.

Micro-ROS provides a complete, containerized toolchain to streamline development for embedded targets. Key tools include:

• Micro-ROS Build System: A set of CMake utilities and a colcon meta-build tool extension that cross-compiles the Micro-ROS stack and user code for the target microcontroller.
• Micro-ROS-Agent CLI: A command-line tool to easily launch the bridging Agent on the host machine with configurable transports (serial, UDP).
• Integration with ROS 2 Debugging Tools: Once connected, embedded nodes appear in the ROS 2 graph and can be inspected with standard tools like ros2 topic list, ros2 node info, and rqt_graph, providing full observability from the high-level system down to the microcontroller.

The Micro-ROS Client Library is the minimal, portable C API that provides the core ROS 2 concepts (publishers, subscribers, services, actions) for microcontrollers. It is designed for deterministic, real-time execution within a Real-Time Operating System (RTOS) like FreeRTOS or Zephyr.

• Key Functions: Implements the ROS 2 Middleware Interface (RMW) for microcontrollers.
• Memory Footprint: Typically requires <100 KB of RAM, making it suitable for MCUs like the ESP32 or STM32.
• Integration: Links directly with the user's application code on the MCU, handling all communication with the Micro-ROS Agent.

The Micro-ROS Agent is a broker process that runs on a more powerful companion computer (e.g., a Linux-based SBC). It acts as the bridge between the Micro-ROS Client on the microcontroller and the full ROS 2 network.

• Primary Role: Translates the serialized data (typically over UART, USB, or Bluetooth) from the MCU into native ROS 2 messages on DDS topics.
• Discovery & Management: Handles node discovery and manages the Micro-ROS Client's participation in the ROS 2 graph.
• Deployment: Runs as a standard ROS 2 node, allowing the embedded device to appear as a peer in the larger system.

Micro XRCE-DDS is the wire protocol and client-server middleware that underpins Micro-ROS communication. It is a lightweight subset of the DDS standard defined by the Object Management Group (OMG).

• Architecture: Uses a client-server model where the MCU is the client and the Agent is the server, unlike the peer-to-peer DDS used in standard ROS 2.
• Efficiency: Designed for minimal bandwidth and processing overhead, using efficient serialization like CDR.
• Standardization: Provides a standardized way for tiny devices to participate in a DDS data space, ensuring interoperability.

A Real-Time Operating System (RTOS) is a critical software layer for Micro-ROS deployments. It provides deterministic scheduling, task management, and synchronization primitives essential for reliable robotic control loops.

• Common Examples: FreeRTOS, Zephyr, NuttX, and Mbed OS.
• Role in Micro-ROS: The Micro-ROS Client Library is ported to run on top of an RTOS. The RTOS manages the execution of the Micro-ROS tasks (e.g., spinning the executor) alongside the user's application tasks.
• Determinism: Guarantees that high-priority control tasks can preempt communication tasks, meeting hard real-time deadlines for actuation.

The Micro-ROS Executor is a specialized, lightweight version of the ROS 2 executor designed for single-threaded, real-time environments on microcontrollers. It processes incoming messages and triggers user callbacks.

• Key Difference: Often implements a static, compile-time allocation of memory for subscriptions and timers to avoid dynamic memory allocation (heap usage).
• Spin Modes: Typically supports a non-blocking spin (check for new data) or a blocking spin (wait for data with a timeout) to fit into tight control loops.
• Performance: Optimized for predictable, low-latency callback execution, which is critical for sensor reading and motor control.

Hardware-in-the-Loop Testing is a critical validation methodology for Micro-ROS systems. It involves connecting the physical microcontroller running Micro-ROS to a simulation of the robot and environment.

• Process: The MCU executes the actual embedded control code (using Micro-ROS), while a simulator (e.g., Gazebo) provides sensor data and consumes actuator commands via the Micro-ROS Agent.
• Benefit: Allows for rigorous testing of low-level firmware, communication reliability, and real-time performance before full integration on the physical robot.
• Toolchain: Often utilizes ROS 2 bag recording/playback and the Micro-ROS Agent's ability to bridge simulated and real topics.