Download Using Assembly Representations to Enable Evolutionary Design of

Using Assembly Representations to Enable
Evolutionary Design of Lego Structures
Maxim Peysakhov and William C. Regli
Geometric and Intelligent Computing Laboratory
Department of Mathematics and Computer Science
Korman Computing Center
Drexel University
Philadelphia, PA 19104
http://gicl.mcs.drexel.edu
Abstract
This research presents an approach to the automatic generation of electromechanical engineering
designs. Our intent is to apply the Messy Genetic Algorithm optimization techniques to the evolution of
assemblies composed of the Lego structures. Each design is represented as a labeled assembly graph.
Designs are evaluated based on a set of behavior and structural equations, which we are trying to
optimize. Our eventual goal is to introduce a simulation of electromechanical devices into our evaluation
functions. The initial populations are generated at random. The design candidates for subsequent
generations are produced by user specified selection technique. Crossovers are applied by using cut and
splice operators at the random points of the chromosomes; random mutations are applied to modify the
graph with a certain low probability. This cycle will continue until a suitable design is found. The
research contributions in this work include the development of a new GA encoding scheme for
mechanical assemblies (Legos), as well as the creation of selection criteria for this domain. We believe
that this research creates a foundation for future work and it will apply GA techniques to the evolution
of more complex and realistic electromechanical structures.
Keywords
Genetic Algorithms, Evolutionary Desgin, Assembly Modeling, Computer-Aided Design, Engineering
Design, Lego.
1
INTRODUCTION
This paper explores a graph-grammar-based approach to use Genetic Algorithms (GAs) to evolve Lego
assemblies in an unknown design space.
The work in this paper contributes a technique for increasing the fidelity of the models of mechanical
assemblies that can be manipulated in a genetic algorithm for evolutionary design generation. Our work
opens new possibilities for using evolutionary computation for design problems. Traditionally, genetic
algorithms have been used to optimize design structures (i.e., the placement of trusses or the solving of
configuration or layout problems). Our work continues the direction started by Funes and Pollack,
toward the evolution of the entire design. We have introduced several variations on their technique
aimed at improving the representational realism of the design models that are capable of being operated
on. Our empirical results show how these representations can be used to evolve real Lego assemblies
subject to parametric and mass properties.
One of the contribution of this work is in the representations used. Our experimental results show that
these representations can be used to reproduce the work of Funes and Pollack while enabling the
possibility of evolving much more complex designs. It is our hope that the representational ideas in the
paper can be used to create more advanced evolutionary design systems.
After some brief background on Genetic Algorithms and their application to Engineering Design, we
describe our initial research goal: to create a unified graph-grammar-based design generation tool that
can evolve geometrically and structurally valid designs to solve a functionally specified set of design
constraints. We provide a description of the representation scheme for Lego assemblies and describe
how a GA can be applied to evolve Lego structures.
Our algorithm combines the knowledge of physical properties of Lego components and evolutionary
process to create more complex mechanisms. Mechanisms are then evaluated to determine how well
their structure satisfies the initial design goals and how well the design conforms to the desired attributes
and performance functions.
2
2.1
BACKGROUND
GENETIC ALGORITHMS AND EVOLUTIONARY COMPUTATION
Interest in evolutionary systems for optimization of engineering problems first arose in the 1950s. The
core idea in these systems was to evolve a population of candidate solutions to a given problem, using
operators inspired by natural genetics: crossover, mutation and selection [3].
GAs operate on chromosomes represented as collections of genes. Each gene is the smallest building
block of the solution. Different permutations of genes create different chromosomes or individuals,
which represents a solution of some quality to the given problem.
In the messy GA [3] (utilized in our project) chromosome usually does not have length constraints
implying that some genes can be over-specified or under-specified. By marking some genes as
dominant, we can introduce an arbitration and validation modules to handle over-specification and
under-specification. We hope that by applying selection and variation operators algorithm will improve
on the initial randomly generated solutions [12]. A typical GA shown in Figure 1.
First, the initial population is generated. Then each member of the population is evaluated. Then, one of
the selection techniques is used to select candidates for the next generation. In order to form the next
generation population mutation and crossover operators are applied with fixed probabilities.
2.2
USE OF GENETIC ALGORITHMS IN ENGINEERING DESIGN.
For certain problems of engineering design, genetic algorithms have been found to be very effective
optimizers. GAs are particularly useful when the design space and the nature of the optimum solution is
difficult to formalize during the initial design [7]. Another advantage is their ability to work
simultaneously with a variety of design variables.
Figure 1. Diagram of the genetic algorithm.
There have been a number of significant research efforts at applying GAs to engineering design. The
work of Bentley [1] uses GAs to evolve shapes for solid objects directed by multiple fitness measures.
This structural engineering problem is known as “structural topology optimization.” Jakiela pursued a
similar approach, using GA chromosomes to represent structural topology [4][6]. His approach is based
on converting the chromosome into topology, evaluating its fitness and structural performance, and then
assigning a fitness value to the chromosome. Later work of Jakiela represents a specification-based
design evaluation method and how it is applied to optimization using GAs [4]. Eric Jones in his Ph.D.
theses successfully applied GAs to evolution of antennas and logic circuits. [8] He developed a special
grammar, so each valid sentence in this grammar will represent a valid antenna design, and when
encoded sentences as chromosomes to perform genetic optimization on them.
Cagan
Szykman
Other GA for optimization stuff…
2.3
EVOLUTIONARY DESIGN
Our work obviously relates to the work of Funes and Pollack.[9] In their ground-breaking work, they
developed an encoding of Lego block structures, in particular their connectivity, in a way that enabled a
genetic algorithm to evolve structures that can be load-bearing (i.e., bridges, cranes, etc). They
employed an elementary model of physics, representing the connective strength of Lego component
connections under torque and their masses, in developing their evaluation function. Essentially, their
work restates the problem of designing simple load-bearing structures as an optimization problem
suitable for stochastic search via a genetic algorithm.
In their work they used networks of the torque propagation to evaluate structures and genetic
programming rather then genetic algorithm operators to perform optimization. Also they used an
assembly tree to represent a Lego structure. According to Pollack it was one of the limitation factors of
their work. In our research we are trying to address this particular limitation.
3
TECHNICAL APPROACH
The work in this paper expands the discussion started by Funes and Pollack in the following ways:
Allow for Mechanisms: Their problem formulation is limited only to design of structures created
solely by Lego blocks. We have re-formulated the problem in a way that includes for the evolution
designs with mechanical properties.
Assembly representation: Their design representation is based on a planar connectivity graph which
enables them to propagate forces through their designs. We have created an encoding for more
traditional representations of mechanical assemblies, allowing for a wider variety of Lego building
blocks and for the inclusion of more sophisticated connectivity among primitives (i.e., motion properties
and constraints).
Lego Shape Grammar: We have created a shape grammar for describing valid configurations of Lego
assemblies. The grammar is used for validity checking of assembly configurations.
Improved Lego Models: Our Lego models are realized as 3D solid models, allowing us to more
accurately model the physics of the design, as well as reason about kinematic properties (i.e.,
interference, collision detection, etc).
3.1
WHY STUDY THE LEGO DOMAIN?
We have selected Lego assembly because it represents a sufficiently complex, multi-disciplinary design
domain that includes a wide variety of realistic engineering constraints and the domain is sufficiently
discrete as to be tractable. Solution of this problem has grate practical value. First, with growing
popularity of Lego robot competition it is very beneficial to have a tool for design generation or
optimization. Second, generation of Lego assemblies is closely related to the generation of the real
engineering artifacts, so similar principles and tools can be applied in both cases.
3.2
PROBLEM FORMULATION
In order to evolve the Lego assembly we had to some extra modules to the generic genetic algorithm.
First we had to add the repository of Lego elements describing the types dimensions and physical
appearance of Lego elements available. Second we had to develop a separate module to perform a
validation and handle over specified and under specified chromosomes. This module uses the graph
grammar rules to validate the structure. The third significant customization we added was the graphical
output and visualization subsystem. That subsystem allow user to see the Lego structures as they are
evolving. The diagram of this algorithm is shown on Figure 2.
Input
Algorithm
parameters
Lego
components
data storage
Initialisation
Initial
population
Mutate
Chromosomes
Next
generation
Validate
Chromosomes
Outputs
Graphics
output
Visualisation
module
Crossover
Chromosomes
Statistical
information
Best solution
found so far
Validated
population
Evaluate
Chromosomes
Evaluated
population
Graph
grammar
rules
Candidate next
generation
Text
output
Candidate next
generation
Select
Chromosomes
Figure 2. Genetic algorithm specialized for evolving Lego assemblies.
3.3
REPRESENTING LEGO COMPONENTS AND PHYSICAL ASSEMBLIES
We used assembly graphs to represent Lego assemblies. Representing Lego designs as a mechanical
assembly graph has a number of potential advantages over the assembly tree approach suggested in
earlier research [9]. A labeled assembly graph is more expressive and can represent greater variety of the
Lego assemblies including kinematic mechanisms as well as static structures [13]. The nodes of the
graph will represent different Lego elements and the edges of the graph will represent connections
between elements. Another problem that we were facing was the absence of the notation for describing
valid Lego assemblies. We developed a graph grammar, similar to the one described in the Linda
Schmidt paper [14][15], to define valid combinations of the nodes and edges precisely and
unambiguously.
Each Lego structure is represented by assembly graph G. Assembly graph G is a directed labeled graph
with non-empty set N(G) of nodes n, representing Lego elements and set E(G) of edges e, representing
connections and relations between those elements [2]. Simple Lego structure and corresponding
assembly graph are shown in Figure 3. The node label contains the type and the parameters of the
element. For now, our program can operate only with 3 types of Lego elements, namely Beam, Brick,
and Plate. We will combine these 3 types under the category Block.
Number and nature of parameters specified in the label depends on the type of element. For Beam,
Brick, and Plate these parameters are the number of pegs on the element in X and Y dimensions. We
have created a labeling scheme for the elements of type Axle, Wheel and Gear and are currently
working on introducing it into the program.
The edge label contains the parameters defining the connection. An edge can be directed or undirected
depending on the type of the connection. For now our program can operate only with one type of Lego
connection a Snap Fit since this is the only possible connection between Brick, Beam and Plate
elements. Snaps are directed edges with arrows pointing from the Block, which provides pegs to the
Block that provides connection surfaces. The Edge label contains the connection type Snap and a PegPair which is used to define the Pair of corresponding pegs in the connection [(PozX1, PozY1); (PozX2,
PozY2)]. (PozX1, PozY1) defines the peg on the Block, which provides pegs, and (PozX2, PozY2)
defines the peg on the Block, which provides connection surface. This means that the peg on the block
Snap is pointing to always defined second in the Peg-Pair. Example of Lego nodes and edges are shown
in Figure 4.
Snap[(1,2)(1,1)]
Brick(2,4)
Snap[(1,1)(1,4)]
Snap[(2,2)(1,1)]
Plate(6,2)
Beam(4,1)
Plate(6,2)
Snap[(1,2)(1,4)]
Snap[(6,2)(2,1)]
Snap[(6,1)(2,4)]
Brick(2,4)
Figure 3. Example Lego structure with assembly graph.
Y
Beam(4,1)
Y
2
Brick(2,4)
4
X
X
Snap[(3,1);(1,1)]
Plate(1,2)
(a) Lego blocks (left) with labeled nodes (right).
(b) Peg coordinates and Snap connection
Figure 4. Example of the nodes and edges.
3.4
A LEGO SHAPE GRAMMAR
A parameterized context-sensitive directional graph grammar was designed to handle three-dimensional
structures assembled from Lego blocks, axles, and wheels. The grammar vocabulary is1
{•MECHANISM, •Module, Connect, •Block, •Element,
1
For notational purposes, “•” corresponds to nodes in the graph grammar; “|” corresponds to an undirected edge; and “↑” to a directed edge.
•Disk, •Pole, PegPair, ↑Snap, Insert, TInsert, GTrans,
•Beam, •Brick, •Plate, •Wheel, •Gear, •Axle, PozX,
PozY,SizeX, SizeY, Len, Diam, Teeth, Hole (, ), [, ], ;}.
Starting word of the grammar is {MECHANISM}. Terminal words of the grammar are:
{↑Snap, Insert, TInsert, GTrans, •Beam, •Brick,
•Plate, •Battery, •Motor, •Wheel, •Gear, •Axle, SizeX,
SizeY, Len, PozX, PozY, Diam, Teeth, Hole (, ), [, ], ;}.
Terminal words “()[],;” are used only to make sentences easier to read, so most often they will be
ignored on the derivation and syntax trees.
Terminals PozX, PozY, SizeX, SizeY, Len, Diam, Hole and Teeth are parameters. Meaning of the
parameters SizeX, SizeY, PozX, and PozY, which are used to define Lego Blocks and their connections,
was described in the previous paragraph.
These sets can be modified according to the Lego brick standards. Len used to specify the number of
pegs on the Lego Beam or the length of an Axle measured in the peg sizes. Hole defines the number of
the hole in the Beam in to which Axle is inserted. Diam reflects the diameter of the wheel. Teeth
represent the number of teeth on the Lego Gear. This number also uniquely defines the diameter of the
Gear. All of the sizes defined in terms of Lego units, but there is one to one correspondence between
Lego units and millimeter measurements of each element as demonstrated in Figure 5.
Figure 5. Lego block with dimensions.
PozX ∈ {1 .. SizeX },
PozY ∈ {1 .. SizeY }
SizeX ∈ {1, 2, 4, 6, 8, 10, 12, 16}
SizeY ∈ {1, 2, 4, 6, 8, 10, 12, 16}
Len ∈ {1, 2, 4, 6, 8, 10, 12, 16}
Hole ∈ {1 .. (Len - 1) }
Diam ∈ {17, 30, 43}
Teeth ∈ {8, 16, 24, 40}
•MECHANISM, •Module, •Element, •Block, •Disk, •Pole, •Beam, •Brick, •Plate, •Battery, •Motor,
•Wheel, •Gear and •Axle are the nodes of the graph grammar.
∀ x∈ N(G), x∈ { •Block, •Disk, •Pole, •Beam, •Brick,
•Plate, •Battery, •Motor, •Wheel, •Gear, •Axle}
Module is representing the number of Elements connected together. Element represents a single Lego
piece. Grammar includes three categories of Lego elements, namely Block, Disk and Pole.
Connect, ↑Snap, Insert, TInsert and GTrans are the edges of the graph grammar.
∀ y∈ E(G), y∈ { ↑Snap, Insert, Tinsert,GTrans }
Figure 6. Examples of Lego grammar rules.
In the future we plan to introduce another level of abstraction and represent Lego mechanisms as a
sentence in a language of Lego assemblies, rather than a graph, which makes it easier to validate the
assembly against grammar rules [8]. A portion of our Lego graph grammar is shown in Figure 6.
LEGEND
Derives
Derives
(several steps)
Connect
Snap
Mechanism
Module
Element
Block
Beam
Plate
Brick
Figure 7. Derivation of the assembly graph for the sample structure.
In the Figure 7 we demonstrate how the assembly graph shown in Figure 3 can be derived from the Lego
grammar described above. We have developed specifications on representation of wheels gears and
axles and their connections an example of which is the assembly graph in Figure 8 for the Lego car in
Figure 9. Having a Lego language greatly aided us in classification of the Lego blocks and connections.
For now we used the developed notation only to formally define the requirements documentation.
GTrans
Wheel(30)
Gear(40)
TInsert[1]
TInsert[1]
Gear(8)
Snap[(6,1)(5,1);(2,1)(1,1)]
Motor(5,4)
TInsert[8]
Plate(6,8)
Snap[(1,1)(1,1);(1,2)(1,2)]
Snap[(1,1)(6,1);(2,1)(2,6)]
Insert[2]
TInsert[10]
Beam(1,2)
Axle(10,1)
Wheel(30)
Snap[(2,4)(1,1);(5,4)(4,1
Insert[7]
Battery(4,14)
Beam(1,2)
Snap[(1,1)(4,13);(1,2)(4,14)]
Wheel(44)
Snap[(1,1)(1,13);(1,2)(1,14)]
TInsert[1]
Insert[2]
TInsert[8]
Wheel(44)
Beam(1,2)
Axle(8,1)
Insert[7]
Figure 8. Assembly graph for the Lego car.
Beam(1,2)
Figure 9. Example of the Lego car.
3.5
ENCODING SCHEME FOR GENETIC ALGORITHM
In order to perform a GA-based optimization on the population of assembly graphs, we first have to
define a way to encode the assembly graph as a chromosome. Currently, the chromosome is represented
by a combination of two data structures: array containing all nodes N(G) and the adjacency hash table
containing all edges E(G) with corresponding string keys as demonstrated on Figure 10. This array is
called the genome, and individual elements of the array called genes. Genome defines what Lego
elements will compose the structure. Key value of the hash table is used to represent γ function of the
graph G, and defines the position and direction of an edge. Key "1>3" is equivalent to key "3<1” and
means that the edge is located between nodes 1 and 3 and directed to node number 3. Hash table defines
the way Lego elements will be connected together.
0 Plate(6,2)
0>2 Snap[(1,2)(1,1)]
1 Plate(6,2)
0>3 Snap[(6,2)(2,1)]
2 Brick(2,4)
1>2 Snap[(1,1)(1,4)]
3 Brick(2,4)
1>3 Snap[(6,1)(2,4)]
4 Beam(4,1)
2>4 Snap[(2,2)(1,1)]
3>4 Snap[(1,2)(1,4)]
Figure 10. Chromosome of the example structure.
3.6
3.6.1
GENETIC OPERATIONS ON ASSEMBLY GRAPHS
Initialization
The initial population is generated at random. First ten nodes of random types are generated with
random dimensions. Then, 9 to 13 edges are generated and placed at random subject to the constraint
that the resulting structure must be physically feasible. In the future we will look into creating and
applying initialization rules to promote exploration of specific areas of the fitness landscape. As an
example, one of the rules can be:
All chromosomes must have at least one Lego element of the specific type.
3.6.2
Mutation
In order to provide the balance between the exploration vs. exploitation mutation operator is applied
with a constant low probability. Mutation operator works on the genome array of the mutated
chromosome. After gene was selected for the mutation it is simply replaced with a Lego element of the
same type and random size as shown on Figure 11. Some edges can become invalid after the element
was mutated. In this case these edges are reinitialized at random. Obviously Mutation has limited ability
to change the structure on the graph and works mostly on the nodes themselves. We are planning to
introduce mutation that alters edges and further the small sub-graphs.
Figure 11. Sample structure with a mutated beam.
3.6.3 Crossover
As in the majority of messy genetic algorithms, crossover is performed with the help of two genetic
operators: cut and splice. When two chromosomes are chosen for crossover the cut operator applied to
both of them at independent randomly selected points. Then, tail parts of the chromosomes spliced with
head parts of the other chromosome. Since selection of the crossover point is independent for each
chromosome, it is obvious that chromosome length can vary during the evolution process, to allow for
evolution of the assemblies with different number of elements. In order to cut the chromosome a random
point P is selected between 1 and N-1 where N is the number of genes in the genome. Then all genes
with the number less than P are considered the head segment and all genes with the number greater or
equal to P are considered a tail segment.
All edges between nodes of two different segments are deleted, but all edges within the segments are
preserved. In order to splice two segments together the head and tail segments are placed into one
chromosome, which produces a disjoint graph. Then sub-graphs are joined with a small number of
randomly generated edges. Figure 12 shows the results of cut and splice operators applied to the sample
Lego structure.
Snap[(1,2)(1,1)]
Snap[(1,2)(1,1)]
Brick(2,4)
Plate(6,2)
Snap[(1,1)(1,4)]
Beam(4,1)
Brick(2,4)
Snap[(1,2)(1,4)]
Snap[(1,1)(1,4)]
Plate(6,2)
Beam(4,1)
Snap[(1,2)(1,4)]
Snap[(6,2)(2,1)]
Plate(6,2)
Brick(2,4)
(a) Sample structure after cut operator was
applied at the point 3
Plate(6,2)
Brick(2,4)
(b) Head and tail sub-graphs spliced with one
random edge.
Figure 12. Demonstration of cut and splice operators
3.6.4
Evaluation Function
Each structure has a number of attributes, such as weight, number of nodes, and size in each dimension.
These parameters are used by the evaluation function to calculate fitness of the structure. Our eventual
goal is to introduce a simulation of electromechanical devices into our evaluation function. Generally
evaluation function was created according to the following form:
1 + ∑ Pi (ai )
1 + ∑ Pi (bi ) + ∑ Pi (| ci − ti |)
Pi is the wait function, which represents the impotence of evaluated parameter. For most critical
parameters it was set equal to the value of the parameter itself. For less important it was set to be square
root of the parameter, and for the least important it vas set to be square root of square root of the
parameter.
Pi = x i, Pi = x½, Pi = x¼
ai denotes the properties user wants to maximize unconditionally. Reliability can serve as example for
such a parameter. bi denotes the properties user wants to minimize, such as manufacturing cost. ci are
properties we want to bring as close as possible to the specific constant ti Sizes in x-y-z dimension can be
a good example of this type of properties.
3.6.5 Handling Over-specified/Under-specified Chromosomes
As in most of the messy genetic algorithms there is a chance of over-specified or under-specified
chromosome, generated during the evolution process [3]. Under-specification means that not all of the
required information is present in the chromosome. Most often it results in the disjoint assembly graph.
In cases like this, the nodes of the sub-graph containing the 0-th node are selected to be dominant. The
submissive sub-graph is not deleted from the chromosome, but is ignored in most calculations. Figure 9
can demonstrate an example of the under-specified chromosome (i.e. a disjoint Lego assembly graph).
On the other hand an over-specified chromosome has more than one value for the same gene. In Lego
structures it either results in the blocks sharing the same physical space, or are connected by the set of
edges, which imply two different locations for the same node. In the first case, the node which was
assigned the location first is marked as dominant, and the node which was assigned location second is
marked as submissive and ignored in most calculations. In the case when different edges imply different
locations for the same block edge which traversed first is given priority and other edges are marked as
submissive and ignored. Example of the over specified and under specified chromosomes is shown on
Figure 13
Snap[(1,1);(1,1)]
Brick(2,4)
Beam(4,1)
Snap[(1,1);(1,1)]
Snap[(1,1);(1,1)]
Plate(2,6)
Figure 13. Example of the blocks sharing same physical space (left) and infeasible connection edges (right).
4
EMPIRICAL RESULTS
4.1
DESCRIPTION OF PROTOTYPE SYSTEM
Our system was extended from sGA system originally created by Hartley [16] and written in the Java
programming language. Java3D and VRML97 were used in order to create a visualizer to monitor Lego
structures as they evolve. The system supports one-point crossover. We are planning to introduce
uniform and N-point crossover in the future. User can choose from proportional, rank, universal
stochastic sampling, sexual, sigma scaling, and Boltzman selection techniques. Other parameters to the
system include mutation and crossover rates, and population size. Although the current system can only
handle static structures composed of block type elements, the general approach can be applied to much
more elaborate kinematic mechanisms.
4.2
4.2.1
EXPERIMENTS
Evolving 10 by 10 by 10 Structure
Figure 14(a) demonstrates the result of 1000 generations of evolution of the static Lego structure with
predefined geometric parameters. In this case the goal was to evolve a structure with the size of 10 Lego
units in each x-y-z dimension with the minimal weight. In this experiment the mutation and crossover
rates were 0.01 and 0.7 respectively and we employed a rank selection strategy and elitism on the
population of 100 members. The resulting structure was discovered at the generation 895 and has the
sizes 10 by 10 by 6.8, which is sufficiently close to the desired result. Further, we note that this is one of
the lightest possible structures that satisfy these parameters that can be created from the set of elements
given. Another run of the similar experiment is shown in the Figure 14(b). This structure as discovered
by GA in the generation 3367 and it is a little bit heavier but it has perfect 10 by 10 by 10 size.
(a) 10 by 10 by 10
(b) 10 by 10 by 6.8
Figure 14. (a). Example of the light structure with 10 by 10 by 10 desired size.
4.2.2
Evolving Pillar-Like Structure
Another line of experiments is shown in Figure 15, where we were evolving a pillar-like structure. The
goal was to make an assembly with 4 by 2 base in x-y dimension and 20, 40 and 60 length in z
dimension. A second constraint we specified was density: the pillar should have as few holes as
possible. We used the same parameters as in the first experiment and ran the simulation for various time
intervals. On average solution was discovered within 5000 generations. All the structures have desired
size, and have very few defects.
Figure 15. Example of the pillar structure.
4.2.3 Evolving Wall Like Structure
The goal of this cycle of experiments was to evolve a wall like structure. The desired structure should
have width of 10 heights of 20 and depth of 1 Lego unit. Maintaining the 1 unit depth had higher priority
then reaching the desider hights and depth. The third goal was to encrease the mass of the structure
while keaping it confined to the mentioned above dimentions. This resulted in a dence uniform structure
with little or no defects. The structure shown on the Figure 16 maches the desired size perfectly. It also
satisfys the maximum dencity reqiurment. This structure was evolved in 91506 generations.
Figure 16. Example of the wall structure.
4.2.4 Evolving Stairs Structure
In this experiments we atempted to evolve a number of staircases. Staircases of the 3, 4, 5, 6, 7 and 10
staps where created by the program. Stairs of 10 and 7 steps are shown on the Figure 17. In order to
define the shape of the staircase we where places the folowing constraints on it. Structure width has to
be equal to number of staps plus one. Getting this dimention right woold give the individual higher score
then getting right any other dimention. Desired hegth was set to number of steps times 0.4 and depth to 1
Lego unit. We also tryed to turget the number steps as a number of bricks used in the structure. In order
to achive these results we had to limit our searchspace by providing only one by two Lego plates for
algorithm to work with. The structures of 10 and 7 steps whre evolved in 568 and 51573 generations
respectively.
(a) 10 step structure
(b) 7 step structure
Figure 17. Example of the staircase.
4.3
VERIFYING THE RESULTS WITH GRAPH GRAMMAR
At this point we can analyze the structures evolved and verify the results against the graph grammar
introduced earlier. For the simplicity we will choose a 4-step staircase for validation. Validation will
consist of creating a parse tree and producing the assembly graph for the structure. Parse tree starts with
the single node called mechanism which is also a module. Mechanism consists of two modules, each of
them in its tern composed of two sub modules. These four modules are one-element modules and for all
of then the 2 by 1 Lego plate is that element. Since all elements of the assembly are plates the only
connection type possible in the assembly is a snap. Due to the highly regular structure of the solution all
these connection s are identical and can be expressed as a connection from peg [1,2] to peg opening
[1,1]. On the Figure X you can see the graphical representation of this derivation and the resulting
assembly graph.
Snap[(1,2);(1,1)]
Plate (1,2)
Plate (1,2)
Plate (1,2)
Plate(1,2)
Plate(1,2)
Snap[(1,2);(1,1)]
Snap[(1,2);(1,1)]
Plate(1,2)
Plate(1,2)
Plate (1,2)
Figure 18. Validating evolution results against the graph grammar. Four steps staircase.
4.4
DISCUSSION OF RESULTS
Currently, our research is in its early stages. We are planning to introduce more types of Lego elements
and connections to connect them. We have specification for encoding elements of the type Wheel, Gear
and Axle as well as connections between them, but we still have to implement it in code. Other types of
Lego elements such as Motors, Batteries and their connections have to be described by the grammar and
implemented later. We are also planning on developing more realistic physical model, to help us better
evaluate the structures. All of these enhancements will help us generate Lego structures more fitted to
perform a specific task.
In all our experiments we noticed that the algorithm was much better in the evolving the structures that
can be represented as a sparse graph or even as a linked list or a tree, then the ones that have to be
represented as a highly connected graph. We think that this is due to the highly disruptive nature on the
cut operator as it applies to graphs. One of the most important directions of research would be the
development of the cellular encoding for the problem. Cellular encoding is a way to evolve the
instructions for graph development, rather then the graph itself. Using cellular encoding should lead to
better continuity of the phenotype over the generations. It also should make development of the
symmetric objects more feasible, which is desired quality for the most mechanisms. This encoding has
to be based on Lego grammar to simplify the process of validation and development into an actual
assembly graph.
There are also a number of improvements to the genetic operators themselves. For example, creating a
mutation operator, which would alter small sub-graphs, will help algorithm to explore areas of the
fitness landscape neighboring to the solution. The GA may also perform some deterministic search that
runs periodically for a limited time. That will also help GA to discover neighboring solutions and
hopefully increase the time efficiency of the algorithm.
For now cut operator was applied at random point often separating elements, which should work
together into two different sub-graphs. We are planning to introduce a notion of clusters, highly
interconnected sub-graphs loosely coupled together, which would correspond to the separate modules or
“organs”. System must promote crossover on the cluster boundaries, and demote crossover, which
brakes up a cluster.
We also noticed that use of elitism usually greatly speeds up the search. One of the experiments we
proposing is to analyze the common features between best performing chromosomes and generate new
elite chromosomes based on these features rather then simply copy it from the previous generation.
Another improvement, which can significantly speed up the search, is in using guided or seeded
initialization. This would mean introducing absolute as well as probabilistic rules and applying them
during the generation of the initial population, or injecting pre-build mechanisms in to the initial
population.
5
CONCLUSIONS, CONTRIBUTIONS AND FUTURE WORK
This paper introduced our approach, prototype system and initial experimental results toward the
evolution of Lego structures. The main research contributions described in this paper are the
development of a graph-grammar based representation scheme for Lego Assemblies and its encoding as
an assembly graph for manipulation and evolution by Genetic Algorithms. This graph-based approach is
unlike other systems for Lego design evolution [10], and we believe that this assembly graph-based
representation scheme is one of the most general ways of representing the assembly, and in this way
provides a more flexible means to represent a wide variety of mechanisms for use with GAs. Another
unique feature of our research is the development of a graph grammar for use in representing Lego
assemblies. Although we used it in all of our requirements documentation for defining connectivity of
the Lego elements, all of the rules were hard-coded into the system during the implementation cycle. We
believe that Lego sentences, rather than graphs on the code level, can bring our system to a new level.
Areas for future work:
Our work contributes to several areas of computer science and engineering design. Fundamentally, we
believe that this work demonstrates how to integrate more sophisticated and realistic engineering models
for use in evolutionary computation. From the standpoint of engineering design, we believe that our
work is part of the ongoing discussion about the utility and limits of evolutionary computation for
engineering design problems. While our empirical results do not show automated generation of fullscale electro-mechanical devices, we believe that our work, coupled with higher-fidelity models of
mechanical kinematics, could indeed lead to the creation of evolutionary design systems for the domain
of Lego devices.
Our future work will include continuing to improve the design representation, incorporating models of
function, behavior in addition to physical properties and mechanical constraints. We have long-term
hopes of creating a coherent model of design semantics, one that might be used to enable truly
knowledge-intensive design applications.
Acknowledgments
This work was supported in part by National Science Foundation (NSF), nowledge and Distributed
Intelligence in the Information Age (KDI) Initiative Grant CISE/IIS-9873005 and CAREER Award
CISE/IRIS-9733545. Additional support was provided by the National Institute of Standards and
Technology (NIST) Grant 60NANB7D0092.
Any opinions, findings, and conclusions or recommendations expressed in this material are those of the
author(s) and do not necessarily reflect the views of the National Science Foundation or the other
supporting government and corporate organizations.
References
1. P. Bentley (ed.) (1999). Evolutionary Design by Computers. Morgan Kaufmann Publishers;
ISBN: 155860605X.
2. S. Chase (1996). Representing designs with logic formulations of spatial relations. Workshop
Notes, Visual Reasoning and Interaction in Design. Fourth International Conference on Artificial
Intelligence in Design, Stanford University, USA, 23 June 1996.
3. D. Goldberg (1989). Genetic Algorithms in Search, Optimization and Machine Learning.
Addison-Wesley Pub Co; ISBN: 0201157675.
4. M. Jakiela, C. Chapman, J. Duda, A. Adewuya, K. Saitou Continuum structural topology design
with genetic algorithms, Computer Methods in Applied Mechanics and Engineering, V 186,
Issues 2-4, 9 June 2000, pp 339-356
5. M. Jakiela, D. Wallace, W. C. Flowers (1996). Design search under probabilistic specifications
using genetic algorithms, Computer-Aided Design, V 28, N 5, pp. 405-421.
6. M. Jakiela, J Duda (1997). Gereation and classification of structural topologies with genetic
algorithm speciation, Journal of Mechanical Design, V 119, Number 1, pp. 127–130.
7. C. Chapman, K. Saitou, M. Jakiela, (1994) Genetic Algorithms as an Approach to Configuration
and Topology Design, ASME Journal of Mechanical Design, V 116, pp. 1005—1012.
8. E. Jones (1999). Genetic design of antennas and electronic circuits, Ph.D. Thesis, Department
of Electrical and Computer Engineering, Duke University.
9. J. Pollack, P. Funes (1997)., Computer Evolution of Buildable Objects. Fourth European
Conference on Artificial Life, P. Husbands and I. Harvey, eds., MIT Press pp 358-367.
10. J. Pollack, P. Funes (1998). Evolutionary Body Building: Adaptive physical designs for robots.
Artificial Life 4, pp. 337-357.
11. J. Pollack, P. Funes (1998). Componential Structural Simulator. Brandeis University,
Department of Computer Science Technical Report CS-98-198.
12. J. Pollack, R. Watson, S. Ficici (1999). Embodied Evolution: Embodying an Evolutionary
Algorithm in a Population of Robots. 1999 Congress on Evolutionary Computation. Angeline,
Michalewicz, Schoenauer, Yao, Zalzala, eds. IEEE Press, pp. 335-342.
13. L. Schmidt, H. Shi, S. Kerkar (1999). The "Generation gap": A CSP Approach linking function
to form grammar generation, Proceedings of DETC99, DETC99/DTM-048, Las Vegas, NV.
14. L. Schmidt, H. Shetty, S. Chase (1996). A Graph Grammar Approach for structure synthesis of
Mechanisms, Journal of Mechanical Design. vol. 122, no. 4, pp. 371-6.
15. L. Schmidt, J. Cagan (1998). Optimal Configuration Design: An Integrated approach using
grammar, Transactions of the ASME, Journal of Mechanical Design V 120, N 1, pp. 2-9
16. URL:http://www.mcs.drexel.edu/~shartley/ConcProgJava/GA/Simple