Executing Robot Task Models in Dynamic Environments Kai Adam, Arvid Butting, Oliver Kautz, Bernhard Rumpe, Andreas Wortmann Software Engineering, RWTH Aachen University www.se-rwth.de Abstract—Deploying successful robotics applications requires experts. The iserveU framework transforms entity models into tremendous effort due to the need for contributions of experts component implementations of its reference architecture [4] from various domains. We present the iserveU family of exe- and leverages transforming service robotics tasks into planning cutable DSLs that separate the concerns of domain experts and robotics experts and leverage model-transformation at system problems at system run-time to enable the service robot to run-time to enable the robotic platform to flexibly fulfill tasks in flexibly fulfill tasks in a changing environment. Based on a changing real-world environment. Current research in DSLs previous work ([2], [4]) this paper presents for robotics applications focuses on abstraction in the solution • the execution of iserveU task and goals models by lever- domain, whereas our DSLs support the domain expert in declar- atively describing properties of the domain and loosely coupled aging their run-time transformation into problems of the tasks. To enable flexible task execution based on the domain planning domain definition language (PDDL), expert’s declarative models, these are translated into components • solving these problems with the Metric-FF planner, and of a reference architecture prior to deployment and into planning • transforming the resulting plans into sequences of robot domain definition language (PDDL) problems at system run- actions that ultimately are executed with a loosely cou- time. Resulting problems are translated into executable plans using the Metric-FF solver and re-translated into iserveU models pled robotics middleware in the real world. that ultimately are executed against a loosely coupled robotics In the following, Sec. II describes preliminaries and Sec. III middleware. Leveraging model transformation at run-time en- presents an example of the iserveU DSLs in action. Af- ables the flexibility necessary for robotics applications deployed terwards, Sec. IV introduces the reference architecture that to dynamic environments where design-time assumptions and run-time reality diverge easily. enables model execution and Sec. V presents the language Index Terms—Model-Driven Development; Domain-Specific transformations. Sec. VI highlights related work and Sec. VII Languages; Planning; Software Architectures; Service Robotics discusses our approach. Sec. VIII concludes. II. P RELIMINARIES I. M OTIVATION This section recapitulates quintessential concepts of the Service robotics is one of the most challenging domains: iserveU DSLs presented in [2] and introduces PDDL as well successful deployment of even simple applications requires as the Metric-FF planner. participation of experts from various domains including nav- igation, perception, software engineering, and the application A. The iserveU DSLs domain. Dynamic environments are a major challenge to The iserveU DSLs are a family of four textual DSLs that en- service robotics success: robots deployed to such environment able describing platform-independent, reusable robotic tasks. must either feature deterministic solutions for many, if not To this effect, we separate the concerns of the domain expert, all, possible challenges or yield flexible solution strategies who knows the domain’s types, causalities, and concerns of to solve service tasks in the face of unforeseen challenges. the robot platform and its environment (denoted as world) [2]. To achieve this, robotic experts usually employ planning The latter describe the robot’s services as tasks that comprise techniques borrowed from knowledge representation. These sequences of reusable goals, i.e., conditions over the properties techniques, such as Golog [1], are tailored towards knowledge of robot and world that must hold at some point in time. representation experts and purely virtual planning only, which define capabilities as actions and properties properties of the domain model raises two challenges: (1) Enabling domain experts to represent «entity» uses «class diagram» uses «entity» TransportRobot LogisticsDomain RoomsWorld the knowledge required to support run-time problem solving; (2) Realizing the actions of the resulting plan in the real world. requires uses requires We conceived the iserveU family of domain-specific lan- «goal» has «task» has «goal» LoadedAt DeliveredTo UnloadedAt guages (DSLs) that separate the concerns of domain experts Boolean conditions over entity properties sequences of goals and robotics experts [2]. These DSLs enable domain experts to specify tasks, goals, and domain causalities in DSLs specif- Figure 1. Models of the four iserveU DSLs: CDs, entities, goals, and tasks. ically tailored to describing service robotics applications. To this effect, they feature robot entity models that are grounded Fig. 1 illustrates the relations of the four iserveU DSLs by in robotics middlewares (such as ROS [3]) by respective example: UML/P [5] class diagram (CD) models describe the platform-independent concepts of the logistics domain. Those is abstracted to a CD holding information of the domain’s classes are accessible in models representing entities, tasks, concepts and their relations. To deliver items between rooms, and goals of a robotics application and can be manipulated by this can be manifested as the CD depicted in Fig. 2. in-class specified methods. Entity models describe properties and actions of actors (robot, world) that can manipulate the LogisticsDomain CD environment and operate in the context of a shared domain. in WayPoint Room Item Entity properties yield parameters and return values of types 1 adjacent String name String name defined in the domain model (plus Java basics). Actions declared in the entity model specify the actor’s capabilities in terms of preconditions and postconditions over the entity Figure 2. Domain model characterizing items in connected rooms. properties or domain model concepts. They resemble actions of STRIPS [6], which enable planners to reason over action This domain model describes the world (i.e., the environ- executability and their effects. Goal models describe situations ment), consisting of connected waypoints out of which some as parametrizable Boolean conditions over domain types and are rooms that store items. It does not disclose who knows entity properties. Task models are sequences of goals that must about this or can provide instances to reason about. For this, hold in the predefined order. They can be parametrized and the iserveU languages distinguish actions and properties of pass arguments to their goals. robot entities and those defined by the world entities. Worlds The DSLs and their MontiArcAutomaton [7] reference provide information about everything required by the robot to architecture, have been deployed to and evaluated in the fulfill tasks. Consequently, in our example, the world knows Katharinenhospital in Stuttgart, Germany [2], [4]. where items are and which rooms are adjacent. We model this as the entity model depicted in Fig. 3. The entity model is B. The Planning Domain Definition Language and Metric-FF PDDL [8] is a widely used artificial intelligence planning 01 domain LogisticsDomain; 02 world RoomsWorld { Entity language. It distinguishes domain and problem models. A 03 property Boolean itemLoc(Item item, Room room); 04 property Boolean adjacent(Waypoint w1, Waypoint w2); domain model expresses the properties of a domain, i.e., all 05 /* Additional properties */ relevant objects, predicates, and actions. An action consists 06 } of parameters, a precondition over the parameters, and an effect. The precondition may reference the action’s parameters Figure 3. World entity providing information about rooms and items. and describes when it is executable with respect to a current valid in the context of the aforementioned domain model (l. 1) domain state. Its effect describes the domain changes that and begins with the keyword world (to distinguish it from occur on action execution. A precondition can be interpreted as robot entity models) followed by its unique name (l. 2) and a an arbitrary function-free first order predicate over the action’s body of properties (ll. 3-5). The properties describe relations parameters. An effect is a list of changes the action imposes on over the instances characterized in the domain model: here its execution. Effects may contain universal quantification and they describe whether an item is in a specific room (l. 3) and conditional expressions. As those are simply lists of actions, a whether two waypoints are adjacent (l. 4). Modeling these universal quantification can be interpreted as a for-each loop. relations independent of their technical realization (which is A conditional expression is a simple if-then-else expression. bound later during design time [4]) enables reusing these A PDDL problem describes an initial domain state in terms concepts in different environments and with different robots of initially satisfied predicates, i.e., existing objects and the with little effort. Similarly, the robot entity depicted in Fig. 4 properties they satisfy, and a goal describing the desired world state that is to be achieved. Goals are arbitrary function-free 01 domain LogisticsDomain; first order predicates also. 02 world RoomsWorld rw; Entity Solving PDDL Problems requires an efficient planner. For 03 robot TransportRobot { 04 property Waypoint robotLoc(); our implementation, we choose Metric-FF [9], a domain 05 property Boolean hasLoaded(Item item); independent and competitive planning system for PDDL. From 06 action move(Waypoint from, Waypoint to) { 07 pre: robotLoc() == from && rw.adjacent(from, to); a black-box perspective, Metric-FF takes a PDDL domain and 08 post: robotLoc() == to; 09 } a PDDL problem as input and outputs a plan, i.e., a list of 10 action pickUp(Item item, Room room) { actions. Starting from the domain state described by the PDDL 11 pre: robotLoc() == room && rw.itemLoc(item, room); 12 post: hasLoaded(item) && !rw.itemLoc(item, room); problem, executing the actions in order leads to satisfaction of 13 } the goal described by the PDDL problem. 14 /* Additional properties and actions */ 15 } III. E XAMPLE Figure 4. Robot entity model specifying its properties and capabilities. Consider describing robot delivery tasks. Decoupling these from the specific environments they can be executed in and is valid in the context of a domain and world (ll. 1-2) only. It from the platforms they can be executed with, requires proper characterizes properties (ll. 4-5) and actions (ll. 6-14) the robot abstractions. With the iserveU languages, the domain model entity is capable of, independent of their technical realization. Robots realizing this entity must be able to identify, which manages task execution waypoint they are at (l. 4) and which item they have loaded TaskExecutor (l. 5). How, for instance, localization is realized is irrelevant. action task Actions feature unique (in context of the containing entity) log response Controller Executor names and parameters over which they specify preconditions plan Action and postconditions. Preconditions describe when executing Planner goal the action is possible, postconditions describe the effect of query response executing the action. For instance, picking up an item in State a specific room (ll. 10-13) requires that the robot and the response Provider query item are in that room (l. 11). Here, itemLoc references retrieves state of the environment the properties specified in the RoomsWorld world entity. On successful action execution, the item is not in that room Figure 6. Overview of the iserveU reference architecture. anymore, but loaded onto the robot (l. 12). These causalities are independent of the specific domain (whether the item is moved around in a factory or hospital is irrelevant) and The execution of actions is influenced by the status of robot independent of the employed platforms. and/or world, which is queried from the StateProvider Tasks in the iserveU context are sequences of goals the robot component. If the execution of an action is finished, it can be must fulfill given what is specified in the world and entity either successful or not. On success, the controller executes the models. These goals are Boolean conditions over properties next action, otherwise, it triggers the Planner component specified in world and robot entities. The goal LoadedAt, to calculate an alternative plan. The implementation of the as depicted in Fig. 5, for instance, is considered fulfilled Controller component is independent of the concrete if the related TransportRobot instance (l. 1) confirms models and is therefore part of the run-time system. The being in the specified room and holding the specified item StateProvider component requires all available properties (l. 3). Instead of imperatively describing a sequence of actions of robot and world and is thus partially generated from the properties defined within entity models. The implementation 01 robot TransportRobot rob; of the ActionExecutor is generated from actions of entity Goal 02 goal LoadedAt(Room room, Item item) { models. It delegates the actual execution of actions to an 03 (rob.robotLoc() == room) && (rob.hasLoaded(item)) 04 } employed middleware API. Therefore, a Java interface for each robot and world is generated, and the handwritten imple- Figure 5. Goal requiring the robot being in a room while holding an item. mentation of these interfaces calls the employed middleware API. The implementation of the Planner component itself that should lead to fulfilling goals at design time, specifying is independent of the concrete types of goals it processes the participating entities and their capabilities declaratively and actions it produces. Instead, it is part of the run-time enables finding solutions using a planner at system run time system and invokes a PDDL tool with arguments generated where potentially unforeseen challenges can arise. This yields as described in Sec. V. greater flexibility and more robust robotics applications. V. T O PDDL AND BACK AGAIN IV. R EFERENCE A RCHITECTURE Developers use the iserveU DSLs to describe domain knowl- The approach relies on a centralized software architecture, edge with UML/P CDs, tasks consisting of sequences of which is deployed to a system that is capable of communicat- goals, and entities consisting of properties and actions. Solving ing with the robot and the user interface. The software archi- tasks requires deriving actions to satisfy their goals step- tecture is modeled as MontiArcAutomaton C&C architecture by-step. The latter is a classic planning problem, hence we as depicted in Fig. 6. The component Controller organizes translate entities with actions and properties as well as domain the orchestration of the overall process of task execution, as knowledge to PDDL, use Metric-FF [9] to solve each goal, and described in [4]. If a task entering the architecture is executed, transform the results back to plans at runtime. the Controller starts by dividing it into an ordered list of The reference architecture’s Planner component imple- goals that the robot has to fulfill one after another. It selects ments the transformations to calculate plans for goals using the the next goal and sends it to the Planner component, which template-based code generation facilities of MontiCore. Fig. 7 either calculates a plan to achieve the goal or indicates that overviews the main modules of the planning infrastructure no plan exists. The plan may depend on the current status and their dependencies. At design time, application developers of each element of the world and the current status of the model entities with properties and actions, domain model robot. Therefore, the Planner component can query the CDs, and goals representing desired situations (Sec. II-A). StateProvider component to obtain current states of robot At compile time, the planning infrastructure applies several and world. A valid plan to achieve a goal comprises an ordered preparing model transformations to the entity models to, e.g., list of actions. The Controller selects the next action to be ensure uniqueness of names for the predicates of the PDDL executed and sends it to the ActionExecutor component. artifacts generated later. Based on the transformed entity 01 (define (domain myDomain) 02 (:types PDDL Entity Entity Entity Intra-language Entity Artifacts 03 String - object ; build-in type models parser ASTs transformations ASTs 04 Boolean - object ; build-in type CD CD 05 Item - object Artifacts CD Inter-language Partial models ASTs PDDL models 06 Waypoint - object parser transformations 07 Room - Waypoint ; ... 08 ) Goal Goal Goal Artifacts PDDL 09 (:constants models parser ASTs Plans tool 10 False - Boolean PDDL 11 True - Boolean Artifacts PDDL models planner e.g., Metric-FF 12 ) provided by architecture at run time 13 (:predicates 14 (Item_name ?item - Item ?name - String) ; ... RTE – Model Realization Base Class instances 15 ) 16 ) Figure 7. Overview of the transformation infrastructure. Figure 8. Results from transforming the domain depicted in Fig. 2 to PDDL. models, it creates intermediate data structures that represent a complete PDDL domain and several partial PDDL problems. the class concatenated to an underscore (_) and the name of To complement a PDDL problem, the planning infrastructure the attribute. Each predicate has two parameters. The first has to be additionally provided with an initial state and argu- parameter has the type of the class, whereas the second ments for goal parameters. These are only available at runtime. parameter has the type of the attribute. The class Item Once the planner receives the information at runtime in form of depicted in Fig. 2, for instance, has an attribute name of type Java objects that are instances of goal and property classes (cf. String. Thus, the class, together with the attribute name, RTE in Fig. 7), the PDDL problem is produced and the PDDL defines the binary PDDL predicate (Item_name ?item - planning problem can be solved. Thus, the PDDL domain is Item ?name - String) depicted in Fig. 8 (l. 14). generated once at compile time and remains unchanged at run b) From Entities to PDDL Predicates and Actions: Each time. In contrast, for each individual runtime planning request, property of each entity is transformed to a PDDL predicate. A a new PDDL problem is produced. After solving a dynamically property has parameters and a return value, whereas PDDL generated PDDL problem with respect to the domain generated predicates represent Boolean predicates on a subset of the once at compile time, the infrastructure transforms the PDDL domain’s types. With this, properties represent functions that planner’s output back to a list of RTE class instances that are transformed to PDDL predicates. Therefore, a property represent sequences of actions. Under the assumption that the with n arguments is transformed to an (n+1)-ary PDDL actions’ symbolic preconditions and postconditions adequately predicate. The first n predicate parameters have the PDDL reflect the actions’ implementations, executing the actions in types corresponding to the types of the parameters of the order leads to physical goal satisfaction. property. The last argument of the predicate has the PDDL type corresponding to the return value type of the property. A. Intra-Language Model-to-Model Transformations Each PDDL predicate has the same name as its corresponding The infrastructure generates a single PDDL domain from a property. For instance, the RoomsWorld properties (Fig. 3, CD domain model, a robot entity, and a world entity. To ensure ll. 3-5) are transformed to the PDDL predicates itemLoc the PDDL domain is well-formed, various transformations are and adjacent (Fig. 9, ll. 3-4) and the TransportRobot applied to the entities. The first transformation ensures that properties (Fig. 4, ll. 4-5) are transformed to the PDDL no two actions have the same name. To this effect, the trans- predicates robotLoc and hasLoaded (Fig. 9, ll. 5-6). formation prefixes each action name with the full-qualified name of its enclosing entity (using _ as package delimiter). 01 (define (domain myDomain) ; ... The same is performed for properties. For instance, the name 02 (:predicates PDDL of the action move depicted in Fig. 4, is transformed to 03 (itemLoc ?item - Item ?room - Room ?res - Boolean) 04 (adjacent ?w1 - Waypoint ?w2 - Waypoint ?res - Boolean) TransportRobot_move. To reduce notational complexity, 05 (robotLoc ?res - Waypoint) 06 (hasLoaded ?item - Item ?res - Boolean) ; ... the examples for the transformations following in the next 07 ) ; ... sections do not include these preparation transformations. 08 ) a) From CDs to PDDL Types and Predicates: Each CD Figure 9. The properties of the entities depicted in Fig. 3 and Fig. 4 in PDDL. class is transformed to a PDDL type and each attribute of each class is transformed to a PDDL predicate. The generated Each action of each entity model is transformed to a PDDL PDDL types preserve the inheritance relation of the CDs action. The parameters and preconditions of entity actions and have the same names as the classes they originate from. correspond to parameters and preconditions of PDDL actions. For instance, the classes depicted in Fig. 2 are transformed The postconditions of entity actions correspond to PDDL to the PDDL types illustrated in Fig. 8 (ll. 5-7). The types effects. After transforming an entity’s action, the resulting String and Boolean (ll. 3-4) are built-in and may be PDDL action yields the same name as the entity’s action. The used in domain and entity models. The name of the PDDL parameters of the resulting PDDL action yield the same names predicate derived from an attribute of a class is the name of and types as the parameters of the entity’s action. c) From Action Preconditions to PDDL Preconditions: tions and transforms infix expressions to PDDL expressions The precondition of an entity’s action is a Boolean expression for removing or adding facts. consisting of logical conjunctions, logical disjunctions, logical The postcondition of the action move (Fig. 4, l. 8), for in- negations, and expressions referencing properties as well as stance, assigns the value of the parameter to and the property attributes of the enclosing action’s parameters. The transforma- robotLoc(). The corresponding generated PDDL effect tion of action preconditions to PDDL preconditions preserves (Fig. 10, ll. 5-8) ensures that the object encoded by ?to is logical negations, conjunctions, and disjunctions. Expressions the only object that satisfies the predicate robotLoc. To this referencing values of properties as well as qualified expres- effect, for all objects ?X_0 (l. 6) such that X_06=?to (l. 6), sions referencing attributes of domain model classes become the effect deletes the fact (robotLoc ?X_0) (l. 7) and corresponding PDDL expressions. In preconditions, values of then adds the fact (robotLoc ?to) (l. 8). The condition attributes and properties may be queried and compared to X_06=?to (l. 6) ensures the effect does not introduce an parameters of the enclosing action, attributes of objects, or inconsistent planning state. Without the condition, the effect values requested from properties. would first add the fact (not (robotLoc ?to)) and afterwards add the fact (robotLoc ?to), which introduces a planning state inconsistency. Expressions used in postcondi- 01 (:action move 02 :parameters (?from – Waypoint ?to – Waypoint) PDDL tions that assign the value of a property to another property or 03 :precondition (AND (robotLoc ?room) 04 (adjacent ?from ?to True)) assign the value of a property to an attribute, and vice versa, 05 :effect: (AND (forall (?X_0 - Waypoint) are transformed similarly as above. 06 (WHEN (AND (not (= ?X_0 ?to))) 07 (AND (not (robotLoc ?X_0))))) 08 (robotLoc ?to )) B. From Goals to PDDL Problems Each goal encodes a partial PDDL problem. In contrast to Figure 10. The action move of the entity depicted in Fig. 4 in PDDL. PDDL problems, goals can be parametrized. Hence, a goal only partially defines a PDDL problem. Additionally, they The result from transforming the precondition of action neither encode information about existing objects, nor about move (Fig. 4, ll. 6-9) is depicted in Fig. 10 (ll. 3-4). The currently valid properties. In contrast, each PDDL problem intention is that the PDDL expressions robotLoc ?room defines a set of existing objects and an initial state consisting and adjacent ?from ?to True are satisfied if, and of facts relating objects (i.e., the corresponding domain’s only if, the property robotLoc returns True and the value of predicates). Thus, PDDL problems cannot be generated at property adjacent applied to ?from and ?to yields True. compile time, but only during run time when the current The transformation of preconditions containing qualified ex- world and robot states are known, i.e., it is known, which pressions that reference values of domain model instances, objects exist and, which properties are valid. Given a list of e.g., i1.name == i2.name where i1 and i2 are of type Property (Sec. IV) instances, which encode facts holding Item (Fig. 2 l. 3), is more involved. The resulting PDDL at a certain point in time, and a Goal (Sec. IV) instance, expression checks whether there is an object reachable by which assigns values to parameters of the corresponding goal, chaining the predicates introduced for the attributes referenced at run time, a well-formed and complete PDDL problem can on both of the expression’s sides. The example above, for be generated. The PDDL problem of Fig. 11, e.g., is an excerpt instance, results in the following PDDL expression: of a PDDL problem generated from the goal model depicted in Fig. 5, a list of Property instances, and a Goal instance. exists (X_0 - String X_1 - String) The PDDL problem generator takes a list of Property (AND (Item_name ?i1 X_0) (Item_name ?i2 X_1) (= X_0 X_1)) instances, a goal model, and a Goal instance corresponding to the goal model and generates a PDDL problem as follows: The intended PDDL precondition’s meaning is the fol- (1) Each attribute of each Property instance becomes an lowing: there exist x0 and x1 such that x0 = i1.name, object in the PDDL problem (ll. 2-6). The identifier of each x1 = i2.name, and x0 = x1 . Expressions comparing the object is determined by concatenating the parts of the full values of two properties are similarly transformed to PDDL. qualified class name of the object before suffixing the object’s d) From Action Postconditions to PDDL Effects: A post- hash-code to the result of the concatenation. condition of an entity action is a Boolean expression that (2) Each Property instance becomes an initial fact in the consists of logical conjunctions and infix expressions, i.e., ex- PDDL problem (ll. 7-13). The name of the fact is the full pressions of the form X == Y, where X and Y are expression qualified name of the class of the Property instance. Each that either query the value of a property, a parameter, or a attribute of the Property instance becomes a parameter of parameter’s attribute. Simply specifying an expression B is the fact. The parameters’ identifiers are determined as in (1). syntactic sugar for B == True and !B is syntactic sugar (3) The goal formula of the PDDL problem (ll. 14-19) is gen- for B == False. Each postcondition can be interpreted as erated from the predicate of the goal model, and the attributes a sequence of assignments, where each either assigns a new of the Goal instance. The attributes of the Goal instance value (Right-hand side Y) to a property or to an attribute (left- instantiate the parameters of the goal model. Therefore, the hand side X). The transformation preserves logical conjunc- goal of the PDDL problem results from applying the following 01 (define (problem LoadedAt) tasks. The concepts presented in the ontology are not realized PDDL 02 (:objects as a modeling technique. Various robotics specific modeling 03 logisticsdomainItem141 - Item 04 logisticsdomainItem149 - Item techniques defined on top of the situation calculus [13] enable 05 logisticsdomainRoom412 - Room ; ... 06 ) describing robotic goals and actions and properties required 07 (:init to fulfill these in a platform-independent fashion. These DSLs 08 (itemLoc logisticsdomainItem141 09 logisticsdomainRoom412 True) are tailored to knowledge representation experts. 10 (itemLoc logisticsdomainItem149 11 logisticsdomainRoom412 True) VII. D ISCUSSION 12 (robotLoc logisticsdomainRoom412 True) ; ... 13 ) The iserveU DSLs enable separating the concerns of ap- 14 (:goal ; Derived from goal “loadedAt” 15 (exists (?room – Room ?item - Item) plication domain experts from robotics experts. Consequently, 16 (and the DSLs are designed to be uncomplicated (i.e., there are 17 (= ?room logisticsdomainRoom412) 18 (= ?item logisticsdomainItem149) no conditionals or loops). However, formulating goals still 19 (and (robotLoc ?room) (hasLoaded ?item True)))) 20 ) requires understanding the dot-notation typical to object- 21 ) oriented programming and describing Boolean expressions. Comprehending dot-notation and Boolean expressions requires Figure 11. PDDL problem derived from the goal depicted in Fig. 5 and a certain skill set from the domain expert. Whether other instances of the classes generated from the properties of the entities depicted notations are better suited for this is subject of research. We in Fig. 3 and Fig. 4 as well as the domain depicted in Fig. 2. also did not include heuristics into planning. Despite being able of accelerating planning, defining heuristics requires two transformation steps: First, the predicate given in the goal modeling relevant properties of tasks and goals as well as model is transformed the same way as preconditions of actions heuristic functions the planner can optimize. With the aim are transformed to PDDL preconditions (l. 19). Afterwards, the of providing straightforward DSLs, we refrained from that. result of the former transformation is enclosed by a term that Our approach requires to explicitly model all effects of an binds the goal’s parameters by existential quantification (l. 15) action that influence the world state. If this is incomplete, and requires equality to the values defined by the attributes of a plan may not be executable, because the models rely on the Goal instance (ll. 17-18). an erroneous description of the current situation. Further, The result from solving a PDDL problem with respect describing non-functional properties as, e.g., the robot has to to a PDDL domain is a sequence of actions defined in the arrive at a certain location within a given amount of time, domain where the actions’ parameters are bound to objects is impossible or complicated with the described approach. defined in the PDDL problem. After planning, the reference Decoupling the robot’s actions from their problem domain architecture maps each action of the plan back to its entity representation enables exchanging the underlying platform action and each PDDL object back to the instance it originated easily: this requires implementing the interface generated from from. With this information, for each action in the plan, the the robot model only. Hence, the same domain model, tasks, architecture creates an instance of the class generated from the goals, and model transformations can be reused to execute entity’s action and sets the instance’s attributes to the domain robot actions with different robots with little effort. instances corresponding to the objects bound to the action in VIII. C ONCLUSION the plan. The architecture then adds the action instances to a We presented a family of executable DSLs that support list (representing a sequence of actions) in the order defined describing the concepts of service robotics applications in a by the plan and forwards it to trigger their execution. platform-independent fashion by separating the different stake- VI. R ELATED W ORK holders’ concerns. Models of these languages are transformed into parts of the execution framework at design time as well Modeling techniques for robotics focus on abstraction in as into PDDL problems at system run time. Based on these the solution domain [10]. Techniques for the problem domain problems, the integrated Metric-FF planner computes a series are rare and usually tied to specific platforms. The textual of actions that ultimately are executed using loose bindings to DSL for modeling robot abilities presented in [11], e.g., also the underlying robot platform. Execution via transformation to enables defining sequences of actions that are independent an established planner yields the benefit of run-time flexibility from specific robots. It is implemented as a DSL embedded required for dynamic real-world environments. in Java and requires imperative programming of tasks. Fixing tasks this way eliminates the flexibility of on-line planning in R EFERENCES cases where the environment at system run time differs from [1] H. J. Levesque, R. Reiter, Y. Lesperance, F. Lin, and R. B. Scherl, assumptions made at system development time. The ontology “GOLOG: A Logic Programming Language for Dynamic Domains,” Journal of Logic Programming, 1997. for service robot behavior presented in [12] resembles the [2] R. Heim, P. Mir Seyed Nazari, J. O. Ringert, B. Rumpe, and A. Wort- DSLs we presented, but distinguishes sensing actions from ma- mann, “Modeling Robot and World Interfaces for Reusable Tasks,” in nipulation actions. The authors present common control struc- Intelligent Robots and Systems Conference (IROS’15), 2015. [3] M. Quigley, B. Gerkey, K. Conley, J. Faust, T. Foote, J. Leibs, E. Berger, tures for robotics applications, whereas we did not consider R. Wheeler, and A. Ng, “ROS: an open-source Robot Operating System,” confronting the domain experts with control structures in the in ICRA Workshop on Open Source Software, 2009. [4] K. Adam, A. Butting, R. Heim, O. Kautz, B. Rumpe, and A. Wort- [9] J. Hoffmann, “The metric-FF Planning System: Translating "Ignoring mann, “Model-Driven Separation of Concerns for Service Robotics,” in Delete Lists" to Numeric State Variables,” Journal of Artificial Intelli- International Workshop on Domain-Specific Modeling (DSM’16), 2016. gence Research, 2003. [5] B. Rumpe, Modeling with UML: Language, Concepts, Methods. [10] A. Nordmann, N. Hochgeschwender, D. L. Wigand, and S. Wrede, “A Springer International, July 2016. survey on domain-specific modeling and languages in robotics,” Journal [6] R. E. Fikes and N. J. Nilsson, “STRIPS: A new approach to the appli- of Software Engineering in Robotics, 2016. cation of theorem proving to problem solving,” Artificial intelligence, [11] M. Reckhaus, N. Hochgeschwender, P. G. Ploeger, G. K. Kraetzschmar, vol. 2, 1971. and S. Augustin, “A Platform-independent Programming Environment [7] J. O. Ringert, A. Roth, B. Rumpe, and A. Wortmann, “Language and for Robot Control,” in Proceedings of the 1st International Workshop Code Generator Composition for Model-Driven Engineering of Robotics on Domain-Specific Languages and models for Robotic systems, 2010. Component & Connector Systems,” Journal of Software Engineering for Robotics (JOSER), 2015. [12] J. P. Diprose, B. Plimmer, B. A. MacDonald, and J. G. Hosking, [8] D. McDermott, M. Ghallab, A. Howe, C. Knoblock, A. Ram, M. Veloso, “How People Naturally Describe Robot Behaviour,” in Proceedings of D. Weld, and D. Wilkins, “PDDL-The Planning Domain Definition Australasian Conference on Robotics and Automation, 2012, pp. 3–5. Language,” Yale Center for Computational Vision and Control, Tech [13] J. McCarthy and P. J. Hayes, “Some Philosophical Problems from the Report, 1998. Standpoint of Artificial Intelligence,” Machine Intelligence, 1969.