⚡ electrical engineering

A Distributed Stereo Visual Feedback Framework for VR- based Telesurgical Robotic Teleoperation: Design and Latency Characterization

本文提出并表征了一种用于基于虚拟现实（VR）的远程手术遥操作的分布式立体视觉反馈框架，研究表明，尽管网络传输延迟极小，但总系统延迟（约 78 毫秒）的大部分源于图像处理和显示渲染阶段。

原作者： Haniyeh Altafi, Rayan Shakeel, Kourosh Zareinia

发布于 2026-08-13

📖 1 分钟阅读☕ 轻松阅读

原作者： Haniyeh Altafi, Rayan Shakeel, Kourosh Zareinia

原始论文采用 CC BY 4.0 许可（https://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

想象一下，你正在尝试玩一款视频游戏，通过它你可以控制房间另一端的一个机器人手臂。你移动双手，机器人也随之移动，但你只能通过一个屏幕看到机器人所看到的画面。如果屏幕上的图像哪怕只有一点点延迟，你的大脑就会感到混乱。这就像是戴着一副眼镜去接球，而眼镜显示的球是在一秒钟前的位置，而不是现在的位置。这就是“远程操作”（teleoperation）中的一个大问题——这个词只是指从远处控制机器人的专业术语。

为了让这种操作高效运行，特别是在像手术这样精细的任务中，你需要两样东西：清晰的 3D 图像（以便判断深度，比如针头离有多远）和速度（以便图像能即时更新）。科学家们称之为“立体视觉反馈”（stereo visual feedback）和“低延迟”（low latency）。如果延迟过长，操作者会感到笨拙，机器人可能会发生碰撞，或者在医疗场景中导致失误。研究人员提出的核心问题是：“时间都去哪儿了？”是互联网连接变慢了，还是计算机处理图像的时间太长了？

这篇论文通过构建一个专门针对机器人视觉的“时间机器”来深入探讨这个谜团。研究人员创建了一个系统，机器人端向另一端的虚拟现实（VR）头显发送 3-D 视频流。他们不仅仅测量了总时间，还将这段旅程分解成了三个不同的阶段，就像通过计时一场接力赛来观察哪位选手跑得最慢。他们发现，虽然互联网连接快如闪电，但计算机处理视频和 VR 头显显示图像的过程才是真正的瓶颈，表现得更像是一只缓慢移动的蜗牛。

机器人的 3D 之眼与 VR 头显

研究人员搭建了一个充当远程眼睛的系统。在“跟随者”（follower）一侧（即机器人所在处），有一个特殊的立体相机，它能像人类的双眼一样同时拍摄两张照片，从而产生 3D 效果。这些照片通过网络传输到“主控者”（master）一侧，那里有一位人类操作员在等待。人类佩戴着 Meta Quest 3 VR 头显，这就像是一个高科技窗口，让他们感觉仿佛就站在机器人身边。

视频的旅程始于相机，穿过中间计算机（它扮演着类似邮局分拣邮件的角色），到达主计算机，由名为 Unity 的游戏引擎进行处理，最后出现在 VR 头显中。团队想要精确测量这段旅程中每一步所花费的时间。

时间的接力赛

为了找出时间隐藏在哪里，团队将视频的旅程分成了三个阶段，就像一场由三位选手组成的接力赛：

网络选手（The Network Runner）： 这是视频通过线路传输所需的时间。
Unity 选手（The Unity Runner）： 这是计算机拆解视频并为 VR 头显做好准备所需的时间。
VR 选手（The VR Runner）： 这是头显将图像实际显示给你的眼睛所需的时间。

他们首先测量了网络选手。他们发送了 10,000 帧视频，发现其速度极快。平均时间仅为 5.59 ± 1.04 毫秒。这简直飞快！他们甚至测试了中间的“邮局”计算机是否会减慢速度，结果发现它增加的时间不到 1 毫秒。这证明了互联网连接本身并不是问题，它是整个系统中速度最快的部分。

然而，当他们观察Unity 选手时，比赛明显慢了下来。计算机仅处理视频并做好准备工作就平均花费了 40.06 ± 10.12 毫秒。这是最大的延迟部分。最后的 VR 选手（头显）在显示图像时又花费了 32.30 ± 0.09 毫秒。

当把这三个选手的时间相加时，从相机看到物体到人类在 VR 头显中看到物体的总时间为 77.95 ± 10.17 毫秒。

大惊喜：不是互联网的问题！

这篇论文中最重要的发现是一个剧情反转。许多人认为，如果你想让机器人更快，你只需要更快的互联网连接。但这项研究表明，即使拥有超高速的网络（那 5.59 毫秒的部分），总延迟仍接近 78 毫秒。为什么？因为计算机处理视频和头显显示图像占据了大部分时间。

这就像拥有一辆法拉利（互联网），却被堵在了由收费站（计算机处理）和慢速司机（头显渲染）造成的交通堵塞中。无论车有多快，旅程都会很漫长，因为中间有停顿。研究人员发现，网络仅对延迟负有极小的责任。真正的“交通堵塞”发生在软件和显示硬件内部。

它真的有效吗？

为了测试这个系统是否真的有用，研究人员邀请了四个人玩一个游戏。游戏是一个“拾取与放置”（pick-and-place）的任务：使用机器人将小方块从一个地方移动到另一个地方。他们尝试了使用 VR 3D 视图和不使用 VR 视图（使用普通 2D 屏幕）两种方式。

结果令人鼓舞。当参与者使用 VR 系统时，他们完成任务的速度更快（使用 VR 平均为 373.7 秒，而不使用 VR 则为 527.2 秒）。此外，他们的机器人移动路径更短、更直接，且掉落的方块也更少。每一位参与者都表示，VR 版本给了他们更好的深度感，并且感觉更加方便。

然而，作者谨慎地指出，这仅仅是一个只有四人的“初步”测试。这表明该系统运作良好，但还不是一个最终证明它能在任何情况下都适用于每个人的结论。在宣布这是一个完美的解决方案之前，他们还需要在更多人和更困难的条件下进行测试。

总结

这篇论文为未来的机器人手术和远程工作奠定了坚实的基础。它证明了你可以将高质量的 3D 视频传输到 VR 头显，且互联网带来的延迟非常小。但它也向工程师们传递了一个明确的信息：如果你想让这些系统更快，不要只去买更快的网线。你需要修复处理视频的软件和显示图像的硬件。互联网已经准备好了，现在轮到计算机和头显赶上来。

技术摘要：一种用于基于 VR 的远程手术机器人操作的分布式立体视觉反馈框架

问题陈述

在机器人辅助远程手术和高精度远程操作中，有效的深度感知和手眼协调高度依赖于低延迟的立体视觉反馈。虽然虚拟现实（VR）界面提供的沉浸式可视化可以提高态势感知能力，但这些系统的总端到端延迟往往是关键瓶颈。先前的研究已经强调，视觉延迟会降低任务性能、增加操作者工作量并危及安全性。然而，许多现有研究主要关注网络传输延迟或通用的交互界面，未能对完整的“相机到头显”视觉反馈管线进行特征化描述。具体而言，目前缺乏对延迟来源的详细分解——即区分网络传输、软件处理（如游戏引擎渲染）和显示渲染——这对于识别基于 VR 的远程手术系统中的真实瓶颈至关重要。

研究方法

作者开发并评估了一种专为基于 VR 的机器人远程操作设计的分布式立体视觉反馈管线。该系统架构由五个主要组件组成：

立体相机： 使用 GXIVISION 3D 立体 VR USB 相机模块，以 30 fps 的帧率捕捉同步的左右并排图像（2560 × 720 像素）。
发送端计算机： 运行 Windows 11，配备 NVIDIA RTX 3060 Ti。通过 GStreamer 利用硬件加速（NVENC）使用 H.264 进行视频编码，并通过 UDP/RTP 传输流。
中间网络计算机： 一个用于 UDP 数据包转发的基于 Ubuntu 的桥接器。在本研究中，为了建立基准，禁用了损伤函数（延迟、抖动、丢包），尽管该设置允许未来的网络模拟。
主端计算机： 运行 Windows 11，配备 NVIDIA RTX 4060 Ti。它解码 H.264 流（使用 NVDEC），并在 Unity 中处理左右并排图像（通过自定义着色器分离左右视图），然后为显示准备帧。
VR 头显： 通过 Meta Quest Link/OpenXR 连接的 Meta Quest 3，用于显示沉浸式立体视图。

延迟特征化方法：
研究将总延迟 ( $L_{total}$ ) 分解为三个不同的阶段：

$L_{network}$ ：传输和解码时间（通过 GStreamer 延迟追踪器测量）。
$L_{Unity}$ ：Unity 引擎内的帧更新和处理时间（通过 Time.realtimeSinceStartup 测量）。
$L_{VR}$ ：从 Unity 提交到头显的渲染和显示延迟。

作者比较了多种实现策略，包括基准 Python Socket 方法与优化的 GStreamer 管线，以及基于 CPU 的编码与基于 GPU 加速（NVENC/NVDEC）编码的对比。此外，还进行了初步的取放任务（pick-and-place task），由四名参与者进行，以比较基于 VR 的立体可视化与非 VR 条件下的表现，测量指标包括任务完成时间、路径长度和掉落件数。

核心贡献

管线实现： 创建了一个分布式立体视觉反馈系统，能够捕获、传输、处理并在 Meta Quest 3 头显中显示同步的立体视频，专门为未来的远程手术应用而设计。
延迟分解： 一种新颖的特征化方法，能够隔离网络传输、Unity 处理和 VR 渲染延迟。这种方法超越了简单的计算机间延迟测量，能够识别出导致端到端延迟的具体阶段。
优化验证： 证明了硬件加速编码/解码（GPU）和结构化媒体框架（GStreamer）在延迟、抖动和帧稳定性方面显著优于基础的 Python Socket 实现。
经验基准： 为基于 VR 的远程操作提供了定量的延迟数据，为未来关于立体感知和操作者性能的研究建立了参考。

实验结果

网络传输： 优化的 GStreamer 管线实现了 5.59 ± 1.04 ms 的平均网络延迟，抖动为 0.45 ms，且在 10,000 帧中零丢包。中间桥接计算机引入的额外延迟极小（<1 ms）。
优化影响： 从 Python Socket 基准切换到 GStreamer 管线使平均延迟降低了约 44.7%（从 10.11 ms 降至 5.59 ms）并消除了丢包。此外，GPU 加速的编解码将平均管线延迟降低了 38.1%，并显著提高了帧定时稳定性（将帧间标准差从约 44 ms 降至约 8 ms）。
端到端延迟： 总的“相机到显示”延迟测量为 77.95 ± 10.17 ms。分解结果显示，网络传输仅占很小的比例（~5.6 ms）。主要的延迟来源是：
- Unity 帧更新：~40.06 ms
- VR 显示渲染：~32.30 ms
初步任务评估： 在四名参与者的取放任务中，VR 条件下的完成时间更快（平均 373.7 s 对比无 VR 时的 527.2 s），笛卡尔路径长度更短，且掉落件数更少（平均 1.25 对比 4.00）。所有参与者在主观上都报告了更好的深度感知，并更倾向于使用 VR 条件。

重要性与主张

本文声称其主要意义在于证明了 网络传输并不是基于 VR 的远程操作系统中延迟的主要来源。相反，可视化和显示阶段（Unity 处理和 VR 渲染）引入了大部分延迟。

因此，作者认为，仅优化网络协议不足以实现低延迟的远程手术反馈。未来的系统设计必须优先优化可视化管线，包括相机帧率、游戏引擎中的纹理上传开销以及 VR 渲染路径。

该研究将所提出的管线定位为未来研究立体感知、视觉延迟和操作者性能在 VR 远程手术领域应用的实用基础。作者明确指出，由于样本量较小，初步任务的结果属于描述性观察，且该系统尚未与触觉反馈或物理机器人控制环路集成。这项工作是实现更复杂的、集成的远程操作研究之前，对完整视觉反馈环路进行特征化分析的必要步骤。