Tracking Moving Targets in a Smart Sensor Network
Department of Electrical & Computer Engineering
and Computer Science
University of Cincinnati
Cincinnati, OH 45221-0030
Samir R. Das
Computer Science Department
SUNY at Stony Brook
Stony Brook, NY 11794-4400
Contact Email: email@example.com
Networks of small, densely distributed wireless sensor nodes are capable of solving a va-
riety of collaborative problems such as monitoring and surveillance. We develop a simple
algorithm that detects and tracks a moving target, and alerts sensor nodes along the projected
path of the target. The algorithm involves only simple computation and localizes communica-
tion only to the nodes in the vicinity of the target and its projected course. The algorithm is
evaluated on a small-scale testbed of Berkeley motes using a light source as the moving target.
The performance results are presented emphasizing the accuracy of the technique, along with
a discussion about our experience in using such a platform for target tracking experiments.
Rapid advances in miniaturization in computing and sensor technologies and advent of low-power
short-range radios recently have given rise to strong interest in smart sensor networks [8, 7]. The
idea is to be bring together sensor nodes with on-board processing capability and radio interface
into a large network to enable them to process higher level sensing tasks in a co-operative fash-
ion. Several new design themes have emerged for such networks. For example, the network must
be fully self-configuring and highly fault-tolerant as the sensors may be deployed in an “ad hoc”
fashion. The network must minimize battery power usage; this enables untethered and unattended
operations for an extended time. A corollary of the latter property is that the system must lever-
age data processing and decision making ability inside the network as much as possible, instead
of shipping the data to a central controller to make decisions. This is because with current day
technology, the power budget for communication is many times more than that for computation.
An emerging application area for smart sensor networks is intelligent surveillance or monitor-
ing. Sensors are distributed, likely randomly, in a geographic area to be monitored. The goal is to
track and predict the movement of an appropriate target and alert the sensors which are close to
the predicted path of the target. The target can be a moving vehicle, for example, or can be a phe-
nomenon such as an approaching fire. It is assumed that each individual sensor node is equipped
with appropriate sensory device(s) to be able to detect the target as well as to estimate its distance
based on the sensed data. The sensors that are triggered by the target collaborate to localize the
target in the physical space to predict its course . Then the sensor nodes that lie close to the
predicted course of the target are alerted. This alert is meant to serve as a trigger for these nodes
to activate additional on-board sensors. For example, these additional sensors may be of a differ-
ent modality (e.g., alerts coming from heat sensors activating vibration sensors) that are ordinarily
turned off or not sampled to conserve power. The alert can also serve as a trigger to actuate certain
on-board devices, depending on the capability of the nodes and the application.
The goal of this paper is to develop techniques for the above moving target tracking problem
and report our experience in testing them in a live low-cost sensor network testbed using Berkeley
motes . Variations of these motes have been used in several experimental testbeds recently.
See, for example, [6, 14, 9, 16]. We will demonstrate the feasibility of our approach. We will also
discuss performance results, and several practical problems a designer/implementor must be aware
The paper is organized as follows. In the next section we describe the hardware and software
architecture of the sensor nodes used. The tracking algorithm is described in Section 3, and exper-
imental evaluation is reported in Section 4. In Section 5, we discuss the problems we faced in our
experiments and some ways to alleviate them. We conclude in Section 6.
2 Sensor Network Testbed
Our testbed comprises of 17 Berkeley motes  based on the MICA platform and manufactured
by Crossbow technology . For sake of completeness, we briefly review the hardware and soft-
ware architecture of these motes.
2.1 Hardware Overview
In order to create a low-power system, MICA platform is based on a single central microcontroller
that performs all sensing, communication and computation tasks. MICA motes use ATmega 128L
processor by Atmel , that is driven by a 8 MHz external crystal and has a 8-bit data bus. It
has 128 KB of program memory and 4 KB of data SRAM. There is a 10-bit internal ADC that is
directly connected to the sensors. Hence a 10 bit reading is obtained from the sensors in the range
0-1023. This will later be used to measure sensor signal strength.
The RF module consists of an RF Monolithics 916.50 MHz transceiver (TR1000) . It can
be externally controlled, through a potentiometer, to have a communication radius ranging from a
few inches to tens of yards, and can operate at data rates up to 115 kbps. A key characteristic of
the radio is that it only consumes 12 mA while transmitting and 5 mA while receiving. An antenna
for the radio has been integrated into the surface of the printed circuit board and connecting an
external antenna is optional. The system is designed to operate off a pair of AA batteries.
The medium access protocol used is a variant of the Carrier Sense Multiple Access (CSMA)
protocol . There is a random delay before the transmission of every packet. If the channel is
busy, the node backs-off for a random amount of time. During backoff, the radio is powered off
to save energy and no communication is possible during this period. This MAC protocol does not
have maximum number of backoffs, and keeps trying until a clear channel is found.
The I/O subsystem consists of a 51-pin expansion connector. It helps in interfacing the mi-
crocontroller with the sensing board. This connector is also used to program the microcontroller
by connecting it to the programming board, which in turn is connected to the parallel port of the
PC. The connector also provides a serial port interface to communicate with the MICA mote and
hence can be used to transfer data to PC and debugging. Three LEDs present on the board act as
actuators that can be controlled through software and act as a user interface.
2.2 Software Architecture
The key requirements of an operating system that run on resource-constrained sensor nodes are (i)
smallmemory footprint, and (ii) effectivemanagement of hardware in terms of power consumption
and processing time.
MICA motes run on an event-based operating system, called TinyOS . TinyOS fits in 178
bytes of memory. It manipulates the hardware directly and there is no kernel layer. To avoid the
overhead associated with context switch and process management, only one process can be active
in the system at one time. There is no dynamic memory allocation and the memory is allocated
at compile time. The TinyOS code and applications are compiled together and run in a single
linear address space. This reduces the memory management overhead. TinyOS is divided into a
collection of software components. The complete system software consists of a scheduler and an
interconnection of these components. An application may consist of a number of layers of these
componenets stacked on top of each other. There are three types of components:
? Hardware Abstraction Components: These components directly map to a physical device
(such as LEDs, UART, ADC) and are used to manipulate them.
? Synthetic Hardware Components: These components simulate the behavior of hardware, in
case the hardware is absent in the mote.
? High Level Components: These components perform various data manipulations and trans-
formations, such as a routing algorithm or any other application.
TinyOS provides two levels of scheduling - Events and Tasks. This helps to do all the pro-
cessing in real-time. Events are synchronous in that they are serviced to completion as soon as
they occur. This includes interrupts from the hardware. Events cannot be preempted. Tasks are
asynchronous and involve time-consuming computations. Tasks are managed by a scheduler that
schedules these tasks when no event is to be processed. Events can preempt a task.
For communication, a fixed size of 38-byte packets are used in TinyOS, with 30 bytes of pay-
load. Message header includes a 16-bit CRC error checking. A mote is uniquely identified by a
16-bit ID that is assigned while uploading the application code to the mote. Each message contains
the destination mote ID. Two special IDs - 0xffff and 0x7e - are reserved for broadcast and UART,
respectively. A message destined for UART is sent to the serial port.
A message-based model called Active Messages  is used by MICA motes to communicate
with each other. Each message contains the name of a user-levelhandler to be invoked on the target
mote, and a data payload that is passed as arguments. If no message handler is intended for the
message, the message is discarded without further processing.
3 Tracking Moving Targets
We assume that the sensor nodes are scattered randomly in a geographical region. Each node is
aware of its location. Location information can be gathered using an on-board GPS receiver. Ab-
solute location information is, however, not needed. It is sufficient for the nodes to know their
location with respect to a common reference point. Many localizing techniques can be used with
varying degree of hardware complexity and accuracy. See, for example, [16, 5]. The sensor nodes
are stationary in our model; this makes the localization problem somewhat simpler. Since the work
presented here is not dependent on any particular localization method used, we do not emphasize
any particular technique. In the experiments reported, we have directly encoded the location infor-
mation into the sensor nodes to eliminate the possibility of any localization error.
The sensors must be capable of estimating the distance of the target to be tracked from the
sensor readings. It is assumed that the sensor has already learned the sensor reading to distance
mapping. We conducted a separate set of experiments to determine this mapping and encoded the
mapping directly as a table in the application component.
Tracking a target involves three distinct steps:
1. Detecting the presence of the target.
2. Determining the direction of motion of the target.
Figure 1: Three distance estimates
location coordinates result in three circles. Two straight lines are drawn through the points of
intersection of two pairs of such circles. The target is localized at the intersection (?) of these two
?, respectively, with known
3. Alerting appropriate nodes in the network.
These steps are discussed in detail in the following subsections.
Each node periodically (every 1 sec in our experiments) polls its sensor module to detect the
presence of any target to be tracked. Sensor reading above a particular threshold indicates the
presence of a target in the vicinity. As soon as this threshold is crossed, a TargetDetected message
is broadcast by the node. Each TargetDetected message contains the location of the originating
node and its distance from the target, as determined from the sensor reading. When this message is
received by a neighboring node, it stores the coordinates of the originator and the target’s distance
from the originator in a table. Table entries expire after a timeout (4 sec in our experiments) unless
The next step is estimating the location of the target. A minimum of three nodes sensing the target
are needed to apply the commonly used triangulation method . See Figure 1 for an explanation
of how we used it. When a node that has already detected the target hears two additional Target-
Detected messages from two different neighbors, it computes a location estimate via triangulation.
Note that any node that hears three TargetDetected messages from three different neighbors can
estimate the location of the target. However, we limit this computation only to the nodes that