Mercury: A Wearable Sensor Network
Platform for High-fidelity Motion Analysis
Konrad Lorincz, Bor-rong Chen, Geoffrey Werner Challen,
Atanu Roy Chowdhury, and Matt Welsh
Harvard University, School of Engineering and Applied Sciences
Shyamal Patel and Paolo Bonato
Spaulding Rehabilitation Hospital, Boston, MA
November 5, 2009
Background: Parkinson’s Disease (PD)
Degenerative disorder that impairs motor skills

Cause: deficiency of dopamine due to degeneration of neurons.
Characteristic motor features:



Bradykinesia: Sluggish movements
Tremor
Dyskinesia: Involuntary movements
Clinical assessment


UPDRS clinical scale (0 to 4)
Performed manually by an observer
Key challenge: Long-term high-resolution
monitoring of patients’ motor functions
Konrad Lorincz - Harvard University
2
Existing Monitoring Solutions
How can we automatically monitor a patient’s motor function?
Wearable data-loggers and wired sensors

Bulky, cumbersome, not ideal for
routine home use
Not Suitable for long-term
use in the home
Vicon motion capture camera system

Extremely expensive ($50k+),
generally used only in lab settings
Konrad Lorincz - Harvard University
3
SHIMMER Wireless Sensor Platform
Tiny, wearable sensor node with:




MSP430+CC2420
Up to 2GB flash (MicroSD)
Triaxial accelerometer and gyroscope
Rechargeable LiPo battery – 250 mAh
http://shimmer-research.com
Approach





Patient wears 8-10 sensors on body segments
Continuous sensor data capture and logging
On-board feature extraction from raw signal
Transmission of features+signal to laptop
base station in home
Offline classification of data to UPDRS scores
Konrad Lorincz - Harvard University
4
Mercury Goals and Challenges
Internet
Enable long-term monitoring of patients in home settings

Target multi-day battery lifetimes: patient recharges sensors every
few days
Challenges





Very constrained battery due to small size and weight
High data rates: 100 Hz per channel * 6 channels/node
Wide variation in power consumption for sampling, storage,
communication
Need to yield clinically relevant data
Provide high data quality subject to severe resource
constraints
Konrad Lorincz - Harvard University
5
Energy Profile of the SHIMMER Node

uJ per second of data sampled or processed
Konrad Lorincz - Harvard University
6
Battery Lifetime Estimates
Reduce
data
quality
Duty-cycle sensors
when not moving
Naïve
approach
Konrad Lorincz - Harvard University
7
Energy-Saving Features in Mercury
Data reduction:


On-board computation of features from raw signals
Reduces bandwidth (and therefore energy) considerably
Activity filtering:

Avoid processing and storing data when sensor is not moving
Utility-driven data collection:

Download highest-quality data from sensors first
Tune node parameters:

Dynamically tune sampling, storage, and downloads to meet battery
lifetime target
Konrad Lorincz - Harvard University
8
Technique #1: On-board Feature Extraction
Raw
signal
Max peak-peak
RMS
Mean
Peak velocity
RMS of jerk
Konrad Lorincz - Harvard University
36,000 bytes
600 bytes
23 mJ to
transmit
1 mJ to compute
and transmit
9
Technique #2: Activity Filtering
Simple algorithm to detect sensor movement



Take peak-to-peak amplitude of accelerometer signal on each channel
If amplitude exceeds threshold, begin active period
Hysteresis to avoid short active periods (must be multiple of 30 sec.)
Energy savings during inactive periods



Active: Accelerometer, radio, gyro, feature computation, flash: 63 mJ/sec
Inactive: Accelerometer, radio: 6.5 mJ/sec
Nearly 10x energy reduction when sensor is not moving
Konrad Lorincz - Harvard University
10
Sensor Node Operation
Compute
features
Accelerometer
@ 100 Hz
Flash
Feature blocks
Sample blocks
Activity
filter
Radio
Gyroscope
@ 100 Hz
Drop
Konrad Lorincz - Harvard University
Base station
11
The Data Fidelity Challenge
Can’t continuously stream data from all nodes


Data rate exceeds radio channel capacity
Energy cost is prohibitive
Observation: Not all data is equally valuable


Many periods when the sensor is still
Arbitrary movements not associated with disease
We need a definition of data utility to drive downloads
Konrad Lorincz - Harvard University
12
Defining Data Utility
Walking
Walking
Sitting
Utility computed
from signal amplitude
Konrad Lorincz - Harvard University
13
Technique #3: Utility-Driven Data Collection
Flash
Feature blocks
Sample blocks
Didn’t download one of
the raw sample blocks
Radio
Utility 140
Priority queue
Utility 110
Base station
Konrad Lorincz - Harvard University
14
Technique #4: Energy Adaptation
Energy
debt
C
Nominal energy
schedule
Surplus
Battery
capacity
Energy profile
without
Disable gyro
adaptation
or
downloads
ρ = C/LTT
Enable
gyro/downloads
time
LTT
Lifetime
target
Konrad Lorincz - Harvard University
15
Mercury Policy Engine
Programmable interface for tuning network operation


Separates low-level mechanisms from policies
Policy engine tailored for a different set of clinical applications
Application-specific
code
Parkinson’s
Epilepsy
COPD
Policy engine
Node status
Node ID
Storage summary
Battery state
Konrad Lorincz - Harvard University
Sampling/storage
control
Download
manager
• Enable/disable gyro
• Enable/disable sample storage
• Set activity threshold
• etc.
16
Some Example Policies
Throttle downloads


Only download data from a node when there is energy surplus
Avoid downloading when radio link quality is poor (increased
retransmissions)
Throttle gyro


Disable gyro sensor when energy limited – saves 53 mJ/sec
Degrades data quality but saves considerable energy
Throttle storage


Don’t store raw samples to flash when energy limited – saves 2.6 mJ/sec
(Features are still computed and stored)
Throttle sampling


Don’t perform any sampling when energy limited – saves 59 mJ/sec
Effectively results in “blind spots” in data coverage
Konrad Lorincz - Harvard University
17
Evaluation
Impact of energy saving features on battery lifetime



Feature extraction
Activity filtering
Driver policies: Throttle downloads, gyro, storage
Data quality versus battery lifetime target

Define quality in terms of data coverage: Fraction of features or raw
samples downloaded to the base station.
What kind of latencies can we expect (features and raw samples)?



Various lifetime targets
Radio link conditions
Amount of activity
Konrad Lorincz - Harvard University
18
Impact of Energy-saving Features
Throttle
gyro
Energy
schedule
with 24-hour
lifetime target
Throttle
downloads
No
adaptation
Activity
filter
Konrad Lorincz - Harvard University
19
Coverage – Throttle Gyro Policy
Features
Increase in both
lifetime target and activity
degrades coverage
% Active
LTT
Samples
Konrad Lorincz - Harvard University
Max sample coverage
limited by channel
capacity
20
Also Discussed in the Paper
Evaluation of data coverage for a range of policies


Feature and sample coverage
Tradeoffs between lifetime and fidelity of data coverage
 full-coverage: acc and gyro data
 degraded-coverage: acc data only
Second Application: Epileptic Seizure Detection



Goal: Rapidly detect epileptic seizures
Approach: Download raw samples from all nodes when seizure suspected
Evaluation: coverage vs noise, true and false positive rates, detection
latency
Application Driver API

Narrow API which makes it easy to write driver policies
Konrad Lorincz - Harvard University
21
Collaboration with Spaulding Hospital
Mercury currently in use in several clinical studies


Parkinson’s Disease
 Tuning of deep brain stimulation parameters
 9 nodes: one each limb plus back (sensors: acc, gyro)
 4 patients: 7 sessions each, 4 hours per session
Epilepsy
 Just starting up (with Spaulding and Beth Israel Hospital)
 6 nodes: 4 on arms, 2 on legs (sensors: acc, gyro, EMG)
 2 patients: 1 week each in hospital
Home monitoring: Parkinson’s Disease


Goal: Continuously monitor several patients for 2 weeks each
Supported by The Michael J. Fox Foundation
Konrad Lorincz - Harvard University
22
Conclusions
Wireless sensors have great potential to assist with treatment of
neuromotor diseases, but face many challenges:


Managing data quality, limited energy and bandwidth
Adapting sensor behavior to meet clinical requirements
Mercury is a platform for managing a network of wearable sensors



Provides global control over data acquisition and sampling
Adaptation to resource constraints
Supports a wide range of clinical applications
konrad@eecs.harvard.edu
http://fiji.eecs.harvard.edu/Mercury
Konrad Lorincz - Harvard University
23