The 3D LED Cube, Part Four
This has become the neverending project! For previous parts, see the index page.
While working more on the 8x8x8 cube design over the past few months in our spare time, we discovered the beauty of RGB LEDs and are going to have to rethink our 8x8x8 cubes before final design. This page covers some of that journey.
For impatient people - here is a 4x4x4 RGB cube capable of showing 4096 colors in a nice case (with a development port for my use).
For the best part, see the older videos.
Now, on to the work completed this time around.
Polishing the 4 cube design
In order to make these cubes as nice as possible, we tried many ways to make a case. For example, we designed a nice laser cut case in Mathematica with interlocking notches that took up exactly 256 cubic inches. But at about $20 each, we needed a cheaper solution. The first version had enough mistakes on our part that they could not even be assembled! It's amazing how many tiny errors slip through even with careful checking. I like software where small errors are cheap to fix early on. A flawed prototype costs real $! Version 2.0 of the lasr cut case worked, except it was missing two tiny corner notches, visible in the next picture (upper right and lower left):
And they are too expensive for our target cost for our cubes. So that sucked....
We found a really cheap collectables case ($6-8 or so in quantity) that looked very nice, but they were smaller than our PCBs by a little bit. We wanted to shrink the PCBs (the huge size of the first was another design error we made!), and while we were at it, we added the ability to drive three color RGB LEDs (each RGB LED is ten times the cost of our bicolor LEDs) in case we wanted to expand. Here is an older PCB and a new one. Note the new ones have RGB pin outs now (and our spiffy new logo, which has moved from the case to the PCB)!
And here is the old (large) laser cut case and PCB compared to the new (smaller) cheap case and PCB:
This move saves us approximately $20-40 per cube (I don't have the exact numbers right here).
The much smaller PCBs make them very affordable in quantity. We also got cheap wall warts to power our cubes:
However, I drove a cube to Cincinnati from Ann Arbor, and the vibrations popped a few items loose. The wires we need to give the cube strength are not good for soldering, another issue we hope to resolve soon. If we want to ship these cubes we need to figure out how to dampen the standing waves set up in the cube, and/or get better supporting wires..... More later.
While this was going on, Gene decided to try plugging some other types of LEDs into the controller, and see what they looked like. After all my hard work tuning the code to make the precise Red-Green LEDs we had look good, we discovered that other LEDs look very cool too. Unfortunately the ratios of colors I had chosen to make very distinct colors on the RG LEDs don't end up so distinct on other color combinations. So the code needs work. We ended up trying many different flavors in many combinations : red-green diffuse, red-blue clear, large ones, small ones, magic ones with lasers on their frickin' heads....
Some bags of various LEDs as they arrive....
Here is some testing of the red-blue clear next to a red-green one:
The large red-green diffuse LEDs make nice solid looking animations, while the small, clear red-blue ones seem to make very sparkly point based images well. So there is no consensus on an overall best LED. For final release we hope to offer a few cool options.
Death of a yellow thing
At this point a banana needed killing: (Video) Moral - in banana versus firecracker, banana loses. Things like this help pass the time when stuck or waiting for parts to arrive.
A close up.
The tricolor solution
After noticing how neat some of the other color combos were, we decide to lower the resistances on the LEDs to make each cube as bright as possible. Another result is I will have to retune the code (more on that later) again! Here is a little device we used to test resistances. The LEDs are run from one of our controller boards to match the timing we use on the boards.
We also finally broke down and decided to buy some RGB LEDs. Our red-green LEDs cost about 10 cents each. At about $1 each, the 130 RGB LEDs we bought to make two 4x4x4 cubes is getting expensive.
But we wanted to pick the best possible items before building a final 8 cube. Now we are thinking of making it a 10 cube, and will probably use RGB LEDs, so building each of those is going to cost us $1000 each in LEDs, not to mention the rest of the hardware. But they will be very pretty, and for sale.
We also do custom design, by the way :)
The RGB LEDs arrive:
A single LED - note they have 4 leads: R,G,B,Ground.
Since the code was designed from the ground up to be bicolor, it took some hacking to even drive the new pins. The first result is a bunch of random colors:
A slightly better picture of random signals sent out the ports:
A camera does not even begin to catch how cool these look to the eye. There is some difference between the precise color emitted from the LED and how a camera CCD captures images, but we hope to find a way to capture how these look to the naked eye.
The coding blues
After testing the various color combinations, and also having new requirements for the tricolor cubes, I realized it would be very tedious fixing all the points in the code where color, rendering, and color modulation were used. Pixels used to be 1 byte, and now they need to be at least two. This changes the memory layout and the very brittle optimized assembly modulation routines. Another serious problem was that colors were very finely tuned to the original LEDs. We now need an easy way to tune the color ratios for various LED behavior, so color palettes need dynamically generated instead of the current static ones. The ramifications would make rewriting the code an error-prone mess.
Plus this was my first ever PIC program, and I learned a lot. I can do better now :)
I decided that a complete, newly designed codebase would be in order. This will make it more modular and maintainable now that I know what features we need. The old code was evolved over several different version of hardware and design and over my learning about PIC programming. To ensure that the rewrite is total, I have locked the old code away where I cannot get it easily. Today I start anew.
It will have all the features as the last one, except it will be built to support LED changes and a full 8 bits color per channel. In practice we'll probably ony render 4 bits per channel, though, giving the RGB cubes 4096 colors. But to guard against another total rewrite I'll design with 8 bits per channel internally. It will remove all the various codepaths for various hardware designs and changes, so our orginal cube prototypes will become orphaned. It will precisely match the PCB design we currently have, which has no issues we want to change.
Hopefully I can finish this in the next two months of spare time.
The current, ready to sell (almost!) cube!
The smaller cubes make the LEDs closer together, and this seems to have solved the vibration problems. I have driven cubes around in my car for a few weeks with no ill effects. So, dampening solved.... The cubes seem robust against shipping abuse.
We now have a nice case, PCB, and power supply solution. Here a close-up of the power plug.
And for our use while working, a development port which plugs into a PICPGM low cost programmer.
The final cube
Finally - shots of the current Red Green LED Cube and the Red Green Blue LED Cube. This is the only image playable on the RGB cube at the moment - it is a hack to show a color cube. Once the complete software rewrite is done we will have a very general cube controller, which will properly color any flavor of LEDs we may decide to throw at it.
In case you missed it above, here are a lot of small videos of the cube in action.
First of all, thanks to all the people emailing me with interest, and the many places our cube is mentioned. Some links to us:
A David Wyatt project at MIT
Again - stay tuned to www.hypnocube.com for purchasing our cubes in kits and finished cubes. If we can find a way to automate the actual 3D cube soldering we might be able to drive the price down to retail store level!