Choosing an Encoder for the Drive-train

[MikeDubreuil]

From my research on the forum it appears the best method for counting rotation in the drive-train is to use an encoder. This year, I’d like to start integrating an encoder during the preseason to become more familiar with them. Unfortunately, choosing an encoder can be a daunting task. Browsing the Digi-key catalog brings more questions than answers.

Optical or mechanical?
PC mount or cable?
Is one manufacturer better than others?
How much resolution will I need?
How much resolution is the robot controller capable of handling?

If anyone can provide answers to those questions, or perhaps post their experience with a certain model of encoder it would be greatly appreciated. Thanks.

[Alan Anderson]

KatsKlaw (team 45's 2004 robot) used Banner sensors pointed at black stripes on the wheel hubs. For initial testing, we had six evenly spaced pieces of electrical tape, alternating with nicely reflective aluminum. The RC had no problem keeping up with the relatively slow signal and its correspondingly coarse resolution. The resolution ended up being just under three inches of linear travel on the field, or about ten degrees of turning in place. That turned out to be plenty for what we needed, so we never tried making it more precise with additional stripes.

For something like closed-loop speed control, more precision is desired. We intend to play around with prototype drive bases for the next couple of months, and rotary shaft encoders might be an option. From what I've seen, building one with optical sensors and a slotted disk is probably going to end up being cheaper than buying one.

[Gary Dillard]

Somebody recently posted a similar thread in the programming forum, without too many takers:

http://www.chiefdelphi.com/forums/sh...=shaft+encoder

Maybe you'll have better luck here with the hardware guys. We've got lots of experience, and depending on your point of view it's good or bad. They work most of the time, but it's that small percentage of time they don't that we've gotten our butt kicked. Because of their location at the stiff wheel structure they're susceptible to high shock loads so we've had alot of failures (either electrical or alignment) at critical points in the match. I'll have to defer to my controls team to give you the specifics on which models we've tried and why - I'll make sure they see this thread.

[Mark McLeod]

We used a set of high quality encoders. They're on the expensive side (~$50 Grayhill series 63R), and they are overkill. We wanted one that was very dependable and wouldn't fail. We plan to use them for a long time. It's guaranteed for 10 years of continuous use at 5000rpm. They are available in a variety of counts per revolution, but digikey (newark also has them I seem to remember) only stocked two variations (128 & 256). There is also a version with a connected ribbon cable and another that's just pins. I prefer the ribbon cable. We bought the 256 variant just so we'd be able to use the higher resolution for other purposes if we so chose. 128 cpr would have still been more than enough for shaft encoders. We used plastic gears to connect them to the shafts and geared them down so we got approximately 2500 counts per second at top speed of ~9fps (~.044" per count I think).

Never failed or hiccuped. We've run them all through competition and through the summer autonomously.

P.S. I suppose I should have posted in the other thread, but I was traveling when that went by.

[edit] (There's always something I think I should add)
We do have a banner quadrature setup on the arm using a printed strip of black & white. Really more of a demonstration than a practical usage. The best resolution possible due to the arm speed, the width of the banner beam, and the length of the arm gave us about one foot, at the far end of the arm, between ticks.

[team222badbrad]

This company seems to have a good selection.

http://www.usdigital.com/

They also have very helpful customer service. A while back I asked them all about encoders and they answered my questions. This website also gives you an encoder glossary.

http://www.usdigital.com/knowledge/glossary.shtml

I think we are going to get them from this company this upcoming year and stop using the Banner sensor to count rotation.

[andy]

I actually just did this

Lemme run you through some of the math first, (these numbers may, scratch that, will change depending on your algorithm and a bunch of other factors)

So our programmer wizzes have told me that the minimum number of "ticks" (not counting double if you have quadrature output) to be a minimum of ten ticks per second (10 hz) for the PID to be effective so... what does that mean?

First, we need a few paramaters about your robot, I will use our robot from last year as an example. Our robot had 12 inch diamater wheels, and maxed out at about 10 feet/sec and (let's assume) a minimum effective speed of about 1/2 ft/sec. Our center of rotation was about 8 inches from the front of our robot. We need to be able to measure speed accurately down to zero feet/sec. Also, the encoders are mounted on the output stage of the gearbox to eliminate confounding due to backlash. Common encoder values are 32, 64, 128, 200, 250, 256, 500 and 512 counts/revoloution, before they get prohivitably expensive.

So, the wheel circumfrance is pi * diamater => 12pi ~ 38 inches. Minimum effective speed is 1/2 ft/sec or 6 in/sec. This gives us 6/38 rotations/sec or roughly .158 rotations/sec. Therefore, we need 10 ticks to occur in .158 of a rotation each second.

Using a simple proportion, we find .158/10 = 1/x or 10 = .158x and 10/.158 = x. This gives us roughly 64 ticks/rotation minimum.

So that's all fine and dandy, but lets look more at the math. 64 ticks only gives us 38/64 ticks per inch or roughly one tick every .568 inches. That kinda stinks. Also, with two motors on opposite sides, that could produce up to twice that error! So one tick every 1.2 inches!!! Even worse, the angular error, as a result of that, is tremendous!

How can we solve that?? We can do many things, go to larger resoloution encoders (we did that and used 512 grayhill encoders - which give us about one tick per 1/3 inch), go to smaller tires, place the encoders higher up in the drivetrain, or use a seperate system (with smaller seperate wheels and maybe geared up output).

All of that is still not entirely perfect, slippages (burnouts!) can and will occur. The gearboxes will not be entirely symmetric. Remember, the motors produce more power in one direction then in the other, build your gearboxes as mirror images, not as duplicates. Also, if you use pnumatic tires, differences in the wheel's circumfrance will signifigantly alter calculations (and make your robot asymmetric - ie. doesn't drive streight).

Again, this will vary greatly based on algorithms etc. This is a specific application and your results may vary.

*the math is kinda sketchy, look for a revised set of calculations later*

good luck!!

-Andy

PS, the spellcheck does not seem to work in firefox, so pardon the errors

[MikeDubreuil]

There's a lot of great information here. Thanks a lot.

I'm trying to determine the maximum number of encoder pulses.

If I have a robot with an 8" wheel, the maximum speed being 10 ft/s and 128 Encoder Counts/Revolution. For this example let's pretend the encoder is connected to the same shaft as the wheel.The maximum number of pulses the encoder could generate would be 611. Is my math correct?

How would this be programmed? As a counter in the fast loop or as an interupt? Can the controller handle this many interupts per second?

[Kevin Watson]

Originally Posted by MikeDubreuil

There's a lot of great information here. Thanks a lot.

I'm trying to determine the maximum number of encoder pulses.

If I have a robot with an 8" wheel, the maximum speed being 10 ft/s and 128 Encoder Counts/Revolution. For this example let's pretend the encoder is connected to the same shaft as the wheel.The maximum number of pulses the encoder could generate would be 611. Is my math correct?

Yep.

How would this be programmed? As a counter in the fast loop or as an interupt?

At the rate you're generating pulses, you'll do better with interrupts. Ideally, you'd want to dedicate some hardware to keep track of the pulse count. This could be done with a binary up/down counter as an example.

Can the controller handle this many interupts per second?

With an efficient Interrupt Service Routine you should be able to do this (I've done it). Be aware that troubleshooting an errent ISR requires a thorough understanding of the underlying hardware and the machine code the compiler has generated for you.

If you have EE leanings, you might consider an FPGA-based prototyping board like this one from Xilinx for your design.

BTW, do you really need 1/5 of an inch worth of resolution?

-Kevin

[Mark McLeod]

Originally Posted by MikeDubreuil

... Can the controller handle this many interupts per second?

Our system does 5000 interrupts per second during normal top speed without any problems. We chose 5000 somewhat arbitrarily as a target value to make sure we stayed well within the capabilities of the RC and the encoder. The delays due to the ISR were measured at max. freewheeling speed (probably ~20fps or ~10000 interrupts per second) and we weren’t pushing the limits of the PIC, but I’m afraid I no longer recall what those numbers were. I’d have to go measure again.

I have to admit I like the high resolution counts purely for the smooth PID curve it helps produce. But it is way overkill. The inaccuracy due to normal play in the drivetrain and loss of accuracy due to minute differences in left/right wheel sizes are probably much greater than the ridiculously small .044” we measure. The greater resolution does, however, profile trends very well and that makes for very smooth PID correction.

We did the theoretical calculations to give us the ballpark figure correlating distance to encoder “ticks.” However, after you’ve mounted and installed your new encoders you need to calibrate them. As mentioned earlier, distance will depend, for example, on how inflated or worn your tires are.
We marked a starting point on the encoder gears (both sides) so we’d have physical confirmation of our results, and we used a debug statement in the code to printout the current encoder count. The machine was then rolled some distance much greater than the circumference of the wheels, all the while watching that mark and counting the number of complete revolutions making sure to stop on the mark so you don’t have a fractional number of rotations. We verified that what we physically saw matched the encoder readings and used a tape measure (again both sides independently) to get a distance to divide the encoder ticks by. The physical check just verifies that the code is counting the encoder ticks as we expect.

-------------------
This may confuse the issue, but as an interesting aside to the use of the Grayhill type of encoder and interrupts, an encoder rated to return 128 counts per revolution (cpr) assumes the use of only “output A” (using the spec sheet I posted previously for an example), and triggering an interrupt only on the rising edge of output A.

You can double the effective resolution (a 128cpr encoder will give 256cpr) by alternating the interrupt trigger within the ISR to tick on both the rising and the falling edges of output A.

Further, you can quadruple your effective resolution (a 128cpr encoder will produce 512cpr) by also interrupting on “Output B” and triggering on both rising and falling edges.

Note: I don't recommend interrupting on both Outputs A&B and only on rising edges, since "ticks" would then vary in distance rather than be of constant length.

[MikeDubreuil]

Originally Posted by Kevin Watson

With an efficient Interrupt Service Routine you should be able to do this (I've done it). Be aware that troubleshooting an errent ISR requires a thorough understanding of the underlying hardware and the machine code the compiler has generated for you.

BTW, do you really need 1/5 of an inch worth of resolution?

I think I have a good idea on how to develop an effecient service routine. Plus, your interupt example is a great starting point, thanks. As far as getting 1/5" resolution is concerned: I probably won't need resolution that accurate. However, although it was only an example, as long as the controller can handle it I would like to have as much resolution as possible.

Originally Posted by Mark McLeod

The greater resolution does, however, profile trends very well and that makes for very smooth PID correction.

Yeah I agree. I do not have a lot of practical experience with the PID loops. I've just done some math on a notebook and what you're saying agrees with the math. This year I'm hoping to bring PID to the team.
I like the way you tested the encoders accuracy, I will have to implement a similar test.

[MikeDubreuil]

Originally Posted by Alan Anderson

From what I've seen, building one with optical sensors and a slotted disk is probably going to end up being cheaper than buying one.

Cost really isn't a consideration as long as we stay within FIRST guidelines. We hardly touch our additional electronics budget.

[eugenebrooks]

We used banner sensors this past season, looking through slots at reflective tape strips put on the black rims of the kit wheels. The light/dark transitions were tracked in the fast loop and the RC was capable of keeping track of the pulses. The only real issue is the possibility of missing pulses while "not" in the fast loop, and if this is a problem, use a timer interrupt fast enough never to miss a transition. This was never a problem for us in practice, but you could demonstrate the issue in high speed with the robot free-wheeling on blocks. We put 72 strips on the wheel rim, providing 144 transitions, or 2.5 degree resolution for wheel rotation. This was about 1/4" on the floor. I have posted the code that supported the sensors in the past, and it can be found in the archives.