I was reminded looking again at Johnny Lee’s Wiimote hijinx of a drawerful of these handy, little SparkFun 3-axis accelerometers I inherited from a project of yore, and I decided to post this simple project as a quick overview of, um, why they are neato.  You could make this project with a Wiimote, too.  Or the nearby 3-axis accelerometer of your choice.  What’s handy about these little SparkFuns is that they are bluetooth-less, battery-less (and power supply-less–it takes its 5V straight off the serial) and gallery-rugged, and they have a little PIC chip already turning the data into RS-232 for you.

The Project: Turn an LCD monitor (and a SparkFun accelerometer and a PC with the Shockwave application we write) into a ball maze.  (Yes, quite like the toy you could alternatively purchase at a Woolworth’s for less than two American dollars.  It’s supposed to be a quickie intro to tilt and gravity interactivity, smartass.)  Anyway, let’s take a closer look at these parts…

Shockwave?  Not really.  Not necessarily.  I wanted (to the extent it is possible) to try to standardize all the demos on this site so that it doesn’t take 114 weird plug-ins to come here.  Shockwave seemed like a logical choice.  Why?  Well, it’s web-based, so I can run demos live on the site.  It can be object-oriented when that is what you are explaining.  It can be timeline-based when that is what you are explaining.  You can do code examples in lingo so that they make sense to non-coders.  You can do code examples in javascript so that they make sense to everyone else.  And, most relevant to today, it can do true 3D complete with physics.  So it seems like the best single platform for platform-agnostic demos.  I’m going to make my ball maze with Shockwave and the Havok physics engine; you can use whatever 3D development platform you prefer.  (I tend to be a Unity fan, by the way, just as a matter of flag waving.)  You could even do 2D physics in Flash if that’s how you roll.  You’re about to see how easy the SparkFun will make it for you to switch around.  I should add that since mine is Shockwave, I’m also going to use this brilliant SerialXtra by Geoff Smith in order that my Shockwave app can hear the incoming accelerometer junk.

LCD Monitor?  Not really.  Not necessarily.  I wanted something handy you could hold and tilt (and show a ball maze application on.)  Maybe you put an LCD in tiltable casework.  Or just project onto a tiltable surface.  Or make a more Wii-ish handheld controller.  It depends on your actual content.  If you don’t care to be overly literal about this ball maze metaphor (or you still use a CRT) you can just hold the SparkFun in your hand and have, like, a magic wand controlled ball maze.  (Take two dollars to Woolworth’s and ask for one of those, smart guy.)

SparkFun Serial Accelerometer Tri-Axis v5?  Not necessarily.  They’re $89.95 plus shipping.  You could make one for less with the logic/serial chip of your choice (PIC, Atmel, etc.) if you’re that way bent, but unless you’re making 1,000, is it really worth it?  Not to museumssuck.com.  But here’s the magic:  Plug this gizmo into your serial port and what does it do?  It says over and over and over as RS-232 its calculated gravity value as a vector.  (Say what? It takes its static acceleration, which is basically caused by gravity, and its dynamic acceleration, which is caused by someone tipping it or bumping it or waving it, and gives you the combined effect as x, y, and z values.)

What’s so cool about that?  Well, gravity vector (the value the SparkFun is calculating and sending you over and over) is a standard environment variable in any 3D physics engine.  So, in the barest oversimplified terms, all your “application” needs to do for a very realistic, accurate effect is build (or import) a 3D model (you can make a simple ball maze out of primitives: a plane, a sphere, a few boxes for walls… all run-time code, no beforehand 3DS Max), initialize a physics engine, and then keep letting the SparkFun redefine gravity over and over.  Your scene just sits there while gravity goes all weird around it.  Tip the sensor a bit and gravity stops pulling perpendicular to your scene, but instead pulls at at angle that matches the tilt of the SparkFun.  Fasten the SparkFun flat against the LCD monitor that is displaying your scene (with double-sided tape for now’ll do) and gravity pulls on your scene at an angle that matches the tilt of the monitor and therefore of the scene. No software tilting or perspective correction.  Just: ask for tilt, reset gravity, ask for tilt, reset gravity, over, and over.

Next you can add bells and whistles and graphics and scoring and collision animations and such to your heart’s content.  But the tilt mechanism at the heart of it is as simple as that.

Well, almost no code at all except building a 3D scene, applying mesh deforms and physics, writing a serial listener, parsing and converting the serial input (which invariably won’t be in the format your physics engine wants), plus all the generic game scoring and what-not.  So: a lot of code.  But almost no code for the tilt interface part was what I meant.  Which is kind of a neat trick, no?

(I’m trying to keep these tech tips brief and big picture and it seemed astray to turn “$90 accelerometers are neat” into a 3D physics tutorial.  I actually have a Shockwave/Havok/Sparkfun-based tilt interactive running in a museum and, therefore, the code on a file server somewhere.  As usual, if you actually do try any of these projects and get stuck anywhere along the way, just email.)