Quote:
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.
Quote:
|
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.