View source for 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 :


[[Image:Screenshot_from_2013-03-21_15-44-27.png|500px|thumb|center]]

=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 :


[[Image:547132375_615.jpg|400px|thumb|center|E18-D50NK]]


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

Capteurs à ultrasons : Il s’agit du type de capteur préféré lors de nos premières réunions avec Digitale, notamment car Mr Donsez avait commandé un certain nombre de capteurs lors du début du projet. Ces capteurs ont l’avantage d’être peu cher (~3-5€), d’avoir une bonne portée et d’être relativement précis. Voici les spécifications du modèle de capteur à ultrasons choisi : 


[[Image:HC-SR04-lg.jpg|400px|thumb|center|HC-SR04]]

La datasheet est disponible [http://jaktek.com/wp-content/uploads/2011/12/HC-SR04.pdf ici].

- Alimentation : 5V
- Consommation : < 12mA
- Distance : 2-500cm avec un angle de 15 dégrés

Ce module dispose simplement de 4 pins de sortie : VCC, TRIG, ECHO, GND. Il est donc très facile de l'interfacer à un microcontrôleur. Le processus complet est le suivant: 

Mettre la pin "TRIG" une impulsion de niveau haut (5V) durant au moins 10µs et le module démarre sa lecture; A la fin de la mesure, s'il détecte un objet devant lui, la pin "ECHO" passe au niveau haut (5V). 
La distance où se situe l'obstacle est proportionnelle à la durée de cette impulsion. Il est donc très facile de calculer cette distance avec la formule suivante:

Distance = ((Durée du niveau haut)*(vitesse du son: 340 m/s))/2.

Notre prototype fonctionne avec ce dernier type de capteur, son implémentation est décrite dans la partie suivante.

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

[[Image:SchemaTablesSensors.jpg|500px|thumb|center|Les capteurs sont représentés par les triangles noirs.]]

==Solution adoptée==

Nous avons choisi d’utiliser en priorité des capteurs à ultrasons car ces derniers étaient les seuls à être disponible suffisamment rapidement en plus de posséder les caractéristiques techniques qui correspondaient à notre besoin. Pour le prototype, nous avons construit une barre en bois sur laquelle les capteurs sont fixés. Nous avons choisi de « serrer » les capteurs pour gagner en précision, ils sont donc espacés d’environ 3 cm. Voici une photo du montage : 

[[Image:DSC00731-Small.jpg|400px|thumb|center|HC-SR04]]

Pour la connectique, un Arduino peut gérer jusqu’à 18 capteurs à condition d’unifier la pin servant de trigger. D’un point de vue software, notre programme gère jusqu’à 15 capteurs, ceci permet de garder une assez bonne réactivité car les capteurs sont « interrogés » un à un. Pour accélérer encore plus ce processus, nous avons limité la distance de détection à 100 cm.

La librairie utilisée est disponible [http://code.google.com/p/arduino-new-ping/wiki/15_Sensors_Example ici].

Le code sur lequel nous nous sommes basé est disponible [http://code.google.com/p/arduino-new-ping/wiki/15_Sensors_Example ici]

==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:

[[Image:SchemaBUSSONARTABLE.jpg|600px|thumb|center|HC-SR04]]

Concernant le bus à messages, nous utilisons un produit développé par le CENA  nommé [[Ivy]]. Le site internet du projet est disponible [http://www.tls.cena.fr/products/[[Ivy]]/ 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é [http://code.google.com/p/arduino-new-ping/wiki/15_Sensors_Example 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.

Git et source : https://bitbucket.org/ldauvergne/table-interact-2013

==Architecture==

*Architecture découpée en deux modules
** SerialPortListener
*** Ecoute l’Arduino (et les capteurs) et renvois des informations brutes.
*** Possède une interface de configuration (port com vers Arduino + Baud)
*** Envois des messages type : STArduino = <Capteur>;<Distance>
** BundlePP
*** Traite les données envoyées par SerialPortListener pour générer des informations de position et de présence. 
*** Possède une interface de configuration (nombres de capteurs en longueur et largeur + résolution de la table)
*** Envois des messages type : Presence = <Capteur>;<Presence> et Position = <Capteur>;<x>;<y>;<distance>
*** Ces messages sont envoyé par un algorithme de décision qui prend en compte les 3 paramètre cités au chapitre précédent. nbAbsenceAcceptee / distanceDifferenceAcceptee / reglageInterval
*Echange via un bus de données [[Ivy]]. Création d’une bibliothèque de fonction [[Ivy]]com
*Deux applications exemples : 
** SonarVizualizer : Affichage minimaliste des données envoyé depuis le module SerialPortListner
** SonarTable : Affichage des données reçus depuis BundlePP avec des feneêtre

=Marketing=

== Video ==

Une vidéo de démonstration disponible [http://www.youtube.com/watch?v=8VKd9UdPNmc ici].

== Poster ==

[[Image:PosterSonarTable.jpg|600px|thumb|center| Resolution originale : 1024*768]]

== Flyer ==

Disponible [http://air.imag.fr/mediawiki/images/0/07/FliyerSonarTable.pdf ici].

== Transparents ==

Disponibles [http://air.imag.fr/mediawiki/images/b/be/Sonar_TablePresentation.pdf ici].

= Optimisations à apporter =

Une fois le prototype monté nous nous sommes rendu compte que les capteurs n’étaient pas très fiables et avaient tendance à ne pas détecter une personne alors que celle-ci était bien présente. Pour essayer de remédier à ce problème nous avons resserré les capteurs mais le problème à tendance à persister. Nous avons donc mis en place des solutions d’optimisation logicielle mais permettre de réduire le problème mais ne le résout pas totalement.

= Suggestions =

D’un point de vue hardware, nous vous conseillons de faire des tests avec d’autres types de capteurs, dont des capteurs infrarouges. Un mélange des deux est aussi envisageable est permettrait de s’affranchir des problèmes inhérents à un type de capteur.

=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 [[Ivy]]Com.
* 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 [[Ivy]]Com 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==
* 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 : 
MiddleWare ne communiquera plus comme une bibliothèque avec SonarTable mais via le bus [[Ivy]].

==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.