Over the last semester, my 18-549 group of Adeola Bannis, Claire Mitchell, Ethan Goldblum, and I has designed and prototyped a magic wand for theme park patrons to use for group games while waiting in long lines. The initial idea of a crowd interaction device (and several thousand dollars of funding) was provided by Disney Research, but we ran with the concept, adding ZigBee wireless networking, an accelerometer, IR tracking via webcam, location based gaming, and so on. We also wrote a few proof of concept games to go along with it. I lost more sleep over this class than any other I’ve taken, but I learned quite a bit more as well.
The hardware is based loosely on Arduino, and we used their bootloader. The software is a modified xbee-api-on-arduino library and code to interface the hardware. The wand consists of an ATmega168, a 3-axis analog accelerometer, a Series 2 XBee, power and lithium ion charging circuitry, a 1400 mAh lithium ion battery, a very highly mediocre button pad, an RGB LED, an IR LED, and an incredible enclosure that Zach Ali at dFAB designed for us. We went through a few hardware iterations before settling on this. The prototypes we built are probably around $60 each in parts, but dropping the XBee for a basic 802.15.4 IC and buying in bulk would drop it below $20. Our goal was to have the wand last a week long theme park visit without needing charged. Our current implementation doesn’t put the XBee to sleep, so it would last around 24 hours of constant use. Sleeping, we would reach about 9 days, surpassing the goal. Swapping out the XBee would also cut current draw in half. Wands can be charged over USB mini (yay for not using proprietary connectors!).
Perhaps the hardest part of the project was devising the network architecture and choosing where the divisions were between wand, server, and game. In general, the underlying network is abstracted completely away from both the wands and the games. The wands are simply advertised games that they are within range to play, and the games are sent joins when the wand joins the game. There are wand and server side timers to make sure that wands are never stuck inside a game if someone walks out of range of the network.
The server tracks all joins and parts from games in a database, and there is a web based interface to allow for user tracking. Perhaps my favorite simple gee-whiz feature that we added is remote battery level tracking. Each time a wand joins a game, its battery level is logged, which is displayed in the web interface. As the wands also have “display names” associated with them, it would be possible to tell someone, in game, that their battery level is low, if they ignore the red low battery LED on the wand.
The server is written in Java, using xbee-api to talk to wands and Google protobuf to serialize data to give to games. We wrote client side networking libraries for Java and Python. The games we wrote were mostly proof of concept to demonstrate the range of possible uses of the wand hardware.
The game below may look familiar. I have stated probably multiple times that I would never touch RocketPong again, but it always manages to pull me back in. In this variant, when a user joins the game, the star on their wand lights up with the color of their team, and their name appears next to their rocket. They then tilt their wand up and down to control the thrust of the rocket. The values between players on a team are averaged, so everyone on the team needs to cooperate if they want to win. It ended up being a lot of fun, and was probably the most popular game during our final demo. You can’t tell in the image below, but the star field in the background reacts to and collides with the ball, using the Lepton particle physics engine.
I also wrote a drawing game that uses the IR LED and a PS3 Eye modded with an IR filter. We had originally used floppy disks for the filter, but we eventually got the correct IR bandpass filter for our LEDs. I am really pleased with the PS3 Eye. It is the only webcam I’ve seen that can do 60 fps VGA in Linux, and it also works beautifully with Pygame’s camera module. The game is just a basic virtual whiteboard, allowing people to use their wand as a marker. Pressing the buttons on the wand changes the color being drawn. The whiteboard slowly fades away to white, erasing old drawings as the line moves on. I had hoped to allow for multiple people to draw at the same time, but ran out of time.
During our final all-nighter, I quickly wrote a music app using the new Pygame midi module. On joining the game, a user selects one of five instruments. For the two percussion instruments, the user can shake the wand like a maraca or hit like a drumstick, using the accelerometer to trigger sound. The other three instruments use the button pad to play notes. Just because I could, this game also uses Lepton to shoot off music notes every time someone plays one. This game is a really watered down version of a project called Cacophony that I will be developing farther when I have time.
We also had a trivia/voting game, and a cave game clone, which I did not write.
I doubt the project as a whole would be useful to anyone else out there, but individual chunks of it surely are. You can get code, schematics, documentation, and assorted other junk for the entire project at our gitorious repo. Note that parts of it probably don’t function, and much of it requires a very specific set of libraries. If you are really interested, I would be happy to help you use what you want of it. The licensing of just about everything is pretty murky, so talk to me first if you are planning on publishing anything based on this.
