Wasserzähler - Selfmade
-
@michaeljoos Die Bilder von den Zeigern sollten quadratisch sein. Die Größe am besten so, wie sie auch vom Server ausgeschnitten werden, dann kannst du einfach die Log-Funktion verwenden.
Intern arbeitet die Erkennung mit 32x32 Pixel großen Bildern. Die Umwandlung mache ich aber besser selbst mit dem Makro, dann ist der Skalierungsalgorithmus identisch mit dem im Server verwendeten (Interpolation etc.).P.S.: ja, die abc, def, ghi waren nur Platzhalten. Wie der Dateilname nach der Klassifizierung ist, ist völlig egal.
-
Hm bei mir hat er die letzte Zeut Probleme mit er Erkennung der digitalen Ziffern.
Die erste 0 wird oft als 6 oder 8 erkannt.
Hat einer ähnliche Probleme?
-
Habe die config.ini jetzt wieder leicht angepasst, so dass die erste Ziffer mehr mittig erfasst wird.
Jetzt funktioniert die Erkennung wieder.
Hatte vor kurzem die Config schon mal anpassen müssen, weil die Ziffern nicht mehr genau mittig waren.
Irgendwie komisch.
Mal gespannt wie lang es jetzt wieder funktioniert.
-
@Atifan Probier mal die Ziffern mit etwas mehr Rand auszuschneiden. Es funktioniert i.d.R. besser wenn die Ziffern mittiger sind und etwas Rand haben.
-
Hallo zusammen
Bin gerade am drucken der Teile. Kann mir jemand auf die Sprünge helfen wie ich in Cura die Support-Settings einstellen muss? Ich kapier das noch nicht richtig (z.B. der Deckel mit den Lüftungslöchern...
Update: Ich glaub es funktioniert...den Deckel habe ich einfachheiltshalber 180° gedreht, dann funktioniert es auch ohne "Support".
Besten Dank
Michael -
@pfried, @michaeljoos, @ehome, @Knallochse und natürlich ALLE anderen
Mal eine Frage an euch Nutzer:
Ich spiele gerade mit dem Gedanken, die ganze Bildverarbeitung auf den ESP32 zu verlagern (Alignment & Ziffernerkennung). Das würde dann gegebenfalls den Dockercontainer überflüssig machen. Ob es geht, ist noch nicht klar (vor allem wegen dem Limit im RAM-Speicher). Das hätte aber im wesentlichen zwei Konsequenzen:
- wesentlich einfachere Installation - da kein Docker und keine Verbindung zwischen beiden. Einfach nur ESP32-CAM flashen
- deutlich langsamere Antwortzeiten - erste Versuche zeigen, dass das Alignment und die Neuronalen Netze dann eher im Bereich viele 10s bis 1 Minuten liegen würden.
Was ist eure Meinung zu einer solchen Weiterentwicklung?
Bin gespannt auf eure Rückmeldungen,
jomjol - wesentlich einfachere Installation - da kein Docker und keine Verbindung zwischen beiden. Einfach nur ESP32-CAM flashen
-
@jomjol die 2 wichtigsten Punke hast du ja schon genannt.
Punkt 1 wird wohl neue User locken, dass Projekt umzusetzen.
Das könnte der Entwicklung (durch eventuell neue Bilder zum trainieren) aber zu gute kommen.Punkt 2 wird wohl User abschrecken, die die bisherige Variante (externe Berechnung) schon am laufen haben. Läuft ja fast unbemerkt (Ressourcen) nebenbei.
Ich gehe auch fest davon aus, dass es in den nächsten Jahren leistungsfähiger Prozessoren (Nachfolger) in diesem Bereich geben wird.
Vielleicht hilft dir auch eine Umfrage weiter, um herauszufinden wer dein Projekt auf Grund der externen Berechnung nicht umgesetzt hat.
PS: Mein größtes Problem bei der Umsetzung war den Fokus der Kamera einzustellen.
Bei mir war da ganz schön viel Kleber im Einsatz. -
@jomjol
Da muss ich Knallochse zustimmen. Für den schnellen Start sicherlich leichter umzusetzen aber wer schnellere Auswertungen braucht wird damit nicht glücklich.
Wenn ich einen neuen Gedanken nennen darf: ich hätte mir lieber gewünscht dass das neuronale Netz selbstständig dazulernt. Ist natürlich abhängig davon ob sich sowas automatisieren lässt. Dann wäre man nicht abhängig von dir. -
@jomjol
Ich weiß nicht, ob der Dockercontainer so ein großer Aufwand ist. Das einzeln zusammen installieren wäre sicherlich einiges, aber, wenn man sich mal überwunden hat, geht es mit dem docker doch recht unproblematisch.
Das war für mich das einfachste an der ganzen Geschichte. Allerdings hab ich auch eher Erfahrung mit Software/Linux als Hardware (das flashen hat ca. einen halben Tag gedauert bis ich das mal raus hatte). -
@jomjol
danke für die Antwort.
Ja das hatte ich ja gemacht - allerdings wurde aufgrund der fehlerhaften Erkennung keine weitern Werte mehr eingelesen - da sie wohl nicht sauber erkannt werden.
Deshalb die Frage ob man Bilder zum Trainieren irgendwo bereitstellen kann. -
@ehome du kannst du Bilder einfach mir schicken - Mail kommt per PM.
Von Zeit zu Zeit mache ich ein Update der tflite. Das funktioniert leider nicht automatisch.
-
@jomjol Ich würde momentan beim Docker bleiben. Wenn man sich mal etwas damit befasst hat geht das recht schnell und komfortabel. Auch ein Update ist so ruckzuck erledigt. Beim ESP32 müsste ich jedesmal den mechanischen Aufbau entfernen und das Teil via USB am PC anschliessen und neu laden (oder läuft das auch per OTA?).
Die Antwortzeiten sind schon auch entscheidend. Wenn es mal eingerichtet ist und stabil läuft ist es tatsächlich nicht kritisch. Wenn ich mir aber vorstelle, wie oft ich als Anfänger "reload" gedrückt habe bis alles gepasst hat und ich jedesmal über 1min hätte warten müssen...
Übrigens, meine Installation läuft jetzt und meine Zeiger werden trotz "ungelernt" schon richtig gut erkannt!! Hier mein Setup
ROI:
Das Bild nehme ich mit einer XGA-Auflösung auf.
openHAB:
Passt!
Die 1 erkennt er aber meistens als 7 und wenn ich die Log-Bilder der Zeiger anschaue, stimmt die Kommastelle meistens nicht. Deshalb sammle ich trotzdem die 200-300 Bilder und schick sie dir dann.
-
@jomjol Hallo Jomjol, war ein langes WE in Ö, deshalb verspätet meine Antwort:
... ich würde lieber beim Docker bleiben und die kürzeren Antwortzeiten bevorzugen
... sollte wirklich einmal ein schnellerer ESP-CAM zur Verfügung stehen, kann man das in Angriff nehmen
... vorher sollte vielleicht eine OTA verwirklich werden und
... ein selbstlernendes AI wäre sicherlich von immenser Vereinfachung (Training Mode)Appropo lernen: Kannst Du mir Bitte die Neun weiter oben im Thread 931 anlernen, da zuckt leider meine Erkennung total aus. Thx!
-
@pfried OTA geht doch schon längst meine ich.
-
@watcherkb Ich habe es einmal getestet, da ging es nicht, oder ich habe etwas falsch gemacht.... Kannst Du bitte eine Anleitung zur Verfügung stellen?
-
-
@jomjol
Zu deiner Frage die ganze Bildverarbeitung auf den ESP32 zu verlagern.Von mir ein klares Ja
zu solo Lösung.
Längere Antwortzeiten sind, so denke ich zu verkraften.Wenn du noch Unterstützung bezüglich Hardware benötigst sag beschied. Ich könnte dir eine passende Hardware entwickelt entweder mit einem ESP32 mit externem zusätzlichem RAM oder evtl mit einem zusätzlichem Co-Prozessor oder Prozessor, FPGA, mit einem ESP8266 ....
-
@pfried Problier mal folgendes tlite-File: https://github.com/jomjol/neural-network-digital-counter-readout/blob/master/Train_CNN_Digital-Readout_Version_6.1.2.tflite
Dachte, ich hätte sie schon beim letzten Mal geteached. Gerade aber erst gemerkt, dass dein Bild in Thread 931 ein png-Format hat. Ich hatte es einfach reinkopiert, aber der Algo verarbeitet nur jpg-Dateinen und hat es daher beim Anlernen einfach ausgelassen :-).
-
@pfried, @michaeljoos, @ehome, @Knallochse und natürlich ALLE anderen
Ich fasse mal eure Rückmeldungen zusammen:
- jetzige Lösung mit ESP + Docker passt für fast alle (
ihr habe es ja auch am laufen) - Vereinzelt auch Wunsch nach einer "einfachen" Single-Tool Lösung
- Hauptthema ist die lange Response-Zeit für eine ESP32-only Lösung
- Debugging und Testen ist bei den langen Response-Zeiten auch aufwendig
Für die Responsezeiten hätte ich die Lösung: das Auslesen kann ich per Timer auch offline periodisch stattfinden lassen und dann eine sofortige Rückmeldung mit dem zuletzt umgewandelten Wert kommt. Ich denke auch, dass eine Hybridlösung einfach möglich sein sollte. Denn wenn das System mal läuft, wäre es ein leichtes, auch als Bildserver für den Docker-Container zu funktionieren. Letzterer könnte dann sogar als Generator für das Config-File für des ESP32 dienen.
Technischer Stand ist der Folgende:
- einige Komponenten laufen schon im Einzelmodus (Bildererkennung, Bildalignment und ROI-Exktraktion, Vereinfache Config.ini Prozessierung
- noch fehlende Komponenten: Ansteuerung Kamera, http-Server Implementierung
- bisher ist die Rechenpower und der Speicher (4 MB PSRAM) ausreichend
- Hauptproblem: bei Kombination von mehr als drei Modulen kommt es zu einem unbekannten Stack-Overflow, dessen Ursache ich noch nicht finden konnte. Leider geht JTAG-Debuging nicht, da die Debugports durch Kamera und SD-Karte belegt sind. Das macht die Fehlersuche sehr aufwendig.
Ich halte euch auf dem Laufenden.
Beste Grüße,
jomjol - jetzige Lösung mit ESP + Docker passt für fast alle (
-
@jomjol
wenn du die SD-Karte nicht brauchst dann kann ich dir gerne ein JTAG Interface "anlöteten"
