4. ROS2通信机制

各位同学，今天我们来聊聊ROS2里最核心的通信机制——发布-订阅模式。说实话，这个模式在自动驾驶系统里无处不在。你想想看，传感器数据要传给感知模块，感知结果要传给规划模块，规划指令要传给控制模块……这一连串的数据流转，靠的就是发布-订阅。

我个人习惯把发布-订阅比作「电台广播」。发布者只管往外发消息，它不需要知道谁在听。订阅者只管收自己感兴趣的消息，它不需要关心谁在发。这种解耦设计，在Apollo这种复杂的系统里特别实用。

4.1 为什么Lidar点云数据适合用发布-订阅？

我在项目中遇到过一个问题：Lidar每秒要产生几十万个点，数据量巨大。如果用传统的请求-响应模式，每帧数据都要等接收方确认，那延迟根本扛不住。

发布-订阅模式的好处就体现出来了：

• 异步通信：发布者发完就走，不用等订阅者处理完
• 多对多关系：一个Lidar数据可以同时被障碍物检测、地面分割、定位等多个模块订阅
• QoS控制：可以设置数据可靠性、历史记录深度等参数

4.2 Apollo中Lidar点云的发布者实现

我们先看看发布者这边是怎么写的。嗯，这里要注意，Apollo的Lidar驱动通常运行在一个独立的节点里，负责从硬件读取数据，然后发布到ROS2话题上。

// 伪代码示例：Lidar驱动节点中的发布者
class LidarDriverNode : public rclcpp::Node {
public:
  LidarDriverNode() : Node("lidar_driver") {
    // 创建发布者，话题名为"/apollo/sensor/lidar/pointcloud"
    publisher_ = this->create_publisher<sensor_msgs::msg::PointCloud2>(
      "/apollo/sensor/lidar/pointcloud", 
      rclcpp::QoS(10)  // 队列深度为10
    );
    
    // 启动定时器，模拟Lidar数据采集
    timer_ = this->create_wall_timer(
      std::chrono::milliseconds(100),  // 10Hz
      std::bind(&LidarDriverNode::publish_pointcloud, this)
    );
  }

private:
  void publish_pointcloud() {
    auto msg = std::make_shared<sensor_msgs::msg::PointCloud2>();
    // 填充点云数据（从硬件读取）
    fill_pointcloud_data(msg);
    
    // 发布消息
    publisher_->publish(*msg);
    
    // 我个人习惯在这里加个日志，方便调试
    RCLCPP_INFO(this->get_logger(), "Published pointcloud with %d points", msg->width);
  }

  rclcpp::Publisher<sensor_msgs::msg::PointCloud2>::SharedPtr publisher_;
  rclcpp::TimerBase::SharedPtr timer_;
};

4.3 Apollo中Lidar点云的订阅者实现

订阅者这边，最常见的就是障碍物检测模块。它需要实时接收点云数据，然后做聚类、识别等处理。

// 伪代码示例：障碍物检测节点中的订阅者
class ObstacleDetectionNode : public rclcpp::Node {
public:
  ObstacleDetectionNode() : Node("obstacle_detection") {
    // 订阅Lidar点云话题
    subscription_ = this->create_subscription<sensor_msgs::msg::PointCloud2>(
      "/apollo/sensor/lidar/pointcloud",
      rclcpp::QoS(10),
      std::bind(&ObstacleDetectionNode::pointcloud_callback, this, std::placeholders::_1)
    );
  }

private:
  void pointcloud_callback(const sensor_msgs::msg::PointCloud2::SharedPtr msg) {
    // 这里处理点云数据
    // 1. 预处理（滤波、降采样）
    // 2. 地面分割
    // 3. 障碍物聚类
    // 4. 输出检测结果
    
    RCLCPP_DEBUG(this->get_logger(), "Received pointcloud with %d points", msg->width);
    
    // 处理完成后，检测结果会通过另一个发布者发布出去
    publish_detection_results();
  }

  rclcpp::Subscription<sensor_msgs::msg::PointCloud2>::SharedPtr subscription_;
};

你可能会问：为什么回调函数里不直接做所有处理？说白了，回调函数里不宜做耗时操作。我在项目里吃过这个亏——回调里做了复杂的聚类算法，结果导致后续消息堆积，系统延迟飙升。

4.4 发布-订阅模式在Apollo中的整体架构

为了让你更直观地理解，我画了一张架构图。这张图展示了Lidar点云数据从驱动到感知模块的完整流转路径。

从这张图你可以看到，Lidar驱动节点只负责发布数据，它根本不知道下游有几个模块在收。而障碍物检测、地面分割、定位这三个节点，各自订阅同一个话题，但处理逻辑完全不同。这就是发布-订阅模式的精髓——解耦。

4.5 实际项目中的几个关键点

讲完了基础用法，我分享几个实际项目中的经验。这些坑我踩过，希望你别再踩。

问题	现象	解决方案
消息丢失	订阅者收不到部分点云帧	检查QoS设置，将Reliability改为RELIABLE
延迟过高	点云数据到感知模块延迟超过200ms	回调函数中避免耗时操作，使用线程池处理
内存暴涨	长时间运行后内存占用持续增加	检查是否有订阅者未释放消息，设置合理的队列深度
话题名冲突	多个Lidar数据混在一起	使用命名空间区分，如 /apollo/sensor/lidar_front/pointcloud

4.6 发布-订阅 vs 其他通信模式

你可能会问：为什么Apollo感知模块不用服务-客户端模式？说白了，服务-客户端适合「请求-响应」这种同步场景，比如查询某个参数。而点云数据是持续产生的流式数据，用发布-订阅天然合适。

我整理了一个对比表，方便你理解：

通信模式	适用场景	Apollo中的例子
发布-订阅	流式数据、一对多广播	Lidar点云、Camera图像、CAN信号
服务-客户端	同步请求、配置查询	获取模块状态、触发校准
动作	长时间任务、可取消	路径规划、泊车控制

嗯，到这里你应该对发布-订阅模式在Apollo感知模块中的应用有了清晰的认识。记住一句话：发布者只管发，订阅者只管收，中间的事交给ROS2的通信层去操心。这种设计让Apollo的各个模块可以独立开发、独立测试，最后拼到一起就能跑起来。

下次你在看Apollo代码的时候，可以留意一下各个节点之间的话题连接关系。你会发现，整个系统就是由无数个发布-订阅关系编织起来的。

可可精品资料库