RoboGraph
Descripción
La mayoría de los sistemas de control de robots móviles funcionan con una capa intermedia con módulos que implementan acciones primitivas y reportan eventes sobre su estado. Estos módulos suelen estar conectados mediante mecanismos de comunicación entre procesos. RoboGraph utiliza redes de Petri jerarquizadas e interpretadas para coordinar la actividad de dichos módulos. Las tareas se definen utilizando un editor de redes de Petri interpretadas y guardandolas en un fichero xml. Un programa de ejecución se encarga de cargar estos ficheros y ejecutar las redes de Petri demandadas por el usuario. Por otro lado se dispone de un programa para monitorizar la evolución de las Redes de Petri en ejecución, muy util para depuración y trazado.
Las redes de Petri son una poderosa herramienta para modelar, diseñar y analizar sistemas distribuidos, secuenciales y concurrentes. Esto proporciona múltiples ventajas en la creación de aplicaciones con robots móviles:
- Reutilización de módulos. Los módulos de navegación e incluso algunos específico permanecen inalterados de una aplicación a otra.
- Reducción del tiempo de desarrollo. En proyectos diferentes pero aplicaciones del mismo tipo, la mayoría de los módulos no presentan diferencias y solo se hace necesario la edición de la red de Petri para personalizar la aplicación. Por ejemplo, se pueden crear distintos proyectos de robots guía para museos con los mísmos módulos cambiando solamente en las redes de Petri los puntos a visitar, el texto a reproducir y otros cambios menores.
- Facilidad de mantenimiento. Los problemas de trazado y depuración pueden resolverse de forma sencilla viendo el estado del sistema según la evolución de una red de Petri y la monotorización de un conjunto de variables..
- Entrenamiento. Casi todo el mundo que ha trabajado o aprendido a utilizar entornos de programación normalizados según IEC 61131-3 (S7 Graph de Siemens, Graphcet, etc) será capaz de programar con nuestra herramienta RoboGraph.
- Análisis y verificación. Las propiedades de las redes de Petri las convierten en buenas candidatas para una evaluación cualitativa (sin temporizar) o cuantitativa (temporizada) del rendimiento de las tareas. En este campo se ha realizado un gran esfuerzo de investigación en el ambito industrial e incluso algo en la creación de tareas en robótica móvil.
RoboGraph se utiliza para la programación de tareas en dos niveles tal como se muestra en la figura. A nivel IPC, las redes de Petri que representan las distintas tareas incluyen comandos (publicación de mensajes) y eventos (recepción de mensajes) sobre los módulos conectados al CENTRAL. A nivel JIPC, las redes de Petri que representan las distintas tareas incluyen comandos (publicación de mensajes) y eventos (recepción de mensajes) sobre los módulos conectados a JCENTRAL.
RoboGraph incluye dos tipos de programa. El GUI (Interfaz Grafico de Usuario) es un paquete de desarrollo que nos permitirá crear, editar y monitorizar la ejecución de las distintas tareas mientras el Dispath se encarga de su ejecución.
GUI
El RoboGraph GUI puede trabajar en tres modos diferentes y es posible pasar de uno a otro en cualquier instante: Editor, Monitor y Play Logger.
En modo edición, el usuario puede crear nuevas tareas utilizando un editor gráfico de redes de Petri simple e intuitivo. Una vez que la red de Petri ha sido creada seleccionando y arrastrando distintos elementos gráficos (Lugares, Transiciones, Arcos y Marcas), deben ser definidas las acciones, asociadas a Lugares y Transiciones, y las condiciones, asociadas a las transiciones para definir la red de Petri interpretada.
Las acciones pueden ser comandos implementados en cualquier módulo de control de la arquitectura. Estos comandos pueden seleccionarse de una lista generada automáticamente por el GUI. Cada comando se corresponde con un mensaje IPC del cual el usuario deberá especificar los parámetros de las variables que aparecerán automáticamente en una nueva ventana cuando se selecciona un comando en el editor.
Cuando el Dispatch ejecute la red de Petri, los mensajes IPC asignados a lugares y transiciones serán publicados según progrese la red de Petri.
Las condiciones pueden ser eventos producidos por cualquier módulo, que se pueden seleccionar de una lista generada automáticamente por el GUI. Un evento puede ser la recepción de un mensaje IPC, una condición sobre algún parámetro de un mensaje IPC o cualquier expresión lógica sobre varios parámetros del mismo o de diferentes mensajes IPC.
Los temporizadores son una herramienta muy extendida en automatización y se presenta muy útil aquí. En las aplicaciones creadas hemos utilizado los temporizadores como un mecanismo de detección de errores temporizando algunas acciones de distintos módulos para detectar posibles bloqueos. Las acciones pueden inicial un temporizador mientras que las condiciones verifican el estado de dicho temporizador.
Se utilizan variables globales para obtener los valores iniciales y para compartir información de eventos y condiciones en lugares y/o transiciones diferentes. La figura muestra la ventana principal de RoboGraph GUI en modo edición.
En este vídeo se muestra el proceso de creación de una tarea de guía de museo (red de Petri). El robot deberá visitar varios lugares y mostrarlos a los usuarios. La red de Petri creada utiliza otra red con nombre go_to_point.
El GUI, funcionando en modo monitor, se conecta al central (IPC) y se suscribe a los mensajes del Dispatch que muestran el estado de las distintas redes de Petri en ejecución. Cada red de Petri en ejecución se muestra en una pestaña con el marcado actual. Cuando el Dispatch evoluciona el marcado de una red de Petri, un mensaje IPC is publicado y el GUI actualiza las pestañas del monitor. Por lo tanto, utilizando el monitor se puede obtener una instantánea del estado del sistema, debido a que el marcado de las redes de Petri representan su estado. Esta es una herramienta muy útil en la depuración de aplicaciones. Por otro lado también se puede visualizar en una nueva ventana las tareas en ejecución (redes de Petri).
Los robots móviles que operan en el mundo real pueden fallar por multitud de razones porque es casi imposible para el programador preveer todas las posibles circunstancias que se pueden producir. Con el fin de poder rastrear los diferentes problemas, se dispone de la posibilidad de crear un fichero XML con los mensajes del Dispatch en tiempo de ejecución. El administrador del sistema puede cargar este fichero con el GUI en modo play-logger y reproducir la misma secuencia con igual latencia o acelerando el tiempo de ejecución. En el GUI se mostrarán distintas pestañas con las redes de Petri en ejecución como en el modo monitor. Aparte de la opción normal de reproducción, el usuario puede monitorizar el fichero log paso a paso, saltar a un lugar definido en ejecución como en muchos entornos de programación y desarrollo para lenguajes de alto nivel (C, Java, C++, etc.). Por último, también es posible ver detalles de los mesajes IPC.
Dispatch
El Dispatch se encarga de la ejecución de las distintas acciones de la capa funcional (acciones básicas), ejecutiva (otras redes de Petri) e interfaces (interfaces de usuario y web), así como de la sincronización con los eventos producidos. La interacción con los módulos de la arquitectura se realiza mediante la publicación y subscripción de mensajes. De esta manera los problemas que se puedan producir en un módulo, como un bloqueo, no provocará el bloqueo del Dispatch e incluso mediante un simple mecanismo se puede detectar el error y recuperarse de un fallo o una situación de error.
Al arrancar, el Dispatch se subscribe a los mensajes de ejecución y cancelación de tareas. Cada uno de estos mensajes disponen de un campo propietario, prioridad y modo de ejecución (serie o paralelo). La prioridad y el propietario definen la prioridad de ejecución y los permisos para poder parar o lanzar una tarea. Las peticiones de ejecución que no pueden ser realizadas, en el momento de la recepción del mensaje, se almacenan en distintas colas en función se su prioridad. La petición de ejecución de una tarea puede venir de varios módulos, tal como una interfaz de usuario (petición de usuario) o incluso del proprio RoboGraph Dispatch cuando la tarea es una acción asociada a otra red de Petri.
La ejecución de una nueva tareas se inicia con la carga del fichero XML que contiene la red de Petri interpretada, situando el marcado inicial, realizando la subscripción a todos los mensajes IPC referenciados en todos los eventos de la red y ejecutando las acciones asociadas a los lugares marcados. La red de Petri solo puede evolucionar con la recepción de un mensaje IPC o con la finalización de un temporizador.
Cada vez que se produce un cambio en el estado de una red de Petri (inicio, final, evolución) o en las colas de ejecución (añadir o eliminar una nueva tarea), se publica un mensaje IPC que refleja el cambio de estado para poder monitorizar con el GUI y guardar en un fichero log para posteriormente utilizar en el GUI en modo play-logger.
RoboGraph dispone de interfaces de comunicación para IPC y JIPC pero puede ser extendido fácilmente a otras arquitecturas modulares con otros sistemas de comunicación.
En este video se puede ver un ejemplo simple utilizando los módulos de CARMEN para programar una sencilla aplicación de guía.
Si está interesado en una parte en concreto, también puede ver:
- Vídeo describiendo el ejemplo: Ejemplo RoboGraph
- Vídeo de la programación de una red de Petri utilizando RoboGraph en modo editor: Programación con RoboGraph
Publicaciones
Título: Using hierarchical binary Petri nets to build robust mobile robot applications: RoboGraph.
Autores: Joaquín L. Fernández, Rafael S. Dominguez, Enrique Paz Domonte and Carlos Alonso
Congreso: IEEE International Conference on Robotics and Automations ICRA2008
Publicaciones: Proceedings of ICRA 2008 pp:1372-1377
Lugar: Pasadena CA USA
Año: 2008
ISBN: 978-1-4244-1647-9
ISSN: 1050-4729
Título: Especificación y modelado de tareas de alto nivel para robots móviles. Aplicación a la interpretación de órdenes vocales.
Autores: Joaquín L. Fernández, Rafael Sanz, Pablo M. Barbosa, Amador R. Diéguez
Congreso: XXVIII Jornadas de Automática 2007
Publicaciones: Proceedings of Jornadas de Automática.
Lugar: Huelva, España, del 5 al 7 de septiembre 2007
Año: 2007
ISBN: 978-84-690-7497-8