28 IEEE POTENTIALS0278-6648/08/$25.00 © 2008 IEEE

There are several driving factors involved in the develop-ment of a robotic swarm. On the hardware side, assem-bly should be adaptable, easily reproduced, and relative-

ly inexpensive. Motors, mounts, wheels, and chassis materialmust be chosen as well as appropriate sensors. A workablecommunication protocol must be determined. Software shouldbe concise and common to each robot in the swarm whilemeeting the requirements of the desired function.

In the summer of 2007, Cleveland State University providedfunding for various undergraduate research projects includingone involving engineering students in the development of arobotic swarm. Under the supervision of one faculty memberand one graduate student, six undergraduate students spentthree months on the design and implementation of a mappingrobotic swarm.

Pedal to the metal

The main objectivewas to produce a swarm

of mapping robots thatcould be sent into an

unknown building to pro-duce a floor map. To accom-

plish this task, a square robotwith differential steering was

designed. This square designsimplifies the manufacturing

process, and the wheel configura-tion allows for easy control of each

robot’s movements. Each robot isoutfitted with an array of three ultra-

sonic range finders, an angular ratesensing gyro, one proximity switch, a

wireless camera, and two wheelencoders. Other sensors were considered, but were eitherdeemed unnecessary or unreliable.

A Microchip PIC18F4520 microcontroller, programmed witha C compiler from Custom Computer Services Inc., providesthe brains. This particular microcontroller provides low cost,good speed, and a sufficient set of peripherals for use in vari-ous robotics applications. Communication is accomplished viaradio, with a transmitter-receiver mounted on each robot.Each robot also has an LCD that can be used for debugging ordisplaying messages during operation.

The motivation for undertaking this project was to build aninfrastructure with which future work could be performed. Aswe develop new theory in research program areas like con-trols, estimation, image processing, and artificial intelligence,we want to have a hardware platform available for testing anddemonstration. Robotic vehicles provide an ideal platformbecause of their multidisciplinary nature.Digital Object Identifier 10.1109/MPOT.2008.924855

©A

RTV

ILLE

Effective implementation of a mapping swarm of robots

CHRISTOPHER CHURAVY, MARIA BAKER, SAMARTH MEHTA, ISHU PRADHAN, NINA SCHEIDEGGER, STEVEN SHANFELT, RICK RARICK, AND DAN SIMON

JULY/AUGUST 2008 29

Assembly lineEach robot is designed to allow for

expansion and quick assembly. Builton a 16 cm × 16 cm × 0.60 cm squarepiece of high density polyethylene(HDPE), otherwise known as plastic,the robots have three tiers of develop-ment space separated by 4-cm metalstandoffs. Two Solarbotics GM-8 gearmotors are mounted to the base with ahand-fashioned brass motor mount.The mounts are made from inexpen-sive 1-in brass strips that are drilledout, bent, and screwed to the chassisto provide strong support for themotors. Two rechargeable AA batterypacks, eight batteries per pack, pro-vide power to the motors and to theonboard electronics.

The microcontroller, voltage regula-tors, and other required electronics aremounted on a two-layer printed circuitboard (PCB) designed with theExpressPCB software package. Thedimensions of the PCB are 10.1cm × 10.3 cm, and the design is simpleenough that a board can be fully popu-lated in about an hour by anyone handywith a soldering iron. The encodersmount easily to the motor casing andwere fitted with an adaptor to connectdirectly to the board. The ultrasonic sen-sors are mounted on the middle tier,with the majority of space on that levelleft for future development.

The third tier houses the radio module,PCB, camera, and LCD. Figure 1 showstwo completely assembled robots ready tobegin mapping. The robots weighapproximately 3.27 lb and cost aboutUS$584 each, with total assembly and test-ing time of about two hours per robot.

Talking the wireless talkCommunication between the robots

and the base station is accomplishedusing the MaxStream 9Xtend RF trans-mitter/receiver. This particular deviceboasts an indoor range of up to 900 m,a selectable output power of between 1mW and 1 W, and selectable RF andserial interface baud rates. At aboutUS$180, this model falls within anacceptable price range for use on multi-ple robots. The base station and each ofthe robots in the swarm are outfittedwith their own radios. The radio at thebase station is connected with a serialcable to the PC’s USART (RS232) and isused to transmit and receive data to andfrom the robots.

Each robot in the swarm is assigneda robot ID number, which is stored in

memory. When the base station wishesto address a robot, that robot’s ID num-ber is loaded into the base microcon-troller program and a wireless connec-tion is established between the basestation and that robot. When the robotis instructed to report, it sends a packetof encoded sensor data back to thebase station over the previously estab-lished connection. This connectionremains open until the base stationwishes to address another robot, where-upon it loads another robot ID numberinto its program and establishes a newconnection. As the swarm movesthroughout the building, each robot isaddressed in succession by the base sta-tion, continually providing informationto the mapping program. In order forthis all to work, therobots must be able tocarry out the instruc-tions that they are toldto perform.

Sensors andsensibility

Each robot in theswarm has the abilityto perform any of anumber of differentmovements. Everytime that a robot iscontacted by the baseprogram, the robot isinstructed to performone of these movements. Generally,when a robot is following along a wall,it will receive the “move forward”instruction. When the instruction isreceived, the robot moves forward 5cm, stops, and takes readings from therangefinders, sending that data back tothe base station.

The next instructiongiven to the robot isdependent on the datathe robot has just sent. Ifthe data indicates anobstacle or a corner, therobot will be instructed toact accordingly. In orderto do this effectively, therobots must consistentlybe able to gather accuratedata from their sensorsand communicate withthe base station. To builda map, the robots mustmove the distance thatthey are instructed tomove and they mustmake precise turns.

Wheel encodersTraveling a specified distance is

accomplished by reading the wheelencoders, the Nubotics Wheel Watcher2, and averaging the two values. As canbe seen in Fig. 2, the encoders areunobtrusive and easily attached to themotors. When moving forward, bothmotors are engaged using the PIC’spulse-width modulated (PWM) outputpins with the signal sent through a75441 motor driver chip to step the cur-rent up to an appropriate level. ThePIC18F4520 has four onboard timers tochoose from when programming forthis task. The PIC’s PWM output usestimer2, and the encoders use timer0and timer3, which are configured ascounters to keep track of wheel ticks.

Each Wheel Watcher 2 unit has threesignal outputs. There are two standardquadrature outputs and one decodedoutput that produces a pulse on anychange of either quadrature pin. Thisdecoded output is ideal for controllingthe forward and backward movementsof the robots.

Fig. 1 Two assembled robots, ready to swarm.

Fig. 2 Encoder mounted on motor.

30 IEEE POTENTIALS

The distance represented byone encoder count is deter-mined by dividing the wheeldiameter (6.83 π cm) by thenumber of encoder counts perrevolution (128). Multiplyingthe result by one-half gives theencoder accuracy of 0.8 mm.In practice, some wheel slip-page and skidding occurs,which is a typical problemwith dead reckoning naviga-tion. Mapping experiments typicallyshowed navigation errors of about 8 cmevery 8 m for a relative accuracy of 1%.

Straight movement is achieved bycontinually monitoring and correctingthe error between the two encoder val-ues. The encoders can be used to feedthe robot information during turns aswell. With the simple knowledge ofeach robot’s turning radius and wheelsize, the angle of rotation at any giveninstant can be determined. The draw-back to this approach is that undesiredwheel slippage and other forms ofinterference can prohibit the robotsfrom making fully accurate turns. Forthis reason, another method wasemployed in the execution of turns, asdiscussed in the following two sections.

CompassInitially, turning of the robot was to

be controlled by a digital compass.The compass being considered wasthe CMPS03 built by Devantech, asshown in Fig. 3. This particular modelhas two methods of operation, both of

which were easily realized with thePIC18F4520. The compass has a PWMpin that outputs a square wave with amaximum cycle time of 167 ms. Thepositive pulse width is proportional tothe direction the compass is facing withrespect to magnetic north. Each positivepulse is separated by a 65 ms period inwhich the output is set low.

The other option provided by thecompass is an inter-integrated circuitinterface, or I2C. This method is light-ning fast compared to PWM and can beconfigured to either 8-b or 16-b resolu-tion. I2C is a protocol that was devel-oped by Philips Semiconductor for com-munication between two or more inte-grated circuits. On the workbench thisapproach seemed to work fine, provid-ing accurate readings with relative con-sistency. However, once tested in anopen hallway outside the lab, the digitalcompass quickly revealed itself as apotential snag in the robot design.Because the compass is designed tofunction in a mostly constant magneticfield such as that of the earth, and the

interior of most buildingsdoes not meet this require-ment, the performance of thecompass proved to be dicey,to say the least. If the com-pass were to be used in awide open space free of largemetal objects, such as out-doors or in a large ware-house, it could be expectedto work fine. But whendesigning a swarm of precise-

ly controlled robots for indoor use, thecompass was not an ideal choice.

Angular rate gyroTo replace the compass, an angular

rate sensing gyro was deemed to be anappropriate choice. The Analog DevicesADXRS401 provides an output voltagethat is proportional to the rate ofchange of the sensor’s orientation aboutan axis normal to the sensors top. Thisdevice, shown in Fig. 4, seemed to bean inexpensive and effective solution tothe orientation problem. The device isavailable in a less-than-ideal Ball GridArray (BGA) package for US$22 (SeeTable 1 for parts list). Luckily, AnalogDevices sells a development board ver-sion of the device that is available on asimple 20 pin dual in-line package chipfor about US$50. The evaluation boardincludes all the assembly and filteringcapacitors that are recommended onthe gyro’s data sheet.

The gyro noise is advertised as0.2◦/s (root-mean-square). The gyroswere used as a feedback signal todetermine when the robot had complet-ed a turn of a desired angle. In practice,all robot turn commands were 90◦. Therobots were hard-coded to completethe turn in about 5 s. Based on theadvertised gyro accuracy, this wouldgive a turn accuracy of 1◦. We foundthat the gyro accuracy was closer to 5◦.The difference between theory andpractice could be due to wheel slip-page, and electrical noise from subopti-mal wiring layouts and other sensors.However, this 5◦ error did not limit themapping performance. This is becausethe encoders were used by the robot to

Fig. 3 Devantech electronic compass.

Pin 9 - 0v Ground

Pin 8 - No Connect

Pin 7 - 50/60 Hz

Pin 6 - Calibrate

Pin 5 - No Connect

Pin 4 - PWM

Pin 3 - SDA

Pin 2 - SCL

Pin 1 - +5v

Fig. 4 Angular rate gyro.

Because the compass is designed to function in a mostly constant magnetic field,

and the interior of most buildings does not meetthis requirement, its performance

proved to be dicey.

JULY/AUGUST 2008 31

follow the wall (as describedearlier), and the mappingalgorithm assumed that thewalls were at 90◦ angles. Ifthis assumption were notvalid for a given environment,then the gyro accuracy wouldneed to be improved to getreasonable maps.

The ADXRS401 null, or the outputvoltage when the gyro is not inmotion, is supposed to be 2.5 V.Unfortunately, the actual null typicallyfalls somewhere between 2.3 V and 2.8V with plenty of noise. The data sheetpresents a method for correcting thenull with a resistor, but this resistorvalue would have to calculated foreach robot and would have to be con-nected to either Vcc or ground,depending on the initial null.Measuring the null of every single gyroand selecting a different configurationfor each robot in the swarm would betedious and would make large scaleproduction impractical. Therefore,deviations from the nominal null valueare dealt with in the software by sim-ply averaging a large number of sam-ples before each time the gyro is used.Averaging the samples takes care ofany noise and returns a fairly constantvalue for the null.

Another problem with the gyro isthe output scale factor. The data sheetclaims that the typical output is 15mV/◦/second measured in either direc-tion from the null voltage. In otherwords, if the null value is 2.5 V and thegyro is rotated at 5◦/second clockwise,stopped, and then rotated at 5◦/secondcounterclockwise, the output of the gyroshould be 2.575 V, then 2.5 V, and final-ly 2.425 V. This scale factor proved tobe different for clockwise and counter-clockwise motion and was in need ofsome type of correction. The solution tothis problem was to calibrate each gyrowith a simple program that calculatesthe actual scale factor and stores it inmemory. Once calibrated, the gyrosfunction properly.

Getting an orientation from the gyrooutput is as simple as measuring theoutput voltage through the analog-to-digital converter (ADC) on the PIC, cal-culating the rate of change, and integrat-ing to acquire a heading value. This isachieved with one of the PIC’s timerinterrupts. When the gyro is to be used,the PIC’s timer1 is set with a prescaler offour, allowing it to overflow with a fre-quency of 38 Hz with a 40 MHz oscilla-

tor. On each overflow the programreads the ADC, converts the bit valueinto a floating point value, multiplies thevoltage by the overflow frequency, andthen adds that value to a running tallyto determine the direction of the robotat any given instant. The tendency forthe gyro output to drift is eliminated bydisregarding any rate changes under acertain threshold. However, disregardingsmall voltage fluctuations prevents thecode from detecting slow robot turns.

Ultrasonic sensorsThe location of walls and other obsta-

cles is obtained by three ultrasonic sen-sors mounted on each robot. Parallax’sPing sensor was used for this project.When the microcontroller is instructed toacquire a distance measurement via anultrasonic sensor, the PIC’s PWM moduleoutputs a 10 μs positive pulse to the sig-nal pin of the sensor. Upon receivingthis pulse, the sensor produces a 40 kHzultrasonic burst and sets its signal pin tologic high. The signal pin remains highuntil the ultrasonic burst reflects off ofan object and returns to the sensor. Thewidth of this pulse corresponds to thedistance between the sensor and anobject. With the burst traveling throughthe air at 344.4 m/s, the distance is cal-culated by multiplying the pulse widthby the velocity. The width of the burst isdetermined by again employing one ofthe PIC’s onboard timers, in this casetimer1. Sensors are mounted on the frontand both sides of each robot. Fig. 5shows an ultrasonic sensor; its ultrasonicburst is transmitted by one side andreceived by the other. Upon the robot’scompletion of each move instruction, thethree sensors are fired in succession andthe retrieved data is sent to the base sta-tion. These data points are then plottedwith respect to the position of eachrobot, thus producing a floor map.

Other sensorsThe robots also have a front-mounted

proximity switch that will open if thefloor in front of the robot drops off. Forinstance, if the robot were to approacha descending flight of stairs, the prox-imity switch would open and generate

an interrupt in the microcon-troller code. At this point, therobot would automaticallyback up and then report thelocation of the drop-off to thebase station.

Each robot is additionallyequipped with a 2.4 GHz wire-

less camera. Initially, the cameras were tobe used in the mapping algorithm.However, as the project progressed, itbecame apparent that the cameras werenot immediately necessary for implemen-tation of swarm. The cameras wereincluded in the final design for the pur-pose of further development of therobots’ image processing capabilities.

Worldcentric viewRobotic mapping has been exten-

sively studied since the 1980s. Mappingcan be classified as either metric ortopological. A metric approach is onethat determines the geometric proper-ties of the environment, while a topo-logical approach is one that determinesthe relationships of locations of interestin the environment. Mapping can alsobe classified as either worldcentric orrobot-centric. Worldcentric mappingrepresents the map relative to somefixed coordinate system, while robot-centric mapping represents the map rel-ative to the robot. Many mappingapproaches also use probabilistic tech-niques (such as Kalman filtering) inorder to account for noise in sensorreadings and navigation information.Robotic mapping continues to be anactive research area.

The robots discussed here use a met-ric, worldcentric approach in order to usethe simplest possible mapping algorithm.The actions of the swarm are controlledfrom a base station PC over a wirelessradio link with software written in the freeExpress Edition of Microsoft Visual Basic.Each robot moves forward from a knownstarting point until it detects a wall withone of its three ultrasonic sensors. Once a

Disregarding small voltage fluctuations preventsthe code from detecting slow robot turns.

Fig. 5 Ultrasonic sensor.

32 IEEE POTENTIALS

robot arrives at a wall, it follows the wallwhile sending sensor data to the base sta-tion. Wall following is controlled by thebase station program through variouscommands that call functions within the

robots’ microcontroller code. The micro-controller contains all communication,sensor, and motor control code as well asa means of decoding the commandsreceived from the base station.

The robots transmit their relativeposition and orientation data (obtainedfrom encoders and gyroscopes) to thebase station PC. The robots also mea-sure distances to nearby walls andobstacles using ultrasonic sensors andtransmit that data to the PC. The basestation software uses that data to calcu-late the absolute position of walls andobstacles. The PC takes its knowledgeof the robots’ starting positions and thenuses simple trigonometry (along withthe robots’ data transmissions) to calcu-late the robots’ absolute positions andorientations. The base station calculatesthe absolute position of walls and obsta-cles using trigonometry, robot ultrasonicsensor readings, and previous calcula-tions of absolute robot positions andorientations.

The PC includes various ad-hocmethods for dealing with erratic or erro-neous sensor data. The PC keeps trackof the absolute positions and orienta-tions of all of the robots. It also keepstrack of the relative positions and orien-tations of each robot with respect toeach other in order to merge the infor-mation from the robots into a coherentmap. The PC communicates with eachrobot one at a time, recalculating robotand obstacle positions after every com-munication cycle. The end result is amap created by the robotic swarm.

The robots were programmed to trans-mit information every 5 cm of movement,so wall and obstacle locations aremapped with a precision of 5 cm. Whendrawn on a map of the scale used in thisproject (tens of meters), points that are 5cm apart appear as a connected line. Fig.6 shows an example of a partial map cre-ated by the base station PC after receivingrobot transmissions. Future work couldinvolve the use of linear regression withless frequent robot transmissions in orderto create the map lines.

Conclusion All of these components come togeth-

er to form the basis for a robotic swarm.This particular project was limited by theusual constraints, mainly time andmoney. About three months were allot-ted for successful design and implemen-tation of a mapping swarm. However,the door has now been opened forfurther development of the swarm.

In the future, control of the robots’actions will be ported to the robots them-selves and inter-robot communication willbe necessary. Task optimization androbot learning can be implemented, as

Table 1. Parts list.

QuantityPart Manufacturer Cost US$ Per Robot

Angular rate gyro Analog Devices $50 1Wireless camera Superdroid $45 1Radio MaxStream $179 1Antenna MaxStream $20 1Wheel encoders Nubotics $22 2PIC18F4520 Microchip $10 1Motors Solarbotics $7 2Chassis material Various $10 1Ultrasonic sensors Parallax $30 3Proximity switch Cherry Electrical $2 1Battery packs (AA) Eagle Plastic Devices $2 2LCD display Parallax $30 1Batteries (AA) Various $2 8PCB manufacture ExpressPCB $50 1Misc. electronics Various $20 1

and connectors

The total parts cost of each robot was approximately US$584.

Fig. 6 Map created by a mobile robot. This map is a sequence of ultrasonic sensorreadings, one pixel per reading, each 5 cm apart.

46 m

Trash Can Starting Point

Doorway

Corridor

Doorway

Trash Can

Ending Point

JULY/AUGUST 2008 33

well as increasing the role of the onboardcamera (which at this point is aesthetic)with various image processing tech-niques. New sensors may be added, oth-ers may be removed, or their role altered.More complex tasks, aside from mapping,can be developed and perfected.

The success of a swarm projectdepends on the foundation set by itsearly development. An effective, simpledesign allows not only for fast implemen-tation, but also further exploration intothe world of possibilities that exist withrobotic swarms.

Read more about it• S. Thrun, “Robotic mapping: A sur-

vey,” in Exploring Artificial Intelligencein the New Millennium. San Francisco,CA: Morgan Kaufmann, 2002.

• J. Castellanos, J. Neira, and J.Tardos, “Map building and SLAM algo-rithms,” in Autonomous Mobile Robots.Boca Raton, FL: CRC Press, 2006.

About the authorsChristopher Churavy (c.j.churavy@

csuohio.edu) is currently pursuing hisbachelor’s degree in electrical engi-neering at Cleveland State University’sFenn College of Engineering.

Maria Baker (m.walden@csuohio.edu)is an electrical engineering student atCleveland State University.

Samarth Mehta (samarth001@gmail.com) is an electrical and comput-er engineering student at ClevelandState University.

Ishu Pradhan (ishu_pradhan@hot-mail.com) is pursuing a bachelor’sdegree in electrical engineering atCleveland State University.

Nina Scheidegger (n.scheidegger@csuohio.edu) is an electrical engi-neering student at Cleveland StateUniversity.

Steven Shanfelt (s.shanfelt@csuohio.edu) is a student at Cleveland StateUniversity with an interest in humanoidrobots.

Rick Rarick (rrarick_mathematikos@roadrunner.com) has a master’sdegree in both electrical engineeringand mathematics from Cleveland StateUniversity. He is currently working onhis doctorate in control theory.

Dan Simon (d.j.simon@csuohio.edu)is a professor in the Electrical andComputer Engineering Department atCleveland State University. He is asenior member of the IEEE.

Call: +1 800 678 4333 or +1 732 981 0060 Fax: +1 732 981 9667 Email: customer-service@ieee.org www.ieee.org/proceedings

Celebrating the Vitality of Technology

Today’s technologies are changing ata pace faster than ever. Every issue of the Proceedings of the IEEE examines new ideas and innovative technologies to keep you up to date with develop-ments within your field and beyond. Our unique multidisciplinary approach puts today’s technolo-gies in context, and our guest editors bring you the expert perspective you need to understand the impact of new discoveries on your world and your work.

Enrich your career and broaden your horizons. Subscribe today and findout why the Proceedings of the IEEEis consistently the most highly citedgeneral-interest journal in electrical and computer engineering in the world!**Source: ISI Journal Citation Report (2004)

No other publication keeps you in touchwith the evolving world of technology better than the Proceedingsof the IEEE.

791-Qg.indd 1 6/26/06 10:48:25 AM