Imagine yourself at a concert on the streets of Madison, a block away from the Wisconsin State Capitol (known for, among other things, being the largest granite dome in the world), listening to Willy Porter, and waiting for the headliner—Eric Hutchinson—to take the stage. As you wend your way through the crowds, you come across a big green button on a pedestal vaugely reminiscent of Portal. Succumbing to decidedly primal instincts, you hit the button, surprised to see a camera flash go off above you. Looking up, you see a camera out the window and a sign that reads: FACEBOOK.COM/CONCERTCAM. Loading up the site on your smartphone, you’re amazed to see your photo already there, primed for you to like and share.
When Bendyworks approached The Majestic about sponsoring their annual concert series Live on King Street (which happens to occur right outside our office), we brainstormed ways to improve the already great experience of attending. After iterating on a few ideas, we hit upon the answer: let’s make a Concert Cam.
What, prithee, is a Concert Cam? Well, we imagined it as a way to capture the fun you’re having while simultaneously sharing that fun with the world. Physically speaking, it’s the aforementioned button, wirelessly connected to a camera and computer running some custom software.
In a previous iteration of the ConcertCam, we used two Raspberry Pis and a Teensy over Wifi. Unfortunately, the RF interference during the concert rendered the system practically inoperable. Enter XBee.
Core to the setup is a pair of XBee Pro Series 1 wireless modules, which communicate using the 802.15.4 standard. 802.15.4 provides specifications for the first two levels of the OSI Model: Physical and Data Link/Media Access Control. Leaving nothing to chance on the RF side, we use the Pro line, which offers a 1 mile radius instead of the standard 100 meter range. The Series 2 modules use ZigBee, which provides the remaining layers. We could have used those, but it would have required more configuration.
You program an XBee by installing a virtual COM port driver for the XBee Explorer USB. Once an XBee module is plugged into the Explorer USB, it shows up as a standard tty device. Then, fire up your favorite terminal program and start throwing AT commands at it. Since there are two XBees that need to know the address of the other, the configurations are slightly different.
We wrote three different programs to run the system. By decoupling the components, we’re able to troubleshoot one aspect during the concert without affecting the others. All the code is available on GitHub under the MIT license.
The first program to fire up is
camera_controller.rb. The functionality is really quite simple, and is practically contained in one tweet that Brad submitted to @climagic. The actual implementation is a little longer, but it’s pretty much all contained in camera.rb. All that’s left to do is connect a camera via USB, potentially change the AUTODETECT_NEEDLE, and note the pid that the program outputs… you’ll need that for the next program.
Next up is the program that connects to the remote button. The general flow is:
- Open the serial port
- Block on reading data frames
- For a data frame, determine if it represents the button being pressed
- Debounce button presses to 1.5 seconds
- Send a
USR1signal to the pid that was output by
The last program in the suite is the facebook uploader, which is actually entirely contained within the Guardfile. Effectively, all it does is watch a folder for new JPGs, then upload them to the Facebook photo album of our choosing. There’s some OAuth magic required, especially since we have to trade a transient access token for a more permanent one, but it works well once that’s hammered out.
People love that fricking button. There were a few technical difficulties during the concert (it turns out, D batteries are really heavy, which has an adverse effect on adhesives), but we ended up taking over 700 photos. You can check out the album on Facebook.