论文

Adaptive Bridge: 一种用于缓解 ROS 2 中 DDS 背压的基于代理的解耦层

Adaptive Bridge: 一种用于缓解 ROS 2 中 DDS 背压的基于代理的解耦层

在基于 ROS 2 与 DDS 构建的系统中,RELIABLE topic 上单个网络受损或被限速的 subscriber 会引发背压,使共享同一 publisher 的所有其他 subscriber(包括安全关键节点)的吞吐与延迟同时恶化,原因是 publisher 的 DDS writer 已无法接收新的样本。 为解耦关键 subscriber 与降级或非关键 subscriber、从而隔离关键路径,我们提出 Adaptive Bridge,一种基于代理的解耦层,其核心手段为 topic splitting 与动态速率控制。该代理充当中介:订阅原始 topic,再把消息重新发布到两个相互独立的 DDS writer —— 面向关键节点的一个 RELIABLE writer,以及面向非关键或已降级节点的一个 BEST EFFORT writer,由此隔离降级节点,并保护 publisher 与关键节点免受背压影响。此外,基于探针的分类器通过带滞回的采样主动监测 subscriber 健康状态,并实时调整 subscriber 的速率上限。 在实验层面,我们采用可复现的 Docker 测试台,在 Gilbert-Elliott 突发无线丢包模型下进行评估。结果表明:在全部损伤严重程度下,使用 Adaptive Bridge 可将关键 subscriber 的尾部 p95 延迟 从最高 15 s 降至 1.55 ms,同时保持 publisher 所配置的吞吐。

论文精读

TL;DR **Adaptive Bridge** 用代理层将 ROS 2 中受 DDS 背压影响的劣化订阅者与关键路径解耦,通过主题分裂与动态速率控制,把关键订阅者 p95 尾部延迟从 15 s 压到 1.55 ms。

问题

问题背景

在基于 ROS 2 和 DDS 的机器人系统中,多个节点订阅同一 RELIABLE 话题时,发布者需保证所有订阅者可靠接收,因此任意一个订阅者性能下降都会拖累整体。

现有方法局限

传统应对方式主要有:

  • 全部改用 BEST EFFORT QoS:牺牲可靠性换取吞吐,但无法满足安全关键数据传输需求。
  • 静态拆分话题或预先限流:缺乏对运行时网络抖动和订阅者健康状态的动态感知,要么过保守浪费资源,要么无法及时隔离故障节点。
  • 依赖人工监控与重配置:无法在毫秒级响应突发丢包或拥塞。

核心问题是 DDS RELIABLE 写者队列 在等待重传时会被阻塞,发布者无法写入新样本,导致 队头阻塞(head-of-line blocking) 波及所有订阅者。

为什么这个问题难/重要

  • 技术挑战:需要在保持关键路径强可靠性的同时,实时识别并隔离降级订阅者,且不能误伤正常节点。
  • 动态性:无线网络损伤(如突发丢包)具有随机性和突发性,静态策略难以覆盖。
  • 业界关注:分布式机器人、自动驾驶等场景对 尾部延迟(p95) 和吞吐稳定性要求极高,单个节点的网络劣化可能造成安全事故。

行业类比

类似大模型在线推理服务中,单个慢客户端占用连接导致整个推理集群吞吐骤降,需要按请求优先级和连接健康状态做动态隔离与限流,而非简单地全量降级。

核心洞察

  • 代理解耦将 ROS 2 发布者与不可靠订阅者隔离,通过 topic splitting 和双 writer 模式阻断 DDS 背压传导。现有方案多在发布端调整 QoS 或改全局 BEST_EFFORT,但 Adaptive Bridge 在中间层引入代理,将单一 RELIABLE topic 拆为面向关键节点的 RELIABLE 和面向非关键节点的 BEST_EFFORT,使受损订阅者无法阻塞发布者,同时保持关键路径可靠性。该设计把背压边界从发布者迁移到代理,无需修改现有节点或 DDS 实现,工程落地性高。
  • 基于探针的健康分类器结合滞后采样和动态速率限制,实现对订阅者状态的实时自适应。不同于静态阈值或一次性丢包率判断,该方法通过 probe 主动采样并引入 hysteresis 机制,避免临界状态频繁切换导致震荡,同时根据分类结果动态调整对非关键订阅者的速率限制。闭环控制区分了突发 impairment 与持续降级,在 Gilbert-Elliott 突发丢包模型下,关键订阅者尾延迟 p95 从最高 15 s 降至 1.55 ms,且不牺牲发布者配置吞吐量,展示了自适应 QoS 在真实无线场景的实用价值。

方法

输入与代理位置

Adaptive Bridge 作为一个 ROS 2 节点部署在发布者与订阅者之间,代理首先订阅原始话题(通常配置为 RELIABLE),接收发布者的所有样本。原始发布者只与代理交互,不再直接面对多个订阅者,从而避免单一慢订阅者拖垮发布者的 DDS writer。

关键模块

  1. Topic Splitting(话题拆分):代理内部创建两个独立 DDS writer:

    • RELIABLE writer 面向关键/健康订阅者,保留可靠传输语义,保证不丢样本。
    • BEST EFFORT writer 面向非关键或已降级订阅者,丢弃重传压力,避免阻塞。 两个 writer 完全隔离,一个 writer 的 backpressure 不会影响另一个。
  2. Probe-based Classifier(探针分类器):主动监控每个订阅者的健康状态。通过周期采样(如心跳或轻量探测消息)评估订阅者是否健康,结合**滞回(hysteresis)**机制避免状态抖动。健康指标可能包括 ACK 延迟、样本丢弃率或队列深度。

  3. Policy Engine & Rate Limiting(策略引擎与限速):根据分类结果动态调整对每个订阅者的发送速率。降级节点被限速,并可能被迁至 BEST EFFORT writer;关键节点维持全速率和 RELIABLE 语义。限速在 writer 端执行,防止降级节点缓存无限增长。

  4. Safety Supervisor(安全监督器):监控整体系统状态,确保关键路径不被策略误伤。若分类器出现错误或策略异常,可回退到安全配置(如强制关键节点保持在 RELIABLE writer 上)。

输出

最终产生两个独立数据流:关键节点获得低延迟、可靠传输;非关键/降级节点获得尽力而为传输且被限速。原发布者无需任何修改,其配置吞吐保持不变。

与静态 QoS 配置或单纯 RTPS 层调优不同,Adaptive Bridge 通过代理层将传输可靠性拆分与运行时健康分类结合,实现按订阅者粒度的动态隔离,且无需修改发布者代码。

实验

实验设计

使用可复现的 Docker 评估 harness,在 Gilbert-Elliott 突发无线丢包模型下模拟网络损伤。发布者以 30 Hz 发送激光扫描数据,关键订阅者与远程可视化节点共享同一 RELIABLE topic。对比基线(无 Bridge)和 Adaptive Bridge 部署后的性能,测量关键订阅者尾部 p95 延迟与发布者吞吐量。

关键发现

在基线中,网络受损的订阅者触发 DDS 重传,导致发布者阻塞,关键订阅者 p95 延迟高达 15 秒。部署 Adaptive Bridge 后,代理将原始 topic 拆分为两个独立 writer:RELIABLE 给关键节点,BEST EFFORT 给非关键/受损节点。结合探针分类器和动态速率限制,p95 延迟骤降至 1.55 ms,降幅约四个数量级,同时发布者吞吐量保持不变。跨 RMW 验证和消融实验(topic splitting vs classification)进一步确认了各组件贡献。

与基线对比解读

基线问题本质是 DDS backpressure 沿订阅图反向传播,单一慢订阅者拖垮全局。Adaptive Bridge 通过代理隔离和 QoS 降级切断这一耦合,使关键路径不受非关键干扰。相比直接修改应用层 QoS 或引入复杂调度,代理方案部署透明、可增量改造。但需关注代理自身成为单点以及额外一跳延迟。对工程实践而言,在 ROS 2 多订阅者场景中,将关键流量与非关键流量物理或逻辑隔离,是提升尾部延迟稳定性的有效手段。

行业影响

落地场景

Adaptive Bridge 适用于任何基于 ROS 2 + DDS 的机器人系统,特别是同时包含安全关键节点和易受无线网络波动影响的非关键节点。典型产品包括自动驾驶车辆、仓储 AMR、无人机集群、远程遥操作机器人。在这些系统中,一个网络受损的订阅者可能拖垮整个发布者,导致安全关键路径延迟骤增。该方案通过代理解耦和动态速率限制,确保关键节点不受 backpressure 影响。

商业价值

  • 降本:避免因 DDS 重传风暴导致的硬件资源浪费和系统停机,减少现场调试与售后支持成本。
  • 增收:提升机器人车队在复杂网络环境下的稳定运行时间,增加可售服务时长;对自动驾驶等安全攸关场景,降低事故风险带来的潜在损失。
  • 体验提升:关键控制回路延迟从最高 15 s 降至 1.55 ms(p95),意味着更平滑的操控和更快的响应。

与现有工作流集成

Adaptive Bridge 可作为独立 ROS 2 节点或容器化 sidecar 部署,不需修改现有发布者/订阅者代码。只需将原始 topic 重映射到 bridge 的输入,再从 bridge 的两个输出 topic 订阅(一个 RELIABLE 给关键节点,一个 BEST_EFFORT 给非关键节点)。可集成到现有 ROS 2 launch 系统与 Docker/K8s 编排中,也可通过 ros2 topic echo 等工具监控各 topic 的健康状态。

具体落地 use case

  1. 自动驾驶车队:激光雷达点云发布者同时供本地规划模块(RELIABLE)和远程可视化(BEST_EFFORT)订阅。远程链路丢包时,bridge 隔离重传压力,本地规划保持 30 Hz 稳定。
  2. 仓储 AMR 集群:调度中心通过 Wi-Fi 向多台 AGV 下发指令,个别 AGV 信号差导致调度器 DDS writer 阻塞,bridge 将关键控制指令与遥测数据分离,保障所有 AGV 实时响应。

局限

  • **实验场景受限**:论文仅在单一发布者与少量订阅者的拓扑下评估,未覆盖多发布者、多代理或节点动态加入/离开的场景;代理引入的额外一跳增加了平均延迟,尽管尾延迟显著改善,但对实时控制环路的端到端延迟预算可能仍有影响,需在真实机器人系统中进一步验证。
  • **部署复杂度与单点风险**:代理作为中间件组件,自身可能成为性能瓶颈或单点故障,且需要预先人工划分关键/非关键订阅者,缺乏自动分类机制;在实际大规模系统中,代理的配置、监控和故障恢复策略将增加运维负担,可能不适合资源受限的嵌入式节点。
  • **评估环境泛化性不足**:实验基于 Gilbert-Elliott 模型模拟突发丢包,未在真实无线网络或实际机器人平台上验证;与现有轻量级 QoS 调优方法(如调整历史深度、资源限制)相比,本方案需额外部署代理,架构更重,且未与这些方法进行直接对比,难以量化相对收益。
论文Kaushalraj Puwar2026-09-06原文

相关内容