Towards a Deep, Domain-speci c Modeling Framework for Robot Applications

Abstract

In the future, robots will play an increasingly important role in many areas of human society from domestic housekeeping and geriatric care to manufacturing and running businesses. To best exploit these new opportunities, and allow third party developers to create new robot applications in as simple and e cient a manner as possible, new user-friendly approaches for describing desired robot behavior need to be supported. This paper introduces a prototype domain-speci c modeling framework designed to support the quick, simple and reliable creation of control software for standard robot platforms. To provide the best mix of general purpose and domain-speci c language features the framework leverages the deep modeling paradigm and accommodates the execution phases as well as design phases of a robot application's lifecycle.

Keywords

• Deep modeling
• ontological classi cation
• linguistic classi cation
• domain-speci c languages

1 Introduction

As robots become more ubiquitous and embedded in our environment there is a need to simplify the creation of software systems to control them. Today this is a highly specialized and time-consuming task, involving the laborious handcrafting of new applications using low-level programming techniques. However, as more quasi-standard robot platforms emerge (such as the NAO [ 2 ], Turtlebot [ 19 ] and Lego Mindstorm [ 21 ] platforms on the hardware side and the Robot Operating System (ROS) [ 17 ] on the software side), the development of robot applications should become easier and more accessible. This, in turn, should encourage the emergence of communities of \robot app" developers o ering robot-controlling software on open marketplaces similar to those for smartphone apps today.

Several important developments in software engineering environments need to take place before this vision can become a reality, however. First, a small number of truly ubiquitous \standard" robot platforms need to emerge, supported by rich software frameworks. Such frameworks need to include a lean, e cient execution platform, a rich library of prede ned routines and a clean, general-purpose programming/modeling language for applying them. Second, these general-purpose language features need to be augmented with domainspeci c modeling capabilities that allow developers to describe their programs using concepts and notations that t their application domain. Ideally, these languages should be synergistic. Finally, the information represented in these languages should seamlessly accommodate all phases of an application's life cycle, from design and implementation to installation and operation. This in turn, requires, information modeling techniques that can seamlessly represent multiple levels of classi cation.

The modeling approach that o ers the most intuitive, exible and yet stable way of supporting such a software engineering environment is the deep (or multi-level) modeling approach [ 7 ]. This has been designed from the ground up to support the uniform and level-agnostic representation of domain concepts at multiple abstraction levels, and makes it possible for them to be visualized in both domain-speci c and general purpose notations interchangeably. For the purpose of developing robot applications, therefore, what is needed is a prede ned framework of robot-control model elements (i.e types and instances) carefully arranged among the multiple classi cation levels within a deep modeling environment, each represented by appropriate domain-speci c symbols. Each level in such a multi-level framework can be regarded as a language in its own right, and where appropriate we will use this term. However, we prefer to use the term \framework" to refer to the whole multi-level ensemble of models. In this paper, we present an early version of a deep modeling framework for robot applications. Developers wishing to create their own robot applications can take this framework and extend/customize the types and objects within it to their own needs. The term \framework" is therefore used in the sense of previous reusable environments such as the San Francisco Framework [ 11 ] etc. However, our framework supports more powerful and exible extension mechanisms.

The remainder of this paper is structured as follows. In the next section, Section 2, we provide a brief overview of deep modeling and the main concepts that are needed to support it. In Section 3, we then provide an overview of the proposed deep robot modeling framework, and the di erent levels of classi cation that it embodies. In particular, we elaborate on the role and nature of each of the four individual ontological classi cation levels within the framework and discuss the kinds of model elements that they contain. In Section 4, we brie y discuss the main related work and in Section 5 we conclude with some nal remarks. 2

Deep Modeling

Deep modeling involves the creation of models spanning multiple classi cation levels. One of the most well known modeling architectures supporting this approach is the orthogonal classi cation architecture (OCA) [ 7 ] which distinguishes two fundamental types of classi cation | linguistic classi cation, de ning which construct in the underlying modeling language a model element is an instance of and ontological classi cation de ning which domain concept in the problem domain a model element is an instance of. By arranging these di erent kinds of classi cation into two separate, orthogonal dimensions, the OCA manages to provide the exibility of multiple (i.e. more than two) classi cation levels whilst retaining the bene ts of strict modeling. In contrast, state-of-the-art metamodeling approaches allow only one pair of class/instance levels to be modeled at a time (e.g. an M2 meta-model which is then instantiated by an M1 model). These are therefore commonly characterized as two-level modeling technologies and generally mix linguistic and ontological classi cation in one dimension.

One important consequence of multi-level modeling is that elements in the middle levels are usually classes and objects at the same time - that is, they usually have both a type facet and an instance facet. To accommodate this, deep models are usually constructed from so called \clabjects" that have an inherent type/instance duality. To support deep instantiation | the instantiation of model elements across multiple classi cation levels | each clabject has a non-negative Integer attribute called potency that captures its \typeness". The potency speci es over how many consecutive levels a clabject can be instantiated. Attributes and their values also have a potency. The potency of an attribute (also known as its durability) speci es over how many instantiation steps an attribute can endure (i.e. be passed to instances). On the other hand, the potency of an attribute's value (also known as its mutability) de nes over how many levels that value can be changed. The values for all three kinds of potency can be either a non negative integer or \*" representing in nity. When instantiating a clabject, the potency of the clabject and the durability and mutability of its attributes are reduced by one. When instantiating a clabject with \*" potency, the potency of the instance can be \*" again or a non-negative integer. Clabjects with a potency of zero cannot be further instantiated, attributes with a durability of zero are not passed on to instances of the containing clabjects and a mutability of zero rules out any further changes to the value of an attribute.

Figure 1 gives a schematic illustration of how models are represented in the OCA [ 7 ]. There are always three linguistic levels, L2 - L0, where the top most level, L2, represents the Pan-level Model (PLM) which is the single, overarching linguistic (meta) model describing the abstract syntax of the deep modeling methodology. The middle level, L1, contains the domain model content created by users, and L0, represents the real world representation of the modeled content in the sense of the \Four-Layer Metamodel Hierarchy" in the UML [ 18 ]. The levels O0 - O2, rendered in the Level-agnostic Modeling Language (LML) [ 8 ], are the ontological classi cation levels which exist within the L1 linguistic level and are therefore orthogonal to it. This model shows only three ontological levels for space reasons, the maximum number of ontological levels depends on the modeled problem domain and is unlimited. In this gure, linguistic classi cation is represented by vertically dashed arrows while ontological classi cation is represented by horizontally dotted lines. However in a real-world model these two representations of classi cation are usually not used for two reasons. Firstly, the linguistic model is not displayed since the linguistic classi cation information is already captured by the symbol used to represent model elements. Secondly, representing classi cation by means of edges clutters diagrams and introduces unnecessary visual complexity. Hence, ontological classi cation is usually shown using the colon notation as in Figure 1. Deep instantiation is captured by means of the potency value attached to clabjects which in the LML is represented as a superscript to the right of a clabject's name. L 1 L 0

O0

Clabject O1

The example in Figure 1 shows how the clabjects in a robot application would be arranged in the deep robot modeling framework presented in the following sections. On the highest (i.e. most abstract) ontological level 00, the concept of a RobotType is introduced. Speci c robot types, such as the NAO robot type from Aldebaran Robotics [ 2 ] are modeled as instances of RobotType at the next level of abstraction O1. The clabject NAO is thus an ontological instance of RobotType and at the same time a type for robot instances in the following levels. The most concrete ontological level in Figure 1, O2, contains speci c robot individuals, such as a robot called Naomi , which is an ontological instance of NAO. Notice that each clabject's potency, represented as superscript after the clabject's name, is always one less than that of its ontological type resulting in a speci c robot at O2 which cannot be further instantiated since it has a potency of 0 . All model elements are also indicated as being an instance of Clabject which de nes their linguistic type. Other linguistic types such as generalization or attribute are also available but are not shown in this small schematic illustration. The bottom linguistic level, L0, contains the real world entities that are actually represented by the clabjects in L0. Note that Naomi is a physical object, while NAO and RobotType are conceptual entities (i.e. types) in the domain. 3

Deep Robot Modeling Framework

The overall structure of the proposed Deep Robot Modeling Framework (DRMF) is presented in Figure 2 which essentially shows the L1 linguistic level of the framework, but rotated anti-clockwise relative to Figure 1 and, thus, represented vertically rather than horizontally. The framework is composed of four ontological levels with the most abstract level O0, depicted at the top and the most concrete, O3, depicted at the bottom. The di erent levels of the model de ne languages which are used for di erent purposes. Their purposes are explained in their own dedicated subsections in the following.

The prototype realization of the framework has been implemented using the Melanee [ 4 ] deep modeling framework under development at the University of Mannheim. It is therefore based on the linguistic L2 model of Melanee which is an EMF implementation of the PLM. The PLM is the vertical linguistic level on the left hand, spanning all ontological levels in the center. Similarly, the \real

dRobeToFytlpToyewlJpNARTeipay,mppnoeestkeRxJegBcutgeRs MAPTSAlyappctleftoiNtirLLTaomTmynyNpeapTR:emaT=eyNe:RpR,p:a=eomRs:,ntVeP*JPgu:JsePsgI;uPtnyVapmaenertaaiyampbeel:Pegn}TaPJymtpyeepee,ATypes pTPoyopstMestxyTuJJNh}}tRrytTBAAoeeaIIRupinnmyt}emevAAarpttPNesee}eeeeo==}IggPat:NsOOAnAI=eexOmAtnatu=rr:}}etme}PregPAA:eApeg=xescoco:ecPr:=ttsrt;PiJJityi:oomuoAAPB=nrnrnoePAAeTTvPTyse==yyPtpybPPp;poptseheeteu?trae=PothJeAtaO=TJbxyABAtpPsuAeitPNs=aAeyacAmscPlPtieePi=:oD=zPn:ePdOktntoeyaebMpbtmsceets:eatc=t:cit=aol:OeP:cn_Pbblddo:OgRese}ettDAtlaspeeeopocccaecltsesnltitFittuetexoiPoecedln;RoncPcPepuwTtsteiudyoEfsdpunellTe:OesO}immVReaeOerniatbkleTMlyppRoeist nJA=LSFAplRciSgCAoteknpANioNpVpdl}neiDietSttdotwtkOAArniiintto}}A}igiSSSrootkpprnnRilinilkkAAottgTTb}}yySoSLppptpk:eell}iittRTToyyabppoeetTJAyp=XneXAOCcRCooOAnond}nidgtSdoiptnilti}iotiSTotnrynianupag:PPpleRl}woSsPespOhptpliirlltieeOAat*tk:}i}PStScipopolilnntigtTdOATyi}typiSpoepJenAlPite=IT{XAyPpe

RoNax=o,m;by=i:V*MSR?o;{otVhveSAetRag=?rtk_eSSevR_AzSR{I BtrupeDeoebRtsteacchlte?ADBeOtebcastetdaMcvlefalseiVusoDesoisbasgrtarceleeADetecMtedP}Pboooleadnel

SitRelax d l r o W A l a e

R BehaNax=o,m;RvyS=iV:V*VMSpRR?mio;{St;VVhv:OoesSAeutpRagcm=?re;k_e:sSsSrevuR_czSeRs A{ItruEpeDoRebnBStsVteaOccpltem?ADa;EeO:tseubccstectedMasclet mVusesobsetaclevDnaeluteec=ttetrduPeA}PbooMlean odel

RSSV,iptmR;e:sluacxes

E L + L l e d o m X a t e M A c i t s i u g n i L

OE V M LPO3 p O3 3

L world", L0 , containing the ob jects and concepts in the real world (in this case the rob ot application) is a vertical linguistic level on the right hand side.

Since the whole framework is based on Melanee, the framework is able to o er some advanced mo deling concepts which are only partially supp orted, if at all, by other comparable mo deling infrastructures and environments. The rst is the supp ort for symbiotic general-purp ose and domain-sp eci c languages. This feature is made p ossible b ecause Melanee allows domain-sp eci c symb ols to b e asso ciated with clab jects directly within the ontological levels. The option of rendering clab jects in one or more domain-sp eci c ways is therefore always additional to the option of rendering clab jects in the general purp ose LML notation which is Melanee's built in concrete syntax for clab jects. When cho osing how a clab ject should b e rendered, therefore, users are able to switch b etween all the de ned domain-sp eci c symb ols or the built-in LML symb ol at the click of a button. The Melanee rendering mechanism is fully re exive, which means that when lo oking for a symb ol to render a clab ject, Melanee searches up the hierarchy of sup ertyp es and (ontological) typ es of the clab ject to b e rendered, lo oking for the closest asso ciated symb ol. As a last resort, if no domain-sp eci c symb ol has b een found, the built in LML notation is used. The rendering algorithm also supp orts concepts of asp ect-orient mo deling. Join p oints can b e de ned in visualizers for which asp ects can then b e provided in other visualizers. The visualizer search algorithm then merges asp ects into join p oints when working out which symb ol to use for a clab jet. The domain-sp eci c mo deling language features are used to provide a standard graphical and textual representation at the Rob ot Mo deling Language Typ es level (O0 ) which can then b e further re ned by asp ects provided at lower levels of abstraction e.g. the Rob ot Mo deling Language (O1 ), the Rob ot Behavior Mo del (O2 ) or the Behavior Enactment Mo del (O3 ).

The second advanced mo deling feature is the uniform and balanced supp ort for textual as well as graphical visualization of clab jects. This is made p ossible by Melanee's supp ort for full pro jective editing [ 5 ], which means that all visualizations, whether textual or graphical are derived by projecting the underlying model content into a particular representational form by selecting a particular set of visualizers. This is a very powerful feature because it means that the same underlying model can be viewed and edited in a graphical way (using graphical visualizers) and in a textual way (using textual visualizers) depending on the skills and goals of the stakeholder concerned. Moreover, each visualization is generated on the y, when needed, so that changes to the model input through one view are automatically updated in all other open views. The textual visualization of the model content is particularly important since it allows the DRMF to interact with existing text-driven technologies. In general, any textual output can be generated, be it code in a high-level programming language like Java or C++ (as in our implementation), XML, JSON or any general-purpose language (e.g. python, perl, LUA, bash) or specialized scripting language (e.g. Urbi script [ 9 ]). By having textual representations of the model, users can apply any kind of algorithm to a model, run it on the robot or load it into other tools.

The third advanced modeling feature supported by Melanee is the ability to model equally and uniformly at all ontological classi cation levels, with changes at one level immediately impacting all other dependent levels. This makes it possible for modelers to dynamically customize (on-the- y) the di erent languages provided by the DRMF to their speci c needs. Hence, new types and default renderings can be introduced at the RMLT level or new features to model new behaviors can be introduced into the RML. An emendation service [ 6 ] is provided to help users handle the impact of model changes at any level. This service scans the whole model for model elements which are impacted by a change and suggests automatic amendments to ensure that all the classi cation relationships valid before the change remain valid.

O0 | Robot Modeling Language Types (RMLT)

The Robot Modeling Language Types (RMLT) model de nes the general concepts needed to create a robot programing language based on a state transition system. More speci cally, it de nes the types that can make up a robot and general algorithm description concepts such as ActionType or VariableType.

O0

PartType3 has

utilizes * *

An excerpt of the RMLT is shown in Figure 3. It provides four basic types: PartType, RobotType, VariableType and FlowType which is specialized by the sub

TypeName JB

JA executionTime;successful FlowType0 1 post executionTime4 successful4

RobotType3 executes ActionType3

* TypeName444=14

PlatformName444=14 1 * cflow 1 post JD

1 1 ControlFlowType3

TypeName'('4JE44');' uses VariableType3 * type name

JC name':'type type4name classes ActionType and ControlFlowType. The central model element is RobotType which is a type for representing a speci c kind of robot and its behavior. The left hand side of the RobotType provides types for describing its structure (i.e. PartType). This is needed as some Robots do not have a static structure but can be changed depending on the task they are required to perform. The right hand side of RobotType de nes types for the set of actions that a robot can execute (i.e the behavior). The underlying idea is that a program consists of a set of actions and control ow statements. Similar to the parts of a robot, the blocks of the program are attached to a robot. Each ActionType can be connected to another ActionType facilitating the creation of sequences of action types. Furthermore, an ActionType allows instances to use a variable for reading or storing information. ActionTypes represent all types of actions that a robot can perform ranging from sensing, waiting for events to actions like moving an arm. In addition to the ActionType, a ControlFlowType is provided representing the the execution order of actions (e.g. parallel execution and repetition). Default textual and graphical renderings are provided by the RMLT which are represented schematically by the clouds in the example. Points for extending these are o ered by join points (represented by the grey Js in Figure 3). The RMLT can also be extended with new types by leveraging the full power of the deep modeling approach. 3.2

O1 | Robot Modeling Language (RML)

The Robot Modeling Language (RML), at level O1, de nes the set of actions which can be used to de ne applications for a robot. This level allows language engineers to de ne types needed to build robotic applications and to solve particular tasks. The RML can then be used by an end-user to build robotic applications at level O2. To de ne a language that can be used by an end user the types of the RMLT need to be instantiated. These instantiations include a robot with such information as connection parameters (e.g. IP attributes) and if necessary the parts that are available for modifying the robot. Additionally the action and ow control elements available in the RML are instantiated from the FlowType subclasses provided by the RMLT . An executable textual de nition and graphical renderings can be de ned by a language engineer for the robot speci c actions and control elements. For this task the renderings provided by the RMLT can be modi ed by providing aspects or by de ning completely new renderings. Using the RMLT , di erent languages can be de ned to create applications for di erent kinds of robots such as humanoid robots, industrial robots and vacuum cleaners etc. The RML can be either created for a speci c robot or for a family of robots. When de ning a language for a family of robots speci c implementation types are provided by subclassing more general model elements.

Figure 4 shows a RML de ned specially for the NAO robot type. In general, the RML contains a family of types for each kind of robot. However, in Figure 4 we have shown a NAO example model for space reasons. Because the NAO robot's body structure is xed and cannot be modi ed the details of the robot and its parts are left out. A NetworkRobot, representing the concept of a NAO robot running over a network is instantiated from RobotType with an additional String attribute for storing its IP. Actions for the NAO which are instantiated FlowElement{ post seuxcecceustsiofunlTfimef } ControlFlow{

Repetition{+:ControlFlowType Condition{+:ControlFlowType condition:String

Split{+:ControlFlowType from ActionType include default operations provided by the API (e.g. Move), custom implementations (e.g. Posture) and actions for sensing and reacting on events (e.g. DetectRedBall ). The commonly known concepts for control ow (e.g. XOR, Repetition) are instantiated from ControlFlowType. The graphical and textual renderings are adapted by providing aspects for join points which is indicated through clouds containing the name of the join point followed by the information provided by the aspect. The de ned types can now be used to de ne applications on the next level.

3.3 O2 | Robot Behavior Model (RBM)

To model behavior for a robot the RML located at O1 is instantiated at O2 as shown in the example in Figure 5. The example shows a simple program for a robot called Naomi , a NAO robot which is available under the IP address 192.168.1.19 . The program instructs Naomi to rst move forward and detect a red ball. If a ball it detected the robot will execute the Agree behavior and if not the Disagree behavior. The application then instructs the robot to sit down and terminates. uses true false

Disagree Detect Red Ball

To execute the application it is translated into an executable textual format by interpreting the visualizers provided by the RMLT and RML. If needed these can even be adapted at the RBM level. In the prototype realization the application is translated into an internal C++ domain-speci c language, compiled and then executed. Other tool chains could also be invoked. The domain-speci c language code created for the application in Figure 5 is shown in Listing 1. #include "naoAPI.h" void NAOProgram::script(){ move_navigation(4.0, 2.6, 0.785); boolean ballDetected = detect_red_ball(); if (ballDetected)

agree(); else

disagree(); posture("SitRelax");

Listing 1. The source code generated from the model displayed in Figure 5.

3.4 O3 | Behavior Enactment Model (BEM)

Robotic behaviors themselves serve as types for the execution of a robotic behavior. In other words, each behavior can be executed (i.e. instantiated) multiple times, with each instance represented as a separate object. Such an instance of a RBM is called an Behavior Enactment Model (BEM). The models are usually retrieved from logging information that was created during the execution of a RBM. A possible enactment model of the application presented in Figure 5 is shown in Figure 6. The example shows the application that was executed by Naomi available under 192.168.1.19 starting with a move at 1.22pm which was nished with success. After the move, the Detect Red Ball was switched on at 1.23pm and nished with success resulting in the red ball detection. The robot then made an Agree gesture at 1.23pm before sitting down at 1.24pm.

Naomi3(192.168.1.19)

Move x=4;y=2.6;theta=0.785 1.22pm;3success

Detect Red Ball 1.23pm;3success uses ballDetected:boolean

value=true 1.23pAmg;r3esueccess true

It can be observed that the rendering in Figure 6 uses the whole palette of visualization possibilities de ned at the levels above. The RBM in contrast did not use the visualization possibilities for the executionTime and the successful ag as there were no values for these attributes at the time of application de nition.

4 Related Work

In recent years several software frameworks have been developed to provide simple and intuitive ways of writing software applications for quasi-standard robot platforms. This includes academic research (e.g. [ 10 ] [ 12 ] [ 20 ]) as well as industrial products. One of the most well known is Lego Mindstorms Evolution 3, developed especially for the Lego robots which can be built out of the Lego model kits. This is an extremely exible and powerful system which allows anyone to build a robot using a few standard parts like motors, color sensors, touch sensors, infrared sensors and other Lego elements. These parts only have to be plugged to the so called brink | \a small computer that controls the motors and sensors" [ 21 ]. Afterwards, the user can graphically implement a program by choosing the desired activities from the pallet of available blocks. The software is advertised as having an \easy, intuitive and icon-based programming interface" [ 14 ] which gives rst-time programmers hands-on access to information technology. Because of this target group, the software only has a limited set of functions and cannot be extended in any way. Evolution 3 only supports the creation of software for Lego robots, and thus cannot be regarded as a general robot modeling framework.

Choregraphe is an environment developed by Aldebaran Robotics, the manufacturer of the NAO humanoid robot, to allow robots to be programmed by graphical applications [ 3 ]. It also supports code reuse and debugging capabilities and makes it possible to monitor and control NAO robots manually. The program uses an intuitive drag-and-drop interface in which a program is created using boxes that can be combined into a kind of ow diagram. Aldebaran Robotics provides several tutorials as well as online documentation which simplies the use of the tool [ 1 ]. In summary, although it is easy to use, Choregraphe allows the creation of complex programs. Like Lego Mindstorms Evolution 3, Choregraphe can only be used in combination with the NAO robot and thus cannot be regarded as a general robot modeling framework.

Robotino View 2 is a visual development environment provided by Festo Didactic exclusively for Robotino robots. It supports a slightly di erent way of visualizing programs than other tools, allowing it to provide some unique features. In particular, Robotino View 2 programs resemble electrical circuit diagrams rather than classical data ow chart. This makes them easier to understand for engineers, but creates a larger learning curve for programmers familiar with traditional langauges. Another unique feature allows users to draw complex lines from several segments. This comes in handy when models grow large and helps minimize intersections. Like Choregraphe, Robotino View 2 allows users to create custom blocks by including C++ code. It also uses two levels of programming, though they are very di erent to one another. The Block library includes all the blocks needed to create both simple and sophisticated programs, and the simulation environment is freely available from developer's website. Robotino View 2 shares the same limitation as the two previously mentioned frameworks | it is proprietary and can only be used with one kind of robot.

Microsoft Robotics Developer Studio 4 (MRDS4) [ 16 ] is another programming environment for building robotics applications. It provides a Visual Programming Language with an intuitive drag-and-drop interface for hobbyists and support for Microsoft Visual Studio for professional developers. MRDS4 has several signi cant advantages. First, numerous robots such as Lego Mindstorms NXT, Roomba [ 13 ] and Reference Platform [ 15 ] are supported. Second, a highdelity simulation environment is provided by Visual Simulation Environment (VSE), powered by NVIDIA PhysX engine, and the functionality of MRDS4 can be extended by providing additional libraries and services. Third, extensive documentation, samples and tutorials are available \out of the box". The main disadvantages of MRDS4 is the computational overhead resulting from the use of the simulation environment to control real robots. Another problem is that simulations tend to be overly simpli ed and do not take into account environment parameters such as surface type and weather.

Although these di erent languages and platforms are super cially very different, at a high enough level of abstraction they all contain the same basic constructs { prede ned types representing the components and actions from which the structure and behavior of individual robots are constructed. The same is true of the Robot Operating System [ 17 ] which represents an attempt to de ne a standard set of component and action types by the Open Source Robotics Foundation. In principle, therefore, they could all be brought together under the umbrella of a single, uni ed robot modeling framework, where common types and speci c types are arranged in inheritance hierarchies in the usual way. The great advantage of using deep modeling technology for such a uni ed robot modeling framework is that new types can be added, and existing types modi ed, at any time, on the y, by simply instantiating the prede ned meta types. All the information in the framework is therefore directly manipulable data, but nevertheless can be created and veri ed using the advantages of a strong typing system.

5 Conclusion

In order to open up the creation of robot applications to a wider range of developers, and encourage the emergence of a community of third party \robot app" developers, it is necessary to o er a robot modeling framework that is e cient, extensible, easy-to-use and able to support the description of applications in a variety of languages. The environment should also support the modeling and visualization of all information relevant to a robot, including dynamic information that is used to control and monitor its operation at run-time. These goals can best be achieved using a deep modeling environment, augmented with support for symbiotic languages, concurrent textual and graphical concrete syntaxes and on-the- y visualization customization via aspect-orientation. In this paper we have presented a prototype framework, known as the Deep Robot Modeling Framework (DRMF), which supports these capabilities using the Melanee deep modeling environment under development at the University of Mannheim. The current version of the prototype supports a rudimentary implementation of all of these features in the context of the NAO robot platform developed by Alderbaran Robots, although the basic framework is platform independent. Applications developed using the NAO-speci c languages are automatically mapped into C++ code that can be loaded onto, and used to drive, individual NAO robots. In the future, we plan to extend the environment to exploit other advanced features of Melenee such as the integrated support for exploratory and constructive modeling.

References

1. Aldebaran: Choregraphe user guide - nao software 1:14:5 documentation . https://community.aldebaran-robotics.com/doc/1-14/software/ choregraphe/index.html ( 2014 )

2. Aldebaran Robotics : Aldebaran robotics | humanoid robotics & programmable robots . http://www.aldebaran.com ( 2014 )

3. Aldebaran Robotics : Choreographe overview . https://community. aldebaran-robotics.com/doc/1-14/software/choregraphe/ choregraphe\_overview.html\# choregraphe-overview ( 2014 )

4. Atkinson , C. , Gerbig , R.: Melanie: Multi-level modeling and ontology engineering environment . In: Proceedings of the 2Nd International Master Class on ModelDriven Engineering: Modeling Wizards . pp. 7 : 1 { 7 : 2 . MW '12, ACM , New York, NY, USA ( 2012 )

5. Atkinson , C. , Gerbig , R.: Harmonizing textual and graphical visualizations of domain speci c models . In: Proceedings of the Second Workshop on Graphical Modeling Language Development . pp. 32 { 41 . GMLD '13, ACM , New York, NY, USA ( 2013 )

6. Atkinson , C. , Gerbig , R. , Kennel , B. : On-the- y emendation of multi-level models . In: Vallecillo, A. , Tolvanen , J.P. , Kindler , E. , Strrle , H. , Kolovos , D . (eds.) Modelling Foundations and Applications, Lecture Notes in Computer Science , vol. 7349 , pp. 194 { 209 . Springer Berlin Heidelberg ( 2012 )

7. Atkinson , C. , Gutheil , M. , Kennel , B. : A exible infrastructure for multilevel language engineering . IEEE Trans. Softw. Eng . 35 ( 6 ) ( 2009 )

8. Atkinson , C. , Kennel , B. , Go , B. : The level-agnostic modeling language . In: Malloy, B. , Staab , S. , Brand , M. (eds.) Software Language Engineering, Lecture Notes in Computer Science , vol. 6563 . Springer Berlin Heidelberg ( 2011 )

9. Baillie , J.C. : Urbi: Towards a universal robotic low-level programming language . In: Intelligent Robots and Systems , 2005 . (IROS 2005 ). 2005 IEEE/RSJ International Conference on. pp. 820 { 825 ( 2005 )

10. Banyasad , O. , Cox , P.T.: Visual programming of subsumption-based reactive behaviour . In: Technical Report CS-2008-03 . pp. 365 { 380 . Dalhousie University ( 2008 )

11. Bohrer , K. , Johnson , V., Nilsson , A. , Rubin , B. : The san francisco project: An object-oriented framework approach to building business applications . In: Computer Software and Applications Conference , 1997 . COMPSAC ' 97 . Proceedings ., The Twenty-First Annual International. pp. 416 { 424 (Aug 1997 )

12. Cox , P. , Smedley , T. : Visual programming for robot control . In: Visual Languages , 1998 . Proceedings. 1998 IEEE Symposium on . pp. 217 { 224 ( 1998 )

13. Kurt , T.E.: Hacking Roomba . Wiley ( 2006 )

14. LEGO: Website, available online at http://shop.lego. com/en-US/ LEGO-MINDSTORMS-EV3-31313; visited on April 13th 2014 .

15. Microsoft Robotics Group: Robotics Developer Studio: Reference Platform Design V1.0 . Microsoft Robotics Group ( 2012 )

16. Morgen , S. : Programming Microsoft Robotics Studio . Microsoft Press, 1st edn. ( 2008 )

17. O 'Kane , J.M.: A Gentle Introduction to ROS. Independently published ( 2013 )

18. OMG: Uml infrastructure 2.4.1 . http://www.omg.org/spec/UML/2.4. 1 ( 2011 )

19. Open Source Robotics Foundation: Turtlebot. http://www.turtlebot.com/ ( 2014 )

20. Simpson , J. , Jacobsen , C.L. : Visual process-oriented programming for robotics . In: Communicating Process Architectures 2008 , volume 66 of Concurrent Systems Engineering. pp. 365 { 380 . IOS Press ( 2008 )

21. Valk , L. : The Lego Mindstroms NXT 2.0 Discovery Book A Beginners Guide to Building and Programming Robots . William Pollock ( 2010 )