Mercury : A Wearable Sensor Network Platform for High-fidelity Motion Analysis

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 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 laptopbase station in home • Offline classification of data to UPDRS scores KonradLorincz - Harvard University

5. Mercury Goals and Challenges 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 Internet 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 Max peak-peak Raw signal RMS Mean Peak velocity RMS of jerk 600 bytes 36,000 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 Feature blocks Accelerometer@ 100 Hz Sample blocks Activity filter Radio Gyroscope @ 100 Hz 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. Defining Data Utility Walking Walking Sitting Utility computedfrom 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 • Enable/disable gyro • Enable/disable sample storage • Set activity threshold • etc. Sampling/storage control Download manager Node status Node ID Storage summary Battery state Konrad Lorincz - Harvard University

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

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 Energy schedulewith 24-hour lifetime target Throttle gyro Throttle downloads No adaptation Activity filter Konrad Lorincz - Harvard University

20. Coverage – Throttle Gyro Policy Features Increase in bothlifetime 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. 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.eduhttp://fiji.eecs.harvard.edu/Mercury Konrad Lorincz - Harvard University