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!

Music Box (Hardware)

In this post, I'll be covering the build details of a project I've recently finished that has ended up as one of the more advanced things I've attempted. In another post, I'll cover some of the programming details, as those were equally as challenging to sort out. The original purpose of this project was to make a small gift for a musician, but it ended up being much more rewarding for myself as the builder/programmer than for the recipient (in my mind).

The original concept was to have a small device that would react to music. Since the device would be given to a violin player, I wanted it to be specifically designed to react to someone practicing an instrument, rather than to regular music being played through speakers. The distinction I make here is that a single instrument (like a violin) being played on its own will create a fairly simple sound wave, consisting of one or two base frequencies as well as a limited set of harmonics, while 'regular' music is a complex mixture of many instruments (possibly including vocals) that create a much more difficult waveform to analyze. There are endless examples on the internet of DIY graphic equalizers that are designed to handle this wide variety of sounds, but I wanted something a little more precise.

At this point I would like to make a note on musical scales, but after a few minutes of research to make sure my language is precise, I realized that I am very much unqualified to give a small lecture on music theory. So I'll keep this short. In modern western music, there are 12 pitches in the chromatic scale that separate each octave (a factor of 2 in frequency). Each of these pitches has a letter name with a possible modifier (ex: D# / Eb). You can also add a number after the name to specify which octave you mean (ex: A4 is 440Hz, A5 is 880Hz). While more traditional tuning is done using various ratios of frequencies to construct the 12 pitches of an octave, a modern approach is to space them out evenly on a logarithmic scale:

f = f_0 * 2^(n/12)

Here, f is the frequency of a note you wish to calculate, f_0 is an initial frequency, and n is the number of pitches away you want to calculate for. So by knowing one frequency (A4 is 440Hz), we can find any other one (A#4 is 440 * 2^(1/12) = 466.13Hz, B4 is 493.88Hz, etc).

In a later post on the software I've written for this project I'll go into more details about how I've used this math to do some clever things, but for now the point I'd like to emphasize is the cyclic nature of the chromatic scale. Every 12 pitches, you return to the same note but an octave higher or lower. It was this idea that led me to think of a circle of 12 lights that would represent each pitch of the scale.

To differentiate different octaves of the same note, I would use RGB LEDs for each light and have each octave glow a different color. To drive these 12 LEDs, I sprang for a couple 16-channel PWM drivers to make my life easier. In order to react to any sounds at all, the device would need a microphone, as well as a fast enough processor to handle the real-time calculations. For the mic I went with a MEMS microphone, and for the processor I sprang for a Teensy 3.0. I've been using one of these Teensy boards for another project and have really loved them. They are fully Arduino compatable, much smaller than most standard Arduinos, and also much faster (overclocking to 96MHz). In contrast to most Arduinos (not the Due), the Teensy is built around a 32-bit ARM Cortex-M4 processor which has a built-in digital signal processor (DSP). I've never used any DSP capabilities before, but I figured this project would be a good one to learn with. As for the aesthetic, I decided to grab a few 6"x6" diffused acrylic panels like the ones used in my water level box project. This way the box will have a nice soft color glow when running and reacting to music.

After testing the PWM drivers and microphone on a breadboard, I went ahead and soldered everything together on a few small protoboards I got for cheap on ebay. While the circuit looks fairly complicated, most of the wires are for daisy-chaining the PWM drivers and linking the outputs to the LEDs. Amazingly, everything seemed to work right off the bat.

At this point I start to wonder if I should plan these circuits before I solder them.

Obviously not done, mostly because the mic isn't connected to anything.

All good things are held together with hot glue and prayers.

While writing the waveform analysis algorithm for this, I realized that I was limiting the usefulness of this device to times when a single instrument is being played nearby. This seemed like a waste of so much soldering, so I decided that the whole device could operate in a few different modes. Some could react to instruments, some to general sound, and some could be oblivious to the environment and just display some pretty colors. In order to switch between these modes, I needed a method of user input. I wanted something sleek, so I went with two small pads of aluminum tape wrapping around the back panel. One is grounded, the other connected to an analog input of the Teensy with an internal pull-up resistor. When the pads are shorted together with a reasonably high resistance object (say, a finger), the Teensy registers a change in the analog read value and the mode is switched.

Gluing everything together.

Once completed, I had a plain white box with 12 individually addressable RGB LEDs in a circle with a microphone and processor to handle the music processing. Power is supplied by a 5V AC adapter dropped to 3.3V with a voltage regulator, and reprogramming can be done right on the Teensy with a micro-USB cable. It actually took longer to write the firmware for the music box than it did to build the whole thing, so I'll cover those details in another post. The goal was to give this box as a birthday gift, and I was pretty rushed to get it done. While I did have it completed in time (neglecting a few coding errors that were fixed post-birthday), I didn't get a chance to take nice pictures of it with my non-phone camera. Hopefully I will have nicer pictures and maybe a video in the next post as well.

Party hard.

LED Color Wand

I've got 6 or so posts drafted on reasonably advanced projects, but I figured it was time to log something that was extremely simple to make. In all, this project took about 3 hours on a Saturday morning.

I do a lot of nighttime photography. I think the reason it appeals to me more than daytime photography is that you can capture an image that the human eye is incapable of seeing. Not only will a long exposure record the movement of light and present it as a still image, but it can reveal color in scenes where the eye would see nothing.

A fun thing to do with long exposures is 'paint' a scene using a light source. In the picture above, I stood below the rock arch waving a flashlight around in my hand to light up the bottom of the arch while the camera shutter was open. You can see the path of the flashlight with the circle of light surrounding my body. I ended up really liking this picture, but I wish I could have changed the color of the flashlight to something a little warmer. My flashlight can light up pure white or pure red, but I wanted something a little more orange-red.

Instead of going out and finding a colored flashlight close enough to the color I wanted, I decided it was time to make my own 'color wand' for night photography.

 This little project ended up being the easiest of any I've shown on this blog so far. I wanted the wand to be extremely versatile in that it could have a wide variety of colors. An important goal was having the ability to change colors quickly so I can combine multiple colors in one complicated exposure.

For the light source I went with 2 diffused RGB LEDs, because I happened to have them sitting around (in fact, they were hooked up to my breadboard with current-limiting resistors already in place). Instead of working with a microcontroller to set the color through PWM, I decided to do things very simply by just using three potentiometers to set the current going through the red, green, and blue channels. This way, a color can be dialed in by setting the RGB levels just as in Photoshop or Paint. At my local electronics store I was lucky enough to find a couple linear 10k pots that would work perfectly.

Battery power is always an issue for me because I hate having to throw away dead batteries and buy new ones. Rechargeable batteries can be expensive and often require special circuitry to change them without lighting things on fire. Luckily, I happened to have a handful of 3S (9.9V) 2100mAh LiFe batteries sitting around from a previous project. I already have a specialized charger for them, so I was good to go.

Ignore the Teensy3, this was just testing the slider and an LED.

The circuit is simple enough that I won't bother posting what I did. When the pushbutton is pressed, current runs through each color channel and is limited by a resistor and a potentiometer. At maximum, each color will have about 20mA running through it, and at minimum about 1mA.

With everything soldered and taped together, I noticed two problems. The first is the non-linearity of the brightness as a function of current. While I designed the potentiometers to vary the current in each channel linearly, the nonlinear response of each LED means that most of the brightness change happens at the low-resistance end of the pots. There's not a whole lot I can do to change that at this point. If I were to redesign the whole thing, I would include a microcontroller that could translate the linear input into a nonlinear output that would create a smoother brightness response.

The second problem with the wand is the LEDs I chose. Because they are diffused, the wand does not produce a beam of light, but instead acts as a beacon that spreads light in all directions. Since the individual colors within the LED package are separated by some small distance, the sides of the LED glow stronger in one color than the others depending on the angle. This means that even when you create an even mix of red, green, and blue to make white, the wand will appear slightly more red, green, or blue depending on which way you look at it. I'm guessing that clear LEDs might not have had this problem, but I'm not entirely sure.

At this point I have yet to use the color wand for any real night photography, but I will try to post an update to this post when I do.

UPDATE: I've tested the wand, and it works wonderfully:

Modular Light Box

  To go along with the continuous stream of data being produced by the water level sensor, I figured it would be nice to have some simple way of displaying the current water level just as one would display the time on a clock. The easiest way I can think of would be just to have a line of LEDs that light up to a certain length based on the incoming data.This seemed a little dull, so I decided to add a few features.
  To go along with the current water level, wouldn't it be nice to see the current temperature? Maybe even the weather prediction for the day (sunny, cloudy, rainy..)? Since I've already chosen a panel of LEDs for the water level, I chose to make another panel for the weather. With 2 roughly square panels of LEDs already, I figured the whole apparatus could just be one big cube. Each of the LED panels would form a vertical wall, and the controller would form the base.
  Of course, getting the data requires an internet connection. One option would be to use an Arduino Ethernet shield, but then you need an ethernet cable running to the device, along with the power cord. To eliminate the extra wire, I opted for the Arduino Wifi Shield mounted on an Arduino Uno.

In the end, I had settled on a modular light box design:
-Arduino base controller with wifi to handle data processing
-Up to 4 removable LED panels forming the box walls
-Each panel uses a standardized 6-pin connection to the base controller
-Panel display determined either by analog signal or simple serial commands

With 2 panels in mind:
-Water level panel - 8x8 matrix of blue LEDs lit to a certain height based on analog input
-Weather panel - 16x16 matrix of RGB LEDs set to a constant color and image based on serial commands

Initial concept drawing, very professional.


Other panels could be added later as long as the main Arduino board is updated to send the appropriate signals.

I won't go into too much detail of how I made the base. It's really just the Uno + Wifi mounted upside down on some male headers, a voltage regulator for each panel, and some wiring to allow one-way communication from the Uno to each panel. Since the Uno is upside down, I added a green LED to indicate when the board is plugged in, and a white LED that flashes when the Uno is being programmed.

I started out working on the water level panel since it was the easier of the two I had in mind. With a pile of blue LEDs and a large protoboard, I got to soldering.

96 blue LEDs all soldered up.

I didn't need to address any of the columns individually, so all of the LEDs on a given row were connected together in parallel. Instead of the 8x8 array I had planned, I went with a 8x12 array for a more vertical aspect ratio. Adjacent to each row I added a current limiting resistor and a NPN transistor to supply the current for that row. This way, all I needed to supply to each row was 5V logic from an IC to turn it on.

The next issue was how exactly to control each row. All the base controller would supply is a serial command specifying how high the water level was, so I needed some logic to turn that into an on/off signal for each row. To interpret the serial commands, I went with an ATtiny84 microcontroller with an Arduino bootloader. I wanted to keep the bottom two LED rows permanently on, which meant that the ATtiny had enough IO pins to control the other 8 rows without using any shift registers or demultiplexers.

ATtiny is the one IC in the lower left corner.

With the first panel finished, I loaded up a simple code to light up the rows and tested it out. This first thing I realized was that 96 LEDs on one panel can be very, very bright when each is pulling 20mA. The panel was also drawing way too much current for the voltage regulator to handle, so I had to quickly shut it off and think of a way to turn down the brightness. Changing out all of the resistors on the board would have done the trick, but it's not the peak current I'm worried about, it's the average current. Instead I opted for using Pulse Width Modulation (PWM) on each of the Attiny output lines to switch the LEDs on and off faster than the eye can register. This way, I could change the panel brightness at any point by changing the PWM duty cycle.

With the first panel working, I write a short code for the base to connect to a wifi network and grab the current water level every few minutes and send the value to the water level panel. For the panel I used an even simpler code that parsed the values sent to it and lit up some number of LED rows. Once the codes were tested, I closed it all up and let it run.

A small gap was left at the bottom due to a correspondingly small miscalculation.

I've let this box run continuously for a few months and haven't run into any problems. There's a second plug for another panel, but that will have to wait for another day.

Final resting place.

Robot Arm: Part 1

In Part 0, I covered the motivation for this project as well as a general outline for how I will proceed. In this part, I'll try to cover the hardware modifications and basic electronics I've used to control the robot arm.

To start, how does the arm work once it is assembled? There are 5 DC motors that control the different joints. There is one motor to control the base swivel, three to bend the arm joints up and down, and one to open and close the gripper. Each motor is driven by applying a voltage across the leads, positive for one direction, negative for the other. There is a hand controller with rocker switches to apply these voltages in either direction. The whole thing is loaded with 4 D-size batteries in series. Each cell provides about 1.5V, but the motors are not driven with the full 6V possible with all of them in series. Instead, 'ground' is taken as half way up this stack, so that the hand controller can apply +/- 3V to each battery depending on the position of the switches.

I've chosen to use an Arduino Pro Mini as the on-board controller for this project, so the first step is to find a way to supply each motor with the proper voltage and current using 5V logic. The Arduino IO pins can't provide enough current to move the motors, so I use a couple H-Bridge drivers instead. Each driver can apply a given voltage to two DC motors in either direction based on input from a microcontroller. With five motors to control, I hook up 3 of these drivers to a protoboard and wire the control lines to the Arduino IO pins.

It's a mess of wires, but some of that is to allow the arm to move freely.

Instead of sticking with the original 3V for each motor, I've gone ahead and allowed for the full 6V of the batteries to be used. The danger here is probably overheating the motors, so I'll have to be cautious. If this turns out to be a problem, I can always get the Arduino to pulse the drivers instead of having them continuously on.

With this step done, I have full control over the movement of the arm. I can either program the Arduino to move the arm in some regular way, or use my laptop to send commands and have the Arduino interpret them and drive the motors. The issue here is that I have no way of knowing where the arm is at a given moment. There is no feedback in the motors that tells the Arduino how far it has been moved, I need to figure that out myself.

There are a few ways I can think of off the top of my head that will allow me to know what position the arm is in:
1) Dead-reckoning - If you know the position at one point and you know how long you've run one of the motors, you can estimate how far it has moved. This still requires knowing the position once, and imperfections in the gearing will cause this method to be very inaccurate.
2) Accelerometers - Each arm segment makes some angle relative to gravity, and knowing each angle allows you to find the arm position. In theory this is fine, but it seems like overkill. Also it does not work for rotation around the base.
3) Potentiometers - Each joint is connected to a potentiometer so that as the arm bends, the potentiometer is turned, causing a variable resistance corresponding to the angle. The Arduino measures this as an analog voltage.
4) Rotary Encoder - Open up the gear boxes and attach a rotary encoder to each motor that sends a signal for every few degrees of gear rotation. Add up the clicks and you get how much the motor has turned. Unfortunately the gear boxes are a pain to open.

The third option seemed like the most reasonable, so I bought a couple 10K potentiometers and glued them to each joint. I'm a fan of using hot glue for projects that don't need to last forever, but if the potentiometers start to come loose I can always switch to epoxy. Each was wired to the main board as a voltage divider with the variable lead being read by the Arduino analog inputs.

Sensor for base rotation. The black sticks are left over from the arm kit.

Second joint. The wire lashing is for safety, or something.

Third joint.

Last sensor. Not the best position, but it works well enough.

With everything hooked up, I check the sensors by letting a single motor turn back and forth while printing the analog input value to the serial port:

Analog reading directly from the Arduino every 10 ms. Bottom axis is around 18 seconds total. I rotated the base from one end to the other, so this is the total range I can get for this sensor.

As you can see, the sensor readings look clean and fairly stable. With some calibration, I'm able to convert these analog values to the angle of each joint. With some simple forward kinematics, I can figure out the 3D position of the claw with reasonable accuracy.

The next part of this project will be sorting out the input method for controlling the arm. I'm hoping to have some sort of physical input using my own arm, but we'll see how things work out!

Maybe after some clever programming I will remove the dunce hat.

Robot Arm: Part 0

The other week, my two siblings sent me a robot arm toy for my birthday. I have a bad history of cutting, burning, and shocking my hands while working on my hobbies, so the idea was that I could use this robot hand instead of my own to save some skin. At first this seemed a little silly, but it got me thinking. Could I figure out a way to use this toy as a useful proxy of my own hand? The range would be limited, the carrying capacity would be small, and the joints wouldn't match my own arm, but there are still some instances where having a hand that doesn't spout blood when something goes wrong would be useful. One such instance is when dealing with the spinning propellers of a drone. In order to test the stability algorithm that keeps my drone in the air, I would really like to poke one side of the frame to see how it reacts. Putting your body anywhere near a large drone is a pretty bad idea (as I now know), so having a remotely controlled arm would be immensely useful.
So I've started a new project to modify this toy arm to mimic my real arm movement. I see this project happening in at least 3 parts. First, I need to modify the arm so it can be controlled by my own code. Next, I need find a way of using the position of my own arm as input for a controller. Finally, I need to come up with an algorithm that translates my own motions to ones the robot arm can handle.

Through all of this I will try to stick to cheap(ish) electronics parts, because if I subject this device to the situations I've put my own hands into, it won't have a long life anyways.