ROS 2 nodes communicate over DDS. Full DDS implementations are designed for computers, not microcontrollers, so getting an MCU-based robot onto a ROS 2 network takes one of a few approaches.
Option 1: micro-ROS
micro-ROS runs a ROS 2 client on the microcontroller and talks to the ROS 2 graph through Micro XRCE-DDS. The MCU runs a lightweight client, and a separate agent process on a computer acts as its proxy in the DDS network. PX4, for example, uses this pattern to connect flight controllers to ROS 2.
- Pros: official ROS 2 ecosystem project, well documented, supports many RTOSes and boards.
- Cons: needs an agent running on another machine, which adds setup and a point of failure.
Option 2: native DDS/RTPS on the MCU
The DDS wire protocol, RTPS, can be implemented directly on a capable microcontroller. The device then performs discovery and publishes topics like any other ROS 2 node, with no agent.
- Pros: no extra computer, robots appear on the network on their own, simpler installs.
- Cons: significant engineering, and you own maintenance and interoperability testing.
| Factor | micro-ROS | Native DDS/RTPS |
|---|---|---|
| Extra machine needed | Yes, for the agent | No |
| Engineering effort | Low to moderate | High |
| Community support | Strong | You own it |
| Best for | Most projects and prototypes | Product lines needing zero extra infrastructure |
Frequently asked questions
Can an ESP32-S3 run micro-ROS?
Yes, micro-ROS supports ESP32-family chips through ESP-IDF.
Is a native stack compatible with standard ROS 2?
It can be, if it follows the RTPS specification and is tested against the DDS implementations your users run.
What about security?
Plain DDS traffic is unauthenticated. Keep robot networks isolated, or use DDS security where supported.
Sources
Embedded systems consultant at TechProgeny, Bengaluru. 7+ years and 29+ shipped products across firmware, embedded Linux, edge AI, apps and IoT servers.