MicroROS简述

---

前言

最近在了解一些开源的桌面机器人项目，发现运动控制等做的比较好的大都上了ROS，我前面了解过ROS2的基础知识也在虚拟机上自己跑过。但是对于实际设备上如何使用怎么进行开发并不是很了解。然后我开始看鱼香ROS的《动手学ROS2》系列课程，去了解下实际设备上是如何将ROS2给使用起来的。

课程中使用的主控是ESP32，然后在ESP32上使用ROS，但是由于ESP32的资源有限，所以实际使用的是一个叫MicroROS的库进行开发的。对于什么是MicroROS起初我有点蒙，所以就想着学习一下，这里把学习到的内容整理出来和大家进行一下分享。

1. 什么是MicroROS

MicroROS 是专门为微控制器（MCU）优化的 ROS 2 轻量级版本。它为资源受限的嵌入式设备提供了 ROS 2 的功能支持，使这些设备能够无缝集成到更大的 ROS 2 系统中。

想象一下 ROS（Robot Operating System） 是一个庞大的、功能强大的“机器人城市”的通信和管理系统。它擅长处理复杂任务（比如地图构建、导航、AI决策），但通常运行在像笔记本电脑或树莓派这样算力较强、内存较大的“城市中央电脑”上。

Micro-ROS 就是为了解决一个问题而生的：让那些资源极其有限、但工作在机器人“第一线”的小型嵌入式设备（比如控制电机的单片机、读取传感器的小板子 ESP32/STM32）也能加入这个“机器人城市”的通信网络。

2. MicroROS的功能

2.1 Micro-ROS 的核心作用：桥梁 + 翻译官

1. 让“小设备”说“ROS话”：

   • 普通的单片机程序无法直接理解和使用 ROS 复杂的通信协议（DDS）。
   • Micro-ROS 为这些单片机提供了一个精简版的 ROS 客户端库。它体积很小（KB级别），可以在 ESP32、STM32 等单片机上运行（需要配合实时操作系统如 FreeRTOS）。
   • 有了这个库，单片机上的程序就能用类似 ROS 的方式：
     • 发布（Publish） 消息（比如传感器读数：温度、距离、电机转速）。
     • 订阅（Subscribe） 消息（比如接收运动指令：前进速度、转向角度）。
     • 调用服务（Service Call） 或 提供应答（Service Response）（比如查询设备状态、发送一个配置命令）。

2. 中间的“翻译官”（Agent）：

   • 单片机直接和运行 ROS 的中央电脑通信还是有困难（协议不同、资源悬殊）。
   • Micro-ROS 引入了一个关键的中间角色：Agent（代理）。
   • Agent 运行在中央电脑 (Linux/Windows) 上，是一个特殊的程序。
   • Agent 的作用：
     • 协议转换： 它理解单片机发来的“简化版ROS协议”(XRCE-DDS)，并将其转换成标准ROS使用的“通用协议”(DDS)，反之亦然。就像把方言翻译成普通话。
     • 连接管理： 负责建立和维护单片机与整个ROS网络之间的连接（通常通过串口、UDP、WiFi等）。
     • 动态发现： 最重要的一点！ 当单片机上的 Micro-ROS 客户端启动，并声明它要发布/订阅某种类型的消息（比如sensor_msgs/msg/Temperature）时，它会把这些消息类型的描述信息发送给 Agent。
     • Agent 知道了什么： Agent 收到这些描述信息后，就清楚地知道：
       • 这个单片机设备上有哪些节点在运行。
       • 这些节点发布了哪些主题（Topics），以及这些主题上传输的消息具体是什么类型、包含哪些数据字段。
       • 这些节点订阅了哪些主题。
       • 这些节点提供了哪些服务（Services），调用了哪些服务。
     • 有了这些信息，Agent 就能：
       • 把单片机发布的消息，正确地转发给 ROS 网络中订阅了相同主题的其他节点。
       • 把 ROS 网络中其他节点发布的消息（单片机订阅的主题），正确地转发给单片机。
       • 把 ROS 网络中对服务的请求转发给单片机，并把单片机的响应转发回去。

2.2 为什么服务端（Agent）能知道设备端的消息和服务？

核心机制就是上面提到的 “动态发现 + 类型注册”：

1. 设备端（单片机）声明： 当单片机上的 Micro-ROS 程序启动时，它会主动告诉连接着的 Agent：“你好，我是节点/sensor_node，我会在主题/temperature上发布类型为 sensor_msgs/msg/Temperature 的消息，我还订阅了主题 /motor_cmd。”
2. Agent 学习与注册： Agent 收到这些信息后，学习并记住了设备端的能力（发布什么、订阅什么、提供什么服务）。它会根据收到的描述信息，在 ROS 网络中动态地注册这些主题和服务，就好像它们是由 Agent 自己发布/订阅的一样。
3. 无缝连接： 现在，ROS 网络中的其他节点（比如在中央电脑上运行的路径规划节点）如果订阅了 /temperature 主题，Agent 就会自动把单片机发来的 /temperature 消息转发给它。同样，如果某个节点（比如控制节点）向 /motor_cmd 主题发布指令，Agent 也会自动把这个指令转发给订阅了该主题的单片机节点。

简单说：设备端启动时会主动把自己的“通讯录”（包含发布、订阅、服务信息）交给 Agent 保管。Agent 有了这本通讯录，就能精准地知道设备端在收发什么消息，并负责在设备端和整个 ROS 网络之间准确无误地传递信息。

3. MicroROS出现的背景

MicroROS的出现源于机器人领域一个关键痛点：ROS 2虽强大，却无法直接在资源匮乏的微控制器（MCU）上运行。而像电机控制等对实时性要求高的外设一般都是使用MCU进行实时性控制，如果MCU不能直接参与到ROS2网络中，那么就需要借助转发（例如MCU通过串口和SOC进行通信，SOC作为ROS的代理），但是这样效率等势必会下降 ，总结起来主要有3个原因

3.1 机器人系统的“断层”问题

• 高端处理器（如工控机/树莓派）：
  运行ROS 2，处理复杂任务（SLAM、导航），但无法直接操控硬件（电机、传感器）。
• 底层MCU（如STM32/ESP32）：
  实时控制硬件，但算力/内存有限（KB级RAM），传统ROS 2（需MB级资源）根本无法移植。
• 后果：
  开发者被迫用串口/UART等原始方式连接两者，手动解析数据，开发效率低、易出错。

3.2 物联网与边缘计算的兴起

• 需求变化：
  智能机器人、IoT设备需在传感器端实时处理数据（如滤波、紧急避障），而非全部上传云端。
• 传统方案缺陷：
  • 自定义通信协议 → 无法复用ROS生态（工具链、算法包）。
  • 用MQTT/CoAP等轻量协议 → 失去ROS的节点管理、服务调用等核心能力，缺乏灵活性

3.3 ROS 2的架构升级

• ROS 1的局限：
  中心化通信（Master节点）、弱实时性，不适合嵌入式场景。
• ROS 2的突破：
  基于DDS通信协议，支持分布式、实时通信，为微控制器集成提供理论可能。
  → MicroROS应运而生，成为ROS 2在MCU端的“轻量化分身”。

3.4 总结

背景矛盾	MicroROS的解决方案	开发者收益
ROS 2无法在MCU运行	极致轻量化客户端库 + Agent代理	MCU直接使用ROS 2 API开发
硬件层与应用层通信效率低下	动态消息注册 + 自动协议转换	省去手动解析，数据直达ROS 2网络
边缘设备无法复用ROS生态	兼容标准ROS 2消息/服务/工具链	共享ROS算法包（如导航、控制）
实时性要求难以满足	集成RTOS，支持硬实时任务调度	电机控制、传感器采集低延迟响应

4. 参考资料

1. DeepSeek
2. 动手学ROS2-Humble