Design and Implementation of a Sensor NetworkSystem for Vehicle Tracking and Autonomous

Interception

Cory Sharp Shawn Schaffert Alec Woo Naveen Sastry Chris KarlofShankar Sastry David Culler

University of California at Berkeley, USA

Abstract

We describe the design and implementation of PEG, a net-worked system of distributed sensor nodes that detects an un-cooperative agent called theevaderand assists an autonomousrobot called thepursuerin capturing the evader. PEG requiresembedded network services such as leader election, routing,network aggregation, and closed loop control. Instead of usinggeneral purpose distributed system solutions for these services,we employ whole-system analysis and rely on spatial andphysical properties to create simple and efficient mechanisms.We believe this approach advances sensor network design,yielding pragmatic solutions that leverage physical propertiesto simplify design of embedded distributed systems.

We deployed PEG on a 400 square meter field using 100sensor nodes, and successfully intercepted the evader in allruns. We confronted practical issues such as node breakage,packaging decisions, in situ debugging, network reprogram-ming, and system reconfiguration. We discuss the approacheswe took to cope with these issues and share our experiencesin deploying a realistic outdoor sensor network system.

I. I NTRODUCTION

The problem of vehicle tracking with autonomousinterception provides a concrete setting in which to ad-vance sensor network and control system design. In ourcase, wireless sensor nodes containing magnetometersare distributed throughout an outdoor area to form adiffuse sensing field. An uncooperative agent, theevader,enters and moves within this area, where it is detected bythe magnetometers. Unlike environmental monitoring, itis not sufficient to obtain measurements of the physicaldisturbance caused by evader; we want to process thereadings within the network and take action in a timelymatter. Thepursuer, a cooperative mobile agent, entersthe field and attempts to intercept the evader usinginformation obtained from the sensor network and itsown autonomous control capabilities.

Local signal processing can be performed at eachnode to distill higher-level events from magnetic-fieldmeasurements due to motions of multiple vehicles. Clus-ters of nodes that sense sufficiently strong events cancollectively compute an estimate of the position of thevehicle causing the disturbance. These potentially noisyestimations from multiple objects must be disambiguatedand used to make continual pursuer course corrections.

The autonomous interception problem concretelymanifests many of the capabilities envisioned for sensornetworks [1], [2], including several levels of in-networkprocessing, routing to mobile agents, distributed coordi-nation, and closed-loop control. We address these issuesin terms of the whole system design, rather than asisolated subproblems. Indeed, this whole-system viewyields pragmatic solutions that are more simple thanwhat is generally found in the literature for individualsubproblems.

We built and demonstrated a working purser/evadersystem comprising a field of 100 motes spread overa 400m2 area in July 2003. The evader was a four-wheeled robot driven by a person using remote control.The pursuer was an identical robot with laptop-classcomputing resources. This paper describes the design,implementation, and experience with PEG.

Our main contributions are:• We describe the design and implementation of PEG,

a networked system of distributed sensor nodes thatdetects an evader and aids a pursuer in capturing theevader.

• We employ whole-system analysis and utilize spa-tial and physical properties to design efficient andsimple distributed algorithms. We believe this ap-proach is applicable to a variety of applications.

• We demonstrate one of the first realistic outdoortracking and pursing system that uses computation-ally and bandwidth limited sensor nodes.

Fig. 1. Illustration of an intruder interception system using sensornetworks to detect the intruder (arrow) and convey such informationto the pursuing robots. Each pursuer matches the sensor data to itslocal map for path estimation and interception of the intruder.

• We share practical advice for deploying realis-tic outdoor sensor network applications, includingpackage design, debugging techniques, and high-level network management services.

II. A PPROACH

Variants of the pursuer-evader problems have beenwell studied from a theoretical point of view [3], [4]and have been used for distributed systems research [5].Sophisticated algorithms [6], [7] have been developed toassociate readings with logical tracks of multiple objects.Elaborate data structures are used to deal with dynamictrack creation and elimination of potential tracks causedby input noise. In addition, there is work [8] on closedloop control for the autonomous pursuer starting withvarious assumptions about what information is providedto the robot.

The early work on wireless sensor networks observedthat distributing intelligence throughout the sensor arraydramatically simplified the tracking problem [2]. Whendense sensing is employed, each patch of sensors onlyhas to deal with a few objects in a limited spatialregion. Signal processing is greatly simplified becausethe sensors are close to the source, so the SNR is high.Physical constraints, such as speed of movement, allowfor low-level filtering of false positives.

Others have studied a decentralized form of theproblem where object tracking, classification, and pathestimation are performed by a network of wireless sen-sors [9], [10]. In this formulation, sensing and detec-tion are performed by local collaborative groups, eachresponsible for tracking a single target. The solutionis cast in traditional distributed system terms with an

explicit representation of the group associated with eachobject. Movement of the object involves nodes joiningand leaving the group. Leader election is performed sothat a particular node represents the object at any point intime and typically as the root of the collaborative signalprocessing. Recent work optimizes a single objectivefunction that combines the cost of signal processingand tracking with the benefits of obtaining the givendata [11]. Sophisticated programming environments havebeen proposed [12], [13] to maintain the distributed datastructure representing each logical entity and the set ofnodes associated with its track. Unsurprisingly, thesestudies suggest that quite powerful nodes are required toperform distributed tracking. In addition, [14] proposes ahigher-level programming environment that uses abstractregions to simplify development of sensor applications.Recently, other researchers have begun to focus on theuse of very simple outputs from dense networks ofsensors. For example, [15] explores tracking where eachsensor reports only a single bit of information of whetherthe disturbance is getting closer.

We adopt a lightweight approach that stems fromtwo key observations. First, the autonomous interceptionproblem admits a natural two-tier hierarchy. The lowertier of nodes, which are the most numerous and mostresource constrained, are responsible for simple detectionfunctions and for providing distilled information to ahigher tier. The higher tier is capable of doing moresubstantial processing and initiating actions based on theinformation. In a basic tracking problem, the higher tiermight include computer-controlled cameras, whereas inthe interception problem it is a mobile pursuer. Elementsin the lower tier generally do not need to know muchabout the track or the identity of the object, as theirbehavior does not change based on that information. Therobots are power intensive and require substantial localprocessing, hence they are a natural point of concentratedprocessing.

Second, in-network processing at the lower tier isessential to conserve bandwidth, thereby reducing con-tention and keeping notification latency low. The pro-cessed results need not be perfect as they will be furtheranalyzed by the higher tier. For example, an inconsistentleader election may cause two closely related positionestimations for an object at nearly the same time. This iseasily addressed in the higher level processing. Inconsis-tency is far more benign here than in the settings wheredistributed consensus is typically used, for example toavoid multiple financial transactions [16], [17].

Calibration &Sensing

Leader Election &Data Aggregation

Data Filtering InterceptionPlanning

PursuerNavigation

Route to Mobile Pursuer

Nodes near evader

Pursuer

Fig. 2. Logical flow of information in PEG. After the nodes calibratetheir sensors, they listen for events in the network. When events aresensed near several nodes, a leader is elected to aggregate the datainto one packet. This packet is routed to the moving pursuer viamulti-hop routing. After data filtering and interception planning, thepursuer chases the evader.

III. SYSTEM ARCHITECTURE

To provide pursuers with accurate detection eventsquickly and often, we developed services for detection,routing, data processing, and pursuit. We provide a senseof the overall information flow and describe the con-stituent system services. Power management and securityare beyond the scope of this paper.

A. Software Services

Figure 2 illustrates the information flow from thelower tier sensing field to the higher tier processing unitat the pursuer. The sensor network detects the evader androutes this information to the pursuer, and the pursueracts on this data to intercept the evader. Figure 3 showsthe overall system architecture of the services requiredto implement PEG.

When a vehicle is present, the sensing and detec-tion component (Section IV-B) of nearby nodes willtrigger detection events and invoke the leader electionalgorithm (Section IV-D) for data aggregation. The pro-cess of leader election is realized over a tuple-spaceneighborhood service (Section IV-C). The elected leaderwill propagate the aggregated data as detections to thepursuers using landmark routing, which operates over asimple tree building mechanism (Section V).

When detections reach the pursuer, the pursuer usesan entity disambiguation service to determine the causeof the event: the evader, the pursuer, or noise. Detectionsthat are determined to correspond to the evader are sentto the evader position estimation service. The pursuerposition estimation service uses data from the GPSunit to determine an estimate of the pursuer position.Estimates of the position of the pursuer and evaderare sent to the interception service, which generates ainterception destination for the pursuer. This destinationis processed by the path planning service to generate a

Path Following Pursuit Services

Purs

uer

Arc

hite

ctur

e

Interception Planning Path Planning

Pursuer Position Estimation Estimation Services

Entity Disambiguation Evader Position Estimation

Application ServicesLocalization Leader Election and Aggregation

Sens

or N

etw

ork

Arc

hite

ctur

e

Landmark Routing Tree Building Node Management Network ServicesNetwork Reprogramming Config Neighborhood

Ranging Sensing and Entity Detection Intra-moteservicesHardware Abstraction Messaging

Fig. 3. Hardware and functional division of services. The dottedline separates services running on the pursuer from services runningin the sensor network.

feasible route. Finally, the route is submitted to the pathfollowing service that tightly controls the pursuer alongthis route. These mechanisms are further developed inSection VI.

Beside the core functionally required for PEG, newsystem services are also implemented to ease the dif-ficulty in managing and configuring the network at thetime of deployment. The Config component allows run-time configuration of system parameters that are usefulfor system tunings. The node management componentis used for node identification, debugging, and network-wide power cycle management. Finally, network repro-gramming allows rapid reprogramming the entire systemover the wireless medium, which is valuable for rapidupdate of code image. We discuss these deploymentissues in Section VIII.

We originally intended to use a self-localization ser-vice to determine each node’s position. This servicewould have used time-of-flight ultrasonic ranging tech-nology with an anchor-based localization algorithm.However, due to sporadic errors, we did not use self-localization in the live demonstration, and instead hard-coded node positions. For more information on ourlocalization service, refer to work by Whitehouse etal. [18], [19].

B. Sensor Tier Platform

The sensor tier of our system consists of BerkeleyMica2Dot motes [20], a quarter-sized unit with an 8-bit 4 MHz Atmel ATMEGA128L CPU with 128 kBof instruction memory and 4 kB of RAM. Its radiois a low power Chipcon CC1000 radio that deliversabout 15 kbit/sec application bandwidth with a maximumcommunication range of around 30 meters using a piano-

Exposed components

Watertight compartment

Ultrasound

Battery

Collision absorption

CPU / RadioMag Sense

Power

Reflector

Fig. 4. Photograph of a PEG sensor deployed in the field on theday of the demonstration (left), and a schematic of its basic elements(right). The height between the plastic end caps is 3.0 inches (7.6 cm),and the height from the bottom spring base and top of the ultrasoniccone is slight less than twice that distance.

wire antenna placed a few inches from the ground in agrassy field. Each node uses a magnetometer to detectchanges in a magnetic field, presumably caused by anearby moving vehicle. We included a 25kHz ultrasoundtransceiver for time-of-flight ranging. A reflector cone issituated above the transceiver to diffuse the ultrasonicwaves for omni-directional ranging which significantlyreduces the ranging radius to about 2 meters.

Figure 4 shows the complete packaging of a sensornode. At the bottom of the node is a base that securesthe node to the ground and extends it a few inchesabove the ground. The battery, voltage conversion board,magnetic sensor, and the Mica2Dot are all protected bythe plastic enclosure. The side of the enclosure has a holethat allows the quarter-wavelength piano wire antenna tobe connected to the Mica2Dot. The only sensor exposedis the ultrasound transceiver at the top, with the conesecurely mounted above it. The package is robust againstimpact from vehicles, and the spring at the base keepsthe node upright even after collisions to elevate the nodea few inches above the ground plane for effective radiocommunication.

All nodes at the sensor tier run TinyOS [20], an event-driven operating system for networked applications inwireless embedded systems. The implementation of allthe core services shown in Figure 3 consumes about60 kB of program memory and about 3 kB of RAM.

C. Higher Tier Platform

Our ground robots are essentially mobile off-roadlaptops equipped with GPS. Each robot runs Linux on a266 MHz Pentium2 CPU with 128 MB of RAM, 802.11wireless radio, a 20 GB hard drive, all-terrain off-roadtires, a motor-controller subsystem, and high-precisiondifferential GPS. This platform is sufficient to execute

the simple higher-tier services shown in Figure 3. TheGPS typically provides estimates every 0.1 seconds withan accuracy of about 0.02 meters. The top speed of therobot is about 0.5m/s, with independent velocity controlfor each wheel. In our deployment, we used one pursuerand one evader, each the same model robot.

IV. V EHICLE DETECTION

Detecting a vehicle in the network begins with a nodegathering and processing data leading up to the formationof a position estimate report. In this section, we showhow a bandwidth analysis of the overall system drivesthe design of our architecture.

A. Bandwidth-Driven Design

We design our sensor network to provide full, redun-dant sensor coverage – for sensors placed in a grid,a vehicle excites at least four and up to nine sensors.From this coverage requirement, we design the rest ofthe detection system with an understanding of the impactof low-level decisions on regional bandwidth limits.

Presuming a local aggregate bandwidth of forty 36-byte packets per second, a single node can provide upto four reports per second before a region of nine nodessaturates the shared channel. If each node sends thesedetection events, the local channel will be saturatedleaving no bandwidth for other communications suchas routing these readings to the pursuer. Additionally,as more vehicles are added to the system, routing thedata will increasingly tax the bandwidth of the system.Clearly, we must use some techniques to conserve band-width.

We use local aggregation to reduce many detectionevents into one position estimate report. We allocatehalf the total bandwidth for exchanging local detec-tion reports and the remaining bandwidth for systemwide behaviors such as routing position estimates topursuers. Even though sharing local detections uses asignificant portion of the local bandwidth, the pursuerstill receives frequent position updates. We decomposethis overall process into three distinct phases: calibrationand sensing, local detection reports, and leader electionand position estimation.

B. Calibration and Sensing

The magnetometer measures the entire magnetic en-vironment. This includes static structures such as theEarth’s magnetic field and other metal in the surround-ings. To detect changes in the magnetic field causedby a moving vehicle, this static environment must be

accounted for in each node’s measurements. Each nodebiases each reading given a moving average of the sensorreadings. This sets a minimum detectable speed on avehicle, because a sufficiently slowly moving object willbe indistinguishable from the static environment.

One interaction that we did not expect is a relationshipbetween the radio communication and the magnetometer.Because of the proximity of the radio chip and themagnetometer chip, which is in part a result of the smallpackage design but also exacerbated by our hardwaredesign, radio transmissions excite significant readingsfrom the magnetometer. As a workaround, we invalidatemagnetometer readings for a short period whenever aradio packet is sent or received at the node.

C. Local Detection Reports

To decide if a node should share its calibrated readingwith its neighbors, the node compares the 1-norm ofits magnetic reading against a preset threshold value.If the detected value exceeds this threshold, the nodesends a message including the magnetic magnitude andits own (x, y)-position in meters. To limit a node’s localdetection report rate to 2 packets per second, each nodeis subject to a reading timeout of 0.5 seconds duringwhich it is not allowed to share a new reading.

To share data among a neighborhood of nodes, weevolved a new programming primitive called Hood [21].A neighborhood in Hood defines a set of criteriafor choosing neighbors and a set of variables to beshared. The neighborhood membership, data sharing,data caching, and messaging is managed by the Hoodabstraction, allowing the developer to focus on theproperties of a neighborhood instead of its mechanics.Hood exploits the cheap broadcast mechanism of asensor network to allow asymmetric membership – anode broadcasts changes to its neighborhood values anddoesn’t know or care what other nodes consider it amember, which is different from the group collabo-ration work found in [9], [10]. Hood is well suitedfor unreliable communication channels such as those insensor networks, and defers concerns of reliability andconsistency to the application level.

For PEG, we created aMagHood that manages themessaging and caching of local detection reports andprescribes the neighborhood membership criteria. Be-cause the magnetometer neighborhood represents a localphysical relationship, and because radio connectivitydoesn’t have a clean relationship with respect to physicaldistance, membership in the neighborhood is restrictedto only those nodes within 3 meters. And, similar to the

report timeout, readings are invalidated after timeout of0.5 seconds, which sets a time window on the validityof a neighbor’s reading.

D. Leader Election and Position Estimation

We cast leader election as primarily a bandwidthreduction technique and relax the usual requirement ofcorrelating a single leader with a single entity, unlike[9], [10] where vehicle classification is done on thesensor node. High level processing on the pursuersimposes model constraints to correlate position estimateswith individual entities. This decomposition allows us toconstruct a significantly more simple and robust leaderelection protocol.

UsingMagHood, each node gains a view of the recentdetection reports from nodes in its neighborhood. At thispoint, the leader election protocol requires no additionalcommunication – a node elects itself leader if it has themaximum magnetometer magnitude among the nodes inits neighborhood. This lightweight mechanism embodiesthe idea of loose consistency: in the worst case, everynode that detects the location of a vehicle reports it.

The pursuer receives reports about all position es-timates in the network – those caused by the evader,by itself, or by noise. Even with this policy, redundantleaders for a single object are the exception not the rule,because leadership changes smoothly over time given thephysical interactions. Additionally, this design implicitlysupports multi-object tracking by providing all the datanecessary for the pursuer to do centralized filtering andcorrespondence.

The position estimate report contains the(x, y)-position calculated as a center of mass, the total numberof nodes contributing to the report, and the sum ofthe detection magnitudes. Similar to previous timeouts,a node is only allowed to become leader and send aposition estimate report at most every 0.5 seconds. Thisestimated position is again a loosely consistent value– instead of using a time synchronization service toguarantee that all readings happen within a strict epoch,the cache timeout establishes a notion of a weak epoch.

Within each weak epoch, a node elects itself leaderthe instant it determines it has the largest detectionmagnitude. As an alternative, if a node would havewaited a period of time for additional readings, thereexist certain vehicle paths that prevent any node frombecoming a leader, which would produce no positionestimates for the pursuer. Furthermore, this protocolensures that a node can become a leader if its detectionexceeds the threshold, meaning that the maximum speed

of the vehicle is only a function of the properties of thesensor and the allocated bandwidth for position reports.

V. ROUTING

The primary routing requirement in PEG is to deliverthe evader detection events, as sensed by the network,to the mobile pursuers. That is, we must route packetsfrom many sources to a few mobile destinations. Thisdiffers from the typical many-to-one data collectiontraffic model found in other sensor network applications[22], [23], [24]. However, it resembles some of the workfound in the mobile computing literature, which providesdifferent approaches to support this mobile routing ser-vice. In this section, we first explore these approachesand then discuss a simple and efficient landmark routingapproach to arrive with a solution, which is potentiallyapplicable to systems other than PEG.

A. Design Approaches

One design approach is to treat the entire network andthe mobile pursuers as one ad-hoc mobile system, anddeploy well-known mobile routing algorithms, such asDSR, AODV, and TORA [25], [26], [27], which requireO(N) of communication complexity to provide an any-to-any routing service. These protocols are designed tosupport any pairs of independent traffic flows while thetraffic in PEG is correlated and directed only to a fewmoving end points (the pursuers).

Another approach is to decouple the network from themobile pursuers and exploit the static network topologyto decrease the communication complexity for routing.This resembles the home-agent work found in mobilecomputing [28], where every pursuer is assigned a home-agent. For example, recent work supports group com-munication among a set of moving agents over a sensornetwork in a bounding box [29]. It assumes that any-to-any routing comes free by using geographical routingand maintains a horizontal backbone to support commu-nication among moving agents within the bounding box.The communication complexity depends on the overheadof backbone maintenance and home agent migrationfrequency.

For efficiency and simplicity, the approach we usealso exploits the static network topology, but we do notassume any geographical routing support or grid locationinformation as in [30]. We use a variant oflandmarkrouting [31] to split the many-to-few routing probleminto two subproblems: many-to-landmark and landmark-to-few. Landmark routing is a simple mechanism thatuses a known rendezvous point to route packets from

many sources to a few destinations. For a node in thespanning tree to route a detection event to a pursuer,it first sends a message up a spanning tree to the rootnode, the landmark. Then the landmark forwards themessage to the pursuer. The original landmark paperdiscusses a hierarchy of landmarks for scalability. In thiswork, we only consider a single landmark. Landmarkrouting results in longer routing paths as traffic must gothrough the landmark, which hurts latency, but requiresless control bandwidth to maintain routes to the movingtarget than other protocols such as AODV.

B. Building Good Trees

For many-to-landmark routing, we rely on a spanningtree rooted at the landmark. All packets are forwardedalong the tree towards the landmark. A common ap-proach to building a spanning tree is to flood the networkwith a beacon, and each node marks its parent in the treeas the first node from which it receives the beacon, andthen rebroadcasts the beacon. This approach of floodingthe network and routing using the reversed paths is usedin ad-hoc routing algorithms such as AODV [26] andDSR [25] to build a topology quickly and trade offoptimality for handling mobility.

Such a flooding process must address two poten-tial problems: quality route selection and the broadcaststorm problem [32]. The routing protocol must avoidselecting bad links for routing; in particular, asymmetricconnectivity should be avoided since the reverse pathsare used for routing. Route selection solely using hopcount cannot address these issues. The second issue,broadcast storms, occurs when many nodes receive abeacon simultaneously and attempt to rebroadcast thebeacon immediately. As a result, a storm of packetcollisions is created and significant message loss wouldoccur, which leads to an ill-formed topology containingmany back edges. Back edges occur when nodes missa beacon message because of collisions, but later over-hear it from nodes further down the tree. Back edgescreate unnecessarily long routes. Empirical data in [33]provides evidence of these issues.

Our first challenge is route selection. A node mustconsider both the link quality and tree depth of thepotential parent. Without any rapid link estimation mech-anism, we rely on the received signal strength indicator(RSSI). Recent studies in [34] and [35] show that RSSIis not always a good predictor of link quality. However,we can exploit spatial information to our advantageto rely on RSSI values. With all nodes on roughlyon a grid configured to transmit at the same power

and the fact that signal strength decays at least1/d2

when close to the ground, it is possible to use RSSIthreshold filter to scope the neighborhood relative tothe physical distance. By empirically measuring therelationship between link reliability and RSSI valuesamong nodes at different grid distances beforehand, wedetermine a high confidence RSSI value for the entirenetwork that maximizes communication distance whilereliably preserving bidirectional link reachability for ourreverse path routing. A node only accepts a message ifits RSSI value is greater than the threshold, even if itwas able to properly decode the message. The routinglayer can be a simple algorithm that selects the shortesthop-count parent that passed the RSSI filter. Section VIIpresents measurements of the end-to-end reliability ofthe routing paths discovered by this approach.

The second challenge is to alleviate the broadcaststorm problem. We used a time-delayed back-off thatadapts to the observed cell density. Broadcast stormsoccur because several nodes simultaneously attempt torebroadcast the beacon. Instead, if each node waits arandom time before re-broadcasting the beacon, thennetwork congestion decreases. With random back-off,the number of potential wait times should be propor-tional to the number of nodes in a radio cell; as nodedensity increases, nodes must wait longer periods oftime. Choosing the maximum wait time, then, requiresknowledge of the density. An alternative idea is toemploy a more adaptive technique. Upon the receptionof a broadcast message, each receiver starts a timer tofire in a random amount of time less thanR. Everytime the node receives a broadcast message before itstimer expires, it resets the timer to fire in a new randomtime. Thus, theR interval from which nodes wait issignificantly smaller than in the naive protocol. The totalwait time is now adaptive and inversely proportional tothe radio cell density, which is the number of times thesame broadcast message is heard. In both sparse anddense networks, propagation within local cells finishesin R · n/2 time, wheren is the cell density.

One typical spanning tree is in Figure 5. The datawas collected from 100 mica2dots with 2m spacing. Thelandmark is near the center of the field, at position (8,8).The tree has depth three, considerably less than if gridrouting were used. Four nodes did not join the spanningtree because they were broken; Section VIII addressesbreakage. Additionally, the parents of most nodes arephysically closer to the landmark. In those cases wherethis is not true, such as at (0,10), the physically closerparent is not any closer by the hopcount metric.

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

0

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

to (4,0)3 hops

to (4,0)3 hops

to (6,4)2 hops

to (6,4)2 hops

to (10,2)2 hops

to (10,2)2 hops

to (12,2)2 hops

to (12,2)2 hops

to (12,2)2 hops

to (12,2)2 hops

to (6,4)2 hops

to (6,4)2 hops

to (6,4)2 hops

to (6,4)2 hops

to (10,2)2 hops

to (8,8)1 hop

to (8,8)1 hop

to (12,2)2 hops

to (12,2)2 hops

to (12,2)2 hops

to (6,4)2 hops

to (6,4)2 hops

to (6,4)2 hops

to (8,8)1 hop

to (6,4)2 hops

to (8,8)1 hop

to (8,8)1 hop

to (12,4)2 hops

no conn. to (14,6)2 hops

to (2,6)3 hops

to (6,4)2 hops

to (6,4)2 hops

to (8,8)1 hop

to (8,8)1 hop

to (8,8)1 hop

to (8,8)1 hop

to (8,8)1 hop

to (14,6)2 hops

to (14,6)2 hops

to (2,8)3 hops

to (6,10)2 hops

no conn.no conn.landmark to (8,8)1 hop

to (8,8)1 hop

to (14,6)2 hops

to (14,6)2 hops

to (14,6)2 hops

to (0,12)3 hops

to (8,10)2 hops

to (6,10)2 hops

to (8,8)1 hop

to (8,8)1 hop

to (8,8)1 hop

to (8,8)1 hop

to (14,12)2 hops

to (14,12)2 hops

to (14,12)2 hops

to (8,10)2 hops

to (8,10)2 hops

to (6,12)3 hops

to (8,12)2 hops

to (8,8)1 hop

to (8,8)1 hop

to (12,14)2 hops

to (8,8)1 hop

to (14,12)2 hops

to (14,12)2 hops

to (0,12)3 hops

to (8,12)2 hops

to (8,12)2 hops

to (8,12)2 hops

to (10,14)2 hops

to (8,8)1 hop

to (8,8)1 hop

to (14,12)2 hops

to (14,12)2 hops

to (14,12)2 hops

to (2,14)3 hops

to (4,16)3 hops

to (8,12)2 hops

to (10,14)2 hops

to (10,14)2 hops

to (10,14)2 hops

to (12,14)2 hops

to (12,14)2 hops

to (12,14)2 hops

to (16,16)3 hops

to (4,16)3 hops

to (4,16)3 hops

to (4,16)3 hops

to (10,14)2 hops

no conn.to (10,14)2 hops

to (10,14)2 hops

to (10,14)2 hops

to (10,14)2 hops

to (16,18)3 hops

x position (meters)

y po

sitio

n (m

eter

s)

Fig. 5. Spanning tree generated by PEG using 100 mica2dot nodes.PEG uses a basic flooding algorithm that adapts to different nodedensities.

C. Efficient Landmark Routing

With the spanning tree built using the previous mech-anism, any nodes in the network can send messagesto the landmark, which forwards them to the movingpursuers. To accomplish this, the pursuer periodicallyinforms the network of its position by picking a node inits proximity to route a special message to the landmark,thereby laying a “crumb trail.” Instead of maintaining allthe routing states at the landmark, this message depositsa “crumb” with each intermediate router on the spanningtree so that messages destined to the pursuers at thelandmark can travel along the crumb trail created by thecrumb message. Each crumb trail is identified by thepursuer’s ID when it deposits its crumb to distinguishfrom multiple concurrent crumb trails. The pursuer in-crements a sequence number to give a time dimension tothese crumb trails so these paths can dynamically trackthe pursuer’s position. Routing states are soft in that theybecome stale over time, and thus, stale crumb trails prunethemselves automatically.

Our approach to solving the many-to-few routingproblem is efficient. The tree-building overhead is anO(N) operation. As discussed earlier, ad-hoc protocolsrequireO(N) overhead to route to a mobile destination.In our landmark scheme, the overhead in maintainingmobility is solely the crumb messages, which has acommunication complexity ofO(d), where d is thenetwork diameter. This means that we can route to apursuer with significantly less overhead.

Note that there is no explicit coupling between the

landmark and the moving pursuers as in the case ofthe home-agent approach. In fact, the pursuers do noteven know the address of the landmark. This is a niceproperty, allowing the landmark to become another nodeif the first fails.

A shortcoming of this approach is that the landmark isa central point of failure. However, there are many tech-niques to eliminate this vulnerability. Since the crumbtrails and the spanning tree can be built rapidly, it is easyto switch over to another landmark if the original fails.Additionally, it is simple to maintain multiple separateinstances of landmark routing with independent crumbtrails and landmarks. This quick failover capability isimportant to cope with the flakiness inherent in sensornetworks.

VI. NAVIGATION AND CONTROL

The pursuer must decide how to assimilate an aggre-gated sensor packet to minimize evader capture time. Inthis section, we will describe the difficulties in designingthis control system, the techniques used to overcomethese difficulties, and the final architecture. Although thecontrol architecture we present is not new, the modalityof the sensor network data is significantly different thanthose of traditional control systems. We will discuss howthese concerns are addressed with our implementation.

A. Design Issues

Classical feedback control design [36] typically as-sumes that periodic sensor readings occur and arrive attheir destination in zero time, that the computation of thecontrol law is instantaneous, and that control signals areapplied to the actuators immediately. These requirementsare typically necessary to analyze a controller’s stabilityand performance. Several techniques have been studiedto relax these assumptions [37], and some researchershave suggested that new techniques need to be de-veloped [38]. However, in practice, these constraintsare typically approximated by using a sufficiently highfrequency of sensor readings, by minimizing timing jitterand latency, and by reducing computation time of thecontrol law. Typical implementations of control systemsachieve these approximations through the use of locallyresident sensors, actuators, and powerful computationalhardware. However, due to the distributed nature andlimited capabilities of sensor networks, many of theseassumptions are violated.

In PEG, we can approximate instantaneous controlcomputation by assuming that the pursuer is a powerful

node that performs all the control computation. How-ever, the application of classical control techniques isfrustrated by the tendency of the sensor network datato be noisy, arrive late, lack time-stamps, and arrivewithout periodicity. High speed controllers, such as apath follower, further highlight the difficulty of controlusing only sensor network data. In our case, a feedbackimplementation using only sensor network data wouldrequire artificially slowing down the dynamics of thesystem.

Furthermore, nodes will fail at times due in part tofaulty hardware and collisions with robots. This presentsanother characteristic of sensor networks that differ froma typical control setting. When operating in a sensornetwork, a controller must additionally compensate forsporadic sensor readings due to badly behaving nodes.For such problems, it is not always possible for acontroller to maintain a constant level of performance.We seek to provide high performance of the controllerwhile allowing for a graceful degradation in performanceas the data qualitatively deteriorates and ensuring safetyproperties such as not leaving the field.

B. Design Choices

To overcome the aforementioned difficulties, we makeseveral design choices for the pursuer control. First,we cleanly separate the control system from the sensornetwork as much as possible. To this end, the networkprovides sensor readings to the pursuer, but all pro-cessing and control computation occurs on the pursuer.Second, we apply more traditional control techniquesto the pursuit algorithm, changing the design wherenecessary for sensor network data.

A pursuit control system ultimately consists of a sys-tem for estimating the position of the evader, strategicallydeciding where the pursuer should go next, planning apath to the next destination, and following that path. Toachieve the best estimation of the evader’s position, weprefer a model for the evader’s dynamics with unknowncontrol input. However, this is an unnecessary burdenconsidering the specification of our system. For instance,the robots can quickly change the velocity of each oftheir wheels independently (within about 0.2 seconds),which, as far as a sensor network that reports every 1-3 seconds is concerned, allows the robot to virtuallychange its speed and direction instantly.

In PEG, the pursuer only needs data every few sec-onds from the sensor network, but requires much moretimely location information for navigation. We use GPS

Strategic Controller

Point Navigation Controller

Motor Controller

Coordinate Transformation

State Estimation

SensorNetwork

State Estimation

GPS

Filter

motors

High Speed

Dynamics

Low Speed Dynamics

Fig. 6. Block diagram view of the hierarchical multi-rate pursuercontroller. All variables except those with aGPSsuperscript representvalues relative to the mote coordinate system. Furthermore, thesubscriptsp ande, indicate pursuer and evader respectively. Finally,wk represents the set-point for velocity of thekth wheel

for navigation which provides updates about every 0.1seconds with an accuracy of about 2cm.

C. Implementation Overview

In this section, we outline our final controller designwhich is illustrated in Figure 6. First, two differentcoordinate systems must be addressed: the GPS co-ordinate system and the coordinate system relative tothe mote network. To work within a single coordinatesystem as quickly as possible, we immediately convertGPS measurements into the mote coordinate system.GPS provides estimates of the pursuer’s position inGPS coordinates,[xgps

p , ygpsp ]T . Using a fixed, known

homogeneous coordinate transformationΦ, we computethe pursuer’s estimated position in the mote coordinatesystem as[xp, yp, 1]T = Φ ∗ [xgps

p , ygpsp , 1]T . Using a

trace of these values,(. . . , [xkp, y

kp ]T , [xk+1

p , yk+1p ]T , . . .),

we can compute a full state estimation for the pursuer,which includes estimations of the position, the velocity,and the orientation.

Although any techniques exist for state estima-tion [39], [40], in our case, it is enough to use simpletechniques. For the estimated position [xp, yp]T , wesimply use an average of the two most recent GPSpositions. These estimated positions then form anothertrace Λ = (. . . , [xk

p, ykp ]T , [xk+1

p , yk+1p ]T , . . .). For the

orientation estimateθp, we use an average of the anglebetween pairwise combinations of the last four estimatedpositions, i.e., the four most recent entries inΛ. Themagnitude and direction of the velocityνp is estimated

by using the two most recent entries inΛ. The numberof readings used for estimation was chosen by trial anderror.

Turning to the evader’s state estimation, we firstreceive an estimate of an unknown object’s position inthe network,(x?, y?). Using a previous estimation ofthe evader’s position(xe, ye) and a current estimationof the pursuer’s position(xp, yp), a filter determines ifthe reading corresponds to the evader, the pursuer, ornoise in the system. If we letα be the average errorof the sensor network due to true positives, i.e., notincluding error due to false positives. Then, we cansafely disregard sensor reports withinα of the pursuer’sestimated location, since these reports must correspondto the pursuer or a captured evader (assuming that ourcapture radius is greater thanα). Sensor reports within2∗α+ |νmax| ∗ t of the previous estimate of the evader’sposition are assumed to be the evader, wheret is theelapsed time since the previous estimate andνmax is themaximum velocity of the evader.

If the new sensor reading is determined to be theevader, this value is used to update the state estimateof the evader using techniques similar to those for thepursuer. In this case, our estimate of the velocity andorientation will be of much lower quality. However,because the strategic controller only updates every timeit receives a new evader state estimate (at a much lowerrate than the actual velocity and heading of the evadercan change) it is unnecessary to exploit knowledge ofthe evader’s orientation and velocity.

Using position estimates of the pursuer and evader, thestrategic controller chooses the pursuer’s next destination[xnav, ynav]T and interception speedνnav. In makingthis choice, the strategic controller attempts to minimizecapture time. Again, we use a simple strategy: thepursuer moves to the estimated position of the evader.Finally, the point navigation controller will compute apath to the new destination. This path is realized bycontinually issuing new set points(ω1, ω2, ω3, ω4) for thevelocity of each robot wheel, such that the robot movesforward enacting turns as needed to reach its destination.

In conjunction with the aforementioned processes, thecontroller maintains safety specifications by applyinghard constraints to the controller at various points. Toensure that the pursuer never leaves the network, thepoint navigation controller always compares the pur-suer’s estimated state with the fixed, known values of thenetwork boundary. If the pursuer is leaving the network,the point navigation controller directs the pursuer to thecenter of the network until further notice. Additionally,

4 5 6 7 8 9 10 11 12150

200

250

300

350

400

450

500

550

600

650

Rou

te ti

me

(ms)

Number of hops

Fig. 7. Latency of packets routed through PEG’s landmark routingalgorithm. Each data point represents the average time to route 200packets through the given number of hops on a 36 node indoorMica 2.

if the strategic controller notices that the pursuer’s esti-mated state is within the capture radius of the evader’sestimated state, it has the point navigation controller stopthe pursuer. The pursuer remains there until a new evaderupdate farther away appears; at which time the controlsystem reinitiates pursuit of the evader.

VII. E VALUATION

A. Routing Service

One of the most important metrics for evaluating themultihop routing service is end-to-end reliability, espe-cially when the topology is built over many unreliablelinks during a network-wide flooding. We created a setof micro-benchmark experiments to measure end-to-endsuccess rate of packet delivery of any random pair ofnodes in the network using our landmark routing. We donot use link retransmissions because of the time sensitivenature of the data. Link retransmissions could haveimproved end-to-end reliability, but the received trackingdata would have been stale. For latency tests, there is nocontention on the channel because only one packet isbeing sent at a time. The end result is very promising.For paths with lengths between 4 to 6 hops, the averageend-to-end success rate falls in the range of 95% to 98%.This implies our topology formation can build trees thatare reliable for bi-directional communication.

Another metric that is important to PEG is the end-to-end latency in delivering the detection events to the mov-ing pursuers. Our landmark routing approach trades offroute efficiency for simplicity and low protocol overhead.The simplicity of the landmark routing scheme producesroutes that may be longer than necessary since the

message must pass through the landmark. For example,for a neighbor to route a message to an adjacent node, itmust traverse through the landmark which could be faraway. There could be delays from many sources: the timeit takes a packet to travel, the processing time, MAC backoff time, and routing decision time. By observing thepacket size and extra synchronization overhead coupledwith the radio bandwidth, we can conclude that a packetoccupies the channel for 26.2 ms. The MAC waits auniformly random time between 0.4 ms and 13.0 msbefore sending a packet, averaging in a 6.7 ms delay.We measured the latency that it takes for our algorithmto route packets in Figure 7 on a field of 36 sensornodes. For a least squares minimum fit on the data inthe figure, we find the slope of the line is 53 ms/hop,so we conclude processing time is consistently around20 ms. Even if the landmark route is 6 hops while theoptimal path is a single hop, the landmark routing willtake 225 ms longer than necessary. In this time, theevader can only travel 13 cm, an insignificant distancecompared to the precision of the measurements. Thus,even though landmark routing may choose longer routes,the extra routing time is within our requirements.

B. Tracking and Interception

To evaluate the system in a realistic outdoor demon-stration on July 14, 2003, we deployed a field of 100nodes and performed a half-dozen runs1. The evader wascontrolled by a driver not affiliated with PEG. The evadercan leave the sensor grid area, but the pursuer cannot.The pursuer was able to successfully capture the evaderin all cases; we define success when the pursuer arriveswithin a grid square of the evader. Figure 8 displays onesuch interception. Initially, the pursuer is in a differentorientation from the evader. It first orients itself towardsthe evader before capturing the evader. The sequencespans 26 seconds and ends when the pursuer touchesthe evader.

In order to display more quantitative data, we wouldlike to analyze network traces from an actual run fromour July 2003 demo. Unfortunately, our demonstrationwas not sufficiently instrumented to collect data, and wehave subsequently instrumented and re-deployed PEG.Figure 9 demonstrates our efforts on a 7x7 field of sensormotes with a 2m spacing. The grid displays the actualtrack of the evader in a solid line demarcated with 10sintervals in squares, as determined by GPS. Each star

1A movie of all runs is available athttp://webs.cs.berkeley.edu/nestdemo.mpg

Fig. 8. This sequence taken from a video of the live July 2003 demonstration shows a successful capture of the evader (foreground) bythe pursuer (background). This sequence spans 26 seconds.

shows the leader node that sent a packet to the movingpursuer after aggregating the detection data. We draw adashed line from the leader to the corresponding pointon the evader’s path when it makes the detection report.When the dashed line is short, it indicates a successful,low error detection reading. There are no reports whenthe evader leaves the playing field around time 100s.

The results also indicate a few noisy nodes. The pur-suer must filter out this noise in estimating the evader’sposition. For example, node (12,12) detects a spuriousreading at around 4 seconds. In analyzing this plot, wefound 4-5 spurious readings. Additionally, we manuallysquelched the output of nodes (4,10) and (4,12). Theirmagnetometers were not properly calibrated and wouldgenerate a false reading every few seconds. Just as inour original run, we found that a few nodes in everydeployment would not act properly when deployed; insuch situations, we needed to suppress a handful ofnodes from reporting. For larger or longer deployments,we foresee an automatic health monitoring service that,in its simplest form, reboots or powers down a nodewhen it behaves outside specified tolerances. As wediscuss in Section VIII, accurate debugging and networkanalysis tools are a necessity for large sensor networkdeployments.

VIII. D EPLOYMENT EXPERIENCES

Through the course of designing and implementingPEG, we faced various system issues, including systembreakage, packaging, in situ debugging, network pro-gramming, and system reconfiguration. In this section,

−2 0 2 4 6 8 10 12 14 16 18−2

0

2

4

6

8

10

12

14

(0,0) (2,0) (4,0) (6,0) (8,0) (10,0) (12,0)

(0,2) (2,2) (4,2) (6,2) (8,2) (10,2) (12,2)

(0,4) (2,4) (4,4) (6,4) (8,4) (10,4) (12,4)

(0,6) (2,6) (4,6) (6,6) (8,6) (10,6) (12,6)

(0,8) (2,8) (4,8) (6,8) (8,8) (10,8) (12,8)

(0,10) (2,10) (4,10) (6,10) (8,10) (10,10) (12,10)

(0,12) (2,12) (4,12) (6,12) (8,12) (10,12) (12,12)

0s

10s

20s 30s

40s

50s60s

70s

80s

90s

100s

110s

120s130s

140s

x physical position (meters)

y ph

ysic

al p

ositi

on (m

eter

s)

Fig. 9. Intruder tracking using PEG. Evader GPS position is shownas a solid line. Detection event leaders are shown as stars. The dottedlines link the leaders to the evader’s position at the time of detection.

we discuss the approach we took to cope with each ofthese issues. These implementation experiences apply tomany kinds of realistic outdoor sensor network applica-tions.

A. Breakage

In the course of deploying and operating PEG, wenoticed a moderate rate of breakage in terms of nodefailure, similar to the experience reported in other sensornetworking deployments [24]. Some of this is due to ourinexperience as packaging engineers. However, in the

course of disassembling the packaging, reprogramming,charging the battery, reassembling, and re-deploying, wenoticed a trend of a few percent of the nodes failing atrun time. Out of this experience came the maxim that“Every touch breaks.” This reinforces our design phi-losophy of maintaining soft state, loose consistency forinter-nodal coordinations, and rapid fail over in networktopology formation. Furthermore, the system services forin situ testing and development, as shown in Figure 3,are therefore sought to eliminateany need to physicallyhandle nodes. We believe that these system servicesare useful even when future sensor nodes become morerobust.

B. Packaging

A real-world sensor deployment must carefully con-sider node packaging, and we discovered that that pack-aging requirements for deployment are different fromthose for development. For development, the packagingshould expose access for convenient debugging, repro-gramming, and battery recharging. However, we did notproperly anticipate such need, and during development,we would frequently need to disassemble the packagingin order to fix broken components, reprogram the nodes,or recharge the batteries. If we had better foresightin our design, we would have designed the packagingto support reprogramming and recharging without fullpackage disassembly.

After deployment we discovered that the packagingwas interfering with the magnetometer. The piano wireantenna, battery, and metallic spring base all align themagnetic field in the proximity of the magnetometer,significantly reducing its sensitivity and overall rangeof detection. The design process should accommodatea series of revisions, because defects may only becomeapparent when the complete design is implemented anddeployed in the sensing environment.

C. Debugging

Debugging large sensor network applications atdeployment time is a challenging experience. Pre-deployment testing using simulations and controlled ex-periments over testbeds are extremely useful as theyallow us to extract information about the external andinternal states of each node. However, in a real deploy-ment, collecting state information can be difficult, espe-cially when the packaging is designed for deployment.For example, even if the EEPROM fully logs the tran-sient internal states of each node, correlating them in anetwork-wide temporal order can be difficult, especially

without time synchronization. In our deployment, we didnot have adequate time to explore this option.

Instead, we exploit a large antenna to snoop onnetwork traffic. This non-intrusive approach allows thecollection of as much external states of the network aspossible, does not affect the application, and enablesa direct communication with each of the node in thenetwork.

A set of services under the node management categoryin Figure 3 are implemented to address in situ debugging.Additionally, we place a version control number intoeach binary to ensure code compatibility across all thenodes in the network. We use a basic “ping” like serviceto verify that a node is up. The ping reply also reportsthe version control number of its code binary, allowingus to detect incompatible binaries. In addition, some ofthe basic primitives for node management such as nodereset, sleep, and active mode control are also supportedover wireless control.

The big antenna allows us to remotely control anddebug each node in the network. We implement a set ofmanagement scripts on a PC computer to invoke the sen-sor node management services to administrate the systemthrough the antenna. Packet traces are archived for off-line debugging and visualization of the entire systemto understand the global behavior, which is extremelyuseful in system tuning. Nodes can send packets withan ASCII text payload to act as a “printf” to signal theoccurrence of some critical debugging events in a humanreadable form.

For larger, real world deployments, we have sincedeveloped a multi-hop system management architec-ture [41] to subsume the role of the big antenna. Thislower layer can perform system health monitoring, re-mote control, and data logging; and, it integrates seam-lessly with a dispersed, higher power second tier tooptimize data gathering. We look forward to reportingon the success of this architecture for real deploymentsin future work.

D. Hierarchy of Programming and Reconfiguration

In sensor networks, the need for a form ofin situprogramming presents a new kind of requirement forremote configuration tools. Besides the common needfor wireless network-wide reprogramming, there is alsoa need to perform in situ protocol parameter tuning sinceanalytical analysis is often insufficient to accommodateenvironmental effects. For example, there are configura-tion options of the code that need to be decided at thetime of deployment, including the application’s sensing

policy, sensor calibrations, and communications param-eters that rely on the cell density. Furthermore, someof these configurations may need to be set on varyinggranularities, ranging from individual nodes, a select fewsubset of nodes, to the entire set of nodes en masse. Wehave implemented both the network reprogramming andconfig services as shown in Figure 3 to address theseneeds.

Our design supports wireless network programming,which is an alternative solution to installing new binariesover many nodes by hand. For a team of five peopleworking with one hundred nodes, manual programmingtakes two hours with an additional two hours to re-deploy the nodes in the field. This approach is clearlynot amenable to a rapid debug and test cycle.

Using network programming, nodes receive the binaryimage over the radio. By exploiting the shared wirelessmedium, many nodes can be reprogrammed simulta-neously and selectively. We anticipated using networkreprogramming for our deployment, but we could notdevelop a sufficiently reliable network reprogrammingmechanism for our purposes2. Given the problems weencountered at the time, the entire process would havetaken longer than individually reprogramming each node.

Interestingly, with a network service we call Config,the limitations of manually programming each node andour inability to use network reprogramming did not posea great hindrance in our deployment. We spend the ma-jority of our time tuning the algorithms to work properlyat scale in the environment. The Config service addressesthis issue efficiently and allows run-time adjustments ofthe internal states of each node. For example, Configallows us to selectively enable sections of the code,adjust parameters, modify calibration values, and adjustvariables at run time.

Config is a smart configuration system that takes theplace of a traditional approach to using a local config-uration file per node. Configuration values are declaredin the code with a specific configuration identifier, asshown in this example:

//!! Config 31 {uint16_t RFThreshold = 200;}

In this case, the RFThreshold parameter, with a defaultvalue of 200, is preprocessed with compilation toolsto convert it to be a member in a global Config datastructure. Config is tightly integrated with the scriptingenvironment in Matlab, allowing the large antenna tobe used for debugging. Therefore, it is easy to change

2Subsequent work has improved upon our initial foray [42].

configuration values for a subset of the nodes or all thenodes from a PC in run time.

When a user changes a node’s configuration value, thechange is automatically reflected in that node’s globalConfig data structure. And, the application is notifiedthrough an asynchronous event of the change to thedata value. Config also supports queries of the currentset of configuration values on each node. With a richconfiguration capability in place and a bit of creativeprogramming to utilize it, the resulting application isquite malleable, saving us a lot of time from installingnew code images.

IX. CONCLUSION

Designing and implementing PEG enables us to es-tablish relevant system design principles that are usefulto other sensor networking systems. Our whole-systemdesign analysis provides a clean process of problemdecomposition. It allows complexity to be placed atthe appropriate levels of the system to achieve overallsimplicity in system implementation. Simplicity is fur-ther achieved by exploiting environmental and physicalcharacteristics of the application at deployment time.Protocols should exploit soft state, loose consistency, andrapid failover when appropriate to cope with the lossywireless channel and the somewhat unreliable sensornetwork hardware platform. The system managementand debugging infrastructure should be well designedto anticipate the need of system reconfigurations atdeployment time.

Our system decomposition allows each of the sub-systems to be reusable by a wide variety of sensornetwork applications. The neighborhood abstraction andleader election mechanisms apply to any monitoringsystem requiring local data aggregation. The densityadaptive flooding mechanism avoids the broadcast stormproblem for other data dissemination protocols. Thelandmark routing subsystem is useful for any applicationwith moving entities. The network management anddebugging services are useful for deploying other sensornetworks. The data filter and robustness of the controlsystem design are applicable to other sensor networkapplications with embedded actuators.

We demonstrate a working system that not only mon-itors sensory data but also tracks and controls a highertier system to accomplish a cooperative task in realtime. The system assumes very little processing andcommunication requirements on the sensor tier. Further-more, throughout our design we exploit the physicalproperties of PEG to achieve a functional, simple design

that is robust to failures. We believe the same designphilosophy should be followed in building future sensingand actuating systems.

In the near future, we will deploy an order of magni-tude larger network to achieve many of the same goalsas this work. We will leverage the lessons from this workto establish a platform well suited for long lifetime andlarge scale remote reprogramming, re-parameterization,and system management. The overall goal of this rede-ployment is to focus on data gathering and methodicalsystem study. In this new deployment, we will be ableto introduce and measure greater variation: robot speed,node spacing, node topology, GPS resolution, sensingfidelity, and sensing period. This initial effort describedin this work has been invaluable for the experience, andwe hope to extend that with a breadth of experimentsthat describe in detail the behavior of the many facets ofthis kind of system and application.

ACKNOWLEDGMENTS

We’d like to thank everyone who worked on PEG, including:Phoebus Chen, Fred Jiang, Jaein Jong, Sukun Kim, Phil Levis,Neil Patel, Joe Polastre, Robert Szewczyk, Terrence Tong, Rob vonBehren, and Kamin Whitehouse. This work is funded in part by theDARPA NEST contract F33615-01-C-1895 and Intel Research.

REFERENCES

[1] D. Estrin, L. Girod, G. Pottie, and M. Srivastava, “Instrumentingthe world with wireless sensor networks,” inInternational Con-ference on Acoustics, Speech, and Signal Processing (ICASSP2001), 2001.

[2] G. Pottie and W. Kaiser, “Wireless integrated network sensors,”in Communications of the ACM, May 2000.

[3] T. Parsons, “Pursuit-evasion in a graph,” inTheory and Applica-tion of Graphs (Y. Alani and D.R. Lick, eds.). Springer-Verlag,1976, pp. 426–441.

[4] I. Suzuki and M. Yamashita, “Searching for a mobile intruderin a polygonal region,” inSIAM J. Comput., vol. 21, October1992, pp. 863–888.

[5] R. Vidal and S. Sastry, “Vision-based detection of autonomousvehicles for pursuit-evasion games,” inIFAC World Congresson Automatic Control, 2002.

[6] H. Pasula, S. Russel, M. Ostland, and Y. Ritov, “Tracking manyobjects with many sensors,” inIn Proceedings of IJCAI-99,1999.

[7] D. Reid, “An algorithm for tracking multiple targets,” inIEEETransactions on Automatic Control, vol. 24:6, 1979.

[8] J. Hespanha and M. Prandini, “Optimal pursuit under partialinformation,” in In Proceedings of the 10th MediterraneanConference on Control and Automation, July 2002.

[9] R. R. Brooks and P. Ramanthan, “Distributed target classifica-tion and tracking in sensor networks,” inProceedings of theIEEE, August 2003, pp. 1163–1171.

[10] J. Liu, J. Liu, J. Reich, P. Cheung, and F. Zhao, “Distributedgroup management for track initiation and maintenance in targetlocalization applications,” inProceedings of the 2nd Workshopon Information Processing in Sensor Networks (IPSN ’03),April 2003.

[11] F. Zhao, J. Liu, J. Liu, L. Guibas, and J. Reich, “Collaborativesignal and information processing: An information directedapproach,” inProceedings of the IEEE, 2003, pp. 91(8):1999–1209.

[12] B. Blum, P. Nagaraddi, A. Wood, T. Abdelzaher, S. Son, andJ. Stankovic, “An entity maintenance and connection servicefor sensor networks,” inThe First International Conference onMobile Systems, Applications, and Services (MOBISYS ‘03),California, May 2003., 2003.

[13] T. Abdelzaher, B. Blum, and et al., “Envirotrack: Towardsan environmental computing paradigm for distributed sensornetworks,” in IEEE International Conference on DistributedComputing Systems, March 2004.

[14] M. Welsh and G. Mainland, “Programming sensor net-works using abstract regions,” inIn Proceedings of the FirstUSENIX/ACM Symposium on Networked Systems Design andImplementation (NSDI’ 04), March 2004.

[15] J. Aslam, Z. Butler, F. Constantin, V. Crespi, G. Cybenko,and D. Rus, “Tracking a moving object with a binary sensornetwork,” in Proceedings of the First ACM Conference onEmbedded Networked Sensor Systems, 2003, pp. 150–161.

[16] K. Birman, “The process group approach to reliable distributedcomputing,” inCommuniation of the ACM, vol. 36(12), 1993,pp. 37–53.

[17] D. Cheriton, “Understanding the limitations of causally andtotally ordered communication,” inSOSP. ACM, December1993.

[18] K. Whitehouse, F. Chen, C. Karlof, A. Woo, and D. Culler,“Sensor field localization: A deployment and empirical analy-sis,” no. UCB//CSD-04-1349, April 2004.

[19] K. Whitehouse, C. Karlof, and D. Culler, “Getting radio signalstrength localization to actually work,” UC-Berkeley, Tech. Rep.UCB//CSD-04-1348, May 2004.

[20] J. Hill, R. Szewczyk, A. Woo, S. Hollar, D. Culler, and K. Pis-ter, “System architecture directions for networked sensors,” inProceedings of ACM ASPLOS IX, November 2000, pp. 93–104.

[21] K. Whitehouse, C. Sharp, E. Brewer, and D. Culler, “Hood: aneighborhood abstraction for sensor networks,” inProceedingsof ACM International Conference on Mobile Systems, Applica-tions, and Services (MobiSys ’04), June 2004.

[22] A. Cerpa, J. Elson, D. Estrin, L. Girod, M. Hamilton, andJ. Zhao, “Habitat monitoring: Application driver for wirelesscommunications technology,” inACM SIGCOMM Workshop onData Communications in Latin America and the Caribbean,April 2001.

[23] S. Madden, “The design and evaluation of a query process-ing architecture for sensor networks,” Ph.D. dissertation, UCBerkeley, 2003.

[24] R. Szewczyk, J. Polastre, A. Mainwaring, and D. Culler,“Lessons from a sensor netowkr expedition,” inProceedingsof the 1st European Workshop on Wireless Sensor Networks(EWSN 04), January 2004.

[25] D. Johnson and D. Maltz, “Dynamic source routing in ad hocwireless networks,” inMobile Computing. Kluwer AcademicPublishers, 1996, pp. 153–181.

[26] C. E. Perkins and E. M. Royer, “Ad hoc on-demand distance-vector (aodv) routing,” inProceedings of the 2nd IEEE Work-shop on Mobile Computing Systems and Applications, 1999.

[27] V. Park and M. Corson, “A highly adaptive distributed routingalgorithm for mobile wireless networks,” inProceedings of theIEEE INFOCOM ’97, April 1997.

[28] C. E. Perkins, B. Woolf, and S. R. Alpert, “Mobile ip designprinciples and practices,” January 1998.

[29] Q. Fang, J. Li, L. Guiba, and F. Zha, “Roamhba: maintaininggroup connectivity in sensor networks,” inProceedings of theThird International Symposium on Information Processing inSensor Networks, 2004, pp. 151–160.

[30] A. Arora, P. Dutta, S. Bapat, V. Kulathumani, H. Zhang,V. Naik, V. Mittal, H. Cao, M. Gouda, Y. Choi, T. Her-man, S. Kularni, U. Arumugam, M. Nesterenko, A. Vora, andM. Miyashita, “Line in the sand: A wireless sensor network fortarget detection, classification, and tracking,” inOSU-CISRC-12/03-TR71, 2003.

[31] P. Tsuchiya, “The landmark hierarchy, a new hierarchy forrouting in very large networks,” inSpecial Interest Group onData Communication (SIGCOMM), 1988, pp. 36–42.

[32] Y.-C. Tseng, S.-Y. Ni, Y.-S. Chen, and J.-P. Sheu, “The broad-cast storm problem in a mobile ad hoc network,”WirelessNetworks, vol. 8, no. 2/3, pp. 153–167, 2002.

[33] D. Ganesan, B. Krishnamachari, A. Woo, D. Culler, D. Estrin,and S. Wicker, “Complex behavior at scale: An experimentalstudy of low-power wireless sensor networks,” inTechnicalReport UCLA/CSD-TR 02-0013, February 2002.

[34] J. Zhao and R. Govindan, “Understanding Packet Delivery Per-formance in Dense Wireless Sensor Networks,” inProceedingsof the First ACM Conference on Embedded Networked SensorSystems. ACM Press, 2003, pp. 1–13.

[35] D. S. J. De Couto, D. Aguayo, J. Bicket, and R. Morris, “Ahigh-throughput path metric for multi-hop wireless routing,”in Proceedings of the 9th annual International Conference onMobile Computing and Networking. ACM Press, 2003, pp.134–146.

[36] W. J. Rugh,Linear System Theory, 2nd ed., ser. Informationand System Sciences Series. Upper Saddle River, New Jersey07458: Prentice Hall, 1996.

[37] P. Marti, G. Fohler, K. Ramamritham, , and J. M. Fuertes,“Jitter compensation for real-time control systems,” in22ndIEEE Real-Time Systems Symposium, London, December 2001.

[38] P. Marti, R. Villa, J. M. Fuertes, and G. Fohler, “Stability ofon-line compensated real-time scheduled control tasks.” inIFACConference on New Technologies for Computer Control, HongKong, November 2001.

[39] B. Ristic, S. Arulampalam, and N. Gordon,Beyond the KalmanFilter: Particle Filters for Tracking Applications. ArtechHouse, February 2004.

[40] P. Varaiya and P. Kumar,Stochastic Systems: Estimation, Iden-tification, and Adaptive Control, ser. Information and SystemSciences Series. Upper Saddle River, New Jersey 07458:Prentice Hall, 1986.

[41] G. Tolle and D. Culler, “Design of an application-cooperativemanagement system for wireless sensor networks,” inProceed-ings of the Second European Workshop on Wireless SensorNetworks (EWSN 05), January 2005.

[42] J. W. Hui and D. Culler, “The Dynamic Behavior of a DataDissemination Protocol for Network Programming at Scale,” inThe Second ACM Conference on Embedded Networked SensorSystems, 2004.