2、ROS2核心通信机制：话题、服务、动作的底层原理与对比
说实话，搞ROS2自动驾驶开发，通信机制是绕不开的坎。我见过太多新手，上来就写代码，结果节点之间数据传不过去，或者卡死在那，一脸懵。
今天咱们就把话题、服务、动作这三个家伙扒个底朝天。你搞懂了它们，后面写代码会顺手很多。
2.1 话题（Topic）—— 最常用的“广播站”
话题是ROS2里最基础的通信方式。说白了，就是一个节点发消息，其他节点收消息。发的人不管谁在收，收的人也不管谁在发。
我习惯把话题比作电台广播。电台只管播，你爱听不听。你打开收音机，调到那个频率，就能收到。
核心特点：
- 异步通信：发送方和接收方不用等对方。发完就走，收完就处理。
- 一对多/多对多：一个话题可以有多个发布者，也可以有多个订阅者。
- 无反馈：发布者不知道消息有没有被收到，订阅者也不知道发布者是谁。
我在项目中遇到过一个问题：激光雷达的数据量很大，如果用服务去传，节点会卡死。后来换成话题，一点事没有。为什么？因为话题是异步的，不会阻塞。
# 发布者示例
import rclpy
from rclpy.node import Node
from std_msgs.msg import String
class Talker(Node):
def __init__(self):
super().__init__('talker')
self.pub = self.create_publisher(String, 'chatter', 10)
self.timer = self.create_timer(1.0, self.timer_callback)
def timer_callback(self):
msg = String()
msg.data = 'Hello, ROS2!'
self.pub.publish(msg)
self.get_logger().info(f'发布: {msg.data}')避坑指南：我曾经把话题的QoS设置成“可靠”，结果在弱网环境下，数据延迟特别大。后来改成“尽力而为”，实时性就好了很多。你想想看，自动驾驶里，控制指令可以丢一帧，但绝对不能延迟。
2.2 服务（Service）—— 一问一答的“客服”
服务和话题不一样。它是同步的，客户端发一个请求，服务端处理完再返回响应。就像你打电话问客服：“我的快递到哪了？”客服查完告诉你：“已经到小区门口了。”
嗯，这里要注意：服务是一对一的。一个服务端只能处理一个客户端的请求。如果有多个客户端同时请求，服务端会排队处理。
核心特点：
- 同步通信：客户端发送请求后，必须等待服务端返回响应。
- 一对一：一个服务端对应一个客户端（但可以有多个客户端轮流请求）。
- 有反馈：客户端能知道请求是否成功，以及返回的数据。
我建议在需要确认结果的场景用服务。比如，自动驾驶里“切换导航模式”，你发一个请求，服务端确认“切换成功”或“切换失败”，你才能继续下一步。
# 服务端示例
class ServiceNode(Node):
def __init__(self):
super().__init__('service_node')
self.srv = self.create_service(AddTwoInts, 'add_two_ints', self.add_callback)
def add_callback(self, request, response):
response.sum = request.a + request.b
self.get_logger().info(f'收到请求: {request.a} + {request.b} = {response.sum}')
return response警告：千万别在服务回调里做耗时操作。我曾经在服务里调了一个图像处理算法，结果客户端等了几秒才返回，整个系统都卡住了。服务只适合做轻量级、快速响应的操作。
2.3 动作（Action）—— 带反馈的“长任务”
动作是ROS2里最复杂的通信机制，但也是最强大的。它结合了话题和服务的优点：像服务一样有目标，像话题一样有反馈。
你想想看，自动驾驶里“泊车”这个任务。你告诉车：“去那个车位停好。”车开始执行，同时不断反馈：“正在倒车”、“距离障碍物0.5米”、“已停好”。这就是动作。
核心特点：
- 异步+同步混合：发送目标后，可以继续做其他事，同时接收反馈。
- 可取消：执行过程中可以取消任务。
- 有反馈：执行过程中不断返回中间状态。
- 有结果：任务完成后返回最终结果。
我个人习惯在需要长时间执行、且需要中间反馈的场景用动作。比如路径规划、机械臂控制、车辆变道等。
# 动作服务端示例（简化）
class MoveRobotActionServer(Node):
def __init__(self):
super().__init__('move_robot_server')
self.action_server = ActionServer(
self,
MoveRobot,
'move_robot',
self.execute_callback
)
async def execute_callback(self, goal_handle):
feedback_msg = MoveRobot.Feedback()
for i in range(10):
feedback_msg.progress = (i + 1) * 10
goal_handle.publish_feedback(feedback_msg)
await asyncio.sleep(1)
goal_handle.succeed()
return MoveRobot.Result(success=True)避坑指南：我曾经在动作回调里忘记调用goal_handle.succeed()，结果客户端一直等，超时了。记住，动作执行完一定要设置结果状态，否则客户端会一直挂在那。
2.4 三种机制的对比
咱们用一张表来对比，这样更直观。
| 特性 | 话题（Topic） | 服务（Service） | 动作（Action） |
|---|---|---|---|
| 通信模式 | 异步 | 同步 | 异步+同步 |
| 通信方向 | 单向（发布→订阅） | 双向（请求→响应） | 双向（目标→反馈→结果） |
| 是否阻塞 | 不阻塞 | 阻塞 | 不阻塞 |
| 是否可取消 | 否 | 否 | 是 |
| 是否有反馈 | 否 | 仅最终结果 | 中间反馈+最终结果 |
| 适用场景 | 传感器数据、状态广播 | 参数查询、简单指令 | 长任务、复杂控制 |
说白了，选哪个取决于你的需求：
- 如果只是“发出去不管”，用话题。
- 如果需要“问一句答一句”，用服务。
- 如果需要“下个任务，边做边汇报”，用动作。
2.5 底层原理：DDS在背后做了什么？
ROS2的通信底层用的是DDS（数据分发服务）。你可能没直接接触过DDS，但它一直在默默工作。
我简单解释一下：DDS是一个中间件，它负责发现节点、管理数据流、保证可靠性。ROS2的话题、服务、动作，本质上都是DDS的封装。
举个例子，当你创建一个话题发布者时，DDS会在网络里广播：“嘿，我在这里，我发chatter话题。”订阅者收到广播后，就会和发布者建立连接。这个过程叫自动发现。
底层原理要点：
- 发现机制：节点启动时，通过DDS的发现协议找到彼此。
- 数据序列化：消息在发送前会被序列化成二进制流，接收后再反序列化。
- QoS策略：可靠性、持久性、历史记录等，都由DDS管理。
嗯，这里要注意：DDS的QoS策略直接影响通信性能。我建议你在自动驾驶项目里，传感器数据用“尽力而为”，控制指令用“可靠”。
2.6 核心逻辑图
下面这张图展示了三种通信机制的核心逻辑。我画得比较简洁，但关键点都在里面了。
这张图把三种机制放在一起对比。你看，话题是单向的，服务是双向但一次性的，动作是双向且持续的。搞懂这个，你就能根据场景选对工具了。
个人经验：我刚开始做ROS2开发时，总喜欢用服务，觉得有反馈才放心。后来发现，服务用多了，系统响应越来越慢。其实，大部分场景用话题就够了。你想想看，激光雷达每秒发10帧数据，你每帧都要确认？没必要。
好了，这一章的内容就到这里。三种通信机制的原理和对比，你应该心里有数了。下一章咱们会深入QoS配置，那是调优的关键。