首页配送机器人遇到临时封路，巡检机器人停在复杂地形前，机械臂面对难以处理的物体——当自主系统无法继续完成任务时，人如何介入，决定了机器人能否顺利完成接下来的工作。
远程操控和平行操控，都为人工参与机器人作业提供了路径。前者侧重人如何通过网络操作设备，后者更关注自主运行与人工干预如何配合。理解它们的区别，可以从一个问题入手：哪些工作交给机器人，哪些判断和操作留给人？
一. 远程操控和平行操控有什么区别？
远程操控：通过网络操作远端机器人
远程操控，即 Teleoperation，是指操作员通过通信链路操作远端设备。机器人将现场画面和状态传回操作端，人据此作出判断，再发送移动、转向、抓取等指令。
远程操控有不同的控制层次。直接遥操作中，人持续控制设备动作；监督控制中，人提供目标或指令序列，由机器人完成相应执行过程。“控制机器人向前移动”和“让机器人前往指定位置”，对应的人工参与程度就不同。
平行操控：自主运行与人工介入相配合
在机器人应用中，平行操控强调机器人自主运行时，人仍能远程观察，并在需要时介入或接管。
例如，配送机器人平时自主行驶，遇到无法处理的通道阻塞后请求帮助。操作员查看现场，提供任务指导，或接管设备完成脱困，再交还自主系统继续运行。
两者存在紧密联系：远程操控提供人工操作设备的能力，平行操控将这种能力与自主运行结合起来。 平行操控中的人工接管，往往就是通过远程操控完成的。
核心区别一览
从典型工作方式来看，远程操控侧重人工直接操作，平行操控侧重自主运行与人工接管的配合。
| 比较维度 | 远程操控 | 平行操控 |
|---|---|---|
| 核心思路 | 人远程观察，通过网络操作机器人 | 机器人自主运行，人监督并按需介入 |
| 人的主要职责 | 判断现场情况，控制作业过程 | 处理自主系统难以应对的异常和复杂任务 |
| 人工参与时间 | 通常在人工操作阶段持续参与 | 集中在请求协助或特定任务阶段 |
| 控制权管理重点 | 操作权限、指令来源和设备响应 | 接管申请、切换确认与控制权交还 |
| 适合的任务 | 需要人持续观察、判断和调整 | 常规部分可自主完成，特殊情况需要人工处理 |
| 典型例子 | 人连续控制机器人通过复杂路段 | 机器人自主配送，人接管脱困后恢复自主 |
选择时，应重点评估任务对人工判断的依赖程度。按需接管能否提高运营效率，还取决于异常频率、处理时长和操作员的响应能力。
二. 不同机器人场景，应该怎样选择？
工业生产、物流配送、清扫巡检和高危作业，对机器人的要求各不相同：有的强调精细操作，有的任务重复但环境多变，有的首先需要让人远离危险区域。
| 应用场景 | 任务特点 | 操控方式如何配合 |
|---|---|---|
| 工业生产与机械臂作业 | 重复动作与精细操作并存 | 规则明确的动作自主执行，需要连续调整的阶段由人远程操作 |
| 物流配送与清扫 | 任务目标明确，可能遇到临时障碍 | 自主完成日常任务，人工协助绕行、脱困或处理异常 |
| 巡检与远程运维 | 常规路线重复，异常情况需要进一步判断 | 自主巡检，发现异常后由人查看现场并决定是否接管 |
| 高危区域作业 | 人员接近现场的风险或成本较高 | 建立远程观察和操作能力，再按任务分配人工与自主系统的职责 |
远程脱困、配送与清扫设备应急接管，以及工程机械高危作业，都是现有平行操控方案覆盖的应用方向。
实际任务也可以组合两种方式：机器人自主到达目标区域，人工接管完成复杂操作，随后恢复自主运行。由此，方案设计的重点进一步转向：什么时候切换，怎样确认切换成功，处理结束后如何交还控制权。
三. 从自主运行到人工接管，难点在哪里？
一次完整接管，可以沿着以下流程展开：
自主运行 → 发现异常 → 请求介入 → 确认控制权 → 人工处理 → 检查恢复条件 → 返回自主运行。
这条流程需要解决三个关键问题。
1. 切换控制权，不能只靠一个按钮
操作员收到接管请求后，系统需要检查是否允许切换，并确认远程指令何时生效。人工处理结束后，也要确认机器人具备继续自主执行的条件。
Autoware 的运行模式设计就区分了自主、远程、本地和停止模式，并设置过渡状态，检查切换条件和完成情况。
因此，界面应让操作员清楚区分“正在申请”“正在切换”和“已经接管”。无人响应、通信中断或切换失败时，也需要有对应的设备处置逻辑。
2. 画面、指令和执行反馈需要连成闭环
操作员看现场、发指令、观察执行结果，构成远程操作的反馈过程。任何环节滞后，都可能影响下一步判断。
NIST 的车辆遥操作研究将通信延迟拆分为操作员到设备的控制指令延迟，以及设备返回操作员的反馈延迟。
评估机器人操控体验时，也应分别观察视频反馈、指令送达和设备执行响应。同时区分“指令已收到”与“动作已完成”，让操作员能够判断设备的真实状态。
3. 弱网下，观察与操作都要保持可用
机器人移动时，可能遇到网络覆盖变化、丢包和抖动。画面卡顿影响现场判断，控制传输不稳定则影响操作响应。
因此，测试不能只看视频是否流畅，还应检查指令传输、状态反馈和网络恢复表现。跨网络体验、音视频延时和控制信令同步，也是远程操控通信方案需要共同解决的问题。
四. 声网如何解决远程操控中的通信难题？
沿着接管流程看，通信系统需要持续完成三件事：把现场信息传回来，把操作指令发过去，让设备状态及时反馈。
声网通过实时音视频、实时信令与网络传输能力，为这三个环节提供支持。
RTC + RTM：连接现场、操作与状态反馈
接管机器人时，操作员往往需要同时查看视频、发送指令并了解执行结果。
声网机器人远程操控与实时互动方案支持 RTC 与 RTM 一体化、模块化接入，提供音视频、控制信令和数据通道。控制传输支持优先保障即时性的低延时模式，以及优先保障指令可达和状态一致性的可靠模式；视频侧能够根据网络状态调整码率、分辨率和帧率。
这些能力让开发者能够围绕任务组织操作界面：画面用于观察，指令用于操作，状态数据用于确认结果，并减少分别搭建通信模块的工作。
SD-RTN 与多路径传输：应对网络质量变化
机器人可能分布在不同园区和城市，作业过程中也可能经历网络切换。远程操控需要同时考虑传输距离与链路稳定性。
声网平行操控方案基于 SD-RTN 实时网络，提供智能路由和 QoS 分级保障；其 AUT 传输协议支持多网卡融合，方案也支持多运营商物联网卡的流量融合。
这些能力从路由选择、传输优先级和连接路径等层面改善通信条件。项目验证时，可以重点测试网络切换、丢包和抖动下的画面、指令及状态反馈表现。
端侧媒体适配：优化从采集到显示的链路
现场视频需要经历采集、编码、传输、解码和显示。设备端媒体处理，也是影响反馈速度的重要环节。
声网与瑞芯微围绕 RK3588、RK3576 平台和 Rockit 多媒体框架开展适配，优化视频处理环节之间的衔接，并提供开发 Demo，为采用相关平台的团队提供已有集成基础。
双方公布的联合测试结果包括端到端延迟低于 200ms、网络延时中位数为 76ms。这两个数字衡量的范围不同，实际选型仍需结合设备处理和执行反馈，测试完整操作链路。
通信接入后，机器人团队还需要完成运动控制对接、控制权管理和异常处置，让实时连接融入整机接管流程。
五. 常见问题
平行操控需要操作员一直在线操作吗？
机器人可以自主完成常规任务，操作员在监督、异常处理或复杂操作阶段参与。人工参与的频率和深度取决于任务与自主能力。
远程操控和平行操控能使用同一套通信方案吗？
可以。两者都可能需要音视频、控制指令和状态传输，设计重点更多体现在人工何时介入，以及控制权如何切换。
一名操作员能管理多少台机器人？
需要结合接管频率、处理时长、任务复杂度和允许等待时间评估，尤其要考虑多台设备同时请求帮助的情况。
对于正在开发接管能力的团队，可以先梳理自主执行与人工介入的边界，再结合声网机器人远程操控与实时互动方案，验证现场反馈、控制传输和设备状态在真实环境中的协同表现。
