## Continue your professional development with Scribd

Exclusive 60 day trial to the world's largest digital library.

Join 1+ million members and get unlimited* access to books, audiobooks.

Cancel anytime.

Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our User Agreement and Privacy Policy.

Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our Privacy Policy and User Agreement for details.

Successfully reported this slideshow.

Like this presentation? Why not share!

Just added to SlideShare
##
Continue your professional development with Scribd

Exclusive 60 day trial to the world's largest digital library.

Join 1+ million members and get unlimited* access to books, audiobooks.

Cancel anytime.

No Downloads

Total views

1,246

On SlideShare

0

From Embeds

0

Number of Embeds

1

Shares

0

Downloads

16

Comments

0

Likes

1

No notes for slide

- 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 efﬁcient locomotion 2 So%ware tools adopted to robot topology or even to speciﬁc 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 efﬁciency for ﬂexibility by building robots from kits Versatility - adapt on-line to changing conditions - fulﬁll 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: speciﬁc 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? • Diﬀerent modular robots: – diﬀerent kinema;cs both for simula;on and VM – diﬀerent physical proper;es in simulator – diﬀerent 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. ﬁguration 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 ﬁguration 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 ﬁgure 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 ﬁelds 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. 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. 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 deﬁnition 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 diﬀerent 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 satisﬁed 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 ﬁxed 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 ﬁx 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

No public clipboards found for this slide

Be the first to comment