Reto Técnico ETSIIT: De estudiantes a emprendedores con Locaviewer

Este artículo fue escrito por los ganadores del TechChallenge: Israel Blancas Álvarez, Ignacio Cara Martín, Nicolás Guerrero García y Benito Palacios Sánchez.

Hace un año, nos embarcamos en el IV Reto Técnico ETSIIT (vídeo). ¿Quiénes somos? Somos cuatro estudiantes de Ingeniería Eléctrica y Ciencias de la Computación en la Universidad de Granada, España.

Nuestro equipo, Prometheus, ganó el Tech Challenge patrocinado por RTI. Equipos de cuatro o cinco estudiantes debían crear un producto que abordara un problema real planteado por un socio externo. El tema de este año fue "Sistema Distribuido de Video Multi-Agente".

Participamos para ganar experiencia práctica. Un año después, mientras seguimos estudiando, identificamos una oportunidad comercial, diseñamos el producto competitivo Locaviewer, ideamos una estrategia de mercado y construimos un prototipo funcional —todo ello además de cumplir nuestros requisitos académicos.

Locaviewer

Muchos padres se preocupan por la salud y el progreso de sus hijos en guarderías. Locaviewer brinda a los padres visibilidad en tiempo real de su hijo. Produjimos un vídeo promocional para mostrar la solución, y nuestro código fuente está disponible bajo licencia MIT en GitHub.

Organización y cronograma del equipo

El proyecto demandó aproximadamente 250 horas. Nos reuníamos semanalmente un mínimo de cuatro horas, escalando a 20 horas semanales en el mes final. Para maximizar eficiencia, nos dividimos en dos sub-equipos: uno centrado en el algoritmo de localización Bluetooth en interiores, el otro en captura, codificación/decodificación y distribución de video vía RTI Connext DDS.

Algoritmo de localización

La piedra angular de nuestra solución fue localizar a cada niño dentro de la guardería. Cada niño llevaba una pulsera con sensor Bluetooth que reportaba continuamente la Indicación de Intensidad de Señal Recibida (RSSI) a dongles fijos en las paredes. Mapeamos valores RSSI a distancia, estableciendo una relación fiable.

Las lecturas RSSI se transmitían a un mini-ordenador (Raspberry Pi o MK802 III) que ejecutaba un algoritmo de triangulación para ubicar a cada niño. Conociendo las posiciones de las cámaras, podíamos seleccionar la cámara óptima para cada niño.

Aplicación de grabación de video

Empleamos GStreamer para Java para manejar captura, codificación, decodificación y visualización de video en tiempo real. Alternativas como vlcj no soportaban Raspberry Pi o no cumplían nuestros requisitos de latencia. Tras amplia investigación, GStreamer resultó adecuado, permitiéndonos acceder a buffers de video codificados mediante elementos AppSink y AppSource y publicarlos en un tema DDS.

Seleccionamos el codificador VP8 (WebM). Debido a la compatibilidad del wrapper Java con GStreamer 0.10, tuvimos que reducir la resolución para ajustarnos a las limitaciones de la plataforma. Nuestra configuración de prueba usó Raspberry Pi, con planes de migrar a MK802 III para mayor potencia de procesamiento manteniendo paridad de coste.

El siguiente fragmento Java crea el codificador VP8:

Element codec = ElementFactory.make("vp8enc", null); codec.set("threads", 5); codec.set("max-keyframe-distance", 20); codec.set("speed", 5); Element capsDst = ElementFactory.make("capsfilter", null); capsDst.setCaps(Caps.fromString("video/x-vp8 profile=(string)2"));

En el lado del cliente, configuramos el pipeline así:

El código Java para el decodificador VP8:

String caps = "video/x-vp8, width=(int)320, height=(int)240, framerate=15/1"; Element capsSrc = ElementFactory.make("capsfilter", null); capsSrc.setCaps(Caps.fromString(caps)); Element queue = ElementFactory.make("queue2", null); Element codec = ElementFactory.make("vp8dec", null); Element convert = ElementFactory.make("ffmpegcolorspace", null);

Experimentamos con codificación JPEG, pero su mayor tamaño de paquete hacía la transmisión en tiempo real impráctica.

Arquitectura DDS

El modelo publicar-suscribir fue central en nuestra solución, eliminando la necesidad de gestionar conexiones de socket manualmente. Abstraímos las interacciones DDS mediante nuestra propia biblioteca wrapper, DDStheus.

Nuestro sistema final comprendía seis programas compartiendo tres temas, implementados en tres lenguajes:

1. Python para manejo Bluetooth de bajo nivel.
2. MATLAB/Octave para scripts de triangulación.
3. Java para integración RTI Connext DDS y desarrollo GUI.

Requeríamos todos los valores RSSI de la sala, así que escribimos un script para configurar los dongles y recopilar datos RSSI. Estos valores se reenviaban a un programa Java vía socket local. La aplicación Java publicaba los datos en el tema Sensor Data, incluyendo ID de niño (MAC del sensor), ID de dongle, posición, sala actual (como clave para filtrado), valor RSSI y tiempo de expiración.

Tras captura y codificación de video, el programa Java Gava transmitía el flujo vía tema Video Data, etiquetando cada paquete con ID de cámara e información de sala. Aprovechamos ContentFilteredTopic para filtrar flujos por posición de cámara y sala.

Metadatos de cámara —ID, sala y posición— se almacenaban en el campo QoS USER_DATA de cada publicador. El mini-ordenador de triangulación podía descubrir todas las cámaras en una sala, detectar cámaras nuevas o fuera de línea en tiempo real y ajustar el algoritmo de selección de cámara en consecuencia.

El paso final consistió en agregar datos de sensores y video en el tema Child Data. Un servidor de sala —implementado en Raspberry Pi o MK802 III— triangulaba la ubicación del niño y seleccionaba la mejor cámara. Filtrada sensores por sala, obtenía info de cámaras, ejecutaba script Octave para calcular posición del niño y cámara óptima, y publicaba el resultado en la nube. ID de niño y calidad de video se usaban como claves de filtro para suscripción eficiente.

Para optimizar uso de recursos, el servidor de sala solo ejecutaba el script de triangulación cuando un suscriptor solicitaba datos para un niño específico, determinado vía detección de suscriptores y filtros ContentFiltere

[1] [2]  >