Tool probe: use retry sample data, don't discard it - #41
Open
samv wants to merge 2 commits into
Open
Conversation
Previously, if you had SAMPLES_TOLERANCE set to a value, and SAMPLES set
to a number of probes, if you had SAMPLES probes within
SAMPLES_TOLERANCE, then those results would get poked into the median or
average function to return the result. If there was a measurement
outside of that window, previous data would be discarded until there
were SAMPLES measurements in a row within SAMPLES_TOLERANCE.
Probe samples exceed tolerance, retrying...
This new algorithm preserves this behavior for the initial SAMPLES worth
of probes; if they are all within SAMPLES_TOLERANCE, the result will
still be passed to median or average and the result yielded. The
difference is what happens to measurements that _don't_ fall within
SAMPLES_TOLERANCE. Instead of discarding these values, they are
retained, and a different method is used to look for a distinct 'peak'
in the values, at least SAMPLES higher than other potential ranges.
Found 2 results at -0.268875 and -0.267312; but also 1 result at -0.175125; need more data...
This is done using a window function over the probe samples, and the
highest count window is chosen as a potential 'winner'. Each of the
next most numerous windows are then compared, to see if any of them
would contradict the 'winner'. If they are a distinctly different
range, that is, starting points are more than SAMPLES_TOLERANCE away,
and the number of measurements in the window is within SAMPLES of the
'winner', this is considered a contradiction, and probing continues.
Found 9 results between -0.259813 and -0.252625; but also 7 results
between -0.272937 and -0.263250; need more data...
The probing will complete when a winner is found, _or_
SAMPLES_TOLERANCE_RETRIES * SAMPLES measurements (the previous worst,
pathological limit on the number of probes in the run) happen without a
clear winner being found.
Peak in data found: 11 results between -0.259813 and -0.252625
Result is z=-0.255125
The median value with this very tightly grouped set of results turns out
to be fairly stable indeed.
Z is currently 1.74, net probe result is 0.02
This filter is designed for Maxwell coupling–based probes, which can
slightly degrade over time and start to return results where the pins
disconnected in a slightly different displacement orientation than
typical, for reasons yet to be clearly identified and probably relating
to creep and friction. However, the approach should be appropriate for
many types of probes which have similar variations in their measured
values. This could mean that people who previously used higher
tolerance values for more reliable probing, can return to using their
preferred tolerances.
If the tolerance is set tighter than the accuracy of the probe, then the
probing will continue until the maximum sample count has been read, and then
fail with:
Results too scattered even after N sample(s): a, b, c, ...
However, there has often been a lot of data collected, and there may be a
signal within it. Using a window for grouping values equal to the "tolerance"
may be fussier than needed. It's quite probable that the median value of the
peak with a slightly wider window will still yield a value that should be
expected to be within the specified tolerance. As such it's not really a
tolerance, but more of a granularity for the peak analysis.
If we reach the maximum number of samples, instead of failing and remaining
uncalibrated (which is arguably worse than giving up), progressively widen the
window starting from the specified tolerance and ending at 10x the tolerance.
Use whichever level first yields a clear answer: window at least 'SAMPLES' more
values in it than any other non–overlapping window.
The specifics of the window expasion should proably be configurable, but for
now these defaults seem reasonable.
Contributor
|
This is supper cool. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
In which a new policy for what to do when a value outside of the specified tolerance range is received. A couple of ideas; I'm pretty happy with the core approach of using window analysis of the results to allow one or two bad samples to not abort the attempt. The probes I'm using are simple and hand–made, and sometimes I just want the probing code to use the "obvious" clustering of values as a signal, , See the first commit mssage for details of this algoritm.
The second commit is currently more of an idea, to again try to make the best if the values are, as the code puts it, "wild". It works by extending the window wider than the tolerance, with the hope that the "Correct" value is probably quite close to right, so use it rather than giving upm with warnngs f