La premisa del proyecto es doméstica y concreta: una piscina que pierde agua con el tiempo y una bomba que puede quemarse si el nivel baja demasiado. En vez de salir a mirar, el padre de la autora quería una respuesta inmediata sobre si tocaba abrir la manguera. En términos técnicos, quería un modelo de visión por computador mirando la piscina por él.
Ese es un caso ideal de despliegue en el borde. La cámara nunca se mueve, la pregunta es binaria y no hay razón para transmitir video a la nube todo el día para responderla.
¿Qué hardware hace falta?
- Una Raspberry Pi: la autora usó una Pi 5, aunque sirve cualquier modelo reciente con algunos GB de RAM. No se requiere GPU.
- Un celular con una aplicación de cámara RTSP, que pasa a funcionar como cámara inalámbrica. También sirve una cámara de seguridad RTSP económica.
- Un computador en la misma red Wi-Fi, para la conexión SSH y para abrir el panel.
- Una cuenta gratuita de Roboflow, para etiquetar, entrenar y armar el flujo de trabajo.
La lista deja el costo de entrada muy abajo: la propia autora describe el resultado como un problema real resuelto con "una cámara, un computador de cuarenta dólares y un modelo entrenado en una tarde". Como el celular hace de cámara, no hay que comprar hardware de captura, y una Pi 4 guardada en un cajón cumple igual.
Paso 1: preparar la Raspberry Pi
Tras conectar la placa a la red y confirmar el acceso por SSH, se instala Docker:
curl -fsSL https://get.docker.com | shDocker es lo que ejecuta el servidor de inferencia de Roboflow de forma local, para que cada cuadro se procese en el dispositivo en lugar de viajar a la nube.
Acá apareció el primer problema real del proyecto. El contenedor gestionado de Roboflow Edge intentaba cargar dependencias de GPU y TensorRT, y la Raspberry Pi no tiene GPU. Al ser un dispositivo solo de CPU, el contenedor entraba en un ciclo de caída y reinicio permanente.
La solución fue cambiar al contenedor de Roboflow Inference exclusivo para CPU:
sudo docker run -it --rm -p 9001:9001 roboflow/roboflow-inference-server-cpuSigue siendo Roboflow de punta a punta, solo que por una ruta de despliegue más liviana, acorde a lo que la placa puede hacer.
Paso 2: convertir un celular en cámara inalámbrica
Para evitar tender un cable hasta una webcam, la autora instaló una aplicación de cámara RTSP en su teléfono. La aplicación convierte el celular en un flujo de video en vivo con una dirección del tipo rtsp://192.168.1.42:8554/stream, que la Raspberry Pi puede leer por Wi-Fi igual que leería una cámara de seguridad montada en la pared.
Paso 3: recolectar y etiquetar los datos
La recolección consistió en fotografiar la piscina en estado de nivel bajo primero, y luego seguir disparando mientras la manguera la llenaba, para capturar también el estado correcto. Con algunas decenas de imágenes por clase alcanza para partir, y siempre se puede sumar más y reentrenar.
Hay una decisión de diseño que conviene subrayar: se usó clasificación de imágenes y no detección de objetos. El modelo no necesitaba dibujar un recuadro sobre la línea de agua ni medir nada con precisión, sino mirar la escena y emitir un único veredicto, si el nivel está bajo o correcto.
| Criterio | Clasificación | Detección de objetos |
|---|---|---|
| Pregunta que responde | Estado global de la escena | Ubicación y cantidad de objetos |
| Caso de este proyecto | Nivel bajo o correcto | No aplica |
| Modelo sugerido | DINOv3 Small | RF-DETR |
| Etiquetado requerido | Imagen completa por clase | Recuadro por objeto |
Cuando la pregunta apunta al estado general de una escena y no a la posición de un objeto, la clasificación es la opción más simple y más adecuada. Si el proyecto sí necesita ubicar o contar cosas, como paquetes en la entrada o pájaros en un comedero, corresponde entrenar un modelo de detección y el resto del armado no cambia.
Paso 4: entrenar el modelo
La autora entrenó un modelo de clasificación DINOv3 Small en Roboflow. Se trata de un problema de reconocimiento de estados visuales, no de medición precisa, y DINOv3 rinde bien aprendiendo estados a partir de una cantidad modesta de ejemplos. La versión Small mantiene la inferencia rápida sobre la CPU de una Raspberry Pi.
Paso 5: armar el flujo de trabajo
Con el modelo entrenado, el flujo de trabajo toma un cuadro de la cámara del celular, ejecuta el modelo de clasificación y evalúa el resultado. Si la piscina está bien, muestra la transmisión. Si el agua está baja, superpone una advertencia grande sobre la imagen que dice que hay que abrir la manguera. La sutileza no era el objetivo, según relata la autora, porque su padre quería una respuesta legible desde el otro lado de la habitación.
Paso 6: publicar un panel
El sistema termina envuelto en una pequeña aplicación web con Flask, de modo que la Raspberry Pi sirve un panel en vivo que cualquiera en la casa puede abrir en un navegador. El resultado final es un celular haciendo de cámara inalámbrica, una Raspberry Pi ejecutando toda la inferencia de forma local y un modelo de clasificación indicando exactamente cuándo abrir la llave.
Sin transmisión de video a la nube, sin hardware costoso y sin tener que mirar la línea de agua desde el porche. Hay un video completo del proyecto disponible.
Qué viene después
Lo que más llama la atención de la autora es cuán poca experiencia profunda exigió el proyecto. El problema más difícil que enfrentó fue una incompatibilidad de contenedor, y la corrección consistió en cambiar de imagen.
La lista de pendientes para una segunda versión incluye una cámara montada de forma permanente, para recuperar el celular, un panel más prolijo y el objetivo evidente de que el sistema abra la manguera por su cuenta cuando el nivel baje.
