Content uploaded by Ronaldo Menezes
Author content
All content in this area was uploaded by Ronaldo Menezes on Apr 14, 2014
Content may be subject to copyright.
Simulating Robot Collective Behavior using StarLogo
Andy Tinkham
Florida Institute of Technology
Department of Computer Sciences
150 W. University Blvd.
Melbourne, FL 32901, USA
atinkham@fit.edu
Ronaldo Menezes
Florida Institute of Technology
Department of Computer Sciences
150 W. University Blvd.
Melbourne, FL 32901, USA
rmenezes@cs.fit.edu
ABSTRACT
Robot simulation is a very important tool to the development of
novel real-world techniques for cooperation of teams of robots.
One major difficulty when trying to introduce students to robotics
is that the teaching of major abstractions used to coordinate group
robot behavior is not easily visualized – it is not always true that
one has enough robots available to be used in real demonstrations.
In this paper, we attempt to improve the situation above by imple-
menting a robot simulator for 5 (five) of the major abstractions used
in robotics. This simulator concentrates on group coordination in a
scenario where robots are required to find their way out of a room
or maze. This paper describes our initial version of this simulator,
as well as our future plans for the simulator, both in usage and in
enhancement of the feature set.
Categories and Subject Descriptors
I.2.8 [Computing Methodologies]: Artificial Intelligence—prob-
lem solving, control methods and search; D.3.m [Programming
Languages]: Miscellaneous—StarLogo
General Terms
Performance, Design, Experimentation
Keywords
random coordination, shared map coordination, broadcast coordi-
nation, contact coordination, stigmergy coordination, swarm intel-
ligence, robots, StarLogo, learning by imitation
1. INTRODUCTION
Robot behavior has been extensively studied in the literature.
From the use of imitation [1] to the simulation of swarms [6, 4]
via the use of stigmergy or related forms of communication, robot
teams have been implemented in several ways. However, students
are not easily introduced to this field. This is particularly due to a
lack of visual stimuli that would help them understand in high level
Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies are
not made or distributed for profit or commercial advantage and that copies
bear this notice and the full citation on the first page. To copy otherwise, to
republish, to post on servers or to redistribute to lists, requires prior specific
permission and/or a fee.
ACM-SE 2004, April 2-3, 2004, Huntsville, Alabama
Copyright 2004 ACM 1-58113-870-9/04/04 ...$5.00.
terms the diverse forms in which robot teams can be coordinated to
achieve a goal.
For this reason, during a Swarm Intelligence course offered by
the department of Computer Sciences at Florida Tech, we set off to
develop a simulator to allow us to visualize the different methods
we envisioned robots using to find their way out of a room in which
they had no pre-existing knowledge. The “maze” scenario was used
because it is a classic example of cooperative work.
We chose five methods that the robots might use to escape and
implemented the approaches using the StarLogo language, devel-
oped at MIT [5]. The five methods are: (i) moving around ran-
domly; (ii) sharing a mental map of the maze across the population
of robots; (iii) broadcasting their individual mental map within a
certain radius; (iv) exchanging their mental maps when they run
into each other; and (v) using a pheromone to implement a swarm
of robots where the solution for the maze emerges from local inter-
actions and stigmergy.
We chose StarLogo largely for the extra relevant functionality
that it provided us. StarLogo is defined especially for use in these
kinds of simulations and so provides “turtles” which are indepen-
dent objects, “patches” which are the squares that the turtles move
around on, and functions to move the turtles, diffuse information
amongst the turtles and patches, and other functionality that we
would have had to code ourselves if we had tried to use another
language, such as Java. In this paper, when we refer to “robots”,
“gargoyles”, or “pheromone-markers”, we are referring to different
types of turtles in our simulator. Additionally, StarLogo is normally
known to freshman computer science students who normally have
contact with the language in school. This familiarity with the lan-
guage will enable us to attract students to work on improvement the
current system.
This paper is divided as follows: in Section 2 we discuss the main
features of the simulator such as user interface, sliders, etc. Then,
in Section 3 the implementation of the simulator is explained. Next,
we discus in Section 4 some of the current problems the simulator
has. Last, in Section 5 we discuss, the improvements expected in
future releases.
2. ABOUT THE SIMULATOR
The simulator attempts to be as realistic as possible with regards
to the movement of robots in the maze scenario. In the pictures
used in this paper, there are no walls but this still constitutes a maze
from the point of view of the robots as they are not equipped with
vision cognition. Each robot (in all group coordination mechanisms
implemented) can only “see” its current cell and the cells in the path
(the room) immediately around its current location.
At its heart, the simulator consists of a “room” – representing
the maze – in which simulated robots move, trying to find the exit
396
– represented by a door. Many aspects of the simulator are con-
figurable such as the width of the door – since the wider the door
the easier the robots should be able to find it – and the number of
robots initially in the room – the larger the number of the robots the
more restricted is their movement.
The robots are initially dispersed throughout the room (though
clustered around the center), and then put in motion. Only one
robot can occupy a physical space in the room. The type of simula-
tion being performed then determines how the robots behave. The
simulator can be configured to run until all the robots have exited
the room or for some specified number of movements (or steps). In
Section 5 we explain that one of our near future plans is to observe
convergence and adaptiveness of the various coordination abstrac-
tions used (see Section 5). We hope that tools such as this simulator
will aid the teaching of robot programming since students can sim-
ulate the consequences of their programming before they actually
attempt to program.
2.1 The User Interface
Figure 1 shows the graphical user interface of the simulator. The
room with the robots in it is located in the center, while on the left
side of the window are the buttons that trigger actions and on the
right side are the sliders that are used to configure the simulator
as desired. Underneath the room are several buttons, monitors and
sliders that show the core information about the simulator as it is
running. The lower left hand corner of the window also includes a
plot showing the number of steps taken in the run plotted against
the number of robots remaining in the room after each step. We will
examine each of these areas in turn in the following subsections.
The components are grouped according to their relevance to a
particular coordination mechanism. For instance the evaporation
rate and diffusion rate sliders are grouped because they both relate
to the Pheronomes coordination mechanism.
2.1.1 Buttons
On the left side of the main simulator window, there are 10 but-
tons. These are the buttons that control the actions of the simulator.
The first three buttons are used to setup the simulator prior to run-
ning it:
Initial setup: creates the room’s outer wall and places the door
randomly according to the width defined in the slider. This
button is associated with a procedure in the simulator that
initializes all the necessary variables.
Setup robots: creates the robots in the room and spreads them out
so that no patch has more than one robot on it. The procedure
makes sure that robots are not stacked on top of each other
or placed over walls.
Final setup: creates the “gargoyles” that sit on the wall patches.
We will talk more about the gargoyles in the section that de-
scribes the contact method of moving around the room. The
final setup is also used to make sure that newly drawn walls
(the simulator allows the user to manually draw extra walls)
are recognized by the simulator as such. Without this final
setup, robots would just go through the walls as if they were
not even there.
The next five buttons trigger the various coordination mecha-
nisms used by the robots for finding where the exit is located (and
will be discussed more in Section 2.2). The final two buttons are
used for cleaning up portions of the run:
Reset room: kills off all the robots and resets all the patch vari-
ables to their initial states. This button allows a simulation
to be run using the same room and walls as were used in a
previous run without the need to redraw the room. This is
important when trying to draw convergence results since we
want to make sure all the coordination methods are run under
the same conditions.
Reset plot: restores the plot of robots remaining vs. steps taken to
its initial (data-less) state.
2.1.2 Sliders
The 12 sliders on the right side of the simulator window control
various aspects of the simulator. Some of these aspects affect only
one movement method, while others affect several methods and
some are global in scope, affecting the simulator in ways that go
beyond changing the methods (such as configuring the width of the
door or the number of robots in the room).
The first four sliders control general aspects of the room:
Width of outer Wall: sets the thickness of the outer wall, thus
changing the interior dimensions of the room.
Width of Door: sets the number of patches that are used to make
the door. Robots should find wider exits more easily than
narrow ones.
Extra Door-Weight: sets the amount of extra weight given to phe-
romone left on the door patches when running in Pheromone
mode. This is useful because pheromone diffuses and evapo-
rates from the edges, and so the door tends to lose pheromone
prior to the spaces in front of the door. This makes it so that
the robots become more inclined to avoid the door than go
to it – without this the largest pheromone concentration will
occur just in front of the door and not at the door.
Mapped Door Threshold: sets a level that a random number must
be greater than before a robot heads towards the door once it
appears on the map. This is to somewhat counter the fun-
nel effect where the robots all immediately head for the exit
once they know about it when they are using the shared map
and broadcast methods. The higher this value is set, the less
likely the robots are to immediately head out the door as soon
as they see it on the map.
The next pair of sliders relate to robot movement:
Wiggle Amount: controls the amount of variance in a straight line
path that the robots have. This slider affects all five move-
ment methods. The robots have a bit of wiggle introduced to
add some randomness to their direction. The wiggle works
by having each robot turn a random number of degrees to the
right, then a different random number of degrees to the left.
This slider controls the maximum value for each of those
random numbers. Higher wiggle values add more variation
to the robots’ paths which can eventually become detrimental
to the goal of finding the door.
Scan Distance: when the head towards door option is enabled, the
robots look at the patches in their immediate vicinity to see
if they are near the door. The value of this slider controls
how far out from the robot’s current patch they look. Higher
values make the robots look further away which makes them
find the door more quickly, but also makes the simulation
run more slowly because the number of neighboring patches
is larger.
The third set of sliders affect the broadcast movement method:
397
Figure 1: User interface of StarLogo Robot Simulator
Number of Broadcast Rings: the broadcast movement method si-
mulates the tapering off of a broadcast signal. This slider
controls the number of concentric broadcast rings used to
get this effect (for more information on how this effect is
achieved, see Section 2.2.3 on the broadcast method). More
broadcast rings mean a finer-grained resolution in determin-
ing which robots receive the broadcast.
Transmission Radius: sets the distance that the furthest transmis-
sion reaches. This radius is split up into the number of rings
specified by the number of broadcast rings slider described
above. A larger transmission radius means more robots re-
ceive the broadcast from a robot.
The fourth set of sliders affect the patches’ pheromone states:
Evaporation Rate: after the robots move in each step, the pheromones
in each patch diffuse and evaporate. This slider controls
the percentage of pheromone that evaporates in each step.
Higher evaporation rates mean that the pheromone trails dis-
appear more quickly.
Diffusion Rate: during the diffuse and evaporate portion of a step,
each patch passes on some percentage of its pheromone amount
to its neighbors. This slider sets that percentage. Higher dif-
fusion rates lead to wider but weaker paths.
The final set of sliders affect the core settings of the simulator:
Max Steps: sets the maximum number of steps that the simulation
should run for. If this slider is set to 0, the simulation runs
until all the robots have found the exit.
Number of robots: sets the number of robots that are placed in the
room.
2.1.3 Bottom Core Settings Controls
The final set of controls on the window toggle variables and show
the current state of the simulator. The two button/monitor pairs
toggle optional features of the simulator:
Head towards door: this button and monitor are used to change
the status of the head towards door option. When this op-
tion is enabled (the monitor shows true), robots scan their
immediate vicinity (to the extent determined by the scan dis-
tance slider) and look for the door. Enabling this option
makes the simulator run more slowly but allows the robots
to find the door more quickly by removing the possibility of
near misses where robots approach the door only to change
direction and move away.
Logging: setting the logging monitor so it displays false turns off
the generation of the output file and plot. Note that the output
file is not available when running the simulator through a
browser.
The two stand-alone monitors display the number of steps ex-
ecuted/remaining and the number of robots remaining in the sim-
ulation. The step monitor varies based on the setting of the max
steps slider - if max steps is set to 0, the monitor shows the num-
ber of steps that have been executed; if max steps is set to some
other value, the monitor shows how many steps remain to be ex-
ecuted. These values are stored in the logs so that they can later
be used in the study of converge characteristics of the coordination
mechanisms that have been implemented.
398
2.2 Robot Coordination Mechanisms
Coordination is an interdisciplinary field which studies interac-
tions between active components of a system [3]. Here we con-
centrate on trying to simulate several coordination schemes used
in group robot mobility. Each of the movement mechanisms make
the robots move in different ways. There are, however, some sim-
ilarities that should be addressed prior to looking at the individual
methods.
First, robots are prohibited from walking on the walls. If a robot
has some way to avoid walls in its movement method (such as a
map), it will avoid running into the walls that it knows about. If a
wall does not appear on the robot’s map, the robot may try to run
into it, wasting a step. If the robot has a means to store the location
of the map, it does so the first time it runs into the wall. Depending
on the movement method selected, one robot running into a wall
patch may make other robots know of that wall patch’s existence.
Robots are also programmed not to run over other robots. In the
case where a robot tries to move to a space occupied by another
robot, the moving robot instead wiggles and remains on the space
it was originally on until the next step where they repeat the process
of determining which space they will move to and try to move there
again.
2.2.1 Random Coordination
In the random movement method, the robots simply move at ran-
dom throughout the room. They have some wiggle to keep them
from simply bouncing off the walls in straight lines, but otherwise,
they simply move wherever they desire.
Figure 2: In random coordination, robots are uniformly dis-
tributed on the maze.
At first this form of coordination may not seem very interesting.
However, for experimental purposes it sets the lowest bar possi-
ble. That is, any other (reasonable) method should do better than
random.
2.2.2 Shared Map Coordination
For the shared map movement method, the robots all have access
to the same representation of the maze. As robots find a wall or the
door, the location of that patch is added to the global map and be-
comes immediately accessible to all the robots in the simulation.
This coordination mechanism is similar to standard centralized ap-
proaches.
The motivation for this coordination mechanism is that it should
converge very rapidly. Also we expect it to perform very well under
a configuration in which the room has no internal walls (such as the
one depicted in Figure 2).
In Section 5 we point out that having a global representation of
the room is much easier than knowing how to use it efficiently.
2.2.3 Broadcast Coordination
The broadcast movement method is similar to the shared map
method, but each robot has its own map. When one robot finds
a wall patch or the door, it broadcasts that finding to other robots
within a given transmission radius. The broadcast mechanism is set
up to simulate the tapering off of a broadcast signal. The transmis-
sion radius is split up into a number of concentric rings (the number
of which is determined by a slider). All of the robots inside the first
ring receive the broadcast. Each subsequent ring has a percentage
of the robots in it that receive the broadcast. This percentage is cal-
culated so that it decreases evenly over the rings and the probability
of a robot outside the last ring receiving the broadcast is 0. Thus,
the further out a robot is from the broadcasting robot, the less likely
it is that it will receive the broadcast.
Broadcast is also related to learning by imitation. Although the
simulation does not force a robot that received the broadcast to im-
itate the transmitter robot, it improves the chances that both robots
will work under the same conditions. Since the simulation assumes
a homogeneous group of robots, these robots are likely to make
similar decisions if they have the same information with them.
2.2.4 Contact Coordination
Robots also have an individual map in the contact movement
method. In this method, when a robot finds a wall patch, it puts
that patch on its own map. Then, when the robot tries to move to a
patch that is occupied by another robot, the robots share their maps
with each other, merging the two together. This merging reflects the
map only at the time of contact and does not form a permanent tie
between the maps. It should also be noted that unlike the Shared
Map and Broadcast methods, door patches are not stored in this
method. This is because they would never get transferred, as a
robot that finds the door is removed from the simulation and does
not come into contact with any other robots.
The motivation for contact coordination already relates to swarms.
Some types of ants do not leave pheromone traces but exchange in-
formation when they bump into each other. This mechanism aims
at simulating the workings of these swarm-based individuals.
2.2.5 Stigmergy Coordination
In the final movement method, each robot remembers the path
that it takes as it wanders around the room. Once a robot finds
the door, it marks its path with pheromones. Other robots that en-
counter this pheromone trail choose the next patch they will move
to by using the amount of pheromone on the surrounding patches
as a weighting. This is done stochastically based on the standard
formula below (based on a formula given in [2])
Pk
ij (t) = [τij (t)]α
Pl∈Jk
i[τil (t)]α(1)
The original formula from which the formula above is derived is
used in the ant-colony solution to the traveling salesman problem
where the amounts of pheromone are summed and each possible
space is weighted based on the amount of pheromone it has relative
399
to the total sum of pheromones in the neighboring patches. The
next position to move to is chosen with a probability equivalent to
its pheromone (τ) amount divided by the total amount of surround-
ing pheromone.1
Figure 3: Robots find the door and diffuse pheromone around
the exit.
For our case in the simulator, when a path is marked with pheromone,
each patch in the path gets marked only once, even if the robot
crossed the patch multiple times. This avoids getting false centers
in a patch that may be far from the door but which was traversed
multiple times by a given robot.
3. IMPLEMENTATION
As stated previously, the simulator is implemented in StarLogo.
While StarLogo provides much of the functionality we required,
and thus most of the implementation is relatively straightforward,
some creative constructs were needed to make everything work the
way we wanted.
For example, the maps that the robots used are implemented as
patch variables rather than turtle (robot) variables. We did this be-
cause turtles have unique identification numbers while patches are
represented by coordinates. Each wall patch simply keeps a list
of the turtles that know about that patch. Querying the map then
consists of each turtle asking the patch immediately in front of it
whether the turtle doing the querying knows about a wall at the
patch.
Door map locations are stored differently, however. Each robot
has two variables that store the absolute x- and y-coordinates for
the door. This allows the robots to easily be told to head towards
those coordinates once they know where the door is.
Another piece of implementation that is not obvious is the de-
termination of which robots receive a transmission in the broadcast
movement method. For each ring after the first one, a list of all
robots inside the current ring is obtained. This list includes both
the robots inside just the current ring and the robots inside all the
inner rings of the broadcast as well. Two lists are kept as the rings
are handled. The first one stores the IDs of the robots that have been
1The original formula (1) given in [2] also uses a distance factor
between the current node and its neighbors (η). In our implemen-
tation of the formula, αis equal to 1.
chosen to receive the broadcast. The second one holds the IDs of
all the robots that have already been considered for inclusion. It
then becomes easy to determine whether a robot is newly included
by the current ring by determining if we have already considered it.
The contact movement method required the addition of “gar-
goyles” to the simulator. Gargoyles are invisible turtles that sit on
the wall patches that robots can run into. As a single robot (or more
generally, turtle) cannot ask a group of patches to do something in
StarLogo, the gargoyles are used to change the maps on the patches
they sit on. Thus, when two robots come in contact with each other,
one asks each gargoyle to update its patch’s map so that any patch
that indicates that the first robot knows about it now also indicates
that the second robot knows about it, and vice versa.
The pheromone movement method was not without its imple-
mentation dilemmas as well. As the robot moves around, it stores
the absolute x- and y-coordinates of its location with each step (Ab-
solute coordinates are based off of the origin being in the center of
the room). However, most turtle commands in StarLogo work on
relative coordinates, where the patch the turtle is on serves as the
origin. Rather than try to convert the absolute coordinates to rel-
ative coordinates so that the robot could leave its own pheromone
markers, we created a third breed of turtle, called the pheromone-
marker. Each simulation has only one of these turtles, which sits
invisibly in the center of the room, without moving. Thus, the
pheromone-marker’s relative coordinates correspond to the abso-
lute coordinate system. A robot that has found the door passes its
id and path to the pheromone-marker which then marks the path
appropriately.
The mechanism used by the head towards door setting is not
a creative implementation, but still merits explanation. The robot
begins by checking the 8 immediate neighbors to the patch it is
on. It begins this checking with the space directly in front of it and
then proceeds in a clockwise fashion. It then increments a distance
counter, checks to make sure the distance counter is less than or
equal to the scan distance and checks the next surrounding square
of patches, again starting at the patch immediately in front of the
robot and proceeding clock-wise around the square. This increment
and progress around the square pattern is repeated until the distance
counter is greater than the scan distance.
One last implementation detail we needed was the addition of
pxcor and pycor variables for the patches. These variables store
the absolute x- and y-coordinates of the patches, and are used in-
stead of the built-in xcor and ycor variables, because when we
tried to access the xcor and ycor variables from a robot, StarL-
ogo would look for a robot on the patch and when there was none,
would return 0, 0 instead of the xcor,ycor variables. We surmise
this is because both turtles and patches have xcor and ycor vari-
ables, and the similarity in names is causing problems.
4. KNOWN SHORTCOMINGS
While this version is stable enough to release, there are a few
shortcomings that have not yet been dealt with. First, if the scan-
distance is set much higher than 3, an echo effect occurs. StarLogo
treats the area on which the room is drawn as a sphere. We have
flattened it into the square it looks like, but not all commands have
been made to work with the flattened area. Thus, when a robot is
checking its vicinity, the patches it is checking may wrap around to
the opposite side of the room, depending on the setting for the scan
radius. If the robot is near the wall that is opposite the door, it may
find the door in its check and try to reach it by going through the
wall. This limitation will be fixed in future versions of the simula-
tor.
A second shortcoming is in the pheromone movement method.
400
The simulator currently runs extremely slowly in this mode and
takes far more steps than it seems it should. While it is possible our
perceptions are incorrect, and this is a true implementation of the
model, we will be reviewing the implementation of the method in
depth and possibly changing it for future versions of the simulator.
5. FUTURE WORK
Foremost in our plans for the simulator (once the shortcomings
are addressed) is to run the simulator in the various modes and com-
pare the outputs. We expect to find that different methods are best
in different situations. For example, in a wide-open room with no
internal walls blocking paths, the shared map method is probably
the best, since no robot encounters a permanent obstacle as it moves
towards the door once one robot has found it. However, in a room
with a complex inner wall structure, the head for the door option
may cause a robot to get trapped and be unable to exit the room.
In this case, one of the other methods may prove to be a far bet-
ter approach. We plan to use our simulation runs to determine the
circumstances in which each approach is most successful.
The above relates to the problem that knowing where the exit is
not necessarily the same as knowing how to get there. Take the
analogy of a person in a real maze. If you are told that the exit
is in the southeastern corner of the maze, does this mean that you
know how to get out of it? Not necessarily, as moving southeast
may turn out to be the worst approach. In the case where no walls
are present, then knowing where the the exit is helps significantly.
We also plan to enhance the feature set of the simulator by adding
the following functionality (in rough order of priority):
•Enhancing the output generated by a run so that details of all
the settings are stored, making it easier to reproduce a given
run.
•Giving the robots the ability to follow alongside a wall as a
method to get around a wall that is in their way. Ideally, it
will be possible for a robot to follow a wall on the map and
determine a good heading based on the map data.
•Giving each robot the ability to remove cycles from its stored
path. Pheromones would thus be better distributed on the
shortest equivalent of the path the robot took.
•Implementing the concept of virtual walls. If a robot com-
pletes a circle, it can safely say the door is not inside that
circle. If it marks the patches in the circle as virtual walls,
fewer patches remain to explore. While this may not lead to
the shortest path, we expect it will make the robots exit more
quickly.
•Implementing the concept of a fitness value for each patch.
This fitness value will be calculated based on the patch’s dis-
tance from a wall and will serve as an indicator of what the
best path might be.
•Adding controls so that some interior walls are optionally
created automatically. This would give those who use the
simulator through a web browser the ability to have a more
complex room than the wide-open room to which they cur-
rently are limited.
•Adding the capability for the walls and doors to move during
the simulation run. We can then examine the coordination
methods and see how well they function in a dynamic envi-
ronment.
•Adding the ability to have additional robots created during
the simulation, rather than having them all exist prior to the
beginning of the run.
•Implement some sort of trust functionality. This would per-
haps have some robots deliberately sharing incorrect infor-
mation in contact mode, broadcasting false data in broadcast
mode, or putting false data on the map. Taken further, robots
might have some form of determining the trustworthiness of
a piece of information based on who provided it.
6. SIMULATOR AVAILABILITY
The simulator is available in two places: online through a browser
at http://my.fit.edu/ atinkham/swarm-sim and downloadable from
http://my.fit.edu/ atinkham/swarm-sim/Robotsim.slogo. The most
current version of this paper will be available (for the foreseeable
future) at http://my.fit.edu/ atinkham/swarm-sim/paper.pdf. We en-
courage you to download and modify the simulator however you
wish. We request, however, that any modifications be shared with
the authors at the email addresses listed at the beginning of the pa-
per.
Acknowledgements
Our thanks to Ahmed Charles and Heather Tinkham for assistance
with the development of this simulator, and to everyone we have
shown this simulator to, for responding with enthusiasm about it.
7. REFERENCES
[1] P. Bakker and Y. Kuniyoshi. Robot see, robot do: An overview
of robot imitation. In Proceedings of the AISB96 Workshop:
Learning in Robots and Animals, 1996.
[2] E. Bonabeau, M. Dorigo, and G. Theraulaz. Swarm
Intelligence: From Natural to Artificial Systems. Oxford
Press, 1999.
[3] Thomas W. Malone and Kevin Crowston. The
interdisciplinary study of coordination. ACM Computing
Surveys, 26(1), March 1994.
[4] A. Martinoli and K. Easton. Modeling swarm robotic systems.
In B. Siciliano and P. Dario, editors, Proc. of the Eight Int.
Symp. on Experimental Robotics ISER-02, Springer Tracts in
Advanced Robotics, pages 297–306. Springer-Verlag, July
2003.
[5] MIT Media Laboratory. Starlogo website.
http://education.mit.edu/starlogo/.
[6] G.C. Pettinaro, I.W. Kwee, L.M. Gambardella, F. Mondada,
D. Floreano, S. Nolfi, J.-L. Deneubourg, and M. Dorigo.
Swarm robotics: A different approach to service robotics. In
Proceedings of the 33rd International Symposium on
Robotics, Stockholm, Sweden, October 7-11 2002.
International Federation of Robotics.
401
