Direct answer
What micro-ROS is used for in robotics
micro-ROS is the bridge between ROS 2 and microcontroller firmware. It lets a constrained embedded device expose ROS-style publishers, subscribers, services and timers while a micro-ROS Agent represents that device inside the wider DDS-based ROS 2 network.
Last verified:
micro-ROS overview
A full ROS 2 installation normally runs on Linux-class computers with more memory, storage and operating-system services than a motor controller or sensor board can provide. micro-ROS moves a selected ROS 2 client stack onto microcontrollers so low-level devices can participate in the same application architecture without pretending that an MCU is a desktop computer.
The common deployment pattern separates the embedded client from the ROS 2 data space. Firmware runs the micro-ROS client libraries and communicates over serial, UDP or a custom transport. A micro-ROS Agent runs on a more capable computer and creates the corresponding DDS entities on behalf of the MCU.
This design is useful for sensor hubs, actuator controllers, mobile-base electronics and custom boards. It does not automatically make firmware deterministic, safe or production-ready. Real-time scheduling, memory allocation, watchdogs, electrical protection and application-specific safety remain the responsibility of the embedded system design.
Core capabilities
- ROS 2-style publishers, subscribers, services, clients, timers and executors on supported microcontroller environments
- C APIs through rcl, rclc and related micro-ROS packages
- DDS-XRCE client-agent communication for resource-constrained devices
- Reliable or best-effort communication profiles and ROS 2 quality-of-service mapping
- Serial, UDP and platform-specific or custom transport options
- Static-library generation for integration into an existing embedded build system
- Platform modules for ecosystems such as FreeRTOS, Zephyr, NuttX, ESP-IDF, Arduino, PlatformIO and vendor toolchains
- Agent deployment on a Linux-class host, container or robot computer connected to the ROS 2 network
How the software fits into a robot stack
- Application code defines sensor, actuator or control behavior and uses the micro-ROS client API.
- rclc and the ROS client support layer create nodes, publishers, subscriptions, services, timers and executors with embedded constraints in mind.
- rmw_microxrcedds maps ROS 2 communication calls to the Micro XRCE-DDS client implementation.
- The XRCE client serializes messages and sends them through serial, UDP or a custom transport from the microcontroller.
- The micro-ROS Agent receives the session, creates DDS entities and exchanges data with the rest of the ROS 2 graph.
- The robot computer handles higher-level planning, logging and visualization while the MCU keeps time-sensitive I/O close to the hardware.
Recommended engineering workflow
- Choose the ROS 2 distribution and use the matching micro-ROS branch instead of mixing unsupported package versions.
- Select an officially documented platform module or generate a static library for the existing firmware toolchain.
- Define message rates, payload sizes, reliability requirements and the transport before sizing memory and task priorities.
- Create the node and entities once where possible, then use a bounded executor loop instead of allocating repeatedly during operation.
- Start the Agent with the same transport parameters and verify discovery, message flow and reconnection behavior.
- Test watchdog recovery, Agent loss, cable disconnects, packet loss, MCU reset and ROS 2 computer restart.
- Measure worst-case execution time, stack usage, heap use and transport latency on the actual board.
Compatibility and installation
- Developer
- micro-ROS project
- License
- Open source
- Operating systems
- FreeRTOS, Zephyr, NuttX, Linux and other supported embedded platforms
- ROS support
- ROS 2
- Languages
- C, C++
- Installation method
- ROS 2 workspace tools, platform-specific modules, static libraries and source builds
Installation and deployment notes
- The micro_ros_setup repository provides a four-stage workflow for supported examples: create, configure, build and flash firmware.
- Platform-specific modules are often a better production starting point than the generic setup package because they integrate directly with the vendor or RTOS build system.
- The static-library workflow is useful when an existing embedded project cannot adopt the micro_ros_setup workspace structure.
- The Agent must be built or installed on the companion computer and launched with the correct serial device, IP address, port and transport.
- Pin the ROS 2 distribution, micro-ROS branch, RTOS version and board support package in the release manifest.
- Treat examples as connectivity demonstrations. Add application-level error handling, timeouts, watchdogs and safety checks before field use.
Robotics use cases
- Motor-driver and actuator-controller boards
- IMU, encoder, force, temperature and environmental sensor hubs
- Mobile-base firmware connected to a ROS 2 navigation computer
- Small robotic arms with a Linux planner and MCU-level servo loops
- Battery-management and power-distribution telemetry
- Educational robots using ESP32, STM32 or supported RTOS boards
- Custom hardware interfaces where a full Linux computer would add cost, boot time or power draw
Limitations and engineering cautions
- The Agent is an architectural dependency in the common DDS-XRCE deployment. Agent loss must be detected and handled safely.
- Supported boards and RTOS combinations differ by repository, branch and integration module. A listed ecosystem does not mean every board is maintained equally.
- MCU RAM, flash, stack depth and message buffers can be exhausted by large message types or excessive entity counts.
- Using ROS 2 APIs does not guarantee hard real-time behavior. Scheduling, interrupts, memory policy and transport jitter still matter.
- Dynamic discovery and desktop-style debugging are more limited than on a full ROS 2 computer.
- Safety-relevant control needs independent limits, watchdogs and fail-safe states rather than relying only on network messages.
- The micro_ros_setup project explicitly warns that its software must be adapted and validated for the intended production or safety use case.
Frequently asked questions
What is the difference between ROS 2 and micro-ROS?
ROS 2 is the wider robotics middleware and software ecosystem. micro-ROS implements selected ROS 2 client concepts for microcontrollers and connects them to the ROS 2 graph through embedded middleware and an Agent.
Does micro-ROS run without Linux on the microcontroller?
Yes. The microcontroller can run an RTOS such as FreeRTOS, Zephyr or NuttX, or another supported platform integration. The Agent normally runs on a Linux-class companion computer.
Why does micro-ROS use an Agent?
The Agent acts on behalf of resource-constrained clients inside the DDS data space. This keeps the MCU-side protocol and memory footprint smaller than a full DDS implementation.
Which transport should be used?
Serial is simple for direct wired links. UDP is useful when the board has networking. The correct choice depends on latency, wiring, reliability, diagnostics and recovery requirements.
Is micro-ROS hard real time?
micro-ROS can be used in real-time systems, but real-time guarantees depend on the RTOS, executor design, memory strategy, interrupt load, transport and application code. The name alone does not provide a timing guarantee.
Can micro-ROS control motors directly?
It can carry commands and telemetry and run embedded application logic, but the motor-control loop, limits and emergency behavior must be designed for the specific hardware. Fast inner loops often stay local on the MCU.
Related robotics guides
Use official installation sources
Use the vendor download page, official documentation, package repository or official GitHub release. Third-party installers and mirrors are not linked from this directory.