📚 课程目录第2章 ROS通信机制深度解析

2. ROS通信机制深度解析

各位同学，欢迎来到第二章。上一章我们聊了ROS的整体架构，今天咱们直接切入核心——通信机制。

ROS之所以能成为机器人领域的“事实标准”，说白了就是因为它把这四种通信模型玩明白了。我刚开始接触ROS时，也经常搞混Topic和Service的区别，后来在做一个多机器人协作项目时踩了坑，才真正理解它们各自的定位。

今天我们就一个一个拆开来看。

2.1 Topic通信模型——发布/订阅模式

Topic是ROS里最常用的通信方式。它的核心思想很简单：发布者只管发，订阅者只管收，双方不需要知道对方的存在。

核心特点：

异步通信：发布者不等待订阅者响应
一对多：一个Topic可以有多个发布者和订阅者
无连接：节点之间没有直接握手
数据流：适合持续更新的数据，比如传感器数据、状态信息

举个例子，你有一个摄像头节点在发布图像数据，另外三个节点——图像处理、显示、录像——都在订阅同一个Topic。摄像头节点根本不需要知道谁在收数据，它只管按自己的频率往外发。

我在项目中遇到过一个问题：某个激光雷达节点发布频率是40Hz，但订阅节点处理不过来，导致消息队列越积越多，最后内存爆了。嗯，这里要注意——ROS的Topic消息队列默认是无限增长的，你最好根据实际情况设置队列长度。

# 发布者示例
import rospy
from std_msgs.msg import String

rospy.init_node('talker')
pub = rospy.Publisher('chatter', String, queue_size=10)
rate = rospy.Rate(10)  # 10Hz

while not rospy.is_shutdown():
    msg = String()
    msg.data = "hello %s" % rospy.get_time()
    pub.publish(msg)
    rate.sleep()

# 订阅者示例
import rospy
from std_msgs.msg import String

def callback(msg):
    rospy.loginfo("I heard: %s", msg.data)

rospy.init_node('listener')
sub = rospy.Subscriber('chatter', String, callback)
rospy.spin()

个人建议：Topic的命名最好用层级结构，比如/robot/left_wheel/velocity。这样在大型项目中，你一眼就能看出数据来源和类型。我曾经接手过一个项目，Topic命名全是/topic1、/topic2……那叫一个酸爽。

2.2 Service通信模型——请求/响应模式

Topic适合持续的数据流，但有些场景你需要“问一句，答一句”。比如你让机械臂去抓一个杯子，你发一个请求，它返回成功或失败。这时候就该Service上场了。

Service是同步通信。客户端发送请求后，会阻塞等待服务器返回响应。你想想看，这就像你打电话问客服：“我的订单到哪了？”——你得等对方查完告诉你，才能挂电话。

特性	Topic	Service
通信模式	发布/订阅	请求/响应
同步/异步	异步	同步（阻塞）
适用场景	持续数据流	一次性任务
多对多	支持	不支持（一对一）
超时处理	无	需要手动设置

我曾经犯过一个错误：在控制机器人导航时，用Service来请求路径规划。结果路径规划耗时3秒，整个控制循环就被卡死了。后来改成Action才解决问题——这个我们马上讲。

# Service服务器端
def handle_add_two_ints(req):
    return AddTwoIntsResponse(req.a + req.b)

rospy.init_node('add_two_ints_server')
s = rospy.Service('add_two_ints', AddTwoInts, handle_add_two_ints)
rospy.spin()

# Service客户端
rospy.wait_for_service('add_two_ints')
try:
    add_two_ints = rospy.ServiceProxy('add_two_ints', AddTwoInts)
    resp = add_two_ints(3, 5)
    print(resp.sum)
except rospy.ServiceException as e:
    print("Service call failed: %s"%e)

避坑指南：Service调用一定要加超时处理！我曾经在一个项目中，Service服务器节点崩溃了，客户端一直阻塞等待，整个系统都hang住了。用rospy.wait_for_service('service_name', timeout=5)可以避免这个问题。

2.3 Action通信模型——带反馈的任务执行

好，现在说Action。为什么需要Action？你想想看，如果我要让机器人从A点走到B点，这个过程可能需要10秒。用Service的话，客户端要阻塞10秒，这显然不合理。用Topic的话，你得自己实现状态管理，太麻烦。

Action就是为这种长时间任务设计的。它提供了三个核心能力：

Goal：发送目标
Feedback：实时反馈进度
Result：最终结果

说白了，Action = Service + 实时反馈 + 可取消。我个人习惯把Action理解为“带进度条的任务管理器”。

# Action服务器端（简化版）
class MoveRobotAction(object):
    def execute_cb(self, goal):
        rate = rospy.Rate(1)
        for i in range(10):
            # 模拟移动过程
            feedback = MoveRobotFeedback()
            feedback.progress = i * 10
            self._as.publish_feedback(feedback)
            rate.sleep()
        
        result = MoveRobotResult()
        result.success = True
        self._as.set_succeeded(result)

rospy.init_node('move_robot_server')
as_ = actionlib.SimpleActionServer('move_robot', MoveRobotAction, execute_cb, auto_start=False)
as_.start()

Action vs Service 选择指南：

任务耗时 < 1秒 → 用Service
任务耗时 > 1秒，需要反馈 → 用Action
任务可能被取消 → 用Action
需要实时进度 → 用Action

2.4 参数服务器——全局共享的配置中心

参数服务器是ROS里一个特殊的存在。它不像Topic那样传输数据流，也不像Service那样做远程调用。它的作用很简单：存一些全局配置参数。

比如机器人的最大速度、PID参数、相机分辨率这些，你不想写死在代码里，就可以放到参数服务器上。任何节点都可以随时读取或修改。

# 设置参数
rospy.set_param('max_speed', 1.5)
rospy.set_param('pid/kp', 0.8)
rospy.set_param('pid/ki', 0.01)

# 读取参数
max_speed = rospy.get_param('max_speed', 1.0)  # 带默认值
kp = rospy.get_param('pid/kp')

我的习惯：所有可调参数都放到参数服务器上，然后在launch文件中用<param>标签加载。这样调试时改参数不用重新编译，直接rosparam set就行。但要注意——参数服务器不是数据库，别往里面塞大数据。

2.5 四种通信模型对比总结

到这里，四种通信模型都讲完了。我画了一张图帮你理清它们的关系：

最后给你一个实战中的选择思路：

先看数据流向：是持续流还是单次请求？持续流用Topic，单次请求看下一步。
再看耗时：短耗时（毫秒级）用Service，长耗时（秒级以上）用Action。
最后看是否需要反馈：需要实时进度反馈？必须用Action。
参数怎么办：所有节点共享的配置，丢到参数服务器里。