next up previous
Next: A Millisecond Oscillator from Up: Why Evolve in Hardware? Previous: Accelerated Evolution

Exploitation of Semiconductor Physics

Work with the ``gantry robot'' at the University of Sussex [7] suggests that it may be feasible to carry out artificial evolution in a real-world environment with fitness evaluations taking place in real time. If, in addition, evolution is given control over the reconfigurable hardware at the lowest possible level (for example the ``configuration bits'' of the FPGA mentioned in Section 1) to produce an electronic circuit as a type of control system in its own right (and not as an implementation of anything else), then circuits of unprecedented power and efficiency will be produced. These systems can exploit every facet of the characteristics of the reconfigurable hardware on which they are developed, because all of the natural real-time behaviours of its components (their physics) are allowed potentially to affect the robot's behaviour, and detailed control is provided to tune their collective action to achieve the task.

In nature, control systems are always adapted to the manner in which they are implemented, because their evolutionary success is determined by their effectiveness as real implemented systems. If engineering success is the objective, then implementations of neural networks (that evolved for an implementation allowing slow, highly unconstrained connections between slow units) may be a bad use of integrated circuits, which are very fast, but have severe constraints on interconnections (because of their planar nature). Perhaps it will be possible to evolve an architecture that is better suited to silicon than neural networks, but yet induces intelligent (``brain-like'') behaviour into a robot. The fine-grained control over the hardware that is required implies a vast search-space for a system of any complexity, so techniques need to be developed cope with this. One possibility is the use of developmental genetic encoding schemes for genetic algorithms [12], which allow the evolution of re-usable building blocks (analogous to neurons?), permitting fine-grained tuning of the building blocks, but yet reducing the search space to systems built out of them.

The space of circuits of the type I propose is very much larger than the space of solutions available to a human designer. The designer works with high-level models of how components or higher-level building blocks behave and interact. Design constraints are adopted to prevent the imperfections of these models from affecting overall behaviour. One such constraint is the modularisation of the design into parts with simple, well defined interactions between them. Another is the use of a clock to prevent the natural dynamics of the components from affecting overall behaviour: the clock is used so that the components are given time to reach a steady state before their condition is allowed to influence the rest of the system. I suggest (with the aid of the empirical evidence presented in the following sections) that such constraints should be abolished whenever they are a limitation on the potentially useful behaviour of an evolving hardware system. A designer carefully avoids ``glitches,'' ``cross-talk,'' ``transients'' and ``meta-stability,'' but all of these things could be put to use by artificial evolution.

Evolution could also put to use properties of the hardware that the designer could never know about. For instance, a circuit may evolve to rely on some internal time-delays of an integrated circuit that are not externally observable. Even if there is a silicon defect, the system could evolve to use whatever function the ``faulty'' part happened to perform. This raises a fundamental problem: a circuit that is evolved for a particular evolvable hardware system (a certain FPGA chip, for example) may not work on a different system that is nominally identical -- no two silicon chips are the same. There are several ways in which this could be avoided. The circuits could be evolved to be robust to perturbations in some properties that vary from chip to chip (by altering the chip's temperature or power supply during evolution, for example). Evolution could be forced to produce building blocks that are repeatedly used in the circuit, and would therefore be insensitive to characteristics that varied across one chip. Evolution could evaluate a configuration on more than one piece of reconfigurable hardware when judging its quality (this can also be done using a single reconfigurable chip that can instantiate the same circuit in several different ways, e.g. by using an FPGA's rotational symmetry). Finally, it could be accepted that further adaptation will have to take place each time a configuration is transferred from one reconfigurable device to another [14, 15, 16, 17].

The next two sections of this paper will provide experimental evidence for the ideas I have put forward here. Firstly, I present a simulation of the evolution of an FPGA configuration, which demonstrates that evolution can produce circuits optimised for a particular implementation, and in the absence of modularisation and clocking constraints. Then I describe a real evolved hardware control system that controls a real robot, and was produced according to the above rationale, demonstrating its benefits.


next up previous
Next: A Millisecond Oscillator from Up: Why Evolve in Hardware? Previous: Accelerated Evolution

Adrian Thompson
Tue Feb 25 13:21:33 GMT 1997