Monday, July 29, 2013

Integrating Sensors and Prompts/Effectors

I’m putting together an architecture that looks like this:

Sensors signals and actuator

The application is a smart-home/safe-home system supporting a combination of

  • Place basedobjects: primarily sensors, e.g., stovetop monitors, water overflow sensors, etc.,
  • Person basedobjects: either prompting/facilitating (flashing lights, feedback tones, vibration) devices, or sensors facilitating a quantified self paradigm (steps, heart rate, blood pressure).

At first glance this architecture looks overly complicated: why have the ZigBee network at all, wouldn’t it be possible to achieve the same result without it, and if so, wouldn’t that be preferable?


ZigBee Sensor Network Advantages

I was driven to this architecture from two directions, first on the ZigBee side: The ZigBee communication fabric is designed for high capacity sensor networks -- in this case high capacity means many sensors, rather than high bandwidth. Considerations included:


  • ZigBee is used in the Phillips Hue lighting system -- which can control up to 50 (!) bulbs from a single gateway. Their website contains a paper which discusses potential interference issues, demonstrating how unlikely it is that interference will be an issue in practice
  • ZigBee is low power -- the radio can run off of batteries for a “long time” (battery life varies with radio settings). A single radio can report on up to 4 different sensors without requiring an Arduino or other micro controller. This not only increases battery life but also substantially reduces costs (any Arduino is more costly that an XBee radio, and uses substantially more power).

And finally: 

Data Cloud


Once you have the ZigBee sensing network in place, getting the data up to a cloud is straightforward using one of Digi’s gateways (I’m using a ConnectPort X2 at the moment). Digi runs their own cloud service geared towards sensor networks. Etherios provides the service at no cost for a small number of gateway nodes -- a nice way to get going and see if your ideas have any traction.


With the sensor data securely stored in a cloud service, caregiver facing applications can access this data via a REST interface. 



Smartphone Prompting/Effector Network


Output device connectivity is an area where “smartphones” shine. I currently only work with iPhones, since I’m familiar with iOS development, and the libraries provided for building user interfaces are complete, well tested and constantly improving. Smartphones also provide a rich set of information about the user situation, with GPS, accelerometer data, etc..


Smartphones have become the default target for consumer facing add-on devices as they support bluetooth, wifi and cellular data connections. The net effect is that an iPhone app can use bluetooth to integrate with a sphero robotand wifi/cellular data to access the data cloud and control Phillips Hue lightbulbs.


In addition, the phone’s GPS and geo fencing capabilities allow checks to be run before leaving the house (stove off, backdoors locked, etc.), making the system potentially attractive to many people, some of whose only “cognitive disability” is having a hectic life. 


On a more speculative level, multiple new sensor types are becoming available in the quantified selfspace. There are a number of startups developing tools to track and measure your activities along with associated apps and API’s. I expect this area to evolve rapidly as companies with a track record of developing high quality consumer products acquire these technologies. Just to pick one example: Jawbone recently acquired BodyMedia



Network Partitioning


Although the functionality->network partition is flexible. It isn’t arbitrary. Low power, sensors requiring reliable, robust transmission will gravitate towards the ZigBee network. The network’s “self healing mesh” topology gives a higher level of assurance and has the advantageous knock-on effect that more nodes increases rather than decreases reliability.


Aside: As I was writing this up, I read an article in the August issue of Computer describing Washington State’s CASAS project, which has similar characteristics