云机器人即插即用通信层

最新推荐文章于 2025-11-15 13:59:10 发布

原创最新推荐文章于 2025-11-15 13:59:10 发布 · 955 阅读

22 ·

CC 4.0 BY-SA版权

文章标签：

#云机器人 # 即插即用 # 远程控制 # ROS # WebSocket

一种用于云机器人技术架构的即插即用透明通信层

摘要

云机器人技术范式旨在通过使用云服务来增强机器人的能力，但在研究领域仍面临诸多挑战。目前大多数文献集中于如何丰富特定的机器人功能，而忽视了如何有效建立两个领域之间的通信。我们提出了一种“即插即用”的解决方案，以弥合云与机器人应用之间的通信鸿沟。所提出的解决方案基于成熟的WebSocket技术，并可扩展至任何基于ROS的机器人平台。本工作的主要贡献在于定义了一种可靠的自动连接/自动配置机制，并构建了一个可扩展的通信层，允许多个用户对多机器人进行有效控制。该“即插即用”解决方案在仿真和真实场景中均得到了验证。在第一种情况下，通过在五台机器上运行的机器人操作系统（ROS）节点模拟用户和机器人的存在。在实际场景中，三名非专业用户通过所提出的通信层及不同的网络协议，同时远程操作三台远程机器人。结果证实了系统在多个层面的可靠性：启动时（成功率_为= 100%）；在高频率通信期间（丢失消息_为= 0 %）；在执行开环螺旋轨迹方面相较于类似工作有所提升；以及在同时远程操作的质量方面。

关键词 ：云机器人技术；系统架构；远程控制；远程操作机器人

1. 引言

在过去几十年中，机器人技术解决方案已应用于多种现实问题，涵盖无人搜救、医疗保健和医疗应用等多个领域。一方面需要提升机器人平台的自主能力，另一方面则需要对这些平台进行控制，采用远程操作方法。正如[4],所述，许多机器人系统基于互联网，通过适当的通信架构和网络基础设施实现远程操作。近年来，电信基础设施的持续改进以及云计算技术的快速发展催生了一个新的研究分支，即云机器人技术，该技术利用云计算解决方案来增强机器人的能力。云机器人技术范式可以定义为“云计算与机器人技术的结合”[5]。这一概念“并非指一种新型的机器人，而是指机器人访问和存储信息的方式”。最近，云机器人被定义为“任何依赖网络中的数据或代码的机器人或自动化系统”，支持其运行，其中并非所有的感知、计算和内存都集成到单个独立系统中[6]。如今，云机器人技术解决方案已应用于不同的应用[7–9]。

除了这些特定应用外，一些研究致力于定义和实现物理机器人与云基础设施上托管的虚拟资源之间通信与交互的架构[10–14]。尽管已提出多种解决方案，但针对不同网络上的代理（即从用户界面到移动机器人平台及其反向）之间的双向通信问题，往往未被充分解决或被低估。虚拟专用网络（VPN）通常被引入作为解决可见性问题的操作方案，但这并未考虑在虚拟网络中对每个代理进行配置所需的工作量。

本文旨在描述一种“即插即用”通信层，该通信层与构成系统的硬件无关（在集成新硬件时无需额外配置），并能在任何情况下保证一组机器人由位于机器人网络外部的代理（例如用户界面）进行远程控制时的稳定性。与VPN配置类似，“即插即用”解决方案依赖于配置方法，而非新软件的实现。选择这一方案的理由在于：旨在利用现有成熟技术构建一个可靠的系统。本文展示并描述了一种将电信网络领域的技术应用于机器人技术领域中的使用案例，这可能为机器人技术社区提供一个有趣的视角。提出的方法基于以下几点：

WebSocket协议，允许全双工客户端‐服务器通信，解决了双向可见性问题；
反向隧道，这是一种与远程设备建立连接的流行技术；
端口重映射，用于在专用端口上自动请求连接。（为了管理多个参与代理的存在，设备与端口之间关联的信息存储在中央服务器上。）

因此，我们的工作所解决的挑战是定义一种可靠的自动连接/自动配置机制，并设计一个可扩展通信层，以实现多个用户对多个机器人的有效控制。

2. 相关工作

云机器人技术为将密集计算从机器人端迁移到云计算基础设施提供了一种高效解决方案。在文献中提出的多种基于云的应用中，代理（即机器人和云资源）之间的双向可见性和通信挑战常常被低估，或依赖于非“即插即用”解决方案（如VPN）。此外，在[11],中，作者提出了计算卸载的三个挑战：1. 传统方法未考虑网络化云机器人技术（NCR）的特性（例如，异构性和机器人协作）；2. 它们未能捕捉机器人流式工作流（RSW）中任务的特性（例如，严格的延迟要求和变化的任务语义）；3. 它们未考虑云机器人技术中的服务质量（QoS）问题。

在上述论文中，提出了一种面向服务质量的机器人流式工作流分配算法，用于网络化云机器人，该算法联合优化延迟、能效和成本，同时考虑了机器人流式工作流和网络化云机器人技术的特点。由于关注的是网络化机器人（即代理属于同一网络），因此未将代理的可见性问题纳入需解决的问题之中。同样，在[12],中，作者聚焦于云资源的管理，论述了多机器人系统在近实时访问云并获取资源方面存在的技术挑战。文中提出了一个构建云机器人系统的通用框架，并对相关问题进行了形式化描述。

作为斯塔克尔伯格博弈，提出了一种带有证明的最优解。随后定义并评估了QoS标准，但未描述在云和机器人资源之间建立连接的操作方法。在[13],云机器人技术被称为“机器人领域最有前景的应用之一”，但由于与安全与隐私相关的风险，其发展仍低于预期。因此，本文聚焦于基于云的机器人服务的安全性，阐述了一个框架，该框架使用椭圆曲线密码学(ECC)提供认证与密钥协商，以访问托管在云中的机器人服务。然而，尽管在抵御各种安全攻击方面取得了有趣的结果，但并未详细说明不同网络中代理之间的双向通信基础设施。

在[14],中，作者旨在通过提出“机器人云”的概念，将信息世界与物理世界融合，从而结合机器人技术和云计算的优势。为了实现这一目标，他们设计了一种新型的机器人云架构，并采用面向服务的架构(SOA)来使机器人云中的功能模块更加灵活、可扩展和可重用。具体而言，在功能层面，通过定期发送HTTP请求（即轮询）到调度服务，并以XML格式接收响应中的命令，来获取最新的指令，这与大多数SOA应用的做法类似。然而，可以论证并证明，由于命令频率较高，轮询方案对于低级别远程控制（如遥操作）并不可行。此外，持续的请求可能会导致带宽使用过载。聚焦于“机器人端”，已有多个框架被提出以促进机器人应用的开发，但机器人操作系统（ROS）[15]可被视为机器人的事实标准操作系统。因此，许多研究集中在云‐ROS案例研究上，而非更通用的云机器人。

在[16],中提出了一种基于使用SpaceBrew帮助用户在远程主节点环境下使用ROS的框架[17]。SpaceBrew被定义为“一种用于编排交互空间的开放、可动态重新路由的软件工具包”。可通过基于 Web的可视化交换板将发布者与订阅者相互连接或断开。然而，SpaceBrew提供的文档仍在开发中，尚不清楚其是否请求或管理代理之间的可见性。此外，在[17],中提出的架构存在一些局限性，但未加以讨论，例如“无法在同一个网络中连接两台计算机使用SpaceBrew”。而且，所呈现的结果仅限于定性分析。

在[18],中提出的工作将ROS包封装为云虚拟机中的Web服务，并设计基于Web服务技术的中间件作为整个云机器人系统的核心。该中间件负责解析云机器人任务请求并在分布式网络中调度ROS节点。通信基于代理虚拟机实现，所展示的结果仅限于单个机器人，作者声称多机器人的情况将在后续研究中考虑。

在[19],中，作者提出了一种面向云机器人技术的软件云架构，该架构旨在用于云计算环境中的三个子系统：中间件子系统、后台任务子系统和控制子系统。该架构调用了云计算、云存储以及其他网络平台等云技术，并借助聚合基础设施和机器人共享服务（例如机器人操作系统（ROS））进行组织。论文中提到了双向通信，但并未详细说明其实现方式。此外，所提出的架构基于ROS多主控FKIE[20],，其要求系统中所有代理之间具备双向可见性。

RoboEarth[21]是云机器人技术领域最重要的欧洲资助项目之一，专注于独立于特定机器人硬件的数据的收集、存储和共享。通过RoboEarth项目开发了Rapyuta云引擎[22]，该引擎基于 WebSocket协议，以确保数据流的双向性，但RoboEarth和Rapyuta均未详细说明代理之间的可见性要求。此外，案例研究也未涉及从远程用户到机器人的转发控制分析。如今，Rapyuta是一家公司总部位于东京[23],并提供企业级的云机器人技术框架。然而，目前仍仅限于早期开发者计划。

自2010年代初以来，rosbridge协议被引入。它是一种用于向ROS（理论上也可用于任何其他机器人中间件）发送基于JavaScript对象表示法(JSON)命令的规范。该规范与编程语言无关，且具有传输无关性。其理念是，任何能够发送JSON的语言或传输方式都可以使用rosbridge协议并与ROS进行交互。该协议涵盖了订阅和发布话题、服务调用、获取和设置参数，甚至消息压缩。基于rosbridge协议，已开发出多个教程和应用[24–27]。其中，机器人网页工具[28]是最成功且应用最广泛的实现。

自2012年正式推出以来，机器人网页工具项目作为开源社区取得了巨大发展，实现了异构机器人系统、设备和前端用户界面之间前所未有的互操作性和可移植性。机器人网页工具的核心是rosbridge协议，它作为一种通用的消息传递机制，采用适合广域网的客户端‐服务器模式，支持通过现代网页浏览器实现全球范围的人机交互。另一方面，尽管rosbridge库提供了JSON<‐>与ROS之间的转换功能，但其传输层需依赖其他组件实现。这一问题可通过使用rosbridge服务器来解决，后者提供WebSocket连接。通常情况下，rosbridge服务器在机器人平台本地运行，从而允许从外部通过rosbridge协议访问 ROS话题和服务。然而，这要求机器人设备对外部可见，而这一条件往往难以满足，特别是对于运行在无线局域网中的平台而言。

2017年，一项新协议在[10]中被提出，旨在将支持机器人操作系统（ROS）的机器人与物联网集成，理由是通过互联网监控和控制机器人时缺乏ROS功能。实际上，所提出的协议与rosbridge协议非常相似；测试仅限于少数模拟机器人，并且通过远程服务器发送命令以开环控制执行螺旋轨迹所获得的结果并不理想。

我们工作中开发的解决方案旨在赋予一组使用ROS框架控制的通用机器人远程控制能力。如前所述，rosbridge服务器提供了一个可在本地机器上运行于ROS框架之上的层，通过rosbridge协议为本地机器外部通信提供接口。因此，本文提出的问题可以描述为：定义一种方法，使用户能够从一个设备（智能手机、平板电脑、笔记本电脑或台式电脑）远程控制任意选定的机器人（从一个未明确限定的集合中选择）。受控机器人和控制设备位于不同的私有网络中；换句话说，机器人与用户设备之间没有可见性。

本段描述的当前技术水平总结于表1。

表1. 当前最先进的其他可用解决方案的总结

参考文献	所用系统特性	本工作的局限性
[11]	感知服务质量的机器人流式工作流分配算法	未包含代理的可见性问题
[12]	问题被形式化描述为斯塔克尔伯格博弈	没有描述在云和机器人资源之间建立连接的操作方法
[13]	提供云和机器人资源之间的连接资源	双向通信基础设施用于不同网络中的代理未详细说明
[14]	最后通过发送HTTP获取的命令定期请求（即，轮询）	轮询解决方案对于低级别的远程操作不可行控制（如遥操作）
[16]	基于使用SpaceBrew	目前尚不清楚是否请求了代理之间的可见性或由SpaceBrew管理。论文中提出了一些限制但未进行讨论
[18]	基于代理虚拟机器	列出的结果仅限于一个机器人
[19]	基于云环境中的三个子系统：中间件子系统，后台任务子系统和控制子系统	基于ROS多主控FKIE[20],，其要求系统中所有代理之间具有双向可见性在系统中
[21]	基于WebSocket协议以确保数据流的双向性	代理之间的可见性要求未详细说明。仍在早期开发者计划中受限
[10]	新协议，类似于rosbridge协议	测试仅限于少量模拟机器人
已提出系统	基于WebSocket通信的方法，反向隧道和端口重映射根据存储在中央服务器上的信息。能够管理代理之间可见性的缺失

3. 系统描述

所提出的系统为涉及多用户多机器人的基于云的机器人场景实现了一个通信层。由于技术种类繁多，需要实现异构设备（例如智能手机、平板电脑、计算机）与不同种类机器人之间的互操作性。此外，通信机制应保证实时性能，以增强用户与机器人交互的用户体验，即使在远程操作时也是如此。

系统的配置如图1所示。该系统由一个中央服务器组成，即托管在云服务基础设施上的虚拟机，具有静态公网IP，支持通过安全外壳协议（SSH）配置实现网关端口映射1。我们在SSH配置文件中显式设置了GatewayPorts参数。关于[29],所述的架构，云资源是一台在FIWARE上运行的Linux虚拟机[30],，其上部署了LAMP服务器（Linux Apache MySQL PHP）。系统中引入的机器人平台基于 ROS中间件进行本地控制。在每个机器人上，均运行有rosbridge服务器[31]和ROS网页视频服务器[32]，以允许在默认端口上接收传入连接，其中一个由rosbridge协议处理[33]，另一个专用于通过视频服务器进行视频流传输。由于涉及多个代理，LAMP服务器上实现了数据库，将每个机器人映射到一个端口号。该端口号定义为机器人网络硬件的MAC（媒体访问控制）地址，因其是唯一信息，可用于标识机器人。此策略保证了系统的灵活性，因为任何基于ROS的机器人只需将其自身信息保存到数据库中即可集成到该场景中。人类用户可通过运行在中央服务器上的网页，从任意设备远程控制机器人平台。

基于此配置，每个代理（用户或机器人）可以位于不同的私有网络中，而只有具有静态公网IP地址的服务器才能从外部访问。系统中各元素之间的双向可见性如以下段落所述得以实现。

1 在文件 /etc/ssh/sshd_config 中应明确设置 GatewayPorts yes。

示意图0

3.1. 机器人端口转发配置

在启动阶段，机器人可以通过执行“反向SSH隧道”来连接服务器。该技术是一种替代虚拟专用网络（VPN）的策略，可安全访问位于防火墙后的远程服务器。在本研究中，机器人会自动查询与其 MAC地址相关的专用端口（用于rosbridge控制和视频流）的数据库记录。如果数据库中存在该机器人MAC地址的记录，则从机器人向服务器建立反向隧道。命令序列总结于图2所示的统一建模语言（UML）图中。使用SSH反向隧道克服了双向可见性不足的问题：通信由机器人发起（而非服务器），从而创建一个支持双向通信的隧道。

示意图1

3.2. 用户远程控制

用户远程控制通过托管在公共服务器上的网页进行。用户可以选择使用指定机器人，该选择用于实例化指向服务器IP和数据库中指定端口的rosbridge客户端和视频客户端。因此，通信通过已打开的反向隧道转发到所选机器人。此序列在图3所示的UML图中进行了总结。

示意图2

一旦用户与机器人之间的通信建立，用户可以通过服务器上存储的网页向机器人发送命令。通过专用网页，用户可以接收所请求命令的反馈（例如，视频流、执行速度）。

4. 实验

本文中，开发了五个实验设置来研究和验证所提出方法的可靠性和有效性。具体而言，进行了定制实验以验证以下特性：

需求1 (RE1)：启动时自动连接/自动配置的可靠性，无需对单个机器执行任何特定操作；
需求2 (RE2)：多个机器人的可扩展性；
需求3 (RE3)：多个用户进行远程控制（例如遥操作）的有效性多个机器人

实验设置根据代理数量（用户和机器人）、网络基础设施和场景的不同而有所差异。对于 [10,18],中描述的研究，用户‐机器人对的数量始终等于或大于三。

前四个提出的实验设置在模拟场景中评估了该系统，其中所涉及的代理（即机器人和用户）通过一台运行多个ROS核心的计算机进行近似模拟。这些测试反映了一种代理数量较多的实际场景（例如，涉及三个以上的机器人）。最终实验设置则还原了一个真实情况，其中包含多个用户与多机器人进行交互。本实验阶段使用的机器人包括两个Astro机器人平台[34]和一个Coro机器人平台[35]。这些机器人均基于SCITOS G5移动平台（Metralabs有限公司，德国）。它们配备了前后激光扫描仪，以实现环境中的安全导航，并安装了用于视频流的摄像头。Astro和Coro平台实现了远程操作服务，允许远程用户向机器人发送速度指令，并接收机器人所在环境的图像。这两个机器人系统均基于ROS框架开发。本节旨在描述不同的实验设置，而结果详见第5节。

4.1. 测试1：启动时的可靠性

第一个测试旨在通过分析图2中所示序列的问题发生情况，验证启动可靠性（RE1）。

使用了五台本地机器，每台机器本地实例化10个ROS核心。通过更改本地端口并运行专用命令，可在同一台机器上运行多个ROS核心。总共设置了50个ROS核心。为每个ROS核心实例化一个 rosbridge服务器。为此特定目的，已更改rosbridge服务器的默认端口，以允许在同一台机器上运行多个rosbridge服务器。程序在Ubuntu系统启动时自动运行。通过所述架构，从远程机器向每个 ROS核心发送一条简单的std_msgs::String消息以测试通信建立，同时已有订阅者运行并等待接收该消息。通过检查所发送消息的接收情况来计算通信建立成功率。测试1重复进行了1000次，每次同时使用50个ROS核心。

4.2. 测试2：高频通信

第二次测试旨在验证涉及高频消息的通信可靠性（RE2）。通过所述架构，使用FIWARE上的服务器（如测试1中所述），从五台机器（用户）向另外五台不同的机器（机器人）以100 Hz的频率发送了100,000个std_msgs::String消息（即每0.01秒发送一条消息，持续1000秒）。订阅者已预先运行，等待接收这些消息。用于评估通信可靠性的指标是数据丢失，计算方式为接收到的消息数量占发送的总消息数量的比例。此外，我们使用iperf[36]评估了通信带宽，并通过Wondershaper [37]限制服务器带宽。测试2重复进行了10次，每次使用五组用户‐机器人对。

4.3. 测试3：不同的网络硬件

在测试1和测试2中，所有机器都连接到相同的网络基础设施。为了使结果不受所用硬件的影响，将测试1和测试2重复进行，并将五台机器的组细分为三个子组：

连接到建筑网络基础设施的机器（固定线路）；
连接到带有4G连接的路由器的机器；
连接到另一个带有4G连接的路由器的机器（同一家电话公司）。

在测试1和测试2中采用的评估指标被用于评估系统的可靠性。这使得可以比较不同场景下的性能。

4.4. 测试4：开环螺旋轨迹

通信层（RE3）的有效性基于[10]中描述的实验进行评估。该实验评估了对Turtlesim机器人（ROS中的默认模拟器）沿开环螺旋轨迹运动的实时控制。螺旋轨迹定义为随时间增加的线速度与恒定角速度的组合。速度指令从五台机器（用户）远程发送至另外五台不同的机器，每台机器均运行一个Turtlesim机器人。

通过所述架构，使用FIWARE上的服务器，如测试1中所述。由于螺旋轨迹对延迟和抖动敏感，因此使用模拟平台的最终位姿作为定性指标来评估实时性能，即沿路径接收到的指令的变化性。测试4重复进行了10次，每次使用五组用户‐机器人对。不幸的是，在[10]未提供网络配置的详细信息。

4.5. 测试5: 同步遥操作的定性评估

之前的实验均在模拟场景中进行，而测试5涉及真实机器人的参与。具体而言，远程遥操作由三名用户同时控制三台不同的真实机器人（RE3）进行评估。该实验扩展了之前[29],中仅考虑单用户单机器人的结果。由于速度指令已在测试4中进行了评估，因此本实验计算了在不同图像分辨率下的性能表现。即，图像质量率被调整为从90%到50%。遥操作实验设置如下所述：

一名位于意大利蓬泰代拉（PI，意大利）生物机器人研究所的操作员控制着位于意大利佩乔利（PI，意大利）辅助机器人实验室的Cororobot；
一名操作员位于意大利蓬泰代拉（PI，意大利）的生物机器人研究所，远程操作位于荷兰弗利辛亨（ZE，荷兰）WVOZorg Ter Reede 居家护理中心的 Astro 1 机器人；
一名操作员位于荷兰泽兰省弗利辛亨的WVO Zorg Ter Reede养老院，控制着位于意大利福贾省圣乔瓦尼罗通多的圣救赎医院内的Astro 2机器人。

示意图3

在测试期间，所有机器人平台和一名操作员的笔记本电脑都连接到建筑物的无线网络，其中一名操作员通过以太网电缆连接，另一名操作员连接到个人4G路由器。网络速度规格通过Ookla网站的速度测试计算得出，结果如表2所示。表2中报告的网络规格可用于评估每个机器人端的连接质量。ping响应时间可用于评估延迟；下载和上传速度提供了评估机器人端性能的附加信息。由于该实验设计，用于评估性能的指标包括以每秒数据包数（pps）和Mb/s为单位的吞吐量。此外，还计算了每个遥操作中心连续接收的数据包之间的平均延迟。使用Wireshark工具分析在专用端口上每个遥操作中心接收到的HTTP数据包。

表2. 网络速度规格

网络名称	延迟（毫秒）	下载 (Mbps)	上传 (Mbps)
蓬泰代拉 (有线)	7	94.41	89.44
蓬泰代拉 (无线)	7	287.77	113.18
蓬泰代拉 (4G)	38	7.13	4.97
圣乔瓦尼罗通多	19	31.13	8.91
弗利辛亨	15	80.07	19.36
佩乔利	31	5.41	5.36
## 5. 结果

所有测试中获得的结果均证明了“即插即用”系统的可靠性和可行性。具体而言，在测试1的每次试验中通信均成功建立（成功率_为= 100%），在测试2中网络未丢失任何消息（消息_丢失 = 0%）。

此外还进行了带宽影响分析。测试2期间，本地机器与FIWARE服务器之间的带宽为39.4 Mbit/s，结果表明，当通过服务器的所有通信总和（即发送至每个代理的通信）小于服务器带宽时，所提出的架构即可正常工作。通信带宽通过分析ROS话题带宽测得。这证实了通过反向隧道进行端口转发不会增加通信所需的带宽。测试3验证了测试1和测试2的结果，表明“即插即用”系统不依赖于网络硬件。

在测试4中，用于评估开环螺旋轨迹的参数包括：额定频率等于2 Hz，初始速度为1.0 m/s，恒定角速度等于1.0 rad/s，线性步长为0.05。结果通过对仿真机器人在开环结束时最终位置的分析得出，共进行了50次测试（测试4重复了10次，每次使用五组用户‐机器人对）。结果表明，所提出的架构能够传输开环命令，并引入可忽略的变异性 σx= 0.001 m，σy= 0.004 m，路径长度为78.275 m。关于 [10],中报告的结果，螺旋轨迹被正确执行。通信层存在的延迟和抖动并未影响性能，这些延迟和抖动在[10],中导致了异常行为，如图5所示。

示意图4

测试5的结果表明，三名操作员可以同时控制三台机器人，而不会经历任何足以破坏其自身体验的显著延迟。通过在遥操作期间测量视频流参数，收集了关于他们体验的定量结果。具体而言，测试了五种遥操作模式，每种模式都具有不同的图像编码质量。图6展示了每个操作员在遥操作中心接收到的数据包大小的比较。正如预期的那样，随着机器人摄像头发送的图像分辨率降低，数据包大小也随之减小。对于Astro 1机器人发送的70%分辨率视频流，记录到一次异常行为，其数据包大小大于80%分辨率的情况。FIWARE与操作员之间交换的平均（µ）pps几乎保持稳定（无线连接为µth= 29.60 pps和 σth= 2.41 pps），但在涉及Coro机器人（以及有线连接）的实验中，pps随图像分辨率变化（µth= 10.80 pps和 σth= 4.55 pps）。图表中报告的吞吐量是通过计算在一定时间内发送的http数据量得出的。因此，它受到机器人端和操作员端网络速度的影响。由于上述原因，通过Coro摄像头（使用有线连接）记录的图像的吞吐量值极低。如图6右下角的图表所示，在4G连接的情况下，连续数据包之间的延迟最为显著（在视频流最高分辨率情况下高达190毫秒）。4G连接的显著延迟既源于4G连接的高ping值（见表2），也源于机器人端较低的上传速率，该机器人位于圣乔瓦尼罗通多，如图4所示。

示意图5 ，平均每秒数据包数 (b)，平均吞吐量 (c)，平均延迟 (d)。)

6. 讨论

提出云机器人技术架构的开发动机在于需要一种可靠的解决方案，以允许将新代理加入系统，而无需对本地机器进行任何特定配置。术语“即插即用”指的是系统的两个主要特性。首先，可以通过在数据库中添加一条新记录，轻松地将新的机器人平台集成到系统中。这种策略使得非技术人员能够轻松更改系统配置，并且也可以远程完成。因此，可以灵活地增加或减少系统中的代理数量。第二个特性涉及架构中所包含的技术元素类型。该开发依赖于成熟且可靠的技术，例如LAMP服务器、WebSocket、SSH反向隧道、rosbridge协议和服务器。与其他现有方法相比，双向可见性问题已被转化为“配置问题”，而非“实现问题”。由于引入了rosbridge技术，无需引入新的代码或通信协议来解决所述问题。

第4和5节中报告的实验与结果证实了所提出方案的可靠性与有效性。一方面，模拟场景验证了通信层在涉及大量代理（测试1和测试3中的50个ROS核心）以及交换大量消息（测试2和测试3中的100,000条消息）时的稳定性。另一方面，实际场景中的实验表明，由于存在更多挑战（这些挑战在模拟场景中被忽略），该方法在具体代理上的应用具有更高的效率。基于云的应用的性能常常受到网络故障、带宽波动的影响，从而导致机器人移动不规则[11]。在两种类型的场景中测试通信层，为其实效性提供了明确的证据。尽管我们的系统满足了第4节中详细列出的要求，但仍需指出一些局限性。

一个涉及网络架构拓扑。由于所有通信都通过中央服务器进行，因此形成的配置类似于典型的星型拓扑。这导致所有通信带宽的总和必须小于服务器最大带宽。此外，在机器人重启的情况下，SSH隧道会在机器人关机时中断，并在机器人启动后重新建立。这就要求在服务器上，该端口在此时间段内必须被释放。通过在一定时间内释放端口，有可能处理多个传入请求。在大量代理通过云连接的场景下，通信系统应集成一个规划器，以高效分配可用服务。在本文所展示工作的实际场景中，每个代理直接访问一个专用机器人，因为机器人数量有限。随着网络化云机器人中元素数量的增加，服务规划器的存在变得至关重要。

如前所述，在移动平台场景中，将架构的通信层与代理当前使用的网络解耦显得尤为重要，因为代理可以使用不同的WiFi连接。在操作员端，测试4和测试5的结果证实了所提出方案的可靠性，且不受所使用硬件的影响。在进行的实验中，遥操作中心连续数据包之间的延迟严格取决于网络延迟和交换信息的大小。通信信道的数据速率与数据量之间的权衡可能成为基于云的机器人应用的一个限制因素。这带来了如何定义应保留在onboard（车载）的机器人任务类型的挑战。云机器人技术为密集计算和大量数据的存储提供了方案，但尚不明确哪些类型的信息可以交换，以使接收端（即机器人或操作员端）的延迟最小化。

如[37–39],所述，ROS存在严重的安全问题。在我们的工作中，我们通过为希望访问公共服务器上托管的网页的用户引入认证系统来解决此问题（如图3所示）。该设计选择可以通过集成安全 HTTP和/或启用rosbridge的可选功能来改进。值得注意的是，其中一项协议的改进包括为WebSocket连接提供传输层安全（TLS）支持，以及通过授权机制限制应用程序编程接口（API）调用和可用主题。

在当前的方法中，通过在机器人领域使用成熟的网络策略（例如WebSocket、反向SSH等），实际的双向可见性问题已得到解决。事实上，据作者所知，目前仅有少数机器人技术研究在其工作中采用了这种方法（[4,40]），且涉及的机器人平台数量仍然较少。本工作的一个可能发展方向是通过采用当前的网络技术趋势（例如命名数据网络方法）来改进所提出的解决方案[41]。