1. 从零开始理解ROS通信的“三驾马车”

搞机器人开发，尤其是用ROS，最绕不开的就是通信。很多刚入门的朋友，特别是从单片机、嵌入式转过来的，一上来就被Topic、Service、Action这些概念绕晕了，更别提怎么让手头的STM32、ESP32或者一块51单片机跟跑着ROS的电脑主机（PC）说上话了。我刚开始接触的时候也是一头雾水，总觉得ROS这套东西离硬件很远，是纯软件层面的“花架子”。直到真正动手把一个超声波传感器数据从STM32发到ROS里，再控制一个舵机转动，才明白这中间的通信机制是连接虚拟算法世界和真实物理世界的桥梁，搞懂了它，你的机器人项目就成功了一大半。

简单来说，ROS通信机制的核心目的，就是让不同的程序（节点）能够高效、可靠地交换数据。你可以把它想象成一个高度组织化的邮局或快递系统。Topic就像订阅杂志，发布者只管寄，订阅者只管收，彼此不知道对方是谁，适合持续不断的数据流，比如摄像头图像、激光雷达点云。Service则像一次性的挂号信或客服电话，客户端发送一个请求，服务端处理并返回一个响应，一问一答，适合偶尔发生的指令，比如请求当前电池状态、让机器人移动到某个点。Action是Service的升级版，专为长时间运行的任务设计，比如导航到目标点，它允许你在任务执行中取消、查看进度，就像你可以随时查询快递物流并决定是否取消配送。

那么，单片机、PC主机和ROS在这个通信体系里各自扮演什么角色？通常，PC主机作为“大脑”，运行着ROS Master（总管所有节点注册和查找的“电话簿”）和复杂的算法节点（如SLAM建图、路径规划）。而单片机作为“神经末梢”和“小脑”，负责连接具体的传感器（电机编码器、超声波、IMU）和执行器（电机、舵机），进行最底层的信号采集、滤波和实时控制。它们之间的通信，本质上就是让这两个角色按照ROS定好的“邮局规则”（协议）来收发“信件”（数据）。

2. 通信机制深度对比：Topic、Service与Action的实战选型

理解了基本角色，我们得深入看看ROS提供的三种核心通信机制。选择哪种，直接决定了你系统架构的效率和可靠性。很多新手容易犯的错就是“手里有锤子，看什么都像钉子”，不分场景乱用，最后导致系统延迟高、响应慢，或者功能根本实现不了。

2.1 Topic：单向、异步的数据洪流

Topic是ROS里最常用、最典型的发布/订阅模型。它的工作方式非常“佛系”：发布者（Publisher）节点创建一个话题（比如/camera/image_raw），然后就开始周期性地往这个话题里“扔”数据消息（Message）。而订阅者（Subscriber）节点，只要它对这个话题感兴趣，就可以去“订阅”它。一旦有新的数据发布到该话题，所有订阅者都会自动收到一份拷贝。

关键特性与适用场景：

• 单向异步：数据流是单向的，从发布者到订阅者。发布者发了数据就去干别的了，根本不管有没有人收、收没收到。订阅者也不知道数据是谁发的，只关心数据本身。
• 一对多/多对多：一个话题可以有多个发布者和多个订阅者，非常灵活。
• 数据流：适合连续、高频的数据传输。比如：
  • 传感器数据：摄像头图像（sensor_msgs/Image）、激光扫描（sensor_msgs/LaserScan）、IMU数据（sensor_msgs/Imu）。
  • 机器人状态：里程计（nav_msgs/Odometry）、关节角度（sensor_msgs/JointState）。
  • 控制指令（在某些简单场景）：速度指令（geometry_msgs/Twist）。

注意：Topic不保证送达（尽管底层TCP会尽力而为），也不提供直接的反馈机制。如果你需要确认指令被执行，或者需要等待一个结果才能进行下一步，Topic就不合适。

2.2 Service：同步的请求-响应“呼叫”

当你的需求从“持续广播”变成“有事呼叫”时，Service就登场了。它模拟了客户端-服务器（Client-Server）的模型。客户端（Client）发送一个请求（Request），然后阻塞等待，直到服务器（Server）处理完请求并返回一个响应（Response），或者等待超时。

关键特性与适用场景：

• 同步调用：客户端发出请求后必须等待，期间线程被挂起。这保证了逻辑的先后顺序。
• 一问一答：一次服务调用必然对应一个请求和一个响应。
• 离散命令/查询：适合那些不需要持续进行、但需要明确结果的操作。比如：
  • 开关类指令：/set_led（开/关LED）。
  • 参数设置：/set_motor_speed（设置电机转速）。
  • 触发计算：/calculate_path（给定起点终点，计算一条路径）。
  • 状态查询：/get_battery_level（查询当前电量）。

与Topic的直观对比：想象一下，Topic像是教室里的广播喇叭，老师（发布者）一直在讲，学生在不在听、听没听懂，广播不管。而Service像是学生举手提问，老师必须走到面前解答完，学生得到答案后才坐下。

2.3 Action：可监控、可中断的长期任务

Service的同步阻塞特性既是优点也是缺点。如果一个任务（比如“移动到(x,y)点”）需要执行10秒钟，客户端线程就要傻等10秒，无法取消，也看不到进度。Action就是为了解决这个问题而生的。你可以把它理解为“带进度条和取消按钮的Service”。

一个Action包含三个部分：

1. Goal：客户端发送的任务目标（比如“目标位置(x,y)”）。
2. Feedback：服务端在执行任务过程中持续发送的进度反馈（比如“当前已走完50%路径”）。
3. Result：任务最终完成（或失败）时返回的结果（比如“已到达目标”或“因障碍物失败”）。

关键特性与适用场景：

• 异步长任务：客户端发送目标后立即返回，可以去做别的事情。
• 进度反馈：通过Feedback实时了解任务进展。
• 可取消：可以在任务执行中发送取消指令。
• 复杂控制：适合所有耗时的、需要监控的控制任务。比如：
  • 机器人导航：/move_base（移动底座到目标点）。
  • 机械臂抓取：/pick_and_place（完成一整套抓取放置动作）。
  • 语音识别任务：/recognize_speech（持续监听直到识别出完整句子）。

选型决策速查表：

在实际的机器人系统中，这三种机制往往是共存的。例如，一个移动机器人可能用Topic发布激光雷达数据和里程计，用Service来切换运行模式，用Action来执行具体的导航任务。

3. 单片机与ROS通信的三大核心方案

现在来到了最硬核的部分：如何让资源受限、通常跑不了完整ROS的单片机，接入ROS的通信网络？这里有三种主流方案，各有优劣，选择哪种取决于你的单片机性能、开发周期和对实时性的要求。

3.1 方案一：rosserial——最经典、最直接的桥梁

rosserial是ROS官方为嵌入式设备（尤其是Arduino）推出的通信协议库。它的核心思想是：在单片机上实现一个精简的ROS客户端（rosserial_client），通过串口（UART）、USB或网络（TCP）等物理链路，与PC上运行的一个名为rosserial_python或rosserial_server的节点进行通信。这个服务节点充当一个“翻译官”或“代理”，将单片机通过串口发送来的原始字节流，翻译成标准的ROS消息并发布到ROS网络中，同时将ROS网络中的订阅消息翻译后发送给单片机。

工作流程：

1. 在单片机程序中，引入rosserial库（如ros_libfor Arduino）。
2. 初始化ROS节点（实际上是一个轻量级客户端），并声明发布者(Publisher)和订阅者(Subscriber)。
3. 在主循环中，调用nh.spinOnce()来处理通信，并发布传感器数据。
4. PC端，先启动roscore，然后运行rosrun rosserial_python serial_node.py /dev/ttyUSB0（以串口为例）来启动代理节点。
5. 至此，单片机上的发布者/订阅者就“映射”到了ROS网络中，其他ROS节点可以像与普通节点通信一样与之交互。

优点：

• 开发简单：单片机端API与ROS C++/Python API高度相似，学习成本低。
• 生态成熟：支持Arduino、STM32（通过HAL库）、ESP32等多种平台，社区资源丰富。
• 与ROS无缝集成：单片机节点在ROS中看起来就是一个普通节点，可以使用rostopic list,rostopic echo等所有工具进行调试。

缺点与坑点：

• 带宽和速率受限：尤其是使用串口时，波特率上限（通常115200或921600）限制了数据吞吐量，传输图像等高带宽数据非常吃力。
• 实时性一般：通信需要经过PC上的代理节点中转，引入额外延迟。
• 依赖PC：单片机必须始终连接PC并运行代理节点。
• 内存占用：ros_lib会占用单片机一定的Flash和RAM，对于资源极其紧张的8位单片机可能比较吃力。

实操心得：使用rosserial时，务必根据数据量调整串口波特率。发布消息的频率不要太高，否则容易堵塞串口缓冲区导致数据丢失。对于STM32，推荐使用CubeMX生成代码，然后手动集成ros_lib，注意处理好HAL库的串口中断与rosserial的spinOnce的配合。

3.2 方案二：Micro-ROS——面向未来的嵌入式ROS 2

如果说rosserial是ROS 1时代的解决方案，那么Micro-ROS就是为ROS 2和现代高性能微控制器（MCU）量身定制的。它是ROS 2的一个子集，专门设计运行在资源受限的微控制器上，直接使用ROS 2的通信中间件（DDS的轻量级实现，如Micro XRCE-DDS）。

架构精髓：Micro-ROS不是在单片机上跑一个完整的ROS 2，而是跑一个Micro-ROS Client。这个Client通过一种极简的传输层（如串口、UDP、TCP）与一个运行在更强力处理器（如PC或嵌入式Linux板卡）上的Micro-ROS Agent（代理）通信。Agent则作为桥梁，将Client接入到完整的ROS 2 DDS网络中。

优点：

• 真正的ROS 2原生体验：支持ROS 2的核心特性，包括服务质量(QoS)策略，可以配置可靠性、持久性、截止时间等，这是rosserial不具备的。
• 性能更优：传输效率更高，延迟通常低于rosserial。
• 支持更现代的硬件：官方积极支持ESP32、STM32、Zephyr RTOS平台等。
• 未来趋势：随着ROS 2成为主流，Micro-ROS是嵌入式端的首选方向。

缺点与挑战：

• 复杂度高：相比rosserial，部署和构建工具链更复杂，需要接触RTOS和交叉编译。
• 资源要求更高：虽然轻量，但对单片机RAM/Flash的需求仍高于rosserial，通常需要Cortex-M4及以上级别的MCU。
• 生态仍在发展：虽然发展迅速，但某些平台的支持和社区示例可能不如rosserial对于Arduino那样“傻瓜化”。

如何选择？如果你的项目基于ROS 2，且单片机性能足够（比如STM32F4/F7， ESP32），追求更低的延迟和ROS 2的高级特性，那么Micro-ROS是更好的选择。如果只是简单的ROS 1项目，或者用的是AVR Arduino这类资源紧张的板子，rosserial更简单快捷。

3.3 方案三：自定义串口/网络协议——极致的控制与效率

当以上两种方案都无法满足你的苛刻需求时——比如你需要极致的实时性、最小的通信开销，或者你的单片机根本跑不动那些库——那么回归本质，设计一个自定义的轻量级协议是最直接的方法。

核心思想：完全抛开ROS的通信库。在单片机和PC上分别编写代码，通过串口（UART）、USB-CDC、TCP/IP Socket等建立原始字节流通信。双方约定好一个简单的数据包格式，例如：[帧头][数据长度][命令字][数据载荷][校验和][帧尾]单片机按照这个格式打包传感器数据并发送；PC端用一个独立的节点（通常用Python或C++写）来接收、解析这些原始数据，然后将其“包装”成标准的ROS消息（如sensor_msgs/Imu）并发布到ROS话题上。反之，PC节点订阅ROS控制话题，收到消息后，再按照自定义协议打包发送给单片机去执行。

优点：

• 绝对的控制权：协议完全自己定义，可以做到极其精简，一个字节都不浪费。
• 极高的效率：没有中间层和通用库的开销，通信延迟可以做到最低。
• 资源消耗极小：单片机端几乎不需要额外库，几行串口发送代码即可。
• 灵活性：可以兼容任何奇奇怪怪的、无法运行ROS库的硬件。

缺点：

• 重复造轮子：你需要自己实现数据打包/解包、校验、重传等通信基础功能。
• 调试复杂：没有现成的ROS工具直接调试，需要自己写日志或借助串口助手。
• 与ROS集成度低：需要自己写一个“桥接”节点，增加了PC端的开发工作量。
• 不易维护：协议一旦确定，后期修改需要两端同步更新，容易出错。

实战建议：这种方案常见于对实时性要求极高的底层控制，比如高速电机驱动、无人机飞控。在协议设计时，一定要加入校验和（如CRC8/CRC16）来保证数据完整性。在PC端的桥接节点中，要处理好数据流的粘包和断包问题。一个常见的技巧是，在ROS节点里使用serial或pyserial库读取串口，在一个独立的线程或定时器中解析数据包并发布消息。

4. 实战演练：基于rosserial的STM32与ROS数据互通

光说不练假把式。我们以一个最常见的场景为例，手把手实现STM32通过rosserial向ROS发布超声波测距数据，并订阅ROS指令控制一个LED开关。这个例子涵盖了双向通信的基本要素。

4.1 开发环境与硬件准备

硬件清单：

• PC：安装好Ubuntu和ROS（这里以ROS Noetic为例）。
• 单片机：STM32F103C8T6（蓝桥杯常用板，即“蓝色药丸”）。
• 传感器：HC-SR04超声波模块。
• 执行器：一个LED灯和220Ω限流电阻。
• 连接线：USB转TTL串口模块（如CH340、CP2102），杜邦线若干。

接线示意图：

HC-SR04 -> STM32 VCC -> 5V Trig -> PA1 (GPIO输出) Echo -> PA2 (GPIO输入，支持外部中断或定时器输入捕获为佳) GND -> GND LED -> STM32 阳极(长脚) -> PA0 (通过220Ω电阻) 阴极(短脚) -> GND STM32 -> USB-TTL模块 PA9 (TX) -> RX PA10 (RX) -> TX 3.3V -> 3.3V (可选，为模块供电) GND -> GND

重要提示：STM32的串口1（USART1）默认引脚是PA9(TX)和PA10(RX)。确保USB-TTL模块的电压电平是3.3V，如果是5V电平，需要电平转换，否则可能损坏STM32芯片。

软件环境：

• PC端：ROS Noetic，rosserial包（sudo apt-get install ros-noetic-rosserial-*）。
• STM32端：STM32CubeIDE（用于生成HAL库代码和编译），ros_lib库。

4.2 STM32端代码详解：集成ros_lib与业务逻辑

1. 创建STM32工程：使用STM32CubeIDE，选择你的芯片型号（STM32F103C8），配置时钟树（通常使用内部8MHz RC振荡器倍频到72MHz），使能USART1为异步模式，波特率设为115200。配置PA0为推挽输出（LED），PA1为推挽输出（Trig），PA2为浮空输入（Echo）。生成代码。

2. 集成ros_lib库：

   • 在ROS环境下，进入你的STM32工程目录，运行rosrun rosserial_stm32 make_libraries.py .。这会在当前目录生成一个ros_lib文件夹。
   • 将生成的ros_lib文件夹整个拷贝到你的STM32CubeIDE工程的Core/Inc或类似头文件路径下，并在IDE中将其添加到包含路径（Include Paths）。
   • 注意：rosserial的ros.h会依赖Arduino.h，对于STM32需要做一些适配。更稳妥的方法是，直接从GitHub克隆rosserial仓库，将其中的rosserial_stm32文件夹下的STM32Hardware.h和STM32Hardware.cpp（可能需要根据你的HAL版本调整）以及ros_lib的核心文件整合到你的工程。网上有大量针对STM32CubeIDE的集成教程，这是初期最大的一个坑，需要耐心对照。

3. 编写主程序逻辑 (main.c) 关键部分：

#include "main.h" #include "ros.h" #include "std_msgs/UInt16.h" // 用于发布距离数据 #include "std_msgs/Bool.h" // 用于订阅LED控制 // ROS节点和消息声明 ros::NodeHandle nh; std_msgs::UInt16 range_msg; ros::Publisher range_pub("ultrasonic_range", &range_msg); void led_callback(const std_msgs::Bool& toggle_msg) { // 当收到Bool消息时，控制LED if(toggle_msg.data) { HAL_GPIO_WritePin(LED_GPIO_Port, LED_Pin, GPIO_PIN_SET); // 点亮 } else { HAL_GPIO_WritePin(LED_GPIO_Port, LED_Pin, GPIO_PIN_RESET); // 熄灭 } } ros::Subscriber<std_msgs::Bool> led_sub("led_control", &led_callback); // 超声波测距函数（简化版，使用HAL延时和输入捕获，实际建议用定时器） uint16_t get_distance(void) { uint32_t start_time, end_time, pulse_width; // 发送10us高电平触发信号 HAL_GPIO_WritePin(Trig_GPIO_Port, Trig_Pin, GPIO_PIN_SET); delay_us(10); HAL_GPIO_WritePin(Trig_GPIO_Port, Trig_Pin, GPIO_PIN_RESET); // 等待回响信号变高（超时处理很重要） while(HAL_GPIO_ReadPin(Echo_GPIO_Port, Echo_Pin) == GPIO_PIN_RESET); start_time = HAL_GetTick(); // 精度不高，仅示例。高精度应用请用定时器输入捕获 // 等待回响信号变低 while(HAL_GPIO_ReadPin(Echo_GPIO_Port, Echo_Pin) == GPIO_PIN_SET); end_time = HAL_GetTick(); pulse_width = end_time - start_time; // 单位ms // 声音速度约340m/s，即0.034cm/us。脉冲宽度单位ms，需换算。 // 距离 = (时间 * 声速) / 2 (往返路程) return (uint16_t)((pulse_width * 340.0) / (2 * 1000.0)); // 单位cm，简化计算 } int main(void) { // HAL初始化... // 外设初始化... // ROS节点初始化，指定串口句柄&huart1 nh.initNode(&huart1); nh.advertise(range_pub); nh.subscribe(led_sub); while (1) { // 读取超声波距离 uint16_t distance_cm = get_distance(); range_msg.data = distance_cm; range_pub.publish(&range_msg); // 处理ROS通信 nh.spinOnce(); // 延时，控制发布频率，例如10Hz HAL_Delay(100); } }

这段代码的关键在于nh.spinOnce()，它负责处理所有ROS后台的收发通信，必须在主循环中频繁调用。超声波测距函数get_distance()这里用了简单的延时和HAL_GetTick()，在实际项目中为了精度和稳定性，强烈建议使用定时器的输入捕获功能来测量高电平脉冲宽度。

4.3 PC端配置与通信测试

1. 启动ROS核心与代理节点： 打开一个终端（Terminal）。

   # 启动ROS Master roscore

   打开另一个终端。

   # 查找你的USB转串口设备，通常是/dev/ttyUSB0或/dev/ttyACM0 ls /dev/ttyUSB* # 启动rosserial_python节点，连接该设备，波特率115200 rosrun rosserial_python serial_node.py _port:=/dev/ttyUSB0 _baud:=115200

   如果连接成功，你会看到类似[INFO] [WallTime: ...] Connected to ...的日志。

2. 测试数据发布： 再打开一个终端。

   # 查看当前所有话题，应该能看到/ultrasonic_range rostopic list # 实时打印超声波距离数据 rostopic echo /ultrasonic_range

   此时，你应该能看到不断刷新的data: xxx，单位是厘米。用手在超声波传感器前移动，观察数值变化。

3. 测试指令订阅： 继续在新的终端中操作。

   # 向/led_control话题发布一个True消息，点亮LED rostopic pub -1 /led_control std_msgs/Bool "data: true" # 发布False消息，熄灭LED rostopic pub -1 /led_control std_msgs/Bool "data: false"

   观察STM32板载LED是否随命令亮灭。至此，一个完整的双向通信demo就完成了。

5. 进阶话题：性能优化与深度踩坑指南

当你成功跑通第一个例子后，接下来就会遇到真实项目中的各种挑战：数据丢包、延迟高、单片机资源耗尽等等。下面分享一些从坑里爬出来的经验。

5.1 通信性能瓶颈分析与优化策略

瓶颈1：串口波特率与数据量这是rosserial最常见的问题。标准消息（如Twist、Odometry）本身不大，但像Image或PointCloud2这种消息，一帧数据就能塞满串口缓冲区。优化策略：

• 提高波特率：在硬件和线材允许的情况下，尽量使用更高的波特率，如921600甚至1500000。需要在STM32的串口初始化和rosserial_python启动命令中同时设置。
• 压缩与降频：对于图像，可以考虑在单片机端先进行压缩（如JPEG）、降低分辨率或颜色深度，或者只发布感兴趣区域(ROI)。对于点云，可以降低发布频率，或者使用更紧凑的消息类型。
• 拆分消息：将一个大消息拆分成多个小消息序列发布。

瓶颈2：单片机处理与发布频率在nh.spinOnce()中，rosserial库需要处理订阅消息的接收和发布消息的打包发送，如果主循环中还有其他耗时任务（如复杂的传感器滤波算法），会导致spinOnce调用不及时，轻则数据更新慢，重则通信超时断开。优化策略：

• 使用中断或DMA：将传感器数据读取这类IO操作放在中断服务程序(ISR)中，或者使用DMA传输，减少主循环阻塞。
• 任务调度：如果单片机跑RTOS（如FreeRTOS），可以为ROS通信单独创建一个高优先级的任务，确保spinOnce被定期执行。
• 简化消息：使用最基本的、字段最少的标准消息，或者自定义最小的消息结构。

瓶颈3：ROS端代理节点延迟rosserial_python节点本身是Python写的，在处理高速数据流时可能成为瓶颈。优化策略：

• 使用C++版本的rosserial_server：性能通常优于Python版本。可以用rosrun rosserial_server serial_node _port:=/dev/ttyUSB0 _baud:=115200来启动。
• 调整缓冲区：在某些情况下，可以调整操作系统级别的串口缓冲区大小。

5.2 稳定性保障：连接、重连与错误处理

在实际的机器人上，USB线可能会被扯松，系统可能重启。通信链路必须足够健壮。

• 心跳机制：在单片机程序中，除了业务数据，可以定期发布一个“心跳”消息（比如一个单调递增的计数器）。PC端节点监听这个心跳，如果超过一定时间（如2秒）没收到，就认为连接断开，尝试重新初始化串口连接。
• 单片机看门狗：在STM32中使能独立看门狗(IWDG)，防止程序跑飞导致通信完全停止。在spinOnce循环中定期喂狗。
• 协议级校验：虽然rosserial协议自身有校验，但在极端干扰下仍可能出错。对于关键指令（如急停），可以在应用层设计应答机制。例如，PC发送一个“设置电机速度”的指令后，单片机执行成功则回发一个“设置成功”的确认消息。
• 优雅的重连逻辑：在PC端的启动脚本中，可以加入循环检测和重连逻辑，而不是简单运行一次serial_node.py。

5.3 从rosserial向Micro-ROS迁移的考量

当你觉得rosserial在性能或功能上无法满足需求时，就该考虑Micro-ROS了。迁移不是简单的替换库，而是架构的升级。

• 评估硬件：确认你的MCU（如STM32F4、ESP32）有足够的资源（>128KB RAM， >512KB Flash是较好的起点），并且有官方或社区支持的Micro-ROS移植层（Client层）。
• 理解构建系统：Micro-ROS通常使用colcon和ros2的构建系统，需要搭建交叉编译环境，这比rosserial复制ros_lib要复杂得多。
• 重写节点逻辑：API虽然相似，但毕竟是ROS 2的API，话题、服务的定义和使用方式需要按照ROS 2的规范来。你需要学习rclc（ROS 2 Client Library for C）的API。
• 配置QoS：这是Micro-ROS最大的优势之一。你需要根据数据重要性选择QoS策略。比如，激光雷达数据使用Best Effort（尽力而为）策略以获得低延迟，而导航目标点使用Reliable（可靠）策略确保必达。
• 部署Agent：你需要在PC或一个嵌入式Linux设备上运行Micro-ROS Agent，它负责桥接MCU和ROS 2网络。这增加了一个必须运行的组件。

迁移过程就像把一个小卖部（rosserial）升级成一个现代化的物流分拣中心（Micro-ROS），前期投入大，但一旦建成，处理能力、可靠性和可管理性都会上一个台阶。

6. 项目实战：构建一个简易的ROS遥控小车

让我们把所有知识串联起来，设计一个综合性的小项目：用ROS和STM32实现一个蓝牙/Wi-Fi遥控小车。这里我们选择ESP32作为主控，因为它集成了Wi-Fi和蓝牙，可以直接使用rosserial或Micro-ROS通过网络通信，摆脱线缆束缚。

系统架构：

1. 感知层：ESP32读取两个电机编码器的脉冲（用于里程计计算），并连接一个MPU6050 IMU。
2. 通信层：ESP32通过Wi-Fi，使用rosserial的TCP模式或Micro-ROS连接到家庭路由器，与同一网络下的PC进行通信。
3. 控制层：PC上运行ROS节点。一个节点订阅游戏手柄（如joy节点）的话题，将其转换为geometry_msgs/Twist速度指令。另一个节点（robot_base_controller）订阅这个速度指令，并通过ROS通信发送给ESP32。同时，这个节点也订阅ESP32发布的编码器和IMU数据，融合后发布nav_msgs/Odometry话题。
4. 执行层：ESP32收到速度指令后，通过PID控制器计算PWM输出，驱动电机驱动板（如L298N或TB6612）控制两个直流电机差速转动。

关键实现步骤：

1. ESP32端（以rosserial over WiFi为例）：

   • 配置ESP32连接Wi-Fi。
   • 初始化ros::NodeHandle，但使用WiFiHardware类代替SerialHardware。

   #include <WiFi.h> #include <ros.h> #include <geometry_msgs/Twist.h> #include <sensor_msgs/Imu.h> #include <nav_msgs/Odometry.h> const char* ssid = "your_SSID"; const char* password = "your_PASSWORD"; IPAddress server(192, 168, 1, 100); // PC的IP地址 const uint16_t serverPort = 11411; // rosserial默认TCP端口 ros::NodeHandle nh; void cmdVelCallback(const geometry_msgs::Twist& twist_msg) { // 解算左右轮目标速度 float linear = twist_msg.linear.x; float angular = twist_msg.angular.z; // ... 根据差速运动学模型计算 ... // 设置电机PWM } ros::Subscriber<geometry_msgs::Twist> cmd_sub("cmd_vel", &cmdVelCallback); sensor_msgs::Imu imu_msg; ros::Publisher imu_pub("imu/data", &imu_msg); nav_msgs::Odometry odom_msg; ros::Publisher odom_pub("odom", &odom_msg); void setup() { WiFi.begin(ssid, password); while (WiFi.status() != WL_CONNECTED) { delay(500); } nh.getHardware()->setConnection(server, serverPort); nh.initNode(); nh.advertise(imu_pub); nh.advertise(odom_pub); nh.subscribe(cmd_sub); // 初始化电机、编码器、IMU... } void loop() { // 读取编码器计数，计算里程计 // 读取IMU数据，填充imu_msg // 发布imu_msg和odom_msg nh.spinOnce(); delay(10); // 控制循环频率 }

2. PC端：

   • 启动roscore。
   • 启动rosserial的TCP服务器节点：rosrun rosserial_python serial_node.py tcp。这个命令会启动一个TCP服务器，等待ESP32连接。
   • 启动游戏手柄节点：rosrun joy joy_node。
   • 运行一个teleop_twist_joy或自己写的节点，将手柄数据转换为/cmd_vel。
   • 运行robot_base_controller节点（需要自己编写或使用diff_drive_controller等包），它订阅/cmd_vel并通过rosserial发送给ESP32，同时接收ESP32发布的/odom和/imu/data，进行融合后发布更准确的/odom话题。

避坑要点：

• 网络延迟：Wi-Fi通信会有不确定的延迟，不适合超高速或高精度的控制。对于要求高的场合，考虑使用有线以太网（如ESP32-Ethernet）或更实时的通信协议。
• 里程计累积误差：仅靠编码器计算里程计（航迹推算）会随着时间产生巨大漂移，必须融合IMU（陀螺仪和加速度计）数据，并通过扩展卡尔曼滤波(EKF)或互补滤波进行传感器融合。ROS中的robot_pose_ekf或imu_filter_madgwick包可以帮助完成这部分工作。
• 电源管理：电机启动瞬间电流很大，会导致ESP32重启。务必为电机驱动板和单片机使用独立电源，或使用大容量电容进行缓冲。

通过这样一个完整的项目，你会深刻体会到ROS通信机制如何将感知、决策、控制模块解耦，并通过标准的消息接口连接在一起。单片机不再是孤立的硬件，而是整个智能机器人系统中一个有机的、可被远程监控和控制的组成部分。