1. 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
Shyamal Patel and Paolo Bonato
November 5, 2009
Harvard University, School of Engineering and Applied Sciences
Spaulding Rehabilitation Hospital, Boston, MA

2. 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

3. 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
Vicon motion capture camera system
Extremely expensive ($50k+), generally used only in lab settings
Not Suitable for long-term
use in the home
Konrad Lorincz - Harvard University

4. 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
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

5. 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

6. Energy Profile of the SHIMMER Node
uJ per second of data sampled or processed
Konrad Lorincz - Harvard University
Konrad Lorincz - Harvard University

7. Battery Lifetime Estimates
Reduce data
quality
Duty-cycle sensors when not moving
Naïve approach
Konrad Lorincz - Harvard University

8. 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

9. Technique #1: On-board Feature Extraction
Raw signal
Max peak-peak
RMS
Mean
Peak velocity
RMS of jerk
Emphasize compute and send
36,000 bytes
600 bytes
23 mJ to transmit
1 mJ to compute and transmit
Konrad Lorincz - Harvard University

10. 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

11. Sensor Node Operation Compute features Flash Activity filter Radio
100 Hz
Compute features
Flash
Feature blocks
Gyroscope
@ 100 Hz
Sample blocks
Activity filter
Radio
Drop
Base station
Konrad Lorincz - Harvard University

12. 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

13. Utility computed from signal amplitude
Defining Data Utility
Walking
Walking
Sitting
Utility computed from signal amplitude
Konrad Lorincz - Harvard University

14. 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

15. Technique #4: Energy Adaptation
Energy debt C
Nominal energy schedule
Battery
capacity
Surplus
Energy profile without adaptation
Disable gyro or downloads
ρ = C/LTT
Enable gyro/downloads
time
LTT
Lifetime target
Konrad Lorincz - Harvard University

16. 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
Sampling/storage control
Download manager
Node ID
Storage summary
Battery state
Enable/disable gyro
Enable/disable sample storage
Set activity threshold
etc.
Konrad Lorincz - Harvard University

17. Some Example Policies Throttle downloads Throttle gyro
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

18. 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

19. Impact of Energy-saving Features
Throttle gyro
Energy schedule with 24-hour lifetime target
Throttle downloads
No adaptation
Activity filter
Konrad Lorincz - Harvard University

20. Coverage – Throttle Gyro Policy
Features
Increase in both lifetime target and activity
degrades coverage
% Active
LTT
Max sample coverage
limited by channel capacity
Samples
Konrad Lorincz - Harvard University

21. 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

22. 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

23. konrad@eecs.harvard.edu http://fiji.eecs.harvard.edu/Mercury
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 Lorincz - Harvard University