-
Notifications
You must be signed in to change notification settings - Fork 805
Description
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:
- the parallax of the dial above the scale - especially when the dial is not pointing to the image center or away from it.
- an offset error in the meter itself, e.g. the dial being rotated to what it should be - likely this is a manufacturer quality issue, but I'm not sure if I am the only one that has this.
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:
def ana_correction( ana, params ):
dx, dy, dval = params.T
theta = ana/10 * (np.pi*2)
corrected = np.arctan2(np.sin(theta) + dy, np.cos(theta) + dx) # corrects the parallax error
corrected_val = corrected / (np.pi*2) * 10 + dval # corrects the offset error
return corrected_val % 10
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 in ClassFlowCNNGeneral::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.