Webcam

This webcam uses a special encoder wheel (see below) to automatically determine its position and correct for misreads with the light sensor. It also uses just one sensor to determine its position, instead of using a sensor and a touch switch as a limit sensor.

The last version of my webcam used just a black and white encoder wheel, with every other wedge being black. This worked fairly well (still had the occasional misread) for knowing that the camera had turned, but there was no way of determining the position of the camera. I had added a touch sensor as a limit switch, and when the program started it would turn all the way to the touch sensor to reset itself, but after a misread or two, it would lose track of where it was.

I had used rotation sensors combined with touch sensors as a limit in an even older webcam, but the rotation sensors just don't have enough resolution, so I had put them right off the motor and had geared down to move the camera. But after moving back and forth a few times the gear slop would cause the sensors to lose track of where things are. This happens because when the motor changes direction, the counter is going even though the camera may not actually be moving yet. After changing direction a few times this error accumulates.

The other night I was trying to figure out if there was any way I could use different gray levels on a wheel to determine my position just from looking at the wheel. Since the light sensor has such a limited range and fluctuates a little on each color, there was no way I could make a wheel that went from black all the way to white in small steps. Then I started thinking about the possibility of having to read 2 or 3 wedges in succession and thereby determine a position. This meant that if you took any of say 3 successive wedges, that pattern would only occur in that one place. The fewer wedges the better, it would mean less rotation necessary to find out where the camera is.

I cobbled up a program that would figure out all the possible combinations of 4 colors (black, dark gray, light gray, white) over 3 wedges, eliminate all the ones where two of the same color are touching, and then try to sort them so that they overlap by 2 wedges. 4 colors with 3 wedges is a good choice, because it gives 36 total combinations (4 x 3 x 3). I soon found I was going to have to use a recursive algorithm.

I finally came up with this wheel, and as you can see, any group of 3 wedges occurs in only one spot. Unfortunately, there's no pattern to the order. This means I have to use a lookup table to convert color groups into positions. This is where the biggest part of the problem comes in, there's very limited variable space in the LEGO RCX operating system. I was able to pack one version of the lookup table into 6 integers (36 two bit numbers with only 14 bits per integer used to avoid the sign bit). The other lookup table is hard coded as a function, which allowed me to have 64 elements and not have to resort to some crazy looping and unpacking scheme.

Click on the picture to get the LDRAW dat file, the NQC source, and the encoder wheel as a PDF and Illustrator EPS.

The RCX program accepts messages from 1-255. If the high-bit is set, it's an indicator to pan, instead of tilt. The lower 7 bits are interpreted as a 2's complement number, giving me a range of +63 to -64.