BSc FINAL PROJECT
Submitted for the
BSc Honours in Computer Science
May 2009
Flocking Algorithm for Emperor Penguins
by
Joseph Laycock
1
TABLE OF C ONTENTS
Abstract...................................................................................................................................................................................... 4
1 Introduction...................................................................................................................................................................... 5
1.1
User Domain........................................................................................................................................................ 5
1.2
Aims and Objectives ....................................................................................................................................... 5
1.2.1
Graphical User Interface .................................................................................................................... 6
1.2.2
Virtual Penguins...................................................................................................................................... 6
1.2.3
Virtual Environment............................................................................................................................. 6
1.2.4
Flocking Rules .......................................................................................................................................... 6
1.2.5
General.......................................................................................................................................................... 7
2 Background Survey...................................................................................................................................................... 8
2.1
Biology .................................................................................................................................................................... 8
2.1.1
Flocking Behaviour................................................................................................................................ 8
2.1.2
Penguin Biology....................................................................................................................................... 8
2.2
2.2.1
Software................................................................................................................................................................. 9
Flocking Software................................................................................................................................... 9
2.2.1.1
Boids.......................................................................................................................................................... 9
2.2.1.2
Swarm.................................................................................................................................................... 10
2.2.2
Artificial Life Simulation Techniques...................................................................................... 10
2.2.2.1
Cellular Automata .......................................................................................................................... 10
2.2.2.2
Neural Networks............................................................................................................................. 11
3 Algorithms ...................................................................................................................................................................... 12
3.1
Flocking Algorithms .................................................................................................................................... 12
3.1.1
Field-of-View .......................................................................................................................................... 12
3.1.2
Areas of Interest and Awareness ............................................................................................... 13
3.1.3
Alignment ................................................................................................................................................. 14
3.1.4
Cohesion.................................................................................................................................................... 15
2
3.1.5
Separation................................................................................................................................................ 16
3.1.6
Random...................................................................................................................................................... 18
3.2
3.2.1
Environment Algorithms.......................................................................................................................... 19
Temperature........................................................................................................................................... 19
3.2.1.1
Uniform Temperature Algorithm ......................................................................................... 20
3.2.1.2
Individual Temperature Algorithm..................................................................................... 21
3.2.1.2.1
Temperature Spread in Penguins ................................................................................. 21
3.2.1.2.2
Asymptotic Temperature Distribution Algorithm ............................................. 22
3.2.2
Wind ............................................................................................................................................................ 23
3.2.2.1
Wind Turbulence............................................................................................................................ 24
3.2.2.2
Ray Tracing ........................................................................................................................................ 24
4 Implementation ........................................................................................................................................................... 28
4.1
Usability .............................................................................................................................................................. 28
4.2
Features .............................................................................................................................................................. 29
4.2.1
Visualizations......................................................................................................................................... 30
4.2.2
Logging....................................................................................................................................................... 33
4.3
Testing ................................................................................................................................................................. 33
5 Experimentation ......................................................................................................................................................... 35
5.1
One Flocking Rule ......................................................................................................................................... 35
5.2
Three Flocking Rules .................................................................................................................................. 35
6 Review ............................................................................................................................................................................... 38
6.1
Ethics .................................................................................................................................................................... 40
6.2
Future work...................................................................................................................................................... 40
6.3
Conclusion ......................................................................................................................................................... 41
7 References ...................................................................................................................................................................... 42
Appendix A: Meeting Notes ........................................................................................................................................ 44
Appendix B: Project Time Plan................................................................................................................................. 48
3
ABSTRACT
Male emperor penguins during the breeding season carry an egg on their feet. Their unique
huddling behaviour during this time was simulated. Using an individual-based model, each
penguin had the flocking rules alignment, cohesion, separation and a random flocking rule to
control movement. Two environmental rules were also used to calculate wind and temperature
values. The penguins had a 360 degree view, the flocking rule ranges and weightings for each
penguin were based on the individual temperature and wind values for that penguin. In cold
conditions penguins would huddle closer. In windy conditions, warm penguins would move to the
outside of the group in the opposite direction of the wind, cold penguins would move to the
sheltered side of the group and move into the centre.
The project produced a tool that would allow the user to change the weightings and ranges for
each flocking rule in the algorithm. Changes would be made based on observations of penguin
movement. Observations of penguins were done from a top down view of penguins. Several
visualizations were used to help identify behaviour, these included visualizations of temperature
and wind for each penguin.
4
1
INTRODUCTION
Artificial Life or Alife is a branch of AI; it is the simulation of any aspect of life, as through
computers, robotics, or biochemistry (Editors of The American Heritage Dictionaries,
2000). Alife in this project crosses through fields in both computer science and biology. In
this project these areas include algorithms, agent based systems such as boids (Reynolds,
1987) and the biology of penguins and flocking behaviour. Alife is an important step in
understanding the interactions of individuals and the intelligent behaviours that emerge.
Male emperor penguins spend the Antarctic winter looking after their eggs in the
harshest weather conditions on the planet. They survive the winter months by collecting
together into large circle formations. Observations have shown that these formations are
constantly changing. In strong winds, the penguins exposed to the weather at the edge of
the circle are constantly replaced by the ones in the warmer centre.
This project will investigate the behaviour of emperor penguins during breeding season
and create a flocking algorithm to simulate their behaviour under a range of different
environment conditions. The project will use design patterns and a flocking algorithm
similar to that of boids (Reynolds, 1987) as a starting model to simulate this behaviour.
Previous related work has simulated the flocking behaviour of fish, birds and insects. The
flocking behaviour of emperor penguins is very different to that of fish, birds and insects
because of the very different environment they occupy. This has produced some unique
challenges and behaviours in penguins that have not been simulated before.
1.1 USER DOMAIN
In the initial specification, user domain was not identified. From looking at the aims below
one could say that the simulation would be useful for a biologist and as a teaching aid.
A biologist will be able to research and apply different theories within the flocking
simulation and then apply scientific method to improve understanding of penguins. The
simulation would demonstrate penguin behaviour visually; User experimentation would
also facilitate learning and as a teaching aid it could be useful for lecturers, teachers and
students of biology or AI.
1.2 AIMS AND OBJECTIVES
This project focuses on the biology and behaviour of emperor penguins and flocking
algorithms. The final simulation should:
Model the penguins and their environment in a realistic way that mimics the natural
flocking behaviour of emperor penguins.
Allow experimentation to show a range of known penguin behaviours under different
conditions typical of the Antarctic.
5
The principal objectives for this program are:
Graphical User Interface
Virtual Penguins
Virtual Environment
Penguin Flocking Rules
1.2.1 GRAPHIC AL USER I NTERFACE
A good GUI is important for usability. Variables such as such temperature, wind speed,
wind direction, number of penguins, etc. were changeable via the user interface of the
program. This allowed a wide variety of conditions to be modelled within the software
very easily. GUI elements were be added as they are implemented into the program. This
helped testing the program.
1.2.2 VIRTUAL PENGUINS
Primarily the program modelled the penguins in 2D as penguins only move on a 2D plane.
The algorithm would therefore only need to work in a 2D space and a top down view of
the penguins would show the penguin behaviour well. The shape of a penguin fro m a top
down perspective is very close to a circle, therefore the flocking algorithm a nd graphical
representation used circles to represent individual penguins. Using circles also made
calculations significantly easier and faster than using a complex shape . The 2D penguin
model also had a beak to show the direction it is facing. The virtual penguin models were
not extended into modelling them in 3D.
1.2.3 VIRTUAL E NVIRONMENT
Like the virtual penguins the environment was primarily a 2D model. The environment
had three main variables: Wind speed, wind direction and temperature. Temperature was
a global variable for the entire environment. This variable would not be the same as the
local temperature of any given space as this would change depending on penguin
locations. Wind speed and direction was shown clearly and graphically on the screen to
show which penguins were being hit by the wind.
Environment features such as hills, rocks and other obstacles were not included in the
simulation. This is because emperor penguin breeding grounds are always on flat ground.
Large features such as hills are often used as cover from wind by penguins however
equivalent conditions can be simulated using wind direction and wind speed variables.
The program could also be extending giving additional views of the penguins in other
ways such as a heat map that could enhance understanding of penguin behaviour and
show what a human may not notice. A wind map could also show the amount of wind
impacting each penguin visually. These views do not change the environment variables;
they are visualisations of the environment data.
1.2.4 FLOC KING RULES
The rules described in section 2.2.1.1 provide a good starting point for the penguin
flocking algorithm. These rules were modified significantly to be adapted for penguins.
Additional flocking rules for temperature, wind speed and wind direction were necessary
for the simulation.
6
Obstacle avoidance steering behaviour would not be necessary for the simulation because
there are no obstacles to avoid; the ground is very flat where penguins breed.
1.2.5 GENERAL
The majority of the program was written using C++ and OpenGL. C++ is a well established
language and has the advantage of being well supported and potentially faster than other
languages such as C#, Java, etc. Using slow languages could become an issue modelling
penguin colonies that are in the 100s and sometimes 1000s in size. The majority of
learning content available for OpenGL uses C++ as an example language, which is also an
advantage. The disadvantages of using C++ are the complex issues that can arise such as
memory management and pointers that can cause program instability or slowdowns.
7
2
BACKGROUND S URVEY
2.1 BIOLOGY
2.1.1 FLOC KING BEHAVIOUR
Many organisms in the world have developed flocking behaviours of some kind in order
to improve their survival rate. There are lots of reasons they will flock, many of these
reasons are for direct/indirect protection from predators but it can also be performed for
breeding and food related reasons.
A school of fish moving underwater can look random and disorderly due to varying speed
and close to instant changes of direction of the fish. It is an example of collective motion;
Hundreds of fish moving like one large object. There are evolutionary reasons that explain
this behaviour. Fish on the outside of the group are most likely to be eaten by predators,
so each fish will try to keep close to as many fish as possible. At the same time the fish
want there to be some distance between each other and lots of distance between other
fish. There is also no leader in a school of fish; they all more or less follow each other. The
combination of these behaviours and the movement of relatively few fish can cause the
whole school to quickly change direction (Partridge, 1982).
2.1.2 PENGUIN B IOLOGY
Emperor penguins live in the harshest conditions out of all penguins in the world. Due to
their long breeding cycle, they have evolved to breed slightly inland on the coast of
Antarctica. This is a very safe area with no predators to the adult penguins and no risk of
the ice breaking up and melting. Most species would not normally need to develop
flocking behaviours under such conditions, but the harsh climate of Antarctica goes well
beyond the temperate ranges a penguin can regulate its own temperature at for sustained
periods of time (Williams, 1995, p. 109).
During the breeding season, male penguins must survive winter temperatures up to -60°C
and winds up to 125mph (Lynch, 2007), for about 4 months without food (Gilbert,
Robertson, Maho, & Ancel, 2007). To survive this, penguins huddle together to conserve
heat. The goals and flocking behaviour of penguins is different to other species. There are
not any predators to the emperor penguin adults in Antarctica. Emperor Penguins are
very unique in this respect; their only threat is the environment that surrounds them. The
goal of a penguin is to keep itself at a comfortable temperature using the least amount of
energy.
When the ambient temperature within a group of huddling penguins is too high (>20°C)
the metabolic rate of penguins increases and they will break up to save energy (Gilbert,
Robertson, Maho, & Ancel, 2007). Equally, when the body temperature of a penguin is too
low to maintain temperature it has two options. The easiest option is fo r the penguin to
move towards other penguins to save energy, if the penguin is already close to other
penguins, it must move around or shiver in order to maintain body temperature. This will
also increase the metabolic rate of the penguin and can only be sustained for so long.
8
Wind speed has a similar effect and will cause penguins to huddle more tightly, but its
main effect is to cause penguins that are being hit by the wind to move around the group
away from the wind to the sheltered side of the group (Gilbert, Robertson, Maho, & Ancel,
2007).
2.2 SOFTWARE
2.2.1 FLOC KING SOFTW ARE
2.2.1.1
Boids
There have been various flocking simulations for fish and birds. One of the more
influential and well known simulators was a generic simulator called Boids by Craig
Reynolds (Reynolds, 1987). Reynolds theorised that flocking could be modelled by
applying a few simple rules to each individual agent. Each agent followed the same set of
rules to create a flocking behaviour similar to that seen in birds or fish. The rules were:
Figure 2-1 (Reynolds, 2007) Separation: Each agent will steer to
avoid colliding with other nearby agents.
Figure 2-2 (Reynolds, 2007) Alignment: Each agent will steer
towards the average direction other nearby agents are steering in.
Figure 2-3 (Reynolds, 2007) Cohesion: Each agent will
steer towards the average position of other nearby agents.
9
Figure 2-4 Obstacle Avoidance: Each agent will steer away
from the position of an obstacle.
Each agent would have a limited view of the scene to calculate its position with, and by
manipulating these rules the behaviours of organisms such as birds or fish would emerge.
2.2.1.2
Swarm
Other notable flocking software is Swarm (SwarmWiki, 2009). Swarm is an open source
platform for making agent-based models. It is a framework for designing and conducting
experiments and is capable of genetic algorithms, neural networks, 3D spaces and outputs
log outputs.
2.2.2 ARTIFIC IAL LIFE SIMULATION TEC HNIQUES
2.2.2.1
Cellular Automata
Cellular automaton is a simple virtual machine, grid of cells, each of which can have a
finite number of states. By knowing the current time and using information from
neighbouring cells each cell uses its own set of rules to determine what the next state is
(Kennedy & Eberhart, 2001). All cells are updated simultaneously in discrete time steps
or frames. A change from one cell can cause change in other neighbouring cells. An
example of this is Conway’s game of life (Gardner, 1970). The game of life is a twodimensional grid of cells, each with two possible states, dead or alive. Every cell intera cts
with its immediate neighbours, and can live, die or multiply based on four rules:
“For a space that is 'populated':
Each cell with one or no neighbours dies, as if by loneliness.
Each cell with four or more neighbours dies, as if by overpopulation.
Each cell with two or three neighbours survives.
For a space that is 'empty' or 'unpopulated'
Each cell with three neighbours becomes populated.” (Martin, 2005)
The boids simulation is also an example simulation using the cellular automaton model
only each cell is instead represented by an agent in a finite torus grid. An agent can be
described as “a system situated within and part of an environment that senses that environment
and acts on it, over time, in pursuit of its own agenda and so as to effect what it senses in the
future” (Franklin & Graesser, 1996).
10
2.2.2.2
Neural Networks
An artificial neural network is a network of interconnecting artificial neurons. The
networks are based on the structure of a brain and try to replicate its behaviour. Each
neuron is a simple processing element. The neurons are usually separated into 3 layers:
Input – the sensory input into the simulation; hidden – these layers do the actual
processing; outputs – these are the processed result of the hidden layers. Based on
connections between elements complex behaviour can emerge and it is suited very well
to learning or adaptive Alife simulations.
11
3
ALGORITHMS
This chapter discusses issues relating to the development and implementation of
important algorithms in the simulation. It examines the various problems encountered
and how they were solved.
3.1 FLOCKING ALGORITHMS
There are lots of ways flocking has been implemented. In early flocking models, a central
force model was used and every agent had access to everything in the environment with
perfect vision. In reality this does not happen as animals perceive the world around them
with imperfect senses that are much more limited.
The initial flocking rules used in the simulation were based on the perception model used
in boids (Reynolds, 2007). However while developing the simulation more rules were
added along with new concepts. The flocking movement of each penguin in the simulation
was dictated by many algorithms. Three flocking algorithms for alignment, cohesion and
separation control the main movement of each penguin. A random algorithm added a
random element into the movement of penguins. A wind algorithm measured the amount
of wind hitting each penguin and influenced that penguins’ movement. Finally a
temperature algorithm controlled the temperature of an individual penguin and this was
also affected by the results of the wind algorithm.
Every flocking rule had a separate adjustable weighting in the overall algorithm. Each
flocking rule except for random also had a separate adjustable radius. By having a user
adjustable radius and weighting for each rule allowed for a much larger variety of
experimentation within the simulation. For example with a large radius and low
weighting of the separation rule each penguin would keep away from each other and the
distance between each penguin will be varied. With a high weighting and small radius
each penguin would generally be closer to each other and commonly be the same distance
away from every other penguin. These are subtle differences that produce d very different
behaviours in the simulation.
3.1.1 FIELD- OF -V IEW
In real life emperor penguins have a much smaller view of their surroundings relative to a
full 360˚ view. For other species such as birds some flocking software uses sight
information from the animal. This has the assumption that because an animal can only see
small view at any given time the animal is only aware of things within that small view. In
reality most non-hunting birds have a large field-of-view (Martin & Katzir, 1999), but for
certain birds this idea works well because when moving in the air at speed there is a small
length of time any old visual information about the nearby birds is useful for. With
penguins the movement speed is much slower, therefore visual information is valuable
for much longer.
Different fields of view produce different flocking results:
12
Figure 3-1 Wide versus narrow field-of-view flock formations (BOURG, 2004)
With a narrow field-of-view line formations tend to form, and with a wide field-of-view
group formations tend to form. Both of the above formations are similar to that of the
emperor penguin. However there are weaknesses to using field-of-view to control
flocking rules.
When navigating to their breeding grounds emperor penguins follow each other in a line
formation, and when they reach the breeding grounds they huddle together (Jacquet,
2006). The emperor penguin has the same field-of-view in both situations, yet produces
completely different flocking patterns that are consistent with different fields of view.
Another weakness of using field-of-view in software can be seen in birds, for example:
Occasionally in bird simulations using small fields of view, a bird with a small field-ofview on the edge of a group will leave the group; it will fly off on its own. This is because
the bird has turned away slightly and can no longer see any other birds in view and so will
just carry on flying straight forward until it finds the group again. In real life this doesn’t
happen, in this situation the bird would be aware of where the group is and just turn back
towards it. Therefore using field-of-view to completely control the flocking is flawed.
Simulated perception is the idea of filtering out surplus information and giving an agent
only a fraction of the information around it. In the bird example, too much information is
cut off and the bird is being given less information than it actually would have – What it
sees is not what it knows. With simulated perception, each agent has a localised view of a
simulation equal to what the actual animal would perceive (Reynolds, 1987). Giving an
agent fuzzy vision of what is around it could potentially improve flocking behaviour, but it
is beyond the scope of this project.
3.1.2 AREAS OF INTEREST AND AW ARENESS
By examining the situations above one can identify two factors that the real life animals
exhibit in these situations. These are the area of interest and the area of awareness. The
area of interest is the area that the animal is concentrated on to achieve its goal. In the
penguin example, the penguin is only interested in what is directly in front of him when
travelling to the breeding ground, but when at the breeding ground the penguin has a
much wider area of interest to keep itself at the correct temperature. The area of
13
awareness is what an animal is aware of using all of its senses. A penguin can use a
combination of its sight, touch, hearing and memory to produce a very accurate area of
awareness around itself compared to using sight only.
The area of awareness is always greater than or equal to the field-of-view. The area of
interest is always less than or equal to the area of awareness. In the penguin example
when travelling to the breeding ground the area of interest is very small compared to the
area of awareness and when in the breeding ground the area of interest is much larger.
The area of interest is similar to field-of-view; however a field-of-view is a fixed arc, while
an area of interest can potentially have a much larger variance in both arc and shape.
Early in the penguin simulation development it was realised that if a penguin was too cold
it would have different goals than a penguin that was too hot. These two goals require
different flocking rules in order to achieve their goals. Using the same flocking algorithm
for both situations, it is unlikely that both penguins will satisfy their goals. The
combination of different flocking behaviours within the same flock of animals allows the
production of behaviours that would be otherwise impossible.
A change in area of interest happens when there is a change in goal, though a change in
goal does not mean a change in area of interest. The penguin and bird examples show that
as goals change for an animal, so does the flocking pattern it exhibits. This implies that in
a flock of animals, not all the animals are necessarily applying the same flocking
behaviour.
Based on the behaviour information given in figure 3-1, each of the flocking rules except
for random were given a 360˚ area of awareness and area of interest for every goal. A
further extension of the program would be a global user adjustable area of awareness,
and adjustable area of interest for each goal, this could potentially allow for simulation of
other types of emperor penguin flocking such as line flocking shown on the right in figure
3-1.
3.1.3 ALIGNMENT
The purpose of the alignment flocking rule is to keep all agents go in the same direction.
The alignment algorithm used was very simple and can be shown with the pseudocode
below.
for each penguin[i] in simulation
{
for each penguin[j] in penguin[i] alignmentRange
{
xAlignmentVector += penguin[j].GetXVector();
yAlignmentVector += penguin[j].GetYVector();
}
Normalize(xAlignmentVector, yAlignmentVector);
}
The code shows the vectors of every penguin within the alignment rule range being added
to two vector variables. After this these variables are normalised. In the final flocking
14
formula (not shown) the variables are multiplied by both global and individual penguin
weightings. The algorithm used had a complexity of O(n²).
A different approach to this problem would be to take an average of the list of numbers as
penguin vectors. In the final formula that decides flocking direction, it was decided
everything should be normalised before weightings were added. Due to this decision it
would be pointless to take this approach as normalising the average is mathematically
equivalent to normalising the total.
Another alternative method to manipulate alignment information would be to weight the
value of a penguin vector by distance. Making the alignment of penguins closer more
important than those further away could potentially produce interesting results .
3.1.4 COHESION
The purpose of the cohesion flocking rule is to keep all agents together and towards the
centre of the group. The cohesion algorithm used is simple and similar to the alignment
algorithm:
for each penguin[i] in simulation
{
for each penguin[j] in penguin[i] cohesionRange
{
xAverage += penguin[j].GetXPos();
yAverage += penguin[j].GetYPos();
averagenum++;
}
if(averagenum != 0) //prevent divison by 0
{
xAverage = xAverage/averagenum;
yAverage = yAverage/averagenum;
xCohesionVector = averagex - penguin[i].GetXPos();
yCohesionVector = averagey - penguin[i].GetYPos();
Normalize(xCohesionVector,yCohesionVector);
}
}
Here the code is taking the position of every penguin within the cohesion rule range.
Unlike the alignment algorithm, an average position of all the penguins is necessary
before normalising. This is because the average position needs to be relative to the
current penguin position. Finally the cohesion vectors are normalised. The algorithm used
had a complexity of O(n²).
This algorithm generally works well though it has some weaknesses. Figure 3-2 shows an
example where there the average y position is very close to the centre of the agent, while
the average x position is to the left of the agent. Under these conditions the agent will not
go towards either of the two other agents, it will go around in circles in the middle
between the two agents but will not actually meet either of them.
15
Figure 3-2 Cohesion issues
Adding decision making to the cohesion algorithm could improve cohesion calculations.
However, this may not be necessary. The only penguins that will have this problem in this
example will tend to be at the centre of the penguin colony. All the surrounding penguins
will be pushing inwards towards the centre penguins so penguins in the centre should not
need to move.
3.1.5 SEPARATION
The purpose of the separation flocking rule is to stop agents moving inside of each other.
Separation keeps agents apart and away from each other. There are many ways to tackle
this. The most common way is as a function of the distance to other penguins. Of this
method there are several possible implementations.
As a linear function of distance as two penguins get closer the separation value rises
linearly. The distance to the closest agent is measured and penguin will move away with
linear urgency. This produces bouncy cartoon like behaviour and is not very realistic
(Reynolds, 1987). Figure 3-3 shows the separation power distribution at any given point.
Figure 3-3 Linear power distribution
Using an inverse square to derive separation power is also a consideration. This method
has been employed in flocking simulations involving birds and fish. However, using an
inverse square it is harder to keep lots of agents very close together, which is key for
huddling penguin behaviour. The behaviour using the inverse square method is generally
16
very unrealistic for penguins. While it may work well for birds or fish, these animals have
a very different movement and flocking goals to penguins.
Figure 3-4 shows flocking behaviour using an inverse square algorithm. In the centre,
there are penguins relatively close to each other but on the outside the penguins are far
away from each other. What is also noticeable is the number and size of gaps between
penguins; this is not good huddling behaviour. An inverse square causes the penguins to
constantly cycle from moving too close to too far. This causes penguin temperatures to
drop much quicker than they should do.
Figure 3-4 Issues with inverse square
Using a fixed separation weight based on distance allows agents to stay close together
well. With a fixed separation weight, the power distribution is uniform. This prevents
sudden movements to move away when penguins move closer to each other; this can be
an issue using inverse square or linear power distribution. With a fixed method, the
separation range is used to control distances, by decreasing the separation range, other
penguins can move closer before the separation rule is active. This allows penguins to
move closer to each other but to not intersect each other. The disadvantage of this
method is the lack of any gradual changes based on distance.
An alternative method for separation is to use short term path finding, this would involve
looking a distance away and moving to the area with the most space rather than the
opposite direction of the closest agent. This method does not work well on its own and
should be combined with other methods to produce realistic behaviour. This method also
has issues with speed and is very slow when there are hundreds of agents. For these
reasons this method of separation was scrapped during development.
A fixed separation algorithm was chosen as the separation algorithm and had a
complexity of O(n²). The separation algorithm that was used in pseudocode is:
17
for each penguin[i] in simulation
{
for each penguin[j] in penguin[i] alignmentRange
{
//find the penguin that is closest to penguin[i]
x = penguin[j].GetXPos();
y = penguin[j].GetYPos();
x2 = penguin[i].GetXPos();
y2 = penguin[i].GetYPos();
//use pythagoras to work out distance
distance = ((x2-x)*(x2-x)) + ((y2-y)*(y2-y));
//first time going through, new distance will always be smallest
if(firsttime)
{
shortestDistance = distance;
shortestDistancePenguin = j;
}
else
{
if(distance < shortestDistance)
{`
shortestDistance = distance;
shortestDistancePenguin = j;
}
}
}
xSeparationVector = penguin[i].GetXPos(); penguin[shortestDistancePenguin].GetXPos()
ySeparationVector = penguin[i].GetYPos(); penguin[shortestDistancePenguin].GetYPos()
Normalize(xSeparationVector, ySeparationVector);
}
The code above finds the position of every penguin[j] in the alignment range. Next it
works out the distance to penguin[i] then compares the distance to the current shortest
distance. To get a vector, position of shortest distance penguin is taken away from the
position of penguin[i]. This vector is finally normalised and added to the final flocking
formula (not shown).
3.1.6 RANDOM
The purpose of the random flocking rule is to provide a random unpredictable element to
the flocking behaviour. Penguins are not all identical in an isolated environment; they are
all different in a dynamic changing environment. Adding randomness helps to reflect this.
18
There are two main ways to implement random flocking. One way is to have a pair of
pseudo-randomly generated numbers represent vectors and use a different set of random
numbers each frame to determine the random vector. This is a quick, easy and effective
way of adding randomness.
Another way is to implement a wandering steering algorithm. With a wandering
algorithm, each frame is related to the next and random numbers are generated to control
the steering direction rather than a direct vector. The advantage of this is there is some
long term order. On its own it works well while using random vectors does not produce
very realistic behaviours. However, with penguins in combination with other flocking
rules, there is little need for long term order as that is provided by the other flocking
algorithms. Therefore the random vector algorithm was chosen.
3.2 ENVIRONMENT ALGORITHMS
To simulate penguins, using flocking rules alone did not create very realistic flocking
behaviour. With animals such as birds, modelling of the environment is very different.
Factors such as wind and temperature are more or less uniform on each bird throughout
the flock; the main environmental factor is the obstacles. This is the opposite of penguins.
Every penguin has a different local environment it is moving in. Penguins that are on the
outside in a group of penguins are more exposed to the environment than those in the
centre. Penguins in the centre of a group are less exposed to the environment and have
more contact with other penguins than those on the outside. Environmental factors that
contribute to penguin behaviour are wind and temperature (Gilbert, Robertson, Maho, &
Ancel, 2007).
3.2.1 TEMPERATURE
At any given temperature, there is a probability of huddling. This can be shown in Figure
3-5.
Figure 3-5 Probability of huddling (GILBERT, ROBERTSON, MAHO, & ANCEL,
2007)
The diagram above shows that as temperature decreases, the probability of huddling
increases. The probability of huddling is also dependent on previous conditions such that
19
if the conditions have been warming quickly to a temperature of -10 from a much lower
temperature, then it is likely huddling may continue. This shows that there is a time lag
between penguin temperature and the environment temperature.
Creating a genuine physics simulation of air currents and heat transference within the
environment is well beyond the scope of the project. The physics involved is complicated
using just spheres, so simulating this with the odd shape of a penguin would not be
realistically achievable. The temperature algorithms to consider must therefore be
simpler but still provide accuracy. A simple temperature model is to control the
temperature of a penguin in two ways.
Uniform temperature - Every penguin has its temperature governed by a central
temperature.
Individual temperature - Each penguin has its own individual temperature governed by
its local environment.
To calculate the temperature of a penguin a combination of the two was used. Each
penguin would have its own individual temperature variable. A general environmental
temperature was used uniformly to make every penguin lose temperature. An individual
environmental temperature was calculated based on the distance to other penguins
nearby, this would add to the penguin temperature. It is this balance that would govern
penguin temperature.
The penguin temperature was used to control how a penguin moved in the simulation. If a
penguin was too cold it would have a different flocking algorithm to a penguin that was
too hot. As the environmental conditions change so does the individual temperature of a
penguin.
3.2.1.1
Uniform Temperature Algorithm
The formula for calculating penguin temperature using the uniform method was:
for each penguin[i] in simulation
{
penguin[i].PenguinTemperature += EnvironmentTemperature * c * dt
}
In the formula, “c” is an arbitrary constant and “dt” is delta time or the difference in time
between two frames. The arbitrary constant was used to keep relative individual and
uniform temperatures gains and losses close to each other. This is done to keep penguin
temperature swings close to those in real life. Having an arbitrary constant in the simplest
formula also makes it easy to make changes.
An improvement to this formula would be to base the temperature gains on the relative
differences in temperature between the individual penguin temperature and the
environmental temperature. However because the individual and uniform temperatures
are calculated very differently it is difficult to combine the two calculations as you do not
know the relative temperature difference between them.
20
3.2.1.2
Individual Temperature Algorithm
To calculate the temperature gain from nearby penguins there are several metho ds:
Measuring the distance between penguins and applying a linear distribution would be a
poor choice. A linear distribution would provide unrealistic heat transference at almost
any distance because there would be no difference between direct contact between
penguins and large gaps of air between penguins.
Measuring the distance between penguins and applying an asymptotic distribution that
was capped would provide more realistic heat transference. By looking at figure 3-6, it
can be seen that at close distances, the contact between penguins would be reflected well
with higher temperatures. At distances, low values at longer distances would be given
which would reflect large air gaps between penguins.
Figure 3-6 Asymptotic graph (KTIMS, 2006)
Measuring the distance between penguins and using an inverse square to achieve a
temperature gain is a potential method. This is because the energy would radiate evenly
in all directions the same way energy such as electromagnetic energy does. This method
was initially used however the results were very poor. Penguins would swing to being too
cold very easily despite being close to several penguins; energy seemed to be dispersed
too quickly. This is because using an inverse square makes the assumption that a penguin
is a sphere and distributes heat evenly.
3.2.1.2.1
Temperature Spread in Penguins
Figure 3-7 shows the 2D cross-section or silhouette of a penguin from a side view. From
this angle, the shape is very different to a circle which an inverse square uses. It is much
closer to an ellipse or rectangle. The difference in shape dramatically changes how heat is
lost on a penguin.
The long sides of the penguin provide good contact for heat transfer with other penguins.
From above a penguin shape is circular. Arranging circular shapes close together results
in many small gaps. However, the body of a penguin is not solid like a rock. Rather, their
bodies are malleable; this means their bodies of penguins can contact each other much
better than solid circles can.
21
Figure 3-7 Emperor penguin silhouette
Environmental factors for heat transfer are the ice on the ground and the surrounding air.
The air in Antarctica is very dry with an average humidity of 0.03% (Antarctic
Connection). The low moisture level in the air significantly reduces the heat transfer into
the air. The final factor is the ice beneath the penguins. Ice is known as very good
insulator and therefore this reduces the heat transfer from the penguin feet into the
ground. Combining all these factors shows that the majority of heat transference happens
in the air in the horizontal plane and relatively little is lost in the vertical plane.
3.2.1.2.2
Asymptotic Temperature Distribution Algorithm
Based on the information in 3.2.1.2.1, an asymptotic distribution was chosen. The
pseudocode of the algorithm is as follows:
for each penguin[i] in simulation
{
for each penguin[j] in penguin[i] heatRange
{
x1 = penguin[i].GetXPos();
y1 = penguin[i].GetYPos();
x2 = penguin[j].GetXPos();
y2 = penguin[j].GetYPos();
radius = penguin[i].GetRadius();
//use pythagoras to work out distance
distance = sqrt(((x1-x2)*(x1-x2)) + ((y1-y2)*(y1-y2)));
penguin[i].PenguinTemperature += (radius/distance) * dt;
}
}
In the code above, the “heatRange” is the distance of 15 penguin radii. It is assumed that
no heat will travel beyond this distance. Within the heat range, the distance to each
penguin in range is measured. The distance between penguins is measured by the number
or radii away each penguin is then multiplied by delta time. This temperature value is
added to the current penguin temperature. The separation flocking rule prevents
penguins moving too close and getting unrealistically high temperature gains.
22
3.2.2 W IND
The wind direction and speed affects penguin movement and temperature. A penguin
colony will slowly move away from the prevalent direction of the wind, this can be shown
in figure 3-8. This slow movement of the colony does not cause every penguin to move in
the same direction. Rather, it is caused by penguins on the outside of the huddling group
being impacted by more wind than those in the centre; these penguins then move around
the other side of the colony to shield themselves from the wind.
Figure 3-8 Site of the emperor penguin colony at Pointe Géologie, showing the different
positions of the groups between June 1st and July 10th, 2000. In black outline are huddling
groups; in dark grey islands and Antarctic continent; in light grey icebergs. The Vallée des
Martyrs is located between the two islands. Breeding site is presented in dashed lines (Gilbert,
Robertson, Maho, & Ancel, 2007).
Accurately measuring the wind impacting each penguin is therefore important. Like with
temperature, creating a genuine physical simulation of wind turbulence on penguins is
well beyond the scope of the project. Instead a more simplified view of the physics
involved was taken with several options that were considered.
23
3.2.2.1
Wind Turbulence
When wind impacts an object, the air flow around it is disturbed. This can be shown in
figure 3-9. Penguins are not simple shapes and accurately measuring the wind impacting
any given penguin is not possible as there is no previous research on this topic.
Estimation was therefore used to calculate wind values.
Figure 3-9 Zone of disturbed flow over a small building (FLOYD, 2006)
Emperor penguins are more aerodynamic than the box shown in 3-9, so a region of
disturbed wind behind the penguin was chosen as 10 x penguin height. The area of
disturbed wind was calculated as a linear function. This can be shown in figure 3-10.
Figure 3-10 Penguin wind values, Red represents the wind cover provided directly
behind a penguin.
3.2.2.2
Ray Tracing
Using a method similar to ray tracing is one way to approach the problem. Using this
technique there are two directions that a ray can travel in:
Ray Direction = Wind Direction: This method is the most intuitive, an array of rays
moving towards the penguin colony. Using this method a large number of rays spread
close together would be needed for accuracy. Each ray would need to be compared to
every penguin in the simulation. This would be very computationally expensive as in the
simulation the position of penguins is not limited to a finite grid. This means that to
reduce the number of wasted ray comparisons, the rays should only travel in areas near
to penguins.
Ray Direction = Opposite of Wind Direction: Using this method rays travel from each
penguin in the opposite direction of the wind. If the ray from a penguin does not intersect
with any other penguins, it is hit by wind. This method is naturally much cheaper
computationally and easy to implement.
24
With the Ray direction as the opposite of the wind direction, using a single ray coming
from the centre of the penguin to intersect with other penguins would produce inaccurate
results. There are several ways to solve this:
Using a single ray then measuring the distance from the ray to the penguin intersection
partially solves this problem. This method is shown in figure 3-11. However, using this
method only one penguin can be used as adding coverage between penguins can cause
issues. Figure 3-12 shows multiple penguins on one side, simply adding the coverage of all
these penguins would result in full coverage, when in reality there would only be approx
60% coverage. This situation would be very common on the edge of a penguin group
where it is important to calculate the correct wind cover.
Figure 3-11 Wind cover using one ray
Figure 3-12 Issues with one ray
Using multiple rays, each ray is sent out and either hits another penguin or misses. The
more rays used, the more accurate the results. This is an effective way to measure wind
cover, figure 3-13 shows multiple rays used in the situation shown in 3-12.
25
Figure 3-13 Using multiple rays
A combination of techniques from single and multiple ray methods was used in the final
algorithm. In the final algorithm, one ray was used like three rays where each ray
measured the distance to the penguin that gave the most coverage in its area. The wind
coverage from each area was added together. The pseudocode is shown below:
for each penguin[i] in simulation
{
for each penguin[j] in penguin[i] windRange
{
//vector from penguin[i] to penguin [j]
xVector = penguin[i].GetXPos() - penguin[j].GetXPos();
yVector = penguin[i].GetYPos() - penguin[j].GetYPos();
hypotenuse = sqrt((xVector * xVector) + (yVector*yVector));
Normalize(xVector,yVector);
dot = (xVector * wind.XVector())+(yVector * wind.YVector());
//angle between wind and penguin
angle = acos(dot);
//distance between intersection of wind and penguin
distance = hypotenuse * sin(angle);
//make sure penguin is infront of wind, not behind
if(angle < pi/2)
{
if(distance is within penguin diameter)
{
if(distance > 0)
{
//2 radius away = 0 cover, 0 radius away = full cover.
tempCoverage = 1 - (distance/penguin[i].GetRadius() * 1/2);
}
else
{
tempCoverage = 1 - (distance/penguin[i].GetRadius() * -1/2);
}
if(tempCoverage > 0)
{
//10 radius away = 0 cover, 0 radius away = full cover
tempCoverage *= 1 - (hypotenuse/penguin[i].GetRadius())/10;
26
if(distance > penguin radius)
{
if(tempCoverage > leftCoverage)
{
//only use penguin which gives largest amount of cover
leftCoverage = tempCoverage;
}
}
else
{
if(distance < - penguin radius)
{
if(tempCoverage > rightCoverage)
{
rightCoverage = tempCoverage;
}
}
else
{
if(tempCoverage > mainCoverage)
{
centreCoverage = tempCoverage;
}
}
}
}
windCover = leftCoverage + centreCoverage + rightCoverage;
}
In the above code, the first part of the algorithm takes a vector from one penguin to
another. The angle between this vector and the wind vector is calculated in radians. This
angle will be between 0 and pi. The angle must be below pi/2 for any cover to be valid as
the angle between the wind vector and covering penguin must be within + or - 90˚. From
this point it is treated like a right angled triangle and using trigonometry, the distance is
calculated. The distance is then cut into three sections; each section can have a different
penguin that gives the most cover and the three cover values are added together for the
total wind coverage value.
27
4
IMPLEMENTATION
4.1 USABILITY
The usability of the application was an important aspect of a program. The program was
targeted to be useable by biologists rather than programmers and features a powerful
GUI capable on controlling a significant proportion of the program easily.
The structure of the GUI was consistent and simple. Almost all tasks were performed on
the right hand side of the simulation window shown in figure 4-1. The design was simple
with common tasks such as changing temperature easy to perform.
Figure 4-1 Penguin simulator with basic GUI tab
All buttons had the same shape; colour was used to differentiate between the different
menus. When changing between basic, advanced and expert menus, the colour
immediately below was the same as the button colour. This gave the look and feel or
several tabs and was an easy visualization to show which UI tab was active. This was
important because several of the UI tabs were similar and as such needed to be
differentiated. Simple icons were also used in the expert tab to differentiate between hot
and cold behaviours for penguins effectively.
The reset button reset the current UI tab to its default values. This encourage d the user to
experiment changing with different variables as resetting back to normal was very simple.
28
The controls for wind speed and wind direction were separated. Having the two controls
separated allowed for more precise control of each element individually, though some
found the controls less intuitive to use. If the controls were combined into one, it would
allow more fluid changes in wind speed and direction.
The use of UI elements such as slider bars, buttons and check boxes was consistent
throughout the design. Anything that had a yellow circle with a black border could be
dragged with the mouse. All check boxes were identical, used consistent positioning and
were easily recognised as check boxes.
Wording of components and items was consistent throughout different menus. Related
items such as general environment controls were placed near to each other while
unrelated items were separated by red headings and space. Feedback in changes of state
from slider bars was instant with values given on the right of every slider bar, though
some changes in sliders would require several minutes before the changes took full effect.
Feedback from check boxes was instant with an X appearing when active and empty when
inactive. All check boxes on the basic GUI also caused significant visual changes in the
simulation.
Support for keyboard shortcuts for commonly used control was implemented. Switching
between tabs was possible using the keys ‘1’, ’2’ and ‘3’ to switch to basic, advanced and
expert tabs respectively. The ‘P’ key was used to pause and unpause the simulation. The
Escape key closes the simulation.
4.2 FEATURES
The final penguin simulator had many features. General simulation features included
sliders to control the number of penguins, penguin speed, environment temperature,
wind speed and wind direction, a pause button also allowed for the simulation to be
paused while variables were changed. Each penguin also had its own individual
temperature.
A moveable view was implemented in the simulation. By dragging the mouse anywhere
within the simulation, the simulation would move the world view. This allowed for
tracking of penguins if the colony moved out of view. The change in view caused by the
dragging of the mouse was relative to the zoom level. When zoomed out, dragging moved
the view much further than when zoomed in. However, the relative movement an object
that moved across the screen stayed the same.
Coordinates within the simulation were shown in the bottom right corner. The coordinate
system was useful for moving the view around in the simulation. Next to the coordinates
the number of frames per second is shown. When the frames per second went below 30,
the text would turn red as a warning. This is because when the simulation was running
below 30 frames per second, the penguin behaviour would change as a lack of updates
would cause exaggerated movement.
29
Flocking features included support for three different flocking rule sets within the same
simulation at the same time. The flocking rule weight and range could be changed
separately in each of the three rule sets. The rule sets were based on individual penguin
temperature. This feature allowed for many different flocking patterns within the same
simulation.
Figure 4-2 User interface for general flocking rule, cold flocking rule and
hot flocking rule respectively
4.2.1 VISUALIZATIONS
To help understand what was happening in the simulation, several visualizations were
implemented:
Texture mapping: Using the library FreeImage (FreeImage, 2008), textures were loaded
into the program. These textures were used to create visual representations of the
environment, penguins and parts of the GUI.
Zoom: At the top left of the UI is a zoom feature. This zooms into or out of the centre of the
screen and can zoom far into or out of the penguin colony. This allowed for both an
overview perspective of the simulation and close inspection of individual penguin
movement.
30
Environment heat map: This heat map (see figure 4-3) shows the environment
temperature at any given point. The map does not visualise the general environment heat
variable as that it constant at every point. Rather it shows the relative temperature
values. Black means no gain and the higher the red value, the higher the temperature. The
resolution of the image can be changed with the environment detail slider (see figure 41).
Figure 4-3 Environment heat map visualization
Penguin heat map: This heat map shows the individual temperature of every penguin in
one of three colours (see Figure 4-4). Red means the penguin is hot and is following the
hot flocking rule. Blue means the penguin is cold and is following the cold flocking rule.
Green means the penguin is at a nice temperature following the green temperature rule.
Figure 4-4 Individual penguin heat map visualization
31
Visualised flocking rule ranges: Ranges for the flocking rules: alignment, cohesion and
separation can be shown visually. Just the separation range is shown in figure 4-5, though
the ranges of all rules together could easily be shown. Each rule had a circle of different
colour; this can be seen surrounding each penguin. Alignment is red, cohesion blue and
separation green. Each circle also has an alpha value so that even when grouped together,
the ranges or several penguins can be seen individually.
Figure 4-5 Visualisation of ranges for separation rule
Penguin wind map: This map is a visualization of the amount of wind each penguin is
being impacted by. Each penguin is represented by circle ranging from black to white.
Black represents no cover from wind and white represents full cover from the wind.
Figure 4-6 shows an example wind map with a north easterly wind.
Figure 4-6 Individual penguin wind visualization
32
4.2.2 LOGGING
The penguin simulation had many logging capabilities. The following items could be
outputted into a text file: Environment temperature, wind speed, wind direction, number
of penguins, penguins speed, penguin temperature, penguin vector, penguin position,
alignment info, cohesion info, separation info, and random weight info. This information
could be outputted at any sample rate between 0 and 10 seconds. The sample size could
also be queried between 0 and 100% of the penguin population. The log GUI can be seen
in figure 4-7. Logging is only active when the simulation is running, when the simulation
is paused as is the logging. Once the start button is pushed, the GUI greys out and the log
GUI controls are locked. This keeps log files consistent. The log feature outputs to a
unique file for each log “/log/outputX.txt” where X is the output ID.
Figure 4-7 Penguin simulator with log GUI tab
4.3 TESTING
Testing the penguin simulation was largely difficult given the nature of the program;
there were no automated tests as only very small parts of the program could be tested in
that manner.
Quantifying whether the penguins in the simulation were flocking properly was very
difficult. Measuring the distances to other penguins did not produce meaningful data
about the behaviour and was less reliable than pure observation. In biology this sort of
behaviour is examined by observation using a scale to measure each of the different
behaviours observed. To properly test this data would require a biologist who had an
expertise in penguins and ideally a biologist who had direct access to observe emperor
33
penguins. This would allow comparisons from the penguin simulation to the actual
penguin behaviour and variables could be matched better to fit the true flocking patterns.
Testing the flocking algorithms was also found to be difficult. This is because a flocking
rule would be functional and provided good penguin behaviour. The best method for
testing non-flocking algorithms was to visualise them. For example, by observing the
wind visualization data, it is much easier to spot incorrect data. Then by carefully
examining the code an unknown bug would appear. Fixing this bug would change the
behaviour and sometimes require readjustments of variables to achieve an improved
behaviour. Judging the differences between two very similar but different flocking rules
by observation alone was difficult especially if the bug fixed algorithm initially had worse
behaviour.
Other parts of the program were more testable. All Graphical elements of the simulation,
including the UI were tested extensively manually. As each GUI element was added, it was
tested for a variety of possible bugs. The ability for the UI to control almost all penguin
movement algorithms helped extensively in bug finding for flocking algorithms and bug
finding generally. By increasing and decreasing the weight and range of each flocking
algorithm, the behaviour that each flocking algorithm achieved was observed. By
observing this data inconsistencies could be checked for and bugs were seen visually.
Logging also acted to help test the program and provided a utility to record simulation
data to a file to help test any future penguin hypothesis.
34
5
EXPERIMENTATION
The experimentation phase of the project was to use the tools shown in chapter 4. This
involved using the visualisations to analyse the data then formulating a hypothesis to
improve the flocking behaviour. Extensive controls and features were implemented to
test different hypothesis to simulate penguin flocking under known conditions. Using the
UI to change environment and flocking controls many emergent behaviours were
observed.
When penguins were initialised into the environment they were given a random position
and orientation. All penguins initialised with an equal neutral temperature. The starting
conditions of penguins were therefore not immediately representative of conditions that
are present in the wild. This would cause the first minute or so of simulation to be
potentially inaccurate and behaviour may or may not be correct. The penguins would take
around a minute for a stable pattern in the simulation to emerge, though this number can
change depending upon the initial conditions.
Changing settings gradually within the simulation would slowly cause the penguins to
change behaviour in a realistic manner. However, sudden large changes within the
settings would quickly change penguin behaviour and it would again take about a minute
for changes to trickle through the simulation and a new pattern to emerge.
5.1 ONE FLOCKING RULE
Early in the program development all penguins would use the same flocking rule to flock
with. When all penguins used the same flocking algorithm it was easy to achieve a
huddling behaviour. This behaviour worked best with the following rule weightings and
ranges:
Alignment flocking weight: 0.6
Alignment flocking range:
120
Cohesion flocking weight:
Cohesion flocking range:
150
2.0
Separation flocking weight: 3.25
Separation flocking range: 66-150
Under these settings, general environment temperature was linked to separation value.
As the temperature was lowered as would the separation value and the penguins moved
closer together. The group behaviour would look similar to that of real emperor penguins.
However penguins would not move into and out of the colony, rather penguins on the
outer edges would stay on the outside while penguins in the centre stayed inside. This
meant individual penguins would not separate to cool down nor move closer to warm up.
Other behaviour that is exhibited in windy conditions could also not be replicated.
5.2 THREE FLOCKING RULES
To simulate penguin behaviour better, penguins would have different flocking rules based
on their temperature. Penguins that were too hot would be those in the centre of the
colony. These penguins would want to move away outside of the colony. Penguins too
35
cold would want to move closer to other penguins and move to the centre of the colony.
Penguins at the correct temperature would use the flocking rule used in 5.1.
For penguins too hot there were several ways to move the penguin to the outside of the
colony. Increasing the separation range or weighting helped slightly in moving a penguin
to the outside. However due hot penguins being surrounded by cold penguins, there was
never a clear path to the outside, only very occasionally would penguins be able to cool
down.
Using a negative cohesion weight was a very effective method of moving out of the group.
The penguins would move away from the centre of the local group, and combined with
separation, this would provide a path for the penguin to take. The penguin would move
aggressively towards cold penguins away from hot penguins and quickly make its way to
the outside of the colony. A smaller cohesion range was use for this attribute to stop the
penguin moving too far away from the colony.
Using a negative alignment weight slightly improved upon the previous two methods
decreased the time taken to move to the outside of the group. This is because there are
more penguins from the outside of the colony that are cold trying to reach the centre than
there are hot penguins from the centre trying to reach the outside of the colony. Due to
this characteristic, a negative alignment value will actually keep all hot penguins in
alignment and heading towards the outside of the colony. However the behaviour from
using a negative alignment did not seem natural and though penguins achieved their goals
quicker, the overall behaviour was worse. Using a smaller alignment weighting made the
behaviour more realistic.
For penguins too cold the penguins would want to reach the centre of the colony. For this
the cohesion range was increased so that the centre position of the colony could be better
established. The cohesion weight was increased slightly and the separation range was
reduced to keep cold penguins closer together.
What was found when using multiple flocking rules was that the flocking weights and
ranges would only be effective in a small range of temperature/wind variables. For
example a flocking rule set used to simulate penguins at -30˚C with 25mph winds may not
work well at -5˚C with no wind. Generalised algorithms could be made that are effective at
simulating a range of temperatures, though the quality of flocking behaviour would be
worse than an algorithm specialised at that specific set of variables. One of the more time
consuming parts of development was in modifying the flocking variables. Each time a
variable was changed, it could take up to 2 minutes for the change to fully take effect and
a new cycle of behaviour to be present. Testing one set of flocking rules against a range of
temperature values, wind values and colony sizes would took a significant amount of time
and many possible combinations were not tried due to this.
36
Another factor was the number of penguins. In small groups of 30 or so penguins flocking
rules that were tested on flocking of 150 or 300 would break down. This is because there
would not be enough penguins for the cyclic behaviours to occur such as that shown in
figure 5-1. The small groups would not generate enough heat so would be perpetually
cold and therefore only use one flocking rule. Penguin colonies are usually 1000s in size,
the algorithm using in figure 5-1 scales well to larger groups but not small. Using the UI
appropriate algorithms for small groups of penguins could be generated, though they
would unlikely scale well to large groups.
Figure 5-1 An example of using multiple rules to achieve different behaviours.
Figure 5-1 shows usage of these rules combined. In the bottom left side of the flock there
is a line of red penguins. These penguins are moving in the same direction to the outside
of the flock and in the opposite direction of the wind. They will then begin to cool down
and move around the outside of the flock and then begin to apply the cold penguin rule.
The penguins in the centre are a mix of cold penguins warming up and hot penguins
moving out. The penguin group is as a whole is also slowly moving in the direction of the
wind. Figure 5-1 used a generalised flocking algorithm. The values used to generate this
behaviour can be seen in the table below. To create better and more accurate flocking
behaviour would require a biologist with knowledge of emperor penguin behaviour.
Alignment Range
Alignment Weight
Cohesion Range
Cohesion Weight
Separation Range
Separation Weight
Random Weight
General
166
0.67
233
2.00
66
3.27
0.13
Hot Multiplier
1
0.33
0.27
-1.00
1.13
2.00
37
Cold Multiplier
1.0
1.0
2.0
1.33
0.73
1.0
-
6
REVIEW
At the end of semester one there was a partially working software prototype of flocking
behaviour. This prototype had representations of penguins and their environment; on the
screen the penguins exhibited flocking behaviour similar to that in the boids simulation.
The GUI backend was complete and the front end was not. Some behaviours and features
were not implemented on target. Significant hardware failures delayed development;
though recent backups meant very little work was lost it took time to repair the
equipment (see appendix A).
An underestimation of development time for the penguin flocking algorithm also delayed
the project. One of the difficulties was in identifying what was and was not appropriate
behaviour for the penguins. The penguin density was something that could be easily
observed and modified within the simulation. However observing more complex
behaviour was more difficult. Using a small group of penguins where it was possible to
identify what each penguin was doing was not useful in observing behaviour. Flocking
rules that work in large groups would break down when used in small groups and vice
versa. Testing the differences in flocking behaviour was also time-consuming and no
solutions could be found to improve this as the behaviour could only be judged by
observation.
Another difficulty was finding film of emperor penguins during the specific time of year
that was simulated. While there was statistical information on their flocking behaviour,
statistics cannot describe behaviour like a moving image can. Access to film of emperor
penguins huddling in various conditions where the temperature and wind information
was also available in real time would have helped development and accuracy of the final
algorithm significantly. However, no information like this could be found, to obtain such
information would likely require an expedition to Antarctica.
In semester two there was a significant amount of progress. Developing the flocking
algorithms and combining them with temperature and wind was the main priority in the
beginning of the semester. One of the early achievements of semester one was using
different flocking algorithms within the same group of animals. Often there are different
flocking rules for different species in a predator-prey simulation, using multiple flocking
rules for the same species is unique to this project. The next achievements were
implementing the temperature and wind calculations and integrating them with the
flocking rules.
Later in the second semester priorities were extending the software. Visualizations were
generally quick to produce and were very helpful in understanding the penguin
behaviour. A notable feature that was difficult to implement was the zoom feature. This
was because it required rewriting large parts of the rendering code for all previous
visualizations. Though most of the rewriting was simple, there were difficulties with the
environment heat map as it worked differently to most other visualizations. Goals were
far exceeded in the number of useful visualizations that were implemented.
38
A 3D visualization was not implemented due to the time needed to implement it versus
the usefulness of the feature. Implementing a 3D visualization would have required
rewriting too significant amount of the program. Had the program been designed for a 3D
view from the start rather than mid way through development it would have been more
viable. Several other visualizations were implemented though and these provided more
useful information.
One of the well designed parts of the program was the visual design of the user interface.
The general UI design was conceived early in the project and the layout was planned such
that there would be space on screen for new and unplanned features if necessary. These
spaces were used quickly in the basic UI tab. Most of the UI was based around slider so
the mechanism for adding sliders was made very simple such that spacing and position
would always be consistent between tabs.
One of the difficulties with the UI was the number of bugs that appeared. Adding an
element to the UI without bugs required changes in several different places in the code. A
better design in the implementation of adding UI elements would be a design
consideration if starting again. In total there were over 50 user interactive elements to the
user interface. While issues were usually quick and simple to solve, when multiplied by
the number of UI elements it quickly became a drain.
In the second semester the time plan was kept to well. However, in week 7 some simple
but useful features such as zooming were added. A draft for the final report was also not
finished until the end of Easter.
An appraisal of the project by task is below:
1. Develop Initial Software Structure: Completed on time.
2. Prepare Initial Report: Completed on time.
3. Background 2D research: Completed on time.
4. Background penguin research: Completed on time.
5. Background flocking research: Completed on time.
6. Develop Penguin flocking Algorithm: Completed on time. The workload for
developing the algorithm was initially underestimated, parts of the software were
rewritten and the new target for completion was easily met.
7. Design Software Tests: Completed on time. The flocking algorithm was tested and
developed manually until the behaviour looks similar to that of actual penguins. It
was then fine tuned by collecting data from the simulation and checking for
consistency.
8. Analyse Software Flocking Behaviour: Completed on time. This was initially
planned to be completed earlier, this task was delayed due to task 6 taking longer
than anticipated. This task was completed on time.
9. Develop 2D Software Prototype: Completed later than planned. The prototype was
functionally complete earlier than the date planned though it was finished in
semester two.
39
10. Develop Software User Interface. Completed on time. The main UI was completed
on time though there were lots of small modifications made after completion to fix
minor bugs or add new features.
11. Prepare Interim Report: Completed on time.
12. Extend Penguin Flocking Software: Completed early. The flocking software was
extended well beyond what was specified in the initial specification. The
visualizations from the initial spec were completed early and other extensions to
the software were made later in the spare time available.
13. Background 3D research: Completed early.
14. Develop 3D software prototype: This feature was not implemented.
15. Prepare Final Report: Completed on time.
16. Prepare for Software Demonstration: In Progress. The majority of preparation for
the software demonstration will begin closer to demonstration date due to other
module commitments, though some progress has been made.
6.1 ETHICS
There are no ethical considerations for simulating emperor penguins as it does not
involve interaction with any animals. There may be some interaction with the program
with humans and if this interaction was to be studied there may need to be some ethical
considerations.
6.2 FUTURE WORK
There has been little research into the flocking behaviour of emperor penguins and there
are many avenues of research that have not been explored:
A video capture from the program would be very useful. By being able to replay the same
scene and compare it to a video using a different but similar algorithm would make
quantifying the data easier. On a similar note, being able to save and load the states of
every penguin and apply different algorithms to the penguins from a set of saved base
states would allow direct comparisons between the behaviour of different flocking
algorithms and would significantly speed up the development of an algorithm.
Algorithmically there are many algorithms that were not tried in the simulation. In this
project, there were partially user-definable algorithms to control weightings and ranges
of flocking algorithms. However the ability to control weightings in the wind and
temperature algorithms as well as link flocking algorithms directly to wind and
temperature values could produce better flocking behaviour. Custom user-definable
algorithms within the program would also be possibility though would require much
work.
A 3D view from the perspective of someone at ground level looking at the penguins would
allow for direct comparisons between most footage of emperor penguin flocking and the
simulation. There is little footage of penguins from a top down view, and biologists with a
firsthand account may not be able to translate their knowledge into a top down
perspective.
40
Better simulation of temperature and wind values using real physics. Using real physics
the flocking behaviour of the penguins may improve and be even closer to that in the wild.
Though the computational cost of this would be enormous and the application would no
longer be real time. This loss of speed would significantly increase development times.
Simulation of other emperor penguin behaviour during different times of the breeding
season for example the journey to the breeding site the penguins exhibit a line formation
and must navigate by memory and landmarks, this could produce some interesting
problems and behaviour. The courting behaviour and behaviour of penguins after
penguin chicks have been born are also considerations.
6.3 CONCLUSION
The aims of the project were to model emperor penguins and environment in a realistic
way that mimics their natural one, and to allow experimentation to show different
penguin behaviours. This project has discussed the flocking behaviour of many species
and applied that knowledge to penguins. It has then modelled their environment to
produce the unique behaviour of emperor penguins. It finally produced a powerful UI
capable of controlling most of the program. This project has achieved its goals and even
gone further with tools to aid the understanding of penguin behaviour. New ideas have
been brought into topic of flocking algorithms and the topic of emperor penguin flocking
has been opened up more for further research.
41
7
REFERENCES
Antarctic Connection. (n.d.). Weather in Antartica. Retrieved April 10, 2009, from The
Antarctica Connection:
http://www.antarcticconnection.com/antarctic/weather/index.shtml
Bourg, D. (2004). AI for Game Developers. O'Reilly Media.
Editors of The American Heritage Dictionaries. (2000). The American Heritage Dictionary
of the English Language, Fourth Edition. Boston: Houghton Mifflin Company.
Floyd, D. (2006). Measuring Wind Speeds for Small Trubine Sites. Oregon: Oregon State
University.
Franklin, S., & Graesser, A. (1996). Is it an agent, or just a program?:A taxonomy for
autonomous agents. Proceedings of the Third International Workshop on Agent Theories,
Architectures and Languages. New York: Springer-Verlag.
FreeImage. (2008). Download. Retrieved April 10, 2009, from The FreeImage Project:
http://freeimage.sourceforge.net/download.html
Gardner, M. (1970). Mathematical games: The fantastic combinations of John Conway's
new solitaire game "life". Scientific American , 120-123.
Gilbert, C., Robertson, G., Maho, Y. L., & Ancel, A. (2007). How do weather conditions affect
the huddling behaviour of emperor penguins? Strasbourg: Springer.
Greenbank, J. N. (1999). Simulating Creature Behaviour: An Investigation. Retrieved
January 5, 2009, from James GreenBank's HomePage:
http://members.fortunecity.com/jngreenb/sim.html
Grimm, V. E., & al, e. (2005). Pattern-oriented modeling of agent-based complex systems:
lessons from ecology. Science , 987-991.
Jacquet, L. (Director). (2006). March of the Penguins [Motion Picture].
Kennedy, J., & Eberhart, R. C. (2001). Swarm Intelligence. Morgan Kaufman.
ktims. (2006, March 15). Hyperbola One over X. Retrieved April 2009, 10, from Wikipedia:
http://en.wikipedia.org/wiki/File:Hyperbola_one_over_x.svg
Langton, C. G. (1995). Artificial Life: An Overview. The MIT Press.
Levy, S. (1993). Artificial Life: A Report from the Frontier Where Computers Meet Biology.
Vintage.
Lynch, W. (2007). Penguins of the world. London: A&C Black.
42
Martin, E. (2005). John Conway's Game of Life. Retrieved January 5, 2009, from Edwin's
Journal: http://www.bitstorm.org/gameoflife/
Martin, G., & Katzir, G. (1999). Visual Fields in Short-Toed Eagles, Circaetus gallicus
(Accipitridae), and the Function of Binocularity in Birds. Brain, Behaviour and Evolution .
Partridge, B. (1982, June). The Structure and Function of Fish Schools. Scientific American ,
114-123.
Peterson, I. (2000). Calculating Swarms. Science News , 314-316.
Reynolds, C. W. (2007). Boids ( Flocks, Herds, and Schools: A distributed behavioural model .
Retrieved October 20, 2008, from http://www.red3d.com/cwr/boids/
Reynolds, C. W. (1987). Flocks, Herds and Schools: A distributed Behavioural Model.
SIGGRAPH '87 Conference Proceedings, (pp. 25-34).
SwarmWiki. (2009). Retrieved January 5, 2009, from SWARM, A platform for agent-based
models: http://www.swarm.org
Williams. (1995). The Penguins. Oxford: Oxford University Press.
43
APPENDIX A: M EETING NOTES
Meeting 1, 2nd October 2008:
Notes:
-Project supervisor change from Dr Purdy to Dr P Chapman.
Tasks:
-
Research Craig Reynolds and flocking algorithms.
Research penguin biology and behaviour.
Long term:
Christmas target – 2D penguin simulation of flocking, UI with sliders for
penguins/wind/temperatures/etc
Meeting 2, 7th October 2008:
Tasks:
-
Understand problem, research biology and AI.
Work on software - Begin work on initial algorithm/rules
Work on initial report
Long term:
Iterate on algorithm and implement it.
Meeting 3, 16th October 2008:
Tasks:
-
Research/Develop Algorithm more
Work on Initial report –
o Gantt chart for project
o Describe boids and simulations
o Describe bird and fish behaviour
44
Meeting 4, 21st October 2008
Tasks:
-
Finish Initial Report
o Email draft to supervisor
o Risk analysis (software issues?)
o Context and task list
Meeting 5, 5th November 2008
Received feedback from initial report
Tasks:
-
Define spec based on users - biologists?
Flocking rules and algorithm
User Interface
Meeting 6, 12th November 2008
Tasks:
-
-
Algorithms
o Vector arithmetic
o Efficiency
o Movement
Implement basic flocking
Meeting 7, 19th November 2008
Notes: Simultaneous hard drive failure of OS hard-drive and main data drive, No meetings
until PC is in a working state.
Tasks:
-
Retrieve most recent backups (3 days old)
Begin fixing PC
o Purchase new hard-drives
o Install OS
o Download/Install various required programs (visual studio, etc)
45
Meeting 8, December 5th 2008
Tasks:
-
Research ways to simulate heat and wind.
Begin work on Interim Report.
Meeting 9 – Cancelled due to flu
Meeting 10, 6th February 2009
Tasks:
-
Begin implementation of multiple flocking rules
Meeting 11, 13th February 2009
Received Feedback from Interim Report
Tasks:
-
Implement Dragging
Implement Texture mapping
Meeting 12, 20th February 2009
Tasks:
-
Implement wind variable
Implement heat variables
Meeting 13, 27th February 2009
Tasks:
-
Implement heat visualizations
Work on User Interface
46
Meeting 14, March 2009
Tasks:
-
Finish implementation of flocking rules.
Meeting 15, March 2009
Tasks:
-
Implement Zoom
Implement logging
Begin work on final report
Meeting 16, March 2009
Tasks:
-
Produce Draft Final report
Bug fixing and small changes to software only.
Meeting 17, 20th April 2009
Received feedback from draft
Tasks:
-
Continue Final report
Meeting 18, 29th April 2009
Received feedback from draft
Tasks:
-
Finish Final report
47
APPENDIX B: PROJECT T IME P LAN
2008
October
November
Summer
Task
2009
December
January
Semester 1
1
2
3
4
5
6
Xmas
7
8
9
10
11
12
1
2
Exams
3
4
1
Develop Initial Software Structure
Prepare Initial Report
D
Background 2D Research
Background Penguin Research
Background Flocking Research
Develop Penguin Flocking algorithm
Design Soft ware Tests
Analyse Soft ware Flocking Behaviour
Develop 2D Soft ware prototype
M
Develop Software User Interface
M
Prepare Interim Report
D
Extend Penguin Flocking Soft ware
Background 3D researc h
Develop 3D Soft ware prototype
Prepare Final Report
Prepare for Software Demonstration
Exam revision
Other Module Deadlines
Key
D = Deadline
M = Milestone
48
2
2009
Task
Develop Penguin Flocking algorithm
Analyse Soft ware Flocking Behaviour
Develop 2D Soft ware prototype
Develop Software User Interface
Extend Penguin Flocking Soft ware
Prepare Final Report
Prepare for Software Demonstration
Exam revision
February
March
Semester 2
1
2
3
4
5
6
7
8
April
Ea ster
1
2
3
May
Semester 2
9 10
11
M
M
Key
D = Deadline
M = Milestone
49
D