第2章通信机制基础

通信机制基础：发布-订阅模式、服务-客户端模式、数据分发服务（DDS）核心概念

各位同学，今天我们来聊聊智驾系统里最核心的“血管”——通信机制。你想想看，一辆自动驾驶汽车上，摄像头、激光雷达、毫米波雷达、IMU、GPS、规划模块、控制模块……几十上百个节点，每秒产生海量数据。它们怎么高效、可靠地交换信息？这就是我们今天要啃的硬骨头。

我个人习惯把通信机制比作一个城市的交通系统。有的像“广播电台”（发布-订阅），有的像“打电话”（服务-客户端），还有的像“智能物流网”（DDS）。咱们一个一个来看。

1. 发布-订阅模式：一对多的“广播电台”

这是智驾系统里最常用的模式，没有之一。说白了，就是“谁说话，谁听者自取”。

核心角色：

发布者（Publisher）： 只管把数据扔到“频道”上，不关心谁在听。比如摄像头节点发布“图像数据”。
订阅者（Subscriber）： 只关心自己感兴趣的“频道”，数据来了就处理。比如感知模块订阅“图像数据”和“点云数据”。
通道（Topic）： 数据的“频道名”，比如 /camera/image_raw、/lidar/points。

关键优势： 解耦。发布者和订阅者不需要知道对方的存在。你可以随时增加一个订阅者，或者替换一个发布者，系统其他部分完全不受影响。这在迭代飞快的智驾开发中，简直是救命稻草。

我在项目中遇到过一个问题：某个激光雷达驱动挂了，结果整个感知链路都卡死了。为什么？因为订阅者用了同步阻塞的方式去等数据。后来我改成异步回调，并且加了超时保护，问题就解决了。嗯，这里要注意：发布-订阅模式虽然解耦了逻辑，但没解耦时间依赖。订阅者如果处理太慢，数据就会堆积，内存迟早爆掉。

来个简单的伪代码示例，感受一下：

// 发布者
Publisher pub = node->create_publisher<Image>("/camera/image_raw");
while (running) {
    Image img = camera->capture();
    pub->publish(img);
}

// 订阅者
Subscriber sub = node->create_subscriber<Image>("/camera/image_raw",
    [](const Image& img) {
        // 处理图像，比如目标检测
        detect_objects(img);
    });

2. 服务-客户端模式：一问一答的“打电话”

有些场景，你不想“广播”，而是想“问一个问题，等一个确切的回答”。比如：规划模块问定位模块“我现在在哪？”，定位模块必须回答一个精确坐标。这就是服务-客户端模式。

核心角色：

服务端（Service Server）： 提供某种功能，等待客户端来“呼叫”。比如定位服务、地图服务。
客户端（Service Client）： 发起请求，然后阻塞等待（或异步等待）响应。

我的建议： 服务-客户端模式适合“低频、高可靠性、需要确认”的操作。比如“初始化标定参数”、“查询地图版本”、“触发紧急制动”。千万别用它来传高频传感器数据，否则系统会卡成PPT。

我曾经踩过一个坑：用服务模式去传每帧的障碍物列表。结果每帧都要等几百微秒的RTT（往返时间），整个控制周期直接超时。后来改成发布-订阅模式，延迟从毫秒级降到了微秒级。所以，选对模式比写对代码更重要。

代码示例：

// 服务端：提供“获取当前位置”服务
ServiceServer server = node->create_service<GetPose>("/get_pose",
    [](const Request& req, Response& res) {
        res.x = gps->get_lat();
        res.y = gps->get_lon();
        res.yaw = imu->get_yaw();
        return true;
    });

// 客户端：请求当前位置
ServiceClient client = node->create_client<GetPose>("/get_pose");
auto result = client->async_send_request();
// 等结果回来再继续
Pose pose = result.get();

3. 数据分发服务（DDS）：智驾系统的“终极武器”

如果你觉得发布-订阅和服务-客户端还不够用，那DDS就是为你准备的。它不是一个简单的通信模式，而是一个完整的实时数据分发标准。ROS 2底层用的就是DDS。

DDS的核心概念：

全局数据空间（Global Data Space）： 所有节点共享一个虚拟的“数据黑板”。你写数据，别人就能读到，不需要知道数据在哪。
QoS策略（Quality of Service）： 这是DDS的灵魂。你可以精细控制：可靠性（可靠vs尽力而为）、持久性（数据是否保留给后来的订阅者）、生命周期（数据过期时间）等等。
发现机制（Discovery）： 节点自动发现彼此，不需要手动配置IP和端口。你想想看，一辆车上几十个ECU，如果每个都要手动配IP，那运维工程师得疯掉。

注意： DDS虽然强大，但学习曲线陡峭。我建议先从ROS 2的默认DDS实现（比如Fast DDS、Cyclone DDS）入手，别一上来就调QoS参数。我曾经在项目里把“可靠性”设成了“尽力而为”，结果关键控制指令偶尔丢失，车在测试场里差点撞墙……从那以后，我对QoS的每个参数都小心翼翼。

DDS的QoS策略，我整理了一个常用表格，方便你查阅：

QoS策略	作用	典型场景
RELIABILITY	可靠传输 vs 尽力而为	控制指令用可靠，图像用尽力而为
DURABILITY	数据是否持久化	地图数据用持久，传感器数据用瞬态
LIVELINESS	节点是否存活检测	安全监控必须用
DEADLINE	数据最大更新间隔	控制周期必须满足
HISTORY	保留最近N个样本	轨迹规划需要历史数据

下面这张图，是我自己画的DDS在智驾系统中的典型架构。你可以看到，传感器、感知、规划、控制，都通过DDS这个“数据总线”连接在一起，每个节点只关心自己需要的Topic，互不干扰。

最后，总结一下这三种模式的适用场景：

发布-订阅： 高频传感器数据、状态广播。90%的场景用它就够了。
服务-客户端： 低频请求-响应、配置查询、触发式操作。
DDS： 需要QoS保障、跨平台、大规模分布式系统。智驾系统的终极选择。

好了，通信机制的基础就聊到这儿。记住，没有最好的模式，只有最合适的模式。下次你在设计系统架构时，不妨先问问自己：数据是流式的还是请求式的？延迟要求多高？可靠性要求多严？想清楚了，再选模式。

📚 课程目录

通信机制基础：发布-订阅模式、服务-客户端模式、数据分发服务（DDS）核心概念

1. 发布-订阅模式：一对多的“广播电台”

2. 服务-客户端模式：一问一答的“打电话”

3. 数据分发服务（DDS）：智驾系统的“终极武器”