Choosing an Encoder for the Drive-train

[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.