UiPath Community: AI for UiPath Automation Developers
A Software Product Line for Modular Robots
1. A Software Product Line for
Modular Robotics
Modular Robotics Lab, Maersk Institute
University of Southern Denmark
Mirko Bordignon Ulrik P. Schultz Kasper Stoy
DSLRob’10
Oct 22, 2010
modular.mmmi.sdu.dk
2. Fixed-topology (“traditional”) robots
Traditionally, heavily task-driven design, e.g.:
precise
manipulation
operation in environments
designed for humans
efficient
locomotion
2
So%ware
tools
adopted
to
robot
topology
or
even
to
specific
robot:
•
forwards
and
inverse
kinema;cs
•
middleware
with
components
(planning,
vision,
...)
•
DSLs?
(hopefully!)
(As
a
whole:
s;ll
working
on
it,
but
so%ware
plaGorms
are
appearing)
3. Modular robots
Key idea: trade efficiency for flexibility by building robots from kits
Versatility
- adapt on-line to changing conditions
- fulfill different tasks with the same hardware
Robustness
- cope with unanticipated failures
- many identical and virtually replaceable
modules: no single points of failure
Cost-effectiveness
- mass-produce many simple units instead of fewer more complex parts
3
4. Modular robots: challenges
• Complexity: every module includes sensors,
actuators, control electronics
– distributed
system
– behavior
must
adapt
to
spa;al
composi;on
– coupling
and
robustness?
• Variation: many module designs
– producing a good module design is tricky
– manually computing kinematics for each assembly
is not feasible
4
5. Dealing
with
complexity:
languages,
layers
and
abstrac;ons
5
So
far:
specific
to
ATRON
(mostly)
How
to
generalize?
Opera;ng
system
abstrac;ons:
TinyOS
components
Execu;on
plaGorm:
DCD-‐VM
[Robocomm'07,ICRA'09]
High-‐level
language:
DynaRole
[ICRA'09]
Robust
&
Reversible
extension
[IROS'09]
ATRON
6. Dealing
with
varia;on?
• Different
modular
robots:
– different
kinema;cs
both
for
simula;on
and
VM
– different
physical
proper;es
in
simulator
– different
high-‐level
spa;al
abstrac;ons
• Limited
tool
support
for
most
modular
robots
6
Idea:
generate
tools
from
model-‐based
descrip;on
of
robot
7. Model? The Modular Mechatronics
Modelling Language (M3L)
Modular mechatronic toolkits:
a set of mechatronic units and of possible ways
to interconnect them to build robots
the ATRON modular system:
- each module consists of two half-spheres that can
rotate about each other through an actuated joint
- four gendered connectors on each hemisphere allow
connections to up to 8 other modules
- 32 possible connections between two modules
The (rigid) connections
enforce precise relative positioning
between the connected modules:
for instance, their joint axes will be
orthogonal
7
[GPCE’10]
8. M3L example: ATRON model
module ATRON:
point c0: coords=(0,1,-1),gender=“male”,extended=[bool]
point …
link north: grouping=(c0,c1,c2,c3)
link south: grouping=(c4,c5,c5,c7)
axis north_axis: origin=(0,0,0), direction=(0,1,0)
axis south_axis: origin=(0,0,0), direction=(0,-1,0)
joint center: type=revolute, value=[-inf,inf],
pair=((north,north_axis),(south,south_axis))
This is all the information we need to calculate the kinematics of this simple 2-links mechanism, i.e.,
the position of each point of interest under the reference frame of each link, given the joint value val.
e.g., c0 coords in the south link’s frame = (0,1,-1) rotated around the (0,1,0) axis by val
8
9. connection ATRON_to_ATRON:
members=(ATRON a, ATRON b)
conditions=( (a.point p_a coincident b.point p_b)
and ((p_a.gender==“male” and p_b.gender==“female”
and p_a.extended==true)
or (p_a.gender==“female” and p_b.gender==“male”
and p_b.extended==true))
This is (almost) all the information we need to enter
for the M3L compiler to compute the possible
connections between two ATRON modules and the
reference frame transformations that they induce.
les of how
ove within
rajectory
planning.
figuration
planning
ace of a
shortest
is seen
s solved
s to pass
planning
deciding
mple 3D
dules for
d motion
on prob-
ch where
rmediate
ation the
figuration
Fig. 2. Left: Picture of a single meta-module. The meta-module consists
of four ATRON modules placed in a square. Right: Screen shot from the
simulator showing the square grid structure of the meta-modules.
Fig. 3. The three basic actions of a meta-module. There is no constraints
upon the presence or absence of meta-modules in the light gray squares. It
should be noted that in the move illustrated in the rightmost figure the two
non-moving meta-modules are connected by the moving module throughout
the entire move.
can move another module by connecting to it and rotating.
The design is such that one module is capable of lifting two
other modules. A complete description of the module design
can be found in [11].
A. ATRON Simulator
The work presented in this paper involves the control
and (a.north_axis orthogonal b.north_axis) )
9
M3L example: ATRON model
10. An ATRON assembly = links belonging to different modules connected together through
a) intra-module joints
b) rigid inter-module connections
Knowing the frame transformations induced by a) and b),
we can compute the full kinematic description of a robot assembled
from ATRON modules, much like we would do for e.g. a robot arm
robot atron_arm:
modules=(ATRON a1,ATRON a2,
ATRON a3,ATRON a4,
ATRON a5),
connections=((a1.c1,a2.c4),
(a2.c2,a3.c7),
(a3.c1,a4.c4),
(a4.c2,a5.c7))
automatically generated
Webots simulation
(more on that later)
10
M3L example: ATRON model
11. 11
M3L model of a modular kit
(modules & connections)
kinematic structure of single modules
(easy, explicitly input by user)
connections
simulations
physical robots
kinematics description
generate the combinations through cartesian products of the
concrete instance sets that the user constraints evaluate to
Determine the transformation for each connection
Generate condition sets for the possible
connections from user-input constraints
geometric constraints solver
(“assembly mating” approach)
avoid generating spurious sets through nested bindings
(details in GPCE'10 paper)
M3L robots
Webots
backend
DCD-VM
backend
DynaRole
backend
[Bordignon’10]
12. Generation of Webots simulations
Webots:
widely used (commercial) robot simulator
supports modular robot
uses a subset ofVRML97
Scene graph
Root = global scene / environment frame
Children nodes = contained bodies, with spatial
relationships determined by
translation / rotation fields
Advantages of M3L-generated simulations:
- no need to create aVRML model for a module
- automatic determination of the initial position
of each module within the scene
- no manual computation and composition of
transformations
12
DEF module__a1 Robot {
name "1"
controller "rdcd_controller"
translation 0 0.278 0
rotation 1.0 0.0 0.0 0
...
children [
DEF joint__ATRON_center Servo {
type "rotational"
name "ATRON_center"
translation 0.0 0.0 0.0
rotation 0.0 -0.039 0.0 0
...
}
]
...
}
DEF module__a2 Robot {
name "2"
controller "rdcd_controller"
translation 0.0 0.2 0.078
rotation -0.5773502691 -0.5773502691
0.5773502691 2.0943951023
...
14. DCD-VM & DynaRole
DCD-VM:
runtime environment serving as the programming substrate for a high-level
programming language for ATRON modular robots (DynaRole)
[RoboComm’07, ICRA’09]
role Head extends Module {
require (self.center == $NORTH_SOUTH);
…}
abstract role Wheel extends Module {
require (self.center == $EAST_WEST);
require (sizeof(self.connected(connected_direction)) == 1);
…}
role RightWheel extends Wheel {connected_direction = $WEST;}
role LeftWheel extends Wheel {connected_direction = $EAST;}
RightWheel
Key language feature supported by theVM: queries about the physical structure of the robot
14
M3L: Generate C code for distributed forward kinematics on the DCD-VM:
- a source module broadcasts its transformation to a global frame
- connected modules receive and compose the transformation with
- the one induced by the connection with the transmitting module
- those eventually introduced by joints
15. Conclusion
&
Future
work
• Problem:
complexity
and
varia;on
• Solu;on:
languages
and
models
(M3L)
• S;ll
missing:
– physics
for
simula;on
– API
(bridging
to
simulator/TinyOS
components)
– inverse
kinema;cs
– support
for
USSR
simula;on
environment
– more
modular
robots!
15
16. M3L: declarative definition of connections
members=(ATRON a, ATRON b)
conditions=( (a.point p_a coincident b.point p_b) and
( (p_a.gender==“male” and p_b.gender==“female”)
or (p_a.gender==“female” and p_b.gender==“male) )
… )
1. Enumerate each atomic expression over the possible values of its left and right hand sides
2. Merge the results of compound expressions according to the joining connective
NB: the name binding mechanism avoids the generation of spurious constraints! (see paper)
c0 coincident c0
c0 coincident c1
c0 coincident c2
…
c0.gender==“male” and c0.gender==“female”
c0.gender==“male” and c1.gender==“female”
…
c0.gender==“female” and c0.gender==“male”
c0.gender==“female” and c1.gender==“male”
…
c0 coincident c1,c0.gender==“male”,c1.gender==“female”
c0 coincident c1,c0.gender==“female”,c1.gender==“male”
AND:
both
condi;ons
need
to
hold
on
the
SAME
constraints
set
OR:
only
one
condi;on
needs
to
hold,
generate
two
different
constr.
sets
16
17. M3L: geometric constraints solver
Once a number of conditions sets have been generated:
1. we prune those containing non-geometric constraints (e.g., on connectors’ gender)
that cannot be satisfied
2. for the remaining ones, we infer as many new geometric constraints as possible
3. we then try to determine the transformations that relate the frame of a connection
member to the frame of the other member (and vice versa).
Given a fixed body, we need to determine the position in space of a second one so as to
satisfy all the geometric constraints relating the two bodies: i.e., we need to fix 6 DOFs.
What does that mean in practice ?
To do so, we use geometric constraints applying the “coincident”,“parallel” and
“orthogonal” operators to geometric elements. Furthermore, the solver generates new
constraints from the inputted ones based on combination rules.
E.g., if two axes coincide and two surfaces coincide as well, it infers that the points resulting
from the pairwise intersection of the axes and surfaces must coincide as well.
17