Coordinación y control de robots móviles basado en agentes

Coordinación y control de robots móviles basado en agentes. PROYECTO FINAL DE CARRERA AUTOR: ADRIÁN CERVERA ANDÉS DIRECTORES: DR. ÁNGEL VALERA FERNÁNDEZ DRA. MARINA VALLÉS MIQUEL Valencia, julio de 2011 2 3 A los que quiero: a mi familia y amigos. A mis padres y hermana, por su constante apoyo. A mis abuelos, especialmente a mi abuelo Toni, por enseñarme tanto. A mis directores, por su ayuda y colaboración. “Hay una fuerza motriz más poderosa que el vapor, la electricidad y la energía atómica: la voluntad” Albert Einstein 4 Índice: 1.- INTRODUCCIÓN_____________________________________________________9 1.1. Introducción………………………………………………………………………..…………….……………9 1.2. Objetivos…………………………………………………………………………….…………………………10 2.- DESARROLLO TEÓRICO I: ROBÓTICA____________________________________12 2.1. Introducción a la robótica……………………………………………………………………………. 12 2.2. Historia de la robótica antigua……………………………………………………………………… 12 2.3. Tipos de robots………………………………………………………………….………………………… 19 2.3.1. Robots Industriales………………………………………………….………………………….19 2.3.1.1. Robots industriales de primera generación……………………………..19 2.3.1.2. Robots industriales de segunda generación.…………………………...20 2.3.1.3. Robots industriales de tercera generación…….…………………………21 2.3.1.4. Robots industriales de cuarta generación……..…………………………21 2.3.1.5. Robots industriales de quinta generación……..…………………………22 2.3.2. Robots móviles……………………………………………………………………………………23 2.3.2.1. Robots rodantes………………………………………………………………………23 2.3.2.2. Robots andantes………………………………………………………………………25 2.3.2.3. Robots reptadores……………………………………………………………………26 2.3.2.4. Robots nadadores……………………………………………………………………27 2.3.2.5. Robots voladores…………..…………………………………………………………27 2.4. Sistemas de control…………………………….…………………………………………………………28 2.4.1. Sistemas en bucle abierto……………………………………………………………………28 2.4.2. Sistemas en bucle cerrado…………………………………………………………………..29 2.5. Comunicaciones inalámbricas…………….…………………………………………………………29 2.5.1. Wi-Fi……………………………………………………………………………………………………30 2.5.2. Bluetooth………………………………….…………………………………………………………31 5 2.5.2.1. Wibree…………………………………………………………………………………….32 2.5.3. Zigbee………………………………………………………………………………………………….32 2.6. LEGO NXT………………………………………………………………………………………………………35 2.6.1. Introducción………………………………………………………………………………………..35 2.6.2. Ladrillo NXT…………………………………………………………………………………………35 2.6.2.1. Microcontrolador…………………………………………………………………….36 2.6.2.2. Entradas y salidas…………….………………………………………………………36 2.6.2.3. Comunicaciones……………….………………………………………………………37 2.6.3. Motores………………………………………………………………………………………………37 2.6.4. Sensores………………………………………………………………………………………………38 2.6.4.1. Sensores originales de LEGO……………………………….……………………38 2.6.4.2. Sensores de terceros…………………………………………………………..……40 2.6.5. Programación………………………………………………………………………………………41 3.- DESARROLLO TEÓRICO II: TECNOLOGÍA AGENTE__________________________44 3.1. Historia………………………………………………….………………………………………………………44 3.2. ¿Qué es una agente software? ……………….…………………………………………………….44 3.3. Tipos de agentes………………………………….………………………………………………………..47 3.4. ¿Por qué agentes? ……………………………….……………………………………………………....49 3.5. Comunicación entre agentes…………………………………………………………………………50 3.5.1. Introducción…………………………………………………………………………………..……50 3.5.2. Organizaciones de estandarización.………………………………………………….…51 3.5.2.1. OMG……………………………………………………………………………………..…51 3.5.2.2. KSE……………………………………………………………………………………..……52 3.5.2.3. FIPA………………………………………………………………………………….………52 3.6. FIPA (Foundation for Intelligent Physical Agents) …………………………………….……53 3.6.1. Modelo de referencia de FIPA………………………………………………………..……53 6 3.6.2. Comunicación FIPA – FIPA ACL………………………………………………………….…55 3.7. JADE (Java Agent DEvelopment Framework) ………………………………………………..57 3.7.1. La plataforma de agentes JADE………………….……………………………………..…57 3.7.2. Comportamientos…………………………………….…………………………………………58 3.7.2.1. Planificación y ejecución de comportamientos…………………………58 3.7.2.2. Tipos de comportamientos………………………………………………………60 3.7.3. Directorio y servicios……………………………………………………………………………61 3.7.3.1. Publicación de servicios……………………………………………………………62 3.7.3.2. Busqueda de servicios………………………………………………………..……63 3.7.4. Comunicacion entre agentes…………………………………….…………………………64 3.7.4.1. Envio de mensajes……………………………………………………………………64 3.7.4.2. Recepción de mensajes……………………………………………………………65 4.- DESARROLLO PRÁCTICO______________________________________________66 4.1. Configuración inicial………………………………………………………………………………………66 4.1.1. Instalación del JAVA JDK………………………………………………………………………66 4.1.2. Instalación del driver USB de Lego………………………………………………….……66 4.1.3. Instalación de Lego NXJ………………………………………………………………….……66 4.1.4. Instalación y configuración de la plataforma JADE….………………………..…67 4.1.5. Configuración del entorno de desarrollo (ECLIPSE) ………………………….…69 4.1.5.1. Compilación y ejecución para NXJ……………………………………………69 4.1.5.2. Compilación y ejecución de agentes JADE…….……………………….…72 4.2. Herramientas de administración y depuración………………………………………………75 4.2.1. Lanzamiento de agentes usando la interfaz……………..…………………….……75 4.2.2. Envío de mensajes ACL…………………………………………….…………………….……76 4.2.3. Dummy Agent………………………………………………………….…………………….……78 4.2.4. DF (Directory Facilator) GUI……………………………………….………………..………79 7 4.2.5. Sniffer Agent…………………………………………………………………………………….…81 4.2.6. Instrospector Agent…………………………………………………….………………………82 4.3. Distribución de la aplicación en varios PCs……………………………..…………….…….…83 4.4. Java Threads: Concurrencia en JAVA…………………………………………………….…….…85 4.5. Aplicación I: Robots limpiadores…………………………………………….…………….…….…86 4.5.1. Introducción……………………………………………………………………………….….……86 4.5.2. Descripción del escenario……………………………………………………………………86 4.5.3. Captura y procesamiento de imágenes……………………….………………………87 4.5.4. Programación de los algoritmos………………………………….………………………90 4.5.4.1. AgenteCámara…….……………………..……………………………………………90 4.5.4.2. AgenteLimpiador………………………..……………………………………………92 4.5.4.3. Código robots………………………………………………….…………….…………93 4.6. Aplicación II: Generación de convoyes………………………………….…………………….…93 4.6.1. Introducción……………………………………………………………….…………………….…93 4.6.2. Descripción del escenario……………………………………………………………………93 4.6.2.1. Configuración del robot líder del convoy……………….…………………94 4.6.2.2. Configuración del robot seguidor………….…………………………………95 4.6.3. Programación del algoritmo……………………………………………..…………………96 4.6.3.1. AgenteLider………………………………………………………………..……………96 4.6.3.2. AgenteSeguidor………………………………………………………….……………97 4.6.3.3. AgenteSolicitador……………………………………………….……………………97 4.6.3.4. Programación de los robots………………………………….……….…………98 4.6.3.5. Programación de la cámara NXTCam……………………………….………99 4.6.3.6. Algoritmos de evasión de obstáculos…………………….…………….…101 4.6.3.7. División de convoyes………………………………………………………..……103 4.6.3.8. Abandono del convoy por batería agotada……………..……..………105 8 4.7. Problemas encontrados y soluciones……………………………………….…………….……106 4.7.1. Problemas por luz ambiental………………………………………….…………………106 4.7.2. Conexión Bluetooth y Threads………………………………………..…………………107 5.- CONCLUSIONES____________________________________________________109 6.- BIBLIOGRAFÍA_____________________________________________________110 Anexo A. Programación de agentes con comportamientos……………………………………111 Anexo B. Programación y utilización del sensor NXTCam………………………………………116 9 1.- INTRODUCCIÓN 1.1. Introducción y justificación Vivimos en una sociedad en la que las necesidades de comunicación se han incrementado de forma exponencial, hasta el extremo que necesitamos estar constantemente conectados entre nosotros. La utilización y proliferación de internet ha sido, sin duda, una de las causantes de este fenómeno. En concreto, en Europa, más del 50% de las personas disponen de una conexión con la que acceder a los contenidos de la red de redes. Esto, junto con la aparición de dispositivos que utilizan métodos de acceso inalámbrico (como portátiles, móviles, PDAs, tabletas y netbooks) hacen que cada día sean más las personas que deciden utilizar estas tecnologías. Este crecimiento en su utilización ha dado lugar a un incesante trabajo por encontrar tecnologías de información cada vez más potentes y con mayores prestaciones, desarrollando protocolos de comunicaciones inalámbricas como Wi-Fi, Bluetooth y WiMax. Al mismo tiempo, las tecnologías electrónicas y mecánicas también han evolucionado, incrementando la capacidad de cómputo a precios muy asequibles. La unión de estas ciencias ha dado lugar a disciplinas como la mecatrónica, sinergia que une la ingeniería mecánica, la ingeniería electrónica y la ingeniería informática, y que tiene como objetivo utilizar un computador en la automatización y control de dispositivos mecánicos y electrónicos. La mecatrónica nos rodea en nuestro día a día, en casa (lavadora, televisión, microondas), en el trabajo (aire acondicionado, calefacción, fotocopiadora), mientras conducimos, etc. Nos permite incluso controlar nuestra casa de forma automática y remota (domótica) o solucionar problemas físicos en los seres humanos (biónica). El uso masivo de Internet ha propiciado también la aparición de aplicaciones basadas en agentes, desarrolladas sobre distintas plataformas. La interoperabilidad entre distintas plataformas de agentes es una característica crítica para el desarrollo de aplicaciones heterogéneas. Para conseguir esta interoperabilidad es muy importante el uso de las especificaciones propuestas por FIPA, organización encargada de la producción de estándares en el área de los agentes. Actualmente, el concepto de robótica ha evolucionado hacia los sistemas móviles autónomos, que son aquellos que son capaces de desenvolverse por sí mismos en entornos desconocidos y parcialmente cambiantes sin necesidad de supervisión. Uno de los grandes retos de la robótica se basa en la colaboración y autodeterminación de sus movimientos, buscando que los robots puedan trabajar de una forma lo más autónoma e independiente del ser humano posible. Para ello, deberán hacer uso de 16 Figura 5: Pato de Vaucanson La construcción de miembros artificiales se remonta a Ambroise Paré (1510-1590) que desarrolló modelos de sorprendente complejidad. En 1769, el ingeniero húngaro Johann Wolfgang Ritter von Kempelen (1734-1804), construye uno de los autómatas más famosos de la historia: una máquina para jugar al ajedrez. Se trataba de un dispositivo puramente mecánico. Por su aspecto la máquina era conocida como “el turco”. Sobre la mesa había un tablero de ajedrez, y en el interior unos finos engranajes y resortes que imprimían movimiento a sus manos, que iban cambiando las fichas de posición a medida que transcurría la partida. El maniquí ganaba las partidas más complicadas y se hizo famoso en toda Europacuando derrotó por tres veces a Napoleón Bonaparte. Nadie consiguió descubrir el secreto de esta máquina y, por supuesto, todos ignoraron que se habían enfrentado en realidad al campeón de ajedrez Johann Allgaier, oculto dentro del cajón. 17 Figura 6: Máquina para jugar al ajedrez conocida como “El Turco” En esta época los autómatas tenían sobre todo una intención lúdica y eran exhibidos en ferias y circos. Sólo después de unos años, a partir de la revolución industrial, empezaron a ser usados para funciones productivas. En 1898 Nicola Tesla (1856-1943), inventor del motor eléctrico de corriente alterna, presenta el que algunos consideran el primer robot de la historia moderna, un barco teledirigido, a partir del que patentó el Teleautomation, un torpedo teledirigido para uso militar. Figura 7: Barco teledirigido de Nicola Tesla 18 Sin embargo, no fue hasta 1921 cuando se escuchó por primera vez la palabra robot, utilizada por el escritor checo Karel Capek en su obra de teatro R.U.R (Rossum´s Universal Robots). La palabra robot viene del vocablo checo ‘Robota’ que significa “trabajo”, entendido como servidumbre, trabajo forzado o esclavitud. Más tarde, Isaac Asimov (1920-1992) postuló las tres leyes de la robótica en su libro I Robot (Yo robot) publicado en 1950, coincidiendo con el apogeo de la robótica moderna. Los primeros robots industriales empezaron a producirse a principios de los años 60 y estaban diseñados principalmente para realizar trabajos mecánicos difíciles y peligrosos. Las áreas donde estos robots tuvieron su aplicación fueron trabajos laboriosos y repetitivos, como la carga y descarga de hornos de fundición. En 1961 el inventor norteamericano George Devol patentaba el primer robot programable de la historia, conocido como Unimate, estableciendo las bases de la robótica industrial moderna. Figura 8: Unimate Este robot industrial era un manipulador que formaba parte de una célula de trabajo en la empresa de automóviles Ford Motors Company, diseñado para levantar y apilar grandes piezas de metal caliente, de hasta 225 kg, de una troqueladora de fundición por inyección. Debido a los continuos avances en la informática y la electrónica, a partir de 1970 fueron desarrollados diversos robots programables, siendo de gran importancia en la industria mecánica, tanto en las líneas de ensamblaje como en aplicaciones como la soldadura o pintura. En los últimos años, los robots han tomado posición en todas las áreas productivas industriales. La incorporación del robot al proceso productivo ha representado uno de 19 los avances más espectaculares de la edad moderna. En poco más de cuarenta años, se ha pasado de aquellos primeros modelos, rudos y limitados, a sofisticadas máquinas capaces de sustituir al hombre en todo tipo de tareas repetitivas o peligrosas, y además, hacerlo de forma más rápida, precisa y económica que el ser humano. Hoy en día, se calcula que el número de robots industriales instalados en el mundo es de un millón de unidades, unos 20.000 en España, siendo Japón el país más tecnológicamente avanzado, con una media de 322 robots por cada 10.000 trabajadores. 2.3. Tipos de robots Aquí lo que se pretende es describir las posibles categorías en las que se pueden clasificar los robots actuales. Aunque se pueden realizar distintas clasificaciones (por grado de autonomía, por tipo de propósito, por función, por medio, por tamaño y peso, anatomía e inteligencia), aquí vamos a describir los principales tipos de robots que se utilizan en la actualidad. 2.3.1. Robots Industriales Se entiende por Robot Industrial a un dispositivo de maniobra destinado a ser utilizado en la industria y dotado de uno o varios brazos, fácilmente programable para cumplir operaciones diversas con varios grados de libertad y destinado a sustituir la actividad física del hombre en las tareas repetitivas, monótonas, desagradables o peligrosas. Por su parte, la Organización Internacional de Estándares (ISO) que define al robot industrial como un manipulador multifuncional reprogramable con varios grados de libertad, capaz de manipular materias, piezas, herramientas o dispositivos especiales según trayectorias variables programadas para realizar tareas diversas. Una clasificación del grado de complejidad del Robot puede establecerse de la siguiente forma: 2.3.1.1. Robots de primera generación Dispositivos que actúan como "esclavo" mecánico de un hombre, quien provee mediante su intervención directa el control de los órganos de movimiento. Esta transmisión tiene lugar mediante servomecanismos actuados por las extremidades superiores del hombre, caso típico manipulación de materiales radiactivos, obtención de muestras submarinas, etc. 20 El sistema de control usado en la primera generación de robots esta basado en la “paradas fijas” mecánicamente. Esta estrategia es conocida como control de lazo abierto o control “bang bang”. Figura 9: Robot de primera generación 2.3.1.2. Robots de segunda generación El dispositivo actúa automáticamente sin intervención humana frente a posiciones fijas en las que el trabajo ha sido preparado y ubicado de modo adecuado ejecutando movimientos repetitivos en el tiempo, que obedecen a lógicas combinatorias, secuenciales, programadores paso a paso, neumáticos o Controladores Lógicos Programables. Utiliza una estructura de control de ciclo abierto, pero en lugar de utilizar interruptores y botones mecánicos utiliza una secuencia numérica de control de movimientos almacenados en un disco o cinta magnética. El mayor número de aplicaciones en los que se utilizan los robots de esta generación son de la industria automotriz, en soldadura, pintado, etc. 21 Figura 10: Robot de segunda generación de ABB 2.3.1.3. Robots de tercera generación La tercera generación de robots utiliza las computadoras para su estrategia de control y tiene algún conocimiento del ambiente local a través del uso de sensores, los cuales miden el ambiente y modifican su estrategia de control, con esta generación se inicia la era de los robots inteligentes y aparecen los lenguajes de programación para escribir los programas de control. La estrategia de control utilizada se denomina de “ciclo cerrado”. Figura 11: Robot de tercera generación 2.3.1.4. Robots de cuarta generación La cuarta generación de robots, ya los califica de inteligentes con más y mejores extensiones sensoriales, para comprender sus acciones y el mundo que los rodea. 22 Incorpora un concepto de “modelo del mundo” de su propia conducta y del ambiente en el que operan. Utilizan conocimiento difuso y procesamiento dirigido por expectativas que mejoran el desempeño del sistema de manera que la tarea de los sensores se extiende a la supervisión del ambiente global, registrando los efectos de sus acciones en un modelo del mundo y auxiliar en la determinación de tareas y metas. Figura 12: Robot de cuarta generación de ABB 2.3.1.5. Robots de quinta generación La quinta generación, actualmente está en desarrollo esta nueva generación de robots, que pretende que el control emerja de la adecuada organización y distribución de módulos conductuales, esta nueva arquitectura es denominada arquitectura de subsunción, cuyo promotor es Rodney Brooks, donde la toma de decisiones del agente (función acción) se realiza mediante un conjunto de módulos de comportamiento que realizan tareas. Un modulo de comportamiento suele implementarse como un autómata finito sin ningún tipo de representación o razonamiento simbólico. Casi siempre el comportamiento se implementa como reglas del tipo: Si (situación) entonces (acción), donde situación se toma directamente de la percepción, sin ningún tipo de transformación a representación simbólica. La selección del comportamiento se basa en la jerarquía de subsunción. Los comportamientos están ordenados por capas y los de las capas mas bajas (máxima prioridad) inhiben a los de las capas superiores (comportamiento más abstracto). Este proyecto final de carrera estaría clasificado en esta generación de robots, ya que sigue 23 la investigación de la toma de decisiones por parte de uno o varios agentes, el cual se encarga de la activación de los comportamientos necesarios. Figura 13: Esquema de funcionamiento de robot de quinta generación 2.3.2. Robótica Móvil En el apartado anterior se ha realizado un desglose de los diferentes tipos de robots existentes atendiendo a su aplicación, pero más allá de este aspecto práctico hay otro hecho característico de los robots modernos que les confiere un mayor grado de libertad y utilidad. Esta característica es el movimiento en el espacio físico, es decir, la posibilidad de desplazarse por el entorno para observarlo e interactuar con él, y de esta forma emular con mayor fidelidad las funciones y capacidades de los seres vivos. 2.3.2.1. Robots rodantes Son aquellos que, como su nombre indica, se desplazan haciendo uso de ruedas. Podemos encontrar varias configuraciones para la posición y el número de ruedas. La primera de ellas sería la configuración de Ackerman, la cual se usa casi exclusivamente en la industria del automóvil. Es la configuración que llevan los coches: dos ruedas con tracción traseras, y dos ruedas de dirección delanteras. Esta configuración está diseñada para que la rueda delantera interior en un giro tenga un ángulo ligeramente más agudo que la exterior, y evitar así el derrape de las ruedas. 24 Figura 14: Robot con configuración de Ackerman También es frecuente encontrar distribuciones de ruedas montadas en configuración diferencial (triciclo) se presenta como la más sencilla de todas. Consta de dos ruedas situadas diametralmente opuestas en un eje perpendicular a la dirección del robot más una rueda loca. Estas ruedas no llevan asociadas ningún motor, giran libremente según la velocidad del robot. Además, pueden orientarse según la dirección del movimiento, de forma análoga a como lo hacen las ruedas traseras de los carritos del supermercado Figura 15: Robot en configuración triciclo Existen algunos casos especiales en los que se usan otras configuraciones que dotan al robot de mejor adaptación a terrenos difíciles. En estos casos los algoritmos de control de movimiento adquieren una mayor complejidad, proporcional al número de elementos direccionales de forma independiente. 25 Figura 16: Robot Koala El último grupo de robots que aquí convendría nombrar es el de los robots que se desplazan mediante la utilización de cadenas. Para la realización de los giros es necesario que ambas cadenas giren en sentidos opuestos dependiendo de cual sea el sentido de giro final del robot, de modo parecido al que se utiliza en la configuración diferencial. Figura 17: Robot rodante Meccano Spykee 2.3.2.2. Robots andantes Los robots andantes son aquellos que basan su movilidad en la simulación de los movimientos realizados por los seres humanos al andar. Estos robots están provistos de dos patas con varios grados de libertad, a través de las cuales son capaces de 32 por radiofrecuencia de forma inalámbrica. Estos dispositivos se clasifican como "Clase 1", "Clase 2" o "Clase 3" en referencia a su potencia de transmisión, siendo totalmente compatibles los dispositivos de una clase con los de las otras. En cuanto al ancho de banda que nos proporciona una conexión Bluetooth, la versión 1.2 de la especificación consigue transmisión de datos a 1Mbps, la versión 2.0 alcanza los 3Mbps, mientras que la última versión 3.0 ofrece hasta 24Mbps, buscando la compatibilidad con Wi-Fi. Figura 25: Logotipo Bluetooth 2.5.2.1. Wibree A partir de la especificación Bluetooth apareció el 12 de junio de 2007 la especificación Wibree. Fue anunciada como una parte de la especificación de Bluetooth encaminada a ser una versión de muy bajo consumo. Sus aplicaciones son principalmente dispositivos sensores o mandos a distancia. Puede resultar interesante para equipamiento médico. Wibree es una nueva tecnología digital de radio interoperable para pequeños dispositivos. Es la primera tecnología abierta de comunicación inalámbrica, que ofrece comunicación entre dispositivos móviles o computadores y otros dispositivos más pequeños (de pila de botón), diseñada para que funcione con poca energía. Figura 26: Logotipo WiBree 2.5.3. Zigbee 33 ZigBee es el nombre de la especificación de un conjunto de protocolos de alto nivel de comunicación inalámbrica para su utilización con radiodifusión digital de bajo consumo, basada en el estándar IEEE 802.15.4 de redes inalámbricas de área personal (wireless personal area network, WPAN). Su objetivo son las aplicaciones que requieren comunicaciones seguras con baja tasa de envío de datos y maximización de la vida útil de sus baterías. En principio, el ámbito donde se prevé que esta tecnología cobre más fuerza es en domótica, como puede verse en los documentos de la ZigBee Alliance. La razón de ello son diversas características que lo diferencian de otras tecnologías: Su bajo consumo. Su topología de red en malla. Su fácil integración (se pueden fabricar nodos con muy poca electrónica). Uno de los objetivos de la especificación de ZigBee es ser más simple y barato que otras tecnologías encaminadas a WPANs como puede ser Bluetooth. Si principal campo de integración son aplicaciones que necesitan un reducido tráfico de datos, un bajo consumo de sus baterías y unas conexiones lo más seguras posibles. Estas características hacen que sea ampliamente utilizado en las siguientes aplicaciones: 1. Automoción 2. Aplicaciones industriales 3. Aviónica 4. Entornos inteligentes 5. Domótica y seguridad 6. Monitorización del medio ambiente 7. Identificación de productos 8. Etc. Este estándar define dos capas físicas: a 868/915 MHz DSSS PHY (espectro con propagación de secuencia directa) y otra a 2450 MHz DSSS PHY. La capa de 2450 MHz soporta un rango de datos de 250 Kb/s y la de 868/915 un rango de datos entre los 20 Kb/s y 40 Kb/s. La elección de cada una de las capas depende de las regulaciones locales y de las preferencias del usuario. Las principales diferencias respecto a Bluetooth son las siguientes: 34 Una red ZigBee puede constar de un máximo de 65535 nodos distribuidos en subredes de 255 nodos, frente a los 8 máximos de una subred (Piconet) Bluetooth. Menor consumo eléctrico que el de Bluetooth. En términos exactos, ZigBee tiene un consumo de 30 mA transmitiendo y de 3 uA en reposo, frente a los 40 mA transmitiendo y 0,2 mA en reposo que tiene el Bluetooth. Este menor consumo se debe a que el sistema ZigBee se queda la mayor parte del tiempo dormido, mientras que en una comunicación Bluetooth esto no se puede dar, y siempre se está transmitiendo y/o recibiendo. Tiene una velocidad de hasta 250 Kbps, mientras que en Bluetooth es de hasta 3 Mbps. Debido a las velocidades de cada uno, uno es más apropiado que el otro para ciertas cosas. Por ejemplo, mientras que el Bluetooth se usa para aplicaciones como los teléfonos móviles y la informática casera, la velocidad del ZigBee se hace insuficiente para estas tareas, desviándolo a usos tales como la Domótica, los productos dependientes de la batería, los sensores médicos, y en artículos de juguetería, en los cuales la transferencia de datos es menor. Existe una versión que integra el sistema de radiofrecuencias característico de Bluetooth junto a una interfaz de transmisión de datos vía infrarrojos desarrollado por IBM mediante un protocolo ADSI y MDSI. Figura 27: Logotipo ZigBee Alliance Actualmente ya podemos encontrar un dispositivo ZigBee para la transferencia de datos entre robots Lego Mindstorms NXT. Dicho hardware se conecta al ladrillo del NXT como un sensor más y es capaz de conectar entre si una gran cantidad de robots NXT. Su alcance le permite enviar datos hasta una distancia de 1200 metros en exterior y más de 90 metros en interior. 35 Figura 28: Dispositivo ZigBee para Lego NXT 2.6. LEGO NXT 2.6.1. Introducción Lego Mindstorms es un kit de robótica fabricado por la empresa Lego, el cual posee elementos básicos de las teorías robóticas, como la unión de piezas y la programación de acciones, en forma interactiva. Este robot fue comercializado por primera vez en septiembre de 1998. Comercialmente se publicita como «Robotic Invention System», en español Sistema de Invención Robotizado (RIS). También se vende como herramienta educacional, lo que originalmente se pensó en una sociedad entre Lego y el MIT. La versión educativa se llama «Lego Mindstorms for Schools», en español Lego Mindstorms para la escuela y viene con un software de programación basado en la GUI de Robolab. Lego Mindstorms puede ser usado para construir un modelo de sistema integrado con partes electromecánicas controladas por computador. Prácticamente todo puede ser representado con las piezas tal como en la vida real, como un elevador o robots industriales. Lego Mindstorms fue uno de los resultados de la fructífera colaboración entre Lego y el MIT. Esta asociación se emplea como ejemplo de relación entre la industria y la investigación académica que resulta muy beneficiosa para ambos socios. La línea Lego Mindstorms nació en una época difícil para Lego, a partir de un acuerdo entre Lego y el MIT. Según este trato, Lego financiaría investigaciones del grupo de epistemología y aprendizaje del MIT sobre cómo aprenden los niños y a cambio obtendría nuevas ideas para sus productos, que podría lanzar al mercado sin tener que pagar regalías al MIT. Un fruto de esta colaboración fue el desarrollo del MIT Programmable Brick (Ladrillo programable). 2.6.2. Ladrillo NXT 36 El bloque NXT es una versión mejorada a partir de Lego Mindstorms RCX, que generalmente se considera la predecesora y precursora de los bloques programables de Lego. Debido a la comercialización de los bloques programables, Lego vendió la generación NXT en dos versiones: Retail Version y Education Base Set. Una ventaja de la versión Educacional es que se incluía las baterías recargables y el cargador, pero esta misma versión debía comprar el software según el tipo de licencia: Personal, Sala de clases, Sitio. Figura 29: Ladrillo del Lego NXT 2.6.2.1. Microcontrolador El microcontrolador que posee es un ARM7 de 32 bits, que incluye 256 Kb de memoria Flash y 64 Kb de RAM externa, la cual a diferencia del bloque RCX, posee mayores capacidades de ejecución de programas, evitando que los procesos inherentes de varios paquetes de datos colisionen y produzcan errores y un posible error en la ejecución del software. Su presentación es similar al Hitachi H8 ya que se encuentra en el circuito impreso del bloque, junto a la memoria FLASH. 2.6.2.2. Entradas y salidas En el bloque de NXT existen cuatro entradas para los sensores, pero los conectores son distintos de los del RCX, lo que impide la conexión de sus motores o sensores, sin embargo, el kit de NXT incluye el adaptador para que los sensores de RCX sean compatibles con NXT.16 37 Las salidas de energía son tres, localizadas en la parte posterior del bloque, haciendo que la conexión para los motores y partes móviles sean de más fácil acceso. 2.6.2.3. Comunicaciones El bloque de NXT puede comunicarse con el computador mediante la interfaz de USB que posee, la cual ya viene en la versión 2.0. Además, para comunicarse con otros robots en las cercanías posee una interfaz Bluetooth. Esta conectividad con Bluetooth no tan sólo permite conectarse con otros bloques, sino también con computadores, teléfonos móviles, y otros aparatos con esta interfaz de comunicación. Dentro de las posibilidades de conexión se encuentran: Conectar hasta tres dispositivos distintos Buscar y conectarse a otros dispositivos que posean Bluetooth Recordar dispositivos con los cuales se ha conectado anteriormente para conectarse más rápidamente Establecer el bloque NXT como visible o invisible para el resto de los dispositivos. 2.6.3. Motores Los motores integrados al bloque son menos versátiles, pero no dependen de conexiones externas, lo cual visualmente ayuda al robot en su presentación. El modelo NXT usa servo motores, los cuales permiten la detección de giros de la rueda, indicando los giros completos o medios giros, que es controlado por el software. El encoder o tacómetro, por su parte, permite conocer el número de vueltas que ha dado el eje del motor con una precisión de 1 grado. Es decir, si el motor realiza un giro completo el encoder verá incrementada su cuenta en 360 unidades. Esto es cierto sea cual sea el sentido de movimiento del motor, incrementándose en un sentido y decrementándose al girar en sentido contrario. Además, el control de la velocidad de los motores se realiza con una señal PWM (Pulse Width Modulation o modulación por ancho de pulso) en la que, dependiendo del ciclo de trabajo de la señal de entrada, podemos incrementar o decrementar la velocidad de los motores. 38 Figura 30: Motor del Lego NXT 2.6.4. Sensores El robot Lego puede utilizar dos tipos distintos de sensores, tanto los originales de Lego como los que han sido construidos por terceros. 2.6.4.1. Sensores originales Lego Algunos de los sensores originales de Lego que podemos encontrar son los siguientes: Sensor de luz: El sensor de luz permite tomar una muestra de luz mediante un bloque modificado que un extremo trae un conductor eléctrico y por el otro una cámara oscura que capta las luces. Esta cámara es capaz de captar luces entre los rangos de 0,6 a 760 lux. Este valor lo considera como un porcentaje, el cual es procesado por el bloque lógico, obteniendo un porcentaje aproximado de luminosidad. La principal utilización de este sensor es la detección de líneas, en aplicaciones como el seguidor de línea, lucha de sumos, robots limpiadores, etc. Figura 31: Sensor de luz del Lego NXT Sensor de temperatura: El sensor de temperatura permite leer el valor aproximado de la temperatura, mediante la interacción de un termistor en uno de los extremos, generando un campo magnético que permite la detección aproximada de la temperatura del bloque que lo contiene. El bloque original de 39 Lego posee un termistor de 12.2 Kohms a 25 °C con un coeficiente de corrección aproximado de un -3,7%/°C. Figura 32: Sensor de temperatura del Lego NXT Sensor de contacto: El sensor de contacto permite detectar si el bloque que lo posee ha colisionado o no con algún objeto que se encuentre en su trayectoria inmediata. Al tocar una superficie, una pequeña cabeza externa se contrae, permitiendo que una pieza dentro del bloque cierre un circuito eléctrico comience a circular energía, provocando una variación de energía de 0 a 5 V. Figura 33: Sensor de contacto del Lego NXT Sensor de giro: El sensor de giro permite conocer la posición del robot en cualquier instante. 40 Figura 34: Sensor de giro del Lego NXT Sensor ultrasónico: su principal función detectar las distancias y el movimiento de un objeto que se interponga en el camino del robot, mediante el principio de la detección ultrasónica. Este sensor es capaz de detectar objetos que se encuentren desde 0 a 255 cm, con una precisión relativa de +/- 3 cm. Mediante el principio del eco, el sensor es capaz de recibir la información de los distintos objetos que se encuentren en el campo de detección. Figura 35: Sensor de ultrasonidos del Lego NXT 2.6.4.2. Sensores de terceros A parte de los sensores creados por Lego, podemos encontrar varios sensores creados por fabricantes externos a lego y que permiten ampliar la funcionalidad y sensorización de nuestro robot en una gran medida. Algunos de estos sensores se pueden conseguir en: HiTechnic (www.HiTechnic.com) MindSensors (www.MindSensors.com) 41 Los sensores más importantes que podemos destacar en este apartado son los siguientes: Sensor de brújula: permite conocer cual es la orientación del robot respecto al norte magnético. Sensor de aceleración: Es capaz de medir las aceleraciones en los ejes de coordenadas. Sensor cámara: Este es uno de los más importantes y que se han utilizado a lo largo del proyecto. Este sensor es capaz de obtener imágenes del medio en el que opera y obtener su información. Su funcionamiento se detallará en secciones posteriores. Figura 36: Sensor cámara NXTCam V2 2.6.5. Programación Para la programación del robot existen varias alternativas a la programación por diagramas de cajas o arbol de decisiones que se proporciona con el robot, el cual tiene una funcionalidad bastante limitada. Para una programación utilizando lenguajes de programación de alto nivel se utilizan principalmente los siguientes lenguajes: RobotC: Entorno de desarrollo integrado que tiene como objetivo la programación del NXT o RCX bajo el lenguaje de programación C. Una de sus ventajas es que no necesita sustituir el firmware original del robot, funcionando bajo el original. Entre sus principales características tenemos una interfaz parecida a la de VisualBasic, herramientas para realizar la depuración de nuestras aplicaciones, tutoriales para aprender la sintáxis del lenguaje y permite la ejecución de distintas tareas de forma concurrente. 48 6. Hybrid agentes 7. Smart agentes Figura 38: Tipos de agentes por Nwana Por su parte, y después de las definiciones dadas por Nwana, Franklin y Graesser, en 1996, dan la suya propia: “un agente autónomo es un sistema situado dentro de una parte del entorno que sensoriza, actuando sobre el todo el tiempo, buscando en todo momento cumplir con sus objetivos.” Al observar que, después de esta definición, incluso un termómetro podría ser considerado un agente, discuten una nueva clasificación, sugiriendo que los agentes pueden ser categorizados por estructuras de control, entornos (bases de datos, sistemas de ficheros, Internet), por el leguaje en el que han sido escritos, y sus aplicaciones. Por eso, finalmente definen la taxonomía que podemos ver en la siguiente imagen. 49 Figura 39: Tipos de agentes por Franklin y Graesser El tiempo y la experiencia acabaran determinando cual es el largo significado de la palabra agente. Como muchos otros términos en uso común como “desktop”y “mouse”, la palabra agente terminará denotando un artefacto software en concreto. 3.4. ¿Por qué agentes? El trabajo original en agentes instigado por investigadores trata de estudiar modelos computacionales de inteligencia distribuida. En el diseño de sistemas distribuidos los agentes proporcionan aspectos sociales, lenguajes y protocolos de comunicación de agentes y distribución de datos, control, conocimiento y recursos. En cuanto al análisis del sistema, un sistema multi-agente tiene un mayor grado de abstracción que un sistema programado mediante la utilización de objetos. Al utilizar la tecnología agente, nuestra aplicación tiene una mayor autonomía y capacidad de decisión, componentes heterogéneos que mantienen relaciones entre ellos y con escalas de tiempo diferentes. Además, facilitan la evolución del sistema, ya que son capaces de adaptarse al entorno y las modificaciones que éste va realizando. Proporcionan escalabilidad, pudiendo añadir más agentes si es necesario llevar a cabo acciones con una mayor carga de trabajo. Podemos también añadir funcionalidad en tiempo de ejecución, con un desarrollo incremental, con capacidad de aceptar nuevos elementos. 50 Los principales motivos que nos han llevado a seleccionar a los agentes son la autonomía de decisión, punto muy importante en nuestro caso en concreto, en el que queremos distribuir una serie de robots para que realicen movimientos de forma colaborativa. También son ventajas el flujo de control propio, la encapsulación de la activación de un comportamiento, la autonomía y la organización mediante las relaciones sociales entre los agentes. Sin embargo, los agentes puede que no siempre sean la solución ideal para un determinado caso de estudio. La tecnología agente, debido a su autonomía y flexibilidad, puede acarrear una ausencia de control/visión global del sistema, lo que puede no ser beneficioso en determinados escenarios. 3.5. Comunicación entre agentes 3.5.1. Introducción Comunicar, según la Real Academia Española, consiste en “hacer a otro partícipe de lo que uno tiene”. La comunicación es uno de los actos más importantes en un sistema multiagente, ya que es la llave para obtener todo el potencial de dicho paradigma. Los sistemas multiagente, al estar orientados a la resolución distribuida de problemas, necesitan de la capacidad de comunicación mediante la cual establecer estrategias de cooperación. Los modelos de comunicación se dividen en dos grandes grupos. Arquitectura de pizarra: La pizarra es una zona de trabajo común donde se encuentra la información a compartir. Esta pizarra puede ser consultada por todos los agentes, del mismo modo que todos pueden dejar información en ella. Pueden existir agentes con tareas de control específicas sobre la pizarra, así como varias pizarras. De este modo, no hay comunicación directa entre los agentes, teniendo toda la información centralizada en cada una de las pizarras. 51 Figura 40: Comunicación utilizando una pizarra Paso de mensajes: La comunicación se realiza del mismo modo que se realiza entre dos seres humanos, mediante el establecimiento e intercambio directo de mensajes entre dos agentes (emisor y receptor). Como ventaja encontramos que es más flexible que la anterior, además de que no es necesario tener toda la información centralizada. Figura 41: Comunicación utilizando mensajes 3.5.2. Organizaciones de estandarización Las organizaciones de estandarización se encargan de la redacción y aprobación de las normas que rigen cual debe ser el formato de la información. En concreto, podemos hablar de tres organizaciones de estandarización para el caso de los agentes software. 3.5.2.1. OMG Asociación de empresas e instituciones formada a finales de los 80. Su objetivo era la reutilización, portabilidad e interoperabilidad de sistemas distribuidos de componentes software orientados a objetos. Sus resultados fueron UML (Unified 52 Modeling Languaje), CORBA (Common Object Requies Broker Architecture) y MASIF (Mobile Agent System Interoperability Facility). 3.5.2.2. KSE La iniciativa fue tomada por varias empresas a las cuales interesaba el software agente: ARPA (Advanced Research Projects Agency), ASOFR (Air Force Office of Scientific Research), NRI (Corporation for National Research Initiative) y NSF (National Science Foundation). Su objetivo principal fue facilitar la compartición y reutilización de bases y sistemas basados en conocimiento. Además, para conseguir una interacción eficaz de agentes software eran necesarias tres componentes fundamentales: 1. Un leguaje común 2. Una comprensión común del conocimiento intercambiado 3. Una habilidad para intercambiar todo lo relativo al lenguaje y la comunicación. De sus trabajos surgen varios lenguajes como resultado, los cuales son: KIF (Knowledge Interchange Format): lenguaje para el intercambio de conocimiento. Ontolingua: Lenguaje para la definición de ontologías KQML (Knowledge Query and Manipulation Language): Lenguaje para la comunicación entre agentes e interoperabilidad entre agentes en un entorno distribuido. 3.5.2.3. FIPA Organización internacional dedicada a la promoción de la industria de los agentes inteligentes mediante el desarrollo de especificaciones que soporten la interoperabilidad entre agentes y aplicaciones basadas en agentes. Su especificación cubre todos los aspectos de un entorno de agentes: aplicaciones, arquitectura, comunicación, protocolos de interacción, actos comunicativos, lenguajes de contenidos, gestión de agentes y transporte de mensajes. Hasta la fecha ha publicado 3 conjuntos de especificaciones: FIPA 97, FIPA 98 y FIPA 2000. 53 3.6. FIPA (Foundation for Intelligent Physical Agents) Una de las formas de alcanzar la deseada interoperabilidad entre plataformas es la definición y uso de estándares aprobados por un comité internacional. En el área de los agentes, FIPA es la organización encargada de producir especificaciones para la interacción de agentes y sistemas de agentes heterogéneos. En la siguiente sección describiremos brevemente el modelo de referencia propuesto por FIPA para las plataformas de agentes, así como el formato e intercambio de los mensajes. 3.6.1. Modelo de referencia de FIPA Uno de los objetivos principales de FIPA es especificar una arquitectura de agentes que permita la utilización de un amplio número de mecanismos y servicios, como varios protocolos de transporte o servicios de directorio. Dada la posibilidad elegir entre varios de estos mecanismos y protocolos, los sistemas de agentes construidos de acuerdo a esta arquitectura deberían de ser capaces de interoperar a través de pasarelas de transporte, ya que la especificación para una arquitectura abstracta de FIPA permite la creación de diferentes implementaciones y ofrece también las transformaciones tanto para transporte de mensajes, esquemas de codificación de mensajes y localización de agentes y servicios a través de directorios de servicios. Sin embargo FIPA no cubre otros aspectos que surgen o dependen de la implementación, bien por que están fuera de ámbito o porque no están incluidos en las especificaciones. Una plataforma de agentes FIPA se define como el software que implementa un conjunto de especificaciones FIPA. Para que se considere que sigue las normas de FIPA, una plataforma debe implementar al menos la especificación sobre la gestión de agentes y las relativas al lenguaje de comunicación de agentes (ACL). La primera se ocupa del control y gestión de agentes dentro de y a través de plataformas de agentes. Las relativas al ACL se encargan del formato de los mensajes, los protocolos de interacción y de intercambio de mensajes entre agentes, la descripción de actos comunicativos que definen la semántica de los mensajes intercambiados y los diferentes lenguajes para expresar el contenido de un mensaje (lenguaje de contenido). 54 Figura 42: Intercambio de mensajes en FIPA El objetivo de la especificación de gestión de agentes es ofrecer un marco de trabajo estándar donde los agentes FIPA existan y operen, estableciendo un modelo de referencia lógico para la creación, registro, localización, comunicación, migración y baja de agentes. Este modelo de referencia se compone de un conjunto de entidades que ofrecen diferentes servicios. Estas entidades son: Agente: un agente software es un proceso computacional que implementa la funcionalidad autónoma y comunicativa de la aplicación, ofreciendo al menos un servicio. Los agentes se comunican a través de un ACL. Un agente debe tener al menos un propietario y un identificador de agente (AID) que lo identifica de forma unívoca. Además, un agente puede disponer de varias direcciones de transporte a través de las cuales puede ser contactado. Dependiendo de la implementación de la plataforma un agente puede tratarse de un componente Java o un objeto CORBA. DF (Directory Facilitator): un facilitador de directorio que ofrece un servicio de páginas amarillas para localizar agentes. Los agentes deben registrarse previamente en este servicio para ser localizados como proveedores de un servicio, y recurren a él en busca de agentes que ofrezcan un determinado servicio. 55 AMS (Agent Management System): un sistema de gestión de agentes que controla el acceso y uso de la plataforma de agentes. Sólo puede existir un agente AMS por plataforma, y se encarga de generar AIDs válidos además de ofrecer un servicio de búsqueda de agentes por nombre. MTS (Message Transport Service): un servicio de transporte de mensajes ofrece un servicio de comunicación entre agentes, encargándose del transporte de mensajes entre agentes. FIPA especifica para este componente un modelo de referencia y varias especificaciones sobre distintos protocolos y mecanismos de transporte que favorece la interoperabilidad entre plataformas. AP (Agent Platform): la plataforma de agentes ofrece una infraestructura física sobre la que desplegar los agentes y está compuesta de un software de soporte, los componentes para la gestión de agentes (DF, AMS, y MTS) y los agentes. Además, FIPA también define y especifica una serie de elementos y conceptos importantes necesarios para conseguir la interoperabilidad. Estos conceptos son: un servicio (para definir un conjunto de acciones incluidas en una ontología), un ACL (lenguaje para construir mensajes y actos comunicativos) y un AID (identifica un agente incluyendo denominaciones, roles y direcciones). 3.6.2. Comunicación FIPA – FIPA ACL La comunicación con FIPA ACL es un servicio de transporte utilizado por los agentes que implementan la especificación FIPA, con el fin de intercambiar información entre ellos. Está basado en la teoría de los actos del habla y con él somos capaces de enviar un mensaje, codificarlo y transmitirlo como una secuencia de bytes. Un mensaje en FIPA ACL representa la intención de realizar alguna acción (acto comunicativo). Este servicio tiene las siguientes características: 1. Servicio de confianza, donde los mensajes que están bien creados/formados no tienen inconveniente para llegar a su destino. 2. Fiable, ya que los mensajes se reciben tal y como se envían, sin modificaciones. 3. Ordenado. El orden de llegada de los mensajes es el mismo que el orden de salida. El elemento básico para la comunicación en la especificación FIPA ACL es el mensaje. Estos mensajes tienen la siguiente estructura: 1. Identificador del acto comunicativo (obligatorio). 56 Figura 43: Actos comunicativos en FIPA 2. Pares parámetro-valor sin un orden predefinido (opcionales). Los posibles parámetros a definir en un mensaje ACL son: a. Content: Contenido del mensaje. b. Sender: Identidad del emisor del mensaje. c. Receiver: Identidad del receptor del mensaje, puede ser un agente o una lista de agentes. d. Language: El nombre del lenguaje de representación empleado en el atributo content. e. Ontology: El nombre de la ontología utilizada en el atributo content. f. Reply-With: Etiqueta para la respuesta (si es que el emisor la espera). g. In-Reply-To: Etiqueta esperada en la respuesta. h. Protocol: identificador del protocolo de interacción que se está utilizando. i. Conversation-Id: identificador de una secuencia de actos comunicativos que forman parte de una misma conversación. 57 j. Reply-To: Agente al que han de ser enviadas las respuestas (si no es el emisor). k. Reply-By: Indicación del tiempo en el que se quiere que se responda al mensaje. Además, el modelo de comunicación está basado en la asunción de que dos agente que quieren conversar han de compartir una ontología común que describa el universo del discurso, de forma que podamos asegurar que estos agentes atribuyan el mismo significado a los símbolos utilizados en los mensajes. Una ontología es una descripción formal de los conceptos y relaciones que pueden existir en una determinada comunidad de agentes. 3.7. JADE (Java Agent DEvelopment Framework) Java Agent DEvelopment Framework, o JADE, es una plataforma software para el desarrollo de agentes, implementada en JAVA, que ha estado en desarrollo al menos desde 2001. La plataforma JADE soporta la coordinación de múltiples agentes FIPA y proporciona una implementación estándar del lenguaje de comunicación FIPA-ACL. Jade fue desarrollado originalmente por Telecom Italia y se distribuye como software libre. Podemos descargar su última versión desde su sitio (http://jade.tilab.com) 3.7.1. La plataforma de agentes JADE La plataforma JADE es 100% compatible con el JDK 1.4 o superiores, e incluye la funcionalidad necesaria para la creación básica de agentes, la programación de comportamiento de los agentes en base a Behaviours, implementación de la especificación FIPA ACL para el envío y recepción de mensajes, clases útiles para programación de protocolos FIPA, manejo de información usando ontologías, etc. Además, proporciona la plataforma FIPA (AMS, Facilitador de directorio y MTS), puede ejecutarse en una o varias JVM (donde cada JVM es vista como un entorno en donde los agentes pueden ejecutarse concurrentemente e intercambiar mensajes) y se organiza en contenedores (un contenedor principal que contiene el AMS, DF y RMA y más contenedores no principales conectados al principal). 64 alguno de los agentes del vector ha cambiado su estado y ya no tiene disponible dicho servicio. 3.7.4. Comunicación entre agentes Una de las características mas importantes que los agentes JADE poseen es la habilidad para comunicarse. El paradigma de comunicación adoptado es el paso de mensajes asíncrono. Cada agente tiene una pequeña pila de entrada de mensajes donde el runtime de JADE almacena los mensajes enviados por otros agentes. Así mismo, cada vez que un mensaje es añadido a la cola de mensajes, el agente que lo recibe es notificado. Sin embargo, el instante en el que el robot coge el mensaje de la cola y lo procesa depende únicamente del programador. Figura 46: Cola de mensajes en JADE 3.7.4.1. Envío de mensajes Enviar un mensaje a otro agente es tan simple como rellenar las valores de un objeto de tipo ACLMessage y llamar al metodo send() de la clase Agent. A continuación vamos a enviar un mensaje de información al agente Ayudante1 avisándole de que necesitamos su ayuda: ACLMessage msg = new ACLMessage(ACLMessage.INFORM); msg.addReceiver(new AID(“Ayudante1”, AID.ISLOCALNAME)); msg.setLanguage(“Castellano”); msg.setContent(“Necesitamos ayuda”); 65 send(msg); 3.7.4.2. Recepción de mensajes Como hemos dicho anteriormente, el runtime de JADE automáticamente almacena los mensajes recibidos en la cola de llegada tan pronto como sean recibidos. Un agente puede obtener un mensaje de su propia cola de mensajes utilizando el método receive(). Este método devuelve el primer mensaje en la cola de mensajes (y lo elimina) o devuelve null en caso de que la cola de mensajes esté completamente vacía. Del mismo modo, disponemos de una función bloqueante para la recepción de mensajes, que detendrá el comportamiento que la invoque hasta que un mensaje con las características necesarias sea recibido. Para ello, debemos invocar a la función blockingReceive(). A continuación mostramos un ejemplo de aplicación de la primera de estas funciones: ACLMessage msg = receive(); if (msg != null) { // Hemos recibido un mensaje y pasamos a procesarlo. } El caso de la espera bloqueante para un mensaje sería muy similar al caso anterior, con la única diferencia de que no es necesario comprobar que el mensaje no es null, ya que siempre se ejecuta dicha instrucción tenemos un mensaje listo para procesar. 66 4.- DESARROLLO PRÁCTICO En este apartado, y después de explicar todos los conceptos teóricos necesarios, nos centraremos en la descripción práctica que se ha llevado a cabo en el proyecto. 4.1. Configuración inicial 4.1.1. Instalación del JAVA JDK (Java Development Kit). Para poder trabajar con el lenguaje de programación Java es necesario instalar lo que se conoce como JDK o Java Development Kit, el cual provee herramientas de desarrollo para la creación de programas en Java. Puede instalarse en un computador local o una unidad de red una vez ha sido descargado del siguiente enlace: http://www.oracle.com/technetwork/java/javase/downloads/jdk-6u26-download400750.html Una vez descargado, solo tenemos que lanzar el ejecutable y seguir los pasos del asistente para instalar el JDK en nuestro ordenador. 4.1.2. Instalación del driver USB de Lego Para que nuestro ordenador pueda comunicarse con todos los robots Lego NXT, independientemente de la versión de firmware que tengan instalada, es necesario instalar los drivers del conector Bluetooth USB de lego. Podemos descargarlos desde el siguiente enlace: http://mindstorms.lego.com/en-us/support/files/default.aspx Una vez instalado el driver, será necesario agregar todos los robots como dispositivos conocidos por el interfaz Bluetooth, ya que en caso contrario no podremos realizar la conexión entre ellos. Para ello, vamos a “Panel de control”->”Dispositivos Bluetooth”->”Agregar…”, con lo que podemos agregar cada uno de nuestros robots introduciendo el PIN cuando nos sea solicitado. 4.1.3. Instalación de LeJOS NXJ. Dado que LeJOS NXJ cuenta con su propio firmware, es necesario reemplazar el original que tienen los robots. Para ello se debe descargar el software desde: http://LeJOS.sourceforge.net/nxj-downloads.php e instalarlo en el ordenador. 67 El software incluye una biblioteca de clases de Java (Classes.jar) que implementan la LEJOS NXJ Application Programming Interface (API), herramientas de PC para actualizar el firmware del robot, cargar los programas, depurarlos, un API de PC para escribir programas de PC que se comunican con los programas de LEJOS NXJ a través de Bluetooth o USB y otras muchas funciones y programas de ejemplo. Se conecta el robot al ordenador por USB y se utiliza la aplicación nxjflash para actualizar el firmware a la versión de LeJOS NXJ, y con esto los robots quedan preparados. Para realizar las aplicaciones, pruebas y rutinas, se ha utilizado el entorno de trabajo de ECLIPSE, por su popularidad entre programadores en Java y por la familiaridad personal con la que se contaba anteriormente. 4.1.4. Instalación y configuración de la plataforma JADE En el presente apartado vamos a explicar la configuración/instalación de la plataforma. Para poder utilizar el framework de JADE es necesario instalar y configurar el equipo. Para ello, lo primero que debemos hacer es descargar las librerías necesarias desde la página web del proyecto (http://jade.tilab.com). La última versión disponible es la 4.0.1, aunque nosotros, por motivos de estabilidad, hemos utilizado la versión 3.4. Para configurar el equipo, es necesario añadir la siguiente línea a la variable de entorno CLASSPATH: CLASSPATH=/ruta/jade/lib/jade.jar:/ruta/jade/lib/iiop.jar:/ruta/jade/lib/http.jar donde ruta indica la ruta donde tenemos las librerías de JADE que acabamos de descargar. Para comprobar que funciona correctamente, abrimos un terminal y ejecutamos el siguiente código java jade.Boot –gui y nos aparece la siguiente ventana: 68 Figura 48: Interfaz de administración JADE Esta es la interfaz de administración de JADE. En ella podemos realizar distintas acciones, desde consultar los agentes en ejecución, lanzar nuevos agentes, consultar sus estados, hacer debug, enviar mensajes ACL, etc. Algunas de estas funciones las explicaremos en el siguiente apartado. Además, como podemos observar, al lanzar la interfaz ya aparecen creados los dos agentes que hemos descrito en el apartado anterior. En concreto, estos dos agentes son: DF (Directory Facilator): agente que se encarga de proveer el servicio de páginas amarillas, donde un agente puede buscar a otros agentes que proveen el servicio que necesita para conseguir sus objetivos. AMS (Agent Management System): provee el servicio de nombres (ya que cada agente debe tener un nombre único en la plataforma) y representa la autoridad en la plataforma, estando dotado de la funcionalidad necesaria para crear/eliminar agentes en su propio contenedor o incluso en contenedores remotos. RMA (Remote Monitoring Agent): Aunque no pertenece a la especificación de gestión de agentes, este agente se encarga del manejo y administración de la interfaz de JADE. 69 4.1.5. Configuración del entorno de desarrollo (Eclipse) Desde http://www.eclipse.org/downloads/ se descarga la última versión de ECLIPSE IDE para desarrolladores Java y hay que descomprimirla en el disco duro. 4.1.5.1. Compilación y ejecución para NXJ Aunque LeJOS NXJ proporciona una aplicación para descargar los programas en el NXT, el hecho de compilar con ECLIPSE y luego usar otra aplicación para descargar los datos al NXT resulta algo engorroso. Por tanto, ya que se va a trabajar en ECLIPSE, se configurará para tener la opción de descargar los programas directamente en el ladrillo, sin necesidad de la aplicación de LeJOS. Para esto hay que configurarlo de la siguiente manera: Con un proyecto abierto, se hace clic en “Run” -> “External Tools” -> “External Tools Configurations…” 70 Figura 49: Configuración Eclipse Se lanza una nueva ventana donde hay que seleccionar “Program” en la parte de la izquierda y el icono de “New launch configuration”. Como nombre se le puede dar “LeJOS Download” por ejemplo y en la pestaña “Main” hay que rellenar el campo “Location” con la ruta donde se encuentra el ejecutable “LeJOSdl.bat” proporcionado por LeJOS. (Deberá estar en %ruta_de_LeJOS_NXT% /bin). Este ejecutable es el que permite descargar directamente al NXT, lo que se está haciendo es vincular el ECLIPSE a esa aplicación para poder hacerlo directamente sin salir del entorno. Siguiendo con la configuración en el campo “Working Directory” hay que introducir “${project_loc}\bin” (sin comillas) y en el campo “Arguments” introducir “${java_type_name}” (sin comillas también). Y aplicar. Figura 50: Configuración Eclipse 2 71 Dar clic en “Add…” en la ventana nueva que aparece y luego seleccionar la opción de “LeJOS Download” (o el nombre que se le haya querido dar a la configuración definida anteriormente). Presionar “Ok” y luego “Ok” de nuevo. Figura 51: Configuración Eclipse 3 De este modo bastará con hacer clic en el botón “Run” que se ha configurado para indicar a Eclipse que debe compilar y descargar el programa en el NXT mediante USB. 72 Figura 52: Configuración Eclipse 4 Cuando ya se ha creado la configuración, se puede poner un acceso directo haciendo clic en el icono de “Run”->”Organize Favorites…” 4.1.5.2. Compilación y ejecución de agentes JADE JADE puede ser ejecutado bajo Eclipse como una aplicación de Java cualquiera. Sin embargo, es necesario llevar a cabo la configuración necesaria, así como incluir las librerías JADE que utilizarán nuestros agentes. En primer lugar, y antes de configurar la interfaz para la ejecución de JADE, debemos incluir las librerías de JADE en el proyecto. Para ello, vamos a “Project”- 73 >”Properties”->”Java Build Path”->”Libraries”. En este momento nos aparecen varios botones. Tenemos que localizar el botón “Add External JARs” y seleccionar las librerías de JADE que hemos descargado previamente y almacenado en nuestro disco duro. Una vez están incluidas aceptamos con el botón “OK”. Figura 53: Inclusión de las librerías en Eclipse Ya tenemos incluidas las librerías en nuestro proyecto, a partir de ahora podemos hacer uso de ellas haciendo llamadas a las funciones que definen. El siguiente paso es configurar Eclipse para la ejecución de aplicaciones basadas en agentes. Para ello, seguimos los siguientes pasos: 1. Vamos a “Run”->”Run Configurations”->”Java Aplication” 2. En la pestaña “Main” introducimos el nombre de nuestro proyecto, en “Main Class” introducimos jade.Boot y nos aseguramos de tener activada la opción que dice “include libraries when searching for a main class”. 3. En la pestaña “argument”->“Program Arguments” introducimos los argumentos que deben ser usados en la línea de comandos cuando se ejecuta JADE. Introducimos lo siguiente: -gui jade.Boot [nombre_agente:paquete_java.nombre_clase] 80 puede ser lanzada únicamente desde el PC que contiene el Main-Container, ya que es donde se encuentra el agente DF. Además, esta interfaz también permite registrar el DF con otros DFs de otras plataformas, con lo que fácilmente podemos tener una compleja red de dominios y subdominios del servicio de páginas amarillas. Figura 59: Herramienta DF GUI Si hacemos doble click en cualquiera de los agentes que nos aparecen en la lista se abre una ventana donde podemos ver los servicios que tiene activos un determinado agente en ese momento, información que se actualiza constantemente y que nos permite conocer información de gran interés en tiempo real. 81 Figura 60: Consulta de servicios publicados con la herramienta DF GUI 4.2.5. Sniffer agent Otra de las grandes herramientas de la interfaz de JADE es el Sniffer Agent. A través de este agente, un usuario puede realizar un “sniff” de un agente o de un grupo de agentes, con lo que todos los mensajes que viajan hacia o desde el agente sobre el que se realiza el “sniff” es inspeccionado y mostrado en dicha interfaz. Todos los mensajes que viajan pueden ser inspeccionados e incluso almacenados en el disco. El usuario puede también inspeccionar todos los mensajes y almacenarlos en un fichero para su posterior análisis y depuración. Esta herramienta puede ser lanzada desde el menú “Tools”->”Sniffer Agent” o desde la línea de comandos a través del siguiente código: Java jade.Boot sniffer:jade.tools.sniffer.Sniffer La siguiente figura muestra una captura de dicha interfaz: 82 Figura 61: Herramienta SnniferAgent 4.2.6. Introspector Agent Esta herramienta permite monitorizar y controla el ciclo de vida de un agente que esta en ejecución. Aquí podemos encontrar información muy útil, pudiendo hace un debug a cada uno de los agentes de nuestra plataforma. Para ejecutarlo, debemos ir a “Tools”->”Instrospector Agent”. En la interfaz que se nos muestra podemos hacer un debug individual a cada uno de los agentes que tenemos en ejecución. Para ello solo debemos seleccionar uno de los agentes que nos aparece en la lista de la izquierda y con el botón de la derecha seleccionamos “Debug On”. Nos aparecerá una ventana con la siguiente información: Current state: estado en el que se encuentra el agente actualmente Incoming Messages: Lista de los mensajes recibidos por el agente en cuestión. Outgoing Messages: Lista de los mensajes que ha enviado un determinado agente 83 Behaviours: Esta es la información más importante de la herramienta, en la que podemos ver cuales son los comportamientos que tiene activos un agente en un determinado instante. En la siguiente imagen podemos ver una captura de pantalla con la información que acabamos de explicar. Figura 62: Herramienta Introspector Agent 4.3. Distribución de la aplicación en varios PCs Uno de los aspectos más importantes en la utilización de la librería JADE es la facilidad que proporciona para distribuir la aplicación a través de la red. Podemos distribuir fácilmente nuestros agentes en varios computadores, con lo que la escalabilidad de una determinada aplicación está garantizada. Al distribuir una aplicación, el host principal crearía los agentes AMS, DF y RMA en su contenedor principal o “Main-Container”, añadiendo el resto de host un nuevo contenedor que se comunicaría con éste. Como podemos observar solo tendremos una instancia de los agentes AMS y DF por lo que, cuando un robot en un contenedor remoto hace una búsqueda de un determinado servicio, se conectará a través de la red con el contenedor principal y a su vez con el agente DF. De esta forma, mientras la aplicación se encuentra distribuida, la publicación de los servicios está centralizada en el agente DF del host principal. El aspecto que quedaría después de la distribución es el siguiente: 84 Figura 63: Contenedores en JADE Lo primero que tenemos que hacer para distribuir la aplicación es seleccionar cual es el host que albergará el contenedor principal. Este host no tendrá que hacer nada especial, ya que son los otros host los que se conectan a éste, por lo que el lanzamiento de los agentes no varía. Si solo queremos poner en marcha la aplicación sin lanzar agentes para que esté disponible para conexiones remotas ejecutamos la siguiente instrucción: Java jade.Boot Una vez tenemos el contenedor principal en ejecución, si queremos agregar un nuevo host a esta arquitectura, debemos lanzar desde el nuevo host la siguiente instrucción: Java jade.Boot –host IPMainContainer –container La opción –container le indica a JADE que tiene que iniciar un nuevo contenedor en el mismo lugar que el contenedor principal. Podemos añadir la instrucción –port númeroPuerto para seleccionar el puerto por el que queremos que se realice la conexión. De lo contrario, JADE tomará el puerto por defecto, que en este caso es el 1099. Además, para que la distribución pueda funcionar sin problemas es necesario indicar a nuestro cortafuegos y/o antivirus que permita las conexiones entrantes y salientes en el puerto en cuestión, ya que de lo contrario no permitirá el intercambio de datos y la distribución fallará. 85 Si todo ha funcionado bien en la interfaz del host principal podemos ver la conexión de los contenedores remotos. Figura 64: Aplicación distribuida en JADE 4.4. Java Threads: Concurrencia en Java. Una de las principales características que se ha utilizado de la programación en JAVA es la creación de hilos de ejecución (también conocidos como Threads) para posibilitar la ejecución de tareas concurrentes, tanto en el robot como en los agentes (que se ha solucionado utilizando un comportamiento ThreadedBehaviour). La máquina virtual de Java (JVM) es un sistema multi-thread. Es decir, es capaz de ejecutar varias secuencias de ejecución (programas) simultáneamente. La diferencia básica entre un proceso de Sistema Operativo y un Thread Java es que los Threads corren dentro de la JVM, que es un proceso del Sistema Operativo y por tanto comparten todos los recursos, incluida la memoria y las variables y objetos allí definidos. A este tipo de procesos donde se comparte los recursos se les llama a veces 'procesos ligeros' (lightweight process). Java da soporte al concepto de Thread desde el mismo lenguaje, con algunas clases e interfaces definidas en el paquete java.lang y con métodos específicos para la manipulación de Threads en la clase Object. Desde el 86 punto de vista de las aplicaciones los threads son útiles porque permiten que el flujo del programa sea divido en dos o más partes, cada una ocupándose de alguna tarea. Para la mayor parte de las aplicaciones programadas ha sido necesario el conocimiento y el manejo de varios hilos de ejecución. Por ejemplo, si la idea es que el robot siga un comportamiento o una rutina y a causa de un cambio externo al robot y detectado por el ordenador, se desea modificar el comportamiento del mismo, se necesitará al menos dos hilos de ejecución en el robot: uno que lleve a cabo la rutina y otro que cada pequeño intervalo de tiempo escuche al ordenador para saber si debe cambiar su rutina debido a algún cambio externo a él. Estas técnicas se han utilizado en las dos aplicaciones que detallamos a continuación 4.5. Aplicación I: Robots limpiadores. 4.5.1. Introducción El hombre, durante toda su existencia, ha convivido con el deseo de crear máquinas capaces de realizar tareas que le facilitasen el trabajo. Por esta razón, la primera aplicación que se ha llevado a cabo ha seguido por esta línea, buscando un modelo autónomo que se encargara de coordinar dos o más robots para realizar la limpieza de un determinado espacio. Este modelo holónico proporciona las directivas de comportamiento a seguir por cada uno de los robots limpiadores, consiguiendo que se coordinen entre ellos para así alcanzar un objetivo común, que en este caso sería mantener su espacio libre de manchas (pelotas). 4.5.2. Descripción del escenario El escenario concreto que se ha utilizado para realizar las distintas pruebas consiste en una superficie de 130 cm de anchura y 170 cm de largura. En ella, se han introducido dos robots, los cuales se encargan de la limpieza de una determinada zona de la superficie. En concreto, un robot tiene asignada la zona norte mientras el otro se encarga de la zona sur. La distribución de robots en la superficie se puede apreciar en la siguiente imagen: 87 Figura 65: Escenario aplicación robots limpiadores Para este ejemplo concreto se han utilizado los robots LEGO NXT con la versión de firmware LejOS, garantizando así la completa compatibilidad entre los robots y la plataforma de agentes JADE, funcionando todos ellos bajo el lenguaje de programación de alto nivel JAVA. En el problema se ha introducido también una cámara cenital que está constantemente (a intervalos regulares de tiempo) obteniendo imágenes del escenario, a partir de las cuales se extrae toda la información necesaria. En concreto, la información que nos proporciona dicha cámara es utilizada para conocer en todo momento cuáles son las coordenadas reales de cada uno de los robots, así como la aparición en el escenario de nuevas manchas/pelotas, lo que nos permite comunicar al robot la aparición de estas y poder activar así sus comportamientos. 4.5.3. Captura y procesamiento de imágenes Para el funcionamiento de la aplicación es necesario obtener toda la información posible de las imágenes que nos proporciona la cámara cenital que tenemos instalada. Para la obtención y filtrado de dichas imágenes se utiliza la librería OpenCV que funciona bajo Java. Se trata de una librería de visión de código abierto desarrollada por Intel bajo la licencia BSD. Es multiplataforma, con lo que puede funcionar en Windows, Linux y MAC OS X. Esta implementación no es una versión completa como la que se utiliza para otros lenguajes como C++, aunque tenemos acceso a todas las funciones necesarias para obtener la información de cada una de nuestras capturas en tiempo real. En concreto, las acciones que debe realizar el algoritmo encargado de controlar la cámara son: 88 Obtener la posición y orientación de cada uno de los robots, para así poder calibrar su posición constantemente. Obtener la aparición de las manchas y sus coordenadas, con el fin de informar al robot pertinente de que debe llevar a cabo su limpieza. Para la detección de los robots se les ha añadido un triángulo de color naranja y otro de color negro en la parte superior a modo de señuelo, con lo que realizando un filtrado por color podemos averiguar de qué robot se trata y a que zona pertenece. Así mismo, el triángulo isósceles posibilita también que podamos obtener cual es la orientación del robot en todo momento Se obtiene una respuesta rápida y en tiempo real frente a la aparición de las manchas, ya que la cámara esté constantemente tomando capturas del escenario y obteniendo la información. En nuestra aplicación en concreto se muestrea el escenario cada 50 milisegundos. En cada uno de esos muestreos las acciones que realiza la cámara son las siguientes: 1. Obtiene una captura del escenario Figura 66: Captura del escenario 2. Realiza un filtrado de la imagen para eliminar toda la información no relevante en nuestro objetivo. 89 Figura 67: Filtrado de la imagen 3. Se obtienen cada uno de los bloobs. Figura 68: Obtención de la información 4. Para cada uno de estos bloobs: a. Se obtienen sus componentes RBG, con lo que podemos discriminar si se trata de una mancha, del robot norte o del robot sur. b. Se dibuja cada una de estas manchas en la interfaz para ayudar a su procesamiento. c. Para los robots, se obtienen no solo sus coordenadas, sino su orientación a partir de la información que nos proporciona el triangulo isósceles situado sobre ellos. La estrategia a seguir para conseguir la orientación del robot es obtener el vector que va desde el centroide del 96 Figura 76: Configuración robot seguidor 4.6.3. Programación del algoritmo En la programación de la aplicación se ha buscado añadir la funcionalidad necesaria para dotar a los convoyes de la autonomía y capacidad de negociación necesaria para responder a diversas situaciones, en las que se requiere toma de decisiones y colaboración entre varios robos o convoyes. 4.6.3.1. AgenteLider Este agente se encarga del control del robot líder, controlando a un determinado robot para que ejerza las acciones propias de un líder del convoy. En concreto, este agente realiza las siguientes funciones: 1. Creación de un convoy, después de recibir una determinada solicitud y de comprobar la disponibilidad de los robots seguidores que se requieren. Si hay suficientes robots seguidores en estado SeguidorEsperando se creará directamente. Sino, buscará un convoy menos prioritario con el número de robots suficientes para crear el nuevo convoy. Si lo hay, solicitará estos robots a su agente líder, sino espera una nueva solicitud. 97 2. Desplazamiento a las coordenadas destino evitando los posibles obstáculos que puedan aparecer en la trayectoria. 3. Negociación y cesión de robots en caso de aparición de un nuevo convoy más prioritario. 4. Negociación con el resto de robots del abandono del convoy por un determinado robot al no tener batería suficiente para proseguir. Además de los comportamientos propios para la realización de estas acciones, se han definido dos comportamientos de tipo ThreadedBehaviour, los cuales se ejecutan en un hilo dedicado de forma concurrente al resto de comportamientos. Estos dos comportamientos se encargan del manejo de la interfaz Bluetooth: uno se encarga del envío de datos y el otro de la recepción, para evitar problemas que se comentan en secciones posteriores. 4.6.3.2. AgenteSeguidor El agente seguidor posee los comportamientos necesarios para formar un determinado convoy cuando éste sea solicitado. Su funcionalidad se resume básicamente en tres tipos distintos de acciones: -Crear y seguir un determinado convoy. -Escuchar posibles solicitudes del robot líder para abandonar el convoy actual y formar parte de uno más prioritario. -Conocer continuamente el estado de la batería y decidir si tiene que abandonar el convoy, solicitando al robot líder su abandono y esperando confirmación por parte de este. Del mismo modo que en el caso anterior, se han definido dos comportamientos de tipo ThreadedBehaviour para la recepción y envío de datos a través del túnel Bluetooth. 4.6.3.3. AgenteSolicitador Este agente se limita a solicitar un determinado número de convoyes con una prioridad entre los valores 1 a 9, siendo prioridad 1 la prioridad más alta y 9 la menos prioritaria. Su funcionamiento se basa en recibir, por parte de una capa superior, la solicitud de una creación de convoy. Es en este momento cuando el AgenteSolicitador busca 98 holones con el servicio LiderEsperando para solicitar la creación de un robot con las características requeridas. 4.6.3.4. Programación de los robots La programación de los robots ha sido menos laboriosa que la de los agentes, ya que son estos últimos los encargados de llevar a cabo la coordinación entre los robots. El robot es capaz de satisfacer todas las necesidades del agente que lo controla y adaptarse a las situaciones cambiantes que le afectan. Para ello se han creado un código que controla al robot líder y otro que controla al robot seguidor. En concreto, las acciones que puede realizar un robot líder y que son recibidas a través de la interfaz Bluetooth son las siguientes: CalibrarRobotLider: Este método se encarga de informar al robot de cual es su situación actual (posición y orientación) al iniciar la aplicación. IniciarConvoy: Con esta orden se sitúa al robot líder en la posición necesaria para comenzar a construir un convoy. Las coordenadas en las que se creará también las recibe desde su agente. IrADestino: Mueve el robot líder a cada uno de los destinos que ha recibido, informando de las posibles situaciones que pueden suceder (aparición de obstáculos, fin de la navegación). EvitarObstaculo: Después de localizar un obstáculo en el escenario y trayectoria del robot, este código se encarga de realizar la evasión del obstáculo, pudiendo elegir entre el algoritmo Bug2 y VFH. IrAConvoy: En este caso, el robot se desplaza hasta un nuevo convoy por ser más prioritario y no disponer de los robots necesarios para su creación. En este método se realiza también evasión de posibles obstáculos. Parar: Se limita a detener el convoy para satisfacer necesidades como la aparición de un convoy más prioritario, el agotamiento de la batería de un robot seguidor, etc. Por su parte, el robot seguidor puede realizar las siguientes acciones: CalibrarRobotSeguidor: De forma análoga al robot líder, este método calibra al robot indicándole su posición inicial y sus coordenadas dentro del escenario. 99 IrAConvoy: Mueve el robot seguidor hasta su posición en el convoy para que pase a formar parte de éste. SeguirConvoy: Código que se encarga de desplazar el robot en el escenario siguiendo a su predecesor. Este método se explica en profundidad en la sección siguiente. Parar: Detiene al robot para satisfacer situaciones como el agotamiento de batería, la aparición de un convoy más prioritario, etc. GetPosiciónRobot: Este método devuelve cuales son las coordenadas y orientación del robot sobre el que se ejecuta. Es necesario para que, si aparece un convoy mas prioritario, el nuevo robot líder pueda calcular la posición a la que debe acudir para crear el nuevo convoy. Giro: Realiza un giro de 180º sobre si mismo para que el robot que lo ejecuta pase a formar parte de un nuevo convoy más prioritario. AbandonoBatería: Si se da la situación en la que un robot no tiene la suficiente batería para continuar, se ejecutará este comportamiento para conseguir que el robot pueda abandonar el convoy. En ambos casos, tanto para el robot líder como para el robot seguidor, se ejecutan concurrentemente los hilos encargados de escuchar la interfaz Bluetooth. 4.6.3.5. Programación de la cámara NXTCam Para dotar a los robots seguidores de la capacidad de seguir a un determinado robot se ha utilizado el sensor NXTCam. Este sensor realiza capturas a través de su objetivo para más tarde procesarlas. Básicamente lo que hace es buscar en la imagen zonas con el color o los colores que se le han programado para luego devolverlos en un vector, añadiendo a cada muestra información útil para su procesamiento. En nuestro caso, la cámara ha sido programada para obtener objetos de color rojo, ya que serán las marcas que poseerán cada uno de los robots en su parte trasera. Para ello, debemos de seguir estos pasos: 1. Conectamos la cámara al PC, lanzar la aplicación NXTCamView y pulsamos el botón “Connect”. 2. En este punto ya tenemos la cámara conectada al PC y podemos tomar capturas, así que enfocamos la cámara a la zona o color de interés y presionamos el botón “Capture”. 100 3. Sobre la imagen obtenida, seleccionamos el color que queremos que la cámara detecte y ajustamos los umbrales a nuestro antojo, permitiendo así un mayor margen de detección (por si cambian variables externas como la luz ambiente, etc.). 4. Una vez establecidos los colores, y con el fin de que la cámara sea capaz de obtener la información de dicho color, guardamos el color en cuestión presionando el botón “Upload”. 5. Para comprobar el correcto funcionamiento podemos lanzar la opción de “Tracking” y ver como detecta el color programado. En la siguiente imagen se muestra una captura de la aplicación. Figura 77: Aplicación NXTCamView Una vez configurada la cámara explicaremos la estrategia que se ha seguido. El robot seguidor es capaz de seguir un determinado robot (con el correspondiente señuelo rojo) adaptando su velocidad a la del robot guía, aumentando la velocidad si detecta que se aleja el señuelo, deteniéndose si se detiene el señuelo y realizando giros para evitar perder el señuelo. La cámara se ha instalado inclinada hacia delante, con lo que, después de obtener el centroide de la marca, tenemos los siguientes casos: 101 a) La marca se detecta en la parte superior de la imagen, lo que indica que se está alejando y que conviene aumentar la velocidad de las ruedas en función de la distancia. b) Si la marca se detecta en la parte inferior de la imagen significará que el robot esta cerca, con lo que conviene reducir la velocidad o incluso detener los motores. c) Si el señuelo se desplaza a uno de los lados será necesario modificar la velocidad de las ruedas para realizar giros, a mayor velocidad de giro cuanto mayor sea el desplazamiento lateral de la marca. Podemos tener simultáneamente dos casos, por ejemplo, que la marca aparece en una esquina superior, con lo que será necesario realizar un giro pero aumentando también la velocidad lineal para no perder el robot predecesor. 4.6.3.6. Algoritmos de evasión de obstáculos Los algoritmos de evasión de obstáculos se encargan de cambiar la trayectoria del robot en base a la información que reciben de sus sensores durante el desplazamiento y con el fin de evitar posibles colisiones. La respuesta del robot en este aspecto debe ser tomar una decisión en función de la lectura de sus sensores y de la posición destino. En esta aplicación se han implementado dos algoritmos de evasión de obstáculos, pudiendo el robot líder elegir entre cualquiera de ellos dos. En concreto, los algoritmos que se han desarrollado son: -Bug2: Es el algoritmo que más ampliamente se utiliza en el campo de la robótica móvil. Representa una técnica en la que solo la lectura actual de los sensores afecta a la hora de tomar decisiones, con lo que su estrategia se basa en detectar un obstáculo para entonces bordear su contorno. El algoritmo finaliza inmediatamente cuando es posible moverse directamente a la posición destino sin producir una colisión, es decir, cuando el robot se encuentra orientado hacia su posición destino de nuevo y ya no hay ningún obstáculo que impida su circulación. En la siguiente imagen podemos observar cual sería la trayectoria a seguir con un obstáculo dado: 102 Figura 78: Algoritmo de evasión Bug2 -Vector field histogram (VFH): Algoritmo desarrollado por J.Borenstein y Y.Koren. El principal inconveniente del algoritmo anterior es que toda decisiones a cada instante teniendo en cuenta únicamente las últimas lecturas de sus sensores. El algoritmo VHF soluciona este problema creando una especie de mapa local del entorno del robot. Su funcionamiento se basa en construir un histograma a partir de los datos que lee de sus sensores, calculando su dirección a partir de esta información. En concreto, se aplica una función de coste para cada una de las opciones, eligiendo siempre la de menor coste. La función de coste es la siguiente: G= a*direcciónObjetivo + b*orientaciónActualRobot + c* orientaciónAnteriorRobot En la formula, el término ‘a’ toma valores mucho mayores que el resto, con lo que se busca minimizar los cambios de trayectoria y alcanzar el destino por la ruta más corta. En nuestro caso, los valores de a, b y c eran 10, 2 y 2 respectivamente. 103 Figura 79: Algoritmo de evasión VFH 4.6.3.7. División de convoyes Una de las características que presenta la aplicación es la posibilidad de dividir un determinado convoy durante su desplazamiento si aparece un convoy con una prioridad mayor. Esta condición se hace verdadera cuando un líder necesita crear un convoy y no hay suficientes robots seguidores en estado de espera, con lo que necesitará solicitar robots a otro convoy que, aunque se ha creado con anterioridad a este, tiene una prioridad menor. La negociación de los robots que forman un determinado convoy es realizada por ambos líderes siguiendo el siguiente patrón: 1. El nuevo líder pregunta a todos los convoyes su longitud y prioridad, para así poder seleccionar a uno de ellos, siendo el elegido aquel que tenga los suficientes robots y una prioridad menor. 2. Una vez seleccionado, informa al líder de dicho convoy la cantidad de robots que necesita. 3. Este envía un mensaje a cada uno de los robots que deben abandonar el convoy para que dejen de ejecutar el comportamiento de seguidores. Así mismo, solicita las coordenadas al último de ellos. 104 4. Informa al nuevo líder de las coordenadas del último robot que forma el convoy para que pueda ir a buscarlos. 5. El nuevo líder calcula a que coordenada debe acudir para posicionarse justo detrás del último robot (a unos 25 cm de distancia más o menos) y, una vez la ha alcanzado, avisa al robot líder de ello. Para obtener la coordenada exacta a la que acudir el agente calcula, en función de la orientación y la posición del último robot del convoy, su posición de acuerdo a la siguiente fórmula: incX = Math.sin (angulo * Math.PI / 180) * 25 ; //ángulo en radianes incY = Math.cos (angulo * Math.PI / 180) * 25 ; xDestino = xUltimoRobot - incX ; yDestino = yUltimoRobot - incY; Figura 80: Cálculo de la posición destino 6. El antiguo robot líder informa a los robots que deben abandonar el convoy que deben realizar un giro de 180º para así pertenecer al nuevo convoy. Estos, cuando han acabado de dar el giro y están preparados, avisan al viejo líder y ejecutan de nuevo el comportamiento de seguidores. 7. Una vez todos los robots están preparados el viejo líder informa al nuevo de que está todo listo, con lo que los dos empiezan a moverse en dirección a sus coordenadas objetivo. 8. Cada uno de los líderes actualiza su información acerca de los robots que forman el convoy. 105 A continuación podemos ver una serie de capturas que ilustran este proceso. Se ha resuelto también la situación en la que puede aparecer un obstáculo en el trayecto de un robot líder mientras éste se desplaza a un convoy menos prioritario para robar robots. En este caso, el algoritmo de evasión de obstáculos utilizado es el mismo. Sin embargo, es necesario comprobar que el obstáculo que se detecta no sea el propio robot que se está intentando alcanzar. Para evitar ejecutar el algoritmo de evasión de obstáculos en esta situación lo que hace el robot es comprobar cual es su distancia a la posición destino mediante la siguiente formula: Distancia = √ ( (xActual – xDestino)² + (yActual – yDestino)² ) Si la distancia es menor de 30 cm indicará que esta cerca de su posición destino, con lo que el objeto que se está detectando es el propio robot que se quiere que forme parte del convoy, con lo que en este caso no se lanzaría el comportamiento de evasión de obstáculos. De lo contrario, significaría que se ha detectado un obstáculo que conviene ser evadido. 4.6.3.8. Abandono del convoy por batería agotada Actualmente, la duración de las baterías es uno de los principales problemas que padecen todos los dispositivos, ya sean móviles, portátiles, reproductores de MP3 o robots. Este fenómeno ha desembocado en un reto de la ciencia actual y que consiste en prolongar la duración de dichas baterías el máximo tiempo posible. Este problema tampoco es ajeno a los robots Lego NXT. Por este motivo, el problema que hemos abordado contempla posibles problemas que pueden aparecer durante la ejecución de la aplicación, proporcionando una solución. En concreto, se ha resuelto el problema que puede aparecer si un robot seguidor se queda sin batería durante su pertenencia a un convoy, ya que no solo él dejaría de seguir al convoy, sino que todos los robots que estuviesen detrás suyo perderían el convoy. En este caso todos los robots posteriores al que agota su batería se detendrían detrás de éste mientras el líder desconocería por completo esta situación. Para solucionar esta situación, cada uno de los robots está monitorizando (a intervalos regulares de tiempo) cual es el estado de su batería. Si se da la situación de que un robot posee poca carga se pondría en contacto con su líder para abandonar el convoy y seguir con el resto de robots. El proceso de comunicación que se seguiría en este caso es el siguiente: 1. El robot con problemas de batería informa a su líder de su estado de baja carga. 112 Anexo A. Programación de agentes con comportamientos En este anexo se explicará detalladamente cual es el procedimiento a seguir para implementar un agente que ejecuta un comportamiento con el código que nosotros necesitemos. Para implementar un determinado agente en la plataforma JADE es necesario crear una clase de Java que extienda de la clase jade.core.Agent y darle código al método setup(), el cual se ejecutará al lanzar nuestro agente. A continuación podemos ver un ejemplo: import jade.core.Agent; public class demo extends Agent{ protected void setup(){ //Aqui introducimos el código que debe ejecutar nuestro agente System.out.println(“Hello World!”); } } Este ejemplo mostrará por pantalla el mensaje “Hello World” y terminará su ejecución. Un agente debe ser capaz de tener las capacidades necesarias para responder a los posibles eventos externos que aparecen. Si queremos que nuestro agente ejecute un determinado comportamiento debemos primero darle código. Para ello, dentro de la clase donde hemos implementado el método Setup(), creamos una nueva clase, la cual en este caso deberá extender a la clase que implementa el tipo de comportamiento que necesitamos. Si queremos un comportamiento que solo se ejecute una vez debemos extender de la clase jade.core.behaviours.OneShotBehaviour. Si por el contrario queremos que se ejecute de forma cíclica extenderíamos de la clase jade.core.behaviours.CyclicBehaviour. Cuando se invoca un determinado comportamiento se ejecuta se método action(), por lo que es aquí donde debemos incluir nuestro código. A continuación mostramos un ejemplo de este desarrollo: private class ComportamientoEjemplo extends OneShotBehaviour{ public void action(){ //Aquí el código del comportamiento System.out.println(“Soy un comportamiento!”); 113 } } Éste comportamiento mostraría por pantalla el mensaje “Soy un comportamiento!”. Para añadir este comportamiento a la pila de comportamientos de un determinado agente debemos llamar al método addBehaviour() de la siguiente forma: addBehavior(new ComportamientoEjemplo()); El planificador de comportamientos sigue un algoritmo Round-Robin, ejecutando el primer comportamiento de la cola y siguiendo hasta llegar al último. Si por ejemplo añadimos esta ultima instrucción al método setup() del agente que hemos definido más arriba y lo ejecutamos lo que obtendríamos por pantalla sería lo siguiente: Hello World! Soy un comportamiento! Si, en lugar de extender de la clase OneShotBehaviour extendemos el comportamiento de la clase CyclicBehaviour el comportamiento se añade a la pila de comportamientos automáticamente cada vez que finaliza su ejecución, por lo que en nuestro caso lo que obtendríamos por pantalla sería lo siguiente: Hello World! Soy un comportamiento! Soy un comportamiento! Soy un comportamiento! Soy un comportamiento! … También se pueden eliminar comportamientos de la cola de comportamientos con el método removeBehaviour(). Como se puede observar este comportamiento se ejecuta en el mismo hilo que el método setup(), por lo que hasta que no finalice la ejecución de éste no se empieza a ejecutar el código del comportamiento. Si, por el contrario, lo que queremos es ejecutar un comportamiento de forma concurrente, será necesario que este sea invocado en un nuevo hilo. Para ello, este comportamiento deberá hacer uso de la clase jade.core.behaviours.ThreadedBehaviourFactory e invocar al método wrap(), el cual se encarga de lanzar el comportamiento. Para ejecutar el comportamiento anterior en un nuevo Thread hacemos lo siguiente: 114 private ThreadedBehaviourFactory hiloComportamiento = new ThreadedBehaviourFactory(); addBehaviour(hiloComportamiento.wrap(new ComportamientoEjemplo())); De esta forma, se creará un nuevo hilo de ejecución para ejecutar el comportamiento ComportamientoEjemplo. Estos comportamientos son los que más se han utilizado a lo largo del proyecto. Si lo necesitamos podemos encontrar más información acerca de la invocación de distintos tipos de comportamientos en la guía de programación avanzada de JADE, la cual se descarga directamente desde el siguiente enlace: http://jade.tilab.com/doc/programmersguide.pdf Para el lanzamiento de cada uno de nuestros agentes podemos utilizar dos métodos, desde la interfaz de administración (como se explica en la sección 4.2.1) o mediante código Java. El código que tenemos que utilizar en este segundo caso, y que se complementa con la sección 4.1.5.2 (donde explica el lanzamiento de agentes mediante Eclipse), es el siguiente: AgentContainer aContainer = getContainerController(); AgentController aController; try { String sName = ""; synchronized(this) { /*Establecemos el nombre de nuestro agente en la variable sName*/ sName="L0"; } /*Mediante el array param podemos proporcionarle argumentos a nuestro agente en el momento de su creación. Estos argumentos serán accedidos desde el agente mediante el método getArguments()*/ Object[] param = {"A87", "00:16:53:0c:10:63", 0, 0, 0}; /*La función createNewAgent() se encarga de crear un agente con los datos que se requieren (nombre del agente, clase que implementa el agente y parámetros). Este agente se lanza desde el método start(), el cual ejecuta el código del método setup() de nuestro agente.*/ 115 aController = aContainer.createNewAgent(sName, "src.AgenteLider", param); aController.start(); } catch(jade.wrapper.StaleProxyException e){ e.printStackTrace(); } 116 Anexo B. Programación y utilización del sensor NXTCam El objetivo del presente anexo es explicar el funcionamiento del sensor NXTCam. El firmware LejOS proporciona la librería lejos.nxt.addon.NXTCam para poder controlar el sensor a través de sus métodos y que podemos encontrar en el siguiente enlace a su API: http://lejos.sourceforge.net/nxt/pc/api/index.html En concreto, los métodos que más nos interesan para realizar el procesado de los datos obtenidos son los siguientes: NXTCam(SensorPort): Creamos un objeto de tipo NXTCam con el que controlar nuestro sensor cámara indicando el puerto en el que ha sido conectada. sendCommand(char cmd): Este método nos permite enviar distintos comandos (inicialización, activación, etc.) a nuestro sensor. getNumberOfObjects(): Devuelve el número total de objetos detectados, independientemente del color que sean. getObjectColor(int id): Indica el color del objeto que se le pasa como argumento, devolviendo el índice de uno de los colores que se le ha programado. getRectangle(int id): devuelve un objeto de tipo java.awt.Rectangle con las medidas y coordenadas del objeto que se le pasa como argumento. La resolución de las capturas que nos proporciona la cámara son 170x143, situándose la coordenada 0,0 en la esquina superior izquierda como se indica en la siguiente figura: 117 Figura A1: Resolución NXTCam El código que se ha implementado para la persecución del convoy se resume en obtener a cada iteración la mancha de mayor área, y en función de su centroide, acelerar, frenar o girar como ya ha explicado en la sección 4.6.3.5. El código que se ha utilizado en la aplicación de generación de convoyes es el siguiente: /*Creamos el objeto cámara y lo incializamos.*/ NXTCam cam=new NXTCam(SensorPort.S1); cam.sendCommand('A'); cam.sendCommand('E'); int increment, numObjetos, x, y, velDerecha, velIzquierda; while(true){ /*Obtenemos el número de manchas que hay en la captura actual.*/ numObjetos=cam.getNumberOfObjects(); if(numObjetos>0){ /*Si se detectan manchas obtenemos la de mayor tamaño con el método obtenerArea y nos guardamos la referencia.*/ rectMax=cam.getRectangle(0); for(int i = 1; i<numObjetos; i++){ rect = cam.getRectangle(i); if(obtenerArea(rect)>obtenerArea(rectMax)) rectMax=rect; } /*Para la mayor de las manchas obtenemos su centroide en las coordenadas x e y.*/ x=(int)rectMax.getCenterX(); y=(int)rectMax.getCenterY(); 118 /*En función de la posición del centroide aplicamos la velocidad necesaria a cada uno de los motores. Si la coordenada y es menor del valor 55 indica que estamos cerca del robot, por lo que debemos detenernos.*/ if(y<55){ if(x>90 && x<110){ //Vamos hacia delante /*La mancha esta centrada, el robot se desplaza en línea recta.*/ velDerecha=300; velIzquierda=300; } else if(x>110){ /*La mancha esta desplazada a la derecha, por lo que, en función de su desplazamiento, hacemos que el robot realice un giro disminuyendo la velocidad del motor derecho.*/ velDerecha=(int)(300-((x*10)-1100)/1.7); velIzquierda=300; } else if(x<90){ /*El caso contrario al anterior, giramos a la izquierda*/ velDerecha=300; velIzquierda=(int)(300-((900-(x*10))/2)); } incremento = (50-y)*4; /*En función de la coordenada y calculamos la distancia a la mancha, por lo que aumentamos la velocidad de los motores sumando el siguiente incremento.*/ velDerecha+=incremento; velIzquierda+=incremento; /*Aplicamos la velocidad al motor derecho. Si es negativa cambiamos el signo e invertimos el sentido de giro.*/ 119 if(velDerecha>0){ Motor.A.setSpeed(velDerecha); Motor.A.forward(); } else if(velDerecha<0){ velDerecha=-velDerecha; Motor.A.setSpeed(velDerecha); Motor.A.backward(); } /*El mismo caso que el anterior pero en el motor izquierdo. Si la velocidad es positiva se aplica directamente, sino se invierte signo y sentido de rotación del motor izquierdo*/ if(velIzquierda>0){ Motor.C.setSpeed(velIzquierda); Motor.C.forward(); } else if(velIzquierda<0){ velIzquierda=-velIzquierda; Motor.C.setSpeed(velIzquierda); Motor.C.backward(); } } /*No se detecta ninguna mancha, por lo que en este caso detenemos los motores.*/ else{ Motor.A.stop(); Motor.C.stop(); 120 } }