Modular Robot Task Functionality Driven by Hybrid Automata

978-1-5090-6190-7/16/$31.00 ©2016 IEEE

Modular Robot Task Functionality Driven by Hybrid

Automata

Kazi Mashfique Hossain; Carl A. Nelson*

University of Nebraska-Lincoln Lincoln, NE, USA * [email protected]

Prithviraj Dasgupta; José Baca

Omaha, NE, USA

Abstract— Reconfigurability, reproduction and self-healing are unique behaviors found in the field of modular robotics. These tasks require docking or coupling and reorganizing of modules to form different configurations according to the task requirements. For successful task achievement, efficient information sharing between the modules, better perception of configuration and well-structured motion sequence or docking are very important. In a scenario where sharing resources between different configurations is a priority, it is crucial to have a well-defined, energy-efficient, task-specific and effective strategy of operation. This paper presents a method to (1) discover the topology of a given structure by a master module in a recursive manner, (2) share the information with another master module to compare the utility of current or future configurations and (3) make a successful docking attachment. These all use automata theory to minimize calculation overhead. The first two methods were tested in simulation for an arbitrary ModRED II (Modular Robot for Exploration and Discovery) configuration with nine modules that uses serial communication between modules, and the third was validated in hardware.

Keywords— Automata; Modular Robots; Configuration Detection; Task Adaptation

I. INTRODUCTION

Robots have become an integral part of present life, making life easier in a variety of application domains where human performance of tasks is undesirable or challenging. Robots have become a part of the assembly and manufacturing industry for their desirable characteristics such as precision and repeatability. As science and technology advance, robots are designed and fabricated for new tasks like household jobs; for example, robots are used for vacuum cleaning and even in the place of human workers, such as receptionists. Beyond these convenience-driven applications, challenging environments such as space, unstructured planetary terrains, and urban search and rescue missions constitute a significant segment of robot application. This field involves a great deal of uncertainty and new challenges which are difficult to address using conventional robot designs. This kind of application requires task-specific design and algorithms, but also features such as multi-tasking, modular design, robustness, and re-configurability [1], so that one modular robot can connect with another one and form different shapes according to the current need. This approach is known as

modular self-reconfigurable robots (MSR). Using unit-modular robots, even if one module is not working anymore, that part of the robot structure can be replaced by another healthy module [2]. A modular robot is defined as one that is “built from several physical independent units that encapsulate some of their complexity and functionality” [3]. In order to change its configuration, the robot system should first know its current configuration, i.e., the number of modules attached to it and how they are arranged.

This problem has been identified in the research community, and several solution techniques have been proposed using graph representation of the robot configuration [4-6]. These methods can be divided into centralized and distributed controllers. A centralized controller has all the information and it generates (broadcasts) the signal (instruction) to reconfigure, while in a distributed controller approach, each member (module) works as an independent controller and shares the information about the overall configuration. Sometimes the system can be assisted by an external computer like in the CONRO system [7]. Using an assembly incidence matrix (AIM), a centralized master may collect the IDs from all the modules and their neighbors and represent them in a matrix [8]. Baca et al. presented a real-time distributed configuration discovery approach for modular self-reconfigurable robots that enables each module to build the topology simultaneously, and they can detect changes in connection between robots in real-time [9].

In the modular robotics literature, automata theory has occasionally been used to implement distributed, low-cost execution of tasks. We are aware of the use of automata for self-reconfiguration [10, 11] and gait generation (locomotion) [12]. However, this approach can be applied to a variety of other tasks and has not yet been fully exploited in modular robotics.

The proposed method in this paper requires a master module to follow a Deterministic Finite State Automaton (DFSA) to discover the topology. This method decreases the computational overhead by using a neighbor-to-neighbor passing technique, in this case an Identifying Immediate Root for each module which uses connector-specific information (CSI) along with the module IDs. In this method, the connector has its own ID and it saves and passes the information about the neighboring module(s). This method not

only tells which module is connected to which module but it also tells ‘how’. The next challenge arises when two separate configurations compete for the same module, i.e., while deciding to change the current configuration after communicating with a separate configuration. A method for this is also proposed here using DFSA. Finally, a hybrid automaton was applied to model and verify the docking mechanism.

II. MODREDIIMODULE DESCRIPTION

A. The Module

The robotic modules used in this work are known as Modular Robots for Exploration and Discovery (ModRED) [13]. ModRED II is the second generation with added docking connectors, better processing capability, and three different types of communication (radio, infrared and wired). Each module has 4 degrees of freedom (DOF) and docking connectors on 4 sides. Each DOF and each connector mechanism is actuated by digital servomotors. The design of each connector includes a single-sided docking mechanism, which enables a healthy module to detach itself from a faulty one [13]. The docking mechanism has a rotary plate in which there are four specially designed hermaphroditic locking fingers. The fingers are placed in a circular array on the plate and the identical edges of the pegs are oriented at 90 degrees from each other. A set of pegs and holes are used to avoid counter-rotation of the modules during docking and to maintain alignment. Each module has two Li-ion battery packs as its power supply. A BeagleBone Black single-board computer (BBB) serves as the controller for each module. There is the option for wireless communication through XBee or Wi-Fi modules that are compatible with BBB. Every docking connector is equipped with an infrared transmitter and receiver to allow proximity sensing, enable localization strategies and facilitate local communication. In addition to these, serial communication is enabled by the four alignment features on each docking face: two of the four pegs have spring-loaded connector pins and the other two have holes with metal plates. One of the pegs works as an RX pin while one of the holes works as a TX pin.

Fig. 1. The layout of the module ModRED II and the position of connectors on the module.

B. Denomination of the module connectors

Each module has six faces and four connectors. Two of the connectors are at the two ends of the module and the other two are on two sides. The segment that holds the side connectors has the capability of continuous rotation whereas the other DOFs have limited range of motion. To correctly identify the orientation of the module, it is important to label each side or face with respect to a fixed feature on the module. The face covering the controller and motor control circuit is defined as the top, and the side close to the rotary segment is identified as the front (see Fig. 1). The rest of the faces are consequently identified as left, right, bottom and back. This enumeration helps to identify, store and share the orientation information for each connector on a given module. The usefulness of tracking this information will become apparent later in this paper.

III. THEORY OF DFSA AND HYBRID AUTOMATA

A. Deterministic Finite State Automata (DFSA)

A deterministic finite state automaton (DFSA) is a finite state machine that accepts/rejects finite strings of symbols and produces a unique computation of the automaton for each input string [14]. It consists of a 5-tuple: D = (Q, Σ, δ, q0, F), where: x Q = finite non-empty set of state (nodes)

x Σ = finite non-empty alphabet

x q0 א Q = initial state. This is indicated by a source-less arrow coming into a state.

x F ك Q = finite, and possibly empty set of final states at which the machine reports that the string processed so far is a member of the language it accepts. If one exists, typically two circles indicate the “accept” state in the graphical representation.

x δ = Q × Σ → Q (total transition function). This is presented as a table for present state and subsequent inputs.

B. Hybrid Automata

A hybrid system contains both continuous dynamics and discrete mode/state changes (jumps) [15]. A hybrid automaton is a collection H = {V, X, f, Init, Inv, Jump} where:

x V = {v1, v2, …, vm} , m ≥ 1 are the discrete control modes representing discrete dynamics.

x X = {x1, x2,…, xn} is a finite set of real-numbered variables. The number n is called the dimension of H. x Init ؿ V × X describes the possible initial states of H. x Inv ؿ V × X is the reachable set of states x א Rn when the

mode of H is v א V. H may only stay in any mode v while the invariant condition is true.

x Jump: (V × X) → P (V × X) where P = power set of (V × X). A jump condition specifies if a jump from one control mode is possible, and if so, what new value is assigned to X.

This is also explained in the form of the directed graph of the corresponding hybrid automaton. For example, the regulation of temperature by a thermostat is represented in Fig. 2.

The thermostat regulates the temperature, x, around 76° by turning the heater on when x is between 70° and 72° and turning the heater off when x is between 82° and 84°. The heating rate varies by state, and ݒ ൌ ሼݒ௢ǡ ݒଵሽ.

IV. METHODS

In this paper, a computationally efficient solution for the following challenges is sought:

x Perception of current configuration.

x If meeting another configuration, how to determine whether a module (or modules) is to be shared/exchanged. x Implementation of steps for successful docking or

undocking sequence. A. Perception of configuration

A master module of a certain configuration should have the information about all the robot modules connected to it. The information should contain the modules’ own ID (MOID), orientation and relative position in the configuration. By knowing this information, the master will have a clear idea of the whole configuration and it will be able to send actuation signals to the specific modules to obtain a certain configuration. To discover the network, it is a general practice to use search algorithms, but here we bypass the computational overhead of the search algorithm by passing the ID of the preceding module as the immediate root ID (IRID) and immediate-immediate root ID (IIRID) from the master to the end module. It should be mentioned that the master module may have any position in the configuration. The steps are as follows:

Step 1: The master sends its ID to the adjacent modules. Step 2: The adjacent modules save the ID as the immediate root, toggle a Boolean to mark the ID as saved (ID saved Boolean - ISB) and each sends its own ID and its IRID to its adjacent modules as their immediate root.

…

Step n: This iterates until each of the modules has its immediate root’s ID.

Exceptions:

(i) If any of the adjacent modules already received its IRID, it does not accept the new ID. In Fig. 2 module I does not accept module H’s ID as its immediate root.

(ii) If one of the modules is passed two immediate roots, it simply saves the first one. In Fig. 2 module G is approached by module F and module H; module G saves only the ID of module F as IRID because it was received first.

With this messaging procedure, the master can eventually determine if all modules are reached. Each module will have nine Booleans (in Fig. 4) for this operation; of these, six are

responsible for triggering the event of sending orientation and configuration data back to the master. We will call it End Reach Signal (ERS). The first one of this series (End Reached Boolean = ERB) is to let its immediate master know if the process of getting data from all 4 connectors is complete. This Boolean becomes true iff the five others are true.

Fig. 3. A configuration with 10 modules (A-J) and one master (red) is shown here. The numeric annotation represents the sequence of messaging events.

The second one (ID sent Boolean = IDSB) is set true if the ID is sent to the adjacent modules. The remaining four Booleans wait to be turned true based on the feedback from the adjacent modules. These four Booleans correspond to the four connectors of the module. These Booleans are toggled to true based on the following rules:

x If an ERS is received.

x If the connector is disconnected.

x If the connected module is the master of the current module.

x If the connected module has a master and it is different from the current module.

This is done by using the remaining three Booleans. In this way when the end module of the configuration is reached the corresponding signal and configuration data travels back to the master. Each module sends out the data that consists of its MOID and the IDs of modules connected to specific ports. This dataset is eventually passed upwards through the immediate roots to the master module.

Fig. 5. The ERS consists of 6 Booleans. The magenta represents the ERB, the green represents IDSB and the remaining four are ERS received from the adjacent modules.

Once the master module has collected the information from all the modules it can manipulate the data to build the adjacency matrix as in [9] and use it to obtain the next configuration or calculate task utility for the current configuration. This method also provides the information about how the modules are oriented, which enables the master to become aware of the configuration kinematics. The DFSA for this process is shown in Fig. 6.

Fig. 6. The states are defined as, A: read, B: save IRID, C: send MOID, D: send out ERB.

B. Exchange of a module between two configurations

The next subtask is to decide if a module should be exchanged from one configuration to another. Here, we propose a hybrid automaton to carry out the task. The hybrid automaton in Fig. 5 models two master modules (each representing the goals or task of its respective configuration) competing for resources (modules). Initially, Master 1 approaches Master 2. After establishing a connection between the two configurations, each of the Master modules calculates the task utility ‘μ’ (here μ1 and μ2); task utility ‘μ’ can depend

on different parameters including battery life, the given task description, DOF, number of modules attached to it, etc. In this instance we leave the process of calculating the value of ‘μ’ as separate work outside the scope of this paper and approach the remainder of the problem without loss of generality. The maximum value of ‘μ’ can be defined based on the scenario or application. In this instance the maximum value of ‘μ’ is defined as ‘5’. Jump conditions are defined based on the difference between the utility variables ‘μ1’ & ‘μ2’. The

threshold difference is set at ‘2’. An invariant condition is set to “μ1 ≤ μ2” for Master 2 controller and “μ1 > μ2” for Master

1 controller. This means if both of the utilities have the same value, the master with a higher ID wins. This value is set arbitrarily to avoid uncertainty due to having the same utility values. This process also minimizes energy loss due to

unnecessary movement of the modules. The control signal is presented as ‘μC1’ and ‘μC2’ which corresponds to ‘Master 1’

and ‘Master 2’. This means if ‘Master 1’ wins, it takes control of the module they were competing for and makes it a part of its own configuration.

Fig. 7. Automaton compares utilities to decide the wining master module.

C. Docking Method

After making successful connections, two modules can maintain their docking status (i.e., remain docked or undocked) or change the status (i.e., initiate a new docking or undocking operation). So, the docking principle has three states: (1) dock, (2) maintain current state, and (3) undock. The states themselves are continuous but change between them is discrete, which introduces a hybrid nature for the system. Once the decision of docking, maintaining status, or undocking is made by the master module, the connector is in one of these states at a given time. It should be mentioned that the design of the docking mechanism allows single-sided docking, which means one of the modules can perform the actions unilaterally.

The method is explained with a hybrid automaton in Fig. 6. The variables ‘U’ and ‘H’ are decided based on the health or task utility of the module as described in the previous section. The status ‘U’ always triggers the event ‘undock’ and the status ‘H’ triggers the event ‘dock’. Once docking or undocking is done, the status is maintained using the jump condition ‘Ө’. ‘Ө = 180’ means the servomotor has travelled to its furthest angular position and the docking has been accomplished, whereas ‘Ө = 0’ indicates the opposite. Here,

x V = {Dock,Undock, Maintain} , x X = {Ө1,Ө2}, f(Dock,x) = {ൣߠሶ൧ ൌ ሾ݂ሺߠǡ Ͳሻሿ}, f(Undock,x) = {ൣߠሶ൧ ൌ ሾ݂ሺߠǡ ͳͶͲሻሿ}, and f(Maintain,x) = {ൣߠሶ൧ ൌ ሾ݂ሺߜሻሿ}, x Jump = ሼሺܦ݋ܿ݇ሻǡ ሺܷ݊݀݋ܿ݇ሻǡ ሺܯܽ݅݊ݐܽ݅݊ሻǡ ݂݅ܵݐܽݐݑݏ ൌ ܪ ת ߠ ൌ Ͳ ݂݅ܵݐܽݐݑݏ ൌ ܷ ת ߠ ൌ ͳͶͲ ݂݅ܵݐܽݐݑݏ ൌ ܪ ת ሺߜ ൌ ͳͶͲ ׫ ߜ ൌ Ͳሻሽ

V. MODEL TESTING AND RESULTS

A. Configuration detection

The method proposed here is basically sharing of information across robot modules in a well-defined sequence based on automata. The method is tested in simulation using an example configuration shown in Fig. 3.

TABLE 1. OUTWARD MESSAGING FROM THE MASTER MODULE; COLOR SHOWS TRANSMITTED INFORMATION.

Module Time Instance 0 Time Instance 1 A 1 0 1 0 1 0 0 0 0 1 0 1 0 1 0 0 0 0 B 0 0 0 0 0 0 0 0 0 1 0 1 0 1 0 0 0 0 C 0 0 0 0 0 0 0 0 0 1 0 1 0 1 0 0 0 0 E 0 0 0 0 0 0 0 0 0 1 0 1 0 1 0 0 0 0 F 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 G 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 H 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 I 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 J 0 0 0 0 0 0 0 0 0 1 0 1 0 1 0 0 0 0 Module Time Instance 2 Time Instance 3

A 1 0 1 0 1 0 0 0 0 1 0 1 0 1 0 0 0 0 B 1 0 1 0 1 0 0 0 0 1 0 1 0 1 0 0 0 0 C 1 0 1 0 1 0 0 0 0 1 0 1 0 1 0 0 0 0 E 1 0 1 0 1 0 0 0 0 1 0 1 0 1 0 0 0 0 F 1 0 1 0 1 0 0 0 0 1 0 1 0 1 0 0 0 0 G 0 0 0 0 0 0 0 0 0 1 0 1 0 1 0 0 0 0 H 1 0 1 0 1 0 0 0 0 1 0 1 0 1 0 0 0 0 I 1 0 1 0 1 0 0 0 0 1 0 1 0 1 0 0 0 0 J 1 0 1 0 1 0 0 0 0 1 0 1 0 1 0 0 0 0

TABLE 2. THE SENDING OF MESSAGES INWARD FROM END MODULE TO THE MASTER.

Module Time Instance 0 Time Instance 1 A 1 0 1 0 1 0 0 0 0 1 0 1 0 1 0 0 0 0 B 1 0 1 0 1 0 0 0 0 1 0 1 0 1 0 0 0 0 C 1 0 1 0 1 0 0 0 0 1 0 1 0 1 0 0 0 0 E 1 0 1 0 1 0 0 0 0 1 0 1 0 1 0 0 0 0 F 1 0 1 0 1 0 0 0 0 1 0 1 1 1 1 1 1 1 G 1 0 1 1 1 1 1 1 1 1 0 1 1 1 1 1 1 1 H 1 0 1 0 1 0 0 0 0 1 0 1 1 1 1 1 1 1 I 1 0 1 0 1 0 0 0 0 1 0 1 1 1 1 1 1 1 J 1 0 1 0 1 0 0 0 0 1 0 1 0 1 0 0 0 0 Module Time Instance 2 Time Instance 3

A 1 0 1 0 1 0 0 0 0 1 0 1 0 1 1 1 1 1 B 1 0 1 1 1 1 1 1 1 1 1 0 1 1 1 1 1 1 C 1 0 1 1 1 1 1 1 1 1 1 0 1 1 1 1 1 1 E 1 0 1 1 1 1 1 1 1 1 1 0 1 1 1 1 1 1 F 1 0 1 1 1 1 1 1 1 1 0 1 1 1 1 1 1 1 G 1 0 1 1 1 1 1 1 1 1 0 1 1 1 1 1 1 1 H 1 0 1 1 1 1 1 1 1 1 0 1 1 1 1 1 1 1 I 1 0 1 1 1 1 1 1 1 1 0 1 1 1 1 1 1 1 J 1 0 1 1 1 1 1 1 1 1 0 1 1 1 1 1 1 1

This configuration has 9 modules and 1 master module. The algorithm is able to inform the modules about their immediate roots and enable the modules to share their connector ID along with the information associated with it. The change in the state of the Booleans (as listed in Fig. 4) during IRID propagation from the master throughout the configuration structure is shown in Table 1, and the return travel of ERS is shown in Table 2.

The transmitted adjacency matrix data for the 9-module configuration in Fig. 2 is shown in Table 3. The matrices are found by compiling all the locally detected matrices together at each time step.

B. Resource sharing across configurations

Next, we test the model for the module exchange scenario. Two configurations, each with its master module, are given tasks which require certain numbers of DOF, number of modules, and module health (battery life). When a module in

TABLE 3. CONFIGURATION DETECTION FOR EXAMPLE CONFIGURATION. EACH MODULE INDICATES ITS RELATION WITH THE NEIGHBORING MODULES (USING DOCKING CONNECTOR NUMBERS) IN THE RESPECTIVE COLUMNS.

Time Instance 0 A B C E F G H I J A 0 0 0 0 0 0 0 0 0 B 0 0 0 0 0 0 0 0 0 C 0 0 0 0 0 0 0 0 0 E 0 0 0 0 0 0 0 0 0 F 0 0 0 0 0 0 0 0 0 G 0 0 0 0 3-3 0 1-3 0 0 H 0 0 0 0 0 0 0 0 0 I 0 0 0 0 0 0 0 0 0 J 0 0 0 0 0 0 0 0 0 Time Instance 1 A B C E F G H I J A 0 0 0 0 0 0 0 0 0 B 0 0 0 0 0 0 0 0 0 C 0 0 0 0 0 0 0 0 0 E 0 0 0 0 0 0 0 0 0 F 0 0 0 0 0 3-3 0 0 0 G 0 0 0 0 3-3 0 1-3 0 0 H 0 0 0 0 0 3-1 0 1-1 2-3 I 0 0 3-3 0 0 0 1-1 0 4-4 J 0 0 0 0 0 0 0 0 0 Time Instance 2 A B C E F G H I J A 0 0 0 0 0 0 0 0 0 B 2-1 0 0 0 0 0 0 0 0 C 0 0 0 0 0 0 0 3-3 0 E 4-2 0 0 0 0 0 0 0 0 F 0 0 0 0 0 3-3 0 0 0 G 0 0 0 0 3-3 0 1-3 0 0 H 0 0 0 0 0 3-1 0 1-1 2-3 I 0 0 3-3 0 0 0 1-1 0 4-4 J 1-3 0 0 0 2-1 0 3-2 4-4 0 Time Instance 3 A B C E F G H I J A 0 1-2 4-2 2-3 0 0 0 0 3-1 B 2-1 0 0 0 0 0 0 0 0 C 4-2 0 0 0 0 0 0 3-3 0 E 3-2 0 0 0 0 0 0 0 0 F 0 0 0 0 0 3-3 0 0 1-2 G 0 0 0 0 3-3 0 1-3 0 0 H 0 0 0 0 0 3-1 0 1-1 2-3 I 0 0 3-3 0 0 0 1-1 0 4-4 J 1-3 0 0 0 2-1 0 3-2 4-4 0

one configuration meets a module in another configuration, each sends a message to its master module, which calculates the utility and returns this value to the respective module. The automaton of Fig. 7 is then used to decide whether to give away one module from one configuration to the other. In this example, we apply an arbitrary user-defined function to calculate task utility based on these parameters:

ui = (task_DOFi)(avg_module_healthi)/(config_DOFi) (2) Modules are assigned arbitrary health values and tasks for the simulation. We assume master MO with modules K,L,M,N

approaches master MA with modules B,C,E,F,G,H,I,J. Both of

the masters then check respectively the utility of receiving and retaining module ‘C’. After it is decided to exchange module ‘C’, the exchange of module ‘I’ is also considered. The result is summarized in Table 4.

TABLE 4. CALCULATION OF UTILITY FOR RESOURCE SHARING

MA MO

DOF required for the task 32 32

Initial utility, before establishing connection

Initial avg. module health 5 7

DOF gained/retained 36 24

Utility 4.4 9.3

Utility for module ‘C’

Avg. module health 4.5 6

DOF gained/retained, with module ‘C’ 36 28

Utility 4 6.9

Decision: uO – uA > 2, UCO ; module ‘C’ goes with master ‘MO’

Utility for module ‘I’ given that module ‘C’ is already exchanged

Avg. module health 5 5.5

DOF gained/retained, with module ‘I’ 36 32

Utility 5 5.5

Decision: UO – UA < 2; master is not changed.

After the utility is calculated by the masters, the utility values are sent to the modules, which use the automaton to decide whether to separate from or remain with the respective master. In Fig. 9, module ‘C’ is exchanged to master ‘MO’.

(a) (b)

Fig. 9. Module exchange between configurations based on calculated utility.

C. Docking experiment

Just as modules ‘N’ and ‘C’ docked and modules ‘C-I-MA’ undocked in the previous example, we have demonstrated the use of the proposed docking automaton (Fig. 8) to achieve this. In ModRED II using the RoGenSid docking connector [13], under Arduino control, the docking and undocking process was successfully demonstrated (see Fig. 10).

VI. CONCLUSIONS

In this paper, we have demonstrated methods for configuration detection, resource sharing (module exchange), and docking in modular robots using automata. This extends

the previously limited applications of automata in modular robots to facilitate task adaptation. The prospective benefits include decreased computational cost of distributed robot operations. Future work includes further experimental verification and extension of automata to govern different low-level tasks in modular robots.

Fig. 10. Successful automaton-based docking using ModRED II modules.

REFERENCES

[1] V. Zykov, E. Mytilinaios, B. Adams, H. Lipson, “Robotics: Self-reproducing machines,” Nature 435.7039, pp. 163-164, 2005.

[2] B. Piranda, G.J. Laurent, J. Bourgeois, C. Clévy, S. Möbes, N. Le Fort-Piat, “A new concept of planar self-reconfigurable modular robot for conveying microparts,” Mechatronics 23.7 (2013): 906-915.

[3] K. Stoy, D. Brandt, D. J. Christensen, “An Introduction to Self-Reconfigurable Robots,” (2010).

[4] I.-M. Chen and G. Yang, “Configuration independent kinematics for modular robots,” in Proc. IEEE Int. Conf. on Robotics and Automation, vol. 2, 22-28, 1996, pp. 1440 –1445.

[5] J. Baca, A. Yerpes, M. Ferre, J. A. Escalera, and R. Aracil, “Modelling of modular robot configurations using graph theory,” in Proc. Int. Conf. on Hybrid Artificial Intelligence Systems, 2008.

[6] V. Rai, A. Van Rossum, and N. Correll, “Self-assembly of modular robots from finite number of modules using graph grammars,” in 2011 IEEE/RSJ International Conference on Intelligent Robots and Systems (IROS), Sept 2011, pp. 4783–4789.

[7] A. Castano and P. Will, “Representing and discovering the configuration of CONRO robots,” in Proceedings IEEE International Conference on Robotics and Automation, vol. 4, 2001, pp. 3503–3509.

[8] M. Park, S. Chitta, A. Teichman, and M. Yim, “Automatic configuration recognition methods in modular robots,” Int. J. Robotics Research, vol. 27, no. 3-4, pp. 403–421, Mar. 2008.

[9] J. Baca, B. Woosley, P. Dasgupta, C. Nelson, “Real-Time Distributed Configuration Discovery of Modular Self-reconfigurable Robots,” 2015 IEEE International Conference on Robotics and Automation (ICRA), pp. 1919-1924, DOI: 10.1109/ICRA.2015.7139449

[10] K. Stoy, “Using cellular automata and gradients to control self-reconfiguration,” Robotics and Auton. Sys., vol. 54, pp. 135-141, 2006. [11] Z. Butler, K. Kotay, D. Rus, K. Tomita, “Cellular Automata for

Decentralized Control of Self-Reconfigurable Robots,” IEEE ICRA Workshop on Modular Robots, 2001.

[12] Y. Zhang, M. Yim, C. Eldershaw, D. Duff, K. Roufas, “Phase Automata: A Programming Model of Locomotion Gaits for Scalable Chain-type Modular Robots,” IEEE 2003 Conference on Intelligent Robots and Systems, pp. 2442-2447.

[13] S.G.M. Hossain, C. Nelson, K. D. Chu and P. Dasgupta, “Kinematics and Interfacing of ModRED: A Self-healing Capable, Four DOF Modular Self-reconfigurable Robot,” J. Mechanisms and Robotics, vol. 6, no. 4, pp. 41017.1-41017.12.

[14] E. Roberts, “Basics of automata theory,”

http://cs.stanford.edu/people/eroberts/courses/soco/projects/2004-05/automata-theory/basics.html, 2015. [Online; accessed 28-Oct-2015] [15] J. Lygeros, “Lecture notes on hybrid systems,”

http://robotics.eecs.berkeley.edu/~sastry/ee291e/lygeros.pdf, [Online; accessed 28-Oct-2015]