Défi technique ETSIIT | Des étudiants aux entrepreneurs

Dans la dernière étape, nous avons traité les données et écrit le résultat en tant que Données enfants sujet. Cela a été fait par le serveur de salle (implémenté avec Raspberry Pi ou MK802 III) qui a triangulé l'emplacement de l'enfant et sélectionné la caméra appropriée. Il a filtré uniquement les capteurs de la pièce actuelle et a rassemblé toutes les informations sur les éditeurs de vidéos dans cette pièce. Les données ont été envoyées à un script Octave, qui a renvoyé l'emplacement de l'enfant et le meilleur identifiant de caméra. Les informations envoyées au cloud avec le sujet Données enfants , y compris l'identification de l'enfant, la qualité vidéo, l'identification de la caméra, l'emplacement de l'enfant et l'identification de la pièce. Pour plus d'efficacité, l'ID enfant et la qualité sont envoyés sous forme de clés qui peuvent être filtrées ou utilisées pour trier la vidéo.

Pour optimiser l'application, le serveur de la salle n'appelait le script de triangulation que s'il y avait un abonné demandant l'enfant. Nous l'avons déterminé en utilisant la découverte d'abonnés et en examinant le ContentFilteredTopic paramètres de filtre.

Enfin, nous avons mis en place un mécanisme de redondance pour gérer la panne du serveur de salle. Chaque mini-ordinateur de la salle a créé un éditeur et a défini sa valeur USER_DATA sur la salle et un ID de priorité (unique) par défaut. Si l'un des mini-ordinateurs détectait qu'il avait l'ID le plus bas dans sa pièce, il démarrait l'application serveur et agissait en tant que serveur jusqu'à ce qu'un nouveau mini-ordinateur avec un ID inférieur apparaisse.

Applications utilisateur

Nous avons développé deux applications pour utilisateurs finaux. Le premier sera utilisé par les parents pour voir leurs enfants à l'école maternelle. Le deuxième programme sera utilisé par les employés de la crèche pour voir toutes les caméras en temps réel, gérer l'accès des parents (ajouter et supprimer) et gérer automatiquement le contrôle des présences.

Réflexions finales

Nous avons dû faire face à deux gros problèmes dans le challenge :

1. Obtenir les valeurs RSSI :nous avons acheté un appareil Bluetooth de très mauvaise qualité et à faible coût (environ 5 $). Le signal avait beaucoup d'erreurs et de bruit. Nous avons dû développer un algorithme pour optimiser les valeurs, réduisant cette erreur de 3 à 0,5 mètre. Nous n'avons trouvé aucune bibliothèque pour les opérations de bas niveau avec les périphériques Bluetooth en Java (nous avons finalement utilisé pybluez). Nous avons dû communiquer en utilisant des programmes Python et Java.
2. Encodage vidéo :il n'a pas été facile de trouver une bibliothèque nous permettant d'obtenir le tampon vidéo encodé. Il était encore plus difficile d'optimiser les éléments du pipeline GStreamer 0.10 pour qu'ils fonctionnent au maximum de leurs performances dans le Raspberry Pi. Avec la configuration finale, le délai d'image est d'environ 3 à 5 secondes. Pour de meilleures performances, nous prévoyons de remplacer le Raspberry Pi par un appareil MK802 III au prix similaire, qui comprend le Wi-Fi et un processeur Cortex A9 double cœur.

RTI Connext DDS nous a permis d'économiser beaucoup de travail en mettant en œuvre des mécanismes de mise en réseau, de sérialisation des données et de qualité de service. Nous remercions notre école d'ingénieurs et RTI de nous avoir donné l'opportunité et les ressources nécessaires pour relever avec succès ce défi commercial.

En savoir plus :

Production de véhicules autonomes »

Connectivité dans les systèmes autonomes »

Qu'est-ce que l'IIoT ? »

Qu'est-ce que DDS ? »