Why only a few people are able to create, control or use a robot? The answer is quite straightforward: because robotics is hard! But what is “robotics" and why it is hard for a person to get involved? Robotics can be seen as an mix of mechanical engineering, electrical engineering and computer science, joining forces towards creating and controlling (manually or autonomously) machines that interact with their environments. Thankfully for the roboticists, they do not have to excel in all of the aforementioned fields, since there are a number of open source and commercial middleware that enable a roboticist to create a controller easily, as well as an abundance of algorithms offered by the robotics community that can be easily plugged in a controller and operate effortlessly.

Nevertheless, since robots evade our everyday lives, a time will come when people with no technical background will need to operate such complex machines. One way to perform such task, without forcing everyone to be a developer, is to use intuitive graphical languages in order to easily create robotic applications.

One of the methodologies used for creating quickly error-less and of high quality Software is Model Driven Engineering, or MDE. MDE is based on models and transformations, in order to allow the software designer to focus to the actual application he/she is trying to implement and not in the implementation details (e.g. programming APIs). Since the transformation of the models to the code is automated, the quality of the results does not depend on human factors.

The goals of the Nao4All platform is to apply the MDE methodology on creating applications for the NAO robot. Specifically, Nao4All attempts to:

• Provide to people with no technical background an easy and fast way to correctly design and implement robotic applications
• Significantly increase the success rate of developing correct robotic applications for NAO robot
• Allow for easy and fast modification of already created robotic applications created with the current tool, in order for their maintenance to be cheap, in terms of time and money

The core concepts of MDE methodology are the model and meta-model. A model is a simplified representation of a system or object, which maintains the necessary aspects towards analysing it for a specific purpose. The meta-model on the other hand, is the set of symbols/concepts, as well as their restrictions, allowed to be used during the designing of a valid model. Therefore, a meta-model fully defines the set of valid models, which usually are arithmetically infinite, by defining how its concepts can be combined correctly. In Nao4All these concepts include the actions we desire to be included in an application/model for NAO, which will be designed with the Nao4All tool.

In order to design such a meta-model, the collaboration of at least two specialists is required, one that is proficient in the modeling domain and another that specializes in the domain that will be modeled (robotics in our case). The following image depicts the R4A-NAO meta-model which is the basis of Nao4All platform. The parent element is the application “NaoApp", which can include at least three high level activities (HLActivity), being the Start, Finish and at least one more activity, in order for an application to be meaningful.

The meta-models structural concepts are Start, the single point of application initiation, Finish, the single point of an application termination, Activity Group which groups HLActivities that will be deployed in parallel, GroupStart – GroupFinish which denote the initiation and termination of an Activity Group, Fork/Join, being the elements that initiate and terminate the parallelism of multiple Activity Groups. The core concepts include the modeling of motions, such as HeadMotion, BodyMotion, BodyStance and Learn/Replay-motion, the modeling of events detection, such as DetectTouch, DetectHuman, DetectMotion and DetectSound, the modeling of Human-Robot-Interaction, such as Listen (command), RecordSound, ReplaySound and Talk.

Apart from the core structural concepts, R4A-NAO contains elements that define their interconnectivity. Specifically, any HLActivity can end up to several other HLActivities via the Transition concept. Furthermore, special transitions exist, such as OnDetectTransition and OnNotDetectTransition for transition-related HLActivities, OnListenTransition for the Listen HLActivity and OnPreemptTransition that can preempt an Activity Group on predefined conditions.

Apart from the modeling part, a domain specialist must exist, in order to define best practices and restrictions on the actions described in the meta-model. As far as restrictions are concerned, two categories exist. The first concerns the structural restrictions that define which is the allowed structure of a generated model (e.g. in R4A-NAO a sentence lexicon can only be associated with Listen). The second concerns the behavioral restrictions that are derived from the experience of the domain specialist. For example an experienced roboticist knows that if NAO moves, simultaneously detecting sound is meaningless, since its motors produce sound, thus the detection will always be True.

In the R4A-NAO meta-model the restictions have been introduced using the AQL (Acceleo Query Language). The following example describes one of the parallelism restrictions incporporated in the language, which does not allow concurrent motion commands.

For any ActivityGroup of a Fork activity, for each HLActivity of this ActivityGroup, if the HLActivity is BodyMotion, it is implied that any onther HLActivity, for any ActivityGroup of this Fork, apart from the HLActivities of the current ActivityGroup, does not contain any HLActivity of types BodyMotion, BodyStance or ReplayMotion

In the MDE context, a transformation is a systematic and (usually) fully automated procedure, during which a model is transformed to another. As evident in the following image, for each transformation, declarative programming is used, in order to define how to transform each concept of the source-model to one or more concepts of the target-model.

In the special case where the target-model is a programming language, the transformation is called M2T (Model-2-Text transformation). For R4A-NAO, the M2T takes as input valid models created using a graphical tool and outputs Python code, capable of interacting with the NAO robot. This M2T was developed using the Acceleo language, and comprises of several Acceleo Templates. In the following figure, an example of an Acceleo Template is evident, which iterates over all HLActivities.

The Nao4All platform exposes the aforementioned meta-model to each users by means of a graphical language that allows for easier and faster creation of robotic applications, even from non-specialists or non-technical persons. The utilization of such graphical languages offer several advantages over textual languages, such as a) the easier comprehension of each activity, without requiring a lot of training time, since icons can be indicative of their implementation and b) the presentation of an application in imagery form allows for quicker inspection and/or debugging.

The graphical tool comprises of a canvas and a toolbar containing the NAO behaviors and transitions:

An example of a simple, serial application, is evident in the following image, where NAO speaks, moves forwards and then the application terminates.

It should be stated that the designed application can be validated, so as the final generated code is always correct. Bellow, the error reporting can be seen:

The next figure, presents an example of implemented loops and forks, depending on whether a human is detected or not.

Of course, as stated before, parallelism is supported, as evident in the next example. Here, a random head motion is performed in the first thread, while at the second thread NAO detects humans for 10 seconds. In either case (detected or not detected), the second thread preemts the first one (which included an endless loop), in order for the application to finish.

In order to evaluate the usefulness and usability of the Nao4All tool, as well as the value of the MDE methodology in the robotics field, several hackathons were organized. There, a brief training for the tool was performed (usually 0.5 to 1 hour), followed by 3 tasks of increasing difficulty (a serial application, a threaded application, an application that contained preemptions), where 0.5 hours were given for each of them. Each participant was allowed to try only once to model the desired application.

Hackathon 1 – Students of School of Electrical and Computer Engineering – Live training: Fourty seven (47) students participated, from which 91.30% perfectly solved the first task, 95.74% the second and 84.78% the third.

Hackathon 2 – Students of School of Electrical and Computer Engineering – Online: Twenty seven (27) student participated, with no training (just by using an online tutorial of the tool). From the 81.48% managed to perfectly solve all three tasks.

Hackathon 3 – Primary School teachers: Four primary school teachers participated, aiming at checking whether this tool can be used by primary school children.

Hackathon 4 – Primary School students: Thirty one (31) students participated (fourth and sixth grade), from which 80.00% perfectly solved the first task (and another 13.33% had up to two minor errors), 36.67% perfecty solved the second task (56.67% had up to two minor errors) and 8.70% perfectly solved the third task (13.04% had up to two minor errors). In this case however, some UI quirks and non-decent English language knowledge affected the capability of the users to model the most complex application.

Conclusively, the Nao4All platform is indeed 4All, since it allowed over 100 people with moderate, minimal or non robotics/technical training to program a NAO robot. Even more importantly, the generated applications were correct by design, essentially protecting the HW (NAO) from damages. It is worth mentioning that the code development for the aforementioned tasks, even from a robotics professional can span from hours to days, fact that showcases the usefulness of the MDE practices in the robotics domain.