Ciclo de ejecución

---

Las versiones de PELEA implementadas comprenden solo una parte de la arquitectura genérica, aprovechando la flexibilidad del sistema para adaptar su red de nodos a unas necesidades particulares. Para entender el ciclo de ejecución propuesto en el paper original, en este apartado van explicando las versiones disponibles para descargar del repositorio, empezando por la más sencilla y terminando por la genérica.

pelea1level

Es la versión más básica de PELEA. Puede usarse directamente tal cual se descarga, por eso es la que se describe en el tutorial de instalación rápida. Consta de solo tres nodos: Monitoring, Execution y Decision support. El que más trabaja es Monitoring, que controla toda la red y hace de servidor. Los demás nodos son clientes que se conectan a él.

Al empezar, todos los nodos se registran en Monitoring. Después Monitoring les manda un mensaje de activación y la red empieza a funcionar. Se leen los ficheros de dominio y problema en PDDL para parsearlos, convirtiéndolos a XML y de ahí a un objeto fácil de tratar. La clase infoMonitoring almacena entre otras cosas el dominio, el problema y el plan recibido.

Tras esto, Monitoring pide al nodo Execution el estado actual del mundo y se lo envía junto con las metas al Decision support en XPDDL. Decision support busca un planificador que pueda resolver el problema. Tras ejecutar el planificador elegido, le manda un objeto de tipo plan a Monitoring. Este plan está compuesto por acciones que pueden estar divididas en subacciones paralelas. Una variable cursor de infoMonitoring indica cuál es la acción que se está ejecutando actualmente. Dicha acción se envía a Execution para que se ejecute.

Después Monitoring pide de nuevo a Execution el estado actual del mundo. A continuación compara el estado que el planificador se esperaba con el estado actual del mundo. Si son similares (la acción ha tenido el efecto esperado en el mundo) se continúa con la siguiente acción del plan y se actualiza el cursor. Si la acción no ha tenido el efecto esperado se inicia la replanificación. Monitoring pide al Decission support un plan reparado enviándole el trozo de plan que ya lleva ejecutado y el estado del mundo recibido. Este nodo usará un replanificador de su lista y en caso de no encontrarlo usará un planificador normal.

Este proceso continúa hasta que se hayan cumplido todas las metas.

pelea2level

El ciclo de ejecución de esta versión es muy parecido al de pelea1level. La diferencia está en que se presupone que ahora el módulo Execution funciona a bajo nivel (coordenadas del robot, ángulos de articulaciones...) en lugar de a alto nivel (robot en punto de inicio, brazos en alto...). Los planificadores usan estados del mundo a alto nivel para determinar qué predicados se cumplen o no. De la traducción entre alto y bajo nivel se encargan dos módulos adicionales: LowToHigh y Low-level planner.

Cuando Monitoring recibe de Execution el estado del mundo a bajo nivel, se lo reenvía al módulo LowToHigh. LowToHigh traduce el estado de bajo a alto nivel y se lo entrega a Monitoring. De este modo, Decision support será capaz de planificar igual que en la versión anterior.

Asimismo, cuando Monitoring selecciona la siguiente acción para ejecutar, debe traducirla llamando a Low-level planner antes de enviársela a Execution. Low-level planner transforma la acción de alto nivel a un conjunto de acciones de bajo nivel que Execution es capaz de interpretar. Puede requerir el uso de, por ejemplo, algoritmos de path-planning para alcanzar el estado deseado desde el estado del mundo actual.

Los módulos LowToHigh y Low-level planner vienen vacíos por defecto porque el propio usuario debe adaptarlos a su problema particular.

Genérico

• Al inicio del ciclo el módulo Execution recibe el problema de alto nivel a resolver (con los objetos que hay en el mundo, el estado inicial y las metas a alcanzar), además del dominioH y el dominioL, que contienen la descripción de las acciones de alto y bajo nivel que el sistema puede realizar. También recibe información del estado de bajo nivel (estadoL) a través de los sensores.
• Toda esta información se envía al Monitoring.
• En caso de ser necesario este módulo llama al módulo LowToHigh que se encarga de crear el estado de alto nivel (estadoH) a partir del estado de bajo nivel (estadoL).
• El problema, que ya incluye el nuevo estado de alto nivel, y el dominio de alto nivel se envían al Decision support, que a su vez invoca al High-level replanner, que crea un plan de alto nivel (planH) y lo envía de vuelta a Decision support.
• En vista de este plan, Decision support calcula las variables que se deben monitorizar y envía esa información (info monitor), junto con el plan, a Monitoring.
• Monitoring manda el plan de alto nivel al Low-level planner que devuelve un plan de bajo nivel (planL), que es el que se manda al módulo Execution.
• Execution toma la primera acción de planL y la ejecuta. A continuación manda el estado de bajo nivel al módulo de Monitoring.
• Monitoring comprueba si en vista del nuevo estado las metas se han cumplido. Si no se han alcanzado, comprueba si las variables a monitorizar (que estaban en info monitor) están en los rangos correctos, es decir, si el estado de bajo nivel es el esperado.
• En caso contrario envía el estado, previo paso por LowToHigh, a Decision support que decide si el nuevo estado requiere de replanificación, reparación del plan, o si los cambios no son relevantes y se puede seguir con el plan inicial.

Este ciclo se repite hasta que se cumplen las metas. En caso de discrepancias entre el estado de bajo nivel encontrado y el esperado, el módulo Monitoring puede también llamar al Low-level planner para que de forma reactiva cree una nueva secuencia de acciones de bajo nivel que solucionen la discrepancia. El módulo de Goal & metric generation actúa solo en caso de que las metas o la métrica del problema cambien. El módulo de Learning recopila información de planes y ejecuciones pasadas para mejorar el comportamiento del sistema.