移动机器人体系结构评价外文翻译资料

 2022-03-21 09:03

英语原文共 17 页，剩余内容已隐藏，支付完成后下载完整资料

移动机器人体系结构评价

摘要 本文对几种成功的移动机器人软件体系结构进行了比较研究。目的是为未来设计一种新的机器人架构收集经验。三种体系结构，Saphira，TeamBots和Bera被更仔细地研究。评估了诸如可移植性、易用性、软件特性、程序设计和运行时易用性等品质。为了得到真实的评价，所有的体系结构都是在一个通用的硬件机器人平台上实现的。每个系统都有一个简单的参考应用程序。对实现这一目标所需的所有步骤进行了讨论和比较。运行时数据也被收集起来。最后得出结论，并在此基础上给出了一种新的体系结构的草图。

关键词：机器人，架构，比较，服务机器人，软件

1.导言

移动机器人技术在商业应用和各种领域的研究中都在逐渐获得发展势头。机器人的初始设计采用了一种感知计划-行为范式来控制机器人，例如Albus等.(1987年)和Barbera等人(1984年)。。如今，人们普遍认识到，机器人设计最有效的策略是采用混合的、深思熟虑的结构，在考虑和反应控制之间有着成功的协调。最近文献报道的大多数机器人都使用这种结构，例如RAP(Firby，1989年)、Xavier(Simmons，1994年)、Saphira(Konolige和Myers，1996年)和3T(Bonasso等人，1997年)。

鉴于对基本架构原则相当普遍的一致意见，人们可能会认为有一个共同的软件基础，这种系统被用于在实验室之间交换算法和进行技术转让。不幸的是，情况并非如此。快速回顾文献和一组商业上可用的平台，就会发现各种各样的不同的软件原型。 技术是可行的。典型的体系结构包括RWI(Real World Interface，1999)、Saphira(IS-Robotics/SRI)(Konolige和Myers，1996年)、TeamBots(Balch，2000年)、RAP(Firby，1989)、Xavier(Simmons，1994)和Berra(Lindstregrave;om等人，2000年)的移动性。然而，使用单一的公共体系结构将具有巨大的潜力，人们不禁要问，为什么会有这么多的体系结构可用，这些体系结构的特点是什么？

从这些体系结构中可以学到什么，是否存在对公共体系结构进行综合的不敏感性，或者所采用的方法是否太过不同，以至于无法综合单一的统一的体系结构？本文从尺寸和控制、模块化、软件工程和运行时性能等方面概述了移动机器人体系结构的总体要求。使用这些需求，可以考虑最常用的体系结构在多大程度上满足这些需求。此外，还可以得出一些关于统一数据库体系结构所需的基本方法的结论。

2.混合故意结构

传统的机器人软件系统的体系结构是层次式的，受到当时人工智能研究的高度重视。这意味着一个系统拥有一个复杂的世界模型，使用传感器更新这个模型，并根据更新的模型得出结论。这通常被称为“感觉计划-行动范式”。这些系统的性能不太好，部分原因是在世界建模中存在差异，部分是因为过于依赖于不充分的传感器。

1987，罗德尼·布鲁克斯提出了一种完全基于反应行为的体系结构，几乎不了解或根本不了解世界，从而彻底改变了经济学，参见布鲁克斯(1987年)。然而，纯反应模式在执行复杂任务时表现不佳。自那时以来，混合方法在研究人员中很常见，例如Arkin(1990)。

2.1层次

混合系统通常被建模为三层：一层是故意的，一层是反应性的，一层是中间层。底层反应层对原始或提取的数据进行重复计算。这些计算应在几乎实时进行，以安全关键考虑。该层中的模块通常是无状态的。顶层负责规划、本地化、推理和与人类操作人员的交互。中间层，通常称为排序器层，或监督层，在故意层和活动层之间架起桥梁。

混合系统的反应层通常是基于行为的。这意味着子系统由独立的行为组成，其中每个行为都有一个特定的非复杂任务。这些行为代表了传感器与执行器之间的紧密耦合。反应层还包括传感器和执行器。传感器产生传递给一个或多个并发运行行为的数据。传感器融合模块可以从两个或多个传感器中提取更高层次的数据。由于多个行为可以同时活动，因此必须将结果融合到一个清晰的执行器命令中。这是在驱动器命令融合模块中完成的。图1中可以看到一个通用混合故意体系结构的模型。

Xavier系统(Simmons，1994年；Olsquo;Sullivan等人，1997年)是在CMU开发的。该系统由任务规划、路径规划、导航和避障四层组成。第二种类型将进入通用体系结构的顶层。虚拟传感器对应于传感器融合模块。由于只有避障指令才能控制执行器，所以不需要执行机构指令融合。

3T(Bonasso，1997)系统的体系结构与一般体系结构非常吻合。在这些层中放置模块的原则是基于四个参数：时间、带宽、任务的要求和可调性。反应层由映射到我们的泛型模型中的行为的技能组成。中间测序层使用RAP操作(Firby，1989年)。

Saphira的开发人员，请参阅第5.1节，体系结构没有选择用层来说明他们的系统。无论如何，都可以对泛型模型进行某种映射。最接近执行器的是反应行为，这些反应行为会被转移到我们的反应层，而传感器则将它们的数据提供给那些提取高阶数据的模块，这些模块被插入到局部感知空间LPS（Local Perceptual Space）中。LPS被其他模块使用，不管它们的时间或数据抽象级别如何。如图4所示还存在目标和导航行为。在上面，我们有一个PRS感应器和一个拓扑规划器，它将被加入到有意的层中。

BERA体系结构，参见第5.3节，与3T类似，与通用模型非常相似。然而，分层更多的是附加问题，而不是像3T中那样对体系结构至关重要。传感器和传感器融合模块称为资源。控制器既代表执行器，也代表执行器命令引信。中间层称为任务执行层。

TeamBots架构，第5.2节，没有真正的刻意层。可以将大多数黏土类放置在反应层中。黏土还包含任务排序的方法。这些都不会被转移到中间层。

3.建筑尺寸

为了设计移动机器人应用的通用体系结构，必须考虑底层系统的关键特性。我们可以把基本要求概括为：

-机器人硬件抽象化

-可扩展性和可伸缩性

-有限运行时间开销

-执行器控制模型

-软件特性

-工具和方法

-记录良好

下文将更详细地讨论这些要求中的每一项，以澄清基本要求，并为评价现有系统提供依据。

3.1机器人硬件抽象化

可移植性是一个非常理想的设计目标，因为硬件通常会发生变化。可移植架构应该提供硬件的抽象，例如传感器和执行器。虽然机器人制造商有不同的硬件解决方案，但基本基础往往是相似的。在最低的水平上，有一两个马达控制驱动和转向。声纳环和保险杠都有。

制造商通常提供一个API，让程序员使用稍高的命令，例如以绝对或速度模式移动。架构应该将这些硬件规范c命令封装成一组通用命令。理想的情况下，硬件特性应该保持在软件源中的一个单独的LE中。然后，当将系统移动到新硬件时，只有这样才能进行更改。

抽象应该在不同的层次上进行。例如，在同步驱动系统上，较高级别的移动命令将被转换为驱动电机和转向电机的单独的低级命令。这样，程序员就可以选择适合他的应用程序编程的级别。见图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社区之外。现在，基于面向对象的语言(如C和Java)是最流行的工具。下一步是使用组件技术，如CORBA(见下文)。

架构的管理思想和原则应该以图形的方式可视化。一个图表通常可以澄清解释文本的页面。UML(Booch等人，1999)，统一建模语言已经成为设计和可视化的标准工具。UML的优点在于它得到了允许自动合成、分析和代码生成的工具的支持。

机器人系统中的关键部件是一种可靠、高效的通信机制。模块需要交换数据和事件。运行时监控和错误处理也非常重要。由于在某些系统中，进程可能分布在多台计算机上，所以主机与主机之间的通信应该是透明的。这需要一个代理对象，它可以帮助其他对象找到彼此。最低要求是能够在运行时激活和停用模块.。运行时恢复连接也应该是可能的。出于可伸缩性的原因，动态对象和在需要时实时调用进程也是非常可取的。现代工具的工厂模式有助于这一点。数据传输可以以拉式或推式启动。

在过去，一些中间件标准，如套接字，远程过程调用(RPC)，TCX(Fedor，1993)或ACE(Schmidt，1994)。最近，出现了一些新的有趣的框架。这些将分布式编程问题提升到了更高的抽象级别。其中最著名的是CORBA、Active X和EJB。CORBA(Common Object Request Broker Architecture)(OMG，2001)是由对象管理小组管理的标准。微软的Active X是一套基于COM(Component Object Model)的技术，企业Java Beans(EJB)和CORBA一样是一种规范。所有这些技术都可以相互交互，并且都遵循接口描述语言(Interface Description Language，IDL)。它们提供组件模型和集成框架，这意味着我们可以将它们用于交互和系统描述。

3.7文档

为了使架构取得成功，除了本地使用之外，文档必须是严格的。以下部分应在适当的文档中提供。

-架构背后的哲学。

-程序员指南。

-用户指南。

-一个描述了每个层次上的API的架构参考手册。

-代码文档。

其中最困难的部分是使文档与系统保持同步。文档可以通过多种方式执行。

-印刷手册。

-网页。

-UMI/class图。

-源中的注释。

-做注释，文档生成器

这些因素的结合是非常可取的。Javadoc/Doxygen实用程序具有嵌入代码的优点。这样，文档总是最新的，即使代码中的更改仍然需要对注释进行相应的更改。这些文档工具对于代码文档来说是很好的，但是不能捕捉到系统的总体概念模型，因此需要结合文档策略。

4.研究目的

本研究的目的是根据上述维度确定一系列常见结构的特征。得出的结论可以帮助设计新的结构。

要记住的一个重要问题是，必须将体系结构与体系结构的实现分离开来。然而，这种研究永远不可能在理论架构上进行，所以我们真正比较的是架构的实现。理想情况下，我们应该对每一种实现进行大量的实现，以便做出更准确的判断。

这项研究的另一个目的是为即将在现有机器人系统中进行选择的读者提供指导。以下是已解决的问题的示例：

抽象模型.控制方法.OS支持.语言API.程序员效率.运行时效率.软件开销(代码大小).工具和方法.文档

4.1测试用例

所考虑的测试用例是一个简单的服务代理系统。在这种情况下，这意味着操作人员可以命令机器人

全文共11486字，剩余内容已隐藏，支付完成后下载完整资料

资料编号：[15939]，资料为PDF文档或Word文档，PDF文档可免费转换为Word

原文和译文剩余内容已隐藏，您需要先支付 30元 才能查看原文和译文全部内容！立即支付

以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。

您可能感兴趣的文章