Fusion multi-capteurs pour table tactile

Enseignants: Didier Donsez

Client: DIGITALE

Eleves RICM5: Maxence Raoux (Responsable Communication), Léopold Dauvergne

=Presentation=

L'objectif de ce projet est de mettre en place des méthodes permettant à la table tactile de Digitale d’interagir avec son environnement extérieur sans action physique des utilisateurs.

Pour arriver à remplir l'objectif, il faut recourir à l'utilisation de capteurs disposés autour de la table. L'application doit être évolutive, une architecture modulaire sera à mettre en place.

La durée du projet est de 6 semaines et la charge de travail est variable et modulée selon les autres cours, séminaires et projets qui prennent aussi place durant cette période.

La représentation de la solution développée respecte l’implémentation souhaité par Digitale, voir schéma ci-dessous, tiré du cahier des charges :



=Projet=

Pour arriver à remplir l'objectif, il faut recourir à l'utilisation de capteurs disposés autour de la table. L'application doit être évolutive, une architecture modulaire sera à mettre en place.

Choix et contraintes matérielles
Dans un premier temps nous avons étudié les différents types de capteurs et les interactions requises pour activer ceux-ci. Nous avons ainsi exclu les options suivantes :

- Kinect : Requiert d’avoir plusieurs kinects disposées autour de la table (et non sur celle-ci), budget assez conséquent et non pratique lors du transport de la table.

- NFC : Bien que pratique ce dernier nécessite que l’utilisateur ai un badge et se loggue sur la table. Cette solution pourrait être adoptée à terme pour permettre d’apporter à l’utilisateur un contenu vraiment personnalisé.

- Caméras : Cette solution, semblable à la Kinect, pose les mêmes soucis que pour la Kinect, il n’est pas facilement envisageable d’installer des caméras dans la pièce et embarquer des caméras dans la table serait complexe notamment au niveau du recul nécessaire.

Notre choix s’est donc porté sur des capteurs permettant d’être embarqués de manière « simple » au sein de la table. Le détail des différents types de capteurs est disponible dans la partie suivante.

Capteurs
Durant la première partie du projet nous avons étudié les différents types de capteurs qui pourraient correspondre au besoin de l’entreprise : Capteurs de contact : Ce premier type de capteur est intéressant car il permet une détection nette de la personne si celle-ci est en contact physique avec la table. Néanmoins nous n’avons pas choisi cette solution car il nous parait important pour la table de détecter les personnes arrivant sur cette dernière.

Capteurs infrarouge : Il s’agit du premier type de capteur que nous avons expérimenté. Ceux-ci sont très directifs et offrent une bonne précision (de l’ordre du millimètre) sur un distance assez grande (allant jusqu’à 1-2mètres). Nous avons eu durant notre projet un capteur infrarouge qui nous donnait des résultats satisfaisants, pour un prix faible (~5€) voici ses caractéristiques :



Ses caractéristiques sont :

- Power Supply :5V DC

- Quiescent Current : <2mA

- Effectual Angle: <15°

- Ranging Distance : 2cm – 500 cm/1" - 16ft

- Resolution : 0.3 cm

La datasheet est disponible ici.

Les capteurs seront idéalement placé sous l'écran de la table, le long des bordures, comme dans l'illustration ci dessous:



Software
Pour la partie software, nous avons utilisé le langage C# et avons développés plusieurs modules orientés autour d'un bus à messages dont voici un schéma:



Concernant le bus à messages, nous utilisons un produit développé par le CENA nommé Ivy. Le site internet du projet est disponible ici. Pour rendre l'utilisation de la bibliothèque Ivy plus agréable à utiliser, et l'adapter au projet, nous avons créer une bibliothèque qui est utilisée dans chaque module. Elle permet par exemple de faire une connexion automatique sur le port et adresse réseau de l'application, mais surtout d'améliorer la réception et envoi de messages sur le bus Ivy. En effet cette bibliothèque gère les messages sous forme d'objets et non de comme de simple chaînes de caractères. De plus cela rend l'application plus maintenable puisque toute la gestion des messages est écrire dans une unique bibliothèque.

Le module d'écoute des capteurs permet de récupérer l'information générée par les Arduinos connectés aux différents ports COM et d'envoyer ces informations "brutes" sur le bus Ivy. Pour récupérer les informations provenant des capteurs, nous avons modifié ce programme destiné à la plateforme Arduino. Ce module possède une interface graphique de configuration pour sélectionner les ports COM sur lesquels sont connectés les Arduinos. Actuellement un seul est sélectionnable dans l'interface et un seul thread d’écoute est lancé. Mais l'évolution du programme vers plusieurs se résume à une ligne de code si nécessaire.

Le module de traitement permet de récupérer les informations des capteurs envoyés sur le bus et de les traiter. Dans le cadre de notre projet il ne reçoit et traite seulement les messages envoyés par les capteurs ultra-sons. Une évolution vers différent type de capteurs se résumerai donc à l'abonnement sur le bus Ivy d'autre type de messages et à leurs traitements. Le traitement des informations consistes à générer des messages de plus haut niveau et ainsi abstraire les informations qui proviennes des capteurs, cela permet donc de proposer plusieurs services qui sont chacun basés sur un ou plusieurs types de capteurs. Ces informations sont ensuite à nouveau transférées sur le bus Ivy. Pour notre projet deux messages sont générés. Présence et position. Présence signale l'arrivé et le départ d'une personne, et position donne la position de la personne autour de la table ainsi que sa distance par rapport à elle.

L'application client est dans notre cas une application de démonstration technologique qui affiche des fenêtres suivant le mouvement des utilisateurs autour de la table. Elle est basée sur le sdk Microsoft Surface.

=Marketing=

Video
Une vidéo de démonstration disponible ici.

Flyer
Disponible ici.

Transparents
Disponibles ici.

=Suivi=

Semaine 5

 * Définition des objectifs du projet
 * Mise en place du dépôts
 * Création d'un projet vide contenant une application Microsoft Surface vide : SonarTable.
 * Mise en place de réunion hebdomadaire pour avoir un bon suivis du projet.

Semaine 6

 * Connexion à l'arduino via le port COM.
 * Création du projet SerialPortListener pour écouter l'Arduino.
 * Apprentissage de la bibliothèque Ivy et création de la bibliothèque IvyCom.
 * Compilation de la bibliothèque ivy pour qu'elle soit disponible sur l'architecture x64 demandé par les applications Surface.
 * Création d'évenements c# pour créer le dialogue entre la bibliothèque IvyCom et les projets qui l'utilise.
 * Création d'une interface pour paramétrer SerialPortListener

Semaine 7

 * Conversion du projet SerialPortListener en x64
 * Création de la bibliothèque MiddleWare pour traiter les message reçut de l'Arduino et envoyer un évènement c# à l'application SonarTable.
 * Création des classes Personnes et Personne pour traiter les différentes personnes présente autour de la table.
 * Création de nombreuse fonction dans les classe Personnes et Personne. Tel que :
 * Ajouter / Supprimer capteurs
 * Recherche personne par id
 * Recherche personne par capteur
 * Ajout / Suppression de personnes ...
 * Création d'un buffer pour sauvegarder par personnes les messages voulus.
 * Début d'algorithme de décision dans MiddleWare pour la conversion de message type Arduino de SerialPortListener par des messages utilisables par l'application SonarTable.
 * Affichage de fenêtres dans l'application SonarTable affichant les données des messages reçuts.

Semaine 8
MiddleWare ne communiquera plus comme une bibliothèque avec SonarTable mais via le bus ivy.
 * Grosse amélioration de l'algorithme de décision
 * Nombreuse correction de bug
 * Placement des fenêtres sur la l'application SonarTable selon la valeurs des messages.
 * Réflexion sur un changement de structure :

Semaine 9

 * Mise en place de la nouvelle structure.
 * Changement de la gestion des fenêtres sur SonarTable dû aux changements de la structure (plus simple)
 * Mise en place de variable de configurations pour l'algorithme de décision :
 * nbAbsenceAcceptee : Nombre de messages d’absences acceptés. Cette variable est dû à des erreurs de distance parfois envoyée par les capteurs.
 * distanceDifferenceAcceptee : Correspond à la distance envoyée entre deux capteurs qui permet de différencier une personne d'une autre.
 * reglageInterval : Nombre de capteurs à proximité nécessaire pour considérer le déplacement d'une fenêtre.

Semaine 10

 * Amélioration de la connexion via le bus ivy
 * Amélioration de la position des fenêtres sur SonarTable.
 * Orientation des fenêtres sur SonarTable.
 * Optimisation de l'algorithme
 * Correction de bugs.
 * Début de rapport

Semaine 11

 * Création d'une nouvelle application qui affiche les valeurs reçut par l'Arduino.
 * Ecriture du rapport.