Choosing an Encoder for the Drive-train

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