0018-9162/04/$20.00 © 2004 IEEE44 Computer

C O V E R F E A T U R E

P u b l i s h e d b y t h e I E E E C o m p u t e r S o c i e t y

The Flock: Mote Sensors Sing in UndergraduateCurriculum

C omputer engineering curricula have evolveddramatically over the past 20 years. Theearly focus was on computer architectureand CPU design. In the 1990s, attentionshifted to systems built around highly inte-

grated microcontrollers. By 2000, the software forthese embedded systems assumed a more importantrole, and embedded operating systems provided high-level design abstractions. More recently, wirelesscommunication capabilities have greatly expandedthe embedded applications space, leading to new sys-tem paradigms such as sensor networks.

Educational excellence requires exposing studentsto the current edge of research. To ensure that stu-dent projects are along the same trajectory that theindustry is traveling, educators must continuallyintroduce emerging techniques, practices, and appli-cations into the curriculum.

At the University of Washington’s Department ofComputer Science & Engineering (UW CSE), wehave integrated the emerging field of wireless sen-sor networks into our undergraduate computerengineering curriculum. While many graduate-levelclasses focus on sensor networks,1-3 they do not provide a good template for the undergraduate curriculum because they assume a much greaterbreadth of knowledge than undergraduate studentsusually have as well as greater maturity to absorbnew topics on their own.

Other efforts to introduce undergraduates to thisimportant application area have focused on usingsensor networks in capstone project courses thatchallenge senior students to apply their acquiredknowledge and skills to a final project. The UWCSE “Flock of Birds” project integrates the theoryand practice of wireless sensor networks into themainstream curriculum early enough to form abasis for all students’ understanding of embeddedcomputing—not just a short-lived application exer-cise for some capstone design projects. Figure 1shows one sensor node—the bird is optional—fromthe project.

COMPUTER ENGINEERING CURRICULUMThe UW CSE computer engineering program

relies on a core curriculum shared with the com-puter science program. It consists of introductorycourses in programming, discrete mathematics, datastructures, formal methods, comparative program-ming languages, logic design, and computer archi-tecture. Computer engineering students specializewith additional second-tier courses in electricalengineering, operating systems, networks, embed-ded software, and digital system design, as well asa capstone design course that takes a product ideafrom concept to prototype.

The embedded software, digital design, and cap-stone design courses give the computer engineering

Integrating wireless sensor networks in an undergraduate embeddedsystems course exposes students to an important emerging technology in the core of the computer engineering curriculum.

BruceHemingwayWaylonBrunetteTom AnderlGaetano BorrielloUniversity of Washington

August 2004 45

program its character. They integrate software andhardware design skills and prepare students tobuild modern digital systems from start to finish.

In the embedded software course, students learnto use microcontrollers and their interfaces effec-tively to build systems that control physical devices.The digital design course teaches them to programalgorithms into hardware. In the capstone designcourse, the students apply all their skills to a prod-uct that we try to make similar to those on whichindustry engineers are currently working—in otherwords, products that will appear on the market oneor two years after the students graduate.

CSE 466: Software for Embedded SystemsThe students in our embedded software course

(CSE 466) have completed computer architectureand digital design courses, and most have studiedoperating systems as well.

This course exposes the students to the designissues that characterize embedded systems. Theseinclude constrained resources, such as limited mem-ory space, I/O, and CPU frequency; the absence ofan operating system to handle low-level tasks suchas interrupts and peripheral device interfaces; anda variety of protocols for communication betweencomponents.

Further, embedded systems often require adebugging tool set different from that of the full-scale systems familiar to our students. Print state-ments are seldom available, nor are breakpointsalways an option. Programmers and, in this case,students must find other methods to signal codemilestones.

Through prerequisite courses on data structures,digital design, and machine architecture, CSE 466students have a solid understanding of how thehardware works and how to build efficient datastructures for their algorithms. This gives them thefoundation they need to write software at the lowlevel required by embedded systems. The studentsbuild on these prerequisites with a hands-on projectthat is designed to lead them through the process ofapplying what they already know while exposingthem to the new issues that arise with embeddedsystems.

When students finish the 10-week class, theyshould be comfortable writing code that directlymanipulates I/O registers and establishes commu-nications between multiple devices. They shouldalso understand how interrupts work and how tohandle them as well as how to interpret thedatasheet of whatever chip they decide to workwith in the future.

Project design for wireless sensor networksEach edition of CSE 466 must define a project

that addresses the complexities of embedded sys-tems within the constraints of a 10-week course.For pedagogical reasons, we want a project thatstudents can complete individually. At the sametime, students are generally more engaged by class-wide projects, so we like the individual work tocontribute to an overall class effort.

Students are also more interested in projects thatuse current technology as opposed to obsolete com-ponents that they will never see again after theygraduate. As both memory and CPU cycles becomemore plentiful in most of today’s microprocessors,designing a project that is resource constrainedposes another challenge.

The computer engineering curriculum alreadyused Atmel ATmega AVR-series microprocessors(www.atmel.com) and the AVR-GCC (www.openavr.org) C compiler, so students were familiarwith these core materials. To incorporate wirelesssensor networks into the curriculum, we selected theCrossbow (www.xbow.com) Mica2dot platform.The product is an implementation of TinyOS sen-sor motes (www.tinyos.net), originally created at theUniversity of California at Berkeley.4 Mica2dot fea-tures a standard platform with built-in hardware,the existing TinyOS code base, and a convenientform factor for adding predefined sensors.

The event-based style of TinyOS helped studentsunderstand time constraints and code structure byforcing them to write short, nonblocking routines.Its modular design simplified the integration of com-ponents like the radio stack, saving countless hoursof coding. TinyOS also provided a degree of abstrac-tion within the embedded system context and intro-duced students to a style of event-based coding thatstresses real-time as well as functional issues.

We made sound generation a major focus of theproject and the overall class. Students can under-stand and implement sound generation in a month,yet it taxes a system’s cycle and memory capacityenough to make efficiency an important design con-

Figure 1. A mote-sensor bird. The“Flock of Birds”embedded systemsproject integratesthe theory and practice of wirelesssensor networksinto the mainstreamclassroom curriculum.

46 Computer

straint. A sample rate in the tens of kilohertz rangecan generate usable sound. Visual displays such asvideo on LCDs demand many more computationcycles, but human observers seldom notice visualtiming errors on the order of tens of milliseconds.On the other hand, errors of even a few microsec-onds are discernible in sound generation, givingstudents quick feedback on program accuracy.

A FLOCK OF BIRDSThe “Flock of Birds” project is a simple distrib-

uted system that meets our course objectives by com-bining sound generation with emergent behavior inan ad hoc network. Each student programs a moteto act as a bird that has several songs stored in itslocal memory. The programs execute a common rulebase, but each bird acts independently—decidingwhich song to sing based on what the other birdswithin radio range are singing. In combination, thesongs create the sound a flock of birds makes.

The flock is designed to work in any randomconfiguration with any number of nodes. Weimplemented the project in the Microsoft Atriumof the University of Washington Paul G. AllenCenter for Computer Science & Engineering,shown in Figure 2.

The primary goal was subjective: to generatebehavior that mimics the effect of birds cooperat-ing to sing the same song but vary the particularsong over time. We implemented monitoring soft-ware to measure the effect, but the final judgmentof success was aesthetic: Does it sound right? The

subjective measure contrasts with the usual quan-titative measures we used in most of our past pro-jects. A visual display of the data associated withthe sound reinforced the aural perception.

The algorithm for generating behavior uses radiopackets collected for random amounts of time fromother motes. After the time lapses, the mote decideswhich song to sing based on the data about whatsongs the neighboring motes are singing. The motethen shuts its radio off, sings its song, turns theradio back on, and transmits a packet announcingwhich song it just sang.

This algorithm requires using timers, radio com-munication, and direct manipulation of hardwareregisters for sound production. Students had to firstdevelop a complex software module on a bread-board and then explore the challenges of portingit to the mote within the TinyOS constraints.

A monitoring node served as the gateway to acontrol laptop that used special radio packets tostart and stop the algorithm and to modify globalparameters, such as the min/max limits for the ran-dom number generation that determined an indi-vidual node’s behavior. This added a dynamic aspectto the flock process. For example, we could controlthe temporal density of bird songs by changing themaximum value for the listen time between songevents. Lowering the radio transmit level in the largespace of the atrium prevented distant motes fromhearing each other and made the flocking effectoperate in multiple local areas.

We presented the flock concept to the studentsin the context of emergent behavior and the basicsof cellular automata and gave them the simplifiedtemplate algorithm shown in Figure 3.

The initial flock specification was purposelyincomplete, as we wanted student feedback andparticipation in completing its definition. This isanalogous to what students might experience in thereal world, where others have decided on a proto-col and high-level algorithm, and the developer’sjob is to implement a system that realizes the func-tionality.

The incomplete specification also exposed stu-dents to different interpretations of the design doc-umentation. They had to identify the ambiguitiesand then clarify them either with other developersor with us, “the customer.”

We asked students to invent a methodology forpredicting the success of this algorithm and to sug-gest three improvements to it. We incorporatedmany of these suggestions into the final algorithmto enhance students’ experience of participating inthe project design. A complete procedural docu-

Figure 2. TheMicrosoft Atrium in the Paul G. AllenCenter for ComputerScience & Engineering, University of Washington. The“Flock of Birds” project concludedwith a concert in the atriumconsisting of 50“bird” motes thatsang songs based on what other birdswithin radio rangewere singing.

August 2004 47

ment is available on the class Web site (www.cs.washington.edu/education/courses/cse466/03au/).

COURSE WORKMost students in the course had no prior embed-

ded programming experience. To keep the first fewassignments simple, easy to debug, and somewhatfamiliar, we had the students begin programmingwith embedded C rather than TinyOS. The assign-ments introduced some basic embedded systemsprogramming concepts such as decoding binarynumbers to pins for a pair of seven-segment dis-plays, using an analog-digital converter to measuresensor voltage and current levels, and writing inter-rupt handlers for timers.

Breadboard basicsThe students compiled their programs with AVR-

GCC and uploaded them to an ATmega16 proces-sor on a solderless breadboard. These chips comein a standard dual-inline package that is easy toplace on a standard breadboard. The breadboardallowed space for students to add peripheral devicesand debug their circuits by connecting probes foroscilloscopes and logic analyzers.

After introducing the basics, the course movedquickly to more specific applications—mostnotably, sound generation with a piezoelectrictransducer. The first sound assignment involvedusing a wave table to generate sine waves at vari-ous frequencies. This introduced the students to thenotion of using a fixed sampling rate with a phaseincrement to control frequency.

Also, because the ATmega microprocessor serieshas no digital-analog converter, the students had touse pulse-width modulation instead to produceanalog outputs to drive the piezoelectric transducer.Using PWM for this purpose was new to many stu-dents, and few of them saw immediately that theycould use a low-pass filter in conjunction withPWM to produce a reasonably accurate DAC. Bythe assignment’s end, however, all the students hadat least a basic grasp of both PWM and simplehardware-based low-pass frequency filtering.

For the next assignment, students had to build asystem that could play several different songs. Thesystem implemented familiar songs based on cellphone ring tones, ranging from Für Elise to Themefrom “The A Team.” Using familiar songs helpedthe students quickly determine whether their imple-mentation worked. If they recognized the song, theywere on the right track; if not, they likely had aproblem. Using familiar songs also raised the inter-est level in the class. This was one of the rare times

that computer engineering students could show offtheir projects to nontechnical friends.

Sound generation uses both wave and sequenc-ing tables, which require large amounts of mem-ory—more than main memory could accommo-date. Because the standard method of simplyputting these tables in RAM as static arrays wasnot possible, students had to put the data in pro-gram space. This was slightly less convenientbecause the lookup required special calls. However,it introduced students to standard practice for han-dling static data in an embedded environment. Thisreinforced the concept of memory mapping andresource allocation.

The final assignment on the ATmega16 was toplay 16 different bird songs. The songs were inMIDI format, which is slightly different from theprevious format and required the students to con-vert to a storage format of their own devising.However, the sound-generation portion of theassignment was very similar to the earlier assign-ment, so students were able to reuse much of thecode they had already written.

Students were not as familiar with the birdsongsas they were with the tunes from the previousassignment. By playing the MIDI files on their PCand comparing the sound with their implementa-tion’s, they were able to get their code up and run-ning quickly.

The ATmega128 processor that the Mica2dotmotes use is very similar to the ATmega16, so muchof the code from this assignment was reused as acomponent in the final project.

Motes and TinyOSOnce the students were comfortable with basic

embedded-systems programming issues, we intro-duced motes and TinyOS. TinyOS is based on anevent-driven paradigm instead of the polling para-digm that was standard for previous student assign-ments. Some students had been exposed to the

Goals for the flock:Birds sing the same song for a little while.Songs start, spread, then die out.Over time, different songs emerge as dominant for some period of time. Flock process flow: 1. Initialization tasks; select x = random(0-15).2. Radio off; sing birdsong[x]; radio on. 3. Listen for Random(min1, max1) sec.4. SendMessage “I sang song x”. 5. Listen for Random(min2, max2) sec.6. Decide which song to sing next:

a. Determine nearest songs. b. If my song is the same as any of the nearest songs, then I’ll repeat the same

song. c. If all nearby motes are singing the same song, then I’ll switch to a different

song. d. If all nearby songs are distinct, then I’ll switch to a different song.

7. Go to step 2 and repeat.

Figure 3. Goals andsimplified algorithmfor each bird in theflock.

48 Computer

event-based paradigm through operating system oruser-interface programming classes, but many ofthem had not.

Students spent the first few weeks learning whata component, module, and interface were and howto wire modules together. To add to the confusionabout event-driven programming, the studentsstruggled to learn NesC (http://nescc.sourceforge.net/), an extension to the C programming lan-guage designed at UC Berkeley for TinyOS.5

We used tutorials from the TinyOS Web site andsimple assignments to introduce this subject to stu-dents. After a rough start, students began to seehow quickly they could build programs with con-siderable functionality and only a little custom codeconnected to existing software components.

Many students used a 15.625-kHz sampling rateon the Crossbow Mica2dot motes. Running at thestandard 4 MHz, the system outputs samples every256 cycles. This forced students to code their sam-pling algorithms carefully so that the processingcould finish within the 256 cycles.

Debugging the Mica2dot motes presents inter-esting challenges. Traditionally, students debug theirprograms by embedding print statements in theircode or using interactive debuggers with breakpointand inspection capabilities. The Mica2dot has onelight-emitting diode for use in feedback. WhileTinyOS includes a simulator, many of the motecomponents that control hardware, such as theradio and sound-generation components, cannot beeffectively debugged with the simulator. Studentscould use some print statements with the serial portwhile the mote is on the programmer, but they hadto be more inventive when debugging in the wireless

communication environment.Given that the flock algorithm runs on a mote

among many other motes running the same algo-rithm, each node receives large amounts of inputthat the test cycle must simulate to emulate all theother nearby nodes. This required a substantialtest fixture that could produce large numbers ofpackets at predetermined times and then report onthe packets sent by the mote under test.

Instead of having the students implement theentire test fixture, we provided a fixture that tookas input a simple description of packets to send andthe time delay between them and sent these to themote under test. This test fixture handled all of thenecessary low-level interactions and allowed thestudents to write arbitrary and repeatable tests.This freed them from having to worry about thedetails of sending packets from a computer to themote under test.

Writing these tests also helped the students tobetter understand the timing details of the com-munication protocol. The students not only had tofigure out how to generate a comprehensive test forthe protocol but also how to create situations thatwould produce specific desired responses. Wherethey lacked understanding or the documentationlacked detail, they had to chase down their bugssystematically.

Concert examThe conclusion of the project was a two-hour

“concert” of 50 motes in the Allen Center Atrium.Students had to qualify their birds for admissionby passing a special test designed to exclude roguebirds from the flock. Well-behaved birds graduatedto the Allen Center atrium for the performance.Students reprogrammed failed motes with codefrom motes that did pass, allowing everyone to par-ticipate in the concert.

For the performance, we had to modify the test-ing program to send specific packets that wouldtrigger the motes to begin their process. The under-lying system was already implemented, so we sim-ply built a GUI to it. The GUI also allowed us tomonitor the motes and project a real-time wall dis-play of the frequency of different birdsongs themotes were singing. Figure 4 shows a snapshot ofthe central monitoring laptop and projected walldisplay during the concert.

We used the existing TinyOS SerialForwardercomponent to put control motes at various placesin the room and have them forward their receivedpackets to the monitoring laptop via 802.11 wire-less Ethernet. In this way, we could turn the trans-

Figure 4. “Flock ofBirds” monitoringlaptop and wall display. Thefrequency of different bird songswas projected inreal time during the concert.

mit strength down very low on the bird motes whilestill ensuring that the monitoring system recordedevery packet sent.

The overall sound effect was pleasing, andeven worked in three dimensions when some stu-dents moved their birds to upper balconies. Theaural feedback contrasted with more conven-tional projects that require extended data analy-sis to understand the results. The results werealso easier to understand than many simulationschemes.

The project succeeded from an instructional per-spective—integrating communication protocols,constrained resources, hardware control, and anovel application that required student projects tointeract. The motes supported a project that wouldotherwise have been too complex to implementover a 10-week quarter.

PROJECT CHALLENGESTinyOS is a work in progress. The large-scale

installation in our laboratories was daunting, par-ticularly relative to conflicts with preinstalled toolssuch as Cygwin and Java. These tools are used sys-temwide by many more classes and students thanour immediate group, and we spent much staff timesolving configuration problems. These problemswill change with each new TinyOS version, so thisaspect of the course will remain time-consuminguntil the tools and installation procedures mature.

The tutorials provided with TinyOS helped tointroduce the students to the basics. However, stu-dents could implement the tutorial examples bysimply copying code or following instructions byrote. To make sure students understood the under-lying concepts, we gave an exam to test theirknowledge. This motivated the students to take thetime necessary to learn the concepts. After theexam, many students claimed that TinyOS was sim-ple once they understood it. Future versions of thetutorials might benefit from scattering conceptualquestions along the way to help students focus onthe high-level structures of TinyOS in addition to itsmechanics.

Some nondeterminism in our specification oftenmade it difficult to accurately predict whether amote under test was going to be listening at anygiven time. Because of this, our testing required usto provide very clear cases in which several droppedpackets would not affect the outcome. We also hadto allow for some packets to be dropped whentransmitting them back from the node under test.

We determined that a fully automated testing sys-tem for grading would not be feasible. Instead, we

scripted seven tests totaling roughly 10 minutes,after which the staff ran through the data by hand.This was not a problem, however, since each testproduced only 5 to 20 packets from the mote—asmall number that was easy to examine.

The test program represented a large undertak-ing for the staff. It totaled more than 4,000 lines ofJava even though it used the SerialForwarder com-ponent shipped with TinyOS. The program never-theless proved quite useful to both staff andstudents, enabling bombardment of a mote withlarge numbers of random packets as well as just afew carefully chosen packets.

W e have considered making several changesto this project if we use it again in thefuture. First, the sound quality of the piezo-

electric transducers, while sufficient, was notexactly high fidelity. The choice was based on itsextremely low power requirement, but in otheroperating environments this might not be a con-sideration. Research into other transducers orspeakers could enable a wider repertory of sounds.For example, we have considered including insects,rain, other animal sounds, and whispered voices,along with contexts and rules sets for emergentbehavior to fit the sound types.

We might add input sensors. Light sensing couldallow the virtual entity to react to the diurnal cycleof ambient light. Proximity sensors could supportbehavior modifications according to the move-ments of people near a mote.

Expanding the project to include rechargeablebatteries and power management could allow a lifecycle that would require activity only when powerwas sufficient, in the style of BEAM robots (www.nis.lanl.gov/projects/robot/).

Controlling light-source color and intensitycould add visual interest and another level of com-plexity.

From the instructional viewpoint, a vital ingre-dient of the course is having an experienced TinyOSprogrammer on the staff. Until the accompanyingteaching materials for motes and TinyOS mature,this expertise will be an important condition inattempts to scale the project. ■

References1. A. Chien, “Programming Sensor Networks,” grad-

uate course CSE 291, Univ. California, Davis, 2003;www-csag.ucsd.edu/teaching/cse291s03/.

2. M. Beigl et al., “Teaching a Practical Ubicomp Course

August 2004 49

50 Computer

with Smart-Its,” poster at Ubicomp 2002; www.teco.edu/~michael/publication/smart-it_ubicomp. pdf.

3. M. Welsh, “Wireless Communications and SensorNetworks,” graduate course CS 263, Harvard Univ.,2004; www.eecs.harvard.edu/~mdw/course/cs263/fa04/.

4. J. Hill et al., “System Architecture Directions for Net-work Sensors,” Proc. 9th Int’l Conf. ArchitecturalSupport for Programming Languages and OperatingSystems (ASPLOS-IX), ACM Press, 2000, pp. 93-104.

5. D. Gay et al., “The nesC Language: A HolisticApproach to Networked Embedded Systems,” Proc.Programming Language Design and Implementation(PLDI) 2003, ACM Press, 2003, pp. 1-11.

Bruce Hemingway is a lecturer in the University ofWashington’s Department of Computer Science &Engineering and manager of its Baxter ComputerEngineering Laboratory. His research interestsinclude the development of autonomous computer-music generators that will sense mood from phys-iological indicators and produce music pleasing tothe listener. Hemingway received an AB in musicfrom Indiana University. Contact him atbruceh@cs.washington.edu.

Waylon Brunette is a research engineer and teach-ing associate in the Department of Computer Science & Engineering at the University of Wash-ington. His research interests include mobile andubiquitous computing, wireless sensor networks,and personal area networks. Brunette received aBS in computer engineering from the University ofWashington. Contact him at wrb@cs.washington.edu.

Tom Anderl is a teaching assistant in computerengineering at the University of Washington. Hisresearch interests include application-specific hard-ware and resource-limited computation. Anderlreceived a BS in computer engineering from theUniversity of Washington. Contact him at tanderl@cs.washington.edu.

Gaetano Borriello is a professor of computer sci-ence and engineering at the University of Wash-ington. His research interests are in ubiquitouscomputing, principally new hardware devices thatintegrate seamlessly into the user’s environmentwith particular focus on location and identificationsystems. Borriello received a PhD in computer sci-ence from the University of California, Berkeley.Contact him at gaetano@cs.washington.edu.