机器人语言对话系统的设计.docx
- 文档编号:5448027
- 上传时间:2022-12-16
- 格式:DOCX
- 页数:14
- 大小:137.96KB
机器人语言对话系统的设计.docx
《机器人语言对话系统的设计.docx》由会员分享,可在线阅读,更多相关《机器人语言对话系统的设计.docx(14页珍藏版)》请在冰豆网上搜索。
机器人语言对话系统的设计
中国石油大学(华东)现代远程教育
毕业设计(论文)
题目:
机器人语言对话系统的设计
学习中心:
重庆信息工程专修学院奥鹏学习中心做论文加260046902
年级专业:
0409级电子信息工程
学生姓名:
姜海涛学号:
0451480145
指导教师:
韩亚军职称:
讲师
导师单位:
重庆信息工程专修学院
中国石油大学(华东)远程与继续教育学院
论文完成时间:
2007年12月1日
中国石油大学(华东)现代远程教育
毕业设计(论文)任务书
发给学员姜海涛
1.设计(论文)题目:
机器人语言对话系统的设计
2.学生完成设计(论文)期限:
2007年11月1日至2007年12月1日
3.设计(论文)课题要求:
要求题材新颖专业,所设计课题能解决实际情况,阐述清楚流畅,论点清晰,要求围绕中心,逻辑性推理强,涉及他人观点请注明出处,对本设计有全面的论证。
4.实验(上机、调研)部分要求内容:
在课余时间充分利用网络资源和各种参考书籍,做出草稿,再利用所学的电路设计软件和各种各样的画图软件,去设计图形。
格式严格按照学校规定排序。
5.文献查阅要求:
确保文献真实可用,具有教强的理论联系实际方案,引用时应该尊重原作者,必须标注引用出处,本文章建议参考文献:
CORBA技术及其应用,论文引用不宜过多过繁复,要求题材新颖,有教强的创新的角度。
6.发出日期:
2007年11月1日
7.学员完成日期:
2007年12月1日
指导教师签名:
学生签名:
摘 要
所谓基于Web的机器人(我们称之为网络化机器人)远程控制就是将机器人构建在Internet的一个Web站点上,操作人员通过Web浏览器(如NetscapeNavigator或MicrosoftIE)对其进行远程控制。
它首要的特点在于它的开放性,以超文本传输协议(HTTP)作为机器人系统的标准通信协议,任何人在任何时候和任何地方,只要能连上Internet,就能实现对远程机器人的控制,因为Internet上的任何站点均可以通过该协议访问到连接在Internet上的机器人,而且普通用户不必了解机器人复杂的操作原理也能进行控制。
其次,Web浏览器可以提供生动友好的人机界面,因为浏览器可以支持各种格式的文件,如超文本、动画、音频和三维图像,同时能够处理各种媒体文件的交互式操作,如可以用鼠标操作由VRML描述的3D对象。
第三,使得为完成某一任务而使用分布在Internet上的不同的软/硬件资源成为可能。
提出这种观点在于参考了纵多远程控制软件的实现,和深入实习生产车间所遇到问题而改建。
关键词:
internetweb网络化机器人HTTP
目录
摘 要i
目录ii
第1章前言1
第2章网络化机器人及其控制方式3
2.1直接控制(DirectControl)3
2.2间接控制(IndirectControl)3
第3章CORBA技术分析4
第4章基于Web的机器人的系统结构7
第5章系统实现9
5.1 用户界面设计9
5.2 Web服务器的实现机制10
第6章结论19
致谢20
参考文献21
第1章前言
随着计算机网络的迅速发展和机器人应用的逐步推广,对远程机器人进行有效监控已经越来越受到人们的关注。
如今,Internet几乎无处不在,它极为方便地为人们提供了各种各样的信息和资源。
而WorldWideWeb(简称Web)是以一个基于Internet的全球连接的、分布的、动态的、多平台的交互式超媒体信息系统,它使得计算机能够相互传送基于超媒体的数据信息。
因此,人们自然想到将机器人远程操控系统建立在Web上,我们称之为基于Web的机器人系统。
事实上这种思想由来已久,其发展历史和研究现状见参考文献[6]。
构件网络化机器人的远程控制,既在运用现代INTERNET技术及各种现代化计算机技术和PLC编程技术,实现在异地对机器人系统的控制。
而且它简单的操作方式,脱离的复杂的机器,只要经过很短时间,可以让任何人在任何地点进行各种复杂的操控。
本文将提出用集成工具CORBA来构建基于Web的机器人系统。
CORBA以ORB(ObjectRequestBroker)为中间件来建立对象间的Client/Server联系,是远程过程调用的面向对象技术的扩充,它使得对象间能够相互通信,而不用关心对方的具体位置、编程语言及操作系统。
第2章网络化机器人及其控制方式
Web机器人就是用户通过Internet访问连接机器人的Web站点,远程控制机器人。
我们之所以选择Internet作为通信介质,原因在于以下两点,其一,WorldWideWeb以及与之有关的工具如HTML、VRML、Java等为在人机界面方面的进一步研究提供了很大的空间。
其二,Internet在进行机器人远程控制研究方面提供了经济、便捷的可视化环境。
机器人的远程控制基本上可以分为两类:
直接控制和间接控制。
2.1直接控制(DirectControl)
在这种控制方式下,由操作人员完全控制机器人,向机器人的某些端口直接发送运动指令函数以完成某项任务,而机器人控制器在远端。
显然,这种控制方式对操作人员的要求比较高,需要机器人底层指令和编程语言。
2.2间接控制(IndirectControl)或称为监督控制的控制方式(SupervisoryControl)
在这种控制方式下,操作人员预先在一个由计算机仿真机器人的虚拟环境中互动地将所需任务(如行走路径)规划好,然后再将其送到远端的实际机器人控制器中执行。
也就是说,在实际执行任务时,远端的操作人员置于控制结构闭环之外,从而减小了因传输时延对整个系统的影响。
远程操作人员只是发送目标任务或很小一部分相关的必需指令给远端,而任务具体由机器人自治完成同时,监控回路向操作人员反馈有关的传感器信息,如将现场摄像机的图像以一定的格式返回给操作人员。
显然,这种控制方式充分利用执行端的本地智能,具有较强的容错和纠错能力同时它还可以使远端操作人员不必持续监控机器人的工作,从而可以减轻操作人员的工作强度因此,后面提出的方案基于该控制方式。
第3章CORBA技术分析
公共对象请求代理体系结构CORBA(CommonObjectRequestBrokerArchitecture)是由对象管理组OMG组织制定的一种标准的面向对象应用程序体系规范。
CORBA是为了实现分布式计算而引入的。
与面向过程的RPC(RemoteProcedureCall)不同,CORBA是基于面向对象技术的,它能解决远程对象之间的互操作问题。
微软的COM/DCOM、COM+也能解决这一问题,但它是基于windows,虽然在Solaris等有限的数个操作系统下也能实现,但只有在微软的windows下才能运行得更好。
而CORBA是真正跨平台的,平台独立性正是CORBA的初衷之一。
另一种能做到平台无关性的技术是JavaRMI(RemoteMethodInvocation),但它只能用Java实现。
而CORBA通过一种叫IDL(InterfaceDefinitionLanguage)的接口定义语言,能做到与语言无关,任何语言都能实现CORBA组件,而CORBA组件也能在任何语言下使用。
换言之,CORBA是异构平台下独立于实现语言的对象互操作模型。
CORBA的对象管理体系结构OMA(ObjectManagementArchitecture)是由对象请求代理ORB、对象服务、应用对象、领域接口和公共设施组成,它们各自的功能及OMA体系结构的详细分析见参考文献[8]。
其中ORB是通信基础,也是CORBA规范的核心部分。
使用ORB,客户可以调用服务器的对象或对象中的应用,被调用的对象不要求在同一台机器上。
由ORB负责进行通信,同时ORB也负责寻找适合于完成这一工作的对象,并在服务器对象完成后返回结果。
单个的ORB结构如图3.1.1所示。
图3-1ORB体系结构
CORBA上的服务用IDL描述,将被映射为某种程序设计语言如C或Java,并且分为两部分,在客户方叫Disturb(桩),在服务器方叫IDLSkeleton(构架)。
两者可以采用不同的语言。
服务器方在Skelton的基础上编写对象实现(ObjectImplementation),而客户方要访问服务器上的方法,则要通过客户桩(Stub)。
而双方又要通过对象请求代理ORB(ObjectRequestBroker)总线通信。
对于CORBA对象服务,OMG已经在ORB核心软件总线基础上规范了一系列的CORBA对象服务,以便采用软件重用技术帮助用户快速、可靠地解决特定领域的分布式计算问题。
对象实现在执行客户请求时,通过对象适配器OA获取ORB的服务。
OA是对象实现访问ORB服务的主要通道,它位于ORB核心通信服务上,为实例化的服务对象提供运行环境,接收请求并传送给服务对象;为服务对象分配对象ID(即对象引用),并将实现对象注册到实现库中。
实现库包含了允许ORB查找和激活对象实现的相关信息。
实现库是ORB进行对象匹配的场所。
ORB接口则是为客户方和对象实现获取少数几个局部性的基本服务而设,它不依赖于对象实现接口。
CORBA给出了一个通用的互操作体系结构,它提供了两种ORB间的互操作协议:
GIOP和IIOP。
GIOP(GlobalInterORBProtocol)是一种通用协议,它为ORB之间的通信规定了一系列标准传输文法、信息和格式。
IIOP(InternetInterORBProtocol)定义了如何在TCP/IP传输上构建GIOP。
CORBA规范提供的软件总线的机制,使得任何应用程序、软件系统或工具只要具有与该接口规范相符合的接口定义,就能方便地集成到CORBA系统中,而这个接口规范独立于任何实现语言和环境。
第4章基于Web的机器人的系统结构
采用间接控制方式设计的一个基于Web的机器人远程控制系统如图4.1.1所示。
图4-1基于Web的机器人系统结构
这是一个典型的三层Client/Server结构。
第一层是浏览器,客户通过浏览器访问系统而无需安装任何软件,用户注册、登录等界面由HTML和Script语言结合完成,主控界面采用JavaApplet。
第二层是Web服务器,由HTTP服务器和图像服务器组成,作为用户服务和数据服务之间的桥梁,其中HTTP服务器的主要任务:
一是通过与数据服务器的连接完成对用户的管理,包括注册、登录及身份认证等;二是维护用户队列,负责控制权的分配;三是与机器人服务器通信,发送客户指令并返回指令的执行结果。
图像服务器处理有关图像的HTTP请求,它通过图像采集卡抓取图像,并可以根据用户的需求调整摄像机的旋转角、放大倍数或向用户返回不同尺寸的图像。
第三层是机器人本地控制系统,包括数据服务器和机器人本地系统。
数据服务器主要储存用户的注册信息、登录访问情况等数据信息。
机器人本地系统由机器人服务器、机器人控制器及机器人本体等组成。
系统的原理为:
客户通过Web浏览器(如Navigator或IE),访问远端连有被控机器人的Web服务器,通过客户机上显示的操作界面发送指令。
Web服务器将收到的指令经协商确认后交由机器人的控制器执行,执行的过程和结果通过传感器和摄像机,返回到机器人服务器,并将其转化为HTML格式,发送到客户端显示。
第5章系统实现
本系统采用Java技术构建,主要有以下几个关键问题:
(1)用户界面的设计;
(2)Web服务器的实现机制;
(3)基于CORBA/IIOP的Web服务器与机器人服务器间的通信机制。
5.1 用户界面设计
在传统的机器人遥控操作中,操作人员都是受过培训的专业人员,对用户界面也可以设计得很“专业”。
但是基于Web的远程控制机器人面对的是具有不同技术基础的Web用户,操作界面应该简洁明了,方便易用,而且应该支持不同层次用户的使用要求,如一些高级用户能够实现比较高级或底层的操作,另一方面界面还需具有一定的兼容性和平台独立性。
最早的基于Web的机器人控制系统的客户端界面多采用HTML语言设计,用户通过填写HTML表单或点击工作区的图像发送指令,功能较为局限。
当涉及多步移动时,需要利用到脚本语言(如JavaScript),那样可以提供客户端的部分数据处理能力,降低了与服务器的通信代价。
本系统用户主控界面采用JavaApplet实现,在客户端Web浏览器中运行的JavaApplet同时进行着两个线程,其一是接收操作员的各种操作命令并根据其内容将命令传递给机器人;其二是获取系统的当前状态并将它综合地反馈给操作员。
为了实现以上功能,我们将人机接口分解为五个模块:
接口表示模块、监视模块、会话模块、操作模块和通信模块。
其中,接口表示模块接收由操作员给出的命令,同时显示机器人系统的当前状态;监视模块的功能是收集系统的各种信息并综合为所需的监视状态;会话模块负责协调操作人员和机器人之间的信息交互;操作模块将命令解释为通信模块可以接收的数据格式。
通信模块的功能是将来自各模块的信息转换为符合特定协议的数据格式。
5.2 Web服务器的实现机制
当前基于Web的远程机器人控制站点的HTTP服务器大多采用CGI编程设计。
CGI的功能是在超文本文件和服务器主机应用程序之间传递信息。
CGI虽然能够满足大多数Web机器人站点的需要,但存在明显的局限:
一个CGI程序只能处理一个客户请求,因此每个客户请求都要激活一个新的CGI进程,当用户增多时会挤占大量的系统资源,使得执行效率降低,而且一些对CGI进行的扩展所得到的性能提高也很有限。
Java技术的出现及服务器方应用构建JavaServlet的推出进一步推动了Web计算的发展,JavaServlet将是CGI一个好的替代品。
JavaServlet是位于服务器端的一种独立于平台和协议的Java应用程序。
Servlet可以生成动态的页面,是Java语言在Web服务器端的一种应用技术。
形象地说,Servlet与Web服务器的关系类似于Applet与Web浏览器的关系,可以认为Servlet是没有前端界面Applet,与Applet不同的是,Servlet运行在服务器端,因此它拥有普通Java应用程序一样的权限。
由于JavaServlet在性能、可移植性和代码重用性等方面比CGI有着显著的优势,因此在不久的将来,Servlet有可能取代CGI。
JavaServlet支持“请求”和“应答”编程模式。
客户端服务器发出请求时,服务器接收该请求并将请求发送给Servlet,Servlet接收该请求并进行处理,向服务器返回应答,服务器再将应答回送给客户端。
对常用的HTTP请求GET(该操作仅仅允许用户从HTTP服务器上取得资源)和POST(该操作包含了在必须通过此Servlet执行的请求中的数据),Servlet调用相应的doGet和doPost方法来处理。
方法doGet和doPost的缺省实现均返回一个HTTP的BAD_REQUEST错误。
DoGet格式如下:
ProtectedvoiddoGet(HttpServletRequesterquest,HttpServletResponse)
ThrowsServletException,IOEcaption;
doPost的格式如下:
protectedvoidsPost(HttpServletRestquipsterquest,HttpServletResponse)
throwsServletException,IOEException
doGet和doPost均以HttpServletRestquest对象和HttpServletResponse对象为参数。
如在提供用户登录的HTTP表单中,指定POST方法,当相应的Servlet接收请求时,在doPost方法中使用HttpServletRequest对象获得请求中的各参数,如用户名和用户密码,经过数据库验证后,利用HttpServletResponse对象获得输出流,即可将验证结果、队列信息、等待或者控制界面通过输出流向客户端返回。
用户控制界面的Applet同Servlet的通信采用了GET方法。
Servlet流程示意图如图5.2.1所示。
图5-2Servlet流程图
用户注册信息的存储及成员用户身份的验证均要通过Servlet与数据库之间信息的交换,系统采用SQLServer2000作为数据库平台,JDBC(Javadatabaseconnectivity)保证了Servlet与数据库之间的数
5.3基于CORBA/IIOP的Web服务器与机器人服务器间的通信机制
CORBA提供了一种交换数据和发现服务的机制,它以ORB为中间件进行对象之间的对话,ORB之间的通信遵循IIOP协议。
基于CORBA/IIOP的系统的分布式结构如图5.3.3所示,作为JavaClient的Servlet在4.2部分已经说明,机器人服务器端的CORBA对象服务可以简化为CServer程序,它包含了运动学逆解、插补计算和轨迹规划等服务程序。
JavaClient和CServer应用程序的开发均采用由东南大学计算机系自行研制开发的CORBA编程工具ORBUS。
服务接口的实现关系如图5.3.1.
图5-3基于CORBA的系统分布式应用结构
图5-3服务接口的实现关系
另外,系统采用串行口与网线交互,就可与系统相连。
系统原理
图5.3为系统原理图框图以及主要操作流程。
图5-3系统原理图及主要操作流程图
系统采用串行口与外界交互,任何具有标准串口的设备均可与本系统相连。
欲发音汉字的国标码(GB码)由串口送入MCU,MCU将其映射为Flash存储器地址表中对应项的地址,然后根据此地址取得对应项中的命令字,由MCU根据该命令字读取该汉字发音对应的语音数据,连续读出语音数据并以游程码解码算法解码后,按照语音采样code段在低速的Flash中运行,在节省空间的同时,却牺牲了时间。
本文介绍了基于嵌入式处理器的操作系统引导方法,重点研究嵌入式系统的引导模式以及不同类别的引导方法。
以在MPC860C处理器上引导CRT0SII操作系统为例,阐述了调试模式和固化模式下引导代码的构成、作用以及执行方式,并对不同引导模式下的时空效率的折衷进行了分析。
最终,借助BDI2000仿真器对编写的引导代码进行调试,成功实现了调试模式和固化模式下操作系统的引导。
后续工作包括:
继续研究在不同硬件平台上的操作系统引导方法,例如最流行的ARM、X86系列;在同一平台上,可以研究不同操作系统的启动方法,例如嵌入式Linux、Vxworks、WinCE等。
同时,可以引入数学模型对时间、空间性能进行量化分析,以便在不《电子技术应用》2oo5年第2期同环境下采取比较合适的引导方案。
时的固定速率通过D/A转换和功率放大播放。
本文中语音采样速率为11025B/s。
为满足应用需求,本文首先构建易于快速解码的语音库,根据特定Flash存储器的存储格式,以快速多重查找表寻址及命令字预先存储的方式组织并存储在Flash存储器中,以满足语音播放的实时要求。
同样,MCU的代码也要优先考虑速度而牺牲诸如模块化、可读性方面的要求。
最后,出于实用性考虑,系统中需加入足够的输入缓冲区支持,以满足一次输入多个汉字或整句的要求。
2原始语音数据的采集和处理本系统共采集了1335种发音,内含1306个汉字发音,26个英文字母发音及3个停顿音,语音采集卡AD转换速率11025B/s,分辨率8位,样本值域0—255,静默值为80H。
原始语音以WAV文件的格式保存在PC机中。
是“哎”音样本的时域波形。
所有的采集样本除具有不同的波形包络外,均具有大体相同的结构,即一个完整的汉字发音均由前后两个静音部分和中间的发音部分组成。
静音的采样值绝大多数为80H(一些轻微扰动可视为录音过程中的噪声,但本文根据上述静默值及边缘值的分布特点,提出了一种改进的游程编码用于语音数据的压缩,具体做法是:
用00H代表游程压缩起始码,其后是被编码字符,再下一个字节是被编码字符的重复码,如:
8080808080可以表示为008O05。
显然,游程长度小于等于3时没有编码的必要,图5-4解码游程图
因而不会出现值为00H、OlH和02H的重复码。
如上所述,在原始语音文件中,00H、01H这些边缘值是基本不出现的。
因为大量出现这些边缘值即意味着语音采集系统的动态范围设置错误。
尽管如此,为确保原始语音文件中没有“多余”边缘值,需要将语音文件略做处理,将可能存在的00H和01H都改为02H,显然这样的处理并不会影响语音的实际播放效果。
处理后的00H、01H即可作为特殊控制字符使用。
编码前,1335种原始语音样本缩的大小为14978622字节,压缩后为7767112字节,压缩比超过50%。
该语音库已经可以装入容量为8M字节的Flash存储器中。
3语音库的存储结构
本文以8Mbitx8位NAND型Flash存储器K9F6408U0B为例,描述本系统语音库的存储结构。
语音库的基本内容分为两部分:
前端是地址查找表,其后是压缩后的语音数据。
地址表中,每4个字节代表一个地址项。
GB2312汉字编码字符集中每个汉字在地址表中都有一个对应项,其内容指向该汉字对应读音的语音数据起始地址。
GB码字符集中共有94个区,每区94个字符,总计8836个汉字、英文字母和其它符号,其中实际使用了7445个,余下的作为预留区。
本系统亦保留了这些预留区,以利于将来的扩充。
这样,地址表的大小为94x94x4=3534字节。
语音数据区共存储1335个发音,采用游程编码压缩存放,并在每段语音数据结尾添加01H作为结束控制符。
对不同的Flash存储器,语音库需做一些针对性的处理。
对于K9F6408UOB而言,要对其C区进行专门的处理。
该芯片中,每个页面(Page)都有A、B、C三个区。
其中A、B区各256字节,而C区仅有16字节。
本设计中没有用到C区,因而在制作写入Flash的二进制语音库文件时必须注意对C区进行空白码(FFH)填充。
考虑C区填充后,地址表对应的二进制语音库文件大小的计算方法改为:
512x69+16=3534,表示当3534字节只占据A区和B区时共需69个页面,多出16字节。
这意味着有69个C区需要填充,即写入Flash的地址表的实际大小应该是3534+69×16=36448。
相应地,语音数据区需要进行同样的处理。
在PC上制作写入Flash的数据文件时,首先将地址表放在最前面,其后将压缩后的语音文件逐一写入,并将每个文件的起始地址转换成对Flash存储器操作的命令字写入地址表相应项中,每写完一个文件要加上O1H结束码,并在写入过程中完成对C区的填充。
在综合完1335个语音文件、地址查找表、C区填充码及文件结束码之后,得到Flash存储器的二进制映像文件,其大小为8047776字节。
写入后,Flash中尚余近333KB可用空间。
联合地址表中的预留项,可用于对系统语音库做进一步的扩充。
上述语音库的存储结构见图5.3.5
图5-4语音库存储结构
语音库生成时已由PC机将语音数据的起始地址转换为操作命令字并存储到了地址表对应项中,即大部分的计算及时序控制操作在使用PC制作Flash的二进制映像文件时已经完成,因而避免了系统运行中的大量计算,从而保证了
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 机器人 语言 对话 系统 设计