Glossary

Fictionlab > Glossary > micro-ROS

micro-ROS

micro-ROS – definition

micro-ROS is a framework that extends ROS 2 communication and client-library concepts to resource-constrained microcontrollers. It enables embedded firmware to participate in a ROS 2 system as a ROS node, publishing and subscribing to topics, providing and using services, and exchanging data with a ROS 2 graph through a micro-ROS Agent.

Unlike a standard ROS 2 node running on Linux, a micro-ROS node usually runs on a real-time operating system (RTOS) or bare-metal target. It uses the rclc client library and a middleware implementation based on eProsima Micro XRCE-DDS. The transport between the microcontroller and the Agent can use serial, UDP, TCP, or custom transports. The Agent connects this embedded communication domain to the DDS middleware used by ROS 2.

For mobile robotics and UGV platforms, micro-ROS is relevant when deterministic low-level functions must remain close to hardware. Typical tasks include motor encoder acquisition, IMU reading, battery monitoring, safety-state handling, GPIO control, and communication with sensor buses such as UART, I2C, SPI, or CAN.

Source: micro-ROS project documentation

How micro-ROS works with ROS 2

micro-ROS does not place a full ROS 2 installation on a microcontroller. Instead, it provides a reduced ROS 2 client stack designed for embedded targets. The microcontroller runs a micro-ROS Client, while a Linux computer or another capable host runs the micro-ROS Agent.

The communication path is typically as follows:

  1. A microcontroller executes firmware built with rclc, rcl, and rmw_microxrcedds.
  2. The firmware sends XRCE-DDS messages over a transport such as USB serial or UDP.
  3. The micro-ROS Agent receives XRCE-DDS traffic and creates corresponding DDS entities in the ROS 2 domain.
  4. Standard ROS 2 nodes can then subscribe to embedded topics or send commands to the microcontroller.

The underlying transport protocol is DDS-XRCE, formally specified by the Object Management Group (OMG). DDS-XRCE is designed for applications where a client cannot host a conventional DDS implementation because of memory, processing, or network constraints.

Source: OMG DDS-XRCE version 1.0 specification

micro-ROS architecture for UGV platforms

On a mobile robot, the division of responsibilities between a Linux computer and a microcontroller is important. High-level perception, mapping, navigation, and user interfaces require substantially more memory and compute capacity than low-level control. These functions normally remain on the main computer.

Function Typical execution target Example ROS 2 interface
Wheel encoder acquisition microcontroller with micro-ROS sensor_msgs/msg/JointState
IMU sampling and timestamping microcontroller with micro-ROS sensor_msgs/msg/Imu
Motor command reception microcontroller with micro-ROS geometry_msgs/msg/Twist
Odometry estimation microcontroller or Linux host nav_msgs/msg/Odometry
SLAM and Nav2 planning Linux computer sensor_msgs/msg/LaserScan, map, tf

A microcontroller should not be treated as a replacement for the onboard computer. It is best used for hardware-near processing with bounded timing requirements. The ROS 2 computer remains responsible for CPU-intensive tasks such as LiDAR processing, visual odometry, SLAM, path planning, and map management.

micro-ROS on Leo Rover and Raph Rover

Leo Rover natively supports ROS 2 on its built-in Raspberry Pi compute unit. In a micro-ROS architecture, the Raspberry Pi can run the micro-ROS Agent while an external microcontroller handles a dedicated sensor or actuator subsystem. This is useful when an integration requires independent timing from the main ROS 2 application.

For example, an external board can publish IMU measurements and wheel-related diagnostics through USB serial. The Raspberry Pi can consume these topics together with LiDAR, depth camera, or GNSS data and pass them to state-estimation or navigation nodes. Leo Rover has differential drive, so velocity commands should be converted into left and right wheel targets by a controller that respects the platform’s kinematic model and safety limits.

Raph Rover can use the same pattern for larger payload integrations. A microcontroller may manage a custom sensor enclosure, a power-distribution interface, an RTK GNSS receiver connected through serial, or an auxiliary actuator subsystem. The main computer should still host ROS 2 navigation and perception components.

Neither Leo Rover nor Raph Rover becomes autonomous solely by adding micro-ROS. Autonomous operation requires a complete ROS 2 stack, including state estimation, transforms, sensor drivers, obstacle perception, localization or SLAM, and a navigation controller.

Key implementation parameters

micro-ROS deployments must define message types, update rates, transport behavior, QoS policies, and memory limits before firmware development. These parameters affect latency, reliability, CPU use, and compatibility with ROS 2 subscribers.

  • Transport: USB serial is common for direct connection to the onboard computer. UDP is suitable when the embedded device is on an IP network.
  • Message type: Use standard ROS 2 messages where possible, such as sensor_msgs/msg/Imu and diagnostic_msgs/msg/DiagnosticArray.
  • QoS: Sensor streams commonly use best-effort delivery, while command or safety-state topics may require reliable delivery.
  • Executor model: The rclc executor supports deterministic callback execution configured by the application.
  • Time synchronization: Timestamped sensor data should use synchronized time when it will be fused with LiDAR, camera, GNSS, or wheel odometry data.

ROS 2 QoS settings must be compatible between publishers and subscribers. A reliable subscriber cannot communicate with a best-effort publisher when the requested QoS policy is incompatible.

Source: ROS 2 documentation: Quality of Service settings

Example: starting a micro-ROS Agent over serial

The following command starts a micro-ROS Agent on a ROS 2 host and exposes a serial-connected microcontroller to the ROS 2 graph. The device path must match the host operating system configuration.

ros2 run micro_ros_agent micro_ros_agent serial \
  --dev /dev/ttyACM0 \
  -v6

After the client connects, standard ROS 2 CLI tools can inspect its interfaces.

ros2 node list
ros2 topic list
ros2 topic echo /imu/data

Limitations and version considerations

micro-ROS is not binary-compatible with arbitrary ROS 2 packages intended for Linux. Its firmware must be built for a supported embedded platform and RTOS, and available features depend on the selected micro-ROS release, middleware, transport, and hardware abstraction layer.

ROS 2 distributions have different support windows and package versions. ROS 2 Humble Hawksbill is an LTS distribution released in 2022, while newer distributions can introduce API, build-system, or dependency changes. A mobile robot integration should pin the ROS 2 distribution, micro-ROS workspace revision, firmware board support package, and Agent version in its build documentation.

Source: REP 2000: ROS 2 Releases and Target Platforms

See also