Choosing an Encoder for the Drive-train

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