LED Cube Controller

Aside from building the LED cube, another major attraction is how the cube would be controlled. There has been a few discussions on what interfaces and controls should be used. We are hoping the cube can be usable (and playable) by students and any visitor at UAT. It all came down to 3 possible options.

1. A Touch Interface
2. A 3D Joystick
3. XBOX Kinect Device

Touch Interface

The original plan for the project, a touch interface could be used to track fingers and map the coordinates with the cube. In order to allow full 3D tracking, the cube would require 2 touch screens. Ideally, 1 on the top face of the cube, the other on one of the side faces. The example above shows how an iPhone uses touch screen works. There are 2 conductive screens that are separated by a thin perforated non-conductive layer. When a finger presses the top of the screen, the conductors touch each other through the holes of the middle layer and map X and Y coordinates to the device. Several other touch screens use the same method.

There were some problems with this option due to some factors. Because of the side of the cube, not everyone, mainly kids, would be able to reach all corners of the touch screens. The cube should be accessible to everyone as well as keeping it ergonomic. Another draw back comes from any pending damages. If a screen were to break, it would take some time to replace the screen due to its cost. Another major flaw is the visibility of the cube with the screens attached on the sides. Although transparent touch screen would be used, it would still blur the quality of our presentation. Also, the user would have a difficult time viewing his/her interaction while controlling it.

3D Joystick

The second option for the LED Cube involved the use of a 3D joystick. Whether it be purchased or self made, a joystick provides accurate 3D tracking and control. The benefits of building a 3D joystick from scratch includes using inexpensive materials to build the device, the possibility of including accelerometers and gyro-sensors or potentiometers to the device, and avoiding the costly expense of purchasing an already built product.

It seemed to be the most plausible controller for the cube. A single dot can be moved and tracked within the cube with a 3D joystick. The problem with this controller is simply aesthetics. The project is meant to be artistic and easy to enjoy. Purchasing a joystick, like the one shown above, may be too big and bulky. Placement for the device would be crucial to the enjoyment and visibility of the LED cube. Building a joystick specifically for the cube could fit the aesthetic needs; however, the time developing a 3D joystick may push back the date for the completed finalized project. Other than that, joysticks have been overused and overdone. An awesome project should have a more interesting controller.

XBOX Kinect

In 2010, Microsoft launched the XBOX Kinect device for XBOX 360. They came up with such slogans as, "14 buttons replaced by you" and "You are the controller". The device uses 3 cameras to track movement and depth and use the data collected to allow wireless control of gamers' video games. For its release, the software development kit was released for programmers and game designers to use, prototype, and create games and applications. After the public release of device drivers for Windows, Mac, and Linux, many programmers and engineers have used the Kinect device to make several games and applications for PCs and have robots move or mirror movement.

Having such a device as a controller would be ideal for the LED project.

RGB Cube Update 1

This past week offered up revisions on the schematic design after being looked over by a manufacturing test engineer. Since he had pretty much no part in designing the schematics, he was perfect for a review. He carefully poured over the datasheets, and came up with several changes that have helped improved the schematic design.

1. Pin 3 on the CD4051B (3:8 Demux) was tied to high, so that a pin was freed up on the microcontroller.

2. Vee and Vss were tied to ground, not 5V like I had originally misunderstood.

3. The connection between XERR and gnd was broken.

4. Provided breakout jumpers so that if one still wants to program EEPROM, one can simply change the jumpers for a given PWM driver and program it.

5. Broke up the PWM drivers into 2 circuits. We kept the first 2 on one circuit, and put the last 2.5 on a separate circuit. This took the number of bits that we need to bit-bang per layer from 72 * 12 down to 40 * 12, offering up about a 45% improvement in speed. So now every layer has 2 serial input lines.

One concern we realized is that there is a great risk for fan-out. One microcontroller was going to be trying to drive upwards of 120 chips, while only being able to output 18mA at max. This was going to be a massive problem, one that was solved by providing the 74LS240’s or 241’s on each panel, offering up a buffer to help push that signal to all the panels. I am unsure, as of right now, exactly how to set up the devices between the chipKIT and the layer, but I should have that next week.

We are also looking at providing 2 power supplies. One power supply will be used for just driving the transistors. The other one will be used for all of the logic. We are hoping that providing a high and low pass filter can mean that this cube only needs 1 power supply, and can handle both signals, but the resulting noise may still be too much for the logic chips to handle. Further testing will be required.

I also have some more details about the software. As I mentioned last post, I was going to be using a 3D array of a struct called Pixel. Each Pixel will hold a 12 bit value representing the PWM clock value. Also in the software I will be providing arrays for color balancing. If someone wants to update a color to a certain level, they would set it by saying something like RedBrightnessLevel[12], and now that value at index 12 will be the value stored in the red value at a given pixel. The highest brightness level that we will be providing (with the exception of a possible strobe effect) will be about 70% of the original brightness level, so that it is easier to bear staring at the cube for long periods of time.

After talking with Microchip, their MPLAB X IDE does not yet support the chipKIT, our microprocessor of choice. We will be using the MPIDE, the Arduino and chipKIT compatible IDE modified by Microchip. We will be needing to use direct port writing. Some tests have revealed that MPIDE can toggle a pin at a max of 2.5MHz, which we need significantly faster than that if we are to have any progress made on this. Aside from other requirements, the PWM driver datasheet provided a couple of formulas to calculate minimum frequencies for the PWM clock and the Serial Clock. These formulas have revealed that the PWM clock needs to oscillate at a minimum of 245.76kHz, and that the Serial Clock needs to oscillate at a minimum of 28.95kHz. The PWM clock will be set to oscillate at 500kHz, and the goal for the Serial Clock will be 30kHz.

We are planning on using interrupts and timers to help regulate these speeds, while still being able to do other functionality, like serial communications. The highest priority interrupt will be the PWM timer, which will toggle a pin on timer overflow. I have not yet determined whether I want to directly control this, or use an output compare module to toggle a pin. The next highest priority interrupt will be updating the serial clock. This interrupt service routine will calculate the next set of values to clock out to the PWM driver if it hasn’t already, output these results, and clock the SCLK line. It will also be used to handle a case when everything has been updated, and it is time to shift to a new row. My goal is to be able to precalculate the next set of values, and then just have the ISR output this. However, the serial lines coming in will take priority over this calculation inside of the main function.

Finally, this week has also produced a bending guide, which will be used to ensure that the LEDs are all bent the same way. When assembling this cube, it will be nice to have consistent LEDs that we can just solder together. See the bottom of this post for some photos of the bending guide. The bending guide offers a tight fit to the LEDs, and ensures that these can only go in one direction. The legs are then bent appropriately. The one lead that goes away from the other leads is the power lead, which gets it above the other leads.

Other than that, no new news has come out of the past week. More updates to come!

24 X 24 X 24 RGB LED Cube

The project to be accomplished this term in Robotics Project is the first layer of a 24 X 24 X 24 RGB LED cube. The design of the cube will use panels of 24 X 24 LEDs, and feature a PCB in the corner. The cube itself will feature a door that will provide access to each of the panels. Each row provides power for the LEDs, while we are going to use PWM chips to provide ground and PWM capabilities. The plan is to use 16 brightness levels, which translates into 4096 different colors per LED.

Each panel will be connected between the layers by 11 data wires, power, and ground. This connection is shown below, in Figure 1.

Figure 1. Layers and connections.

Let’s look into a single layer. One layer is located on one panel from above. Each layer features 3 major parts, the LEDs, the power circuit, and the ground circuit. We plan on using a row/column select format by putting the LEDs in a grid. The LEDs will appear in the small grid pattern shown in Figure 2, except it will be extended 8 times in each direction.

Figure 2. 3 X 3 grid of LEDs.

This grid pattern covers the LEDs, which are common anode in the current situation. Each row of LEDs requires about 1.4 A of power. This will be taken care of on the power side, which will use demuxes to drive a given transistor. This transistor is hooked up to a 5V, 30A line to drive every layer. This schematic is show in Figure 3 below.

Figure 3. Power side schematic.

On the ground side of the panel, each TLC5940 (PWM driver) is a current sink driver. The TLC chip offers resistance on each output channel, set by a resistor on the IREF pin. The ground circuit is laid out in Figure 4.

Figure 4. Ground side schematic.

Software has not yet been worked out. The idea is to use a 3D array of Pixels. Each Pixel holds a 4 bit number for red, green, and blue values representing the brightness levels. These brightness levels will then be translated into a 12 bit value, which will then be bit banged out of the microprocessor into the TLCs.

More details to come!

LEDs

Ryan Carmain and Raul Garcia were discussing on on what levels of brightness they should use for their LED Cube project. Garcia asked several professors from the UAT campus including Professor Vesna Dragojlov and Professor Roy Trouerbach. Professor Trouerbach forwarded an email providing further information on how the combination of lights may affect the audience's perception of color.

"There really are no recommended brightness levels as far as I know

It all depends on how a mix of colors will create certain hues and what our preferences are for the various applications.

Color perception will change, depending on which color will have the highest brightness level.

And with LED lights the situation gets a little more complicated as there are varying LED lights that will have different
effects on how we perceive colors.

See http://donklipstein.com/ledc.html. The article is I believe from 2006."

A Maker Wedding

This post is a little late in coming, but this past March I married a wonderful and patient woman, Beth.  For our wedding we wanted to keep costs low and still make it very personalized, so we did all of the planning and made several custom pieces for our special day.  We planned color schemes, table settings, and the hall layout using InkScape - an open source SVG editor, and Beth made beautiful blue and black ribbon table squares for the centerpieces. I designed 3D printed candle holders, and custom ties for my groomsmen presents.

More details and fancy bits after the break.

Automatic Cat Feeder

It's 4am, and I'm sound asleep dreaming of robots when I'm startled awake by 10 lbs of hungry cat jumping on my face with a pleading "mew".  I get up, feed the cats, and unsuccessfully attempt to resume my slumber.  This scene repeated itself every day for only a couple weeks before I decided I needed an automatic cat feeder to maintain my sanity.

The feeder needed to only handle dry food, be able to ration food quantity so that the cats wouldn't get fat, and it needed to have a lot of storage so that the cats wouldn't starve while my wife and I were traveling.  Similar off-the-shelf feeders cost upwards of $50, and I like a challenge, so I set out to build one myself.

Build details and more pictures after the break.

Hash Murder: Statistical Password Breaking

Joe DeMesy implemented an MPI-based parallel password hashing program as the semester project for my Parallel Programming class this semester.  There have been many parallel password breaking programs implemented before, but what makes Joe's implementation unique is how trial passwords are generated.  In his report, he details how he used statistical analysis of known human passwords (from Sony and Grokker leaks) to prioritize what passwords are attempted.  Using this prioritization, he is able to crack a password much faster than the standard random implementation.

You can find Joe's code here.