Transcript ppt - Coventry University

VoxNet: An Interactive,
Rapidly Deployable
Acoustic Monitoring Platform
Michael Allen¹, Lewis Girod², Ryan Newton², Samuel Madden²,
Travis Collier³, Daniel Blumstein³, Deborah Estrin³
¹Coventry University ²CSAIL, MIT ³CENS, UCLA
Applications and Challenges of
Distributed Acoustic Sensing
Has traditional WSN
complexities, in addition:
 High data rate = no
streaming to sink
 Forces local, in network
processing
VoxNet: integrated hardware and software platform
for distributed acoustic sensing
* Distributed processing properties
Captures,
* Developintegrates
applications previous
using a high experience
level language in acoustic
* Easily push new applications into the network
sensing
networks
Without sacrificing performance
Audio
Input

Detect
Sensor Node
Buffer
>3sec?
sync4
N
Server Side
Send AML
Output
Run Local
AML DOA
Y
Server Side
AML DOA
Event
association


2008/23/4
IPSN/SPOTS '08, St. Louis, MO
Send Raw
Data
Network Operators
Sensor side
Server side
2
How we got to VoxNet
SenSys 2006 (Girod et al)
Acoustic sensing Platform
IPSN 2007 (Ali et al)
Marmot localization application
Wavescope: signal-oriented
stream processing @ MIT
VoxNet
2008/23/4
IPSN/SPOTS '08, St. Louis, MO
3
VoxNet architecture
Off-line operation and storage
On-line operation
Storage Server
Mesh Network of Deployed Nodes
Gateway
Internet or
Sneakernet
Compute Server
In-field PDA
2008/23/4
Control Console
IPSN/SPOTS '08, St. Louis, MO
4
Roadmap

VoxNet platform
How it’s used
 How it’s programmed


Performance results
Network latency
 Runtime dynamics



Ongoing work
Conclusions
2008/23/4
IPSN/SPOTS '08, St. Louis, MO
5
Current VoxNet node: ENSBox V2

Based on Acoustic ENSBox prototype




Low power supervisor



4 channel mic. array at 48KHz, 802.11b
Linux, 400 MHz ARM/64MB/8GB
Smaller form factor, Internal battery
Always-on mote for duty cycling
Example: ~5 days @ dawn/dusk sampling
Rapidly deployable!



Field tested over several months
…in the rainforest (Chajul, Mexico)
…and the mountains (Gothic, CO)
With thanks to Travis Collier
2008/23/4
IPSN/SPOTS '08, St. Louis, MO
6
VoxNet on-line usage model
// acquire data from source, assign to four streams
(ch1, ch2 ch3, ch4) = VoxNetAudio(44100)
// calculate energy
freq = fft(hanning(rewindow(ch1, 32)))
bpfiltered = bandpass(freq, 2500, 4500)
energy = calcEnergy(bpfiltered)
Node-side part
Write
program
Optimizing
compiler
Sink-side part
Development cycle
happens in-field,
interactively
Run program
2008/23/4
IPSN/SPOTS '08, St. Louis, MO
Disseminate
to nodes
7
Programming VoxNet

Programming language: Wavescript




User writes a script connecting operators


High level, stream-oriented macroprogramming language
Compiles down to a directed, graph of communicating ‘stream operators’
which data flow through (source to endpoint)
Operates on stored OR streaming data
Writes both node side + sink side separately
User decides where processing occurs (node, sink)

Explicit, not automated processing partitioning
Source
Source
Endpoint
Source
2008/23/4
IPSN/SPOTS '08, St. Louis, MO
8
Example – energy calculation
ch1
VoxNetAudio
rewindow
hanning
fft
// acquire data from source, assign to four streams
(ch1, ch2 ch3, ch4) = VoxNetAudio(44100)
// window ch1 data stream into 32 sample chunks,
// passing through hanning then fft operators
freq = fft(hanning(rewindow(ch1, 32)))
// apply bandpass filter to freq
bpfiltered = bandpass(freq, 2500, 4500)
// calculate energy in bandpassed data
energy = calcEnergy(bpfiltered)
2008/23/4
IPSN/SPOTS '08, St. Louis, MO
9
Splitting up a logical program
freq
toNet(“frequencies”)
fromNet(“frequencies”)
send(“frequencies”)
arrived(“frequencies”)
bandpass
// acquire data from source, assign to four streams
(ch1, ch2 ch3, ch4) = VoxNetAudio(44100)
freq = fft(hanning(rewindow(ch1, 32)))
Node
//send data to sink
toNet(“frequencies”,freq)
// receive data from node stream
freq2 = fromNet(“frequencies”)
// apply bandpass filter to freq
bpfiltered = bandpass(freq2, 2500, 4500)
Sink
// calculate energy in bandpassed data
energy = calcEnergy(bpfiltered)
2008/23/4
IPSN/SPOTS '08, St. Louis, MO
10
Roadmap

VoxNet platform
How it’s used
 How it’s programmed


Validating VoxNet
Network latency
 Runtime dynamics



Ongoing work
Conclusions
2008/23/4
IPSN/SPOTS '08, St. Louis, MO
11
Validating VoxNet

Implementation of indicative application


Resource usage


Marmot localization (from IPSN ‘07)
Hand coded C vs. high level Wavescope
Network trade-off

2008/23/4
Process locally or send raw data to sink?
IPSN/SPOTS '08, St. Louis, MO
12
Example VoxNet application

Detect and determine location of marmots
Crossing of DoA estimates
 Obtain results on-line (scientist interaction)

X
Send 32KB
per node,
per detection
Event detection
DoA processing and
position estimation
NODES
2008/23/4
SINK
IPSN/SPOTS '08, St. Louis, MO
13
Hand-coded C vs. Wavescript
100%
EVENT DETECTOR
DATA ACQUISITION
‘SPILL TO DISK’
30% less CPU
Hand-coded C
2008/23/4
Extra resources mean that data can be
archived to disk as well as processed
(‘spill to disk’, where local stream is
pushed to storage co-processor)
Wavescript
IPSN/SPOTS '08, St. Louis, MO
14
Detection data transmission latency

Deployed network in Gothic, CO



Request all nodes to transmit data
simultaneously
Emulates the ‘worst case’ when all
nodes detect the acoustic event
Measure latency to transmit
raw detection or processed data
(32KB vs. 800B/node)



2008/23/4
Gathered single and multi-hop data
Up to three hops
Used single hop 800B data to help
predict missing 800B multi-hop data
IPSN/SPOTS '08, St. Louis, MO
15
Detection data transfer latency
12
1 HOP
2 HOPS
3 HOPS
Network latency will become a problem
if scientist wants results in <5 seconds
(otherwise animal might move position)
2008/23/4
IPSN/SPOTS '08, St. Louis, MO
16
Processing trade-off

Sending raw data to sink
DoA processing takes a short time (0.04s)
 Sending data takes a long time
(32KB, up to 12s in expt.)


Sending processed data to sink
DoA processing takes a long time (~2.2s)
 Sending data takes a short time (800B, <1s)


Which is best to do to reduce overall position
estimation latency?
2008/23/4
IPSN/SPOTS '08, St. Louis, MO
17
Local vs. sink processing trade-off
NETWORK LATENCY
AML PROCESSING TIME
Process locally, send 800B
Send raw data, process at sink
As hops from sink increases, benefit of
processing DoA locally is clearly seen
DoA processing
2008/23/4
IPSN/SPOTS '08, St. Louis, MO
18
Applying the trade-off at runtime

Aim: process raw data locally when possible


Node has limited buffer space for data samples
Event detection can happen faster than real-time, so can catch up
Sink
Node
N
Buffer
>3sec?
Y

Send Raw
Data
x
AML DOA
0.04s
Merge
AML DOA
2.2s Send AML
Output
y
Wavescript makes this easy to implement
Trivial, natural to split and merge multiple streams
 Same on-node and sink DoA implementations

2008/23/4
IPSN/SPOTS '08, St. Louis, MO
19
Roadmap

VoxNet platform
How it’s used
 How it’s programmed


Performance results
Network latency
 Runtime dynamics



Ongoing work
Conclusions
2008/23/4
IPSN/SPOTS '08, St. Louis, MO
20
Ongoing work

VoxNet Platform Development
NSF Funded UCLA/MIT collaboration (2008-2010)
 Aiming for 10x improvement on lifetime
 Make platform smaller, lighter, cheaper


Develop VoxNet application portfolio further
Add classification, census to bioacoustics apps.
 New applications from different domains:
Increases generality, validates applicability


Ongoing development of Wavescript compiler
2008/23/4
IPSN/SPOTS '08, St. Louis, MO
21
Conclusions

VoxNet hardware is easy to deploy


Wavescript simplifies development


Allows on-line development in the field
Provides comparable operating performance


Experience is invaluable in this respect
Despite being high level language
Easy to implement network dynamics

2008/23/4
Such as local processing adaptation
IPSN/SPOTS '08, St. Louis, MO
22
2008/23/4
IPSN/SPOTS '08, St. Louis, MO
23
The ENSBox platform solves
lots of problems, but…

Algorithm is still difficult to implement
Must code in C, lacks safety features
 Want convenient networking primitives
 Hard to debug, hard to choose parameters


Desired features
Visibility in the field
 Convenient way to install code
 Interactive use in the field


 Motivation for Wavescope
2008/23/4
IPSN/SPOTS '08, St. Louis, MO
24
What is Wavescope?
Streaming
Databases
Borealis
Stanford STREAM
TelegraphCQ
Coral8, StreamBase
Ptolemy
StreamIT
GnuRadio
Simulink
Dataflow
Languages
ProfileDetector
<t1,t2,emit>
+



Audio0
<audio>
Audio1
<audio>
Audio2
<audio>
Audio3
<audio>
sync
Idea: High performance dataflow system,
but with semantics similar to stream
databases
Safe, powerful, optimizable language
Support for asynchronous, dynamic,
unreliable sensor net environment
IPSN/SPOTS '08, St. Louis, MO
2008/23/4
<w1,w2,w3,w4>
Initial Results:
• 1000x faster than
existing stream db’s;
• Similar performance to
hand-coded C;
• Better support for task
dynamics than SDF
25
Wavescope Objectives

Interactive “query” model
Concurrent queries installed in node engine
 UI tools provide visibility into query progress


Integration between backend and sensors
Single program is split across both realms
 Operates on stored and streaming data


Safe, fast, highly optimizable language
High rate isochronous data, dynamic data flow
 Single language with modern properties

2008/23/4
IPSN/SPOTS '08, St. Louis, MO
26
Girod, et. al., CIDR 2007
Wavescript



Functional language with mutation
Strict, static typing with type inference
Partial evaluation at compile time


“meta-program” constructs data flow graph
Why a new language?
Expressive for this class of applications
 Optimizations

2008/23/4
27
Newton, et. al., in submission to PLDI 2008
IPSN/SPOTS '08, St. Louis, MO
Contributions

Developed platform capable of rapid deployment in
realistic environments


High level macroprogramming interface



Platform = Hardware + software
Compiles into a high performance distributed application
Abstracts the user from network details
Defined an interactive usage model


2008/23/4
Run-time installable programs
Run same program over live or stored data
IPSN/SPOTS '08, St. Louis, MO
28
Conclusions:
VoxNet

First deployment, platform using Wavescope approach on
embedded hardware


Improves on previous work





Deployed, validated with motivating application
Less resource overhead
On-line interaction
Data archival
Dynamically adjust processing boundaries
Built over solid, deployed, software framework (EmStar)


2008/23/4
Less emphasis on debugging visibility
EmStar validated through application experience, deployment and
iterative development over several years
IPSN/SPOTS '08, St. Louis, MO
29
Conclusions:
Motivations and challenges

Distributed acoustic sensing is ongoing



A variety of motivating domains and applications



High data rate sensing is a challenge in WSNs
In-network processing/data reduction is vital
Scientific, military, smart office
Event detection, localization, classification
A need for flexible, capable, general acoustic sensing platforms





Applications are hard, solutions need iteration
Significant expense, effort is always expended in deployment
Suitable high level programming abstraction for non-experts
Highly optimized for embedded platforms
Interactive - react to unforeseen situations
We believe VoxNet meets these needs
2008/23/4
IPSN/SPOTS '08, St. Louis, MO
30
Here’s how

Interactive programming allows operational
adjustments in the field



Programming environment allows abstraction of
networking concerns (as far as possible)
Platform architecture avoids problems of badly
configured applications


Make most of time present in field
Record full data stream, replay data offline
Accurate self-localization removes need for manual
surveying*

Deployment is always harder than you remember
*not a direct contribution of VoxNet
2008/23/4
IPSN/SPOTS '08, St. Louis, MO
31
Library: Spill to disk

Save full data stream locally (on gumstix storage server)



Regardless of current on-line processing
User can spill whatever data they require to named local
stream
Multiple uses for disk archiving


Process data in the field, after the fact
Off-line archival, indexing, annotation, sharing
Chan 1
Data Acq.
Chan 2
+
Chan 3 Time sync
Chan 4 (slauson)
2008/23/4
Raw data stream
Application (slauson)
Spill to disk (gumstix)
IPSN/SPOTS '08, St. Louis, MO
32
What’s new?


First embedded Wavescope deployment
Provides on-line and off-line operation


Safe, high level macro-programming environment



Record all data or last hour’s data for reprocessing in the field
Single Wavescript program is partitioned and distributed
Heterogeneous, multi-hop wireless network
Efficiency improvements (CPU, memory)
2008/23/4
IPSN/SPOTS '08, St. Louis, MO
33
Backup: Named Network Streams
// Send side:
ToNet(“MyStream”, S);
// Receive side:
R = FromNet(“MyStream”);


Default stream semantics: reliable message delivery,
with bounded send buffer and head drop
Implemented in Wavescript and C via Foreign
Function Interface
2008/23/4
IPSN/SPOTS '08, St. Louis, MO
34
Backup: Streams in Wavescript
// Sensor side:
(sendback,runlocal) = switch(Detections,
fun (x) SensorBufferTimeRemaining() < 3.0);
ToNet(“AMLStream”, AML(runlocal));
ToNet(“RawStream”, sendback);
// Server
AMLStream
RawStream
AllAMLs =


side:
= FromNet(“AMLStream”);
= FromNet(“RawStream”);
merge(AMLStream, AML(RawStream));
Note: switch is simple to implement in Wavescript.
Related work: VanGo
2008/23/4
IPSN/SPOTS '08, St. Louis, MO
35
Backup: Visualisation


Visualiser allows scientist to ‘subscribe’ to any network
stream and visualise it
Future work – automatic marshalling, data types
2008/23/4
IPSN/SPOTS '08, St. Louis, MO
36
Backup: One-hop data transfer
2008/23/4
IPSN/SPOTS '08, St. Louis, MO
37
Back up: VoxNet node






Four channel 48KHz audio, 802.11b network,
internal battery (5-10hr)
400MHz processor, 64MB RAM
Linux based OS, with EmStar on top
Targeted at science applications
A standard acoustic platform
Rapidly deployable:


2008/23/4
Attended
short-lived deployments
IPSN/SPOTS '08, St. Louis, MO
38
Back up: VoxNet node

Self-calibration/localization
Acoustic time of flight ranging (~75m)
 Direction of arrival
 Multilateration algorithm for
position/orientation estimation
 Take advantage of capabilities required
for acoustic sensing


Global time over network (10us)
5cm 2D pos, 1.5 deg. orientation error
in 80mx50m outdoor environment
2008/23/4
IPSN/SPOTS '08, St. Louis, MO
39
What is VoxNet?


Integrated hardware and software platform for
distributed acoustic sensing
Captures previous experience in deploying
acoustic sensing networks
Top level Wavescript application
Node-side
+
Sink-side
EmStar drivers
Networked streams
EmStar drivers
Control console
Networked streams
MH Routing
App. Dissemination
MH Routing Data archival
Self-localization Time sync
Data acquisition
Hardware
2008/23/4
IPSN/SPOTS '08, St. Louis, MO
Visualization
App. Compilation
40
Distributed Acoustic Sensing is hard
Goals
 Event detection
 Target localization
 Target tracking
 Target classification
 Signal enhancement
Domains



Scientific research
Smart offices
Military
2008/23/4
Challenges
 Deployment
 Self-localization
 Time synchronization
 Programming model
 Network communication
 Operating faults
 Wide-band signals
 Channel noise
 Processing capability
 Real-time operation
IPSN/SPOTS '08, St. Louis, MO
41
VoxNet network support

Support flow of Wavescript streams between nodes


Publish/subscribe named streams (“control”, “data”)


Sits below Wavescope application
Default network stream semantics:



In our case, sink is endpoint for programs
Reliable message delivery
Bounded send buffer, head drop
Assumes IP connectivity (over multiple hops)

2008/23/4
User space implementation of Dynamic Source Routing
IPSN/SPOTS '08, St. Louis, MO
42
VoxNet node software stack
Wavescript application
Node-side
Sink-side
Drivers
Drivers
Networked streams
MH Routing
Control console
Networked streams
Data archival
MH Routing
Self-localization
Time sync
Data acquisition
App. Dissemination
Visualization
Hardware
2008/23/4
App. Compilation
IPSN/SPOTS '08, St. Louis, MO
43
Networked streams

Special network operators allow logical streams
to flow over network toward endpoint (sink)
Publish/subscribe mechanism
 Underlying C implementation


Default network stream semantics:
Reliable message delivery
 Bounded send buffer, head drop


Assumes multi-hop IP connectivity

2008/23/4
Used implementation of Dynamic Source Routing
IPSN/SPOTS '08, St. Louis, MO
44