RoboGraph
Overview
Most of the mobile robot control frameworks are based on a middleware layer with several independent modules that implement primitive actions and report events about their state. These modules are usually connected with different inter- process communication mechanisms. RoboGraph uses hierarchical interpreted binary Petri nets to coordinate the activity of these modules. Tasks are described using an interpreted Petri net editor and saved in a xml file. A dispatcher loads these files and executes the different Petri nets under user requests. A monitor that shows the state of all the running nets is very useful for debugging and tracing purposes
Petri nets are a powerful tool to model, design and analyze distributed, sequential and concurrent systems. This provides several advantages building mobile robot applications:
- Module reusability. Navigation modules and even some application specific modules will remain unchanged from application to application.
- Reduce development time. In different projects of the same kind of applications, most of the modules remain without changes and only the edition of the Petri nets will be necessary to personalize the application. For example, different robot museum projects can be built with the same modules changing in the Petri nets the points to visit, the texts to say and some other minor changes.
- Facilitate maintenance. Tracing and debugging problems are easier to settle when the system state can be seen looking at the evolution of a Petri net that monitoring a set of variables.
- Training. Almost everybody that has worked or learn to use IEC 61131-3 compliant programming environments (Siemens S7 Graph, Graphcet, etc) will be able to program with our tool RoboGraph.
- Analysis and test. Petri net properties also make them good candidates for qualitative (un-timed models) performance evaluation and quantitative (timed models) performance evaluation of robotic tasks. Significant research has been done in this area for industrial applications and also some in mobile robots tasks.
RoboGraph is applied to program task in two different levels as shown in next figure. On the IPC level the Petri nets that represent the different tasks include commands (message publication) and events (message reception) for the modules connected to CENTRAL. On the JIPC level, the Petri nets that represent the different tasks include commands (message publication) and events (message reception) for the modules connected to JCENTRAL.
Robograph includes two different programs. The GUI (Graphical User Inteface) is a development kit that will allow us to create, edit and monitor the execution of the different tasks while the Dispatch is in charge of executing those tasks.
GUI
RoboGraph GUI can work in three different modes and it is possible to switch at any time from one to another: Editor, Monitor and Play Logger.
In editor mode, the user can create new tasks using a simple and intuitive Petri net graphical editor. Once the Petri net is constructed by selecting and dragging different elements (Places, Transitions, Arcs and Marks), actions, associated to Places and Transitions, and conditions, associated to transitions, must be defined for the interpreted Petri net.
Actions can be commands implemented in any module in the control architecture of figure 1. These commands can be selected from a list automatically generated by the GUI. Each command is an IPC message and the user must define the command parameters that will automatically appear in a new window when that command is selected in the editor.
When Dispatch executes the Petri net, the IPC messages assigned to places and transitions will be published as the net progress.
Conditions can be events produced by any module in figure 1 that can be selected from a list generated automatically by the GUI. An event can be the arrival of an IPC message, a condition on some IPC message parameter or any logical expression on several parameters over the same or different IPC messages.
Timers are a tool widely used in automation that comes very handy here. In addition, in our applications we have also used them as an error detection mechanism in order to time some actions of different modules in case they get stuck. Actions can start a timer while conditions can test the value of a timer.
Global variables are used to get starting data and store information to share conditions and events in different places and/or transitions. Next figures shows the main window of RoboGraph GUI in editor mode.
This videos shows one example of creating a tour guide task (Petri net). The robot should visit several points and show the points to users. The Petri net uses another Petri net go_to_point.
GUI in monitor mode connects to central (IPC) and subscribes to different dispatch messages that show the status of the different running or waiting Petri nets. Every running Petri nets is shown in a different tab with the actual marking. When dispatch evolves a Petri net marking, an IPC message is issued and GUI will update the monitor tabs. Therefore, using monitor we can see in a snapshot the status of the system, since the marking of the running Petri nets represents their status. This is a very helpful tool when debugging an application. An information window with the queued tasks (Petri nets) can also be displayed.
Mobile robots operating in the real world can fail for many reasons because it is almost impossible for the programmer to predict all the circumstances that might be encountered. In order to be able to trace different problems, an XML log file with Dispatch IPC messages is created in running time. The system administrator can then run GUI in play-logger mode, open the log file and play it at the same pace as in the real execution. Different tabs with the running Petri nets will be shown as in monitor mode. Besides the regular play option, the user can monitor the log file step by step, jump to a defined place in execution as many commercial programming development environments for high level languages (C, Java, C++, etc.). Finally, the user can see different details about the IPC messages.
Dispatch
Dispatch schedules the different actions of the functional (basic actions), executive (other Petri nets) and interface layer (user and web interfaces), as well as the synchronization with the events produced. The interaction with other modules in the architecture is performed by publishing and subscribing to messages. This way, problems on a module, such as a deadlock problem, do not block dispatch and we can set up simple mechanisms to detect and recover from a failure or exception situation.
When starting, dispatch subscribes to the task execution or cancellation requests. Every requested message has an owner, priority and execution mode (serial or parallel). Priority and owner define the execution priority and the ability to kill or stop a task. Execution requests that cannot be executed at the reception time, they are stored in different queues according to their priority. A task execution request can come from different modules (figure 1), such as user interface modules (user requests) or even the RoboGraph dispatch when the task is an action associated to some running Petri net.
The execution of a new task starts loading the interpreted Petri net from a XML file, setting the initial marking, subscribing to all the IPC messages referenced in the events and executing the actions associated to the marked places. The Petri net can progress only with the arrival of IPC messages or the end of a timer.
Each time a change in the status of a Petri net (start, stop, evolve) or in the waiting queues (new requests added or removed) is produced, a new IPC message reporting that change is issued for GUI monitor mode and stored in the log file for GUI play-logger mode.
RoboGraph has interfaces for IPC and JIPC communication system but it can be easily extended to modular architectures with other communication systems.
On this video you can see a simple example using CARMEN modules to program a simple tour application.
If you are interested in only one part of the example, you can see:
- Video defining the example: RoboGraph Example
- Video programming one of the Petri nets using RoboGraph in editor mode: RoboGraph Programming
Publications
Title: Using hierarchical binary Petri nets to build robust mobile robot applications: RoboGraph.
Authors: Joaquín L. Fernández, Rafael S. Dominguez, Enrique Paz Domonte and Carlos Alonso
Congress: IEEE International Conference on Robotics and Automations ICRA2008
Publication: Proceedings of ICRA 2008 pp:1372-1377
Place: Pasadena CA USA
Year: 2008
ISBN: 978-1-4244-1647-9
ISSN: 1050-4729
Title: Especificación y modelado de tareas de alto nivel para robots móviles. Aplicación a la interpretación de órdenes vocales.
Authors: Joaquín L. Fernández, Rafael Sanz, Pablo M. Barbosa, Amador R. Diéguez
Congress: XXVIII Jornadas de Automática 2007
Publication: Proceedings of Jornadas de Automática.
Place: Huelva, Spain, 5 to 7 September 2007
Year: 2007
ISBN: 978-84-690-7497-8