机器人已经可以自主规划路线、上下楼梯、避开障碍物,甚至独立完成巡逻和物资转运任务。但当这些设备真正进入园区、仓库、工厂等场所,新的问题也随之出现:巡逻途中发现异常情况怎么办?运输通道被临时占用,机器人无法继续前进怎么办?一台部署在异地的机器人突然停下,是否每次都要安排人员赶到现场?这些问题不完全取决于机器人的自主导航能力,还涉及现场判断、异常处理以及设备运维。对于分布在不同区域的机器人来说,远程操控正是解决这类问题的重要手段。
2026 年 10 月 23 日至 24 日,在 iRTE 2026 实时智能大会上,联想轮足机器人 MC 亮相声网展台。这款小型行业级四轮足机器人采用轮足融合设计,最大越障高度可达 65cm,最大续航里程约 9km,面向园区安防巡逻、物流转运、教育实训等场景。
联想 MC 已接入声网机器人远程操控解决方案,通过 RTC 实时音视频与 RTM 实时信令,实现现场画面回传和远程运动控制,让工作人员不必始终跟随机器人,也能了解现场情况并进行远程操作。

一. 机器人能够自主作业,为什么还需要远程操控?
首先需要区分两个概念:自主作业和远程操控,并不是互相替代的关系。
自主作业解决的是机器人如何独立完成既定任务。例如按照巡逻路线移动、识别障碍物、规划通行路径,或者根据调度系统的任务要求,将物资运送到指定位置。
远程操控则是在需要人工介入时,让工作人员能够查看机器人所处环境,并根据实际情况调整机器人的动作或任务。
在相对固定的实验环境中,机器人可以按照预设任务反复运行。但实际业务现场并不会始终保持不变。
园区的道路可能临时施工,建筑出入口可能被车辆堵住,物流通道可能出现临时堆放的货物。即便机器人的导航和避障系统能够识别这些障碍,也不一定能独立判断下一步该如何处理。
例如,一台巡逻机器人发现原定路线被封闭,它可以停止移动或尝试重新规划路径,但是否允许进入其他区域、能否绕行、是否需要调整巡逻任务,可能还需要工作人员判断。
如果机器人具备远程查看和操控能力,工作人员就可以先获取现场画面,再决定是修改任务、远程调整位置,还是安排现场人员处理。
远程操控的价值,不是让人代替机器人完成所有工作,而是避免机器人遇到无法自行处理的问题时,整个任务只能停在那里。
对于持续运行的机器人系统来说,这种人工干预能力直接关系到异常处理效率和实际可用性。
二. 园区巡逻、物流转运,哪些情况需要人工远程介入?
机器人远程操控并不是一个单独的应用场景,它通常嵌入巡逻、运输、巡检等具体业务流程。不同场景中,工作人员需要接管机器人的原因也不一样。
1. 园区安防巡逻:发现异常之后,还需要进一步确认
园区巡逻机器人通常按照预定路线行驶,通过摄像头、传感器等设备采集环境信息,辅助安防人员了解现场状况。
但发现异常与处理异常是两回事。
假设一台机器人夜间巡逻时,发现某处通道有人员停留,或者某个设施周围出现异常情况。即使系统能够自动识别并上报异常,工作人员也可能需要进一步确认现场情况。
例如:
- 当前画面无法看清目标,需要调整机器人位置或观察角度。
- 通道被临时占用,需要判断是否继续通行。
- 异常发生在监控盲区附近,需要机器人靠近查看。
- 巡逻路线发生变化,需要临时调整任务。
如果机器人只能上传报警信息,工作人员仍然需要通过固定摄像头查找相关画面,或者直接赶到现场确认。
接入实时视频与远程控制能力后,工作人员可以直接查看机器人摄像头传回的画面,在必要时远程调整其移动方向、观察位置或巡逻路线。
这里对实时通信的要求很具体。
机器人向前移动时,操作者需要持续了解前方是否有障碍物、机器人与目标之间还有多远。如果画面出现明显延迟,工作人员看到的位置就可能落后于机器人实际位置。
同样,操作指令也需要及时传达到设备。尤其在靠近墙体、台阶、车辆等障碍物时,指令响应不及时可能影响操控精度。
因此,园区巡逻中的远程操控并不是简单地打开一个视频监控窗口,而是需要将现场画面与机器人的运动控制结合起来。
2. 物流转运:路线规划完成,不代表运输过程不会中断
与园区巡逻相比,物流转运机器人面对的问题更加复杂。
在仓库或固定生产线中,运输路线通常比较明确。但当机器人需要跨建筑、跨楼层移动,或者进入室外园区时,环境条件就不再完全可控。
联想 MC 采用轮足融合结构,兼顾轮式移动效率与足式越障能力。根据联想与声网公布的合作信息,围绕 MC 平台的物流转运方案面向生物化工园区、酒店园区、景区等场景,支持跨建筑、跨楼层及非结构化环境下的运输任务。

这些场景对机器人的要求,不只是从起点移动到终点。
以园区内的物资配送为例,机器人可能需要经过室外道路、建筑入口、坡道及楼层之间的连接区域。
如果某段通道临时堆放了货物,机器人可能通过自主避障功能绕行;但如果所有可用路线都被占用,或者系统无法判断当前路径是否允许通行,运输任务就可能中断。
这时,远程工作人员可以查看现场视频,确认问题究竟是临时障碍、路径变化,还是机器人自身出现异常。
对于具备相应控制权限和安全机制的机器人,工作人员可以进一步远程调整设备位置、重新指定路线,或将任务交给现场人员处理。
这类能力能够减少部分异常情况下的现场介入需求,但并不意味着远程操控可以解决所有问题。
例如,机器人发生机械故障、负载异常,或者需要通过存在安全风险的区域时,仍然可能需要工作人员到场。
对物流转运业务来说,远程操控真正重要的地方,是在运输过程出现异常时,提供一种不必立即到场的处理方式,减少能够远程解决的问题对任务连续性的影响。
3. 多区域部署:设备不在身边,如何及时处理异常?
当机器人从单台试运行进入多区域部署阶段,运维方式也需要发生变化。
假设一家企业在三个园区部署了多台巡逻机器人。如果每个园区都安排专人跟随设备,不仅增加人力投入,也难以发挥机器人的自主作业优势。
一种可考虑的模式是:机器人平时自主执行任务,管理人员集中查看设备状态;当某台机器人出现异常时,再通过远程视频确认情况,并根据需要介入。
这种模式下,机器人不一定需要持续向管理平台传输高清视频。设备状态、任务进度、异常告警可以通过业务系统上报,需要进一步查看现场时再建立实时音视频连接。
但远程操控也带来了新的要求。
首先,工作人员需要知道自己正在控制哪台机器人,避免设备与控制界面对应错误。
其次,同一台机器人不能同时接收多个操作者相互冲突的运动指令。系统需要明确控制权限,并处理人工控制与自主导航之间的切换。
此外,设备可能部署在不同城市、不同运营商网络下,远程连接不能完全依赖局域网环境。
远程通信解决的是人能否及时看见和控制设备,而真正的多机器人运维还需要任务管理、设备状态监控、权限控制和异常处理机制配合。
对于机器人厂商来说,这些能力需要在产品设计阶段统筹考虑,而不是设备交付后再临时增加一个遥控功能。
三. 从现场画面到运动指令,机器人远程操控如何实现?
远程操控看起来像一个简单的过程:操作人员在屏幕上看到机器人周围的画面,再通过摇杆、键盘或控制界面让机器人移动。
但从技术实现看,它至少涉及两条通信链路。
一条负责将机器人摄像头采集的画面实时传回操控端,另一条负责将操作者的控制指令发送到机器人。
这两条链路传输的数据不同,对延迟、可靠性和带宽的要求也不同。
联想 MC 接入的声网远程操控解决方案,采用 RTC 实时音视频与 RTM 实时信令相结合的方式,为上述通信需求提供支持。
1. RTC:现场画面需要及时、连续地传回来
机器人远程操控首先需要解决的是现场可视化问题。
机器人通过摄像头采集视频,经过编码、网络传输和操控端解码显示后,工作人员才能看到现场。
这条链路涉及视频采集、编码、网络传输、解码和渲染等环节。任何环节出现较大延迟,都可能影响最终的操作体验。
对于普通视频监控而言,画面稍有滞后可能仍然能够满足事后查看或一般观察需求。但如果工作人员需要根据视频判断机器人下一步该向左转还是向右转,延迟带来的影响就更加直接。
例如,机器人以每秒 1 米的速度移动,假设操作者看到的画面比现场晚了 500ms,那么在这段时间内,机器人可能已经向前移动约 0.5 米。
这个计算只是用于说明视频延迟与运动距离之间的关系,不代表联想 MC 的实际运行速度或测试结果。
在双方合作中,声网 RTC 承担实时画面传输能力。根据声网公布的方案指标,其端到端音视频延迟可稳定低于 200ms,全球延迟达标率达到 99.9% 以上。
实际部署时,机器人端的视频采集、编码配置、网络条件和操控端性能仍会影响最终效果,因此需要针对具体设备进行端到端测试。
2. RTM:控制指令既要及时,也要考虑可靠性
视频解决的是操作者能否看清现场,RTM 解决的则是控制指令如何传达到机器人。
例如,工作人员通过控制界面发出向前移动、左转、停止等操作,系统需要将这些指令发送到设备端,再由机器人控制系统决定如何执行。
与视频数据不同,运动控制指令通常数据量不大,但对时效性的要求很高。
特别是连续移动类指令,如果机器人收到的是已经过期的操作信息,就可能出现操作者已经松开摇杆,设备却仍在执行之前运动指令的情况。
因此,在设计远程操控协议时,需要区分两类指令。
一类是持续更新的运动指令。例如摇杆方向、移动速度和转向角速度。这类指令通常更关注最新状态,需要结合指令序号、时间戳和超时机制,避免旧指令积压后继续执行。
另一类是需要明确处理结果的关键指令。例如任务启动、模式切换、控制权移交等。对于这类操作,系统通常需要考虑可靠送达、执行确认、重复指令处理等问题。
声网 RTM 提供低延时、高可靠的实时信令传输能力,可根据业务需求选择适当的消息传输方式。
在联想 MC 的合作方案中,声网公布的控制信令延迟指标为 100ms 以内,全球网络延时中位数为 76ms;在 70% 丢包的极端弱网条件下,方案具备高可靠信令传输能力。
需要注意,消息成功送达到机器人,并不代表机器人已经执行完成。因此,机器人业务系统仍需要设计必要的状态反馈和执行确认机制。
3. 远程控制不能只追求低延迟,还要处理失联风险
远程操控机器人,与远程控制一个普通软件界面不同。
软件操作出现延迟,通常只是影响使用体验;但机器人是会移动的实体设备,错误或过期的控制指令可能导致设备碰撞障碍物,甚至影响周围人员安全。
因此,实时通信必须与机器人端侧的安全控制配合。
例如,机器人在远程控制模式下,如果连续一段时间没有收到有效运动指令,设备应当能够根据预设规则减速、停止或进入安全状态,而不是无限期执行最后一次收到的移动命令。
当通信连接中断、控制权限发生变化,或者设备检测到危险障碍物时,也需要由本地控制系统进行安全处理。
对于采用自主导航与人工远程接管相结合的机器人,还需要明确两种控制模式的优先级,以及什么时候允许从人工控制切回自主模式。
这些属于机器人远控系统需要考虑的工程设计,并非声网 RTM 单独能够解决的问题。
声网负责提供实时音视频与信令传输能力,机器人厂商则需要结合自身运动控制系统、传感器及安全策略,完成端侧控制闭环。
四. 机器人持续移动,远程操控如何应对网络变化?
相比固定安装的摄像头或工业设备,移动机器人的网络环境通常更加复杂。
一台机器人可能从室内 Wi-Fi 覆盖区域进入室外道路,也可能经过信号较弱的建筑入口、楼梯间或地下空间。
即使机器人始终使用同一种无线网络,移动过程中也可能遇到信号遮挡、带宽波动、网络拥塞等问题。
对于远程操控,这些变化会同时影响视频和控制指令。
视频传输需要持续占用一定带宽。如果网络吞吐能力下降,仍然坚持较高分辨率和码率,可能导致画面卡顿、延迟累积,甚至无法连续显示。
控制信令的数据量虽然较小,但网络丢包或连接异常仍然可能影响指令到达时间。
因此,视频和信令通常需要采用不同的传输策略。
1. 视频优先保证可用性,而不是始终追求最高画质
在网络状况良好时,操作者可以通过较清晰的实时视频观察机器人周围环境。
当网络带宽下降时,系统则需要根据实际情况调整编码码率、帧率或分辨率,尽量避免视频延迟持续累积。
声网 RTC 具备网络自适应和抗弱网传输能力,能够根据网络状态动态调整音视频传输参数。
根据声网公布的技术资料,其方案在最高 80% 音视频丢包的极端弱网测试条件下仍具备相应抗丢包能力。不过,这不意味着所有网络条件下都能保持相同的视频质量和操控效果。
在实际机器人项目中,还需要结合运动速度、观察距离和现场环境,确定可接受的视频质量与延迟范围。
2. 控制信令需要避免与视频争抢资源
视频与控制信令对网络资源的需求存在明显差异。
视频数据量大,需要持续传输;控制指令数据量小,却往往对时效性更加敏感。
如果通信方案没有合理处理这两类数据,当视频占用大量带宽时,可能影响控制指令的及时传输。
在联想 MC 的远程操控方案中,RTC 与 RTM 分别承担实时音视频和信令通信职责。
声网通过 SD-RTN™ 全球实时传输网络、智能路由调度和抗弱网能力,为跨地域的实时连接提供支持。
不过,通信链路是否稳定,还受到无线信号覆盖、机器人终端性能及当地网络基础设施等因素影响。
如果设备进入完全没有网络覆盖的区域,仅依靠传输优化无法保证远程控制继续进行。这种情况下,机器人必须能够依靠本地控制系统采取安全措施。

五. 从联想 MC 看机器人远程操控的实际价值
联想 MC 的案例说明,机器人行业应用并不只取决于设备能否独立完成某个动作。
轮足结构让机器人能够适应更多复杂地形,自主导航和任务调度让设备可以在一定条件下独立作业,而实时通信则为工作人员提供了远程查看和操作设备的手段。
三者承担的职责不同,但在实际业务中需要相互配合。
对于园区巡逻,工作人员可以在需要时远程查看现场、调整观察位置,并处理部分异常情况。
对于物流转运,远程控制能够在机器人无法继续执行任务时,为工作人员提供一种现场干预之外的处理选择。
对于跨区域设备部署,远程音视频和控制信令则是实现异地操作、远程协助的基础能力之一。
从技术上看,远程操控也不是简单地把一个视频 SDK 和一个消息 SDK 装到机器人上。
真正进入生产环境后,开发者还需要处理画面延迟、指令时效性、弱网通信、控制权限、设备状态同步及断联安全等问题。
此次声网与联想的合作,通过 RTC 与 RTM 的组合,将实时画面回传和运动控制信令接入轮足机器人 MC,为机器人远程操控提供了一个具体实践。

对正在开发机器人产品的企业来说,值得关注的不只是某一项延迟指标,而是如何在设备自主作业之外,建立一套能够查看现场、及时干预,并与本地安全控制相配合的远程操作机制。
毕竟,机器人进入真实业务场景后,衡量它是否好用的标准,不只是能否顺利完成预定任务,也包括任务发生意外时,能否及时、安全地得到处理。