-
Notifications
You must be signed in to change notification settings - Fork 658
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Correction of analog readings with calibrated error model #2716
Comments
I don't think its an issue of the parallax, you camera looks quite straight to the meter. Better than on many other pictures I have seen! The pointer indicates it is around 0.41, but the 0.01 pointer sais its more 0.465, so this clearly looks like to be a manufacturers quality issue. Also I never have seen such discrepancy before. An offset calibration might solve it, but it would have to be implemented extra and I fear it would be challenging with all the existing algorithms. I am not too experienced with the algorithms, @JoMol would know better. |
There is a sligth tolerance for the alignment of the different analog meters (I think it's +/- 0.2). Currently it cannot be parametrized. |
@jakobs I am very much interested. In my case, I don't have the problem that the analog meters are out of sync but the 0.1 analog meter is not in sync with the last digit (see #2743 ). An example: In my case the last digit (x1) already shows 3.9, when first analog (x0.1) shows 0.4. What I am looking for is a generic correction procedure. We can assume, that all values I am currently wrapping my head around the processing code in |
I second that some meters need this correction, see my exact same issue: #3255 |
The Feature
I have noticed that I don't get reliable readings from the analog part of my water meter. The 4 dials seem to be out of sync.
Here is an example of what I mean:
.
The fractional reading of the 0,1 dial does not match the 0,01 dials value.
The 0,1 dial is at 4.1 and the 0,01 dial is at 6.5. This doesn't match, as the 0,01 dial should be closer to 1. This leads to the generation of wrong readings as the reading formulation seems to be using an error threshold of 3 to disambiguate.
Based on the images, I've identified 2 sources of errors:
I've done a bit of analysis on 3 days worth of analog dial data:
The orange readings are the original readings, and show the offset and the generally wide error spread that I thought was due to the parallax error.
I have written a python script to calculate correction parameters based on a model assumption:
the params [parallax_x, parallax_y, rotary_offset], I have calculated using an optimization that tries to minimize the difference between the fractional part of a dial and the value of the next dial. The result is shown in the graph above and results in a significant improvement of the readings. The reconstruction of meter reading values in python resulted in far less errors:
I would like to add this correction model to the code now. Ideally the model parameters would be added to the
roi
struct, and the correction could be applied inClassFlowCNNGeneral::getReadout
.I thought I'd ask first before implementing this, and see if this is interesting to others, and if so what would be the preferred way to integrate it so you would accept a merge request.
The text was updated successfully, but these errors were encountered: