在城市里，每天有无数包裹在流动。寄件人把快递投进驿站，取件人凭取件码取走包裹，自始至终双方都不知道对方是谁。驿站按标签分拣、按区域派送，慢了会被投诉，丢了要负责赔偿——整套流程有规则、有保障。这就是 DDS 中间件在机器人世界里的定位。 机器人身上有雷达、摄像头、电机、导航算法，它们无时无刻不在交换数据。ROS2 把“机器人通信”这件事，托付给了 DDS（Data Distribution Service，数据分发服务）中间件。DDS 的发布订阅模型让节点之间彻底解耦；QoS 策略（可靠性、持久性、历史深度等）就像邮政服务里不同的邮寄等级；多域配置则让不同机器人团队在同一个网络里互不干扰。 本文从“快递驿站”这个比喻出发，一步步拆解 DDS 的发布订阅模型、QoS 可靠性、持久性、历史策略、ROS1 对比、实时性保障、多域配置与实战配置。你会发现，给机器人选通信方式，就像给不同包裹选邮寄方式一样朴素自然。

岗位关联

掌握 DDS 与 QoS，是 ROS2 开发者从“能跑 demo”进阶到“能交付可靠机器人系统”的关键一步。它直接决定多机协同、实时控制等场景的通信质量，是机器人通信领域的“内功”。

目录
  1. 可视化演示
  2. 发布订阅模型
  3. QoS可靠性策略
  4. QoS持久性策略
  5. QoS历史策略
  6. ROS1与ROS2通信对比
  7. 实时性保障
  8. 多域配置
  9. QoS配置实战
  10. AI 应用场景
  11. Python 演示
  12. 常见误区
  13. 面试题

可视化演示

展示系统处理流水线、实时性能指标曲线及多方案对比分析，包含数据流转、吞吐延迟监控与方案评估。

本节配有交互动效（进入视口后自动加载，约 3KB）。

系统可视化 处理流程：输入→处理→模型→输出 性能监控：实时指标 P=L×T

发布订阅模型

想象小区里的快递驿站。寄件人把包裹投进驿站，不需要知道谁会来取；取件人来了，也不关心包裹来自谁。驿站只按标签分拣，“生鲜”放冷藏区，“文件”放前台柜。这种“各投各的、各取所需”的模式，就是发布订阅模型的生活原型。

机器人系统也是这样。激光雷达节点不断发出扫描数据，导航节点需要吃进这些数据，但雷达节点不需要知道“谁在消费我的数据”，导航节点也不关心“雷达是谁”。DDS（Data Distribution Service，数据分发服务）就是这套系统的“驿站”，它是 ROS2 默认的通信中间件。

DDS 的发布订阅模型在标准里被称为 DCPS（Data-Centric Publish-Subscribe，以数据为中心的发布订阅）。节点在“主题”（Topic）上发布消息，任何订阅该主题的节点都能收到副本。双方在时间上、空间上完全解耦：发布者离线不影响订阅者等待，订阅者晚到也不影响发布者继续发布。这是 ROS2 系统稳定性的基石。

驿站不怕寄件人少、取件人晚，只要标签写清楚，包裹总能流转。DDS 也一样，发布者与订阅者互不相识，却因为同一个“主题标签”被牢牢地连接在一起。

N连接=N发布者×N订阅者\displaystyle N_{\text{连接}} = N_{\text{发布者}} \times N_{\text{订阅者}}
DDS 底层会为每个发布者-订阅者配对建立逻辑通道，因此同一主题上的连接数是两者乘积。这也解释了为什么完全解耦仍能支持一对多通信——驿站替双方把连接管理好了。
  1. 主题上的发布者数量同一 Topic 上执行发布操作的节点总数，决定“谁在投递包裹”。
    N发布者\displaystyle N_{\text{发布者}}
  2. 主题上的订阅者数量订阅该 Topic 并等待收包的节点总数，决定“谁在等待包裹”。
    N订阅者\displaystyle N_{\text{订阅者}}
  3. 乘积得到连接数每个发布者都要与每个订阅者建立一条逻辑通道，总通道数是两者乘积。
    N发布者×N订阅者\displaystyle N_{\text{发布者}} \times N_{\text{订阅者}}

QoS可靠性策略

寄包裹时，邮局会问：“寄挂号还是平信？”挂号信有回执、丢了补寄，但流程慢、价格贵；平信便宜快速，可丢了就是丢了。DDS 的可靠性策略（Reliability）也提供两个档位。

RELIABLE 模式下，发布者会检测订阅者是否真的收到了消息，一旦发现丢包就自动重传，确保每条消息都送达；BEST_EFFORT 模式则“发了就当成功”，不检测、不重传。控制指令适合 RELIABLE——差一条电机指令，机器人就可能撞墙；激光雷达数据适合 BEST_EFFORT——下一帧 20 毫秒后就到，重传旧帧反而堵塞通道。

QoS 可靠性本质上是通信质量与时效之间的权衡。RELIABLE 在丢包严重时会不断重传，导致消息延迟上升、带宽被占满；BEST_EFFORT 在弱网环境下会丢数据，但能保持恒定的低延迟。对机器人开发者来说，选错档位往往比丢包本身更危险。

给控制指令上“挂号信”，给传感器数据发“平信”，机器人系统才能在可靠与流畅之间找到平衡点。

P成功=1−(1−p)n\displaystyle P_{\text{成功}} = 1 - (1 - p)^n
假设单次传输丢包率为 p，最多重传 n-1 次（共尝试 n 次），那么消息最终能成功送达的概率是 1 减去 n 次全部失败的概率。重传次数越多，成功概率越接近 1。
  1. 单次丢包率一次发送尝试失败的概率，弱网环境下可能是 1%~10%。
    p\displaystyle p
  2. 尝试总次数原始发送加上最多重传次数，n 越大越可靠。
    n\displaystyle n
  3. n 次全部失败的概率每次失败概率相乘，得到 (1-p)^n。
    (1−p)n\displaystyle (1 - p)^n
  4. 补集转换用 1 减去全部失败的概率，得到至少有一次成功的概率。
    1−(1−p)n\displaystyle 1 - (1 - p)^n

QoS持久性策略

驿站里有个快递柜。你出差一周，包裹先放进柜子里，回来后凭取件码照样取到。但如果驿站没有快递柜，包裹投递时你不在，快递员只能原路退回——消息就永久错过了。

DDS 的 Durability（持久性）策略解决“晚到的订阅者如何补历史消息”的问题。VOLATILE 表示发布者不为晚到者保留任何消息；TRANSIENT_LOCAL 表示发布者在本地缓存最近发布的消息，新订阅者一接入就立刻补收；TRANSIENT_GLOBAL 则让整个 DDS 域协同缓存，可靠性更高但资源开销更大。

举个例子：建图节点发布地图数据，导航节点 3 秒后才启动。如果发布者是 VOLATILE，导航节点永远拿不到地图；如果设置了 TRANSIENT_LOCAL，发布者会保留最近一次地图消息，导航节点一启动就收到最新地图，不用傻等下一帧。

快递柜决定了晚归的人能不能拿到包裹，Durability 决定了晚启动的节点能不能吃上“热乎”的数据。

T有效=T发布时刻+T持久时长\displaystyle T_{\text{有效}} = T_{\text{发布时刻}} + T_{\text{持久时长}}
一条消息在发布后，还能被晚到的订阅者获取的“有效期”，等于它的发布时刻加上 QoS 中配置的持久化时长。快递柜的“暂存时间”越长，晚到的人越从容。
  1. 发布时刻发布者调用 publish() 的时间戳，是消息的“出生时间”。
    T发布时刻\displaystyle T_{\text{发布时刻}}
  2. 持久时长Durability 策略决定消息在缓存中保存的时长，对应快递柜的“暂存期限”。
    T持久时长\displaystyle T_{\text{持久时长}}
  3. 求和得到有效期限消息的有效窗口等于发布时刻加持久时长，过期后新订阅者无法补收。
    T发布时刻+T持久时长\displaystyle T_{\text{发布时刻}} + T_{\text{持久时长}}

QoS历史策略

驿站的小黑板上只贴最近 5 个待取件通知，贴太多黑板就写不下了。你的微信聊天记录也可以设置“只保留最近 20 条”或“全部保留不清理”——History（历史）策略就是干这个的。

DDS 的 History 策略规定每个发布者或订阅者队列里保留多少条历史消息。KEEP_LAST(depth) 只保留最近的 depth 条，超出后最早的消息被丢弃；KEEP_ALL 表示尽可能保留全部消息，直到资源耗尽或订阅者赶上进度。

激光雷达用 KEEP_LAST(1) 就够了，因为只需要最新一帧；调试机器人状态时用 KEEP_LAST(10) 看滑动窗口；KEEP_ALL 要特别小心——如果订阅者处理速度跟不上，消息会在队列里越积越多，内存像发面团一样膨胀，最终拖垮整个节点。

小黑板面积有限，就像内存有限；贴最近几条是明智的，全贴只会让驿站墙壁坍塌。

M=Ddepth×Smsg\displaystyle M = D_{\text{depth}} \times S_{\text{msg}}
历史队列的内存占用上限，约等于队列深度乘以单条消息的大小。深度越大、消息越大，内存就越紧张。
  1. 队列深度KEEP_LAST 中配置的 depth，决定缓存几条历史消息。
    Ddepth\displaystyle D_{\text{depth}}
  2. 单条消息大小一条消息序列化后的平均字节数，图片消息远比浮点数大。
    Smsg\displaystyle S_{\text{msg}}
  3. 相乘得到内存上界缓存全部深度消息所占的内存约为两者乘积，可用来估算配置深度是否合理。
    Ddepth×Smsg\displaystyle D_{\text{depth}} \times S_{\text{msg}}

ROS1与ROS2通信对比

ROS1 时代像一个校园广播站：班长在教室里喊一嗓子，全班都听见，可跨教室、跨楼就喊不到了；更重要的是，班长一旦生病请假，全校通信就瘫痪。ROS2 换成了国家邮政系统：网点遍布各地，邮件按标准分拣、自动路由，没有“班长”也能运转。

ROS1 采用 TCPROS/UDPROS 协议，依赖中心化的 Master 节点做命名与发现服务。所有节点先找 Master“报到”，再由发布者与订阅者直接建立 TCP 连接。这套机制在小规模机器人上够用，但 Master 一挂、跨机器通信一多，问题就暴露了。

ROS2 直接用 DDS 做传输层。DDS 是一个由 OMG 组织制定的国际标准，自带服务发现、消息路由、QoS 协商。节点之间不需要中央服务器，天然支持多网络、多机器人协同。代价是概念栈更深——开发者要理解 DDS 域、RMW、QoS 等新概念。

从“喊话找人”到“标准邮政”，虽然流程变多了，但少了中心依赖、多了标准保障，机器人系统才真正具备了走向复杂场景的底气。

T总延迟=T序列化+T传输+T反序列化\displaystyle T_{\text{总延迟}} = T_{\text{序列化}} + T_{\text{传输}} + T_{\text{反序列化}}
消息从发布者到订阅者的总延迟，由序列化、传输、反序列化三部分构成。ROS1 与 ROS2 都存在这三段，但 DDS 的传输层更高效、更可预测。
  1. 序列化耗时把内存中的消息结构编码成字节流的时间，格式越复杂耗时越长。
    T序列化\displaystyle T_{\text{序列化}}
  2. 传输耗时字节流在物理通道（网络或共享内存）上搬运的时间。
    T传输\displaystyle T_{\text{传输}}
  3. 反序列化耗时接收端把字节流还原成消息结构的时间。
    T反序列化\displaystyle T_{\text{反序列化}}
  4. 总和即端到端延迟三段相加，是评估 ROS1/ROS2 通信性能的基本模型。
    T序列化+T传输+T反序列化\displaystyle T_{\text{序列化}} + T_{\text{传输}} + T_{\text{反序列化}}

实时性保障

高峰期的城市里，救护车走应急车道，一路绿灯；普通快递车只能堵在路上。DDS 也为关键消息留了“绿色通道”。

DDS 的实时性保障来自三层机制：共享内存传输让同一进程内的消息不必经过网络栈；零拷贝（Zero-Copy）机制避免多次复制数据，直接把内存块“递”给订阅者；实时调度策略为高优先级消息开快速通道，减少排队等待。

在 ROS2 中开启进程内通信（Intra-Process）后，消息可以不序列化、不经过网卡，延迟低至几十微秒。零拷贝进一步减少内存拷贝次数，但需要锁定内存页、管理缓冲区生命周期，实现复杂度较高。需要强调的是，DDS 提供的是“软实时”——大幅降低延迟和抖动，但无法承诺硬实时的微秒级绝对上限。

绿色通道给了关键消息优先权，普通消息排队等待，整个系统的“物流”才能又快又稳。

T端到端=T发布+T队列+T传输+T处理\displaystyle T_{\text{端到端}} = T_{\text{发布}} + T_{\text{队列}} + T_{\text{传输}} + T_{\text{处理}}
端到端延迟由发布调用、队列等待、数据搬运、订阅者回调处理四段组成。实时性优化的本质，就是分别压缩这四段时间。
  1. 发布调用开销应用调用发布 API 到消息进入 DDS 的时间。
    T发布\displaystyle T_{\text{发布}}
  2. 队列等待时间消息在发送或接收队列中等待被调度的时间。
    T队列\displaystyle T_{\text{队列}}
  3. 数据传输时间消息通过共享内存或网络从发布端到订阅端的耗时。
    T传输\displaystyle T_{\text{传输}}
  4. 回调处理时间订阅者收到消息后执行回调函数的耗时。
    T处理\displaystyle T_{\text{处理}}
  5. 求和为端到端延迟四段时间的和，是 QoS 调优时逐项压缩的目标函数。
    T发布+T队列+T传输+T处理\displaystyle T_{\text{发布}} + T_{\text{队列}} + T_{\text{传输}} + T_{\text{处理}}

多域配置

快递公司按邮区划分，江浙沪和京津冀互不相通。只要邮编不同，包裹不会串区。每个机器人团队就是一个“邮区”，里面怎么发都行，不会干扰隔壁团队。

DDS 用 Domain ID 来隔离通信域，ROS2 通过 ROS_DOMAIN_ID 环境变量设置。相同 Domain ID 的节点会自动发现彼此、正常通信；不同 Domain ID 的节点即使在同一台机器、同一张网卡上，DDS 层也完全隔离，互不收发。

多机器人比赛中，如果 5 台机器人连在同一个 WiFi 下又不设域 ID，A 车的 /cmd_vel 会串到 B 车，出现“幽灵控制”。给每台车分配不同的 ROS_DOMAIN_ID（0、1、2…），每台车的节点就只在各自的域内通信，互不干扰。

邮编不同，包裹不会串区；Domain ID 不同，机器人不会串线。多机协作的安全，从配置好“邮区”开始。

C(n,2)=n(n−1)2\displaystyle C(n, 2) = \frac{n(n-1)}{2}
同一个域内 n 个节点之间，理论上可以形成的通信对数等于组合数 C(n,2)。跨域则完全没有这些连接。
  1. 域内节点数同一个 Domain ID 下参与通信的节点总数。
    n\displaystyle n
  2. 两两互联关系数DDS 自动发现在同一域内建立的连接对数量。
    C(n,2)\displaystyle C(n, 2)
  3. 组合数展开等于 n(n-1)/2，例如 4 个节点同域最多有 6 对连接。
    n(n−1)2\displaystyle \frac{n(n-1)}{2}

QoS配置实战

寄文件走平邮，寄贵重仪器用保价运输，寄生鲜走冷链——不同物品选不同邮寄方式。在 ROS2 里配置 QoS，就是给每类消息选择“邮寄方式”。

ROS2 的 Python/C++ API 提供 QoSProfile 类，可以链式设置可靠性、持久性、历史深度、截止期限等参数，还有预设的 SensorDataQoS（适合传感器、可丢帧）和 ParametersQoS（适合参数服务、必须可靠）。底层由 RMW（ROS Middleware Interface，ROS 中间件接口）决定，常见实现有 Fast DDS、Cyclone DDS 等。

发布激光雷达数据的典型配置是 BEST_EFFORT + VOLATILE + KEEP_LAST(5)，因为雷达帧丢几帧没关系，但必须保持低延迟。发布控制指令则反过来：RELIABLE + VOLATILE + KEEP_LAST(10)，确保每条指令执行到位。注意 QoS 兼容规则：发布端 BEST_EFFORT 无法满足订阅端 RELIABLE 的要求，两者将无法建立连接；反之则可以。

给每条消息选对“邮寄方式”，机器人的通信质量才能既可靠又高效。

吞吐量=D消息总量T传输耗时\displaystyle \text{吞吐量} = \frac{D_{\text{消息总量}}}{T_{\text{传输耗时}}}
配置 QoS 后，可以通过吞吐量评估效果：单位时间内实际送达的消息字节数。可靠模式降低吞吐换取可靠性，尽力模式反之。
  1. 消息总量一段时间内成功送达的累计字节数。
    D消息总量\displaystyle D_{\text{消息总量}}
  2. 传输耗时传输这些消息消耗的总时长。
    T传输耗时\displaystyle T_{\text{传输耗时}}
  3. 相除得吞吐量平均每秒送达的字节数，是衡量通信效率的核心指标。
    D消息总量T传输耗时\displaystyle \frac{D_{\text{消息总量}}}{T_{\text{传输耗时}}}

AI 应用场景

多机器人仓库调度隔离

阶段：部署运维 / 多机通信配置

解决的问题：多个机器人共享同一个无线网络时，通信串扰会导致错误指令。传统 ROS1 依赖 Master 集中管理，多机部署复杂；DDS 多域配置让每台机器人独立成“邮政区”。

具体案例：仓库里 3 台 AGV 小车各执行不同任务，为它们配置 ROS_DOMAIN_ID=0/1/2，即使团队共用同一 WiFi，A 车的速度指令也不会发给 B 车。

自动驾驶感知链路 QoS 调优

阶段：数据链路优化

解决的问题：激光雷达、摄像头每帧数据量大，若采用 RELIABLE 重传机制，会造成数据延迟与带宽浪费。

具体案例：自动驾驶原型车上，激光雷达话题用 BEST_EFFORT + KEEP_LAST(1)，确保规划模块始终拿到最新一帧；车辆控制话题用 RELIABLE + 深度 10，确保刹车指令不丢失。

遥操作手术机器人低时延通信

阶段：实时系统设计

解决的问题：主手遥操作从手时，指令延迟超过数百毫秒会造成操作抖动甚至危险。

具体案例：手术机器人团队将控制指令 QoS 设为 RELIABLE 并启用共享内存/零拷贝传输，让端到端延迟稳定在毫秒级。

Python 演示

python67 行
# -*- coding: utf-8 -*-"""模拟 DDS 中 RELIABLE 与 BEST_EFFORT 两种 QoS 的送达率对比"""import random  class Message:    """一条待发布的消息"""     def __init__(self, seq):        self.seq = seq  class Publisher:    """模拟 DDS 发布者，支持可靠模式和尽力模式"""     def __init__(self, reliable, depth=5):        self.reliable = reliable        self.depth = depth        self.history = []        self.subscribers = []     def add_subscriber(self, sub):        self.subscribers.append(sub)        for msg in self.history[-self.depth:]:            sub.on_message(msg)     def publish(self, msg):        self.history.append(msg)        if len(self.history) > self.depth:            self.history.pop(0)        for sub in self.subscribers:            if self.reliable or random.random() > 0.25:                sub.on_message(msg)            else:                sub.lost += 1  class Subscriber:    """模拟 DDS 订阅者，统计收到与丢失的消息数"""     def __init__(self):        self.received = []        self.lost = 0     def on_message(self, msg):        self.received.append(msg)  def run_scene(reliable, total=500):    pub = Publisher(reliable, depth=5)    sub = Subscriber()    pub.add_subscriber(sub)    for i in range(total):        pub.publish(Message(i))    return len(sub.received), sub.lost, total  def main():    for reliable in (True, False):        got, lost, total = run_scene(reliable)        rate = got / total * 100        tag = "RELIABLE" if reliable else "BEST_EFFORT"        print("{}: 送达 {} / {} 条，送达率 {:.1f}%".format(tag, got, total, rate))  if __name__ == "__main__":    main()
目的：这个脚本模拟了 DDS 两种可靠性策略的消息送达率对比。RELIABLE 模式不丢消息，BEST_EFFORT 模式在约 25% 丢包率下会损失部分数据，帮助直观理解 QoS 可靠性策略的代价与收益。
  1. pub = Publisher(reliable, depth=5)创建一个发布者，reliable 决定使用可靠还是尽力模式，depth 对应 KEEP_LAST 历史深度。
  2. sub.on_message(msg)订阅者收到消息后存入列表，是 DDS 回调机制的最小模拟。
  3. if self.reliable or random.random() > 0.25可靠模式下必定送达；尽力模式下有 25% 概率丢弃消息。
  4. for msg in self.history[-self.depth:]订阅者晚到时补发历史消息，模拟 TRANSIENT_LOCAL 持久性行为。
  5. len(sub.received) / total * 100计算送达率，量化两种 QoS 策略的可靠性差异。

常见误区

误区QoS 可靠性最好全部设为 RELIABLE，这样消息一定不会丢，系统肯定更安全。

正解RELIABLE 在丢包时会不断重传，导致延迟升高、带宽占用暴涨。对激光雷达这类高频传感器数据，BEST_EFFORT 丢一帧根本无所谓，但重传旧帧会阻塞新数据，反而让系统“卡死”。就像生鲜必须走冷链，但普通报纸走平邮就好，全部挂号只会又慢又贵。

为何常见：新手天然觉得“可靠”优于“尽力”，忽略了通信质量是权衡取舍而不是单点最优。

误区ROS2 里出现的 QoS 是 ROS2 框架特有的 API 设计。

正解QoS 是 DDS 国际标准（OMG DDS）中早已定义的核心概念，ROS2 只是把 DDS 的 QoS 策略透传给了开发者。RMW 层换成 Fast DDS 还是 Cyclone DDS，QoS 语义保持一致。

为何常见：ROS2 文档把 QoS 包装得很友好，开发者只看到 ROS2 API，看不到背后的 DDS 标准。

误区设置 KEEP_LAST(10) 后，整个系统里只会保留最近 10 条消息，所有人都共享这 10 条。

正解KEEP_LAST(10) 是每个发布者或订阅者各自的队列深度，不是全局公共缓存。发布端和每个订阅端都可能有自己独立的 10 条历史队列，内存占用是各队列之和。

为何常见：从“消息总线”的直觉出发，容易把 DDS 想象成一根公共管道，忽略了 DDS 是分布式、多点缓存的架构。

误区只要 `ROS_DOMAIN_ID` 相同，两个节点就一定能收发消息。

正解域 ID 只是第一道门槛。同一域内还必须满足 Topic 名称一致、消息类型一致、QoS 策略兼容。例如发布者是 BEST_EFFORT，订阅者要求 RELIABLE，两者就无法建立连接。就像同一邮区里还要门牌号对得上，收件人还得在家。

为何常见：初学时把域 ID 当作唯一匹配条件，忽视了 DDS 主题发现和 QoS 协商的多重约束。

面试题

Q1. 在 DDS 发布订阅模型中，发布者和订阅者之间的耦合方式是：

单选题 · easy

  • A.时间耦合和空间耦合都强
  • B.时间耦合和空间耦合都弱← 正确答案
  • C.空间强耦合时间弱耦合
  • D.时间强耦合空间弱耦合

答案：B。DDS 是典型的数据为中心的发布订阅模型，发布者不需要知道订阅者存在，订阅者也不需要知道发布者是谁，双方在时间和空间上都解耦。就像寄件人和收件人通过驿站中转，互不依赖。

Q2. ROS2 通信底层默认采用的中间件是：

单选题 · easy

  • A.TCPRos 中心化协议
  • B.默认的 DDS 中间件← 正确答案
  • C.ZeroMQ 消息队列
  • D.WebSocket 浏览器协议

答案：B。ROS2 默认使用 DDS 作为底层通信中间件，通过 RMW 接口可以切换不同的 DDS 实现。TCPRos 是 ROS1 的协议，ZeroMQ 和 WebSocket 都不是 ROS2 的默认通信中间件。

Q3. 下列哪种 QoS 配置最适合传输激光雷达扫描数据：

单选题 · easy

  • A.RELIABLE 且 KEEP_ALL 缓存
  • B.BEST_EFFORT 加 KEEP_LAST(1)← 正确答案
  • C.RELIABLE 且无限深度缓存
  • D.TRANSIENT_GLOBAL 持久保存

答案：B。激光雷达数据频率高、实时性强，丢一帧没关系，但必须拿到最新帧。BEST_EFFORT 避免重传阻塞，KEEP_LAST(1) 保证队列里只有最新数据。这就像平信送报纸，丢了今天的还有明天的。

Q4. 关于 RELIABLE 与 BEST_EFFORT，下列说法正确的是：

单选题 · mid

  • A.RELIABLE 一定比 BEST_EFFORT 快速
  • B.BEST_EFFORT 会一直重传消息直到成功
  • C.RELIABLE 会重传丢失的消息导致延迟上升← 正确答案
  • D.相对 RELIABLE 而言，BEST_EFFORT 更耗带宽

答案：C。RELIABLE 在丢包时会自动重传，确保可靠性但可能增加延迟和带宽消耗；BEST_EFFORT 不重传，延迟低但可能丢消息。挂号信更稳妥但更慢，平信更快但可能丢失。

Q5. DDS 的 KEEP_LAST(10) 策略含义是：

单选题 · mid

  • A.所有历史消息永久保存
  • B.只保存最近 10 条历史消息← 正确答案
  • C.每条消息保存在内存中 10 秒
  • D.最多允许 10 个订阅者连接

答案：B。KEEP_LAST(depth) 是 History 策略之一，表示队列只保留最近的 depth 条消息，超出后最旧的消息被丢弃。就像小黑板只贴最近 10 条通知，新通知来了旧通知就被擦掉。

Q6. 在 ROS2 中若两个节点在同一域但 QoS 不兼容，会发生：

单选题 · mid

  • A.自动降级为 BEST_EFFORT
  • B.通信正常但性能下降
  • C.无法建立订阅关系← 正确答案
  • D.编译时报出错误

答案：C。发布端 QoS 必须能“满足”订阅端要求。比如发布者是 BEST_EFFORT，订阅者要求 RELIABLE，DDS 匹配时认为不兼容，双方无法建立连接。就像收件人要求挂号信，寄件人却只肯寄平信，邮局不会受理这笔业务。

Q7. TRANSIENT_LOCAL 持久性策略的主要作用是：

单选题 · hard

  • A.将消息持久化保存到磁盘
  • B.为晚加入订阅者补发已发布消息← 正确答案
  • C.提升消息的底层采样频率
  • D.加密发布者和订阅者的通道

答案：B。TRANSIENT_LOCAL 让发布者在本地缓存最近发布的消息，当新的订阅者加入时，会立即收到这些历史消息。这解决了 late joiner（晚到订阅者）问题。注意它缓存的是“已发布的消息”而非参数或密钥。

Q8. 下列属于 DDS 标准 QoS 策略的是：

多选题 · mid

  • A.Reliability 可靠性策略← 正确答案
  • B.Durability 持久性策略← 正确答案
  • C.Deadline 截止期限策略← 正确答案
  • D.Rosbag 数据录制组件

答案：ABC。Reliability、Durability、Deadline 都是 DDS 标准中的 QoS 策略，分别控制消息可靠性、持久性和最大响应期限。Rosbag 是 ROS2 中的录制工具，不属于 QoS 策略。

Q9. ROS2 相比 ROS1 的优势包括：

多选题 · hard

  • A.去中心化，无单点故障← 正确答案
  • B.同域多机器人跨域隔离← 正确答案
  • C.内置 QoS 服务质量控制← 正确答案
  • D.只能运行在 Linux 平台

答案：ABC。ROS2 基于 DDS，不再依赖中心化 Master，天然支持域隔离和 QoS 控制，还支持更广泛的平台。D 选项错误，ROS2 支持 Linux、Windows、macOS 等多个平台。

Q10. 关于 DDS 实时性保障机制，正确说法有：

多选题 · extreme

  • A.共享内存传输可减少数据拷贝← 正确答案
  • B.零拷贝传输需要锁内存页面← 正确答案
  • C.实时调度降低消息排队延迟← 正确答案
  • D.DDS 能保证硬实时响应

答案：ABC。共享内存和零拷贝能减少数据搬运开销，实时调度能降低排队延迟。但 DDS 提供的是软实时保障，无法像实时操作系统那样承诺微秒级硬实时上限。救护车走绿色通道能大幅提速，但无法保证绝对不堵车。