I don’t like dumb objects. I don’t like noticeable user interfaces. I want shiny things that just do what I want, without me telling them what I want. And anyway, given that any physical connections to the outside world will have to come out through the tiny, busy ends, then it’s not like I can cover this staff with buttons unless I want to drill holes in the polycarbonate tube, making horrible stress concentrators and greatly reducing the toughness of the tube. Hence I wanted to squeeze a whole bunch of sensors into the Mark 3.5.
I wanted the Mitochondrion to wake up when spun, and gradually chill out when not spun. Hence there’s two accelerometers in there, I used the Pololu ones, good to 6g. Using two mounted along the axis allows me to subtract the readings from each, cancelling out all translational accelerations and picking up just the centrifugal acceleration to tell me how fast it is rotating.
Accelerometers give pretty noisy data to start with, let alone when spun around. So these readings from these get chucked into a eight-reading buffer in the scratchpad on the Picaxe. When that buffer fills, the Picaxe sums the readings, does a fast shift to divide the total by eight to give an average. I know nothing about digital signal processing, but this works well enough.
I wrote this code, got it working, and the next weekend, that laptop got nicked. So, backup more than once per month. I haven’t had the heart to rewrite it.
This set up can work out how fast the thing is spinning, but I’d love for it to be able to detect which way is up. Then, it can start to display POV images that don’t rotate in space. However, this turns out to be tricky.
If the mitochondrion is stationary, picking up the direction of gravity is easy, that’s what controls the hue in the screensaver mode. However, when spinning, the 1 g signal from gravity is superimposed on the multiple g signal from the centrifugal force. Added to that, I’m spinning this by hand, so it’s not rotating smoothly around a fixed point.
At some point, I’d like rig it to dump a good pile of acceleration readings to the 32 kB EEPROM, bring that data over to the laptop, and have a play with algorithms, so see if the gravity signal can be extracted from that noise. And then there’s seeing if it can be extracted from that noise with the somewhat tiny computational resources that a Picaxe provides. I’m not hopeful.
Ultrasonic range finders
A transmit/receive pair will just about fit into one end of the tube. Bingo, these can detect it they’re pointing ground vs. sky and provide the reference mark needed to locate the Mitochondrion in space. I tried with a SRF005, works lovely. However, that uses 20 mm diameter transducers and they won’t fit into the ends. Replacing these with the 10 mm transducers that would fit, just didn’t work. Crap range, like less than 20 cm, and huge noise. I couldn’t find any info about why they weren’t compatible, so I gave up on this one.
There’s an electret microphone at one end, a two-stage audio amplifier based on an LM358 op amp, all connected up to the ADCs on the Picaxe. One ADC connects to one amplifier stage, then the feed from that goes into the next amplifier and then to a second ADC. This should give me a decent volume range for sound responsive patterns, It’s there, it works, but I haven’t written the code to respond to that signal, nor has the Picaxe got enough spare programming cycles to cope.
Overall – it’s dumb
So, the accelerometers worked but were noisy, the ultrasonics didn’t fit, and the audio was too much for the Picaxe to deal with. In the end, the Mark 3.5 turned out dumb. Hell, that’s one reason why I’m building the Mark 4.