¿Se puede ejecutar visión artificial en una ESP32-CAM en clase o va demasiado lenta?

Una ESP32-CAM puede gestionar detección facial básica y umbralización de color, pero la tasa de fotogramas cae a 2-5 FPS con carga de trabajo. Para una clase de 45 minutos, ejecutar modelos de visión en el navegador suele ser mucho más fiable.
Sí, una ESP32-CAM puede ejecutar visión artificial básica de forma integrada en el chip (on-chip), pero con limitaciones severas: cabe esperar entre 2 y 6 fotogramas por segundo para un seguimiento ligero de manchas de color o detección facial, cayendo por debajo de 1 fotograma por segundo para cualquier procesamiento similar a un modelo real de aprendizaje automático. Si el alumnado espera un seguimiento interactivo en tiempo real como el de una aplicación móvil, la propia latencia del hardware arruinará la sesión.
En proyectos de aula estructurados, el problema rara vez radica en si el microcontrolador tiene la capacidad técnica de procesar píxeles; la cuestión es si las dificultades de depuración encajan en una clase de 45 minutos. Comprender dónde residen los cuellos de botella determinará si conviene programar la placa o mantener el procesamiento en el navegador.
Qué puede hacer realmente la ESP32-CAM en el chip
La ESP32-CAM estándar combina un chip Espressif ESP32-D0WDQ6 (Tensilica Xtensa LX6 de doble núcleo a 240 MHz) con un módulo de cámara OV2640 y 4 MB de PSRAM externa (RAM pseudoestática). Dado que la visión artificial requiere importantes búferes de memoria para los fotogramas de imagen, el cálculo bruto se ve fuertemente limitado por la velocidad a la que se transfieren los datos entre el sensor, la PSRAM y la caché de la CPU.
| Tarea de visión | Tasa típica de fotogramas | Viabilidad en una clase de 45 minutos |
|---|---|---|
| Seguimiento de manchas de color / umbralización | 6–12 FPS (QQVGA 160×120) | Viable. Funciona bien para seguir una pelota de color brillante o una línea. |
| Detección facial con Haar-Cascade (ESP-WHO) | 2–5 FPS (QVGA 320×240) | Marginal. Permite demostrar la detección, pero el movimiento debe ser lento. |
| Reconocimiento facial (registro y comparación) | 0,5–2 FPS | Frágil. Los cambios de luz y los ángulos leves anulan con facilidad el reconocimiento. |
| Clasificación de objetos con ML en el extremo (TensorFlow Lite Micro) | 0,2–1 FPS (96×96 escala de grises) | Inviable para robótica en directo; válida únicamente para clasificar capturas estáticas. |
El seguimiento por color funciona porque solo requiere operaciones aritméticas sencillas: comparar los valores RGB o HSV de cada píxel con límites de umbral fijos. La detección facial mediante la biblioteca ESP-WHO de Espressif recurre a redes neuronales simplificadas e imágenes integrales, pero a una resolución de 320×240, el chip consume casi todo su presupuesto de cálculo en un único fotograma, sin dejar margen para controlar motores o leer sensores de forma simultánea.
Los modos de fallo en el aula
En un taller doméstico, esperar cuatro segundos a que una placa capture y clasifique una imagen es un inconveniente menor. En el aula de informática de un centro educativo, introduce puntos de fallo críticos:
- Colapso de la transmisión por wifi: Muchos tutoriales de ESP32-CAM se basan en transmitir fotogramas JPEG mediante la red wifi local a un servidor web alojado en el propio chip. En un aula con 20 placas conectándose a un único punto de acceso escolar (o fallando ante la autenticación WPA2-Enterprise), la red se satura de inmediato, provocando pérdidas de conexión y retardos de vídeo de varios segundos.
- Sensibilidad a la iluminación: El económico sensor OV2640 carece de rango dinámico. Un modelo calibrado bajo los fluorescentes del laboratorio fallará en cuanto la luz del sol de la tarde incida sobre la mesa, transformando una clase de programación en un frustrante ejercicio de ajuste de lente.
- Caídas de tensión y reinicios (brownouts): Cuando la ESP32 activa la radio wifi mientras captura un fotograma, el consumo de corriente supera picos de 300 mA. Si los estudiantes alimentan las placas desde concentradores USB de baja calidad o puertos de portátil sin suficiente potencia, la placa sufre caídas de tensión y se reinicia continuamente.
La alternativa: descargar la visión en el navegador
Si el objetivo curricular es enseñar la lógica de la visión artificial —como la clasificación de objetos, la estimación de posturas o el seguimiento espacial—, ejecutar la inferencia directamente en el microcontrolador suele ser una decisión arquitectónica errónea. Un modelo mucho más robusto es el procesamiento distribuido:
Haga que la cámara del portátil del alumno capture la imagen y ejecute el modelo de visión en el navegador mediante WebAssembly o TensorFlow.js a 30 FPS, para enviar después órdenes direccionales sencillas de un solo byte (como
LEFT,RIGHToSTOP) al microcontrolador a través de Web Serial o Bluetooth.
Este enfoque separa responsabilidades: el alumno depura la lógica de visión artificial con retroalimentación visual inmediata en una pantalla de alta resolución, mientras que el microcontrolador se centra por completo en el control de motores y la respuesta del hardware. Plataformas como Sheen Canvas utilizan este modelo dividido para que los alumnos puedan construir proyectos de robótica interactiva en tiempo real sin atascarse con la asignación de memoria de bajo nivel ni la latencia del búfer de fotogramas.
¿Cuándo conviene realmente utilizar la ESP32-CAM?
Utilice la ESP32-CAM de forma autónoma en el chip cuando la lección trate específicamente sobre las limitaciones de los sistemas embebidos y la arquitectura IoT en el extremo (edge)—por ejemplo, una cámara automatizada para plantas que se active cada diez minutos, capture una fotografía estática, la guarde en una tarjeta SD y vuelva a entrar en modo de suspensión profunda (deep sleep). Para robótica en tiempo real, vehículos autónomos y proyectos de visión interactiva, deje la computación pesada en el ordenador y permita que el microcontrolador se encargue de mover las ruedas.



