DragonfruitReal Time Well-Being Monitoring

Alex Erdman | Brendan Tawa

Team

Alex Erdman

Hometown: St. Louis, MO Hobbies:

Aviation, Photography, Liquor After RIT:

Intel – Client Applications Engineering (Folsom, CA)

Brendan Tawa

Hometown: Fairport, NY Hobbies:

Video Games, Skiing, Beer After RIT:

Cisco - Technical Assistance Center (Raleigh, NC)

Product Vision Develop a system for monitoring elderly persons or medical

patients in a household environment.

Monitor What?

Environmental parameters: Ambient Temperature / Humidity Smoke / Fire / CO Physical Security

Patient Health General Activity

Did the person get out of bed in the morning? Is there periodic movement? Fall Detection Heart Rate / BP

Target Market Families

Private Caregivers

Senior Apartments

Nursing Homes / Rehab Centers

Geographies Where Competing Commercial Services Aren’t Available

What Is Dragonfruit?

3 Tier Solution:

1. Sensor Network In-home and on-person

2. Base Station Single piece of on-site

hardware to aggregateall sensor data.

3. Web-Based GUI Provide real time information

and historical event logs.

Environment Monitoring

Patient Monitoring

WWW

Email Alerts Web Tracking

Mobile / Desktop

Tier 1 | Sensor Network Environment Sensors

Typically analog Motion detection Smoke / fire / CO Intrusion detection

Interface device : electric imp

Patient Metrics Typically digital Heart Rate / BP Fall Detection

Interface device: TI ez430 Chronos Wristwatch

Tier 1 | Sensor Network Electric Imp

ARM Cortex-M3 microcontroller 802.11n WiFi, GPIO, I2C, UART, PWM, Analog I/O SD Card Form-Factor

JSON

Pros Form Factor Cost

$30 $12 breakout

Cons Squirrel ? Web-based SDK

Poor debugging Community support

pails in comparison to mBed

Tier 1 | Sensor Network TI ez430-Chronos Wristwatch

MSP430, 915Mhz RF transmitter, 96-segment LCD 3-axis accelerometer, pressure sensor, temperature sensor

Pros Form Factor Cost

$60 Eclipse + C Active user

community

Cons Unstable HW TI documentation

scarce / poor Flaky client drivers

Tier 2 | Base Station RaspberryPi

ARM1176JZ-F, GPIO, Ethernet, HDMI, Audio, USB

Pros Cost

$35 I/O Flexible UI Active user

community

Cons None ?

Tier 2 | Base Station Inside the base station - “Pi Filling” : Python, Python and HTML

Establish HTTP socket server / listen for POSTs from electric imp overload the server’s do_Post handler function

parse JSON string fields into local variables decide if the data constitutes an “alarm condition”

has the smoke alarm been set off? the motion detector has been triggered

note the time how long before next trigger is expected?

log alarms by sensor ID and date/time in SQLite database

Open serial comm with ez430-Chronos RF receiver poll receiver for accelerometer data compute the moving average of mgrav in Z direction

is there a sharp spike over a window of ~6 samples? indicates possible fall

SMTP daemon to send email alerts. Serve HTML for web interface

dynamically generate log tables from SQLite database

Tier 3 | Web-Based GUI Presents all system data in one place,

easily accessible anywhere, from any web enabled device.

Python script crawls the SQLite data and reports last known events and generates historical logs.

Why Dragonfruit? The idea isn’t new. The technology isn’t new. Commercial solutions already available.

What sets Dragonfruit apart? Accessibility

Low initial costs, no recurring fees. Similar service from ADT

$365 install ~$80/mo. = ~$1000/yr.

Similar service from Philips LifeLine $100 install + $30 enrollment + $20 s&h $41/mo. Push button pendant only, no fall detection, no environment monitoring

Dragonfruit works wherever there is a web connection Traditional services rely on PSTN and are region specific

Retrospective | Looking Back Did the final product measure up to our original goals?

No – but it is a start.

“lofty” goals from the beginning

Envision a polished final product, retail ready Solid aluminum housing Black glass front Voice activation

End up with prototype / proof of concept

Two guys Three platforms Five software languages

Squirrel, C, Python, SQL, HTML Ten weeks

Minus ~a week to finalize platform / idea Minus time commitment to other full-time undergrad responsibilities

Retrospective | Roadblocks Self-support

Hardware Middleware Web

WiFi @ RIT Electric imps wouldn’t work at first

Chris to manually register the MAC addresses

TI watch Crashing, resetting RF USB dongle

Send erroneous data if buffer filled up

Electric Imp / COSM Foreign language Attempted to use COSM as primary data transport method, mainly due to

its curb appeal, however it introduced significant delay; resulted to HTTP POST

Retrospective | Lessons Learned

In general we liked the project. The idea of following an idea from conception to implementation is

rewarding. More applicable, certainly more challenging then textbook lab

exercises. Exciting challenge to consider / incorporate UX.

Branching out from C / VHDL Taking what you know from those languages and applying it others.

Time flies Make quick decisions

HW selection or SW methodology If something is panning out, how much effort are you going to sink into it

before moving on to plan B?

Retrospective | Dragonfruit 2.0 If we had to do it again. (Recommendations for future ESDIII students)

Keep it simple. No, really. Keep it simple. Ambitions

Realistic goals up front. Get initial features 100% working, then add on.

HW 1 platform

Choose wisely. Well documented, solid online user community

1 SDK Rely less on middleware, such as python, do as much work as possible in

hardware microcode.

Time management If something isn’t working, cut your losses and move on to the next option.

Home Health Hub Reference Platform

DragonfruitReal Time Well-Being Monitoring

Alex Erdman | Brendan Tawa