文章目录
灵活使用ROS2的QOS策略,优化节点间通信
消息质量策略
| 策略 | 可选值 | 作用 |
|---|---|---|
| History | KEEP_LAST / KEEP_ALL |
缓存多少历史消息 |
| Depth | 正整数(如 10) | KEEP_LAST 时的队列长度 |
| Reliability | RELIABLE / BEST_EFFORT |
是否保证消息必达 |
| Durability | VOLATILE / TRANSIENT_LOCAL |
新订阅者能否收到历史消息 |
| Deadline | 时间周期 | 期望的最小通信频率 |
| Lifespan | 时间周期 | 消息的有效期,过期丢弃 |
| Liveliness | AUTOMATIC / MANUAL_BY_TOPIC / MANUAL_BY_NODE |
检测发布者是否存活 |
| Ownership | SHARED / EXCLUSIVE |
多发布者时是否允许竞争 |
History(历史策略)
- KEEP_LAST + depth=N:只保留最近的 N 条消息(内存友好,默认)。
cpp
qos.history(RMW_QOS_POLICY_HISTORY_KEEP_LAST).depth(10);
- KEEP_ALL:保留所有消息(直到被消费或内存耗尽)。
Reliability(可靠性)
- RELIABLE:类似 TCP,发送方重传直到确认收到。适合命令、配置等不能丢的数据。
- BEST_EFFORT:类似 UDP,不保证到达,延迟更低、吞吐量更高。适合传感器高频数据(如激光雷达、图像)。
Durability(持久性)
决定新订阅者上线时能否收到之前发布的历史消息:
- VOLATILE(默认):不保留历史,新订阅者只能收到之后的消息。
- TRANSIENT_LOCAL:发布者在本地保留历史消息,新订阅者上线后立即收到。适合地图、状态、配置等需要同步初始数据的场景。
Deadline(截止时间)
我期望每 X 时间内至少收到/发布一条消息"。如果超时,会触发 Deadline Missed 回调。
c
qos.deadline(rclcpp::Duration::from_seconds(0.1)); // 100ms
Lifespan(消息寿命)
消息的有效期。超过该时间后,即使还在队列中也会被丢弃,防止消费过时的数据。
c
qos.lifespan(rclcpp::Duration::from_seconds(5.0)); // 5秒
Liveliness(活跃度)
| 模式 | 说明 |
|---|---|
AUTOMATIC |
节点存活即自动认为活跃(默认) |
MANUAL_BY_TOPIC |
需手动调用 assert_liveliness() 声明该 Topic 活跃 |
MANUAL_BY_NODE |
需手动声明整个节点活跃 |
配合 lease_duration(租约时长):如果在该时间内未收到活跃声明,则认为发布者已失效,触发回调。
Ownership(所有权)
多个发布者向同一 Topic 发布时:
- SHARED(默认):所有消息混合接收。
- EXCLUSIVE + ownership_strength:只接收强度最高的发布者的消息,其余忽略。适合主备切换场景。
常用的几种自带QOS策略
c
#include "rclcpp/qos.hpp"
// 1. 传感器数据(高频、可丢、低延迟)
rclcpp::SensorDataQoS(); // BEST_EFFORT, VOLATILE, KEEP_LAST(depth=5)
// 2. 参数服务(可靠、持久)
rclcpp::ParametersQoS(); // RELIABLE, VOLATILE
// 3. 默认 QoS
rclcpp::QoS(10); // KEEP_LAST, depth=10, RELIABLE, VOLATILE
典型场景
| 场景 | 推荐配置 |
|---|---|
| 激光雷达 / 摄像头图像 | SensorDataQoS()(BEST_EFFORT, VOLATILE) |
| 机器人状态 / 里程计 | KEEP_LAST(10), RELIABLE, VOLATILE |
| 地图 / 初始配置下发 | KEEP_LAST(1), RELIABLE, TRANSIENT_LOCAL |
| 控制指令 / 急停信号 | KEEP_ALL, RELIABLE, VOLATILE |
| 心跳检测 / 状态监控 | KEEP_LAST(1), BEST_EFFORT, VOLATILE + Liveliness |
兼容性
发布者和订阅者的 QoS 必须兼容才能建立通信,并且存在降级兼容的情况
| 发布者 \ 订阅者 | RELIABLE | BEST_EFFORT |
|---|---|---|
| RELIABLE | ✅ 兼容 | ❌ 不兼容 |
| BEST **_**EFFORT | ✅ 兼容(降级为 BEST_EFFORT) | ✅ 兼容 |