Unexpected results from Encoder::GetRate()

[vamfun]

Originally Posted by Alan Anderson

When the interrupt occurs is not related to when the program wants to know what the decoded position value is. Even though there might be perfect certainty at that instant, at the time the value is actually used the certainty is not guaranteed.

I agree, the error can be any value [0 to 1] when the program wants the data, and this is exactly why I qualify my statements to the interrupt time.

I think we all understand the problems associated with quantization and my characterization of the error is perhaps clouding the discussion a bit too much.

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. Joe's conveys directional sense by creating a high but erroneous initial rate, mine does not. Joe's lead hurts if the return never occurs because of a reversal. Mine gets in trouble if the return occurs quickly since I delay the rectification count ,however, if there is a reversal, mine then creates a smoother transition since I never changed direction.
Mine creates delay which makes control more difficult. It creates a control dead zone of +_ 1 count.

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.
The quadrature encoder gives us access to the B channel which allows us to know both position and direction on a same edge reversal. I'm thinking about creating a GetState() which outputs the position ,direction and speed states at the edge event. I suspect this would be close to using joes GetDistance(), GetRate() output pair , but slightly different algorithms.
I'll post more when I've done a little more thinking.

Are you basing your preference for the "hysterical" scheme on naive rate calculations? You can put that concern aside, as the FPGA does not produce the rate spikes you were worried about.

Hmmm, I thought Joe's actual algorithm showed that differentiated GetDistance() outputs would be a problem with an oscillating edge and that the GetRate() would not. The naive rate calculations are used in the WPI PID routines so teams would have to be careful to source the rate from the GetRate() rather than the error function fed to the PID routine.

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?