1. 研究目的与意义（文献综述）

1.研究目的及意义

机器人研究是一项涉及多学科、多领域的新兴研究，其对于一个国家的工业、农业和服务业等行业的发展都具有十分重要的意义。机器人技术的发展已经成为衡量一个国家制造和科技水平的重要标志[1]。同时机器人的发展可以分为三个阶段：1、示教再现机器人；2、具有视觉、感知以及一定判断能力功能的机器人；3、具备自适应、推理、判断和决策等能力的智能机器人。虽然如今机器人的发展已经进入第三阶段，智能机器人可以满足一部分工业生产和仿真研究需求，但当其处在逼近于真实的复杂环境中，还是存在一些问题，例如：当机器人本身不能提供足够的计算资源时，执行一些性能较好的算法会降低机器人系统的整体使用效果；机器人无法提供自主适应环境变化的能力等问题。

云计算（Cloud Computing）是在分布式计算（Distributed Computing）、网格计算（Grid Computing）、并行计算（Parallel Computing）等发展的基础上提出的以Internet为服务方式，并提供动态可伸缩的虚拟化的一种新型计算模型[2]。由于云计算能够为使用者提供丰富的计算资源，所以云计算十分适合对大数据进行处理，这也使得越来越多研究人员试图将智能机器人与云计算相结合来解决上述问题。

机器人与云平台相结合在现在看来已经不是陌生而又遥远的事情，早在2010年，“云机器人”[3]一词首次被提出并出现在公众视野中，这是来自卡耐基梅隆大学的James Kuffner教授在Humanoids 2010会议上，抛出的机器人与云平台相结合的概念。云机器人不仅可以将复杂的计算任务传递至云端处理，还可以分享信息和技能。较之传统机器人，云机器人的优势是存储与计算能更强，学习能力更强，机器人之间共享资源更加方便。

但研究人员发现，在智能机器人和云机器人的研究之中，通信机制都是机器人软件开发的重点与难点[4]。受通信机制的影响，机器人所采集的数据在传输过程中往往出现实时性不高、无法适应工作环境（网络环境发生变化）等问题，因此无法保证机器人动作执行的准确、高效，这也使得机器人在商用领域的开发、使用受到了限制。因此，如何充分利用云计算资源解决机器人数据传输的实时性问题是机器人研究的发展趋势。

在归纳总结当前社会需求以及机器人相关技术研究后，提出现阶段云机器人存在问题如下：

1.目前 pub/sub 模型自身并不提供适应性。机器人在运行时可能遇到网络不稳定的情况，但由于pub/sub模型无法判断当前网络情况，所以会导致数据无法发送的窘境；

2.从程序开发人员的角度出发，可以发现使用者必需掌握特定的开发语言才能在特定的平台上进行开发，这种方式已经过时。这使得更加智能的解释性语言在新平台上的普及是必要的；

3.机器人平台的处理性能相比于强大的云平台，计算量十分有限。因此面对AI-based的信息处理(比如图像、声音和视频)等非构造性数据，借助云平台的计算是必需的；

综合上述研究背景以及提出的问题，本次研究具有如下意义：我们将通过使用python、Kafka消息系统和云平台，开发一套自适应流框架。当机器人运动至网络延时较大的工作环境中，我们的流框架能够进行自适应，动态地选择将数据传输至本地或云端，并提高数据传输的实时性。通过使用易读、易维护的程序设计语言python进行系统设计，让使用我们框架提供的API的开发人员，能在不使用ROS的前提下，对机器人内部嵌入的传感器集群进行数据的采集和分析。同时自适应策略与云平台相结合的方式，使得机器人能够根据计算需求，在云和其本身之间自主选择合适的计算位置提供服务，从而真正的为用户提供更优越更快捷的实时处理和高效的智能服务，并在此过程中用户不需要知道计算在何时何地发生。当然我们的计算平台还可以根据用户对移动机器人的需求进行可视化服务定制；研究人员同样可以根据自己的需求在我们的平台上扩展API接口，并向第三方提供自己的算法接口。

2.相关技术研究现状

2.1云机器人的平台架构

在开发独立机器人的同时，很多研究者注重平台架构的研究。由于研究者的思维理念大有不同，故出现了很多不同的平台架构。本文将按时间顺序分别列举三个具有代表性的云机器人平台架构。

2010年R. Arumugam提出了达芬奇架构（Distributed Agents withCollective Intelligence）[5]。该架构将云平台作为主节点进行通讯，通过HTTP协议对传输数据进行封装；当节点接收到数据之后，通过开源Hadoop分布式文件系统进行数据处理，最终处理结果将被反馈至机器人。达芬奇架构是基于ROS系统构建的，因此其对于ROS高度依赖，所以该架构在非ROS系统的机器人中进行数据传输是十分困难的。虽然达芬奇架构可以实现数据在云端进行计算，但数据传输受Hadoop生态体系的影响，这也使得云平台信息反馈的实时性较差。

图2.1DAvinCi架构示意图

2011年Markus Waibe等提出了RoboEarth，一个专门为机器人服务的网站。RoboEarth类似于一个巨大的网络数据库，机器人可以通过网络连接至RoboEarth完成知识共享，相互学习等操作。RoboEarth的出现让云机器人不再是一个概念，由于多机器人可以在网络中共享数据，这也使得机器学习更加高效；得益于该架构的数据支持，机器人可根据先验知识完成未提前设定的任务；开发人员在多次使用该架构后，RoboEarth能自动记录相关操作，这也使得新机器人在初次连接RoboEarth时能很快地学习到相关知识，提高工作效率。其体系结构如图所示。

图2.2RoboEarth工作原理图[6]

RoboEarth通过构建以“服务器层”为核心的体系结构，来完成数据的传输，但由于“服务器层”中数据库接口类型多样，开发人员在不熟悉数据库接口类型的情况下，很难快速找到对应的数据库接口，因此无法保证机器人在数据传输时的高效性。虽然RoboEarth最早实现了“云机器人”这个概念，但是它并未真正使用云计算资源。

2011年，SATO M等提出了UNR-PF（Ubiquitous Network RobotPlatform）[7]。UNR-PF架构利用云平台中的机器人服务来满足人类的日常生活[8]。该平台架构主要有两类平台组成：整体平台和本地平台。通过将两类平台相连接，可以为机器人提供更好的响应、处理速度以及丰富的功能。但其缺点明显，机器人想要连接UNR-PF平台获取资源，必须先搭建好本地平台，且机器人与本地平台属于一一对应的关系。由于整体平台和本地平台属于一对多的关系，使得不同机器人在首次使用该框架时需要重复进行本地平台的搭建。同时该框架对网络要求较高，在网络环境较差的情况下无法为机器人提供相关服务。

表2.2 平台架构对比表

通过对上述三个已有的云机器人平台架构进行对比分析，我们可以发现： 虽然UNR-PF框架摆脱了ROS的束缚，并且能够充分利用云计算资源，该架构对我们设想的流框架具有一定的借鉴意义，但由于该框架对使用环境要求较高，并未提及具有适应性，所以构建我们的自适应流框架为移动机器人提供自主适应环境变化的能力是必要的。

2.2 发布/订阅通信模式研究现状

2.2.1发布/订阅通讯模型

发布/订阅通讯模型主要分为两种：基于内容的发布/订阅模型以及基于主题的发布/订阅模型。基于内容的发布/订阅模型是通过对其发布的信息进行标记，赋予发布信息一组属性/值对；当节点向系统提出订阅时，该订阅信息转化为属性上的谓词；当谓词与发布信息中的属性相匹配时，则该系统完成消息的发布订阅。在基于主题的发布/订阅模型中，发布者没有直接的与订阅者进行信息传输，属于一对多的信息传输模式，发布者在发布一条带有特定主题的信息后，订阅该主题的订阅者都会收到消息。从上述的原理来看，基于主题的发布/订阅模型较之基于内容的发布/订阅模型要简单得多。

Pub/sub模型最早的论文是1987年K. Birman提出的在分布式系统中虚拟同步环境的构建[9]。该模型可让应用程序在进行分布式处理时，各部分互不干扰，保证处理的正确性。

在过去30年中许许多多的研究机构都对基于内容的发布/订阅模型进行研究，其难点主要体现在如何实现发布者与订阅者之间的匹配。在一项基于内容的发布/订阅模型研究中，Rosenblum提出可以通过对传输数据进行计算得出相应的谓词从而实现订阅，减少对数据属性进行计算的复杂度[10]。

2010年Biao Zhang[11]等提出了三种不同的方法（黑盒法、灰盒法以及白盒法），通过这三种不同的方法将基于内容的发布/订阅系统集成到云平台中，在不同的应用需求中使用者可以合理的选择集成方法，以达到在云上部署信息系统的目的。其主要缺点在于并未考虑将信息系统进行分布式部署，而是把整个信息系统放置在云端，这样会增加部署的成本，在机器人处在网络环境不佳的环境中无法进行数据传输。2011年Ming Li[12]等提出了一种基于BlueDove属性的发布/订阅服务，意在通过给订阅者分配大量服务器达到信息高效传输的目的，并通过系统中设定的“性能感知转发”让服务器之间能够均衡地传输数据。

相比于基于内容的发布/订阅模型，基于主题的发布/订阅模型应用更加广泛，如Twitter、流量报警系统、移动设备通信架构等。在基于主题的发布/订阅模型中，Aurenhammer提出了一种负载分配方法，其通过使用一致的散列将通道分布到多个发布/订阅服务器上[13]由于每组通道受相应的服务器负责，所以极大的提升了信息系统的效率。该方法通过对每台服务器设定一组虚拟标识符，而散列的通道将根据虚拟标识符找到最接近的服务器，该操作将保证通道分发的准确性。当出现用户需要添加新服务器时，该方法提供了共享机制，即新服务器可以将现有服务器的虚拟标识符以及该服务器得到的信道进行复制，从而得到相应的数据。若用户需要删除某个服务器时，为保证负载平衡这一条件（即每台服务器负责数量相同的的通道），该服务器会将其拥有的标识符以及通道共享给其余的服务器。该方法存在一定局限，当信道上的负载不平衡时无法进行工作，由于在现实中很难实现负载时刻保持平衡，所以该方法存在很大的不确定性。

2015年Julien Gascon-Samson[14]等人提出了Dynamoth，一款基于通道（主题）的发布/订阅中间件。他是一个完全部署在云平台上的中间件，通过设定特殊的传播机制，来保证该信息系统可以在用户增减服务器时能够稳定的工作，保证信息传输不中断。但由于其完全部署在云平台上，并其具备处理大量数据的能力，但对于本文对于移动机器人的通讯研究来说，该中间件成本过高，性能超出了我们的需求，会造成资源浪费，故该方法不适合我们的研究。

2015年Jingtao Sun[15]等人提出了Mimosa Pudica，一种适用于pub/sub系统中各种变化的自适应中间件。其目的是为了解决现有发布/订阅模型自身不提供适应性、在复杂环境中传输信息易丢失以及传统信息系统中冗余节点等问题。该中间件通过选举领导者进行网络拓扑的管理以及制定策略选择合适的代理为核心概念，进而实现发布/订阅信息系统在复杂环境中的自适应。这篇文章对本文的启发很大，在构建机器人与云平台的流框架时通过设计合适的中间件，能帮助本文构架实现自适应的目的。

2.2.2P2P通讯模型

一、P2P模型的概念

服务器是网络中最容易受到攻击的节点，一旦海量地向服务器发出服务请求，就容易导致服务器瘫痪，以致所有客户都不能得到服务响应，为了解决这种问题，研究人员设计了P2P模型。P2P可以理解为对等互联网，点对点或者端对端。在P2P模型中网络的参与者共享它们所拥有的一部分资源，这些资源通过网络提供服务和内容，能被其他对等节点直接访问，网络的参与者既是服务提供者（server），又是资源获取者（client）。其模型图如下：

图2.3 P2P模型示意图

上面是P2P模型的交互形态，每个节点既充当服务器，为其他节点提供服务，同时也享用其他节点提供的服务。

二、P2P模型的特征

① 非中心化：P2P是全分布式系统，网络中的资源和服务分散在所有的节点上，信息的传输和服务的实现都直接在节点之间进行，可以无需中间环节和服务器介入；

② 可扩展性：用户可以随时加入该网络，系统的资源和服务能力随之同步扩充；

③ 健壮性：因为服务是分散在各个节点之间的，部分节点或网络遭到破坏对其他部分的影响很小，故P2P具有耐攻击、高容错的特点；

④ 自治性：由于节点来自不同的所有者，不在全局的控制，节点可以随时退出和加入；

⑤ 高性价比：计算机的任务或资料分布到所有节点，达到了高性能计算和海量存储的目的；

⑥ 隐私保护：用户的信息被分散到各节点间，降低了用户信息的泄露；

⑦ 负载均衡：由于每个节点既是服务器又是客户端，减少了传统C/S模型中对服务器计算能力、存储的要求，将这种要求分布在各个节点上。

三、相关研究

2011年Yuichi Ogata[16]等人提出了一个基于JXTA Overlay的知识共享P2P系统，该系统意在为多机器人框架提供服务。由于P2P系统是独立于网络的，具有可扩展性，能够在TCP/IP、蓝牙和其他有线和无线技术上进行操作。这也使得其适合作为多机器人协作的通讯系统。

2019年Manh Tien[17]等人提出了一种多机器人制图系统，该系统采用P2P通信协议根据给定的制图或平面布置图解决制图问题和地图分割方法。同时由于在该系统中P2P网络是基于集中式覆盖网络构建的，可扩展并可以将控制命令从基站广播到所有机器人，这也使得机器人可以通过协作进行准确的地图构建。

综合上文对pub/sub模型以及P2P模型的研究分析，可以发现两者存在以下区别：

1、P2P模型中每个消息只有一个消费者，即一旦消息被消费，消息将从消息队列中消失，而pub/sub模型中每个消息可以有多个消费者；

2、P2P模型中发送者和接收者之间在时间上没有依赖性。而pub/sub模型中发布者和订阅者之间有时间上的依赖性，针对某个主题的订阅者，它必须创建一个订阅之后，才能消费发布者的消息，而且为了消费消息，订阅者必须保持运行的状态；

3、P2P模型适合构建同步通信系统，而pub/sub模型适合在工作环境容易变换的场景中使用，由于P2P类似于单链路的结果也使得在数据量较大的场景中较为困难的进行高效的传输工作。

2. 研究的基本内容与方案

3.设计的基本内容、目标、拟采用的技术方案

3.1基本内容和目标

论文所要进行的研究的基本内容主要包括以下五个方面：

（1）通过论文阅读，调查分析移动机器人的实际需求以及与机器人功能对应的数据类型，为消息系统开发提供数据基础，同时明确自适应流框架的应用场景；

（2）通过Kafka消息系统与其他常用消息系统的对比，选择适合本文的消息处理系统；

（3）通过使用Docker快速配置Kafka以及Jupyter Notebook，构建数据收集处理的计算平台；

（4）通过设计数据传输处理的API ，并定义复杂环境的特征量，从而实现移动机器人间和云平台间的自适应动态“计算迁移”；

（5）完善程序设计，并通过对提案方式的定量测评来验证提案方式的有效性。

论文研究的目标为开发一套自适应流框架，充分利用云计算的优势为移动机器人提供自主适应环境变化（带宽波动）的能力，提高数据传输处理的实时性，最终通过实验验证自适应流框架的有效性。

3.2机器人介绍以及机器人数据类型定义

本文预计使用未配备ROS系统的小型机器人进行试验仿真，该机器人将搭载RGB-D摄像头、激光传感器以及声音传感器，同时能够在4G环境中运行工作。我们将模拟一个正在作业的物流仓库，该仓库中有一列货架、两条互不干扰的传送带以及三名工人组成，其中两名工人A、B工位固定并且在不同传送带前进行作业，而另外一名工人C允许沿货架进行货物拣选，我们的机器人在其中起到配送货物的作用。在此场景中，机器人将会面临以下情况：1、判断C的位置（定位），避免碰撞；2、进入狭小区域时，网络环境变差；3、语音交互；4、系统更新升级；5、软硬件故障等问题。

图3.1API中自适应方法

结合上图我们将对机器人在生产工作中遇到的情况制定相应的适应性方案。首先以定位功能为例，当我们的机器人在仓库中作业时，由于工作环境复杂且移动速度不能过慢，在这种情况下机器人对强大的定位功能有很高的需求，但受限于自身条件，机器人依靠自身无法十分快速完成地图构建并定位，所以我们的migration方法在此时便能将机器人定位功能传输至云端，帮助机器人进行定位。其次以数据可视化功能为例，由于仓库分布在全球多个地区，仓库管理者时常需要分析各个区域的货物需求量和作业能力，从而制定相应的仓库管理策略，这时候我们的copyas方法可以将机器人收集的数据在各地的云服务器上进行可视化操作，这能让仓库管理者更加直观的对各地区仓库进行任务分配和管理。最后当我们的机器人需要进行系统更新升级时，我们的timer方法可以配合migration方法对系统功能进行移动，帮助机器人完成更新升级。同时在系统更新时，由于我们各地的云服务器会存在系统更新之前已产生的可视化结果，所以我们定义了self_destroy方法会将这些失去有效性的可视化结果进行自毁，释放云端的资源。

同时本节将研究归纳机器人在实际生产作业中，所需要用到的功能及其对应的数据类型。一般机器人在传输过程中，往往会打包传输结构化数据——以json形式为主，还会传递非结构化数据——以图像为主的byte列，还有可能会通过传递object对象实现反射功能，我们在这里定义了3个传递形式。将机器人功能所需数据与这三种形式数据匹配，能保障数据的高效处理。

3.3拟采取的技术方案

3.3.1消息通信机制选择

Apache Kafka[18]是由Linkedln开发的高性能的消息发送和高性能的消息消费的消息引擎系统， 其主要有以下四个特点：

l可靠性：partition机制和replication机制，使消息的传递有着很高的可靠性；

l稳定性：支持集群；

l高性能：高吞吐量，即使在TB的数据存储情况下，仍然表现出很好的稳定性；

l支持消息广播和单播，可以根据重设offset实现消息的重复消费。

3.3.2云平台的选择

下表为国内外主要的云平台。其中根据Gartner 2017年的调研显示，在全球公有云服务市场方面，Amazon EC2（亚马逊云）和Microsoft Azure（微软云）是公有云市场中两大主要供应商，分别占据了47.1%和10%的市场份额，在这两家之后的是Google Cloud（3.95%）和IBM Cloud（2.77%）；根据IDC统计数据显示，在国内公有云服务市场方面，阿里云 2017 年上半年 IaaS 营收 5 亿美元，占据 47.6% 中国市场份额，紧随其后的是腾讯云，营收约 1 亿美元左右，份额为 9.6%[19]，金山云位居第三，营收 6839 万美元，份额 6.5%， 中国电信位居第四，营收 6254 万美元，份额 5.9%。所以在经过多方面的权衡选择，我们将选择在阿里云中进行平台搭建。

表3.1 国内外云平台

3.4环境搭建

3.4.1Docker搭建

Docker是一个开源的应用容器引擎。Docker让开发者可以打包他们的应用以及依赖包到一个可移植的镜像中，然后发布到任何流行的 Linux或Windows 机器上，也可以实现虚拟化。容器是完全使用沙箱机制，相互之间不会有任何接口[20]。Docker具有以下四大特点：

1、更加高效的利用硬件资源；

2、更快速的启动时间，Docker启动为秒级，而虚拟机启动为分钟级；

3、轻松迁移；

4、持续交付和部署。

综上所述，通过使用Docker安装所需镜像，能极大的简化镜像安装过程，即便在不同配置环境中使用Docker中同一镜像，也无需担心镜像兼容问题。

3.4.2Kafka搭建

Kafka的搭建是本文中最关键的环节之一，只有在Kafka能够正常运转的前提下，我们的自适应流框架才能顺利运行。由于我们需要进入云服务器终端安装配置Kafka，所以在此我们借助Docker对Kafka进行搭建。同时需要对Kafka进行配置的参数有：broker.id、listeners、advertised.listeners、log.dirs以及zookeeper.connect。

3.4.3JupyterNotebook搭建

JupyterNotebook[21]是一个交互式笔记本，支持运行 40 多种编程语言。其本质是一个 Web 应用程序，便于创建和共享文学化程序文档，支持实时代码，数学方程，可视化以及markdown。搭建Jupyter Notebook是为了实现对机器人传输数据的有效处理，包括数据收发以及计算处理。该部分我们使用Docker进行jupyter的部署。

3.5API设计

API设计是本文中最为重要的环节，用户通过API的调用能够使用以下功能：连接判断，数据收发、处理，数据类型判断，数据安全和数据同步非同步，意外处理，移动机器人算法以及自适应操作等。具体API设计如下表所示：

表3.2 API列表

通过配置Docker、Kafka运行环境、Jupyter Notebook环境以及API的调用这四个简单的步骤，用户可以十分便捷的进行机器人的使用——机器人采集数据的传输、算法调用以及数据可视化等；对于开发人员来说可以对我们的API进行扩展，向第三方提供算法包接口。

3.6今后的工作

在完成API的基础设计之后，我们将进一步向algorithms_for_mobile_robot包中增添移动机器人算法。

最后本文将使用iperf进行性能评价，测定不同信息大小的数据包的最大最小吞吐量以及机器人和云之间的延时。

3. 研究计划与安排

4.进度安排

4. 参考文献（12篇以上）

5.参考文献

[1] 任福继, 孙晓. 智能机器人的现状及发展[j]. 科技导报, 33(21).

[2] 蒋茵. 浅谈cdn与云计算的发展趋势[j]. 科学时代, 2014(19).