kilobot: a low cost scalable robot system for collective...

9
Kilobot: A Low Cost Scalable Robot System for Collective Behaviors Michael Rubenstein Nicholas Hoff and Radhika Nagpal TR-06-11 Computer Science Group Harvard University Cambridge, Massachusetts

Upload: others

Post on 25-Jan-2021

1 views

Category:

Documents


0 download

TRANSCRIPT

  • Kilobot: A Low Cost Scalable Robot System for

    Collective Behaviors

    Michael Rubenstein Nicholas Hoff

    and Radhika Nagpal

    TR-06-11

    Computer Science Group Harvard University

    Cambridge, Massachusetts

  • Kilobot: A Low Cost Scalable Robot System forCollective Behaviors

    Michael Rubenstein, Nicholas Hoff, Radhika Nagpal

    Abstract—In current robotics research there is a vast bodyof work on algorithms and control methods for groups ofdecentralized cooperating robots, called a swarm or collective.These algorithms are generally meant to control collectives ofhundreds or even thousands of robots; however, for reasonsof cost, time, or complexity, they are generally validated insimulation only, or on a group of a few 10s of robots. To addressthis issue, this paper presents Kilobot, a low-cost robot designedto make testing collective algorithms on hundreds or thousands ofrobots accessible to robotics researchers. To enable the possibilityof large Kilobot collectives where the number of robots is anorder of magnitude larger than the largest that exist today, eachrobot is made with only $14 worth of parts and takes 5 minutesto assemble. Furthermore, the robot design allows a single userto easily oversee the operation of a large Kilobot collective, suchas programming, powering on, and charging all robots, whichwould be difficult or impossible to do with many existing roboticsystems. We demonstrate the capabilities of the Kilobot as acollective robot, using a 25 robot test collective to implementthree popular swarm behaviors: foraging, formation control, andsynchronization.

    I. INTRODUCTION

    A large group of decentralized closely cooperating entities,commonly called a collective or swarm, can work togetherto complete a task that is beyond the capabilities of anyof its individuals. Many such examples can be found innature: army ants and honeybee colonies effectively forageover large areas many kilometers wide; desert ant groups cancollectively transport large irregular objects 50 times theircollective weight; termite colonies construct mounds meterstall even though individuals are only a few millimeters tallthemselves. These examples from nature have inspired long-standing research in collective robotics to achieve the kindof parallelism, robustness and collective capability of thesenatural systems.

    Within robotics, there is a wide range of active researchtopics that explore algorithms to control these robotic collec-tives, such as self-assembly [1, 21, 19], collective construction[5, 9], and exploration [8, 24], to name a few. Researcherscommonly envision these algorithms to operate on collectivesof hundreds [5], thousands [21, 19], or more [1, 15], robots;however, for reasons of cost, time, or complexity, they aregenerally validated in simulation only [1, 19], or on a group ofa few 10s of robots or fewer [6, 20]. When using a simulationto validate an algorithm for a collective of robots, it is difficultto accurately model robots’ interaction with each other, suchas communication and sensing, and with the environment,such as movement and collisions. This modeling difficultycan lead to disparities in algorithm behavior when operating

    on a simulated collective versus a real robotic collective.Additionally, operating an algorithm designed for a largecollective of robots on just a few may hide scaling issueswithin the algorithm that can only be uncovered in a muchlarger collective. To better understand and validate both currentand future collective control algorithms, it would be usefulfor these algorithms to be tested on a larger collective of realrobots.

    Other research groups have also recognized the importanceof a collective of robots for testing and validating algorithms;however, for various reasons, most operate collectives of afew 10s of robots [12, 6, 3] or at the very most a fewhundred robots [2, 14]. These collective sizes are primarilylimited by robot cost and operational complexity. The cost ofan individual robot is perhaps the largest limiting factor forcollective size; for a fixed budget, the lower the robot price,the larger the size of the collective. For example, a popularcommercially available robot, the e-puck [3], equipped withan infrared communication ring for collective operations, costsover $1300, and as a result, is usually operated in collectivesof about 10 robots. A robot more oriented towards large scalemulti-robot research is the Jasmine robot [14]. This robot costsabout $130 in parts and has been operated in collectives of 150robots; however, the robot is not available for purchase.

    In addition to cost, the complexity of operating the robots,such as turning the robots on/off, charging, controlling, andprogramming the collective, also plays a role in limiting thesize of the collective. For example, a common way to controlthe power of a robot is to have a switch on each robot to turnthe robot on and off [3, 12]. If this switch takes three secondsper robot to find and flip, then it would take a single person 50minutes to turn on a collective of 1000 robots. Furthermore,if the collective is large enough, the first robot to turn on mayactually run out of power before the last robot is turned on.This manual power switch as well as other design decisionscan prevent the size of the collective from scaling to largenumbers.

    To make a robot scalable to large collective sizes, as de-scribed in [10], all the operations of the robot must work on thecollective as a whole, and not require any individual attentionto the robot, such as pushing a switch or plugging in a chargingcable for each robot. In other words, all collective operationsmust be scalable. An example of a scalable operation on arobotic collective is the programming of the I-Swarm robots[18]. In these robots, instead of plugging in a programmingcable to each robot in order to update its program, each canreceive a program via an infrared communication channel.

  • This allows an overhead infrared transmitter to program allthe robots in the collective in a fixed amount of time, inde-pendent of the number of robots. Another example of scalableoperations is found in [10, 14], where instead of manuallyplugging in each robot to a charger for battery charging,they use an automatic charging dock that allows the robotsto charge themselves without human help, thus making therobot charging scalable. An example of a scalable operationregarding power control is found on the Robomote [20], and insensor networks. Instead of powering off the robot, the robotis always on, but in a low power sleep state, ready to turnon if the appropriate command is received. As a result, aRobomote never has to be turned on or off manually, and theentire collective can be turned “on” in a fixed time independentof the number of robots. These sorts of scalable operations areessential for collective operations, but at the same time, theyshould not dramatically change the robots’ capabilities, cost,or ease of manufacturing.

    The rest of this paper introduces a new robot, the Kilobot,which is a low cost robot with fully scalable operations.This robot is designed to make testing collective algorithmson hundreds or thousands of robots accessible to roboticsresearchers. First we describe the hardware design of a Kilobotrobot, where its low cost ($14 worth of parts) and ease ofassembly (5 min to assemble) enable large numbers to beproduced easily. While these robots are low-cost, they stillhave abilities similar to other collective robots. These abilitiesinclude: differential drive locomotion, on-board computationpower, neighbor-to-neighbor communication, and neighbor-to-neighbor distance sensing. These abilities are achieved at lowcost mainly through the use of vibration based locomotionand a simple range only sensor. Next, we discuss how theoperations of a Kilobot, such as programming, turning poweron and off, battery charging, and starting/stopping programs,do not require any individual attention by a person, andtherefore a large collective can be easily overseen by a singleoperator. Finally we will demonstrate that the Kilobot can beused for implementing and testing collective behaviors. Thesedemonstrations use a 25 Kilobot test collective to implementthe popular collective behaviors of foraging, formation control,and synchronization. A video showing these demonstrations isavailable at http://tinyurl.com/kilobot

    II. KILOBOT DESIGN

    Two competing factors were considered when designing theKilobot robot: the cost, and the functionality. The Kilobotneeds enough functionality to allow it to perform a widevariety of collective behaviors, while at the same time, itmust be simple enough to keep the cost low. The chosenfunctionality for Kilobot is that it must move within itsenvironment, run a user defined program, communicate withits neighbors, measure distance to those neighbors, displaysome internal state to assist with debugging, and allow forscalable operations. While these are not the minimum set offunctions needed for a collective robot, they strike a balancebetween what behaviors a collective of robots is capable of,

    Fig. 1. Four views of a Kilobot robot (clockwise from top left: thetop, bottom, side, and front views). Some key features are: (A) Vibrationmotors, (B) Lithium-Ion battery, (C) Rigid supporting legs, (D) Infraredtransmitter/receiver, and (E) Three-color (RGB) LED. Note the 1cm line forscale.

    Fig. 2. Picture of the Kilobot arena, including overhead controller (A),control station (B), 25 robot test collective (C), and charging station (D).

    and the cost of that collective. This section describes the designof the Kilobot hardware which has the functionality needed,while also keeping the price low. A general overview of theKilobot robot is given in Fig. 1. The environment, called the“arena”, that these robots are intended to operate in, consistsof a smooth, level, reflective table (e.g. a standard dry erasesurface) which can be seen in Fig. 2.

    A. Locomotion

    One important capability of the Kilobot is that it mustbe able to move in its environment. The most commonlocomotion strategy for swarm robots is to use a two-wheeleddifferential drive, where each wheel is powered by an electricgear motor. While this conventional wheeled locomotion isquite effective, it is relatively expensive, as even a low-cost

  • gear motor and wheel is about the same price as an entireKilobot! To keep the cost down, Kilobot uses two sealedcoin shaped vibration motors for locomotion. When one ofthese motors is activated, the centripetal forces generatedby the vibrating motor are converted to a forward force onthe Kilobot located at the motor’s mounting location. Theprinciple of converting the motor vibration to a forward forcecan be explained using the slip-stick principle, the detailsof which can be found in [22]. The Slip-stick locomotionof a Kilobot was confirmed using high-speed video of therobot’s movement. Due to the off-center mounting of the twovibration motors, as shown in Fig. 1, the vibration of one motoralone will cause a rotation of the Kilobot about its verticalaxis, while the vibration of the other motor will cause anopposite rotation. By controlling the magnitude of vibration forthe two motors independently in a differential drive manner,the robot can move in a continuous range from clockwiserotation, to straight forward, to counterclockwise rotation. Thisenables the Kilobot to move approximately 1 cm/sec and rotateapproximately 45 degrees/sec.

    One major drawback to using this low-cost slip-stick basedlocomotion, as opposed to wheels with encoders, is that thereis no real form of odometry. This makes moving precisely overlong distances or for a long time difficult. One way to addressthis difficulty, which harnesses the power of a collective, is touse the measured distances between neighbors as feedback tocorrect errors in the robot’s movement. As is shown in sectionII-F, this allows the robot to achieve fairly accurate motioncontrol when aided by other robots. Another limitation to thislocomotion is that it can not move over rougher surfaces,requiring a smooth surface such as a dry erase surface towork. While this does limit the environments that Kilobot canoperate in, it dramatically reduces its cost, and still allows forthe demonstration of many interesting collective behaviors.

    B. Communication and Sensing

    A vast majority of collective robot algorithms use robot-to-robot communication and sensing, such as distance andbearing to neighbors, as the main information to drive thebehaviors of individual robots. Therefore, it is critical thatKilobot also be able to communicate with its neighbors andsense some information about its physical relation to itsneighbors. In order to keep the robot cost down, the sensing ofneighbors only includes distance sensing, not bearing sensing.While bearing sensing is often used with collective robots, forexample [11], distance-only sensing [19] is still sufficient forinteresting collective behaviors, as section IV shows.

    To communicate with neighboring robots, each Kilobot hasan infrared LED transmitter and infrared photodiode receiver,which are located in the center of the PCB and are pointeddirectly downwards at the table the Kilobot is standing on asshown in Fig. 1. Both the transmitter and receiver have anisotropic emission or reception pattern, which allow the robotto receive messages equally from all directions. Additionally,both the receiver and transmitter are wide-angle, with an angleof half power of 60◦ from the robot’s downward pointing

    Fig. 3. Picture showing the reflection path of robot communication.

    vertical axis. When the transmitter is active, any nearby robotcan receive the light emitted by the transmitting robot after it isreflected off the table, as shown in Fig. 3. Messages are trans-mitted by pulsing the transmitter according to standard linecoding technique. Using this simple communication method,a Kilobot can communicate at rates up to 30 kb/s with robotsup to 10cm (about 6 robot radii) away.

    With all robots using the same infrared channel for commu-nication, there is the possibility that two or more robots maytry to transmit at the same time. To mitigate this problem astandard carrier sense multiple access with collision avoidance(CSMA/CA) method is used. Even with CSMA/CA, environ-ments with many nearby robots will experience a reductionof the channel bandwidth due to collisions. In an experimentwith 25 robots, configured as shown in Fig. 2, the channelcould support on average 240 five-byte packets/second, a 32%channel usage.

    During any communication between robots, the receivingrobot also measures the intensity of the incoming infraredlight. This incoming light intensity is a monotonically de-creasing function of the distance between the transmitter andthe receiver; therefore the distance to the transmitter can becalculated by the receiver. In practice, the incoming intensityof light is also affected by noise and manufacturing variances,which leads to sensing accuracy of ±2 mm, and precisionunder 1 mm.

    C. Controller

    The controller for the robot serves two functions. Firstly, itinterfaces with all the low-level electronics such as motors,communication, power circuitry, and the RGB LED (usedfor displaying information to the operator, seen in Fig. 1).Secondly, it runs a user-defined robot behavior program. Thecontroller used is an Atmega328 microprocessor, which runsat 8 Mhz and has 32K of memory. Some key features ofthis controller used in the Kilobot are: two pulse widthmodulation (PWM) channels used for controlling the speedof the vibrating motors, 10-bit analog-to-digital convertersused for measuring the incoming infrared light intensity, self-programmable memory used to update the robot’s program(described in section III-C), and a low-power sleep mode (seesection III-A). The program for the robot is written in C,which allows researchers to quickly and easily develop robotbehaviors.

  • TABLE IA SUMMARY OF KILOBOT PARTS COST. PART COSTS ARE BULK PRICES AT

    QUANTITIES FOR 1000 ROBOTS.

    Category CostLocomotion $3.12

    Power $3.61Communication/Sensing $2.20

    Control $2.83Structure $1.55

    Miscellaneous $0.74Total Parts $14.05

    D. Power System

    To power the entire robot, each Kilobot has a 3.4 V160 mAh lithium-ion battery, shown in Fig. 1. This batterycan power the robot for 3-10 hours depending on the robot’sactivity level. Connected to this battery are three voltageregulators and a battery charger. Two of the voltage regulatorsprovide power to the motors and the communication system.Both of these regulators can be switched on and off by themicrocontroller, enabling shutdown of the motors and thecommunication system to conserve power consumption. Thethird voltage regulator continuously provides power to themicrocontroller, and during low-power states (described insection III-A) only draws 50 µA. When the battery chargerreceives 6 Vdc (described in section III-B), the charger willbegin charging the onboard battery; when the battery ischarged, the charging will stop.

    E. Cost

    To allow for large Kilobot collectives, it is critical thateach robot be as low-cost as possible. The Kilobot designas described uses about $14 worth of parts, which is at least10 times less than the lowest cost of currently used collectiverobots [11]. The cost of each Kilobot can be broken down intosix categories: locomotion, power, communication/sensing,control, structure (includes PCB and battery holder), andmiscellaneous (all other parts, such as the RGB LED). Table Igives a summary of the cost of these six categories of Kilobotparts.

    The assembly time of a robot can also affect the price ofa robot if it is pre-assembled; if not, it can make buildinga collective difficult and time-consuming. Either way, it isimportant for the robot to be able to be assembled quickly. Toaid in a quick assembly time, most of the robot’s componentsare surface-mount, and are placed using a pick-and-placemanufacturing robot. The remaining parts to be assembled are:the battery holder, the legs, the motors and the infrared receiverand transmitter. The battery holder and the infrared receiverand transmitter can be assembled by hand. For the remainingparts, custom-made assembly rigs allow for quick and precisealignment and attachment of the motors and the legs. Thisentire assembly process takes less than five minutes.

    Fig. 4. The path of a Kilobot (black marker) orbiting five times arounda second stationary Kilobot (green marker) (A). “U” shaped path followingrobot (marked with black) and the three stationary beacon robots (markedwith green). The path of the moving robot during 5 attempts at following thedesired path is shown (B). The path of a single Kilobot attempting to circlewithout assistance from other robots (C).

    F. Robot Capability Demonstrations

    To demonstrate Kilobot capabilities, this section shows twodemonstrations that provide evidence for the robot’s basicfunctionality: the ability to move within its environment, runa controller, communicate with its neighbors, and measuredistance to those neighbors. Additionally, these demonstra-tions show that when Kilobots sense and communicate withneighbors, they can improve their capabilities beyond what isdirectly available to them in hardware. In these demonstra-tions, the improved capabilities shown are position sensingand bearing sensing.

    1) Orbit Demonstration: In the first demonstration, a singlerobot is tasked to travel on a circular path. Lacking odometry,this task is not possible for a single Kilobot, as shown in Fig.4(C). However, with the assistance of a stationary neighboringKilobot acting as a marker for the center of the orbit, orbitingis possible, as shown in Fig. 4(A). This stationary robotsends out a message at 1/10th of a second intervals, whichis received by the orbiting Kilobot. These messages allowthe orbiting Kilobot to compute its current distance to thestationary robot, which is also its distance to the center of itsdesired orbital path. These distance measurements allow theonboard controller to compute the robot’s deviation from theideal orbit, and using a PD controller, adjust the intensity ofboth motors’ vibrations to correct for it, keeping the robotclose to the ideal path.

    2) Path Following Demonstration: A second demonstrationshows a Kilobot following a more complicated path, in thiscase a “U” shaped path. This path is defined in Cartesiancoordinates as a polygon in which the robot is allowed tomove. If the robot is inside the polygon, it moves straight, ifnot, it turns back towards the interior of the polygon. To enable

  • this behavior, three stationary robots are set in the environmentin a triangle shape, as shown in Fig. 4(B). These three robotsknow their position in a coordinate system and communicatethat position to the moving robot 10 times a second. Themoving robot uses the communicated positions of the threestationary robots, as well as its measured distance to thoserobots, to trilaterate its own position in the coordinate system.Once the moving robot knows its position in the coordinatesystem, it can compute if it is located inside the polygon ornot. If not, it can also compute which direction to turn in orderto move back into the polygon. The position of the movingrobot during five attempts at following the path is shown inFig. 4(B).

    III. A SCALABLE COLLECTIVE

    With a large collective of robots, it can become tediousor even impossible to work with it if the robots require ahuman operator to interact with each of the robots one ata time. Some of these individual interactions could includepushing the robot’s power switch on or off, plugging in acable to program or charge the robot, and pausing, starting,or stopping the program running on the robot. The followingsection explains how a Kilobot does not require any individualattention for normal collective operations; i.e., it is a scalablerobot. To allow a single user to scalably operate the collective,the setup for Kilobot testing and operations has an overheadinfrared controller, as shown in Fig. 2. This controller can sendinfrared messages, using the same methods as in II-B, to all theKilobots on the testing arena at once. The overhead controlleris in turn controlled by an operator sitting at a computer-basedcontrol station.

    A. Power

    To avoid a physical switch to turn the robots “on” or “off”,Kilobots use a power control scheme similar to some sensornetworks and the Robomote [20]. This power control schemeworks by replacing the standard “off” state of the robot, wherethe battery is disconnected from the robot, with a low-powersleep mode. While in this mode, the battery stays connectedto the robot, but the robot powers down most of its electronicsand the microprocessor goes into a sleep state for one minute.During this time, the power drawn from the battery by theKilobot is approximately 170 µW. After one minute, themicroprocessor wakes up, turns on the infrared sensor, andfor 10 ms it checks if it receives a wake-up message fromthe overhead controller. To ensure that a message is receivedduring this 10ms window, the overhead controller transmits thewake-up message every 3ms for over a minute. If a wake-upmessage is received by the robot, it switches to the standard“on” mode. If no-wake up message is received, then the robotwill go back to the low power sleep mode, repeating this cycleuntil a wake-up message is received. If the robot is in the “on”mode, a sleep message sent from the overhead controller willswitch it to the low-power sleep mode.

    Using this power control scheme, the robot can remain in thelow-power sleep mode, waiting to switch to the “on” mode, for

    Fig. 5. Connecting to charger input (A); manually pushing robots towardscharger (B); a side view of a group of Kilobots charging (C).

    more than 3 months on a single battery charge. Furthermore,the entire collective can be switched from the low power sleepmode to the “on” mode in under one minute, and from the “on”mode to the low-power sleep mode in a few seconds.

    B. Charging

    As described in section II-D, when 6 Vdc is applied to theinput of a Kilobot’s battery charger, it will charge the on boardbattery until the battery is full. To apply this potential to thecharger input, the top of the robot is connected to an electricalground, and the bottom legs are connected to 6Vdc, as shownin Fig. 5(A). This enables an entire collective to be charged byfirst placing it onto a conductive surface, which can easily bedone by pushing the whole group with a long stick as shownin Fig. 5(B). Next, a conducting board, such as a poster boardcoated with metallic tape, is placed on top of the collective.Finally 6Vdc is applied across the bottom conductive surfaceand the top conducting board, connecting the input of all thechargers to the required voltage. Fig. 5(C) shows a group ofKilobots in this charging configuration which does not requireany attention to the individual robots.

    C. Programming

    To change the program running on the Kilobot’s microcon-troller, the self-programming feature of the Atmega328 is used.This feature allows the main program code, located in theprimary sector of memory, to be overwritten by a programwritten in a separate “bootloader” sector in memory. In thisbootloader sector of memory, Kilobot has a program thatreceives infrared messages from the overhead controller whichcontain portions of the new desired main program code. Itthen writes these portions of code to the appropriate locationin the primary sector of memory. The bootloader programhas error-checking to ensure that the program placed in theprimary sector is complete and error-free. Once the completereplacement program has been received, the bootloader code

  • resets the microprocessor, and the newly loaded main programcode begins execution. When the operator desires to put a newprogram in all of the Kilobots, the operator transmits a “jumpto bootloader” message from the overhead controller. Whenthis message is received by the main program code, it movesthe program counter to the bootloader section of code, causingthe bootloader program to execute. This scalable programmingscheme allows all the Kilobots present in the testing arena toload a new program in under one minute. To validate this, a testcollective of 25 robots were programmed using this methodin 35 seconds.

    D. Other Control

    In addition to programming and power control, the overheadcontroller is also useful in other aspects of Kilobot operationssuch as querying a robot’s battery voltage, and starting,restarting, and pausing the robot’s programs. For example, itmay be useful for the operator to know the battery voltageof the robots in the collective to determine if they need tobe recharged. To do this, the operator sends a message to allthe robots via the overhead controller to display voltage. Eachrobot then displays a color on its RGB LED based on themeasured voltage of its battery, displaying green if the batteryhas more than 90% charge remaining, blue if between 90%and 40% is remaining, and red if less than 40% is remaining.With all robots displaying their charge status, the operator canthen look at the collective and determine its overall chargestatus. In addition, the operator can control the execution ofthe main program in all Kilobots by issuing commands viathe overhead controller to pause, start, stop or restart the mainprogram.

    IV. COLLECTIVE BEHAVIOR DEMONSTRATIONS

    While designed to be low cost and simple, Kilobot is still ca-pable of interesting collective behaviors. To demonstrate this,a test collective of 25 robots was built and used to implementthree popular collective behaviors. These behaviors are: ant-inspired foraging, formation control, and synchronization.

    A. Foraging

    Foraging is a popular biologically inspired task in col-lective robotics, for example [23, 13]. The task generallyinvolves robots exploring the environment to find a “food”goal, and delivering it to the “nest”. In this demonstration,the foraging algorithm from [7] is implemented directly ona Kilobot collective. Two immobile Kilobots with specializedprograms are placed as markers in the environment, as shownin Fig. 6, symbolizing the nest and food locations. Thesemarkers constantly transmit a message that tells any robotswithin communication range that the marker is the nest orfood. For food to be delivered to the nest, a robot must passclose to the food marker, where it “picks up” a unit of foodfrom the food marker, and then the same robot must then passclose to the nest marker, where it “drops off” the food.

    In this foraging algorithm, some of the robots can take onthe role of a “beacon”. The goal of this beacon is to aid the

    Fig. 6. Initial start of foraging demo, note food (green marker) and nest(red marker) (A). Ant algorithm after finding food; note beacons (RGB LEDon) and walkers (RGB LED off) (B). The path of a single walker from thefood, to the nest, and back to the food (C). Note: the other walkers in (c)have been digitally removed for clarity.

    remaining robots, the “walkers”, in navigating between thenest and the food. The beacons do this by maintaining twovariables, food gradient, and nest gradient. If any beacon seesthe food or the nest, it sets its corresponding gradient valueto one. Otherwise, the beacon sets its gradient value to be thevalue of the lowest corresponding gradient it receives fromneighboring beacons, plus one. This allows any walker robotto listen to the nearby beacons and determine which beaconis closest to the nest or the food. If the walker does not havefood, it moves towards the beacon that is closest to the food.If the walker does have food, it moves towards the beacon thatis closest to the nest. A walker can move closer to a desiredbeacon by sensing its distance to that beacon, and then movingto reduce that distance. While moving, a walker also needs toavoid collisions with other robots. This is done by detectingif any neighbors are less than 1cm away, and if so, turningaway until it no longer is. This overall movement strategy ofmoving towards the desired beacon while avoiding collisionsallows the walkers to travel from the nest to the food and back.

    Initially, as shown in Fig. 6(A), all the robots are placednext to the nest marker and have no information about thelocation of the food marker. They all start in the walker roleand spread out from the nest. As they spread out and explorethe environment, some walkers choose to become beacons.

  • Fig. 7. Screenshots of Kilobots following the leader is shown on the left. The starting frame is on top, ending frame is on bottom. The leader is markedwith green. On the right, the paths of five Kilobots following the leader (black line is the leader’s path) are shown. Starting locations are marked as circles,ending locations marked as squares.

    These beacons are created to provide a connection betweenthe exploring walkers and the nest. If, as shown in Fig. 6(B),one or more beacons see the food, then the remaining walkerswill be capable of navigating to the food and nest, as shown inFig. 6(C). For a more detailed explanation of this algorithm,please see [7].

    B. Formation Control

    Formation control, another biologically inspired behavior, isoften applied to robotic collectives, particularly in the controlof unmanned vehicles. This demonstration shows “follow-the-leader”, a popular formation control behavior often appliedto robot collectives [16], and implements it on 6 Kilobots.In this demonstration, the Kilobots start lined up facing theleader. The leader then moves in its forward direction, andall the followers follow along approximately the same path.Note that as seen in Fig. 7, without positional information, theleader does not always move precisely forward; however, theother Kilobots still follow the leader.

    To initialize the Kilobot collective for follow the leader,each robot is assigned an ID, where the ID of the leader robotis 1. The ID of the remaining robots is one greater than therobot immediately in front of it. This allows the robots toknow the ID of the robot immediately in front and behind it.Additionally, the front robot knows that it is the leader (its IDis 1), and the last robot, the tail, knows that it has no robotsbehind it (it sees no ID greater than its own). All robots canoperate in two states, move and wait. Initially, if the robot hasan even ID, it starts in the wait state, and if its ID is odd, itstarts in the move state. During the entire demonstration, eachrobot will constantly communicate this state and its ID to itsneighbors. A robot in the wait state will stay stationary andwait until the robot immediately in front of and behind it arealso in the wait state. When this condition is met, the robot willthen switch to the follow state. The leader and tail robots onlywait for the robot in back or in front of it respectively. Duringthe follow state, each robot will measure the distance to therobot directly in front of it, and move to reduce this distance.

    Once this distance is less than one cm, the robot will stopmoving and switch to the wait state. Since the leader has norobots in front of it, when it is in the follow state, it movesforward until it is four cm away from the robot directly behindit, then switches to the wait state. There are some additionalnuanced rules for switching states to prevent premature statechanges, but for the sake of brevity, these will not be discussedhere. These two behaviors allow robots to move towards theleader robot, while at the same time not move so fast as tobreak communications with the robot directly behind it. Theresult is that the collective of Kilobots follow the leader, asshown in Fig. 7.

    Fig. 8. The number of robots that flashed its LED during 0.5 secondincrements. Initially the robots flash at random times, but over a period ofone minute they become synchronized.

    C. Synchronization

    Synchronization is often used when coordinating simulta-neous actions between many entities, such as robots or sensornetworks. A popular method for synchronization [17] is based

  • on how fireflies synchronize their periodic light emissions innature. In this work, each entity maintains a periodic clockthat when it reaches its maximum value, the clock resets, andthe entity sends a signal to its neighbors. Whenever a neighborreceives a signal, it adjusts its local clock according to whenit was received. This adjustment is enough to eventuallysynchronize all the entities. A modification of this approach[4] is intended to operate on systems that use a communicationchannel where contention and delays are possible, whichis true for the Kilobot system. This demonstration uses anapproach closely related to [4] to synchronize the flashes ofthe RGB LED on 25 Kilobots. Fig. 8 shows the number offlashes for the whole collective during 0.5 second increments,demonstrating that the initially unsynchronized collective doesbecome synchronized.

    V. CONCLUSION

    In this paper, we have presented the Kilobot robot, a $14robot designed specifically for operation in a large collective.While the Kilobot is a relatively simple and low cost robot,we have shown it to be a viable collective robotic system bydemonstrating three popular collective multi-robot behaviorsusing a 25 Kilobot test collective. The robot design andcollective operations are carefully considered in order to makeit easy to manufacture and operate a large collective ofKilobots. To keep the robot cost low, its design uses an unusuallocomotion technique (vibration-based) and relatively simplesensing (distance but no bearing), both of which dramaticallyreduce the robot cost without sacrificing its functionality. Asthe range of collective behaviors is expanded, it may be usefulto modify this choice in the robot design by adding othersensors, for example a bump sensor or an ambient light sensor.In the future, we hope to make both the Kilobot hardwaredesigns and software openly available for others to use andto extend. Additionally, we plan on building a 1024 Kilobotcollective and applying it to additional collective behaviorssuch as self-healing and collective transport.

    REFERENCES

    [1] D. Arbuckle and A. Requicha. Self-assembly and self-repair of arbitrary shapes by a swarm of reactive robots:algorithms and simulations. Autonomous Robots, 28(2):197–211, 2010.

    [2] G. Caprari, P. Balmer, R. Piguet, and R. Siegwart. Theautonomous micro robot “alice”: a platform for scientificand commercial applications. In Proc. of the Ninth Int.Symp. on Micromechatronics and Human Science, 1998.

    [3] F. Mondada, et al. The e-puck, a robot designed foreducation in engineering. In Proc. of the 9th Conf. onAutonomous Robot Systems and Competitions, 2009.

    [4] G. Werner-Allen, et al. Firefly-inspired sensor networksynchronicity with realistic radio effects. In SenSys,2005.

    [5] K. Galloway, R. Jois, and M. Yim. Factory floor: Arobotically re-configurable construction platform. ICRA,2010.

    [6] K. Gilpin, A. Knaian, and D. Rus. Robot pebbles: Onecentimeter modules for programmable matter throughself-disassembly. In ICRA, 2010.

    [7] N. Hoff, A. Sagoff, R. Wood, and R. Nagpal. Twoforaging algorithms for robot swarms using only localcommunication. In IEEE International Conference onRobotics and Biomimetics (ROBIO), 2010.

    [8] A. Howard, L. Parker, and G. Sukhatme. Experimentswith large heterogeneous mobile robot team: Exploration,mapping, deployment and detection. International Jour-nal of Robotics Research, 25(5):431–447, 2006.

    [9] J. Everist, et al. A system for in-space assembly. IROS,2004.

    [10] J. McLurkin, et al. Speaking swarmish: Human-Robotinterface design for large swarms of autonomous mobilerobots. In AAAI Spring Symposia, March 2006.

    [11] J. McLurkin, et al. A low-cost multi-robot system forresearch, teaching, and outreach. In DARS, 2010.

    [12] M. Jørgensen, E. Østergaard, and H. Lund. Modularatron: Modules for a self-reconfigurable robot. In IROS,2004.

    [13] K. OHara, et al. Physical path planning using the gnats.In ICRA, 2005.

    [14] S. Kernbach, R. Thenius, O. Kernbach, and T. Schmickl.Reembodiment of honeybee aggregation behavior in ar-tificial microrobotic system. Adaptive Behavior, 17(3):237–259, 2009.

    [15] M. DeRosa, et al. Scalable shape sculpting via holemotion: Motion planning in lattice-constrained modularrobots. In ICRA, 2006.

    [16] M. Gupta, et al. Collective transport of robots: Emergentflocking from minimalist multi-robot leader-following. InIROS, 2009.

    [17] R. Mirollo and S. Strogatz. Synchronization of pulse-coupled biological oscillators. SIAM Journal on AppliedMathematics, 50(6):1645–1662, 1990.

    [18] R. Casanova, et al. Enabling swarm behavior in mm3-sized robots with specific designed integrated electronics.In IROS, 2007.

    [19] M. Rubenstein and W. Shen. Automatic scalable sizeselection for the shape of a distributed robotic collective.In IROS, 2010.

    [20] G. Sibley, M. Rahimi, and G. Sukhatme. Robomote:A tiny mobile robot platform for large-scale sensornetworks. In ICRA, 2002.

    [21] K. Støy and R. Nagpal. Self-repair through scale inde-pendent self-reconfiguration. In IROS, 2004.

    [22] P. Vartholomeos and E. Papadopoulos. Analysis, de-sign and control of a planar micro-robot driven by twocentripetal-force actuators. In ICRA, 2006.

    [23] R. Vaughan, K. Støy, G. Sukhatme, and M. Matarić.Whistling in the dark: Cooperative trail following inuncertain localization space. In AAMAS, 2000.

    [24] W. Burgard, et al. Collaborative multi-robot exploration.In ICRA, 2000.

    IntroductionKilobot DesignLocomotionCommunication and SensingControllerPower SystemCostRobot Capability DemonstrationsOrbit DemonstrationPath Following Demonstration

    A Scalable CollectivePowerChargingProgrammingOther Control

    Collective Behavior DemonstrationsForagingFormation ControlSynchronization

    Conclusion