Mercury A Wearable Sensor Network Platform for High-fidelity

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 n Cause: deficiency of dopamine due to degeneration of neurons. Characteristic motor features: n n n Bradykinesia: Sluggish movements Tremor Dyskinesia: Involuntary movements Clinical assessment n n 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 n Bulky, cumbersome, not ideal for routine home use Not Suitable for long-term use in the home Vicon motion capture camera system n Extremely expensive ($50 k+), generally used only in lab settings Konrad Lorincz - Harvard University 3

SHIMMER Wireless Sensor Platform Tiny, wearable sensor node with: n n MSP 430+CC 2420 Up to 2 GB flash (Micro. SD) Triaxial accelerometer and gyroscope Rechargeable Li. Po battery – 250 m. Ah http: //shimmer-research. com Approach n n n 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 n Target multi-day battery lifetimes: patient recharges sensors every few days Challenges n n n 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 n u. J 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: n n On-board computation of features from raw signals Reduces bandwidth (and therefore energy) considerably Activity filtering: n Avoid processing and storing data when sensor is not moving Utility-driven data collection: n Download highest-quality data from sensors first Tune node parameters: n 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 36, 000 bytes 23 m. J to transmit Konrad Lorincz - Harvard University 600 bytes 1 m. J to compute and transmit 9

Technique #2: Activity Filtering Simple algorithm to detect sensor movement n n n 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 n n n Active: Accelerometer, radio, gyro, feature computation, flash: 63 m. J/sec Inactive: Accelerometer, radio: 6. 5 m. J/sec Nearly 10 x 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 Gyroscope @ 100 Hz Radio Drop Konrad Lorincz - Harvard University Base station 11

The Data Fidelity Challenge Can’t continuously stream data from all nodes n n Data rate exceeds radio channel capacity Energy cost is prohibitive Observation: Not all data is equally valuable n n 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 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 n n 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 n n Only download data from a node when there is energy surplus Avoid downloading when radio link quality is poor (increased retransmissions) Throttle gyro n n Disable gyro sensor when energy limited – saves 53 m. J/sec Degrades data quality but saves considerable energy Throttle storage n n Don’t store raw samples to flash when energy limited – saves 2. 6 m. J/sec (Features are still computed and stored) Throttle sampling n n Don’t perform any sampling when energy limited – saves 59 m. J/sec Effectively results in “blind spots” in data coverage Konrad Lorincz - Harvard University 17

Evaluation Impact of energy saving features on battery lifetime n n n Feature extraction Activity filtering Driver policies: Throttle downloads, gyro, storage Data quality versus battery lifetime target n 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)? n n n 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 n n Feature and sample coverage Tradeoffs between lifetime and fidelity of data coverage n full-coverage: acc and gyro data n degraded-coverage: acc data only Second Application: Epileptic Seizure Detection n 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 n 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 n n Parkinson’s Disease n Tuning of deep brain stimulation parameters n 9 nodes: one each limb plus back (sensors: acc, gyro) n 4 patients: 7 sessions each, 4 hours per session Epilepsy n Just starting up (with Spaulding and Beth Israel Hospital) n 6 nodes: 4 on arms, 2 on legs (sensors: acc, gyro, EMG) n 2 patients: 1 week each in hospital Home monitoring: Parkinson’s Disease n n 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: n n 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 n n n 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