2. ROS基础回顾

在无人车系统中，ROS（Robot Operating System）承担着“软件总线”的角色，将感知、决策、规划、控制等模块连接为一个整体。理解ROS的四大通信机制——节点、话题、服务、动作——是掌握无人车运动控制接口的前提。本章将从工程实践角度出发，梳理这些机制的核心原理、适用场景，并结合无人车底盘控制的实际案例，说明如何将模型输出的目标速度、转向角等结果，通过ROS接口可靠地发送给底层执行器。

上图展示了无人车运动控制中ROS通信机制的整体架构。感知/决策节点（如运行深度学习模型的节点）计算出目标速度和转向角后，通过话题发布到 /cmd_vel；运动控制节点订阅该话题，经过安全校验和滤波后，通过服务或动作接口与底盘驱动节点交互；底盘驱动节点最终将控制指令通过串口发送给电机控制器。整个链路中，话题负责高频数据流，服务负责低频控制，动作负责需要反馈的复杂任务。

2.1 核心原理：ROS通信机制的本质与分工

ROS采用分布式架构，不同节点（Node）之间通过三种主要机制通信：话题（Topic）、服务（Service）、动作（Action）。理解它们的本质区别，是设计无人车控制接口的基础。

• 话题（Topic）：异步、单向、持续的数据流。发布者（Publisher）向话题发送消息，订阅者（Subscriber）接收消息。适合传感器数据、速度指令等周期性数据。在无人车中，/cmd_vel（速度指令）和/odom（里程计）是典型话题。
• 服务（Service）：同步、双向、一次性的请求-应答。客户端（Client）发送请求，服务端（Server）处理后返回响应。适合开关控制、参数查询等低频操作。例如，/enable_motor服务用于使能或禁用电机。
• 动作（Action）：异步、双向、带反馈和取消机制的任务模式。客户端发送目标（Goal），服务端执行并持续反馈（Feedback），最终返回结果（Result）。适合路径跟踪、机械臂抓取等耗时任务。在无人车中，/follow_path动作可接收一系列路径点，并实时反馈执行进度。

2.2 判断方法：如何选择正确的通信机制

在设计无人车控制接口时，可按照以下流程判断使用哪种机制：

1. 判断数据流向：是单向持续流，还是双向请求-应答？单向流选话题，双向选服务或动作。
2. 判断是否需要反馈：如果客户端需要知道任务执行进度，选动作；如果只需要最终结果，选服务。
3. 判断频率：高频（>10Hz）选话题，低频（<1Hz）选服务，任务级（秒级）选动作。
4. 判断是否可取消：如果任务可能被中断（如紧急避障），必须选动作。

例如，当模型输出目标速度时，控制节点需要以20Hz频率持续接收，此时话题是唯一合理选择。而当用户通过遥控器按下“急停”按钮时，需要确认底盘确实停止，此时服务更合适。

2.3 案例拆解：基于ROS话题的差速底盘速度控制

下面通过一个差速底盘无人车的实例，展示如何将模型输出的线速度和角速度转换为ROS话题消息，并最终通过串口控制电机。

背景与约束：某差速底盘无人车使用STM32作为底层控制器，通过串口与上位机（运行ROS）通信。上位机运行YOLO目标检测模型，输出目标速度。要求控制周期为20Hz，串口波特率115200，通信协议为自定义帧格式。

初始现象：模型输出的速度指令直接通过串口发送，但出现两个问题：一是速度指令不连续，导致电机抖动；二是无法与ROS生态中的其他模块（如导航栈）集成。

关键输入数据：模型输出线速度 0.5 m/s，角速度 0.2 rad/s；底盘轮距 0.5m；轮子半径 0.1m。

分析判断过程：问题根源在于没有使用ROS标准接口。解决方案是：在上位机创建ROS节点，将模型输出封装为 geometry_msgs/Twist 消息发布到 /cmd_vel 话题；另建一个底盘驱动节点订阅该话题，将Twist转换为左右轮速度，再封装为串口帧发送。

实际操作步骤：

# 1. 创建速度发布节点（Python伪代码）
import rospy
from geometry_msgs.msg import Twist

rospy.init_node('model_velocity_publisher')
pub = rospy.Publisher('/cmd_vel', Twist, queue_size=10)
rate = rospy.Rate(20)  # 20Hz

while not rospy.is_shutdown():
    twist = Twist()
    twist.linear.x = 0.5   # 线速度 m/s
    twist.angular.z = 0.2  # 角速度 rad/s
    pub.publish(twist)
    rate.sleep()

# 2. 底盘驱动节点订阅并转换
def cmd_vel_callback(msg):
    v = msg.linear.x
    w = msg.angular.z
    # 差速模型：左轮速度 = v - w*L/2，右轮速度 = v + w*L/2
    v_left = v - w * 0.25
    v_right = v + w * 0.25
    # 转换为电机转速并封装串口帧
    send_serial_frame(v_left, v_right)

rospy.Subscriber('/cmd_vel', Twist, cmd_vel_callback)
rospy.spin()

结果对比：改造后，速度指令平滑连续，电机抖动消失；同时，ROS导航栈（如move_base）可以直接发布 /cmd_vel，无需修改底盘驱动代码，实现了模块解耦。

风险与代价：串口通信存在延迟和丢帧风险，需在驱动节点中加入超时重发机制；另外，/cmd_vel 话题可能被多个节点同时发布，需使用 rostopic 工具监控发布频率，避免冲突。

2.4 常见误区与总结复盘

在ROS与无人车运动控制的结合中，初学者常犯以下错误：

• 误区一：所有通信都用话题。例如用话题发送使能信号，无法确认底盘是否响应。正确做法是使用服务，通过响应值判断执行结果。
• 误区二：忽略消息类型匹配。例如将 Twist 消息的线速度赋给 angular.z，导致转向异常。应严格遵循ROS标准消息定义。
• 误区三：串口通信不设超时。当串口阻塞时，ROS节点会卡死，导致控制中断。应在驱动节点中设置串口读取超时（如100ms），并加入看门狗机制。
• 误区四：话题队列设置不当。对于高频控制指令，queue_size 应设为1（只保留最新数据），避免订阅者处理不及时导致延迟累积。

总结：ROS的节点、话题、服务、动作机制为无人车运动控制提供了清晰的软件架构。节点负责模块化，话题负责高频数据流，服务负责可靠控制，动作负责复杂任务。在实际工程中，应遵循“话题传数据、服务传指令、动作传任务”的原则，并结合串口通信的可靠性设计，才能构建稳定、可扩展的无人车控制系统。