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

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)  

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  

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  

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  

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  

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]  

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  

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.

Fig. 1. A small picture sequence illustrating the basic principles of howone ATRON module is dependent upon the others in order to move withinthe cluster. The connections between modules are not shown.

to divide the planning problem into three layers. Trajectoryplanning, configuration planning and task-level planning.Algorithms for both trajectory planning and configurationplanning is presented. The algorithm proposed for planningthe trajectory of a single Molecule on the surface of agroup of Molecules is a variation of Dijkstra’s shortestpath algorithm where the surface of the structure is seenas a graph. The configuration planning problem is solvedby introducing meta-modules, which allow modules to passthrough the structure, such that the configuration planningproblem is reduced to a matching problem, of decidingwhich meta-module should move where, and a simple 3Dmanhattan routing problem.In [10] Rus and Vona use 16 module meta-modules for

the Crystalline robot as the basis for a centralized motionplanning algorithm for the general self-reconfiguration prob-lem. The algorithm is based on a melt-grow approach wherethe initial configuration is first melted into an intermediateconfiguration and from this intermediate configuration thegoal configuration is grown. The intermediate configurationused is a simple line configuration.We will later show that the proposed meta-module effec-

tively reduces the motion constraints of the ATRON robotto be quite similar to a 2D version of the sliding cube stylemodules used by Butler in [17] and Støy in [18]. This allowsthese algorithms to be transferred to the ATRON robot usingthe proposed meta-module.The distributed control algorithm presented in this paper

uses some inspiration from the work on the Fracta robot byMurata et al. In [2] a completely distributed control algorithmis presented. In this algorithm each module decides whetherto move or not based completely on local information. Ifa module decides to move it moves randomly. The resultsshow that the algorithm is able to reconfigure small groupsof Fracta modules, however, deadlocks did occur in sometrails.

III. ATRONThe robot platform used for this work is the ATRON

robot which is a lattice-based modular self-reconfigurablerobot system consisting of homogeneous modules. The basicmodule design is based on two hemispheres connected by arotational joint. Further, each hemisphere is equipped withfour connectors, two male and two female; the male/femaleconnector design is chosen for mechanical reasons. The mod-ules are equipped with infra red transmitters and receiversused for both local communication and sensing obstacles inclose proximity of the module. Figure 1 shows how a module

Fig. 2. Left: Picture of a single meta-module. The meta-module consistsof four ATRON modules placed in a square. Right: Screen shot from thesimulator showing the square grid structure of the meta-modules.

Fig. 3. The three basic actions of a meta-module. There is no constraintsupon the presence or absence of meta-modules in the light gray squares. Itshould be noted that in the move illustrated in the rightmost figure the twonon-moving meta-modules are connected by the moving module throughoutthe entire move.

can move another module by connecting to it and rotating.The design is such that one module is capable of lifting twoother modules. A complete description of the module designcan be found in [11].

A. ATRON SimulatorThe work presented in this paper involves the control

of more ATRON modules than the 100 we currently havebuilt. To explore scalability and speed up the time used forexperiments a simulator for the ATRON system is used.The simulator is an efficient transition based simulator,

which is able to simulate self-reconfiguration with morethan 5000 ATRON modules. The different timing issues aresimulated by running the simulator in time steps, and at everytime step the controllers of the modules are simulated oneat a time in random order, described as the D1 activationscheme in [17]. The simulator contains routines for collisiontesting which handles both module/module collisions andmodule/environment collisions. The simulator contains nosimulation of real-world physics such as friction, stabilityetc.

IV. META-MODULE

In this paper we propose a new meta-module for theATRON robot. The purpose of the meta-module is to reducethe complexity of self-reconfiguration control for the ATRONrobot by reducing the complexity of the motion constraintsof the modules. The proposed meta-module consists of fourATRON modules connected in a square configuration. Apicture of a single meta-module can be seen in Figure 2along with an illustration of the orthogonal 4-connected 2Dgrid formed by the meta-modules.One of the key features of the proposed meta-module is

its high degree of symmetry and simple motion constraintswhich reduces the complexity of the self-reconfiguration

and (a.north_axis orthogonal b.north_axis) )

9  

M3L example: ATRON model

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  

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]  

Generation of Webots simulations Webots: widely used (commercial) robot simulator supports modular robot uses a subset of VRML97

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 a VRML 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 ...

Examples of generated simulations 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))

robot mtran_quadruped:

modules=(MTRAN m1,MTRAN m2,MTRAN m3,MTRAN m4,MTRAN m5,\ MTRAN m6,MTRAN m7,MTRAN m8,MTRAN m9),\

connections=((m1.c2,m2.c5),(m2.c2,m3.c5),(m3.c2,m4.c5),\ (m2.c3,m5.c4),(m3.c6,m5.c3,3),\ (m6.c2,m7.c5),(m7.c2,m8.c5),(m8.c2,m9.c5),\ (m7.c1,m5.c6),(m8.c4,m5.c1,35))

robot molecube_couple: modules=(molecube m1, molecube m2),\ connections=(m1.side_4,m2.side_4,75)

13  

ATRON Webots model: 532 LOCs

Webots simulation: 2816 LOCs (World desc. + 5*532)

ATRON Webots model: 34 LOCs

Webots simulation: 5062 LOCs !

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 the VM: 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

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  

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 c0c0 coincident c1c0 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  

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