Un detector de fallas con inteligencia artificial no aprende qué es una impresión mala. Aprende cómo se ve tu impresora cuando todo va bien. Esa diferencia, que suena a detalle académico, es la que decide si tu proyecto funciona por meses o se cae el día que alguien roza la cámara con el codo.
En esta guía vas a ver el ciclo completo de puesta a punto de un vigilante de impresión 3D basado en un Arduino UNO Q y un modelo de detección de anomalías de Edge Impulse: cómo construir un soporte rígido para que la escena no se mueva nunca más, por qué ese cambio de hardware obliga a botar todo el dataset anterior, cómo calibrar el umbral de alarma leyendo distribuciones en vez de creerle al F1-score de la plataforma, y por qué un sistema que filtra sus propios datos de entrenamiento se queda ciego a sus propios errores. Al final vas a saber tomar la decisión que casi nadie documenta: cuándo tu detector todavía no está listo para tocar la impresora.
Bloque 1. El concepto que hay que entender antes de tocar un tornillo
El modelo que usa este proyecto es FOMO AD (Visual Anomaly Detection) de Edge Impulse. Se entrena solo con imágenes de impresiones normales. No ve ni una foto de spaghetti durante el entrenamiento. Cuando después le muestras una imagen, devuelve un número. un score de anomalía. que dice cuán raro le parece lo que está viendo respecto a esa normalidad aprendida.
De ahí sale la regla que ordena todo lo demás: la escena es parte del modelo. El ángulo de la cámara, el recorte, el foco, la iluminación de la pieza y hasta el ruido del sensor entran al entrenamiento como si fueran parámetros. Mueve la cámara tres grados y no degradaste el modelo: lo invalidaste. Le estás mostrando un mundo que nunca vio.
Esto tiene una consecuencia práctica que cuesta días si la aprendes tarde:
Primero fijas el hardware. Después recolectas. Nunca al revés.
Quien recolecta primero y atornilla después, recolecta dos veces. Y las imágenes no se juntan a la velocidad que tú quieras: se juntan a la velocidad a la que tu impresora imprime.
Bloque 2. Hardware: por qué una abrazadera rápida no sirve
La primera versión del soporte era una abrazadera apretada al borde del gabinete de la impresora: nada perforado, nada pegado. Perfecta para probar el concepto, y ahí termina su mérito. En el uso diario aparecieron tres problemas que vale la pena que conozcas antes de imprimir la tuya:
- Quedaba justo donde uno pasa a cambiar filamento, así que se movía sola cada dos días.
- En piezas altas dejaba de apuntar al objeto, y subirla la habría dejado todavía más inestable.
- La placa quedaba colgando del cable, no sostenida.
El rediseño parte de tres requisitos concretos: un brazo rígido, en un lugar donde nadie mete la mano; la placa sostenida y no colgada; y una articulación que permita ajustar la cámara en horizontal y vertical.
A eso se suma un criterio de diseño para impresión 3D que se subestima seguido: dividir en piezas chicas y bien orientadas. Mientras más grande y retorcida es una pieza, más soporte necesita y más caro sale corregir una medida.
Tres piezas en vez de un bloque
El resultado es un kit de tres piezas impresas:
- El brazo se aprieta a la columna Z de la impresora y sostiene todo el conjunto.
- La bandeja recibe el Arduino UNO Q, con ranuras laterales para los cables.
- El adaptador de cámara permite girar e inclinar el módulo.
Todo se une con tornillos y tuercas comunes. Nada de roscas impresas, que se pasan al tercer apriete.
El diseño se hizo en FreeCAD de forma paramétrica: todas las medidas viven en una tabla y un cambio se propaga a todo el modelo. La curva de aprendizaje es más empinada que Tinkercad, pero te ahorra exactamente el trabajo manual que cuestan tres iteraciones.
Dos datos para reimprimirlo:
- Soporte de impresión lo necesita solo la bandeja, y únicamente en los dos pivotes que salen hacia arriba. El resto sale limpio.
- La bandeja original quedó justa. La placa entra, pero sin holgura. Si la vas a reimprimir, dale medio milímetro más al contorno interior.
Parámetros de impresión y orden de armado
Las tres piezas se imprimen en PLA con 0,2 mm de altura de capa y cuatro o cinco perímetros. El brazo carga peso: ahí rinden mucho más las paredes extra que subir el relleno.
El orden de armado importa:
- Desliza la mordaza del brazo sobre el perfil de la columna Z y asegúrala con los dos tornillos.
- Encaja la bandeja de costado sobre los dos pivotes, hasta que la lengüeta apoye bajo la viga.
- Pon el adaptador de cámara sobre la viga: tuerca desde abajo en el avellanado, tornillo desde arriba. Apriétalo solo con la mano por ahora.
- Cuelga la carcasa de la cámara en la horquilla con un tornillo M5 y su tuerca.
- Deja la placa en la bandeja y pasa el cable de cámara y el USB-C por las ranuras laterales.
Recién después de eso apuntas la cámara, y para eso la vista en vivo en el navegador vale oro: abres la imagen, corriges giro e inclinación, aprietas los dos tornillos y listo.
La lista de ferretería es corta: dos tornillos para madera (o dos insertos roscados M3), un tornillo M6 o de 1/4 de pulgada con tuerca, y un tornillo M5 con tuerca.
Bloque 3. El costo escondido: cambiar el soporte obliga a reentrenar
Acá viene la parte incómoda del rediseño, y es la lección más cara de todo el proyecto.
Con el soporte nuevo colgado, la imagen de la cámara cambió: otro montaje, otra perspectiva. Y para peor, al mismo tiempo el filamento pasó de blanco a negro y afuera se puso el sol. Para una persona, las dos imágenes son "la impresora". Para el modelo son dos mundos distintos.
Consecuencia: el dataset se arma de nuevo. Las imágenes anteriores no pueden quedarse, porque si el modelo aprende dos estados normales como si fueran uno, queda más difuso en ambos. Un detalle práctico que ayuda a limpiar: si tus imágenes llevan la fecha y hora en el nombre de archivo, la línea de corte entre "antes" y "después" del cambio queda evidente.
Cómo recolectar sin apagar el vigilante
Durante la fase de recolección el sistema sigue corriendo, pero como observador mudo: subes el umbral de alarma a 100 para que no dispare nunca, y activas la casilla que guarda imágenes de entrenamiento. El vigilante escribe solo en su buffer.
Ojo con esto: el buffer es rotativo. Si dejas pasar demasiadas horas sin descargar o subir esas imágenes, se sobreescriben y perdiste la cosecha.
La variedad sí se busca, la perspectiva no se toca
Hay algo que parece contradecir todo lo anterior y no lo hace. En la recolección conviene buscar variedad a propósito: distintos colores de filamento, distintas horas del día, luz natural y luz artificial.
La regla fina es esta:
- Lo que no debe cambiar es la perspectiva de la cámara.
- Lo que sí debe cambiar es todo lo que en operación normal varía igual.
El mecanismo es el mismo que hizo caro el cambio de soporte, pensado al revés. El modelo conoce exactamente la normalidad que vio. Si en el entrenamiento solo hubo filamento negro, una impresión gris le va a parecer rara, y en un detector de anomalías "raro" significa alarma por definición. Mientras más ancha sea la normalidad aprendida, menos falsas alarmas vas a comer después.
¿No se pueden generar las imágenes de falla con IA? Edge Impulse tiene una pestaña Synthetic data que genera imágenes con DALL·E o FLUX Pro, así que la pregunta es razonable. Para este caso no sirve, por dos razones. Primero, la detección de anomalías no necesita imágenes de falla para entrenar: aprende solo el estado normal. Las imágenes de falla se usan únicamente para fijar el umbral. Segundo, el score depende de tu escena concreta: tu ángulo, tu cama, tu luz, hasta el ruido de tu cámara. Un ovillo de spaghetti generado es, para el modelo, tan ajeno como una foto sacada con el soporte viejo. Calcularías un umbral perfecto, pero el equivocado. Lo que sirve es una falla real frente a la cámara real. Y si no aparece ninguna: pones un ovillo de filamento sobre la cama, sacas unas fotos y listo.
Bloque 4. Reentrenar: qué cambiar en el impulse y qué no
El proyecto nuevo necesita su propio impulse, es decir la cadena de preprocesamiento de imagen más el bloque de aprendizaje. La estructura es la misma de siempre, con un cambio deliberado.
Resolución: 160 × 160 en vez de 96 × 96
La cámara captura a 632 × 480 y en esa resolución quedan guardadas las imágenes del dataset. Los 96 × 96 nunca fueron una propiedad de las fotos: eran el tamaño al que el impulse las reducía. El razonamiento para subir a 160 × 160 es que un ovillo de spaghetti recién empezando es una estructura fina, y a 96 × 96 puede simplemente no quedar nada de ella.
El costo es más tiempo de cómputo por imagen, que con un ciclo de revisión de 15 segundos sobra de todas maneras.
Vale una advertencia honesta que el artículo original hace bien en dejar por escrito: no está medido que el salto haya valido la pena. Para probarlo haría falta un set de prueba con muchos hilos finos, y ese set no existe todavía. Es una decisión fundamentada, no una decisión demostrada.
Resize mode: por qué Squash y no Fit shortest axis
Este campo es el que más gente pasa por alto y el que más cuesta caro. Decide cómo se convierte una imagen rectangular en un cuadrado.
- Fit shortest axis escala el lado corto a 160 y recorta a izquierda y derecha cerca de un 12 % del ancho cada lado. Casi un cuarto del campo visual que el vigilante no vuelve a ver nunca.
- Squash achata la imagen a 160 × 160. Se deforma, pero no se pierde nada.
Como el recorte ya no cubre toda la cama, regalar otro cuarto no es opción: va en Squash. Para FOMO AD la deformación es inofensiva, porque el entrenamiento y la vigilancia posterior deforman exactamente igual: el modelo aprende la escena achatada y en operación ve esa misma escena achatada.
Si cambias este modo después, tienes que volver a correr Generate features. Las características calculadas antes ya no calzan.
Y la trampa clásica, porque pega fácil: el bloque que necesitas se llama "Visual Anomaly Detection (FOMO AD)" y solo aparece en el diálogo si haces clic en Show all blocks. El bloque "Anomaly Detection" que se ve sin ese clic es otra cosa completamente distinta: espera datos de sensores y responde a tus imágenes con un error de reshape.
Los números del entrenamiento
El dataset final quedó en unas 2.300 imágenes, recolectadas a lo largo de tres días, en varias impresiones, con distintos colores de filamento y desde luz de día hasta luz artificial de noche. Las sacó el propio vigilante mientras corría en modo observador.
Antes de entrenar va la división en entrenamiento y prueba, en Dashboard → Perform train/test split. Quedaron 1.838 imágenes para aprender y 473 para probar.
Que exista una mitad de prueba no es un detalle burocrático. Esa mitad necesita imágenes normales que el modelo no haya visto, porque solo con ellas puedes medir cuán seguido el detector dispara sin motivo. Sin ellas terminas conociendo la tasa de aciertos, pero no la de falsas alarmas, y recién las dos juntas te permiten elegir un umbral.
El entrenamiento tomó unos 35 minutos y 7.352 iteraciones. Es bastante más que con 96 × 96, y la razón son los 160 × 160: el modelo divide cada imagen en una grilla más fina. Ese costo se paga una sola vez, en la nube, no en la placa.
El resultado inesperado del deployment
En Deployment eliges el destino Arduino UNO Q y generas el archivo .eim. Ahí aparece un número que contradice la intuición de casi cualquiera que haya optimizado modelos antes.
Normalmente cuantizar. pasar el modelo de coma flotante de 32 bits a enteros de 8 bits. lo hace más chico y más rápido. En el UNO Q pasa exactamente lo contrario: 119 milisegundos la versión cuantizada contra 67 milisegundos la no cuantizada.
La explicación es de arquitectura, no de software: la ventaja de velocidad de int8 aparece solo cuando existe hardware especializado para aritmética entera. Si no lo hay, de la ecuación queda únicamente el trabajo extra de convertir de un formato a otro. Entonces se usa la versión sin cuantizar. Con un ciclo de 15 segundos la diferencia es irrelevante de todos modos.
Volver a la placa sin quemar las naves
Un consejo de operación: no borres el modelo viejo. El .eim nuevo va con su propio nombre en la misma carpeta, con su propio model.yaml, y en el app.yaml de la aplicación solo cambias el nombre del modelo. Si el modelo nuevo decepciona, volver atrás es editar una línea y no montar un rescate.
La primera contraprueba fue tranquilizadora. Sobre una impresión en curso, el modelo viejo entregaba valores entre 48 y 61 en la escena nueva: encontraba sospechoso su propio entorno. El modelo nuevo respondió a la misma impresión con 29 a 38, justo lo que había predicho la prueba en la nube. Eso confirma que el modelo no solo funciona en el estudio, sino que sobrevive completo al pipeline de cámara de la placa.
Bloque 5. Calibrar el umbral: por qué un 40 % de exactitud puede ser un buen modelo
Y entonces el estudio muestra este resultado: 40,16 % de exactitud, F1 de 0,10. Parece una pérdida total.
La matriz de confusión al lado cuenta otra historia: el 100 % de las imágenes de falla fue detectado, ni una sola se pasó. Por lo que el modelo está siendo castigado es por la otra columna: el 62 % de las imágenes normales también quedó marcado como falla.
Esto es clave y conviene decirlo sin rodeos: el número que muestra la plataforma corresponde a un umbral por defecto, y ese umbral está mal puesto para tu escena. No es un juicio sobre el modelo, es un juicio sobre una configuración que vas a elegir tú en el paso siguiente.
El trabajo de verdad es mirar qué valores reciben las imágenes normales y las fallidas.
Como imágenes de falla se usaron 17 fotos: en su mayoría escenas armadas. un ovillo de filamento puesto sobre la cama, en blanco, beige y oscuro, a veces grande, a veces chico, a veces al borde del cuadro. más dos capturas reales de una impresión que se despegó. Contra ellas, las 471 imágenes normales de la mitad de prueba.
| Medición | Valor |
|---|---|
| Normales. promedio | 28,9 |
| Normales. 95 % está bajo | 39,1 |
| Normales. 99 % está bajo | 47,1 |
| Normales. valor más alto | 63,5 |
| Fallas | 40,4 a 60,2 |
En la ronda anterior del proyecto, las normales quedaban casi todas bajo 33 y la falla más débil en 43,8: entre medio había un hueco donde el umbral se acomodaba solo. Esta vez los dos rangos se solapan. Ya no existe un valor que atrape todas las fallas sin tocar ninguna imagen normal:
| Umbral | Falsas alarmas | Fallas perdidas |
|---|---|---|
| 40 | 19 de 471 (4,0 %) | 0 de 17 |
| 45 | 8 de 471 (1,7 %) | 5 de 17 |
| 50 | 3 de 471 (0,6 %) | 8 de 17 |
| 65 | 0 | 17 de 17 |
De dónde sale el solapamiento
Antes de fijar un número conviene mirar qué imágenes normales se están puntuando tan alto. En la ronda anterior una supuesta falsa alarma resultó ser un hilo real que se había etiquetado mal: el modelo había encontrado un error humano.
Esta vez no. Al descargar las diez imágenes normales peor puntuadas, lo que aparece son piezas terminadas claras al borde del cuadro, reflejos en la cama y luz de ambiente inusualmente clara. Estados perfectamente normales, pero poco representados en un dataset dominado por cama oscura y filamento oscuro. Al modelo lo "claro" le resulta inusual, y en detección de anomalías inusual significa sospechoso.
Con eso el consejo anterior se devuelve como un búmeran. Sí, hay que meter colores y condiciones de luz variadas al dataset. Pero cada variante nueva también ensancha lo que pasa por normal, y una normalidad más ancha vuelve al modelo menos sensible a fallas débiles. La variedad no es gratis.
La decisión: 40
Umbral 40, la opción que atrapa las 17 fallas y acepta 4 % de falsas alarmas. El razonamiento de costos es simple: una falla no vista cuesta una noche de spaghetti y un rollo de filamento; una falsa alarma cuesta mirar el celular.
Además ese 4 % son imágenes sueltas, y el vigilante recién dispara cuando tres de cuatro revisiones consecutivas salen sospechosas. Un valor alto aislado, porque una pieza clara asomó al cuadro, no debería activar nada.
Debería. Sigue leyendo.
Bloque 6. Armar la alarma en serio y descubrir el punto ciego
Con el umbral en 40, el plan era dejar el vigilante armado unas cuantas impresiones y, si aguantaba, autorizarlo a pausar la impresora solo.
La primera alarma llegó a los cuatro minutos. Sobre una impresión perfectamente normal.
La imagen marcada muestra la causa de inmediato: las celdas rojas no están sobre la pieza, están repartidas sobre la zona vacía y clara de la cama. Exactamente lo que el análisis del set de prueba había anticipado. El vigilante se molesta con un brillo que no conoce.
El registro de la misma impresión normal termina de explicarlo:
28,7 — 34,0 — 37,4 — 41,3 — 41,5 — 41,6 — 43,1 — 47,8
El umbral de 40 no se cruza por poco: se cruza cada minuto. Y ahí se cae también el supuesto anterior sobre el filtro temporal. Tres de cuatro no protege de esto. Ese filtro está construido contra valores atípicos aislados. una imagen en la que aparece una mano, por ejemplo. . Acá la zona clara es una propiedad sostenida de la escena: se queda muchas imágenes seguidas. Tres aciertos en fila dejan de ser cuestión de azar y pasan a ser cuestión de tiempo.
El error de diseño que afecta a todo sistema que se autofiltra
Buscando la reparación aparece un problema más de fondo, y este vale para cualquier proyecto de este tipo, no solo para este.
El buffer de entrenamiento guarda únicamente imágenes bajo el umbral de alarma. La intención era razonable: que no se cuele una impresión rota al dataset, que solo debe contener estados normales.
Pero las escenas claras que el modelo no conoce, y que justamente causan las falsas alarmas, están sobre el umbral. O sea que nunca se recolectan. Y lo que nunca se recolecta nunca entra al entrenamiento, y lo que nunca entra al entrenamiento le queda ajeno al modelo para siempre.
El vigilante excluye exactamente las imágenes que necesitaría para mejorar. Mientras está armado, no puede mejorar: cementa su propio punto ciego.
Esto no es una particularidad de esta implementación. Todo sistema que filtra sus propios datos de entrenamiento según su propio criterio tiene este problema. Si estás construyendo cualquier cosa con reentrenamiento automático, anótalo.
La decisión: todavía no
Así que se vuelve al principio. Umbral de nuevo en 100, el vigilante observa y recolecta. esta vez también las fases claras. . Después de unas cuantas impresiones más, esas imágenes entran al proyecto, se reentrena, y recién de las distribuciones medidas ahí sale un umbral que aguante en operación. Solo después de eso se activa la pausa automática.
La alternativa fácil habría sido correr el umbral a 50. Las falsas alarmas desaparecerían casi por completo, pero ocho de diecisiete fallas también pasarían de largo. Un vigilante que no ve la mitad de las fallas, pero nunca molesta, es un adorno.
Bloque 7. Autoarranque: que el vigilante vuelva solo después de un corte de luz
Un detalle que en el día a día molesta más de lo que suena: después de reiniciar el UNO Q. corte de luz, actualización, alguien que desenchufó la fuente. el vigilante no volvía a levantar.
App Lab no recuerda el estado de una aplicación a través de un reinicio, y arduino-app-cli app simplemente no tiene un subcomando para eso: hay start, stop y restart, pero no existe enable. Para un equipo que va a estar meses sin supervisión al lado de la impresora, eso no alcanza.
La tentación es cambiar la política de reinicio de los contenedores Docker, ya que la aplicación corre en contenedores. Es la palanca equivocada: App Lab inicia y detiene esos contenedores por su cuenta y deja la política en no a propósito. Quien mete mano ahí pelea contra la capa de administración que está por encima.
El camino limpio es un servicio systemd:
[Unit]
Description=Spaghetti-Waechter nach dem Booten starten
Requires=arduino-app-cli.service
After=arduino-app-cli.service docker.service network-online.target
Wants=network-online.target
[Service]
Type=oneshot
RemainAfterExit=yes
User=arduino
Group=arduino
Environment=HOME=/home/arduino
ExecStart=/home/arduino/waechter_autostart.sh
TimeoutStartSec=300
[Install]
WantedBy=multi-user.target
El servicio se cuelga detrás de arduino-app-cli.service, o sea detrás del demonio de App Lab. Y ahí está la trampa en la que es fácil caer: que el demonio esté corriendo no significa que ya acepte comandos. Un ExecStart=arduino-app-cli app start directo llega demasiado temprano y se pierde sin dejar rastro. sin mensaje de error, el servicio reporta éxito y la aplicación igual no está corriendo. .
Por eso la unidad llama a un script de espera que pregunta hasta que el demonio conteste:
#!/bin/sh
# Startet den Spaghetti-Waechter nach dem Booten, sobald der App-Lab-Daemon bereit ist.
# Aufgerufen von /etc/systemd/system/spaghetti-waechter-autostart.service
CLI=/usr/bin/arduino-app-cli
APP=user:spaghetti-waechter
laeuft() {
$CLI app list 2>/dev/null | grep -q "^$APP .*running"
}
bekannt() {
$CLI app list 2>/dev/null | grep -q "^$APP"
}
i=0
while [ $i -lt 30 ]; do
if laeuft; then
echo "Waechter laeuft."
exit 0
fi
if bekannt; then
echo "Daemon bereit, starte App (Versuch $((i + 1)))."
$CLI app start "$APP" 2>&1
sleep 10
if laeuft; then
echo "Waechter gestartet."
exit 0
fi
else
echo "Daemon noch nicht bereit (Versuch $((i + 1)))."
fi
i=$((i + 1))
sleep 5
done
El patrón es el que conviene copiar aunque no uses App Lab: espera activa con reintentos acotados en vez de asumir que un servicio del que dependes está listo apenas systemd lo da por arrancado. El bucle prueba hasta 30 veces con pausas de 5 segundos y se rinde si el demonio nunca responde, en vez de quedarse colgado para siempre.
Bloque 8. Reproducir el proyecto
La aplicación completa está publicada como archivo zip en el repositorio. En App Lab haces clic en el signo más junto a Apps, arrastras el archivo al diálogo Import an App, presionas Run y eso es todo. La aplicación arranca con un modelo de reemplazo y empieza a juntar imágenes para el tuyo desde la primera impresión.
Lo que no se comparte es el modelo entrenado, y a esta altura ya sabes por qué: ese modelo conoce una sola escena, la del autor. En tu impresora marcaría todo como falla.
Variantes y mejoras
Tres extensiones concretas que no están en el proyecto original y que puedes armar sobre esta misma base:
1. Una versión de bajo costo con ESP32-CAM. El UNO Q corre Linux y el modelo completo, pero si tu objetivo es solo detectar el ovillo, un ESP32-CAM con un modelo FOMO clásico exportado desde Edge Impulse hace el trabajo por una fracción del precio. Pierdes la matriz LED integrada, el pipeline de cámara es más pobre y vas a tener que bajar la resolución de inferencia, pero el flujo conceptual. recolectar normalidad, entrenar, calibrar umbral con distribuciones. es idéntico. Si armas las dos, tienes además una comparación de costo y desempeño que casi nadie ha publicado con números reales.
2. Un botón físico de parada de emergencia en el microcontrolador. El UNO Q trae un microcontrolador STM32 además del procesador que corre Linux. Ese micro puede leer un pulsador y cortar la impresión por hardware sin depender de que el lado Linux esté sano. Es la diferencia entre un sistema de aviso y un sistema de seguridad.
3. Registro histórico de scores en una base de datos. En vez de mirar solo la alarma, guarda cada score con su marca de tiempo en InfluxDB o en un archivo CSV en una microSD. Con dos semanas de datos vas a poder calcular tu umbral de forma estadística en vez de a ojo, y vas a ver la deriva del modelo. el momento en que los scores normales empiezan a subir porque algo cambió en la escena. antes de que se traduzca en falsas alarmas.
Personalización para Chile
En MechatronicStore puedes conseguir la mayor parte de este montaje con componentes en stock local. Los equivalentes que buscar en el catálogo:
- Filamento PLA 1,75 mm. para las tres piezas del soporte. Con menos de 100 gramos alcanza para el juego completo.
- Cable USB-C. alimentación de la placa. Ojo con la corriente: este proyecto pide una fuente generosa, no un cargador de celular viejo.
- Fuente 5 V switching o cargador USB-C de al menos 3 A, si no vas a usar la fuente original del kit.
- Tornillos y tuercas M3 y M5. la ferretería del soporte. Un tornillo M6 o de 1/4" sirve para el eje de giro de la cámara.
Sobre los dos componentes centrales conviene ser franco: el Arduino UNO Q con su UNO Media Carrier y la cámara IMX219 son piezas de importación reciente y su disponibilidad en Chile es intermitente. En vez de recomendarte un reemplazo que no cumple la misma función, prefiero decirlo derecho: si no los encuentras, la variante con ESP32-CAM de la sección anterior es el camino realista para replicar el proyecto con lo que hay en el mercado local, y es más barata por bastante.
Equivalencias útiles si vienes del artículo original:
- Donde el original habla de un carrier con conector CSI, cualquier cámara CSI con sensor IMX219 en formato V2 sirve. El carrier no acepta el Camera Module 3.
- Una webcam USB conectada al hub USB-C cumple el mismo propósito y suele ser mucho más fácil de conseguir acá.
- El PLA funciona para el soporte, pero si tu impresora está en un lugar caluroso o el brazo va a cargar peso por meses, el PETG aguanta mejor la deformación por fluencia.
Recursos
- Tutorial original: KI Druckwächter mit dem Arduino UNO Q (Teil 5): Optimierung und Finalisierung
- Repositorio GitHub (archivos STL, modelo FreeCAD paramétrico, scripts y la app en zip): arduino uno-q-projects
- Archivos del soporte v2 directo: kamera halterung-v2
- Partes anteriores de la serie: Parte 1. idea y soporte · Parte 2. cámara y recolección · Parte 3. entrenar con Edge Impulse · Parte 4. la app en App Lab
Versión chilena inspirada en el trabajo de Philipp Schweizer en raspberry.tips, reescrita con componentes en stock local en MechatronicStore.
