288?1442652660

胡奔 (Student)

siteen

国防科学技术大学

Ta在确实 over 5 years

  • 湖南-长沙
  • 2013-11-15开始使用
  • 6710次访问(自2016年5月)
Ta的动态
288?1442652660
发布时间:04/17/2017 22:30
更新时间:04/18/2017 10:41
docker swarm join \
    --token SWMTKN-1-27bz71vdidnqycj5n6we1e0xw4h8ncdzbabufnzxto2qtzdqr0-1lpqhmf8q2odexfixaps3uhiq \
    192.168.43.176:2377



docker swarm join \
    --token SWMTKN-1-3yik9ne9hv4knjoszb5i5cl1t2h58a709b9d4q7zi6fnul8lcl-4dlvilrez7ajmq1jc3qtgbei3 \
    192.168.43.87:2377


回复 ︿
288?1442652660
创建时间:01/13/2017 10:58
288?1442652660
发布时间:01/03/2017 09:53
更新时间:01/03/2017 09:53
sudo apt-get install software-properties-common
sudo apt-get install python-software-properties
sudo add-apt-repository ppa:v-launchpad-jochen-sprickerhof-de/pcl
sudo apt-get update
sudo apt-get install libpcl-all
回复 ︿
288?1442652660
发布时间:12/20/2016 16:43
更新时间:01/03/2017 09:09

 每次评估都有4次迭代优化,零次迭代时也有个优化时间,但是是其他几次迭代的优化时间的一半左右。其他几次迭代优化所需时间差别不大。下面是我选取其中一次迭代优化来分析:

台式机:

600 Features            "ATE MAX"                "Duration"                            "Optimization Time"                            Nodes  Edges

FR2 xyz         AT-MAX   0.043872   m  Duration   455.698757350  s  Optimizer Runtime   0.567449            s  Number of Nodes/Edges   3612  36528

 

600 Features

"ATE MAX"

"Duration"

"Optimization Time"

Nodes

Edges

FR2 xyz

0.043872

455.698757350

0.567449

3612

36528

 

华硕笔记本:

600 Features            "ATE MAX"                "Duration"                              "Optimization Time"                            Nodes  Edges

FR2 xyz         AT-MAX   0.043844   m  Duration   16263.569546481  s  Optimizer Runtime   73.0853             s  Number of Nodes/Edges   3612  35804

 

600 Features

"ATE MAX"

"Duration"

"Optimization Time"

Nodes

Edges

FR2 xyz

0.043844

16263.569546481

73.0853

3612

35804

 

这条数据总共有6个值:


  • 600 Features 是指数据集,由于华硕的本运行实在太慢,我只测了一个数据集 FR2 xyz,在两台机器上都是这个数据集。
  • ATE MAX 是指absolute trajectory error (ATE),绝对误差轨迹
  • Duration 是指运行时间,从上面的两个表格可以看出来华硕本是台式机的四倍左右
  • Optimization Time是指优化时间,具体指的是什么的优化时间我还没搞清楚,但是可以看出差距巨大
  • 后面两个是节点和边


 



参考:

测试方法:

http://wiki.ros.org/rgbdslam_electric/evaluation

论文:

http://ais.informatik.uni-freiburg.de/publications/papers/sturm12iros.pdf

http://www2.informatik.uni-freiburg.de/~hess/publications/endres12icra/endres12icra.pdf

测试数据集:

http://vision.in.tum.de/data/datasets/rgbd-dataset

http://vision.in.tum.de/data/datasets/rgbd-dataset/download

测试源码:

https://github.com/felixendres/rgbdslam_v2/tree/indigo/test


回复 ︿
288?1442652660
发布时间:12/28/2016 11:40
更新时间:12/29/2016 14:48

1.研究目标

本课题以云机器人为背景,研究实现一个透明的能够对QoS进行感知的为云机器人提供后台服务支持软件框架Cloudroid。该框架基于开源机器人操作系统(ROS),能够根据ROS软件包自动生成与云进行交互的代理,并且无需修改软件包就能其透明地转成可通过互联网连接的机器人云服务。同时为了满足机器人云服务的实时性和高可靠性要求,着重考虑云机器人数据传输和云端资源分配的服务质量保证。最后完成一个完整的云机器人服务平台的开源实现,部署常见的机器人云服务。

2.主要研究内容及拟解决的关键科学问题和技术问题

通过云与机器人的结合,将机器人的数据采集与数据应用同数据计算分离。云端利用自身优质的计算资源和丰富的知识存储,将机器人采集到的数据进行处理,为机器人的需求提供服务。这种模式能够提升机器人对复杂环境和复杂任务的处理能力。目前已经有机器人云平台的研究工作利用利用ROS构建了面向具体场景的云平台并验证了云对于机器人能力的提升作用。但是,目前的工作尚未考虑互联网环境下 ROS 应用“云”化以及机器人云服务的服务质量保证。

再这样的背景下,本课题拟对如下的三个方面进行研究:

1)支持ROS软件包部署和服务化使用的云平台开源实现

目前已有的机器人云平台的工作过于关注于云端就某一类问题或是在某一特定场景对机器人进行支援与能力提升的验证。其架构往往具有较强的固定性,很难就不同的问题或是不同场景下的需求进行灵活的部署与调整。本课题拟根据之前研究提出的支持 ROS 软件包快速部署与服务化使用的云平台架构,通过已有的开源软件ROS、Docker、Rosbridge等搭建一个软件系统。实现对已有的机器人软件通过web服务进行自动地云服务的部署和管理以及机器人端代理的自动化生成。并在这个系统上开展云机器人进一步的研究。

2)ROS消息在互联网环境中传输的QoS保证

ROS的消息机制是机器人软件运行时相互交互重要机制,也是ROS实现其元操作系统跨平台交互功能的核心。然而ROS运行在局域网环境的特性,没有考虑其消息机制在互联网环境下的服务保证。

机器人是信息世界与物理世界交互的平台,为了保证其功能的正确运行,机器人软件运行的实时性和准确性有其特殊的要求。机器人要从云端获取云服务,考虑到机器人工作环境以及互联网环境的动态变化,必须对ROS消息的传递进行QoS保障。

3)基于Docker的机器人云平台的QoS保证

平台是服务提供的基石,拟实现的系统基于Docker容器技术实现机器人云服务资源的获取和隔离。目前基于容器的PaaS工具正在逐渐发展,典型的工具包括Fleet、Flynn、Deis、Kubernetes等。机器人云平台有这种专用平台的特点,例如很多工具都有对云平台的中容器的内存CPU使用进行限制,但是没有对容器的网络带宽进行管理的工具。但是为了满足某些高优先级云机器人应用的带宽需求,需要对Docker容器的网络带宽进行管理。

4)面向云机器人应用的典型软件包的部署和实验

搭建平台的最终目的是为了实践使用。为了验证平台的实用性,本文将用机器人领域典型的计算密集型的算法对平台进行测试。这些算法包括机器人建图SLAM算法,机器人场景识别的物品识别算法等。将采集实验数据,检验机器人云平台对这些算法的加速效果和QoS保证效果。

3.拟采取的研究方法、技术路线、实施方案及可行性分析

1)研究方法

针对上面研究的四个问题,本小节主要对设计思路与解决方案进行分析。本课题拟采用根据已有的原型系统利用开源软件搭建完整的系统软件。然后通过利用这个系统软件测试机器人在云平台的协助下运行一些计算密集型和知识共享型任务所获得收益。并且对本研究提出的一些机器人云平台QoS保证方法的效果进行测试和评估。

2)课题的技术路线和实施方案

-支持ROS软件包部署和服务化使用的云平台开源实现




4.预期创新点

回复 ︿
288?1442652660
发布时间:12/27/2016 11:26
更新时间:12/29/2016 08:56


2.1面向云机器人的“平台即服务”的基础设施

2.2云机器人平台相关技术调研

2.2.1ROS

2.2.2Docker

2.2.3Rosbridge

机器人云平台的作用是接收机器人通过传感器收集到的数据并进行处理,同时将处理过后的结果返回给机器人进行使用。ROS提供基于消息发布订阅机制的通讯系统,能够为机器人间的通讯以及机器人与云端的通讯提供支持。所以ROS是搭建云机器人平台的重要技术之一。但是ROS不提供互联网环境下的通讯支持,为此布朗大学与博世公司的研究人员于 2011 年提出了Rosbridge以及在Rosbridge基础上进行扩展的Robot Web Tool

Rosbridge的主要功能就是在WebSocket的基础上,通过一个socket接口对ROS所有的消息与服务进行序列化,将其转换成JSON格式的工作。由于WebSocket使用了互联网环境中各个节点默认开放的80端口, 建立连接的双方并不需要知晓对方的全部网络配置就可自由通信。同时,JSON格式作 为一种轻量级的数据交换格式,以其易于阅读编写以及机器解析生成的特点,得到了广泛的 应用。基于这种简单、完全独立于语言的JSON格式的通信方案,既保证了ROS的通用性与 普适性(提供了ROS与非ROS节点通信的可能性),也降低了ROS消息序列化的难度。因此 这一方案被认为是可行的互联网通信方案,并被ROS官方所采纳。

在此基础上,研究人员于2015年发表了Robot Web Tool项目。这一项目在Rosbridge的基础上,提供了一系列功能强大的工具与库。其主要目的在于构建基于Web的功能丰富的机器人应用,并在此背景下提供互联网环境中高带宽要求的ROS消息的传输方案。Robot Web Tool项目沿用了Rosbridge基于WebSocket使用JSON的通信方式,并在rosbridge协议的基础上提出了rosbridge v2协议。相较于之前的rosbridge协议,rosbridge v2增加了对于数据的压缩处理,并提供了对于ROS核心消息的完整支持,总体完成度与传输效率较之前版本有所提高。在这一新协议的基础上,Robot Web Tool项目开发了功能丰富的工具库,包括针对2D图像的可视化工具ROS2DJS3D建模的可视化工具ROS3DJS,以及服务端的支持rosbridge v2WebSocket服务端ROSBRIDGE SUITE、专门用于接受ROS图片流的WEB VIDEO SERVER等。可以说,RosbridgeRobot Web Tool,尤其是Robot Web Tool项目,开发的完整支持ROS消息并具有数据压缩功能的rosbridge v2 通信协议,是解决ROS互联网环境中分布式通信的重要方案。对于构建以ROS为基础环境的机器人云平台而言,是关键的技术手段。

2.3云机器人平台的服务质量(QoS)保证

机器人作为信息世界与物理世界直接交互的平台,其应用程序存在其所需的特定的QoS属性。将计算外包给云可能会引入一些影响机器人应用程序的特定QoS属性的不确定性。 例如,网络可能不总是满足机器人和云之间的数据传输的需求,或者云上的资源竞争可能导致性能下降,特别是当多个机器人同时访问服务,其封装了大量计算时。 为了最小化这些不确定性的影响,机器人云平台在机器人和云端之间要设立一组QoS意识机制。 通过这些机制合作,尽力满足机器人客户端指定的QoS要求。

2.3.1机器人消息传输服务质量(QoS)保证

基于ROS的发布订阅消息传输机制以及Rosbridge工具,ROS软件包运行时发布的Topic能够在互联网环境下传播。这使得机器人与云平台之前的通讯得到满足。但是基于这种方案的消息传递QoS对于与物理环境直接交互的机器人来说是远远不够的,理由如下:

-ROS的发布订阅机制底层基于对TCPUDP协议的封装,没有机制来保障QoS

-rosbridge提供了传输过程中对大数据包的分片和压缩功能,有一定的QoS保障能力,但是对于实时性,准确性要求很高的自主机器人来说是远远不够的。

为了提高ROS消息传输的实时性和准确性。学术界已经有了一些尝试。micROS-drt通过在ROS消息通讯的基础上增加了Object Management Group (OMG)的实时系统数据分布服务(DDS)来实现ROS消息的实时传输。

但是这种方法并没有支持互联网环境下的消息传递。

2.3.2机器人云端管理服务质量(QoS)保证

利用Docker搭建的云端平台,能够实现机器人任务的在云端的运行。但同时多个机器人访问云服务的时候可能会出现以下问题:

-多个机器人访问同一个任务可能会相互之间影响

-集群上运行多个机器人服务的时候,出现负载不均衡的问题,致使云端资源利用率不高

-机器人服务拥有一定的优先级,可能存在优先级高的服务得不到资源,优先级低的应用一直霸占资源情况

Docker是利用LXC来实现类似VM的功能,从而利用更加节省的硬件资源提供给用户更多的计算资源。同VM的方式不同, LXC 其并不是一套硬件虚拟化方法 - 无法归属到全虚拟化、部分虚拟化和半虚拟化中的任意一个,而是一个操作系统级虚拟化方法。LXC所实现的隔离性主要是来自操作系统内核的namespace, 其中pid, net, ipc, mnt, uts 等namespace将容器的进程, 网络, 消息, 文件系统和主机隔离开。通过这种方法实现了容器之间的资源隔离,使得运行在不同容器内的程序不会相互影响。


Docker

回复 ︿
288?1442652660
发布时间:12/20/2016 22:52
更新时间:12/27/2016 11:14


1.学位论文选题的立论依据

1.1课题来源

本课题来源于校重大应用基础研究项目“机器人操作系统”。课题以云计算和机器人领域所交叉而形成的“云机器人”架构为背景, 通过构建支持多种云机器人服务部署和运行的“平台即服务”云计算基础设施Cloudroid,并且充分考虑机器人和机器人所需的云服务的特点,重点设计和实现针对机器人云服务的多种QoS保障机制。

1.2选题依据和研究意义

机器人由于其模拟人类或者生物的思维或者行为的特性,可以进行一些重复性高的或者危险人类不想做的工作,也可以做一些因为尺寸限制,人类无法作的工作,甚至是像外太空或是深海中,不适人类生存的环境中的工作。随着计算机与信息技术、人工智能技术、自动控制技术、传感检测技术、伺服传动技术和机械技术等交叉的系统技术发展,机器人技术和产业得到了飞速发展。据国际机器人联合会(IFR)统计,工业机器人销量增长了15%到253,748个单位,其中中国占据了2015年总供应量的27%,作为全球最大市场,显著扩大了领先地位。

随着机器人应用领域的拓展,人们对于其能力的期望也日益增长。机器人不再只是机械执行预置程序的物理装置,人们希望它们具有更高的智能化水平,能够根据一定的人工智能原则应对复杂环境、遂行复杂任务。然而,这也往往意味着机器人需要内置更复杂的算法、更丰富的知识、更庞大的数据。但实际中,机器人个体受限于硬件水平、电池容量、成本等设计约束,其计算资源和所拥有的知识往往是受限的。例如,当前许多机器人的板载计算机(onboard computer)都还只是能力十分有限的嵌入式设备。如何在这种客观条件下提高机器人的智能化水平和自主行为能力,解决资源、知识受限与能力提升之间的矛盾,是机器人研究者和实践者当前所面临的挑战之一。

在这种背景下,“云机器人”(Cloud Robotics)的概念应运而生[3]。云机器人并不是指某一个机器人,也不是某一类机器人,而是指机器人信息存储和获取方式的一个学术概念。利用云端资源丰富的计算基础设施,以及云端充沛的存储资源和大数据支持,能够为机器人提供场景定位,地图构建,物品识别等应用带来非常大的性能提升。例如对于机器人SLAM( simultaneous localization and mapping)问题, 2010 年的文献【1】即已通过实验表明, 在 300*300的网格地图和 500 个粒子条件下, 8 个结点的集群相对于单个计算结点可以获得接近 1 个数量级的性能收益。对于机器人的物品识别,文献【2】能够在拥有Nvidia Titan X加速的情况下做到实时的物品识别。

基于“云+机器人”的理念,“平台即服务”是机器人按需使用云端资源的重要方式之一。根据美国国家标准技术研究所(NIST)的定义[5],云计算对外提供服务的模式可以分为“基础设施即服务” (Infrastructure  as  a  Serivce, IaaS)、 “平台即服务” (Platform  as  a  Service,PaaS)、 “软件即服务”(Software  as  a  Service,  SaaS)等类型。其中, “平台即服务”通过在云端提供支持应用部署、 运行和维护的基础设施, 以应用容器的方式为软件云端托管提供基本平台。在已有的商业实践中,“平台即服务”的典型实例包括 Google App Engine、CloudFoundry 等。暂时没有提供商用的机器人“平台即服务”实例。但是在学术界已经有这方面的探索。例如新加坡科技局在2010年提出了一个云机器人框架DAvinCi【1】,该框架旨在用Hadoop集群加速SLAM的计算。Rapyuta Rapyuta【3】是由苏黎世联邦理工学院的研究小组于 2013 年提出的 RoboEarth 项目中的云引擎(Cloud Engine)框架,旨在为每一个机器人在云端提供一个对应的计算环境。Cloudroid【4】是国防科技大学PDL重点实验室云机器人团队中提出的一种能够将机器人软件包直接转成云服务的框架,并且实现了一个原型系统。

虽然学术界提出了一些云机器人平台的框架,也实现了一些原型系统,但是在云机器人平台领域还没有研究重点考虑机器人的服务质量保障(Quality of Service)。机器人云平台作为为机器人提供服务的软件设施,机器人只有通过利用服务质量得到保证的云平台才能对其能力进行提升,所以服务质量保证也是很重要的,原因如下:

-从机器人工作环境角度:通用机器人的工作环境是动态变化的,由于其处在的复杂的环境的变化会导致网络信号的不稳定。例如在危险环境中执行任务的机器人如灭火机器人或者战场机器人所面临的复杂网络环境。

-从机器人来角度:机器人所需的云服务的服务质量对其行为会产生重要的影响。例如机器人云服务如果不能及时识别行进路上的障碍物可能会导致机器人撞上障碍物。

-从平台本身角度考虑:平台要为多个机器人同时提供相同或者不同的服务,如何保障每个机器人都能得到想要的有保障的服务也是一个很重要的研究方向。


6.主要参考文献

【1】Arumugam, Rajesh, et al. "DAvinCi: A cloud computing framework for service robots." Robotics and Automation (ICRA), 2010 IEEE International Conference on. IEEE, 2010.

【2】Liu, Wei, et al. "SSD: Single Shot MultiBox Detector." arXiv preprint arXiv:1512.02325 (2015).

【3】Hunziker, Dominique, et al. "Rapyuta: The roboearth cloud engine." Robotics and Automation (ICRA), 2013 IEEE International Conference on. IEEE, 2013.

【4】Wen, Shangmin, et al. "Towards migrating resource-consuming robotic software packages to cloud." Real-time Computing and Robotics (RCAR), IEEE International Conference on. IEEE, 2016.




回复 ︿
288?1442652660
发布时间:12/15/2016 17:23
更新时间:12/22/2016 15:22

在这里记录王老师在师门会上对我们研究指导的一些经典语录,铭记王老师的教导,做好自己的本职工作。凭记忆记录,有失偏颇之处请多多指教。


  • “一定要把故事讲好!”

这句话我的印象非常深刻。把故事讲好意味着把问题看得很透彻,抓住了问题的本质,只有找到了对研究内容很好的应用才能把对应的故事讲好,讲的让人信服;把故事讲好意味着对事情的来龙去脉很清楚,意味着做了大量的调研和调查,阅读了大量的论文,只有通过这样才能把故事串通,才算把故事讲好;把故事讲好意味着对研究内容的逻辑很清晰,对问题的解决一环扣一环,让人听了感觉故事逻辑严密,发展合理,写成论文让人一看就能竖起大拇指。


  • “研究不一定要玩智力游戏,对已有的东西能解决自己的问题就大胆地拿来用,用已有的东西组合解决新的问题也是创新。”

王老师举了苹果乔布斯的例子,乔布斯的伟大来自于他组合已有技术产生了iPhone这么伟大的产品。我觉得很有道理,毕竟做完全的原创是很难的,微创新也是一件很有意义的事。就像铅笔和橡皮,有人把橡皮绑在铅笔上做成一件产品就是一件很有意义的重要的创新。


  • “为什么做这件事?做这件事真有这个需要吗?”

这是我们开题过程中需要时刻反问自己的一个问题。比解决问题更难的是发现问题,开题过程就是一个发现问题的过程,只有在开题过程中不断反问自己王老师提的这个问题才能让自己发现的问题经得起推敲,经得起质询,才能找到问题的意义所在。



这里只记录了我记忆深刻的通用性的观点,还有一些针对具体问题的很睿智意见和建议就不在此记录了。



回复 ︿ (3)
  • 用户头像
    16FanQ 2年前

  • 用户头像
    余跃 2年前
    确实值得我们反复认真研读!

  • 用户头像
    尹刚 2年前
    学习了!再看一遍又有了新的收获

288?1442652660
发布时间:12/01/2016 08:19
更新时间:12/18/2016 20:59

1.消息传输方法和传输协议的改进

  • 当前传输方法和协议的实现
  • 当前方法的优缺点
  • 改进方案
根据王老师的启发,做底层的协议来提高效率是不现实的,底层你像TCP/IP这种协议是没法更改的,是这么多年生态的行程的结果。我们唯有能做的是overlay的工作,在现有工作之上做协议的实现。

   1.1 MQTT协议三层QoS的设定

(http://www.hivemq.com/blog/mqtt-essentials-part-6-mqtt-quality-of-service-levels)可以给不同的任务设置三种不同的协议需求。这个可以由用户定义,根据用户的需求提供不同的proxy包来支持不同的QoS等级。

   1.2 DDS传输协议

跑在互联网上的DDS

2.传输消息的压缩

要针对不同的消息进行不同的压缩

3.平台资源调配

  • 当前资源调配的几种方式
  • 当前方案的优缺点
  • 改进方案
考虑网络带宽

4.机器人端本地资源重启

机器人在网络完全断掉以后能够重启本地的资源完成任务
回复 ︿
288?1442652660
发布时间:11/01/2016 15:09
更新时间:12/15/2016 20:58

1.The concept of service-oriented architecture is by no means new.

2.An interesting question is whether or not it is technically feasible to develop such a tool based on a service-oriented architecture.

3.The remainder of the paper is organized as follows:

回复 ︿
点击展开更多
问题和建议
还能输入50个字符 Submit

加入QQ群

关注微信APP


×