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

4.1 发布-订阅模型：从“点对点”到“解耦协作”

ROS2中最核心的通信方式就是话题（Topic）通信，它采用发布-订阅（Publish-Subscribe）模式。与ROS1中基于TCPROS的弱实时通信不同，ROS2的底层基于DDS（Data Distribution Service），这使得通信具备更强的实时性、可靠性以及分布式能力。

在话题通信中，存在两个角色：发布者（Publisher）和订阅者（Subscriber）。发布者将消息“广播”到某个命名的话题上，而订阅者则通过该话题接收消息。双方互不感知对方的存在，只关心话题名称和消息类型。这种解耦设计带来了极大的灵活性：一个话题可以有多个发布者和多个订阅者，节点可以随时上线或下线而不影响其他节点。

核心特征：

  • 异步通信：发布者发送消息后无需等待订阅者响应。
  • 多对多：一个话题可被多个节点同时发布和订阅。
  • 动态发现：节点通过DDS的发现协议自动建立连接，无需中心服务器。
话题 /sensor_data 消息类型: sensor_msgs/msg/Image DDS 数据总线 相机节点 发布者 rclcpp::Publisher 激光雷达节点 发布者 rclcpp::Publisher 障碍物检测 订阅者 rclcpp::Subscription 路径规划 订阅者 rclcpp::Subscription 发布 发布 订阅 订阅

上图展示了典型的机器人感知场景：相机节点和激光雷达节点分别向话题 /sensor_data 发布图像和点云数据，而障碍物检测与路径规划节点则订阅该话题获取数据。整个过程无需节点间直接建立连接，体现了发布-订阅模型的解耦优势。

4.2 QoS策略：让通信“按需定制”

QoS（Quality of Service，服务质量）是ROS2相对ROS1最重要的增强之一。它允许用户针对不同场景配置通信的可靠性、时效性和资源占用，从而在实时控制与数据完整性之间取得平衡。

QoS策略由多个独立的QoS Policy组成，最常用的包括：

策略名称 可选值 适用场景
可靠性
(Reliability)		 RELIABLE / BEST_EFFORT RELIABLE用于控制指令；BEST_EFFORT用于传感器大数据流
历史记录
(History)		 KEEP_LAST / KEEP_ALL KEEP_LAST配合深度队列；KEEP_ALL缓存全部消息
队列深度
(Depth)		 正整数（如10、100） 控制缓存消息数量，影响内存与实时性
消息时效
(Durability)		 VOLATILE / TRANSIENT_LOCAL TRANSIENT_LOCAL让晚到的订阅者也能收到“最后状态”

在C++中，可以通过 rclcpp::QoS 类快速配置这些策略。例如，创建一个适合图像传输的BEST_EFFORT订阅者：

// 图像订阅：允许丢帧，但要求低延迟
rclcpp::QoS qos_image(10);
qos_image.best_effort();          // 可靠性设为 BEST_EFFORT
qos_image.durability_volatile();  // 不保留历史

auto sub = this->create_subscription<sensor_msgs::msg::Image>(
    "/camera/image_raw", qos_image,
    [this](const sensor_msgs::msg::Image::SharedPtr msg) {
        // 处理图像帧
    });

而控制指令通常需要RELIABLE + KEEP_LAST(1)的配置，确保最新指令不丢失且不堆积旧指令：

// 速度指令发布：必须可靠送达
rclcpp::QoS qos_cmd(1);
qos_cmd.reliable();               // 可靠性设为 RELIABLE
qos_cmd.keep_last(1);             // 只保留最新一条

auto pub = this->create_publisher<geometry_msgs::msg::Twist>(
    "/cmd_vel", qos_cmd);

重要提醒：发布端与订阅端的QoS必须兼容才能建立通信。例如，发布端为RELIABLE，订阅端为BEST_EFFORT时，通信可以建立（订阅端按尽力而为接收）；但若发布端为BEST_EFFORT，订阅端为RELIABLE，则通信无法建立。设计系统时务必统一QoS配置。

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

ROS2的消息类型使用接口定义语言（IDL）描述，文件扩展名为 .msg。消息类型定义了话题上传输的数据结构，是发布者与订阅者之间的“契约”。

ROS2标准消息包提供了丰富的预定义类型，常用的包括：

  • std_msgs/msg/String、Int32、Float64：基础数据类型
  • geometry_msgs/msg/Twist：速度控制指令（线速度+角速度）
  • sensor_msgs/msg/Image：图像数据
  • sensor_msgs/msg/LaserScan：激光雷达扫描数据
  • nav_msgs/msg/Odometry：里程计数据

自定义消息类型时，需要创建独立的接口包。例如，定义一个包含机器人状态信息的消息：

# 文件: robot_status/msg/BatteryStatus.msg
float32 voltage          # 电压
float32 percentage       # 剩余百分比
bool is_charging         # 是否在充电
string status_code       # 状态码，如 "OK", "LOW", "CRITICAL"

在CMakeLists.txt中需要声明依赖：

find_package(rosidl_default_generators REQUIRED)
rosidl_generate_interfaces(${PROJECT_NAME}
  "msg/BatteryStatus.msg"
  DEPENDENCIES std_msgs
)

编译后，其他包即可通过 robot_status::msg::BatteryStatus 使用该消息类型。

4.4 实战案例：构建一个温度监控系统

下面通过一个完整的温度监控示例，串联发布-订阅模型、QoS策略和消息类型三个核心概念。

场景：机器人搭载温度传感器，需要将温度数据以10Hz频率发布，同时一个监控节点订阅并显示温度，当温度超过阈值时发出警告。

步骤1：定义消息类型

# temperature_system/msg/Temperature.msg
float32 temperature    # 摄氏度
float32 humidity       # 相对湿度 %
builtin_interfaces/Time timestamp  # 采集时间

步骤2：创建发布者节点

class TemperaturePublisher : public rclcpp::Node {
public:
  TemperaturePublisher() : Node("temperature_publisher") {
    // QoS: 可靠传输，保留最近10条
    rclcpp::QoS qos(10);
    qos.reliable().keep_last(10);
    
    publisher_ = this->create_publisher<temperature_system::msg::Temperature>(
        "/sensor/temperature", qos);
    
    timer_ = this->create_wall_timer(
        std::chrono::milliseconds(100),  // 10Hz
        std::bind(&TemperaturePublisher::timer_callback, this));
  }

private:
  void timer_callback() {
    auto msg = temperature_system::msg::Temperature();
    msg.temperature = 25.0 + rand() % 10;  // 模拟25~35度
    msg.humidity = 40.0 + rand() % 20;
    msg.timestamp = this->now();
    publisher_->publish(msg);
  }
  
  rclcpp::Publisher<temperature_system::msg::Temperature>::SharedPtr publisher_;
  rclcpp::TimerBase::SharedPtr timer_;
};

步骤3：创建订阅者节点

class TemperatureMonitor : public rclcpp::Node {
public:
  TemperatureMonitor() : Node("temperature_monitor") {
    // QoS必须与发布端兼容
    rclcpp::QoS qos(10);
    qos.reliable().keep_last(10);
    
    subscription_ = this->create_subscription<temperature_system::msg::Temperature>(
        "/sensor/temperature", qos,
        [this](const temperature_system::msg::Temperature::SharedPtr msg) {
          RCLCPP_INFO(this->get_logger(), 
            "温度: %.1f°C, 湿度: %.1f%%", 
            msg->temperature, msg->humidity);
          
          if (msg->temperature > 30.0) {
            RCLCPP_WARN(this->get_logger(), 
              "⚠ 温度过高！建议启动散热机制");
          }
        });
  }

private:
  rclcpp::Subscription<temperature_system::msg::Temperature>::SharedPtr subscription_;
};

步骤4：运行验证

# 终端1：启动发布者
ros2 run temperature_system temperature_publisher

# 终端2：启动订阅者
ros2 run temperature_system temperature_monitor

# 终端3：查看话题信息
ros2 topic info /sensor/temperature
ros2 topic echo /sensor/temperature --qos-reliability reliable

调试技巧：使用 ros2 topic info -v 可以查看话题的详细QoS配置，帮助排查通信不兼容问题。当订阅者收不到数据时，优先检查发布端与订阅端的QoS是否匹配。

4.5 常见误区与复盘

在实际开发中，以下问题经常导致通信异常或性能下降，需要特别注意：

误区1：所有话题都使用默认QoS

默认QoS为RELIABLE + KEEP_LAST(10)，对于图像、点云等大流量数据，这会导致背压和延迟。应针对传感器数据使用BEST_EFFORT策略。

误区2：发布端与订阅端QoS不匹配

例如发布端使用BEST_EFFORT，订阅端使用RELIABLE，会导致通信建立失败。设计时应统一约定QoS配置，或通过 ros2 topic info -v 提前检查。

误区3：忽略消息类型版本管理

当消息类型字段变更后，旧节点未重新编译，会导致类型不匹配而无法通信。建议使用 ros2 interface show 验证消息定义。

复盘建议：在系统设计阶段，先梳理所有话题的通信需求（实时性、可靠性、数据量），为每个话题制定明确的QoS配置表。例如：

话题名称 消息类型 可靠性 队列深度 更新频率
/cmd_vel Twist RELIABLE 1 50Hz
/camera/image_raw Image BEST_EFFORT 5 30Hz
/sensor/temperature Temperature RELIABLE 10 10Hz

通过这种表格化管理，可以显著减少通信配置错误，提升系统稳定性。话题通信作为ROS2最基础的通信方式，掌握其发布-订阅模型、QoS策略和消息类型设计，是构建可靠机器人系统的关键一步。

← 上一章 📖 返回目录 下一章 →