Wasserzähler - Selfmade

[michaeljoos]

@jomjol Es hat mir einfach keine Ruhe gelassen und ich wollte wissen, ob ich das mit dem Neural Network auch irgendwie und ohne Vorwissen hinkriege

Heute habe ich mir Anaconda, Tensorflow, Keras und alles was es benötigt auf meinem Laptop installiert und ein paar Bilder von der Ziffer 3 meines Zählers (die als Ziffer 1 erkannt wurde) im Verzeichnis \ziffer_sortiert_raw\3\ abgelegt.

1. jupyter notebook gestartet
2. Image_Preparation.ipynb ausgeführt
3. Train_CNN_Digital-Readout.ipynb ausgeführt
4. Neues tflite-File auf den Raspi kopiert
5. Docker neu gestartet

Resultat:

993N.662 00993N 662

Die 3 wird erkannt !!

Und das alles nur dank deiner riesigen Vorarbeit & Dokumentation! Besten Dank nochmals! Ok, ein paar Hürden gab es schon zu überwinden bis alles lief.

Ich werde dir später trotzdem meine gesammelten Ziffern schicken damit alle profitieren. Kann einfach etwas dauern, da sich mein Wasserverbrauch ziemlich in Grenzen hält.

Gruss
Michael

[el_kassi]

@jomjol hier einmal mit rotem Hintergrund. rot.zip
Viel Variation im Licht ist nicht, da es ziemlich konstant und in einer abgeschlossenen Halterung verbaut ist.

[el_kassi]

Und hier eine erste Fuhre weiß auf schwarz. (0,2,3,4). schwarz.zip

Wie es ausschaut gibt's hier keine in 10, da der Zähler scheinbar sauber umspringt. Zumindest erkenne ich das so aus den Bilder, aber ist noch nicht vie Zeit ins Land gezogen.

Wenn noch jemand einen Sensus 620 hat, kann er gerne hier mithelfen, Bilder hochzuladen.

[jomjol]

@el_kassi Okay, danke. Du schneidest ziemlich knapp aus. Etwas mehr Rand könnte zusätzlich helfen und macht das Bild robuster gegenüber einen Shift im Alignment.
Ich melde mich, wenn ich die Bilder trainiert habe.

[el_kassi]

@jomjol Ok, kann ich einstellen. Ich bin allerdings schon am Rand des Rades. Wenn ich oben/unten mehr dazu gebe, dann kommt blaue Umrandung dazu.

Noch was: Da meine 4 bereits oft als 8 falsch erkannt wird (und andere auch), macht es wahrscheinlich Sinn, für die weiß auf schwarz/rot gelagerten Ziffern eine eigene tflite Datei anzulegen, die man dann auswählen kann. Ansonsten dürfte es schwierig werden, was erkannt wird am Ende.

[jomjol]

@el_kassi Der blaue Rand dürfte nicht so sehr stören. Du kannst auch ein leicht anderes Aspektverhältnis wählen (einfach von Hand in der Config.ini die Größe des ROIs anpassen).
Eine zweite tflite ist schon ein etwas größeres Ding, da im Code fest ein digitales und ein analoges CNN hinterlegt sind. Da muss ich an den Quellcode ran.
Momentan bin ich gerade daran, das System direkt auf dem ESP32 zum laufen zu bekommen. Dort habe ich schon eine etwas flexiblere Implementierung gewählt und die wäre grundsätzlich leichter anpassbar. Wenn das soweit ist, könnte ich das vielleicht auch auf den Docker zurück importieren. Ist dann aber C++ statt Python.

[el_kassi]

@jomjol Ich kann in der config doch im modelfile eine tflite Wählen. Die sollte doch dann verwendet werden. Im Code wird ja auf die tflite zurückgegriffen. So nur mein Verständnis. Ich befürchte halt, dass wenn alle Ziffern in einer Datei zusammengefasst sind, dass das System hier Fehlalarm schlägt, da er jetzt schon statt einer weiß-auf-schwarz 4 eine schwarz-auf-weiß 8 erkennt.

Ich bin gerade parallel dabei, die Python Version etwas zu modifizieren. Hauptsächlich refactorings, die wir natürlich besprechen müssten.
Das Ganze bräuchte ich, um einen Zähler mit Vor- und Nachkommazahlen zu betreiben.
Auf dem ESP wäre das natürlich auch willkommen, wenn das ginge. Allerdings ist das schwieriger zu aktualisieren, da mann dafür den ESP jedesmal rausnehmen, oben anschließen, programmieren und wieder einsetzen muss. Geht auch, aber der Entwicklungszyklus ist definitiv länger, wenn man das häufiger machen muss.
Bin gespannt.
Wenn du reviews benötigst, gib bescheid. Meinen github account kennst du ja.

[el_kassi]

Wäre das hier ein besserer Schnitt?

Oder geht das zu weit runter? Hab versucht, mich an die 23% und 78% zu halten. Die 3 an Pos. 5 ist warum auch immer recht tief und der blaue Rand hat da eine Wölbung. Ist dann aber auch weiß mit auf dem Bild ganz unten.

[jomjol]

@el_kassi Enschuldige die später RM, ich war ein paar Tage offline. Von der Größe der Zahlen passt das. Ich würde die ROIs noch etwas nach oben setzen, so dass die Zahlen mittig sind.

[watcherkb]

@jomjol
Hi, ich habe seit heute das Problem dass der Server mir beim Aufruf über http://192.168.1.36:3000/wasserzaehler.html nichts liefert. Die Seite bleibt leer. Der Parser-Adapter meckert auch:

Cannot read link "http://192.168.1.36:3000/wasserzaehler.html": {"statusCode":200,"body":"","headers":{"server":"BaseHTTP/0.6 Python/3.7.4","date":"Tue, 30 Jun 2020 12:10:00 GMT","content-type"

Der Aufruf http://192.168.1.36:3000/wasserzaehler.html&full funktioniert, hat aber die 6 falsch erkannt (letztes tf-file)

Server und ESP sind bereits neu gestartet. Eine Idee was es sein kann?

[jomjol]

@watcherkb Ist das genau der Output von "...&full" oder hast du die erste Reihe einfach nicht ausgeschnitten?

Normalerweise stehen dort auch die Ziffern in der ersten Reihe und erst dann kommen die Bilder. Wäre ein Hinweis, wo ich suchen könnte. So einen Fehler hat noch keiner berichtet.

P.S.: ich würde etwas mehr Rand um die Ziffern lassen, dann ist die Bilderkennung etwas stabiler.

[watcherkb]

@jomjol in der ersten Reihe sind auch keine Ziffern, und das große Gesamtbild habe ich auch nicht gescreenshotet.

Danke werde es anpassen

[watcherkb]

@jomjol heute gehts wieder obwohl ich nichts verändert habe. Einzig die 6 die gestern als 8 berechnet wurde, ist heute korrekt. Evtl. liegt es dadran? Anbei Screenshot und meine Settings:

[Imagesource]
timeoutloadimage = 30
#ip durch die ip des esp32 ersetzen!
urlimagesource = http://192.168.1.209/capture_with_flashlight?quality=25&size=svga
logimagelocation = ./log/source_image
#logonlyfalsepictures=false

[ConsistencyCheck]
enabled = False
#stores the last value in a file for the case of a restart (e.g. docker container after update)
readprevaluefromfileatstartup = True
#maximum time spanning since last startup for use of prevalue from filestorage in minutes
readprevaluefromfilemaxage = 30
allownegativerates = true
#maximum change of new to old value (+ or -)
maxratevalue = 0.5
#return in case of error: value = oldvalue or newvalue
#                         errormessage = return text with problem (seperated by tabstopp) if nothing, then no error message
#                         readout = real readout without corrections (newvalue)
errorreturn = errormessage

[AnalogReadOut]
#if enabled analog counters will be read, if disabled only digital counters will be read.
enabled = True

[alignment]
initial_rotation_angle = 180.0

[alignment.ref0]
image = ./config/ref0.jpg
pos_x = 51
pos_y = 125

[alignment.ref1]
image = ./config/ref1.jpg
pos_x = 611
pos_y = 59

[alignment.ref2]
image = ./config/ref2.jpg
pos_x = 362
pos_y = 398

[Digital_Digit]
names = ziffer1, ziffer2, ziffer3, ziffer4, ziffer5
modelfile = ./config/neuralnets/Train_CNN_Digital-Readout_Version_6.1.2.tflite
logimagelocation = ./log/digital_digit
#lognames=

[Analog_Counter]
names = zeiger1, zeiger2, zeiger3, zeiger4
modelfile = ./config/neuralnets/CNN_Analog-Readout_Version-6.2.0.tflite
logimagelocation=./log/analog_counter
#lognames=

[Analog_Counter.zeiger1]
pos_x = 572
pos_y = 174
dx = 158
dy = 158

[Analog_Counter.zeiger2]
pos_x = 486
pos_y = 344
dx = 155
dy = 155

[Analog_Counter.zeiger3]
pos_x = 329
pos_y = 423
dx = 156
dy = 156

[Analog_Counter.zeiger4]
pos_x = 101
pos_y = 352
dx = 168
dy = 168

[Digital_Digit.ziffer1]
pos_x = 174
pos_y = 6
dx = 48
dy = 86

[Digital_Digit.ziffer2]
pos_x = 258
pos_y = 7
dx = 49
dy = 88

[Digital_Digit.ziffer3]
pos_x = 345
pos_y = 5
dx = 50
dy = 89

[Digital_Digit.ziffer4]
pos_x = 430
pos_y = 8
dx = 48
dy = 85

[Digital_Digit.ziffer5]
pos_x = 516
pos_y = 7
dx = 46
dy = 83

[el_kassi]

out.zip
Neuer Schnitt und mehr Ziffern

[el_kassi]

@jomjol Ich hab das CNN auch mal bei mir trainieren lassen, um zu sehen, ob es taugt und auch um die Fehlerrate mal zu verringern. Auf meine 16000 SourceImage der letzten Tage angewendet habe ich > 50% NaN in den letzten 4 Ziffern, bzw. tatsächlich in der letzten Ziffer. Daher meine Frage:
Was darf alles in den NaN Ordner rein zum trainieren und was nicht?

Wenn ich mich auf das Bild von @michaeljoos beziehe:
Käme hier die letzte Ziffer in NaN oder in 9 oder sollte man sie für das Trainieren komplett vermeiden? D.h. sollte man nur Bilder, die exakt zwischen 2 Ziffern liegen, in NaN kopieren?
Ich habe die Erfahrung gemacht, dass sehr oft zwischen 6 und 7 als 9 erkannt wird. Der Kringel der 6 und der schräge Balken der 7 sind da anscheinend gewichtiger als die Tatsache, dass beide Teile nicht durchgängig verbunden sind.

In diesem Zusammenhang noch eine Frage:
Sollte ich (siehe Bild in einem der vorherigen Posts) die letzte Ziffer (digit8) bei mir kleiner ausschneiden? Beim letzten Rad ist offenbar der sichtbare Bereich größer, so dass ich grundsätzlich immer Teile einer anderen Ziffer sichtbar habe, was dann sehr stark in Richtung NaN oder Fehlinterpretation geht.

Außerdem habe ich mich noch gefragt, ob man das CNN auf 21 Klassen erweitern könnte und exakt solche Werte, 2.5, 6.5, etc. zulassen kann, wenn man sie erkennt. Habe damit ein bisschen probiert, aber zu wenig Daten dafür. Dies würde ggf. auch die NaN Rate reduzieren.

Resultat:

[jomjol]

@el_kassi sagte in Wasserzähler - Selfmade:

@jomjol Ich hab das CNN auch mal bei mir trainieren lassen, um zu sehen, ob es taugt und auch um die Fehlerrate mal zu verringern. Auf meine 16000 SourceImage der letzten Tage angewendet habe ich > 50% NaN in den letzten 4 Ziffern, bzw. tatsächlich in der letzten Ziffer. Daher meine Frage:
Was darf alles in den NaN Ordner rein zum trainieren und was nicht?

In NaN sortiere ich eigentlich alles, wo die Ziffer nicht vollständig im Bild zu sehen sind (= ohne Berührung des Randes)

Wenn ich mich auf das Bild von @michaeljoos beziehe:
Käme hier die letzte Ziffer in NaN oder in 9 oder sollte man sie für das Trainieren komplett vermeiden? D.h. sollte man nur Bilder, die exakt zwischen 2 Ziffern liegen, in NaN kopieren?

Definitiv in NaN

Ich habe die Erfahrung gemacht, dass sehr oft zwischen 6 und 7 als 9 erkannt wird. Der Kringel der 6 und der schräge Balken der 7 sind da anscheinend gewichtiger als die Tatsache, dass beide Teile nicht durchgängig verbunden sind.

In diesem Zusammenhang noch eine Frage:
Sollte ich (siehe Bild in einem der vorherigen Posts) die letzte Ziffer (digit8) bei mir kleiner ausschneiden? Beim letzten Rad ist offenbar der sichtbare Bereich größer, so dass ich grundsätzlich immer Teile einer anderen Ziffer sichtbar habe, was dann sehr stark in Richtung NaN oder Fehlinterpretation geht.

Eigentlich würde ich es nicht kleiner aussschneiden, sondern nur beim Einsortieren das gleiche Kriterium angwenden: ist die Zahl von Interesse vollständig im Bild und berührt den Rand nicht.

Außerdem habe ich mich noch gefragt, ob man das CNN auf 21 Klassen erweitern könnte und exakt solche Werte, 2.5, 6.5, etc. zulassen kann, wenn man sie erkennt. Habe damit ein bisschen probiert, aber zu wenig Daten dafür. Dies würde ggf. auch die NaN Rate reduzieren.

Würde ich nicht empfehlen, da

1. Brauchst du viel mehr Bilder zum Teachen
2. wo ist dann die Grenze? warum nicht auch 0,25-er Schritte
3. Die Mechanismen zum Korrigieren von NaN ("usePreValue") funktionieren i.d.R. gut.

Resultat:

[jomjol]

@el_kassi sagte in Wasserzähler - Selfmade:

out.zip
Neuer Schnitt und mehr Ziffern

Danke für den Input - ist verarbeitet und hochgeladen:

TfLite v6.2.0: https://github.com/jomjol/neural-network-digital-counter-readout
wasserzaehler - rolling v7.5.0: https://github.com/jomjol/water-meter-system-complete/tree/rolling

[jomjol]

Hallo zusammen,

es ist schon länger etwas ruhiger hier im Thread. Hoffentlich bedeutet es, dass eure Zähler gut laufen

Ich habe in der letzten Zeit an einer neues Version gearbeitet und möchte einen ersten Zwischenstand geben. Es ist mir gelungen, alle Prozesse, also auch die CNN-Image Recognition direkt auf dem ESP32 laufen zu lassen. Damit ist bald hoffentlich kein Docker-Container mehr nötig. Einige Punkte von euren Rückmeldungen habe ich auch schon berücksichtigt.

z.B. die längere Laufzeit der Auswertung wird durch eine periodische automatische Erkennung gelöst, so dass ich bei Abfrage des Wertes eine schnelle aktuelle Antwort bekomme.

Damit der Übergang möglichst einfach wird und auch, damit ich die Performance testen kann, habe ich auch die bisherige Funktion des ESP32-CAM als Bildlieferant beibehalten und man kann sowohl den Dockercontainer (Abfrage über /capture_with_flashlight), wie auch das komplette System auf dem ESP32 parallel laufen lassen ohne gegenseitge Beeinflussung.
Ich hänge noch ziemlich in der Dokumentation und den Source-Code sollte ich auch noch etwas aufräumen, bevor ich ihn ins GitHub hochlade. Das ist mein Projekt für die kommenden Sommerferien

Ich poste hier schon mal einen Link zum neuen Repository: https://github.com/jomjol/AI-on-the-edge-device

Ist noch sehr leer, füllt sich aber bald hoffentlich kontinuierlich. Ich suche noch ein oder zwei Early-Adopter, die meine sehr frühen Versionen vorab testen. Ist aber noch ein früher Stand. Wer will, kann sich gerne per Chat bei mir melden.

Beste Grüße,
jomjol

[gerald123]

@jomjol Hallo jomjol,
Das ist gut zu hören das in Zukunft alles nur noch am ESP32 läuft und direkt vom IoBroker abgefragt werden kann.
Leider wurde bei mir jetzt ein neuer Wasserzähler eingebaut Type Diehl.
Gibt es dazu schon eine Möglichkeit das ich ihn auch auslesen kann.

Sg. Gerald

[jomjol]

@gerald123 Hallo Gerald,
das sollte funktionieren. Inzwischen sind auch erste Ziffern mit weißer Schrift auf schwarzem bzw. rotem Hintergrund geteached. Einzig für das Komma brauchst du noch einen Trick auf der Serverseite. Das kann ich aber auch parametrisierbar gestalten, du bist nicht der erste, der danach fragen.

Gruß,
jomjol