Quote:
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:
Quote:
Position
JoeMethod -
ChrisMethod -
. Uncertainty is bounded to [-1.5, 1.5]
|
Uncertainty is bounded to [-1., 1.]
Quote:
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.
Quote:
|
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.
Quote:
|
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.