Once upon a time in media art, keeping your “secret sauce” of techniques confidential and proprietary was more or less given. Nowadays, though, collective knowledge about how to make stuff helps everyone improve their craft, and push the media forward – perhaps more in line with mature, traditional art technique. So, I hope we’ll more regularly feature the process behind new work, and some of the lessons learned behind the scenes. It gives us the chance to better appreciate the work as viewers, and helps all of us better our own technique.
In that spirit, I recently spoke to Andrew O’Malley, whom we most recently spotted here on CDM with his open source alarm clock. This time, he and wife and partner Deborah worked on an interactive lighting installation (under the name “The Latest Artists.”) The project had a good cause, too: focusing on housing rights issues in Ottawa. The project was not only conceptual, but also keys into efforts by a local charitable organization that helps empower low-income individuals and families to find and maintain good housing in the area.
The project is simple but elegant: visitors “keep the lights on” in a human-sized architectural tower. It’s got the kinds of ingredients other projects might, too. So Andrew is able to share some real insight into real-world experience with those very components, namely, his work with:
- Processing software for manipulating the LED array (with a corresponding display on the screen)
- XBee wireless communication [see a good reference on Ladyada’s site
- Shiftbrites for LED arrays [nice writeup on Hackaday]
- Capacitive touch panels
This information will arrive a little late (cough) for those of you students now polishing off thesis projects, but file it away.
Andrew writes:
The Processing control software mimics the LED array, and also shows on the screen when a touch is registered.
The only software prototyping I used was an early version of the control software that took the raw data from the touch sensors and displayed across the array so I could more easily make sense of it all (as opposed to watching it fly by on the Arduino IDE serial window). The control software still has a long way to go, though!
The touch array was prototyped, as seen in this image.
Because Shiftbrites are relatively quick to connect into large arrays, after a few experiments with 2 on a breadboard, we went straight into building the large arrays directly.
I’ve used XBees before, and they’re great: very simple to configure, and once configured, I’ve found they just work. I’ve tried working w/ inexpensive FM transmitter/receiver pairs, but have found them much more finicky; w/ XBees you pretty much have a wireless serial port out of the box.
Regarding capacitive touch sensing, it really is touchy! A major problem we encountered was tuning the capacitive touch system. The circuit exhibited varying behavior between all environments from proof-of-concept to final integration with the structure. We experienced noise problems when using the touch panels near the lights, and further interference when the arrangement was placed into the metal structure (common grounding solved most of these issues — subject to a blog post all their own). The biggest downfall to this sensitivity was experienced during the move from studio testing to the actual venue: in the studio we had to use sensitive settings to obtain usable touch data, while once in the venue, the control software was receiving so much touch data that it became overwhelmed and couldn’t control the lighting exactly as planned.
The major advantage of this system, however, was its scalability and low complexity. In terms of scalability, using a row/column arrangement of sense electrodes meant that only 11+1 i/o pins were needed for each 5×6 array of windows. It was also less complex than a large arrangement of IR LEDs and accompanying IR sensitive cameras, and much easier to assemble than adding a mechanical button mechanism to each of the 120 windows.
As for Shiftbrites, they are simple in theory — the control data gets passed along nicely from the controller to each respective light along the chain — but have many practical caveats: power needs to be
injected along the chain to keep things stable; the power supply used has implications; a long chain of Shiftbrites seems very susceptible to interference/glitches on the data lines, resulting in unwanted
behavior (solved largely in software); and you must be very careful interconnecting Shiftbrites as they are easily damaged irreparably (make sure to order a contingent stash!). Diffusion needs to be well
thought-out as well.That said, Garrette at Macetech (makers of Shiftbrites) was extremely helpful with his knowledge of the product and seems very committed to helping customers get their ideas up and running.
Full writeup on Andrew’s blog:
Urbana 2011 @ “It’s More Fun to Compute”