Défi technique ETSIIT : d'étudiants à entrepreneurs avec Locaviewer

Cet article a été rédigé par les gagnants du TechChallenge : Israel Blancas Álvarez, Ignacio Cara Martín, Nicolás Guerrero García et Benito Palacios Sánchez.

Il y a un an, nous nous sommes lancés dans le IVe Défi Technique ETSIIT (vidéo). Qui sommes-nous ? Nous sommes quatre étudiants en Génie Électrique et Informatique à l'Université de Grenade, en Espagne.

Notre équipe, Prometheus, a remporté la victoire au Tech Challenge sponsorisé par RTI. Des équipes de quatre ou cinq étudiants devaient créer un produit répondant à un problème réel posé par un partenaire externe. Le thème de cette année était « Système vidéo distribué multi-agents ».

Nous avons relevé le défi pour acquérir de l'expérience pratique. Un an plus tard, tout en continuant nos études, nous avons identifié une opportunité commerciale, conçu le produit concurrentiel Locaviewer, élaboré une stratégie de marché et construit un prototype fonctionnel — le tout en plus de nos obligations académiques.

Locaviewer

De nombreux parents s'inquiètent de la santé et des progrès de leurs enfants à la crèche. Locaviewer offre aux parents une visibilité en temps réel sur leur enfant. Nous avons produit une vidéo promotionnelle pour présenter la solution, et notre code source est disponible sous licence MIT sur GitHub.

Organisation et planning de l'équipe

Le projet a demandé environ 250 heures. Nous nous réunissions chaque semaine pendant au minimum quatre heures, montant à 20 heures par semaine pendant le dernier mois. Pour maximiser l'efficacité, nous nous sommes divisés en deux sous-équipes : l'une focalisée sur l'algorithme de localisation intérieure Bluetooth, l'autre sur la capture vidéo, l'encodage/décodage et la distribution via RTI Connext DDS.

Algorithme de localisation

La pierre angulaire de notre solution était la localisation de chaque enfant dans la crèche. Chaque enfant portait un bracelet avec un capteur Bluetooth rapportant en continu l'indication de puissance de signal reçue (RSSI) vers des dongles fixes montés sur les murs de la salle. Nous avons corrélé les valeurs RSSI à la distance, établissant une relation fiable.

Les lectures RSSI étaient transmises à un mini-ordinateur (Raspberry Pi ou MK802 III) exécutant un algorithme de triangulation pour localiser chaque enfant. Connaissant les positions des caméras, nous pouvions sélectionner la caméra optimale pour chaque enfant.

Application d'enregistrement vidéo

Nous avons utilisé GStreamer pour Java pour gérer la capture vidéo temps-réel, l'encodage, le décodage et l'affichage. Des alternatives comme vlcj manquaient de support pour Raspberry Pi ou ne répondaient pas à nos exigences de latence. Après de nombreuses recherches, GStreamer s'est avéré adapté, nous permettant d'accéder aux tampons vidéo encodés via les éléments AppSink et AppSource et de les publier sur un sujet DDS.

Nous avons choisi l'encodeur VP8 (WebM). En raison de la compatibilité du wrapper Java avec GStreamer 0.10, nous avons dû réduire la résolution pour tenir dans les contraintes de la plateforme. Notre configuration de test utilisait un Raspberry Pi, avec une migration prévue vers un MK802 III pour plus de puissance de calcul à coût équivalent.

Le fragment Java suivant crée l'encodeur 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"));

Côté client, nous avons configuré le pipeline comme suit :

Le code Java pour le décodeur 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);

Nous avons expérimenté l'encodage JPEG, mais sa taille de paquet plus importante rendait le streaming temps-réel impraticable.

Architecture DDS

Le modèle publication-souscription était central dans notre solution, éliminant le besoin de gérer manuellement les connexions socket. Nous avons abstrait les interactions DDS via notre propre bibliothèque wrapper, DDStheus.

Notre système final comprenait six programmes partageant trois sujets, implémentés en trois langages :

1. Python pour la gestion Bluetooth bas niveau.
2. MATLAB/Octave pour les scripts de triangulation.
3. Java pour l'intégration RTI Connext DDS et le développement d'IHM.

Nous avions besoin de toutes les valeurs RSSI de la salle, donc nous avons écrit un script pour configurer les dongles et collecter les données RSSI. Ces valeurs étaient transmises à un programme Java via un socket local. L'application Java publiait les données sur le sujet Sensor Data, incluant l'ID enfant (MAC du capteur), l'ID dongle, la position, la salle actuelle (comme clé de filtrage), la valeur RSSI et le temps d'expiration.

Après capture et encodage vidéo, le programme Java Gava transmettait le flux via le sujet Video Data, étiquetant chaque paquet avec l'ID caméra et les informations de salle. Nous avons exploité ContentFilteredTopic pour filtrer les flux par position de caméra et salle.

Les métadonnées caméra — ID, salle et position — étaient stockées dans le champ QoS USER_DATA de chaque éditeur. Le mini-ordinateur de triangulation pouvait découvrir toutes les caméras dans une salle, détecter en temps réel les caméras nouvelles ou hors ligne, et ajuster l'algorithme de sélection de caméra en conséquence.

L'étape finale consistait à agréger les données capteurs et vidéo dans le sujet Child Data. Un serveur de salle — implémenté sur Raspberry Pi ou MK802 III — triangulait la position de l'enfant et sélectionnait la meilleure caméra. Il filtrait les capteurs par salle, récupérait les infos caméra, exécutait le script Octave pour calculer la position de l'enfant et la caméra optimale, et publiait le résultat vers le cloud. L'ID enfant et la qualité vidéo servaient de clés de filtrage pour une souscription efficace.

Pour optimiser l'utilisation des ressources, le serveur de salle n'exécutait le script de triangulation que lorsqu'un abonné demandait des données pour un enfant spécifique, déterminé via la découverte d'abonnés et les filtres ContentFilteredTopic.

Nous avons aussi implémenté un mécanisme de tolérance aux pannes : chaque mini-ordinateur publiait un ID de priorité dans USER_DATA. Le nœud avec l'ID le plus bas devenait le serveur actif jusqu'à l'arrivée d'un nouveau nœud avec un ID encore plus bas.

Applications utilisateur

Nous avons développé deux applications utilisateur final. La première permet aux parents de voir leur enfant en temps réel. La seconde est destinée au personnel de crèche pour surveiller toutes les caméras, gérer les accès parents et automatiser le contrôle de présence.

[1] [2]  >

Concevoir des systèmes de fabrication adaptatifs pour l'Industrie 4.0 : tirer parti de l'IIoT et de RTI Connext 2014 : une année charnière pour RTI dans l'innovation Industrial IoT