Lampduino - an 8x8 RGB Floor Lamp

Lampduino is a computer-controlled free-standing floor lamp, comprised of an 8x8 RGB LED matrix. The lamp stands 45" high and 18" wide.  Light emanates from both sides.  It has various display modes, as well as an included editor for creating animations.  The lamp is controlled via an application running on a PC host.  The display modes include realtime drawing, playback of previously created animations, snow, meteor, plasma, and synchronization with music.  With its endless available colors, Lampduino can also be used for color therapy, or as a mood light.  When running standalone, without a computer, it plays a soothing plasma simulation..

NOTE:  Any flickering in the videos below is caused by video camera aliasing.  Persistence of vision makes it look flicker-free by the naked eye.

 

Step 1 Bill of Materials

Parts List

(64) 5mm common anode RGB LED's. I bought mine on eBay
(1) ITead Studio Colorduino or an Arduino with Itead Studio Colors Shield
(1) large piece of foamcore board.  This kind of board can be found in most office or artist supply shops.  It is a foam core sandwiched between two sheets of thick paper.  I recycled a 45x30" piece that had a previous life as an advertising poster.
(2) 18x18" pieces of matte drafting film.  I cut them out of a single 24x36" sheet of .003" thick Grafix 2-sided matte drafting film.
lots of 30AWG kynar-insulated wrapping wire. I bought 3 50 feet rolls at Radio Shack, one each of red/white/blue. 150 feet is overkill, but it's a lot easier to work with different colors of wire.
(2) 16-pin male headers
(1) 5V 1A power supply.  I repurposed a wall wart from a broken gadget.

For music synchronization, a few additional parts are needed.  See the Music Synchronization step.


Tools

x-acto knife
hot glue gun
wire stripping/wrapping tool
straight edge
ruler

Comments

[aridee87992]

Hi Lincomatic!

I'm nearly finished with this project, but I was wondering if you put current limiting resistors anywhere in this circuit?

Thanks!

[lincomatic]

You don't need current limiting resistors. The current is adjusted via software

[newdos]

HI Lincomatic - still having trouble here - got myself a colorduino shield plugged on top of my uno. Uploaded the colorduino slave software and now it at least plays the color morphing. When I start RGBmtx it recgonises the UNO but it doesnt take control of it ie if I change modes everything except the plasma mode just freezes the display when I click it and change it - going back to the plasms mode starts it running again. For example when in snow mode I can see the TX and Rx leds on the uno flashing but the color shield is not responding it just sits there with a frozen plasma display. Any ideas, or do I now need to go an buy a full blown colorduino!!!!

Cheers Kev

[lincomatic]

Hmm.. unfortunately, I don't have an Uno, so I don't know what is wrong.
There was another user who hit the reset switch before launching Processing to fix his problem, but in his case, RGBmtx seemed not to detect his board, which is not your case.

Try downloading downloading and installing Processing. Then download and unzip RGBmtxsrcV1.1..zip into your processing sketch folder. Start Processing and load RGBmtx.pde into it (see my instructions in my response to roncobra if you run into problems). Once you get it running, exit Processing, download ColorduinoDeviceDbg.zip and replace the existing ColorduinoDevice.pde with the version in the ColorduinoDeviceDbg.zip.

Restart Processing and load in RGBmtx.pde. Now, you should see messages in the bottom pane of the Processing UI such as cE=0, etc. Let me know what you see, and maybe I can figure out what's wrong.

[globo]

Hi lincomatic,

I have a similar setup as kevin (MacBook Pro OS X 10.7.3 - Uno connected to the Colorduino). I had quite a few problems getting RGBmtx to start. RXTX Library mismatch between arduino and Processing. I also had to lower the baud rate to 19200 and enable the delay(100) in openPort ().
Now RGBmtx starts up fine, finds my serial port but doesn't do anything.

Scanning ports for Colorduino
Stable Library
=========================================
Native lib Version = RXTX-2.1-7
Java lib Version = RXTX-2.1-7
cE=-16pingrc=-16Found a Colorduino on: /dev/tty.usbmodemfa131
cE=13cE=13

cE=13 probably means that the communication is not working. Any ideas how to get it to work?

Yours Jan

[lincomatic]

@Jan,

I don't understand what you mean ty RXTX library mismatch between arduino and Processing. There is no shared code between Arduino and Processing.

[globo]

I was refering to
"WARNING: RXTX Version mismatch
Jar version = RXTX-2.2pre1
native lib Version = RXTX-2.2pre2"

Processing has one, Arduino the other it seems. After copying the one from aruino to Processing it worked again.

[lincomatic]

OK. Please try adding the the wf= print statements I asked newdos to put in below and report back.

[globo]

Scanning ports for Colorduino
Stable Library
=========================================
Native lib Version = RXTX-2.1-7
Java lib Version = RXTX-2.1-7
cE=-2pingrc=-2Found a Colorduino on: /dev/tty.usbmodemfa131
cE=13wf=2cE=13

[lincomatic]

OK, this is just too strange. So RGBmtx is sending PlayFrame packets, and the UNO is seeing SetMode packets. I really have no idea what is going on. There must be something weird about the UNO making it corrupt my packets.

I'm starting to think the only way to figure out what's going on is for someone to send me an UNO to debug with.

[globo]

I have removed the ATMEGA Chip from my UNO board, so it ist basically a dumb bridge to programm the Colorduino. The code is being interpreted on the Colorduino.

[lincomatic]

Yes, there seems to be something going on when the 8U2 chip translates the USB to serial to transmit to Colorduino. Do you have an FTDI cable? I would like to know if you have the same problem using FTDI for the USB->Serial conversion.

[globo]

No I don't have one. I'll see if I can get one. That might take a while though...

[lincomatic]

How about a Duemilanove? That has FTDI on it. That's the setup I used.. Duemilanove w/ the 328P removed.

[newdos]

Hi LInco - ignore my last post - I as well didnt realise processing was a separate program to arduino IDE - however still get the same result as before but for info had to drop the baud rate to 9600 to get RGBmtx to see the colorduino and then I got the debug code show below from the window


Scanning ports for Colorduino
WARNING: RXTX Version mismatch
Jar version = RXTX-2.2pre1
native lib Version = RXTX-2.2pre2
cE=0pingrc=0Found a Colorduino on: COM1
cE=0cE=0cE=0cE=0cE=0cE=0cE=0cE=0cE=0cE=0cE=0cE=0cE=0cE=0cE=0cE=0cE=0cE=0cE=0cE=0cE=0cE=0cE=0cE=0cE=0cE=0cE=0cE=0cE=0cE=0cE=0cE=0cE=0cE=0cE=0cE=0cE=0cE=0cE=0cE=0cE=0cE=0cE=0cE=0cE=0cE=0cE=0cE=0cE=0cE=0cE=0cE=0cE=0cE=0cE=0cE=0cE=0cE=0cE=0cE=0cE=0cE=0cE=0cE=0cE=0cE=0cE=0cE=0cE=0cE=0cE=0cE=0Start Writing Matrix - Done

got the matrix write bit from trying to save a frame to the colorduino - display still just freezes the plasma mode on it when I try anythigng but plasma mode. I notcied the code in the debug window just says cE=0 on everything mode I try and fyi I still can see the rx an tx lights flashing on the uno in snow mode etc

Look fwd to your reply

Cheers Kev

[lincomatic]

Hmm.. the good news is cE=0 means there is no data corruption when communicating with the Arduino, and that the Colorduino is receiving all the commands and data. The bad news is I have no idea why it's not working.

So in record mode, the matrix doesn't update in realtime when you edit the matrix? Snow and Meteor do nothing? And it never returns cE=anything other than 0?

If so, I don't get why the matrix isn't updating except in plasma.

[newdos]

correct matey!!! in record mode the plasma has just froze and nothing changes on the display at all until you toggle back to plasma mode. Do you think it is becuase it is a colorshield rather than a colorduino ??? I was wondering about the comms because of the number of pins connected on the shield to the uno.
Just wondering if I now go for a colorduino are you confident it will work with that and its not down to the Uno ???

Cheers again Kev

[lincomatic]

Kev,
Sorry for the delay in replying.. I've been quite busy. I am really stumped as to what's going on.. the fact that the plasma works indicates the that colors shield is functioning properly. The cE=0 indicates that the communication is working properly ... so what's wrong? I would expect that if the Uno were the culprit, that the communications would have errors. And if the colors shield were the culprit, the plasma would fail. When you put it in snow or meteor mode, do you get a continuous stream of cE=0 messages?

[newdos]

Thanks Lincomatic - just glad you got back. I have done what you suggested and any mode except record and plasma gives a constant string of cE = 0 - hope that helps get to the bottom of this conundrum.

Cheers Kev

[lincomatic]

OK, debugging remotely is a slow an laborious procedure, so bear with me... I'm going to give you some code for testing, so I can try to figure out what's going on. Edit ColorduinoSlave.pde and look for the following lines:

case OPC_PLAY_FRAME: // incoming frame
// curMode = CMODE_PLAY_FRAME;
if (curMode == CMODE_PLAY_FRAME) {
if (packetBuf[1] == PACKED_FRAME_LEN) {
unpackFrame(packetBuf + 2);
curError = 0;

change the last 2 lines so they look like this:

case OPC_PLAY_FRAME: // incoming frame
// curMode = CMODE_PLAY_FRAME;
if (curMode == CMODE_PLAY_FRAME) {
if (packetBuf[1] == PACKED_FRAME_LEN) {
unpackFrame(packetBuf + 2,1);
curError = 0xbd;

upload the updated sketch to your Arduino and restart RGBmtx.

now, you should see cE=-67 coming out randomly when moving the cursor in RGBmtx. When you are in snow mode, there should be a continous strea of cE=-67. Let me know the result.. I'm trying to see if the frames are getting received properly.

[newdos]

Hi Linco,
Sorry for my delay in replying this time my turn to have been ttied up at work!! anyway changed the code as you said and I still get cE=0 when moving the cursor and a constant string of cE-0 in snowmode - over to you!!

Cheers Kev

[lincomatic]

Wow that is really strange. So the board is decoding the packets properly, but processing them wrong. OK, I will work on some more debugging code and let you know when it's available.

[lincomatic]

OK, try this.. again, this is just debugging code to see what's going on...
replace readProcessPacket() in ColorduinoSlave.pde with the one below, upload it to your Colorduino, and run the debug Processing sketch, and let me know what cE=xx numbers you get when you try to run snow mode.

// check for a packet from the host and process it
void readProcessPacket()
{
//
// fetch a data packet from host
//
int bytesRead = readPacket(packetBuf);

if (bytesRead) {
//Serial.write(bytesRead);
if (bytesRead > 0) { // process packet
switch(packetBuf[0]) {
case OPC_PING:
// NOP
curError = 10;
break;
case OPC_PLAY_FRAME: // incoming frame
// curMode = CMODE_PLAY_FRAME;
if (curMode == CMODE_PLAY_FRAME) {
if (packetBuf[1] == PACKED_FRAME_LEN) {
unpackFrame(packetBuf + 2,1);
curError = 11;
}
else {
curError = 1; // bad data length
}
}
break;

case OPC_QUEUE_FRAME: // incoming frame
if (packetBuf[1] == PACKED_FRAME_LEN) {
if (!packedFrameQueue.addFrame(packetBuf + 2)) {
//success
curError = 12;
}
else {
curError = 1; // bad frame
}
if ((curMode == CMODE_MUSIC_SYNC) && packedFrameQueue.isFull()) {
return;
}
}
else {
curError = 1; // bad data length
}
break;

case OPC_SET_MODE:
if (!setMode(packetBuf[2])) {
curError = 13;
}
else {
curError = 1; // unknown mode
}
break;
case OPC_FILL:
if (curMode == CMODE_FILL) {
ColorFill(packetBuf[2],packetBuf[3],packetBuf[4]);
curError = 14;
}
break;
default:
// unknown opcode
; // fall though
}
}
Serial.write(curError); // send current error code to host
}

}

[newdos]

Hi Linco,
Sorry for delay man been snowed under at work again!!!
anywayI now get cE=13 all time in any mode, and as before display freezes unless in plasma mode.

Look forward to your reply

Kev

[lincomatic]

That's very strange. It means it's only getting set mode commands, not play frame commands. OK, edit ColorduinoDevice.pde in Processing and search for

pkt[idx++] = (current_mode == mode_music) ? OPC_QUEUE_FRAME : OPC_PLAY_FRAME; // frame opcode

add the following line after it:

print("wf=");print(pkd[idx-1]);

and let me know what you see in the Processing console.

[newdos]

Hi LInco,
This is what I get in snow mode - just a cut and paste from processing and it just keep repeating

cE=13wf=2cE=13wf=2cE=13wf=2cE=13wf=2cE=13wf=2cE=13wf=2cE=13wf=2cE=13wf=2cE=13wf=2cE=13wf=2cE=13wf=2cE=13wf=2cE=13wf=2cE=13wf=2cE=13

Cheers Kev

[lincomatic]

OK, that's bad news :(
globo is getting the same thing.
I don't understand. I send a play frame command and it receives a set mode command. Must be something strange with the UNO corrupting the data.
I'm not sure I can figure this out unless someone sends me an UNO to debug.
I'll think about it some more this weekend and see if I can think of some other tests to do.

[newdos]

Hi LInco - any news on this yet ?

Kev

[lincomatic]

Hi Kev, sorry, since I don't have an UNO I can't figure out how to fix it, even though I know what's wrong. The UNO is somehow running the code improperly.globo has verified the same problem with his UNO

[newdos]

OK so as a quick fix what board do I need to buy with which chip etc to get this working ???

Cheers Kev

[lincomatic]

Try a Duemilanove. I think it should work.

[newdos]

Hey Linco!!! got my duemilanove and guess what ? it still doesnt work!!!!! all it does now is run the plasma and rgnmtx does nothin doesnt even freeze the display like before. I still have the debug code running you gave me and I can see it is finding the colorduino okay but thats it over to you mate!!!!

Cheers Kev

[lincomatic]

Is the console output from the debug code the same as before? This is very strange

[newdos]

Sure is Linco using the code exactly as we left it when we finished using the Uno
Do you want shot of the messages it brings up ?

[lincomatic]

Yes, please.

[globo]

it should be:

print("wf=");print(pkt[idx-1]);

right?

[newdos]

Hi Linco - this comes up when start RGBMtx




Scanning ports for Colorduino
WARNING: RXTX Version mismatch
Jar version = RXTX-2.2pre1
native lib Version = RXTX-2.2pre2
pingrc=-1No Colorduino on: COM3
cE=-2pingrc=-2Found a Colorduino on: COM5

And after this nothing else appears as I change modes etc. Incidentally if I close MTX and restart it, it wont find the colorduino until I unplug it and reconnect

Cheers Kev

[newdos]

Hi Lincomatic, I have tried what you suggested but I cant get it to run in processing get a load of errors below and I think I have installed the colorpicker library correctly - can you help please ? determined to get this working!!!!

button:326: error: stray '#' in program
Frame:219: error: stray '#' in program
FrameChooser:6: error: stray '#' in program
FrameChooser:6: error: stray '#' in program
GuiElement:55: error: stray '#' in program
GuiElement:55: error: stray '#' in program
GuiElement:60: error: stray '#' in program
RGBmtx:10: error: expected unqualified-id before 'public'
RGBmtx:15: error: 'PFont' does not name a type
RGBmtx:16: error: 'PFont' does not name a type
RGBmtx:18: error: 'Matrix' does not name a type
RGBmtx:19: error: 'Device' does not name a type
RGBmtx:56: error: expected constructor, destructor, or type conversion before 'buttons'
RGBmtx.cpp: In function 'void setup()':
RGBmtx:63: error: 'frame' was not declared in this scope
RGBmtx:63: error: 'getToolkit' was not declared in this scope
RGBmtx:66: error: 'matrix' was not declared in this scope
RGBmtx:66: error: expected type-specifier before 'Matrix'

[roncobra]

I'm getting the following error:

WARNING: RXTX Version mismatch
Jar version = RXTX-2.2pre1
native lib Version = RXTX-2.2pre2
No Colorduino found!

RGBmtx is not "seeing" the Colorduino. It had been seeing it before but not any longer.

Guidance?

[roncobra]

Still having trouble. I'm still getting the message "No library found for com.bric.swing
As of release 1.0, libraries must be installed in a folder named 'libraries' inside the 'sketchbook' folder." when I run RGBmtx.pde in Processing. I attached a photo of my file tree showing the location of colorpicker.jar. Is this the correct placement?