Nous nous demandions comment proposer une solution de caméra personnalisée qui serait abordable et facile à intégrer dans plus de 400 000 imprimantes Original Prusa que nous avons déjà expédiées dans le monde entier. Un jour, nous sommes tombés sur une excellente solution open source spécialement conçue pour Prusa Connect par un membre de notre communauté, Miroslav Pivovarský – un module ESP32-CAM avec firmware personnalisé.

Ce module abordable a une flash, des LED et un WiFi intégrés, et vous pouvez l’acheter à peu près n’importe où, le flasher avec le firmware de Miroslav, et commencer à l’utiliser immédiatement. Il n’est pas particulièrement révolutionnaire, mais il offre une solution de surveillance par caméra à distance de votre imprimante facile, bon marché et surtout fonctionnelle.

Une fois que vous avez flashé le firmware, toute la configuration est une question de quelques clics. Après cela, tout ce que vous avez à faire est d’enregistrer la caméra dans Prusa Connect, de copier son jeton d’accès et, dans quelques secondes, vous verrez son premier instantané dans votre interface. Ne vous attendez pas à un flux vidéo 4K60, avec l’implémentation actuelle, elle envoie une image toutes les deux secondes, mais même cela est plus que suffisant pour vérifier à distance votre impression. Ou même pour envoyer l’image dans un réseau neuronal pour la détection automatique des écheccs, comme nous l’avons teasé dans l’épisode du Prusa Podcast sur l’IA dans l’impression 3D. Et comme le firmware propose des mises à jour OTA, la fonctionnalité pourra être améliorée à l’avenir.

Des instructions détaillées pour l’ensemble de la configuration peuvent être trouvées dans ce PDF. Vous pouvez également imprimer un support de caméra pratique qui peut être fixé au cadre de votre imprimante 3D. Il est flexible, mais robuste, et vous pouvez facilement y définir la position de la caméra. Il a été créé par le grand designer, Michal Fanta et vous pouvez le télécharger gratuitement sur Printables, avec le boîtier pour le module caméra.

Et si vous vous demandez ce qu’il faut pour développer une telle solution, y compris l’interface d’application Web, les mises à jour du micrologiciel OTA et bien d’autres choses intéressantes, laissez-nous vous donner les informations nécessaires.histoire détaillée derrière son développement! 🙂

L’histoire commence

Miroslav a commencé à expliquer comment le travail sur sa solution de caméra a commencé : « Nous avions quelques imprimantes 3D MK3S+ au travail, et elles étaient connectées au réseau via un Raspberry Pi avec PrusaLink dessus. » PrusaLink vous permet d’obtenir des fonctionnalités réseau avancées même sur les anciennes machines 8 bits et vous permet de les connecter à Prusa Connect. « J’utilisais un ancien smartphone comme caméra distante (une fonctionnalité intégrée à Prusa Connect), mais je cherchais également quelque chose de plus compact. Idéalement, un petite caméra qui fonctionnerait toute seul », a-t-il ajouté.

Entre-temps, il a commencé à analyser le fonctionnement interne du système, notamment la manière dont le téléphone envoie l’image à Connect. Il n’a pas fallu longtemps pour modifier le script NodeJS qui gère les transferts d’images, afin qu’il puisse obtenir des photos capturées depuis une petite caméra Raspberry Pi via le bus CSI.

Miroslav a ensuite téléchargé le script sur une autre Raspberry Pi, y a connecté la caméra et a exécuté le script pour récupérer l’image de la caméra et l’envoyer à Connect. Cependant, il y avait quand même un inconvénient : il fallait deux cartes RPi – une pour gérer la caméra, l’autre pour exécuter PrusaLink. Cela a fonctionné, mais comme l’a dit Miroslav, c’était loin d’être idéal.

Caméra fixée sur l’Original Prusa MK4

Comme cela arrive souvent, une percée est survenue par pure coïncidence. « L’autre jour, je nettoyais mon bureau et mes tiroirs parce que j’ai plein de modules et d’addons Arduino différents – et le voilà ! Un petit module ESP32-CAM« , se souvient Miroslav. Ce MCU (Micro Controller Unit) bon marché possède son propre processeur ARM, une grande mémoire Flash, suffisamment de RAM et également un module Wi-Fi. Il était parfait ! 🙂

Bien sûr, le chemin vers une solution efficace n’a pas été tout à fait simple. Même s’il aurait pu sembler que l’IDE Arduino de base (l’environnement de développement) suffirait, ce n’était pas tout à fait vrai. Finalement, Miroslav a créé son propre serveur HTTP pour recevoir et enregistrer les images entrantes, tout comme Prusa Connect. Avec ce serveur, il a testé les premières versions de ses scripts – ceux qui fonctionnaient déjà sur la Raspberry Pi.

Cela fonctionne sur ma Raspberry Pi !

L’étape suivante était assez évidente : faire en sorte que l’ESP32-CAM fasse le même travail que la Raspberry Pi. Il fallait comprendre comment fonctionne le module caméra et comment envoyer des photos non seulement via HTTP, mais aussi via HTTPS, qu’utilise Prusa Connect et qui est plus complexe à utiliser. Cependant, après quelques recherches, l’obtention du certificat nécessaire et sa bonne configuration, Miroslav a réussi à envoyer les données correctes de l’ESP32-CAM au serveur et même à Prusa Connect ! Tout semblait bien fonctionner, mais les premiers problèmes sont apparus immédiatement.

L’un des plus gros problèmes concernait la taille et la résolution de l’image envoyée. La résolution maximale, envoyée sans problème, était de 320×240 pixels, ce qui n’est pas particulièrement beaucoup. Cette limitation était causée par le module ESP32-CAM lui-même, dans lequel le problème se produisait, lorsque la taille du fichier envoyé via HTTPS était supérieure à 9 Ko. Après quelques recherches et plusieurs tentatives, Miroslav a découvert que s’il divisait le fichier en fragments de 5 Ko et les envoyait séquentiellement, tout fonctionnait correctement. Même si cela entraînerait des téléchargements légèrement plus lents, c’était une solution idéale, du moins pour le moment.

C’était même suffisant pour créer un flux vidéo pour un réseau local. La préoccupation initiale était que la fréquence d’images maximale serait d’environ 1 FPS, mais après quelques problèmes de résolution, où le streaming provoquait divers artefacts de couleur et une mauvaise synchronisation horizontale, les résultats ont montré 5-7FPS à une résolution de 1024×768, ce qui était un excellent résultat 🙂. Et le MCU devrait avoir le potentiel d’obtenir encore plus de FPS et une meilleure résolution, donc Miroslav continue à travailler dessus.

Désormais, Miroslav disposait d’une solution logicielle simple mais fonctionnelle, qu’il a immédiatement partagée sur GitHub et le forum Prusa, car il voulait juste être le premier à proposer cette solution.

Vous pouvez afficher la dernière image de la caméra dans l’application Prusa Connect

Il restait encore beaucoup de choses à résoudre, par exemple, il n’était pas idéal que toute la configuration du MCU soit intégrée dans le code source – le jeton, l’empreinte digitale, le SSID WiFi, la configuration de la caméra, etc. L’ensemble de ce package est compilé et flashé dans la mémoire du MCU, sans possibilité de modifications supplémentaires. Ainsi, Miroslav a commencé à chercher une solution dans un domaine avec lequel il avait peu d’expérience – l’interface web.

Même si le développement web n’était pas l’objectif principal de Miroslav, il a adopté son idée avec enthousiasme et après plusieurs soirées de programmation, il a créé une application web fonctionnelle pour la configuration de la caméra, qui s’exécutait directement sur le module de la caméra. « On aurait dit qu’elle venait tout droit des années 90, mais ça a marché, donc ça me convenait. » Miroslav rit.

Une des premières versions de l’interface web de la caméra

Sur les rails du développement

Nous avons également remarqué sa solution et l’avons beaucoup appréciée, nous l’avons donc contacté par e-mail et lui avons proposé de coopérer sur son développement. « J’ai été très agréablement surpris par l’offre et j’ai immédiatement accepté. Entre autres choses, parce que je voudrais contribuer davantage à la communauté open source« , a déclaré Miroslav.

Après quelques discussions et révisions du code, nous avons proposé plusieurs idées pour améliorer le logiciel et l’interface web, par exemple, la mise en œuvre d’une interface utilisateur plus moderne, etc. Miroslav a abordé tous ces points avec enthousiasme et a immédiatement commencé à y travailler. « Pour moi, la partie la plus difficile de tout le projet a été le développement de l’application web elle-même », a déclaré Miroslav. Le site web devait être beau et moderne, idéalement dans un design Prusa, tout en s’intégrant dans la mémoire Flash limitée du MCU. D’un autre côté, après avoir analysé et lu plusieurs articles, il a évalué que sa solution actuelle, impliquant une combinaison de HTML et JavaScript avec jQuery, était la bonne voie à suivre.

Miroslav en a également profité pour travailler avec une IA, ce qui l’a aidé dans la création du site. Par exemple, il a conseillé et expliqué les différents composants, comment ils s’appellent, comment les utiliser, etc. « C’était drôle. J’ai essayé d’expliquer à l’IA ce que je voulais, mais je ne savais même pas exactement ce que je voulais. Je savais juste à quoi je voulais que ça ressemble à la fin », a mentionné Miroslav. Il a également admis que même si l’interface web aurait pu être plus optimale et plus agréable, il a passé un bon moment en la développant et a appris beaucoup de nouvelles choses.

Le besoin de configuration

Maintenant que le design de l’interface web était pratiquement terminée, il a commencé à réfléchir à d’autres fonctionnalités. Par exemple, les mises à jour du firmware doivent être possibles via l’interface web : la caméra peut vérifier la dernière version du firmware et la télécharger si nécessaire, et tout doit être aussi convivial que possible.

Apparence actuelle de l’interface web de la caméra

Il était maintenant temps de s’attaquer à l’un des problèmes les plus importants, qui était le premier lancement et la configuration du MCU. Miroslav a proposé deux solutions différentes, qui peuvent exister l’une à côté de l’autre et chacun peut choisir sa méthode préférée d’initialisation de la caméra.

La première solution est le mode AP, où un point d’accès avec un SSID spécifique est créé après la mise sous tension du MCU. Le client peut se connecter au point d’accès via WiFi et ici il peut définir les informations de connexion de son réseau sans fil et configurer davantage la caméra. Pour éviter que les points d’accès inutilisés n’interfèrent inutilement avec la bande WiFi 2,4 GHz (imaginez en avoir des dizaines allumés), si aucun appareil ne se connecte dans les cinq minutes suivant la mise sous tension de la caméra, le mode AP est automatiquement désactivé.

Une fois votre caméra configurée, vous pouvez localiser son administration dans le réseau via l’adresse IP, mais cela n’est pas très pratique, surtout si vous ne connaissez pas l’adresse IP et n’avez pas accès à l’administration de votre routeur. Pour faciliter cela, Miroslav a également ajouté la fonctionnalité mDNS au logiciel de la caméra, ce qui signifie que vous pouvez accéder à l’appareil sur votre réseau local via un enregistrement DNS (vous pouvez le considérer comme un surnom), vous n’avez donc pas besoin de connaître ou de retenir son adresse IP. L’enregistrement mDNS est configurable – par exemple, le nom actuel est http://prusa-esp32cam.local

Cependant, la solution du mode AP a posé un problème, car l’interface web doit fonctionner en mode hors ligne, pendant que l’utilisateur se connecte à la caméra en mode AP. De ce fait, il était nécessaire de stocker la bibliothèque jQuery directement dans le code source du MCU. Heureusement, de petites bibliothèques jQuery optimisées existent déjà à cet effet, même si cela nécessite encore environ 86 Ko de mémoire Flash du MCU, et c’est beaucoup.

Une autre façon de configurer la caméra était une interface de communication série, que les utilisateurs peuvent utiliser à la place du mode AP s’ils ne peuvent ou ne veulent pas l’utiliser. Ici, l’utilisateur peut définir les informations d’identification WiFi et le jeton d’autorisation pour l’application backend, afficher l’adresse IP de la caméra sur le réseau ou utiliser d’autres commandes via la console.

Plus ça grossit…

À ce stade, le projet a pris beaucoup d’ampleur. Miroslav a réécrit le site web environ 3 à 4 fois parce qu’il trouvait toujours quelque chose qui pouvait être mieux fait. La première version du code a été écrite en C, alors maintenant il a essayé de tout réécrire en C++, ce qui n’est pas encore complètement fait, mais le code est en cours d’édition et d’amélioration partie par partie. Bien que le projet se soit considérablement développé, il a commencé et se poursuit en tant que projet Arduino, de sorte que la communauté peut facilement éditer le code source sans avoir à utiliser un autre IDE dédié avec un compilateur.

Il était maintenant temps de déterminer comment implémenter la mise à jour du firmware OTA (over-the-air). La version actuelle du MCU dispose de 4 Mo de mémoire Flash, ce qui signifie que seulement 1,9 Mo de Flash peuvent être utilisés pour l’ensemble de l’application. Si vous vous demandez pourquoi, c’est parce que pour la mise à jour du firmware, on utilise ce qu’on appelle le « double banking », ce qui signifie que la mémoire est divisée en deux secteurs (c’est en fait plus, mais par souci de simplicité, disons deux). Dans un secteur, il existe une application à jour et valide (nous l’appellerons secteur A). Dans l’autre secteur, il existe une version d’application invalide et obsolète (vous l’aurez deviné, c’est le secteur B).

Informations sur le système de la caméra, y compris les options de mise à jour du firmware OTA

Lorsque le nouveau firmware est téléchargé, le secteur B (l’application invalide) est écrasé. Ensuite, l’intégrité du firmware installé est vérifiée et si tout va bien, l’application du secteur B est définie comme active. Grâce à ce système, une mise à jour OTA n’écrase jamais l’application en cours d’exécution.

Limites matérielles

En plus de divers problèmes logiciels, il y a également eu quelques problèmes avec le matériel lui-même. Certains des échantillons de test ont arrêté d’envoyer des photos, se déconnectaient régulièrement du WiFi, redémarraient, etc. « Il y avait de nombreux problèmes différents, mais cela m’amusait de les résoudre. C’était très intéressant de voir comment ils se produisent et de trouver ensuite des solutions pour les éliminer », a commenté Miroslav.

Le plus gros problème était causé par le design de la carte ESP32-CAM. Par exemple, étant donné que le processeur possède peu de broches et un nombre relativement important de périphériques, le designer a également utilisé la broche pour éclairer la LED comme l’une des broches pour la communication avec la carte microSD. Cela entraînait un problème de communication entre le MCU et la carte microSD lorsque la LED était allumée. Ce problème a été résolu en utilisant le « mode un fil » de la carte microSD, dans lequel les données sont lues et écrites uniquement via une seule entrée/sortie numérique.

Le problème le plus important concerne la LED flash sur la carte : le designer a connecté cette LED directement au 3,3 V sans résistance de limitation de courant, ce qui rend le courant circulant à travers la LED trop élevé et la diode mourra après un certain temps. Sur une carte, la LED s’est éteinte après un mois de flashage toutes les 30 secondes. Miroslav a proposé plusieurs solutions à ce problème, notamment en soudant une résistance entre le collecteur du transistor et le PCB, ou en utilisant une source de lumière externe, commutée par un relais, un MOSFET ou quelque chose de similaire. Certaines pièces de la carte chauffent également beaucoup, mais cela dépend du lot en cours. Ce problème est toujours en cours d’investigation, car plusieurs tentatives telles que la réduction de la fréquence d’horloge du processeur ont été tentées, mais elles n’ont pas apporté beaucoup d’amélioration.

Les quelques solutions possibles au problème des LED proposées par Miroslav

Comme vous pouvez le constater, il reste encore beaucoup de choses à résoudre et à améliorer dans ce projet. Cependant, Miroslav l’apprécie toujours et aime y travailler. Ce qu’il aime le plus, c’est découvrir ce qui peut être fait avec un petit module de caméra bon marché. Il aimerait travailler encore plus sur le multitâche, puisque tout fonctionne simultanément sur un seul cœur de processeur, bien que celui-ci ait deux cœurs (dual core). Et il y aura sûrement un paquet d’autres ajustements/améliorations qu’il aimerait ajouter.

Alors n’hésitez pas à essayer cette solution de caméra intéressante, et partagez également vos commentaires ou questions avec nous et l’auteur.

Bonne impression !