Skip to content

Correction of analog readings with calibrated error model #2716

@jakobs

Description

@jakobs

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:
image.
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:

  1. the parallax of the dial above the scale - especially when the dial is not pointing to the image center or away from it.
  2. 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:
image
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:
image

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions