DPHP 11 - Technologic Rehashed

And that's my last video. I readers will be pleased. I should be current from here on out, right?

In this I decided to redo my Conway's Game of Life simulation.  The last one was flawed, it ran for a finite number of cycles and did not have any 'end condition' detection.  So, it was perfectly possible for the screen to hit a repeating or frozen state.  So I fixed that with some interesting use of 'lifetimes' that was linked to the hue of the cell, and some interesting use the neighbor function to detect repeating or frozen screens.

But the bigger 'behind the scenes' change was the use of a new firmware for the rainbowduinos.  Funnily enough, this firmware is very similar to one of the failed firmwares from way back in the infancy of the software development.  My janky original firmware uses multiple send and receive 'sessions' because there is a limit to the size of the send buffer.  As a result, there are largish delays introduced because of the need for the multiple sessions and having to wait after each data transmission.  Well, apparently, when I tried to up that buffer back in the day, I changed only one of the two numbers I was supposed to change to get it work.

Either way, I'm using a new firmware that is far more robust.  It did require a rather large 'going over' of my code, especially the oldest stuff that was coded at a very low level to save on operating memory.  Fun to do?  Not in the slightest.  But everything works so much nicer and faster now.  I haven't done any refresh rate testing yet, but early 'camera testing' doesn't cause any of the usual weirdness like you get when you point at a TV, or like in my very first videos.

So, guess I need to start planning these posts out a bit more, now that I'm out of videos to use as a starting point.  Bugger.

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.

DPHP 9 - A.I. = Attenuated Intelligence

Yep. Pong. Seriously, why wouldn't you?  The hard part?  Faking being human, and failing like a real human.  I mean, I could do the MONOCRON thing and have it tell time our just count up in increments, but wheres the fun in that?  No, I wanted some AI's that would play against each other, relatively evenly matched.  Apparently it's the sign of a good AI if it can play itself and stay relatively matched.  Bonus points if it manages to use different tactics and still score very close.  But anyways, evenly matched AI's are mostly likely to just volley endlessly, which isn't very sporting, or interesting, or technically challenging, or going to sound impressive in programming circles, etc etc. 

The breakthrough came when I included some 'random tiring' where one of the AI's would reduce in skill over time.  Theoretically, this could lead to an interesting situation where a paddle would 'negatively follow' the ball and move in the opposite direction, but hasn't happened yet.  I will worship the day that it does though, especially if both paddles manage to go negative at the same time.

Also, Pacman sprites fit on my display.  Neat.  I wish more of the Megaman sprites fit.