/ [plg] Planning & Learning research Group - UC3M
PLANNING & LEARNING RESEARCH GROUP logoplg Universidad Carlos III de Madrid

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

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.