Leon the Chameleon
For a class project, I was given a $100 budget to create a small, biomimetic robot. My group decided on active camouflage as our project, and built Leon the Chameleon, who would change to the color of whatever he drove over using a small color sensor and an array of RGB LEDs. For this project I handled most of the hardware and electronics design and installation, sourced the components, and helped with some of the programming.
Because of the requirements of the project, Leon did more than simply change color. He was equipped with an H-bridge motor, and there were loops in the program to have him meander about. He also had buttons that acted as interrupts, making him stop in place and change to a specific color (sandy brown), as well as a phototransistor located at the top of his shell that would respond to shadows by stopping and turning LEDs off.
For Leon to run effectively, multiple subsystems had to run within their correct power, current, and voltage ratings. For the project, I chose to use an Arduino Uno, and took advantage of its multiple voltage regulated pins to help power different parts of the project. Besides the primary problem of fitting all of the wiring within the board’s limited GPIO, there was also worry of current management. Arduinos can only source 40 mA of current at maximum per pin, and it is not advisable to approach this amount. For this reason, the two largest current sinks, the motors and the LEDs, were not powered from the board. The motors were connected to their own dedicated power source through an H-bridge and the LEDs were powered through a small array of transistors.
Managing the LEDs took extra care; each LED package had 4 pins, and each color channel in the RGB LED ran on its own unique (yet equally inconvenient) voltage level but needed 20 mA of current. As a result, one of the biggest inhibiting factors in the number of LEDs installed was the availability of high wattage resistors. I did not have the physical space to wire resistors to each individual pin of the LEDs, so I combined 3 of the same colored pins into one 1/4 Watt resistor. This balance meant that I could use only 6 resistor packages to power 6 LEDs (with 6 pins for the red, green, and blue lines, that would be 2 resistors per color). A transistor would open and close a 9 V battery source to power the LEDs, with the base connected to the Uno.
Additive vs Subtractive Colors, and a Software Gain
One of the most difficult hurdles in getting Leon operational was integration of the color sensor with the LEDs. Thankfully the color sensor was a very complete package, coming with a bright white LED that helped ensure consistency across the colors read into the board. With proper white balancing and calibration, it was very easy to reproduce colors to the screen. Unfortunately, producing colors on the LEDs was not as simple.
RGB LEDs use the additive color system. If all of the color channels are set to maximum, they should produce white. As a result, not all colors can be created when using an sRGB color space. One clear example is the color black, but other, less clear examples include many shades of brown, many shades of magenta, and most turquoise-like colors. As a result, extra care was needed when trying to integrate the LEDs and the color sensor. Each was individually white balanced, and in order for the color sensor to correctly output the color it saw, an additive color algorithm was introduced. This algorithm also took into account calibration, and added a software-based gain on the PWM values for each color.
Why a software-based gain? The R, G, and B channels on the LED took in 2.0 V, 3.1 V, and 3.2 V, respectively. Each needed 20 mA, and the power source was shared between the LEDs and the board, over our many, many hours of testing. Of course, each LED was rated for different amounts of lumens, and because we used resistors instead of potentiometers, sending the same PWM signal to each RGB channel would produce widely different results, and would change over the course of many hours of testing as the batteries drained. Before we implemented any sort of calibration, sending a max-analog value to the channels created a deep blue instead of a white. Adjusting gain with components (like a variable resistor) would mean that we would want to adjust the values as battery charge fell. So if the color sensor saw purple, how would it be able to recreate equal levels of red and blue in the LED? The software gain, adjusted during calibration, made sure that if we input a Hex RGB value, it would be able to adjust the LED levels to create what we wanted. It also stayed constant, regardless of how much the battery drained over the testing period. By adjusting the PWM values instead of introducing more circuitry we were able to save on components this way and stay within our $100 budget, too.
Because of time constraints, we kept our design on a breadboard. This meant tons of loose wires, and initially, poor organization of our breadboard lead to many shorts, and some burnt out components. Even though we didn’t have time to solder to a protoboard, we did address the problem by organizing our wiring layout to minimize problems and keep everything organized. Inside Leon we also had similar problems, as his small shell housed 6 4-pin LEDs, two buttons, and a phototransistor. In our first test, I soldered all the wires to each pin individually, using electric tape and hot glue to insulate components, but this created many problems when it came time to wiggle the wires around each other to get them into the breadboard. Eventually, in order to minimize wiring inside Leon, LEDs were soldered together in groups of 3 (3 Red pins soldered together, 3 blue pins soldered together, etc.), which helped reduce clutter inside Leon and on the breadboard. Longer wires were used from inside Leon, components and wires were trimmed to size on the breadboard, and in the end, even though Leon was living on a broadboard, our component layout made sure small collisions or extended use wouldn’t cause any problems inside his shell.
Leon was an ambitious feat to accomplish with only $100. With a larger budget, a protoboard, ribbon cables, or perhaps even a dedicated PCB would have been used instead of a breadboard. Because of how big Leon’s shell is, all the components, minus perhaps the motors and wheels, could have easily been housed inside his frame, making a more compact package. In addition, in some cases, better components could have been sourced. Leon’s phototransistor was not very sensitive to light, and the motors and chassis came in a package, but did not have a gearbox and as a result handled a low load and was susceptible to a lot of flyback. Also, as a result of a lot of testing, Leon’s batteries were very drained come exhibition day. Once again, using a better power source (like a LiPo with a charge management IC) could have left us with better power results, and prevented us from needing to (and forgetting about) changing his batteries.
Also, because we were Macgyver’ing our way through some parts of the project due to financial constraints, Leon’s wiring looked a lot less sophisticated than it was. One obvious example was with the color sensor, which needed to be held close to the ground in order to be accurate. Without any spacers or a budget for anything to hold him, the color sensor was just soldered to a wire that would leave it dangling right above the ground. Uneven ground could have damaged the circuitry.
Budget complaints aside, Leon was a successful project, and despite the trouble he threw my way, he will always hold a special non-turquoise, non-grayscale place in my heart.