Imagina un taller chico en Quilicura: cuatro impresoras 3D corriendo pedidos de piezas, un turno de noche que no existe porque no da el presupuesto, y la costumbre de dejar las máquinas trabajando solas hasta el otro día. Cuando una pieza se despega de la cama a las dos de la mañana, la impresora no se entera. Sigue extruyendo al aire durante seis horas. A las nueve hay un ovillo de filamento pegado al cabezal, un rollo perdido y un pedido que hay que empezar de nuevo.
Ese es el problema que resuelve este proyecto, y de paso es el mejor ejemplo práctico de Edge AI que vas a encontrar: un modelo de inteligencia artificial corriendo en la máquina, al lado de la impresora, sin nube, sin suscripción y sin que ninguna foto de tu taller salga a internet.
En este artículo vas a entender qué es Edge AI en concreto y no en abstracto, por qué la detección de anomalías es el enfoque correcto para esta tarea, cómo se arma el sistema completo desde la cámara hasta la notificación al celular, y. lo más valioso. las seis lecciones que salieron de operarlo en la vida real, incluyendo las dos veces que los números parecían un desastre y no lo eran. Al final vas a poder decidir si te conviene replicarlo, y con qué presupuesto.
Qué significa Edge AI cuando lo bajas a un taller
Edge AI quiere decir que el modelo corre en el dispositivo, en terreno, en vez de mandar imágenes o datos de sensores a un servidor. En este caso: un Arduino UNO Q montado al lado de la impresora, con Linux corriendo sobre el procesador Qualcomm y un modelo de visión encima.
Lo que ganas es concreto:
- Los datos se quedan. Ni una foto del taller sale de la red.
- No hay costo recurrente. Sin suscripción, sin costo por imagen procesada.
- Funciona sin internet. El sistema no se cae porque se cayó la fibra.
Lo que pagas también es concreto: poder de cómputo limitado y poca memoria. El modelo tiene que ser chico y la tarea, acotada.
Y acá está el punto que hace de este proyecto un caso de estudio decente y no una demo: la tarea sí es acotada. La pregunta es una sola. ¿se ve normal la cama de impresión?. los datos se generan justo ahí, y el tiempo real en milisegundos no hace falta. Una imagen cada 15 segundos alcanza y sobra, porque un ovillo de spaghetti necesita minutos para crecer. Al mismo tiempo, nadie quiere mandar un flujo permanente de fotos de su taller a un servidor ajeno ni pagar una mensualidad por eso.
Por qué un sensor común no sirve acá
Vale detenerse en esto, porque explica por qué hay que meter IA en el asunto y no basta con un sensor y un umbral.
Una impresión se ve distinta en cada minuto. La cama se mueve, el cabezal entra y sale del cuadro, el objeto crece capa a capa, el filamento cambia de color entre trabajos. Un detector de movimiento no distingue "sana" de "rota", y un valor fijo de brillo tampoco: los dos ven cambio permanente en las dos situaciones.
Un modelo de anomalías sí puede, porque vio miles de imágenes de impresiones normales y avisa de todo lo que se aparta de eso: spaghetti, una pieza despegada, un hilo cruzado sobre la cama.
El sistema, comparado con no tener nada
| Situación | Sin vigilante | Con vigilante |
|---|---|---|
| Falla durante la noche | Te enteras en la mañana: ovillo, rollo perdido, en el peor caso el hotend encapsulado | Notificación en menos de un minuto, con pausa automática opcional |
| Evidencia de qué pasó | Ninguna | Foto con las regiones sospechosas marcadas |
| Control a distancia | Mirar la cámara en vivo cada cierto rato | Página de estado con semáforo y score; el sistema mira por ti |
| Costos y datos | Servicio en la nube con suscripción y subida de imágenes | Inversión única, todo local, ninguna imagen sale de la red |
Cómo funciona: el ciclo completo en una vuelta
El vigilante trabaja en un ciclo simple, y conviene tenerlo claro antes de mirar cualquier código:
- El UNO Q le pregunta a la impresora, vía la API de Moonraker, si está imprimiendo.
- Si la respuesta es sí, captura una imagen de la cámara.
- Pasa la imagen por el modelo de anomalías y recibe un score de vuelta.
- Si tres de las últimas cuatro revisiones superan el umbral de alarma, dispara: matriz LED en rojo, foto de evidencia con las regiones marcadas, mensaje por MQTT a Home Assistant y, opcionalmente, un comando de pausa a la impresora.
Todo eso ocurre en la placa. Home Assistant aparece únicamente como el camino hacia la notificación push al celular; no procesa nada.
El detalle de las "tres de cuatro" no es decoración: es un filtro temporal para que un valor atípico aislado. una mano que aparece en el cuadro, un reflejo momentáneo. no dispare una alarma. Más adelante vas a ver dónde ese filtro falla.
El enfoque de IA: aprender la normalidad en vez de coleccionar fallas
El camino obvio sería entrenar un modelo con miles de fotos de impresiones fallidas. Fracasa antes de empezar, por un motivo puramente práctico: nadie va a arruinar decenas de impresiones a propósito, menos aún en una impresora prestada o en una que está produciendo.
Por eso el sistema usa detección de anomalías con FOMO AD, el modelo de anomalías visuales de Edge Impulse. Aprende exclusivamente cómo se ve una impresión normal, y reporta todo lo que se aparte.
La ventaja económica es enorme: las imágenes de entrenamiento se generan solas en cada impresión exitosa. Imágenes de falla necesitas apenas un puñado, y no para entrenar sino para fijar el umbral de alarma.
Ahora, el principio tiene una contracara que marcó todo el proyecto y que conviene grabarse: FOMO AD no aprende "spaghetti", aprende "así se ve esto normalmente aquí". La posición de la cámara, el encuadre, el foco y la iluminación son parte del modelo. Cada soporte que se corre y cada lámpara nueva en la sala devalúa el dataset completo junto con el modelo entrenado.
Para quien lo va a replicar, eso se traduce en una regla dura: primero fijas el hardware, después recolectas.
El hardware: tres compras y dos piezas impresas
La lista es corta:
| Componente | Función | Precio referencial |
|---|---|---|
| Arduino UNO Q, kit de 4 GB con fuente USB-C | Inferencia de IA (Linux) + matriz LED (microcontrolador) | ~88 € |
| UNO Media Carrier (ASX00083) | Conectores CSI de cámara para el UNO Q | ~19 € |
| Cámara IMX219 en formato V2 | Vista de la cama de impresión | 17 a 30 € |
| Filamento PLA, tornillos y tuercas | Carcasa y soporte | < 5 € |
En pesos chilenos el conjunto queda del orden de CLP $130.000 a $150.000 aproximados, según el tipo de cambio y los aranceles de importación del momento. Es una cifra aproximada y conviene verificarla al comprar.
Dos advertencias de compatibilidad que ahorran una devolución:
- El carrier acepta solo sensores IMX219. Un Camera Module 3 no funciona.
- Una webcam USB conectada al hub USB-C cumple el mismo propósito y suele conseguirse mucho más fácil.
La carcasa del UNO Q y el soporte de cámara salen de la propia impresora. La primera versión fue una abrazadera al borde del gabinete: rápida de montar, y demasiado fácil de desajustar en el uso diario.
La segunda versión es un brazo rígido apretado a la columna Z, diseñado de forma paramétrica en FreeCAD, que sostiene la placa arriba y la cámara abajo en una articulación. Todos los archivos de impresión están en el repositorio.
Recolectar y entrenar: el primer modelo
Antes de que la cámara entregara una sola imagen hubo que resolver un rodeo: la imagen estándar del UNO Q no activa el subsistema de cámara del chip Qualcomm. En imágenes actuales existe un interruptor en la configuración de App Lab (Carriers → Camera0 → "type1-2lanes"); en imágenes antiguas hay que agregar una entrada de arranque con el device tree correspondiente.
La cámara entrega 632 × 480 píxeles, que es todo lo que permite la memoria reservada. Da lo mismo: el modelo trabaja con 96 × 96, y más adelante con 160 × 160.
Un script de GStreamer guardaba una imagen cada diez segundos durante cada impresión. Después de una semana de trabajos normales había unas 2.600 imágenes normales, más 20 imágenes reales de stringing salidas de una falla no planificada. La subida se hizo directo desde la placa con curl contra la API de ingestión de Edge Impulse, sin software adicional. El entrenamiento tomó cinco minutos.
Primera trampa: un F1 de 0,23 que no era malo
El primer resultado de prueba parecía una pérdida total: F1-score de 0,23.
Los datos crudos decían lo contrario. Las 20 imágenes de falla fueron detectadas todas. Las normales tenían mediana 26 y el 99 % estaba bajo 33. Las de falla partían en 44. El único problema era que el umbral por defecto, 27,3, caía justo en la mitad de la distribución normal.
Moviendo el umbral a 40, el F1 subió a 1,00.
Y de yapa, el modelo encontró un hilo cruzado sobre la cama que los propios autores habían pasado por alto al etiquetar. La imagen "normal" con score 62,8 no era una falsa alarma: era un error humano de etiquetado que el modelo detectó.
En la placa, el modelo cuantizado ocupa 41 milisegundos por imagen y el archivo pesa 3,9 MB. Con una imagen cada 15 segundos, el vigilante usa alrededor de 0,3 % del tiempo de cómputo disponible. El procesador está desocupado prácticamente todo el tiempo.
La aplicación: dos bricks y una página de estado
La aplicación se arma con dos bricks de App Lab:
visual_anomaly_detectionejecuta el modelo propio.web_uientrega una página de estado en el puerto 7000, con semáforo, score, imagen en vivo, última foto de alarma y todos los ajustes.
Vía MQTT Discovery el vigilante se registra solo en Home Assistant con cuatro entidades. alarma, score, estado y la foto de alarma como entidad de cámara. sin escribir una línea de configuración.
Un buffer rotativo guarda las últimas 2.500 imágenes sin novedad para un reentrenamiento posterior. Guarda ese dato: más adelante se convierte en el problema más interesante de todo el proyecto.
El primer día real: tres lecciones y cinco atrapadas
Lección uno: la inferencia tiene que pasar por el mismo pipeline de imagen que el entrenamiento. Un balance de blancos distinto. el canal azul salió al doble que en las imágenes de entrenamiento. hizo que cada imagen apareciera como anomalía. No es un ajuste fino: es la diferencia entre funcionar y no funcionar.
Lección dos: la partida necesita un bloqueo de calentamiento. El homing y la línea de purga producen imágenes que no estaban en el entrenamiento, así que los primeros 60 segundos hay que ignorarlos.
Lección tres: unos pocos grados de desvío de la cámara suben los scores normales de forma permanente, de menos de 33 a 45 a 50. No es deriva del modelo: es que le cambiaste el mundo.
En medio de eso, filamento húmedo produjo cinco fallas reales en una sola mañana. El vigilante avisó cada una: score sobre 50, alarma en Home Assistant, matriz LED roja y foto de evidencia.
La segunda ronda, y los números honestos
Al cambiar al soporte rígido, la normalidad anterior quedó sin valor: el primer modelo evaluaba la escena nueva, en una impresión perfectamente normal, entre 48 y 61.
Así que de nuevo desde cero: unas 2.300 imágenes en tres días, distintos colores de filamento, luz natural y artificial, recolectadas por el propio vigilante en modo observador. El impulse nuevo trabaja a 160 × 160 y el entrenamiento tomó 35 minutos. Sobre la placa, el modelo nuevo respondió a la misma impresión con 29 a 38.
La página de deployment entregó un hallazgo típico de Edge AI y contraintuitivo para cualquiera que venga de optimizar modelos: la versión cuantizada int8 necesita 119 milisegundos por imagen en el UNO Q, y la float32 sin cuantizar solo 67. La ventaja de velocidad de int8 aparece únicamente cuando hay hardware especializado para aritmética entera. Sin él, de la ecuación queda solo el trabajo extra de conversión.
Cuando las distribuciones se solapan
Al calibrar el umbral esta vez las distribuciones se cruzaron. De las 471 imágenes normales del set de prueba, el 95 % quedó bajo 39,1; las 17 imágenes de falla. en su mayoría ovillos puestos a propósito más dos despegues reales. cayeron entre 40,4 y 60,2. Ya no existe un valor que atrape todas las fallas sin tocar ninguna normal:
| Umbral | Falsas alarmas (de 471 normales) | Fallas perdidas (de 17) |
|---|---|---|
| 40 | 19 (4,0 %) | 0 |
| 45 | 8 (1,7 %) | 5 |
| 50 | 3 (0,6 %) | 8 |
| 65 | 0 | 17 |
Las imágenes normales mal puntuadas no eran fallas escondidas: eran piezas terminadas claras al borde del cuadro, reflejos en la cama y luz ambiente clara. Estados normales que aparecían poco en el dataset.
Con umbral 40, la primera alarma llegó a los cuatro minutos sobre una impresión normal, y las regiones marcadas cayeron sobre la zona vacía y clara de la cama. El filtro temporal no ayudó, porque la zona clara no genera un valor atípico aislado: es una propiedad sostenida de la escena. Tres aciertos seguidos dejan de ser azar.
Detrás de eso hay un error de razonamiento que afecta a todo sistema que se autoentrena: el buffer guarda solo imágenes bajo el umbral, para que ningún spaghetti se cuele como "normal". Pero justamente las escenas claras que el modelo no conoce están sobre el umbral, así que nunca se recolectan. El vigilante cementa su propio punto ciego.
Por eso el umbral volvió a 100, el sistema sigue recolectando. ahora también las fases claras. y la pausa automática queda desactivada hasta que un reentrenamiento entregue un umbral que aguante. La alternativa de subir a 50 habría dejado pasar ocho de 17 fallas.
Seis lecciones sobre Edge AI que sirven fuera de este proyecto
Este es el material que hace que valga la pena leer el proyecto completo aunque nunca imprimas nada:
- El cómputo nunca fue el cuello de botella. Con una imagen cada 15 segundos el procesador está desocupado casi todo el tiempo. El cuello de botella siempre fue la imagen: resolución baja, sensor NoIR sin filtro infrarrojo con contraste plano y un pipeline que hubo que corregir a mano.
- Los pipelines de entrenamiento e inferencia deben ser idénticos. Misma resolución, misma rotación, mismo balance de blancos, idealmente el mismo código. Un canal azul distinto bastó para volver anomalía cada imagen.
- Un modelo de anomalías es la escena. Cámara, luz y ángulo son parte del modelo. Por eso un modelo entrenado no se puede regalar: cada réplica entrena el suyo.
- Las métricas de la plataforma dependen del umbral. F1 de 0,23 y de 0,10 no eran juicios sobre el modelo, sino sobre una configuración por defecto. El umbral sale de las distribuciones de scores, no del dashboard.
- La variedad no es gratis. Más estados normales en el entrenamiento bajan las falsas alarmas, pero también ensanchan lo que pasa por normal y vuelven al modelo menos sensible a fallas débiles.
- Los sistemas que se autocuran tienen un punto ciego estructural. Quien filtra sus datos de entrenamiento según su propio criterio excluye exactamente los casos que necesitaría para mejorar. Toda rutina de reentrenamiento necesita una fase de recolección sin filtro.
Y la séptima, corta: cuantizar necesita hardware acorde. Sin acelerador de enteros, int8 es más lento que float32, no más rápido.
Variantes y mejoras
Tres extensiones que no están en el proyecto original:
1. Vigilar varias impresoras con un solo cerebro. Para el taller del ejemplo, una placa por impresora es caro. Una alternativa realista es un Raspberry Pi 5 con dos o tres cámaras USB y una instancia del modelo por cámara, corriendo secuencialmente. Con un ciclo de 15 segundos por impresora hay tiempo de sobra. Ojo: cada cámara necesita su propio modelo, porque cada una ve una escena distinta. El costo por máquina baja, el trabajo de entrenamiento se multiplica.
2. Contabilidad de material perdido. Cada alarma confirmada es un rollo parcialmente perdido. Si registras la altura de capa al momento de la alarma. Moonraker la entrega en la misma consulta de estado. puedes calcular gramos y minutos perdidos por falla, y en un mes tienes el número que justifica la inversión ante quien firma los cheques.
3. Enganche con un bot de Telegram en vez de Home Assistant. Home Assistant es potente pero es una instalación completa que hay que mantener. Si lo único que quieres es la notificación con foto, un bot de Telegram desde la misma aplicación reduce el sistema a una sola pieza. Pierdes la integración con el resto de la domótica, ganas simplicidad.
Personalización para Chile
En MechatronicStore encuentras la parte del montaje que se consigue con stock local. Los equivalentes a buscar en el catálogo:
- Filamento PLA 1,75 mm. para la carcasa y el soporte de cámara. Menos de 100 gramos alcanza.
- Cable USB-C. alimentación de la placa.
- Fuente 5 V switching o cargador USB-C de 3 A, si prefieres no depender de la fuente original del kit.
- Tornillos y tuercas M3 y M5. la ferretería del soporte.
- Raspberry Pi 5. si tomas la variante multiimpresora de la sección anterior, esta es la base más disponible en Chile.
Sobre las piezas centrales, prefiero ser derecho contigo: el Arduino UNO Q, el UNO Media Carrier y la cámara IMX219 son de importación reciente y su disponibilidad local es intermitente. No tiene sentido ofrecerte un reemplazo que no cumpla la misma función. Si no los encuentras, la ruta realista para replicar esto en Chile es Raspberry Pi 4 o 5 con cámara CSI, que Edge Impulse también soporta como destino oficial y que sí se consigue acá sin problema. Lo que pierdes respecto al UNO Q es la matriz LED integrada como luz de alarma y el microcontrolador para extensiones como un botón de emergencia físico.
Equivalencias respecto al artículo original:
- Donde el original dice "IMX219 en formato V2", cualquier cámara CSI con ese sensor sirve; el Camera Module 3 no.
- Donde dice "webcam USB al hub USB-C", cualquier webcam UVC estándar cumple, y en Chile es la opción más barata y más disponible.
- El PLA está bien para el soporte, pero si el brazo va a cargar peso por meses el PETG resiste mejor la deformación lenta.
Recursos
- Tutorial original: Edge KI in der Praxis: Ein Arduino UNO Q erkennt Fehldrucke am 3D-Drucker, ohne Cloud
- Repositorio GitHub (código de la app, scripts de cámara, script de subida a Edge Impulse, archivos STL y FreeCAD): arduino uno-q-projects
- Serie completa: Parte 1. idea, carcasa y soporte · Parte 2. cámara y recolección de imágenes · Parte 3. entrenar el modelo con Edge Impulse · Parte 4. la app con App Lab · Parte 5. optimización y cierre
Nota de transparencia del autor original: el Arduino UNO Q fue facilitado por Arduino como equipo de prueba y la impresora Elegoo Neptune 4 Plus es un préstamo de Elegoo; según el autor, eso no influyó en el contenido ni en la evaluación.
Versión chilena inspirada en el trabajo de Philipp Schweizer en raspberry.tips, reescrita con componentes en stock local en MechatronicStore.
