为什么每个机器人远程操作团队最终都会超越 WebRTC 的范畴

我们看到的几乎所有远程操作项目都是这样开始的：团队中的某个人找到 WebRTC 文档，让两台笔记本电脑之间连接网络摄像头，将其连接到机器人，然后在办公室演示远程操控。

但当机器人离开大楼后，飞行员发现办公室演示中的几乎所有设置都无法迁移到实际网络中。实际网络环境使用不同的运营商网络，操作员的 Wi-Fi 连接质量很差，实验室中 80 毫秒的延迟，在网络出现任何波动时都会飙升至 220 毫秒。就在操作员准备抓取机器人时，机器人会突然停止响应半秒钟。事后分析中反复出现的问题，也是我们经常听到的：我们是继续修补 WebRTC，还是应该彻底更换其底层的网络协议栈？

这种模式非常稳定，几乎可以精确到时钟。WebRTC 能让机器人团队比市面上任何其他方案都更快地搭建出一个可运行的演示版本，但一旦演示版本需要部署到实际环境中，它就会失效。这种不匹配并非漏洞，而是协议本身固有的设计选择，这意味着你无法通过任何修补来绕过协议最初的设计考量。

为什么 WebRTC 是默认的起点

在深入探讨故障模式之前，我们有必要先肯定一下 WebRTC 的优势。团队选择它的原因确实都很充分：

• 它是免费开源的，针对机器人团队可能使用的所有语言都有成熟的实现，并且采用宽松的许可协议。
• 它可以运行在浏览器中，这意味着无需安装即可在任何笔记本电脑的 Chrome 标签页上运行操作界面，从而大大加快早期演示的速度。
• NAT穿越问题已解决。ICE、STUN和TURN负责防火墙，并解决转换问题，否则这些问题可能需要耗费数周的工程时间。
• 编解码器协商正常。两端无需手动配置即可确定可以编码和解码的内容。
• 该社区规模庞大，Stack Overflow 几乎可以解答所有问题，而主要浏览器厂商也在推动该协议向前发展。

对于一个正在开发第一个远程控制演示的小团队来说，这其中的利弊显而易见，因为午饭前就能上线。我们并非反对在原型开发中使用 WebRTC，它确实是合适的工具。我们讨论的是，当你尝试将原型投入生产环境时会发生什么。

当限制条件发起反击时

机器人远程操作面临四项限制，这些限制与 WebRTC 的设计选择相冲突，且每项限制都在生命周期的不同阶段显现出来。

蜂窝网络的运行方式与WiFi截然不同

大多数远程操控部署方案都会将至少一部分路径路由到蜂窝链路上，通常机器人使用专用的 5G 网络，而操作员则使用移动网络或家庭网络连接。WebRTC 是为公共互联网优化的，在公共互联网上，丢包通常表示网络拥塞，正确的应对措施是降低发送速率。

蜂窝网络的运行方式截然不同。LTE 和 5G 上的丢包通常是短暂的无线电事件，例如小区切换或来自其他设备的干扰，正确的应对方法是继续发送数据而不是停止发送。WebRTC的拥塞控制会将这些事件视为限制数据流的信号，从而在运营商无法纠正的情况下，在最不恰当的时刻限制了运营商的可见性。

延迟低于 40 毫秒需要采用不同的抖动策略

远程操控可用延迟的阈值约为100 毫秒（即从终端到终端的延迟），低于此延迟，操作员可以完成闭环抓取；高于此延迟，他们往往会过度修正并反复操作，直至任务失败。Adamo 的延迟低至 40 毫秒，因为延迟的下限也是上限：每一毫秒浪费在可避免的事情上，都会因为网络传输或显示刷新等不可避免的事情而损失掉。

WebRTC 的抖动缓冲通常设置为 50 到 100 毫秒，对于视频通话来说，这是一个合理的折衷方案，因为视频通话更注重流畅播放而非响应速度。但对于远程操作来说，仅此缓冲就消耗了大部分带宽。虽然可以降低缓冲值，但这会牺牲流畅度来换取响应速度，而且大多数团队都是在客户面前而不是在白板上才发现这种权衡的。

ROS 不支持 WebRTC

我们使用过的几乎所有机器人的自主系统都运行在 ROS 或 ROS2 上。WebRTC 本身没有 ROS 主题的概念，因此团队需要构建一个转换层，将 ROS 消息打包到数据通道中，并在另一端进行解包，但这会带来转换过程中的时序和可靠性问题。

这个补丁很容易变得脆弱，因为ROS端的任何改动都会导致转换层出现难以诊断的故障。故障模式是静默的：通道看起来仍然连接着，但消息却悄无声息地停止流动或乱序到达。

数据采集​​是事后才考虑的

远程操作会话最有价值的成果并非恢复本身，而是随之而来的数据：同步视频、遥测数据、传感器数据流以及操作员操作数据流，这些数据共同构成下一轮自主操作的训练轨迹。WebRTC 的设计初衷并非用于记录这些数据，因为这些数据流的编码是为了传输而非存储，而要忠实地记录来自摄像头和操作数据流的信息本身就是一个独立的工程项目。

将录制功能后期集成到 WebRTC 流水线上的团队几乎总是​​会遇到录制数据缺失的问题，因为拥塞期间丢失的帧无法恢复，而且时间戳会在原本就没打算同步的数据流之间漂移。操作员的输入数据记录在一个日志中，视频数据记录在另一个日志中，事后进行数据协调本身就是一个数据工程难题，导致那些录制成本最高的会话中出现数据缺失。

实际影响表现如何

我们最常听到的版本大致是这样的：

“我们派了两名工程师花了九个月时间修补我们的 WebRTC 堆栈。我们将延迟从 240 毫秒降到了大约 150 毫秒。录制功能仅能部分实现。我们仍然无法通过蜂窝网络从客户现场可靠地操控机器人。”

具体数值因团队和网络而异，但情况总是大同小异。这些补丁占用了本应投入到机器人、自主系统和操作员体验上的工程资源，最终产出的技术栈虽然能在测试环境中正常运行，却在下一位客户处就出现故障。即使经过数月的修复，延迟的下限仍远高于操作所需达到的响应速度。

当技术已无法满足需求时，应评估哪些方面

当团队最终决定放弃 WebRTC 时，问题就从“如何修复这个问题”转变为“替代方案究竟应该具备哪些功能”。以下是我们建议的检查清单，内容源自我们的客户在切换前向我们提出的问题：

• 在实际网络环境下测量端到端延迟。并非理想链路下的营销数据。请索取在蜂窝网络、网络性能下降的 Wi-Fi 以及跨洲际网络环境下的基准测试结果。
• 丢包情况下的行为。视频质量应平稳下降，同时控制频道仍保持响应，而不是频道完全卡死。
• 原生集成 ROS 和 ROS2。平台应该使用你的机器人已经使用的语言，因为翻译层是需要永久支付的费用。
• 支持多路径。在传输层实现 LTE、5G 和 WiFi 之间的绑定与故障转移有着本质区别，它消除了任何单一网络路径所造成的单点故障。
• 同步数据采集。该平台应以共享时钟记录视频、遥测数据和操作员操作，以便直接用于培训。
• 集成成本。只需几个小时而非几个月，而且只需一个二进制文件，零外部依赖，这是任何供应商都应该遵守的标准。
• 安全性和合规性。所有数据流均采用 AES 256 加密，符合 SOC2 标准，所有受管设施均采用生物识别访问控制。
• 运营模式。纯软件模式是一种选择，托管运营商网络模式是另一种选择，平台应该支持您需要的任何一种模式，理想情况下两者都支持。

如果供应商无法具体回答这些问题，那么对于“我们是否应该继续为 WebRTC 打补丁”这个问题，诚实的答案可能是再坚持一个季度，因为至少补丁是你自己控制的。

Adamo的成果

Adamo 的诞生，正是因为当我们向开放标准提出上述每一个问题时，答案都是“不”，因此我们从头开始重建了网络协议栈，并专门针对机器人技术进行了设计：

• 通过全球中继网络实现低至 40 毫秒的端到端延迟，比典型的 WebRTC 协议栈快 180%，在网络条件较差的情况下快 10 倍。
• 在传输层实现LTE、5G 和 WiFi 之间的多路径绑定，数据包沿着每个可用路径快速传输，接收器使用最先到达的副本。
• 控制优先架构。控制指令运行在专用的高优先级数据流上，永远不会排在视频之后，因此当信道变窄时，视频比特率会进行调整，而机器人仍能继续响应。
• 原生支持 ROS 和 ROS2，无需转换层，并且开箱即用，兼容 NVIDIA。
• 一个 40MB 的二进制文件，没有任何外部依赖项，可以在真正的机器人实际使用的旧的未打补丁的 Linux 内核上运行，具有端到端 AES 256 加密和 SOC2 合规性。
• 内置同步数据采集功能。视频、遥测数据、传感器数据流和操作员操作数据均以共享时钟进行采集，并可随时反馈到下一次训练运行中。

除了软件之外，我们的托管运营商服务还由专门建造的设施提供，这些设施配备冗余的互联网服务提供商、备用电源和生物识别访问系统，运营商均经过心理测试和绩效筛选，提供全天候 24/7 服务，并可根据您的车队规模进行扩展。

如果你现在已经在生产环境中运行 WebRTC，那么问题不在于它是否会被淘汰，而在于何时会被淘汰，以及接下来六个月的工程团队应该把精力投入到哪些方面。那些行动最快的团队，是那些不再把远程操作视为附属项目，而是将其视为真正意义上的基础设施层的团队。

本文内容及观点仅代表作者个人立场。