Replies: 4 comments
-
|
Please try the rolling version: https://github.com/jomjol/AI-on-the-edge-device/actions/runs/10621763080 There you can use the improved zoom function and then increase CamGainceiling and reduce the LED intensity at the same time, which will most likely get rid of the reflection at the top.
|
Beta Was this translation helpful? Give feedback.
-
|
Thanks @SybexX will give that a try |
Beta Was this translation helpful? Give feedback.
-
|
@SybexX I am now using the rolling version, and with use of the zoom it seems to have improved the reliability. Image quality is also much clearer and played a bit with the lighting settings to reduce the reflections:
Still, when one of the decimal digits is number 3, it is frequently interpreted as an 8 and vice versa:
It seems to be much less frequently than before, which is good:
Unfortunately not reliable enough for automations. For example if 0.3 m3 is interpreted as 0.8 m3, it will likely fall beyond a plausible maximum rate. This invalidates subsequent measurements until that value is plausible. If I want to detect leaks this can be a problem because any non-zero flow will go unaccounted for during a potentially long period of time. I left the collection of digits on so that I can have samples of my digits. Will try to add these to the TF model, and maybe improve the recognition reliability in this type of edge case (?) |
Beta Was this translation helpful? Give feedback.
-
|
I have extracted and classified digits from my meter, having placed these in this issue: I tried following some of the documentation about incrementing with this as training data, but could not find a sufficiently consistent step by step guide on how to do that. I have used: https://jomjol.github.io/AI-on-the-edge-device-docs/Learn-models-with-your-own-images/ But it fails while running the jupyter notebook. |
Beta Was this translation helpful? Give feedback.
-
The Problem
I find that in my meter (an Apator SV-RTK - https://www.apator.com/en/our-solutions/water-and-heat/water-meters/volumetric/sv-rtk-do-r200), some digits are often misrecognized, especially the 4 (interpreted as 1) and the 3 (interpreted as 8). This happens in all
dig-class*.
I am not using the dig-cont* as these have poorer recognition performance.
I have optimized the ROI for the dig-class models (digit width in the inner box, and window height in the outer box). This behaviour is very consistent, especially in the rightmost digits. I presume that given the parallax, the tips of the '3' digits being closer to the window/frame, may confuse the model given the absence of black in between (?).
For example:
Version
Firmware version: Release: v15.7.0 (Commit: 0d0b018+)
Logfile
Expected Behavior
In that example, would expect the value to be recognized as 374.337 instead of 374.887.
Screenshots
No response
Additional Context
No response
Beta Was this translation helpful? Give feedback.
All reactions