-Deploying successful robotics applications requires tremendous effort due to the need for contributions of experts from various domains. We present the iserveU family of executable DSLs that separate the concerns of domain experts and robotics experts and leverage model-transformation at system run-time to enable the robotic platform to flexibly fulfill tasks in a changing real-world environment. Current research in DSLs for robotics applications focuses on abstraction in the solution domain, whereas our DSLs support the domain expert in declaratively describing properties of the domain and loosely coupled tasks. To enable flexible task execution based on the domain expert's declarative models, these are translated into components of a reference architecture prior to deployment and into planning domain definition language (PDDL) problems at system runtime. Resulting problems are translated into executable plans using the Metric-FF solver and re-translated into iserveU models that ultimately are executed against a loosely coupled robotics middleware. Leveraging model transformation at run-time enables the flexibility necessary for robotics applications deployed to dynamic environments where design-time assumptions and run-time reality diverge easily. Index Terms-Model-Driven Development; Domain-Specific Languages; Planning; Software Architectures; Service Robotics
Service robotics is one of the most challenging domains:
successful deployment of even simple applications requires
participation of experts from various domains including
navigation, perception, software engineering, and the application
domain. Dynamic environments are a major challenge to
service robotics success: robots deployed to such environment
must either feature deterministic solutions for many, if not
all, possible challenges or yield flexible solution strategies
to solve service tasks in the face of unforeseen challenges.
To achieve this, robotic experts usually employ planning
techniques borrowed from knowledge representation. These
techniques, such as Golog [
We conceived the iserveU family of domain-specific
languages (DSLs) that separate the concerns of domain experts
and robotics experts [
In the following, Sec. II describes preliminaries and Sec. III presents an example of the iserveU DSLs in action. Afterwards, Sec. IV introduces the reference architecture that enables model execution and Sec. V presents the language transformations. Sec. VI highlights related work and Sec. VII discusses our approach. Sec. VIII concludes.
The iserveU DSLs are a family of four textual DSLs that
enable describing platform-independent, reusable robotic tasks.
To this effect, we separate the concerns of the domain expert,
who knows the domain’s types, causalities, and concerns of
the robot platform and its environment (denoted as world) [
«goal» has
LoadedAt Boolean conditions over entity properties
uses «task» DeliveredTo sequences of goals has
requires
«goal»
UnloadedAt
platform-independent concepts of the logistics domain. Those
classes are accessible in models representing entities, tasks,
and goals of a robotics application and can be manipulated by
in-class specified methods. Entity models describe properties
and actions of actors (robot, world) that can manipulate the
environment and operate in the context of a shared domain.
Entity properties yield parameters and return values of types
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
properties or domain model concepts. They resemble actions
of STRIPS [
The DSLs and their MontiArcAutomaton [
PDDL [
Solving PDDL Problems requires an efficient planner. For
our implementation, we choose Metric-FF [
Consider describing robot delivery tasks. Decoupling these from the specific environments they can be executed in and from the platforms they can be executed with, requires proper abstractions. With the iserveU languages, the domain model 01 domain LogisticsDomain; 02 world RoomsWorld rw; 03 robot TransportRobot { 04 property Waypoint robotLoc(); 05 property Boolean hasLoaded(Item item); 06 action move(Waypoint from, Waypoint to) { 07 pre: robotLoc() == from && rw.adjacent(from, to); 08 post: robotLoc() == to; 09 10 11 12 13 } 14 /* Additional properties and actions */ 15 } } action pickUp(Item item, Room room) { pre: robotLoc() == room && rw.itemLoc(item, room); post: hasLoaded(item) && !rw.itemLoc(item, room); is valid in the context of a domain and world (ll. 1-2) only. It characterizes properties (ll. 4-5) and actions (ll. 6-14) the robot entity is capable of, independent of their technical realization. is abstracted to a CD holding information of the domain’s concepts and their relations. To deliver items between rooms, this can be manifested as the CD depicted in Fig. 2.
adjacent
String name 1 in
CD
String name
This domain model describes the world (i.e., the
environment), consisting of connected waypoints out of which some
are rooms that store items. It does not disclose who knows
about this or can provide instances to reason about. For this,
the iserveU languages distinguish actions and properties of
robot entities and those defined by the world entities. Worlds
provide information about everything required by the robot to
fulfill tasks. Consequently, in our example, the world knows
where items are and which rooms are adjacent. We model this
as the entity model depicted in Fig. 3. The entity model is
valid in the context of the aforementioned domain model (l. 1)
and begins with the keyword world (to distinguish it from
robot entity models) followed by its unique name (l. 2) and a
body of properties (ll. 3-5). The properties describe relations
over the instances characterized in the domain model: here
they describe whether an item is in a specific room (l. 3) and
whether two waypoints are adjacent (l. 4). Modeling these
relations independent of their technical realization (which is
bound later during design time [
Controller
State Provider Robots realizing this entity must be able to identify, which waypoint they are at (l. 4) and which item they have loaded (l. 5). How, for instance, localization is realized is irrelevant. Actions feature unique (in context of the containing entity) names and parameters over which they specify preconditions and postconditions. Preconditions describe when executing the action is possible, postconditions describe the effect of executing the action. For instance, picking up an item in a specific room (ll. 10-13) requires that the robot and the item are in that room (l. 11). Here, itemLoc references the properties specified in the RoomsWorld world entity. On successful action execution, the item is not in that room 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 independent of the employed platforms.
Tasks in the iserveU context are sequences of goals the robot must fulfill given what is specified in the world and entity models. These goals are Boolean conditions over properties specified in world and robot entities. The goal LoadedAt, as depicted in Fig. 5, for instance, is considered fulfilled if the related TransportRobot instance (l. 1) confirms being in the specified room and holding the specified item (l. 3). Instead of imperatively describing a sequence of actions 01 robot TransportRobot rob; 02 goal LoadedAt(Room room, Item item) { 03 (rob.robotLoc() == room) && (rob.hasLoaded(item)) 04 } Goal that should lead to fulfilling goals at design time, specifying the participating entities and their capabilities declaratively enables finding solutions using a planner at system run time where potentially unforeseen challenges can arise. This yields greater flexibility and more robust robotics applications.
The approach relies on a centralized software architecture,
which is deployed to a system that is capable of
communicating with the robot and the user interface. The software
architecture is modeled as MontiArcAutomaton C&C architecture
as depicted in Fig. 6. The component Controller organizes
the orchestration of the overall process of task execution, as
described in [
r n to io cu t cA xeE response query retrieves state of the environment
The execution of actions is influenced by the status of robot and/or world, which is queried from the StateProvider component. If the execution of an action is finished, it can be either successful or not. On success, the controller executes the next action, otherwise, it triggers the Planner component to calculate an alternative plan. The implementation of the Controller component is independent of the concrete models and is therefore part of the run-time system. The StateProvider component requires all available properties of robot and world and is thus partially generated from the properties defined within entity models. The implementation of the ActionExecutor is generated from actions of entity models. It delegates the actual execution of actions to an employed middleware API. Therefore, a Java interface for each robot and world is generated, and the handwritten implementation of these interfaces calls the employed middleware API. The implementation of the Planner component itself is independent of the concrete types of goals it processes and actions it produces. Instead, it is part of the run-time system and invokes a PDDL tool with arguments generated as described in Sec. V.
Developers use the iserveU DSLs to describe domain
knowledge with UML/P CDs, tasks consisting of sequences of
goals, and entities consisting of properties and actions. Solving
tasks requires deriving actions to satisfy their goals
stepby-step. The latter is a classic planning problem, hence we
translate entities with actions and properties as well as domain
knowledge to PDDL, use Metric-FF [
The reference architecture’s Planner component implements the transformations to calculate plans for goals using the template-based code generation facilities of MontiCore. Fig. 7 overviews the main modules of the planning infrastructure and their dependencies. At design time, application developers model entities with properties and actions, domain model CDs, and goals representing desired situations (Sec. II-A). At compile time, the planning infrastructure applies several preparing model transformations to the entity models to, e.g., ensure uniqueness of names for the predicates of the PDDL artifacts generated later. Based on the transformed entity CD Artifacts models Goal Artifacts models CD parser Goal parser CD ASTs Goal ASTs
PDDL tool
Plans mAProDtidfDaecLlsts pPlaDnDneLr e.g., Metric-FF provided by architecture at run time
RTE – Model Realization Base Class instances models, it creates intermediate data structures that represent a complete PDDL domain and several partial PDDL problems. To complement a PDDL problem, the planning infrastructure has to be additionally provided with an initial state and arguments for goal parameters. These are only available at runtime. Once the planner receives the information at runtime in form of Java objects that are instances of goal and property classes (cf. RTE in Fig. 7), the PDDL problem is produced and the PDDL planning problem can be solved. Thus, the PDDL domain is generated once at compile time and remains unchanged at run time. In contrast, for each individual runtime planning request, a new PDDL problem is produced. After solving a dynamically generated PDDL problem with respect to the domain generated once at compile time, the infrastructure transforms the PDDL planner’s output back to a list of RTE class instances that represent sequences of actions. Under the assumption that the actions’ symbolic preconditions and postconditions adequately reflect the actions’ implementations, executing the actions in order leads to physical goal satisfaction.
A. Intra-Language Model-to-Model Transformations
The infrastructure generates a single PDDL domain from a CD domain model, a robot entity, and a world entity. To ensure the PDDL domain is well-formed, various transformations are applied to the entities. The first transformation ensures that no two actions have the same name. To this effect, the transformation prefixes each action name with the full-qualified name of its enclosing entity (using _ as package delimiter). The same is performed for properties. For instance, the name of the action move depicted in Fig. 4, is transformed to TransportRobot_move. To reduce notational complexity, the examples for the transformations following in the next sections do not include these preparation transformations.
a) From CDs to PDDL Types and Predicates: Each CD class is transformed to a PDDL type and each attribute of each class is transformed to a PDDL predicate. The generated PDDL types preserve the inheritance relation of the CDs and have the same names as the classes they originate from. For instance, the classes depicted in Fig. 2 are transformed to the PDDL types illustrated in Fig. 8 (ll. 5-7). The types String and Boolean (ll. 3-4) are built-in and may be used in domain and entity models. The name of the PDDL predicate derived from an attribute of a class is the name of Intra-language transformations Inter-language transformations
Partial PDDL models 01 (define (domain myDomain) 02 (:types 03 String - object 04 Boolean - object 05 Item - object 06 Waypoint - object 07 Room - Waypoint ; ... 08 ) 09 (:constants 10 False - Boolean 11 True - Boolean 12 13 14 15 ) 16 ) ) (:predicates (Item_name ?item - Item ?name - String) ; ...
; build-in type ; build-in type the class concatenated to an underscore (_) and the name of the attribute. Each predicate has two parameters. The first parameter has the type of the class, whereas the second parameter has the type of the attribute. The class Item depicted in Fig. 2, for instance, has an attribute name of type String. Thus, the class, together with the attribute name, defines the binary PDDL predicate (Item_name ?item Item ?name - String) depicted in Fig. 8 (l. 14).
b) From Entities to PDDL Predicates and Actions: Each property of each entity is transformed to a PDDL predicate. A property has parameters and a return value, whereas PDDL predicates represent Boolean predicates on a subset of the domain’s types. With this, properties represent functions that are transformed to PDDL predicates. Therefore, a property with n arguments is transformed to an (n+1)-ary PDDL predicate. The first n predicate parameters have the PDDL types corresponding to the types of the parameters of the property. The last argument of the predicate has the PDDL type corresponding to the return value type of the property. Each PDDL predicate has the same name as its corresponding property. For instance, the RoomsWorld properties (Fig. 3, ll. 3-5) are transformed to the PDDL predicates itemLoc and adjacent (Fig. 9, ll. 3-4) and the TransportRobot properties (Fig. 4, ll. 4-5) are transformed to the PDDL predicates robotLoc and hasLoaded (Fig. 9, ll. 5-6). 01 (define (domain myDomain) ; ... 02 (:predicates 03 (itemLoc ?item - Item ?room - Room ?res - Boolean) 04 (adjacent ?w1 - Waypoint ?w2 - Waypoint ?res - Boolean) 05 (robotLoc ?res - Waypoint) 06 (hasLoaded ?item - Item ?res - Boolean) ; ... 07 ) ; ... 08 ) PDDL
Each action of each entity model is transformed to a PDDL action. The parameters and preconditions of entity actions correspond to parameters and preconditions of PDDL actions. The postconditions of entity actions correspond to PDDL effects. After transforming an entity’s action, the resulting PDDL action yields the same name as the entity’s action. The parameters of the resulting PDDL action yield the same names and types as the parameters of the entity’s action. c) From Action Preconditions to PDDL Preconditions: The precondition of an entity’s action is a Boolean expression consisting of logical conjunctions, logical disjunctions, logical negations, and expressions referencing properties as well as attributes of the enclosing action’s parameters. The transformation of action preconditions to PDDL preconditions preserves logical negations, conjunctions, and disjunctions. Expressions referencing values of properties as well as qualified expressions referencing attributes of domain model classes become corresponding PDDL expressions. In preconditions, values of attributes and properties may be queried and compared to parameters of the enclosing action, attributes of objects, or values requested from properties.
01 (:action move 02 :parameters (?from – Waypoint ?to – Waypoint) 03 :precondition (AND (robotLoc ?room) 04 (adjacent ?from ?to True)) 05 :effect: (AND (forall (?X_0 - Waypoint) 06 (WHEN (AND (not (= ?X_0 ?to))) 07 (AND (not (robotLoc ?X_0))))) 08 (robotLoc ?to )) PDDL
The result from transforming the precondition of action move (Fig. 4, ll. 6-9) is depicted in Fig. 10 (ll. 3-4). The intention is that the PDDL expressions robotLoc ?room and adjacent ?from ?to True are satisfied if, and only if, the property robotLoc returns True and the value of property adjacent applied to ?from and ?to yields True. The transformation of preconditions containing qualified expressions that reference values of domain model instances, e.g., i1.name == i2.name where i1 and i2 are of type Item (Fig. 2 l. 3), is more involved. The resulting PDDL expression checks whether there is an object reachable by chaining the predicates introduced for the attributes referenced on both of the expression’s sides. The example above, for instance, results in the following PDDL expression: exists (X_0 - String X_1 - String) (AND (Item_name ?i1 X_0) (Item_name ?i2 X_1) (= X_0 X_1)) The intended PDDL precondition’s meaning is the following: there exist x0 and x1 such that x0 = i1:name, x1 = i2:name, and x0 = x1. Expressions comparing the values of two properties are similarly transformed to PDDL.
d) From Action Postconditions to PDDL Effects: A postcondition of an entity action is a Boolean expression that consists of logical conjunctions and infix expressions, i.e., expressions of the form X == Y, where X and Y are expression that either query the value of a property, a parameter, or a parameter’s attribute. Simply specifying an expression B is syntactic sugar for B == True and !B is syntactic sugar for B == False. Each postcondition can be interpreted as a sequence of assignments, where each either assigns a new value (Right-hand side Y) to a property or to an attribute (lefthand side X). The transformation preserves logical conjunctions and transforms infix expressions to PDDL expressions for removing or adding facts.
The postcondition of the action move (Fig. 4, l. 8), for instance, assigns the value of the parameter to and the property robotLoc(). The corresponding generated PDDL effect (Fig. 10, ll. 5-8) ensures that the object encoded by ?to is the only object that satisfies the predicate robotLoc. To this effect, for all objects ?X_0 (l. 6) such that X_06=?to (l. 6), the effect deletes the fact (robotLoc ?X_0) (l. 7) and then adds the fact (robotLoc ?to) (l. 8). The condition X_06=?to (l. 6) ensures the effect does not introduce an inconsistent planning state. Without the condition, the effect would first add the fact (not (robotLoc ?to)) and afterwards add the fact (robotLoc ?to), which introduces a planning state inconsistency. Expressions used in postconditions that assign the value of a property to another property or assign the value of a property to an attribute, and vice versa, are transformed similarly as above.
Each goal encodes a partial PDDL problem. In contrast to PDDL problems, goals can be parametrized. Hence, a goal only partially defines a PDDL problem. Additionally, they neither encode information about existing objects, nor about currently valid properties. In contrast, each PDDL problem defines a set of existing objects and an initial state consisting of facts relating objects (i.e., the corresponding domain’s predicates). Thus, PDDL problems cannot be generated at compile time, but only during run time when the current world and robot states are known, i.e., it is known, which objects exist and, which properties are valid. Given a list of Property (Sec. IV) instances, which encode facts holding at a certain point in time, and a Goal (Sec. IV) instance, which assigns values to parameters of the corresponding goal, at run time, a well-formed and complete PDDL problem can be generated. The PDDL problem of Fig. 11, e.g., is an excerpt of a PDDL problem generated from the goal model depicted in Fig. 5, a list of Property instances, and a Goal instance.
The PDDL problem generator takes a list of Property instances, a goal model, and a Goal instance corresponding to the goal model and generates a PDDL problem as follows: (1) Each attribute of each Property instance becomes an object in the PDDL problem (ll. 2-6). The identifier of each object is determined by concatenating the parts of the full qualified class name of the object before suffixing the object’s hash-code to the result of the concatenation. (2) Each Property instance becomes an initial fact in the PDDL problem (ll. 7-13). The name of the fact is the full qualified name of the class of the Property instance. Each attribute of the Property instance becomes a parameter of the fact. The parameters’ identifiers are determined as in (1). (3) The goal formula of the PDDL problem (ll. 14-19) is generated from the predicate of the goal model, and the attributes of the Goal instance. The attributes of the Goal instance instantiate the parameters of the goal model. Therefore, the goal of the PDDL problem results from applying the following two transformation steps: First, the predicate given in the goal model is transformed the same way as preconditions of actions are transformed to PDDL preconditions (l. 19). Afterwards, the result of the former transformation is enclosed by a term that binds the goal’s parameters by existential quantification (l. 15) and requires equality to the values defined by the attributes of the Goal instance (ll. 17-18).
The result from solving a PDDL problem with respect to a PDDL domain is a sequence of actions defined in the domain where the actions’ parameters are bound to objects defined in the PDDL problem. After planning, the reference architecture maps each action of the plan back to its entity action and each PDDL object back to the instance it originated from. With this information, for each action in the plan, the architecture creates an instance of the class generated from the entity’s action and sets the instance’s attributes to the domain instances corresponding to the objects bound to the action in the plan. The architecture then adds the action instances to a list (representing a sequence of actions) in the order defined by the plan and forwards it to trigger their execution.
Modeling techniques for robotics focus on abstraction in
the solution domain [
The iserveU DSLs enable separating the concerns of application domain experts from robotics experts. Consequently, the DSLs are designed to be uncomplicated (i.e., there are no conditionals or loops). However, formulating goals still requires understanding the dot-notation typical to objectoriented programming and describing Boolean expressions. Comprehending dot-notation and Boolean expressions requires a certain skill set from the domain expert. Whether other notations are better suited for this is subject of research. We also did not include heuristics into planning. Despite being able of accelerating planning, defining heuristics requires modeling relevant properties of tasks and goals as well as heuristic functions the planner can optimize. With the aim of providing straightforward DSLs, we refrained from that. Our approach requires to explicitly model all effects of an action that influence the world state. If this is incomplete, a plan may not be executable, because the models rely on an erroneous description of the current situation. Further, describing non-functional properties as, e.g., the robot has to arrive at a certain location within a given amount of time, is impossible or complicated with the described approach. Decoupling the robot’s actions from their problem domain representation enables exchanging the underlying platform easily: this requires implementing the interface generated from the robot model only. Hence, the same domain model, tasks, goals, and model transformations can be reused to execute robot actions with different robots with little effort.
We presented a family of executable DSLs that support describing the concepts of service robotics applications in a platform-independent fashion by separating the different stakeholders’ concerns. Models of these languages are transformed into parts of the execution framework at design time as well as into PDDL problems at system run time. Based on these problems, the integrated Metric-FF planner computes a series of actions that ultimately are executed using loose bindings to the underlying robot platform. Execution via transformation to an established planner yields the benefit of run-time flexibility required for dynamic real-world environments.