基于ROS和QoS的云机器人研究

张 伟，郝丽娜，程红太，高 乾

(东北大学机械工程与自动化学院，辽宁 沈阳 110819)

0 引言

自从“云机器人”这个术语首次由James Kuffner在2010年IEEE humanoid大会上提出来以后[1]，许多云机器人架构和应用被提出。云机器人主要侧重于存储和计算功能，如SLAM、数据存储、抓取规划、导航以及计算机视觉等[2-5]。

Arumugam 等[6]提出了集成Hadoop集群和ROS消息传递框架的云平台Davinci，在Map/Reduce中实现的FastSLAM算法并在地图构建效率和传感器需求方面有显著的改进。Doriya等[7]提出了一个名为Robot-cloud的云机器人系统，通过云为低成本支持ROS的异构机器人提供帮助，但云端不支持多个机器人同时访问同一服务。Mohanarajah等[8]提出了一个基于RoboEarth的开源云机器人框架Rapyuta，通过OpenStack和Docker提供安全的、与ROS兼容的弹性计算环境，帮助机器人减轻繁重的计算负担。但是这些机器人通过WebSockets协议连接到Rapyuta，这与rosbridge类似，它们之间的信息每次都需要转换，并且没有考虑QoS。胡奔等[9]建了带QoS感知的基于ROS的云机器人平台，云端和机器人端使用Jason WebSocket协议进行消息转换，并根据云端/本地转换机制处理QoS的动态变化，但系统仅把请求响应时间(RRT)作为评价Qos的主要因素。杨小桃等[10]组合柔性提出了制造云服务组合的自适应调整框架、自适应调整方法以及提升策略等。

虽然上述的几个云机器人系统可以把机器人的任务卸载到云端，但是对异构机器人的兼容性和网络条件下的鲁棒性仍有待提高。因此本文提出了一种基于ROS并带有QoS调节机制的云机器人系统CloudROS。

1 系统的整体框架

云机器人系统是典型的分布式系统，本文基于ROS分布式框架进行了系统设计。如图1所示，架构中有3种角色：云服务端、机器人端和用户监控端。云端是服务资源的提供者；机器人端是服务的请求者，既可以请求计算服务，也可以把自身产生的数据进行上传共享；用户监控端可以帮助用户监控机器人的运行状态。

图1 CloudROS系统

与其他云机器人系统相比，CloudROS具有如下特点：

a.主节点运行在机器人端。在机器人端运行ROS主节点，可以对机器人端的ROS节点和属于该机器人的云端服务节点进行统一管理，即使云端服务节点异常退出时，机器人仍可以在不使用云端服务的情况下提供基本功能，并在网络恢复时提供高级功能。

b.云端服务以ROS节点的形式提供。ROS节点间通信方式非常适合分布式架构，本地和云端建立以话题为基础的节点通信，避免了数据通信的格式转换。另一方面，ROS系统集成了丰富的开源算法包，能够实现机器人应用服务的快速部署。

c.云端/机器人端的切换机制。由于云端服务依赖网络通信质量，所以当网络质量较差的时候，基本的数据传输无法保证，那么云端服务也无法保持正常运行。所以此时系统自动切换到本地预先设置的基础服务以保证机器人基本功能的运行，并且当网络质量恢复后，机器人端重新请求云端服务。

d.QoS调节机制。云端服务的动态性能同时受网络条件(网络延迟、带宽等)和计算复杂度的影响，即使云服务正常运行时，也存在服务质量等级的划分，CloudROS系统中建立了QoS的调控机制，对网络因素和计算复杂度进行综合监控，并且根据QoS监控结果进行动态调整来保证计算服务度匹配网络条件，从而保证云端服务正常运行。

2 系统的实现

2.1 计算环境和平台

为了确保系统安全性和稳定性，云端服务节点应运行在独立的容器中。选择Docker容器作为CloudROS的计算环境，与其他虚拟化技术相比，Docker容器处于应用程序级别，不需要虚拟化完整的操作系统，就像在主机上运行的进程一样[11]。

2.2 基于REST API的本地-云端接口

机器人端采用REST API请求云端服务。在CloudROS中，把封装好的云端服务和操作放入不同的URI中，客户端通过REST API接口获取云端服务。

云端计算服务URI可以表示成如下的形式：http://server_ip:port/compute///。其中,“server_ip:port”是云服务器的IP地址和云端服务管理器连续监听的端口；“compute”字段表示请求一个计算服务；“service”字段是指由云机器人平台提供的云端计算服务；“action”字段是指控制服务状态的特定动作；字段“token”用于云服务请求时的身份验证。通过以上4个参数就可以在云端找到相应的资源。

2.3 ROS网络的动态拓扑

ROS网络和主节点都位于机器人端，云服务器收到机器人端端请求后，云服务节点想要动态加入本地ROS网络以提供服务，需要将其自身注册到本地的主节点上。因此，双方都需要知道彼此的地址。ROS支持分布式主机和网络，可以使用环境变量(例如ROS_MASTER_URI和ROS_IP)来定位主节点并配置主机。通常，每个主机都使用静态配置，对于动态ROS网络，每个主机仅在需要时配置其自己的环境变量。

为了使云端服务的 ROS 节点动态加入到本地 ROS 网络中，机器人和云端服务端都需要配置相关的ROS环境变量。对于机器人端，需要环境配置文件 bash.rc 中配置 ROS_MASTER_URI 和 ROS_IP。对于云端，从机器人端的 POST请求参数中获取ROS_MASTER_URI。并且在服务节点运行前配置临时的 ROS_MASTER_URI 和 ROS_IP，在服务运行时才会生效；服务关闭时，临时的环境变量也会失效。

2.4 本地端/云端的桥节点

尽管本地机器人和云端服务都遵循ROS标准，但云端服务加入本地机器人ROS网络需要一个桥节点。桥接节点与rosbridge不同，rosbridge用于将消息从ROS协议转换为非ROS协议，而桥接节点仅传递一些重要参数，建立连接后，所有消息均以ROS标准格式传输。

2.5 调度机制

CloudROS旨在为多个异构机器人提供异步并发服务，可以根据需要扩展云服务。机器人可以请求多个服务，并且不同的机器人可以同时请求相同的服务。因此，有必要在云中加入调度机制，以确保其健壮性、稳定性和安全性。调度机制如图2所示。

图2 服务请求和调度工作流程

a.当机器人请求云端服务时，将服务名称、动作、令牌和本地替代服务节点的名称发送到桥节点。

b.桥接节点收到请求后，首先检查网络状况。如果网络较差并且无法保证对云端服务的最低要求，则启动相应的本地服务节点。如果网络状况良好，则桥接节点构造REST URI并向云发起HTTP请求。

c.一旦请求了新的REST URI，云调度程序首先解析URI并提取参数(令牌，服务，动作)。

d.云调度程序检查机器人的权限。如果机器人未经授权或请求超出其权限，则拒绝该请求。

e.授权后，云调度程序检查请求的云端服务是否存在。如果该服务不存在，该请求被忽略。如果该服务存在，则云调度程序检查所请求服务的状态并找到相应容器映像的位置。

f.此信息以及请求的动作被发送到处理功能。如果请求的服务当前正在运行并且动作为“开始”，则该请求被忽略；如果请求的服务未运行并且操作为“停止”，则该请求被忽略；如果请求的服务未运行且操作为“启动”，则初始化容器并启动云端服务节点；否则，调用停止脚本以停止云端服务节点，并且销毁容器。

g.处理后，服务运行状态在数据库中更新。

3 云端服务性能的评估与管理

在此，QoS是基于云端的处理速度和网络延迟以及处理结果的质量来评估的，不确定的网络条件和云端承载、负载变化通常都会影响到最终的QoS值。为了准确地计算QoS，本文对QoS指标进行加权计算得到最终QoS，权重可以由用户根据任务属性指定。QoS监测和调节机制如图3所示。

图3 QoS监测和调节机制

3.1 QoS指标

3.1.1 往返延时

服务延迟由请求响应时间(RRT)来度量，往返延时(RTT)由2个部分组成：网络响应时间和应用程序响应时间。由于云端通常对同一任务具有恒定的处理时间，因此RRT可以用网络响应时间来近似。RTT用于表示网络响应时间，较小的RTT表示较小的网络延迟。RTT评估网络连接的质量，但该指标不可控，不能按需调节。

通过定期“PING”云服务器，可以获得RTT值的统计结果。在CloudROS系统中，定义了2个RTT阈值：Tg和Tb分别表示低延迟和高延迟的临界值。对于RTT影响的Qt的计算描述为

(1)

如果Qt>50%，则处于中等状态; 如果Qt<50%，那就是状况不佳。

3.1.2 数据发布频率

云端服务节点订阅一些数据源主题，并将处理后的结果发布到目标话题上。2个话题都有自己的发布率。rsrc表示源话题的发布频率；rdst表示目标话题的发布频率。rsrc和rdst的平衡对于ROS机器人控制系统非常重要。由于ROS系统中的消息传输采用先入先出(FIFO)队列的方式，如果rdst

(2)

Nqueue为队列的大小。

为了避免引入新的延迟时间，应该尽量保持rsrc和rdst近似相等。而由数据发布频率产生的云服务质量影响为

(3)

对于多个订阅和发布者的情况，客户端可以分配K对话题来评估服务质量。

(4)

其中，最小值作为最终的服务质量的评分。

3.1.3 数据的压缩率

对于图像和点云这样的高带宽消息，为了减少传输和计算复杂度通常使用压缩技术。对于图像，提供了图像传输机制从而将原始消息编码为压缩格式，例如“JPEG”；对于点云，可以应用一系列过滤器(例如Voxel过滤器，Radius离群值过滤器)来减少点数。算法中通常有一个比例因子来控制结果的质量和压缩率。为了协调不同因素的影响，进行归一化处理方式为

(5)

Sbest为质量最好时的压缩系数或者没有压缩时的压缩系数；Snow为当前的压缩系数。

3.2 QoS的计算算法

对于不同的服务，各个指标的优先级不同，最终QoS的值是通过3个指标的加权总和来计算的：

Q(k)=wtQt(k)+wrQr(k)+wsQs(k)

(6)

k为QoS监控频次；wt、wr和ws分别表示RTT、数据发布频率和数据压缩率影响Q值的权重，wt+wr+ws=1，可以通过分配不同的组合来调整QoS。由于时间延迟通常会对控制系统造成严重的负面影响，因此它具有最大的权重。默认配置为：wt=0.6，wr=0.3，ws=0.1。为了减少QoS值的变化，将滑动窗口平均算法应用于Q(k)。

(7)

k表示QoS监控频次，窗口大小为M+1。为了减少QoS的监测和管理难度，将QoS划分为4个应对等级：流畅、中等、一般、极差。如表1所示。

表1 QoS等级划分

当云机器人系统运行时，许多不确定因素可能会影响服务质量，如信号质量差，网络环境拥挤，服务请求拥挤以及服务器负载沉重等，导致QoS动态变化。根据上述规则，可以评估当前的服务质量，采取适当的策略来确保稳定和高质量的服务，具体的调整策略如表2所示。

表2 云端服务动态调节措施

如果QoS Level = 1，表示云端服务处于良好状态。可以实现低延时和高帧率传输。因此，在当前配置下无需进行任何更改。

如果QoS Level = 2，表示云端服务的质量略低，但相对较好。因此，可以适当降低高带宽消息的压缩率，这样仍然可以保持低延迟和高帧率传输。

如果QoS Level = 3，表示云端服务的质量已降低到严重的低水平。因此，为了继续使用云服务，除了降低压缩率之外，还应该降低发布率。该系统将以高延迟，低发布率的状态工作。

如果QoS Level = 4，表示延迟严重，以至于云端服务无法正常工作。在这种情况下，应当切换到相应的本地服务。

4 实验

为了验证CloudROS系统的可行性、有效性和效率，在实物实验平台上进行了本地云连接性和QoS调度机制的性能实验。

4.1 实验平台

实验平台如图4所示，包括1个云服务器、1个移动机器人和1个电脑模拟的客户端。它们之间通过WiFi连接。

图4 实验平台

4.1.1 云服务器

云服务器是一台“高性能”的电脑(与机器人相比)，处理器为英特尔酷睿i7-8700，16 GB 内存，安装了 Ubuntu16.04 和 ROS Kinetic 操作系统，还安装了LXD用于管理Docker容器以及MySQL数据库用于存放容器镜像。

4.1.2 移动机器人

移动机器人采用3个全向轮驱动，并配置了树莓派、双目摄像头、触摸屏、麦克风和扬声器，如图4所示。机器人的每个轮子上都有1个编码器，同时还搭载了1个AHRS惯性传感器，用于估计机器人的里程信息。树莓派控制机器人，并与云服务器进行通信，安装了Ubuntu Mate系统和Hydro版本的ROS。电机控制、里程估计等的低水平任务由Arduino Mega2560完成。Arduino 和树莓派之间的通信使用Rosserial 接口实现。

4.1.3 基准测试任务

在CloudROS系统中，机器人端和云端同时集成了gmapping功能包、pointcloud_to_laser功能包、stereo_proc包等构成本次实验的双目构图服务，如图5所示。双目构图服务具体完成对左右图像的立体匹配、三维提取、点云转激光等一系列操作，最终获取仿激光数据，并且由此构建二维地图。

图5 视觉处理任务

4.2 云服务的连接性和有效性实验

4.2.1 本地服务模式

在本地服务模式中，图像采集和处理都在机器人端完成。本地服务模式下的实验结果如图6所示，其中图6a表示树莓派CPU的占用率，图6b表示源图像数据发布频率和目标仿激光数据发布频率的对比情况。

图6 本地服务模式下的实验结果

由图6a可知：当树莓派独立处理双目图像时，树莓派的CPU占用率达到了80%，表明系统运行压力很大。由图6b可知：当源图像数据发布频率是9 Hz，目标仿激光数据的发布频率小于1 Hz，绝大多数图像在传输过程中丢失。说明本地机器人的计算处理能力低效，机器人无法独立完成计算密集型任务。

4.2.2 云服务模式

在云服务模式中，图像处理任务在云端完成，机器人只负责图像数据的采集。云服务模式下的实验结果如图7所示。

图7 云服务模式下的实验结果

由图7a可知：当云端负责处理图像时，树莓派系统的CPU占用率大约在30%，这表明系统运行 压力正常，系统完全有空闲的资源去完成其他任务。由图7b可知：在图像处理任务迁移到云端的条件下，源图像数据发布频率和目标仿激光数据的发布频率都近似9 Hz，也就是说双目图像任务被高效地完成。实验结果说明将计算密集型的计算任务迁移到云端后，释放了机器人系统的运行压力，同时云端具有更强的计算能力，处理的效果也远比机器人更加稳定高效。

通过比较本地模式和云服务模式下的处理结果，验证了CloudROS系统架构的可靠性和高效性。机器人通过访问云端服务，将计算复杂度较高的任务交由云端处理，提升了机器人的工作性能。

4.3 QoS有效性实验

QoS机制就是为了监控动态网络条件下服务质量并进行服务质量动态优化的。下面将对比不采取动态调整措施和采取动态调整的QoS结果。

4.3.1 不采取调整措施

在不采取动态调整措施的情况下QoS的变化情况如图8所示。

由图8a可知：网络传输速率在第27次和第42次的监控中突然降低，而相应的RTT则有所增加，表示网络在逐步变差，低的网络传输速率限制了高帧率、高质量的数据通信，影响云端的服务处理结果；在第54次监控中网络传输速率恢复到高速率值，而RTT也降低初始值左右。由图8b可知：在第27次监控时仿激光数据的发布频率极速降低到0帧，这说明了数据在网络传输过程中完全丢失；在第54次监控后，也就是网络条件恢复到高速状况时，仿激光数据的发布频率又达到与源图像数据相近值。由图8c可知：在网络变差的过程中，QoS也在逐步下降，说明云服务性能持续下降；而在网络恢复后，QoS也得到了提升，说明云服务性能也得到恢复。

图8 不采取调整措施的QoS实验结果

4.3.2 采取调整措施

之前不采取调整措施的QoS实验证明了QoS的变化依赖网络条件。采取调整措施的QoS实验结果如图9所示。

由图9a可知：网络在第38次、第76次和第122次监控中网络传输速率降低，RTT增加，网络状况逐步下降；从第134次监控开始，网络传输速率逐步提升，RTT逐步下降，网络状况得到持续改善。图9b显示仿激光数据发布频率在第38次监控中突然降低，图9c显示QoS也发生了等级跳跃，降低到等级2的水平，这激发了QoS调控机制。根据表2的动态调整措施，此时的源图像数据压缩比率被动态降低，从而一定程度上降低了计算复杂度。在进行压缩比率调整后，激光数据发布频率恢复到源图像数据相近值，并且QoS也适当得到提升，并稳定在等级为2的区域。虽然采取措施后，牺牲了数据的质量，但是保证了云端对高帧率数据的流畅处理和服务的稳定运行。

图9 采取调整措施的QoS实验结果

图9b的仿激光数据发布频率在第76次监控中再次突然降低，图9c中的QoS同样发生了等级跳跃，降低到等级3的水平。说明此时的调整措施不仅保持低的压缩比率，还要降低数据源图像数据的发布频率，从而更进一步地减少计算复杂度，降低网络中数据传输压力。经过措施调整之后，目标仿激光数据的发布频率得到一定提升并且会稳定在与当前源图像发布频率相近的水平。QoS曲线也同样会得到适当提升并达到一个新的平衡状态。

图9b的仿激光数据发布频率在第122次监控中突然降低到0，图9c中的QoS同样发生了等级跳跃，降低到等级4的水平。根据表2所示的动态调整措施，此时本地服务切换机制触发，云端服务节点关闭，相应的本地服务节点开启。但是根据图6的结果，本地无法处理该双目任务，所以仿激光数据发布频率小于1。在第134次、第136次、142次的监控中，网络服务质量逐渐得到改善，QoS也不断提升。在第134次监控中，QoS升至等级3的水平，说明此时的网络传输能力达到了云端服务的基本要求，此时本地服务节点停止，云端服务节点启动。根据表2，此时源数据的发布频率和压缩比率还是保持一个比较低的水平。目标仿激光数据发布频率上升。在第136次监控中，QoS升至等级2的水平，根据表2，提高源数据的发布频率，源数据满足高帧率、低压缩比率的条件。经过措施调整后，目标仿激光数据发布频率上升，QoS也得到提升。

通过比较2组实验结果可知，网络条件直接影响了QoS指标且QoS能够反映服务质量。通过QoS动态调整机制一定程度上提升云服务质量，并当在前的网络条件下使QoS稳定运行，证明该动态调整机制是有效的。

5 结束语

本文提出的CloudROS云机器人系统在引入授权，安全认证和QoS功能的同时，尽可能保持ROS规范。所有云服务均作为1个或1组ROS节点提供，这些节点可以动态加入到本地机器人上运行的ROS网络。机器人端只有1个ROS主节点，为云/本地服务交换功能提供可行性并提升了网络断开时的鲁棒性。CloudROS中引入了QoS监测和控制机制，根据不同的QoS状态可以进行动态调整参数和网络拓扑，从而保证了在变化的网络条件下云服务的稳定性和流畅性。实验结果证明，CloudROS云机器人系统可以将机器计算密集型任务卸载到云端并提高整体性能，还证明了QoS机制在监视系统状态和控制系统性能方面的有效性。