Unexpected results from Encoder::GetRate()

[Alan Anderson]

I'm confused. I'm getting the impression you don't understand how quadrature encoding works, but I can't believe that's the case.

Originally Posted by vamfun

So here is a thumbnail of the problem:
The two algorithms simply take the high road or the low road to rectify the count on a return trip. Taking the low road (joe) rectifies the count immediately on start of return, where the high road(chris) delays rectification until the return trip is completed. Joe's leads, mine lags.

The "Joe" algorithm doesn't lead; it tracks. The "Chris" algorithm is still off by one at the completion of the trip; it can't get back in synch until after the return trip is completed.

Joe's conveys directional sense by creating a high but erroneous initial rate, mine does not.

Why do you keep saying this? Maybe Joe needs to recap the FPGA rate computation for you. It explicitly does not compute a rate on the change of direction.

The problems occur in both algorithms because we are trying to describe position and speed states with one variable. At the initial reversal, joe's is good at showing direction at the expense of accurate position. Mine is good at position, but lousy at direction.

You are trying to describe position and speed with one variable for some reason I do not understand. Don't do that. The provided distance and rate values are two different things.

(And I think it's Joe's algorithm that accurately reflects the position, and it's your algorithm that has the inaccurate position issue, but we've been through that already.)

How did you guys use Kevin's type encoder algorithm that solved the oscillating edge problem? Was the encoder information used in a closed loop controller? Doesn't that algorithm use a "hysterical" scheme?

Kevin Watson implemented two different schemes for reading quadrature encoders, based on the different features of hardware interrupts on the PIC input pins. I used a routine that would count up and down as the phase A signal changed state; the other could be fooled into continually incrementing or continually decrementing at the noisy edge. It was indeed used for closed loop control, with two encoders being read to determine robot heading based on the difference in their values. (A third encoder provided odometer information. It was read by the simpler routine because it did not suffer from noisy rotational motion.)