Development of a Deployable Platform for Collaborative

1
Development of a Deployable Platform for
Collaborative Acoustic Sensing

• Lewis Girod
• CENS Systems Lab
• girod_at_cs.ucla.edu

2
The Exciting World of Acoustic Sensing!
3
Proposed Woodpecker Application

• Local processing
• Search signal for characteristic sounds of
  woodpecker events
• Estimate 3-D DOA by phase comparison
• Share DOA info and detection time
• Distributed processing
• Match up observations on nodes based on timing,
  location, other parameters
• Cross-beam location estimation

4
Sounds fun, but first

• Automatic calibration of array location and
  orientation?

• Hardware?
• Support for time-synchronized sampling?
• Network primitives for coordination among groups
  of nodes?
• Automatic calibration of array location and
  orientation?
• Development tools
• Simulation tools, testbeds, visualization
• Deployment tools
• Control groups/individual nodes
• Health monitoring
• Diagnostic data
• Error logs

5
Location/Orientation Discovery via Acoustics

• Many positioning and ranging techniques
• GPS, compass, RF TOF, RSSI, acoustic TOF, sensor
  correlation
• Acoustics is an interesting choice for this
  platform
• Leverages existing hardware
• Does not depend on GPS (overhead foliage issues)
• Exercises many of the same requirements as our
  target applications.. being a distributed sensing
  application itself

6
Location Discovery System Components
Diagnostic
Application
Bcast Shell
Logrings
IP Routing
SinkTree
SysHealth
AppStatus
Physical Hardware
7
Drilling down
Diagnostic
Application
Bcast Shell
Logrings
IP Routing
SinkTree
SysHealth
AppStatus
Physical Hardware
8
Drilling down Hardware
Diagnostic
Application
Bcast Shell
Logrings
IP Routing
SinkTree
SysHealth
AppStatus
Physical Hardware
9
CENS Acoustic Platform
.

• Requirements
• Easy deployment
• Water-resistant box
• Self-contained except for mic array
• 1 day battery life
• Self-configuring
• Hardware Configuration
• Stargate board
• VXPocket440 4-channel sound card
• External antenna for 802.11
• Internal Li battery

10
Microphone Array

• 4 high-sensitivity condenser mics (RTI 1207A)
  preamps
• 8 cm square array with one microphone raised
• Wind filters for outdoor use

11
Drilling down Ranging
Diagnostic
Application
Bcast Shell
Logrings
IP Routing
SinkTree
SysHealth
AppStatus
Physical Hardware
12
Basic Acoustic Ranging

• S emits a coded acoustic signal with seed N at
  time T
• S floods a message M containing T, N
• R1 and R2 receive M and search for signal N after
  time T
• Lag in detection time yields distance estimate

R1
R2
S
M
M
M
13
System Considerations

• Coordination of independent emitters?
• Using different PN codes, acoustic collisions can
  be rejected
• Nondeterministic network latency?
• Buffered sampling interface extract samples
  post-facto
• Multihop network?
• Convert local sample index ? local CPU time ?
  timestamp in M
• Timestamp in M converted to local time after each
  hop
• Convert timestamp in M ? local sample index ?
  extract samples

R1
R2
M
S
M
3
M
2
1
M
14
Detection and Range Estimation

• Signal detection via matched filter constructed
  from PN code
• Observed signal S is convolved with the reference
  signal
• Peaks in resulting correlation function
  correspond to arrivals
• Earliest peak is most direct path

Observed
Reference
15
Phase Differences Across Channels
1/3
Estimate DOA by correlating phase differences
with array geometry?
2
4
16
DOA Estimation Algorithm

• Basic idea Each DOA corresponds to a specific
  set of phase offsets
• Hypothesize an angle
• Shift the correlations to match angle
• Multiply channels and accumulate
• Direction with greatest correlated energy is most
  likely DOA

x
225
270
Direction of wave
0
17
DOA Estimation Example

• Hypothesize incoming angle of 0
• Shift correlation functions to match
• Signals are uncorrelated.. Multiply and
  accumulate 0
• Store resulting point in angular correlation
  function

Shift
Shift
Shift
x
Shift
225
0
270
Direction of wave
0 90 180 270
0
18
DOA Estimation Example

• Hypothesize incoming angle of 45
• Shift correlation functions to match
• Significant correlation Multiply and accumulate
  gtgt 0

Shift
Shift
x
180
225
gtgt0
270
Direction of wave
0 90 180 270
0
19
3-D DOA Estimation

• 3-D DOA correlation results from real data
• Flats caused by quantization from fast
  time-domain shifting
• Zoom in on peak areas with frequency-domain
  phase shifts

210 Azimuth Angle
20 Zenith Angle
Secondaries
Azimuth Angle
Zenith Angle
20
Recombine to Select Single Ray

• Recombine original signals using fractional phase
  shifts in FD
• Correlate reference with recombined signal for
  higher SNR

21
Drilling down StateSync
Diagnostic
Application
Bcast Shell
Logrings
IP Routing
SinkTree
SysHealth
AppStatus
Physical Hardware
Under submission to Sensys
22
Challenges for Local Collaboration

• Short-term sharing of small data is simple
• My current light reading is X
• Process all readings from last epoch
• Larger size/lifetime needs
• More efficient reliability mechanism
• Stable group membership
• Support for late join / reboot
• Efficient maintenance of freshness
• The usual wireless issues
• Dynamic link quality
• No clearly defined topology

23
Target Application Properties
e.g. AR component on each node publishes 20
estimates. Mean key lifetime 30 min

• Reliable Delivery Desirable
• Greatly simplifies application design
• Large amount of long-lived data
• Data too large to refresh frequently
• Data changes gradually ? diffs
• Low update latency
• Updates propagate quickly, including source
  removal
• Service shared among applications
• Amortize costs over many concurrent applications
  each app adds own data

24
A Metric for Application Suitability

• Key Churn
• Distribution of key lifetimes
• Cost tradeoffs
• Short life
• periodic refresh
• Long life
• reliable transfer
• Experimental data
• Churn data for three applications
• Localization 1506 121
• Sink Tree 388 97
• Membership 538 36

25
StateSync Abstraction

• Publish/Subscribe interface
• Data published as key-value pairs
• Source node is implicit in the key
• No contention between publishers
• Published data broadcast for N hops
• Reliability/consistency model
• Data is transmitted reliably with a probabilistic
  latency bound
• All states presented for a particular node
  represent actual past published states
• No attempt to ensure consistency across sets of
  nodes

Ranging
Multilat
All ranges from N hops
Current local ranges
StateSync
26
Several Implementations

• To explore this abstraction, we implemented
  several variants
• SoftState Soft state refresh via flooding
• LogFlood Log-based representation, local retx,
  no routing
• LogTree Log, retx, topology control,
  distribution tree
• Ex. SoftState is a trivial implementation
• Floods the complete current state on change and
  periodically
• Times out entries after 3 misses
• Properties
• Low latency if complete state fits in a few
  packets
• High cost unless state is small or has high
  churn

27
Log-based Data Representation

• Growing log of sequenced ADD, DEL entries
• Periodically the active log is terminated and
  saved
• New active log appends to compressed version of
  last log
• Nodes maintain only active and most recently
  terminated logs
• Late joiner must transfer both to catch up
• Retransmission protocol
• Retx by sequence number
• LogFlood
• Proactively retransmit if new

Terminated Log
Active Log
28
LogTree

• Defines a stable topology
• Passive link quality estimation
• Reject bad or unidirectional links
• Prune redundant links
• DV algorithm to find N hop distribution tree
• Proactively transmit along tree
• ClusterSync
• StateSync for pruned 1-Hop neighborhood
• Publish routing tables and per-flow seqnos

29
Application Performance

• AR application, 13 nodes running on 802.11
  testbed for 3 hours
• Soft state is expensive
• LogTree is the cheapest
• Knee at 5 sec latency

30
Drilling down Diagnostic Support
Diagnostic
Application
Bcast Shell
Logrings
IP Routing
SinkTree
SysHealth
AppStatus
Physical Hardware
31
Diagnostics and Control

• Critical part of a deployment or field test
• Debug problems that arise only in field
• Weird sensor data
• Different network topology
• Hardware failures
• Command and control
• See internal state of complex system of
  components with limited network access
• Interactive diagnosis and configuration
• Manage nodes en masse
• Measure system performance
• Enormous amount of work to build
• But not in itself very publishable ?
• EmStar project accumulate all these pieces

32
Typical Questions in the Field (expletives
deleted)

• What is the topology?
• Need a way to collect and view the connectivity
  graph
• Walk with laptop, ping nearby nodes at link level
• Why doesnt that node connect?
• Log in and diagnose..
• Is the network working?
• Can it see neighbors?
• Is something else broken?
• Is the software working? Is anything crashing?
• Gather and summarize health information, critical
  logs

33
Topology Discovery and Visualization

• Multihop topology reporting
• Current prototype scheme uses LogFlood protocol
• Timers specially tuned, 1 packet/sec rate limit
• Each node publishes significant changes to
  neighbor state
• Gateway node pushes them to a visualizer

34
Diagnosing Deployments in EmStar

• System Health and Logging
• In-memory per-process log rings
• Runtime configurable levels
• Process health monitoring and auto-respawn
• Monitor memory usage, leak detection
• Log exit code and last message on crashes
• Extensible to more sophisticated diagnostics
• Shell-Accessible Control/Status Interfaces
• Interactive diagnosis from the shell
• Rapid fault isolation by querying status of
  system and application modules
• Remote access via rbsh
• Libraries make adding interfaces easy

cat /dev/link/mote0/status Root Device BMAC
Mote Stack /dev/ttyS0,mote0 Interface Addr
0.0.0.100 MTU 200 Stats packets_rx 1
packets_tx 1 bytes_rx 164 bytes_tx 164
errors_tx 0 errors_rx 0 Active 1 Promisc
0 POT 6
3 rbsh 12gt cd /dev/link/mote0 3 rbsh 12gt cat
status grep bytes_rx 3 rbsh
12gt Node0.0.0.100, reply to seqno12 Exit
status 0 bytes_rx 164 Node0.0.0.101, reply to
seqno12 Exit status 0 bytes_rx
342 Node0.0.0.102, reply to seqno12 Exit
status 0 bytes_rx 112 3 rbsh 13gt
35
Conclusions
Diagnostic
Application
Bcast Shell
Logrings
IP Routing
SinkTree
SysHealth
AppStatus
Physical Hardware
36
Conclusions

• The acoustic localization application
• Easier problem than woodpecker detection
• But motivates development of many common
  components
• Field experience motivates much development
• Without tools, very little progress can be very
  unpleasant
• Gradually discovering the right abstractions and
  layers?
• Reliable group communication?
• Ad-hoc, autonomous wireless ? topology is not
  defined
• Should the first step be to define one?

37
Continuing Work

• Acoustic Ranging
• Sometimes selects a secondary for DOA estimate
• Detectable because recombined signal matches late
• Possible fix subtract out secondary and try
  again
• Measure frequency stability of sampling cards
• If significant variance, need to detect and
  calibrate?
• Multilateration
• Current version in Matlab (work by Hanbiao Wang)
• Networking Components
• More measurement, application experience,
  restructuring
• Applications..
• Woodpecker detection and localization
• Some AR work should apply
• Fielded Testing and Experimentation
• Component performance measurements
• More experience with deployment tools

38

• Thank you!
• More information on EmStar.. http//cvs.cens.ucla.
  edu/emstar