Note: Super sorry about the seriously shaky footage above. Next time I’ll make sure it doesn’t happen.

Yesterday, I spent about 12 hours making what I thought would take “a couple hours” — the Flow Receiver module. In the video above, you can see me demoing the system. Everything is up and running and working seemingly well. This means it’s time to start creating “art.”

I designed the UI for this thing to be as simple as I could make it while also accounting for the fact that I’d be using it on a touch-enabled display. It only has three different “views” which you can see below.

+ View larger on Flickr.

+ View larger on Flickr.

+ View larger on Flickr.

Everything for Flow Receiver is built using Adobe AIR. It communicates with Community Core Vision using CCV’s built-in UDP->TCP bridge which sends out TUIO data associated with the tracked blobs.

Flow Receiver intercepts this TUIO data and displays the incoming data in the right-side panel. I’ll also use this software to interface with the Flow Storage back-end module for creating projects and recording the TUIO data to those projects.

When in “recording mode”, Flow Receiver buffers the incoming TUIO points until its internal “cache” is full, then sends that info via HTTP POST request to Flow Storage which dumps it into a MySQL database. I’m also storing a timestamp (to the millisecond) with each TUIO point collected so that I can later determine velocity data between “frames” as needed.

When it’s time to export a project’s data, I’ll use Flow Receiver to export the data as either an XML or CSV text file.

Not much else to it than that; it’s a super-simple application.

On a side note, I’m pretty amazed at what we can do with technology these days, the number of options from which we have to choose, and the speed at which we can produce this stuff. I’ve somehow managed to create a fully-functioning toolset in a total of about 20 man-hours, cobbled together from open source libraries, applications, and various other technologies — all at pretty much zero cost (aside from the time put in).

It’s written in Processing, uses the WiiuseJ open source Java library (which I highly recommend, at least on the Windows side), and leverages the “Warper” class from Johnny Chung Lee’s Interactive Whiteboard project for mapping the x,y position of my hand on my desk to the correct x,y position in my Processing sketch.

I ended up moving the contraption that holds the Wiimote up as high as I could, since the FOV was definitely cramped (and still is). I think I need to open up the hole in the cardboard holder a bit so the FOV gets extended even more.

I ran into an issue with the tracking becoming very unreliable if the IR LED wasn’t pointed directly at the Wiimote up above. To compensate, I created a little cone out of aluminum foil and wrapped it around the LED. It has a wedge that’s open and faces the general direction of the Wiimote. This definitely did the trick as the light from the LED reflects off the foil and creates a much bigger target for the Wiimote to see.

Now I can start moving onto the other physical components of this piece.

I spent today doing two things. 1) Making the thing that suspends the Wiimote above my desk. 2) Making the modifications to a glove so that it’ll hold the LED assembly I made yesterday. Above, you can see the finished glove, which uses velcro to hold the battery pack in place and a scrap of t-shirt to hold the actual LED in place.

And below, you’ll see a WIP shot of the cardboard enclosure that wraps the Wiimote:

Here’s what the finished structure looks like:

This is just cardboard, duct tape, and a couple screws to hold it against the wall. Right now, my biggest concern revolves around the FOV of the Wiimote. I need to do some tests tonight or tomorrow to make sure it can see my whole drafting table when it’s tilted at an angle.

And since I’m going to be taking more pictures than should be shown here, I’ve created a Flickr set documenting the process of this project.

And finally, a little walk-thru of the stuff in meat-space: