PUCK: PUCK of Ubiquitous Contextual Knowledge™
Internet-of-things / ubiquitous computing … these concepts have been central to NYTLabs thinking over the last year (and related to much of my past work 1, 2). They are old ideas, but we are finally seeing their fruition in interesting consumer products on the market.
I’m into two concepts in particular: Twine and GreenGoose. Both are looking at dirt simple, generalized hardware (particularly the mighty accelerometer) that wirelessly spit data up to the cloud. Server-side software can then contextualize that data to serve any number of social purposes, like alerting you when the mail comes (Twine) or keeping tabs on whether the dog is getting fed (GreenGoose). It hits that middle range of Greenfield’s notion of scale — the level of the room (as opposed to the individual, building, or street) — which I think is a particularly ripe area.
So in tribute I wanted to create our own version at NYTLabs (after acronym brainstorming w/ @mboggie). The idea is a small, generalized piece of hardware that you can attach to a physical thing in your world which can be programmatically assigned to monitor interesting events. It should have long battery life and report data from the accelerometer and other sensors wirelessly. Its logic should be on the server somewhere, not burned into the device, and it should have HTTP and UDP interfaces. And finally, in my twist on the concept, I want it to respond to touch, so that if you pick it up, it turns into a high-resolution controller, like a Nintendo Wii. The idea is to then have hundreds of these all over everything. I’ve been picking at this the last few months, and finally have a proof of concept running.
The core component of PUCK is the XBee. XBees rule. A network of lightweight components is in itself aesthetically appealing, and in essence, all I want to do here is hook a sensor up to one. The XBee is smart enough that this can be done without the help of an Arduino or other microcontroller, which is essential to keeping down the cost.
The path I went down and should not have is trying to figure out how to program them directly in python over the serial port. Instead, Andrew Rapp has an awesome java library and a wealth of documentation that is the way to go. I got hung up in that I didn’t just want to collect data from the XBee, I wanted to reprogram its behavior on the fly, using ‘API’ mode — this library has all that hard work in place.
In any case, the rest of the design here comprises an accelerometer, tilt switch, and LED. The tilt switch is able to wake up an XBee — it’s quite sensitive, so moving the device at all can take it from a mode where its just periodically reporting data and put it into high-frequency reporting mode. Finally, the LED just indicates when the puck is awake. When we get a MakerBot I’ll design a housing.
On the server side, I’m pushing the data into Redis and rebroadcasting it via OSC. The next step is to figure out how to architect the signal processing and the nature of the interface.
But I’m far from a hardware ninja, so I’m pleased to have something together that I can experiment with. Updates to come.
