Modular Robots

When a task or terrain varies, reconfigurable robots can change their shape to get the job done

10 min read
Modular Robots

chain of simple hinge joints

Photos: Robert Schlatter
Xerox PARC's multimodule robot, PolyBot, can move in several ways, starting as a rolling tread [first frame]. With the connectors between two modules released, it moves in a snake-like manner [second frame]. With its end modules docked to its center module, it forms a figure-8 [not shown]. Breaking the intermodule connections at the ends of the figure-8 [third frame] leads to a four-legged spider configuration that walks like a person on crutches [last frame]. Click on the image for the full illustration view.

Robots out on the factory floor pretty much know what's coming. Constrained as they are by programming and geometry, their world is just an assembly line. But for robots operating outdoors, away from civilization, both mission and geography are unpredictable. Here, robots with the ability to change their shape could be of great value, since they could adapt to constantly varying tasks and environments. Modular reconfigurable robots—experimental systems made by interconnecting multiple, simple, similar units--can perform such shape shifting.

Imagine a robot made up of a chain of simple hinge joints [see photos, right]. It could shape itself into a loop and move by rolling like a self-propelled tank tread; then break open the loop to form a serpentine configuration and slither under or over obstacles; and then rearrange its modules to "morph" into a multilegged spider, able to stride over rocks and bumpy terrain. This robot, dubbed PolyBot, is being built and experimented with at Xerox Palo Alto Research Center (PARC), in California. In fact, as far back as 1994, a simulation of it was displaying its assorted abilities at Stanford University, also in California. Systems of this kind would be useful for remote, autonomous operations, particularly in hostile environs such as under the sea, at the scene of a natural disaster, or on other planets.

Researchers not only at PARC but also at Johns Hopkins University, in Baltimore, Md., the National Institute of Advanced Industrial Science and Technology, in Tsukuba, Japan, the Information Sciences Institute at the University of Southern California, and elsewhere have been experimenting along these lines. The systems they have built can reconfigure themselves automatically, with no help from outside, to tackle whatever tasks and terrain they encounter.

Three promises

Modular reconfigurable robots are built up from tens to hundreds, and potentially millions, of modules. These, like cells in a human body, are few in type but many in number. Such robots are called n-modular systems (where n is the number of module types).

An n-modular system holds out three promises: versatility, robustness, and low cost. Its versatility stems from the many ways in which modules can be connected, much like a child's Lego bricks. The same set of modules could connect to form a robot with a few long thin arms and a long reach or one with many shorter arms that could lift heavy objects. For a typical system with hundreds of modules, there are usually millions of possible configurations, which can be applied to many diverse tasks.

Obviously, turning a bunch of uniform modules into a versatile robot is not child's play. To put together a useful system, solutions must be found to the complexities of programming a great many coupled, but independent, robotic units. Worse, as more modules are added, many of the programming issues get exponentially harder. These include controlling and coordinating modules to work together effectively and not collide or otherwise interfere with each other.

Robustness is born of the redundancy and small number of module types. The units diagnose themselves and each other and compensate for, replace, or reconfigure themselves around any that are malfunctioning. But the overall number of modules is a factor: the more of them there are, the more likely it is that some may fail. Clearly, if just a few modules fail, others may be able to compensate for them. The main advantage of redundancy is that when one or more modules malfunction, overall function degrades gracefully, instead of failing catastrophically. Naturally, such a robotic system must have a control strategy for dealing with partial failures. Ultimately, the system should be able to repair itself by shedding crippled units.

The promise of low cost may be the most difficult to realize. Being few in type, the modules can be mass produced, and as economies of scale come into play, the cost of each one can be reduced. But how cheap can they get? That may really depend on how small they can get. At their current scale of 5 cm on a side, our modules consist of many parts and fasteners that must be assembled, some by hand, but as their size diminishes, batch fabrication becomes practical, even necessary. However, even if the cost of each module is reduced to just US $1, a complete system might require one million modules. Still, even that $1 million price tag might be worth it, especially if one modular robot can adapt to a variety of difficult tasks.

Modular robots should have the most impact on those tasks that need versatility. Exploration of a distant planet should be just the thing. Its inherently unknown aspects demand that a system adapt to unexpected situations. The need for self-repair and reliability also looms large since it is difficult, if not impossible, to do on-the-spot repairs, and the cost of transporting the robot to the site is high. Urban search and rescue in buildings badly damaged by an earthquake or a bomb is another promising application.

connection plate

Photos: Robert Schlatter
The 25-cm 2 connection plate shown on this PolyBot G2 segment mates with an adjacent module. Infrared sensors align the modules for docking, and a latch made of shape-memory alloy holds them together. Holes and pins add stability to the connection, with power and data transmitted via electrical connectors. "Under the hood" where they can't be seen are the microprocessor and memory. Click on the image for the full illustration view.

Dissecting PolyBot

PolyBot, the modular robot being developed at Xerox PARC, is a chain reconfiguration robot. As such, it belongs to one of three classes of reconfigurable robots [see "The Three Types of Reconfigurable Robot," ]. PolyBot, which has been made of as many as 100 modules, has demonstrated several abilities, including locomotion, manipulating simple objects, and reconfiguring itself. Different versions vary the on-board computational power; the on-board battery power; the ability of modules to automatically dock, attach, and detach themselves; and the power of the modules' motors.

The two used most at PARC are known as G2 and G1v4. The more powerful one, G2, is made of just two types of cube-shaped modules: a segment that has a hinge-joint between two hermaphroditic connection plates, and a node, which doesn't move but has six connection plates [see photo, right]. Most of the functions depend on the hinged segment, which produces the robot's movement, whereas the node's job is to provide branches to other chains of segments. In theory, with enough nodes and segments, PolyBot could approximate any shape.

Structurally, each segment is roughly the size of a cube about 5 cm on a side and has one motor that rotates the hinge. The two connection plates on either side of the hinge join it to other modules, electrically as well as physically.

On every connection plate there are four electrical connectors, each with four contacts; and through the connectors electric power and communications pass from module to module. The communications network uses the CAN protocol (for controller area network), which is a popular automotive serial network standard.

For physically docking and undocking, every connection plate also houses a latch. At its heart the latch is a wire made of a shape memory alloy, a nickel-titanium combination that alternates between two shapes when alternated between two temperatures. In this case, resistive heating is used. When current is run through the wire, the latch opens and releases its hold on a neighboring module. Stopping the current allows the latch to close by a return spring.

Embedded in each PolyBot segment and node is a 32-bit Motorola PowerPC 555 processor (MPC555) along with 1MB of external RAM. Granted, the MPC555 is a rather powerful processor to have on every module, and its full processing power is not yet utilized. However, the goal of this research is a large, multipurpose, fully autonomous robot, which may require the complete use of these processors and memory.

The G2 has two kinds of sensors: position sensors, to determine the angle between the two connection plates, and proximity sensors. The first are Hall effect sensors, which measure voltage induced by magnetic flux to determine the motor's angle with a resolution of 0.45 degrees. These also serve for commutation and are built into the segment's 30-W brushless DC motors, which can generate 4.5 newton-meters of torque. The proximity sensors are infrared detectors and emitters mounted on the connection plates. They serve primarily to aid in docking two modules but can also be used to help the robot maneuver in tight spaces.

In the next version of PolyBot, G3, the plan is to equip the segments and nodes with other proximity, tactile, and force/torque sensors, plus possibly a low-resolution CMOS camera. These sensors and the camera will help the robot with manipulating objects and interacting with the environment.

A less elaborate PolyBot, the G1v4, was built mainly to prototype and evaluate a variety of configurations and gaits [see "Walk This Way"]. Its modules are of one type only, a hinge, and because they cannot dock and undock automatically, they must be plugged together by hand. It is powered by on-board batteries and controlled by an 8-bit microcontroller, the PIC16F877 from Microchip Technology Inc., Chandler, Ariz.

PolyBot is by no means the only chain-reconfiguration robot. In the Conro system, built at the Information Sciences Institute at the University of Southern California, in Marina del Rey, every module is like every other, with two small hobby servomotors that actuate right-angled hinge joints controlled by an 8-bit microcontroller. The modules communicate with their neighbors through an infrared interface. Rather than hermaphroditic connection plates, Conro's modules have three male connectors at one end and one female connector at the other. A system like this will easily form tree-like structures (the same structure as limbed animals) as well as structures with single loops but none with more than one loop--no figure-8s.

Programming perplexities

Programming the movements of n-modular systems is a struggle. As the number of modules grows, the complexity of many of the computational tasks explodes. At the same time, though, because each module has its own computer, the computational resources increase, but only linearly. Further complications accrue from increases in the number of module types, the distributed nature of the resources, constraints posed by torque limits of the motors, failing modules, and limited communication bandwidth. To keep confusion at bay, three control techniques are being tried: gait control tables, an unusual messaging method, and a hierarchical organization.

angles, downloaded from a gait control table

Gait Control: How the robot moves is determined by the angle between the connection plates that each module's motor makes. The angles, downloaded from a gait control table, result in a sequence [top to bottom] that propels the robot.

A gait control table stores precomputed motions for reference [see illustration, above]. Simple open-loop control instructions coupled with the mechanics of the configuration suffice for many of the capabilities demonstrated so far, including the snake, loop, and spider gaits. Most often, one module contains the set of gait control tables, which are downloaded as needed to the other modules.

Still, beyond a very minimal point, no table could hold all of a robot's possible gaits and configurations, because that number soars exponentially with the number of its modules. A PolyBot with 10 segments and two nodes, say, could form hundreds of distinct configurations, while another with 100 segments and 10 nodes could make well over a million. For any given application, though, a robot relies on a fixed and relatively small set of configurations, determined by analyzing the task to be performed. The sequence of motions by which the robot changes configuration is then planned and stored in a table. This approach does not fully exploit the versatility of the system, both for self-repair and for adaptation to the task in hand. For that, the robot would have to be able to reconfigure itself into arbitrary shapes. This is something researchers at PARC are working on.

An alternative to gait control tables is a message-passing method developed by the University of Southern California's Information Sciences Institute. The novel technique is modeled on the way a single hormone may produce a variety of responses throughout the human body. Rather than specific instructions being sent to each module, a single message flows from module to module. It is modified by some of them as it passes through and therefore sends dissimilar messages to and produces different effects on other modules. The state of the module to which the message is passed—the joint angle, for instance—dictates whether and how the message is altered. The same message, then, could change the motor angle in one segment, not change it in the next, and delete itself in the third.

Another way of simplifying programming, which is well suited to chain-type robots, is to divide the robot into hierarchical portions, rather as a finger, hand, and arm form a hierarchy within the body. For example, if an elbow is moved, the hand attached to it and the fingers on that hand also move. Several modules can be grouped into larger virtual modules, which can then also be grouped and a hierarchy formed. Such an organization simplifies the programming, because the motions of the modules within the smaller virtual modules matter less. A hand need not know how it got over the keyboard, just that it got there; and a shoulder couldn't care less whether a finger typed "y" or "m," just that the shoulder pointed the upper arm toward the desktop.

In planning reconfiguration, one must first consider how the modules need to be connected, and then plan the motions needed to get there. Much as a human can be drawn as a stick figure, the connectivity of a configuration can be drawn as a graph, with lines for the segment chains and intersections of lines where nodes need to be. Graph theory provides the tools for manipulating such graphs.

The future is modular

The first two generations of PolyBot have shown some of the versatility possible with these systems, most notably the use of self-reconfiguration to adapt to changes in the environment or the task. New versions of PolyBot and other modular robots are being constructed to explore other issues.

For example, the next PolyBot generation, G3, will grapple with robustness and self-repair as aspects of reliability, for G3 will have over 100 modules, an order of magnitude more than any other modular robot so far. G3's goal is to move autonomously, shift lightweight objects blocking its path, and reshape itself while moving through a pile of rubble as part of a search-and-rescue task.

To cope with some of the issues that will arise with G3 and more sophisticated robots, PARC engineers plan to look to biology to see how nature solves the same problems of complex control, self-repair, and efficiency. Then we plan to adopt similar solutions in a modular robot.

—Samuel K. Moore, Editor

About the Authors

MARK YIM (M), YING ZHANG (M) & DAVID DUFF (M) are researchers at Xerox Palo Alto Research Center (PARC), in California. They're on the modular robotics project, part of PARC's research on "smart matter," which interlinks computer science, electromechanical systems, and distributed control. Yim is the principal investigator, Zhang oversees the software architecture, and Duff leads the mechanical design.

To Probe Further

A technical description of PolyBot can be found in "PolyBot: A Modular Reconfigurable Robot,'' by M. Yim, D.G. Duff, and K.D. Roufas, in Proceedings of the 2000 IEEE International Conference on Robotics & Automation, May 2000, Vol. 1, pp. 514-20.

Details of PolyBot's software controls appear in "Software architecture for modular self-reconfigurable robots,'' by Y. Zhang, K.D. Roufas, and M. Yim, in Proceedings of the IEEE/RSJ International Conference on Intelligent Robots and Systems (IROS), 29 October-3 November 2001.

More on Xerox's efforts in modular robots, as well as a video clip of a reconfiguration simulation, are at

An alternative modular robot, Conro, and its control scheme is described in "Hormone-controlled metamorphic robots," by B. Salemi, et al., in the 2001 Proceedings of the IEEE International Conference on Robotics and Automation, Vol. 4, pp. 4194-99.

This article is for IEEE members only. Join IEEE to access our full archive.

Join the world’s largest professional organization devoted to engineering and applied sciences and get access to all of Spectrum’s articles, podcasts, and special reports. Learn more →

If you're already an IEEE member, please sign in to continue reading.

Membership includes:

  • Get unlimited access to IEEE Spectrum content
  • Follow your favorite topics to create a personalized feed of IEEE Spectrum content
  • Save Spectrum articles to read later
  • Network with other technology professionals
  • Establish a professional profile
  • Create a group to share and collaborate on projects
  • Discover IEEE events and activities
  • Join and participate in discussions