Repositorio Institucional de Documentos

 3UR\HFWR)LQGH&DUUHUD  ,QWHJUDFLyQGHORVFRPSRQHQWHV\VLVWHPDV GHSHUFHSFLyQGHXQDFpOXODGHIDEULFDFLyQ URERWL]DGD  -RVp,JQDFLR$EDG0DUWtQH]  'LUHFWRUHV *RQ]DOR/ySH]1LFROiV -RVp-HV~V*XHUUHUR&DPSR  ,QJHQLHUtD,QGXVWULDO $XWRPDWL]DFLyQ,QGXVWULDO\5REyWLFD  'HSDUWDPHQWRGH,QIRUPiWLFDH,QJHQLHUtDGH6LVWHPDV (VFXHODGH,QJHQLHUtD\$UTXLWHFWXUD 8QLYHUVLGDGGH=DUDJR]D $EULOGH ii Integraci´on de los componentes y sistemas de percepci´on de una c´elula de fabricaci´on robotizada. RESUMEN. El presente proyecto describe el trabajo desarrollado para realizar la integraci´on de los diferentes componentes que forman parte de una c´elula industrial robotizada disponible en el laboratorio L0.6 del edificio Ada Byron de la Escuela de Ingenier´ıa y Arquitectura de la Universidad de Zaragoza. Adem´as de una puesta a punto, tambi´en se busca proporcionar funcionalidad adicional (tanto operativa como docente) a la configuraci´on actual de dicha c´elula mediante el uso de visi´on por computador y de simuladores comerciales de rob´otica industrial. El trabajo realizado tiene como denominador com´un el empleo de gran cantidad de documentaci´on t´ecnica referente a los componentes de la c´elula de fabricaci´on, la implementaci´on de soluciones funcionales y operativas en el momento actual, y la documentaci´on exhaustiva de todo el trabajo realizado. Fundamentalmente, el proyecto se ha desarrollado a lo largo de los siguientes bloques tem´aticos: 1. Integraci´on de los diferentes componentes de la c´elula industrial mencionada. Los aspectos m´as relevantes, entre muchos otros, que se han trabajado han sido: La programaci´on de un robot industrial modelo ((Fanuc Arcmate 50 IL)); El desarrollo del sistema de comunicaciones entre dicho robot y un aut´omata industrial modelo ((Modicon M340)); El control de los diversos automatismos mec´anicos mediante la programaci´on de dos aut´omatas adicionales; El establecimiento de comunicaciones y jerarqu´ıas de control entre los diferentes aut´omatas; Y el desarrollo de aplicaciones de control mediante terminales visuales Hombre-M´aquina, concretamente sobre plataformas ((Magelis)) presentes en el laboratorio. 2. Ampliaci´on de la funcionalidad tradicional de las c´elulas de fabricaci´on mediante el empleo de algoritmos de visi´on para c´amaras RGB-D. Para ello se han desarrollado algoritmos en lenguaje de programaci´on C++, para uso con c´amaras RGB-D que permiten la localizaci´on de objetos predefinidos, obteniendo del algoritmo informaci´on tal como el tipo de objeto localizado, su posici´on, orientaci´on y color. Adicionalmente, los algoritmos tambi´en permiten realizar un control de seguridad sobre la presencia de objetos extra˜nos en el espacio de trabajo. 3. A un nivel superior en el dise˜no de una c´elula de fabricaci´on, se encuentra la fase de simulaci´on. Tambi´en se ha abordado esta fase y se ha realizado un estudio y an´alisis de los diferentes simuladores comerciales de rob´otica industrial disponibles en el mercado. Bas´andose en el an´alisis y comparaci´on de opciones realizado, se seleccion´o el simulador ((ABB Robot-Studio)). Adicionalmente, se han realizado diversos programas demostrativos, as´ı como una gu´ıa sobre el programa, varios v´ıdeos tutoriales y varias propuestas de guiones de pr´acticas sobre dicho programa. ´ Indice general 1. Introducci´on 1 1.1. Contexto y motivaci´on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.2. Objetivos y alcance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.3. Herramientas y entorno de trabajo . . . . . . . . . . . . . . . . . . . . . . 4 1.4. Organizaci´on de la memoria . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.5. Gr´afico resumen del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Situaci´on previa de la c´elula industrial 7 2.1. C´elula de fabricaci´on industrial . . . . . . . . . . . . . . . . . . . . . . . . 7 2.2. Robot industrial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.3. Aut´omatas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3. Programaci´on del robot industrial 15 3.1. Controlador del robot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.2. Terminal de ense˜nanza . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.3. Hyper-terminal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.4. Lenguaje Karel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.5. Aspectos relevantes de la programaci´on . . . . . . . . . . . . . . . . . . . . 21 3.6. Programa principal del robot . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.7. Material docente resultante . . . . . . . . . . . . . . . . . . . . . . . . . . 25 4. Control del robot con aut´omatas 27 4.1. Comunicaci´on entre aut´omata y robot . . . . . . . . . . . . . . . . . . . . 27 4.2. Programaci´on de los aut´omatas . . . . . . . . . . . . . . . . . . . . . . . . 28 4.2.1. Aut´omata principal . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 4.2.2. Aut´omata de la estaci´on de expedici´on de palets . . . . . . . . . . . 35 4.3. Integraci´on del conjunto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 4.3.1. Jerarqu´ıa de los componentes . . . . . . . . . . . . . . . . . . . . . 37 4.3.2. M´odulo de comunicaciones Ethernet . . . . . . . . . . . . . . . . . . 38 4.4. Material docente resultante . . . . . . . . . . . . . . . . . . . . . . . . . . 39 5. Supervisi´on mediante terminal de di´alogo 41 5.1. Motivaci´on del uso de un terminal de di´alogo . . . . . . . . . . . . . . . . . 41 5.2. Modificaciones necesarias en la programaci´on de los aut´omatas . . . . . . . 42 5.3. Integraci´on en el conjunto . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 5.4. Material docente resultante . . . . . . . . . . . . . . . . . . . . . . . . . . 45 iv ´ INDICE GENERAL v 6. Incorporaci´on de una c´amara RGB-D 47 6.1. Motivaci´on para el uso de una c´amara RGB-D . . . . . . . . . . . . . . . . 47 6.2. Obtenci´on de la informaci´on . . . . . . . . . . . . . . . . . . . . . . . . . . 49 6.2.1. Representaci´on y almacenamiento de la informaci´on . . . . . . . . . 49 6.2.2. Segmentaci´on del escenario . . . . . . . . . . . . . . . . . . . . . . . 50 6.3. Algoritmo para identificar objetos . . . . . . . . . . . . . . . . . . . . . . . 51 6.3.1. Orientaci´on de la imagen respecto al plano principal . . . . . . . . . 52 6.3.2. Segmentaci´on y eliminaci´on de planos . . . . . . . . . . . . . . . . . 54 6.3.3. Divisi´on de la imagen resultante en conjuntos de puntos . . . . . . . 55 6.3.4. Identificaci´on del contenido de los conjuntos . . . . . . . . . . . . . 55 6.3.5. Informaci´on adicional de color para los conjuntos . . . . . . . . . . 57 6.3.6. Resultado en formato cualitativo y coordenadas . . . . . . . . . . . 58 6.4. Algoritmo de control del espacio de trabajo . . . . . . . . . . . . . . . . . . 58 7. Simulador de rob´otica industrial 61 7.1. Motivaci´on para la b´usqueda de un simulador . . . . . . . . . . . . . . . . 61 7.2. Estudio y comparaci´on de simuladores . . . . . . . . . . . . . . . . . . . . 62 7.2.1. RoKiSim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 7.2.2. V-rep . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 7.2.3. Easy-Rob . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 7.3. ABB Robot-Studio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 7.3.1. Aprendizaje y preparaci´on de material . . . . . . . . . . . . . . . . 66 7.4. Material docente resultante . . . . . . . . . . . . . . . . . . . . . . . . . . 67 8. Conclusiones 69 8.1. L´ıneas abiertas para trabajar . . . . . . . . . . . . . . . . . . . . . . . . . 71 A. Cableado de las E/S digitales del robot A B. Programas del robot en lenguaje KAREL B C. Manual de configuraci´on de un m´odulo Advantys C D. Manual de uso de E/S por red Ethernet D E. Programas de los aut´omatas E F. Manual de uso de Robot-Studio F G. Gui´on de la pr´actica de Guiado G H. Gui´on de la pr´actica de Integraci´on H I. Gui´on de la pr´actica de Integraci´on (II) I J. Gui´on de la pr´actica de terminales de di´alogo J K. Gui´on de la pr´actica del simulador Robot-Studio K vi ´ INDICE GENERAL Bibliograf´ıa XV Cap´ıtulo 1 Introducci´on 1.1. Contexto y motivaci´on La automatizaci´on industrial es una rama de la ingenier´ıa que si bien se encuentra ya muy desarrollada e implantada en gran parte de las industrias de los pa´ıses desarrollados, todav´ıa se encuentra en un proceso de mejora, perfeccionamiento y aumento de sus capacidades. Dentro de la automatizaci´on industrial, uno de los aspectos m´as importantes radica actualmente en la integraci´on de los diferentes componentes automatizados de una planta de producci´on. Esta integraci´on es muy importante para el funcionamiento de la planta como conjunto, y es frecuentemente el punto donde m´as dificultades se encuentran. El contexto en el que se desarrolla este proyecto parte de la existencia en los laboratorios de la Escuela de Ingenier´ıa y Arquitectura, de una c´elula de fabricaci´on industrial, con todos los elementos comunes a una industria de manufactura. M´as adelante se detallar´an sus componentes, pero a modo de ilustraci´on, dispone de: Aut´omatas programables, un robot industrial, buses de comunicaciones, estaciones de trabajo, etc. En este contexto, la motivaci´on de este proyecto tiene dos claras vertientes. Por un lado, el inter´es del proyectando tanto en la rob´otica como en la automatizaci´on, que hac´ıa que este proyecto quedara perfectamente integrado en su formaci´on. Por otro lado, el inter´es en generar una nueva configuraci´on y programaci´on integrada de la c´elula de fabricaci´on presente en el laboratorio L 0.6 del edificio Ada Byron, con el objeto de poder servir como soporte para el desarrollo de futuras pr´acticas para nuevas asignaturas de Grado. Sin salir del campo m´as pr´actico, y como mejora directa del potencial que ofrecen las c´elulas automatizadas de fabricaci´on, se hizo el planteamiento de realizar algunos algoritmos para la utilizaci´on de una c´amara RGB-D. Con ello se busca indagar en el inter´es que pueden tener estas c´amaras como complemento a los sistemas de percepci´on m´as tradicionales de las c´elulas de fabricaci´on, dado que ya han tenido resultados muy positivos en campos como el entretenimiento. 1 2CAP´ ITULO 1. INTRODUCCI ´ ON En estrecha uni´on con la parte m´as pr´actica y aplicada del proyecto, se propuso una m´as te´orica consistente en la selecci´on e implantaci´on de un simulador de rob´otica industrial. El inter´es de esta parte se centra fundamentalmente en la necesidad docente de poder ense˜nar un simulador completo de rob´otica. Un simulador que incluya no solo los tradicionales aspectos de cinem´atica de un robot de seis ejes, sino tambi´en la posibilidad de interactuar con un entorno industrial complejo. Una vez seleccionado un simulador, tambi´en era necesaria la elaboraci´on de documentaci´on y simulaciones de prueba. 1.2. Objetivos y alcance El objetivo principal de este proyecto es la puesta en funcionamiento, de un modo completamente operativo, de una nueva configuraci´on para la c´elula de fabricaci´on industrial mencionada, de tal forma que sirva mejor a los m´as recientes objetivos docentes. Incluyendo as´ı mismo ampliaciones de sus funcionalidades mediante el empleo de la visi´on por computador, y el uso de un simulador comercial de rob´otica industrial en un contexto docente. En particular, los objetivos iniciales de este proyecto Fin de Carrera son: Conseguir una integraci´on segura y robusta de los diferentes componentes de la estaci´on del robot, la estaci´on de transporte y la estaci´on de expedici´on de palets de la c´elula de fabricaci´on antes mencionada. Programaci´on del robot, de los aut´omatas, y de otros componentes que pudieran ser necesarios. Desarrollo de un programa demostrativo que permitiera mostrar el potencial de la c´elula. Desarrollo de algoritmos para c´amaras RGB-D que aportaran valor a la supervisi´on y al control de una c´elula de fabricaci´on. Selecci´on y estudio de un programa de simulaci´on de robots que permitiera la simulaci´on completa tanto de un robot industrial en su aspecto cinem´atico, como de un entorno completo de trabajo con el que pudiera interactuar. Realizaci´on de manuales de uso y de utilizaci´on tanto de la parte empleada de la c´elula de fabricaci´on como del simulador a buscar. Documentaci´on de todo el trabajo desarrollado, as´ı como de los manuales realizados. Respecto al alcance final del proyecto, que se ir´a desgranando a lo largo de los diferentes cap´ıtulos, se destacan los siguientes hitos: Se ha efectuado un desarrollo a todos los niveles para lograr la correcta integraci´on de todos los componentes propuestos de la c´elula de fabricaci´on mencionada. En concreto, se han integrado para permitir su funcionamiento como un conjunto: 2.1. C ´ ELULA DE FABRICACI ´ ON INDUSTRIAL 9 Figura 2.3: Subc´elula de preparaci´on y transporte de pedidos Figura 2.4: Estaci´on expendedora de palets para colocar las piezas. Estaci´on 5. Es un almac´en intermedio, que es capaz de distinguir las piezas que le llegan y almacenarlas hasta que son solicitadas. Est´a compuesto de dos motores paso a paso y un cilindro neum´atico que gu´ıan a un brazo con ventosa a lo largo de un almacenamiento de tipo matricial. A partir de aqu´ı, se pueden considerar las siguientes estaciones como pertenecientes a la sub-c´elula de gesti´on de pedidos, que es a la que se refiere este proyecto: Transporte 2. Se encarga de transportar los carritos en los que se sit´uan los pedidos a lo largo de la sub-c´elula de gesti´on de pedidos. Consta de seis cintas transportadoras, un desv´ıo intermedio, diversos sensores de detecci´on (inductivos y capacitivos) y cuatro carritos transportadores. Los diversos carritos pueden circular entre las diferentes estaciones, existiendo desv´ıos para que no sea necesario que pasen por todas para llegar a una determinada. Estaci´on 6. Esta estaci´on coloca una placa con capacidad para tres cilindros. La placa puede ser blanca o negra, lo que aumenta las variantes del pedido. Su funcionamiento corre a cargo de diversos cilindros de simple y doble efecto, as´ı como de sensores de posici´on para los cilindros, y de detecci´on de placas. En esencia funciona del siguiente modo: las placas est´an colocadas en alimentadores; Se extrae una de las placas de un alimentador mediante un empujador; Una vez detectado que se ha sacado la pieza, se mueve el brazo con ventosas hasta la pieza y se succiona para agarrarla; La pieza se coloca sobre el carrito, y se devuelve el brazo a su posici´on de reposo. Esta estaci´on dispone adem´as de una luz de emergencia. Tambi´en dispone de una botonera, un aut´omata con m´odulo CANopen, y diversos m´odulos de cableado r´apido. Estaci´on 7. Es el almac´en final de pedidos, posee cierta complejidad debido a sus complicados mecanismos de posicionamiento y a la existencia de m´as de 70 lugares 10 CAP´ ITULO 2. SITUACI ´ ON PREVIA DE LA C ´ ELULA INDUSTRIAL de almacenamiento. En el momento actual est´a en desuso, y el aut´omata que la controla es un modelo antiguo. En el momento de comenzar el proyecto, todos los elementos descritos hasta el momento estaban parcialmente operativos desde el punto de vista de su funcionamiento mec´anico. Adicionalmente, se descart´o el uso de la sub-c´elula de fabricaci´on debido a ciertas carencias respecto a las comunicaciones de algunos de los aut´omatas que la deb´ıan controlar, todo ello se detallar´a en el apartado correspondiente a los aut´omatas. Hay que a˜nadir que dos de las cintas transportadoras se encontraban rotas al comienzo del proyecto, faltaban algunos m´odulos de comunicaciones, hab´ıa modelos de aut´omatas incompatibles entre s´ı, y exist´ıan algunos problemas de incompatibilidad entre el software m´as moderno de programaci´on de aut´omatas (Unity Pro), y los aut´omatas m´as antiguos. A continuaci´on se detalla el estado inicial de los elementos involucrados m´as importantes. 2.2. Robot industrial Una de las partes fundamentales de la sub-c´elula de gesti´on de pedidos, incluso quiz´a la m´as importante debido a su versatilidad, es el robot industrial presente en la misma. Se trata de un robot industrial de seis ejes, modelo FANUC ARCMATE 50IL (M´as informaci´on en [15]). Sus principales caracter´ısticas se recogen a continuaci´on: Node ejes 6 Carga m´axima 3 kg Repetibilidad 0.04mm Peso del robot 41 kg Distancia alcanzable (Horizontal) 856 mm Velocidades (Ejes 1 a 3) 1.57 rad/s Velocidades (Eje 4) 6.98 rad/s Velocidades (Eje 5) 5.76 rad/s Velocidades (Eje 6) 8.38 rad/s Tabla 2.1: Principales caracter´ısticas del robot Este robot est´a equipado con una garra especialmente dise˜nada para poder coger los peque˜nos cilindros que se fabrican en la otra parte de la c´elula, pero tambi´en puede coger otra serie de objetos tales como prismas, esferas, cilindros m´as grandes, etc. En su momento, el conjunto del robot y la sub-c´elula de expedici´on de pedidos, fueron dise˜nados para que el robot pudiera acceder a la cinta por la que llegan las piezas y a la cinta por la que llegan los carros. En el caso de la cinta de los carros, tiene alcance para coger o colocar piezas en las dos posiciones fijas que pueden adoptar los carros. Adem´as, tambi´en tiene alcance para poder trabajar en una gran superficie que se sit´ua al otro lado de las cintas transportadoras, y en la cual se pueden desarrollar m´ultiples operaciones tal y como se ver´a en el cap´ıtulo dedicado al robot. 2.2. ROBOT INDUSTRIAL 11 Figura 2.5: Zona de trabajo del robot. Est´a delimitada por las cintas transportadoras y tres vallas de protecci´on. Como se ve en la figura 2.5, se aprecian tanto las dos cintas transportadoras a las que puede acceder, como una de las posiciones fijas para los carros. La zona de la izquierda es en la que se ha comentado que se pueden realizar tareas adicionales no necesariamente relacionadas con los cilindros. El estado del robot en el momento de comenzar el proyecto es de plena operatividad, aunque de una forma aislada respecto del resto de la c´elula de fabricaci´on. Tanto el robot como su controlador estaban en perfectas condiciones de uso. Adem´as, el robot ten´ıa una serie de programas demostrativos que han sido muy ´utiles para la posterior programaci´on del mismo. Respecto a la comunicaci´on del robot con otros elementos, se realizaba mediante un m´odulo de entradas y salidas por red Ethernet, denominado TSX MOMENTUM. El robot ten´ıa cableadas una serie de entradas y salidas digitales a dicho m´odulo de comunicaciones, el cual las pon´ıa a disposici´on de la red Ethernet del laboratorio. Pero desde un primer momento se comprob´o que esa conexi´on hab´ıa dejado de ser operativa, por lo cual (entre otras razones) se terminar´ıa por sustituir ese m´odulo por otro diferente, como m´as adelante se abordar´a. El robot se puede programar de dos formas diferentes. O bien mediante el terminal de di´alogo, o bien mediante lenguaje de alto nivel ((KAREL)). La forma elegida fue el lenguaje de alto nivel, por su mayor versatilidad y por el hecho de que la programaci´on es mucho m´as legible al hacerse en un lenguaje de alto nivel que si se hubiera hecho mediante el terminal de di´alogo, el cual directamente genera archivos binarios. Hay que a˜nadir, que el software de comunicaci´on con el robot desde el PC asociado, se encontraba disponible parcialmente. Si bien el compilador de lenguaje KAREL, y el emulador de disquetera virtual funcionaban, otros programas originales del fabricante del robot no lo hac´ıan. 12 CAP´ ITULO 2. SITUACI ´ ON PREVIA DE LA C ´ ELULA INDUSTRIAL 2.3. Aut´omatas Cuando se comenz´o el proyecto, la c´elula de fabricaci´on dispon´ıa de dos tipos de aut´omatas. Por un lado exist´ıan los m´as modernos M340 (M´as informaci´on sobre M340 en [18]), del fabricante Schneider Electric, y por otro lado los algo m´as antiguos TSX Premium (Informaci´on adicional sobre TSX PREMIUM en [19]), del mismo fabricante. Las estaciones n´umeros 1, 3, 4 y 6 estaban equipadas con los M340. Mientras que las estaciones 2, 5 y 7 lo estaban con los TSX Premium. Figura 2.6: Aut´omata M340 e isla Advantys pertenecientes a la estaci´on 6. Figura 2.7: M´odulo TSX Momentum, perteneciente a una estaci´on de transporte Debido a problemas de comunicaciones por incompatibilidad de m´odulos entre los dos tipos de aut´omata, y a la posibilidad de que trabajar con la c´elula completa pudiera ser excesivo, se decidi´o trabajar con la estaci´on 6, las cintas transportadoras de la sub-c´elula de pedidos, y el robot industrial. El modo en el que los aut´omatas controlan las partes de la c´elula es el siguiente: Cada estaci´on tiene todos sus sensores y actuadores cableados f´ısicamente con un m´odulo de entradas y salidas. Dichos m´odulos, denominados ((islas)), son del modelo ADVANTYS STB (M´as informaci´on de ADVANTYS STB en [20]), y son del fabricante Telemecanique, del grupo Schneider Electric. Cada uno de estos m´odulos de entradas y salidas est´a conectado mediante un bus CANopen al aut´omata que controla dicha c´elula. El aut´omata intercambia informaci´on con el m´odulo de entradas y salidas, y mediante la ejecuci´on del programa que tenga cargado, realiza el control efectivo de la estaci´on. Adem´as, tambi´en pone a disposici´on de otros entes de mayor jerarqu´ıa la posibilidad de acceder a las entradas y salidas, as´ı como a otras variables propias del aut´omata, todo mediante la red Ethernet. Adem´as, por otra parte est´an las estaciones que no disponen de aut´omata propio, que son las de transporte. Todos los sensores y actuadores de cada una de estas dos estaciones est´an conectados a su respectivo m´odulo de entradas y salidas modelo TSX MOMENTUM, que las vuelca a la red Ethernet, haci´endolas accesibles a cualquier aut´omata que disponga de un m´odulo de control Ethernet. 2.3. AUT ´ OMATAS 13 En los siguientes cap´ıtulos se desarrollar´an los cambios realizados en la instalaci´on de la c´elula de fabricaci´on, as´ı como la forma en la que se han utilizado y programado los elementos mencionados. Cap´ıtulo 3 Programaci´on del robot industrial En este cap´ıtulo se presentan las tareas rob´oticas realizadas y se explica de manera concisa c´omo se ha programado el robot y por qu´e se ha programado as´ı, y se resaltan los aspectos m´as importantes de la programaci´on que se ha realizado. 3.1. Controlador del robot El robot industrial FANUC ARCMATE 50IL, en concreto en su versi´on presente en el laboratorio L 0.6, puede estar controlado mediante dos controladores diferentes. El controlador RJ-2 y el RJ-3, ambos del mismo fabricante que el robot. En el caso de este robot, el controlador presente es como muestra la figura 3.1, el RJ-3. El tipo de controlador tiene importancia, ya que trat´andose del mismo robot, los m´etodos de programaci´on, y los modos de comunicarse con el exterior pueden ser muy diferentes dependiendo del controlador. Para el controlador especificado, aparte del conocimiento disponible por el personal con el que se ha colaborado, se han consultado los manuales contenidos en la bibliograf´ıa [9] y [11]. Sobre este controlador en cuesti´on, y la manera en la que se instal´o, ya han versado otros proyectos y trabajos previos, por lo que no se pretende repetir de nuevo esa informaci´on. No obstante s´ı que se remarcan los siguientes aspectos importantes de ´el: Incluye un terminal de ense˜nanza, denominado ((Teach Pendant)), con el cual se puede realizar la programaci´on completa del robot, y del que se hablar´a m´as adelante. Dispone de tarjetas para las conexiones f´ısicas de entradas y salidas digitales. Durante la realizaci´on de este proyecto, se han llevado a cabo algunas modificaciones respecto a las originales (Ver ap´endice A). El resultado final es de 8 salidas digitales (DO) y 9 entradas digitales (DI), adem´as de m´ultiples entradas y salidas de control y de seguridad hasta completar las 16 entradas y 16 salidas posibles (Limitaci´on debida al m´odulo de entradas y salidas modelo ((ADVANTYS STB)) al que est´an cableadas). Como se acaba de comentar, dispone de una serie de entradas y salidas digitales de seguridad, aptas para un control robusto. Dichas entradas y salidas no son dependientes del programa en ejecuci´on, sino que dependen ´unicamente del hardware, por 15 16 CAP´ ITULO 3. PROGRAMACI ´ ON DEL ROBOT INDUSTRIAL Figura 3.1: Armario del controlador RJ-3 del robot FANUC, con el terminal de ense˜nanza en primer plano. lo que son consideradas como robustas frente a posibles bloqueos del programa. El cableado completo de estas entradas y salidas en su forma actual, se adjunta en el ap´endice A. Tambi´en dispone de entradas y salidas digitales propias para la tarea a realizar por el robot. Sirvan como ejemplo las que controlan la garra del mismo. Uno de los aspectos m´as importantes que posee el controlador es la protecci´on contra sobre-esfuerzos. El controlador es capaz de detectar la sobre-intensidad que se provoca en los motores cuando estos intentan hacer un movimiento, y dicho movimiento no se puede realizar debido a un obst´aculo, un atasco... En ese momento se corta la corriente, y el controlador entra en un estado de ((Falta)). Para salir de dicho estado hay que utilizar el terminal de ense˜nanza o la botonera del controlador. Tambi´en existe una entrada digital que puede cumplir esa funci´on, aunque en este proyecto no ha llegado a utilizarse por considerarla potencialmente insegura (La potencial inseguridad se debe al hecho de que se cree una acci´on anti faltas, que libere al robot autom´aticamente sin comprobar su estado). Adem´as de la ya comentada protecci´on contra sobre-esfuerzos, tambi´en dispone el controlador de otros elementos de seguridad tales como fusibles y topes mec´anicos. No obstante, es necesario ser extremadamente cuidadoso para no provocar la entrada en funcionamiento de uno de estos sistemas de seguridad, ya que su bloqueo es mucho m´as costoso de solucionar, incluyendo la posible sustituci´on de piezas. 3.2. Terminal de ense˜nanza El terminal de ense˜nanza es un elemento muy importante del controlador, y extremadamente ´util a la hora de programarlo. Sin entrar en el modo de programaci´on mediante este elemento, que se detalla extensamente en uno de los manuales disponibles [12], se va a dar una breve descripci´on de sus funciones y c´omo se han usado para programar el robot durante este proyecto. 3.2. TERMINAL DE ENSE ˜ NANZA 17 Figura 3.2: Terminal de ense˜nanza del robot FANUC. Se aprecia el pulsador de emergencia. Como se puede observar en la figura 3.2, el terminal de ense˜nanza (en adelante TPE), dispone de m´ultiples botones, un selector y un pulsador de emergencia. Adem´as, tambi´en dispone de dos pulsadores de ((hombre muerto)) en la parte de atr´as. Las principales funciones del TPE, y m´as utilizadas durante el proyecto son las siguientes: Guiado del robot entre diferentes posiciones. El robot puede ser guiado manualmente mediante el TPE. Este guiado puede realizarse mediante el uso de un sistema de coordenadas globales (Articulares y cartesianas), coordenadas desde el punto de vista de la herramienta y coordenadas definidas por el usuario. Las m´as utilizadas durante el proyecto han sido las globales, tanto en formato articular como en cartesiano. La utilidad que ha tenido en este caso el guiado, ha sido fundamentalmente comprobar la alcanzabilidad de ciertas posiciones, comprobar las coordenadas calculadas previamente, y por supuesto la obtenci´on de coordenadas tanto globales como articulares para su posterior programaci´on en lenguaje de alto nivel. Otra de las funciones fundamentales que permite es la variaci´on de la velocidad del robot. Este aspecto, aunque parezca trivial, es muy importante, ya que parte de la precisi´on que puede alcanzar el robot proviene de la velocidad a la que est´a trabajando. Adem´as, a la hora de ejecutar los programas de prueba, el poder variar la velocidad de una forma r´apida es en extremo ´util, ya que permite realizar a mayor velocidad los tramos de programa ya seguros, y bajar la velocidad para controlar mejor los m´as novedosos o inseguros. No hay que olvidar la activaci´on de se˜nales digitales, que tambi´en puede hacerse de manera manual desde el TPE. Este aspecto ha sido muy ´util mientras se realizaba la programaci´on de los aut´omatas, ya que permit´ıa probar entradas y salidas sin tener que ejecutar un programa entero. 18 CAP´ ITULO 3. PROGRAMACI ´ ON DEL ROBOT INDUSTRIAL Aunque pueda resultar cuando menos curioso, otro aspecto para el que es necesario el TPE es para solucionar bloqueos y faltas. Es un caso muy frecuente que se intente hacer pasar al robot cerca de una singularidad (Estado cinem´atico que el controlador no es capaz de resolver), y en ese momento el robot entre en falta. Entonces, la manera m´as efectiva de desenclavar el robot es utilizar el guiado manual mediante el TPE, y luego ejecutar un programa o instrucci´on que lo devuelva a su posici´on de reposo. Tambi´en es necesario realizar esto cuando la falta ha sido provocada por un sobreesfuerzo o un bloqueo. 3.3. Hyper-terminal Se ha comentado ya que la programaci´on se ha realizado en lenguaje Karel, el cual se compila en un PC adjunto al robot. Es momento ahora de hablar sobre c´omo se han realizado las cargas de programas al robot. Con el objeto de ser breve, no se contar´a hasta el ´ultimo detalle de c´omo se carga el programa, si bien s´ı lo m´as importante. Todos los detalles y el m´etodo completo se encuentran en el manual de lenguaje Karel [10]. Figura 3.3: Vista del programa de comunicaci´on por puerto serie ((Hyper-terminal)). Figura 3.4: Vista del programa ((Kfloppy)), que emula una disquetera virtual. En esencia, el robot posee una memoria interna en la que guarda los programas, y a la cual se puede acceder mediante un puerto serie. Para poder utilizar el puerto serie, se dispone del programa ((Hyper-terminal)), que es el que establece la conexi´on. Para poder cargar mediante dicho puerto serie un programa al robot, es necesario emular una disquetera virtual del mismo, lo cual se hace con el programa ((kfloppy)), incluido dentro de los programas que suministra el fabricante. El programa (que tiene que estar ya compilado y convertido a formato binario), es transmitido al robot mediante una orden dada a trav´es del hyper-terminal. Su ejecuci´on tambi´en puede ser solicitada a trav´es del hyper-terminal. Como resumen de las ´ordenes que pueden ser dadas a trav´es del hyper-terminal, se pueden considerar las siguientes: Cargar un programa. 3.7. MATERIAL DOCENTE RESULTANTE 25 Finalizaci´on de programa. Tambi´en est´a programado como una interrupci´on, solo que su valor se guarda en una variable booleana, de tal manera que en el instante en que acabe el sub-programa en ejecuci´on (si lo hubiera), regresar´a a la posici´on de reposo y finalizar´a el programa principal. Carga de un carro. Realiza el cargado con tres cilindros del carrito situado m´as pr´oximo a la puerta junto a la estaci´on 6. Se utilizan para su programaci´on tanto coordenadas relativas como concatenaci´on de movimientos. Descarga de un carro. Es el inverso del anterior, solo que descarga el carro situado al otro lado de las cintas transportadoras, si se toma al robot como centro. Devuelve las piezas a la cinta de suministro. 3.7. Material docente resultante De lo que es puramente la programaci´on del robot, se ha obtenido material para realizar un gui´on de pr´acticas (con su soluci´on), equivalente a la pr´actica que se realizaba con otro modelo de robot en la asignatura ((Control y Programaci´on de Robots)), impartida en Ingenier´ıa Industrial. En esencia, la pr´actica consiste en tener que manejar mediante el terminal de ense˜nanza el robot, para obtener las coordenadas de diversas posiciones. Posteriormente hay que programar el robot para que en base a las posiciones conseguidas, simule el proceso de realizaci´on de dos puntos de soldadura, y un cord´on de soldadura por el borde de una caja de cart´on. El contenido ´ıntegro del gui´on de la pr´actica se encuentra en el ap´endice G. Adem´as del material directamente resultante de este cap´ıtulo, los conocimientos y parte del material derivado del mismo, junto con el resultado de cap´ıtulos posteriores, han servido para crear m´as material de uso docente, as´ı como ´utiles manuales sobre el uso de los elementos de la c´elula de fabricaci´on sobre la que versa gran parte de este proyecto. Es por ello que el trabajo desarrollado y explicado durante este cap´ıtulo es una parte b´asica del que se desarrollar´a en cap´ıtulos posteriores. Cap´ıtulo 4 Control del robot con aut´omatas Aunque el objeto principal de este cap´ıtulo es explicar c´omo se ha realizado la comunicaci´on y el control del robot mediante un aut´omata programable, se extender´a la explicaci´on al control de todos los elementos de la c´elula de fabricaci´on mediante los aut´omatas programables utilizados, dado que se realiz´o de forma secuencial en el tiempo y mediante id´enticos principios b´asicos. 4.1. Comunicaci´on entre aut´omata y robot Un aspecto muy importante, y a su vez un constante reto a lo largo de todo el proyecto ha sido c´omo comunicar el robot y el aut´omata. Si bien desde el primer momento se tuvo claro que lo deseado era que el robot recibiera ´ordenes simples del aut´omata, que pod´ıan perfectamente ir contenidas en se˜nales digitales, el c´omo efectuar ese paso de datos era un problema a resolver. Como ya se ha comentado en el cap´ıtulo 2, el estado original de las comunicaciones del robot era considerablemente diferente al que se ha adoptado finalmente. En primer lugar, el robot se encontraba conectado a un m´odulo de entradas y salidas modelo ((TSX MOMENTUM)), y s´olo ten´ıa conectadas unas pocas entradas y salidas digitales, una se˜nal de encendido y otra de emergencia. Los motivos para cambiar este m´odulo fueron m´ultiples, aunque no se debieron exclusivamente a su inoperatividad, sino tambi´en a razones de homogeneizar los m´odulos conectados a aut´omatas, y facilidad de uso. El nuevo m´odulo que se ha instalado durante la realizaci´on de este proyecto, y que es el utilizado actualmente, es como en todas las estaciones que cuentan con un aut´omata M340, una isla ((Advantys STB)) con cabecera de bus CANopen. En un principio se instalaron en la isla 6 m´odulos de entradas y salidas (tres m´odulos de cada tipo), alcanzando doce entradas y catorce salidas (ver figura 4.1). En previsi´on de posibles ampliaciones y en previsi´on de que pudiera realizarse una programaci´on que requiriera mayores prestaciones, se decidi´o cambiar estos m´odulos por otros m´as potentes que proporcionan 16 entradas y 16 salidas, con la utilizaci´on de s´olo dos m´odulos en lugar de los cinco anteriores (ver figura 4.2). La idea de utilizar un m´odulo con cabecera de tipo CANopen se debe a que como en el 27 28 CAP´ ITULO 4. CONTROL DEL ROBOT CON AUT ´ OMATAS Figura 4.1: Isla Advantys STB que se instal´o inicialmente. Figura 4.2: Isla Advantys STB que se encuentra actualmente instalada. resto de estaciones, el deseo era situar un aut´omata pr´oximo al robot que lo controlara. En un primer momento el aut´omata que se situ´o para controlar al robot era un aut´omata de iguales caracter´ısticas que el resto de los que hay en el laboratorio. M´as adelante se le a˜nadir´ıa un m´odulo de comunicaciones ((NOE)) del que se hablar´a m´as adelante en el apartado 4.3.2, y que diferencia a este aut´omata de los dem´as en cuanto a prestaciones, ya que las aumenta. Para poder utilizar la isla Advantys, tanto la primera en ponerse, como la que se coloc´o despu´es y a´un perdura, ha sido necesario realizar la configuraci´on de sus m´odulos. Dicha configuraci´on se realiza mediante el programa para PC ((Advantys)), suministrado por el mismo fabricante de las islas Advantys, Schneider Electric. Dado que en el momento de realizar dicha configuraci´on, no se contaba con esos conocimientos, fue necesario consultar diferentes manuales[22], [23], [25] y como resultado de ello y de la experiencia obtenida, se cre´o el ((Manual de configuraci´on de un m´odulo Advantys para su funcionamiento con un aut´omata MODICON)). Dicho manual se adjunta en el ap´endice C. Haciendo un resumen de las conexiones del robot con los aut´omatas se concluye que tras el trabajo realizado durante este proyecto: El robot est´a cableado f´ısicamente con un m´odulo ((Advantys STB)) de entradas y salidas (Todos los detalles en el ap´endice A). Ese m´odulo est´a conectado, mediante un bus CANopen de dos puntos de acceso, a un aut´omata M340 situado junto al robot. Ese aut´omata adem´as de poder realizar el control del robot de forma directa, puede servir de pasarela a otros aut´omatas mediante la red Ethernet. 4.2. Programaci´on de los aut´omatas La programaci´on de los aut´omatas realizada durante el proyecto se va a tratar de abordar de una manera sencilla y concisa. Se intentar´an evitar los puntos m´as t´ecnicos as´ı como 4.2. PROGRAMACI ´ ON DE LOS AUT ´ OMATAS 29 incluir c´odigo innecesariamente. No obstante, el c´odigo completo se puede encontrar en el ap´endice E. El software utilizado para realizar la programaci´on de los aut´omatas, ha sido el programa ((Unity PRO)). Este programa es del propio fabricante de los aut´omatas, y es un software muy vers´atil, ya que permite la programaci´on en cuatro lenguajes para aut´omatas diferentes: LD (Ladder Diagram, o Diagrama de Contactos). Se trata de un lenguaje antiguo proveniente de los diagramas de rel´es. Es poco potente, y no se ha empleado en la programaci´on de este proyecto. IL (Lista de Instrucciones). Es un lenguaje de instrucciones extremadamente b´asicas, muy parecido al ensamblador para el c´odigo m´aquina. Puede ser muy eficiente, pero es asimismo muy complicado de seguir, por lo que tampoco se ha utilizado. ST (Texto estructurado). Se trata de un lenguaje muy parecido a los lenguajes de programaci´on de alto nivel m´as habituales como C++. Es relativamente sencillo de usar y muy vers´atil. Se ha utilizado as´ıduamente durante este proyecto. SFC (Sequential Function Chart o Diagrama de Funciones Secuenciales). Es un lenguaje que reproduce en bastantes aspectos lo que ser´ıa un diagrama Grafcet. Ha sido tambi´en muy utilizado en el proyecto por ser un lenguaje muy visual y adecuado para realizar con facilidad su seguimiento durante la ejecuci´on. Para ilustrar dos de estos lenguajes se adjuntan las figuras 4.3 y 4.4. Figura 4.3: Ejemplo de programa SFC. Se aprecian varias acciones secuenciales, y dos en paralelo. Figura 4.4: Ejemplo de programa LD. Se aprecian diversas condiciones a la izquierda, y algunas acciones a la derecha. Como regla general sobre la utilizaci´on efectuada de los dos lenguajes de programaci´on que se han se˜nalado, se puede indicar lo siguiente: Para los programas de control de las estaciones, debido a su gran versatilidad para acciones secuenciales, se ha utilizado el lenguaje SFC. Tambi´en se ha utilizado este lenguaje a la hora programar la selecci´on de tareas del robot. El lenguaje ST se ha utilizado fundamentalmente para realizar las copias de variables, operaciones booleanas de comparaci´on o verificaci´on, y para otras instrucciones y rutinas inmediatas como los desencadenantes de las acciones del robot. 30 CAP´ ITULO 4. CONTROL DEL ROBOT CON AUT ´ OMATAS Se pasa a continuaci´on a analizar con algo m´as de profundidad los puntos b´asicos de los programas del aut´omata principal y del aut´omata de la estaci´on de expedici´on de palets. La divisi´on entre aut´omata principal y secundarios se analiza exhaustivamente en el apartado 4.3.1. 4.2.1. Aut´omata principal El aut´omata principal (figura 4.5), como se explicar´a en el apartado 4.3.1, cumple dos funciones: Por una parte es un aut´omata secundario que controla dos estaciones de la sub-c´elula de pedidos (el robot y la estaci´on de transporte) de manera independiente. Y por otra parte es el aut´omata que controla y coordina a todos los dem´as cuando se quiere que la sub-c´elula funcione integrada. Esto s´olo es posible mediante una minuciosa programaci´on, en la cual se consideran tres programas, dos de los cuales son independientes entre s´ı, y un tercero, de jerarqu´ıa superior, que es capaz de manejar a los otros dos. De esta manera, el aut´omata principal contiene los programas correspondientes a lo que ser´ıan dos aut´omatas secundarios, y el programa que ejecutar´ıa el aut´omata principal. Figura 4.5: Aut´omata principal, situado junto al robot industrial. Figura 4.6: Aut´omata secundario presente en la estaci´on de expedici´on de palets. Programa que controla al robot: El programa que controla al robot, es un programa que se trat´o de hacer lo m´as sencillo posible, pero que cumpliera su funci´on. Su funcionamiento se basa en dos premisas: El robot tiene tres estados desde el punto de vista de la seguridad: Operativo, apagado o en emergencia. Dentro de operativo adem´as puede estar en reposo (preparado para realizar nuevas tareas), o realizando una tarea. El ´unico estado habilitante para poder realizar tareas es el de Operativo. Cualquier petici´on realizada mientras el robot est´a en otro estado deber´a ser rechazada. El robot s´olo es capaz de realizar una ´unica tarea al mismo tiempo. Si un usuario solicita dos diferentes, es el aut´omata el que debe discernir. Por otra parte, si en el 4.2. PROGRAMACI ´ ON DE LOS AUT ´ OMATAS 31 momento en el que el robot se quede libre, la tarea que anteriormente se ha denegado en favor de otra todav´ıa est´a solicitada, debe poder ejecutarse. De acuerdo con las premisas anteriores, ambas fruto de la experiencia de las primeras tomas de contacto, se program´o el aut´omata que controla al robot. El programa en esencia consiste en dos diagramas grafcet disjuntos, que controlan por una parte la selecci´on de tareas del robot, y por otra parte la seguridad. La selecci´on se realiza de la siguiente forma (Figura 4.7): Estando el robot en reposo, se abre un abanico de siete posibilidades. De estas siete posibilidades (Coincidentes con las siete tareas comentadas en el apartado 3.6), se pueden elegir todas (Salvo unos casos especiales que se comentar´an m´as adelante). El m´etodo de elecci´on depende del operario, ya que est´an disponibles al menos dos m´etodos diferentes1 (Botonera f´ısica y terminal de di´alogo). Una vez se ha realizado la selecci´on, se pasa a un estado de pre-ejecuci´on, en el cual se env´ıa la orden al robot. En cuanto el robot confirma el inicio del programa, se pasa a un estado de ejecuci´on de tarea. Este estado durar´a hasta que el robot indique que ha acabado. Cuando el robot confirma que ha acabado, se vuelve al estado de reposo. Y si no hay ning´un problema, se pasa al estado de robot preparado. Respecto a los casos especiales que se han mencionado anteriormente, son los siguientes: El trenecito mencionado en el apartado 3.6, inicialmente se considera desmontado. Por tanto, la tarea ((desmontar tren)) est´a deshabilitada hasta que se haya montado una vez. Del mismo modo ocurre con la tarea ((montar tren)), ya que si el tren ha sido montado queda deshabilitada hasta que se desmonte. La tarea ((cargar palet)) solo est´a disponible cuatro veces de forma consecutiva, de tal manera que si se han llenado los cuatro carritos, no puede ejecutarse hasta que se vac´ıe uno de ellos. De una forma parecida ocurre con ((descargar palet)), que solo puede realizarse si previamente se ha realizado la carga de al menos un palet. Programa que controla la seguridad del robot: En realidad se trata de una parte del programa que controla al robot, pero se describe como parte separada a continuaci´on para darle un valor a˜nadido debido a que es muy importante para la seguridad. Este programa es muy directo, y est´a basado en el diagrama grafcet que se puede ver en la figura 4.8. Sus funciones, que son muy b´asicas, son detener el programa del aut´omata en aquellos casos en los que el robot est´e en emergencia o apagado. Ambos casos son un poco diferentes. En el caso de que el robot est´e apagado, lo ´unico que sucede es que se deshabilita la condici´on de robot preparado, con lo cual el robot no puede alcanzar el estado de robot preparado (ver figura 4.7). En el otro caso, cuando se entra en una situaci´on de emergencia, la acci´on es m´as contundente. Se paraliza el desarrollo del grafcet que controla al robot, y se reinicia ese grafcet 1Al menos dos significa que adem´as de la botonera y del terminal de di´alogo, tambi´en se entra en esa selecci´on cuando se opera de manera automatizada toda la sub-c´elula, solo que no lo hace un operario. 32 CAP´ ITULO 4. CONTROL DEL ROBOT CON AUT ´ OMATAS Figura 4.7: Ejemplo de SFC, correspondiente a la selecci´on de programa del robot. Se aprecia una selecci´on y diversas acciones secuenciales. Figura 4.8: SFC correspondiente a la gesti´on de la seguridad del robot. una vez se ha solventado la emergencia. Este segundo caso es m´as importante ya que si no se reiniciara el grafcet de control del robot, se volver´ıa a ejecutar la misma orden que se hab´ıa dado antes de la emergencia, 4.2. PROGRAMACI ´ ON DE LOS AUT ´ OMATAS 33 pudiendo volver a provocar el mismo resultado. Programa que controla la estaci´on de transporte: Consiste en un programa basado en un grafcet de etapas secuenciales (Figura 4.9), ya que todas las acciones necesarias para controlar la estaci´on de transporte se realizan de forma consecutiva. Figura 4.9: SFC correspondiente al control de los transportes (Cintas, topes, desv´ıos...). En esencia su funcionamiento es el siguiente: La estaci´on est´a en reposo hasta que recibe la orden de mover los carros una posici´on (Habilitar la transici´on ((avanzar 1 pos))); Se produce el desbloqueo de los carros y se ponen en marcha las cintas transportadoras; Transcurrido un breve tiempo (obtenido de forma experimental), se considera que los carros ya est´an desplazados lo suficiente de sus bases, y se activan los topes; Se sigue produciendo el movimiento de los carros hasta que van llegando a su posici´on de destino, en la cual se paran mediante el tope correspondiente, y esperan a que todos est´en en posici´on; Una vez en su posici´on, que se detecta por medio de sensores inductivos y capacitivos, se activan los bloqueos y se paralizan las cintas; Llegados a este punto, el programa termina y se vuelve al estado de reposo, hasta que vuelva a llegar la orden de inicio. Programa que controla toda la sub-c´elula de expedici´on de pedidos: ´ Este es realmente el programa que hace que el aut´omata adosado al robot sea el aut´omata principal. Hasta el momento se hab´ıa hablado de programas propios de un aut´omata secundario, solo que en este caso se implementaban todos a la vez en el mismo aut´omata debido a que puede soportarlos todos. Pero el programa que se describe a continuaci´on es propio de un aut´omata de jerarqu´ıa superior (superior en nivel de mando, lo que no implica que tenga que ser superior en prestaciones). El programa que controla la sub-c´elula completa, se basa nuevamente en un diagrama grafcet con una importante componente secuencial y con car´acter c´ıclico, que se muestra en la figura 4.10. 34 CAP´ ITULO 4. CONTROL DEL ROBOT CON AUT ´ OMATAS Figura 4.10: SFC correspondiente al control de la sub-c´elula completa (controlada totalmente por el aut´omata principal). Dado que su funci´on es permitir el funcionamiento autom´atico y continuado de la subc´elula, su estructura es fundamentalmente de car´acter c´ıclico y se puede dividir en dos partes: En primer lugar hay una parte no-c´ıclica, correspondiente a la inicializaci´on de la subc´elula. En ella lo que se hace es colocar una placa contenedora en un carro, y avanzarlo una posici´on, de tal forma que quede listo para ser cargado. En segundo lugar aparece la parte c´ıclica del grafcet. Mientras est´e activada la condici´on ((modo autom´atico)) (resultante de colocar el selector ((MAN/AUT)) en posici´on ((AUT)), el selector ((IND/INT)) en posici´on ((INT)) y haber pulsado ((marcha)) una vez; Ver figura 4.11), se repite c´ıclicamente la siguiente secuencia: Se carga un carro con tres cilindros, se carga el carro siguiente con una plaquita del color que se haya definido, y se avanzan los carros una posici´on. Resultando siempre un carro totalmente vac´ıo en la estaci´on expendedora de palets, y un carro con plaquita y sin cilindros en la estaci´on del robot. Figura 4.11: Botonera f´ısica de la estaci´on de transporte. Se aprecian los diferentes pulsadores y selectores a los que se hace referencia. La manera que tiene el programa de controlar a los otros programas es muy directa. Los otros programas act´uan como si controlaran a sus estaciones de manera aut´onoma, con la diferencia de que la se˜nal que provoca el comienzo del programa solo puede provenir Cap´ıtulo 5 Supervisi´on mediante terminal de di´alogo 5.1. Motivaci´on del uso de un terminal de di´alogo Los terminales de di´alogo son elementos muy extendidos actualmente en todos los procesos automatizados. Debido entre otras cosas a su gran versatilidad a la hora de ser programados, y al hecho de que aumentan mucho la facilidad de manejo de la instalaci´on ya que si la programaci´on se ha realizado adecuadamente, son bastante intuitivos. Sirva la figura 5.1 como ilustraci´on de lo que puede ser la pantalla de un terminal de di´alogo en su utilizaci´on en una industria. Figura 5.1: Ejemplo de terminal de di´alogo en una industria. Respecto a los motivos de su utilizaci´on, se dio adem´as de todas sus virtudes, la circunstancia adicional de que entre el material disponible en el laboratorio L 0.6 del edificio Ada Byron, existen cinco terminales de di´alogo, modelo ((MAGELIS XBTGT4330)), del fabricante Schneider Electric. Debido a su disponibilidad, a la existencia de material sobre c´omo utilizarlos [27], y al gran valor a˜nadido que pod´ıan aportar al proceso de integraci´on en curso, se decidi´o su incorporaci´on al mismo. 41 42 CAP´ ITULO 5. SUPERVISI ´ ON MEDIANTE TERMINAL DE DI ´ ALOGO 5.2. Modificaciones necesarias en la programaci´on de los aut´omatas La utilizaci´on de estos terminales de di´alogo, implicaba la necesidad de replantear c´omo se deb´ıa acceder al control de los aut´omatas, ya que como es l´ogico, no debe de permitirse el acceso desde diferentes elementos al mismo tiempo, ya que podr´ıan incluso dar ordenes contradictorias. Por ello, lo que se decidi´o fue que el acceso al control de los aut´omatas viniera determinado por la botonera f´ısica presente en cada una de las estaciones. De esta manera se evita la posibilidad de que sean controlados desde dos accesos diferentes. El selector ((MAN/AUT)) de la botonera fue el elegido para la disyunci´on entre el control mediante la botonera y el terminal de di´alogo. En el apartado 4.3 se puede consultar la tabla 4.1, en la cual se detalla c´omo operar con este selector. Aunque en el referido apartado 4.3 ya se habla brevemente sobre el c´odigo empleado para el uso de los terminales de di´alogo, se va a especificar un poco m´as c´omo se realiza y por qu´e se ha hecho as´ı. Para la utilizaci´on de los terminales Magelis, es necesario el uso de unas variables intermedias pertenecientes a la memoria del aut´omata. Esto es as´ı porque: Los terminales Magelis tienen capacidad para leer y escribir cualquier posici´on de la memoria interna del aut´omata. Pero solo de la memoria interna, ya que no es posible acceder a ninguna otra direcci´on de memoria. Originalmente, los programas se dise˜naron para ser dirigidos mediante la botonera. Por ello algunos desencadenantes ven´ıan dados por las variables en las cuales se escribe el estado de la botonera (A trav´es del bus CANopen). El terminal Magelis es capaz de leer las posiciones donde se escribe el estado de la botonera, pero no es capaz de escribir sobre ellas porque son actualizadas cada ciclo de reloj con los valores reales. Por tanto, para que el terminal pueda dirigir las operaciones, lo que se hizo es una ((copia)) de las variables originales. Esa ((copia)) recibe el valor de las variables de la botonera cuando dicha botonera est´a habilitada, o es modificada por el terminal Magelis cuando este est´a habilitado. Sirva la figura 5.2 para ilustrar c´omo funciona la asignaci´on de valor a las variables que manejan los programas de los aut´omatas. 5.3. Integraci´on en el conjunto Una vez realizadas las modificaciones necesarias en el c´odigo de los aut´omatas, se pas´o a realizar el dise˜no de los terminales. En concreto se han dise˜nado dos terminales diferentes: Uno para la supervisi´on de la c´elula completa (cuando funciona en modo continuo), que 5.3. INTEGRACI ´ ON EN EL CONJUNTO 43 Figura 5.2: Diagrama explicativo del acceso a memoria. La posibilidad de acceder a la memoria est´a condicionada seg´un el selector MAN/AUT. tambi´en puede controlar al robot y a la estaci´on de transporte (en modo no continuo). Y otro para la supervisi´on (en modo integrado) de la estaci´on de expedici´on de palets, y su control cuando se utiliza en modo aislado. Para la programaci´on de estos terminales se ha utilizado el software ((Vijeo-Designer)) suministrado por el propio fabricante Schneider Electric. La documentaci´on de referencia ha sido una pr´actica de una asignatura de Ingenier´ıa Industrial [27], as´ı como la ayuda contenida dentro del programa. Figura 5.3: Pantalla del terminal dise˜nado para controlar el conjunto. Figura 5.4: Pantalla del terminal dise˜nado para la estaci´on expendedora de palets. La programaci´on mediante este software es relativamente intuitiva debido al aspecto de car´acter actual del programa, y permite como se puede comprobar en las figuras 5.3 y 5.4 un resultado bastante atractivo y f´acil de interpretar. El objetivo perseguido con los dise˜nos realizados era lograr la mayor facilidad de uso de los terminales, y dar toda la informaci´on posible sobre el estado del funcionamiento de la c´elula. 44 CAP´ ITULO 5. SUPERVISI ´ ON MEDIANTE TERMINAL DE DI ´ ALOGO Ambos paneles realizados poseen en com´un los siguientes elementos: Un pulsador de emergencia. El cual se trat´o de hacer lo m´as visible posible. Este pulsador est´a disponible siempre, incluso cuando el terminal est´a deshabilitado. Botones y pilotos. Sirven respectivamente para cambiar el estado de variables de tipo booleano, y para mostrar su estado. Cuadros de di´alogo. Permiten se˜nalar el estado de la c´elula mediante la visualizaci´on de diferentes textos. El texto a mostrar se selecciona dependiendo de una variable de tipo entero, que es cambiada por el programa del aut´omata en funci´on de en qu´e estado se encuentra. Adem´as de estos puntos en com´un, tambi´en aparecen ventanas emergentes, paneles de informaci´on de emergencias y visualizadores num´ericos. Un punto a tener en cuenta en el caso de ambos terminales es que cuando est´an deshabilitados (Ver figuras 5.5 y 5.6), aquellos botones que pierden su funci´on desaparecen de la pantalla. Facilitando as´ı la detecci´on de que el terminal est´a deshabilitado. Este estado tambi´en se se˜nala mediante los paneles de informaci´on. En cualquier caso, con el panel deshabilitado a´un se puede supervisar por separado el estado del conjunto o de la estaci´on 6 (en sus respectivos terminales), mediante la visualizaci´on de algunas variables y de los paneles informativos. Figura 5.5: Terminal de la estaci´on de expedici´on de palets en estado habilitado Figura 5.6: Terminal de la misma estaci´on en estado deshabilitado. Desaparece la botonera dado que no se permite su uso. En las figuras 5.5 y 5.6 se observa claramente c´omo algunos botones han desaparecido al deshabilitar el terminal. La deshabilitaci´on adem´as se puede distinguir f´acilmente debido a que el cuadro de habilitaci´on ha pasado de verde a rojo. N´otese que el pulsador de emergencias sigue habilitado en ambos casos, as´ı como todos los elementos que sin controlar la estaci´on, dan informaci´on sobre ella. 5.4. MATERIAL DOCENTE RESULTANTE 45 5.4. Material docente resultante Del conjunto de todos los elementos utilizados hasta ahora, se ha obtenido informaci´on para la realizaci´on de una propuesta de gui´on para un pr´actica muy completa, que a´una tanto la programaci´on de un robot, como de un aut´omata, y la utilizaci´on de terminales de di´alogo para la supervisi´on (y el control si se desea) de la sub-c´elula de expedici´on de pedidos. Dicha pr´actica, cuya propuesta consta de dos partes, se adjunta en los ap´endices H e I. Adem´as, debido a la posibilidad de que la propuesta anteriormente mencionada fuera excesivamente ambiciosa para una sesi´on pr´actica de la duraci´on habitual, y para posibilitar m´as opciones, se ha desarrollado una segunda propuesta, encaminada ´unicamente a ense˜nar c´omo usar los terminales de di´alogo, para el control de tres estaciones diferentes de la c´elula completa. En concreto, de las estaciones 1, 3 y 4. El gui´on propuesto se adjunta en el ap´endice J. Para esta ´ultima pr´actica, tambi´en ha sido necesario realizar una programaci´on b´asica de los aut´omatas que controlan respectivamente a las estaciones 1, 3 y 4. Hay que destacar que una versi´on adaptada de esta propuesta de pr´actica ya ha sido empleada en una asignatura de grado. Cap´ıtulo 6 Incorporaci´on de una c´amara RGB-D Las c´amaras RGB-D son dispositivos de percepci´on un tanto especiales, ya que a´unan las caracter´ısticas de una c´amara RGB, con las de un sensor de rango (de profundidad). El resultado que ofrecen es una imagen que combina el color de cada punto con la posici´on respecto a la c´amara de dicho punto. Esta informaci´on adicional, convierte a este tipo de dispositivos en elementos extremadamente ´utiles, en tanto que son capaces de obtener de una misma escena mucha m´as informaci´on que uno solo de los dispositivos que combinan, y de un modo mucho m´as eficaz que si hubiera que utilizar dos dispositivos independientes. Figura 6.1: C´amara RGB-D modelo ((Asus Xtion Pro Live)) utilizada durante este proyecto. Como se puede observar en la figura 6.1, se distinguen tres dispositivos en el frontal de la c´amara. Uno de ellos es la c´amara RGB. Los otros dos son el emisor de infrarrojos para la proyecci´on de patrones, y el receptor de infrarrojos para obtener coordenadas a partir de esos patrones (M´as informaci´on en apartado 6.2). La Universidad de Zaragoza dispone de varios de estos dispositivos, y dada la posibilidad de utilizarlos, y tras valorar su utilidad (Ver apartado 6.1), se procedi´o a incorporarlos al proyecto. 6.1. Motivaci´on para el uso de una c´amara RGB-D Aunque en un principio pueda costar el ver la utilidad inmediata que tiene el uso de una c´amara RGB-D en un proceso de automatizaci´on, tras el desarrollo de algunos programas, y en base a la experiencia adquirida, es posible afirmar que tienen un largo recorrido en 47 48 CAP´ ITULO 6. INCORPORACI ´ ON DE UNA C ´ AMARA RGB-D aplicaciones tales como la seguridad, la identificaci´on y la localizaci´on de objetos. Figura 6.2: Imagen RGB capturada por la c´amara. Figura 6.3: Imagen resultado de la combinaci´on del color y la profundidad. Se aprecian puntos con color y posici´on. En primer lugar es interesante tener una representaci´on gr´afica de qu´e se obtiene de este tipo de c´amaras. Sirvan para ello las figuras 6.2 y 6.3. En estas im´agenes, especialmente en la segunda de ellas, se pueden apreciar los puntos que conforman los datos que proporciona esta c´amara. La importancia de tener informaci´on sobre las coordenadas de cada punto de la escena es alta, ya que un cl´asico de la visi´on por computador es el dedicar un gran esfuerzo a obtener las coordenadas de un punto, mediante la resoluci´on de ecuaciones procedentes de algoritmos complejos de emparejamiento de puntos, a partir de c´amaras est´ereo. Por tanto, la ventaja que proporciona este formato de c´amaras es la de aligerar mucho los c´alculos, con lo que se obtiene un procesamiento de imagen mucho m´as fluido. Por parte de la automatizaci´on industrial y la rob´otica, el uso de la visi´on es ya un hecho consumado, por lo que el inter´es radicaba en este caso en ver cu´an eficientes pod´ıan ser los algoritmos de estas c´amaras para competir con la visi´on por computador m´as cl´asica, y ya implantada en este sector. En resumen, el objetivo de introducir la visi´on por computador mediante c´amaras RGB-D en este proyecto era fundamentalmente comprobar la gran potencialidad que se les supone a estas c´amaras, en concreto como asistencia a la rob´otica. Como avance, se han planteado dos l´ıneas a explorar: Por un lado el aspecto de control de seguridad dentro del espacio de trabajo de un robot. Y por otra parte, la identificaci´on de algunos de los peque˜nos objetos que est´an presentes en la c´elula de transporte sobre la que se ha estado trabajando durante el proyecto. Esta parte del proyecto se ha realizado con la intenci´on de proporcionar informaci´on ´util sobre la manejabilidad y el potencial de estas c´amaras, as´ı como unos ejemplos demostrativos, y que puedan servir de base para futuras l´ıneas a trabajar. 6.2. OBTENCI ´ ON DE LA INFORMACI ´ ON 49 6.2. Obtenci´on de la informaci´on Esta secci´on no pretende m´as que esbozar c´omo se obtiene la informaci´on que m´as tarde se utilizar´a. Por ello, en caso de necesitar m´as informaci´on, ser´a necesario consultar las referencias que se citan a lo largo de este cap´ıtulo. El dispositivo utilizado para la obtenci´on de los datos es una c´amara de tipo RGB-D, modelo Asus X-tion Pro Live. Se trata de un dispositivo orientado a desarrolladores, de car´acter no industrial, cuyo m´aximo exponente de utilizaci´on actualmente podr´ıa ser la c´amara ((KINECT)) para videoconsolas XBOX. A d´ıa de hoy existen dispositivos RGB-D de car´acter industrial, aunque son mucho menos asequibles, y menos adecuados para el ligero desarrollo que se ha hecho durante este proyecto. Las principales caracter´ısticas del modelo empleado en este proyecto son las que se muestran en la tabla 6.1. M´as informaci´on en [3]. Rango de uso Entre 0.8 m y 3.5 m Campo de vista 58oHorizontal, 45oVertical, 70oDiagonal Sensores RGB, profundidad y 2 micr´ofonos Tama˜no de la imagen VGA (640x480) hasta 30fps (Fotogramas por segundo). de profundidad QVGA (320x240) hasta 60fps Interfaz USB 2.0 ´o 3.0 Entorno de trabajo Interior Tabla 6.1: Caracter´ısticas del dispositivo RGB-D. La captura de im´agenes, ya sean de color o de profundidad, se puede hacer de dos maneras diferentes, dependiendo de las necesidades del programa. Por una parte, la m´as sencilla es realizar una captura individual, y trabajar sobre ella extrayendo toda la informaci´on. La pr´oxima captura se realizar´a cuando se haya completado el trabajo con la primera, si es que se solicita una segunda captura. La otra forma de trabajar consiste en lo que se denomina un funci´on de ((devoluci´on de llamada)). Esta funci´on realizar´a fotos continuamente, corriendo en paralelo al programa principal que se est´e utilizando. Para aprovechar toda la informaci´on que captura, requiere de programas muy ligeros. En caso de que el tiempo de c´alculo sea mayor que el tiempo entre dos fotogramas, se perder´a el ´ultimo (o los ´ultimos). A continuaci´on se realizar´a una breve explicaci´on del modo en el que se representa y ordena la informaci´on capturada mediante este dispositivo. Tambi´en se explicar´an brevemente las librer´ıas de funciones utilizadas. 6.2.1. Representaci´on y almacenamiento de la informaci´on Una manera muy pr´actica de almacenar la informaci´on dada por una c´amara RGB-D, y la usada en este proyecto, es lo que se denominan ((Nubes de puntos)). En concreto seg´un el formato utilizado en las librer´ıas de funciones PCL (Point Cloud Library)[16]y[17] , una nube de puntos consiste en una matriz bidimensional, que contiene toda la informaci´on 50 CAP´ ITULO 6. INCORPORACI ´ ON DE UNA C ´ AMARA RGB-D que la c´amara es capaz de capturar. En primer lugar es un vector ordenado, en el que cada posici´on corresponde a uno de los puntos que la c´amara puede captar (307200 en el caso de resoluci´on VGA(640x480)). Cada una de estas posiciones, contiene un nuevo vector en el cual se almacenan los siguientes datos: Color. Con sus tres canales (R, G y B). Dependiendo del formato de datos tambi´en puede darse en su formato hexadecimal. Posici´on. Con otros tres par´ametros (X, Y, Z). Tambi´en existe la opci´on NaN (Not a Number) que indica que no se ha podido realizar la medida para ese punto. Otra informaci´on relevante. Por ejemplo el n´umero de puntos, el vector normal a cada punto, el punto de vista de la c´amara... En la figura 6.4 se explica de un modo m´as gr´afico la manera en la que se almacena toda la informaci´on. El tipo de archivo es propio de la librer´ıa comentada, y su extensi´on es ((.PCD)). Figura 6.4: Esquema explicativo del almacenamiento de informaci´on en formato ((Nube de Puntos)). Como se puede entrever, el consumo de memoria es mucho mayor que en el caso de una fotograf´ıa normal, ya que la representaci´on del color en las nubes de puntos es solo una cuarta parte del total de informaci´on. L´ogicamente, esto hace muy costoso en cuanto a c´alculos el trabajar con nubes en bruto. Por ello un tratamiento muy usual es el de pasar un filtro que elimine aquellos puntos que no poseen informaci´on relevante de posici´on. O tambi´en un filtro denominado ((Voxelgrid)), que se encarga dividir la escena en ((cubos)), y convierte todos los puntos del interior de cada cubo en un ´unico punto, cuyas caracter´ısticas (color y posici´on) son el compendio de todos los puntos. 6.2.2. Segmentaci´on del escenario En visi´on por computador, segmentar una imagen consiste en dividirla en m´ultiples conjuntos de p´ıxeles. El objetivo de esta divisi´on es convertir, simplific´andola, la repre- 6.3. ALGORITMO PARA IDENTIFICAR OBJETOS 57 Figura 6.9: Imagen original, e identificaci´on realizada por el algoritmo. Se aprecian objetos identificados, y huecos en aquellos que no se han reconocido. 6.3.5. Informaci´on adicional de color para los conjuntos Como extensi´on final al algoritmo de identificaci´on de objetos, se ha introducido una diferenciaci´on del color de los objetos. Para proceder al reconocimiento del color, se ha realizado una discretizaci´on en el rango que la c´amara es capaz de captar en formato RGB. Originalmente la c´amara proporciona 256 valores para cada uno de los tres canales. No obstante, el algoritmo realiza una simplificaci´on de estos valores, permitiendo 3 valores por canal. Los colores que se han implementado (se les ha proporcionado un nombre y se es capaz de distinguirlos) son los 27 colores diferentes que corresponden al total de los posibles tras la simplificaci´on. La funci´on del algoritmo que se encarga de identificar los colores predominantes de un conjunto de puntos, y que ha sido ´ıntegramente creada en el proyecto, comienza por hacer la discretizaci´on de los colores. Despu´es prosigue haciendo un recuento del n´umero de puntos que tienen cada tipo de color. Por ´ultimo los ordena y guarda los tres colores mayoritarios, as´ı como la cantidad relativa de cada uno de esos tres colores. En la figura 6.10 se muestra un ejemplo de c´omo queda un objeto tras la rectificaci´on del color. Figura 6.10: Imagen original, y discretizaci´on del color realizada por el algoritmo. Se aprecia la adecuada conversi´on a colores m´as puros sin perder apenas informaci´on. 58 CAP´ ITULO 6. INCORPORACI ´ ON DE UNA C ´ AMARA RGB-D 6.3.6. Resultado en formato cualitativo y coordenadas En ´este ´ultimo punto se describe c´omo proporciona el algoritmo implementado la informaci´on que ha obtenido. En primer lugar, el algoritmo muestra visualmente informaci´on de c´omo est´a transcurriendo el proceso. Adem´as tambi´en tiene la opci´on de realizar todas las operaciones paso a paso para poder comprobar posibles fallos. La otra v´ıa para proporcionar informaci´on de la que dispone el algoritmo, es la generaci´on de un archivo de datos en formato de texto (ASCII), en el que plasma la informaci´on que ha obtenido, tanto cualitativa como cuantitativa. El archivo creado es de extensi´on ((.KL)), que es la extensi´on de los archivos de programa del robot. Con ello se pretende facilitar su uso por parte del programador del robot. La informaci´on cuantitativa viene dada por las coordenadas y tama˜nos de los objetos encontrados.La cualitativa la da la forma de dichos objetos, y su color. Se incluye en la figura (6.11)un ejemplo demostrativo del fichero de datos que se obtiene a partir del empleo del algoritmo de reconocimiento de objetos creado en este proyecto. Figura 6.11: Ejemplo del archivo de salida con los objetos que el algoritmo ha logrado identificar. Se incluyen el tipo de objeto, su posici´on, tama˜no, y colores principales. 6.4. Algoritmo de control del espacio de trabajo El otro algoritmo al que se hace menci´on en el apartado 6.1, es un detector de variaciones en espacios de trabajo controlados. Su utilidad es manifiesta, ya que su prop´osito es comparar continuamente mientras est´e conectado, la escena que capte a trav´es de la c´amara RGB-D, con una escena de referencia, y avisar cuando los cambios superen un umbral previamente establecido de riesgo. Con ello se puede comprobar la aparici´on de elementos inesperados o no deseados, o cu´ando un elemento de la zona de trabajo est´a fuera del sitio que le corresponde. La forma de trabajar de este algoritmo es muy directa: En primer lugar, est´a continuamente obteniendo capturas de la escena, lo que le permite (dependiendo de la potencia de c´alculo del computador asociado) un control de hasta 10 fotogramas por segundo. 6.4. ALGORITMO DE CONTROL DEL ESPACIO DE TRABAJO 59 Con cada escena, el proceso es efectivo y r´apido. En primer lugar crea un ´arbol de vecindad de los puntos de la nube obtenida. Y posteriormente los compara con los presentes en la escena de referencia. Los cambios detectados en los puntos (puntos que aparecen o desaparecen), son considerados como puntos cambiantes. Si la cantidad de puntos cambiantes es mayor que un umbral establecido por el usuario, salta una advertencia. y si supera un segundo umbral mayor, salta una alarma. Esta alarma podr´ıa servir para detener un proceso, o impedir su inicio, ya que la zona de trabajo no re´une las condiciones en principio previstas. Un punto a destacar de este algoritmo es que es relativamente inmune a los cambios de luz, ya que no utiliza el color, sino solo la informaci´on de profundidad. No obstante, tiene cierta variabilidad con la iluminaci´on, ya que cuanta m´as luz haya, mayores perturbaciones surgen en el patr´on infrarrojo que la c´amara emite, y m´as ruido aparece. Precisamente debido al ruido existente, se decidi´o que el programa realizara una peque˜na calibraci´on del ruido durante las primeras capturas de escena. En concreto sobre las 100 primeras capturas. Este ruido de referencia medido mediante el periodo de calibraci´on, no es tenido en cuenta para el c´omputo total de las variaciones. Esto es: Con respecto a la cantidad (ya expresada como un dato num´erico) de variaci´on detectada, el algoritmo eliminar´a la cantidad num´erica que se ha definido como ruido. Figura 6.12: Ejemplo de la salida por pantalla del algoritmo de control del espacio de trabajo. Como punto a ampliar de este algoritmo se propone su interconexi´on con otros dispositivos de seguridad tales como sensores de presencia, detectores de paso, puertas con 60 CAP´ ITULO 6. INCORPORACI ´ ON DE UNA C ´ AMARA RGB-D sensores... Ya que el algoritmo requiere ser reiniciado cada vez que se ha producido un cambio intencionado en la disposici´on de los elementos contenidos en el espacio controlado, o cada vez que en el espacio de trabajo se produzca un movimiento intencionado (como el funcionamiento de un robot). En la figura 6.12 se puede apreciar un ejemplo del resultado de este algoritmo. En la imagen se muestran en rojo los puntos que son diferentes de los que se ten´ıan como referencia. Se puede apreciar que corresponden claramente con los puntos pertenecientes a objetos que se han puesto ah´ı posteriormente a ser tomada la imagen de referencia, y por lo tanto se consideran como intrusiones en el espacio. Cap´ıtulo 7 Simulador de rob´otica industrial La simulaci´on es una parte esencial en el proceso de dise˜no de los sistemas autom´aticos. Hasta ahora, en este proyecto se han abordado los diferentes niveles de implementaci´on de la c´elula de fabricaci´on, y la incorporaci´on de un elemento adicional que proporciona informaci´on de superior nivel como la c´amara RGB-D. Falta ahora tratar el nivel superior de dise˜no de la c´elula de fabricaci´on mediante herramientas de simulaci´on. Este cap´ıtulo est´a dedicado a explicar el trabajo que se ha realizado en cuanto a la b´usqueda, an´alisis y elecci´on de un programa sobre simulaci´on de robots, y la elaboraci´on del material correspondiente para docencia sobre dicho simulador. 7.1. Motivaci´on para la b´usqueda de un simulador La utilidad que tienen los simuladores no s´olo de rob´otica, sino de cualquier materia en general, es de sobra conocida ya que ahorran tiempo y dinero a la hora de probar diferentes alternativas antes de proceder a dise˜nos concretos en actividades de casi cualquier ´ambito. En el caso que a este proyecto ata˜ne, el inter´es por encontrar un simulador actual de rob´otica viene dado por la intenci´on de reemplazar, de cara a la docencia de las nuevas asignaturas de grado, al simulador ((SG-Robot)), que ha sido utilizado durante con gran ´exito durante un largo periodo de tiempo como herramienta docente en asignaturas de rob´otica industrial. Si bien no exist´ıa una urgente necesidad de realizar dicha b´usqueda, s´ı es cierto que se conoc´ıa la existencia en el mercado de potentes simuladores de robots industriales. Adem´as, el simulador SG-Robot empezaba a quedarse algo limitado respecto a los simuladores comerciales, y por lo tanto perd´ıa parte de su valor como herramienta docente. Por todo ello, se decidi´o realizar una b´usqueda de un nuevo simulador que reuniera las caracter´ısticas que hab´ıan hecho del SG-Robot una herramienta docente tan buena, tales como su f´acil manejo, la posibilidad de crear nuevos escenarios, la buena simulaci´on de las singularidades... Y que adem´as, tuviera los par´ametros que caracterizan a los m´as modernos simuladores, tales como un buen entorno gr´afico, capacidad para utilizar diferentes robots, manejo de se˜nales... 61 62 CAP´ ITULO 7. SIMULADOR DE ROB ´ OTICA INDUSTRIAL Posteriormente a esta b´usqueda, ser´ıa momento de valorar los diferentes simuladores y elegir uno si se juzgaba adecuado, tal y como al final se hizo. 7.2. Estudio y comparaci´on de simuladores Tras haber definido los requisitos que se quer´ıan para el simulador llamado a reemplazar al SG-Robot, comenz´o la b´usqueda. Los requisitos mencionados son fundamentalmente los siguientes: Se buscaba un simulador cuyo fundamento fueran los brazos rob´oticos, pero sin dejar de tener en cuenta la posibilidad de simular otros formatos de robots industriales. Una interfaz gr´afica actual, acorde con lo que se espera de un programa moderno. Con buen tratamiento gr´afico, continuidad en la representaci´on de los movimientos, y posibilidad de grabar v´ıdeo. Posibilidad de crear objetos y escenarios de un modo que no fuera en exceso complicado, acorde con el manejo de los modernos programas de dise˜no 3D. Con posibilidad de realizar la programaci´on tanto por guiado como por introducci´on de coordenadas v´ıa c´odigo. En la medida de lo posible, que tuviera buena manejabilidad, y un entorno de programaci´on amigable. Y por ´ultimo, que tuviera disponibilidad gratuita, o al menos a un bajo coste para su uso como elemento docente en la Universidad. Se encontraron m´ultiples simuladores, de los cuales solo los que m´as adelante se detallan son los que reun´ıan en mayor medida las caracter´ısticas deseadas. Por supuesto, se encontraron muchos simuladores que eran en exceso simples, y otros de los cuales no se consigui´o obtener ni una versi´on de prueba. Esto sucedi´o por ejemplo con dos potentes fabricantes de robots como KUKA, que dispone del software ((KUKA sim PRO)), y con FANUC, que dispone de su simulador ((FANUC RoboGuide)). A continuaci´on se incluyen los programas que pasaron las primeras fases de la evaluaci´on. De cada uno se dan algunos datos interesantes. 7.2.1. RoKiSim El simulador ((RoKiSim)) (Robot Kinematics Simulator), es un simulador bastante sencillo de brazos rob´oticos, desarrollado por el Laboratorio de Control y Rob´otica de la ´ Ecole de Technologie Sup´erieure de la Universidad de Montreal [6]. Sus principales caracter´ısticas son las siguientes: Dispone de varios modelos de robots populares (ABB, KUKA, ST¨ AUBLI, etc). Permite introducir geometr´ıas de objetos. 7.2. ESTUDIO Y COMPARACI ´ ON DE SIMULADORES 63 Simula de una forma bastante buena las posiciones dif´ıciles del robot (M´as concretamente las singularidades). Es muy f´acil de manejar, y est´a disponible en varios idiomas. Figura 7.1: Muestra de la pantalla del programa RoKiSim. Se aprecian unos gr´aficos bien conseguidos y una interfaz lista para el uso. A pesar de todas sus virtudes, y de ser totalmente gratuito, se termin´o eligiendo otro por las aportaciones adicionales respecto al simulador SG-Robot, ya que RoKiSim en esencia permite las mismas simulaciones que SG-Robot, pero con una est´etica actualizada. 7.2.2. V-rep El simulador ((V-Rep)) es un simulador desarrollado por la empresa Coppelia Robotics [7]. Se trata de un software, que en el estado en el que se da por parte del desarrollador, est´a m´as destinado al desarrollo e investigaci´on en el sentido de que permite acceder a su c´odigo fuente y modificarlo, que a la simulaci´on propiamente dicha. Es un programa m´as avanzado que lo que se buscaba con software del estilo del simulador SG-Robot. Ya que si bien las posibilidades de simulaci´on que ofrece el programa tal cual se da son menores, su potencial es muy grande a la hora de poder usar cualquier modelo de CAD, adem´as de sus posibilidades en cuanto a poder reprogramarlo y crear nuevas interfaces gr´aficas, desarrollo din´amico, etc. Estas caracter´ısticas lo convierten en un software apropiado a la hora de trabajar en proyectos m´as complejos y avanzados que unas pr´acticas de laboratorio. Sus principales virtudes son las siguientes: Tiene un entorno gr´afico bueno, amigable y con posibilidad de utilizaci´on de ventanas, pesta˜nas, etc. Existentes o creadas. Licencia educativa que incluye la posibilidad de modificaci´on del programa. Permite la utilizaci´on de hasta 6 lenguajes de programaci´on (incluyendo C++ y MatLab). 64 CAP´ ITULO 7. SIMULADOR DE ROB ´ OTICA INDUSTRIAL Figura 7.2: Ejemplo de la pantalla del simulador V-Rep. Se puede apreciar mayor complejidad que en otros simuladores. Permite simular m´as all´a de robots industriales. Se pueden llegar a incluir robots con sensores de visi´on, de posici´on, adem´as de todo objeto cuyo comportamiento se pueda modelar de manera anal´ıtica. No obstante a ser un excelente simulador, tambi´en se descart´o su uso debido fundamentalmente a su complicado uso, que hubiera requerido de cualquier alumno un tiempo excesivo para aprender su manejo. Tambi´en hubiera sido necesario reprogramar partes de su c´odigo fuente para que hubiera servido adecuadamente a los objetivos iniciales. 7.2.3. Easy-Rob El simulador de robots ((Easy Rob)) es otro de los programas que se logr´o obtener para su evaluaci´on. Se trata de un simulador de rob´otica industrial de apariencia amigable, basado en un entorno de ventanas y pesta˜nas. Dispone de m´ultiples botones y men´us en los cuales est´an contenidas todas las funciones existentes en el programa, y que permite utilizarlo de una forma m´as o menos intuitiva. La versi´on demostrativa incluye algunos robots simples y una herramienta de tipo cono. M´as informaci´on en [8]. Sus puntos fuertes son: Entorno gr´afico amigable y sencillo de usar. Facilidad de utilizaci´on y variedad en las vistas 3D y vista libre. Posibilidad de simular colisiones. Descuentos en la adquisici´on de licencias con fines educativos. En este caso, se termin´o por descartar este simulador por un lado porque de forma gratuita solo ofrec´ıa una versi´on de prueba de 15 d´ıas, frente a otros programas que 7.3. ABB ROBOT-STUDIO 65 Figura 7.3: Vista general de la pantalla del simulador Easy-Rob. Se observa un buen tratamiento gr´afico y m´ultiples opciones de acceso r´apido. daban versiones educativas gratuitas. Y por otra parte porque de nuevo la ´unica ventaja clara respecto al simuladorSG-Robot era la actualizaci´on de su apariencia. 7.3. ABB Robot-Studio El programa que finalmente result´o elegido es el simulador ((Robot Studio)) del fabricante de robots industriales ABB Robotics. Se trata de un simulador potente e intuitivo a la hora de utilizarlo, el cual est´a basado en imitar el comportamiento real de los robots industriales, para lo cual simula el control de los mismos mediante un ((Controlador virtual)) que simula todos los detalles de un controlador real de robot. Entre otras cosas, permite la utilizaci´on de varios robots simult´aneamente, as´ı como otros elementos t´ıpicos de las industrias como cintas transportadoras, o cualquier elemento que se desee modelar mediante la parte del programa a ello dedicada. As´ı mismo, permite crear de una manera r´apida y simple diversos objetos inanimados para interactuar con el robot, tales como cajas, cilindros, cubos... Adem´as, tambi´en incluye la simulaci´on de se˜nales de entrada y de salida, as´ı como la interacci´on entre los controladores de varios robots, al estilo de lo que ser´ıa una planta industrial real. Por ´ultimo, existe gran cantidad de material en internet acerca de este simulador, desde tutoriales hasta v´ıdeos de demostraci´on. El simulador Robot-Studio fue finalmente el elegido por varias razones, pero en t´erminos generales se pueden destacar dos: A pesar de no ser el m´as destacado en manejabilidad, ni en posibles prestaciones, es el 66 CAP´ ITULO 7. SIMULADOR DE ROB ´ OTICA INDUSTRIAL Figura 7.4: Vista de la pantalla principal del simulador Robot-Studio. Se aprecian diferentes pesta˜nas, y se intuye el amplio rango de opciones que tiene. que mejor a´una todas las caracter´ısticas deseadas de los simuladores probados. Adem´as, es un simulador muy utilizado comercialmente, que se puede incluso usar para programar los robots del fabricante ABB. Como ´ultimo punto a destacar de este simulador, se han obtenido 100 licencias educativas para uso en la Universidad de Zaragoza. 7.3.1. Aprendizaje y preparaci´on de material El aprendizaje sobre el programa Robot-Studio se ha basado fundamentalmente en tres pilares: El manual del programa [2], diversos tutoriales y v´ıdeos demostrativos existentes en internet, y el aprendizaje autodidacta en base a su utilizaci´on. Con estas tres fuentes de conocimiento es con las que se han desarrollado tanto los manuales y tutoriales (Ver secci´on 7.4), como todas las simulaciones y pruebas intermedias hasta llegar a los resultados finales. Como parte del trabajo preparatorio antes de poder obtener el plausible material docente, fue necesario realizar multitud de pruebas incluyendo: Diversos escenarios, utilizaci´on de hasta cinco robots al mismo tiempo, creaci´on de objetos, ensayo de herramientas... Tras realizar esas pruebas, la conclusi´on a la que se lleg´o fue la de crear dos tipos de escenarios diferentes. Por un lado escenarios orientados a montar diversos elementos que constituyen una pieza, incluyendo soldaduras, y colocaci´on de pegamento. En general las tareas mencionadas son tareas que puede hacer un ´unico robot de manera independiente, o integrado en una c´elula de producci´on con un ´unico robot de manufactura. El otro tipo de escenario est´a orientado m´as hacia el transporte de piezas, incluyendo acciones tales como paletizado, limpieza de objetos y transporte de un lugar a otro. En este caso son necesarios varios robots, y coordinarlos entre s´ı. ´ Indice de figuras 1.1. Gr´afico resumen del proyecto. . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1. Tipos de piezas que se producen en la c´elula industrial. . . . . . . . . . . . 7 2.2. Vista general de la c´elula completa. Se aprecian diferentes estaciones de trabajo, cintas transportadoras, y al fondo el robot industrial . . . . . . . . 8 2.3. Subc´elula de preparaci´on y transporte de pedidos . . . . . . . . . . . . . . 9 2.4. Estaci´on expendedora de palets para colocar las piezas. . . . . . . . . . . . 9 2.5. Zona de trabajo del robot. Est´a delimitada por las cintas transportadoras y tres vallas de protecci´on. . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.6. Aut´omata M340 e isla Advantys pertenecientes a la estaci´on 6. . . . . . . . 12 2.7. M´odulo TSX Momentum, perteneciente a una estaci´on de transporte . . . 12 3.1. Armario del controlador RJ-3 del robot FANUC, con el terminal de ense˜nanza en primer plano. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.2. Terminal de ense˜nanza del robot FANUC. Se aprecia el pulsador de emergencia. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.3. Vista del programa de comunicaci´on por puerto serie ((Hyper-terminal)). . . 18 3.4. Vista del programa ((Kfloppy)), que emula una disquetera virtual. . . . . . . 18 3.5. Piezas apiladas en tres montones distintos como resultado del programa ((Paletizado)). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 3.6. Momento en el que el robot descarta una pieza durante el programa ((Desechar)). 24 3.7. Colocaci´on de una de las piezas del tren durante la ejecuci´on del programa ((Montar tren)). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 4.1. Isla Advantys STB que se instal´o inicialmente. . . . . . . . . . . . . . . . . 28 4.2. Isla Advantys STB que se encuentra actualmente instalada. . . . . . . . . . 28 4.3. Ejemplo de programa SFC. Se aprecian varias acciones secuenciales, y dos en paralelo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 4.4. Ejemplo de programa LD. Se aprecian diversas condiciones a la izquierda, y algunas acciones a la derecha. . . . . . . . . . . . . . . . . . . . . . . . . 29 4.5. Aut´omata principal, situado junto al robot industrial. . . . . . . . . . . . . 30 4.6. Aut´omata secundario presente en la estaci´on de expedici´on de palets. . . . 30 4.7. Ejemplo de SFC, correspondiente a la selecci´on de programa del robot. Se aprecia una selecci´on y diversas acciones secuenciales. . . . . . . . . . . . . 32 4.8. SFC correspondiente a la gesti´on de la seguridad del robot. . . . . . . . . . 32 4.9. SFC correspondiente al control de los transportes (Cintas, topes, desv´ıos...). 33 ix x´ INDICE DE FIGURAS 4.10. SFC correspondiente al control de la sub-c´elula completa (controlada totalmente por el aut´omata principal). . . . . . . . . . . . . . . . . . . . . . 34 4.11. Botonera f´ısica de la estaci´on de transporte. Se aprecian los diferentes pulsadores y selectores a los que se hace referencia. . . . . . . . . . . . . . . . 34 4.12. Diagrama SFC correspondiente al control de la estaci´on de expedici´on de palets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 4.13. Estructura jer´arquica del conjunto integrado. . . . . . . . . . . . . . . . . . 37 4.14. Vista de un m´odulo NOE 0100 como el existente en el laboratorio. . . . . . 38 5.1. Ejemplo de terminal de di´alogo en una industria. . . . . . . . . . . . . . . 41 5.2. Diagrama explicativo del acceso a memoria. La posibilidad de acceder a la memoria est´a condicionada seg´un el selector MAN/AUT. . . . . . . . . . . 43 5.3. Pantalla del terminal dise˜nado para controlar el conjunto. . . . . . . . . . . 43 5.4. Pantalla del terminal dise˜nado para la estaci´on expendedora de palets. . . 43 5.5. Terminal de la estaci´on de expedici´on de palets en estado habilitado . . . . 44 5.6. Terminal de la misma estaci´on en estado deshabilitado. Desaparece la botonera dado que no se permite su uso. . . . . . . . . . . . . . . . . . . . . . 44 6.1. C´amara RGB-D modelo ((Asus Xtion Pro Live)) utilizada durante este proyecto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 6.2. Imagen RGB capturada por la c´amara. . . . . . . . . . . . . . . . . . . . . 48 6.3. Imagen resultado de la combinaci´on del color y la profundidad. Se aprecian puntos con color y posici´on. . . . . . . . . . . . . . . . . . . . . . . . . . . 48 6.4. Esquema explicativo del almacenamiento de informaci´on en formato ((Nube de Puntos)). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 6.5. Imagen introducida al algoritmo . . . . . . . . . . . . . . . . . . . . . . . . 51 6.6. Resultado obtenido del algoritmo. . . . . . . . . . . . . . . . . . . . . . . . 51 6.7. Proceso seguido para reorientar una nube de puntos. . . . . . . . . . . . . 53 6.8. Ilustraci´on de c´omo se eliminan los planos. Se puede observar c´omo se van eliminando secuencialmente de mayor a menor. . . . . . . . . . . . . . . . . 54 6.9. Imagen original, e identificaci´on realizada por el algoritmo. Se aprecian objetos identificados, y huecos en aquellos que no se han reconocido. . . . . 57 6.10. Imagen original, y discretizaci´on del color realizada por el algoritmo. Se aprecia la adecuada conversi´on a colores m´as puros sin perder apenas informaci´on. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 6.11. Ejemplo del archivo de salida con los objetos que el algoritmo ha logrado identificar. Se incluyen el tipo de objeto, su posici´on, tama˜no, y colores principales. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 6.12. Ejemplo de la salida por pantalla del algoritmo de control del espacio de trabajo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 7.1. Muestra de la pantalla del programa RoKiSim. Se aprecian unos gr´aficos bien conseguidos y una interfaz lista para el uso. . . . . . . . . . . . . . . . 63 7.2. Ejemplo de la pantalla del simulador V-Rep. Se puede apreciar mayor complejidad que en otros simuladores. . . . . . . . . . . . . . . . . . . . . . . . 64 7.3. Vista general de la pantalla del simulador Easy-Rob. Se observa un buen tratamiento gr´afico y m´ultiples opciones de acceso r´apido. . . . . . . . . . 65 ´ INDICE DE FIGURAS xi 7.4. Vista de la pantalla principal del simulador Robot-Studio. Se aprecian diferentes pesta˜nas, y se intuye el amplio rango de opciones que tiene. . . . . 66 ´ Indice de tablas 2.1. Principales caracter´ısticas del robot . . . . . . . . . . . . . . . . . . . . . . 10 4.1. Resumen de los modos de funcionamiento de la sub-c´elula. . . . . . . . . . 36 6.1. Caracter´ısticas del dispositivo RGB-D. . . . . . . . . . . . . . . . . . . . . 49 xiii Bibliograf´ıa [1] ABB-Robotics. Abb robot-studio (http://new.abb.com/products/robotics/robotstudio). [2] ABB-Robotics.Manual del operador. Robot Studio 5.15., 2013. [3] ASUSTeK-Computer-Inc. Asus xtion pro live. (http://www.asus.com/multimedia/xtion pro live/), url = http://www.asus.com/multimedia/Xtion pro live/,. [4] Barrientos, A., Pe˜ nin, L. F., Balaguer, C., and Aracil, R. Fundamentos de rob´otica. Mc-Graw-Hill, Ed. [5] Beltr´ an, R., and Romeo, A. Programa tareak, 2003. [6] ´ Ecole Technologie-Sup´ erieure-Universit´ e-Montreal. Informaci´on y descarga del programa rokisim (http://www.parallemic.org/rokisim.html). [7] Coppelia-Robotics. Informaci´on y descarga del programa v-rep (http://www.coppeliarobotics.com/). [8] Easy-Rob-Inc. Informaci´on y descarga del programa easy rob (http://www.easyrob.com/easy-rob/). [9] FANUC-Robotics.R–J3iB Mate Controller LR Handling Tool Operator’s Manual. [10] FANUC-Robotics.SYSTEM RJ-3 Controller KAREL Reference Manual. [11] FANUC-Robotics.R-J3 Controller CE Maintenance, 2000. [12] FANUC-Robotics.Curso de programaci´on TPE, 2003. [13] Fischler, M. A., and Bolles, R. C. Random sample consensus: A paradigm for model fitting with apphcatlons to image analysis and automated cartography. In Magazine Communications of the ACM (1981). [14] OpenNI-organization. Openni libraries (http://www.openni.org/), url=http://www.openni.org/,. [15] robots.com. http://www.robots.com/fanuc/arcmate-50il. [16] Rusu, R. B., and Cousins, S. 3D is here: Point Cloud Library (PCL). In IEEE International Conference on Robotics and Automation (ICRA) (Shanghai, China, May 9-13 2011). xv xvi BIBLIOGRAF´ IA [17] Rusu, R. B., O’Leary, G., and Rublee, E. Point cloud library documentation (www.pointclouds.org). [18] Schneider-Electric. Informaci´on sobre el aut´omata modicon m340 (http://www.schneider-electric.com/products/co/ls/3900-pac-plc-y-otroscontroladores/3950-pacs/1468-modicon-m340/). [19] Schneider-Electric. Informaci´on sobre el aut´omata tsx premium (http://www.schneider-electric.com/products/ww/en/3900-pac-plc-othercontrollers/3950-pacs/537-modicon-premium/). [20] Schneider-Electric. Informaci´on sobre el m´odulo de entradas y salidas distribuidas ((advantys stb)) (http://www.schneider-electric.com/products/mx/ls/3900pac-plc-y-otros-controladores/3930-i-o-distribuida/606-advantys-stb/). [21] Schneider-Electric. Magelis xbtgt4330 (http://www.schneiderelectric.com/site/home/index.cfm/es/). [22] Schneider-Electric.Advantys STB, m´odulo de interfaz de red CANopen b´asico. Manual de aplicaciones, 2009. [23] Schneider-Electric.Advantys STB, m´odulos de E/S digitales. Manual de referencia, 2009. [24] Schneider-Electric.Modicon M340 para Ethernet. Procesadores y m´odulos de comunicaciones. Manual de usuario, 2009. [25] Schneider-Electric.Unity Pro. Lenguajes y estructura del programa. Manual de referencia, 2009. [26] Tuerker, S. Euclidean cluster extraction (www.pointclouds.org/). [27] Universidad-Zaragoza. Sistemas industriales de control. pr´actica 4. utilizaci´on de una red industrial de comunicaciones. programaci´on de una interfaz humanom´aquina., 2013.