|
|
|
![]() |
|
|||||||
|
||||||||
![]() |
| Thread Tools |
Rating:
|
Display Modes |
|
#46
|
|||
|
|||
|
Re: Unexpected results from Encoder::GetRate()
Quote:
Quote:
Here you have disconnected the rate from the position signal temporarily. This is why I like Kevin's or my approach .. since it doesn't require this and yet maintains the same accuracy if what I said above is true. Quote:
Please, please, please put these algorithms in the code documentation at the nearest opportunity. I don't want to spend the rest of my retirement slowly extracting this information on our CD threads ![]() Last edited by vamfun : 20-04-2010 at 15:40. |
|
#47
|
||||
|
||||
|
Re: Unexpected results from Encoder::GetRate()
Quote:
Quote:
Quote:
By allowing the oscillation in position, you are penalizing those who derive rate from position with unwarranted errors that you corrected for in your GetRate(). Quote:
It seems reasonable therefore to simply apply the same logic to the position as you apply to GetRate() and force the position to match the rate. Aside: I was only partially correct a while back when I said that the x2 and x4 were not edge oscillation sensitive.... they will not increment continuously but they will oscillate between increment and decrement as the x1 case because of the way your algorithm works. Right? Users who are listening... is this a bug in your minds? Last edited by vamfun : 23-04-2010 at 03:40. |
|
#48
|
|||
|
|||
|
Re: Unexpected results from Encoder::GetRate()
Quote:
Quote:
Quote:
-Joe |
|
#49
|
|||
|
|||
|
Re: Unexpected results from Encoder::GetRate()
Quote:
Your scheme and mine will both have 1 count ambiguity...it just occurs at different times. I am interested in the best estimate of angle not just the count. I am showing a preference to have the best estimate at edge reversal rather than a count later. I can do this because of B channel information. Lets take a simple 1 deg resolution encoder. We start with 0 angle, rotate to 1.1 deg and reverse to .99 and continue back to .1 and eventually back to 0. Error = true - encoder Angle..joe count/chris count... joe error/chris error 0.0..0/0....0/0 1.1..1/1... 0.1/0.1*****tie 0.9..0/1...0.9/-0.1*****chris wins 0.5..0/1...0.5/-0.5*****tie. 0.1..0/1....0.1/-0.9*****joe wins 0.0..0/0.....0/0******tie So if we are oscillating in a band about the 1 deg edge [.9 to 1.1], my algorithm will give a better estimate of angle position on reversal and we are the same going forward past 1. My rate will be zero without special compensation when oscillating in band, yours needs compensation to avoid huge rates with high frequency small amplitude oscillations (see Edit). Likewise, if we oscillate about the 0 deg edge or any edge. So the reason for introducing the hysteresis is to avoid the rate spikes associated with the edge oscillation without giving up anything on accuracy. I.e. both have the same maximum error , just shifted in the cycle. Edit: Refer back to the above example and assume a small oscillation about the 1 deg edge with .1 deg amplitude at 10 rad/s. The truth rate amplitude should be 1 deg/s. Mine will be 0 yours will be (1*10) deg/s. The error in rate estimate for mine will in general be A*w , yours will be (1-A)*w where w is the frequency (rps) and A is the angle displacement amplitude. The ratio between our errors (joe/chris) is roughly 1/A for small A. Therefore , very small amplitude vibrations can cause very large differences in accuracy. E.g. A =.01 ... your error can be 100 times mine. In absolute terms, my error will be equal to the truth amplitude (100%) , while yours will be 100%/A. This you know and that's why you compensated for this effect in GetRate(). Using the hysteresis scheme, this is automatically compensated for in the GetDistance() count hence no compensation is required in GetRate() if you just divide the count by the count period. Quote:
Quote:
-Joe Last edited by vamfun : 24-04-2010 at 04:10. |
|
#50
|
|||||
|
|||||
|
Re: Unexpected results from Encoder::GetRate()
Quote:
Quote:
You also left out all of the samples that would reveal that yours gives different values for the same position depending on where it came from. For measuring position, I do not believe hysteresis is a positive attribute. |
|
#51
|
|||
|
|||
|
Re: Unexpected results from Encoder::GetRate()
Quote:
Good to hear from you Alan. I am primarily addressing the 1x decoding of a quadrature encoder. So we have two channels to make the best 1x estimate. We are using 1x to minimize the rate errors associated with extra edge phase noise found with 2x and 4x decoding. So please evaluate my comments in this regard. The 1 deg resolution is identical to the kit 360 count encoders. The comparison is between Joe's 1x and my 1x. The example doesn't favor either but is designed to illustrate the differences in the two approaches, so it focuses on the edge reversal. If there isn't an edge reversal, then the two schemes are identical. You can start anywhere on the cycle... at the exact point where the edge reverses, Joe's error will have a max 1 count error (ambiguity) and mine will be zero. As the reversal continues toward the next edge, Joe's estimate gets better and mine gets worse. If you look at the example carefully, you will notice that the max distance error is the same for both and will not exceed the resolution. If the Kevin W. algorithm was implemented as I discussed earlier in the thread , I believe it would produce the same output as my 1x case. So I thought I was arguing in your favor. Quote:
Let's nix that "hysteresis" word, since it only applies to same edge reversals not all reversals and may be confusing. Last edited by vamfun : 24-04-2010 at 16:04. |
|
#52
|
|||||
|
|||||
|
Re: Unexpected results from Encoder::GetRate()
Quote:
Quote:
|
|
#53
|
|||
|
|||
|
Re: Unexpected results from Encoder::GetRate()
Quote:
You are right.. they are the only kind... But the hysteresis is cleared up as soon as the next count comes in without another reversal. In a normal hysteresis, this doesn't happen. This is what I meant by possible confusion. Do you still feel that the value should be the same going up as down for the 1x case as discussed in post 51? If so .. can you think of a counter example that illustrates your concerns with my logic? This goes for Joe too. Last edited by vamfun : 24-04-2010 at 21:24. |
|
#54
|
|||||
|
|||||
|
Re: Unexpected results from Encoder::GetRate()
Quote:
Quote:
|
|
#55
|
|||
|
|||
|
Re: Unexpected results from Encoder::GetRate()
Quote:
1x Decoding example of a quadrature encoder Lets take a simple 1 deg resolution encoder. We start with 0 angle, rotate to 1.1 deg and reverse to -.9 and then reverse again and go forward back to 0. Error = true - encoder Angle..joe count/chris count... joe error/chris error fwd 0.0..0/0....0/0********tie 0.5..0/0....0/0********tie 1.0..1/1... 0/0 New edge event (joe and chris increment)****tie note:joe and chris in sync 1.1..1/1... 0.1/0.1*****tie bkwd 1.0..0/1... 1/0 Same edge event (joe decrement, chris no) ****chris wins note:joe and chris out of sync by 1 0.9..0/1...0.9/-0.1*****chris wins 0.5..0/1...0.5/-0.5*****tie. 0.1..0/1....0.1/-0.9*****joe wins 0.0..-1/0....1.0/0 New edge event(joe and chris decrement) ******chris wins -0.5..-1/0...0.5/-.5*****tie -.9...-1/0....0.1/-.9*****joe wins fwd -.5... -1/0...0.5/-.5*****tie 0.0...0/0....0/0 Same edge event(joe increment,chris no) ***tie note: back in sync here 0.5...0/0.... 0/0********tie Quote:
Quote:
Here is another analogy: A climber must report his position to base camp as either (ground or top). The climber reaches the top of a mountain and reports (top) to base camp. He then turns around and takes one step down and then updates his position to base camp. What is his best estimate? Alan/joe might say..of course... he must report a ground position. I say no... he has knowledge that he is at the top on his last report and he that he is still there... so his best estimate must be his last reported position which is top. Last edited by vamfun : 25-04-2010 at 15:28. |
|
#56
|
|||
|
|||
|
Re: Unexpected results from Encoder::GetRate()
Quote:
So Joe has reached a compromise position by providing a GetDistance() that is control friendly but sensitive to oscillating edges and a GetRate() that is insensitive to oscillating edges. I still need to study Kevin's solution since it appears to have the hysteresis in it.... yet Alan found it acceptable for his control problem. Perhaps Alan can describe what type of control they were doing at that time. |
|
#57
|
|||
|
|||
|
Re: Unexpected results from Encoder::GetRate()
Quote:
Quote:
Therefore, I say again that I do not have two events... I have one. As such, I do not report an invalid rate. It is not a patch to the algorithm, it is fundamentally accurate and required. -Joe |
|
#58
|
|||
|
|||
|
Re: Unexpected results from Encoder::GetRate()
Quote:
Your algorithm would say ground when starting, then after crossing half way, you are at the top... then you come back down all the way to the ground, and you still report that you are at the TOP! -Joe |
|
#59
|
|||
|
|||
|
Re: Unexpected results from Encoder::GetRate()
Quote:
See post 58. Quote:
-Joe |
|
#60
|
|||||
|
|||||
|
Re: Unexpected results from Encoder::GetRate()
Joe figured out what the disconnect was.
A proper quadrature decoder has a sawtooth-shaped error. This is typical of any digital measurement of a continuous value. Usually, one chooses the interpretation of the actual value to be between the transitions rather than right at them. This places the "zero error" level midway up the sawtooth, yielding a quantization error of +/- half the precision. The hysterical scheme instead puts the "zero error" level at the bottom of the sawtooth when traveling in one direction, and at the top when traveling in the other. The quantization error is either between 0 and 1, or between 0 and -1. Such a scheme strikes me as less desireable in every way but one -- that one way being ease of implementation when the only tool is an inflexible edge detector.Any scheme with a one-count lag when changing direction can not give the same answer at both the beginning and the end of a round trip. If it says you're at the bottom of the mountain when you start, and you go far enough for it to say you're at the top, it will still say you're at the top after you return to the bottom. Trying to measure the position at the transition is always problematic. Once you choose which side of the discontinuity you want to compare things on, the advantages of each scheme become much more clear...and I see no obvious advantages to the scheme with the lag on direction reversal. |
![]() |
| Thread Tools | |
| Display Modes | Rate This Thread |
|
|
Similar Threads
|
||||
| Thread | Thread Starter | Forum | Replies | Last Post |
| [BB] An unexpected change in plans | yodameister | General Forum | 22 | 01-12-2009 21:26 |
| Inconsistent reading from encoder get rate | rwood359 | National Instruments LabVIEW and Data Acquisition | 5 | 13-01-2009 19:10 |
| Results from Drexel, thanks from 365. | archiver | 2001 | 1 | 24-06-2002 02:44 |
| Results from GLR? | archiver | 2001 | 0 | 24-06-2002 02:44 |
| results from regionals | archiver | 2000 | 0 | 23-06-2002 22:31 |