B grade Authoritative secondary, traced to origin

micro-ROS: ROS 2 on a microcontroller, and the bridge your two-computer robot needs

An MCU for real-time control, an SBC for perception and navigation — the soundest split in hobby robotics. micro-ROS is the bridge that keeps the two from needing hand-made protocol glue.

Licence: Apache 2.0
Protocol: XRCE-DDS (bridges into the ROS 2 DDS graph)
Boards: STM32 / ESP32 / RP2040 among others
Start: Firmware compiled per target board; common dev boards officially supported
Role: The standard bridge between the real-time layer and the ROS 2 graph

What it solves: It answers 'do you have to write the bridge yourself?'. Without it, the MCU-to-Pi link is a hand-rolled serial protocol, your own packet-loss handling, your own format versioning. With it, the MCU program is a first-class ROS 2 node — topics, services and parameters matching the rest of the graph. Architecturally, what it removes is exactly the layer where self-made components hide their most silent bugs.
Alternatives: Your own serial protocol (entirely sufficient for simple remote control, and easier to debug); ros2_control with a hardware interface (when the same machine has a real-time kernel); everything on the SBC (no real-time guarantees; demo-grade). The test is one question: does the control loop need timing determinism? Yes — use it. No — hand-rolling is faster.
What it takes to start: The bar is tooling, not concepts: firmware compiles per target board (major boards are officially supported, but the cross-compilation environment, RTOS configuration and host-side Agent deployment are all yours to break in). First light takes days. Get it working on an officially supported board first, then move to your own — changing two variables at once is the debugging sin.
Known pitfalls: ① XRCE-DDS QoS does not fully match desktop DDS — keep large messages (images) off this bridge; ② firmware build configuration is board-locked; a new board means a new build setup; ③ when the host-side Agent dies, the whole layer goes dark — run the Agent as a service with automatic restart. It is in the documentation, and it is skipped more often than it is followed.
What we checked: We verified: licence and protocol (Apache 2.0 / XRCE-DDS); official support for RP2040, ESP32 and STM32; and that running the Agent as a managed service is the documented deployment advice. We have not deployed it ourselves — per-board tooling hours come from community reports. The grade stays accordingly.

This site's call

For a rover or any MCU-plus-SBC machine, it earns its place — the hand-made protocol layer it removes is where the silent bugs nest. It is not mandatory: for a simple remote-controlled car, a serial protocol of your own is faster. The deciding question is whether you have a real-time control loop. Yes, and it repays its setup cost. No, and it is premature.

Sources

micro-ROS official documentation (supported boards, XRCE-DDS, deployment)

Objects in this entry

Last checked 2026-09-28