Peut-on faire de la vision par ordinateur sur un ESP32-CAM en classe, ou est-ce trop lent ?
Un ESP32-CAM peut gérer la détection faciale basique et le seuillage de couleur, mais la fréquence chute à 2–5 FPS en charge. Pour un cours de 45 minutes, exécuter les modèles de vision dans le navigateur s'avère généralement bien plus fiable.
Oui, un ESP32-CAM peut exécuter de la vision par ordinateur élémentaire directement sur la puce, mais avec de sévères contraintes : comptez 2 à 6 images par seconde pour un suivi léger de taches de couleur ou une détection de visage, chutant sous 1 image par seconde pour tout ce qui s'apparente à un véritable modèle d'apprentissage automatique. Si un élève s'attend à un suivi interactif en temps réel digne d'une application pour smartphone, la seule latence matérielle fera dérailler le cours.
Pour des projets structurés en classe, la question est rarement de savoir si le microcontrôleur peut techniquement traiter des pixels ; il s'agit plutôt de savoir si les frictions de débogage sont compatibles avec une séance de 45 minutes. Comprendre où se situent les goulots d'étranglement permet de décider s'il faut flasher la carte ou conserver le traitement dans le navigateur.
Ce que l'ESP32-CAM peut réellement faire sur la puce
L'ESP32-CAM standard associe une puce Espressif ESP32-D0WDQ6 (Tensilica Xtensa LX6 double cœur à 240 MHz) à un module caméra OV2640 et 4 Mo de PSRAM (RAM pseudo-statique) externe. Comme la vision par ordinateur nécessite d'importants tampons mémoire pour les trames d'image, le calcul brut est lourdement bridé par la vitesse de transfert des données entre le capteur, la PSRAM et le cache du processeur.
| Tâche de vision | Fréquence typique | Viabilité sur un cours de 45 minutes |
|---|---|---|
| Suivi de couleur / seuillage (Blob tracking) | 6–12 FPS (QQVGA 160×120) | Viable. Fonctionne bien pour suivre une ligne ou une balle de couleur vive. |
| Détection faciale par cascades de Haar (ESP-WHO) | 2–5 FPS (QVGA 320×240) | Marginal. Démontre la détection, mais les mouvements doivent être lents. |
| Reconnaissance faciale (Enrôlement + Comparaison) | 0,5–2 FPS | Fragile. Les variations d'éclairage et les légers angles de vue font rapidement échouer la reconnaissance. |
| Classification d'objets par ML embarqué (TensorFlow Lite Micro) | 0,2–1 FPS (96×96 niveaux de gris) | Inutilisable pour de la robotique en direct ; viable uniquement pour la classification d'instantanés statiques. |
Le suivi par couleur fonctionne car il ne repose que sur une arithmétique simple : comparer les valeurs RVB ou HSV de chaque pixel à des seuils fixes. La détection faciale via la bibliothèque ESP-WHO d'Espressif utilise des réseaux de neurones simplifiés et des images intégrales, mais à une résolution de 320×240, la puce consacre la quasi-totalité de son budget de calcul à une seule trame, ne laissant qu'une marge infime pour contrôler simultanément des moteurs ou lire des capteurs.
Les modes de défaillance en classe
Dans un atelier personnel, attendre quatre secondes qu'une carte capture et classifie une image n'est qu'un désagrément mineur. Dans une salle informatique scolaire, cela engendre des points de rupture bien précis :
- Effondrement du flux Wi-Fi : de nombreux tutoriels pour ESP32-CAM reposent sur la diffusion de trames JPEG en Wi-Fi local vers un serveur web hébergé sur la puce. Dans une classe où 20 cartes se connectent à un unique point d'accès scolaire (ou échouent face à l'authentification WPA2-Enterprise), le réseau sature immédiatement, provoquant des pertes de connexion et une latence vidéo de plusieurs secondes.
- Sensibilité à la lumière : le capteur économique OV2640 manque de plage dynamique. Un modèle calibré sous l'éclairage fluorescent d'une salle de classe échoue dès que la lumière du soleil de l'après-midi frappe le bureau, transformant un cours de programmation en un exercice frustrant de réglage d'optique.
- Chutes de tension et redémarrages intempestifs (brownouts) : lorsque l'ESP32 active sa radio Wi-Fi tout en capturant une trame, les pics de consommation dépassent 300 mA. Si les élèves alimentent leurs cartes via des hubs USB bas de gamme ou des ports d'ordinateurs portables non alimentés, la carte subit des baisses de tension répétées et redémarre en boucle.
L'alternative : déporter la vision dans le navigateur
Si votre objectif pédagogique est d'enseigner la logique de la vision par ordinateur — comme la classification d'objets, l'estimation de posture ou le suivi spatial —, exécuter l'inférence directement sur le microcontrôleur constitue souvent un mauvais choix d'architecture. Une approche bien plus robuste repose sur le calcul distribué :
Laissez la caméra de l'ordinateur portable de l'élève capturer l'image et exécuter le modèle de vision dans le navigateur via WebAssembly ou TensorFlow.js à 30 FPS, puis transmettez de simples commandes directionnelles d'un octet (comme
LEFT,RIGHTouSTOP) au microcontrôleur via Web Serial ou Bluetooth.
Cette approche sépare les responsabilités : l'élève débogue la logique de vision avec un retour visuel immédiat sur un écran haute résolution, tandis que le microcontrôleur se consacre entièrement au pilotage des moteurs et aux entrées-sorties matérielles. Des plateformes comme Sheen Canvas exploitent ce modèle hybride afin que les élèves puissent concevoir des systèmes robotiques interactifs en temps réel sans s'enliser dans l'allocation mémoire bas niveau et la latence des mémoires tampons d'image.
Quand utiliser réellement l'ESP32-CAM ?
Utilisez l'ESP32-CAM directement sur la puce lorsque la séance porte spécifiquement sur les contraintes des systèmes embarqués et l'architecture IoT en périphérie (edge) — comme une caméra pour plante connectée qui se réveille une fois toutes les dix minutes, capture une image fixe, la sauvegarde sur une carte SD et repasse en sommeil profond (deep sleep). Pour la robotique en temps réel, les rovers autonomes et les projets de vision interactifs, laissez le poste de travail faire le gros du calcul et confiez au microcontrôleur le contrôle des moteurs.
