Incorrect combined readout when using Digital + Analog ROIs, individual numbers recognized correctly

[Plawasan]

First of all let me say that the last update (running master - v11.0.0 - 2022-08-13) is a massive improvement, for me it made a difference between getting a result maybe in 1 out of 5 readings to pretty much perfect results everytime. I did notice one issue though:

If I only use digital ROIs, I get a correct result, down to the last decimal implied from the rotation of the digits:

However, when I add the analog ROI to this to make it even more precise, I get wrong results even though each digits is still recognized correctly:

Looks to me like the issue is not in the OCR but rather in the logic of combining the inputs from Digital and Analog ROIs.

Thanks!

[Plawasan]

For the record, same thing happens on my other meter:

all digits recognized correctly:

(Value should be: 167.73462)

however the last digital ROI is then 1 higher than it should be when the inputs are combined:

Drop the Analog ROI, the last digit goes back to the correct value:

[haverland]

@jomjol ClassFlowCNNGenerial.cpp:195

if ((zahl_vorgaenger >= 0.5 ) && (zahl_vorgaenger < 9.0)) { // kein Ziffernwechsel, da Vorkomma weit genug weg ist (0+/-0.5) --> zahl wird gerundet return ((int) round(zahl) + 10) % 10; }

Im wondering if a return ((int) trunc(zahl) + 10) % 10;

would be better. But I'am not sure on side effects.

See #919 is similar

[caco3]

I see exactly the same issue on my last digital digit: https://github.com/jomjol/AI-on-the-edge-device/issues/923

[jomjol]

Implemted in version 11.1.0

[Plawasan]

Sorry to be a pest... upgraded to 11.1.0 but still no bueno, the problem seems to have shifted one digit up:

all ROIs correct, RAW number is incorrect:

This time with/without the Analog ROI makes no difference, this is with it disabled:

[jomjol]

I agree, problem is still present. Quick fix did not solve the problem. I'm working on it, but maybe might take a bit more time.

[jomjol]

Just uploaded one last rolling version for today - with a new algo (analog brand new and digital partially).

@haverland: fyi

Please use and test. It has also an extended logging switch on. This will help to debug the algo. ' afk for next 20h

[haverland]

Im working on it currently. The readout needs another variable of the last ROI->float_result and reducing to <9.0 was not a good idea. The fix will take a bit. I add testing cases for post-process too.

[Plawasan]

I hate to be that guy.... but....11.1.1 still doesn't get it quite right:

[haverland]

I've not see the failure. Smale differences like 96 97 is another issue, but it's ok. Is in the fault tolerance of the neuronal network models.

[haverland]

@Plawasan What kind of model you use for analog pointer? It's a 9.0 and not 9.7. It should not so much differences.

[Plawasan]

That I'm not worried about however the result in the screenshot above should be 377.08397, not 377.08497 - it's off by 1 on the last digital ROI.

[haverland]

OK, now I know what you mean. @jomjol Test case for reproducing I've pushed as request. @Plawasan thanks for your persistence

[jomjol]

What kind of firmware do you use?

In the version 11.0.0 and 11.1.0 is a bug in the transition from analog pointers to digital values. It is improved in the today released version 11.1.1

[Plawasan]

What kind of firmware do you use?

In the version 11.0.0 and 11.1.0 is a bug in the transition from analog pointers to digital values. It is improved in the today released version 11.1.1

That's what I'm on:

[jomjol]

then you found a bug :-). Needs to be tested.

[Plawasan]

Just installed 11.2.0... got another bad result from a good recognition:

[cbho]

Unfortunately also here:

Version: master - v11.2.0 - 2022-08-28 HTML version 15.1.0

(Parts of the) Config: [Digits] Model = /config/dig-cont_0570_s3.tflite CNNGoodThreshold = 0.5

[Analog] Model = /config/ana-class100_0120_s1_q.tflite

[PostProcessing] m3.DecimalShift = 0 PreValueUse = true PreValueAgeStartup = 3600 AllowNegativeRates = false m3.MaxRateValue = 1 m3.MaxRateType = AbsoluteChange ;m3.ExtendedResolution = false m3.IgnoreLeadingNaN = true ErrorMessage = true CheckDigitIncreaseConsistency = true

[haverland]

Unfortunately also here:

Version: master - v11.2.0 - 2022-08-28 HTML version 15.1.0

(Parts of the) Config: [Digits] Model = /config/dig-cont_0570_s3.tflite CNNGoodThreshold = 0.5

[Analog] Model = /config/ana-class100_0120_s1_q.tflite

[PostProcessing] m3.DecimalShift = 0 PreValueUse = true PreValueAgeStartup = 3600 AllowNegativeRates = false m3.MaxRateValue = 1 m3.MaxRateType = AbsoluteChange ;m3.ExtendedResolution = false m3.IgnoreLeadingNaN = true ErrorMessage = true CheckDigitIncreaseConsistency = true

Looks more like a recognition issue. The current raw is ok, but there was a previous read, that had set the 8.

[cbho]

Absolutely possible, of course, although when I look at the graphs in Home Assistant, I think it's the other thing that's happening. I'll make some additional sensors in Home Assitant and monitor Value, Previous Value and Raw and see if I can add anything of value :-)

[haverland]

Should be a 78.99996, isn't it?

[jomjol]

You are right. The problem is the various types of counters. I need 7-9 parameters to model the transition. I decided to go for a model based algorithm for the transistion. But this will take quite some time.

[Wingsofcourage]

I'm on version

And things getting better. But now the first number is a "2" even if the recognition tells me a "3.1"

Any thoughts ?

[jomjol]

The problem is the 9.1 in the previous value. Therefore the algo thinks, that the next number is already in the moving situation and has not crossed "0" yet. This is really a problem as almost every counter is starting to rotate the next number at a different value. It needs to be parametrized, but this is quite some modeling effort (not programming, but finding a general and easy to adjust model).

[haverland]

But 3.1 is over 0. Here should not be an incomplete transition detected. I make a test case.

Edit: Works fine with latest rolling.

[jomjol]

@Haverland: there are also digits, that have an offset. In this case the unrotated number is e.g. 3.2. Therefore a 3.1 can still be before "0" crossing.

[pos-ei-don]

@haverland: there are also digits, that have an offset. In this case the unrotated number is e.g. 3.2. Therefore a 3.1 can still be before "0" crossing.

I have such a Meter, which is my early rotator. I have an late rotator as well which still Shows 9.0 in the Digital when the analog already crossed the "0".therefore I suggest a cobfigurable "offset" value which could be just added/subtracted to the recognised value

[haverland]

@haverland: there are also digits, that have an offset. In this case the unrotated number is e.g. 3.2. Therefore a 3.1 can still be before "0" crossing.

I have such a Meter, which is my early rotator. I have an late rotator as well which still Shows 9.0 in the Digital when the analog already crossed the "0".therefore I suggest a cobfigurable "offset" value which could be just added/subtracted to the recognised value

Your case should be calculated properly. I hope we do not need a configurable value for it. It should be easy to use for Users.

[dl6dbh]

How did you get such a razor sharp picture? My pictures don't turn out that well.

[Plawasan]

How did you get such a razor sharp picture? My pictures don't turn out that well.

Did you adjust the focus of the camera lens? It needs a bit of force to rotate it ccw a get it to focus closer.

[stefanbode]

Regarding rotate of the digital values: The mechanic of these meters are finally connected to the LAST digit. That means if the last digit is still at 8 or 7 all other digits before will NOT start to move. As soon as the LAST digit is at 9 or further all digits before start moving too. Therefore a 19998.5 is stable at the first 4 digits. every 8.9 or 9.2 is a 9. If the last digit is a 9 the movement will start. If you take this into consideration I believe you will get away from some of your problems.

[stefanbode]

I take a look at process_doFlow() and I assume this is where you generate the final number. As a human you would not start with the largest value and then go to the smaller ones. You would do it quite vise versa. Because if the lower value is as 2.5 then you KNOW that the next higher must be something at x.0 to x.4 (+-0.2 deviation). If the reading is 8.8 or 8.9 you're 100% sure it must be a 9. This will also solve your 9 problem. If the before reading is a 0.9 and the digit is 7.8 you're now even sure this must be a 8.9 and not a 7.9.

[stefanbode]

Another comment on the analog wheels of the water-meter. These are connected through gears. That means the movement of ALL gears is continuous. Therefore the evaluation of these ones is different to the digital ones.

[stefanbode]

Something for regression. Used current development build form yesterday. All digits correctly scanned but value is wrong: 32290.420. should be 32289.420

[haverland]

Mhh.. with current rolling it should run fine. Did you set CheckDigitIncreaseConsistency = true?

[stefanbode]

CheckDigitIncreaseConsistency is new to me. I can check for it. Anyhow my assumption is that we calculate the rolling false. Only the 9er rolls and the digit before the last 9. all other values are not touched by the rolling. I find the code where this is calculated. Maybe can send a PR soon. Im this case the rolling stops at the 2. the 8 and the 9 will never be effected by rolling because the digit changing is 1 to a 2.

[jomjol]

@stefanbode : please be very careful with adopting the changing the code for the rolling calculation. There are a variety of counters out there. E.g.

• early runner, late runner (roll over of number earlier or later than expected)
• or a larger spread while rolling (start rolling with previous number only at 7/8 and rolling until 2/3)
• zero point not beeing at x.0, but (x-1).8 or x.1

This is still part of some work and a more sophisticated modelling is in my head, but needs some more time and then extensive testing to be transfered in code.

[caco3]

@stefanbode Thats odd. I also have a BK-G4 and I never see half digits:

There seem to be different implementations of the counter (mine gauge is from a swiss vendor).