Posts tagged LEDs

Try, learn, try again – Mitochondrion Mark 4.2.4 progress

The Mitochondrion M4.2.3 code was a bit of a mess. It wasn’t bad, but it wasn’t great either that it was put together in a bit of a hurry for last summer’s festivals. And then I tweaked it further over the summer while running out of program memory (Arduino Nano/ATmega328 so only 32 kb). And then I left it alone for a month or so, to get sufficient distance from that code base before thinking about what it could be. The vast majority of the code sat in one big library file, the control logic say in one big function, and inter-object dependencies were bloody everywhere, to the point where I didn’t want to mess with any part of it.

Clearly the solution was to mess with all of it. So it was major refactor time, starting with a clean sheet of paper, then scribbling all over it to come up with a design that was pretty close to the existing approach but without all the knobbles. And then coding and testing and more coding.

*wavy lines*

The Mark 4.2.4 now has co-operative multitasking with flexible time-based scheduling; one task object per sensor, output, or pattern generator; a message queue for asynch inter-object comms; and a nice and tidy state/event table for controlling switching between different modes and smoothly handling those transitions. Objects have much more responsibility to handle their own transitions and modes, leading to fewer cross-object tangles and asynchronous behaviour where a mode change sends a message to every object, those objects can finish doing what they are doing before changing modes and reporting those changes back. Of course, it’s never that simple

Can you spot the problem?

One of the LED strips in the Mitochondrion is has a problem. Only the first third of the LEDs light up, the rest are dim. Now, finding hardware problems can take bloody forever. Poking, swearing, scratching of head. In this case, however:

Yeah, that’s a crack through the middle of the driver chip. It’s pretty easy to work out why this strip isn’t working.

Short term fix is new LED strip. Longer term, well, the driver chips are slightly wider than the aluminium strip underneath. When I drop the whole thing, the chip bangs up against the curve of the polycarbonate tube, pushing the ends down and the middle up. Thus the crack across the middle. So, some padding required for the Mark 4 to help cushion these chips. For the Mark 5, the drivers are inside the LEDs, so that should be more robust, but again, padding will be required.

Mitochondrion glow staff progress – where I’m at, where I want to go

Back from Rainbow Serpent now and mostly recovered from having too much fun. So much fun that I haven’t any pics or vids. The Mitochondrion mark 4.2.3 got a great reception, someone described it as brain-melting, which is one of the feelings that I’m trying to create, and I got to meet lots of other good people and see lots of other LED gear.

I’ve mostly been developing this glow staff for my own pleasure* but with an eventual goal of making these available to other people. “Eventual” can be a long time in the future, but Reese from Soul-fire had a spin (and looked downright wonderfull with it) and then bounced up to me and said “you should be making these so other people can have this experience”. That’s the best reason for hurrying this process along.

This year's plan

And a Mitochondrion video from Circillumina

The Mitochondrion M4.2.2, as spun by Ben.

Apparently, ironically hip people have noticed that psytrance* is neither ironic or hip – A Big Night Out at… a Psytrance Rave! It is, however, fun way to have a night out dancing. That article describes it as “total aesthetic non-conformity” but that implies that the psytrance community cares enough about normality to decide to reject it. I don’t think that’s the case at all (or at least, not very often). It’s more that self-expression can explore a range of directions. By the simple law of averages, most of those directions lead in a different direction to conformity. It’s not rejection, it’s just possibility.

My direction just happens to involve excessive use of computer-controlled LEDs. That’s not because I’m rejecting fluorescent lighting, it’s because I personally think excessive LEDs are a fun challenge. Also I eventually want to spin LEDs whilst having to wear a welding mask due to those LEDs kicking out all the photons.

* – Yes, I know it’s all psybreaks/tech-funk around these parts, not psytrance, and that the tune in that vid is old-school rave, but such distinctions don’t matter at the level of the ironically hip.

Quick Circulation post/Mitochondrion progress

I wandered off to Circulation, caught up with lots of people that I don’t see often enough, made new friends, did a small amount of tissu, trapeze, yoga, slack line (hard), slack rope (ridiculously hard), and gave the Mark 4.2.2 it’s first public showing. It looked a bit like this:

For the Mark 4.2.2, I’ve switched all the pattern generators from red, green, blue to hue, saturation, and brightness, with saturation generally whacked all the way up as far as it goes. I got over myself and gave it to various people for a spin. They didn’t break it and I got to see it from the outside for once.

That’s Keir having a spin in the marquee. I’m sure the first thing that comes to mind is the refresh rate. 20 ms per update, 44 frames in the one loop in the photo, from which we can calculate that he’s spinning it at 720 degrees per second and that the camera shutter was open for half a second. What, that’s not the first thing that comes to your mind?

Having had a chance to sit and watch other people spin it, it’s clear to me that the new code generates all sorts of patterns, most of which I thought up while sitting in front of a laptop. Some work visually, some don’t, so the next stage is to work out what patterns and responses actually look good while spinning and winnow down the random spray of colour and light into a better selection. Oh, and tweaking the slower patterns to remove the bottlenecks in the generator code (floating-point divides and calls to the random function, as you’d expect), with the goal of getting the update time down to under 10, maybe under 5 ms, for bonus complexity, more interpolation in the patterns, and smoother visual flow. And more integration of the motion sensors with the patterns. And a few other things. But it’ll do for now.

Mitochondrion mark 4 – First public spin

So I quietly set myself a deadline of having the the Mitochondrion mark 4 ready for this weekend’s dance party (after having missed the deadlines for Kiwiburn and the Juggling Festival, and having taken the mark 3 apart more than two years ago). As of last Monday, it finally all came together, so here’s the first public spin, at Saturday’s Circillumina dance party:

A decent number of people asked me what brand it was or where I bought it, which is the level I’m aiming for.

The list of things it doesn't do is still longer than the list of things it does

Mitochondrion Mark 4.2 Build Log: The inevitable stage where nothing works

The Mitochondrion Mark 4.2 build is getting to the fun part, the bit where pretty much none of the parts work. However, there are at least parts that don’t work, as opposed to no parts. This counts as progress.

So:
All the parts that don't work, have yet to arrive, or appear to work but haven't really been tested properly:

And the version number ticks ever upwards…

The Mitochondrion, Mark 4.1, reached the spinnable stage, but had some irritating flaws. Hence I’m taking that learning into the Mark 4.2, using almost the same hardware and design as the 4.1, but with a new main board. Here I’m testing out the design. You’re looking at an Arduino Nano, 128 kB external memory chip, a combined compass/gyro/accelerometer motion sensor board and the upright bit is a Bluetooth module, all mostly behaving themselves so far.

Oh, and a level shifter, coz one of the things I learnt from the Mark 4.1 was that the motion sensor runs 3.3 Volts internally and has a voltage regulator so you can power it from a 5 Volt supply. However, it also has pull-ups on the I2C communication lines, pulling those up to 3.3 V. If you’re running the rest of the I2C network at 5V, everything all gets very unhappy very quickly.

Progress so far: motion sensing and external memory working just fine and my phone can see the Bluetooth module. Yup, one of the aims for the Mark 4.2 is to control the Mitochondrion from my phone. And for it to act as a thermometer, and possibly portable clock, coz everyone at festivals needs to be reminded that they are up past their bed-time.

Next steps are either getting the audio circuit design tested in hardware, getting the Bluetooth to work from laptop and phone through the software-serial port, refactoring all the software from an OO perspective, or shifting all the floating point maths into fixed point for a dramatic speed up. Coz you know me, I want to make pretty lights turn on and off and clearly the way to do that is not to buy some pretty lights and an on/off switch, but instead to start by writing my own code to perform basic mathmatics, coz other people’s addition and subtractions functions just aren’t good enough.

Hmm… oh, and more skirting boards. Only another 27 metres to go, for which I will be starting with pieces of wood that look nothing like skirting boards.

In other news, I stood under Patrick Herd’s Light with no sense of proportion with Darryl from Firepixie, who is wearing Phoenix Rising pants and comes from the Bay area, hence the excessive interwebnicity:

And we risked the life of The Secret Ruler of the Internet.

Mitochondrion Mark 4.1 Build Log: Post Kiwiburn

Yup, the replacement power conversion chip arrived, I soldered it in and the whole lot now works:

From Mitocondrion Mark 4.1

You’ll note that it isn’t plugged in to a computer, that the batteries are powering both the LEDs and the microcontroller, and that it is electrically complete and ready to be mounted in the tube. There’s still a couple of pieces of hardware to test (audio analysis circuit, accelerometer, reset socket) and lots of code to write, but it’s ready for Kiwiburn.

In other news, I’m now back from Kiwiburn. I was alternately social and effectively productive. The large shade structure/dance floor roof didn’t blow away or tear itself apart, the portable shade structure worked fine. Other people have pics, I have a huge pile of washing and six bean bags left in the van.

Mitochondrion Mark 4.1 Build Log – It’s Aliv… oh bollocks

The Mitochondrion currently looks like this:
And now… the magic smoke appears

Perlin noise, simplex noise, and interpolation

Most programming these days seems to consist of banging other people’s code together until it all behaves. This wasn’t much different.

I’ve been playing around with some algorithms for the Mitochondrion, Mark 4.1. For one mode, I want smoothly flowing and random patterns. There’s a kind of noise that suits called Perlin noise, invented by Ken Perlin and used to generate natural patterns like clouds in possibly every movie ever.

So, I found an implementation for Arduinos by some guy on a forum, tried it, horribly slow. Like a couple of hundred times too slow to give me a smoothly changing pattern on the hardware I’m using. There’s another kind of noise called simplex noise, also by Ken Perlin and faster. Found someone’s implementation in Java, ported it, tried it, faster, but still not fast enough. Scratched my head for a while, slept on it, had a shower and in the shower came up with the only original idea here, which is to just run the simplex noise for a few of the LEDs spaced out along the LED strip and just interpolate to fill in the gaps. Tried it, total speed up of around three hundred and now I’ve a hundred LEDs all doing what I want.

So cubic interpolation makes me happy, although to be honest, I wouldn’t have thought of doing it like this if I hadn’t asked Ranty Dave an entirely different answer a few months back and received the answer that “Catmull–Rom splines, mate, see you right”. And it’s not exactly a new idea to say “slow algorithm is slow, so only do slow algorithm occasionally and use fast algorithm to fill in the gaps”.

Anyway, here’s a vid of the Perlin, simplex, and interpolated modes. (On anything less than 720p it’s a little jerky, but that’s Youtube’s compression, not my code.)
http://www.youtube.com/watch?v=vtO0A0CRxo8

Question for people who actually know about this stuff: Perlin and simplex noise produce noise with a (roughly) normal distribution, i.e. across the interval from -1 to 1, but mostly clustered about zero. What if I want smooth noise with a flat distribution, i.e. with equal probability of occuring in the interval from 0 to 1? I ask as I’m changing the above code from RGB to HSV so that I can control the saturation (coz max saturation FTW) and I’d like to pick hues with an equal chance of getting any hue.

Is there an algorithm that does smooth noise with a flat probability? I haven’t found one, but I don’t know where to look. Right now I’m just expanding, scaling, and clipping the simplex noise, which isn’t really very flat at all.

The Mitochondrion 3.5 – An Excessive Glowstaff (8 of 8)

Doing better next time:

In the year or two since I finished the Mark 3.5, I’ve had time to give it a good workout and to have a think about what worked, what didn’t, and how to do it better.

Trading time for money for aggravation

The Mitochondrion 3.5 – An Excessive Glowstaff (7 of 8)

Debugging:

You wire it all up. You plug it in. You turn it on… and nothing happens.

Debugging Picaxe code and general swearing about unreliability

The Mitochondrion 3.5 – An Excessive Glowstaff (6 of 8)

Tips for making circuit boards – (tiny, dense, double-sided boards in your kitchen):

Like a fool, I tried to pack far too much into far too small a space. Hence the PCBs had to be equally dense and tiny. But then again, fitting electronics into a 25 mm tube is never going to be easy.

Strong oxidising chemicals in the kitchen

The Mitochondrion 3.5 – An Excessive Glowstaff (5 of 8)

Sensors:


Pic by Marla at Kiwiburn 2009

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.

None of this worked

The Mitochondrion 3.5 – An Excessive Glowstaff (4 of 8)

Power and output:


Photo by Loki Gash for Filament Magazine

LEDs

For the purposes of shiny toys, LEDs come in two kinds: bright ones and painfully bright ones. The painful ones draw 350 mAmps or more, need fancy constant-current power supplies for each LED and will melt without proper heatsinking. I went for the bright ones that draw 20 mAmps each and only need a resistor to protect them.

I chose the Piranha-style square LEDs, for the brightness and broad spread of the beams (like these ones from Sparkfun. I thought about going for smaller, surface-mountable ones, but chose the through-hole LEDs for shock resistance.

Never again.

Dry ice, address space mangling, and the persistent headache of batteries

The Mitochondrion 3.5 – An Excessive Glowstaff (3 of 8)

Picaxe Microcontroller:


Photo by Loki Gash for Filament Magazine

Knowing nothing about microcontrollers, I chose something easy to start, the Picaxe family. The learning curve is easy, it’s designed for schools. Of course, something this simple is going to have limitations and by the end of two years of development, I’ve bumped up against most of them, but I wouldn’t have done this differently.

Even though it runs interpreted BASIC

The Mitochondrion 3.5 – An Excessive Glowstaff (2 of 8)

Physical structure and layout:


Photo by Loki Gash for Filament Magazine

Layout, tubing, stiffness, keeping the insides inside, and shock resistance

The Mitochondrion 3.5 – An Excessive Glowstaff (1 of 8)


Vidcap by Craig Bellhouse

Firespinning is fun, but I thought to myself:
1) It’s been done
2) This is the Twenty-First Century and we have semiconductors
3) This is the Twenty-First Century and burning fossil fuels for gratuitous reasons is just so Twentieth

So a plan formed in my head to make a glow staff. Now, coz I’m stupid an overachiever, I decided to make one with bells on. A glow staff that pushed the boundaries, a glow staff like no other. The only limits are technology, time and money. The technology I can handle, and I don’t have kids or a TV, so time and money are no problem.

There was a slight drawback, in that I hadn’t done any electronics since school and wasn’t entirely sure what a microcontroller was or where to get one. I’d never designed a digital circuit or etched a circuit board, but hey, it can’t be that hard, right?

Several years later, the Mark 3.5 is quite shiny. Forty RGB LEDs, all individually addressable, over a hundred patterns, and bright enough to hurt*. So at long last and before I get too carried away with the Mark 4, it’s time to write down and share what I’ve learnt, both about glowstaffs and electronics. This writeup is an attempt to help other people avoid making the same mistakes as me. And there were a lot of mistakes.

The writeup is going to look like this, one per weekday, until we’re done:

  • Physical structure and layout
  • Picaxe microcontroller
  • LEDs and drivers and power and batteries
  • Sensors – this really didn’t work
  • Making PCBs
  • Debugging & Reliability
  • Doing it better next time

* – Mostly the Mitochondrion hurts other people, coz when I’m spinning it, I can’t see anyone or anything else.

Trivial WIP post

Assorted knitters that I know seem to like to do Work In Progress posts, whereas I never do, for two reasons. The first is that I doubt my ability to do anything, hence I don’t want to jinx it by talking about it. Case in point – Patrick is doing some 3D printing for me. I posted a progress picture, the printer promptly blew up. The second is that I like to things that haven’t been done before. Said thing may not have been done before because I’m trying to do something impossible. Thus I may well be in the state of being about to discover that what I want to do can’t be done and if I’ve told people I’m going to do it, then egg meets face.

And let’s face it, if some random nutter comes up to you at a festival and starts going “yeah, I’m gonna make this thing, it’ll be better than all the other things that have ever been done before, it’s going to be awesome”, then you’re generally going to go “yeah, right, show me the money”. So I don’t want to be that guy.

Nevertheless, I should get over myself. Thus I’m getting out of my comfort zone here by sharing some WIP. But hey! I’m pushing the boundaries and living life on the edge! Danger is my middle name. (Actually, my full name is Happyin Danger Roaring Lethal Molybdenum Balloon Motion, but that’s another story.)

So… here’s some code that I plan to put in the Mitochondrion, Mark 4. I want the Mark 4 to have some ambient/screensaver modes so that when I’m not spinning it, it’s still doing something visually interesting. One simple mode is a slow colour change. I could just loop through red-green-blue like every other bugger on the planet, but nah. So if I’ve got 16 million colours, then I want to use them all, without repeats, and with very gentle, barely noticeable colour changes. Hence there was an immense amount of code written trying to generate smooth paths spiraling through RGB colourspace and … none of it looked right. So in the end, I just said bugger it and wrote four lines of code that randomly walk up and down red, green, and blue. Yeah, sometimes simplest is best.

LJ doesn’t let me embed a Processing sketch, but if you really need to see a square changing colour slowly, then it is.

And if I want to do this at a mellow brightness, then I’ve got a problem. This kind of colour transition looks crap with less than 6 bits (64 brightness levels) for each colour. If I’m using 8-bit drivers, then I’ve 255 brightness levels from off to OMFG, and level 64, (i.e. one quarter of full whack) is too bright to be mellow. Anything over 16 brightness is excessively bright, but then that only gives 16 brightness levels to play with, which makes colour transitions too notchy. So really, I need at least 10 bits of brightness control with, from hardware which will only do 8. Current plan is to try to fake the two extra bits in software, but we’ll have to see if the Mark 4 has enough grunt.