Daft Punk Helmets: Intro

Halloween approaches, which means it's time to spend far too much of my free time working on a costume. Last year, I used my costume as an opportunity to refresh myself on basic electronics and get up to speed on Arduinos. I was pleased with the results, but was very much limited at the time by what I knew. Now I've had a whole year to experiment with embedded electronics, so I figure it's time to apply myself a bit more and see what happens.

During this last year, Daft Punk released their new album Random Access Memories. In case you don't know, Daft Punk is a French electronic music duo consisting of two robots that are sometimes erroneously referred to as men. They look like this:

Their heads contain all kinds of electronic goodies, most of which control LEDs that light up beneath the visors. The one on the left (which I will refer to as Thomas) has a 2D matrix of red LEDs that can display patterns or words that scroll across the visor. The one on the right (Guy) has a few horizontal strips of colored LEDs going up each side of the visor. Over the years, there have been a few iterations of the robot-heads that have shown different amounts of LED activity, but what I have described seems to be the most recognized set of lights.

My goal this Halloween is to make helmet versions of both of these robot heads. Each will contain embedded electronics to recreate the LED patterns that make them identifiable.

The first big challenge I see in this project is the creation of the non-electronically-enhanced helmets. Luckily, there is a fairly evolved online community of folks who are similarly interested in mimicking the looks of these fashionable robots. A common practice for creating props like these that I will use is to start with a papercraft model, reinforce it with fiberglass, cover with Bondo, then fine-tune the shape through sanding. This creates a hard helmet that can later be painted. To create the semi-transparent visors, I plan on replacing the fiberglass/Bondo visors with clear acrylic molded into the right shape.

Once the helmets are forged, the electronics must be added. Both need LEDs, control electronics, and power. Since I anticipate the helmets impeding vocal communication (I assume the robots communicate via wifi instead), I'm interested in implementing some kind of 2-way communication between the helmets.

In all, this is the intended order of operations:
1 - Create full-size paper helmets (post)
2 - Reinforce helmets with fiberglass
3 - Shape helmet exterior with Bondo
4 - Paint helmets
5 - Replace solid visors with acrylic visors (post)
6 - Install lights and control electronics
7 - (Optional) Install 2-way communication
8 - (Optional) Tack on any other neat electronic components I have sitting around.

Taken one step at a time, I think this is a completely doable project, given a few weeks to complete. I will post updates to this project as I complete the steps listed above (assuming plans don't change, which they always do).

Music Box (Software)

In my previous post, I covered the build details of a 'music box' that could listen to music being played, compute a response, and display the output on a 12 RGB LED display. This purpose of this post is to talk some more about the software and algorithms behind the device. There are a couple parts to this, so I'll try to introduce them in an order that makes sense.

The code for the Music Box is available on github.

1 - LED control
There are 12 RGB LEDs that can each be set individually using 3 16-channel PWM drivers. This means that 36 of the 48 channels are wired directly to the LEDs, and each controls the brightness of a single color of a single LED. I've used TLC5940 drivers for this project, which basically act as shift registers. The output value of each channel is set by an internal 12-bit register that is filled by shifting values through each channel register sequentially. The drivers are daisy-chained together so that only one long string of bits needs to be shifted out to set the value for every LED.

The brightness of an LED is logarithmically related to the current running through it. This means that the increase in brightness per increase in PWM value actually decreases as you move up in value. While you may think this only matters if you plan on linearly dimming LEDs back and forth, it actually has a profound effect on color mixing. With only a narrow range of PWM values that cause an LED to appear dimmed, linearly sliding through PWM values will cause each color of an RGB LED to mostly appear on or off. Without correcting for this logarithmic response, sliding through hue on an RGB LED will look more like cycling through the primary and secondary colors (red-yellow-green-cyan-blue-magenta-) with little mixing in between.

To correct for this, I used a pre-computed 12-bit look-up table for each value in [0-255] that would approximately linearize the brightness. While I could only set the color values with 8 bits per channel, the output to the PWM drivers was 12 bit to maintain precision at the low end of the look-up table.

There are a few inputs on the drivers that need to be toggled while shifting data in, but this is well documented elsewhere.The only tricky part is getting the overall PWM frequency right. The grayscale clock (GSCLK) pin needs to be toggled 4096 times to complete one pulse cycle in our PWM setup. In order to have LEDs appear continuously on, the pulse frequency needs to be at least 60Hz or so. This means the GSCLK line needs to be toggled at 4096*60Hz = 246kHz or higher.

When the music box is powered up, it begins by testing the LEDs and drivers by displaying a simple pattern. Then it jumps into Ambient Mode, where the value of each LED is set based on some simple math.

The pattern cycles itself randomly forever, creating an endless sequence of new color patterns. After letting the music box sit around in ambient mode for a few hours, I've decided I should really make more of these. Someday..

2 - Sound Reactive

To react to music, first the software must be able to react to what the microphone picks up. The microphone is hooked up to one of the analog input pins of the Teensy3, so I just need an analogRead() to grab the current state. In order to sample at a constant rate, I used an interrupt that would force the code to take a microphone measurement every few microseconds. After a measurement is made in the software interrupt, the sound reactive algorithms perform some incremental calculations to update the frequency-dependent output.

Since the microphone-sampling interrupt occurs every few microseconds (~350us), any computing that is done using a new microphone reading needs to complete in a very small amount of time.

The following video shows the Party Mode. Six different frequency bins are updated as the microphone samples come in and the amplitude of these bins are displayed on the LED circle. This mode acts as a simple graphic equalizer.

I'm not 100% happy with how it acts, but I think it's a great start.

The final mode is Tuner Mode, which keeps track of 36 different frequency bins that are spaced much closer in frequency. This is the mode I originally designed the music box to run, and much of the math and theory for it was covered in my last post. Unfortunately this mode is also the least impressive right now, so I don't have a video at this point. I think it needs some careful adjustments in the code and possibly some circuit modifications to deal with electromagnetic interference (EMI) produced by the LED drivers. If I can get it working satisfactorily, I will update with a third video!