Unexpected results from Encoder::GetRate()

[vamfun]

Originally Posted by Alan Anderson

You don't know that. You know you have traveled at least one tick. You might have traveled almost two ticks. That's what the [1 .. 2) notation Joe used means.

What you know is that you are between the first and second marks.

You were at the second mark for a moment. Until another edge occurs, you don't know precisely where between the first and second marks you
are.
The number that a quadrature decoder yields does not represent an edge. It represents a region between edges. Does that help you understand the explanations here?

Alan, all my comments are referenced to when an interrupt occurs. There is no uncertainty at that time except for what happens during the interrupt processing time. Again, I am focused on the relative accuracy and if you believe the new edge events and use them as a reference, the same edge event will cause a 1 cnt error with joes scheme and not mine.

It is reasonable to consider the true quadrature algorithm to have a maximum error of a half count either side of zero. Again, this is typical of an optimum quantization process.

Yes, it is reasonable... then both algorithms would be better on an absolute scale. But when considering relative distances which you encounter with dead reckoning, won't there will always be the 1 count max error?

Alan: What rate spikes? I think you missed the part where the FPGA doesn't compute a rate until two events have occurred in the same direction.

Joe:This is why I was interested in the algorithm you are using. If you are counting events between fixed times, then you can compute a rate with no events. If instead you are measuring the time between events (as the FPGA does), you must have monotonic events.

It also seems to me that your algorithm will give a false speed...

Lets say the true shaft is 0.4 when you make your first speed sample. You then move to 1.4 and then back to 0.4 to take your second speed measurement. Your encoder will have changed from 0 to 1, so your speed will report forward 1 tick / period. My algorithm will report 0 speed.

Am I missing something?

In my mind , I was picturing a user derived rate on the GetDistance() output which rookie PID users might encounter using the WPI PIDController.cpp routine. I will post some discussion on Joe's example and propose a GetRate() for my algorithm a little later.