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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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