Botfest 2003 - Marble Madness Color Sensor
Nick Pennella
Introduction
Durrell Bishop, while at the Royal College of Art (RCA), designed a prototype telephone answering machine. His idea was to have a tangible interface to a very standard device (see picture below). The idea for this was fairly simple; represent each message that has been left on a simple telephone answering machine by a tangible object, in this case a marble. Once a message was left on the machine, a marble would drop out of the machine into a tray. In order to play back your message, all you had to do was simply re-insert the marble back into the machine and the marble would trigger some mechanism that would play back the message. Although simple, it allows digital information to be represented by a physical object rather than just some 1's and 0's. Unfortunately, Bishop never got around to implementing his idea in any practical way.
For this project I choose to implement Darrell Bishop's Marble answering machine. The concept for Bishop's Machine appears to be simple, but for an amateur robot builder this device would pose a number of design issues. In the time that I had to work and develop a solution to this problem, I choose to address only a few.
My Implementation
With the time I had available to develop a solution I knew that I could not fully implement the entire device. Instead, I choose a "proof of concept" model of implementation, where I would prove the the model could work given a small scale design. Therfore, I choose to ignore the answering machine portion of this and instead focus on the delivery and recognition of "messages", or in my case colored marbles. In order to deliver and recognize marbles, two major peices needed to be constructed:
1) A delivery system for the marbles so to deliver them exactly one at a time
2) A color sensor to read and store the value of the colored marbles.
The overall design when peiced together would deliver and read and display a colored marble using a cricket to control the entire process.
Delivery System
Design Decisions
The delivery system for this project had two major requirements:
1) Deliver exactly one marble at a time when triggered
2) Hold the marble in the same place every time to get an acurate color reading
The task of designing such a system with the given requirements stumped me for a number of days. While I was in the lab late one night, I decided to go down to the vending machines to get a drink. While down there it hit me... Vending machines have similar charactaristics, they deliver exactly one product at a time and hold all of the products in exactly the same place. Once inspired, I ran back up to the lab and came up with the following diagram...
Physical Implementation
| Part |
Quantity |
| IR Sensor |
1 |
| DC Motor |
1 |
| PVC Pipe |
1 |
| Dasani Water Bottle |
1 |
| Spiral Notebook Spiral |
1 |
Once equipped with a design, I then had to build the system using whatever I could find. I first started by gathering a set of parts and refining my design include a little more control. This included the use of PVC piping to reduce the amount of jitter while the marble was traveling from the hopper to the destination as well as an IR sensor to stop the marble when it was at the desired spot for a color reading. Once built, the physical peices would remove a marble from the hopper and pass the marble down the tube until it reached the IR sensor. Once at the IR sensor it would pause, then pass the marble down the exit tube. This entire flow was controlled entirely by the Handy Cricket (see code section below).
Code
The code for this mechanism is fairly simple. The only function the drive system performs is setting up to read a colored ball. This involves turning on the motor until the ball has reached the IR sensor, sending over the cricket bus a command to read the color, and then beeping the color (the numberic representation of the color). Once the beeping has finished, a ball is sent out the output shoot and the process repeats. See the full code listing below:
Full Cricket Code Listing
Color Sensor
Design
For the color sensor peice of this project I found that the best implementation given the time constraints would be a reflective light one. In a reflective light design different colors of light are reflected off of a source object, and based on the intensity of each of the colored lights (red, green, blue) a determination can be made as to the color of the reference object. For this design I choose to use a CDs Photocell teamed up with a tri-colored led to provide and take the measurements on the reference object.
Physical Implementation / Schematic
| Part |
Quantity |
| Tri-Colored LED |
1 |
| CDs Photocell |
1 |
| LogoChip |
1 |
In this implementation I set up the LED next to the CDs Photocell and pulsed the light while taking a reading on the Analog to Digital converter on the Logochip. The Logochip drives each of the three colors using its standard ports configured as outputs (please see source below for an example of how-to). As an additional enhancement, it was crucial to sheild the CDs Photocell from the direct light of the led. I did this by using shrink tube, which I placed around the photocell so that it would only receive reflected light.
Color Sensor Schematic (full-screen)
Source Code
The LogoChip code for this peice of the puzzle was in charge of driving the LED through the use of the PICs ports and then taking a measurement using the A/D converter that is also build into the PIC. To give an overview of the process, it would simply flash the green light... take a group of 3 measurments, flash the blue light... take a group of three measurments, flash the red light... take three measurements, then take the result and determine which color you had and send it back to the cricket.
LogoChip Color Sensor Code
Future Enhancements
Now that I feel that I have got the hard part of this project under-wraps, there are a number of future enhancements that I am thinking about working with for the rest of the semester.
- Re-Implement the color-sensor using a PhotoTransistor rather than a CDs Photocell
- Implement a Digital Recorder/Playback so to record the incoming messages
- Implement a phone interface that works with the digital recorder
Final Product - Design Considerations
Although I am satisfied with the outcome of this project, it has been a long journey from when I first decided to take on this project. There were numerous drawbacks and design choices that I had to make to come to my final decision, and although a few of the design decisions were based on time a lot of them were based on research.
Drive Mechanism
The drive mechanism for this project posed one of biggest challenges for me. At first when thinking of the requirements for such a mechanism, I had to think of devices that allready delivered the same type of functionality. My first thought was a softball launcher, similar to those used for batting practice or in a batting cage. The problem with this type of design was due to the fact that I couldn't hold the ball in place long enough to take a valid color measurement. My next idea was inspired by both the lottery machines (the ones shown on tv) and the gumball machines that you can find at any corner store. The idea for this is simple, allow only one ball to pass at a time by constructing a container that will hold exactly one ball and then emptying the container. I started mocking up a little diagram as to how this would work, and unfortunatly it became rather complex really fast. I instead decided to use a vending machine type of interface which allowed me the movement I needed while allowing me to hold and stop a marble on a dime.
Color Sensor
This peice was decidedly the most complex of the parts, mostly due to the fact that I have little to no experience with electronics. The first step for me was to do some research. I first started by looking online for comercially available products that would allready do what I needed. The result was that I couldn't really find any products that could give me the type of response that I needed for under one hundred dollars. Since I couldn't find what I was looking for, the next step was to research how color could be measured. This led me to three designs, the first of which involved theatre gels. The idea behind the gel, is that when a colored light is passed through the gel, the gel filters out the color that is not in its spectrum. So if I was on the other side of a green gel and a green light was passed through it, the light would appear rather white, while using the same green gel and passing a blue light the light would appear very dark. The problem with this design was more of an physical implementation issue. The results of this type of design would be just as accurate as the design that I choose, but I was having a hard time trying to think of a device I could create that would hold the gel in place in front of a photocell and then supply light. Scrathing that design, I looked online to parts suppliers and consulted Prof. Martin, who steered me in the direction of light sensitive LEDs. The idea with these is simply that a red led SHOULD be more sensitive to red light then green or blue, so having the light pass through an object and having a colored LED at the other side, you should be able to take a measurement as to the intensity of each of the colors. The flaw with this design was that I couldn't find translucent marbles, all of the marbles I had were solid colored, and when I tested it with reflected light, the response was not as strong as I expected. The final design I choose was to use a phototransistor with a reflective light scheme (as described above). I choose a phototransistor over a photocell because of an article I read online about the mean time between measurements with a photocell. The article talked about how because of the nature of the photocell it needed time to refresh it self between readings (approx 2 milliseconds) thus cutting in half the time you could read relative to a phototransistor. I switched my ideas right at the end because I was having problems getting my phototransistor to work, due to the fact that I was wiring it incorrectly. In order to compensate with the photocell, I took 3 readings for each color and averaged them together, delaying in between each of the three readings to account for refresh time. Although it slowed my color reading down, it allowed me to at least get a measurement. The final disapointment was due to the fact that the photocell seemed un-responsive to the color Green. Without that color, I had to rely on red and blue as my determinates which let to very tight boundries as to what was acceptable for each of the colors and thus un-reliable results.
Communication
My original intent was to have the cricket move the marble to a mark where it could get a measurement from a color sensor, then signal the logochip to read and send the color back over to the cricket. Unfortunatly I could not for the life of me get this to work. The cricket-bus seemed completly un-responsive. At this point I haven't done a lot of investigation as to why, but my initial feeling is that it was probably because I was trying to get it to work at three in the morning. For the Botfest, I set up a bank of 6 LEDs and just lit up a light coresponding to color of the marble that the LogoChip sensed.
Pictures
