工业机器人应用论文关于机器人的论文

工业机器人应用论文关于机器人的论文基于中间件的工业机器人软件框架的研究和应用摘要：在国内首次使用中间件技术，面向机车维护工业机器人,设计开发可扩展、升级和移植的软件应用框架。详细介绍了软件框架的设计和实现,包括采用两层结构实现服务器、框架的技术指标、系统CORBAIDL的具体设计和定义。最后规划了今后的研究工作。关键词：中间件；公共对象请求代理体系结构；工业机器人;机车维护引言火车机车车辆的检测与维护是铁路机务段和机车维护厂的主要任务，检修车间每天需要检测与维护的火车有数十列，每列火车被分解检查、更新部件，然后重新装配后投入运行，工作量巨大。由于车底盘是磨损消耗最集中的部位，火车检修主要是针对车厢底盘。机车底盘维护流程大体如下：a)在机车承载两侧取出四组承载耳并检查承载耳b)在机车承载两侧取出弹簧组并检查弹簧c)翻转机车承载，卸掉交叉杆，检查交叉杆d)卸掉机车承载两端的三角梁e)在四个八字面上去掉垫片，焊接新的垫片f)重新安装机车承载两端的三角梁g)重新安装交叉杆，翻转机车承载h)重新安装弹簧组i)重新安装承载耳。以上每一步操作持续5~10min。目前国内所有工作都是人工操作，辅以简单的机械设备，自动化水平非常低。

根据上述情况，启动了采用工业机器人流水线实现机车车盘检修自动化的研究。维修线整体设计布局如图1所示。图中流程按逆时针方向进行，右边工作带是步骤a)~d)；左边工作带是步骤f)~i)；中间是步骤e)。步骤e)配置了4台焊接机器人，其他步骤都各配置1台机器人，台移动机器人作为AGV，负责将弹簧和承载耳从右边工作带运送到左边工作带。整个流程包括13台机器人，在研发阶段，步骤c)和g)使用自行设计制造的特种机器人，使用Pioneer先锋作为AGV,其他步骤使用2自由度的MotomanUP6机械手。在现场应用中，机器人类型以及工位作业不一样，控制方式和通信协议也不一样，作业流程是分布异构的。各机器人必须按一定的节拍工作，以确保整个流程在给定时间内完成。符合现场应用的软件框架要求能够管理工业机器人，调度指定作业，并为作业的编辑、仿真和实时监控提供有效的视觉手段。根据现场的特性和要求，软件框架采用中间件技术和虚拟现实技术实现。目前可用的中间件技术包括CORBA、Microsoft.NET、IBMSOM、SOAP、RTC、Sun’sJava/RMI等。软件框架的系统中间件采用C++CORBA,在客户端除了C++CORBA,还使用Java/RMI。

CORBA是由OMG提出并维护的独立于供应商的标准协议[1]，它为可移植的分布式计算应用提供了平台无关的编程接口和服务模型。由于独立于编程语言、操作系统平台和网络协议，CORBA高度适合于分布式应用系统的集成以及在已有系统内开发新的应用软件[2]。图2展示了CORBA机制内的部件模型，这些部件一起实现了CORBA的互操作性、可移植性以及其他特性。其中,客户端和驻留在服务器的各种CORBA对象通过ORB(objectrequestbroker)互连通信。ORB可由不同厂家实现，但都遵循一致的CORBA协议,对于客户端来说都是透明无区别的。实时CORBA(real－timeCORBA，RTCORBA)协议[3]扩展了CORBA核心模型以支持实时架构需要。当前可用的实时CORBA是基于C++和Java的实现。实时CORBA设计了编程接口，可以在应用程序中配置并控制计算机处理器以及通信和内存等资源。由于这些特性，软件框架采用了实时CORBA提供的若干特性和服务。试验环境如图3所示，软件框架的试验环境是基于局域网的，实际包括三个机器人单元，一台网络计算服务器和若干工控PC。机器人单元中有两个是MotomanUP6机械手及配套的控制器和本地工控机。

该机械手有六个自由度，由控制器直接控制，控制器可以通过RS－232或以太网卡与一台工控PC连接，如图4所示。系统服务器的配置如下：操作系统为RedHatAS3；CPU为Intel(R)Xeon(TM)CPU3．00GHz；RAMGB；CORBA为ACE/TAO1．4；数据库为Oracle9iLinux。在客户端研发使用三台工控PC：一台运行Linux操作系统用于Pioneer编程和调试;两台运行Windows。其中一台运行VisualC++和ACE/TAO,用来开发基于CORBA方式的客户端应用；另外一台安装JDK用来开发基于RMI方式的客户端应用。图5说明了客户端应用结构。按图3~5设计,整个软件框架的通信都是基于CORBAIIOP(Internetinter－ORBprotocol)的。CORBA协议定义了GIOP(generalinter－ORBprotocol)作为其互协作的基本框架,但GIOP只是抽象概念定义,不能直接应用于ORB的通信。IIOP是基于TCP/IP的GIOP具体实现,软件框架中,客户端应用与系统服务器的通信,以及机器人工作单元与系统服务器的通信都是基于IIOP中的服务器的设计是两层结构，而在文献[1，4~7，9]中的服务器的设计都是单层结构。

这样设计是因为应用对实时性要求高，如文献[6]中所论述，在中间件系统中有很多因素导致恶劣的实时性能，包括用户响应、网络传输、CORBA协议处理、CORBA服务处理、显示处理等。如果所有13部机器人的工作负载以及多个用户的请求处理全部集中于系统主服务器，则系统主服务器就会成为整个系统性能的瓶颈。为解决此问题，如图4所示，由于具体机器人的行为和控制方式都相对固定，针对每部机器人都配置了一台本地工控PC,设立了CORBA环境，并开发了本地服务程序，专门处理机器人的具体操作。这样系统主服务器可以专注于高级的综合任务和事务，如作业调度、远程实时监控、作业仿真、系统日志、客户请求处理等。系统主服务器通过RM(robotmanager)与机器人单元交互，每个机器人在系统主服务器的实时POA(real－timeportableobjectadapter,RTPOA)内都驻留着相应的RM，如图6所示。RM是主服务器和本地机器人的双重代理，主服务器只与代表机器人的RM交互，不去考虑机器人的具体实现；本地机器人也只与自己的RM交互，不必考虑其驻留的主服务器的设计和实现。服务器的两层结构设计分离了应用中的低级具体操作和概念级的高层次服务模型，因此提升了系统的升级扩展能力和可移植性。

当在系统中增加或移除机器人时，只需要配置对应的RM模块而不影响系统整体的概念设计和实现架构，不必考虑机器人具体的操作和相关编码实现。当主服务器移植到新的硬件服务器或运行新的操作系统时，底层的与机器人相关的应用程序都不必在新环境下重新编译或者改动。在软件框架中采用了CORBA标准服务包括：a)命名服务(namingservice)。它是基本的CORBA标准服务，用于提供透明的中间件服务定位。服务器端驻留并维护着服务对象，并以字符串名字进行 广播；客户端可以通过解析这些字符串名字获取所需要的服务对象引用机器人应用，进而 取得所需要的服务，而不必考虑服务对象和服务器的位置和具体实现。

（编辑：天瑞地安资讯网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!