Molecubes Extended: Diversifying Capabilities of Open-Source Modular Robotics Victor Zykov, Phelps Williams, Nicolas Lassabe and Hod Lipson Computational Synthesis Laboratory Sibley School of Mechanical & Aerospace Engineering Cornell University, Ithaca, NY 14853, USA Email:
[email protected]
Abstract— This paper presents an open hardware and software platform for modular robotics (Molecubes). The goal of this project is to share the practice of design and construction of modular robotic systems with an emphasis on an expandable, open-architecture system made of standard components at reasonable costs. We present several different types of active modules including a controller, actuated joint, gripper, wheel, camera, and a number of passive modules.We then demonstrate the use of evolutionary search to rapidly-design different types of robots. The designs of Molecubes and the interface software are freely distributed through a dedicated user-group website at http://www.molecubes.org.
I. I NTRODUCTION The field of modular robotics aims to expand modern conventional robotics and industrial automation by producing a set of modules capable of forming a variety of robots of different shapes and functionalities, where each of these robots performs as well as a conventional robot dedicated to one specific task [1-37]. Such successful systems are yet to be demonstrated; current modular robotics research still requires a high entry level of expertise in robotics, engineering, and computer science. A major obstacle to the progress of this field is the cost barrier: Over the recent two decades research in modular robotics has remained expensive, making the development of modular robotics platform cost thousands of dollars, rendering research in this area affordable only by a few universities. On the other hand, as concluded by many researchers in the field [32], one of the major challenges limiting public interest in the area of modular robotics is the lack of a demonstrable killer application in which modular technology could, beyond doubt, prove superior to the conventional robotics. Within the modular robotics community, several attempts have been make to rise to this challenge. However, attempts of reaching outside the community are complicated by the lack of physical robot or design availability, the expense of construction, or the insufficient level of end-user expertise. The design presented in this paper was inspired by earlier modules used to demonstrate physical robotic selfreplication [37], [35]. The original Molecube design of 2004 has been miniaturized, simplified, and ruggedized [36].
II. M OLECUBE MODULES This section describes the set of Molecube modules and their features. We provide information and software with the goal of encouraging researchers to propose and build new types of Molecubes. We also show how designs from one type of cube, such as the actuator, can be adapted in order to produce other functionalities, such as wheel and gripper modules. The variety of types of modules allows for rapidly building many different types of robots. Since the previous report of this system [36], new types of cubes were created, the high mechanical retention force between two joined modules was improved using a new mechanical interface. A RGB LED was added at the center of each face (Fig. 2.a) for feedback and debugging purposes. The communication and the electronic interface that was described in the previous article have remained unchanged [36] and could be used with the new Molecubes. A. Electronic Design Every Molecube is equipped with a set of circuit boards (Fig. 1) that enable all of its programmable functions, such as turning an actuator to a desired angle, setting the speed and torque of its motion, controlling the module digital outputs or reading digital inputs, reading or writing internal servo motor register values, etc. To streamline low level software and simplify overall system construction, we designed a unified set of circuit boards that is used across all types of Molecubes. These circuit boards are then programmed differently depending on the type of module at hand. 1) Design Considerations: With an intent to minimize the volume occupied by circuit boards inside of individual modules, we combined the communication/power interface and control functions of module electronics into a single design. This way, every module equipped with the interface circuit boards, is also programmable. The actuator module is equipped with two sets of three diamond-shaped boards. Individual boards of each set are interconnected with flat flexible 50-conductor cables. These cables allow placing the boards at an angle relative to each other, thus providing each robot side with an electronic interface. Two sets of boards are connected with each other with four electrical lines passing through a slip ring, thus enabling
(a)
(b)
Fig. 1. (a) Inward side of one Actuator PCB set: ATmega324P processor is visible on the Middle board (top left), switching 1A 10VDC power supply for the AX-12 servo motor can be seen on the Right board (top right). (b) Outward side of one Actuator PCB set: Every board is equipped with an electrical interface and a programmable RGB LED.
(a)
(b)
(c)
Fig. 2. (a) Molecube interface: mechanical and eletrical interface with the RGB LED in the middle, (b) design 3D of the actuator, (c) Molecube actuator.
Molecube with endless rotation capabilities. These lines transmit ground and power signals through the Molecube rotary joint, as well as the two serial communication signals, one for data exchange between internal module processors, and the other for global assembly-wide communication. 2) Functionality: The main processing unit of an interface circuit board is an ATmega324P processor, running at a clock frequency of 16 Mhz. This processor provides all control and communication capabilities to the individual non-controller Molecube modules. For exchange of commands and data between the internal processors on board of individual Molecubes, as well as between the processors of different Molecubes joined into a single assembly, we have designed a specialized serial communication protocol. This is a half-duplex serial protocol with Rx and Tx signals modulated on a single bus. There is always only one bus master issuing requests to which one
of the slave processors responds as specified in the master’s transmitted packet. The protocol details and the packet structure are given in the Hardware Protocol Definition document. This serial communication protocol is designed to be compatible with the communication protocol used by Robotis AX-12 servos so that the module controller could directly communicate with and control the servos.
B. Actuator module The actuator module (Fig. 2) was previously described in detail in [36]. This module uses a modified AX-12 servomotor with an internal gear. The gripper and the wheel that are described in the next sections also use half of this part of the module with the motor.
(a) Fig. 3.
(b)
(a) ARM controller and the bluetooth module, (b) 3D design of the Molecube controller.
(a) Fig. 4.
(b)
(a) 3D model exploted: this show the position of the Arm controller and the bluetooth module inside the molecube, (b) Molecube controller.
C. Controller module The Molecube controller is composed of an ARM microprocessor-based control unit and of a Bluetooth module embedded inside a Molecube (Fig. 3) and (Fig. 4). The ARM microprocessor-based control unit (Fig. 3.a) and the embedded software framework include both the design of the hardware and the embedded software of a controller module. The controller enabling a direct interface from existing PC-based simulation software to the connected actuator, wheel or gripper Molecube modules. The design utilizes USB-based communication with a host computer. The communication system has also been expanded to include wireless connectivity using Bluetooth. The controller hardware includes a high capacity external memory device enabling the storage of system logs and command execution sequences. The hardware design includes five standard Molecube physical interfaces for robotic module retention and electronics connectivity. The hardware design includes an enclosure of approximately equal dimension as a Molecube actuator module.
The embedded software provides three primary functional modes. First is the ability to receive, execute, pause, and stop modular robot actuation control sequences. The format and content of these control sequences define the control elements that enable the utilization of Molecube compatible designs (such as wheels and grippers) without modification of the control framework. Hardware specifics are implemented at the interface computer level which increase the design’s longevity. The second functional mode is the ability to report the physical state of a composition of Molecube modules into a single physical robot. This involves an interface and an orientation map, that reports the identity of each Molecube in the network and how it is physically connected to its neighbors. The final functional role of the software is to allow for direct command injection. This enables direct real time control of individual Molecubes in a connected network. The interface to this software functionality shall be identical regardless of the interface (wired or wireless).
(a) Fig. 5.
(a)
(b) (a) 3D battery model, (b) View of battery and external power port.
(b) Fig. 6.
(c)
(a) 3D gripper model, (b) Gripper Molecube opened. Gripper Molecube closed (c)
D. Battery modules The Battery Molecube (Fig. 5) enables wireless execution of motion. Several options were considered in the production of this cube including power density, ease of manufacturing, and cost. The initial consideration was a custom Lithium Ion pack that was optimal in terms of power density. However, in attempt to maintain the open-source nature of this design, we sought more readily available components. Commercial prismatic Lithium Polymer cells in the 2000mAh range are not available in the dimensions required (50mm x 50mm x 50mm). Commonly available video camera batteries happen to have very similar requirements as what is needed for Molecubes. Power density is critical, smaller is better, and due to much aftermarket competition, these products are reasonably priced at roughly $20 each. After testing several at various discharge rates and identifying the limits of the protection circuitry internal to the battery a Samsung SB-L220 2200mAh pack was selected at 7.2v. Notably, a pack rated at 3000mAh showed a tested capacity of 2000mAh while the selected Samsung pack consistently performed in the 2400mAh range. To achieve the required bus voltage (12v − 24v) a boost regulator was used. With some assistance from National
Semiconductor an appropriate design was created that conformed to the volume limitations. The regulator based around the National LM3478 achieves roughly 91% efficiency. The regulator has V in = 6.0V − 8.5V and a V out = 14V @2A. The maximum discharge rate of the battery is estimated to be in the 4A range for short bursts. Estimates place maximum regulator load within this range of battery load conditions. This battery pack should support between 6 and 10 cubes under a medium to heavy load for between 30 minutes and 1 hour. The pack has been tested under a light load with 2 to 4 cubes for several hours of continuous use. A plug was included in the final battery assembly that enabled the battery to also provide a power interface for powering Molecubes from a power supply between 12 and 24V . A power switch accessible on the side turns the pack on and off. Because these packs are regulated, they cannot be safely connected in parallel (multiple packs on the same bus). Future ideas include a 2-cube battery that is essentially 2 Molecubes printed as a single unit. These two battery cubes would be configured in series, thus no longer requiring a regulator. This would also allow multiple of these dual packs to be connected on the bus resulting in higher capacity and higher maximum discharge rate configurations.
(a)
(b) Fig. 7.
(a) Wheel Molecube 3/4 view, (b) Wheel Molecube.
(a)
(b)
Fig. 8. (a) Power supply is an alternative to the Molecubes’s batteries and allows for the use of the passive modules as a static support for a robotic arm, (b) Molecube arm robot on a power supply.
E. Gripper module The gripper module (Fig. 6) is activated by an AX-12 servomotor. This module is also based on one half of the actuator module and has three interfaces to connect to other Molecubes. The rotation of a central curved structure on the other halves of the Molecubes can be open and close the grips (Fig. 6.(a)). The gripper can be used on a mobile robot or an arm (Fig. 8.(b)). F. Wheel module This module is also based on one half of the actuator module and has three interfaces to connect to Molecubes. The wheel module (Fig. 7) is activated by an AX-12 servomotor that is connected to a hub that supports the tire. G. Passive modules Passive modules comprise units without electrical connections (Fig. 9). These modules include a universal-joint core, hinge, cube rod socket and foot could be used to connect any
Molecube and improve the morphology of the robot for a low cost. However, the controller modules would not be able to detect these passive modules. Nevertheless, they could be used to extend the morphology to build parts such as legs. H. Power supply The power supply (Fig. 8) allows for the function of a robot without a battery module. Any face of each module of the robot could be connected to the power supply. The power supply could serve as a support base for a static robot, such as an articulated manipulator arm. (Fig. 8.(b)) at a low cost. I. Wireless camera The wireless camera module is composed of a small color onhole camera, a 9V battery and a support encasing that can be connected to a Molecubes. The video is broadcasted in 2.4GHz to a receiver connected to an offboard computer, which can be used to process the image stream (possibly
Fig. 9.
Passive modules: cardan core, hinge, cube, rod socket and foot.
(a) Fig. 10.
(a) Wireless camera and its support, (b) Camera module on a Molecubes robot.
(b)
Fig. 11. Cubeinterface: graphical interface that can simulate Molecube robots by using a physical engine. Here, the interface displays the evolutionnary process of a robot controllor.
from multiple cameras) and direct the robot using a Bluetooth connection (Fig. 10). III. M OLECUBES SOFTWARE The Molecubes software is designed to test and evaluate different morphologies and behaviors on the Molecubes. The interface allows the user to add Molecubes in any configuration in a virtual world that emulates real world physics, and then to send commands to individual Molecubes for actuation. In this way, the software allows the user to simulate and evaluate what might happen with a custom configuration and structure of Molecubes before physically constructing it. A. CubeInterface To build and simulate the robots, we provide to the users a graphical interface using the physical engine AGEIA PhysX and Ogre 3D (Fig. 11)1 . This interface allows to edit, save and load robots with complexe morphologies by using the 1 Physical engine AGEIA PhysX: http://www.ageia.com/ and Ogre 3D: http://www.ogre3d.org/
Molecubes modules. The virtual robots could be animated manually or by evolution of their controllers. This plateform is open source and allows interested people to share and to extend its functionalties. From the previous version, the collision shapes were changed to be more realistic motions and improve the safety of the robots. B. Molecube sequence file The Molecube sequence file (*.msf) is generated by the PhysX simulation running on the host computer. This file maintains a simple header describing global parameters about the sequence such as length and the Molecube topology it is associated with. Following this header, commands compliant with the command specification document are combined with a timestamp indicating the time of execution (Fig. 12). From this file the controller builds a memory structure consisting of timestamp ordered queues of commands. The actual runtime is quite simple, it simply needs to dequeue and execute commands when the current timestamp is less than or equal to the timestamp of the head of a particular queue. This action is continuously applied to each cube queue until no
Name Sequence Name char array size 25 Topology Hash
Variable Type Human Readable identifier of the command sequence. Links sequence to hardware configuration. unsigned int (32bit)
Command Count Size
unsigned int (32bit) unsigned int (32bit)
Header Checksum
unsigned char (8bit)
Cmd0 Timestamp Cmd0 Bus Cmd0 Header Cmd0 Class Cmd0 ID Cmd0 Length Cmd0 Instruction Cmd0 Param 0 ... Cmd0 Param n ... Cmd N Timestamp Cmd N Bus Cmd N Header Cmd N Class Cmd N ID Cmd N Length Cmd N Instruction Cmd N Param 0 ... Cmd N Param n
unsigned unsigned unsigned unsigned unsigned unsigned unsigned unsigned
char(32bit) char (8bits) char (8bits) char (8bits) char (8bits) char (8bits) char (8bits) char (8bits)
Description
Links sequence to hardware configuration. LSB must equal number of cubes, format of 3MSB Total Number of commands in this particular sequence Size of all Commands in the sequence, not including this header Equals Name, Topology Hash, Command Count and size, summed and inverted Time in milliseconds of execution 0 (Internal Bus), 1 (External Bus) Always 255 Device Address
unsigned char (8bits) unsigned unsigned unsigned unsigned unsigned unsigned unsigned unsigned
char(32bit) char (8bits) char (8bits) char (8bits) char (8bits) char (8bits) char (8bits) char (8bits)
unsigned char (8bits) Fig. 12.
Molecubes Sequence File (.msf) Specification
commands remain in any queues. List of the commands for the Molecubes sequence file: Get Firmware Version, Set Address, Set Address with Orientation Pin, Set Address with Orientation Pin and Set Motor Master, Get Raw Angle, Get Measured Angle, Set Orientation Pin, Get Orientation Pins, Is Orientation Pin Observed, Get Motor Status, Get Motor Register, Set Motor Register, Set Motor Register, Set Motor Master, Preload Motor Profile, Preload Command Hearbeat, Set LEDs, Get Status. IV. C YCLE TO DESIGN A MOLECUBE ROBOT To design a robot, we propose a cycle of four steps.The first of these steps includes assembling the robot with different types of Molecube modules, retrieving the morphology product and saving the morphology of the robot onto a compact flashcard. It then includes sending this structure to the simulator, evolving a robot controller in the physical simulator and then finally loading the sequences file on the robot in order to bring it to life (Fig. 15).
Fig. 15.
Cycle to design a robot.
A. Assembling the robot To design a robot the first step is to assemble the robot from the Molecube parts. Each robot should be composed of a minimum of one controller module and one battery (or a power supply) and any others types of modules. Only a few minutes are necessary to build a new robot. There
is no constraint of connectivity or of orientation between the different types of modules (Fig. 13.a). Before building the robot, it is also possible to build it inside the physical simulator to see what it looks like.
(a) Fig. 13.
(b)
(a) Assemble robot from the Molecubes parts, (b) the morphology of the robot is saved on a compact flash.
(c) Fig. 14.
(d)
(c) Generation motion inside the physical simulator, (d) Motion executed by the robot.
B. Send structure to simulator At this point, the controller Molecube has this point can recognize the morphology of the robot and save it on a compact flash in order to communicate it to the simulator (Fig. 13.b). However, note that the controller could not recognize the passive modules. In addition to the passive modules, the controller will not recognize an active module isolated from it by a passive module. This means that the passive modules will be not represented inside the simulator for all the morphologies generated by a robot. C. Evolve robot controller We have developed a visual software interface that provides users with the ability to display the morphologies of robot generated and to evolve a behavior for these robot (Fig. 13.c). It is also possible to manually design the motions. In order to generate the behavior, we use an evolutionary algorithm that generates a sequence file that could be interpreted directly by the robot. We plan to improve this aspect of the process through the us of an evolving modular neural network. In order to evolve the motion of the robot, the
genetic algorithm selects the robots best adapted to traveling long distances (Fig. 16). D. Bringing robot to life At this step, the robot could execute the sequence file previously generated from the simulator (Fig. 13.d). If the result is unsatisfactory, it is still possible to restart the cycle and improve the morphology of the robot. In the future, we plan to propose the evolution of the robots morphology inside of the virtual simulator. V. P ERSPECTIVES We propose to evolve both the morphology and the modular neural network controller from the simulator in order to provide robots with the ability to walk, climb a stair, push an object or even drive a skateboard [14], [38] or on a grid (Fig. 17). We also plan to have caps sensors such as ultrasonic or infrared distance sensors and accelerometers that could be connected and oriented on each of the faces of the Molecubes.
(a)
(b)
(c) Fig. 16. Tree different types of motions generated by evolution of controller for two similar robots and a snake robot (a) Here, the robot uses the Molecubes actuator like wheels. (b) In this case, the robot does little jumps with its arms. (c) Here the snake robot at the beginning in a line position modifies his morphology before to forward.
Fig. 17.
Robot evolved on a grid
VI. C ONCLUSIONS We presented new Molecube modules and an example case to efficiently produce robot behavior. The new types of module provided to Molecubes the possibility of building a large variety of robots for a reasonable cost. This paper also shows how easy it is to reuse some part of the Molecubes in order to build new types of cubes. VII. ACKNOWLEDGMENTS This research was funded in part by Microsoft Research, Embedded Systems and Robotics program, by Festo AG, Learning systems program, and by the U.S. National Science Foundation, Emerging Frontiers in Research and Innovation (EFRI) grant #0735953. We thank Dr. Stewart Tansley and Dr. Hermann Klinger for their support. Nicolas Lassabe’s research was funded in part by the University of Toulouse, France. Blueprints, source code and circuit schematics are available at http://www.molecubes.org. R EFERENCES [1] Z. Butler, K. Kotay, D. Rus, and K. Tomita, “Generic decentralized locomotion control for lattice-based self-reconfiguring robots,” Int. J. Robotics Res., vol. 23, no. 9, pp. 919–938, 2004.
[2] A. Castanoand and P. Will, “Mechanical design of a module for autonomous reconfigurable robots,” in Proc. IEEE/RSJ Int. Conf. Intelligent Robots and Systems, 2000, pp. 2203–2209. [3] G. Chirikjian, A. Pamecha, and I. Ebert-Uphoff, “Evaluating efficiency of self-reconfiguration in a class of modular robots,” J. Robotic Systems, vol. 13, no. 5, pp. 317–338, May 1996. [4] G. Chirikjian, Y. Zhou, and J. Suthakorn, “Self-replicating robots for lunar development,” IEEE/ASME Trans. Mechatron., vol. 7, no. 4, pp. 462–472, Dec. 2002. [5] R. Fitch and D. Rus, “Self-reconfiguring robots in the usa,” Japanese Robot. Soc. J., vol. 21, no. 8, pp. 4–10, 2003. [6] T. Fukuda, S. Nakagawa, Y. Kawauchi, and M. Buss, “Self organizing robots based on cell structures—cebot,” in IEEE/RSJ Int. Conf. Intelligent Robots and Systems (IROS), 1988, pp. 145–150. [7] T. Fukudaand and S. Nakagawa, “Dynamically reconfigurable robotic system,” in Proc. IEEE Int. Conf. Robotics and Automation, vol. 3, 1988, pp. 1581–1586. [8] S. Goldstein, J. Campbell, and T. Mowry, “Programmable mater,” IEEE Computer, vol. 28, no. 6, pp. 99–101, May 2005. [9] K. Hosokawa, T. Tsujimori, T. Fujii, H. Kaetsu, H. Asama, Y. Kuroda, and I. Endo, “Self-organizing collective robots with morphogenesis in a vertical plane,” in Proc. IEEE Int. Conf. Robotics and Automation, 1998, pp. 2858–2863. [10] N. Inou, K. Minami, and M. Koseki, “Group robots forming a mechanical structure-development of slide motion mechanism and estimation of energy consumption of the structural formation,” in IEEE Int. Symp. Computational Intelligence in Robotics and Automation, vol. 2, 2003, pp. 874–879. [11] A. Kamimura, H. Kurokawa, E. Yoshida, S. Murata, K. Tomita,
[12]
[13]
[14] [15]
[16]
[17] [18]
[19]
[20]
[21] [22]
[23]
[24]
[25]
[26]
[27]
[28]
[29]
[30]
[31] [32]
[33]
[34]
and S.Kokaji, “Automatic locomotion design and experiments for a modular robotic system,” IEEE/ASME Trans. Mechatron, vol. 10, pp. 314–325, Sept. 2005. E. Klavins, S. Burden, and N. Napp, “Optimal rules for programmed stochastic self-assembly,” in Proc. Robotics: Science Systems ’06, 2006. H. Kurokawa, S. Murata, E. Yoshida, K. Tomita, and S. Kokaji, “A three-dimensional self-reconfigurable system,” Adv. Robot., vol. 13, pp. 591–602, 2000. H. Lipson and J. B. Pollack, “Automatic design and manufacture of artificial lifeforms,” Nature, vol. 406, 2000. S. Murata, E. Yoshida, H. Kurokawa, K. Tomita, and S. Kokaji, “Concept of self-reconfigurable modular robotic system,” J. AI Eng., vol. 15, no. 4, pp. 383–387, 2001. S. Murata, E. Yoshida, A. Kamimura, H. Kurokawa, K. Tomita, and S. Kokaji, “M-tran: Self-reconfigurable modular robotic system,” IEEE/ASME Trans. Mech., vol. 7, no. 4, pp. 431–441, 2002. S. Murata, H. Kurokawa, and S. Kokaji, “Self-assembling machine,” in IEEE Int. Conf. Robotics and Automation, 1994, pp. 449–455. S. Murata and H. Kurokawa, “Self-reconfigurable robot: Shapechanging cellular robots can exceed conventional robot flexibility,” IEEE Robotics and Automation Magazine, pp. 71–78, march 2007. E. Ostergaard, “Distributed control of the atron self-reconfigurable robot,” Ph.D. dissertation, Maersk McKinney Moller Institute for Production Technology, Univ. of Southern Denmark, 2004. A. Pamecha and I. Ebert-Uphoff, “Useful metrics for modular robot motion planning,” IEEE Trans. Robot. Automat., vol. 13, pp. 531–545, Aug. 1997. D. Rus and G. Chirikjian, “Eds., autonom. robots,” (Special Issue on Modular Robots), vol. 10, no. 1, 2001. B. Salemi, M. Moll, , and W.-M. Shen, “Superbot: A deployable, multi-functional, and modular self-reconfigurable robotic system,” in Proc. 2006 IEEE/RSJ Intl. Conf. Intelligent Robots Systems, 2006, pp. 3636–3641. W. M. Shen, B.Salemi, and P.Will, “Hormone-inspired adaptive communication and distributed control for conro self-reconfigurable robots,” IEEE Trans. Robotics Automat., vol. 18, no. 5, pp. 700–712, Oct 2002. W.-M. Shenand and M. Yim, “Eds., ieee/asme trans. mechatron.” (Special Issue on Self-Reconfigurable Modular Robots), vol. 7, no. 4, 2002. K. Stoy, W. Shen, and P. Will, “Using role based control to produce locomotion in chain-type self-reconfigurable robot,” in IEEE/ASME Trans. Mechatron., vol. 7, 2002, pp. 410–417. K. Tomita, S. Murata, H. Kurokawa, E. Yoshida, and S. Kokaji, “A self assembly and self-repair method for a distributed mechanical system,” IEEE Trans. Robot. Automat., vol. 15, pp. 1035–1045, 1999. H. Ueno, Y. Wakabayashi, Y. Ohkami, S. Matunaga, R. Hayashi, and T. Yoshida, “Ground testbed of a reconfigurable brachiating space robot,” in Advanced Robot., vol. 14, no. 5, 2000, pp. 355–358. C. Unsal, H. Kiliccote, and P. Kohsla, “A modular self-reconfigurable bipartite robotic system: implementation and motion planning,” Autonomous Robots, vol. 10, no. 1, pp. 23–40, 2001. M. Yim, Y. Zhang, K. Roufas, D. Duff, , and C. Eldershaw, “Connecting and disconnecting for chain self-reconfiguration with polybot,” Proc. IEEE/ASME Trans. Mechatron, vol. 7, pp. 442–451, Dec. 2002. M. Yim, K. Roufas, D. Duff, Y. Zhang, C. Eldershaw, and S. Homans, “Modular reconfigurable robots in space applications,” in In Autonomous Robot Journal, special issue for Robots in Space, S. Verlag, Ed., 2003. M. Yim, Y. Zhang, and D. Duff, “Modular robots,” IEEE Spectr., vol. 39, no. 2, pp. 30–34, Feb. 2002. M. Yim, W.-M. Shen, B. Salemi, D. Rus, M. Moll, H. Lipson, E. Klavins, and G. S. Chirikjian, “Modular self-reconfigurable robot systems: Challenges and opportunities for the future,” IEEE Robotics and Automation Magazine, March 2007. E. Yoshida, S. Murata, A. Kamimura, K. Tomita, H. Kurokawa, and S.Kokaji, “A self-reconfigurable modular robot: reconfiguration planning and experiments,” Int. J. Robot. Res, vol. 21, no. 10, pp. 903–916, 2003. E. Yoshida, S. Murata, K. Tomita, H. Kurokawa, and S. Kokaji, “Experiment of self-repairing modular machine,” in Distributed Autonomous Robotic Systems 3, E. N. Y. Springer, Ed., 1998, pp. 119– 128.
[35] V. Zykov, E. Mytilinaios, M. Desnoyer, and H. Lipson, “Evolved and designed self-reproducing modular robotics,” IEEE Transactions on Robotics, vol. 23, no. 2, pp. 308 – 319, 2007. [36] V. Zykov, A. Chan, and H. Lipson, “Molecbues: An open-source modular robotic kit,” in IROS-2007 Self-Reconfigurable Robotics Workshop, 2007. [37] V. Zykov, E. Mytilinaios, B. Adams, and H. Lipson, “Self-reproducing machines,” Nature, vol. 435, no. 7038, pp. 163–164, 2005. [38] N. Lassabe, H. Luga, and Y. Duthen, “A new step for evolving creatures,” in IEEE-ALife’07. IEEE, 2007, pp. 243–251.
