A Functional Language for Programming Self-Reconfigurable ... - SDU

Chapter 6

A Functional Language for Programming Self-Reconfigurable Robots1 Ulrik P. Schultz, Mirko Bordignon, David Christensen, Kasper Stoy2 Category: Research Paper

Abstract: A self-reconfigurable robot is a robotic device that can change its own shape. Self-reconfigurable robots are commonly built from multiple identical modules that can manipulate each other to change the shape of the robot. The robot can also perform tasks such as locomotion without changing shape. Programming a modular, self-reconfigurable robot is however a complicated task: the robot is essentially a real-time, distributed embedded system, where control and communication paths often are tightly coupled to the current physical configuration of the robot. To facilitate the task of programming modular, selfreconfigurable robots, we are currently developing a functional, domain-specific language that allows the programmer to use pattern matching and higher-order functions to program closely coordinated groups of modules. In more detail, higher-order functions are used to specify behaviors that are applied to groups of modules and a distributed pattern matching mechanism is used to select specific behaviors from these functions depending on the state of the individual modules. We have implemented our language for a virtual machine running on the ATRON self-reconfigurable robot.

1 Presented

at TFP’08, published in the preliminary proceedings Robotics Group, University of Southern Denmark, Campusvej 55, DK-5230 Odense M, Denmark, {ups,mirko,david,kaspers}@mmmi.sdu.dk 2 Modular

VI–1

VI–2 6.1

CHAPTER 6. SELF-RECONFIGURABLE ROBOTS INTRODUCTION

A self-reconfigurable robot is a robot that can change its own shape. Self-reconfigurable robots are built from multiple identical modules that can manipulate each other to change the shape of the robot [2, 6, 7, 10, 12, 15, 19, 18]. The robot can also perform tasks such as locomotion without changing shape. Changing the physical shape of a robot allows it to adapt to its environment, for example by changing from a car configuration (best suited for flat terrain) to a snake configuration suitable for other kinds of terrain. Programming self-reconfigurable robots is however complicated by the need to (at least partially) distribute control across the modules that constitute the robot and furthermore to coordinate the actions of these modules. Algorithms for controlling the overall shape and locomotion of the robot have been investigated (e.g. [3, 16]), but the challenge of providing a high-level programming platform for developing controllers remains an open issue. In this paper, we present ideas for a functional approach to programming a controller for a modular robot system independently of the concrete physical structure of the robot. Higher-order functions are used to specify sets of behaviors that are applied to multiple robot modules. Pattern matching is then used to select specific behaviors based on the physical state of each module and that of its neighbors. The physical state of a module is abstracted by the role of the module; a role is a common abstraction in modular robots that serves to indicate the functionality of the individual module depending on its context [17]. Our functional programming language uses a declarative approach to defining the set of roles used on a robot, similarly to type declarations in a traditional functional language. Our language targets the distributed control diffusion virtual machine (DCD-VM) running on the ATRON modular, self-reconfigurable robot [7, 9, 13].3 Organization: The rest of this paper is organized as follows. First, Section 6.2 describes the ATRON self-reconfigurable robot and an existing object-oriented style ATRON programming language. Then, Section 6.3 presents the main contribution of this paper, namely the initial design of a functional programming language for the ATRON robot. Implementation details are described afterwards in Section 6.4, and last Section 6.5 discusses the main issues raised by this paper. 6.2 6.2.1

BACKGROUND: ATRON AND THE RDCD LANGUAGE The ATRON Self-Reconfigurable Robot

The ATRON self-reconfigurable robot is a 3D lattice-type robot [7, 9]. Figure 6.1 shows an example ATRON car robot built from 7 modules. Two sets of wheels (ATRON modules with rubber rings providing traction) are mounted on ATRON modules playing the role of an axle; the two axles are joined by a single module 3 Note

that due to implementation constraints, all experiments reported in this paper are performed in simulation on a virtual machine capable of running on the physical modules.

6.2. BACKGROUND: ATRON AND THE RDCD LANGUAGE

FIGURE 6.1.

VI–3

The ATRON self-reconfigurable robot, real and simulated cars

playing the role of “connector.” This car robot can change its shape to become a snake (a long string of modules). An ATRON module has one degree of freedom, is spherical with two hemispheres, and can actively rotate the two hemispheres relative to each other. A module may connect to and communicate with neighbor modules using eight mechanical connectors equipped with infrared ports (the infrared ports also serve to detect nearby obstacles). The single rotational degree of freedom of a module makes its ability to move very limited: the help of another module is always needed to achieve movement. A module has 128K of externally programmable flash memory for storing programs and 4K of RAM for use during execution of the program. 6.2.2

The RDCD Language

A first attempt at providing a high-level language for the ATRON is the Rolebased Distributed Control Diffusion (RDCD) language. RDCD is inspired by object-oriented programming: each role is declared similarly to a class [14]. RDCD targets the DCD-VM, a virtual machine for ATRON modules that supports distributed control diffusion: controller code is dynamically deployed to those modules where a specific behavior is needed [13]. The virtual machine provides a number of services, such as broadcast communication with role-based addressing and tracking the relative spatial orientation of each module. RDCD however exhibits the typical problem of object-oriented languages [4, 8, 11]: RDCD is well-suited to expressing gradual refinement of role behaviors for individual modules, but is ill-suited to expressing behaviors that span several modules. We have observed that when a small number of modules are collaborating in a well-defined way, programming the modules in a low-level language is often done using a form of distributed state machine where different steps of the same program are executed in turn on each of the modules to orchestrate the overall behavior of the robot. Such a state machine is however difficult to program and moreover tends to be closely tied to the specific configuration of the robot. As an alternative to this low-level approach, we are proposing the use of a functional language that uses pattern matching to abstract over the concrete configuration of the robot and higher-order functions to activate parameterized behaviors on

VI–4

CHAPTER 6. SELF-RECONFIGURABLE ROBOTS

different modules depending on their role. Moreover, to facilitate interactive experiments with the ATRON modules, we are interested in providing an interactive language, which is often more easily done with a functional language than with a class-based object-oriented language. 6.3

A FUNCTIONAL ATRON PROGRAMMING LANGUAGE

We propose a functional ATRON programming language (simply abbreviated FAPL) with the following features: (1) the role hierarchy is declaratively defined, (2) higher-order functions are applied to the modules that constitute the robot and pattern matching on roles selects what behaviors (if any) to run on each module, and (3) event handlers are described declaratively using pattern matching. The language is envisioned as a domain-specific language for scripting coordinated behaviors in ATRON robots. See Section 6.5 for considerations on providing a general-purpose language. 6.3.1

Role Hierarchy

The role hierarchy can be described as a tree where the nodes are boolean expressions that range over the physical state of each module and that of its neighbors, the latter as abstracted by the role of the neighboring modules. A child node describes a more specific role that refines the parent role, and hence the role selection mechanism always descends as far as possible into the tree structure. For example, for the car robots shown in Figure 6.1, part of the role hierarchy (wheels and axles) could be defined as follows: role | | | |

Wheel (Module x) = (center_position EAST_WEST x) and ... LeftWheel (Wheel x) = sizeof (connected WEST x)=1 RightWheel (Wheel x) = sizeof (connected EAST x)=1 Axle (Module x) = sizeof (connected_role DOWN Wheel x)>0 ...

Here, the spatial orientation of the central axis and the number of connections and their roles are used to describe the hierarchy [13, 14]. In more detail, initially all modules play the role of Module which is the root of the role selection tree (meaning that it does not yet have a specific role). Such a module can change role to a Wheel when the central axis is perpendicular (east-to-west) to the orientation of the robot and a number of other conditions (not shown) are also fulfilled. A module already playing to role of a Wheel can subsequently change to be a LeftWheel or a RightWheel depending on how it is connected to the rest of the robot. This declaration also gives rise to a form of subtyping in terms of pattern matching, since a pattern matching Wheel will also match any child in the role selection hierarchy. As a first prototype we are currently envisioning a dynamically typed language, the issue of whether static typing can be useful in the context of a functional scripting language for modular robots is considered future work. Likewise,

6.3. A FUNCTIONAL ATRON PROGRAMMING LANGUAGE

VI–5

selection of roles is not currently required to be unambiguous, i.e., the boolean conditions of two branches in the role hierarchy are not required to be mutually exclusive. For a first prototype we can simply provide a well-defined evaluation order, the issue of statically verifying mutual exclusiveness is considered future work. 6.3.2

Pattern Matching and Higher-Order Functions

Pattern matching on roles is used to select specific behaviors to run on the modules. As an example, consider movement of the wheels of the robot. The left and right wheels must turn in opposite directions (clockwise and counterclockwise) to propel the robot in a forwards direction. Such an operation can be expressed using pattern matching on the role of the module, as follows: fun moveWheel speed (LeftWheel w) = @turnContinuous speed w | speed (RightWheel r) = @turnContinuous -speed w

The function moveWheel can be used to initiate forwards movement of any wheel using the built-in function @turnContinuous which controls the central motor of the ATRON module. To apply this function to all modules of the robot, we use the built-in function apply* which applies its argument (a closure) too all modules in the robot. Thus, any “car” robot can be made to move forward using the expression apply* (moveWheel 1)

In more detail, by using apply* the closure containing the speed at which to move is applied to every module by using pattern matching to select correct behaviors. Note that unlike standard pattern matching the function application is simply ignored for modules that are not playing the role of a wheel. We imagine a general form of pattern matching that can match multiple modules in specific configurations, similarly to pattern matching for graphs [5]. Note that a simple naming convention is used to distinguish user-defined functions from primitive functions that operate on the module they are evaluated on (these are prefixed with the @ character) and primitive functions that operate on all modules (these are postfixed with the * character). 6.3.3

Event Handlers

Event handlers are used to spontaneously trigger actions in the robot as response to stimulus from the environment. For example, encountering an obstacle should trigger an obstacle evasion behavior. Event handlers can also be specified using pattern matching, for example for triggering the evasion behavior: handle Proximity (LeftWheel w) LeftProximity = apply* evade | (RightWheel w) RightProximity = apply* evade

The variables LeftProximity and RightProximity are used to denote constants that identify the infrared port that is facing forwards on the respective mod-

VI–6


Experimental setup

Approaching obstacle

Stopped

Reverse and turn

Moving forward again

New obstacles!

Stopped (again)

Reverse and turn (again)

FIGURE 6.2. Obstacle avoidance scenario to be resolved using the controller program of Figure 6.3.

ules. The event Proximity is triggered when an obstacle is nearby, and will in this case cause the function evade to be applied to the modules of the robot. 6.3.4

Complete Example

As a complete example of a controller program written in FAPL, consider obstacle evasion where any appropriately car-shaped ATRON robot should behave as illustrated in Figure 6.2: drive forwards, approach an obstacle, stop, reverse while turning, and continue driving forwards. The program shown in Figure 6.3 implements such a controller. The controller program includes constants (defined using val), functions, and role definitions. The constants define specific attributes of the modules that are used for controlling use of the proximity sensor, as described below. The role declarations define wheels (left and right), axles (front and rear), as well as a special “mixin” role that can be “mixed” with other roles. Mixin roles can be assumed temporarily by modules using the special form letrole. This role change can be observed by neighboring modules and causes the module to match the mixin role. Role declarations can be partial, indicated by the corresponding keyword, meaning that they are never assigned to modules but can be used for pattern matching. Movement can be initiated by invoking the function move with an argument indicating the speed, the rest of the controller is reactive based on triggering of the proximity sensor mounted on each module (the constants LeftWheelProximity and RightWheelProximity are used to identify the proximity sensors that are pointing forwards). When an obstacle is detected by the proximity sensor, the event Proximity is triggered, causing the function evade to be invoked on all modules in the robot. The function evade is defined for modules playing the role of wheels: when applied it causes them to temporarily assume the mixin role Reverse. This change of role is observes by the axles through the event handler

6.3. A FUNCTIONAL ATRON PROGRAMMING LANGUAGE

VI–7

val LeftWheelProximity = EVENT_1 val RightWheelProximity = EVENT_5 fun stop () = apply* @centerStop role Wheel (Module x) partial = (center_position EAST_WEST x) and (sizeof (total_connected x)=1) and (sizeof (connected UP x)=1) | LeftWheel (Wheel x) = sizeof (connected WEST x)=1 | RightWheel (Wheel x) = sizeof (connected EAST x)=1 | Axle (Module x) partial = sizeof (connected_role DOWN Wheel x)>0 | FrontAxle (Axle x) = sizeof (connected NORTH x)=0 | RearAxle (Axle x) = sizeof (connected SOUTH x)=0 | Reverse (Module x) = mixin fun turn degrees (FrontAxle a) = @turnTo degrees a | degrees (RearAxle a) = @turnTo -degrees a fun moveWheel speed (LeftWheel w) = @turnContinuous speed w | speed (RightWheel r) = @turnContinuous -speed w fun evade (Wheel w) = letrole (Reverse w) in moveWheel -1 ; sleep_turns 3 end | (Reverse w) = () handle Proximity (LeftWheel w) LeftWheelProximity = apply* evade | (RightWheel w) RightWheelProximity = apply* evade handle ContextChange (Axle a) (Reverse w) = turn 30 | (Axle a) (Wheel w) = turn 0 fun move speed = apply* (moveWheel speed) handle RoleChange (LeftWheel w) = moveWheel 1 w | RoleChange (RightWheel w) = moveWheel 1 w

FIGURE 6.3. tax)

Obstacle evasion for cars (manually prettyprinted from abstract syn-

VI–8


Program Unit Value Function Alternate Parameter Constant Role Handler Exp

::= ::= ::= ::= ::= ::= ::= ::= | ::= ::= | |

Unit* Value | Function | Role | Handler | Exp val Name equals Exp fun Name Pattern+ equals Exp Alternate* bar Parameter+ equals Exp VarName | nil | ( RoleName Name ) | Constant ValueName | Integer role Name ( RoleName VarName ) partial? equals Exp role Name ( RoleName VarName) equals mixin handle EventName Parameter* equals Exp Alternate* Exp Exp+ | letrole (RoleName VarName) in Exp end Exp ; Exp | Exp binop Exp | unop Exp | ( Exp ) Constant

VarName, RoleName, ValueName ∈ Name FIGURE 6.4.

Abstract syntax in BNF for FAPL

for ContextChange, causing them to turn by an appropriate number of degrees to make the car turn while reversing. When the car stops reversing the wheels stop assuming the role Reverse and the axles respond by turning back to their previous position. At the time of writing this example is however only partially supported by the current implementation of our FAPL compiler, and is moreover only available in abstract syntax that is fed directly to the compiler. The program shown in Figure 6.3 has been manually prettyprinted from this abstract syntax. See Section 6.4 for a discussion of the implementation. 6.3.5

Abstract Syntax and Informal Semantics

The abstract syntax for FAPL is outlined in Figure 6.4. A program is a sequence of units: values, functions, roles, event handlers, and expressions. The program is transmitted to a single module in the robot; expressions are evaluated locally in the module, all other unit types are available in all modules of the robot and must hence be deployed to the rest of the robot when they are first received. Programs are dynamically typed and new units can be added interactively to a running program already deployed to the modules of the robot. A value definition represents a constant that must be computable at compiletime, that is, the expression that defines the value can only refer to other previously defined constants and can only use simple operators. A function has a name and a number of bodies each guarded by a pattern. Functions are mutually recursive. A function is always invoked with a specific module as a target, if a pattern matches the corresponding body is evaluated. As a special case, the primitive function apply* allows a function to be applied to all modules of the robot. Pattern matching not only allows constants to be used as guards and variables to be bound, but also allows the role of the module to be

6.4. IMPLEMENTATION

VI–9

used as a condition. Currently, only a single pattern specifying the role of the module itself is allowed (see Section 6.5 for a generalization). A pattern with a role constraint will only match the remaining arguments if the role constraint also matches the current state of the module. A role has a name, a required role, and an expression that defines the invariant(s) of the role. For a module to assume a given role, the invariants of the required role must be fulfilled as well as the invariants of the role itself, effectively structuring the set of roles into a hierarchy with the initial role Module as the root. Role selection is continuous as the shape of the robot may evolve through self-reconfiguration as the program is running. A partial role is never assigned to a module, and mixin roles can only be assigned by explicitly changing the role using the special form letrole explained below. (Writing a set of roles as a single block, as done in the examples, is simply syntactic sugar for a sequence of role definitions.) An event handler names (using a constant) a specific event that it handles. The handler defines a number of bodies guarded by patterns, similarly to functions. An event handler is essentially a function that is implicitly invoked when a specific event occurs, although multiple role constraints are allowed in the pattern. Depending on the event type, one or more of the role constraints are used to match the state of other modules in the structure. Concretely, in the case of role changes, the role of the module observing the role change as well as the role of the neighboring module that performed the role change can be specified. Expressions can be function applications that evaluate either to values or closures. The special form letrole lets the module temporarily assume the given role while evaluating the expression body. This role assumption is unconditional, that is, independent of the invariants, modifies the behavior of the module while it is in place, and is signaled to the neighboring modules using the DCD-VM notification mechanism. Expressions can be sequenced using the ; operator meaning they are performed in sequential order, the value of the sequence is the value of the last expression. 6.4

IMPLEMENTATION

We have implemented a compiler for a limited subset of FAPL: role declarations and function definitions with pattern matching on the role of the module. Event handlers and value declarations are not currently supported, but we expect that they are easy to implement using the existing infrastructure of the RDCD compiler which already includes provisions for generating bytecode from similar declarations in RDCD. The DCD-VM has been extended to support a limited form of higher-order functions: fully general closures are not needed for the complete obstacle evasion example shown earlier in Figure 6.3, rather being able to pass functions (primitive or user-defined) as arguments is sufficient. The FAPL compiler simply compiles partial applications to anonymous functions. Moreover, functions currently always take exactly one argument in addition to pattern matching on the role of the module (functions taking multiple arguments are then curried

VI–10


and compiled as separate functions, which is problematic due to the lack of support for general closures but happens to be sufficient for the target example). In more detail, a role declaration compiles to a small mobile program fragment that traverses the modules of the robot structure using the primitives provided by the DCD-VM. For each module, the invariant expression is evaluated, and if it evaluates to true, the role is set accordingly using the appropriate DCD-VM primitive. A function declaration compiles to multiple program fragments, one for each body. Each program fragment traverses the module structure and installs itself as a user-defined command on those modules that match the role designated by the corresponding pattern (which is the root role Module for those functions that do not explicitly specify a role restriction in their pattern). The DCD-VM supports invoking the same user-defined command on all modules of the robot that are currently playing a specific role, which provides a simple way of implementing the apply* primitive. If the robot reconfigures the roles and functions currently need to be redeployed, which means that the program fragments that were used to diffuse their definitions must be cached by one or more modules in the robot; this facility is however considered future work. The FAPL compiler shares the same backend as the RDCD compiler. The output currently is a C program fragment that emulates transmitting the FAPL programs to a module. Reprogramming this module then serves to reprogram the rest of the robot. We are currently adding a new backend to the FAPL/RDCD compiler to support outputting the compiled program as binary packets that can be transmitted to the DCD-VM interactively. We expect that extending the FAPL compiler to completely support the obstacle evasion example will be unproblematic; the DCD-VM already now provides the required functionality. Supporting a more unrestricted implementation of FAPL, for example allowing any number of arguments to a function, implementing pattern matching on the values passed as arguments, and supporting closures should be possible using standard functional programming techniques. Supporting closures will nevertheless require statically handling the associated memory management issues, which is considered future work. In general, the severe resource constraints of the ATRON modules will severely limit the complexity of the programs that can run on the virtual machine: there is at best 2.5K of available RAM for storing bytecode programs. For this reason, we expect that programming will primarily concern reaction and coordination patterns that do not involve datastructures and therefore can run without the use of a normal heap. Functions and closures that are stored in modules throughout the robot structure can perhaps be garbage collected when the interactive front end determines that they are not needed any more, but such memory management is considered future work: currently existing definitions that are redefined can be overwritten on the modules by reusing the same memory slot.

6.5. DISCUSSION 6.5

VI–11

DISCUSSION

In earlier work, we have proposed that programs running on the DCD-VM be used for interactive experiments [13, 14], whereas more stable code can be compiled to native code that is stored in the 128K of available flash memory. This approach is compatible with our proposed functional language: once tested, stable functionality can be compiled to C code that then runs efficiently and with no significant RAM overhead. Moreover, complex functionality that cannot run in the available RAM using standard techniques for compiling functional languages can in an initial prototype be implemented using C code. The issue of investigating to what extent an interactive general-purpose language can be implemented on the ATRON modules is considered future work. Using functional-style yet distributed pattern matching on the module structure to select behaviors is non-trivial to implement. Nevertheless, for our initial prototype we delimit pattern matching to only concern a module and its immediate neighbors. Since the DCD-VM automatically maintains information about the neighbor roles, we expect that this particular pattern matching will be possible to implement efficiently. Arbitrary pattern matching, e.g., determining whether a set of modules distributed throughout the structure plays a certain set of modules, is probably more general that what is required in practice. Concretely, we plan to support those forms of pattern matching that turn out to be useful in realistic control examples, taking inspiration from pattern matching for graphs [5]. A common style of programming for writing robot controllers is behaviorbased control, where the behavior of the robot is a direct function of the input it receives from its sensors [1]. The entire obstacle evasion example program of Section 6.3.4 is written using behavior-based control. A more local example is the behaviors of the axles in the obstacle evasion program: the axles simply react to role changes in their environment. Behavior-based control is typically very robust and works in many different kinds of environments. FAPL however only supports behavior-based control written using event handlers. Alternatively, one could imagine expressing the behavior of a module or perhaps even the entire robot as a set of functions that are continuously invoked with the state of the modules and the inputs to their sensors as an argument. The evaluation of these functions would then control the behavior of the modules of the robot. This form of control is explicitly supported on a single-module basis in the RDCD language in the form of behavior methods, but are considered future work for FAPL.

REFERENCES [1] R. Brooks. A robust layered control system for a mobile robot. IEEE Journal of Robotics and Automation, 2:14–23, Mar. 1986. [2] A. Castano and P. Will. Autonomous and self-sufficient CONRO modules for reconfigurable robots. In Proceedings of the 5th International Symposium on Distributed Autonomous Robotic Systems (DARS), pages 155–164, Knoxville, Texas, USA, 2000.

VI–12


[3] D. Christensen and K. Stoy. Selecting a meta-module to shape-change the ATRON self-reconfigurable robot. In Proceedings of IEEE International Conference on Robotics and Automations (ICRA), pages 2532–2538, Orlando, USA, May 2006. [4] W. R. Cook. Object-oriented programming versus abstract data types. In REX workshop on Foundations of Object-Oriented Languages, number 489 in LNCS. SpringerVerlag, 1990. [5] M. Erwig. Functional programming with graphs. In ICFP’97: Proceedings of the second ACM SIGPLAN international conference on Functional programming, pages 52–65, New York, NY, USA, 1997. ACM. [6] S. Goldstein and T. Mowry. Claytronics: A scalable basis for future robots. Robosphere, Nov. 2004. [7] M. W. Jorgensen, E. H. Ostergaard, and H. H. Lund. Modular ATRON: Modules for a self-reconfigurable robot. In Proceedings of IEEE/RSJ International Conference on Robots and Systems (IROS), pages 2068–2073, Sendai, Japan, Sept. 2004. [8] S. Krishnamurthi, M. Felleisen, and D. Friedman. Synthesizing object-oriented and functional design to promote re-use. In Proceedings of ECOOP 1998, number 1445 in LNCS. Springer-Verlag, July 1998. [9] H. Lund, R. Beck, and L. Dalgaard. Self-reconfigurable robots with ATRON modules. In Proceedings of 3rd International Symposium on Autonomous Minirobots for Research and Edutainment (AMiRE 2005), Fukui, 2005. Springer-Verlag. [10] S. Murata, E. Yoshida, K. Tomita, H. Kurokawa, A. Kamimura, and S. Kokaji. Hardware design of modular robotic system. In Proceedings of the IEEE/RSJ International Conference on Intelligent Robots and Systems (IROS), pages 2210–2217, Takamatsu, Japan, 2000. [11] J. C. Reynolds. User-defined types and procedural data as complementary approaches to data abstraction. In S. A. Schuman, editor, New Directions in Algorithmic Languages, IFIP Working Group 2.1 on Algol. INRIA, 1975. Reprinted in D. Gries, editor, Programming Methodology, Springer-Verlag, 1978, and in C. A. Gunter and J. C. Mitchell, editors, Theoretical Aspects of Object-Oriented Programming, MIT Press, 1994. [12] D. Rus and M. Vona. Crystalline robots: Self-reconfiguration with compressible unit modules. Journal of Autonomous Robots, 10(1):107–124, 2001. [13] U. Schultz. Distributed control diffusion: Towards a flexible programming paradigm for modular robots. In Proceedings of the First International Conference on Robot Communication and Coordination (ROBOCOMM2007). ACM, Oct. 2007. [14] U. Schultz, D. Christensen, and K. Stoy. A domain-specific language for programming self-reconfigurable robots. In APGES 2007 — Automatic Program Generation for Embedded Systems — Workshop Proceedings, pages 28–36, Oct. 2007. [15] W.-M. Shen, M. Krivokon, H. Chiu, J. Everist, M. Rubenstein, and J. Venkatesh. Multimode locomotion via superbot robots. In Proceedings of the 2006 IEEE International Conference on Robotics and Automation, pages 2552–2557, Orlando, FL, 2006. [16] K. Stoy. How to construct dense objects with self-reconfigurable robots. In Proceedings of European Robotics Symposium (EUROS), pages 27–37, Palermo, Italy, May 2006.

6.5. DISCUSSION

VI–13

[17] K. Stoy, W.-M. Shen, and P. Will. Implementing configuration dependent gaits in a self-reconfigurable robot. In Proceedings of the 2003 IEEE international conference on robotics and automation (ICRA’03), pages 3828–3833, Tai-Pei, Taiwan, Sept. 2003. [18] M. Yim. A reconfigurable modular robot with many modes of locomotion. In Proceedings of the JSME international conference on advanced mechatronics, pages 283–288, Tokyo, Japan, 1993. [19] M. Yim, D. Duff, and K. Roufas. Polybot: A modular reconfigurable robot. In Proceedings of the IEEE International Conference on Robotics and Automation (ICRA), pages 514–520, San Francisco, CA, USA, 2000.