英语原文共 11 页，剩余内容已隐藏，支付完成后下载完整资料
OPRoS:一个新的基于组件的机器人软件平台
Choulsoo Jang, Seung-Ik Lee, Seung-Woog Jung, Byoungyoul Song, Rockwon Kim,Sunghoon Kim,和 Cheol-Hoon Lee
概要：
组件是通过其接口访问的可重复使用和可替换的软件模块。基于组件的开发有望缩短开发周期，降低维护成本，提高程序的可重复使用性和组件的互操作性。为了支持机器人软件开发的全过程，本文提出了一种新的机器人软件组件平台。它的标准组成如下，组件模型、组件创作工具、组件编写器和组件执行引擎。为了证明其可行性，本文给出了该组件的通信开销分析结果，并与其他机器人软件平台进行了比较，以及在商业机器人中的应用。
关键词:
机器人软件，组件，组件平台，创作工具，组件编写器，组件执行引擎，OPRoS。
一、介绍
机器人不仅有许多不同类型的传感器、执行器和自由度，而且它们的服务也变得越来越复杂，允许它们自主运行，同时在未知或部分已知的环境中提供复杂的服务[1]。不幸的是，它们的服务常常不能重用，即使在稍微不同的应用程序场景中也是如此，因为它们绑定到特定的机器人硬件、处理平台和通信基础设施。此外，关于任务和操作环境的假设和约束在软件实现中被隐藏和硬编码[2]。这种复杂性的增加导致了对模块化、生产力、可重用性、集成和维护的需求增加。
组件技术似乎是满足机器人软件领域需求的有吸引力的方法[3]。组件是一个可重复使用和可替换的软件模块，可以轻松地开发复杂的功能。基于组件的开发的主要关注点是将预先存在的软件组件组装成更大的组件。然而，软件重用和基于组件的开发还不是机器人技术中最先进的实践软件开发方法。
EJB[4]、. net[5]和CORBA[6]组件模型等广泛使用的组件技术，已经引起了人们对业务应用程序的广泛关注。他们相比于其他业务是重量级和复杂的。即便如此，它们也不能解决实时应用程序、故障管理或其他对机器人很重要的功能等问题。
近年来，对基于构件的机器人软件平台[7]-[19]进行的积极的研究。它们可以分为三类:基于中间件的组件平台、机器人设备接口平台和机器人软件体系结构平台。
MSRDS [8]， MARIE [9]， Miro [10]， RT-Middleware [11]，
OROCOS[12]、ROS[13]和PEIS Ecology[14]是基于中间件的组件平台，用于管理用于多用途机器人控制软件的组件及其与组件执行引擎的通信。但是，他们专注于中间件框架，因此他们没有充分支持相关工具来进行组件开发及其模拟。Player[15]等机器人设备接口平台的目的是为通过网络访问机器人传感器和执行器提供接口。ERSP[16]、Urbi[17]、MobileRobots[18]和iRobot Aware[19]是提供分层软件架构的机器人软件架构平台。
我们认为，一个好的机器人软件平台应该提供比纯中间件更多的东西，这样才能支持机器人软件的完整开发生命周期。为了满足上述要求，本文提出了一种新的机器人服务开放平台(OPRoS)[20]组件技术。它通过提供机器人软件组件模型、组件执行引擎、各种中间件服务、开发工具和仿真环境，支持机器人软件的完整开发生命周期。
本文的其余部分讲述了如下几点。第二部分详细介绍了一个良好的基于中间件的机器人软件组件平台。第三部分介绍了OPRoS组件模型。第四节解释了组件执行引擎，第五节展示了用于编写和组合组件的开发工具。第六部分对OPRoS组件平台及其在商业机器人中的应用进行了分析，第七部分对本文进行了总结。
二、需求分析
在本节中，我们将分析机器人组件软件平台的理想和必要特性，这些属性旨在作为一个新的组件平台的基础。
首先，机器人组件软件平台应该支持多种操作系统，如MS Windows、Linux和实时操作系统，因为机器人系统通常运行在各种操作系统下。
其次，组件软件平台需要支持分布式通信。机器人系统经常分布以扩展计算能力或与其外部服务器交互。。
第三，组件软件平台必须独立于体系结构。它不应该依赖于任何特定的机器人软件架构，比如Sense-Plan-Action、Subsumption[21]、Hybrid[22]等架构，这样无论它们采用什么架构，它可以应用于尽可能多的机器人，减少受到的约束。
第四，机器人组件软件平台需要支持多种执行语义。机器人有时会定期执行他们的工作，也可以非周期性地执行经典控制循环，更高级别控制的方法调用或基于事件的刺激响应。
第五，部件不仅要尽可能简单，但同时它们应该是可组合的，因此可以将更复杂的部件与其他部件组装在一起。 如果我们能够组成几个组件以便它们合作以实现共同目标，那将是非常有帮助的。
第六，它应该易于使用。机器人开发人员相比于学习新的开发方法，通常更喜欢使用他们熟悉的开发方法。因此，有必要提供一个简单的组件模型、它的开发工具以及易于使用的可重用服务构建块。此外，为了便于使用，还需要支持通信中间件的透明性，因为机器人软件开发人员通常不愿意进行依赖于中间件的编程。
最后，机器人组件软件平台应具备故障检测、恢复、实时、QoS支持。机器人是嵌入式系统，它们通常运行很长时间(以小时、月或年为单位)。它们通常在需要快速响应的环境中运行，有时需要在无人干扰的情况下自主运行。
三、OPRoS组件模型
EventPort (output)
onEvent()
Event
EventPort (input)
Periodic Non-periodic
unqueued
DataPort (input)
DataPort (output)
onExecute()
Data
DataPort queued (input)
ServicePort (required)
Method A Method B Method Z
ServicePort (provided)
ServicePort (required)
Method 1
Method 2 Method N
ServicePort (provided)
本节介绍满足前面提到的需求的OPRoS组件模型。
- 网络分布式
OPRoS组件是可重复使用和可替换的软件模块，不需要重新编译。它们分布在一个网络上。它们松散耦合，独立运行，通常代表机器人的设备。机器人服务由这些分布式组件组成，其方式类似于由设备组装的机器人硬件系统。组件执行引擎(OPRoS组件的运行时环境)提供了包括组件连接管理 图1. OPRoS组件模型
的通信基础设施。
通过将网络管理与组件逻辑分离，开发人员可以专注于他们打算开发的逻辑，而无需担心网络管理。
任何级别的粒度的可以成为分布式OPRoS组件。例如，它可以是在设备级、算法级或协调级，等等，由组件开发人员决定哪一个是合适的。利用不同粒度的分布式组件，可以采用扁平或分层的组合方式实现各种机器人软件体系结构。
- 端口作为接口
在基于组件的机器人软件中，组件之间通过连接进行通信。从发送组件的端口建立到接收组件的端口的连接。我们注意到，机器人软件开发人员通常使用组件间通信来发送或接收三种类型的信息:方法调用、数据和事件。
为了支持这些特性，OPRoS组件模型有三种类型的对应端口，即服务、数据和事件端口。每个组件具有这些类型的一个或多个端口。图1描述了OPRoS组件模型。
服务端口允许其他组件调用它的方法。它有一组方法的接口定义。服务端口要么是提供的类型，要么是必需的类型。所提供的服务端口向其他组件提供方法服务。提供的服务端口的方法映射到组件中用户定义的方法。所需的服务端口充当连接组件的用户定义方法的代理。
数据端口是用来交换数据的。它要么用于输入，要么用于输出。输出数据端口将数据发送到其他组件的输入数据端口。对于数据交换，输入和输出都应该具有相同的数据类型。数据端口可以具有存储接收数据的队列，也可以具有单个大小的缓冲区以存储最近接收的数据。接收到的数据在组件的onExecute()方法中以周期性或非周期性的方式处理。
事件端口用于传输事件。虽然数据端口和事件端口在传输结构化数据方面是相似的，但是事件是由网络服务线程使用onEvent()方法立即处理的，而数据端口接收到的数据是缓存的，然后由组件服务线程稍后处理。
数据/事件的输出端口在传输数据/事件时不会阻塞，而服务端口根据方法类型支持阻塞和非阻塞调用。
- 执行模式
组件的执行模式可以是周期的、非周期的或被动的。在周期模式下，组件的onExecute()回调方法将定期调用，以处理数据或执行其算法。这对于机器人设备组件非常有用，因为它们通常定期运行。用户可以在组件配置文件中指定组件的执行周期。
相等周期的组件的onUpdate()方法在调用它们的所有onExecute()方法之后立即在周期内调用。onExecute()方法通常执行组件的主要逻辑并尽快完成，与此相反，onUpdate()方法用于相对昂贵的计算操作。这种两阶段执行可以最小化延迟和抖动，这在实时应用程序中是至关重要的。
当onExecute()方法的预期执行时间相当长或不可预测时，使用非周期模式。一个线程专用于每个非周期组件。这种模式下的组件在onExecute()方法中迭代地继续执行，直到销毁为止才释放其专用线程。
被动模式下的组件既没有onExecute()回调方法，也没有自己的线程。相反，只有当事件或方法请求等刺激从其他组件到达时才会激活。
- 类图
用户组件应该继承OPRoS的一个名为“组件”的基类，如图2所示。组件有一个或多个端口与其他组件交互。它再次继承各种接口，如生命周期、端口管理和属性。组件容器使用这些接口来管理组件。继承基类的用户组件通过覆盖继承的回调函数和添加用户定义的方法来实现。用户定义的方法由网络服务线程在接收到来自客户机的请求时调用，而组件的父接口和回调方法则由容器调用。
组件的活动执行(周期性或非周期性模式)是通过组件容器管理的执行器来完成的。容器将组件注册到执行程序，执行程序运行已注册的组件，这些组件具有相同的周期和相同的优先级，并具有来自容器的已分配线程。
图3. OPRoS组件的状态转换图
图2. OPRoS组件的UML类图
- 生命周期管理
组件在其生命周期中运行一系列状态，如图3所示。创建组件实例时，它处于创建状态。当容器调用onInitialize()后，它的状态变为就绪状态。onStart()方法将组件引导到活动状态，在其中迭代onExecute()和onUpdate()方法。当调用onStop()方法时，它将进入非活动状态，并暂停执行，直到onStart()方法再次激活为止。
如果发生错误，组件将转换为错误状态，容器将调用它的onError()回调函数来处理错误。当组件从错误中恢复时，在调用onrecovery()方法之后，组件立即进入就绪状态。组件实例在调用其onDestroy()方法后被销毁。
- 组件组成
显然，如果我们在制作新组件时可以利用现有组件，这将有助于减少从头开始创建组件时可能发生的开发时间和错误。这自然导致了基础组件的分为了不同的类型:原子组件和复合组件。
原子组件是单独构成的，主要用于抽象底层设备或算法。
复合组件由其他组件(原子组件或复合组件)组成。复合组件访问每个包含组件的端口。当调用组合组件的接口时，将其委托给相应的包含组件。通过这种方式，组合组件抽象内部组件的接口，以便用户可以访问简化的接口。
- XML配置文件
组件的端口类型、执行语义、属性等在称为组件概要文件的XML文件中进行描述。配置文件由组件执行引擎解释，以便操作相应的组件。
组件的api在单独的服务概要文件中描述为组件的服务端口提供的方法签名列表。此外，数据概要文件还描述了方法调用或组件之间的数据传输中使用的数据类型或数据结构。这两个概要文件在描述接口和数据类型方面类似于CORBA IDL。
描述分布式节点的网络配置，对参与组件的引用以及组件之间的端口连接的应用程序简档被提供给用于运行机器人应用程序的引擎。
Component service
Component Execution semantics Component execution deploy/undeploy management coordination
OS abstraction
Component container
Remote monitoring 全文共10573字，剩余内容已隐藏，支付完成后下载完整资料
资料编号：[453814]，资料为PDF文档或Word文档，PDF文档可免费转换为Word
以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
