Wir haben uns überlegt, wie wir eine maßgefertigte Kameralösung anbieten könnten, die erschwinglich und einfach in die mehr als 400.000 originalen Prusa-Drucker zu integrieren wäre, die wir bereits weltweit ausgeliefert haben. Eines Tages stießen wir auf eine großartige Open-Source-Lösung, die von einem Mitglied unserer Community, Miroslav Pivovarský, speziell für Prusa Connect gemacht wurde – ein ESP32-CAM-Modul mit angepasster Firmware.

Dieses erschwingliche Modul verfügt über eine integrierte Blitz-LED und WiFi. Sie können es so gut wie überall kaufen, mit Miroslav’s Firmware flashen und sofort verwenden. Es ist nicht besonders revolutionär, aber es bietet eine einfache, billige und vor allem funktionelle Lösung für die Kamerafernüberwachung Ihres Druckers.

Sobald Sie die Firmware geflasht haben, ist die gesamte Einrichtung eine Sache von ein paar Klicks. Danach müssen Sie die Kamera nur noch in Prusa Connect registrieren, ihr Zugriffstoken kopieren und in wenigen Sekunden sehen Sie den ersten Schnappschuss in Ihrer Benutzeroberfläche. Erwarten Sie keinen 4K60-Videostream. Bei der aktuellen Implementierung sendet sie alle paar Sekunden ein Bild, aber selbst das ist mehr als genug, um Ihren Druck aus der Ferne zu überprüfen. Oder sogar um das Bild an ein neuronales Netzwerk zur automatischen Fehlererkennung zu senden, wie wir in der Prusa Podcast Episode über KI im 3D-Druck angedeutet haben. Und da die Firmware über OTA-Updates verfügt, kann die Funktionalität in Zukunft noch verbessert werden.

Eine detaillierte Anleitung für die gesamte Einrichtung finden Sie in in diesem PDF. Sie können auch eine praktische Kamerahalterung drucken, die Sie am Rahmen Ihres 3D-Druckers befestigen können. Sie ist flexibel und dennoch stabil und Sie können die Position der Kamera ganz einfach darauf einstellen. Es wurde von dem großartigen Designer Michal Fanta, entworfen und Sie können es kostenlos von Printables herunterladen, zusammen mit dem Gehäuse für das Kameramodul.

Und wenn Sie sich fragen, was es braucht, um eine solche Lösung zu entwickeln, einschließlich der Webanwendungsschnittstelle, OTA-Firmware-Updates und vieler anderer interessanter Dinge, dann lassen Sie uns Ihnen die detaillierte Geschichte hinter der Entwicklung erzählen! 🙂

Die Geschichte beginnt

Miroslav begann zu erklären, wie die Arbeit an seiner Kameralösung begann: „Wir hatten ein paar MK3S+ 3D-Drucker auf der Arbeit und sie waren über einen Raspberry Pi mit laufender PrusaLink-Software mit dem Netzwerk verbunden.“ Mit PrusaLink erhalten Sie selbst auf älteren 8-Bit-Geräten erweiterte Netzwerkfunktionen und können sie mit Prusa Connect verbinden. „Ich habe ein älteres Smartphone als Remote-Kamera verwendet (eine integrierte Funktion in Prusa Connect), aber ich war auch auf der Suche nach etwas Kompakterem. Idealerweise eine kleine Kamera, die auch alleine funktionieren würde“, fügte er hinzu.

Also begann er in der Zwischenzeit, das Innenleben des Systems zu analysieren – insbesondere wie das Telefon das Bild an Connect sendet. Es dauerte nicht lange, bis er das NodeJS-Skript, das die Bildübertragungen verwaltet, so modifiziert hatte, dass es die aufgenommenen Fotos von einer kleinen Raspberry Pi Kamera über den CSI-Bus abrufen konnte.

Miroslav lud das Skript dann auf einen anderen Raspberry Pi hoch, schloss die Kamera daran an und führte das Skript aus, um das Bild von der Kamera zu holen und es an Connect zu senden. Allerdings gab es noch einen Nachteil: Es wurden zwei RPi-Boards benötigt – eines für die Verwaltung der Kamera, das andere für die Ausführung von PrusaLink. Es funktionierte, aber wie Miroslav sagte, war es alles andere als ideal.

Kamera angebracht am Original Prusa MK4

Wie es so oft geschieht, kam der Durchbruch durch reinen Zufall. „Ich habe neulich meinen Schreibtisch und meine Schubladen aufgeräumt, weil ich viele verschiedene Arduino-Module und -Erweiterungen habe – und da war es! Ein kleines ESP32-CAM-Modul.“ Miroslav erinnert sich. Diese billige MCU (Micro Controller Unit) hat einen eigenen ARM-Prozessor, einen großen Flash-Speicher, ausreichend RAM und auch ein Wi-Fi-Modul. Es war perfekt! 🙂 .

Natürlich war der Weg zu einer funktionierenden Lösung nicht ganz geradlinig. Es sah zwar so aus, als ob die grundlegende Arduino IDE (die Entwicklungsumgebung) ausreichen würde, aber das stimmte nicht ganz. Letztendlich hat Miroslav seinen eigenen HTTP-Server erstellt, um eingehende Bilder zu empfangen und zu speichern, genau wie Prusa Connect. Mit diesem Server testete er die ersten Versionen seiner Skripte – diejenigen, die bereits auf dem Raspberry Pi funktionierten.

Es funktioniert auf meinem Raspberry Pi!

Der nächste Schritt war ziemlich offensichtlich – das ESP32-CAM sollte die gleiche Aufgabe erfüllen wie der Raspberry Pi. Dazu war es notwendig zu verstehen, wie das Kameramodul funktioniert und wie man Fotos nicht nur über HTTP, sondern auch über HTTPS sendet, das Prusa Connect verwendet und das komplexer zu handhaben ist. Nach einigen Nachforschungen, der Beschaffung und der korrekten Einrichtung des erforderlichen Zertifikats gelang es Miroslav jedoch, die richtigen Daten von der ESP32-CAM an den Server und sogar an Prusa Connect zu senden! Alles schien gut zu funktionieren, aber die ersten Probleme traten sofort auf.

Eines der größten Probleme betraf die Größe und Auflösung des gesendeten Bildes. Die maximale Auflösung, die ohne Probleme gesendet werden konnte, betrug 320×240 Pixel, was nicht besonders viel ist. Diese Einschränkung wurde durch das ESP32-CAM-Modul selbst verursacht, bei dem das Problem auftrat, wenn die Größe der über HTTPS gesendeten Datei größer als 9kB war. Nach einiger Recherche und mehreren Versuchen fand Miroslav heraus, dass alles korrekt funktioniert, wenn er die Datei in 5kB große Fragmente aufteilt und diese nacheinander versendet. Obwohl das Hochladen dadurch etwas langsamer wurde, war es eine ideale Lösung, zumindest für den Moment.

Es reichte sogar aus, um einen Videostream für ein lokales Netzwerk zu erstellen. Die ursprüngliche Befürchtung war, dass die maximale Framerate bei etwa 1FPS liegen würde, aber nach einigen Problemlösungen, bei denen das Streaming verschiedene Farbartefakte und eine schlechte horizontale Synchronisation verursachte, zeigten die Ergebnisse 5-7FPS bei einer Auflösung von 1024×768, was ein tolles Ergebnis war 🙂. Und die MCU sollte das Potenzial haben, noch mehr FPS und eine bessere Auflösung zu erreichen, also arbeitet Miroslav weiter daran.

Jetzt hatte Miroslav eine einfache, aber funktionale Softwarelösung, die er sofort auf GitHub und im Prusa Forum teilte, weil er einfach der Erste sein wollte, der diese Lösung gefunden hatte.

Sie können das letzte Bild der Kamera in der Prusa Connect Anwendung sehen

Es gab noch viele Dinge zu lösen, zum Beispiel war es nicht ideal, dass die gesamte MCU-Konfiguration in den Quellcode integriert ist – der Token, der Fingerabdruck, die WiFi SSID, die Kameraeinrichtung und mehr. Dieses ganze Paket wird kompiliert und in den Speicher der MCU geflasht, ohne dass weitere Änderungen möglich sind. Also begann Miroslav nach einer Lösung auf einem Gebiet zu suchen, mit dem er wenig Erfahrung hatte – der Webschnittstelle.

Obwohl die Webentwicklung nicht Miroslavs Hauptaugenmerk war, nahm er seine Idee mit Begeisterung auf und nach mehreren Programmierabenden hatte er eine funktionale Webanwendung für die Kamerakonfiguration entwickelt, die direkt auf dem Kameramodul lief. „Es sah aus, als käme es direkt aus den 90er Jahren, aber es funktionierte, also war das für mich in Ordnung.“ Miroslav lachte.

Eine der ersten Versionen der Kamera-Weboberfläche

Auf den Pfaden der Entwicklung

Auch uns ist seine Lösung aufgefallen und sie gefiel uns sehr gut, also haben wir ihn per E-Mail kontaktiert und ihm eine Zusammenarbeit bei der Entwicklung angeboten. „Ich war von dem Angebot sehr angenehm überrascht und habe sofort zugestimmt. Unter anderem, weil ich gerne mehr zur Open-Source-Gemeinschaft beitragen möchte,“ sagte Miroslav.

Nach einigen Diskussionen und der Überprüfung des Codes kamen wir auf mehrere Ideen zur Verbesserung der Software und der Weboberfläche, z.B. die Implementierung einer moderner aussehenden Benutzeroberfläche, usw. Miroslav griff all diese Punkte mit Begeisterung auf und begann sofort mit der Arbeit daran. „Der schwierigste Teil des gesamten Projekts war für mich die Entwicklung der Webanwendung selbst“, so Miroslav. Die Webseite musste gut und modern aussehen, idealerweise in einem Prusa-Design, und gleichzeitig in den begrenzten Flash-Speicher der MCU passen. Andererseits kam er nach der Analyse und Lektüre mehrerer Artikel zu dem Schluss, dass seine aktuelle Lösung, die eine Kombination aus HTML und JavaScript mit jQuery beinhaltet, der richtige Weg ist.

Miroslav nutzte auch die Gelegenheit, mit KI zu arbeiten, die ihm bei der Erstellung der Website half. Er beriet und erklärte zum Beispiel die einzelnen Komponenten, wie sie heißen, wie man sie verwendet usw. „Es war lustig. Ich habe versucht, der KI zu erklären, was ich wollte, aber ich wusste nicht einmal genau, was ich wollte. Ich wusste nur, wie es am Ende aussehen sollte“, sagte Miroslav. Er gab auch zu, dass er, obwohl die Weboberfläche optimaler und schöner hätte sein können, eine gute Zeit bei der Entwicklung hatte und eine Menge neuer Dinge gelernt hat.

Die Notwendigkeit der Konfiguration

Als das Design der Weboberfläche so gut wie fertig war, begann er über weitere Funktionen nachzudenken. Zum Beispiel sollten Firmware-Updates über die Weboberfläche möglich sein – die Kamera könnte die neueste Firmware-Version überprüfen und bei Bedarf herunterladen, und alles sollte so benutzerfreundlich wie möglich sein.

Aktuelles Erscheinungsbild der Kamera-Weboberfläche

Nun war es an der Zeit, sich mit einem der wichtigsten Dinge zu befassen, nämlich dem ersten Start und der Einrichtung der MCU. Miroslav hat sich zwei verschiedene Lösungen ausgedacht, die nebeneinander existieren können und jeder kann die bevorzugte Art der Kamera-Initialisierung wählen.

Die erste Lösung ist der AP-Modus, bei dem nach dem Einschalten der MCU ein Zugangspunkt mit einer bestimmten SSID erstellt wird. Der Client kann sich über WiFi mit dem AP verbinden und hier die Anmeldedaten seines drahtlosen Netzwerks einstellen und die Kamera weiter konfigurieren. Um zu verhindern, dass ungenutzte APs das 2,4-GHz-WiFi-Band unnötig stören (stellen Sie sich vor, Sie hätten Dutzende von ihnen eingeschaltet), wird der AP-Modus automatisch ausgeschaltet, wenn sich innerhalb von fünf Minuten nach dem Einschalten der Kamera kein Gerät verbindet.

Sobald Ihre Kamera eingerichtet ist, können Sie die Verwaltung im Netzwerk über die IP-Adresse ausfindig machen, aber das ist nicht sehr bequem, vor allem, wenn Sie die IP-Adresse nicht kennen und keinen Zugang zur Verwaltung Ihres Routers haben. Um das Problem zu lösen, hat Miroslav die Kamera-Software um die mDNS-Funktionalität erweitert. Das bedeutet, dass Sie auf das Gerät in Ihrem lokalen Netzwerk über einen DNS-Eintrag zugreifen können (Sie können sich das wie einen Spitznamen vorstellen), so dass Sie die IP-Adresse nicht kennen oder sich diese merken müssen. Der mDNS-Eintrag ist konfigurierbar – zum Beispiel lautet er jetzt http://prusa-esp32cam.local

Die Lösung für den AP-Modus brachte jedoch ein Problem mit sich, denn die Weboberfläche muss im Offline-Modus funktionieren, während sich der Benutzer im AP-Modus mit der Kamera verbindet. Deshalb war es notwendig, die jQuery-Bibliothek direkt im Quellcode der MCU zu speichern. Glücklicherweise gibt es bereits kleine und optimierte jQuery-Bibliotheken für diesen Zweck, obwohl sie immer noch etwa 86kB des Flash-Speichers der MCU beanspruchen, und das ist eine ganze Menge.

Eine weitere Möglichkeit, die Kamera zu konfigurieren, war eine serielle Kommunikationsschnittstelle, die der Benutzer anstelle des AP-Modus verwenden kann, wenn er diesen nicht nutzen kann oder will. Hier kann der Benutzer die WiFi Zugangsdaten und das Autorisierungs-Token für die Backend-Anwendung festlegen, die IP-Adresse der Kamera im Netzwerk anzeigen oder andere Befehle über die Konsole verwenden.

Je größer es wird…

Zu diesem Zeitpunkt ist das Projekt schon ziemlich gewachsen. Miroslav hat die Webseite etwa 3-4 Mal umgeschrieben, weil er immer etwas fand, das man besser machen konnte. Die erste Version des Codes war in C geschrieben, so dass er jetzt versucht, alles in C++ umzuschreiben, was immer noch nicht ganz fertig ist, aber der Code wird Stück für Stück bearbeitet und verbessert. Obwohl das Projekt ziemlich gewachsen ist, wurde und wird es als Arduino-Projekt weitergeführt, so dass die Community den Quellcode leicht bearbeiten kann, ohne eine andere spezielle IDE mit einem Compiler verwenden zu müssen.

Nun war es an der Zeit, herauszufinden, wie man das OTA (over-the-air) Firmware-Update implementieren kann. Die aktuelle MCU-Version hat 4 MB Flash-Speicher, was bedeutet, dass nur 1,9 MB Flash für die gesamte Anwendung verwendet werden können. Wenn Sie sich fragen, warum das so ist, dann liegt das daran, dass für das Firmware-Update das so genannte „Double Banking“ verwendet wird, was bedeutet, dass der Speicher in zwei Sektoren aufgeteilt ist (eigentlich sind es mehr, aber der Einfachheit halber sagen wir zwei). In einem Sektor läuft eine aktuelle, gültige Anwendung (nennen wir ihn Sektor A). Im anderen Sektor befindet sich eine ungültige, veraltete Anwendungsversion (Sie haben es erraten, es ist Sektor B).

Kamerasysteminformationen, einschließlich OTA-Firmware-Update-Optionen

Wenn die neue Firmware heruntergeladen wird, wird der Sektor B (die ungültige Anwendung) überschrieben. Dann wird die Integrität der installierten Firmware überprüft, und wenn alles in Ordnung ist, wird die Anwendung in Sektor B als aktive Anwendung festgelegt. Dank dieses Systems überschreibt ein OTA-Update niemals die gerade laufende Anwendung.

Hardware-Einschränkungen

Zusätzlich zu den verschiedenen Softwareproblemen gab es auch einige Probleme mit der Hardware selbst. Einige der Testgeräte sendeten keine Fotos mehr, trennten sich ständig vom WiFi, starteten neu usw. „Es waren viele verschiedene Probleme, aber ich hatte Spaß daran, sie zu lösen. Es war sehr interessant zu sehen, wie sie auftreten und dann Lösungen zu finden, um sie zu beseitigen“, kommentierte Miroslav.

Das größte Problem wurde durch das Design des ESP32-CAM-Boards verursacht. Da der Prozessor nur wenige Pins und eine relativ große Anzahl von Peripheriegeräten hat, verwendete der Designer den Pin für die Beleuchtung der LED auch als einen der Pins für die Kommunikation mit der microSD-Karte. Dies führte zu einem Problem bei der Kommunikation zwischen der MCU und der microSD-Karte, wenn die LED leuchtete. Das Problem wurde gelöst, indem der „Ein-Draht-Modus“ der microSD-Karte verwendet wurde, bei dem die Daten nur über einen digitalen Eingang/Ausgang gelesen und geschrieben werden.

Das viel größere Problem liegt bei der Flash-LED auf der Platine – der Designer hat diese LED direkt an 3,3V ohne einen Strombegrenzungswiderstand, angeschlossen, wodurch der durch die LED fließende Strom zu hoch ist und die Diode nach einer gewissen Zeit erlischt. Auf einer Platine ging die LED nach einem Monat, in dem sie alle 30 Sekunden blinkte, aus. Miroslav fand mehrere Lösungen für dieses Problem, darunter das Einlöten eines Widerstands zwischen dem Kollektor des Transistors und der Platine oder die Verwendung einer externen Lichtquelle, die durch ein Relais, einen MOSFET oder etwas Ähnliches geschaltet wird. Einige Teile der Platine erhitzen sich auch ziemlich stark, aber das hängt von der aktuellen Charge ab. An diesem Problem wird immer noch gearbeitet, denn verschiedene Versuche, wie z.B. die Reduzierung der Taktfrequenz des Prozessors, haben keine große Verbesserung gebracht.

Die wenigen möglichen Lösungen für das LED-Problem, die Miroslav vorgeschlagen hat

Wie Sie sehen können, gibt es bei diesem Projekt noch viele Dinge zu lösen und zu verbessern. Trotzdem hat Miroslav immer noch Spaß daran und arbeitet gerne daran. Was ihm am meisten Spaß macht, ist herauszufinden, was man mit einem kleinen, billigen Kameramodul alles machen kann. Er würde gerne noch mehr an Multitasking arbeiten, da alles gleichzeitig auf nur einem Prozessorkern läuft, obwohl der Prozessor zwei Kerne hat (Dual Core). Und es gibt sicher noch einen Haufen anderer Optimierungen, die er gerne hinzufügen würde.

Zögern Sie also nicht, diese interessante Kameralösung auszuprobieren, und teilen Sie uns und dem Autor bitte auch Ihre Kommentare oder Fragen mit. Viel Spaß beim Drucken!