IMA5 2019/2020 P18 - Historique des versions

Ibendhia le 19 février 2020 à 16:48

2020-02-19T16:48:45Z

Ibendhia : /* Documents Rendus */

2020-02-19T16:43:26Z

‎Documents Rendus

Ibendhia : /* Partie Unity */

2020-02-19T15:24:42Z

‎Partie Unity

Ibendhia : /* Partie web */

2020-02-19T13:18:46Z

‎Partie web

Ibendhia : /* Description */

2020-02-19T09:58:58Z

‎Description

Ibendhia : /* Description */

2020-02-19T09:57:05Z

‎Description

Ibendhia : /* Partie web */

2020-02-18T18:01:52Z

‎Partie web

Ibendhia : /* Semaine 6 */

2020-02-18T18:01:09Z

‎Semaine 6

Ibendhia : /* Partie web */

2020-02-18T15:44:56Z

‎Partie web

Ibendhia : /* Les tests */

2020-02-18T15:41:03Z

‎Les tests

@@ Ligne 35 : / Ligne 35 : @@
 ==Choix techniques : matériel et logiciel==
-Le choix matériel et logiciel avait déjà été décidé par l'équipe MINT. Le casque Oculus Quest est idéal pour ce projet car il est portable et les applications tournent directement dessus, sans devoir passer par un ordinateur, et a un coût abordable. La Raspberry Pi a été choisie car moins intrusive comparé à un ordinateur, et bien moins cher.
+Le choix matériel et logiciel avait déjà été décidé par l'équipe MINT. Le casque Oculus Quest est idéal pour ce projet, car il est portable et les applications tournent directement dessus, sans devoir passer par un ordinateur, et a un coût abordable. La Raspberry Pi a été choisie car moins intrusive comparé à un ordinateur, et bien moins cher.
-Ce projet est réalisé à l'aide de Unity (scripts en C#) pour programmé le casque Oculus Quest, couplé à des serveurs webs et TCP sur une Raspberry Pi, donnant l'accès à une page web de configuration pour l'utilisateur et renvoyant la configuration au Quest.
+Ce projet est réalisé à l'aide de Unity (scripts en C#) pour programmer le casque Oculus Quest, couplé à des serveurs webs et TCP sur une Raspberry Pi, donnant l'accès à une page web de configuration pour l'utilisateur et renvoyant la configuration au Quest.
 ==Calendrier prévisionnel==
@@ Ligne 107 : / Ligne 107 : @@
 La première consiste à déplacer librement les différents boutons composant la manette NES afin de pouvoir changer la difficulté de l'exercice en temps réel et pouvoir adapter l'exercice au plus de patients possibles.
 La seconde idée a pour but de faire marcher le patient, pour ceci nous avons pensé à faire bouger l'écran afin que le patient soit obligé de se déplacer pour pouvoir continuer à voir l'écran correctement. Cette fonctionnalité pose plusieurs problèmes, si nous faisons bouger l'écran et que le patient bouge, nous devons également faire bouger la manette NES matérialisée dans le casque. Cependant, faire bouger la manette NES sans aucune concordance avec les déplacements du patient rendrait l'utilisation de la manette très difficile. Nous avons donc décidé d'accrocher la manette NES à la caméra et ainsi toujours l'avoir devant les yeux. Le second problème vient du déplacement, si le patient se déplace avec le casque sur les yeux, il ne pourra pas voir les obstacles qui l'entoure. Pour cela, la seule solution est un bon paramétrage du guardian (zone de jeu, en dehors de cette zone de jeu le casque affiche l'entourage de l'utilisateur grâce aux caméras de l'Oculus) ou une surveillance des médecins. Pour ce second problème, nous pouvons limiter les risques d'accident en définissant les déplacements de l'écran et toujours le faire revenir à sa position initiale et donc faire des aller-retour.
-A la fin de cette réunion nous avons pu parler de ce qui était faisable dans notre temps imparti et avec l'équipe nous en avons déduit que la seconde fonctionnalité était trop longue à réaliser en intégralité avec le peu de temps que nous disposions et au vu de nos connaissances des différents langages de programmation et du projet. Cependant il serait bien que l'on en étudie la faisabilité pour les personnes qui continuerons de travailler sur le projet. Nous avons ainsi été assigner à la première fonctionnalité qui est la plus intéressante en termes d'interêt.
+A la fin de cette réunion nous avons pu parler de ce qui était faisable dans notre temps imparti et avec l'équipe nous en avons déduit que la seconde fonctionnalité était trop longue à réaliser en intégralité avec le peu de temps que nous disposions et au vu de nos connaissances des différents langages de programmation et du projet. Cependant il serait bien que l'on en étudie la faisabilité pour les personnes qui continuerons de travailler sur le projet. Nous avons ainsi été assignés à la première fonctionnalité qui est la plus intéressante en termes d'interêt.
 ===La première fonctionnalité===
@@ Ligne 140 : / Ligne 140 : @@
 	"oculusControllerOn": false
 }</nowiki>
-Elle récupère enfaite la position relative de chaque image sur la fenêtre. Sur Unity, les axes y et z sont inversés, c'est pour cela que la première fenêtre enverra les données en x et z dans le json, et la seconde en y. Cependant, les positions qui été enregistrées sont relatives aux pixels de la page web, et ne sont pas adapter au Quest qui prend des positions métriques (si x=1 alors la touche est placée à 1m à droite du joueur), en semaine 3 on établira rapidement l'équation pour les convertir.
+Elle récupère enfaite la position relative de chaque image sur la fenêtre. Sur Unity, les axes y et z sont inversés, c'est pour cela que la première fenêtre enverra les données en x et z dans le json, et la seconde en y. Cependant, les positions qui étaient enregistrées sont relatives aux pixels de la page web, et ne sont pas adaptées au Quest qui prend des positions métriques (si x=1 alors la touche est placée à 1m à droite du joueur), en semaine 3 on établira rapidement l'équation pour les convertir.
 =====Partie Unity=====
@@ Ligne 169 : / Ligne 169 : @@
 ====Partie web====
-On a considérée la zone de placement des touches avec les distances ci-contre:
+On a considéré la zone de placement des touches avec les distances ci-contre:
 *Axe x: -1.8 à 1.8m
 *Axe y: -0.8 à 0.8m
 *Axe z: -0.9 à 0.9m
-On a obtient ainsi, par exemple, la conversion pour l'axe x ci-dessous:
+On obtient ainsi, par exemple, la conversion pour l'axe x ci-dessous:
 <code>((coordonnees.x-(app.screen.width/2))/(app.screen.width/2))*1.8</code> (avec app.screen.width = longueur de la fenêtre)
-De cette manière, le Quest reçoit des coordonnéees adéquates, et peut positionné les touches sans problème. Maintenant que la première fenêtre à bien été mise en place, la seconde est réalisée de la même manière, seulement cette fois, les touches peuvent seulement être translatées sur l'axe y, et pas dans le plan commme sur la première fenêtre. On obtient ainsi les fenêtres suivantes:
+De cette manière, le Quest reçoit des coordonnéees adéquates, et peut positionner les touches sans problème. Maintenant que la première fenêtre à bien été mise en place, la seconde est réalisée de la même manière, seulement cette fois, les touches peuvent seulement être translatées sur l'axe y, et pas dans le plan commme sur la première fenêtre. On obtient ainsi les fenêtres suivantes:
 [[Fichier:Fenetre pageweb.png|center|600px|thumb|Fenêtres de placement libre des boutons]]
-On a également ajouté une checkbox similaire aux autres checkbox, pour activer/désactiver le placement libre. On avait un problème pour manipuler les fenêtres sur la page html, on a donc du créer un style CSS '''#frame''' et y lier les fenêtres, et ainsi on peut facilement les manipuler dans les div html.
+On a également ajouté une checkbox similaire aux autres checkbox, pour activer/désactiver le placement libre. On avait un problème pour manipuler les fenêtres sur la page html, on a donc dû créer un style CSS '''#frame''' et y lier les fenêtres, et ainsi on peut facilement les manipuler dans les div html.
 ===La seconde fonctionnalité===
@@ Ligne 206 : / Ligne 206 : @@
 ===La seconde fonctionnalité (suite)===
-La semaine dernière, nous avons pu voir que cette seconde fonctionnalité était faisable, il nous reste du temps donc nous allons pouvoir commencer son développement et l'implémenter dans le projet. Cette seconde fonctionnalité comporte deux parties, celle de la manette devant suivre le joueur et celle de l'écran devant bouger dans l'espace. Nous allons commencer par la partie la plus mathématiques, le suivi de la manette.
+La semaine dernière, nous avons pu voir que cette seconde fonctionnalité était faisable, il nous reste du temps donc nous allons pouvoir commencer son développement et l'implémenter dans le projet. Cette seconde fonctionnalité comporte deux parties, celle de la manette devant suivre le joueur et celle de l'écran devant bouger dans l'espace. Nous allons commencer par la partie la plus mathématique, le suivi de la manette.
 ====Suivi du Pad====
@@ Ligne 269 : / Ligne 269 : @@
 ====Interprétation des données====
-Maintenant que l'on a nos 6 variables indiquant tous les déplacements du mouvement, nous pouvons les interpréter et ainsi envoyer les commandes correspondantes au jeu (à la Raspberry). Nous avons alors les données du mouvement en cours assez détaillées, à partir de celé nous pouvons détecter tous les mouvements de type rectiligne. Ainsi nous avons créé une fonction prenant en comptes les 6 variables et vérifie qu'il y a eu assez de mouvement sur la variable passée dans la première entrée et que le reste des variables n'est pas trop élevé. Cela signifie que nous voulons un mouvement dans la direction désignée par la première variable sans qu'il y ai eu trop de perturbation dans les autres directions. Nous avons laissé la possibilité de modifier facilement les limites et d'ajouter des fonctions d'interprétations.
+Maintenant que l'on a nos 6 variables indiquant tous les déplacements du mouvement, nous pouvons les interpréter et ainsi envoyer les commandes correspondantes au jeu (à la Raspberry). Nous avons alors les données du mouvement en cours assez détaillées, à partir de cela nous pouvons détecter tous les mouvements de type rectiligne. Ainsi nous avons créé une fonction prenant en comptes les 6 variables et vérifie qu'il y a eu assez de mouvement sur la variable passée dans la première entrée et que le reste des variables n'est pas trop élevé. Cela signifie que nous voulons un mouvement dans la direction désignée par la première variable sans qu'il y ai eu trop de perturbation dans les autres directions. Nous avons laissé la possibilité de modifier facilement les limites et d'ajouter des fonctions d'interprétations.
 ====Les tests====

← Version précédente		Version du 19 février 2020 à 16:43
Ligne 304 :		Ligne 304 :

	=Documents Rendus=		=Documents Rendus=
		+
		+	Rapport : [[Fichier:RapportPFE_P18_Fdinatale_Ibendhiab.pdf]]
		+
		+	Présentation : [[Fichier:PresentationPFE_P18_Fdinatale_Ibendhiab.pdf]]

@@ Ligne 148 : / Ligne 148 : @@
 Une fois cela définit nous avons dû apprendre comment manipuler un fichier json en C#, récupérer les informations que l'on souhaite. Cela nous a pris quelque temps car avec le programme déjà en place nous avons pu voir comment récupérer les éléments basiques d'un fichier json et les traiter. Cependant le fait que nous aillons choisi d'avoir mis des objets json pour chaque bouton cela impliqué une nouvelle méthode de lecture car celle utilisée dans ce projet ne fonctionner pas. Nous avons remarqué que lors de l'appel à la fonction affichage, l'affichage se fait correctement mais lorsque nous essayons de manipuler les objets le compilateur nous produit des erreurs. Nous avons donc choisi de reproduire une partie de la fonction d'affichage, la partie cast nous permettant alors de manipuler les sous objets comme des strings pour pouvoir enfin récupérer les données qui nous ont été envoyées. Nous envoyons ensuite la configuration des boutons dans le casque.
-Afin que tous cela fonctionne nous avons dû modifier le fichier de configuration qui est l'une des pièces maîtresse du projet. Nous avons fait en sorte que cette fonction ne soit pas la prioritaire et que la fonction prioritaire soit la manette NES totalement prédéfinie.
+Afin que tout cela fonctionne nous avons dû modifier le fichier de configuration qui est l'une des pièces maîtresse du projet. Nous avons fait en sorte que cette fonction ne soit pas la prioritaire et que la fonction prioritaire soit la manette NES totalement prédéfinie.
 La modification du fichier de configuration n'a été faite qu'une fois le test fini c'est à dire que pour tester notre script nous l'avons rendu complétement indépendant avec une mise à jour lors d'une entrée clavier sur un fichier qui était directement stocké sur l'ordinateur. Le fait de travailler sous Unity avec un matériel de ce type et une dépendance à la Raspberry nous a obligé à nous adapter et découvrir de nouvelles fonctionnalités du logiciel Unity. Ainsi, après avoir testé tout cela au fur et à mesure grâce à Unity, nous avons pu tester cela avec la configuration venant directement de la Raspberry. (Ne pas oublier d'enlever tous ce qui a permis de faire les tests sur le simulateur de Unity et ajouter les liaisons avec le fichier de configuration.)

@@ Ligne 279 : / Ligne 279 : @@
 ====Partie web====
-De même que pour l'option de suivi, il fallait juste ajouter une checkbox pour activer/désactiver l'option ''Mouvement Libre''. On a aussi ajouté un moyen d'enregistrer des configurations de placement libre des touches, en leurs attribuant des ID, comme ça l'utilisateur peut rapidement charger le placement des touches cependant. Les ID sont stockés dans un fichier JSON '''layoutIDS.json''' qu'on peut facilement manipuler, et est appelé à chaque chargement de page pour pouvoir incrémenter un menu déroulant de sélection des IDs. Ce menu est également incrémenté dès qu'un nouvel ID est créé. Si l'utilisateur essaie de créer un ID avec un nom déjà existant, une alert s'affiche et indique que l'ID est déjà existant. Il est également impossible d'enregistrer un ID sans nom. La liste des IDs peut être réinitialisée à tout moment avec le bouton ''Reset layouts IDs list''.
+De même que pour l'option de suivi, il fallait juste ajouter une checkbox pour activer/désactiver l'option ''Mouvement Libre''. On a aussi ajouté un moyen d'enregistrer des configurations de placement libre des touches, en leurs attribuant des ID, comme ça l'utilisateur peut rapidement charger le placement des touches qu'il souhaite. Les ID sont stockés dans un fichier JSON '''layoutIDS.json''' qu'on peut facilement manipuler, et est appelé à chaque chargement de page pour pouvoir incrémenter un menu déroulant de sélection des IDs. Ce menu est également incrémenté dès qu'un nouvel ID est créé. Si l'utilisateur essaie de créer un ID avec un nom déjà existant, une alert s'affiche et indique que l'ID est déjà existant. Il est également impossible d'enregistrer un ID sans nom. La liste des IDs peut être réinitialisée à tout moment avec le bouton ''Reset layouts IDs list''.
 On a décidé de peaufiner la page pour rendre l'interface utilisateur plus pertinente, notamment en chargeant la dernière configuration envoyée au casque dès l'ouverture de la page, pour que l'utilisateur sache la configuration actuellement dans le casque, c'est à dire que les checkbox seront cochées ou non, et le dernier layout ID affiché sera le dernier envoyé. On a aussi fait en sorte de cacher la partie ''placement libre'' lorsque la checkbox est décochée, pour être moins intrusive et rendre l'interface plus agréable.

@@ Ligne 7 : / Ligne 7 : @@
 Encadrant : Laurent Grisoni & Valentin Beauchamp
 ==Description==
-L'équipe de recherche MINT, dans le cadre d'un projet européen intitulé VR4REHAB, travaille sur un dispositif combinant réalité virtuelle et "serious gaming", et qui a pour but d'aider à la rééducation des personnes handicapées. L'utilisateur pourra jouer à des jeux rétros tel que Tetris ou encore Bomberman, et bien d'autre. Pour cela, ils ont installé le système d'exploitation RetroPie sur une Raspberry Pi qui permet d'émuler des jeux rétro, la Raspberry envoie ensuite le flux vidéo du jeu par wifi au casque VR.
+L'équipe de recherche MINT, dans le cadre d'un projet européen intitulé VR4REHAB, travaille sur un dispositif combinant réalité virtuelle et "serious gaming", et qui a pour but d'aider à la rééducation des personnes atteintes d’un handicap ou d’une incapacité physique. L'utilisateur pourra jouer à des jeux rétros tel que Tetris ou encore Bomberman, et bien d'autre. Pour cela, ils ont installé le système d'exploitation RetroPie sur une Raspberry Pi qui permet d'émuler des jeux rétro, la Raspberry envoie ensuite le flux vidéo du jeu par wifi au casque de réalité virtuelle Oculus Quest.
 ==Objectifs==

@@ Ligne 283 : / Ligne 283 : @@
 On a décidé de peaufiner la page pour rendre l'interface utilisateur plus pertinente, notamment en chargeant la dernière configuration envoyée au casque dès l'ouverture de la page, pour que l'utilisateur sache la configuration actuellement dans le casque, c'est à dire que les checkbox seront cochées ou non, et le dernier layout ID affiché sera le dernier envoyé. On a aussi fait en sorte de cacher la partie ''placement libre'' lorsque la checkbox est décochée, pour être moins intrusive et rendre l'interface plus agréable.
-[[File:Conf page finale.png|center|thumb|600px|Aperçu page web finale]]
+[[File:Conf page finale.png|center|thumb|600px|Aperçu page web finale (les canvas sont en dessous du bouton Reset Layout)]]
 ==Semaine 6==

@@ Ligne 287 : / Ligne 287 : @@
 ==Semaine 6==
-Maintenant que les deux fonctionnalités sont terminées et que nous avons fini le contrôle par le mouvement des manettes nous avons effectué beaucoup de test et de combinaison afin de chercher les bugs qui pourrait survenir. On a réglé les différentes fonctionnalités afin qu'elles s'exécutent proprement et que l'on puisse changer de fonctionnalité sans bug et sans devoir relancer l'application. <br><br>
+Maintenant que les deux fonctionnalités sont terminées et que nous avons fini le contrôle par le mouvement des manettes, nous avons effectué beaucoup de tests et de combinaisons afin de chercher les bugs qui pourraient survenir. On a réglé les différentes fonctionnalités afin qu'elles s'exécutent proprement et que l'on puisse changer de fonctionnalité sans bug et sans devoir relancer l'application.
-Suite à tous ces tests nous sommes satisfaits de notre travail et de son bon fonctionnement. La plupart de notre travaille a été fait dans des nouveaux scripts et nouveaux fichiers afin de ne pas gêner le projet et afin de rendre notre travail le plus facilement réutilisable par la suite.
+Un bug rendait impossible l'accés à la seconde fonctionnalité ou son lancement était approximatif et l'écran passait derrière le mur. Ce problème venait de la configuration qui oubliait d'activer le gamepad utilisé dans cette fonctionnalité et désactivait le mur. Une fois cela fait nous avons remarqué que nous ne pouvions plus sortir de cette fonctionnalité. Nous avons fini par remarquer une erreur dans notre configuration une nouvelle fois, cette fois-ci la partie de désactivation n'était pas atteinte à cause d'un certain enchaînement de commande. Nous avons donc réglé cela ainsi que la fonction de fin de suivi où nous avons oublié de rétablir les positions initiales des boutons.
-Sur demande de notre tuteur nous arrêtons de développer et d'améliorer ce que l'on a fait pour combiner notre travaille avec le travaille qu'il a effectué sur le projet pendant ces 6 semaines. Cependant avec le développement nous avons pu envisager plusieurs nouvelles fonctionnalités à implémenter pour le futur du projet VR4REHAB.
+Sur demande de notre tuteur, nous avons arrêté de développer le projet pour combiner notre travail avec celui réalisé par notre tuteur ainsi que François Brassart. Cependant avec le développement nous avons pu envisager plusieurs nouvelles fonctionnalités à implémenter pour le futur du projet VR4REHAB.
 ===Améliorations potentielles===
-Pour la seconde fonctionnalité, nous pouvons créer une fonction permettant de faire bouger l'écran selon un paterne prédéfini ou configuré par le médecin avec la manette. Ce qui pourrait être imaginé c'est que le médecin prenne une des manettes de l'oculus pour définir le déplacement que l'écran devra faire en appuyant sur un bouton. Le script aurait à transformer les positions en une liste de vecteur puis faire bouger l'écran soit en faisant des aller-retours ou des boucles selon si le déplacement fait par le médecin commence en un point et fini au même point ou pas. Ainsi pour cela il faudrait une fonction pour traduire les positions en une liste de vecteurs, ceci peut s'appuyer sur la normalisation et le filtre utilisé dans le script de détection de mouvement. Il faudrait ensuite une fonction prenant une liste de vecteur et une vitesse afin de déplacer l'écran, ceci peut s'appuyer sur la fonction permettant déjà de bouger l'écran avec un flag permettant de dire si on fait des aller-retours ou des boucles et une variable globale permettant de se déplacer dans la liste.<br>
+Pour la première fonctionnalité, nous pouvons l'améliorer en ajoutant une option permettant de choisir la taille de chaque bouton en plus de leur position. De plus, un script que nous n'avons pas utilisé durant notre PFE est déjà présent à cet effet dans le projet. Cette option pourrait être ajoutée par la suite selon les envies du client ou de notre tuteur. Cependant, cela pourrait rendre la configuration trop lourde pour un médecin et donc faire perdre trop de temps, il faudrait donc voir avec eux.
-Pour la gestion des mouvements, il y a le problème du filtre à régler pour commencer. Ensuite notre code laisse la possibilité de différencier les deux manettes grâce à une variable nommée ''main'' ce qui pourrait mener à quelques optimisations ou améliorations selon les envies du tuteur ou les demandes des médecins. De plus nous pouvons imaginer de nouvelles détections de mouvement plus complexe que de simple mouvement rectiligne que nous avons pu implémenter la semaine dernière. Pour cela nous pouvons imaginer une fonction connaissant tous les mouvements implémenter, prenant le mouvement en cours du joueur et éliminant les différentes possibilités de correspondance jusqu'à ce que la correspondance soit parfaite avec un des mouvements implémenté. Ceci permettrait d'éliminer le problème de ne pas avoir assez de mouvement implémenter pour y faire correspondre les 8 boutons de la manette NES nécessaire pour jouer.
+Pour la seconde fonctionnalité, nous pouvons créer une fonction permettant de faire bouger l'écran selon un motif prédéfini ou configuré par le médecin avec la manette. Ce qui pourrait être imaginé c'est que le médecin prenne un des contrôlleur du Quest pour définir le déplacement que l'écran devra faire en appuyant sur un bouton. Le script aurait à transformer les positions en une liste de vecteurs puis faire bouger l'écran soit en faisant des aller-retours ou des boucles selon si le déplacement fait par le médecin commence en un point et fini au même point ou pas. Ainsi il faudrait une fonction pour traduire les positions en une liste de vecteurs, pour cela on peut s'appuyer sur la normalisation et le filtre utilisé dans le script de détection de mouvement. Il faudrait ensuite une fonction prenant une liste de vecteur et une vitesse afin de déplacer l'écran, ici on peut s'appuyer sur la fonction permettant déjà de bouger l'écran avec un flag permettant d'indiquer si on fait des aller-retours ou des boucles et une variable globale permettant de se déplacer dans la liste.
-Une autre amélioration est possible avec la détection de mouvement, c'est le fait d'appuyer sur un bouton afin qu'une fois le mouvement détecter le jeu considère que l'on reste appuyer sur le bouton permettant ainsi de maintenir un bouton enfoncer. Ce qui est impossible à faire sur plus de quelques secondes avec la détection des mouvements normale car lorsque nous arrêtons de bouger notre main avec la manette nous tremblons, le joueur ne sait pas garder sa main stable, le script considère alors le début d'un nouveau mouvement et envoie la commande de fin de mouvement. De plus la détection peut créer une erreur infime mais suffisante pour que le vecteur créé ne corresponde pas au mouvement précédent. Ainsi le script considère que nous avons commencé un nouveau mouvement et enverra la commande fin de mouvement.
 =Documents Rendus=

@@ Ligne 272 : / Ligne 272 : @@
 ====Les tests====
-Tous ceci est le résultat de beaucoup de test nous ayant permis de régler les variables de changement afin de plus facilement délimiter les mouvements, régler les limites d'interprétations afin d'éviter de faire des gestes trop amples. De plus, ces tests nous on permit de nous rendre compte du troisième problème de traitement des données. Au début, nous n'avions pas pensé à ajouter un filtre mais avec les tests et le fait que les utilisateurs seront des personnes en rééducation donc des personnes n'ayant pas pleinement la possibilité de faire des gestes droits, l'utilisation d'un filtre était nécessaire. Cependant l'utilisation de ce filtre entraine un lissage des positions et donc rend notre protection contre les sauts, c'est à dire entre la fin d'un mouvement et le début du suivant, lorsqu'on lâche la gâchette de la manette à un certain endroit et que nous bougeons la manette pour commencer un autre mouvement.////////////////////////
+Tous ceci est le résultat de beaucoup de test nous ayant permis de régler les variables de changement afin de plus facilement délimiter les mouvements, régler les limites d'interprétations afin d'éviter de faire des gestes trop amples. De plus, ces tests nous on permit de nous rendre compte du troisième problème de traitement des données. Au début, nous n'avions pas pensé à ajouter un filtre mais avec les tests et le fait que les utilisateurs seront des personnes en rééducation donc des personnes n'ayant pas pleinement la possibilité de faire des gestes droits, l'utilisation d'un filtre était nécessaire.
 La troisième problématique est de nouveau d'actualité, nous avons donc étudié plus en profondeur le code du filtre 1€ développé par Cristal afin de trouver une solution pour régler ce problème et ainsi réinitialiser le filtre lorsque le mouvement est trop grand. Cependant, après plusieurs tests, nous ne sommes pas arrivés à résoudre ce problème de cette façon. De plus, le temps nous manque et le filtre ne comporte pas de fonction de destruction, nous supposons alors que le garbage collector fonctionne correctement sur le filtre. Avec cette supposition, nous avons créé alors un nouveau filtre dès que la gâchette est relâchée mais ceci pourrait créer une perte de mémoire donc pas optimale, ceci aura besoin d'être modifié par la suite.