©2018 by Effectively Specifying Multi-Robot Missions. Proudly created with Wix.com

In this page, we present an online platform that contains a set of software packages, including PROMISE (simPle RObot MIssion SpEcification), our DSL: a multi-robot mission specifier. With our research, we aim at providing an easy (i.e. conceived to be used by non-technical users) yet powerful tool to specify, generate, and decompose missions for robotic teams.

PROMISE was developed to support both developers—i.e. users with technical knowledge who may use our DSL for a possible project development—and non-technical end users—i.e. users that do not necessarily have technical knowledge—in mission specifications. Our DSL supports the specification of complex missions via the use of some operators that permit the composition of tasks. These operators are inspired by Behaviour Trees (BTs), which are used in computer science, robotics, control systems and video games for structuring and model behaviors directed toward achieving goals. 

Our software platform implements a list of packages, starting from an Eclipse workspace. The contains are provided and explained in the provided Github repository.

We also provide an implementation to test our work using either real robots or via simulation. The two developed components are explained in the section ROS implementation.




An easy way of manage multi-robot missions!

The purpose of the DSL is to provide a proper language, supported by a tool to define complex missions for multi-robots. The DSL enables the specification of missions for multi-robot; missions have alternatives according to events that may happen during the mission execution. For instance, a mission specification should include possible reconfigurations in the case of events that can be both internal to the system, e.g., “out of battery,” or external, e.g., “human in the room.” In the following, we go through some terms that help to understand our research.

The DSL builds on a catalog of mission specification patterns for mobile robots. This pattern catalog provides a set of building blocks that support developers in mission specification. Each pattern can be used to describe simple tasks that a single robot should perform.



So we use operators, but, what are them? In this section we introduce the semantics of all our operators.


Our DSL was developed as a stand-alone application, here we explain how we did it!


Here we introduce an example in detail to clarify the implementation and usage of our DSL.


The current implementation of our DSL is built upon a software unit of an existing software architecture (SERA). SERA is composed of two units: 1) the Central Station, where global missions are defined, generated, and decomposed into local missions; 2) the Robot unit, which represents the logic and control software components allocated in each robot. The DSL is allocated in the Central Station unit, allowing an easy yet powerful way of defining missions and their decomposition. In order to implement our research upon an existing framework, we developed instantiations of the SERA’s components of Communication & collaboration manager and Local mission manager (both of them were implemented in Python).

The current implementation of the software components works with the Robot Operating System (ROS) framework.



This software component serves as a proxy between the Service-Oriented Architecture paradigm of communication that we use for the communication between the DSL or central unit and each robot and the ROS environment. The ROS environment represents the framework that contains and manages the software allocated within each robot. The Communication and collaboration manager receives the information from the Central Station and forwards the mission tree to the Local mission manager.


The Local mission manager encapsulates a high-level orchestrator—the component that coordinates the interaction among different components—for the mission tree within each robot. The orchestrator is the component in charge of reading the lines of the mission tree, parse them and delegate its execution to the mid- and low-level components of the architecture. The former components give feedback to the local mission manager concerning the status of the mission (whether it was successful or not) and events in the environment (e.g. there is a human requesting help, should I help him?). The orchestrator collects all this information and decides the next steps to be taken based on it.


The Github repository is available here.

This site was designed with the
website builder. Create your website today.
Start Now