micro-ROS Explained: ROS 2 for Embedded Robots

Robots often combine a Linux computer that handles planning with small microcontrollers that read encoders, drive actuators, and enforce low-latency control loops. Connecting those devices to the same software graph can otherwise require a custom protocol and bridge. micro-ROS brings ROS 2 concepts to resource-constrained microcontrollers, so embedded nodes can communicate with the rest of a robot using familiar ROS interfaces. This explainer covers its client-and-agent architecture, where it fits, and how to try a host-based demo before deploying to a board.

What Is micro-ROS?

micro-ROS is an open-source project that adapts ROS 2 client concepts to microcontrollers and real-time operating systems (RTOSes). A device can expose nodes, publishers, subscriptions, services, and other ROS concepts without running a full desktop-class ROS 2 installation. The micro-ROS project describes its purpose as bridging resource-constrained microcontrollers and larger processors in robotics.

The MCU runs a small client library. A companion micro-ROS Agent runs on a more capable computer and connects that client to a normal ROS 2 system. The MCU does not need to run a complete DDS implementation or Linux. It exchanges data with the Agent over a supported transport, while ROS 2 applications on the host can interact with its nodes through the wider graph.

micro-ROS is therefore not a separate robot operating system and not simply a tiny copy of ROS 2. It is a way to use ROS 2 communication patterns at the edge of a robot where memory, compute, power, and timing budgets are tighter.

Why Does micro-ROS Exist?

Microcontrollers are useful in robots because they interface directly with hardware, can run low-power firmware, and support predictable control loops. But firmware running on an MCU does not automatically participate in the ROS 2 graph. Teams traditionally connect it to a host using a custom serial protocol, a vendor-specific library, or a bespoke gateway node.

Those approaches can work, but each project must define message formats, error handling, connection recovery, and a way to map device data into ROS topics or services. The result may be harder to inspect with ROS tools and can couple firmware to one robot application.

micro-ROS addresses that integration gap. It preserves a small on-device client and moves more complex middleware work to an Agent on a host or gateway. ROS 2 tools can then inspect and communicate with embedded nodes using the same graph model as other nodes. It does not eliminate the need to design a device protocol, choose a transport, budget memory, or validate timing; it provides reusable ROS-compatible building blocks for doing that work.

How the micro-ROS Architecture Works

A typical data path begins with firmware reading a sensor or updating an actuator. The micro-ROS client publishes a typed message through the embedded ROS client libraries and its middleware layer. A transport carries that message to the Agent, which connects the MCU client to the host-side ROS 2 data space. A regular ROS 2 subscriber can then receive it. Commands and other messages travel back in the opposite direction.

The micro-ROS architecture overview describes a client API built around ROS 2’s rcl support library and the rclc extensions. The embedded middleware uses Micro XRCE-DDS. XRCE is the constrained-device protocol defined by the OMG DDS-XRCE specification. The Agent mediates between XRCE clients and the DDS-based ROS 2 side; it is a required part of this common client-to-ROS-graph path, not a ROS 2 broker that replaces all DDS participants.

This split is useful when the MCU must participate in a distributed application but cannot reasonably host the standard ROS 2 middleware stack. It also creates a boundary to plan for: if the Agent or link is unavailable, communication through that path is interrupted. Local control that must continue through a link outage should remain on the MCU and should not depend on a host round trip.

Components and Key Concepts

• rcl and rclc: The ROS client support library and its C-focused extensions provide familiar entities and execution tools suited to embedded applications. rclc includes executor options for scheduling callbacks. The application still needs to choose callback order, buffer sizes, and timing behavior deliberately.
• The micro-ROS client and RMW layer: Firmware uses the client to represent ROS entities and exchange serialized data. The Micro XRCE-DDS RMW layer connects the ROS-facing API to the XRCE protocol. This is different from running a full DDS participant on the MCU.
• The Agent: The Agent runs off-device and links micro-ROS clients to the rest of ROS 2. It can run on a robot computer or a gateway that has the required network or serial connection to the device.
• Transport: Serial and UDP are common choices; available options depend on the client port, board, and integration. The client and Agent must agree on transport settings, addressing, and ports. Wireless links add loss and latency that the application must tolerate.
• Memory and generated types: Embedded deployments often use fixed-size pools and bounded buffers instead of relying on unrestricted dynamic allocation. Message types and build configuration must be available to both the firmware and host-side ROS 2 workspace.
• RTOS and platform support: micro-ROS provides integrations for RTOSes such as FreeRTOS, Zephyr, and NuttX. A supported board or port still needs a compatible toolchain, transport implementation, and build configuration.

Memory behavior is a design property, not a guarantee that every application uses the same amount of RAM. Entity counts, message sizes, history depth, transport buffers, and executor configuration all affect the footprint. Measure the compiled firmware and runtime behavior on the target hardware.

Real-World Use Cases

• Sensor and actuator interfaces: An MCU can publish encoder, temperature, or inertial measurements while keeping sampling and low-level control close to the hardware. A host can subscribe, fuse measurements, and coordinate higher-level behavior.
• Distributed mobile robots: A small controller can expose device status and receive supervisory commands through ROS interfaces, while a Linux computer handles mapping, planning, visualization, or user interaction.
• Resource-constrained robot products: Battery-powered or compact devices can use an RTOS and MCU for local work, while reserving a larger processor for tasks with heavier computation or data storage.
• Prototyping and integration tests: Developers can exercise firmware-facing ROS interfaces and inspect topics using ROS 2 tools rather than first writing a project-specific monitoring bridge.

For sensor selection, calibration, and timestamping around the larger robot, see the guide to robotics sensor integration. micro-ROS can connect part of that pipeline, but it does not replace the sensor driver, coordinate-frame design, or fusion logic.

Getting Started with a Host-Based Demo

The simplest first test is to run the example on a development computer before cross-compiling firmware for a particular board. Use a Linux environment with a ROS 2 distribution that has a matching micro_ros_setup branch, along with the required ROS build tools and rosdep. Follow the micro-ROS tutorials for current distribution and platform details.

Source the installed ROS 2 environment, then create and build the setup workspace. In this example, $ROS_DISTRO is the distribution name exported by the setup script:

source /opt/ros/$ROS_DISTRO/setup.bash
mkdir -p ~/microros_ws/src
cd ~/microros_ws
git clone -b "$ROS_DISTRO" https://github.com/micro-ROS/micro_ros_setup.git src/micro_ros_setup
rosdep update
rosdep install --from-paths src --ignore-src -y
colcon build
source install/local_setup.bash

Create a host firmware workspace and build the sample application and Agent:

ros2 run micro_ros_setup create_firmware_ws.sh host
ros2 run micro_ros_setup build_firmware.sh
ros2 run micro_ros_setup create_agent_ws.sh
ros2 run micro_ros_setup build_agent.sh
source install/local_setup.bash

Run the Agent in one terminal:

source /opt/ros/$ROS_DISTRO/setup.bash
cd ~/microros_ws
source install/local_setup.bash
ros2 run micro_ros_agent micro_ros_agent udp4 --port 8888

In a second terminal, run the host demo with the micro-ROS RMW implementation:

source /opt/ros/$ROS_DISTRO/setup.bash
cd ~/microros_ws
source install/local_setup.bash
export RMW_IMPLEMENTATION=rmw_microxrcedds
ros2 run micro_ros_demos_rclc ping_pong

In another sourced ROS 2 terminal, verify that messages are visible:

ros2 node list
ros2 topic list
ros2 topic echo /microROS/ping

This confirms the host-based demo and graph integration; it does not demonstrate a physical MCU’s timing, memory use, electrical interface, or radio reliability. For a board, choose a supported platform, follow its firmware creation and configuration steps, set the actual transport endpoint, build with its toolchain, and flash the result. The Micro XRCE-DDS documentation explains its client-Agent model and transport options, while the micro-ROS platform tutorials provide the MCU-specific sequence. Diagnose failures by checking that the Agent is running, the client uses the same transport and endpoint, and host and firmware were built against compatible message definitions.

Before connecting actuators, test the MCU and Agent with noncritical telemetry. Measure end-to-end latency and dropped messages under expected load, test behavior during disconnects, and keep safety-critical control local. The ROS graph being visible is not evidence that a deadline or safety requirement is met.

Common micro-ROS Misconceptions

• “micro-ROS installs a full ROS 2 system on a microcontroller.” The MCU runs a constrained client and communicates through the Agent; it does not need to host the full DDS-based ROS 2 stack.
• “The Agent makes a robot real-time.” It provides a communication bridge. Scheduling, control-loop timing, transport delays, and outage behavior remain properties of the full system and must be measured.
• “Any ROS 2 node can connect to an MCU without configuration.” The device needs a compatible firmware build, message types, transport, endpoint, and Agent. Network reachability and resource limits still matter.
• “ROS compatibility means the project is safety-certified.” The micro-ROS project explicitly notes that it is not developed according to a safety standard. A robot’s safety case needs separate engineering and validation.

Related Articles

• ROS 2 architecture, DDS, and setup
• Embedded systems for IoT
• Robotics sensor integration and testing

Changelog

• Initial publication.

Last updated: 26 October.