Domain Specific Language for Geometric Relations between Rigid
Bodies targeted to robotic applications
Tinne De Laet, Wouter Schaekers, Jonas de Greef, and Herman Bruyninckx
Abstract— This paper presents a DSL for geometric rela-
tions between rigid bodies such as relative position, orien-
tation, pose, linear velocity, angular velocity, and twist. The
DSL is the formal model of the recently proposed semantics
for the standardization of geometric relations between rigid
bodies [1], [2], referred to as ‘geometric semantics’. This
semantics explicitly states the coordinate-invariant properties
and operations, and, more importantly, all the choices that
are made in coordinate representations of these geometric
relations. This results in a set of concrete suggestions for stan-
dardizing terminology and notation, allowing programmers
to write fully unambiguous software interfaces, including
automatic checks for semantic correctness of all geometric
operations on rigid-body coordinate representations.
The DSL is implemented in two different ways: an external
DSL in Xcore and an internal DSL in Prolog. Besides defining
a grammar and operations, the DSL also implements con-
straints. In the Xcore model, the Object Constraint Language
language is used, while in the Prolog model, the constraint
are natively modelled in Prolog.
This paper discusses the implemented DSL and the tools
developed on top of this DSL. In particular an editor, checking
the semantic constraints and providing semantic meaningful
errors during editing is proposed.
I. INTRODUCTION
When developing robotic applications, robot program-
mers and application developers have to deal with three-
dimensional motion and relations between rigid bodies
(manipulated objects, robot links, or mobile bases). Rigid
bodies are essential primitives in the modelling of robotic
devices, tasks and perception. Basic geometric relations
between rigid bodies include relative position, orientation,
pose (combining position and orientation), linear velocity,
angular velocity, and twist (combining linear and angu-
lar velocity). To express geometric relations and perform
mathematical operations on them (e.g. composition of
relative motion, time differentiation, or integration), robot
programmers have to choose coordinate representations
with which to perform the corresponding numerical op-
erations.
Until recently, and despite a history of over 50 years,
the geometric properties of rigid-body operations, and their
Tinne De Laet and Herman Bruyninckx are with the Department
of Mechanical Engineering, Katholieke Universiteit Leuven, Belgium.
Wouter Schaekers and Jonas de Greef are students at the Computer
Science Engineering Department, Katholieke Universiteit Leuven, Bel-
gium. Corresponding author: Tinne De Laet (Tinne.DeLaet@mech.
kuleuven.be)
coordinate representations, were not standardized, which
has led to a proliferation of mutually incompatible software
libraries, in the robot control products of commercial
manufacturers as well as in open source libraries such
as KDL (Kinematics and Dynamics Library) [3], ROS
(Robot Operating System) [4], RL (Robotics Library) [5],
.... All geometric relations and their coordinate represen-
tations entail a surprisingly large number of choices or
assumptions, which are often made implicitly, but which
are necessary to consider in view of (i) understanding the
physical meaning of the numerical values that constitute
the coordinate representation of a geometric relation and
(ii) performing physically meaningful mathematical opera-
tions on these numerical values. Not explicitly stating the
above assumptions may lead to errors in the calculations
(composition of geometric relations expressed in different
coordinate frames, composition of poses and orientation
coordinate representations in wrong order,... [1]). To al-
leviate this problem, we recently proposed semantics for
the standardization of geometric relations between rigid
bodies [1], referred to as ‘geometric semantics’. This se-
mantics explicitly states the coordinate-invariant properties
and operations, and, more importantly, all the choices that
are made in coordinate representations of these geometric
relations. This results in a set of concrete suggestions
for standardizing terminology and notation, allowing pro-
grammers to write fully unambiguous software interfaces,
including automatic checks for semantic correctness of all
geometric operations on rigid-body coordinate representa-
tions. This resulted in a Robot Request for Comments [2]
for the Robot Engineering Task Force [6]. Furthermore,
software providing a C++ implementation of the software
is developed and available as open-source [7], [8].
Domain Specific Languages are lightweight program-
ming languages designed to concisely express the con-
cepts of a particular domain. Commonly two types are
distinguished: internal and external DSLs. The former are
built on top of an existing language, while the latter are
developed from scratch resulting in a custom syntax and
making them independent from existing languages. By
reusing existing infrastructure, internal DSLs are easier
to create, maintain, and combine with other DSLs than
external ones [9]. External DSLs, while suffering from
an increased cost for creating and maintenance, are not
arXiv:1304.1346v3  [cs.RO]  10 Apr 2013
constrained by any other language. Therefore, the choice
between an internal or external design often depends on
the particular application, use case, available tools, and
preferences of the designer. In this paper we develop both
types for the geometric semantics: 1) an external DSL in
Xcore and 2) an internal DSL in Prolog.
The goal of this paper is fourfold. Firstly, we want
to build a DSL for geometric relations between rigid
bodies such as relative position, orientation, pose, linear
velocity, angular velocity, and twist founded on the geo-
metric semantics [1], [2]. This DSL advances with respect
to the available available implementation in the general-
purpose programming language C++, by formalizing the
underlying model of the geometric semantics. Furthermore,
the DSL is the basis for the developments of tools that
assist the robot programmers and application developers to
write fully unambiguous software interfaces and prevent
common errors in geometric calculations. In particular this
paper presents and editor built on top of the proposed
DSL that automatically checks the semantic correctness of
all geometric operations on rigid-body coordinate repre-
sentations, while writing and editing the code. Secondly,
we want to explore the impact of different design choices
(internal, external), work flows, and tools. Thirdly, we
believe that due to the concise and mature nature of the
underlying geometric semantics theory and its relevance
for the robotics domain it will prove to be an excellent
example for future DSL development in robotics. Fourthly,
we will highlight the unfulfilled robotic needs still present
in Model Driven Engineering.
Section II gives an overview of related work. Section IV
provides a short summary of the geometric semantics
theory relevant for this paper. Section III situates this
paper’s contributions using the four levels of abstraction
in Model Driven Engineering.
II. RELATED WORK
Since we are not aware of any DSL on the semantics for
geometric relationships between rigid bodies, our related
work will rather point to some other DSLs developed in
the robotics domain.
Frigerio et al.’s DSL is the DSL most related to the
DSL proposed in this paper. They propose a DSL for kine-
matic models and fast implementation of robot dynamic
algorithms. The DSL allows to model algorithms that
are parametrised on the kinematics/dynamics model of a
robot, hereby facilitating the generation of executable code
tailored for a specific robot. This approach only requires
the users to provide a high level description of their robot
and relieves them from hand-crafted development.
Furthermore, we want to mention the Mechatronics De-
scription Language (MDL), which is a domain-specific
language that can model the kinematic structure of individ-
ual robot modules and declaratively describe their possible
interconnections. From this description, the MDL compiler
generates the code that is needed to simulate the resulting
robots within Webots, a widely used commercial robot
simulator, and the software component needed for spatial
structure computations by a virtual machine-based runtime
system, which we have developed and use for programming
physical modular robots [10].
Klotzb¨ucher et al. [11] propose a DSL for specifying
robotic tasks using the task frame formalism as an example
of lua as a lightweight and composable metamodelling
language for specification and validation of internal DSLs.
In later work Klotzb¨ucher et al. [9]) propose a DSL
allowing to separate task specification and coordination of
these tasks using state charts.
III. LEVELS OF ABSTRACTION IN MODEL DRIVEN
ENGINEERING
Figure 1 illustrates a systematic approach to model a
certain domain in four levels of abstraction [9], [12]. These
four levels have the following meaning for the context of
the geometric semantics:
M0: the level of the concrete implementations, for instance
a particular set of geometric semantics calculations
using the C++ library of the geometric semantics [8],
M1: the level of a particular set of geometric semantics
calculations using the geometric semantics DSL,
M2: the level of the application independent geometric
semantics DSL, which provides a language for both
coordinate representation independent and dependent
(taking into account the constraints of a particular
coordinate representation) geometric calculations.
M3: the highest level of abstraction, that is, the model in
terms of which we describe our meta-models (M2).
For example, ecore that we can use to describe our
geometric semantics DSL.
The geometric semantics theory [1], summarized in
Section IV, can be considered as the basis for the M2
level DSL, as it describes (in language) the constraints
on the geometric relations semantics, the possible oper-
ations on the geometric relations, the constraints on the
relations and operations, and the constraints imposed by
particular coordinate representations. The available C++
implementation [8] and the applications implemented in
it, are examples of the M0 level.
This paper provides DSL implementations, both an
external DSL and an internal DSL, on the M2 level.
Furthermore, this paper presents tools based on the de-
veloped DSLs, that allow the DSL users to implement
their particular set of geometric semantic calculations,
i.e. to work on the M1 level. To illustrate the proposed
approach, we provide an example on a M1 implementation
metameta
model
Real-world systems
domain
model
domain
model
domain
model
metamodel
(DSL)
metamodel
(DSL)
M3
M2
M1
M0
DSL
designer
DSL
user
Conforms to
Conforms to
Conforms to
Conforms to
Conforms to
Conforms to
Conforms to
Conforms to
Conforms to
Fig. 1: The four levels of abstraction.)
for a particular geometric calculation and show how the
developed DSL and the accompanying tools will help to
prevent commonly made errors.
IV. GEOMETRIC SEMANTICS, BACKGROUND [1]
A. Geometric relations
Geometric relations between bodies are described us-
ing a set of geometric primitives1: points (e), vectors,
orientation frames ([a] , they represent an orientation, by
means of three orthonormal vectors indicating the frame’s
X-axis X, Y-axis Y , and Z-axis Z), and frames ({g}).
Figure 2 presents the geometric primitives body, point,
vector, orientation frame, and frame graphically. To help
the reader we will consistently use the following naming
for the geometric primitives to represent the geometric
relation of a body C with respect to body D in this
document: e|C, [a]|C, {g}|C, f|D, [b]|D, and {h}|D.
Table I summarizes the minimal but complete set of
geometric primitives and the (coordinate) semantics for
the geometric relations position, orientation, pose, twist
between rigid bodies, which are the most relevant relations
for this paper.
B. Semantic operations
On the geometric relations defined in Section IV-A,
semantic operations that compose the geometric relations
or that change the point, orientation frame, reference point,
reference orientation frame, or coordinate frame of the ge-
ometric relation can be applied. These semantic operations
themselves impose constraints on the geometric relation
they are applied to and on the operation arguments (which
are themselves geometric relations) of the operator. While
1This background contains a short summary of the semantics for the
standardization of geometric relations between rigid bodies, for more
details we refer to [1].
[a]
e
C
{g}
[b]
f
D
{h}
[r]
Fig. 2: The geometric relation between rigid bodies are de-
scribed using a set of geometric primitives: points, vectors,
orientation frames, and frames. The above figure shows the
geometric primitives that are useful to define the position,
orientation, pose, linear velocity, angular velocity, and twist
of body C with respect to body D: an orientation frame [a],
a point e, and frame {g} fixed to body C, an orientation
frame [b], a point f, and frame {h} fixed to body D, and
a coordinate frame [r], considered instantaneously fixed to
body D, in which the coordinates are expressed. (Extract
from [1].)
[1] provides an overview of semantic operations that can
be applied to geometric relations and lists the constraints
imposed by the operations, we will only give an example
illustrating the concept of the semantic operation and the
constraints imposed by it.
As
an
example,
consider
the
semantic
operation
to
change
the
point
used
to
describe
the
posi-
tion of body C with respect to body D. Imagine
PositionCoord (e1|C, f|D, [r]) is the semantic description
of the position of body C with respect to body D. To
change the point to describe the position from the current
point e1 to a new point e2, the position of the new
Geometric Relation
(Coordinate) semantics
Geometric primitives
Graphical representation
Position
Position (e|C, f|D)
point e
e
f
C
D
[r]
PositionCoord (e|C, f|D, [r])
body C
reference point f
reference body D
coordinate frame [r]
Position of point e fixed to body C (e|C) with respect to point f fixed to body D (f|D), expressed in coordinate frame [r]
Orientation
Orientation ([a]|C, [b]|D)
orientation frame [a]
[a]
[b]
C
D
[r]
OrientationCoord ([a]|C, [b]|D, [r])
body C
reference orientation frame [b]
reference body D
coordinate frame [r]
Orientation of orientation frame [a] fixed to body C ([a]|C) with respect to orientation frame [b] fixed to body D ([b]|D), expressed
in coordinate frame [r]
Pose
Pose ((e, [a])|C, (f, [b])|D)
point e
[a]
[b]
e
f
C
D
[r]
PoseCoord ((e, [a])|C, (f, [b])|D, [r])
orientation frame [a]
body C
reference point f
reference orientation frame [b]
reference body D
coordinate frame [r]
Pose of point e and orientation frame [a] fixed to body C ((e, [a])|C) with respect to point f and orientation frame [b] fixed to body
D ((f, [b])|D), expressed in coordinate frame [r]
Pose ({g}|C, {h}|D)
frame {g}
{g}
{h}
C
D
[r]
PoseCoord ({g}|C, {h}|D, [r])
body C
frame {h}
reference body D
coordinate frame [r]
Pose of frame {g} fixed to body C ({g}|C) with respect to frame {g} fixed to body D ({g}|D), expressed in coordinate frame [r]
Linear velocity
LinearVelocity (e|C, D)
point e
e
C
D
[r]
LinearVelocityCoord (e|C, D, [r])
body C
reference body D
coordinate frame [r]
Linear velocity of point e fixed to body C (e|C) with respect to body D, expressed in coordinate frame [r]
Angular velocity
AngularVelocity (C, D)
body C
C
D
[r]
AngularVelocityCoord (C, D, [r])
reference body D
coordinate frame [r]
Angular velocity of body C with respect to body D, expressed in coordinate frame [r]
Twist
Twist (e|C, D)
point e
e
C
D
[r]
TwistCoord (e|C, D, [r])
body C
reference body D
coordinate frame [r]
Twist of body C with velocity reference point e (e|C) with respect to body D, expressed in coordinate frame [r]
TABLE I: Minimal semantics and coordinate semantics (expressed in coordinate frame [r]) including the minimal but
complete set of geometric primitives for the position, orientation, pose, linear velocity, angular velocity, and twist of
body C with point e, orientation frame [a], and frame {g} with respect to D with point f, orientation frame [b], and
frame {h}, including a graphical representation. (extracted from [1])
point e2 fixed to body C with respect to e1 fixed to
body C and expressed in the same coordinate frame [r] is
needed, i.e. PositionCoord (e2|C, e1|C, [r]). If the semantic
operator .changePoint () is applied to the geometric relation
of which the point has to be changed (in our example
PositionCoord (e1|C, f|D, [r])) and has as an argument the
geometric relation needed to achieve this change of ref-
erence point, the .changePoint () imposes the following
constraints: (1) the argument of .changePoint () should be
a PositionCoord geometric relation; (2) the reference point
of the argument should be equal to the point of the position
the operator is applied on; (3) the body of the argument
should be equal to the body of the position the operator is
applied on; (4) the reference body of the argument should
be equal to body of the position the operator is applied on;
and (5) the coordinate frame of the argument should be
equal to the point of the position the operator is applied
on. This can be visually illustrated as follows:
PositionCoord (e2|C, f|D, [r]) =
PositionCoord

e1|C, f|D,
h
r
i
.changePointPosition(
PositionCoord

e2|C, e1|C,
h
r
i
),
(1)
the semantic constraints imposed on the geometric relation
the operation is applied to, and on the operation arguments,
are shown by using the same names for the geometric
primitives when equality of the primitives is imposed,
furthermore the lines indicate ones again the geometric
primitives that should be equal to obtain a semantically
correct operation.
V. GEOMETRIC SEMANTICS DSL (M2) AND THE
TOOLING (M1)
A. External DSL
1) DSL design: The external DSL is developed using
Xcore. As this DSL is not using the java specific syntax
parts of Xcore, it can be considered as a plain text file
and therefore as an external DSL. The geometric semantics
DSL uses the Object Contraint language (OCL) DSL to
define the constraints in the geometric semantics. Defining
these constraints only requires a small set of constraints of
OCL, making it feasible (although not necessarily desired)
to eliminate the dependency on OCL with limited effort.
Next we discuss the design of the DSL in Xcore. Our
DSL consists of a ‘root’ class called ‘DomainModel’. This
DomainModel class contains DomainRules. A DomainRule
consists of ‘Primitive’, ‘GeometricRelation’, ‘Geometric-
CoordinateRelation’, ‘SemanticOperation’ and ‘Semantic-
CoordinateOperation’. Listing 1 shows the definition of
the primitive Point and the geometric (coordinate) relation
PositionSemantics and PositionCoordinateSemantics.
Listing 2 shows the definition of the PositionChange-
Point geometric operation and the constraints (defined
using OCL) to which this operation has to comply.
2) Work flow and tooling: Thanks to the Xcore support
in DSL we can make use of a Model Driven Engineering
work flow in Eclipse. The DSL can be loaded inside Eclispe
and converted into an ecore model and subsequently in
an Xtext model. The tooling (such as an editor) made
available by Xtext can be created to support the M1
level for the geometric semantics. The Xtext editor hereby
allows for semantic checking of the geometric semantics
during editing, hereby reducing application development
time since errors are detected very early.
B. Internal DSL
1) DSL design: The internal DSL is built on top of
Prolog. This way Prolog can be used to define the grammar,
and in particular the logic constraints of the geometric
semantics. Furthermore it provides a good mechanism
to provide bookkeeping of the geometric primitives and
relations in a particular application (which points, ori-
entation frames, poses, ...are defined and check if they
are uniquely defined). Listing 3 shows the definition of
the geometric (coordinate) relation Position (defining both
PositionSemantics and PositionCoordinateSemantics).
Listing 4 shows the definition of the PositionChange-
Point geometric operation and the constraints to which this
operation has to comply.
2) Work flow and tooling: The work flow is a particular
work flow based on the Prolog language. As a tool we de-
veloped our own editor that allows the DSL user to use the
syntax as proposed in the geometric semantics theory [1],
but parses it to Prolog code which is subsequently executed
in the background to do the semantic checking. This way,
similar functionality as obtained with the Xtext editor is
obtained, i.e. semantic checking is done and meaningful
error statements are produced during editing.
VI. EXAMPLE
This section illustrates how the DSL can be used to
prevent common errors in geometric calculations. To this
end we use the following semantic operations:
Position
e1|C, f|D


.changePointPosition(
Position
e2|C, e1|C


).
(2)
In the above statement the lines illustrate the constraints on
the semantic operation i.e. (we refer to the PositionCoord
to which the operator is applied to as the subject and to the
PositionCoord that is used as an argument in the operation
as the argument): 1) the point of the subject has to be
equal to the reference point of the argument, 2) the body
of the subject has to be equal to the reference body of the
Listing 1: Geometric semantics primitive and relation example in Xcore
* Root class
abstract class DomainRule{}
* Definition of primitives
abstract class Primitive extends DomainRule{}
class Point extends Primitive {String name }
* Definition of geometric (coordinate) relation Position
abstract class GeometricRelation extends DomainRule{}
abstract class GeometricCoordinateRelation extends DomainRule{}
class PositionSemantics extends GeometricRelation, SuperPosition
{
String name
refers Point [1] point
refers Body [1] body
refers Point [1] refPoint
refers Body [1] refBody
}
class PositionCoordinateSemantics extends GeometricCoordinateRelation, SuperCoordinatePosition
{
String name
@Pivot(derivation="self.positionSemantics.point")
refers derived Point point
@Pivot(derivation="self.positionSemantics.body")
refers derived Body body
@Pivot(derivation="self.positionSemantics.refPoint")
refers derived Point refPoint
@Pivot(derivation="self.positionSemantics.refBody")
refers derived Body refBody
refers PositionSemantics [1] positionSemantics
refers OrientationFrame [1] coordFrame
}
Listing 2: Geometric semantics operation example in Xcore
* Definition of PositionChangePoint semantic operation and the constraints
@Ecore(constraints="SamePoint SameBody")
@Pivot(SamePoint="if notNull then self.superPos0.superPoint = self.superPos1.superRefPoint else true endif",
SameBody="if notNull then (self.superPos0.superBody = self.superPos1.superBody and self.superPos0.superBody =←-
self.superPos1.superRefBody) else true endif")
class PositionChangePoint extends PositionOperation, SuperPosition
{
@Pivot(derivation="self.superPos1.superPoint")
refers derived Point point
@Pivot(derivation="self.superPos0.superBody")
refers derived Body body
@Pivot(derivation="self.superPos0.superRefPoint")
refers derived Point refPoint
@Pivot(derivation="self.superPos0.superRefBody")
refers derived Body refBody
@Pivot(derivation="self.superPos0 <> null and self.superPos1 <> null")
derived Boolean notNull
String name
refers SuperPosition [1] superPos0
refers SuperPosition [1] superPos1
}
Listing 3: Geometric semantics primitive and relation example in Prolog
% Definition of geometric (coordinate) relation Position
position(Name,P1,P2) :- inferBody(P1,Point1,Body1),inferBody(P2,Point2,Body2),handleParamsInit([Name,Point1,←-
Body1,Point2,Body2],position, [position,point,body,point,body]),!.
position(Name,P1,P2,OrientationFrame) :- position(Name,positionCoordinates,P1,P2,OrientationFrame).
Listing 4: Geometric semantics primitive and relation example in Prolog
changePoint(Result,Changee,Change) :- incrementLC, exists(Changee,Type1), exists(Change), constrainChangePoint(←-
Type1,Result,Changee,Change).
changePoint(Result,Changee,Change1,Change2) :- incrementLC, exists(Change1), exists(Change2), exists(Changee,←-
Type), constrainChangePoint(Type,Result,Changee,Change1,Change2).
% Constraint check for point change
checkPointChange(Point,Body,Change,NewPoint) :- getPosition(Change,position,NewPoint,NewBody,NewRefPoint,←-
NewRefBody),((NewBody = Body, NewRefPoint = Point, NewRefBody = Body) -> true ;
writeError(['Constraint error on changing point: Position(',NewPoint,'|',NewBody,',',NewRefPoint,'|',←-
NewRefBody,')',' when Position(',NewPoint,'|',Body,',',Point,'|',Body,') was expected.'])).
argument, 3) the body of the subject has to be equal to the
body of the argument, The figures below how the Xtext
(Figure 3) and Prolog-based (Figure 4) editor react on a
mistake on the first constraint in the above list. As shown
in the figures they both provide information on the kind of
error.
VII. DISCUSSION
A. Xcore versus Prolog DSL
In this section we want to highlight some advantages
and disadvantages of the Xcore and Prolog DSL for two
use cases: the DSL developer and the DSL user.
For the DSL user both the external Xcore DSL and
internal Prolog DSL currently provide an editor that offers
checking of the constraints defined in the DSL. However,
because the Xcore DSL is easy to integrate into Eclipse,
it immediately opens the way to all the tooling available
in Eclipse. An example is the nice Xtext editor for the
M1 level that can be generated in Eclipse from the Xcore
DSL. Since, the Xcore DSL is however basically a text
model, it is still possible to create any other parser or
editor. Therefore, the Xcore DSL does not create a hard
dependency on Eclipse or Xtext, while the tools of Eclipse
and Xtext can still be used when desired. The tooling
around Prolog is not as developed as around Eclipse.
Therefore, we implemented a simple editor for the M1 level
ourselves. While the editor only offers basic checking and
simple error reporting, it provides all the basic functionality
to check the constraints defined in the DSL. The Prolog
DSL has the extra advantage that uses the Prolog language,
which is already executable. Therefore, it is more easy
to create executable (Prolog) code from the M1 models
defined using the Prolog DSL.
A DSL developer has to adapt or extend the external
Xcore DSL and/or the internal Prolog DSL. The involved
syntax of the OCL constraints make the Xcore DSL harder
to ‘read’. Therefore, if the readability is an issue, it could
be decided to natively implement the constraints in Xcore
rather than using the OCL constraints. This is feasible in
this case since we only use a small subset of the available
OCL constraints. Since the Prolog syntax is quite intuitive
it makes the internal Prolog DSL easier to ‘read’.
B. Code generation: from M1 to M0
An important limitation so far is that we have no code-
generation support, i.e. the automatic transformation from
the M1 to the M0 level is lacking. In the robotics context
this is an important limitation, since we need to obtain
executable code. Moreover, preferably we want support for
different programming languages (C++, python, ...) and
execution on different types of hardware (FPGA, normal
PC, . . . ). Therefore in future work we will also look at
tools as Epsilon that allow to generate executable code.
C. Future in robotics
To ensure a future in robotics, not only code generation
for the geometric semantics DSL is essential. Moreover, we
need better support to write entire robotic applications
at the M1 level. In robotics the code typically originates
from different domains: geometry, kinematics, dynamics,
state machines, estimators, etc. Therefore, it should be
possible to write code that interleaves different DSLs. To
this end, different DSL (geometric semantics DSL, compo-
nent models, kinematic and dynamic algorithms DSL [13],
state charts [11], motion specification DSL [9]), ...) have
to be supported at the same time. Tools will have to be
developed that are composable, such that it possible to,
depending on the application, load the relevant DSLs and
to generate code from M1 specifications that are inter-
leaving code of different DSLs. Finally, the entire robotic
application developed at M1 level has to be transformed to
executable code (M0 level).
VIII. CONCLUSION
In this paper we presented both an external DSL in Xcore
and an internal DSL in Prolog for geometric relations
between rigid bodies such as relative position, orientation,
pose, linear velocity, angular velocity, and twist founded
on the geometric semantics [1], [2]. These DSLs advance
with respect to the available implementation in the general-
purpose programming language (C++) by formalizing the
underlying model of the geometric semantics. Furthermore,
we showed that these DSLs are the basis tools that assist
the robot programmers and application developers. In an
example we showed how editors built on top of the DSLs
automatically check the semantic correctness of geometric
operations on rigid-body coordinate representations while
writing and editing the code. Furthermore, it was shown
that these editors produce meaningful error statements
when semantic constraints are violated. We listed our
experiences from writing the DSL up to using the editors.
Finally, we discussed some things that are still lacking to
integrate the geometric semantics DSL into the work flow
of a robot programmer or application developer.
We believe that this paper has shown that the geometric
semantics, due to is mature but concise nature, is an
excellent example for the development of DSLs in robotics
and the use of these DSLs in the work flow of a robot
programmer or application developer.
ACKNOWLEDGEMENTS
All authors gratefully acknowledge the financial support by KU
Leuven’s Concerted Research Action GOA/2010/011, European
FP7 project Rosetta (2008-ICT-230902), European FP7 project
BRICS (2008-ICT-231940), European FP7 project RoboHow
(FP7-ICT-288533). Tinne De Laet is a Postdoctoral Fellow of
the Fund for Scientific Research–Flanders (F.W.O.) in Belgium.
Fig. 3: Xtext editor example when violating the constraint that the point of the subject has to be equal to the reference
point of the argument when applying the geometric operation changePoint.
Fig. 4: Prolog-based editor example when violating the constraint that the point of the subject has to be equal to the
reference point of the argument when applying the geometric operation changePoint.
REFERENCES
[1] T. De Laet, S. Bellens, R. Smits, E. Aertbeli¨en, H. Bruyninckx, and
J. De Schutter, “Geometric relations between rigid bodies: Semantics
for standardization,” IEEE Rob. Autom. Mag., 2012.
[2] T. De Laet, S. Bellens, and H. Bruyninckx, “Semantics underlying
geometric relations between rigid bodies in robotics,” https://retf.
info/rrfcs/0005, 2012, last visited September 2012.
[3] R. Smits, H. Bruyninckx, and E. Aertbeli¨en, “KDL: Kinematics and
Dynamics Library,” http://www.orocos.org/kdl, 2001, last visited
August 2012.
[4] Willow Garage, “Robot Operating System (ROS),” http://www.ros.
org, 2008, last visited 2012.
[5] “Robotics library,” http://sourceforge.net/apps/mediawiki/roblib.
[6] G. Biggs, K. Conley, B. Gerkey, and I. L¨utkebohle, “Robot Engi-
neering Task Force,” http://www.retf.info/, 2011.
[7] T. De Laet, S. Bellens, H. Bruyninckx, and J. De Schutter, “Geo-
metric relations between rigid bodies: from semantics to software,”
IEEE Rob. Autom. Mag., 2012.
[8] T. De Laet and S. Bellens, “Geometric semantics software,”
http://www.orocos.org/wiki/geometric-relations-semantics-wiki,
2012, last visited September 2012.
[9] M. Klotzbuecher, R. Smits, H. Bruyninckx, and J. De Schutter,
“Reusable hybrid force-velocity controlled motion specifications
with executable domain specific languages,” in Proc. IEEE/RSJ Int.
Conf. Int. Robots and Systems, San Francisco, California, 2011, pp.
4684–4689.
[10] M.
Bordignon,
U.
P.
Schultz,
and
K.
Stoy,
“Model-based
kinematics
generation
for
modular
mechatronic
toolkits,”
in
Proceedings of the ninth international conference on Generative
programming and component engineering, ser. GPCE ’10.
New
York, NY, USA: ACM, 2010, pp. 157–166. [Online]. Available:
http://doi.acm.org/10.1145/1868294.1868318
[11] M. Klotzbuecher, P. Soetens, and H. Bruyninckx, “OROCOS
RTT-Lua:
an
Execution
Environment
for
building
Real-time
Robotic
Domain
Specific
Languages,”
in
Int.
Workshop
on
DYn.
languages
for
RObotic
and
Sensors,
2010,
pp.
284–
289. [Online]. Available: https://www.sim.informatik.tu-darmstadt.
de/simpar/ws/sites/DYROS2010/03-DYROS.pdf
[12] J. B´ezivin, “On the unification power of models,” Software and
Systems Modeling, vol. 4, no. 2, pp. 171–188, 2005.
[13] M. Frigerio, J. Buchli, and D. G. Caldwell, “A Domain Specific
Language for kinematic models and fast implementations of robot
dynamics algorithms,” in Workshop on Domain Specific Languages
for Robotics, 2011.
Domain Specific Language for Geometric Relations between Rigid
Bodies targeted to robotic applications
Tinne De Laet, Wouter Schaekers, Jonas de Greef, and Herman Bruyninckx
Abstract— This paper presents a DSL for geometric rela-
tions between rigid bodies such as relative position, orien-
tation, pose, linear velocity, angular velocity, and twist. The
DSL is the formal model of the recently proposed semantics
for the standardization of geometric relations between rigid
bodies [1], [2], referred to as ‘geometric semantics’. This
semantics explicitly states the coordinate-invariant properties
and operations, and, more importantly, all the choices that
are made in coordinate representations of these geometric
relations. This results in a set of concrete suggestions for stan-
dardizing terminology and notation, allowing programmers
to write fully unambiguous software interfaces, including
automatic checks for semantic correctness of all geometric
operations on rigid-body coordinate representations.
The DSL is implemented in two different ways: an external
DSL in Xcore and an internal DSL in Prolog. Besides defining
a grammar and operations, the DSL also implements con-
straints. In the Xcore model, the Object Constraint Language
language is used, while in the Prolog model, the constraint
are natively modelled in Prolog.
This paper discusses the implemented DSL and the tools
developed on top of this DSL. In particular an editor, checking
the semantic constraints and providing semantic meaningful
errors during editing is proposed.
I. INTRODUCTION
When developing robotic applications, robot program-
mers and application developers have to deal with three-
dimensional motion and relations between rigid bodies
(manipulated objects, robot links, or mobile bases). Rigid
bodies are essential primitives in the modelling of robotic
devices, tasks and perception. Basic geometric relations
between rigid bodies include relative position, orientation,
pose (combining position and orientation), linear velocity,
angular velocity, and twist (combining linear and angu-
lar velocity). To express geometric relations and perform
mathematical operations on them (e.g. composition of
relative motion, time differentiation, or integration), robot
programmers have to choose coordinate representations
with which to perform the corresponding numerical op-
erations.
Until recently, and despite a history of over 50 years,
the geometric properties of rigid-body operations, and their
Tinne De Laet and Herman Bruyninckx are with the Department
of Mechanical Engineering, Katholieke Universiteit Leuven, Belgium.
Wouter Schaekers and Jonas de Greef are students at the Computer
Science Engineering Department, Katholieke Universiteit Leuven, Bel-
gium. Corresponding author: Tinne De Laet (Tinne.DeLaet@mech.
kuleuven.be)
coordinate representations, were not standardized, which
has led to a proliferation of mutually incompatible software
libraries, in the robot control products of commercial
manufacturers as well as in open source libraries such
as KDL (Kinematics and Dynamics Library) [3], ROS
(Robot Operating System) [4], RL (Robotics Library) [5],
.... All geometric relations and their coordinate represen-
tations entail a surprisingly large number of choices or
assumptions, which are often made implicitly, but which
are necessary to consider in view of (i) understanding the
physical meaning of the numerical values that constitute
the coordinate representation of a geometric relation and
(ii) performing physically meaningful mathematical opera-
tions on these numerical values. Not explicitly stating the
above assumptions may lead to errors in the calculations
(composition of geometric relations expressed in different
coordinate frames, composition of poses and orientation
coordinate representations in wrong order,... [1]). To al-
leviate this problem, we recently proposed semantics for
the standardization of geometric relations between rigid
bodies [1], referred to as ‘geometric semantics’. This se-
mantics explicitly states the coordinate-invariant properties
and operations, and, more importantly, all the choices that
are made in coordinate representations of these geometric
relations. This results in a set of concrete suggestions
for standardizing terminology and notation, allowing pro-
grammers to write fully unambiguous software interfaces,
including automatic checks for semantic correctness of all
geometric operations on rigid-body coordinate representa-
tions. This resulted in a Robot Request for Comments [2]
for the Robot Engineering Task Force [6]. Furthermore,
software providing a C++ implementation of the software
is developed and available as open-source [7], [8].
Domain Specific Languages are lightweight program-
ming languages designed to concisely express the con-
cepts of a particular domain. Commonly two types are
distinguished: internal and external DSLs. The former are
built on top of an existing language, while the latter are
developed from scratch resulting in a custom syntax and
making them independent from existing languages. By
reusing existing infrastructure, internal DSLs are easier
to create, maintain, and combine with other DSLs than
external ones [9]. External DSLs, while suffering from
an increased cost for creating and maintenance, are not
arXiv:1304.1346v3  [cs.RO]  10 Apr 2013
constrained by any other language. Therefore, the choice
between an internal or external design often depends on
the particular application, use case, available tools, and
preferences of the designer. In this paper we develop both
types for the geometric semantics: 1) an external DSL in
Xcore and 2) an internal DSL in Prolog.
The goal of this paper is fourfold. Firstly, we want
to build a DSL for geometric relations between rigid
bodies such as relative position, orientation, pose, linear
velocity, angular velocity, and twist founded on the geo-
metric semantics [1], [2]. This DSL advances with respect
to the available available implementation in the general-
purpose programming language C++, by formalizing the
underlying model of the geometric semantics. Furthermore,
the DSL is the basis for the developments of tools that
assist the robot programmers and application developers to
write fully unambiguous software interfaces and prevent
common errors in geometric calculations. In particular this
paper presents and editor built on top of the proposed
DSL that automatically checks the semantic correctness of
all geometric operations on rigid-body coordinate repre-
sentations, while writing and editing the code. Secondly,
we want to explore the impact of different design choices
(internal, external), work flows, and tools. Thirdly, we
believe that due to the concise and mature nature of the
underlying geometric semantics theory and its relevance
for the robotics domain it will prove to be an excellent
example for future DSL development in robotics. Fourthly,
we will highlight the unfulfilled robotic needs still present
in Model Driven Engineering.
Section II gives an overview of related work. Section IV
provides a short summary of the geometric semantics
theory relevant for this paper. Section III situates this
paper’s contributions using the four levels of abstraction
in Model Driven Engineering.
II. RELATED WORK
Since we are not aware of any DSL on the semantics for
geometric relationships between rigid bodies, our related
work will rather point to some other DSLs developed in
the robotics domain.
Frigerio et al.’s DSL is the DSL most related to the
DSL proposed in this paper. They propose a DSL for kine-
matic models and fast implementation of robot dynamic
algorithms. The DSL allows to model algorithms that
are parametrised on the kinematics/dynamics model of a
robot, hereby facilitating the generation of executable code
tailored for a specific robot. This approach only requires
the users to provide a high level description of their robot
and relieves them from hand-crafted development.
Furthermore, we want to mention the Mechatronics De-
scription Language (MDL), which is a domain-specific
language that can model the kinematic structure of individ-
ual robot modules and declaratively describe their possible
interconnections. From this description, the MDL compiler
generates the code that is needed to simulate the resulting
robots within Webots, a widely used commercial robot
simulator, and the software component needed for spatial
structure computations by a virtual machine-based runtime
system, which we have developed and use for programming
physical modular robots [10].
Klotzb¨ucher et al. [11] propose a DSL for specifying
robotic tasks using the task frame formalism as an example
of lua as a lightweight and composable metamodelling
language for specification and validation of internal DSLs.
In later work Klotzb¨ucher et al. [9]) propose a DSL
allowing to separate task specification and coordination of
these tasks using state charts.
III. LEVELS OF ABSTRACTION IN MODEL DRIVEN
ENGINEERING
Figure 1 illustrates a systematic approach to model a
certain domain in four levels of abstraction [9], [12]. These
four levels have the following meaning for the context of
the geometric semantics:
M0: the level of the concrete implementations, for instance
a particular set of geometric semantics calculations
using the C++ library of the geometric semantics [8],
M1: the level of a particular set of geometric semantics
calculations using the geometric semantics DSL,
M2: the level of the application independent geometric
semantics DSL, which provides a language for both
coordinate representation independent and dependent
(taking into account the constraints of a particular
coordinate representation) geometric calculations.
M3: the highest level of abstraction, that is, the model in
terms of which we describe our meta-models (M2).
For example, ecore that we can use to describe our
geometric semantics DSL.
The geometric semantics theory [1], summarized in
Section IV, can be considered as the basis for the M2
level DSL, as it describes (in language) the constraints
on the geometric relations semantics, the possible oper-
ations on the geometric relations, the constraints on the
relations and operations, and the constraints imposed by
particular coordinate representations. The available C++
implementation [8] and the applications implemented in
it, are examples of the M0 level.
This paper provides DSL implementations, both an
external DSL and an internal DSL, on the M2 level.
Furthermore, this paper presents tools based on the de-
veloped DSLs, that allow the DSL users to implement
their particular set of geometric semantic calculations,
i.e. to work on the M1 level. To illustrate the proposed
approach, we provide an example on a M1 implementation
metameta
model
Real-world systems
domain
model
domain
model
domain
model
metamodel
(DSL)
metamodel
(DSL)
M3
M2
M1
M0
DSL
designer
DSL
user
Conforms to
Conforms to
Conforms to
Conforms to
Conforms to
Conforms to
Conforms to
Conforms to
Conforms to
Fig. 1: The four levels of abstraction.)
for a particular geometric calculation and show how the
developed DSL and the accompanying tools will help to
prevent commonly made errors.
IV. GEOMETRIC SEMANTICS, BACKGROUND [1]
A. Geometric relations
Geometric relations between bodies are described us-
ing a set of geometric primitives1: points (e), vectors,
orientation frames ([a] , they represent an orientation, by
means of three orthonormal vectors indicating the frame’s
X-axis X, Y-axis Y , and Z-axis Z), and frames ({g}).
Figure 2 presents the geometric primitives body, point,
vector, orientation frame, and frame graphically. To help
the reader we will consistently use the following naming
for the geometric primitives to represent the geometric
relation of a body C with respect to body D in this
document: e|C, [a]|C, {g}|C, f|D, [b]|D, and {h}|D.
Table I summarizes the minimal but complete set of
geometric primitives and the (coordinate) semantics for
the geometric relations position, orientation, pose, twist
between rigid bodies, which are the most relevant relations
for this paper.
B. Semantic operations
On the geometric relations defined in Section IV-A,
semantic operations that compose the geometric relations
or that change the point, orientation frame, reference point,
reference orientation frame, or coordinate frame of the ge-
ometric relation can be applied. These semantic operations
themselves impose constraints on the geometric relation
they are applied to and on the operation arguments (which
are themselves geometric relations) of the operator. While
1This background contains a short summary of the semantics for the
standardization of geometric relations between rigid bodies, for more
details we refer to [1].
[a]
e
C
{g}
[b]
f
D
{h}
[r]
Fig. 2: The geometric relation between rigid bodies are de-
scribed using a set of geometric primitives: points, vectors,
orientation frames, and frames. The above figure shows the
geometric primitives that are useful to define the position,
orientation, pose, linear velocity, angular velocity, and twist
of body C with respect to body D: an orientation frame [a],
a point e, and frame {g} fixed to body C, an orientation
frame [b], a point f, and frame {h} fixed to body D, and
a coordinate frame [r], considered instantaneously fixed to
body D, in which the coordinates are expressed. (Extract
from [1].)
[1] provides an overview of semantic operations that can
be applied to geometric relations and lists the constraints
imposed by the operations, we will only give an example
illustrating the concept of the semantic operation and the
constraints imposed by it.
As
an
example,
consider
the
semantic
operation
to
change
the
point
used
to
describe
the
posi-
tion of body C with respect to body D. Imagine
PositionCoord (e1|C, f|D, [r]) is the semantic description
of the position of body C with respect to body D. To
change the point to describe the position from the current
point e1 to a new point e2, the position of the new
Geometric Relation
(Coordinate) semantics
Geometric primitives
Graphical representation
Position
Position (e|C, f|D)
point e
e
f
C
D
[r]
PositionCoord (e|C, f|D, [r])
body C
reference point f
reference body D
coordinate frame [r]
Position of point e fixed to body C (e|C) with respect to point f fixed to body D (f|D), expressed in coordinate frame [r]
Orientation
Orientation ([a]|C, [b]|D)
orientation frame [a]
[a]
[b]
C
D
[r]
OrientationCoord ([a]|C, [b]|D, [r])
body C
reference orientation frame [b]
reference body D
coordinate frame [r]
Orientation of orientation frame [a] fixed to body C ([a]|C) with respect to orientation frame [b] fixed to body D ([b]|D), expressed
in coordinate frame [r]
Pose
Pose ((e, [a])|C, (f, [b])|D)
point e
[a]
[b]
e
f
C
D
[r]
PoseCoord ((e, [a])|C, (f, [b])|D, [r])
orientation frame [a]
body C
reference point f
reference orientation frame [b]
reference body D
coordinate frame [r]
Pose of point e and orientation frame [a] fixed to body C ((e, [a])|C) with respect to point f and orientation frame [b] fixed to body
D ((f, [b])|D), expressed in coordinate frame [r]
Pose ({g}|C, {h}|D)
frame {g}
{g}
{h}
C
D
[r]
PoseCoord ({g}|C, {h}|D, [r])
body C
frame {h}
reference body D
coordinate frame [r]
Pose of frame {g} fixed to body C ({g}|C) with respect to frame {g} fixed to body D ({g}|D), expressed in coordinate frame [r]
Linear velocity
LinearVelocity (e|C, D)
point e
e
C
D
[r]
LinearVelocityCoord (e|C, D, [r])
body C
reference body D
coordinate frame [r]
Linear velocity of point e fixed to body C (e|C) with respect to body D, expressed in coordinate frame [r]
Angular velocity
AngularVelocity (C, D)
body C
C
D
[r]
AngularVelocityCoord (C, D, [r])
reference body D
coordinate frame [r]
Angular velocity of body C with respect to body D, expressed in coordinate frame [r]
Twist
Twist (e|C, D)
point e
e
C
D
[r]
TwistCoord (e|C, D, [r])
body C
reference body D
coordinate frame [r]
Twist of body C with velocity reference point e (e|C) with respect to body D, expressed in coordinate frame [r]
TABLE I: Minimal semantics and coordinate semantics (expressed in coordinate frame [r]) including the minimal but
complete set of geometric primitives for the position, orientation, pose, linear velocity, angular velocity, and twist of
body C with point e, orientation frame [a], and frame {g} with respect to D with point f, orientation frame [b], and
frame {h}, including a graphical representation. (extracted from [1])
point e2 fixed to body C with respect to e1 fixed to
body C and expressed in the same coordinate frame [r] is
needed, i.e. PositionCoord (e2|C, e1|C, [r]). If the semantic
operator .changePoint () is applied to the geometric relation
of which the point has to be changed (in our example
PositionCoord (e1|C, f|D, [r])) and has as an argument the
geometric relation needed to achieve this change of ref-
erence point, the .changePoint () imposes the following
constraints: (1) the argument of .changePoint () should be
a PositionCoord geometric relation; (2) the reference point
of the argument should be equal to the point of the position
the operator is applied on; (3) the body of the argument
should be equal to the body of the position the operator is
applied on; (4) the reference body of the argument should
be equal to body of the position the operator is applied on;
and (5) the coordinate frame of the argument should be
equal to the point of the position the operator is applied
on. This can be visually illustrated as follows:
PositionCoord (e2|C, f|D, [r]) =
PositionCoord

e1|C, f|D,
h
r
i
.changePointPosition(
PositionCoord

e2|C, e1|C,
h
r
i
),
(1)
the semantic constraints imposed on the geometric relation
the operation is applied to, and on the operation arguments,
are shown by using the same names for the geometric
primitives when equality of the primitives is imposed,
furthermore the lines indicate ones again the geometric
primitives that should be equal to obtain a semantically
correct operation.
V. GEOMETRIC SEMANTICS DSL (M2) AND THE
TOOLING (M1)
A. External DSL
1) DSL design: The external DSL is developed using
Xcore. As this DSL is not using the java specific syntax
parts of Xcore, it can be considered as a plain text file
and therefore as an external DSL. The geometric semantics
DSL uses the Object Contraint language (OCL) DSL to
define the constraints in the geometric semantics. Defining
these constraints only requires a small set of constraints of
OCL, making it feasible (although not necessarily desired)
to eliminate the dependency on OCL with limited effort.
Next we discuss the design of the DSL in Xcore. Our
DSL consists of a ‘root’ class called ‘DomainModel’. This
DomainModel class contains DomainRules. A DomainRule
consists of ‘Primitive’, ‘GeometricRelation’, ‘Geometric-
CoordinateRelation’, ‘SemanticOperation’ and ‘Semantic-
CoordinateOperation’. Listing 1 shows the definition of
the primitive Point and the geometric (coordinate) relation
PositionSemantics and PositionCoordinateSemantics.
Listing 2 shows the definition of the PositionChange-
Point geometric operation and the constraints (defined
using OCL) to which this operation has to comply.
2) Work flow and tooling: Thanks to the Xcore support
in DSL we can make use of a Model Driven Engineering
work flow in Eclipse. The DSL can be loaded inside Eclispe
and converted into an ecore model and subsequently in
an Xtext model. The tooling (such as an editor) made
available by Xtext can be created to support the M1
level for the geometric semantics. The Xtext editor hereby
allows for semantic checking of the geometric semantics
during editing, hereby reducing application development
time since errors are detected very early.
B. Internal DSL
1) DSL design: The internal DSL is built on top of
Prolog. This way Prolog can be used to define the grammar,
and in particular the logic constraints of the geometric
semantics. Furthermore it provides a good mechanism
to provide bookkeeping of the geometric primitives and
relations in a particular application (which points, ori-
entation frames, poses, ...are defined and check if they
are uniquely defined). Listing 3 shows the definition of
the geometric (coordinate) relation Position (defining both
PositionSemantics and PositionCoordinateSemantics).
Listing 4 shows the definition of the PositionChange-
Point geometric operation and the constraints to which this
operation has to comply.
2) Work flow and tooling: The work flow is a particular
work flow based on the Prolog language. As a tool we de-
veloped our own editor that allows the DSL user to use the
syntax as proposed in the geometric semantics theory [1],
but parses it to Prolog code which is subsequently executed
in the background to do the semantic checking. This way,
similar functionality as obtained with the Xtext editor is
obtained, i.e. semantic checking is done and meaningful
error statements are produced during editing.
VI. EXAMPLE
This section illustrates how the DSL can be used to
prevent common errors in geometric calculations. To this
end we use the following semantic operations:
Position
e1|C, f|D


.changePointPosition(
Position
e2|C, e1|C


).
(2)
In the above statement the lines illustrate the constraints on
the semantic operation i.e. (we refer to the PositionCoord
to which the operator is applied to as the subject and to the
PositionCoord that is used as an argument in the operation
as the argument): 1) the point of the subject has to be
equal to the reference point of the argument, 2) the body
of the subject has to be equal to the reference body of the
Listing 1: Geometric semantics primitive and relation example in Xcore
* Root class
abstract class DomainRule{}
* Definition of primitives
abstract class Primitive extends DomainRule{}
class Point extends Primitive {String name }
* Definition of geometric (coordinate) relation Position
abstract class GeometricRelation extends DomainRule{}
abstract class GeometricCoordinateRelation extends DomainRule{}
class PositionSemantics extends GeometricRelation, SuperPosition
{
String name
refers Point [1] point
refers Body [1] body
refers Point [1] refPoint
refers Body [1] refBody
}
class PositionCoordinateSemantics extends GeometricCoordinateRelation, SuperCoordinatePosition
{
String name
@Pivot(derivation="self.positionSemantics.point")
refers derived Point point
@Pivot(derivation="self.positionSemantics.body")
refers derived Body body
@Pivot(derivation="self.positionSemantics.refPoint")
refers derived Point refPoint
@Pivot(derivation="self.positionSemantics.refBody")
refers derived Body refBody
refers PositionSemantics [1] positionSemantics
refers OrientationFrame [1] coordFrame
}
Listing 2: Geometric semantics operation example in Xcore
* Definition of PositionChangePoint semantic operation and the constraints
@Ecore(constraints="SamePoint SameBody")
@Pivot(SamePoint="if notNull then self.superPos0.superPoint = self.superPos1.superRefPoint else true endif",
SameBody="if notNull then (self.superPos0.superBody = self.superPos1.superBody and self.superPos0.superBody =←-
self.superPos1.superRefBody) else true endif")
class PositionChangePoint extends PositionOperation, SuperPosition
{
@Pivot(derivation="self.superPos1.superPoint")
refers derived Point point
@Pivot(derivation="self.superPos0.superBody")
refers derived Body body
@Pivot(derivation="self.superPos0.superRefPoint")
refers derived Point refPoint
@Pivot(derivation="self.superPos0.superRefBody")
refers derived Body refBody
@Pivot(derivation="self.superPos0 <> null and self.superPos1 <> null")
derived Boolean notNull
String name
refers SuperPosition [1] superPos0
refers SuperPosition [1] superPos1
}
Listing 3: Geometric semantics primitive and relation example in Prolog
% Definition of geometric (coordinate) relation Position
position(Name,P1,P2) :- inferBody(P1,Point1,Body1),inferBody(P2,Point2,Body2),handleParamsInit([Name,Point1,←-
Body1,Point2,Body2],position, [position,point,body,point,body]),!.
position(Name,P1,P2,OrientationFrame) :- position(Name,positionCoordinates,P1,P2,OrientationFrame).
Listing 4: Geometric semantics primitive and relation example in Prolog
changePoint(Result,Changee,Change) :- incrementLC, exists(Changee,Type1), exists(Change), constrainChangePoint(←-
Type1,Result,Changee,Change).
changePoint(Result,Changee,Change1,Change2) :- incrementLC, exists(Change1), exists(Change2), exists(Changee,←-
Type), constrainChangePoint(Type,Result,Changee,Change1,Change2).
% Constraint check for point change
checkPointChange(Point,Body,Change,NewPoint) :- getPosition(Change,position,NewPoint,NewBody,NewRefPoint,←-
NewRefBody),((NewBody = Body, NewRefPoint = Point, NewRefBody = Body) -> true ;
writeError(['Constraint error on changing point: Position(',NewPoint,'|',NewBody,',',NewRefPoint,'|',←-
NewRefBody,')',' when Position(',NewPoint,'|',Body,',',Point,'|',Body,') was expected.'])).
argument, 3) the body of the subject has to be equal to the
body of the argument, The figures below how the Xtext
(Figure 3) and Prolog-based (Figure 4) editor react on a
mistake on the first constraint in the above list. As shown
in the figures they both provide information on the kind of
error.
VII. DISCUSSION
A. Xcore versus Prolog DSL
In this section we want to highlight some advantages
and disadvantages of the Xcore and Prolog DSL for two
use cases: the DSL developer and the DSL user.
For the DSL user both the external Xcore DSL and
internal Prolog DSL currently provide an editor that offers
checking of the constraints defined in the DSL. However,
because the Xcore DSL is easy to integrate into Eclipse,
it immediately opens the way to all the tooling available
in Eclipse. An example is the nice Xtext editor for the
M1 level that can be generated in Eclipse from the Xcore
DSL. Since, the Xcore DSL is however basically a text
model, it is still possible to create any other parser or
editor. Therefore, the Xcore DSL does not create a hard
dependency on Eclipse or Xtext, while the tools of Eclipse
and Xtext can still be used when desired. The tooling
around Prolog is not as developed as around Eclipse.
Therefore, we implemented a simple editor for the M1 level
ourselves. While the editor only offers basic checking and
simple error reporting, it provides all the basic functionality
to check the constraints defined in the DSL. The Prolog
DSL has the extra advantage that uses the Prolog language,
which is already executable. Therefore, it is more easy
to create executable (Prolog) code from the M1 models
defined using the Prolog DSL.
A DSL developer has to adapt or extend the external
Xcore DSL and/or the internal Prolog DSL. The involved
syntax of the OCL constraints make the Xcore DSL harder
to ‘read’. Therefore, if the readability is an issue, it could
be decided to natively implement the constraints in Xcore
rather than using the OCL constraints. This is feasible in
this case since we only use a small subset of the available
OCL constraints. Since the Prolog syntax is quite intuitive
it makes the internal Prolog DSL easier to ‘read’.
B. Code generation: from M1 to M0
An important limitation so far is that we have no code-
generation support, i.e. the automatic transformation from
the M1 to the M0 level is lacking. In the robotics context
this is an important limitation, since we need to obtain
executable code. Moreover, preferably we want support for
different programming languages (C++, python, ...) and
execution on different types of hardware (FPGA, normal
PC, . . . ). Therefore in future work we will also look at
tools as Epsilon that allow to generate executable code.
C. Future in robotics
To ensure a future in robotics, not only code generation
for the geometric semantics DSL is essential. Moreover, we
need better support to write entire robotic applications
at the M1 level. In robotics the code typically originates
from different domains: geometry, kinematics, dynamics,
state machines, estimators, etc. Therefore, it should be
possible to write code that interleaves different DSLs. To
this end, different DSL (geometric semantics DSL, compo-
nent models, kinematic and dynamic algorithms DSL [13],
state charts [11], motion specification DSL [9]), ...) have
to be supported at the same time. Tools will have to be
developed that are composable, such that it possible to,
depending on the application, load the relevant DSLs and
to generate code from M1 specifications that are inter-
leaving code of different DSLs. Finally, the entire robotic
application developed at M1 level has to be transformed to
executable code (M0 level).
VIII. CONCLUSION
In this paper we presented both an external DSL in Xcore
and an internal DSL in Prolog for geometric relations
between rigid bodies such as relative position, orientation,
pose, linear velocity, angular velocity, and twist founded
on the geometric semantics [1], [2]. These DSLs advance
with respect to the available implementation in the general-
purpose programming language (C++) by formalizing the
underlying model of the geometric semantics. Furthermore,
we showed that these DSLs are the basis tools that assist
the robot programmers and application developers. In an
example we showed how editors built on top of the DSLs
automatically check the semantic correctness of geometric
operations on rigid-body coordinate representations while
writing and editing the code. Furthermore, it was shown
that these editors produce meaningful error statements
when semantic constraints are violated. We listed our
experiences from writing the DSL up to using the editors.
Finally, we discussed some things that are still lacking to
integrate the geometric semantics DSL into the work flow
of a robot programmer or application developer.
We believe that this paper has shown that the geometric
semantics, due to is mature but concise nature, is an
excellent example for the development of DSLs in robotics
and the use of these DSLs in the work flow of a robot
programmer or application developer.
ACKNOWLEDGEMENTS
All authors gratefully acknowledge the financial support by KU
Leuven’s Concerted Research Action GOA/2010/011, European
FP7 project Rosetta (2008-ICT-230902), European FP7 project
BRICS (2008-ICT-231940), European FP7 project RoboHow
(FP7-ICT-288533). Tinne De Laet is a Postdoctoral Fellow of
the Fund for Scientific Research–Flanders (F.W.O.) in Belgium.
Fig. 3: Xtext editor example when violating the constraint that the point of the subject has to be equal to the reference
point of the argument when applying the geometric operation changePoint.
Fig. 4: Prolog-based editor example when violating the constraint that the point of the subject has to be equal to the
reference point of the argument when applying the geometric operation changePoint.
REFERENCES
[1] T. De Laet, S. Bellens, R. Smits, E. Aertbeli¨en, H. Bruyninckx, and
J. De Schutter, “Geometric relations between rigid bodies: Semantics
for standardization,” IEEE Rob. Autom. Mag., 2012.
[2] T. De Laet, S. Bellens, and H. Bruyninckx, “Semantics underlying
geometric relations between rigid bodies in robotics,” https://retf.
info/rrfcs/0005, 2012, last visited September 2012.
[3] R. Smits, H. Bruyninckx, and E. Aertbeli¨en, “KDL: Kinematics and
Dynamics Library,” http://www.orocos.org/kdl, 2001, last visited
August 2012.
[4] Willow Garage, “Robot Operating System (ROS),” http://www.ros.
org, 2008, last visited 2012.
[5] “Robotics library,” http://sourceforge.net/apps/mediawiki/roblib.
[6] G. Biggs, K. Conley, B. Gerkey, and I. L¨utkebohle, “Robot Engi-
neering Task Force,” http://www.retf.info/, 2011.
[7] T. De Laet, S. Bellens, H. Bruyninckx, and J. De Schutter, “Geo-
metric relations between rigid bodies: from semantics to software,”
IEEE Rob. Autom. Mag., 2012.
[8] T. De Laet and S. Bellens, “Geometric semantics software,”
http://www.orocos.org/wiki/geometric-relations-semantics-wiki,
2012, last visited September 2012.
[9] M. Klotzbuecher, R. Smits, H. Bruyninckx, and J. De Schutter,
“Reusable hybrid force-velocity controlled motion specifications
with executable domain specific languages,” in Proc. IEEE/RSJ Int.
Conf. Int. Robots and Systems, San Francisco, California, 2011, pp.
4684–4689.
[10] M.
Bordignon,
U.
P.
Schultz,
and
K.
Stoy,
“Model-based
kinematics
generation
for
modular
mechatronic
toolkits,”
in
Proceedings of the ninth international conference on Generative
programming and component engineering, ser. GPCE ’10.
New
York, NY, USA: ACM, 2010, pp. 157–166. [Online]. Available:
http://doi.acm.org/10.1145/1868294.1868318
[11] M. Klotzbuecher, P. Soetens, and H. Bruyninckx, “OROCOS
RTT-Lua:
an
Execution
Environment
for
building
Real-time
Robotic
Domain
Specific
Languages,”
in
Int.
Workshop
on
DYn.
languages
for
RObotic
and
Sensors,
2010,
pp.
284–
289. [Online]. Available: https://www.sim.informatik.tu-darmstadt.
de/simpar/ws/sites/DYROS2010/03-DYROS.pdf
[12] J. B´ezivin, “On the unification power of models,” Software and
Systems Modeling, vol. 4, no. 2, pp. 171–188, 2005.
[13] M. Frigerio, J. Buchli, and D. G. Caldwell, “A Domain Specific
Language for kinematic models and fast implementations of robot
dynamics algorithms,” in Workshop on Domain Specific Languages
for Robotics, 2011.