开放式机器人智体Word格式.docx

上传人:聆听****声音 文档编号:957362 上传时间:2023-04-29 格式:DOCX 页数:10 大小:32.15KB
下载 相关 举报
开放式机器人智体Word格式.docx_第1页
第1页 / 共10页
开放式机器人智体Word格式.docx_第2页
第2页 / 共10页
开放式机器人智体Word格式.docx_第3页
第3页 / 共10页
开放式机器人智体Word格式.docx_第4页
第4页 / 共10页
开放式机器人智体Word格式.docx_第5页
第5页 / 共10页
开放式机器人智体Word格式.docx_第6页
第6页 / 共10页
开放式机器人智体Word格式.docx_第7页
第7页 / 共10页
开放式机器人智体Word格式.docx_第8页
第8页 / 共10页
开放式机器人智体Word格式.docx_第9页
第9页 / 共10页
开放式机器人智体Word格式.docx_第10页
第10页 / 共10页
亲,该文档总共10页,全部预览完了,如果喜欢就下载吧!
下载资源
资源描述

开放式机器人智体Word格式.docx

《开放式机器人智体Word格式.docx》由会员分享,可在线阅读,更多相关《开放式机器人智体Word格式.docx(10页珍藏版)》请在冰点文库上搜索。

开放式机器人智体Word格式.docx

A

英文摘要

Abstract :

Tosolvetheproblemsofupdating,modifying,upgradingandmaintainingthefunctionofrobotbyofflineandstaticmethod,SoftManwasintroducedforrobotplatform,andthearchitectureofrobotsystem,whosemanagingcenterishostSoftMan,wasbuilt.ThehostSoftManwasmainlyresearched.Firstly,thearchitectureofhostSoftManwasconstructed.ThenthedescriptiveunificationmodelofknowledgeandbehaviorofhostSoftManwasputforwar,dtheknowledgemodelwasconstructedandimplementedbasedondatastructur,eandthedesignspecificationsandreferencerealizationofthealgorithmweregivenforitsmainservicebehaviors.

Finally,therobotsystemwasunifiedwiththeSoftMansystem.Throughthetest,thefunctionofrobotwassuccessfullyreplacedonlineanddynamically,implementingthemeaningoftheintroductionofhostSoftManandverifyingthecorrectnessandfeasibilityofthemethodofdesigningandimplementingthehostSoftMan.

英文关键词

Keywords :

robot;

hostSoftMan;

modelofknowledgeandbehavior;

SoftMansystem;

syncreticsystem

0 引言

目前,机器人控制结构的开放化、模块化[1],机器人控制器的标准化、网络化以及PC

(PersonalComputer)化已成为机器人领域的研究热点。

实际上,早在20世纪90年代初开

始,美国三大汽车制造公司就已联合发表了它们对未来开放式模块化控制器的需求白皮书,提出了“开放式、模块化体系结构控制器(OpenModularArchitectureControllers,OMAC)”的概念,并于1997年成立了OMAC用户组织[2]。

欧洲共同体的22家控制器开发商、机床生产

商、控制系统集成商和科研机构于1990年联合发起“自动化系统中开放式体系结构(OpenSystemArchitectureforControlswithinAutomationSystem,OSACA)的研究和开发”的倡议

[3]。

近二十几年间,机器人系统的开放可重构研究更是受到了极大的重视。

White等[4]从物理运动学理论的角度证明了任意尺寸自重构机器人的存在性,并于2005年设计了Molecubes模块化机器人;

Ferenc等[5]提出了一种实时的基于公共对象请求代理体系结构(CommonObjectRequestBrokerArchitecture,CORBA)协议的分布式机器人控制系统;

麻省理工学院

(MassachusettsInstituteofTechnology,MIT)的Gilpin等[6]于2006年设计了Miche晶格式模块化机器人,实现了机器人任意形状的组建。

国内对机器人的研究起步相对较晚,但在开放可重构机器人研究方面也取得了一定的成果。

刘明尧等[7]提出一种基于多智体(Agent)的机器人控制方法;

张玉华等[8]提出了一种新型模块化可重构机器人(HitModularSelfreconfigurable

Robot,HitMSR)系统的硬件和软件系统实现方案;

谢峰等[9]以异构多Agent系统

(MultiAgentSystem,MAS)理论为基础,提出了一种可在多个层次上动态重构的控制系统设计方案。

“软件人”[10]是近年来在软计算、智能化领域提出并发展较快的一个课题方向。

它是将人工生命、人工社会研究方法与现有(多)智体(Agent)[11-12]的研究成果结合起来的、网络世界中的虚拟机器人,是“智体(Agent)”和“对象”的升华,比通常的Agent更富有“人工生命”的特性和活性,具有感知、通信交互、任务分解、局部规划、任务分配、学习、控制与决策、进化(自适应)等功能,其中学习与进化特征是其区别于Agent的关键所在[13]。

作为人的“自然生命”在软件世界里的模拟、延伸和扩展,“软件人”能进入、迁移并驻留各种计算机信息网络中,完成计算、通信等各种信息处理工作,因此“软件人”属于软件范畴,它需与类人机器人

(humanoidrobot)有所区分。

类人机器人是外观和功能与人一样的智能机器人,通常是由传感器、微型处理器等组建搭建的机器人系统,它包含了硬件和软件两个范畴。

普通的机器人控制系统通常采用的是封闭式的结构,程序改动困难,无法实现机器人功能的在线实时更新。

针对这一问题,本文拟将宿主“软件人”和附体“软件人”[14]引入到机器人的控制系统中,通过附体“软件人”与宿主“软件人”配合工作来代替普通的机器人控制系统,为机器人与PC机上的“软件人”系统[15]之间构造一个对等、柔性、动态的协同模式,实现机器人控制系统的开放化、标准化以及模块化。

“软件人”系统通过迁移不同的附体“软件人”附着到机器人控制系统中,实现对机器人功能的动态配置与在线重构,进一步提升机器人系统的柔性智能能力,改善其环境的适应协调能力。

引入的宿主“软件人”不仅是机器人系统的信息处理和管理中心、PC平台与机器人交互的枢纽,同时需为应用层的附体“软件人”搭建运行支撑环境。

此时机器人蜕变为传感载体和末端执行机构平台,如图1所示。

本文将重点对宿主“软件人”进行研究。

首先依据“软件人”构造分层体系理论[10],对宿主

“软件人”的体系结构进行设计;

然后,以“软件人”知行模型[14]为指导提出宿主“软件人”的知识行为一体化描述模型,并对其知识模型进行实现研究,对相关服务行为进行描述及算法研究;

最后,通过测试用例,验证在以本文提出的宿主“软件人”的设计理论与实现方法的基础上,以宿主“软件人”为管理中心的机器人平台能否实现上文提出的对机器人功能的在线重构,是否真正实现引入的宿主“软件人”在机器人平台中的角色功能。

1宿主“软件人”模型设计

1.1宿主“软件人”体系结构设计

宿主“软件人”为机器人平台的守护、信息处理和管理中心,根据其在合一系统机器人平台中的角色,结合“软件人”构造分层体系理论[10],对其体系结构的设计如图2所示。

各层功能定义如下。

本体核心层组成“软件人”最基本的部分。

它包括“软件人”的构造数据结构、本体控制机制。

相应的构造数据如“软件人”脑、眼、耳、手、脚及其基本动作机制。

本体的控制如本体各部分的驱动、“肢体”的协调、信息的刷新。

守护内核层负责注入到机器人系统中,改变系统的启动流程,并负责初始化相关数据,使得机器人系统能正确运行。

宿主抽象层宿主“软件人”不仅要能对机器人的硬件设备进行控制,同时,还需要在此基础上对其进行抽象与封装,使得外界能了解机器人提供的行为功能信息。

节点数据层节点数据层负责机器人社区内活动的附体“软件人”信息和环境资源信息的管理及维护。

此层是机器人社区管理的关键依据,同时,此层还存储由管理“软件人”或社会协调

“软件人”向机器人平台下达的相关策略信息。

内外交互层宿主“软件人”既有与外地联络的职责,也有本地交互的义务。

内部交互就是为完成与附体“软件人”的交互而设立的,通过此层接受内部信息,同时向附体“软件人”传递外来的信息。

外部交互是指与外社区的信息交流,包括与某个社区“软件人”的交流、与某个社区管理机构的交流或与“软件人”社会协调机构的交流。

此外,内外交互层内部还构成出/入两个消息队列。

迁移接收层宿主“软件人”需要搭建一个运行支撑环境供附体“软件人”控制机器人完成任务。

社区决策层社区决策层是“软件人”对本地社区实施行动的决策依据和决策算法。

但是考虑到机器人端资源的紧张性以及响应的实时性要求,本文将宿主“软件人”社区决策层的功能弱

化,它只负责任务调度以及执行管理“软件人”的决策。

节点协调层执行管理“软件人”或社会协调“软件人”的协调策略,从而保证局部与整体、局部与局部的协调运行、效益最大化与整体最大化。

1.2宿主“软件人”知识行为一体化描述模型

机器知行学是研究使机器具有一定“知行能力”的学科[16-17],其理论核心是“信息-知识-智能的转换与统一理论”,从机器知行学在Agent技术[18]、自然语言处理[19]、情感计算[20]等方面的应用,可以认识到,从拟人角度出发的,生存于网络环境下的虚拟机器人——“软件人”的设计与实现也应该遵循机器知行学中的相关规律。

关于“软件人”的知行模型理论在文献[14]中已有详细论述,本文依据宿主“软件人”的体系结构,将“软件人”知识行为一体化描述模型[14]应用于宿主“软件人”资源及服务的抽象建模中,建立了一种结构化、易于动态维护和调整的宿主“软件人”知识行为一体化描述模型,如图3所示。

白色节点为普通的知识节点,节点名称是用户自定义的;

灰色节点为系统的保留节点,节点名称不可变。

图3中:

HostSoftMan为根节点,表示机器人系统中的宿主“软件人”,由知识库KnowLedgeBase和行为集Behaviors组成;

InitROT、NodeData、MessageBuffer、和HostAbstract作为KnowLedgeBase的第一级子节点,分别表示宿主“软件人”初始化机器人平台时需要的知识以及节点数据层、消息缓冲层和宿主抽象层所涉及的信息;

AppendSM表示活动的附体“软件人”信息;

Context表示“机器人”端的环境资源信息;

HardwareAbstract和BehAbstract表示机器人硬件抽象和行为抽象信息。

LifeCycleCtrl 、ResCtrl、CommBehs、CognBehs和SrvBehs作为Behaviors的第一级子节点,分别表示宿主“软件人”的生命周期、系统资源控制行为、交互行为、认知行为和服务类行为。

LifeCycleCtrl、ResCtrl、CommBehs、CognBehs属于“软件人”本体行为,在此不再赘述。

宿主“软件人”特有的服务类行为SrvBehs可划分为社区初始化行为InitBeh、迁入登记行为

MigInBeh、硬件抽象层调用行为HALCallBeh、节点容错行为FaultToleranceBeh、信道建立行为CreateChannelBeh、对动态附体“软件人”控制行为AppendSMctrl和环境资源感知行为

CxtCtrl。

其中,AppendSMctrl可分为对附体“软件人”的生命周期及状态控制AppendLifeCycle

和任务协调行为TaskCoordinate。

1.2.1宿主“软件人”知识模型实现研究

“软件人”知识模型(SoftManKnowLedgebaseModel,SMKM)定义为一个三元组[14]:

SMKM= 〈Data,Type,Relation〉。

1)Data为“软件人”知识的数据部分,表述为一个三元组:

Data=〈DataType,

DataContent,DataLen〉其中:

DataType表示数据类型,DataContent表示数据内容,DataLen表示数据长度。

2)Type为本“软件人”知识节点的逻辑类型,即资源类型知识节点或属性类型知识节点。

3)Relation用于描述本知识节点与其子节点之间的模糊关联,表示为:

Relation= ∪〈SubSKMi,tValuei,fValuei〉;

0≤i≤n其中:

tvaluei表示第i个子知识节点相对于本节点的隶属度,fvaluei表示第i个子知识节点相对于本节点的假隶属度[14]。

“软件人”知识模型SMKM主要是由以下4个数据结构来构造和实现的。

1)枚举类型SMKMType表示“软件人”知识Data部分的DataType,其成员包括:

无数据类型smkm_no_type,整数类型smkm_int_type,浮点类型smkm_float_type,字符串类型

smkm_str_type,结构体类型smkm_struct_type,链表类型smkm_list_type。

2)枚举类型SMKMLogicType表示“软件人”知识Type部分的逻辑类型,其成员包括:

资源类型smkm_logic_res_type,属性类型smkm_logic_attr_type。

3)结构体smkmTerm表示“软件人”知识的基本构造元素,其成员包括:

smkmType表示

“软件人”知识Data部分的DataType,*p表示“软件人”知识Data部分的DataContent,len表示

“软件人”知识Data部分的DataLen,logicType标明“软件人”知识的逻辑类型Type,wMs和

wUnMs表示本知识节点与其父节点的模糊关联。

4 )结构体smkmStructType为软件人”知识基本构造元素提供了一种灵活的组装方式。

根据以上对“软件人”知识模型与其数据结构的定义与说明,对图3左边宿主“软件人”的知

识库KnowledgeBase部分进行实现,其实现示意图如图4所示。

行为集Behaviors的实现逻辑与此类似,不再详细赘述。

图4顶层方框表示要描述的是知识Data部分的DataType为结构体类型smkm_struct_type的知识节点“HostSoftMan”。

第二层左分支方框描述的是“软件人”名称,名称的数据类型为字符串类型smkm_str_type;

LogicType=smkm_logic_res_type表明该“软件人”知识的逻辑类型为资源类型;

*p表示名称的数据内容为“HostSoftMan”;

len=11表明名称的数据长度为11个字符;

wMs=1、wUnMs是否应为wUnMs,图中表述为wUnMs将wUnM改为wUnMs=0表明与其父节点隶属度为1、假隶属度为0。

第二层右分支方框枚举了图3宿主“软件人”知识库KnowledgeBase的下层组成要素名称及个数。

由*p可看出组成知识库要素的数据名称分别为NodeData、MessageBuffer、HostAbstract和InitROT,枚举类型SMKMType的数据类型为字符串类型smkm_str_type;

len=4表明组成要素数据个数为4;

wMs=1、wUnMs=0表明与其父

节点隶属度为1、假隶属度为0。

对图4中第三层与第四层的理解可分别参照对顶层和第二层的解释,不再赘述。

1.2.2宿主“软件人”行为规范及算法实现

服务类行为集SrvBehs是与宿主“软件人”的职能所对应的,因篇幅有限,本节选取其服务类行为集SrvBehs中典型的信道建立行为CreateChannelBeh和节点容错行为FaultToleranceBeh进行相关设计规范及算法的参考实现。

1)信道建立行为CreateChannelBeh。

“软件人”之间通过消息传递进行交互[21],因此,在机器人平台中担当守护、信息处理角色的宿主“软件人”需先创建通信信道。

在嵌入式Linux系统中,支持多种进程间通信

(InterProcessCommunication,IPC),常用的IPC方式有:

共享内存、信号量、管道、消息队列、socket等。

本文选取socket作为进程间通信的方式,建立机器人平台上的通信信道。

信道建立后,宿主“软件人”可为机器人端提供消息守护功能。

节点内部的附体“软件人”能通过信道与宿主“软件人”进行通信,同时,“软件人”平台上的消息节点也能通过连接该信道与机器人平台上的“软件人”进行通信。

宿主“软件人”消息守护流程如图5所示。

2)节点容错行为FaultToleranceBeh。

容错机制是系统可靠性的一种保证。

宿主“软件人”作为机器人系统的守卫者和管理者,关键是要保障机器人节点的正常运行。

因此,需讨论宿主“软件人”为使系统可靠运行而提供的容错行为。

对于宿主“软件人”的容错行为,首先需要能为异常结束的附体“软件人”提供重新启动的功能。

宿主“软件人”处理附体“软件人”进程退出信号过程如图6所示。

在宿主“软件人”监听到附体“软件人”退出时,通过查看“软件人”状态来判断是否有异常。

若已申请退出,则宿主“软件人”释放维护的相关信息;

否则认为该“软件人”进程为异常退出,重新启动附体“软件人”。

当宿主“软件人”接收到操作系统内核传来的信号时,附体“软件人”进程已经结束,且尚未处理的输入消息也将丢失。

若采用直接重新启动从初始化状态开始工作,虽然避免了附体“软件人”异常退出,但并未能保证其对外服务的连续性。

因此,为了避免附体

“软件人”服务的中断,宿主“软件人”采取了检查点容错机制。

即宿主“软件人”定期的保存运行期附体“软件人”的相关信息(检查点),当附体“软件人”因意外终止而重启时,利用保存的信息初始化附体“软件人”,使得“软件人”能从检查点继续执行,以此保持“软件人”对外服务的持续性。

现阶段各式各样不同功能的机器人可谓层出不穷。

若把专注点投向机器人嵌入式系统时,不难发现:

由于编程环境、实现架构和支撑平台等多种技术因素的制约,涉及机器人功能的更新、修改、升级、维护等工作,只能采用离线、静态方式进行。

因此,从机器人与PC端“软件人”系统合一机制(如图7所示)出发,通过将移动端机器人系统改造成一个以宿主“软件人”

为管理守护中心的平台,使得宿主“软件人”在自身实现的基础上搭建附体“软件人”的运行环境,可使一个机器人实现多个功能。

在图7所示机器人与“软件人”合一机制工作场景中,宿主“软件人”角色功能描述如下:

1)位于机器人平台的宿主“软件人”加载启动,完成机器人系统的初始化工作;

2)宿主“软件人”利用机器人行为功能描述,向“软件人”平台进行注册,提供机器人的功能信息;

3)“软件人”平台依据用户请求,查询相关信息,匹配出能完成任务的机器人,并指派相应的附体“软件人”去执行;

4)宿主“软件人”接收迁移过来的附体“软件人”,并为其构造运行环境,执行任务;

5)如果需要机器人继续执行任务,跳转到4),否则跳转到6);

6)宿主“软件人”结束运行,机器人进入关闭状态。

本章以由飞凌嵌入式公司生产的型号为OK210A的开发板作为硬件平台的机器人(如图8所示)为测试实物,与PC上的“软件人”系统搭建了一个简单的合一系统,来进行引入宿主“软件人”后的机器人蜂鸣功能、闪灯功能和截图功能的实现,以此验证本文提出的宿主“软件人”设计和实现方法的正确性和可行性,实现将宿主“软件人”引入机器人平台的初衷——机器人平台的在线功能动态更替。

控制机器人实现蜂鸣功能、闪灯功能和截图功能的三个附体“软件人”在初始状态时,是存在于PC端的,没有在移动设备上。

当移动端需要使用蜂鸣功能时,将联系PC端,将负责蜂鸣功能的附体“软件人”通过无线网络在线下载,并加载到移动设备上,执

行任务,测试用例一即验证其是否成功。

以此类推,测试用例二和三测试在同一移动设备上闪灯功能和截图功能的实现。

由此可见,机器人平台中宿主“软件人”的引入,使得机器人系统与“软件人”系统的合一得以实现,实现了同一机器人功能的动态配置与在线重构,在解决机器人应用领域中存在的可扩展性差、软件移植难、可复用性低等问题方面做出了努力,与传统的机器人控制系统开放性差、功能单一或功能只能离线、静态更替相比,表现出了其优越性,同时验证了关于宿主“软件人”的设计和实现方法的正确性和可行性。

3 结语

本文提出了在机器人平台中引入“软件人”的思想,目的是与网络平台中的“软件人”系统融合,实现机器人功能的在线动态更替。

详细研究了引入机器人平台中作为管理中心的宿主“软件人”,对其体系结构进行了设计,并基于机器知行学与前期研究的“软件人”知行模型理论,提出了宿主“软件人”的知识行为一体化描述模型,给出了知识模型的实现方法,对其行为集进

行了相应的行为规范和算法实现。

最后搭建了简单了合一系统测试平台,测试得出经过设计实现的宿主“软件人”成功地将机器人平台与“软件人”平台合一,使机器人功能得以在线更替。

从宏观角度来看,以宿主“软件人”为管理中心的机器人系统,从逻辑上转变为一个有形的、活动于物理空间的“软件人”实体(即虚体实物化),使得“软件人”系统成为一个虚实结合的、规模更大的人工生命系统。

参考文献:

[1]TIANM ,TANGX,MENGG,etal.Implementationofinteractiveco

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > IT计算机 > 电脑基础知识

copyright@ 2008-2023 冰点文库 网站版权所有

经营许可证编号:鄂ICP备19020893号-2