Unexpected results from Encoder::GetRate()

[vamfun]

Originally Posted by jhersh

Aside from the fact that your algorithm has a different value at the same position depending on the direction of approach, I must also point out that the mapping of "true to encoder" is arbitrary and is chosen to optimize for accuracy. What I mean by this is you have chosen that the code "1" represents true [1 .. 2) where as I would argue that the code "1" represents true [0.5 .. 1.5). Hence my algorithm is more accurate than yours given that definition.

I beg to differ again.... what is important is the relative accuracy and that is referenced to the new edge ticks. When a new edge is detected, a mark is made in the sand. You travel one tick to another new edge. You make a second mark in the sand. You know that you have traveled exactly one tick from your first mark. If you now reverse slightly and get a same edge indication... you will always say that you are at the 1st mark when indeed you know that you are not. Hence no matter what the relative scaling, when a reverse edge occurs... my algorithm will always be better than yours since its says I'm at the second mark which is indeed where I am.

So there is no uncertainty here... you are purposely causing an error of 1 tick but it is warranted because it signals to whomever is watching that you have reversed direction which allows tighter control. My algorithm lacks that signal so the control must be delayed until a new edge is detected. I believe that if a "direction" sense was outputted from a decoder with my algorithm, one could design a controller that would not suffer the hysteresis problem while not needing to cause an error on a same edge event.

I think we all agree that both algorithms will have a max error of 1 count and this will occur at different times. If you demand exact repeatability with angle, then Joe's is the way to go. However, it introduces large rate spikes when oscillating over an edge. Mine will always be 1 count different on the return trip, but it tolerates an oscillating edge and its control can never be tighter than +_1 one count.... unless modified to output a direction sense (TBD). With today's high resolution encoders, a 2 count error band might be very acceptable.

Again, I contend that the definition of speed is distance per time. Distance is the difference between two positions. If the encoder reverses directions, then the only thing I know about the distance is that it is somewhere between (0 .. 2) counts of the encoder. I effectively have no (known) distance. How, then, can I claim to compute a speed with no distance?

With my algorithm, the "average" speed at a same edge is zero because the "known" distance between the last two edge events is zero no matter how long it took to get them.

[jhersh]

Originally Posted by jhersh

I'm not clear on what algorithm you are using to compute the rate in software. Depending on what you are using, this may or may not be a moot point or have other issues. Please describe what you are using.

Originally Posted by vamfun

With my algorithm, the "average" speed at a same edge is zero because the "known" distance between the last two edge events is zero no matter how long it took to get them.

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?

-Joe

[Alan Anderson]

Originally Posted by vamfun

I beg to differ again.... what is important is the relative accuracy and that is referenced to the new edge ticks. When a new edge is detected, a mark is made in the sand. You travel one tick to another new edge. You make a second mark in the sand. You know that you have traveled exactly one tick from your first mark.

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.

If you now reverse slightly and get a same edge indication... you will always say that you are at the 1st mark when indeed you know that you are not.

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

Hence no matter what the relative scaling, when a reverse edge occurs... my algorithm will always be better than yours since its says I'm at the second mark which is indeed where I am.

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.

I think we all agree that both algorithms will have a max error of 1 count and this will occur at different times.

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.

If you demand exact repeatability with angle, then Joe's is the way to go. However, it introduces large rate spikes when oscillating over an edge.

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.





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?

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

[Alan Anderson]

Originally Posted by vamfun

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.

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.

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.

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.

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

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

[vamfun]

Originally Posted by 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

Sorry for the confusion...Its funny, I know we have the exact same picture in mind, but choose to describe it so differently. So I will break the limit cycle in interest of your sanity and perhaps any readers and not try to re clarify.

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

Did your decoder also use B phase to halt the continuous counting similar to Kevin? If so wouldn't it have incorporated a type of hysteresis?

Probably at that time you did not have a need for special rate processing of your decoded heading unless heading rate was involved in your loop...right?

[EricVanWyk]

I really hope that I can end this thread with this post, but I'm not holding my breath.

Lets examine the Rate and Position functions separately - assume that selecting one implementation of Position does not necessitate selecting the matching implementation of Rate.

Position
JoeMethod -
. Error is bounded to [-.5, .5]
. Uncertainty is bounded to [-.5, .5]
. Position is repeatable (no hysteresis).
ChrisMethod -
. Error is bounded to [-.5, .5]
. Uncertainty is bounded to [-1.5, 1.5]
. Position is dependent on direction (hysteresis).

View the position as a circle divided into quadrants. A true quadrature decoder tells you which quadrant you are currently in. You then make the optimal assumption that you are right in the middle of that quadrant. Thinking in terms of assuming that you are on the border is non-optimal. Joe will always report the correct quadrant. You will be off by one half of the time, depending on which direction you are traveling.

As far as I'm concerned, that is a clear win towards using an actual quadrature encoder, such as the one currently implemented.

Arguments as to 'free hysteresis' are bunk as far as I'm concerned. I don't want features that belong in my controller sneaking into my sensor. Tell me what is happening, and I'll work with it from there.

Rate
JoeMethod GetRate
. Given an oscillating edge, no rate is reported
JoeMethod GetPosition+hand derivative
. Given an oscillating edge, the correct rate is reported for the time period.
ChrisMethod
. Given an oscillating edge, zero rate is reported.

These all stink in their own way. But, none of them report rate "spikes". I'd rather get the GetPosition delta at fixed time intervals as rate, if I could choose.


I'm not saying that every aspect of the FPGA is perfect, but I will assert that the encoder implementation is what I hoped it would be. If it was implemented per your suggestion, I'd be disappointed.

[vamfun]

Originally Posted by EricVanWyk

I really hope that I can end this thread with this post, but I'm not holding my breath.

You can't get off that easy
Personally, I would like to see it end with Joe's report on the GetPeriod() problem. Your summary is a nice place to break on the algorithm discussion subject but I would feel better about the table with the following amendments:

Position
JoeMethod -
ChrisMethod -
. Uncertainty is bounded to [-1.5, 1.5]

Uncertainty is bounded to [-1., 1.]

Rate
. JoeMethod GetPosition+hand derivative
. Given an oscillating edge, the correct rate is reported for the time period.

JoeMethod GetPosition+hand derivative
. Given an oscillating edge, an amplified rate is reported for the time period.


I rationalize this as follows: If the true oscillating edge amplitude is A , it will always cause an average GetPosition() oscillation amplitude of 0.5. Since this is a single edge oscillation, A < .5 , so any rate derived will be amplified by a factor of .5/A. E.g. A = .05 will amplify by 10 the true rate. This is the main reason that the Joe rate method and mine are in the ball game is to prevent these amplifications from tainting the rate output.

These all stink in their own way. But, none of them report rate "spikes". I'd rather get the GetPosition delta at fixed time intervals as rate, if I could choose.

One might characterize the above amplified rates as spikey behavior if viewed on a plot but its not important.

I'm not saying that every aspect of the FPGA is perfect, but I will assert that the encoder implementation is what I hoped it would be. If it was implemented per your suggestion, I'd be disappointed.

I too would be disappointed if the current algorithms were not available since most of my control work would be happy with them.

What I would like, though is an option to modify the algorithms which I could do if the A/B interrupt count and timing was transparent. But Joe /Ni have elected to not make this code open source. We can write our own routines from scratch, but I would be satisfied if a GetEdgeState() function was implemented that provided edge count, direction and time_since_last_edge for the 1x case. This state captures all the information available from the A/B channels and could be easily modified to create whatever distance/rate algorithms you wanted. One could argue that these are available with GetRaw(), GetDirection() and GetPeriod() or their visible subfunctions.. but if called in sequence, I don't think they can guarantee to be synchronized to the same edge event. Maybe Joe can comment on this.

[Alan Anderson]

Originally Posted by vamfun

JoeMethod GetPosition+hand derivative
. Given an oscillating edge, an amplified rate is reported for the time period.

I rationalize this as follows: If the true oscillating edge amplitude is A , it will always cause an average GetPosition() oscillation amplitude of 0.5. Since this is a single edge oscillation, A < .5 , so any rate derived will be amplified by a factor of .5/A. E.g. A = .05 will amplify by 10 the true rate. This is the main reason that the Joe rate method and mine are in the ball game is to prevent these amplifications from tainting the rate output.

I have no idea what you're trying to say here.

[vamfun]

Originally Posted by Alan Anderson

I have no idea what you're trying to say here.

Here is pseudo simulation code that I would write to illustrate the error amplification

Param: 
T = edge oscillation period
A  = edge oscillation amplitude
dt = T/20,  sample rate small enough to measure oscillation
variables: 
t = time,
x = encoder input
y = encoder output
x_dot = encoder input rate 
y_dot= encoder output rate

Run Simulation:
while(t < runtime){

Encoder input movement:

x = A*sin(2*pi*t/T); Small oscillation movement , A < 1 to be on same edge.

x_dot = A*2*pi/T*cos(2*pi*t/T)

Encoder output change when x is centered on a threshold:

If(x > 0 ) {y = .5 }   //sample
else {y = -.5 }

y_dot = (y-y_last)/dt   //Derive simple rate 
y_last = y;
t= t + dt;
}

Expected Results:
The output amplitude will oscillate between -.5 and .5

The amplitude ratio y/x = .5/A.

peak |y_dot| = 1/dt,

average |y_dot| = 2/dt/(20)= 2/T Average over oscillation period



Then (avg |y_dot|)/(x_dot amplitude) = 1/(A*pi)
(this is slightly less than my .5/A approximation.)

[jhersh]

Originally Posted by vamfun

What I would like, though is an option to modify the algorithms which I could do if the A/B interrupt count and timing was transparent. But Joe /Ni have elected to not make this code open source. We can write our own routines from scratch, but I would be satisfied if a GetEdgeState() function was implemented that provided edge count, direction and time_since_last_edge for the 1x case. This state captures all the information available from the A/B channels and could be easily modified to create whatever distance/rate algorithms you wanted. One could argue that these are available with GetRaw(), GetDirection() and GetPeriod() or their visible subfunctions.. but if called in sequence, I don't think they can guarantee to be synchronized to the same edge event. Maybe Joe can comment on this.

This is yet another demonstration that there has not been enough time for code or documentation. The whole point of the DMA engine is to provide you with information in a synchronous packet. I believe that with the Interrupt and DMA together you can accomplish everything you described or intended.

Here's how:

The DMA packet contains the position, direction, period, and "stalled" indicator (the configurable counter-inactivity timer). Each packet also includes a timestamp. You can configure DMA packets to be sent periodically or you can configure a digital source as the packet clock. If you use one of the encoder phases as the packet clock, then you can just use the timestamp in the packet for your timing. If you hook the packet clock to some unused digital output, you can request DMA packets on demand. You can also use periodic timing and use the distance and direction only. You can also hook one or both of the encoder phases to interrupts. This will not only notify your code, but also timestamp the event (using the same timestamp source as the DMA packets) so you can compare the timestamps of interrupts and DMA packets as needed.

That being said, the one that is built in for you is WAY easier to use so at least for me I would have to have a pretty big problem with that implementation to want to reimplement it on the RTOS using DMA and Interrupts. The reason for including DMA and Interrupts was to make the system be super flexible to support interesting sensor interface requirements.

BTW, you can get the same results that you get with your algorithm by simply adding 1 to the distance if direction is false with the built-in counter and you don't need any of that fancy stuff. But it will be worse!

-Joe

[jhersh]

Originally Posted by vamfun

You can't get off that easy
Personally, I would like to see it end with Joe's report on the GetPeriod() problem.

I haven't gotten around to evaluating what the problem is with that just yet. Perhaps if I'm bored this weekend I'll find some test hardware and dive into it.

-Joe

[Alan Anderson]

Originally Posted by vamfun

Expected Results:
The output amplitude will oscillate between -.5 and .5

Ignoring for a moment the oddness of deciding that the measurement will always end in 0.5, that is the optimum result. It matches the resolution of the sensor. It's as good as it gets. You have no way of knowing whether the true amplitude is less than that, or greater than that (but less than +/-1).

Anyway, so far as I can tell, your proposal is worse than what you're pointing out here. Ignoring the first edge after a change in direction gives an unchanging output for any input oscillation amplitude less than 1, right?