企业官网建设流程全解析

面试被问："ROS2的QoS有哪些策略？你在项目中怎么选的？"

我说"可靠和尽力而为两种"。面试官说："那截止时间（Deadline）和存活时间（Lifespan）你用过吗？什么场景下用？"

我答不上来。

QoS是ROS2相比ROS1最大的改进之一，也是面试高频考点。只了解可靠和尽力而为远远不够，今天把所有常用的QoS策略讲清楚。

什么是QoS

QoS全称Quality of Service，服务质量。简单说就是一组参数，控制消息在发布者和订阅者之间怎么传输。

ROS1没有QoS的概念，消息丢了就丢了，你根本不知道。ROS2基于DDS，提供了一套完整的QoS策略，让你可以针对不同的数据流做精细化的控制。

每个Topic的发布者和订阅者都有自己的QoS配置。两边匹配的时候，DDS会根据兼容性规则决定是否建立连接。

可靠性（Reliability）

这是最基础的QoS策略，两个选项：

RELIABLE——可靠传输。DDS保证消息一定能送达，如果丢了会重传。适合不能丢的数据，比如地图、诊断信息、状态报告。

BEST_EFFORT——尽力而为。DDS不保证送达，丢了就丢了。适合高频数据，比如传感器数据、控制指令。丢一帧没关系，下一帧马上就来。

兼容性规则：RELIABLE的发布者和BEST_EFFORT的订阅者可以匹配（订阅者收到可靠数据，没问题）。反过来不行——BEST_EFFORT的发布者和RELIABLE的订阅者无法匹配，因为DDS没法保证可靠传输。

在机器人项目里，激光雷达、IMU、里程计这些传感器数据用BEST_EFFORT就够了。地图、路径规划结果、系统状态用RELIABLE。

历史深度（History & Depth）

KEEP_LAST——只保留最新的N条消息。N就是Depth参数。比如Depth=10，队列里最多存10条消息，新的来了旧的就丢掉。

KEEP_ALL——保留所有消息，直到订阅者取走。理论上不会丢消息，但如果订阅者处理不过来，队列会无限增长，最终内存爆炸。

大多数场景用KEEP_LAST就行。Depth的设置取决于你的需求：控制指令设小一点（1-5），传感器数据设中等（10-30），关键数据设大一点（50-100）。

持久性（Durability）

这个策略控制的是：订阅者在发布者之后启动，能不能收到之前的数据。

TRANSIENT_LOCAL——发布者会缓存最近的数据。新的订阅者连上来后，立刻就能收到之前发布的内容。适合静态数据，比如地图、标定参数。

VOLATILE——不缓存。订阅者启动后只能收到之后发布的数据，之前的全部丢失。这是默认值，适合实时数据流。

举个例子：你的导航系统启动时，地图服务器已经把地图发布到/map这个Topic上了。如果地图服务器用的是VOLATILE，导航Node启动后拿不到地图，得等地图服务器重新发布。用TRANSIENT_LOCAL就没这个问题，导航Node一启动就能拿到缓存的地图。

截止时间（Deadline）

这个策略定义了一个预期：发布者每隔多久至少发一次消息。

比如你设Deadline=1秒，发布者超过1秒没发消息，DDS就会触发一个Deadline missed事件。订阅者收到这个事件后可以报警或者采取补救措施。

在机器人项目里，这个策略特别有用。激光雷达如果超过预期时间没发数据，可能是驱动挂了或者USB断了。用Deadline可以及时检测到这种故障，而不是等到机器人撞墙了才发现。

存活时间（Lifespan）

Lifespan定义了消息的有效期。消息发布后，超过Lifespan时间还没被订阅者取走，就自动丢弃。

这个策略用在时效性强的数据上。比如一个目标检测结果，500毫秒后就过时了（目标可能已经移动了），没必要让订阅者收到一条过时的检测结果。设Lifespan=500ms，过期的消息自动清理。

兼容性规则

QoS兼容性是面试常考的点。发布者和订阅者的QoS不是随便组合都能匹配的，DDS有一套"请求-提供"兼容模型：

订阅者的可靠性要求不能高于发布者的能力。发布者BEST_EFFORT，订阅者要RELIABLE，不兼容。

订阅者的持久性要求不能高于发布者的能力。发布者VOLATILE，订阅者要TRANSIENT_LOCAL，不兼容。

其他策略（Deadline、Lifespan、History）的兼容性规则类似：订阅者的要求不能比发布者提供的更严格。

简单记忆：发布者的QoS是"我能提供什么"，订阅者的QoS是"我需要什么"。需求不能超过供给。

实际项目中的QoS配置

在我们项目的代码里，有一个专门的qos配置文件，定义了所有Topic的QoS策略。

传感器数据（激光雷达、IMU、编码器）：BEST_EFFORT + KEEP_LAST(10) + VOLATILE。不需要重传，丢帧无所谓。

控制指令（cmd_vel）：BEST_EFFORT + KEEP_LAST(1) + VOLATILE。只关心最新的指令。

地图数据：RELIABLE + KEEP_LAST(1) + TRANSIENT_LOCAL。必须送达，新订阅者要能立即获取。

路径规划结果：RELIABLE + KEEP_LAST(5) + VOLATILE。必须送达，但不需要缓存历史。

诊断信息：RELIABLE + KEEP_ALL + TRANSIENT_LOCAL。绝对不能丢，新节点要能获取最新状态。

这套配置不是一开始就定好的，是踩了很多坑之后慢慢调出来的。建议你也根据自己的项目需求，逐个Topic分析，不要一刀切全用默认值。

常见的QoS踩坑经历

说一下我见过的几个典型问题。

第一个，订阅者收不到消息。排查了半天代码没问题，最后发现是QoS不匹配。发布者用的BEST_EFFORT，订阅者用的RELIABLE，DDS直接拒绝建立连接。ros2 topic info能看到发布者数量是1，但订阅者就是收不到数据。这种问题排查起来特别折磨人，因为没有任何错误提示。

第二个，TRANSIENT_LOCAL用在了高频数据上。有个同事把激光雷达的QoS设成了TRANSIENT_LOCAL，结果每次新订阅者连上来，DDS都要把缓存的历史数据一股脑发过去，直接把网络打满了。TRANSIENT_LOCAL只适合低频的静态数据，高频数据千万别用。

第三个，Deadline设太紧。激光雷达标称10Hz，但偶尔会因为USB带宽波动掉到9Hz。Deadline设了100ms，结果频繁触发deadline missed告警，监控系统一直在报警。后来改成150ms，留出余量，问题就消失了。

面试中怎么聊

面试官问QoS，你可以说："ROS2的QoS策略包括可靠性、历史深度、持久性、截止时间和存活时间。在项目中，传感器数据用BEST_EFFORT减少重传开销，关键数据如地图用RELIABLE加TRANSIENT_LOCAL保证送达。Deadline用来检测传感器故障，Lifespan用来清理过期数据。每个Topic的QoS需要根据数据特性单独配置。"

QoS策略的选择指南

QoS是ROS2相比ROS1的重要改进，但很多初学者对QoS的各种配置感到困惑。一个简单的选择指南：传感器数据如雷达相机用BEST_EFFORT加VOLATILE，因为丢几帧没关系但要求低延迟；控制指令用RELIABLE加TRANSIENT_LOCAL，因为不能丢失且新节点需要获取最新值。面试时如果被问到QoS，不要只背概念，要结合具体场景说明选择理由。

还有一个面试常问的点：TRANSIENT_LOCAL和VOLATILE的区别。TRANSIENT_LOCAL会为新订阅者发送最近的消息，适合静态地图这种不常更新但新节点需要获取的数据；VOLATILE则只发送订阅建立后的新消息。

给你的建议

打开你项目里的QoS配置看看，是不是全用的默认值。如果是，那你现在就有活干了。

写一个测试程序：发布者设BEST_EFFORT，订阅者设RELIABLE，看看能不能匹配上。然后反过来试试。亲手验证一遍兼容性规则，比背十遍文档都记得牢。另外ros2 topic info --verbose可以同时看到发布者和订阅者的QoS配置，排查不匹配问题时非常直观。

上一篇：第113篇 ROS2 Topic通信——发布订阅的底层机制

下一篇预告：第115篇 ROS2 Service通信——同步请求响应的适用场景