DPHP 10 - Making the Robot Rock... Again

Yep. Bad song title pun. Haven't I done enough of those? Not in the slightest. I pride myself on my pseudo-English heritage and mad attention to Top Gear, so I should be able to sprout random one liners til the sun goes down.

Anyways...

So I did sound.  Again.  Why?  Well the first setup, with the Processing sketch and the laptop, would be cumbersome to deploy on the real thing, to put it mildly.  I went so far as to track down the exact model of UMPC (ultra mobile PC) I would have used to run the script and provide the music.  Namely, the Viliv S5.  I was even somewhat willing to pay the ~$500 for the unit.  It'd be a nice toy anyways.  But really, it wasn't really a practical idea.  It meant another device with another battery that would need to be kept charged.  It would mean even more cables.  Not practical.

I learned enough in signals and systems (the class I hated the most in school) to know the theory of what I wanted.  I wanted a discretely calculated (because floating point numbers take a lot of process time on arduinos) FFT (fast Fourier transform).  And I knew that I didn't have the wherewithal to do it myself.

So, I stumbled upon a pre-built FFT library one day on the interwebs, dropped it in, and off we go.  I now have a locally calculated FFT that gives me some pretty lines that dance to the music.  It has some problems.  It probably only registers up to 500Hz and even then it seems to have a ton of noise built into the signal path.  The arduino ADC (analog to digital converter) only reads the positive side of an AC signal from an audio source, so about half the signal is missing.  I did try to get round this with a coupling capacitor and some other circuitry, but the result still isn't perfect.  The typical signal from a MP3 player maxes out around 2.5V, which means your signal is at best 1/2 the voltage you want it to be, and small voltage signals means more noise and more problems.

But I got it done locally on the micro-controllers.  $500 saved.  Job done none the less.

And this brings us to the second half of the video.  Almost more impressive.  Or certainly a more lengthy discussion.  Oh boy.

The side lights.  They're a hug part of most builds, because that's the extent that most others go for with their lights.  Simple reason: you need to see, that gets rid of the front display.  I've gotten around that with the camera and video goggles.  I didn't get around to the side lights until rather late in the game here.

I must one up everything, that's a given.  So, no cellophane covered LEDs here.  Nope, instead I'll continue the RGB trend and give each bar 3 RGB LEDs.  All kinds of coolness ensue as a result.  As you see in the videos, you have scrolling rainbows in the horizontal, in the vertical, and diagonal.  How cool is that?  It basically an extension of the display itself.  Tons of flexibility, limited only to the code I bother to write.

But like everything, there has to be some caveats and some problems.  This is where my new best friend (he who is building another copy of the helmet, otherwise known as ThreeFF) comes in and his innate ability to ask questions.  Plenty of times they're questions and problems I've thought out (like how do you see in the dark: headlights), and I explain as much.  But it's very helpful when he calls out the bits I haven't thought of.

He points out, simply, that if I used a rainbow, like you see in the video, I'm essentially using 1/6 the power of the main display (1 rainbowduino instead of 6) to light up roughly the same surface area with the side bars.  Yah, problems.  This eventually turned into an epic saga, in which I became knowledgeable about almost every off the shelf LED lighting system in the hobby electronics scene, from shiftbrites, BlinkMs, bliptronics, etc.  But as always that's discussion for other another time.