air - User contributions [en]

PAGE WIKI ETUDIANTS 2011-12 SERRURE VOCALE

2012-03-12T13:59:09Z

Emilien: /* Montage électronique de la gâche */

=Présentation du projet=

Le but de ce projet est de développer un système de reconnaissance vocale. Le projet consiste à réaliser un programme permettant d'ouvrir une gâche électronique simplement par la parole. Les voix des locuteurs seront préalablement enregistrées, et devront être identifiées par un système de reconnaissance vocale afin de permettre ou non l'ouverture de la gâche électronique.
Pour réaliser ce projet, nous disposons d'un montage électronique de la gâche qui sera ouverte ou non selon l'acceptation ou le rejet du signal reçu en entrée.
Pour la démonstration du projet, nous réaliserons une interface graphique qui permettra l'enregistrement des voix ainsi que leur reconnaissance.
La partie IHM sera plus expliquée en détail grâce à des sketchs par la suite.

Nous étudierons aussi à la fin du projet les performances et la robustesse de notre système.

=Déroulement du travail=
===Etude de l'existant===

Ce projet a déjà été réalisé l'année précédente, pour cela,la première étape sera d'analyser le travail effectué par les élèves de l'année précédentes, afin de garder les parties fonctionnelles et les améliorer.
Ce projet est essentiellement composé de trois grandes parties:

#Montage électronique de la gâche
#Acquisition et Reconnaissance des données
#IHM de pilotage de la gâche

Pour la réalisation de la phase d’acquisition, les travaux se sont appuyés sur le TP Biométrie préparatoire à ce projet.

Les signaux de départ correspondent aux voix des membres du groupe enregistrées au format raw comme dans le TP. Les vecteurs paramètres de ces voix ont ensuite été générés grâce à l’outil spro, puis le modèle du monde créé en suivant les étapes décrites dans le TP préparatoire. Les modèles de locuteurs correspondant à ces 12 voix qui seront reconnues par le système ont également été créés.

L’an dernier, en plus de l’acquisition des signaux de 12 membres du groupe, deux scripts ont été également faits pour l’acquisition du signal d’un nouveau locuteur et la reconnaissance d’un locuteur quelconque par le système.
Le script d’acquisition de signaux permet donc d’enregistrer le signal d’un nouveau locuteur, de créer le vecteur de paramètre, de traiter le signal (normaliser, détecter l’énergie, renormaliser) et de l’ajouter au modèle du monde. Lors de l’acquisition le locuteur peut choisir d’être reconnu par le système ou non. S’il souhaite être reconnu alors son modèle de locuteur est généré. Une méthode java permettant d'exécuter un script shell a été réalisée mais nous ne disposons pas de cette méthode dans la documentation fournie.
Le script de reconnaissance du locuteur permet de tester l’appartenance d’un locuteur au système. Il enregistre le signal du locuteur pendant quelques secondes, crée le vecteur de paramètres, traite le signal (normalisation, détection de l'énergie, re-normalisation) puis teste, en fonction de son nom, si ce locuteur est reconnu par le système ou non. Vu que cette partie du projet a été bien réussie, nous réutiliserons, les 2 scripts fournis. Pour ne pas avoir à chercher en permanence des personnes extérieures à notre système pour les tests, nous utiliserons les membres de notre groupe de 6 : 4 locuteurs reconnus par le système et 2 imposteurs.

Concernant l'IHM réalisée l'année précedente, il existe 2 modes distincts:
#Le mode acquisition qui sert à récupérer le signal et créer un modèle à partir de celui-ci.
#Le mode test qui sert d’identification. L’authenticité de l’utilisateur est vérifiée en comparant au modèle enregistré.Ces modes sont aussi utilisés dans notre application, mais l’interface est différente.

'''Mode acquisition :'''

Il faut entrer le nom de l’utilisateur et la durée souhaitée de l’enregistrement. En dessous se trouve un texte important que l’utilisateur doit lire, après avoir lancé l’enregistrement à l’aide d’un bouton.
Le problème de ce type d’interface vient du texte à lire. En effet, celui-ci représente un pavé énorme, pas forcément facile à lire pour l’utilisateur. Il serait plus aisé de lire plusieurs phrases courtes, apparaissant l’une après l’autre, plutôt que de lire cet imposant paragraphe.

'''Mode test :'''

Il y a un champ disponible pour l’identifiant de l’utilisateur, ainsi qu’un slider permettant de définir le seuil.
Une fois le nom entré et le seuil réglé, l’utilisateur lance l’enregistrement à l’aide d’un bouton. Il prononce alors la phrase de son choix (environ 3secondes).

Ce modèle possède des défauts. Le plus flagrant est de donner à l’utilisateur le choix du réglage du seuil :

- Il ne sait pas forcément ce qu’est ce seuil, et ne comprend donc pas l’utilité du slider.

- S’il connait l’utilité, il peut alors le régler pour essayer de fausser la reconnaissance.

Les développeurs de cette précédente version ont précisé qu’il s’agissait d’une interface de « test » et non « d’identification », ce qui explique les libertés données à l’utilisateur.

Le second défaut est la liberté donnée pour la phrase à dire :

- D’un point de vue purement IHM, il est moins déroutant (et donc plus rapide) pour l’utilisateur de réciter une phrase affichée que d’en inventer une.

- D’un point de vue reconnaissance vocale, il est aussi plus facile de comparer une phrase connue au modèle. On limite aussi les risques (phrase trop courte par exemple).

===Répartition des tâches===
Nous avons réparti les différentes parties sur les différents membres du groupe. Nous allons démarrer en parallèle les trois parties: Montage, acquisition et IHM afin de gagner un maximum de temps. Une fois ces parties finies, on se penchera tous sur l'interfaçage entre l'IHM et les scripts de reconnaissance ainsi que les tests de performances.
Voici les rôles de chaque membre de l'équipe:

Chef de projet:
#NAHUM Solis

Développeurs Acquisition/ Reconnaissance:
#MALKAS Benjamin
#NAHUM Solis
#EL BAKKOURI Nysrine

Montage gâche:
#ODUL Jonathan

Développement IHM:
#ODUL Jonathan
#RIOT Emilien
#SEISSON Julien

Responsable wiki:
#EL BAKKOURI Nysrine

===Diagramme prévisionnel de tâches===

[[File:Tat.png]]

=Requis non fonctionnels=

Pour ce projet, nous avons choisi de mettre l’accent sur la fiabilité, l’utilisabilité, la maintenabilité et la robustesse du système.

===Interface intuitive===
L'utilisateur doit passer par une interface d'interaction afin de piloter le système, pour cela, nous avons jugé important de réaliser une interface intuitive, ergonomique et très facile d'utilisation.

===Test des performances et robustesse de notre système===
Afin de tester les performances de notre système, il est nécessaire de fixer une valeur seuil d’acceptation/rejet. Cette valeur doit permettre au mieux de deviner si la personne qui est en train de s’identifier est la bonne personne ou non. Nous allons donc effectuer plusieurs tests à partir de notre modèle du monde. La bonne valeur du seuil sera trouvée lorsque le nombre de faux rejets sera égal au nombre de fausses acceptations.

=Requis fonctionnels=

===Montage électronique de la gâche===

'''Description'''
Cette partie consiste à réaliser un simple montage électronique qui nous permettra de tester le système à la fin du projet.Voici une petite vidéo montrant les différents composants du montage ainsi que le fonctionnement de celui-ci:

[http://www.youtube.com/watch?v=sY2SDPq5gWg&feature=youtu.be]

'''Objectif'''
L’objectif est de piloter la gâche électrique depuis un PC en passant par une carte Arduino. Cette dernière devra donc être reliée à un PC en série (via USB), et la gâche électrique branchée à une sortie digitale du microcontrôleur.
La carte Arduino devra être pourvue d’un programme qui sera en mesure d’acquérir les commandes reçues via le port série, donc du PC, et ainsi, après interprétation, envoyer un signal d’ouverture ou de fermeture à la gâche.
La réalisation d’un programme sur PC sera nécessaire dans le but de pouvoir envoyer sur le port série, correspondant à la carte Arduino, les commandes d’ouverture et de fermeture. Pour cela, il existe la librairie RXTX permettant cela dans un programme Java. De plus, avec cette librairie, nous pouvons trouver beaucoup de tutoriels sur internet expliquant son utilisation pour communiquer avec une carte Arduino depuis un programme Java.
En regroupant toutes ces technologies, nous devrions être en mesure de piloter depuis un programme Java tournant sur un PC, la gâche électrique.

'''Matériel requis'''
- Gâche électrique
- Carte Arduino (ou de la même famille)
- Batterie
- Breadboard
- Quelques fils et câbles

'''Cablage'''

'''Arduino'''
Une sortie digitale (aussi appelée « pin ») sur une carte Arduino permet une commande à deux états pouvant être « haut » et « bas ». Quand on envoie un signal « haut » à une sortie digitale, alors cette dernière sera alimentée en 5 volts, tandis qu’au contraire, si un signal « bas » correspondra à une tension nulle.
Ainsi, selon la configuration de notre câblage, un signal haut correspondra à l’ouverture de la gâche électrique, et un signal bas correspondra à sa fermeture.
Afin de faire fonctionner le système, la carte Arduino devra inclure un programme compilé permettant ces actions :
- Initialisation de la communication sur le port série
- Initialisation de la sortie digitale correspondant au branchement de la gâche électrique
- Lire en continue les données reçues via le port série :
o Si commande ‘o’ reçue, envoyer signal haut à la sortie digitale
o Si commande ‘c’ reçue, envoyer signal bas à la sortie digitale

'''Programme Java'''
Afin de communiquer avec la carte Arduino, la librairie RXTX est nécessaire. L’objectif ici est simplement de créer une fonction envoyant la commande ‘o’ à la carte Arduino pour ouvrir la gâche électrique, ou bien la commande ‘c’ pour la fermer.
Un tutoriel complet est disponible à cette adresse http://arduino.cc/playground/Interfacing/Java expliquant comment établir une communication entre un programme Java et une carte Arduino.
Dans notre projet, l’environnement utilisé est un environnement Windows, ainsi certaines des indications qui suivront ne sont valables seulement pour cet environnement. Pour faire de même dans un autre environnement, se reporter au tutoriel indiqué ci-dessus.
Pour utiliser RXTX dans un projet Java, cela nécessite plusieurs choses à faire :
- ajouter la librairie RXTXcomm.jar de RXTX dans le buildpath du projet ;
- copier le fichier rxtxSerial.dll dans le répertoire du projet ;
- ajouter le paramètre « -Djava.library.path=. » dans les arguments de la JVM. Le chemin doit correspondre à l’emplacement du fichier .dll copié auparavant.
Par la suite, il faut aussi que les drivers de la carte Arduino soient installés et que cette dernière soit reconnue par le PC en tant que port COM. De plus, il faudra bien noter quel numéro est attribué au port de la carte Arduino lors de l’installation du matériel (COMX). Il est aussi possible de le voir dans la liste des matériels du PC. En effet, il servira à indiquer dans le programme à quelle adresse joindre la carte Arduino.

===Acquisition et Reconnaissance des données===
Cette partie demande la mise en place de l'environnement de travail, pour cela, il faut faire le TP: http://www-clips.imag.fr/geod/User/laurent.besacier/NEW-TPs/TP-Biometrie/ qui explique bien toutes les étapes d'installation.

===IHM de pilotage de la gâche===

Voici quelques prises d'écran du système:

====Login====
[[File:1.jpg]]

====Test identification====
[[File:2.jpg]]

====Identification échouée====
[[File:3.jpg]]

====Identification réussie====
[[File:4.jpg]]

====Page d'administration====
[[File:5.jpg]]

====Gestion de profils====
[[File:6.jpg]]

====Page de profil====
[[File:7.jpg]]

====Page d'enregistrement====
[[File:8.jpg]]

====Enregistrement lancé====
[[File:9.jpg]]

File:Cablage.jpg

2012-03-12T13:56:11Z

Emilien:

PAGE WIKI ETUDIANTS 2011-12 SERRURE VOCALE

2012-03-12T13:55:12Z

Emilien: /* Montage électronique de la gâche */

=Présentation du projet=

Le but de ce projet est de développer un système de reconnaissance vocale. Le projet consiste à réaliser un programme permettant d'ouvrir une gâche électronique simplement par la parole. Les voix des locuteurs seront préalablement enregistrées, et devront être identifiées par un système de reconnaissance vocale afin de permettre ou non l'ouverture de la gâche électronique.
Pour réaliser ce projet, nous disposons d'un montage électronique de la gâche qui sera ouverte ou non selon l'acceptation ou le rejet du signal reçu en entrée.
Pour la démonstration du projet, nous réaliserons une interface graphique qui permettra l'enregistrement des voix ainsi que leur reconnaissance.
La partie IHM sera plus expliquée en détail grâce à des sketchs par la suite.

Nous étudierons aussi à la fin du projet les performances et la robustesse de notre système.

=Déroulement du travail=
===Etude de l'existant===

Ce projet a déjà été réalisé l'année précédente, pour cela,la première étape sera d'analyser le travail effectué par les élèves de l'année précédentes, afin de garder les parties fonctionnelles et les améliorer.
Ce projet est essentiellement composé de trois grandes parties:

#Montage électronique de la gâche
#Acquisition et Reconnaissance des données
#IHM de pilotage de la gâche

Pour la réalisation de la phase d’acquisition, les travaux se sont appuyés sur le TP Biométrie préparatoire à ce projet.

Les signaux de départ correspondent aux voix des membres du groupe enregistrées au format raw comme dans le TP. Les vecteurs paramètres de ces voix ont ensuite été générés grâce à l’outil spro, puis le modèle du monde créé en suivant les étapes décrites dans le TP préparatoire. Les modèles de locuteurs correspondant à ces 12 voix qui seront reconnues par le système ont également été créés.

L’an dernier, en plus de l’acquisition des signaux de 12 membres du groupe, deux scripts ont été également faits pour l’acquisition du signal d’un nouveau locuteur et la reconnaissance d’un locuteur quelconque par le système.
Le script d’acquisition de signaux permet donc d’enregistrer le signal d’un nouveau locuteur, de créer le vecteur de paramètre, de traiter le signal (normaliser, détecter l’énergie, renormaliser) et de l’ajouter au modèle du monde. Lors de l’acquisition le locuteur peut choisir d’être reconnu par le système ou non. S’il souhaite être reconnu alors son modèle de locuteur est généré. Une méthode java permettant d'exécuter un script shell a été réalisée mais nous ne disposons pas de cette méthode dans la documentation fournie.
Le script de reconnaissance du locuteur permet de tester l’appartenance d’un locuteur au système. Il enregistre le signal du locuteur pendant quelques secondes, crée le vecteur de paramètres, traite le signal (normalisation, détection de l'énergie, re-normalisation) puis teste, en fonction de son nom, si ce locuteur est reconnu par le système ou non. Vu que cette partie du projet a été bien réussie, nous réutiliserons, les 2 scripts fournis. Pour ne pas avoir à chercher en permanence des personnes extérieures à notre système pour les tests, nous utiliserons les membres de notre groupe de 6 : 4 locuteurs reconnus par le système et 2 imposteurs.

Concernant l'IHM réalisée l'année précedente, il existe 2 modes distincts:
#Le mode acquisition qui sert à récupérer le signal et créer un modèle à partir de celui-ci.
#Le mode test qui sert d’identification. L’authenticité de l’utilisateur est vérifiée en comparant au modèle enregistré.Ces modes sont aussi utilisés dans notre application, mais l’interface est différente.

'''Mode acquisition :'''

Il faut entrer le nom de l’utilisateur et la durée souhaitée de l’enregistrement. En dessous se trouve un texte important que l’utilisateur doit lire, après avoir lancé l’enregistrement à l’aide d’un bouton.
Le problème de ce type d’interface vient du texte à lire. En effet, celui-ci représente un pavé énorme, pas forcément facile à lire pour l’utilisateur. Il serait plus aisé de lire plusieurs phrases courtes, apparaissant l’une après l’autre, plutôt que de lire cet imposant paragraphe.

'''Mode test :'''

Il y a un champ disponible pour l’identifiant de l’utilisateur, ainsi qu’un slider permettant de définir le seuil.
Une fois le nom entré et le seuil réglé, l’utilisateur lance l’enregistrement à l’aide d’un bouton. Il prononce alors la phrase de son choix (environ 3secondes).

Ce modèle possède des défauts. Le plus flagrant est de donner à l’utilisateur le choix du réglage du seuil :

- Il ne sait pas forcément ce qu’est ce seuil, et ne comprend donc pas l’utilité du slider.

- S’il connait l’utilité, il peut alors le régler pour essayer de fausser la reconnaissance.

Les développeurs de cette précédente version ont précisé qu’il s’agissait d’une interface de « test » et non « d’identification », ce qui explique les libertés données à l’utilisateur.

Le second défaut est la liberté donnée pour la phrase à dire :

- D’un point de vue purement IHM, il est moins déroutant (et donc plus rapide) pour l’utilisateur de réciter une phrase affichée que d’en inventer une.

- D’un point de vue reconnaissance vocale, il est aussi plus facile de comparer une phrase connue au modèle. On limite aussi les risques (phrase trop courte par exemple).

===Répartition des tâches===
Nous avons réparti les différentes parties sur les différents membres du groupe. Nous allons démarrer en parallèle les trois parties: Montage, acquisition et IHM afin de gagner un maximum de temps. Une fois ces parties finies, on se penchera tous sur l'interfaçage entre l'IHM et les scripts de reconnaissance ainsi que les tests de performances.
Voici les rôles de chaque membre de l'équipe:

Chef de projet:
#NAHUM Solis

Développeurs Acquisition/ Reconnaissance:
#MALKAS Benjamin
#NAHUM Solis
#EL BAKKOURI Nysrine

Montage gâche:
#ODUL Jonathan

Développement IHM:
#ODUL Jonathan
#RIOT Emilien
#SEISSON Julien

Responsable wiki:
#EL BAKKOURI Nysrine

===Diagramme prévisionnel de tâches===

[[File:Tat.png]]

=Requis non fonctionnels=

Pour ce projet, nous avons choisi de mettre l’accent sur la fiabilité, l’utilisabilité, la maintenabilité et la robustesse du système.

===Interface intuitive===
L'utilisateur doit passer par une interface d'interaction afin de piloter le système, pour cela, nous avons jugé important de réaliser une interface intuitive, ergonomique et très facile d'utilisation.

===Test des performances et robustesse de notre système===
Afin de tester les performances de notre système, il est nécessaire de fixer une valeur seuil d’acceptation/rejet. Cette valeur doit permettre au mieux de deviner si la personne qui est en train de s’identifier est la bonne personne ou non. Nous allons donc effectuer plusieurs tests à partir de notre modèle du monde. La bonne valeur du seuil sera trouvée lorsque le nombre de faux rejets sera égal au nombre de fausses acceptations.

=Requis fonctionnels=

===Montage électronique de la gâche===

'''Description'''
Cette partie consiste à réaliser un simple montage électronique qui nous permettra de tester le système à la fin du projet.Voici une petite vidéo montrant les différents composants du montage ainsi que le fonctionnement de celui-ci:

[http://www.youtube.com/watch?v=sY2SDPq5gWg&feature=youtu.be]

'''Objectif'''
L’objectif est de piloter la gâche électrique depuis un PC en passant par une carte Arduino. Cette dernière devra donc être reliée à un PC en série (via USB), et la gâche électrique branchée à une sortie digitale du microcontrôleur.
La carte Arduino devra être pourvue d’un programme qui sera en mesure d’acquérir les commandes reçues via le port série, donc du PC, et ainsi, après interprétation, envoyer un signal d’ouverture ou de fermeture à la gâche.
La réalisation d’un programme sur PC sera nécessaire dans le but de pouvoir envoyer sur le port série, correspondant à la carte Arduino, les commandes d’ouverture et de fermeture. Pour cela, il existe la librairie RXTX permettant cela dans un programme Java. De plus, avec cette librairie, nous pouvons trouver beaucoup de tutoriels sur internet expliquant son utilisation pour communiquer avec une carte Arduino depuis un programme Java.
En regroupant toutes ces technologies, nous devrions être en mesure de piloter depuis un programme Java tournant sur un PC, la gâche électrique.

'''Matériel requis'''
- Gâche électrique
- Carte Arduino (ou de la même famille)
- Batterie
- Breadboard
- Quelques fils et câbles

'''Cablage'''
[[File:cablage.jpg]]

'''Arduino'''
Une sortie digitale (aussi appelée « pin ») sur une carte Arduino permet une commande à deux états pouvant être « haut » et « bas ». Quand on envoie un signal « haut » à une sortie digitale, alors cette dernière sera alimentée en 5 volts, tandis qu’au contraire, si un signal « bas » correspondra à une tension nulle.
Ainsi, selon la configuration de notre câblage, un signal haut correspondra à l’ouverture de la gâche électrique, et un signal bas correspondra à sa fermeture.
Afin de faire fonctionner le système, la carte Arduino devra inclure un programme compilé permettant ces actions :
- Initialisation de la communication sur le port série
- Initialisation de la sortie digitale correspondant au branchement de la gâche électrique
- Lire en continue les données reçues via le port série :
o Si commande ‘o’ reçue, envoyer signal haut à la sortie digitale
o Si commande ‘c’ reçue, envoyer signal bas à la sortie digitale

'''Programme Java'''
Afin de communiquer avec la carte Arduino, la librairie RXTX est nécessaire. L’objectif ici est simplement de créer une fonction envoyant la commande ‘o’ à la carte Arduino pour ouvrir la gâche électrique, ou bien la commande ‘c’ pour la fermer.
Un tutoriel complet est disponible à cette adresse http://arduino.cc/playground/Interfacing/Java expliquant comment établir une communication entre un programme Java et une carte Arduino.
Dans notre projet, l’environnement utilisé est un environnement Windows, ainsi certaines des indications qui suivront ne sont valables seulement pour cet environnement. Pour faire de même dans un autre environnement, se reporter au tutoriel indiqué ci-dessus.
Pour utiliser RXTX dans un projet Java, cela nécessite plusieurs choses à faire :
- ajouter la librairie RXTXcomm.jar de RXTX dans le buildpath du projet ;
- copier le fichier rxtxSerial.dll dans le répertoire du projet ;
- ajouter le paramètre « -Djava.library.path=. » dans les arguments de la JVM. Le chemin doit correspondre à l’emplacement du fichier .dll copié auparavant.
Par la suite, il faut aussi que les drivers de la carte Arduino soient installés et que cette dernière soit reconnue par le PC en tant que port COM. De plus, il faudra bien noter quel numéro est attribué au port de la carte Arduino lors de l’installation du matériel (COMX). Il est aussi possible de le voir dans la liste des matériels du PC. En effet, il servira à indiquer dans le programme à quelle adresse joindre la carte Arduino.

===Acquisition et Reconnaissance des données===
Cette partie demande la mise en place de l'environnement de travail, pour cela, il faut faire le TP: http://www-clips.imag.fr/geod/User/laurent.besacier/NEW-TPs/TP-Biometrie/ qui explique bien toutes les étapes d'installation.

===IHM de pilotage de la gâche===

Voici quelques prises d'écran du système:

====Login====
[[File:1.jpg]]

====Test identification====
[[File:2.jpg]]

====Identification échouée====
[[File:3.jpg]]

====Identification réussie====
[[File:4.jpg]]

====Page d'administration====
[[File:5.jpg]]

====Gestion de profils====
[[File:6.jpg]]

====Page de profil====
[[File:7.jpg]]

====Page d'enregistrement====
[[File:8.jpg]]

====Enregistrement lancé====
[[File:9.jpg]]

AmIWheelchair

2011-10-06T13:15:41Z

Emilien:

'''Projet AmIWheelchair : Assistance et suivi de la personne utilisatrice d’un fauteuil roulant manuel intelligent et communiquant'''

* UE/Module: Projet innovant de RICM4 option CM + 3I

* Enseignants TIS : Pierre-Yves Gumery, Nicolas Vuillerme, Pascale Calabrese, Didier Pradon (AP-HP Hôpital Raymond Poincaré Garches).
* Enseignants RICM : Didier Donsez, Olivier Richard, Nicolas Palix
* Enseignants 3I : David Eon, Sophie Chareyron, Yves Lavault, Skandar Basrour

* Elèves
** RICM : Jonathan Odul (chef de projet), Emilien Riot, Solis Nahum, Corentin Foucault, Nysrine El Bakkouri
** 3I : Alexandre Chaboche, Sylvain Jourdan, Thibaut Montagnat-Rentier, Marielle Amans
** TIS : la promotion
------------------------

==Introduction==

On estime à environ 1,5 millions de personnes « handicapées motrices » en France. Parmi elles, 340 000 utilisent un fauteuil roulant . Les pathologies concernées liées ou pas au vieillissement sont nombreuses : myopathies, lésions de la moelle, traumatismes crâniens, accidents vasculaires cérébraux, maladies dégénératives (sclérose en plaques…), infirmité motrice cérébrale, séquelles de poliomyélite… Curieusement, le monde médical s’intéresse peu à l’utilisation de ces fauteuils roulants, qui est pourtant, considérés comme des dispositifs médicaux, font partie de la liste des produits de prestation. Il faut cependant rappeler la loi du 11 Février 2005 pour l’égalité des droits et des chances pour les personnes handicapées, qui souligne le droit à la compensation du handicap. Aussi des centres référents (Fondation Garches, CERAH à Woippy) ou centres de rééducations (CHU Raymond Poincaré APHP Garches, CHU Henri Gabriel HCL Lyon, CHR Lille, …) ont mis en place une prise en charge adaptée aux besoins et aux demandes de l’utilisateur. Cette prise en charge est pour l’essentiel curative lors des soins et préventive lors de la rééducation. Actuellement, l’utilisation de cette aide au déplacement est prise en charge uniquement dans ces différents centres. Aussi, l’utilisateur se trouve la plupart du temps dépourvu de toute assistance, mais aussi de conseils au quotidien et hors de ces centres. Par conséquent, il lui est difficile d’appliquer les mouvements appris lors de la rééducation, d’adopter des stratégies d’évitement ou de contournement lors de la présence d’obstacles et autres difficultés dans ces déplacements quotidiens. L’émergence et le développement des technologies de l’informatique ambiante peuvent apporter des solutions non seulement pour conseiller, mais également pour assister ces personnes dans l’utilisation de leur fauteuil lors de leurs déplacements quotidiens.

==Objectif==
Le projet AmiWheelchair concerne l’assistance et le suivi de la personne handicapée se déplaçant à l’aide d’un fauteuil roulant manuel ou à assistance électrique à la propulsion sur ses lieux de vie (logement, travail, site urbaine, transport en commun) au moyen des technologies de l’informatique ambiante.

Ce projet permet aux personnes atteintes de graves restrictions de mobilité consécutives à une lésion de la moelle épinière, à une maladie neurologique ou musculaire congénitale ou acquise, à un traumatisme des membres inférieurs, ou au vieillissement, de préserver leur autonomie et leur qualité de vie lié au déplacement en fauteuil roulant manuel :

# en favorisant le choix et le réglage approprié du fauteuil à leurs caractéristiques, besoins et attentes,
# en minimisant le risque d’apparition de troubles musculo-squelettiques,
# en optimisant leur prise en charge fonctionnelle thérapeutique,
# en fournissant des informations pertinentes, fiables et valides aux collectivités locales pour la conception, l’aménagement et l’évaluation de l'accessibilité aux personnes à mobilité réduite dans le cadre d’activités quotidiennes (logement, établissements recevant du public, installations ouvertes au public, bâtiments d’habitation et ses annexes, moyens de transports collectifs conventionnels …) ou des informations correspondantes au déplacement et à l’utilisation d’un lieu public.

Ce projet vise à
* instrumenter la personne pour monitorer son usage musculaire de son fauteuil au moyen d’EMG et d’accéléromètres ainsi que son effort au moyen de cardio-fréquencemêtre.
* instrumenter le fauteuil personne handicapée pour monitorer son usage musculaire de son fauteuil au moyen de gyroscopes, inclinomètre, compteurs de tour de roue, capteurs de vibration, …
* collecter les mesures acquises au moyen du téléphone 3G/Wifi de l’utilisateur. Le GPS intégré au téléphone fournit les positions géographiques pour le suivi spatial de l’utilisateur . Le téléphone sert également à dénoncer des obstacles explicitement par l’utilisateur. Les mesures et les dénonciations sont remontées via des liaisons 3G/Wifi vers un centre serveur qui les archive.
*restituer aux médecins et aux urbanistes les mesures individuelles ou collectives concernant les usagers dans un objectif de support à la prise de décision (réglage du fauteuil, aménagement des accès handicapés sur les sites).

La figure 1 schématise les composants fonctionnels décrits ci-dessus, ainsi que les communications multimodales (ZigBee ou 6LoWPAN/RF, Bluetooth, 3G et Wifi) utilisés entre ceux-ci. Les composants doivent pouvoir supporter des intermitences dans les communications (perte de la 3G ou sortie d’un hotspot Wifi, ...)

[[File:archiwheelchair.png]]

'''Références'''
# Vignier N, Ravaud JF, Winance M, Lepoutre FX, Ville I. (2008). Demographics of wheelchair users in France: results of national community-based handicaps-incapacités-dépendance surveys. J Rehabil Med. 40(3):231-9.
# The Ambient Assisted Living (AAL) Joint Programme http://www.aal-europe.eu

==Synthèse du projet==
[[AmiWheelchair]]

== Etapes du projet ==

=== Sous-groupes ===

* Groupe 3i + 1 groupe RICM : sous-projet 'mesures EMG' : l'objectif est l'évaluation de la co-contraction biceps/triceps par poussée fauteuil avec un feedback utilisateur (sur smartphone Android,...). Une IHM mobile est à développer (RICM)

* Groupe 3i : sous-projet 'mesures mécaniques embarquées' sur le fauteuil : inclinométrie, compte-tour, accéléromètrie

* Groupe RICM : sous-projet 'data serveur' pour l'archivage et la visualisation des informations collectées

=== Requis ===
L'ensemble des groupes doit s'intéresser au problème de la synchro et de la géolocalisation.

== Partie Instrumentation (3I) ==

[[File:AmoWheelChair.png]]

=== Photos ===
[[File:amowheelchair01.jpg|200px]]
[[File:amowheelchair02.jpg|200px]]
[[File:amowheelchair03.jpg|200px]]
[[File:amowheelchair04-igoe.jpg|200px]]
[[File:amowheelchair05-emg.jpg|200px]]
[[File:amowheelchair06-emg.jpg|200px]]

== Partie Logiciel (RICM) ==

=== Bluetooth ===

* Récupération de données via Bluetooth fonctionnelle mais non intégrée au programme AMODROID

=== AMODROID ===

* Interface utilisateur pour Android
* Affichage des informations en temps réels
* Prise de photos d’obstacles
* Envoi de données au Data Server

==== Vidéo de démonstration ====

[http://www.youtube.com/watch?v=hx4JFqrTQFA Projet AMO - AMODROID]

==== Screens ====
[[File:Amo3.png|200px]] [[File:Amo4.png|200px]] [[File:Amo2.png|200px]]

=== Data Server ===

* Récupération des fichiers XML envoyés par le téléphone
* Parsage et ajout des informations dans la base de données
* Ne gère pas encore la récupération de photo

=== Doctor Monitoring Console ===

* Affichage des courbes de valeurs des capteurs

=== Standard XML pour l'échange entre AMODROID et Data Server ===

Structure du fichier :

<pre>
<?xml version='1.0' encoding='UTF-8' standalone='yes' ?>
<user name="Jojo">



</user>
</pez>

Ajouter les valeurs de capteurs:

La date se trouve en nombre de millisecondes depuis le 1/1/70

* GPS :
<pre>
<capture name="gps" date="TIME" value="LATTITUDE;LONGITUDE" option="" />
</pre>

* Vitesse :
<pre>
<capture name="speed" date="TIME" value="VITESSE" option="" />
</pre>

* Inclinaison :
<pre>
<capture name="angle" date="TIME" value="Angle_X;Angle_Z" option="" />
</pre>

-180°<Angle_X<180° Angle par rapport à l'axe X
-90°<Angle_Z<90° Angle par rapport à l'axe Z

* Présence des pieds :
<pre>
<capture name="feet" date="TIME" value="true|false" option="RIGHT_FEET|LEFT_FEET" />
</pre>

* EMG :
<pre>
<capture name="emg" date="TIME" value="EMG" option="RIGHT_ARM|LEFT_ARM" />
</pre>

Exemple de fichiers XML
<pre>
<?xml version='1.0' encoding='UTF-8' standalone='yes' ?>
<user name="Jojo">
<capture name="angle" date="1302020063061" value="-28.0546126677242;-63.50424358674799" option="" />
<capture name="speed" date="1302020063166" value="0.9431113020310783" option="" />
<capture name="feet" date="1302020063279" value="true" option="RIGHT_FEET" />
<capture name="emg" date="1302020063380" value="78.86916229314703" option="LEFT_ARM" />
<capture name="gps" date="1302020063491" value="46.75984635429418;5.731604442019073" option="" />
<capture name="speed" date="1302020063597" value="1.6357488275481757" option="" />
<capture name="speed" date="1302020063698" value="1.7421962830724746" option="" />
<capture name="gps" date="1302020063799" value="46.75985238471921;5.731604475843198" option="" />
<capture name="speed" date="1302020063906" value="1.0719870056896013" option="" />
<capture name="feet" date="1302020064012" value="true" option="RIGHT_FEET" />
</user>
</pre>

==Equipement==
* [http://www.invacare.fr/articles/invc-fauteuil-roulant-invacare--43-72.php Invacare Wheelchair]
* HTC Hero
* Archos Internet Tablet 101

Board
* [http://www.seeedstudio.com/depot/seeeduino-stalker-v2b-p-727.html Seeeduino Stalker v2b]
* [http://www.sparkfun.com/products/9266 LilyPad Arduino 328 Main Board]
* [http://www.sparkfun.com/products/8937 Lilypad XBee shield]
* [http://www.sparkfun.com/products/8767 XBee Pro module]
* [http://www.sparkfun.com/products/8687 XBee Explorer USB]
* [http://www.sparkfun.com/products/9358 Bluetooth Mate]
* [http://www.sparkfun.com/products/10009 FTDI Basic Breakout - 3.3V]
* STM32
* [http://arduino.cc/en/Main/ArduinoBoardMega2560 Arduino Mega2560]
* [http://processors.wiki.ti.com/index.php/EZ430-Chronos TI' ez430 Chronos 433]
* Bluetooth mate
** [http://www.amarino-toolkit.net/index.php/home.html liaison bluetooth entre un Arduino et un telephone Android]

Sensors
* [http://www.sparkfun.com/products/9267 LilyPad Accelerometer ADXL335]
* Récepteur OEM Polar pour les ceintures cardio Polar
** http://www.sparkfun.com/products/8661
** http://www.sparkfun.com/products/8660
* [http://www.sparkfun.com/products/9197 Piezo Vibration Sensor - Large with Mass]
* [http://www.sparkfun.com/products/9376 Force Sensitive Resistor - Square]
* [http://www.sparkfun.com/products/10055 Conductive Fabric]
* [http://www.sparkfun.com/products/8549 Conductive Thread - 234/34 4ply]
* Wiimote, Wiimotion, Nunchuk (Bluetooth)
* [http://www.seeedstudio.com/depot/magnetic-door-switch-p-666.html?cPath=156_160 Magnetic Door Switch]
* [http://www.sparkfun.com/products/9312 Hall effect sensor]
* Bicycle wheel counter

* '''Cardio frequencemetre'''
** Recepteur OEM Polar pour les ceintures cardio Polar
*** http://www.sparkfun.com/products/8661
*** http://www.sparkfun.com/products/8660
** [http://www.decathlon.fr/cw-kalenji-100-id_montre_8051265.html montre et sa bande poitrine communiquant probablement en 433 MHz (non codé)]
** recepteur USB 433 MHz livré avec la [http://processors.wiki.ti.com/index.php/EZ430-Chronos ez430 Chronos 433]
** [http://www.seeedstudio.com/depot/433mhz-rf-link-kit-p-127.html?cPath=139_140 émetteurs récepteurs 433MHz]

Others
* 433 MHz receiver/transceiver dongles
** [http://www.seeedstudio.com/depot/433mhz-rf-link-kit-p-127.html 433Mhz RF link kit]

==Canevas Logiciels==
* Android
* [[Google Web Toolkit]]
* [[JFreeChart]]
* [http://www.google.com/earth/explore/products/plugin.html Google Earth Plugin] : [http://earth-api-samples.googlecode.com/svn/trunk/demos/drive-simulator/index.html Un exemple intéressant pour le projet]

==Remerciements==
* AP-HP Hôpital Raymond Poincaré Garches
* Centre d’Investigation clinique et d’Innovation Technologique (CIC-IT 805) Garches "Evaluation des médicaments et des dispositifs médicaux pour le handicap"
* Fondation Garches
* Invacare

AmIWheelchair

2011-10-06T13:15:03Z

Emilien:

'''Projet AmIWheelchair : Assistance et suivi de la personne utilisatrice d’un fauteuil roulant manuel intelligent et communiquant'''

* UE/Module: Projet innovant de RICM4 option CM + 3I

* Enseignants TIS : Pierre-Yves Gumery, Nicolas Vuillerme, Pascale Calabrese, Didier Pradon (AP-HP Hôpital Raymond Poincaré Garches).
* Enseignants RICM : Didier Donsez, Olivier Richard, Nicolas Palix
* Enseignants 3I : David Eon, Sophie Chareyron, Yves Lavault, Skandar Basrour

* Elèves
** RICM : Jonathan Odul (chef de projet), Emilien Riot, Solis Nahum, Corentin Foucault
** 3I : Alexandre Chaboche, Sylvain Jourdan, Thibaut Montagnat-Rentier, Marielle Amans
** TIS : la promotion
------------------------

==Introduction==

On estime à environ 1,5 millions de personnes « handicapées motrices » en France. Parmi elles, 340 000 utilisent un fauteuil roulant . Les pathologies concernées liées ou pas au vieillissement sont nombreuses : myopathies, lésions de la moelle, traumatismes crâniens, accidents vasculaires cérébraux, maladies dégénératives (sclérose en plaques…), infirmité motrice cérébrale, séquelles de poliomyélite… Curieusement, le monde médical s’intéresse peu à l’utilisation de ces fauteuils roulants, qui est pourtant, considérés comme des dispositifs médicaux, font partie de la liste des produits de prestation. Il faut cependant rappeler la loi du 11 Février 2005 pour l’égalité des droits et des chances pour les personnes handicapées, qui souligne le droit à la compensation du handicap. Aussi des centres référents (Fondation Garches, CERAH à Woippy) ou centres de rééducations (CHU Raymond Poincaré APHP Garches, CHU Henri Gabriel HCL Lyon, CHR Lille, …) ont mis en place une prise en charge adaptée aux besoins et aux demandes de l’utilisateur. Cette prise en charge est pour l’essentiel curative lors des soins et préventive lors de la rééducation. Actuellement, l’utilisation de cette aide au déplacement est prise en charge uniquement dans ces différents centres. Aussi, l’utilisateur se trouve la plupart du temps dépourvu de toute assistance, mais aussi de conseils au quotidien et hors de ces centres. Par conséquent, il lui est difficile d’appliquer les mouvements appris lors de la rééducation, d’adopter des stratégies d’évitement ou de contournement lors de la présence d’obstacles et autres difficultés dans ces déplacements quotidiens. L’émergence et le développement des technologies de l’informatique ambiante peuvent apporter des solutions non seulement pour conseiller, mais également pour assister ces personnes dans l’utilisation de leur fauteuil lors de leurs déplacements quotidiens.

==Objectif==
Le projet AmiWheelchair concerne l’assistance et le suivi de la personne handicapée se déplaçant à l’aide d’un fauteuil roulant manuel ou à assistance électrique à la propulsion sur ses lieux de vie (logement, travail, site urbaine, transport en commun) au moyen des technologies de l’informatique ambiante.

Ce projet permet aux personnes atteintes de graves restrictions de mobilité consécutives à une lésion de la moelle épinière, à une maladie neurologique ou musculaire congénitale ou acquise, à un traumatisme des membres inférieurs, ou au vieillissement, de préserver leur autonomie et leur qualité de vie lié au déplacement en fauteuil roulant manuel :

# en favorisant le choix et le réglage approprié du fauteuil à leurs caractéristiques, besoins et attentes,
# en minimisant le risque d’apparition de troubles musculo-squelettiques,
# en optimisant leur prise en charge fonctionnelle thérapeutique,
# en fournissant des informations pertinentes, fiables et valides aux collectivités locales pour la conception, l’aménagement et l’évaluation de l'accessibilité aux personnes à mobilité réduite dans le cadre d’activités quotidiennes (logement, établissements recevant du public, installations ouvertes au public, bâtiments d’habitation et ses annexes, moyens de transports collectifs conventionnels …) ou des informations correspondantes au déplacement et à l’utilisation d’un lieu public.

Ce projet vise à
* instrumenter la personne pour monitorer son usage musculaire de son fauteuil au moyen d’EMG et d’accéléromètres ainsi que son effort au moyen de cardio-fréquencemêtre.
* instrumenter le fauteuil personne handicapée pour monitorer son usage musculaire de son fauteuil au moyen de gyroscopes, inclinomètre, compteurs de tour de roue, capteurs de vibration, …
* collecter les mesures acquises au moyen du téléphone 3G/Wifi de l’utilisateur. Le GPS intégré au téléphone fournit les positions géographiques pour le suivi spatial de l’utilisateur . Le téléphone sert également à dénoncer des obstacles explicitement par l’utilisateur. Les mesures et les dénonciations sont remontées via des liaisons 3G/Wifi vers un centre serveur qui les archive.
*restituer aux médecins et aux urbanistes les mesures individuelles ou collectives concernant les usagers dans un objectif de support à la prise de décision (réglage du fauteuil, aménagement des accès handicapés sur les sites).

La figure 1 schématise les composants fonctionnels décrits ci-dessus, ainsi que les communications multimodales (ZigBee ou 6LoWPAN/RF, Bluetooth, 3G et Wifi) utilisés entre ceux-ci. Les composants doivent pouvoir supporter des intermitences dans les communications (perte de la 3G ou sortie d’un hotspot Wifi, ...)

[[File:archiwheelchair.png]]

'''Références'''
# Vignier N, Ravaud JF, Winance M, Lepoutre FX, Ville I. (2008). Demographics of wheelchair users in France: results of national community-based handicaps-incapacités-dépendance surveys. J Rehabil Med. 40(3):231-9.
# The Ambient Assisted Living (AAL) Joint Programme http://www.aal-europe.eu

==Synthèse du projet==
[[AmiWheelchair]]

== Etapes du projet ==

=== Sous-groupes ===

* Groupe 3i + 1 groupe RICM : sous-projet 'mesures EMG' : l'objectif est l'évaluation de la co-contraction biceps/triceps par poussée fauteuil avec un feedback utilisateur (sur smartphone Android,...). Une IHM mobile est à développer (RICM)

* Groupe 3i : sous-projet 'mesures mécaniques embarquées' sur le fauteuil : inclinométrie, compte-tour, accéléromètrie

* Groupe RICM : sous-projet 'data serveur' pour l'archivage et la visualisation des informations collectées

=== Requis ===
L'ensemble des groupes doit s'intéresser au problème de la synchro et de la géolocalisation.

== Partie Instrumentation (3I) ==

[[File:AmoWheelChair.png]]

=== Photos ===
[[File:amowheelchair01.jpg|200px]]
[[File:amowheelchair02.jpg|200px]]
[[File:amowheelchair03.jpg|200px]]
[[File:amowheelchair04-igoe.jpg|200px]]
[[File:amowheelchair05-emg.jpg|200px]]
[[File:amowheelchair06-emg.jpg|200px]]

== Partie Logiciel (RICM) ==

=== Bluetooth ===

* Récupération de données via Bluetooth fonctionnelle mais non intégrée au programme AMODROID

=== AMODROID ===

* Interface utilisateur pour Android
* Affichage des informations en temps réels
* Prise de photos d’obstacles
* Envoi de données au Data Server

==== Vidéo de démonstration ====

[http://www.youtube.com/watch?v=hx4JFqrTQFA Projet AMO - AMODROID]

==== Screens ====
[[File:Amo3.png|200px]] [[File:Amo4.png|200px]] [[File:Amo2.png|200px]]

=== Data Server ===

* Récupération des fichiers XML envoyés par le téléphone
* Parsage et ajout des informations dans la base de données
* Ne gère pas encore la récupération de photo

=== Doctor Monitoring Console ===

* Affichage des courbes de valeurs des capteurs

=== Standard XML pour l'échange entre AMODROID et Data Server ===

Structure du fichier :

<pre>
<?xml version='1.0' encoding='UTF-8' standalone='yes' ?>
<user name="Jojo">



</user>
</pez>

Ajouter les valeurs de capteurs:

La date se trouve en nombre de millisecondes depuis le 1/1/70

* GPS :
<pre>
<capture name="gps" date="TIME" value="LATTITUDE;LONGITUDE" option="" />
</pre>

* Vitesse :
<pre>
<capture name="speed" date="TIME" value="VITESSE" option="" />
</pre>

* Inclinaison :
<pre>
<capture name="angle" date="TIME" value="Angle_X;Angle_Z" option="" />
</pre>

-180°<Angle_X<180° Angle par rapport à l'axe X
-90°<Angle_Z<90° Angle par rapport à l'axe Z

* Présence des pieds :
<pre>
<capture name="feet" date="TIME" value="true|false" option="RIGHT_FEET|LEFT_FEET" />
</pre>

* EMG :
<pre>
<capture name="emg" date="TIME" value="EMG" option="RIGHT_ARM|LEFT_ARM" />
</pre>

Exemple de fichiers XML
<pre>
<?xml version='1.0' encoding='UTF-8' standalone='yes' ?>
<user name="Jojo">
<capture name="angle" date="1302020063061" value="-28.0546126677242;-63.50424358674799" option="" />
<capture name="speed" date="1302020063166" value="0.9431113020310783" option="" />
<capture name="feet" date="1302020063279" value="true" option="RIGHT_FEET" />
<capture name="emg" date="1302020063380" value="78.86916229314703" option="LEFT_ARM" />
<capture name="gps" date="1302020063491" value="46.75984635429418;5.731604442019073" option="" />
<capture name="speed" date="1302020063597" value="1.6357488275481757" option="" />
<capture name="speed" date="1302020063698" value="1.7421962830724746" option="" />
<capture name="gps" date="1302020063799" value="46.75985238471921;5.731604475843198" option="" />
<capture name="speed" date="1302020063906" value="1.0719870056896013" option="" />
<capture name="feet" date="1302020064012" value="true" option="RIGHT_FEET" />
</user>
</pre>

==Equipement==
* [http://www.invacare.fr/articles/invc-fauteuil-roulant-invacare--43-72.php Invacare Wheelchair]
* HTC Hero
* Archos Internet Tablet 101

Board
* [http://www.seeedstudio.com/depot/seeeduino-stalker-v2b-p-727.html Seeeduino Stalker v2b]
* [http://www.sparkfun.com/products/9266 LilyPad Arduino 328 Main Board]
* [http://www.sparkfun.com/products/8937 Lilypad XBee shield]
* [http://www.sparkfun.com/products/8767 XBee Pro module]
* [http://www.sparkfun.com/products/8687 XBee Explorer USB]
* [http://www.sparkfun.com/products/9358 Bluetooth Mate]
* [http://www.sparkfun.com/products/10009 FTDI Basic Breakout - 3.3V]
* STM32
* [http://arduino.cc/en/Main/ArduinoBoardMega2560 Arduino Mega2560]
* [http://processors.wiki.ti.com/index.php/EZ430-Chronos TI' ez430 Chronos 433]
* Bluetooth mate
** [http://www.amarino-toolkit.net/index.php/home.html liaison bluetooth entre un Arduino et un telephone Android]

Sensors
* [http://www.sparkfun.com/products/9267 LilyPad Accelerometer ADXL335]
* Récepteur OEM Polar pour les ceintures cardio Polar
** http://www.sparkfun.com/products/8661
** http://www.sparkfun.com/products/8660
* [http://www.sparkfun.com/products/9197 Piezo Vibration Sensor - Large with Mass]
* [http://www.sparkfun.com/products/9376 Force Sensitive Resistor - Square]
* [http://www.sparkfun.com/products/10055 Conductive Fabric]
* [http://www.sparkfun.com/products/8549 Conductive Thread - 234/34 4ply]
* Wiimote, Wiimotion, Nunchuk (Bluetooth)
* [http://www.seeedstudio.com/depot/magnetic-door-switch-p-666.html?cPath=156_160 Magnetic Door Switch]
* [http://www.sparkfun.com/products/9312 Hall effect sensor]
* Bicycle wheel counter

* '''Cardio frequencemetre'''
** Recepteur OEM Polar pour les ceintures cardio Polar
*** http://www.sparkfun.com/products/8661
*** http://www.sparkfun.com/products/8660
** [http://www.decathlon.fr/cw-kalenji-100-id_montre_8051265.html montre et sa bande poitrine communiquant probablement en 433 MHz (non codé)]
** recepteur USB 433 MHz livré avec la [http://processors.wiki.ti.com/index.php/EZ430-Chronos ez430 Chronos 433]
** [http://www.seeedstudio.com/depot/433mhz-rf-link-kit-p-127.html?cPath=139_140 émetteurs récepteurs 433MHz]

Others
* 433 MHz receiver/transceiver dongles
** [http://www.seeedstudio.com/depot/433mhz-rf-link-kit-p-127.html 433Mhz RF link kit]

==Canevas Logiciels==
* Android
* [[Google Web Toolkit]]
* [[JFreeChart]]
* [http://www.google.com/earth/explore/products/plugin.html Google Earth Plugin] : [http://earth-api-samples.googlecode.com/svn/trunk/demos/drive-simulator/index.html Un exemple intéressant pour le projet]

==Remerciements==
* AP-HP Hôpital Raymond Poincaré Garches
* Centre d’Investigation clinique et d’Innovation Technologique (CIC-IT 805) Garches "Evaluation des médicaments et des dispositifs médicaux pour le handicap"
* Fondation Garches
* Invacare