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.