📚 课程目录第4章 ROS2通信机制

4. ROS2通信机制：话题通信的发布与订阅、消息类型、QoS策略

4.1 核心原理：从“点对点”到“发布-订阅”的范式转变

ROS2的通信核心并非传统的客户端-服务器模式，而是采用了发布-订阅（Pub/Sub）模型。在这个模型中，数据的生产者（Publisher）和消费者（Subscriber）彼此并不直接知晓对方的存在，而是通过一个中心化的话题（Topic）作为中介。这种解耦设计带来了巨大的灵活性：一个节点可以同时发布多个话题，也可以订阅多个话题；多个发布者可以往同一个话题发送数据，多个订阅者也可以同时接收同一话题的数据，彼此之间互不干扰。

与ROS1相比，ROS2的底层通信不再依赖TCPROS/UDPROS，而是基于DDS（Data Distribution Service）中间件。DDS提供了真正的分布式发现机制，节点启动后通过DDS的发现协议自动寻找匹配的话题，无需ROS Master进行集中式注册。这意味着系统没有单点故障，更适合多机器人协同和实时性要求较高的场景。

  关键理解：话题通信的本质是“数据流”的传递，而非“服务调用”。发布者只管往“河流”里放数据，订阅者只管从“河流”里取数据，至于谁在上下游，系统不关心。

4.2 消息类型：通信的“通用语言”

话题上传输的数据必须遵循特定的结构，这就是消息类型（Message Type）。ROS2的消息定义文件以.msg结尾，采用与C语言类似的字段定义语法。每个消息由若干字段组成，每个字段包含类型和名称。消息类型是话题通信的“契约”，发布者和订阅者必须使用完全相同的消息类型才能正常通信。

ROS2内置了大量常用消息类型，分布在不同的功能包中：

std_msgs：基础类型封装，如 std_msgs/msg/String、std_msgs/msg/Int32、std_msgs/msg/Float64 等。
geometry_msgs：几何相关，如 geometry_msgs/msg/Point、geometry_msgs/msg/Pose、geometry_msgs/msg/Twist（速度控制常用）。
sensor_msgs：传感器数据，如 sensor_msgs/msg/Image（图像）、sensor_msgs/msg/LaserScan（激光雷达）、sensor_msgs/msg/Imu（惯性测量单元）。
nav_msgs：导航相关，如 nav_msgs/msg/Odometry（里程计）、nav_msgs/msg/Path（路径）。

自定义消息类型时，需要在功能包的msg/目录下创建.msg文件，并在CMakeLists.txt和package.xml中声明依赖。例如创建一个描述机器人状态的消息：

# 文件: my_robot_msgs/msg/RobotStatus.msg
string robot_name
float32 battery_level    # 0.0 ~ 1.0
bool   is_moving
geometry_msgs/Pose pose  # 可嵌套其他消息类型

编译后，ROS2会自动生成对应语言的代码类（如Python中的RobotStatus类），开发者直接实例化并填充字段即可。

4.3 方法流程：从创建到通信的完整步骤

实现一个话题通信程序，通常遵循以下流程。以Python为例，发布端和订阅端的核心逻辑如下：

步骤	发布端（Publisher）	订阅端（Subscriber）
1. 导入模块	`from std_msgs.msg import String`	`from std_msgs.msg import String`
2. 创建节点	`node = rclpy.create_node('talker')`	`node = rclpy.create_node('listener')`
3. 创建发布/订阅对象	`pub = node.create_publisher(String, 'chatter', 10)`	`sub = node.create_subscription(String, 'chatter', callback, 10)`
4. 编写逻辑	循环中构造消息并调用 `pub.publish(msg)`	定义回调函数处理接收到的消息
5. 保持运行	`rclpy.spin(node)` 或手动循环	`rclpy.spin(node)` 等待回调

一个最小发布端示例：

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'Publishing: {msg.data}')

def main(args=None):
    rclpy.init(args=args)
    node = Talker()
    rclpy.spin(node)
    node.destroy_node()
    rclpy.shutdown()

订阅端只需将create_publisher改为create_subscription，并传入回调函数。回调函数会在每次收到消息时被自动调用。

4.4 QoS策略：通信质量的“调节旋钮”

QoS（Quality of Service，服务质量）是ROS2通信中最重要的新特性之一。它允许开发者针对不同场景调整通信行为，在实时性、可靠性和资源消耗之间做出权衡。QoS策略的核心参数包括：

Reliability（可靠性）：RELIABLE（保证送达，适用于控制指令）或 BEST_EFFORT（尽力而为，适用于传感器数据流）。
Durability（持久性）：VOLATILE（不保留历史数据）或 TRANSIENT_LOCAL（为后加入的订阅者保留最近数据）。
History（历史记录）：KEEP_LAST(N)（保留最近N条）或 KEEP_ALL（保留全部）。
Deadline（截止时间）：两次消息发布的最大间隔，超时则触发警告。

常见误区：发布端和订阅端的QoS必须兼容才能通信。例如，发布端使用 BEST_EFFORT，订阅端使用 RELIABLE，则通信会失败或降级。ROS2的规则是：如果一端要求 RELIABLE，另一端必须也提供 RELIABLE 才能匹配。

实际选择建议：

控制指令（如/cmd_vel）：使用 RELIABLE + KEEP_LAST(1)，确保指令不丢失。
图像/点云数据：使用 BEST_EFFORT + KEEP_LAST(5)，允许丢帧但保持实时性。
地图数据（如/map）：使用 TRANSIENT_LOCAL，让新订阅者立即获取当前地图。

4.5 案例场景：激光雷达数据转发与可视化

假设我们有一个机器人，搭载了激光雷达，需要将扫描数据从采集节点转发到可视化节点。采集节点发布sensor_msgs/msg/LaserScan话题，可视化节点订阅该话题并在RViz中显示。

采集节点（模拟数据）核心代码：

from sensor_msgs.msg import LaserScan
import math

class LaserPublisher(Node):
    def __init__(self):
        super().__init__('laser_publisher')
        # 使用 BEST_EFFORT，因为激光数据允许丢帧
        qos = QoSProfile(depth=5, reliability=QoSReliabilityPolicy.BEST_EFFORT)
        self.pub = self.create_publisher(LaserScan, '/scan', qos)
        self.timer = self.create_timer(0.1, self.publish_scan)

    def publish_scan(self):
        msg = LaserScan()
        msg.header.stamp = self.get_clock().now().to_msg()
        msg.header.frame_id = 'laser_frame'
        msg.angle_min = 0.0
        msg.angle_max = 2 * math.pi
        msg.angle_increment = math.pi / 180  # 1度分辨率
        msg.range_min = 0.1
        msg.range_max = 10.0
        msg.ranges = [5.0] * 360  # 模拟距离
        self.pub.publish(msg)

可视化节点订阅时，必须使用兼容的QoS：

qos = QoSProfile(depth=5, reliability=QoSReliabilityPolicy.BEST_EFFORT)
self.sub = self.create_subscription(LaserScan, '/scan', self.scan_callback, qos)

如果可视化节点使用默认的RELIABLE，则无法接收到数据。此时终端会显示警告："New publisher discovered on topic /scan, offering incompatible QoS"。

4.6 误区与复盘：常见问题排查

复盘清单：当话题通信不工作时，按以下顺序排查：

消息类型是否一致？使用 ros2 topic info /topic 查看类型。
QoS是否兼容？使用 ros2 topic info -v /topic 查看发布端和订阅端的QoS设置。
节点是否在同一个DDS域？检查 ROS_DOMAIN_ID 环境变量是否一致。
话题名称是否拼写正确？使用 ros2 topic list 查看实际话题列表。
回调是否被阻塞？如果回调中执行耗时操作，会阻塞后续消息处理，考虑使用多线程执行器。

另一个常见误区是混淆话题与服务。话题用于持续的数据流（如传感器数据），而服务用于请求-响应模式（如调用某个功能）。如果试图用话题实现“请求-应答”，往往需要额外的状态管理，不如直接使用服务来得清晰。

最后，务必注意消息的内存管理。在Python中，发布消息时如果复用同一个消息对象并修改字段，可能会导致数据竞争。建议每次发布时创建新消息，或使用copy.deepcopy()确保数据隔离。