ed and represented in models while robot-specific code is generated from these models using code generation. With a robot modelling framework, we can work on a higher abstraction level making the task of programming complex heterogeneous robots more efficient. In this paper, we present such a modelling framework and evaluate its flexibility by extending it with wireless communication functionalities.
Robots come in a variety of sizes and shapes and with different purposes and
abilities. In today’s society robots have revolutionized the efficiency and
productivity in many fields. The use of robots in the field of manufacturing cars has
increased the capacity and quality of the cars, in addition to protecting
workers from performing extremely dangerous tasks. In agriculture, drones are being
used to analyze soil and plant seeds and choosing the best moment to harvest.
Whether robots are used for bomb disposal or vacuum cleaning, their operation
depends on both their hardware and the software they are running [
Current robot programming frameworks require both a steep learning curve
and specific hardware and software environments. A large number of robotic
software exist but interoperation across robots is difficult, with dependencies on
specific hardware or software platforms that are hard-wired into the robot code
[
In this paper, we present a prototype framework CommonLang (CoL) which
uses MDSE-techniques [
Given a number of heterogeneous robots, each with its own programming language, the main feature of CoL is its ability to parse a common set of robot instructions into multiple tailor-made scripts to yield identical behaviour for the robots. The layout of the output scripts is dependent on XML configuration files that contain the implementation of the metamethods and specify what language they should be parsed to (e.g., C, Python, Java, etc.). In this paper, we demonstrate behavioural programming of two robots that use C/C++ and Python, respectively, as well as providing an evaluation of CoL’s ability to avoid increased complexity—keeping usability and ease of access at an acceptable level—when adding WiFi communication functionality by utilizing metamethods. 2
CommonLang (CoL)—which was first described in [
The aim of CoL is to enable reusable behavior for different robots with similar
abilities. To accomplish this goal, a textual DSL was defined using Xtext in
Eclipse [
Defining behavior in CoL consists of two steps: writing a CoL script and listing the collection of metamethods. The script is declared by the script keyword, the script name, then the target keyword, and finally the platforms to be targeted (see Fig. 2). The script is written in a file with the extension name .commonlang and consists of two main blocks. The first part contains the script definition, name of the script (MyScript), and a set of what robots the script will be generated for (LegoMindstormsEV3 and ArduinoShieldBot), in the form of configuration file names for each robot. Target platforms must include a specific configuration for each platform as many robot platforms allow the hardware to be configured differently as needed. Scripts may consist of variables, metamethod invocations, and some common control statements such as if, else, and while. The program code will be written inside a method called loop contained in the script block, and consists of user methods and metamethods. The output code, here parsed to Arduino (C/C++) and Python, will continuously iterate this method, hence it does not allow for storing states, like integers and booleans.
The second block is called metamethodcollection, which is a set of predefined methods that every robot with a different programming language is able to run and has its own implementation of. Each metamethod declaration consists of the reserved keyword meta, followed by a return type, name and its corresponding parameters. For example, the metamethod MoveForward may for some robots make two of the wheels spin forward, whereas for other robots may make four wheels spin at different speeds. Some robots may even be flying, meaning they will have rotors spinning in different directions to be able to fly forward.
For CoL to generate code for a robot’s native language, we need to declare
two XML files (see Fig. 3). The first XML file is generic for all robots of its
kind and contains various types of data, such as the file format for the language
files (e.g., .py or .c indicating Python or C files, respectively), global variables,
declarations and method calls for the setup method of the final script. It also
contains which metamethods the robot can execute. In this XML file, the
metamethods have a simple code segment, either calling its corresponding method
from the other XML file where it is implemented, or returning a value from
global variables or forwarding the return value from the method it is calling [
The other XML file is specific for the robot configuration and contains the implementation of the methods in the robots’ own language, for instance, setting a motor to run for the duration specified in the parameters or reading the value of a digital pin and returning it. These methods with their implementations are then automatically added without changes to the final output script which is already in the target language. Additionally, this XML file contains a tag called assignments for setting up robot sensors to the right pin values, since this configuration is robot-dependent. 2.2
As mentioned, the CoL grammar is defined in Xtext [
Once a valid CoL script (according to the grammar) is saved, all these classes gets instantiated automatically by the Xtext language-infrastructure. In addition, a code generator (which is a simple Java program as shown in Fig. 3) will be generated automatically for each CoL script. Running this Java program will create the final robot scripts for the target platforms. 10 CAPITALFIRST ) ’) ’ (’,’ ’(’ robottypes +=( LOWERFIRST | CAPITALFIRST ) ’,’ robotconfigs +=( LOWERFIRST | CAPITALFIRST ) 11 ’) ’)* ’{ ’( methods += UserMethod *) ’}’; 12 MetaMethods : 13 { MetaMethods } ’ metamethodscollection ’ ’{’( methods += MetaMethod )* ’} ’; 14 Block : 15 { Block } ’{’ (( exs += SimpleExpression ’;’ | exs += StructureExpression ))* ’}’; 16 SimpleExpression : 17 Crement | Call | Assignment | Return ; 18 StructureExpression : 19 Block | If | For | While ; 20 Expression : 21 SimpleExpression | StructureExpression ; 22 // ... 23 Method : 24 ( UserMethod | MetaMethod ); 25 MetaMethod : 26 ’meta ’ type = Methodtype name = CAPITALFIRST ’(’ parameters += Declaration ? (’,’+ parameters += Declaration )* ’) ’ ’; ’; 27 UserMethod : 28 type = Methodtype name = LOWERFIRST ’(’ parameters += Declaration ? (’,’+ parameters += Declaration )* ’) ’ bl = Block ;
Using the standard Xtext methodology, code-generation is divided into two steps. Firstly, an object model will be created for the parsed CoL script, then, target scripts in the native languages of the robots will be created using the customized code-generators. The complexity of these code generation steps depends on the complexity of the CoL script and the number of robot kinds which are defined in the targets block. These steps are hidden from the CoL script and metamethod developers.
Extending CoL with support for generating code to new target platforms require some knowledge of Java and Xtext. This consists of implementing a Java class for each new target language (however, C and Python covered all the robots which we have had in hand, e.g. Arduino robot, Lego Mindstorm, CrazyFlie mini-drones and Land-rovers with Raspberry PI 3). In the envisioned scenario, this activity is hidden from CoL script developers and delegated to DSL-infrastructure experts.
Configuring and developing metamethods are done in the XML files. Our optimal goal is to ship the DSL with a number of most-used metamethods for various commonly available robots. However, we see this activity as a community effort and envisage that the future of the DSL will be depending on the availability of this infrastructure. We have currently not defined any scheme or convention for the definition of these metamethods due to their simplicity, however, in future work we plan to define a guideline and a metamodel in form of an XML Schema Definition (XSD) for the configuration XML files. 3
In order to evaluate the DSL, we have extended its functionality by adding
features for WiFi communication using Message Queuing Telemetry Transport
(MQTT) [
MQTT is a lightweight messaging protocol that allows the robots to
subscribe to topics. They can also publish messages to the topics, so that clients
subscribed to a particular topic will receive the messages. A broker is required
for this setup to work. It keeps track of available topics and clients connected
to the server, forwarding incoming messages to all the clients subscribing the
respective topics. For a client to subscribe to a topic it needs only to know the
IP address of the broker. We have used the Eclipse Mosquitto [
An important decision had to be made regarding whether the communication should be integrated as part of the CoL grammar or as additional metamethods through the XML files. Editing the grammar of the language results in fewer unnecessary lines of code in the XML files. However, modifying the CoL grammar is more complex than making metamethods for it: the DSL is designed for handling metamethods specified in the robots’ XML files. It creates an environment for general purpose robot programming which could be compromised by adding grammar specifically for MQTT communication since with further development of the language other communication protocols may be desirable. By refraining from doing grammatical adjustments, it becomes quite manageable to add or edit already existing metamethods for communication.
A crucial part of integrating communication through metamethods is making the code intuitive and user-friendly, and at the same time not limiting what the end user is able to do. Various approaches to how the syntax and methods should look like have been considered. One of the approaches was to let the end user create a method surrounding a selection of metamethods. This user method would then be connected to a message string through a metamethod called OnMessage. This is how it would look like:
Listing 1.2. OnMessage metamethod 1 OnMessage (" go " , forwardAndLightsOn ); 2 3 void forwardAndLightsOn () { 4 MoveForward () ; 5 LightsOn () ; 6 }
This approach would result in more code to write. It would also require a change in the language’s grammar, allowing it to take a method as a parameter. After considering variations of similar syntax, we settled on utilizing the simplicity of metamethods combined with if statements, which are already part of the Commonlang grammar. The metamethod is called ReceiveMessage and takes a single string parameter, returning a boolean value. Here is an example:
Listing 1.3. ReceiveMessage metamethod 1 if ( ReceivedMessage (" go ")) { 2 MoveForward () ; 3 LightsOn () ; 4 }
The method is checking whether the robot has received a specific message. When the robots receive messages, the method triggers a callback called on_message that will put the messages in a list. This is because the callback method is hardcoded in the XML files and cannot be dynamically changed. Instead, this ReceivedMessage method was created to scan through the message list to check for the string from its parameter. If it finds it, a single instance of the message will be removed from the list and it will return true; otherwise false. 4
Robots can be programmed in different ways: from writing robot-specific code
directly to using frameworks with varying functionality. Some of these
frameworks, such as Papyrus-RT [
ROS is an open source project consisting of a collection of tools, libraries and
conventions that aims to simplify programming robust and complex behaviour
of robots of all shapes and sizes across a wide variety of platforms, whereas
Papyrus-RT is another framework for real-time programming of robots which
generates C++ code from models defined in the UML-RT modeling language.
RobotML is a DSL that aims at solving several central problems with robot
programming today [
We have presented CoL, a DSL for robot task specification which enables compilation of tasks to heterogeneous robot platforms. With CoL, one can do the time-consuming work of writing functions and setup once, then use these functions to define tasks for robot teams. The functions are developed as metamethods which extend what the users can express with CoL scripts. Since one could make any kind of metamethods, the functionality can vary greatly from a simpler move-forward function to highly abstract functions such as “water field” or “defuse bomb.” The defined functionality is contained within XML configuration files that are included in CoL scripts. This means one could make these robot-specific files beforehand and make documentation for them so that the CoL scripts can be written by less technical domain-experts to define heterogeneous robot behavior in various domains. These domains could be anything as long as the tasks in the CoL script can be achieved by robots for which the appropriate metamethods are implemented. The usability and extendability of CoL was demonstrated by adding support for wireless communication. The work done to add communications functionality to CoL was implemented through configuration files and metamethods; i.e., the DSL itself is not modified. This proved the potentials to add functionality to CoL with a library-like approach.
Future work would includes (i) expanding the available library of metamethods
to offer greater flexibility in how the user would like to use the DSL, possibly
dividing the metamethods into different collections with solid documentation.
This includes also guidelines and conventions for developing and documenting
metamethods. Testing and calibrating the robots was time consuming,
connecting via USB or SSH; transferring the script and then running the script when
the robot was in a semi-suitable location was not ideal. (ii) Implementing a
simulator could cut down on testing time, as well as being a solid tool for
evaluation. Moreover, (iii) implementing a modeling and reasoning functionality on
top of CoL to describe intended behavior of a team of robots—in the direction
of [