Ejecución de la máquina de estados

La deserialización del autómata definido en XML se realiza a través de un parser. El cual extrae del archivo todos los datos necesarios para crear los objetos que propiamente serán ejecutados en el agente. El parser de XML así como la máquina de estados deben de programarse en el agente (utilizando su lenguaje específico).

El agente requiere una máquina que sea capaz de leer los objetos construidos a partir del documento de XML, debe contar con las estructuras de control que determinen el estado en el cual se encuentra y realizar las acciones asociadas a este estado, debe de tener un registro de los eventos que han ocurrido y aquellos que han dejado de ocurrir para en conjunto disparar transiciones entre estados y lograr que el agente exhiba un comportamiento complejo. Además debe ser capaz de manejar adecuadamente la jerarquía de los comportamientos.

Los comportamientos como se mencionó previamente se consideraron atómicos y no atómicos. El primero significaría que una tarea va a ser completada de principio a fin, sin intervención de eventos es decir se comportaría igual a una acción atómica. Si el comportamiento no es atómico significaría que en cualquier momento el autómata puede ser interrumpido por un

evento con su consecuente cambio de estado. Por lo tanto las transiciones del un nivel superior pueden ocultar a las transiciones originales del comportamiento.

En cuanto al nivel jerárquico de los comportamientos se decidió que un nivel superior tiene preferencia sobre un nivel inferior de manera que si un comportamiento no es atómico este puede ser interrumpido para dar paso a una transición de nivel superior.

3.2.3.1. IMPLEMENTACIÓN CON MÁQUINA DE ESTADOS NO JERÁRQUICA

La implementación final de la máquina de ejecución genérica presentada en este trabajo es el resultado de varias mejoras y pruebas que se realizaron a diferentes estrategias solución. La primera solución fue construir un programa para transformar una máquina de estados jerárquica en una máquina de estados no jerárquica, con ello se agiliza la ejecución del autómata ya que cada estado tiene una acción básica relacionada y todas las transiciones se encuentran en el mismo nivel por lo que en un paso cambia al siguiente estado en ejecución. El autómata final se convierte a una forma más sencilla en donde la red de comportamientos corresponde a un solo autómata con solamente un estado inicial y en donde ningún estado es sub-estado de otro, ya que todos finalmente se encuentran en un mismo nivel.

El procedimiento para convertir el autómata jerárquico debe considerar varios casos. Si se trata de un un comportamiento atómico, este se rescribe agregando una transición al estado inicial del sub-autómata en todas las transiciones donde se haga una llamada a este estado, y agregando todas las transiciones de salida al estado final; En caso de ser un comportamiento no-atómico, además de agregar las transiciones de entrada, se deben agregar en cada sub-estado las transiciones de salida definidas en el estado de alto nivel.

Un comportamiento que es agregado como acción compleja en dos estados diferentes, no puede ser tratado como el mismo comportamiento, esto provocaría un funcionamiento equivocado del robot. Para evitar esta anomalía todos los estados son renombrados anteponiendo el nombre del comportamiento al cual están asociados. Por ejemplo, se define un comportamiento “seguir_balón” y más adelante un comportamiento “defender_porteria” tiene un estado “x” y un

estado “y” que tengan asociada la acción “seguir_balón”, si al momento de reducir el autómata se conservara el nombre “seguir_balón”, el autómata al ejecutarse se dirigiría al mismo estado independientemente del camino que se haya tomado para llegar a esta situación, renombrando los estados se corrige el problema, cuando se incluye una acción compuesta (comportamiento) los estados son almacenados anteponiendo el id del estado desde donde es ejecutada esta acción. Para el ejemplo anterior, en el comportamiento “seguir_balón”, se crea un estado “x.segur_balón” y otro “y.seguir_balón”, las acciones compuestas también son agregadas con un nombre extendido por ejemplo: “x.seguir_balón.acciónA”, “x.seguir_balón.acciónB” y en el caso de “y” serían “y.seguir_balón.acciónA”, “y.seguir_balón.acciónB”.

Esta estrategia tiene algunas ventajas y desventajas, al estar todos en un mismo nivel jerárquico la máquina de ejecución es más sencilla ya que basta con revisar exhaustivamente los eventos que han ocurrido y las transiciones definidas dentro del estado de ejecución para realizar un cambio de estado. Por otro lado la explosión de estados en este autómata final es muy grande y se requerirá más memoria para guardar todos estos estados expandidos. Esta estrategia mejora la velocidad de respuesta del agente y simplifica la construcción de la máquina de ejecución, pero por otro lado se complica la construcción y depuración del autómata original.

3.2.3.2. IMPLEMENTACIÓN CON MÁQUINA DE ESTADOS JERÁRQUICA

La segunda implementación y definitiva guarda la misma relación jerárquica de la definición de los estados ya que se crean estructuras de datos para cada uno de los comportamientos y estados los cuales pueden tener asociados ya sea una acción básica, o bien otro comportamiento. Lo más importante de este tipo de implementación es que la ejecución misma se desarrolla de una manera jerárquica. Se ejecuta sobre las mismas estructuras de datos previamente definidas, por lo que ya no es necesaria esta conversión a un autómata plano y por consiguiente ya no se agregan transiciones nuevas a los estados previamente definidos.

La ventaja de esta implementación es que no es necesario realizar este procesamiento previo de los estados para dejarlos de una forma no jerárquica, además se tiene un mejor control sobre la ejecución ya que el usuario ve los comportamientos tal y como los definió en el

documento de XML, con la primera implementación se podría identificar el estado en ejecución revisando el nombre aumentado del estado pero ya no se ejecuta propiamente un comportamiento, todo queda reducido a la ejecución de los estados que tienen asociados acciones básicas. Esta segunda implementación es más natural y se puede observar en el simulador inclusive la ejecución de un estado asociado a un comportamiento no a una acción básica y navegar a través de este.

La ejecución en esta segunda implementación resulta más complicada que la anterior ya que un estado puede ejecutar o una acción básica o un comportamiento, si se trata de un comportamiento nuevamente se tiene que revisar cual es el estado en ejecución de este comportamiento y si este tiene asociado un comportamiento de nueva cuenta se debe avanzar en la profundidad del autómata, esta acción se realiza hasta que finalmente se encuentra un estado que ejecuta una acción básica realizable por el robot.