A Software Product Line for Modular Robots


Published on

Published in: Technology
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

A Software Product Line for Modular Robots

  1. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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 ...
  13. 13. 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 !
  14. 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. 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. 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. 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