Mitochondrion mark 4 - First public spin
A decent number of people asked me what brand it was or where I bought it, which is the level I'm aiming for.
It lasted an evening of dancing about, or rather, it lasted longer than my arms did, coz it's a lot heavier than the mark 3, what with the twenty batteries in there.
The mark 3 ran off a Picaxe with 23 bytes of memory for variables, so all it did was through pre-processed patterns at the LED drivers. The mark 4 runs on Arduino Nano, at Atmel 328P with two thousand bytes OMG the hugeness! "2000 bytes ought to be enough for anybody."* The LED drivers are now one driver per LED, rather than one per five, and can cope with 127 independent levels of red, green, and blue for each LED, rather than a horrible mess of dependent levels leading to about four possible colours per LED. Thus this can do smooth fades of brightness and hue on any LED. And structurally, the mark 3 was a mess of circuit boards, bits of wood, and dodgy wiring. This version has two aluminium spines inside the polycarbonate tube, with 3D printed parts holding the batteries and end pieces (Thanks to Patrick Herd and Shapeways.)
The software is C++ not BASIC and I'm exceedingly happy about that. It's running a minimal co-operative multitasking framework where particular tasks can be set to run at particular points in the future. So the supervisor code can just tell the battery sensor object to run again in five seconds time and not have to worry about it until then. Message passing between tasks is mostly a bunch of globals for things like msg_isSpinning and msg_batteryFlat. (Thanks to ferrouswheel and He Who Cannot Be Named on the Internet for code design help.)
There's enough computational grunt to generate patterns, although I've spent all my coding time on the background code and hardly any on the pattern generators. So in this pic, one task is just painting the length of the staff a dim blue, the other is drawing the two moving white blobs. With two trivial pattern generators running, it's pushing out about fifty frames per second. I want it faster.
Next software job for me is profiling all this code and speeding things up, then writing some pattern generators that are driven by the audio and motion sensors and that use textures and icons stored in the 128 kB EEPROM chip that I've also squeezed in there. And rewriting the supervisor so that there can be N pattern generators, so that the microcontroller is always fully loaded, rather than two and only two. Next hardware job is to work out why the 24V to 5V DC-DC converter isn't turning off when the Arduino tells it to turn off, leading to a standby mode that flattens the batteries in a day. Oh, and there's a couple of loose wires in one socket, and that and that and a few other things...
But hey, MVP. It goes.
* - Most of the crashes in development were down to this memory limit. All the debugging text gets stored in the SRAM, along with all the variables, arrays, and objects. Running out of SRAM causes a silent crash. So when something is making it crash, what do you do? Well, the only debugging is to print out text via the serial line, so you add more debugging text and... you've now caused it to silently crash for a second reason. Grr....