Encoder Sensor Analysis

The goal of this analysis is to make a decision on buying the Lynxmotion SingleLine Detector (SLD) or the Hamamatsu Photoreflector (HAMP) to use in detecting the encoder pattern. Even from a qualitative point a view the decision is still not easy. The SLD is $14.95 and the HAMP is $2.20. If I go with the HAMP, I can purchase 2 more IR distance rangers. However, minimal external circuitry is needed to interface with the brainstem. While the SLD comes with three convenient wires that can be directly plugged into the brainstem. As far as mounting issues, the HAMP will be a little more difficult, since its pins are small and may need to be first mounted on a PCB.

The quantitative analysis will focus on the frequency response of the 2 sensors because I have mounted the encoder disk onto the high RPM shaft of the motor. I do not know the RPM of this shaft, but it is fast! First take a look at the 2 datasheets, HAMP datasheet and the SLD datasheet. Note that what I call the SLD datasheet is the datasheet for the IR sensor and not the User's Guide given here. After all the circuit will not be faster than the IR sensor.

Looking at the rise and fall times shown in the graphs of the datasheets, the worst cases are 1 milliseconds for the SLD and 4 microseconds for the HAMP. Figure 1 depicts the relationship between the pulses and the encoder.

figure 1

At the 'start' where the red arrows are and going in a counter clockwise direction, the voltage will be 0 corresponding to the reflectance of the white. There are 2 quantities of interest here. One is the rise and fall time of the pulse and the other is the length of the pulse. Since the SLD could take 1 ms to 'rise' to 5 volts when it goes into the black area and then 1 ms to fall back down to 0 volts, there could clearly be issues if our pulse was 2 ms wide. This could create either a triangle with an analog input or a missed pulse for a digital input. So without caring about the pulse width, I'll call this 2 ms for the rise and fall the theoretical limit. It should not be attempted to use the SLD sensor for anything near this speed or faster. The HAMP sensor had a rise and fall time of 4 microseconds, so each pulse will have a limit of 8 microseconds.

Next, we are concerned with what this translates into the fasted RPM that the sensor can deal with no regard on how the microcontroller will sample the signal (this will come later). For my case (and this will change based on encoder disk), I have 4 pulses per revolution as you can see in figure 1. This means the limit for the SLD will be 8 ms per revolution and for the HAMP it will be 16 microseconds. There are 2 rises and 2 falls for 1 revolution so multiply the rise/fall time by 4.

Finally, to get the RPM limit we need to convert microseconds and ms to minutes. Essentially, think that there are 8 ms per revolution so how many revolution can be done in a minute. First convert to seconds so this is 8 x 10^-3 seconds. Then convert to minutes so divide by 60 to get 1.33 x 10^-4 minutes per revolution, but we want revolutions per minute so take the inverse, which yields a theoretical limit of 7500 RPM. Doing a similar calculation for the HAMP, yields a limit of 3,750,000 RPM. Clearly, we want to stay away from this limit so choosing a 50% 'safety' margin gives a max of 3750 RPM for SLD and 1,875,000 RPM for HAMP. If I choose HAMP, the limiting factor will be sampling the sensor and not the sensor itself. However, the SLD is too close to risk so I'll be ordering the HAMP. Look forward to an article on interfacing this to the brainstem in the coming weeks.

Test 1: Mini Power Draw

The mini ran for 4.33 hours using an inverter on a 12 volt 18 aH battery. Divide the aH by the time so 18/4.33 and then multiply by the 12 volts to get an approximate 50 Watts of power. I had iTunes playing music and SETI running the entire time to tax the CPU and then 2 usb cameras plugged in. Overall, I think this is the upper bound because the battery I was using is quite old (4 years). I am going to pick up another battery and run the test again. Also coming soon will be CAD drawings of the robot layout using Sold Works. In the future, I'll try to convert this to an open source cad program, but for now I am trying to brush up on my SW skills.

Cold Feet

On the eve of the operation I realize I do not have the heart to splice the mac mini's power cord to accommodate the CNX-P1900. Carnetix says they are trying to acquire the funky power plug (estimated to be around Aug/Sep), which will leave the power cord intact. Since I have a long way to go before full operational capability, I will use an inverter for now. Tonight, I'll try and run an endurance test.

Return to Power

The mac mini is back from the shop. Apparently, the optical drive broke and they replaced it. The DC-DC converter also arrived so it is time to begin.

The Shaft Encoder Debacle

Someone once said that you should look before you leap. Clearly, he did not have the robot tinker gene. What started as a simple layer add on to accommodate the mac mini with a big battery, turned into a complete robot redesign. Ok, maybe not a complete redesign since I like my stacked platform layout (see picture below), but every system is getting a thorough examination.

Starting at the bottom I decided to upgrade my motor control capability. Originally, I thought my robot could do without precise relative positioning (i.e. dead-reckoning, INS). After all do you whip out a ruler and measure the distance to the door before opening it? I was convinced navigation could be handled without 'counting the inches'. Then I read the technical report "UMBmark - A method for Measuring, Comparing, and Correcting Dead-reckoning Errors in Mobile Robots" and realized I needed to come up with a better navigation plan. The paper made it clear that one must take advantage of absolute and relative positioning.

The only real option for relative positioning due to cost is dead-reckoning. So what do I do? I dive right in and start making shaft encoders without any analysis of the problem. I assumed there was nothing to worry about and the 43 pages in "Building Robot Drive Trains" about encoders equipped me with all the knowledge I needed. I should have known better. In all those pages there was no mention of how good an encoder needs to be to help feed dead-reckoning navigation. It may be elsewhere in the book but this is unacceptable. Before you decide to build shaft encoders, DO THE MATH!!! It is simple and can save you many hours of frustration. The technical report goes through the math, which is so simple Homer could do it. We will get to this later, but for now I will retrace my steps so others can learn from my misfortune. As the great philosophers at Despair, INC. informed us, "Mistakes - It could be that the purpose of your life is only to serve as a warning to others."

The first problem encountered and the reason why I so easily bypassed the need for encoders is how to attach a encoder pattern. I couldn't attach it to the 'rear' part of the shaft as you can see in figure 1.

figure 1

Although there appears to be room at the front of the shaft as seen in figure 2, the problem occurs when the wheel is attached.

figure 2

The wheel and hub assembly are shown in figure 3 and there is no room for adding an encoder wheel and a sensor because the air nozzle gets in the way.

figure 3

Luckily, a solution was available thanks to the one tool every robot builder must have, the dremel. I mounted the hub on this side of the wheel because the other side had some metal in the way as you can see in figure 4.

figure 4

I know I tried to remove this at one time and failed. Clearly, I did not posses the power of the dremel. I used up about 20 cutting wheels, but I sliced through that metal like a spork attacking a coconut. The upside to this modification, which otherwise would have been a waste of time , is that I can now easily pump up the wheels without removing them, since the air nozzle is now on the outside of the assembly. The intermediate result which is now obsolete is shown in figure 5. The details of making the encoder pattern was more onerous then dealing with Microsoft Windows, which is pushed on us by our evil IT overlords at work.

figure 5

Making the encoder pattern turned into the 2005 Memorial Day boondoggle. It has been a couple years since I used a graphics program for more than cropping pictures, but come on the pattern is simple. Well, I tried openoffice draw, power point, paint and a paintshop pro trial. I could not get the fill option to work. I created a circle with the correct dimensions. This is easy in openoffice and I could choose cm units from in the options. Then another joy happened when I found I could easily create a line segment, copy and paste it, then rotate to a desired degree. So 36 copies later I had a great pattern with a circle and 36 equal segments. So when I began to try and fill in the segments a thick fog of frustration settled in as I could not do it. I tried grouping and merging by selecting on 2 line segments and then the circle, but the fill never worked or it filled in the whole circle. The next course of action was to use the select tool and try to come close to selecting a 'pie piece'. No luck, it would never follow the line. After about 2 hours of frustrating trial and error with different programs I decided to print it out and color in the segments with permanent marker.

In the drive train book it mentions using transparency paper and a cdrom to help with reflection. So after gluing the pattern on a cdrom I built the circuit to test the IR sensor. For a while, I thought I was just choosing the wrong resistors but then I tested it with regular paper and the circuit worked. The problem is that the permanent marker still reflects. So I just replaced the transparency with regular computer paper and all was well.

Once the pattern was installed on the hub, I began to be curious about how good it will be. The simplest calculation involves the linear resolution. As one segment passes the IR sensor, how far did the wheel go forward or backward. First, look at the equation given in the UMBmark paper.

C_m is the conversion factor to translate encoder pulses into linear displacement. D_n is the nominal wheel diameter. n is the Gear ratio of the reduction gear between the motor where the encoder is attached and the drive wheel. C_e is the number of pulses per revolution. For my case D_n is 8.25", n = 1 since my encoder is attached to the wheel and C_e = 36 pulses per revolution (Just count the number of segments on your encoder). Performing the calculation yields 0.72" for C_m. This means if I measure one pulse the wheel moved 0.72" inches.

Is this good? Assuming my sensor does not miss any pulses and I go 10 feet (120") and having everything else perfect (no wheel slippage, uneven floors, etc.) I should expect to be +/- 0.72" for 0.72/120 or a 1.4% error. Not too shabby. Unfortunately, this hides the real problem and that is rotation. If my robot is to perform the UMBmark test it has to do 90 degree turns so I need to find out by angular error.

This is a very rough estimate, but it should reveal the problem. Assuming the distance from one wheel to the other is 15", then this is the diameter of my turning circle since my wheels are on the outside of the base. So if I am off by 0.72" on a turn as shown in figure 6, I calculated the angular error associated with this by taking the inverse tangent of the angle.

figure 6

theta = 5.5 degrees. Now this is a significant error. After three turns in the UMBmark test, the robot could be off by16.5 degrees from intended heading. So back to the drawing board.


The dremel came to the rescue again. After taking apart the robot there seemed to be enough room to shave off some hopefully unneeded backing in the rear of the motor. By shaving off the back, I bought about 3 mm on the end of the shaft (figure 7 shows this nicely).

Yipee, I can attach an encoder to the rear shaft and obtain all the resolution I need. This means the dominant errors for dead-reckoning will not be the encoders, but other things like uneven wheel diameters. The weekend is now over and it is time to rest. Next will come a battery test to see how long the mini will run on an 18 ah battery. Of course the mini needs to return from the shop and the power supply from mp3car needs to come in.