Archive for the 'Arduino' Category

Arduino Lightshow

Published January 16, 2010 Arduino Leave a Comment
Tags: , , ,

One of the first projects I started thinking about when I got my first Arduino was an RGB LED lightshow of some kind.  Eventually my goal is to incorporate some audio spectrum analysis stuff to have a lightshow that responds to music, but we must make baby steps.

Unfortunately I didn’t take pictures as I was doing the work but here are some after-shots. The basic setup is this: two boards about four feet long with six small holes drilled and RGB LEDs inserted in. The LEDs are diffused by jelly jars painted with frosted spray paint.  This is all controlled by an Arduino using two TLC5940 PWM drivers.

The LEDs are connected to the Arduino through cat5 cables, two LEDs per cable.  All the wire-stripping was a bit tedious but what’re you gonna do.  Eventually I’d like to use some RJ45 connectors to allow the lights to be connected and disconnected easily.  I thought about using some kind of ribbon cable, but it’s so much easier to find cheap/free cat5 at the kind of lengths I’d need.

And there you have it.

Finally here’s a shot of the controller.  Initially I was using a pro mini but I learned a very important lesson about drawing too much current, destroying my first Arduino in the process.  I then switched to a Boarduino which is why it’s like overlapping one of the TCLs.  From the picture it should be obvious why I want to switch to using RJ45 connectors.

So now that I have a series of RGB LEDs  I need to figure out what pattern to use in lighting them up.  I decided sine waves were probably the way to go and came up with this pattern.  Basically there’s a sine wave for each color and each wave has a slightly different frequency.  This results in some nice rotating overlapping of colors.  The picture below shows how the colors combine differently throughout the plot.


Here’s a video demonstration of this pattern. As the video progresses the base frequency of all the sine waves slowly increases. You may also enjoy the majestic sounds of the dryer off in the distance.

I decided the project could use an interactive component as well.  I incorporated a PING))) ultrasonic sensor and used it to adjust the base frequency of the pattern above depending on the distance reported by the sensor.  At first this didn’t work well at all; the sensor was so jittery and adjusting the frequency of a sine wave at each point (even if only by a small amount) results in some pretty chaotic output.  I used Paul Badger’s digitalSmooth code to make for smoother transitions between frequencies.  In the future I think an even better way to handle it would be to quantize the jumps in frequency between say 4 discrete levels.  I had hoped that as someone approached it would slowly start to speed up, but it ended up being jumpy anyway, so might as well go for the more controlled approach of a set of discrete frequencies.  Who knows.

I’ve been working on this project on and off for a while but I had some free time during the holidays to finally get it working completely; with our New Year’s party approaching, I figured the luge would be the perfect place to mount the lightshow. My wife took this video of the lights deployed on the luge. The video struggles a bit in capturing the color changing once the lights start going fast, but you can get the general idea.

Sourcecode is on Github.

Advertisement

Productivity Monitor with Subversion and Arduino

Published May 6, 2009 Arduino , Python 1 Comment

I’m a big fan of metrics. We use Scrumworks at the office and we put our burndowns on a whiteboard so we can see how each sprint is going day-to-day. Having this feedback always available is both informative and motivating. But we only update the burndown once a day; what about a more instantaneous feedback mechanism?  I figure there are two sources for a measure of our productivity: Scrumworks and Subversion.  I decided that Subversion would provide a more immediate indicator of our progress than Scrumworks.  So I have a datasource, now I just needed a display mechanism.

I’ve been playing a lot lately with the Arduino and specifically with RGB LEDs. It’s super easy to communicate with the Arduino over its USB cable, so some of my first experiments with the RGB LEDs involved controlling them with Python. Now, the last time we were at Ikea I bought this weird little rubber lamp creature thing named Spöka.  It’s just two green LEDs inside with a rechargeable battery and some limited circuitry.  There’s actually room enough for an Arduino Pro Mini and the power cord appears to provide 4.8V so it would be perfect.  Of course, I don’t have a Pro Mini so for now I can prototype it with my Duemilanove.

Here’s the Spöka cover and the box I’ll be putting the Arduino/wiring in.  I cut a hole in the top to fit the little creature on to.
dsc_0072

I’m really terrible at soldering but I did manage to get my RGB LED soldered onto a little board with some wires connected out.  Note: I actually ended up redoing this with a brighter LED I got from superbrightleds.com, I also soldered in a resistor.

The wiring is very simple, just the USB cable in and the few wires from the LED connected to the PWM pins on the Arduino.

dsc_0077

The Arduino reads from the serial connection with one byte for the red, green, and blue LEDs.  There is a bit of fanciness with the red LED since it operates at a different voltage.  I’ve had some difficulty getting good color mixing with the red.  I imagine this could be resolved with wiring a different resistor for the red LED, but I haven’t tried that yet plus I’d need three resistors instead of one.  I’ve also added some “pulsating” action that makes the LEDs fade in and out a bit.  It’s especially cool with the color-mixing.

Here are some photos of the device in action.

dsc_0078

dsc_0081

dsc_0082

Now we just need to connect this up to Subversion.  I used the pysvn and pyserial libraries.  Basically, the program monitors a local copy of a repo;  when it starts it gets all the commits that have occurred within the last three hours, then every 30 seconds it updates the repo and incorporates any new commits into the calculations.   To calculate the “productivity score” it sums up an exponential term decaying with time for each commit scaled by the “size” of the commit as determined by the length of its diff with the prevision revision.  It then uses this productivity score to set the colors on the Arduino: green is good, blue is okay, red is bad.

I’ve tried it out at the office and so far the response from the team has been really positive.  I’ve been playing a lot with the coefficients to get a nice effect from the system.  There are a number of factors to balance.  First, we want it to decay quickly enough that it provides good feedback but not so quickly that it’s too difficult to “keep it green.”  Also we want small commits to contribute a reasonable amount to the score but we want to ensure that large commits (for example adding a bunch of test data or something) don’t kick the score up so high that it stays green for hours.  There are still adjustments to be made but for now it works reasonably well; small to medium sized commits will keep the monster (this is the name that’s stuck) happy for about 20 to 30 minutes and pretty much after an hour and a half or two hours, it’s angry no matter what we’ve done.  With 3 or 4 people all working on a project we really shouldn’t go 2 hours without a commit and it’s not unreasonable to expect at least a small commit every 30 minutes.

There have been a few unanticpated benefits so far.  First, the system rewards more frequent commits even if they’re small.  This is a better practice in general, so that’s been nice.  This has encouraged more small refactoring work.  It’s more rewarding to make something like a small naming convention correction if you get some nice visual feedback.  Also, since it turns green (or at least blue) within 30 seconds of a commit, it’s a nice way to notify other team members that a commit has been made.  This leads to more frequent updating and fewer conflicts.  Finally, it can serve as an indicator that people aren’t sure what to do.  If the monster stays red for a while that’s a good time to get up, walk around and see what’s going on.

Since the color changes no matter who makes a commit, it is a team metric instead of a personal metric.  I think this is important for keeping it light-hearted and not something used to pressure people to feel like they have to be making commits every 30 minutes.  So far we haven’t had any problem with this but in the wrong hands or implemented poorly it could end up being something that would reduce morale instead of improving it.

Code is available on GitHub.  It’s not as clean as I’d like it to be, but it works well enough.

Wiichuck/Arduino controlled LEDs

Published April 19, 2009 Arduino Leave a Comment

I got an Arduino a few weeks ago and I’ve been playing with it pretty obsessively since then.   Since the Wii Nunchuck controllers use an I2C serial it’s super easy to connect one to the Arduino.  Here’s a nice tutorial I used to connect the Nunchuck to the Arduino.  I got my WiiChuck adapter from FunGizmos for $4.  It comes unsoldered but it’s only four pins, so no big deal.  I should mention that I’m using Tim Hirzel’s version of the WiiChuck library which has some nice improvements to the rotation data from the Nunchuck; although in this demo I’m not using the accelerometer data.

I’ve also been working for a while on a music visualization project using a bunch of LEDs.  Initially I was connecting the LEDs directly to the PWM outputs on the Arduino.  But since there are only six of them I quickly realized I needed some way to control many more pins.  I found a nice library for the TLC5940 16-channel LED driver from Texas Instruments.  TI offers free samples for many of their components, so I was able to get a couple TLC5940’s for free (no shipping even)!  The library includes all the instructions for how to wire up the device so it was really easy to get that up and going.  The library also offers features specifically for controlling servos which I will have to check out at some point.

The default demo included with the library is a Knight Rider style animation of the LEDs.  I modified that demo to use the joystick input from the nunchuck to move the active LED around.  The input value ranges from -100 to 100 for the joystick which I square and normalize down to get nicer analogish movement (i.e the ability to just slightly move the point or move it very quickly).  I’m using two daisy-chained TLCs, which is almost as easy as using one.  You just take one of the outputs from the first and plug it into the second.  All the rest of the connections can be shared (each does require its own 2k resistor).  One last thing you have to do is adjust the NUM_TLCS variable in tlc_config.h.

Code

#include <Tlc5940.h>
#include <tlc_animations.h>
#include <tlc_config.h>
#include <tlc_fades.h>
#include <tlc_progmem_utils.h>
#include <tlc_servos.h>
#include <math.h>
#include "Wire.h"
#include "WiiChuck.h"

WiiChuck chuck = WiiChuck();
double xJoy;
double position = 15;

void setup() {
Tlc.init();
chuck.begin();
chuck.update();
}

void loop() {
chuck.update();
xJoy = chuck.readJoyX();
//We want to move only if the user has really moved the joystick,
//otherwise the LEDs flicker back and forth.
if (abs(xJoy) > 10) {
if (xJoy < 0) position -= pow(xJoy,2)/5000.0;
if (xJoy > 0) position += pow(xJoy,2)/5000.0;
}
if (position < 1) position = 1;
if (position > 30) position = 30;
Tlc.clear();
Tlc.set((int)position-2, 100);
Tlc.set((int)position-1, 1000);
Tlc.set((int)position, 4095);
Tlc.set((int)position+1, 1000);
Tlc.set((int)position+2, 100);
Tlc.update();
delay(30);

}

Twitter-feed