英语原文共 17 页，剩余内容已隐藏，支付完成后下载完整资料
- 介绍
移动机器人正在逐渐获得商业应用的动力，并成为不同领域研究的手段。 机器人的初始设计使用感应计划行为范例来控制机器人，例如Albus等（1987）和Barbera et al（1984）。 今天，人们普遍认识到，设计机器人最有效的策略是使用混合体系结构，在审议和反应性控制之间有成功的协调。 在最近的文献中报道的大多数机器人中使用这种架构，例如RAP（Firby，1989），Xavier（Simmons，1994），Saphira（Konolige和Myers，1996）和3T（Bonasso等，1997） 。
鉴于对基本架构原理的一般性协议，人们可能希望通用的软件基础是可用的，并且这样一个系统用于实验室和技术转让的算法交换。 不幸的是不是这样。 对文献和商业平台的一系列的快速评论显示出可以使用各种不同的软件体系结构。 典型的架构包括来自RWI的移动性（Real World Interface，1999），IS-Robotics / SRI的Saphira（Konolige和Myers，1996），TeamBots（Balch，2000），RAP（Firby，1989），Xavier（Simmons，1994）和BERRA（Lindstrouml;met al，2000）。 然而，使用单一的通用架构将具有巨大的潜力，人们不禁想知道为什么这么多的架构可用，这些架构的特点是什么？
可以从每种架构中学到什么，并且有可能执行一个通用架构的综合，还是采用太多不同的方法来合成单一的统一架构？ 在本文中，移动机器人架构的总体要求根据要考虑的尺寸和控制，模块化，软件工程和运行时性能的基本要求进行了概述。 使用这些要求，可以考虑最常用的架构在多大程度上符合这些要求。 此外，可以对统一架构所需的基本方法得出一些结论。
2.混合的体系结构
传统上，机器人软件系统的架构是分层式的，受到时间的AI研究的高度影响。 这意味着具有世界精细模型的系统，使用传感器来更新此模型，并根据更新的模型得出结论。 这通常被称为感觉计划行为模式。 这些系统的表现不佳，部分原因是世界建模困难，部分原因在于传感器不足。
1987年，罗德尼·布鲁克斯（Rodney Brooks）通过提出一种基于纯粹反应行为的架构，革新了该领域，很少或根本没有世界知识，参见例如Brooks（1987）。 然而，纯粹的反应性方案在执行复杂任务时表现不佳。研究人员如Arkin（1990）中的共同之处在于共同作用。
2.1层次
混合系统通常被建模为具有三层; 一个故意的，一个反应的和一个中间层。 底层反应层对原始或提取的数据进行重复计算。 这些计算应在近乎实时的情况下进行，以确保安全性。 该层中的模块通常是无状态的。 最重要的层次是处理与人类操作人员的规划，本地化，推理和互动。 中间层，通常称为定序器层或监控层，桥接故意层和反应层之间的差距。
混合动力系统的活性层往往是行为的基础。 这意味着子系统由单独的行为,每个行为都有一个指定的非复杂的任务。 的行为代表了一个从传感器到执行机构紧密耦合。 活性层还包括传感器和致动器。 传感器产生的数据传递给一个或多个并发运行的行为。 传感器融合模块可以从两个或两个以上的传感器提取更高级别的数据。 由于一些行为可以活跃的同时,必须融合成一个单一的结果脆致动器的命令。 这样做是在一个驱动器命令融合模块。 一个通用的模型混合经过深思熟虑的。架构图1中可以看到。
2.2混合体系结构的例子
混合故意的概念架构通常归因于阿金(1986、1987)。 实现的方法是光环架构。 光环有一个等级系统组成的任务规划、空间推理程序,计划定序器加上一个模式控制器形式反应系统。 一个模式管理器控制和监视行为流程执行期间。 每个行为与感知模式提供需要的刺激行为。 行为是总结和规范化的控制命令在一个特殊的过程,然后发送到硬件。 正如我们看到的,这种布局图1的匹配很好。
泽维尔系统(西蒙斯,1994;奥沙利文et al .,1997)一直在卡内基梅隆大学开发的。 系统由四层与特定功能:任务规划、道路规划、导航和避障。 前两个适合的顶层通用体系结构。 虚拟传感器对应传感器融合模块。 不需要驱动器命令融合,因为只有避障的命令的执行机构。
3 t的架构(Bonasso et al .,1997)系统通用体系结构对应很好。 原则将模块层是基于四个参数,时间,带宽需求,从任务和可修改性。 技能的活性层包含映射到通用的行为模型。 中间测序层操作通过使用说唱(Firby,1989)。
Saphira的开发者,参见5.1节,建筑没有选择来说明他们的系统层。 一些无论如何映射到通用模型。 最近执行机构的反应行为将我们重新适应 活性层。 然而,传感器模块提供数据,提取高阶数据插入到本地感知空间有限合伙人。 有限合伙人所使用的其他模块,不管他们的时间或数据抽象层。 我们可以看到在图4中,也有目标和导航行为。 前我们有PRS-lite和拓扑规划师符合故意层。
BERRA架构,参见5.3节,就像3 t,相似的通用模型。 分层但是更多的是一个描述性的问题,而不是像3 t的基本架构。 传感器和传感器融合模块被称为资源。 熔化炉控制器代表执行机构和执行机构命令。 中间一层一层被称为任务执行。
TeamBots建筑,5.2节,没有真正的深思熟虑的层。 人们可以把大部分的粘土类在活性层。 粘土还包含测序方法的任务。 这将符合中间层。
3.一个体系结构的维度
为了定义和设计一个共同的架构对于移动机器人应用程序必须考虑底层系统的主要特征。
可以简要总结基本要求为:
——机器人硬件抽象
——可扩展性和可伸缩性
——有限的运行时开销
——致动器控制模型
——软件特点
——工具和方法
——良好的文档记录
下面将更详细地讨论这些需求澄清的基本要求和现有系统的评价提供依据。
3.1机器人硬件抽象
可移植性是一个非常理想的设计目标,因为硬制品通常是可能发生变化。 便携式建筑应该提供的抽象硬件传感器和制动器等。 尽管机器人制造商有不同的硬件解决方案,最根本的基础通常仍然是相似的。 在最低层次上,一个或两个电机控制驱动和转向。 通常声纳环和保险杠。
制造商通常会提供一个API,允许程序员使用更高级别的命令绝对移动或速度等模式。 架构应该封装这些硬件具体命令到一个通用的命令集。 理想情况下的硬件特征应该保存在一个文件在软件源。 那么这个文件是唯一一处变化,当系统转移到新的硬件。
应在不同的抽象级别。 例如,在同步传动系统上,上级命令将被转换为单独的低级命令驱动电动机和控制电机。 这样,程序员可以选择水平 适合他的应用程序编程。 参见图2层次抽象的一个例子。
这种抽象同时使它更加难以利用专用传感器和硬件,因此抽象和效率之间的平衡。 但少数情况下,效率应该牺牲因为软件通常更昂贵,比硬件。
3.2可扩展性和可伸缩性
可扩展性是指这里的支持添加新的软件模块以及新的硬件系统。 这是一个非常重要的方面,因为机器人系统研究环境中倾向于发展方面的硬件和软件。 添加新的传感器都是一个标准的活动在这样的环境中。 在软件方面,以行为为基础的系统中添加新的行为也是一种常见的做法。 可伸缩性是通过使用高效沟通和计划周详的数据流。 避免瓶颈和不必要的约束也是重要的。 可伸缩性也 在架构层面,通过例如提供几个主机方式分发流程。
3.3运行时开销
运行时环境是由很多因素,包括
1 内存需求
2 cpu需求
3 频率
4 端到端延迟。
在这种背景下,频率是指控制回路的数量底层每秒运行。 端到端延时是指传感器的最大时间阅读给影响硬件驱动器命令。
3.4致动器控制模型
在以行为为基础的系统中,个人行为的输出需要融合,以产生一个清爽的致动器的命令。 这可以通过多种方式进行。 不同种类的简单叠加不过是最普遍的。
机器人的执行机构控制模型最终定义了机器人将如何行动。 一个快速和平滑的行为通常是可取的。 不幸的是,这一领域已成为一个宗教信仰的来源。 有些主张以行为为基础的方法,模糊逻辑的方法,等等。 注意尽管大多数这些模型不排除别人但可以在一个系统一起使用。
3.5软件特点
必须健壮和可靠的机器人系统,必须准备处理意料之外的情况。 系统必须提供一个框架的体系结构 强大的集成所需的技能。 为研究和开发的目的,一个架构应该提供支持:
——一个概念性框架的可重用性
——明确区分的能力水平
——简单的集成的新组件和设备
——简单的调试
——原型
以下是特征(Gabriel,1993),应考虑为一个通用的软件系统。 这些特征的相对权重是一个争论不休的话题。
——设计必须简单,在实现和接口。
——设计必须在所有的方面是正确的。
——保持设计不能一致。
——补充,设计必须覆盖尽可能多的重要的情况下是可行的。
此外,好的架构是基于正式的理论基础。 是非常重要的,程序员将开发的系统,得到一个清晰的架构视图。 否则他们可能计划系统远离最初的想法,结果可能会失去它最初的凝聚力。 可选地,用户可以提供一个替代的简化视图。
3.6工具与方法
构建软件架构系统时可以使用各种工具。 应该使用标准化（由诸如ISO，ANSI，OMG，POSIX等）的工具进行标准化，因为专有工具往往是短暂的，而且通常都有怀疑。 如前所述，硬件制造商提供访问硬件的基本界面。 这很可能是一个C语言API。 在之上
这个函数或类应该被构造来封装和分离硬件特定的。这些功能可以由更高层次的功能来形成一个强大的词汇表。
随着面向对象编程的出现，可编程便携式和可重复使用的模块。这种趋势也可以在机器人中看到。 早期的系统几乎完全以C语言编程，除了使用LISP的AI社区外。 现在，基于OO的语言（如C 和JAVA）是最流行的工具。 下一步将使用组件技术，如CORBA（见下文）。
架构的管理理念和原则应以图形方式可视化。 单一的图形通常可以解释说明文本的页面.UML（Booch等，1999），统一建模语言已经成为设计和可视化的标准工具。 UML的优势在于它支持允许自动合成，分析和代码生成的工具。
机器人系统中的关键部件是可靠且高效的通信机制。 模块需要交换数据和事件。 运行时监控和错误处理也非常重要。 由于在某些系统中，进程可以分布在多台计算机上，因此主机到主机的通信应该是透明的。 这需要一个可以帮助其他对象找到彼此的代理对象。 最低要求是能够在运行时激活和停用模块。 互连的运行时重新配置也应该是可能的。 对于可扩展性的原因，动态对象和流程调用也是非常需要的。现代工具有工厂模式，有助于此。数据传输可以以拉或推的方式启动。
在过去，开发了几个中间件标准，如套接字，远程过程调用（RPC），TCX（Fedor，1993）或ACE（Schmidt，1994）。 最近，出现了一些新的有趣的框架。 这些将分布式编程的问题提升到更高的抽象层次。 最着名的是CORBA，ActiveX和EJB.CORBA（通用对象请求代理体系结构）（OMG，2001）是由对象管理组管理的标准。 微软的ActiveX是一套的基于COM（组件对象模型）的技术。企业Java Bean（EJB）是一个像CORBA这样的规范。 所有这些技术可以相互交互，他们都遵守接口描述语言（Interface Description Language，IDL）。 它们提供组件模型和集成框架，这意味着我们可以将它们用于交互以及系统描述。
3.7文件
为了使架构取得成功，这与本地使用不同，文档必须严格。 以下部分应在适当的文件中提供。
- 建筑背后的哲学。
- 程序员指南。
- 用户指南
- 一个架构参考手册，用于描述每个级别上的API。
- 代码文档。
最困难的部分是将文档保留在系统中。 可以通过多种方式执行文档。
- 印刷手册。
- 网页。
- UML /类图。
- 来源中的评论。
- Javadoc，Doxygen
这些的组合是非常可取的。 JavaDoc / Doxygen实用程序具有嵌入到代码中的优点。 这样，文档始终是最新的，即使代码中的更改仍需要相应的注释更改。这些文档工具非常适用于代码文档，但无法捕获系统的整体概念模型，因此需要组合文档策略。
- 研究目的
根据上述方面，本研究确定了一系列常见结构的特征。 可以得出可以帮助设计新架构的结论。
要牢记的一个重要问题是，必须将架构与架构的实现分开。 然而，这种研究永远不能在理论架构上执行，所以我们真正的比较是架构的实现。 理想情况下，我们应该有各种各样的实现，以便做出更准确的判断。
这项研究的另一个目的是为即将在可用的机器人系统之间进行选择的读者提供指导。 以下是已解决的问题的例子：
- 抽象模型
- 控制方法
- 操作系统支持
- 语言API
- 程序员效率
- 运行时效率
- 软件开销（代码大小）
- 工具和方法
- 文件
<p
全文共6865字，剩余内容已隐藏，支付完成后下载完整资料</p
资料编号：[142688]，资料为PDF文档或Word文档，PDF文档可免费转换为Word
以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
