Tu celular como cámara IA del Arduino UNO Q: detección de objetos sin hardware extra

Al terminar este tutorial vas a tener un Arduino UNO Q reconociendo objetos en tiempo real, usando como cámara el celular que ya tienes en el bolsillo. Sin comprar un módulo, sin soldar nada, sin un cable cruzando el escritorio y sin que una sola imagen salga de tu red local.

La gracia del UNO Q es que trae dos cerebros: un microcontrolador STM32 en tiempo real y un SoC Qualcomm QRB2210 corriendo un Debian Linux completo. La detección de objetos se calcula en el lado Linux, y la app Arduino IoT Remote convierte tu teléfono en la fuente de video por WiFi.

Qué vas a saber hacer al final:

• Levantar el ejemplo de detección de objetos de App Lab sin escribir una línea de código.
• Parear el celular con la placa por QR y entender qué viaja por cada canal.
• Comprobar con tus propios ojos si el modelo corre en CPU, GPU o NPU (spoiler: no es lo que promete el marketing).
• Diagnosticar los tres fallos que se llevan el 90% de los intentos.
• Integrar ese mismo stream de cámara en una app Python propia.

Qué necesitas

Y una condición que no aparece en la lista de materiales pero es la que más falla: la placa y el celular tienen que estar en la misma red WiFi. Si tu teléfono se cambió a datos móviles sin avisarte, nada de esto funciona.

Cómo el celular se convierte en cámara

Antes de apretar botones conviene entender el mecanismo, porque después ahorra media hora de diagnóstico a ciegas. El pareo ocurre en tres etapas, y cada una usa un canal distinto:

1. Código QR. Al arrancar la app, el UNO Q genera una clave numérica de seis dígitos de un solo uso y la empaqueta junto con su IP y su puerto dentro de un QR que muestra la interfaz web.
2. Handshake. Escaneas el código con la cámara del teléfono, se abre la app IoT Remote y se registra contra la placa por una conexión WebSocket cifrada. Por ese canal viajan solo órdenes de control, nunca video.
3. Stream de video. Recién ahí el celular empieza a mandar los cuadros de la cámara por HTTP al puerto 4912 de la placa. De ahí entran al modelo de IA y vuelven dibujados a la interfaz web.

Esa separación explica dos cosas que después vas a agradecer: que el pareo pueda funcionar y el video no (típico de un firewall que bloquea el 4912 pero deja pasar el WebSocket), y que bajar la resolución alivie el WiFi sin tocar el pareo.

Un punto importante para quien lee "IoT" y piensa en la nube: el video no pasa por Arduino Cloud. Va directo del teléfono a la placa por tu red local, y Arduino lo confirma en su documentación oficial. Internet solo se usa para el login de la app en el celular.

Puesta en marcha en App Lab

Arduino trae el ejemplo listo, así que no hay que programar nada.

1. Abre App Lab, conecta el UNO Q y busca smartphone en la sección Inspirations.
2. Elige el ejemplo Detect Objects on Smartphone Camera. Los ejemplos integrados vienen con protección de escritura: duplícalo con Copy and edit app antes de tocarlo.
3. Aprieta Run arriba a la derecha. La primera vez demora bastante más, porque se descarga el modelo de IA.
4. La interfaz web se abre sola en el navegador. Si no lo hace, ábrela a mano en http://<nombre-de-la-placa>.local:7000 — por ejemplo http://unoq.local:7000.

En pantalla aparece un QR grande y, debajo, el mismo código en seis dígitos. Son lo mismo: el QR es la vía cómoda, pero puedes tipear el número a mano.

Ahora instala Arduino IoT Remote en el teléfono, inicia sesión con tu cuenta Arduino y elige un camino:

Camino A. escanear el QR. Abre la app de cámara normal del celular y apúntala a la pantalla. La app IoT Remote se abre sola y se conecta. Mantén el teléfono firme a unos 10-15 cm; si el monitor está oscuro, sube el brillo.

Camino B. a mano. En la app entra a Devices, toca el símbolo +, elige Stream phone camera to UNO Q, selecciona tu placa de la lista (solo aparece si está en la misma red) y escribe el código de seis dígitos.

Apenas se establece la conexión, la interfaz web cambia del QR a la imagen en vivo de tu cámara. El código queda quemado: sirve para una sola conexión y caduca a los cinco minutos. Si necesitas otro, recarga la página.

Que empiece a reconocer cosas

Apunta la cámara a lo que tengas alrededor. En la interfaz aparece un recuadro sobre cada objeto detectado, con su nombre y la probabilidad de acierto. por ejemplo "95% potted plant". Abajo se van listando las últimas cinco detecciones con su hora.

El modelo que viene incluido está entrenado con objetos cotidianos. La app de ejemplo reacciona con una animación a seis de ellos, así que vale la pena buscarlos a propósito: gato (cat), perro (dog), celular (cell phone), reloj (clock), taza (cup) y planta en macetero (potted plant).

El deslizador de la interfaz ajusta el umbral de confianza, es decir, desde qué probabilidad se reporta una detección. Si lo bajas, el modelo detecta más cosas… y también más tonterías. Para los primeros intentos el valor por defecto está bien.

Vale la pena entender qué hace ese control, porque es el que más se malinterpreta: el umbral no cambia la precisión del modelo, solo mueve la línea de corte entre lo que se muestra y lo que se descarta. Un umbral alto te da pocas detecciones muy seguras (muchos falsos negativos); uno bajo te llena la pantalla de cajas dudosas (muchos falsos positivos). Para vigilancia conviene bajarlo y filtrar después por cantidad de cuadros consecutivos; para un contador conviene subirlo.

¿Dónde corre realmente el modelo?

Qualcomm y Arduino promocionan bastante la "aceleración de IA" del chip. Así que la pregunta interesante es: ¿la detección corre en una NPU, en la GPU, o en la CPU de siempre? La forma de saberlo es dejar htop corriendo mientras el modelo trabaja.

La respuesta es clara: el modelo incluido se llama YOLO-X-nano (reconoce las 80 clases habituales del dataset COCO) y corre sobre TensorFlow Lite en la CPU. En htop, el proceso yolo-x-nano.eim se mantiene en torno al 70% de un núcleo. De NPU o GPU, ni rastro. Aun así rinde unos 10 cuadros por segundo, suficiente para que los recuadros sigan a los objetos sin retraso molesto.

¿Y la GPU y la NPU existen? Sí, pero no se usan solas:

• El chip trae una GPU Adreno, conectada en la placa a través del driver abierto Mesa. Edge Impulse permite exportar modelos apuntando específicamente a "Arduino UNO Q (GPU)": solo así el cálculo se va a la GPU. Los modelos de ejemplo no lo hacen.
• La NPU Hexagon, que es la que más se promociona, ni siquiera está conectada en la imagen actual del sistema.

Para probar, da lo mismo. Pero si más adelante necesitas un modelo propio más rápido, ya sabes de dónde sale la aceleración: hay que pedirla explícitamente al exportar.

De dónde sale el retraso que ves en pantalla

Vale la pena desarmar esos 10 cuadros por segundo, porque el número final no lo pone solo el modelo. Entre que apuntas el teléfono y que aparece el recuadro en el navegador hay cuatro etapas que suman:

1. Captura y compresión en el celular. El teléfono codifica cada cuadro antes de mandarlo. Casi siempre es la etapa más rápida.
2. Transmisión por WiFi. Acá está la varianza. Un cuadro de 480×640 comprimido pesa del orden de decenas de kilobytes; en una red congestionada o con el router lejos, esta etapa sola puede duplicar la latencia total.
3. Inferencia del modelo. El proceso yolo-x-nano.eim a ~70% de un núcleo: es la etapa constante y la que fija el techo de cuadros por segundo.
4. Vuelta a la interfaz web. El resultado dibujado se manda de vuelta al navegador.

Lo importante de esta separación es cómo se diagnostica: si la imagen se ve entrecortada pero el recuadro sigue bien al objeto, el problema es la red (etapa 2) y la solución es bajar la resolución o acercar el router. Si la imagen fluye pero el recuadro va atrasado respecto del objeto, el cuello es el modelo (etapa 3) y ahí bajar la resolución no ayuda: hay que exportar a GPU o usar un modelo más liviano. Son dos síntomas parecidos con causas opuestas, y confundirlos hace perder mucho tiempo.

Cuando algo falla

Un detalle que vale para muchas casas en Chile: varios routers de las operadoras publican la banda de 2.4 GHz y la de 5 GHz como dos redes con nombre distinto. Si el celular quedó en la de 5 GHz y la placa en la de 2.4 GHz, técnicamente están en la misma red y el pareo debería funcionar… salvo que el router tenga activo el aislamiento de clientes (AP isolation), que bloquea el tráfico entre dispositivos y también el descubrimiento mDNS que necesita el .local. Si el nombre unoq.local no resuelve, usa la IP directa: en el terminal de la placa escribe hostname -I y toma la primera dirección.

Meter la cámara del celular en tu propia app

El ejemplo está bien, pero la gracia real aparece cuando llevas ese stream a una aplicación tuya. Del lado Python la pieza clave es la clase WebSocketCamera, que levanta el extremo asegurado al que se conecta el teléfono:

import secrets
import string
from arduino.app_peripherals.camera import WebSocketCamera

def generate_secret() -> str:
    return ''.join(secrets.choice(string.digits) for _ in range(6))

secret = generate_secret()
resolution = (480, 640)  # Formato vertical, calza con el celular

camera = WebSocketCamera(
    resolution=resolution,
    secret=secret,
    encrypt=True,
)

El objeto camera resultante se le pasa después al brick que va a analizar las imágenes; en el ejemplo eso es VideoObjectDetection(camera, ...). Los datos de conexión (IP, puerto y el secreto) se los mandas a tu interfaz web, que con eso arma el QR.

El stream de cámara no está casado con la detección de objetos: según la documentación de Arduino puedes alimentar con él otros bricks de visión, como video_classifier para clasificación de imágenes o face_detection para detección de rostros.

Variantes y mejoras

Tres extensiones concretas para cuando el ejemplo ya te funcione:

1. Contador de aforo con línea virtual. Como cada detección trae su caja delimitadora, puedes calcular el centro de cada caja de clase person y contar cuántas cruzan una línea horizontal imaginaria entre un cuadro y el siguiente. Con eso tienes un contador de entradas y salidas sin agregar un solo sensor: es todo aritmética sobre las coordenadas que ya te entrega el brick.

2. Alerta física con el segundo cerebro. El UNO Q trae un microcontrolador STM32 en tiempo real además del lado Linux. Cuando la detección de una clase determinada supera tu umbral durante N cuadros seguidos, manda esa orden al lado microcontrolador y haz que active un relé o una sirena. La ventaja de repartirlo así es que la reacción física no depende de que Linux esté ocupado calculando.

3. Modelo propio con Edge Impulse, exportado a GPU. El brick trae una pestaña AI models con el botón Train new AI model, y tu cuenta Arduino sirve también en Edge Impulse. Al terminar te queda un archivo .eim dentro de tu app. Aquí está lo importante: si lo exportas como "Arduino UNO Q (GPU)", el cálculo se va a la Adreno en vez de comerse la CPU. Ojo con una limitación documentada: la guía oficial de entrenamiento de modelos propios asume una cámara USB, y Arduino no documenta si un .eim propio funciona sobre el stream del celular.

Personalización para Chile

Todo lo esencial de este proyecto se consigue en MechatronicStore, con stock local y sin esperar importación:

• Arduino UNO Q QRB2210 compatible con Linux Debian (SKU C-222). $91.990 CLP
• Cable USB Tipo C a USB Tipo A 1mt (SKU B-101). $2.190 CLP

Total del montaje base: $94.180 CLP aproximado. Como referencia, el tutorial original habla de unos 60 euros por la placa (~$62.000 CLP), pero ese precio no incluye envío internacional, IVA de importación ni el tiempo de espera.

Para el modo de cámara fija (la alternativa cuando quieres dejar el sistema funcionando días, no minutos):

• Módulo cámara IMX219 M12/CS Raspberry pi / NVIDIA Jetson (SKU GS2-6). $34.990 CLP

Ese módulo es exactamente el sensor que acepta el UNO Media Carrier: el conector MIPI CSI del carrier oficial solo admite sensores IMX219, así que si tienes una Raspberry Pi Camera v2 guardada, sirve; los módulos más nuevos de Pi no calzan.

Equivalencias y advertencias honestas:

• El tutorial original recomienda una webcam USB tipo Logitech C270 para operación permanente. MechatronicStore no vende webcams USB UVC, así que ese ítem queda sin equivalente local. igual lo dejamos en la lista de materiales para que veas el BOM real. Cualquier webcam UVC de una tienda de computación sirve.
• La webcam USB además exige el dock USB-C oficial de Arduino o un hub USB con alimentación propia, que tampoco está en el catálogo. Por eso, si tu objetivo es dejar esto funcionando fijo, el camino del módulo IMX219 + UNO Media Carrier sale más limpio que el de la webcam.
• El smartphone no lo compras: es el que ya tienes. Ese es justamente el punto del tutorial.

Preguntas frecuentes

¿El video pasa por Arduino Cloud? No. La imagen va directo del celular al UNO Q, exclusivamente por tu red local, y Arduino lo confirma en su documentación. Por internet solo viaja el inicio de sesión de la app IoT Remote, para el que necesitas una cuenta Arduino gratuita.

¿Necesito hardware adicional para hacer visión artificial en el UNO Q? Para empezar, no. Un Arduino UNO Q, un smartphone con iOS o Android y una red WiFi compartida son suficientes. Una webcam USB o un módulo IMX219 sobre el UNO Media Carrier recién hacen falta cuando quieres la cámara fija en una posición permanente.

¿Qué objetos reconoce el modelo incluido? Objetos cotidianos: el modelo YOLO-X-nano está entrenado con las 80 clases del dataset COCO. La app de ejemplo reacciona con una animación a seis de ellas: gato, perro, celular, reloj, taza y planta en macetero. Para cualquier cosa fuera de esas 80 clases. una impresión 3D fallida, una pieza específica de tu taller. hay que entrenar un modelo propio.

¿Puedo correr mi propio modelo sobre el stream del celular? Los modelos propios se entrenan con la integración de Edge Impulse dentro de App Lab y se eligen en el brick bajo "AI models". La guía oficial de Arduino asume una cámara USB para ese flujo, y no está documentado si la combinación de un .eim propio con el stream del celular funciona. Si vas a depender de eso, pruébalo antes de comprometerlo en un proyecto.

El stream no arranca, ¿por qué? En la enorme mayoría de los casos es una de tres cosas: el celular y la placa están en redes distintas (datos móviles o red de invitados), el puerto 4912 está bloqueado por un firewall, o el código de seis dígitos ya caducó. Ese código vale una sola vez y unos cinco minutos; recargando la página del navegador se genera uno nuevo.

¿Sirve el celular para operación permanente? Solo hasta cierto punto. La pantalla tiene que quedarse encendida, la app en primer plano, y el teléfono queda bloqueado mientras graba. Para prototipos y demostraciones es ideal; para vigilar algo durante muchas horas conviene cambiar a una cámara USB o MIPI montada de forma fija.

Recursos

• Tutorial original (alemán): Arduino UNO Q: Smartphone als Kamera für die KI Bilderkennung nutzen
• Repositorio GitHub con los ejemplos: arduino/app bricks examples
• Documentación oficial de la integración IoT Remote: docs.arduino.cc
• Edge Impulse (para entrenar tu propio modelo .eim): edgeimpulse.com

Contenido inspirado en el tutorial de Philipp Schweizer en raspberry.tips. Versión chilena con componentes en stock local en MechatronicStore.