《基于中间件的工业机器人软件框架的研究和应用》由会员分享，可在线阅读，更多相关《基于中间件的工业机器人软件框架的研究和应用（6页珍藏版）》请在金锄头文库上搜索。
1、基于中间件的工业机器人软件框架的研究和应用摘要：使用工业机器人维护机车,设计开发可扩展,可升级和可移植的软件应用框架.软件框架的核心是基于 C+ CORBA 的中间件.试验环境包括 2 台 Motoman UP6 机械手和一台 Pioneer 移动机器人.详细介绍了软件框架的设计和实现,包括采用两层结构实现服务器,框架的技术指标,系统CORBA IDL 的具体设计和定义.结论部分规划了今后的研究工作.关键词：中间件；CORBA ；工业机器人The Research and Application of Middleware-based Software Framework for Indust
2、rial Robot Abstract：To develop an extensible, scalable and portable software framework for train maintenance using industrial robots. The core is middleware by C+ CORBA, it expatiates at length on the frameworks design and implementaion , the testbed includes two Motoman UP6 manipulators and one Pio
3、neer mobile robot, the framework employs two-tier server. Systems CORBA IDL are described and explained. Finally, concluding remarks for future works are given.Key words：Middleware; CORBA; Industrial Robot1 引 言火车机车车辆的检测与维护是铁路机务段和机车维护厂的主要任务，检修车间每天需要检测和维护的火车有数十列，每列火车被分解检查，更新部件，然后重新装配后投入运行，工作量巨大。由于车底盘是
4、磨损消耗最集中的部位，因此火车检修主要是针对车厢底盘。机车底盘维护流程大体如下：1) 在机车承载两侧取出4组承载耳并检查承载耳2) 在机车承载两侧取出弹簧组并检查弹簧3) 翻转机车承载，卸掉交叉杆，检查交叉杆4) 卸掉机车承载两端的三角梁5) 在四个八字面上去掉垫片，焊接新的垫片6) 重新安装机车承载两端的三角梁7) 重新安装交叉杆，翻转机车承载8) 重新安装弹簧组9) 重新安装承载耳以上每一步操作持续 5-10 分钟。目前所有工作都是人工操作，辅以简单的机械设备，自动化水平非常低。根据上述情况，启动了采用工业机器人流水线实现机车车盘检修自动化的研究。维修线整体设计布局如图 1 所示。图 1
5、机器人化的机车车盘检修流程布局图中流程按逆时针方向进行，右边黄色工作带是步骤 1-4,左边绿色工作带是步骤 6-9,中间是步骤 5。步骤 5 配置了 4 台焊接机器人，其他步骤都各配置 1 台机器人，一台移动机器人做为 AGV，负责把弹簧和承载耳从黄色工作带运送到绿色工作带。整个流程包括 13 台机器人，在研发阶段，步骤 3 和步骤 7 使用自行设计制造的特种机器人，使用 Pioneer 先锋做为 AGV,其他步骤使用两台 6自由度的 Motoman UP6 机械手。在现场应用中，机器人类型以及工位作业不一样，控制方式和通讯协议也不一样，作业流程是分布异构的。各机器人必须按一定的节拍工作，以确
6、保整个流程在给定时间内完成。符合现场应用的软件框架要求能够管理工业机器人，调度指定作业，并为作业的编辑，仿真和实时监控提供有效的视觉手段。根据现场的特性和要求，软件框架采用中间件技术和虚拟现实技术实现。目前可用的中间件技术包括 CORBA(Common Object Request Broker Architecture), Microsoft .NET,IBM SOM,SOAP, RTC, Suns Java/RMI 等。软件框架的系统中间件采用 C+ CORBA,在客户端除了 C+ CORBA,还使用了 Java/RMI.CORBA是由OMG(Object Management Group
7、)提出并维护的独立于供应商的标准协议1，CORBA 为可移植的分布式计算应用提供了平台无关的编程接口和服务模型。由于独立于编程语言，操作系统平台和网络协议，CORBA高度适合于分布式应用系统的集成以及在已有系统内开发新应用软件2。图2展示了CORBA 机制内的部件模型，这些部件一起实现了CORBA 的互操作性，可移植性以及其他特性。其中,客户端和驻留在服务器的各种CORBA对象通过 ORB(Object Request Broker)互联通讯.ORB可由不同厂家实现,但是都遵循一致的CORBA协议,对于客户端来说都是透明无区别的.图 2 CORBA 机制内部的部件模型实时 CORBA(RTCO
8、RBA: real-time CORBA)协议3扩展了 CORBA 核心模型以支持实时架构需要。当前可用的实时 CORBA 是基于 C+和 Java 的实现。实时 CORBA 设计了编程接口，可以在应用程序中配置并控制计算机处理器以及通讯和内存等资源。由于这些特性，软件框架采用了实时 CORBA 提供的若干特性和服务。首先介绍软件框架的试验环境和系统架构，然后阐述了中间件设计的指标和考虑，展示了系统 IDL 接口的设计，并描述了系统服务器的实现。2 试验环境如图 3 所示，软件框架的试验环境是基于局域网的，实际包括 3 个机器人单元，1 台网络计算服务器和若干工控 PC.机器人单元中有两个是
9、Motoman UP6 机械手及配套的控制器和本地工控机，该机械手有 6 个自由度，由控制器直接控制，控制器可以通过RS232 或以太网卡与一台工控 PC 连接，如图 4 所示。系统服务器的配置如下：1) 操作系统: RedHat AS3 2) CPU: Intel(R) Xeon(TM) CPU 3.00GHz3) RAM: 2G4) CORBA: The ACE/TAO 1.45) 数据库: Oracle 9i for Linux图 3 系统整体架构示意图图 4 机器人单元示意图图 5 客户端应用结构在客户端研发使用 3 台工控 PC，1 台运行Linux 操作系统用于 Pioneer 的
10、编程和调试;2 台运行 Windows,其中 1 台运行 Visual C+和ACE/TAO,用来开发基于 CORBA 的 C/S 方式的客户端应用，另外 1 台安装 JDK 用来开发基于 RMI的 B/S 方式的客户端应用。图 5 说明了客户端应用结构.按图3,图4,图5设计,整个软件框架的通讯都是基于CORBA IIOP(Internet Inter-ORB Protocol)的.CORBA协议定义了 GIOP(General Inter-ORBProtocol)做为其互协作的基本框架, 但GIOP只是抽象概念定义,不能直接应用于ORB间的通讯.IIOP是基于TCP/IP的GIOP具体实现
11、, 软件框架中,客户端应用与系统服务器的通讯,以及机器人工作单元与系统服务器的通讯都是基于IIOP的.3 系统中间件的设计首先要关注图 3 和图 4，服务器的设计是两层结构，而在145679的工作中服务器的设计都是单层结构。这样设计是因为应用对实时性要求高，如6中所论述，在中间件系统中有很多因素导致恶劣的实时性能，包括用户响应，网络传输，CORBA协议处理，CORBA 服务处理，显示处理等。如果所有 13 部机器人的工作负载以及多个用户的请求处理全部集中于系统主服务器，则系统主服务器就会成为整个系统性能的瓶颈。为解决此问题，如图 4 所示，由于具体机器人的行为和控制方式都相对固定，针对每部机器
12、人都配置了一台本地工控 PC,设立了 CORBA 环境，并开发了本地服务程序，专门处理机器人的具体操作。这样系统主服务器可以专注于高级的综合任务和事务，如作业调度，远程实时监控，作业仿真，系统日志，客户请求处理等。系统主服务器通过 RM(Robot Manager)和机器人单元交互，每个机器人在系统主服务器的实时POA(RTPOA: Real Time Portable Object Adapter)内都驻留着相应的 RM(如图 6 所示)。RM 是主服务器和本地机器人的双重代理，主服务器只和代表机器人的 RM 交互，不去考虑机器人的具体实现；本地机器人也只和自己的 RM 交互，不必考虑其驻留
13、的主服务器的设计和实现。这种关系也体现在图 8 中。服务器的两层结构设计分离了应用中的低级具体操作和概念级的高层次服务模型，因此提升了系统的升级扩展能力和可移植性。当在系统中增加或移除机器人时，只需要配置对应的 RM 模块而不影响系统整体的概念设计和实现架构，不必考虑机器人具体的操作和相关编码实现。当主服务器移植到新的硬件服务器或运行新的操作系统时，底层的和机器人相关的应用程序都不必在新环境下重新编译或者改动。在软件框架中采用了 CORBA 标准服务，包括命名服务(Naming Service), 实时事件服务(Real-Time Event Service)和实时日志服务(RTEvent b
14、ased Log Sevice)。命名服务是基本的 CORBA 标准服务，用以提供透明的中间件服务定位。服务器端驻留并维护着服务对象，并以字符串名字进行广播，客户端可以通过解析这些字符串名字获取所需要的服务对象引用，进而取得所需要的服务，而不必考虑服务对象和服务器的位置和具体实现。因为要应用于工业现场，采用 CORBA 的实时日志服务为系统提供日志能力。在本框架中，用户的所有操作，请求，相应以及系统内所有的事件，异常，运行状态都可以配置到日志记录中。这些被记录的信息可用来在研发阶段调试系统框架，在现场应用中帮助评估系统性能，协助机器人的示教训练和编码，跟踪用户操作等。图6 系统服务器结构实时事
15、件服务使 CORBA 系统可以交换命名的事件，并没有传统的客户与服务器的界定，而只是发出事件的”供应者”和定制并接受事件的”消费者” ，事件在供应者和消费者之间的专有事件频道内传输。实时事件服务给应用实现以及数据交换带来了极大的灵活，比如当机器人的空间位姿或作业状态发生变化，就会产生相应的事件，该事件通过事件频道传送到定制事件的消费者，消费者可以是任意的 CORBA 对象。从远端分布的多个用户来实时的监控多个机器人要求系统较好地利用多线程处理并发。RTCORBA 提供了 ”线程池”(Thread Pool)机制来支持服务器的多线程编程，实现服务器资源预分配。当服务器启动时，一组线程可以被静态地
16、创建，这些线程随时准备被绑定到客户地请求，可以防止系统运行时线程创建/释放引起的过载，并通过配置服务器的线程数量来确保系统的性能1。为避免低优先级的请求消耗掉所有线程，线程池可以进一步按优先级划分成若干”泳道”(Lanes)，这样可以分组管理线程同时保证高优先级的请求不被错过或延误。划分不是绝对的，当高优先级请求所属”泳道” 无线程可分配时，可以从低优先级”泳道”借线程使用。在软件框架中，如图 6 所示，当系统启动时，对应于每一个服务对象(RM,系统日志等)的RTPOA 就被创建，同时相应的线程池也被创建，划分成若干”泳道” 并处于工作待命状态。针对 RM，线程池按高，中，低三个优先级划分”泳道”，一般的作业操作属于低级别请求，状态改变相关的事件属于中级别请求，碰撞和紧急停机属于最高优先级。这样在正常情况下，机器人可执行规定的作业并及时把自身状态事件发布出去，并保证在紧急情况下停止工作和动作。4 机器人 IDL 文档的设计与定义软件框架定义了一组机器人对象和接口做为全部工作的基础，所
