Castellano     English    
Inicio
RIDE
Investigación
Software
Docencia
Gente
Personal
Otros Enlaces
DGP - Documentación de Distributed Graphic Planner

Distributed Graphic Planner (DGP)

El Distributed Graphic Planner (DGP) es un entorno ejecutivo independiente del middleware (middleware-agnostic) diseñado para especificar, programar, analizar y supervisar aplicaciones distribuidas complejas utilizando Redes de Petri Interpretadas por Mensajes (MIPN). En lugar de depender de pasarelas o puentes inter-middleware especializados y de alta latencia (como los acopladores ROS-a-MQTT), DGP implementa una Interfaz de Middleware Abstracta que se conecta de forma nativa y concurrente a ROS 1, ROS 2, MQTT y JIPC bajo una única lógica de tareas. El entorno incluye un entorno de desarrollo integrado (IDE) para la especificación visual de tareas, la verificación formal de modelos y el seguimiento gráfico de la ejecución, así como un despachador (dispatcher) de alto rendimiento guiado por eventos que ejecuta los modelos de tareas de manera eficiente y con un consumo de recursos despreciable.

GDGP. General Distributed Graphical Planner.

Esta versión de DGP es capaz de trabajar con varios middlewares al mismo tiempo: MQTT, ROS1, ROS2 y JIPC. Ha sido probada con los siguientes middlewares:

Todos los comandos en este documento y los scripts fueron desarrollados para linux. Sin embargo, dado que todo se ha programado en Java, se puede encontrar fácilmente un equivalente en windows.

Requisitos

Descarga

Instalación

Para instalar GDGP, siga estos sencillos pasos:

  1. Descomprima el archivo tar en el directorio donde desee instalarlo. De aquí en adelante se asumirá que se realiza en su carpeta personal (~):
tar -xzvf GDGP.tar.gz

Ejecución

Tras instalar el sistema como se describe en la sección anterior, si tiene instalado Java (versión 17 o superior) debería poder iniciar los módulos de GDGP:

  1. Inicie el despachador (dispatch) de RoboGraph para ejecutar tareas (redes de Petri): 
    ~/DGP/bin$ ./GDGPDispatch
  2. Inicie la interfaz gráfica (GUI) de RoboGraph para editar tareas y monitorizar su ejecución: 
    ~/DGP/bin$ ./GDGPGui

Debería ver la siguiente ventana:

Espacio de trabajo de RoboGraph GUI
Figura 2: Ventana principal del editor de la GUI de RoboGraph al inicio.

Por defecto, solo está activado el middleware ROS1. Para cambiar esto, consulte la sección "Activación de middlewares". En este punto ya tiene el sistema básico funcionando. Utilizando la GUI puede crear su primer proyecto DGP con paquetes y algunas tareas básicas (redes de Petri) con temporizadores, por ejemplo. Sin embargo, una aplicación real incluirá varios módulos (modulo1, modulo2, ...) ejecutándose sobre uno o varios middlewares (hasta el momento se han implementado JIPC, ROS1, ROS2 y MQTT) junto con mensajes (msg1, msg2, ...) para compartir información entre ellos.

Activación de middlewares

La lista de middlewares activados en DGP se define en el archivo de texto DGP/res/middleware_list.

Al iniciarse, DGPDispatch intentará conectarse a todos los middlewares enumerados allí. Tenga en cuenta que si activa middlewares como JIPC, ROS1 o MQTT, deberá iniciar JCentral, roscore o el bróker de MQTT antes de arrancar cualquier otra cosa:

Pruebas del sistema

Se proporcionan algunos ejemplos para probar si los diferentes middlewares funcionan correctamente. En primer lugar, es recomendable probar cada middleware de forma individual. Las MIPNs utilizadas en esta sección se encuentran en el proyecto DGP/examples/paper_RAS. Primero debe abrir el proyecto y compilarlo para generar los archivos de clase (.class).

Pruebas de DGP con ROS1.

  1. Inicie roscore: 
    ~/DGP/bin$ ./startROSCore
  2. Inicie DGP dispatch: 
    ~/DGP/bin$ ./GDGPDispatch
  3. Inicie DGP GUI: 
    ~/DGP/bin$ ./GDGPGui

A continuación, en la GUI mostrada en la imagen anterior, debe seguir estos pasos:

Diálogo Ejecutar Tarea en DGP
Figura 3: Diálogo de ejecución de tareas solicitando "ROS1Tests.latency" dentro de la GUI.

4. Inicie otro módulo de ROS1 que publique el mensaje:

~/DGP/bin$ ./ROS1PublisherPaper

Comenzará a publicar el mensaje e imprimirá en pantalla el número del mensaje y el tiempo. El lugar Report en la MIPN escribirá en el archivo ROS1.txt una línea por cada mensaje recibido con el número de mensaje, la marca de tiempo en que fue enviado y el tiempo en que el despachador reaccionó al mensaje.

Pruebas de DGP con ROS2.

  1. Comente (usando %) todos los middlewares en el archivo DGP/res/middleware_list excepto la línea con ROS2_LP.
  2. Inicie el despachador ejecutando el archivo: 
    ~/DGP/bin$ ./GDGPDispatch
  3. Ordene la ejecución de la red de Petri. Puede hacerlo desde la GUI iniciando DGP/bin/GDGPGui como en el caso de ROS1, cambiando luego al modo de monitorización, haciendo clic en el botón de ejecutar red de Petri y escribiendo ROS2Tests.latency como nombre de la red.
  4. Por último, debe iniciar el módulo de ROS2 que publica mensajes con el tema "/helloRos" de tipo id.jrosmessages.std_msgs.StringMessage con una cadena que incluya "Hello ROS #ROS2%"+ index +" "+ time +" $", donde 'index' es el índice del mensaje y 'time' es el tiempo de publicación actual en milisegundos (System.currentTimeMillis()). También puede suscribirse al mensaje "ROS2/miTopic2" publicado por la red de Petri. Proporcionamos un ejemplo que se puede arrancar con: 
    ~/DGP/bin$ ./ROS2PublisherPaper

Pruebas de DGP con MQTT.

  1. Comente (usando %) todos los middlewares en el archivo DGP/res/middleware_list excepto la línea con MQTT_PAHO.
  2. Inicie el bróker de MQTT (por ejemplo, el bróker mosquitto).
  3. Inicie el despachador ejecutando el archivo: 
    ~/DGP/bin$ ./GDGPDispatch
  4. Ordene la ejecución de la red de Petri. Puede hacerlo desde la GUI iniciando DGP/bin/GDGPGui, cambiando luego al modo de monitorización, haciendo clic en el botón de ejecutar red de Petri y escribiendo MQTTTests.latency como nombre de la red.
  5. Por último, debe iniciar el módulo de MQTT que publica mensajes con el tema "miTopic" con una cadena que incluya "Hello ROS #MQTT%"+ index +" "+ time +" $", donde 'index' es el índice del mensaje y 'time' es el tiempo de publicación actual en milisegundos (System.currentTimeMillis()). También puede suscribirse al mensaje "MQTT/miTopic2" publicado por la red de Petri. Proporcionamos un ejemplo que se puede arrancar con: 
    ~/DGP/bin$ ./MQTTPublisherPaper

Pruebas de DGP con JIPC.

  1. Comente (usando %) todos los middlewares en el archivo DGP/res/middleware_list excepto la línea con JIPC.
  2. Inicie jcentral. Puede hacerlo en su propio sistema o ejecutando el archivo: 
    ~/DGP/bin$ ./jcentral
  3. Inicie el despachador ejecutando el archivo: 
    ~/DGP/bin$ ./GDGPDispatch
  4. Ordene la ejecución de la red de Petri. Puede hacerlo desde la GUI iniciando DGP/bin/GDGPGui, cambiando al modo de monitorización, haciendo clic en el botón de ejecutar red de Petri e ingresando JIPCTests.latency como nombre de la red.
  5. Finalmente, necesita iniciar el módulo de JIPC que publica mensajes con el tema "/disa/dgp/paper/" de tipo std_msgs.String con una cadena que incluya "Hello ROS #ROS1%"+ index +" "+ time +" $", donde 'index' es el índice del mensaje y 'time' es el tiempo de publicación actual en milisegundos (System.currentTimeMillis()). También puede suscribirse al mensaje "ROS1/miTopic2" publicado por la red de Petri. Proporcionamos un ejemplo que puede iniciarse con: 
    ~/DGP/bin$ ./ROS1PublisherPaper

NOTA: Rara vez verá el token en el lugar Report porque la transición T2 se dispara inmediatamente (no tiene condición asociada). Sin embargo, debería ver el archivo correspondiente con los tiempos de latencia (ROS1.txt, ROS2.txt, MQTT.txt o JIPC.txt).

La siguiente imagen muestra la red de Petri para la prueba de latencia:

Diagrama de la Red de Petri de Latencia
Figura 4: Red de Petri de evaluación de latencia que modela el ciclo WAIT-Report.

Tras dos segundos, el temporizador startTime finalizará y el lugar wait recibirá un token. En este estado, si se recibe el mensaje correcto desde el módulo publicador, se disparará la transición Msg_arrive escribiendo en un archivo de texto (<MDLWR>.txt) el índice del mensaje, el tiempo en que llegó y el tiempo en que se disparó la transición. Se activa el lugar Report y se publica un mensaje "<MDLWR>/miTopic2".

Ejemplo de la Tortuga (Turtlesim)

Otro ejemplo proporcionado es una red de Petri que mueve la tortuga de ROS llamada turtle_square. La red de Petri se encuentra en el proyecto DGP/examples/Tasks y se muestra en la siguiente imagen:

Red de Petri de la Tortuga
Figura 5: Red de Petri Interpretada por Mensajes (MIPN) que modela una trayectoria cuadrada para el simulador turtlesim de ROS.

Esta red consta de cinco ramas que se comportan de la misma manera. Cada rama de esta red de Petri tiene dos lugares. Las acciones asociadas al primer lugar (P1) son iniciar un temporizador (pub_rate) con 500 ms y enviar el mensaje para avanzar (geometry_msgs/Twist). La transición T9 está asociada con el fin del temporizador pub_rate, de modo que se dispara tras 500 ms y el primer lugar (P1) recupera el token, volviendo a ejecutar las acciones asociadas. El resultado es que cada 500 ms se publica el mensaje para avanzar hasta que se dispara la otra transición (T1). Esta transición también está asociada a otro temporizador (action_time), pero esta vez de 5 segundos. Transcurrido ese tiempo, el token se mueve al segundo lugar, donde se envía un mensaje que ordena a la tortuga girar cada 500 ms.

Para ejecutar esta tarea, debe realizar los siguientes pasos, que son muy similares para los ejemplos de ROS1 y ROS2:

Después de esto, debería ver a la tortuga moviéndose, ¡aunque no espere un cuadrado perfecto! :-)

Definición de mensajes personalizados

El tipo de mensajes que se pueden publicar o suscribir depende del middleware. Por ejemplo, en el caso de MQTT solo hay un tipo de mensaje (String), pero middlewares como ROS1, ROS2 y JIPC permiten definir mensajes que contienen diferentes tipos de datos. Para su proyecto personal, es posible que desee incluir los mensajes que los módulos intercambian con DGP. Estos mensajes deben definirse como clases Java que deben incluirse en paquetes Java. Dichos paquetes deben estar incluidos en el CLASSPATH al ejecutar el sistema. DGP lee la lista de estos paquetes desde los siguientes archivos de texto:

Puede utilizar los mensajes estándar incluidos en los entornos de desarrollo de ROS1 o ROS2 (consulte "Mensajes estándar" más abajo) o definir sus propios mensajes (consulte "Añadir mensajes personalizados" más abajo).

Mensajes estándar

Puede utilizar los mensajes estándar de ROS 1 (jros1messages) o ROS 2 (jros2messages) junto con los mensajes generales de ROS (jrosmessages), pero tenga en cuenta que DGP adopta un espacio de nombres de mensajes unificado para todos los middlewares soportados (ver más abajo). Para añadir estos paquetes de mensajes estándar, debe agregar el paquete al archivo de texto correspondiente:

Evidentemente, los paquetes Java de la lista deben encontrarse en el CLASSPATH de Java.

Añadir mensajes personalizados

La adición de mensajes personalizados depende del middleware que se vaya a utilizar. De manera general, se proporciona un proyecto de IntelliJ IDEA para cada middleware:

Debe seguir estos pasos para incluir sus mensajes personalizados:

  1. Añada sus mensajes personalizados al proyecto. Consulte el archivo readme.md dentro de ese proyecto.
  2. Se creará un archivo .jar en el directorio build/libs. Copie dicho archivo jar a un directorio que esté en el CLASSPATH. Por ejemplo, en ~/DGP/class si descomprimió el archivo GDGP.tar.gz en su carpeta personal.
  3. Añada el nombre del paquete de sus mensajes al archivo ~/DGP/res/modules.

En general, el formato de los mensajes depende del middleware:

Manejo de los mismos mensajes en diferentes middlewares

DGP adopta un espacio de nombres de mensajes unificado para todos los middlewares soportados. Los mensajes que representan el mismo tipo de datos pueden definirse en múltiples middlewares (por ejemplo, std_msgs/String en ROS1 y ROS2). La publicación de un mensaje provoca su propagación a todos los middlewares en los que ese mensaje esté definido; el mismo comportamiento se aplica a las suscripciones. For ejemplo, el mensaje robograph/roboGraph_dispatch_run_PN_message debe estar definido en cada middleware destinado a ordenar la ejecución de tareas a DGP dispatch. Este diseño simplifica la comunicación entre middlewares y la gestión de espacios de nombres. El aislamiento de mensajes específicos de un middleware se puede lograr organizando los mensajes bajo un paquete raíz con el nombre del middleware correspondiente.

PROBLEMA CON ROS2: Hemos detectado varios inconvenientes con la API de ROS2. Uno de ellos está relacionado con la publicación de una gran cantidad de mensajes sin un suscriptor activo. Esto implica que se debe tener especial cuidado cuando se defina el mismo tipo de mensaje en ROS2 y en otros middlewares.

Mensajes de DGP

DGP dispatch define sus propios mensajes. Por un lado, se suscribe a mensajes para:

Por otro lado, publica mensajes para:

La comunicación entre DGP dispatch y DGP GUI utiliza la mayoría de estos mensajes. Dado que no tiene sentido que se comuniquen a través de más de un middleware, cuando DGP GUI se inicia, si se definen varios middlewares, se seleccionará uno según el siguiente orden de preferencia: primero MQTT; si no está habilitado, se utilizará JIPC; si ninguno de estos está activo, se empleará ROS1; y finalmente, como último recurso, se usará ROS2.

PROBLEMA CON ROS2: Debido al problema de la API de ROS2 mencionado anteriormente, el módulo de mensajes ros2.robograph no debe incluirse en DGP/res/modulesROS2 a menos que este sea el único middleware activo.