INSTITUTO TECNOLÓGICO Y DE ESTUDIOS SUPERIORES DE MONTERREY
DEFINICIÓN DE ESTRATEGIAS DE ROBOTS JUGADORES DE
FÚTBOL A TRAVÉS DE XML.
TESIS QUE PARA OPTAR EL GRADO DE MAESTRO EN CIENCIAS COMPUTACIONALES
PRESENTA
JOSÉ LUIS VEGA ROMERO
Asesor:
Asesor:
Dr. JORGE RAMÍREZ URESTI
Dra. MA. DE LOS ÁNGELES JUNCO REY
Comité de tesis: Dr. ISAAC RUDOMÍN GOLDBERG
RESUMEN
La implementación de comportamientos en robots o agentes computacionales es una tarea que implica el tener conocimientos muy particulares sobre la programación interna del robot. Con el trabajo realizado se separa la programación de bajo nivel del robot de la definición de estrategias, lo que permite un desarrollo acelerado en ambas vertientes.
La definición de los comportamientos en este trabajo se realiza a través de XML por la facilidad de interpretación y la gran cantidad de herramientas disponibles para su manipulación. Los comportamientos se definen como una máquina de estados jerárquica en la cual las acciones pueden ser básicas o bien otros comportamientos definidos a través de XML. Este archivo es interpretado por una máquina de ejecución de autómatas dentro del robot.
El sistema ofrece un código de programación estándar, que puede ser ocupado en otros ámbitos. Las funciones básicas del robot como pueden ser sus movimientos o procesamiento de imágenes, se implementan en el lenguaje nativo del agente, y se relacionan a los comportamientos definidos en XML a través de un sistema de eventos y acciones.
El ambiente de desarrollo incluye un simulador, el cual puede contener robots con diferentes características y un ambiente virtual similar al ambiente real donde desempeñarán su función los robots. El simulador cuenta con varias herramientas para realizar un análisis detallado, puede mostrar en cualquier momento la etapa de ejecución del autómata así como los eventos que el robot puede percibir.
ÍNDICE
1. Introducción ... 7
1.1. Planteamiento del problema ... 8
1.2. Hipótesis ... 10
1.3. Objetivos ... 10
2. Antecedentes ... 12
2.1. Técnicas conocidas de definición de tareas en agentes ... 12
2.2. Planificación ... 13
2.3. Robótica basada en comportamientos ... 16
2.4. Problema de decisión en RoboCup ... 22
2.5. Lenguajes basados en XML ... 26
2.5.1. Historia y beneficios de XML ... 26
2.5.2. Definición de comportamientos de Agentes en XML ... 28
3. Definición de comportamientos a través de XML ... 36
3.1. Documento de XML ... 40
3.1.1. Definición de comportamientos ... 41
3.1.2. Definición de estados ... 44
3.1.3. Definición de transiciones ... 45
3.1.4. Definición de acciones ... 48
3.1.6. Definición de ambiente de simulación XML ... 52
3.1.7. Validación de documentos de XML ... 55
3.2. Implementación en simulador ... 56
3.2.1. Acciones básicas ... 58
3.2.2. Eventos ... 59
3.2.3. Ejecución de la máquina de estados ... 60
3.2.4. Definición del ambiente ... 63
3.2.5. Interfaz con el usuario ... 64
3.2.6. Validación a través de DTD ... 65
4. Resultados ... 67
4.1. Definición de un jugador tipo portero ... 67
4.2. Comunicación ... 76
4.2.1. Envío de pases utilizando Red de contratantes ... 77
4.2.2. Posesión del balón ... 85
5. Conclusiones ... 88
5.1. Trabajo futuro ... 89
6. Referencias ... 92
Anexos ... 96
Anexo a. Manual de usuario del simulador de jugadores de fútbol ... 96
LISTA DE FIGURAS
Figura 2.1 Simulador TBSim utilizada en la arquitectura “Teambots” ... 18
Figura 2.2 Programación estructurada ... 20
Figura 2.3 Programación por capas ... 20
Figura 2.4 Representación jerárquica de un comportamiento ... 22
Figura 2.5 Definición de agentes con XML (Rudomín, Millán) ... 29
Figura 2.6 Definición de estados con XABSL ... 31
Figura 2.7 Imagen generada con la herramienta DotML ... 32
Figura 2.8 Simulación de jugadores definidos con XABSL ... 33
Figura 2.9 Representación de objetos por medio del lenguaje XOD. ... 35
Figura 3.1 Flujo de datos del sistema de decisión ... 37
Figura 3.2 Editor de documentos XML EditiX ... 39
Figura 3.3 Modelo de ejecución del agente ... 41
Figura 3.4 Ejemplo de definición de comportamientos en XML ... 43
Figura 3.5 Encapsulamiento de comportamientos ... 43
Figura 3.6 Ejemplo de definición de estados en XML ... 45
Figura 3.7 Ejemplo de definición de transiciones en XML ... 46
Figura 3.8 Ejemplo de una transición difícilmente ejecutable... 47
Figura 3.9 Ejemplo de una definición de transición nula ... 47
Figura 3.10 Ejemplo de acciones dentro de una transición ... 48
Figura 3.12 Ejemplo de acción con dos parámetros ... 51
Figura 3.13 Ejemplo de diferentes definiciones de eventos ... 52
Figura 3.14 Ejemplo de un archivo de definición del ambiente ... 54
Figura 3.15 Simulación a partir de un archivo de definición de ambiente ... 55
Figura 3.16 DTD para validar una definición de ambiente ... 65
Figura 3.17 DTD para validar un comportamiento ... 66
Figura 4.1 Máquina de estados básica de un jugador de tipo portero. ... 68
Figura 4.2 Máquina de estados para ubicarse en determinada posición. ... 70
Figura 4.3 Secuencia de movimientos del agente portero. ... 72
Figura 4.4 Máquina de estados del jugador portero. ... 73
Figura 4.5 Detalle del estado “Ubicarse”, de un jugador tipo portero. ... 74
Figura 4.6 Máquina de estados del sub-estado ubicarse de un jugador tipo portero. ... 74
Figura 4.7 Máquina de estados del sub-estado ubicarse de un jugador tipo portero. ... 75
Figura 4.8 Ejemplos de sub-máquinas de estado. ... 76
Figura 4.9 Jugadores enviando pases a través de una red de contratantes... 78
Figura 4.10 Jugadores enviando pases a través de una red de contratantes... 80
Figura 4.11 Envío de mensajes tipo KQML para enviar un pase. ... 80
Figura 4.12 Gráfica de la función riesgo para evaluar un posible pase de acuerdo a los ángulos entre un contrario y el agente objetivo ... 82
Figura 4.13 Gráfica de la función de riesgo para evaluar un posible pase de acuerdo a la distancia entre el jugador contrario y la distancia al agente objetivo. ... 83
Figura 4.14 Tiro a Gol ... 84
Figura 4.15 Envío de pases entre jugadores. ... 85
1. INTRODUCCIÓN
Los robots y los agentes computacionales cada vez cuentan con más y mejores características para interactuar con el medio y con las personas. En cuanto a percepción se han tenido grandes avances, desde sensores que pueden medir con precisión una gran cantidad de variables como: temperatura, presión, distancia, iluminación, posición, hasta cámaras de video que bien pueden simular la visión de una persona, en varios casos estas tecnologías de hardware han superado a la percepción humana. También en cuanto a actuadores e indicadores los agentes han evolucionado en gran medida, ahora los agentes se pueden comunicar por emisión de luces, sonido, imágenes e inclusive gestos y pueden realizar tareas en diversos ambientes.
Paralelamente se avanza en técnicas de programación para dotar a los agentes de un pensamiento inteligente que les permita improvisar, aprender y tomar decisiones ante situaciones inesperadas, los avances que se han tenido en áreas de computación y tecnología son asombrosos, en situaciones donde el medio es completamente accesible y la certidumbre de una acción es alta las computadoras aventajan ya al hombre, un ejemplo fue el sistema DeepBlue que venció en una partida de ajedrez a Garry Kasparov considerado por algunos como el mejor jugador de todos los tiempos y en la actualidad existen sistemas jugadores de ajedrez mucho más poderosos y rápidos como Hydra.
Sin embargo al interactuar con el mundo real, donde intervienen una gran cantidad de variables, se tiene un grado alto de incertidumbre y se debe reaccionaren tiempo real, los agentes en la mayoría de los casos siguen dependiendo altamente de una persona que les indique con anterioridad cómo deben actuar.
sistemas multiagentes, encontrando útil contar con elementos como: cooperación, competencia, negociación y aprendizaje, que han hecho posible la presencia de agentes computacionales o robóticos en ámbitos en los que anteriormente sólo una persona era capaz de desenvolverse adecuadamente, estos sistemas de agentes abarcan desde guías turísticos hasta jugadores de fútbol.
Por otro lado, a pesar de los adelantos en compiladores y novedosos lenguajes de programación, el lenguaje de los robots sigue siendo críptico para una persona sin conocimientos de programación. El presente trabajo es un intento por facilitar la tarea de definir el comportamiento de un agente brindando varias herramientas de programación, prueba y análisis, para de ser posible evitar que sean excluidaspersonas ajenas al área de computación o robótica. Se ha desarrollado una estrategia que simplifica la programación y proporciona una plataforma estándar, intuitiva y sencilla para plasmar un modelo de ejecución.
En este primer capítulo se presenta una introducción a la problemática que motiva la realización del trabajo, así como los objetivos que han guiado el desarrollo de la tesis. En el capítulo 2 se revisarán algunos métodos para generar un comportamiento en un robot y mencionaremos algunas de las más exitosas en ambientes robóticos particularmente en un entorno de robots jugadores de fútbol. En el capítulo 3 se presenta el desarrollo de definición de comportamientos a través de XML, así como la implementación en una herramienta de simulación. En el capítulo 4 se muestran varios ejemplos de comportamientos definidos a través de XML y los resultados obtenidos.
1.1.
PLANTEAMIENTO DEL PROBLEMA
Arkin [1] se busca que esto no sea una limitante de forma que cualquier persona sea capaz de definir tareas complejas para robots y sean los mismos usuarios finales los que indiquen que se debe realizar. Para que esto sea una realidad, el sistema debe permitir definir comportamientos de los robots de una manera sencilla e intuitiva para el usuario.
El Tecnológico de Monterrey Campus Estado de México cuenta con un equipo de robots que compiten en la liga de robots cuadrúpedos “RoboCup” [2,3,4], donde precisamente la definición de tareas se realiza por medio de máquinas de estado programadas en el lenguaje nativo de los robots (C++), lo cual no permite que personas ajenas al área puedan definir una estrategia. De acuerdo con algunas plataformas de robots y agentes computacionales [1,5,6,7,8] para que se puedan definir de una manera más sencilla las tareas que los jugadores deben desempeñar y poder involucrar a varias personas en la construcción de estrategias, la plataforma de definición de estrategias debe contar con las siguientes características:
- Sencilla: Se deben definir jugadores de una manera intuitiva y sin necesidad de conocer la programación nativa del robot.
- Jerárquica: Se desea tener varios niveles jerárquicos para mantener una complejidad baja en cada uno de los niveles.
- Escalable: Es necesario que la arquitectura se pueda adaptar fácilmente a los desarrollos de otros módulos.
- Versátil: La plataforma debería poder ser aplicable a otros sistemas, si bien el objetivo primario es tener una plataforma para agentes jugadores de fútbol, el sistema debe de ser lo suficientemente adaptable como para permitir definir tareas en otros ámbitos.
- Estándar: El modelo de las estrategias y definición de tareas debe ser estándar para poder funcionar con otros robots y sistemas y así se pueda tomar como base de futuras investigaciones sobre agentes y sistemas multiagentes.
Actualmente no se cuenta con una herramienta genérica que cuente con todas estas características.
tener rápidos resultados en un ambiente controlado de simulación y sólo probar en el robot los mejores comportamientos.
Además al ser un ambiente rápidamente cambiante como lo es un juego de fútbol no se sabe con certeza cuales son las condiciones y los estados internos del robot que provocan que este actúe de determinada manera, por lo que la mejora de los comportamientos es todavía más difícil.
1.2.
HIPÓTESIS
Al desarrollar una plataforma de definición de comportamientos de robots, por medio de Autómatas Finitos Deterministas (AFD) descritos mediante XML (Extensive Markup Language), se pueden implantar tareas complejas aún sin conocer los detalles de programación del robot. Con dicha herramienta se facilitará la creación de herramientas gráficas que resulten aún más intuitivas para el usuario acelerando el aprendizaje y simplificando los cambios a un comportamiento, al tener una mejor comprensión del sistema de decisión del agente. Si además se desarrolla un sistema jerárquico, los comportamientos definidos pueden ser reutilizados y evolucionarán de acuerdo a las características del robot. Se podría incluso trabajar paralelamente en la generación de nuevos comportamientos. Además este sistema puede utilizarse como un lenguaje genérico de definición de comportamientos en agentes implementando el sistema en la plataforma específica de cada robot. Las características y funcionalidad del sistema serán validadas con la construcción de algunos roles básicos de agentes jugadores de fútbol en un simulador de la liga de robots cuadrúpedos, el cual incluirá herramientas gráficas para visualizar su comportamiento, también se utilizará por personas del área de computación y personas ajenas al área para verificar que realmente el sistema es más fácil de utilizar.
El objetivo general del trabajo es:
Desarrollar una plataforma de definición de comportamientos de robots jugadores de fútbol, en la cual los usuarios pueden implementar tareas complejas aún sin conocer los detalles de programación específicos del robot.
Este objetivo se aborda a través de los siguientes objetivos particulares:
1. Desarrollar un modelado de comportamientos de jugadores de fútbol a través de XML, en el cual se puedan representar tareas complejas, conociendo de antemano cuales son los eventos que el robot puede percibir y las acciones que éste puede llevar a cabo.
2. Desarrollar un programa que pueda ser implementado en un agente computacional, el cual tenga la capacidad de procesar y ejecutar una máquina de estados modelada por medio de XML. De esta manera se podría cambiar de estrategia sin tener que recompilar el código nativo del robot, haciendo este proceso más eficiente y versátil.
3. Programar un simulador de jugadores robóticos de fútbol. Este módulo debe permitir a los usuarios trabajar directamente con estrategias de alto nivel, ocultando los detalles de implementación. Adicionalmente debe ser factible agregar acciones y eventos o bien adecuarse a nuevas características que se incorporen al agente tanto en lo que puede percibir del ambiente como las acciones que puede realizar, sin que esto implique realizar grandes cambios en el módulo de decisión. Además se propone contar con un sistema que pueda exportar las estrategias desarrolladas previamente para que éstas puedan ser probadas en un ambiente controlado; de esta forma, las estrategias podrán ser monitoreadas y mejoradas rápidamente.
2. ANTECEDENTES
El problema de definir inteligentemente comportamientos en agentes se ha estudiado ampliamente, históricamente se ha considerado que la inteligencia de los robots radica en la conexión entre la percepción que se tiene del ambiente con las acciones que estos pueden realizar.
Existen varias técnicas conocidas de solución que han resultado eficientes en determinadas situaciones mas el caso de los agentes jugadores de fútbol es muy particular por las características del ambiente y del propio agente robótico [3]. En este capítulo se revisarán técnicas clásicas de definición de tareas en agentes así como algunas de las técnicas más conocidas y útiles de generación de estrategias en ambientes físicos, donde la intervención del hombre para definir una tarea sigue siendo una de las mejores opciones para lograr que un agente tenga éxito en el cumplimiento de sus metas. Además se revisarán algunas plataformas de desarrollo de agentes tanto físicos como virtuales y características del lenguaje XML el cual se ha utilizado con buenos resultados para definir ambientes virtuales e inclusive para definir tareas en agentes.
2.1.
TÉCNICAS CONOCIDAS DE DEFINICIÓN DE TAREAS EN
AGENTES
soluciones dentro de la representación interna y si esto no es suficiente entonces se experimenta. A partir de esta estructura de representaciones internas y en búsqueda de una solución a determinadas metas, surgen varios métodos de planificación los cuales se han ido refinando a lo largo de la historia.
Los enfoques utilizados varían mucho dependiendo del tipo de agente o robot y de la tarea que se va a desempeñar.
2.2.
PLANIFICACIÓN
Se denomina planeación a la tarea de encontrar una secuencia de acciones u operadores para conseguir un determinado objetivo [11]. Este problema ha sido investigado por décadas y en la actualidad sigue siendo un área en continuo desarrollo.
Los algoritmos de planificación actuales buscan sacar ventaja de la estructura lógica de un problema cuya representación debe ser lo suficientemente descriptiva pero a su vez restrictiva para que los algoritmos que operen sobre esta sean eficientes.
En un planificador se deben de representar adecuadamente, los estados, las metas y las acciones posibles.
Representación de estados. Los planificadores descomponen el mundo en condiciones lógicas representando un estado como la conjunción de literales de primer orden aterrizadas [11].
Representación de metas. Una meta corresponde a un estado parcialmente especificado. Un estado s satisface una meta g si s contiene todos los átomos de g [11].
efectos de haber tomado esta acción [11], a estas acciones también se les denomina operadores.
En ocasiones los sistemas planificadores no requieren propiamente crear un plan, sino buscar un plan que sea el adecuado el cual se encuentre almacenado previamente en memoria [16].
El problema de planificación es un problema intratable cuando se intentan aplicar todos los posibles operadores con las posibles situaciones uno después de otro para obtener todos los posibles estados. Para evitar esto se han generado métodos heurísticos.
Uno de los primeros métodos heurísticos y además de los más conocidos es STRIPS (Stanford Research Institute Problem Solver) [13], presentado por Fikes y Nilsson. STRIPS surge como mejora al método GPS inventado por Newell, Shaw y Simon, comienza con una meta e intenta aplicar los operadores disponibles en sentido inverso para obtener una solución. El resultado esperado como en todo planificador es encontrar un plan o secuencia de operadores que permitan transitar desde un estado inicial a un estado en que todas las metas se hayan cumplido. Los operadores se definen según tres listas: una de precondiciones, o condiciones necesarias para poder aplicar un operador; otra de añadidos o lista de predicados que se agregan después de ejecutar un operador; y una última de borrados o lista de predicados que se quitan de la lista cuando se ejecuta un operador. En conjunto estas listas conforman las precondiciones y postcondiciones de los operadores. Después de cada resolución, el componente del aprendizaje toma un plan computado y lo almacena en un macro-operador con todas sus precondiciones y post-condiciones, de esta manera en un futuro el plan puede utilizarse en situaciones donde se busquen las mismas metas y las precondiciones se cumplan. Este lenguaje y sus variantes son de los más utilizados en la actualidad. Particularmente en RoboCup esta estrategia es utilizada en ligas con hardware sencillo o nulo, por ejemplo la liga de simulación [4].
los caminos, la única restricción de los caminos es que los operadores no pueden regresar a su estado anterior. Resuelve de manera sencilla la anomalía de Sussman presentada en STRIPS.
Otro planificador altamente utilizado es PRODIGY [15] concebido por Jaime Carbonell y Steve Milton, el cual esta construido por un planificador y por varios módulos de aprendizaje que están involucrados tanto en la generación de planes como en el control para guiar una búsqueda efectivamente. Su lenguaje esta basado en STRIPS pero integra una gran cantidad de módulos los cual lo hace muy poderoso, y empíricamente demuestra como planificación y aprendizaje pueden integrarse en una sola herramienta lo cual significa un paso importante hacia la resolución de problemas cercanos al mundo real.
Los planificadores ante la necesidad de solucionar problemas cada vez más complejos han evolucionado hacia formas más eficientes y rápidas para generar un plan. Algunos de los planificadores de propósito general intentan resolver problemas buscando en todo el espacio de solución sin ningún intento por descomponer el problema en problemas más sencillos o determinar que partes del problema son cruciales y deben resolverse primero, inclusive para tareas simples los espacios de búsqueda son muy grandes. Un planificador jerárquico emplea una o más abstracciones del espacio de un problema para reducir el espacio de búsqueda. En lugar de intentar resolver un problema en su espacio original, el planificador resuelve el problema en un espacio abstracto más reducido y después va afinando cada nivel insertando los operadores necesarios para cumplir con las precondiciones ignoradas en un principio. Esta método potencialmente puede reducir en gran medida los espacios de búsqueda y por consiguiente el tiempo y tamaño de un plan, ya que es equivalente a descomponer un problema en problemas más sencillos de resolver. Esta técnica se ha utilizado eficientemente en sistemas planificadores como ABSTRIPS, PRODIGY o GPS. Aún así el formar espacios abstractos automáticamente que descompongan el espacio original de un problema no es una tarea sencilla.
manualmente indicar las abstracciones o bien las representaciones abstractas se forman de la misma manera sin importar el dominio del problema. El primer sistema que automatiza la construcción de representaciones abstractas es ABSTRIPS, el cual restablece la jerarquía de espacios a través de criticas, donde cada nivel ignora las precondiciones de un nivel inferior, el problema que presenta este método es que implícitamente asume que las precondiciones son independientes y no que los planes en conseguir diferentes submetas pueden interactuar entre si, por lo que ABSTRIPS sólo es efectivo sobre espacios de problemas donde se pueda mostrar que las precondiciones pueden ser alcanzadas independientemente [16].
Otro ejemplo de reducción automática de espacios de búsqueda que resuelve la problemática de ABSTRIPS es ALPINE [17], el cual es un sistema que forma abstracciones jerárquicas del problema que son resueltas en una versión jerárquica del planificador PRODIGY, para que las partes del problema que son resueltas en un espacio abstracto se mantengan invariantes mientras se resuelven las restantes partes del problema ALPINE hace uso de la propiedad de monotonicidad ordenada, la cual indica que para todos los planes abstractos, todos los refinamientos de estos planes deben dejar sin cambio las literales establecidas en el espacio abstracto.
2.3.
ROBÓTICA BASADA EN COMPORTAMIENTOS
El término robótica basada en comportamientos puede ser aplicado a un gran número de enfoques de control de robots. Sin embargo existen algunas características comunes en este tipo de arquitecturas [23].
- Existe una estrecha relación entre los sensores del robot y las acciones. En determinado nivel existe un mapeo prácticamente directo entre lo que el robot percibe y las acciones que este realiza.
esfuerzo por crear una representación abstracta del mundo que pudiera ser manipulada internamente.
- Se descomponen en unidades contextuales significativas. Los comportamientos actúan como pares de situación-acción.
- Se requiere de un esquema de control el cual es utilizado para variar los niveles de activación de los comportamientos que se ejecutan concurrentemente.
Son varias las formas por medio de las cuales se implementa la robótica basada en comportamientos. Una de las formas de llevar a cabo esto es implementar una red de varios comportamientos todos corriendo en paralelo ocupando la capacidad de las computadoras de ser multitareas. Así pueden correr varios comportamientos como si procesos independientes con la ayuda de un planificador de tareas. Una manera efectiva de pasar el control entre los procesos y el planificador es implementar cada uno de los procesos como una máquina finita de estados. Se ha encontrado que esta es una manera muy sencilla de implementar comportamientos. Una máquina de estados finitos es una abstracción computacional que esta compuesta por muchos estados. Dada una entrada particular la máquina de estados es capaz de cambiar de estado o bien permanecer en él.
implementación, al compararlos con los retardos de los dispositivos de entrada y salida el sistema basado en Java resulta una alternativa lo suficientemente rápida, esto más los beneficios del lenguaje, como son: su fácil manejo, su rápido desarrollo y portabilidad, hacen que Java sea una muy buena opción como lenguaje de programación. En la figura se muestra el simulador “TBSim” utilizado en la arquitectura Teambots 2.1, con esta plataforma se han programado robots para competir en RoboCup F-180, con buenos resultados, además el simulador ha permitido probar estrategias previo a su control con robots reales..
Figura 2.1 Simulador TBSim utilizada en la arquitectura “Teambots”
También existen algunos intentos por tener un código genérico en dispositivos, que constan de microcontroladores limitados. Una alternativa es la creación de máquinas virtuales como por ejemplo: Lejos 25, desarrollado por la comunidad “sourceforge net”, la cual funciona en equipos RCX de Lego.
Lejos contempla un API completo de programación, que incluye clases de los principales periféricos de Lego, como son motores, sensores de luz, sensores de choque o sensores de temperatura.
virtual de java limitada. Los programas se realizan en Java, se compilan utilizando el compilador estándar (proporcionado por SUN Microsystems, J2SDK). Posteriormente se genera un archivo binario el cual puede ser descargado al RCX, para comenzar su ejecución.
Inclusive en esta plataforma Lejos, muy limitada en cuento a hardware (máximo se pueden conectar 3 sensores y 3 actuadores), existen varias clases para programar los robots en forma de comportamientos organizados por capas. Como se observa en las figuras 2.2 y 2.3 la estructura del programa es muy diferente presentando la estrategia por capas algunas ventajas sobre la programación estructurada.
En el API orientado a comportamientos existen clases a través de las cuales sólo es necesario implementar tres métodos por capa: un método que indica la acción asociada al comportamiento, un segundo método que indica que va a realizar el robot una vez que haya concluido con el comportamiento y un tercer método que devuelve un valor de tipo falso/verdadero el cual indica cuando se va a ejecutar este comportamiento. Se cuenta además con una clase Arbitrer que guarda una relación por capas entre los diferentes comportamientos, esto se logra definiendo los comportamientos en un arreglo, en el cual cada comportamiento tiene asociado un índice que representa la prioridad de ejecución de cada comportamiento. La clase
Arbitrer selecciona sólo un comportamiento a la vez para ser ejecutado, la selección es muy simple ya que recorre el arreglo de comportamientos y si uno de estos devuelve verdadero en su método de disparo, ejecuta este comportamiento. Si existen dos comportamientos que en algún momento podrían devolver un valor de verdadero en su método de disparo, simplemente el comportamiento con mayor prioridad es el que se ejecuta. Por ejemplo si se tiene un comportamiento evasión de obstáculo asociado a un sensor de presión, con una prioridad alta y otro comportamiento de seguir de frente con una prioridad menor el comportamiento con la prioridad mayor es el que se ejecuta y el robot evita el obstáculo.
Figura 2.2 Programación estructurada
Figura 2.3 Programación por capas
inteligencia artificial. Se introduce el concepto de comportamientos abstractos los cuales son tratados como operadores de nivel superior y con los cuales se pueden elaborar estrategias e inclusive planes.
Los elementos que se encargan realmente de realizar algo son los comportamientos primitivos estos son activados por algún comportamiento abstracto toman alguna acción y además tienen la capacidad de enviar una señal al comportamiento abstracto para indicar que una acción todavía no se ha terminado de realizar esto es útil para asegurar que una acción se ejecute completamente. Para agregar características de sistemas simbólicos se usan redes de comportamientos la activación entre estos se da por medio de condiciones que los estados se envían entre sí llamados efectores, estos pueden ser de tres tipos: condiciones permanentes, las cuales deben permanecer activas para que el comportamiento se active; condiciones habilitadoras, las cuales deben de estar activas al momento en que el comportamiento se activa; requisitos de orden, que son acciones que se debieron cumplir con anterioridad. Con estas tres señales que se envían entre los comportamientos se pueden generar estrategias parecidas a las producidas ocupando métodos tradicionales de planeación. En cuanto a la ejecución la red de comportamientos puede ejecutarse de manera oportunista o bien secuencial, en la primera forma no todos los estados se encuentran ordenados (con requisitos de orden) de manera que puede haber varios estados ejecutándose concurrentemente, cuando existen varias acciones que son independientes entre si este tipo de ejecución es óptimo cuando existen acciones que hacen uso de los mismos actuadores entonces se ocupa un mecanismo de bloqueo de los actuadores para que solo un comportamiento haga uso del recurso compartido a la vez.
Figura 2.4 Representación jerárquica de un comportamiento
Paralelamente con el desarrollo de estrategias basadas en comportamiento se ha tenido un importante desarrollo en inteligencia artificial distribuida, estas estrategias han sido de gran utilidad en ambientes de competencia o cooperación, donde ha surgido toda un área de investigación en sistemas multiagentes según Ferber, “Un sistema multiagente es un conjunto de entidades individuales que pueden parcialmente percibir su ambiente e interactuar con él” [9]. Con estas estrategias se ha descubierto que inclusive con comportamientos individuales muy sencillos se pueden obtener comportamientosemergentes muy complejos una vez que los agentes interactúan entre sí.
2.4.
PROBLEMA DE DECISIÓN EN ROBOCUP
de agentes autónomos, sistemas multiagente, colaboración, competencia, desarrollo de estrategias, razonamiento en tiempo real e inclusive desarrollo de hardware.
RoboCup provee una plataforma en la cual los desarrollos de software son validados a través de la experimentación directa con los robots. Paralelamente a las ligas donde los robots juegan físicamente al fútbol se encuentra una liga de simulación sobre la cual se pueden probar estrategias de software, aplicadas al juego del fútbol, en esta liga se puede avanzar de manera más acelerada en lo que a algoritmos y sistemas de agentes se refiere, para después aplicar estos mismos algoritmos en alguna liga donde los robots jueguen físicamente, esto resulta muy necesario ya que en ocasiones el tener un ambiente simulado pasa por alto muchos detalles a los que un robot se enfrenta en el un ambiente real.
Particularmente el juego de fútbol cubre con varias áreas dentro de la inteligencia artificial e ingeniería como son adquisición de datos en tiempo real, comportamientos reactivos, definición de estrategias, aprendizaje, planeación en tiempo real, sistemas multiagentes, reconocimiento de patrones, visión, toma estratégica de decisiones, control, inteligencia entre muchas otras.
El juego del fútbol soccer puede ser visto como un sistema mutiagente, altamente competitivo y a la vez cooperativo. Los jugadores además deben realizar diferentes comportamientos dependiendo de la situación en la que se encuentren la cual es sumamente dinámica ya que la pelota, el agente mismo y los demás jugadores están en constante movimiento.
A pesar de existir muchos desarrollos sobre comportamientos en sistemas multiagentes, el problema en RoboCup es difícil de resolver. Los agentes de RoboCup que compiten en ambientes físicos como es el caso de la liga “Robots Cuadrúpedos”, “Robots pequeños”, “Robots medianos” y humanoides, poseen varias características que dificultan la planificación de tareas. Algunas de estas características se describen a continuación:
con que un objeto este ocluyendo otro o se encuentre detrás de la cámara para que el jugador no pueda percibirlo.
Las acciones de los robots no son determinísticas, a diferencia de otros programas computacionales, en los robots jugadores de fútbol no hay forma de asegurar que una acción tendrá garantizado un efecto bien definido. Por ejemplo al patear la pelota varias veces con una misma patada no se tiene la certeza de que la pelota tome la misma trayectoria en todos los casos.
El robot trabaja en un ambiente no episódico ya que su comportamiento está bien relacionado con las acciones que él mismo y los demás agentes ha realizado en episodios previos. Un ambiente episódico implica que los episodios siguientes no dependen de las acciones que ocurrían en episodios previos.
El ambiente de juego de fútbol es altamente dinámico y no dependen de modo alguno del agente; en él los cambios pueden ser movimientos de oponentes, el balón, intervención de los jueces e inclusive cambios en iluminación y movimiento de los espectadores.
Adicionalmente el ambiente de juego es continuo, no puede ser dividido en etapas bien definidas.
Estas características hacen que la tarea de dar autonomía a los robots sea aún más compleja. El problema puede ser atacado por varios enfoques clásicos como planificación de tareas, pero al necesitar tomar decisiones muy rápidamente implementaciones estáticas como los AFDs, son las más utilizadas. Además se requiere de un esquema de construcción estándar y fácil de manejar. Para que inclusive dentro de la competencia se puedan realizar ajustes de estrategia dependiendo del equipo rival.
buscan características como extensibilidad, adaptabilidad y predicción, no obstante algunos equipos como “RoboLog Koblenz 2000” [19] en la liga de Simulación o el equipo “Mostly Harmless” [20] en la liga de Robots Medianos han aplicado técnicas de planificación con buenos resultados. Cómo se revisará más adelante nosotros ocuparemos un enfoque rápido y reactivo para elaborar comportamientos inteligentes.
Los equipos que ocupan sistemas de decisión basados en planificadores deben de contemplar que se debe poder generar un plan prácticamente en tiempo real. El ambiente es tan dinámico que tal vez un plan generado de manera tardía podría no ser adecuado o inclusive ser nocivo para la meta final del equipo. Más aún, a pesar de haber generado un plan a tiempo, la ejecución del plan en el mundo real puede no arrojar los resultados esperados, por ello se han creado sistemas capaces de ejecutar múltiples planes en paralelo, planes con ciclos condicionales, manejo de acciones con determinada duración y sistemas de falla de plan.
Debido a que se requiere un sistema rápido y reactivo muchos equipos han optado por dejar a un lado el problema de planeación (que toma por lo general más tiempo), e intentar solucionar el problema de otras formas como por ejemplo máquinas de estados o árboles de decisión [1].
La competencia de RoboCup a desencadenado el desarrollo de sistemas completos de programación de agentes robóticos, un ejemplo es “Tekkotsu”[7] desarrollado en la Universidad Carnegie Mellon, el cual que provee una plataforma para programar robots AIBO, se implementó con un paradigma orientado a objetos, cuenta con módulos de visión, control, estado del ambiente, entre otros y los robots pueden utilizar un sistema de eventos, como los utilizados en interfaces gráficas, los cuales pueden ser detectados y desencadenar algún proceso.
2.5.
LENGUAJES BASADOS EN XML
Un código escrito en lenguajes de programación como C o Java, para una persona sin habilidades de programación, no resulta de lo más intuitivo cuando se desea programar una tarea en particular a un robot. De hecho difícilmente alguien sin estas habilidades podrá desarrollar con éxito una tarea compleja. Una de las razones de utilizar XML es tener una estructura genérica bien definida para modelar un comportamiento de manera más natural y apegándose a determinadas reglas de escritura que en conjunto conformen un lenguaje fácil de interpretar y de escribir.
2.5.1. HISTORIA Y BENEFICIOS DE XML
El lenguaje XML (Extensible Markup Language) originalmente fue diseñado para publicación electrónica a gran escala. Se deriva del lenguaje SGML (ISO 8879) el cual fue presentado por Goldfarb en 1986.
Es un lenguaje que especifica una serie de reglas para crear lenguajes basados en etiquetas. Dichas etiquetas ayudan a un documento a separar la estructura de su contenido y describen propiamente la información que contienen.
Actualmente es uno de los métodos de representación de datos más utilizados. Brinda características como la portabilidad de información y facilidad de generación marcos de información estándares (a través de herramientas de validación de esquemas como XSLT y DTDs).
Los datos pueden encontrarse en dos estatus diferentes como datos vivos dentro de las estructuras internas del programa y como datos suspendidos cuando se encuentran serializados mediante alguna notación específica. La deserialización de los datos normalmente se realiza mediante un programa de análisis de formato (parser o loader). XML es una opción más de serialización de datos y ha resultado un mecanismo útil tanto en su almacenamiento como en su transporte.
Debido a su amplia demanda existen varios estándares industriales en continua revisión como son DOM y SAX, también existen múltiples aplicaciones y programas de análisis de este formato en varios lenguajes de programación, por ejemplo: XPath [26] o Xerces [27]. El propósito principal de XPATH es apuntar a partes específicas de un documento de XML, y también provee funcionalidades básicas para manipular cadenas, números y boléanos. XPATH modela un documento de XML como un árbol de nodos donde los nodos pueden ser de diferentes tipos como son elementos, atributos y texto, soportando el uso de 1namespaces. Sobre XPATH se han desarrollado otras herramientas para procesar documentos de XML como XPointer, XLink y XQL (manejo de documentos como si se tratara de una base de datos). Xerces es un parser y manipulador de documentos XML construido para varios lenguajes como Java, C++ y Perl, el cual implementa las recomendaciones de W3C como son: XML versión 1.0, DOM y SAX. Este programa es además altamente modular y configurable.
También se encuentran editores, plugins para herramientas de diseño (por ejemplo Eclipse) y programas de diseño de aplicaciones de XML, como por ejemplo: Oxygen [28], XMLSpy [29], XEENA [30], las cuales son poderosas aplicaciones de edición de documentos en XML, y en la mayoría de los casos incluyen funciones de validación y transformación.
1
Colección de nombres utilizados en un documento de XML como elementos y atributos. Se distinguen por
Para especificar qué elementos y atributos son permitidos en el archivo de XML, se recomienda construir esquemas. Los documentos generados deben estar apegados a este tipo de notación. Los esquemas a pesar de no ser requeridos son herramientas importantes para guardar la consistencia de los archivos de XML. De esta manera se puede comparar un documento en particular con su esquema y revisar si es válido o no.
2.5.2. DEFINICIÓN DE COMPORTAMIENTOS DE AGENTES EN XML
Si bien XML es un lenguaje para transportar datos en la industria, en sistemas de agentes se ha sacado provecho del desarrollo que ha tenido y en varias ocasiones se ha ocupado este lenguaje para modelar un ambiente o un comportamiento.
En trabajos anteriores, como por ejemplo en [6], se han utilizado documentos de XML no sólo para definir animaciones de bajo nivel, si no que además se incluye una forma de interacción del agente con el ambiente, lo cual resulta una manera simplificada para asignar a un agente o grupos de agentes un comportamiento en particular. Los agentes definidos en XML pueden actuar de una manera en particular denominada “tipo de agente”, el cual puede cambiar dependiendo de las condiciones. Esto se ha convertido en una manera más sencilla y flexible de crear patrones complejos. En este trabajo los comportamientos se definen a través de máquinas de estado, ya que presentan reacciones rápidas y predecibles.
La figura 2.5 presenta un ejemplo de un documento de XML que define un comportamiento de un agente que sigue a otro cuando este se encuentra cerca. Como se puede observar es sencillo seguir cada uno de los estados definidos con la etiqueta <state> (ej. línea 3). Las transiciones se producen al evaluar una sentencia de tipo switch, identificada por una etiqueta <switch> (línea 4) donde cada una de las transiciones, identificadas por la etiqueta <transition> (línea 7), tiene una precondición que se debe de cumplir para realizar un cambio de estado.
1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17: 18: <agenttype name="boid">
<var name="closest" type="user" /> <state name="init" initial="true">
<switch>
<condition type="close" class="user"> <set var="closest" />
<transition to="follow_me" />
</condition> </switch>
<behavior type="turn" style="run" angle="10" time="0.5" />
</state>
<state name="follow_me">
<behavior type="follow" style="run"
target="closest" speed="12" time="0.25" /> </state>
</agenttype>
<group name="flock" x="-20" y="-20" radius="40">
<model type="boid" size="8" src="mon.md2" tex="mon.bmp" />
</group>
Figura 2.5 Definición de agentes con XML (Rudomín, Millán)
En RoboCup el equipo campeón del 2004 en la liga de robots cuadrúpedos “German Team” [8] ocupa el lenguaje XABSL (Extensible Agent Behavior Specification Language) [5] basado en XML. Esta herramienta se ha propuesto como un método genérico para definir tareas en agentes, mientras estos cuenten con un compilador de C++ disponible. Con el se modelan los comportamientos de los agentes jugadores de fútbol.
El comportamiento de los jugadores es definido a través de un sistema modular de máquinas de estado, donde cada módulo es denominado opción, y éstas son definidas por medio de un archivo de XML.
Las opciones son grafos acíclicos direccionados donde cada flecha del grafo corresponde a una transición entre estados. Los comportamientos se inician en una opción raíz a partir de la cual se activa un estado, a su vez este estado tiene asignado ya sea otra opción o un comportamiento básico. Si es una opción la que se encuentra activa ésta por consiguiente puede activar otra opción y así sucesivamente. En algún punto de la jerarquía de la máquina de estados, la opción en ejecución debe tener un comportamiento básico asociado que implica la ejecución de una acción en particular.
Las opciones en si son un conjunto de estados con sus respectivas transiciones, y cada opción se guarda en un archivo por separado. El tener varios archivos de opciones resulta útil como método para almacenar comportamientos, estos pueden ser reutilizados inclusive en una misma máquina de estados de manera que pueden existir varios estados que ejecuten una misma
opción o comportamiento básico sin que esto sea una limitante. Además si se desarrolla una mejor estrategia basta con actualizar una opción para que en todos los comportamientos que hagan uso de esta se vea reflejada esta mejora.
Las opciones (máquinas de estado) y los comportamientos básicos están parametrizados, es decir, cuando un estado realiza una transición a otro, puede definir algunos datos que la opción
La figura 2.6 muestra la definición de un estado en XABSL, contienen: una acción a realizar, que puede ser básica (utilizando una etiqueta subsequent-basic-behavior) o una opción (subsequent-option); y un árbol de decisión el cual contiene todas las condiciones para realizar una transición a otro estado.
<state name="first-state" is-target-state="true"> <subsequent-basic-behavior ref="move-to"> <set-parameter ref="move-to.x">
<decimal-value value="42"/> </set-parameter>
</subsequent-basic-behavior>
<set-output-symbol ref="op-mode" value="op-mode.fast"/> <decision-tree>
<if>
<less-than>
<decimal-input-symbol-ref ref="foo"/> <decimal-value value="14"/>
<less-than>
<transition-to-state ref="second-state"/> </if>
<else>
<transition-to-state ref="first-state"/> </else>
</decision-tree> </state>
Figura 2.6 Definición de estados con XABSL
tener un espacio reservado en memoria. En este archivo se indica el tipo de dato del que se trata y una breve descripción del parámetro que almacenarán.
Por la misma estructura de XML y la definición de condiciones, el esquema final de control del robot está conformado por un árbol de decisión donde los nodos terminales tienen su correspondiente en un comportamiento básico el cual puede ser ejecutado por el robot, por consiguiente todos los comportamientos básicos se encuentran implementados en el robot en su lenguaje de programación C++.
En esta aplicación se utiliza la herramienta DotML [22], la cual es una extensión de la aplicación DOT para generar diagramas en formato SVG. Con DotML se pueden se pueden generar imágenes de las máquinas de estado las cuales pueden ser comprendidas y publicadas a toda una comunidad de desarrollo (ver figura 2.7).
Figura 2.7 Imagen generada con la herramienta DotML
En la figura 2.8 se muestra una simulación de un partido de fútbol entre un equipo definido en su totalidad en C++ y un equipo definido con XABSL. En la simulación los agentes se muestran con símbolos “<” para los agentes definidos en XABSL y “>” para los agentes contrarios (Diagonal Daemons) el balón se representa con “O”.
Figura 2.8 Simulación de jugadores definidos con XABSL
El simulador resulta ser una herramienta útil para probar las estrategias definidas en XML, si bien no es del todo flexible para cambiar algunos parámetros de simulación, así como para agregar o quitar jugadores, se puede variar la velocidad de la simulación y obtener resultados experimentales rápidamente. Muestra cómo con muy pocas acciones básicas como: go-to (acción para moverse a determinado lugar), get-behind-ball (método para acercarse al balón y ponerse detrás de él), y simple-action (contiene acciones como moverse o patear el balón), se pueden generar comportamientos realmente complejos y lo más importante en cuanto a definición de comportamientos, se pueden probar agentes XABSL contra agentes definidos directamente en C++, donde se puede comprobar que el realizar un cambio directamente sobre C++ es más complicado que cambiar un agente definido en XABSL y se pueden generar comportamientos en XABSL igual o más eficientes que los generados en C++.
máquinas de estado resulta ser una tarea que depende mucho de la intuición y experimentación. Más adelante se revisarán las herramientas que se incluyen en el presente trabajo para facilitar esta tarea.
En cuanto a lenguaje, XABSL resulta una poderosa herramienta de diseño de comportamientos, sin embargo las personas que lo utilizan deben poseer conocimientos de programación por lo menos de sentencias básicas, operaciones lógicas y definición de variables. Para generar comportamientos en este sistema se debe estar familiarizado con el sistema de archivos y sintaxis.
Este lenguaje definitivamente es más fácil e intuitivo que el desarrollo en el lenguaje original de los robots en este caso C++, resulta además sumamente flexible, mas para alguien que no conoce cual es el significado de cada una de las variables así como la magnitud que representan cada uno de los rangos utilizados en las comparaciones puede resultar complicado.
la línea, en la figura 2.9b la definición del bode de la cancha se hace a través de la distinción de líneas formadas por la adyacencia de los colores blanco-verde, amarillo-verde y azul-verde. Una vez definido algún objeto puede ser ocupado dentro de otro archivo de XML para determinar si este guarda alguna relación en particular por ejemplo si se desea determinar si el balón se encuentra dentro de la portería contraria se puede definir un objeto balón, otro área de portería y después con un operador determinar si este último engloba al primero.
a) b)
<object>
<id>PY BEACON</id> <above>
<touching proximity=0.25> <proportional error=0.25>
<blob><colour>PINK</colour></blob> <blob><colour>YELLOW</colour></blob> </proportional>
</touching> </above> </object>
<object>
<id>FIELD EDGE</id> <edge>
<source>FIELD BLOB</source> <colour>WHITE,GREEN</colour> <colour>YELLOW,GREEN</colour> <colour>BLUE,GREEN</colour> <vectorise>line</vectorise> </edge>
</object>
Figura 2.9 Representación de objetos por medio del lenguaje XOD.
3. DEFINICIÓN DE COMPORTAMIENTOS A TRAVÉS
DE XML
Se desarrolló una plataforma de definición de comportamientos de robots, por medio de Autómatas Finitos Deterministas (AFD), descritos mediante XML. En la cual los usuarios pueden implementar tareas complejas aún sin conocer los detalles de programación propios del robot. Esto facilita la creación de herramientas gráficas aún mas intuitivas para el usuario inexperto en computación y robótica.
El esquema que se utiliza para modelar la ejecución del comportamiento consiste en una máquina de estados, el cual responde rápidamente a cambios en el medio ambiente y permite en niveles superiores desarrollar estrategias más complejas.
Se propone que el módulo de definición de estrategias defina el comportamiento del robot mediante un documento XML [1], de esta forma se evita el tener que programar en C++ (lenguaje nativo de los robots AIBO de Sony) un autómata en particular, el robot más bien implementa una máquina genérica que puede correr cualquier autómata y el comportamiento específico esta dado por el documento de XML. El documento de XML ofrece varias ventajas como son: una descripción bien estandarizada, fácil manejo por parte de los usuarios, gran portabilidad, además de múltiples herramientas de desarrollo.
Los agentes pueden cambiar de estrategia sin tener que recompilar el código ya que el modelo del comportamiento se encuentra serializado en el documento de XML, de esta forma el proceso de cambio de estrategia implica solo un cambio en el archivo de XML y no en el código fuente del agente haciendo este proceso más eficiente y versátil.
estrategias son las posibles acciones que puede realizar el agente así como todo aquello que el agente puede percibir del medio ambiente.
Además si desarrollos posteriores permiten agregar nuevas acciones o eventos, como agregar sensores, elaborar un nuevo caminado o recibir un nuevo mensaje, se debe de poder agregar estas nuevas opciones al modelo en XML, sin que esto sea una tarea que implique cambios el las definiciones anteriores. Por ejemplo el lanzamiento de un nuevo modelo de robot AIBO implicaría cambios dependiendo de las nuevas características que se incorporen al robot.
Utilizando este esquema (figura 3.1) se pueden realizar cambios en la estrategia del jugador rápidamente y sin necesidad de entrar en detalles de implementación de bajo nivel. El sistema de etiquetas de XML permite contextualizar cada uno de sus elementos, gracias a esto el documento es fácil de entender por una persona inclusive ajena al área de computación.
La implementación de una estrategia se basa en la definición de AFD, donde cada estado de dichos autómatas representa un comportamiento que el robot puede llevar a cabo. En los apartados posteriores se describe como se logra integrar dichos comportamientos y como se define finalmente la estrategia que un robot puede ejecutar.
Se trabaja sobre un paradigma orientado a eventos parecido al utilizado en Tekkotsu [7] en donde los cambios de comportamiento del robot dependen de eventos que se hayan percibido del exterior, como por ejemplo el encontrar la pelota, caer al piso, entre otros. Sólo que en Tekkotsu la programación de las máquinas de estado se realiza directamente en el lenguaje nativo del robot (C++ para robots AIBO).
El modelado de los objetos por medio de XML debido a la estructura misma de XML se encuentra en forma de árbol. Donde los nodos representan estados y los arcos representan transiciones.
Como en varias de las máquinas de estado jerárquicas [5,6,7] cada estado tiene asociada una acción la cual es propiamente la que el robot ejecutará mientras se encuentre en este estado. Dicha acción puede tener su correspondiente implementación en el robot o bien ser una acción compuesta por otra máquina de estados. Al momento de ejecutar el autómata el nivel más básico debe ser una acción básica con su correspondiente implementación en el robot de manera que este en todo momento realice acciones concretas.
poderosas características más parecidas a un sistema planificador, estas complicarían la definición de una estrategia.
Como se mencionó anteriormente existen varios programas de edición de XML se recomienda utilizar uno que sea muy sencillo y con una curva de aprendizaje corta para el usuario como es el caso del programa “EditX” (figura 3.2) que proporciona una muy sencilla validación con documentos de tipo DTD, estos pueden ser creados y editados inclusive sin conocer los detalles de un documento de XML. El editor toma los elementos de un DTD y se construye una ventana gráfica con estos elementos. De esta manera todos los documentos se observan como un árbol dirigido, el cual puede ser creado editado y expandido de manera gráfica.
3.1.
DOCUMENTO DE XML
En la siguiente sección se muestra como se estructura el documento de XML que modela una máquina de estados, además de las características y restricciones que tienen cada uno de los diferentes elementos. El presente modelado en XML, es el resultado de una serie de mejoras e incorporación de características útiles de otras plataformas existentes como “Tekkotsu” [7] y “German Team” [8]. En esta sección revisaremos como transformar un conjunto de comportamientos como el de la figura 3.3 en un documento de XML.
El elemento más general de nuestro modelo es un conjunto de comportamientos donde cada uno es una máquina compuesta por estados los cuales se interrelacionan con transiciones. Cuando el robot se encuentra en determinado estado puede estar realizando varias acciones básicas o bien estar ejecutando una acción compleja definida por medio de otra máquina de estados, esto se indica incorporando elementos de tipo acción básica o de tipo comportamiento dentro de un estado, además cada estado incluye transiciones de éste hacia otros estados. Las transiciones a su vez pueden incluir condiciones y acciones básicas que sean ejecutadas al realizar la transición. Las condiciones son construidas con eventos generados por el agente. Este es un sencillo pero poderoso esquema para definir tareas complejas.
acción básica
acción básica
acción compuesta
Conjunto de comportamientos
comportamiento
estado
transición
evento1 ^ evento2 … acción1, acción2…
transición
comportamiento
comportamiento estado
estado
transición
transición
Figura 3.3 Modelo de ejecución del agente
3.1.1. DEFINICIÓN DE COMPORTAMIENTOS
La etiqueta más general se denomina “behaviorSet”, no contiene ningún atributo y dentro se encuentran cualquier número de comportamientos. Los cuales representan todo un mapa de acción de un agente, como se mencionó previamente cada comportamiento incluye un conjunto de estados y un conjunto de transiciones entre ellos.
Los comportamientos son definidos de una forma jerárquica en la que un comportamiento a través de sus estados puede contener otros comportamientos. No existe un nivel de jerarquía máximo pero con inclusive tres niveles se han definido comportamientos lo suficientemente complejos como para que un agente sea eficiente en un juego de fútbol [5].
las transiciones del subcomportamiento, sólo en el caso en el que el subcomportamiento es de tipo atómico, no se realizan transiciones en el nivel superior sino hasta que el autómata atómico se encuentre en un estado final (se decidió implementar este esquema ya que existen algunas acciones como una patada que repercuten en varios módulos del robot y para que este pueda realizar otra acción debe haberse completado todo un proceso).
Para tener un límite en la profundidad de ejecución del agente, se exige que las acciones de los estados de un comportamiento se encuentren definidas previamente. Todos los comportamientos son definidos en un mismo archivo de XML, por supuesto sólo uno de estos será el que define el comportamiento del agente y todos los demás derivarán de este. Para señalar en el archivo de XML el estado inicial, se cuenta con el atributo “isInitialBehavior” el cual puede tener valores true o false. Al momento de ejecutar el conjunto de comportamientos, el comportamiento marcado como inicial corresponderá al nivel superior de toda la estructura jerárquica.
Bajo este esquema un autómata puede ser encapsulado como una acción de un autómata de nivel superior y así sucesivamente, lo cual da como resultado que el comportamiento general del robot estará ordenado jerárquicamente evitando tener autómatas sumamente complejos en un sólo nivel. Cuando se desean hacer cambios en el comportamiento global del agente se puede revisar capa por capa, y así determinar sobre cual debemos impactar y cambiar exclusivamente esta porción de la máquina de estados.
Para definir el comportamiento en XML se utiliza una etiqueta denominada behavior la cual contiene los siguientes atributos:
name: Indica el nombre del comportamiento.
isAtomic: Indica si este comportamiento debe ser ejecutado de principio a fin sin ser interrumpido.
isInitialBehavior: Indica si es el behavior inicial del agente.
En la figura 3.4 se muestra un ejemplo de definición de un comportamiento. <behavior name= ”searchBall” isAtomic=”true” >
</behavior>
Figura 3.4 Ejemplo de definición de comportamientos en XML
Una vez definidos estos comportamientos pueden ser reutilizados como acciones en estados que se encuentren en un nivel superior como en [10]. Esto facilita la definición de estrategias por ejemplo: un defensa en algún momento puede ir tras el balón, si ya se tiene definido un comportamiento acercarse-al-balón que ya haga esta tarea en alguno de sus estados simplemente se coloca este comportamiento como acción.
De esta forma alguien que se encuentre definiendo una estrategia puede reutilizar comportamientos previamente definidos, es decir los comportamientos quedan ordenados de forma jerárquica, donde los de más bajo nivel representan acciones básicas y los de más alto nivel representan comportamientos más complejos que pueden incluir acciones básicos o incluso comportamientos complejos (ver Figura 3.5).
estado con acción compuesta
3.1.2. DEFINICIÓN DE ESTADOS
Un estado representa todo un contexto en el cual se encuentra un agente en determinado momento, bajo nuestro enfoque la respuesta del agente ante esta situación es un conjunto de acciones y una posible transición a otro estado.
El autómata contiene un solo estado inicial, estados intermedios y estados finales, donde cada estado tiene asociada una o varias acciones y se puede definir como iterativo o no iterativo.
La máquina de estados requiere de un punto de partida para comenzar su ejecución por lo que se necesita la selección de un único estado inicial. En el documento de XML los estados iniciales corresponden al primer estado definido dentro de un comportamiento.
También pudieran existir estados finales los cuales tienen sentido solo si éste comportamiento modela una acción que no se puede fragmentar o que debiera llegar a determinado punto de ejecución, en otras palabras tiene que terminar toda una secuencia para que el agente pueda salir de esta máquina de estados. Si este es el caso entonces el comportamiento puede ser marcado como atómico y además deben de existir uno o más estados finales que permitan que el comportamiento pase a un estatus de terminado.
Para definir los estados en XML se utiliza una etiqueta denominada state, este elemento está contenido en el elemento behavior y tiene los siguientes atributos:
name: Indica el identificador del estado.
iterate: Indica si la acción realizada es iterativa o no.
isFinalState: Indica si el estado es un estado final. Puede tomar valores true y
false.
En la figura 3.6 se muestra un ejemplo de una definición de estado en XML.
<state name="begin" iterate="false">
Figura 3.6 Ejemplo de definición de estados en XML
Un estado iterativo provoca que una acción se ejecute en repetidas ocasiones, hasta que se encuentre un evento que permita al robot salir de dicho estado. Un ejemplo de este tipo de actividad es: girar hasta encontrar el balón, lo cual puede ser modelado con un solo estado iterativo que tenga la acción de girar y una vez que se genere el evento “ver pelota” cambiar a otro estado. La manera de indicar que un estado es iterativo es con el valor true en el atributo
iterate.
Un estado no iterativo ejecuta su acción asociada una sola vez y posteriormente espera a que ocurra algún evento sin realizar alguna acción en particular. Se indica que un estado no es iterativo con el valor de false en el atributo iterate.
El atributo isFinalState tiene sentido solamente si se trata de un comportamiento atómico. Este es un valor opcional si se omite, el valor por omisión es de false que indica que el estado no es final, para indicar que un estado es final simplemente se agrega el atributo con valor true.
Los estados contienen acciones asociadas y transiciones hacia otros estados, los cuales se revisarán a continuación.
3.1.3. DEFINICIÓN DE TRANSICIONES
Las transiciones se representan con una etiqueta tipo transition, cuyo único atributo es
state el cual indica cual sería el siguiente estado en caso de que se disparara dicha transición.
Dentro de la definición de transición se pueden encontrar cualquier número de eventos, para que una transición se dispare todos los eventos que se encuentren dentro de la definición de la transición deben de estar activos. Esto representa una manera muy sencilla de tener una sentencia conjuntiva de eventos. Para hacer una disyunción de eventos lo que se necesitaría es definir de nueva cuenta una transición hacia el mismo estado pero con otro conjunto de eventos.
El ejemplo mostrado en la figura 3.7 muestra la definición una transición de un estado “adelante” a un estado “searchBallRight” al dispararse el evento “not-ballFound”:
<state name="adelante" iterate="true">
<action id="goForward/>
<transition state="searchBallRight">
<event operator="not"
name ="ballFound"/>
</transition>
<transition state="turnRight">
<event name="ballAtRight"/>
</transition>
<transition state="turnLeft">
<event name="ballAtLeft"/>
</transition>
</state>
Figura 3.7 Ejemplo de definición de transiciones en XML