IMA4 2016/2017 P18 : Différence entre versions

De Wiki de Projets IMA
(→‎Semaine 2)
 
(143 révisions intermédiaires par 3 utilisateurs non affichées)
Ligne 7 : Ligne 7 :
 
L’évolution de l'informatique a engendré une modification de la place du salarié dans l'entreprise. Ainsi, nombreux sont ceux qui travaillent dans un bureau face à un ordinateur. De ce fait, il a été remarqué par une association de la santé que les maux de dos sont en majorité dus à une mauvaise hygiène de vie notamment liée à une mauvaise posture au travail.
 
L’évolution de l'informatique a engendré une modification de la place du salarié dans l'entreprise. Ainsi, nombreux sont ceux qui travaillent dans un bureau face à un ordinateur. De ce fait, il a été remarqué par une association de la santé que les maux de dos sont en majorité dus à une mauvaise hygiène de vie notamment liée à une mauvaise posture au travail.
 
   
 
   
−
C'est après différentes études, notamment un bilan postural montrant où se situe la tête par rapport à une position idéale que l'on a remarqué que ces dernières années, 50% des personnes ayant des maux de dos sont en réalité dus au cervicale contre 20 % seulement il y a une dizaine d’année.
+
C'est après différentes études, notamment un bilan postural montrant où se situe la tête par rapport à une position idéale que l'on a remarqué que ces dernières années, 50% des personnes ayant des maux de dos sont en réalité dûs aux cervicales contre 20 % seulement il y a une dizaine d’années.
 
   
 
   
−
C'est après ce constat qu'il nous a été proposé de réaliser ce projet ayant pour but de faciliter aux kinésithérapeutes la rééducation de la position de la tête des patients se plaignants de leur dos.
+
Du constat précédent découle ce projet ayant pour but de faciliter aux kinésithérapeutes la rééducation de la position de la tête des patients se plaignants de leur dos.
  
 
=== Description du projet ===
 
=== Description du projet ===
Ligne 15 : Ligne 15 :
 
La rééducation de la posture de la tête chez un kinésithérapeute pourrait être améliorée si le travail pouvait se faire en autonomie.
 
La rééducation de la posture de la tête chez un kinésithérapeute pourrait être améliorée si le travail pouvait se faire en autonomie.
 
   
 
   
−
Ce projet propose de réaliser un système de suivi de la position de la tête d'un patient en rééducation grâce à un monitoring continu de la position de la tête, ainsi qu'un mécanisme pour aider le patient à reprendre une position correcte. En effet on lancera le système pendant environs 30 min durant lesquelles nous détecterons les variations de position et indiquerons au patients le moment ou sa position n’est plus bonne.
+
Ce projet propose de réaliser un système de suivi de la position de la tête d'un patient en rééducation grâce à un monitoring continu de la position de la tête, ainsi qu'un mécanisme pour aider le patient à reprendre une position correcte. En effet on lancera le système pendant environ 30 min durant lesquelles nous détecterons les variations de position et indiquerons au patient le moment ou sa position n’est plus bonne.
 
   
 
   
 
Ce projet devra ainsi comparer la position actuelle de la tête du patient à une position idéale (celle de la verticale) et lui signaler s’il doit ou non ajuster sa position.
 
Ce projet devra ainsi comparer la position actuelle de la tête du patient à une position idéale (celle de la verticale) et lui signaler s’il doit ou non ajuster sa position.
−
+
 
 
=== Choix techniques : matériel et logiciels ===
 
=== Choix techniques : matériel et logiciels ===
 
   
 
   
−
Nous avons choisi d’utiliser des accéléromètres afin de pouvoir récupérer des données décrivant la position de la tête. Avec un microprocesseur ATMEGA, nous pourrons utiliser 5 capteurs (5*3 entrées analogiques = 15 entrées pour ATMEGA à 16 entrées).
+
Nous avons choisi d’utiliser des accéléromètres afin de pouvoir récupérer des données décrivant la position de la tête. Les accéléromètres nous permettent de calculer l'angle d'inclinaison à partir de la force gravitationnelle qu'ils peuvent mesurer selon les trois axes. Lorsque la position idéale du patient sera choisie par le médecin, nous pourrons enregistrer cette position en mémorisant l'inclinaison de chaque accéléromètre pour cette position. Ainsi un changement de position sera identifié par une variation des angles d'inclinaison précédemment pris. Nous allons utilisé les accéléromètres analogiques de type adxl335. Une fois que nous aurons à disposition les valeurs de l'accéléromètre et, par conséquent les angles d'inclinaison, nous aurons besoin d'un moyen d'affichage des ces données. Pour ce faire, nous avons opté dans un premier temps pour une affichage sur smartphone. Les données vont être envoyées au smartphone à travers un module WIFI connectés au même réseau que le smartphone. En récapitulant, nous aurons finalement besoin de:
−
 
+
* 5 accéléromètres adxl335.
 +
* un arduino Mega
 +
* un module WIFI
 +
* des fils pour la liaison.
  
 
===Calendrier prévisionnel===
 
===Calendrier prévisionnel===
  
 
====Liste des tâches à effectuer====
 
====Liste des tâches à effectuer====
−
étude des accéléromètres
+
Etude et choix des accéléromètres
−
*fonctionnement  
+
*fonctionnement : accéléromètres à sortie analogique. Nous aurons donc besoin de 3 sorties analogiques par capteur (donc 3*5 sorties analogiques)
−
*type de data collecté
+
 
−
prise en main de la carte ATMEGA et des accéléromètres
+
*type de données collectées: force gravitationnelle selon les trois axes qu'il faudra transformer de telle sorte à avoir l'inclinaison de l'accéléromètre par rapport à l'axe x, y et z
−
*lien entre les ATMEGA et les capteurs
+
 
−
*mise en oeuvre du programme d'acquisition  
+
 
−
réalisation d'un prototype
+
 
−
  *réalisation du premier prototype avec l’étude de la position au niveau des cervicales
+
*mise en œuvre du programme d'acquisition.
−
acquisition de la position idéale grâce à notre système
+
 
−
*réaliser une commande à partir de données récupérées de la position idéale
+
Moyen d'affichage des résultats
−
réaliser le système d'alerte (en cas de mauvaise position )
+
 
−
*...
+
*si position correcte par rapport à celle idéale ;
 +
*envoi des résultats sur un smartphone.
 +
 
 +
Réalisation d'un prototype  
 +
   
 +
*identification et acquisition de la position idéale à l'aide des accéléromètres placées le long de la colonne vertébrale;
 +
*notification au patient (à travers le smartphone) lorsqu'une position différente de celle idéale a été détectée.
  
 
====Calendrier====
 
====Calendrier====
 +
==tâches à réaliser==
 +
 +
{| class="wikitable"
 +
!Tâche !! Avancement !! Commentaires
 +
|-
 +
| acquisition des données 10DOF
 +
| <font style="color: green;">Terminé</font>
 +
|
 +
|-
 +
| connexion au WIFI (esp9266)
 +
| <font style="color: green;">Terminé</font>
 +
| connexion à un wifi standard prédéfinit lors de la programmation
 +
|-
 +
| pages application smartphone
 +
| <font style="color: green;">Terminé</font>
 +
| 
 +
|-
 +
| envois et réception de données sur smartphone
 +
| <font style="color: green;">Terminé</font>
 +
| terminé et testé
 +
|-
 +
| acquisition des données de l'accéléromètre avec l'arduino mini
 +
| <font style="color: green;">Terminé</font>
 +
| donnée récupérer à partir de 2 accéléromètre mais on peut en ajouter plus
 +
|-
 +
| liaison série arduino mini et esp8266
 +
| <font style="color: orange;">testé</font>
 +
| Communication réalisé mais quelque amélioration à faire, il faut optimiser le code
 +
|-
 +
| mise en commun de la partie wifi et acquisition de données
 +
| <font style="color: orange;">Inachevé</font>
 +
| la mise en commun pose quelque problème notamment la réception de donnée non cohérente par le smartphone
 +
|}
  
 
==Feuille d'heures==
 
==Feuille d'heures==
  
 
{| class="wikitable"
 
{| class="wikitable"
−
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Total
+
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 + Heures supplémentairements !! Total
 
|-
 
|-
 
| Définition cahier des charges  
 
| Définition cahier des charges  
−
| 0
+
| 2H
 +
|
 +
| 8H
 +
|
 +
|
 +
|
 +
|
 +
|
 +
|
 +
|
 +
|
 +
|
 +
|-
 +
| documentation
 +
| 2h
 +
| 4h
 +
|
 +
|
 +
|
 +
|
 +
|
 +
|
 +
|
 +
| 4h
 +
|
 +
|
 +
|-
 +
| liste du matériel
 +
|
 +
| 2h
 +
| 6h
 +
|
 +
|
 +
|
 +
|
 +
|
 +
|
 +
|
 +
|
 +
|
 +
|-
 +
| étude du module Wi-fi
 +
|
 +
|
 +
|
 +
| 8H
 +
| 2H
 +
| 4H
 +
|
 +
|
 +
|
 +
| 12h
 +
|
 +
|
 +
|-
 +
| étude, programmation, câblage du 10 DOF
 +
|
 +
|
 +
|
 +
| 4H
 +
| 8H
 +
|
 +
|
 +
|
 +
|
 +
|
 +
|
 +
|
 +
|-
 +
| Accéléromètre
 +
|
 +
|
 +
|
 +
|
 +
|
 +
| 2H
 +
| étude 3H
 +
|
 +
| schématique 2H
 +
| 12h
 +
|
 +
|
 +
|-
 +
| liaison arduino esp
 +
|
 +
|
 +
|
 +
|
 +
|
 +
|
 +
|
 +
|
 +
|
 +
|
 +
| 16H
 +
|
 +
|-
 +
| étude et programmation arduino mini
 +
|
 +
|
 
|  
 
|  
 
|
 
|
Ligne 56 : Ligne 197 :
 
|
 
|
 
|
 
|
 +
|
 +
| 16H
 +
|
 +
|-
 +
| application mobile
 +
|
 +
|
 +
|
 
|
 
|
 
|
 
|
 +
|2H
 +
|4H
 +
|4H
 
|
 
|
 +
|10h
 +
|10H
 
|
 
|
 
|}
 
|}
Ligne 65 : Ligne 219 :
  
 
===Semaine 1===
 
===Semaine 1===
 +
 +
Nous avons été confronté à différents choix matériel notamment dans la référence des accéléromètres ou encore le moyen de transmission des données.
 +
 +
L'accéléromètre doit être assez précis pour des petites variations de position. Après avoir parcouru les catalogues de fournisseurs nous avons trouvé le ADXL335.
 +
 +
De plus, nous devions choisir le mode de transmission des données vers un smartphone. Nous avions le choix entre un module Bluetooth et un module wifi. Le module Bluetooth est plus rapide que le module bluetooth. Cependant, ce dernier ne consomme pas beaucoup de charge de la batterie du smartphone mais il fonctionne  essentiellement sur de petites distances et avec des données de petite taille. En revanche le module WIFI lui consomme beaucoup plus de batterie mais couvre des distances beaucoup plus grandes ainsi que des tailles de données beaucoup plus importantes.
 +
 +
Finalement, nous avons opté pour le module WIFI pour limiter le moins possible l'utilisateur en ce qui concerne la distance entre les appareils et le volume de données transmis.
 +
 +
*Confirmation de la liste de matériel:
 +
**accéléromètre ADXL335
 +
**Smartphone sous Android
 +
**15 longs fils mâle-femelle, mâle-mâle
 +
**Arduino pro -mini
 +
**Module WIFI
 +
 +
===Semaine 2===
 +
 +
Réalisation d'un cahier des charges fonctionnelles avec les outils de gestions de projet telle que le FAST, la bête à cornes, SADT.
 +
[https://docs.google.com/document/d/1e6291kst6O6Ic0IWnadg5l10HiiZeqsw72GxfXC7O7U/edit cahier des charges fonctionnels]
 +
 +
[[Fichier:cad1_1.PNG| 900px ]]
 +
[[Fichier:cad1.PNG| 900px ]]
 +
 +
===Semaine 3===
 +
 +
En début de semaine, nous avons reçus un premier capteur, l’accéléromètre 10 DOF, ainsi que l'arduino MEGA qui sera utilisé pour l’acquisition des données. L'accéléromètre 10DOF incorpore un gyroscope et un magnétomètre. Ceux-ci nous permettront d'avoir une meilleure précision des mesures notamment avec la mesure des orientations (vitesses angulaires).
 +
 +
Nous avons ensuite étudié le capteur et réalisé le premier montage en connectant ce capteur de manière à pouvoir lire les données récupérées en direct sur l'ordinateur.
 +
 +
[[Fichier:10dof.PNG| 400px ]]
 +
 +
Nous nous sommes également intéressé au calcule de l'angle à partir de l’accélération.
 +
Prenons l'exemple de l’accéléromètre penché de la manière suivante.
 +
 +
[[Fichier:exemple5.PNG| 400px ]]
 +
 +
Le triangle G,Gx Gz forme un triangle rectangle, dans notre cas nous avons Gx,Gy et Gz qui sont les valeurs du vecteur gravitationnel G sur les trois axes et nous devons déduire 𝝰 (l’angle que fait Gx avec l’axe x), 𝝋 (l’angle que fait Gy avec l’axe y) et ᴪ (l’angle que fait Gz avec l’axe z). La norme de G est
 +
[[Fichier:Norme2.PNG| 200px ]]
 +
On récupére ensuite chaque angle de la manière suivante:
 +
[[Fichier:Calcule_angle.PNG| 200px ]]
 +
 +
Nous avons ensuite réalisé un premier programme afin de lire les données du 10DOF que nous testerons la semaine suivante.
 +
 +
===Semaine 4===
 +
 +
Nous avons débuté le traitement des données directement sur le MEGA en réalisant de code de récupération de l'angle réalisé par l'accéléromètre.( Dans le code suivant nous avons uniquement l'acquisition des données)
 +
 +
[[Fichier:10dof_code.PNG| 200px ]]
 +
 +
Nous nous sommes rendus compte que les calculs ne sont pas réalisés correctement par le MEGA. En effet la mesure de l'angle n'était pas précis car le MEGA n'a pas assez de puissance de calcul pour faire les différentes divisions. 
 +
 +
[[Fichier:Exempleaccelero.PNG| 100px ]]
 +
 +
Nous avons donc décidé que le MEGA servira uniquement à récupérer les données et à les envoyer via module WIFI. Ce sera donc à l'application Android d'effectuer le traitement des données.
 +
 +
Nous avons ensuite étudié le module WIFI ESP8266 que nous utiliserons, afin de nous faire une idée de son utilisation.
 +
 +
Nous avons également installé les logiciels nécessaires ( Android studio,... )
 +
 +
===Semaine 5===
 +
 +
Nous nous sommes intéressées  au module wifi, en commençant par lire la fiche technique de l'esp 8266, nous avons également cherché les différents types d'exemples .
 +
 +
Des recherches sur le mode de connexion entre le smartphone et le Mega à travers le module WIFI ont également été effectuer dans le but de se faire une idée, nous hésitons sur l'utilisation de Sockets UDP , ou de réaliser une transmission en TCP .
 +
 +
Le programme réalisée lors de la séance précédente a été testé, notamment les tests de récupération des données de l'accéléromètre 10-DOF sur le Mega.
 +
 +
Le code pour les autres accéléromètres en attendant la livraison de l'ADXL335 a également été entamé.
 +
 +
Nous avons également rencontré un certain nombre de problème :
 +
 +
Afin se connecter en WIFI à partir de n’importe où, nous avons décidé de se connecter premièrement à un réseau standard (point d'accès fourni par le smartphone dans un premier temps) puis de modifier le réseau sur lequel nous sommes connecté à partir du smartphone. Ce dernier enverra le SSID et le mot de passe du nouveau réseau souhaité au module et on  modifiera le paramètre de  cette manière.
 +
[[Fichier:connection.PNG| 500px ]]
 +
 +
La possibilité et l'utilité de l'ajout de l'acquisition des données du gyroscope pour avoir plus de précision sur l'accéléromètre 10-DOF qui sera sur la tête ( gérer les rotations).
 +
 +
 +
 +
En parallèle, nous avons également avancé avec la création d'une application android pour la réception et l'affichage de données.
 +
Nous avons décidé de:
 +
* faire une page d'accueil dans laquelle le kinésithérapeute devra appuyer sur un bouton lorsqu'il aura bien positionné le patient pour enregistrer la bonne position.
 +
* à l'appui du bouton, le smartphone va contacter le module WIFI à travers un message broadcast (en utilisant une communication UDP) dans le réseau.
 +
* Le MODULE WIFI, qui est déjà en attente d'une trame venant du smartphone, reçoit le message broadcast, extrait l'adresse IP du smartphone, puis, lui envoie des données du capteur.
 +
* le smartphone, à son tour va utiliser ces données pour calculer les angles d'inclinaison sur les différents axes et les afficher. Notons que les premiers angles calculés sont ceux correspondant à la bonne position.
 +
* A intervalle régulier, le module ESP va envoyer de nouvelles données que le smartphone va traiter et comparer avec les angles de la bonne position et prévenir le patient si la position a changer.
 +
 +
[[Fichier:transmition.PNG| 600px ]]
 +
 +
===Semaine 6===
 +
* Réception du matériel
 +
 +
[[Fichier:ADXL345.PNG| 100px ]]
 +
 +
Nous avons commencé par étudier l'accéléromètre reçu, en effet la référence de ce dernier est ADXL345 et est digital à l’inverse de celui choisi qui était analogique. De ce fait, nous avons modifié une partie du cahier des charges.
 +
 +
Les accéléromètres adxl345 sont alimentés en 3.3V et sont digitaux. Par conséquent, nous n'aurons plus besoin de sortie analogique. 
 +
 +
*fonctionnement : accéléromètres digitaux pouvant fonctionner en SPI comme en I2C et supportant 3.3V. Résolution: 10 bits, régler en mode +/-2g. Donc les valeurs de notre registre de données seront dans la plage [-512 ,512]. Mais puisque nous ne mesurons que la force gravitationnelle, nous aurons des valeurs comprises entre [-256,256] qui est la plage correspondant à -/1g. 1g correspond à la valeur de 9.80m/s2.
 +
 +
*type de données collectées: des entiers de -512 à 512 qu'il faudra transformer de telle sorte à avoir l'inclinaison de l'accéléromètre selon l'axe x, y et z
 +
 +
L'établissement des activités nécessairement et documentation sur le choix des sockets à utiliser pour l'envoi des données a également été entamé.
 +
 +
Coté Smartphone:
 +
 +
*Créations de la page d'accueil et de la page de visualisation des angles d'inclinaisons
 +
 +
===Semaine 7===
 +
 +
Nous avons réalisé l'étude de l'accéléromètre digital, nous avons choisis de travailler avec le mode SPI qui consiste à donner la parole à chaque accéléromètre l'un après l'autre en alimentant chaque pin CS l'un après l'autre. ( Le mode SPI utilise les ports digitaux )
 +
 +
Seulement les pins de l’accéléromètre n'acceptent que des tensions de 3.3V alors que ceux du Mega fournissent des tensions de 5v. Nous aurons donc besoin d'un mécanisme de régulation des tensions en sortie de Mega.
 +
 +
Nous nous sommes alors documenté sur les circuits de régulations et conversions de tension. Nous devons réaliser un dispositif de préférence réversible qui fourni une tension de 3.3v en sortie lorsqu'on lui injecte une tension de 5v en entré.
 +
 +
Les premières connections à partir se l'esp8266. Nous nous sommes donc connecté à notre téléphone utilisé comme point d’accès.
 +
 +
[[Fichier:espconnect.PNG| 300px ]]
 +
 +
===Semaine 8===
 +
Nous avons réalisé une carte électronique grâce au logiciel fritzing pour réaliser l’adaptation de tensions entre l’accéléromètre adxl345 et la carte MEGA. En effet l'accéléromètre supporte des tensions maximales de 3.3V alors que le MEGA donne en sortie 5V.
 +
 +
[[Fichier:carte_elec1.PNG| 400px ]]
 +
 +
Coté Smartphone:
 +
 +
* création de la page d'accueil avec implémentation du code pour la communication UDP entre le smartphone et l'ESP8266.
 +
 +
[[Fichier:page_daccueil.jpg | 200px]]
 +
 +
Nous avons également commencé la transmission de donnée avec le smartphone en fixant des valeur à envoyer.
 +
Dans la photo suivante, on peut voir l'esp connecté et attendant le message venant du smartphone.
 +
 +
[[Fichier:wifi_conect.png | 300px]]
 +
 +
===Semaine 9===
 +
 +
Nous avons testé la carte électronique faite la semaine précédente.
 +
 +
[[Fichier:carte_elec2.PNG| 200px ]]
 +
 +
Afin de tester la carte, nous avons alimenter les pins d’entrée par des 5v et avons observé la sortie du circuit. Malheureusement, seulement un pin en sortie
 +
fournissait une tension de 3.3V.
 +
Elle ne fonctionne pas et nous n'avons pas pu comprendre pourquoi.
 +
 +
Par conséquent, nous avons changé de microcontrôleur. Nous avons reçu un arduino pro mini 3.3V compatible avec nos capteurs ( mais qui ne l'est pas avec le 10DOF ).
 +
Nous commençons par conséquent à recueillir les données du capteurs. Pour cela, nous avons utilisé une librairie pour les ADXL345.
 +
La première étape est de sélectionner le chip Select en définissant un ADXL grâce à la fonction suivante:
 +
[[Fichier:def_adxl.PNG| 200px ]]
 +
Cette fonction prend en paramètre le pin lié au chip Select de accéléromètre.
 +
 +
Ensuite on récupère les données grâce à la fonction readaccel comme suit:
 +
[[Fichier:readaccel.PNG| 200px ]]
 +
La fonction stocke alors les valeurs lues par l'accéléromètre dans x,y et z.
 +
 +
code :
 +
[[Fichier:codemini1.PNG| 400px ]]
 +
 +
[[Fichier:codemini2.PNG| 600px ]]
 +
 +
Nous réalisons ensuite le montage suivant de manière à pouvoir lire sur le port série les valeurs .
 +
 +
[[Fichier:montageaccel.PNG| 600px ]]
 +
 +
 +
Partie smartphone:
 +
succès de la connexion au wi-fi partagé d'un smartphone. Coté ESP comme coté smartphone.
 +
 +
[[Fichier:affichage_valeur.jpg | 200px]]
 +
 +
===Semaine 10===
 +
 +
'''Etude de la partie communication entre l'arduino pro mini et l'ESP8266 pour l'envoie des données du capteur'''
 +
 +
Nous avons implémenté le module Wifi de manière à ce que l’on puisse recevoir les données des accélérations reçus par l’arduino mini.7
 +
 +
Pour cela, nous avons utilisée la bibliothèque SoftwareSerial d’arduino et avons défini deux liaisons série (l'une du côté du mini et l’autre du coté esp).Le mini envois un “a” indiquant à l'esp qu'il commence à envoyer une série de données.Ensuite on ramène les valeurs de l'accéléromètre sur l'échelle de g (gravitation terrestre ) grâce à un produit en croix . Pour finir, nous envoyons les données grâce à un serial write qui écrit sur les pins de l’esp ( pin 14 RX et 12 TX).
 +
 +
Du côté de l’esp, on définit une liaison du nom de swSer au même baudrate que la précédente (9600). On attend la réception de 72 ( l'équivalent de ‘a’ en integer) indiquant que l’on commence à transmettre des données de l'accéléromètre. Une fois ce nombre reçu on incrémente un compteur à chaque réception d’un chiffre et à partir de la valeur de ce compteur nous plaçons la donnée dans la variable qui la définit ( la première donnée est celle de x1 donc si compteur est à 1 on place la valeur lue par swSer.read dans la variable x1 )
 +
 +
'''Mise en commun de la partie Wifi et arduino mini'''
 +
 +
L’union de ces deux partie n'est pas un succès dans le sens ou bien que la connexion aboutit, les donnée qui sont envoyé au smartphone ne sont pas celle envoyé par le mini. Il se pourrait qu'il y ai un problème dans le software serial mis en place entre les deux éléments. Pour résoudre ce problème il faudrait optimiser le code au maximum en enlevant tous ce qui pourrait paraître excédent.
 +
 +
===Fichiers rendus===
 +
 +
Rapport de projet : [[Fichier:Rapport_Fahem_Diop.pdf]]
 +
 +
Code de la partie smartphone: [https://archives.plil.fr/mdiop/ima4_position_de_la_tete/tree/master/clientServerEspApp]
 +
 +
Code de la partie arduino : [https://archives.plil.fr/mdiop/ima4_position_de_la_tete/blob/master/minipro.ino]
 +
 +
Code de la partie esp: [https://archives.plil.fr/mdiop/ima4_position_de_la_tete/blob/master/espfinal21.ino]

Version actuelle datée du 15 juin 2017 à 06:19

Présentation générale du projet

Objectif du projet

Rééducation de la position de la tête.

Contexte

L’évolution de l'informatique a engendré une modification de la place du salarié dans l'entreprise. Ainsi, nombreux sont ceux qui travaillent dans un bureau face à un ordinateur. De ce fait, il a été remarqué par une association de la santé que les maux de dos sont en majorité dus à une mauvaise hygiène de vie notamment liée à une mauvaise posture au travail.

C'est après différentes études, notamment un bilan postural montrant où se situe la tête par rapport à une position idéale que l'on a remarqué que ces dernières années, 50% des personnes ayant des maux de dos sont en réalité dûs aux cervicales contre 20 % seulement il y a une dizaine d’années.

Du constat précédent découle ce projet ayant pour but de faciliter aux kinésithérapeutes la rééducation de la position de la tête des patients se plaignants de leur dos.

Description du projet

La rééducation de la posture de la tête chez un kinésithérapeute pourrait être améliorée si le travail pouvait se faire en autonomie.

Ce projet propose de réaliser un système de suivi de la position de la tête d'un patient en rééducation grâce à un monitoring continu de la position de la tête, ainsi qu'un mécanisme pour aider le patient à reprendre une position correcte. En effet on lancera le système pendant environ 30 min durant lesquelles nous détecterons les variations de position et indiquerons au patient le moment ou sa position n’est plus bonne.

Ce projet devra ainsi comparer la position actuelle de la tête du patient à une position idéale (celle de la verticale) et lui signaler s’il doit ou non ajuster sa position.

Choix techniques : matériel et logiciels

Nous avons choisi d’utiliser des accéléromètres afin de pouvoir récupérer des données décrivant la position de la tête. Les accéléromètres nous permettent de calculer l'angle d'inclinaison à partir de la force gravitationnelle qu'ils peuvent mesurer selon les trois axes. Lorsque la position idéale du patient sera choisie par le médecin, nous pourrons enregistrer cette position en mémorisant l'inclinaison de chaque accéléromètre pour cette position. Ainsi un changement de position sera identifié par une variation des angles d'inclinaison précédemment pris. Nous allons utilisé les accéléromètres analogiques de type adxl335. Une fois que nous aurons à disposition les valeurs de l'accéléromètre et, par conséquent les angles d'inclinaison, nous aurons besoin d'un moyen d'affichage des ces données. Pour ce faire, nous avons opté dans un premier temps pour une affichage sur smartphone. Les données vont être envoyées au smartphone à travers un module WIFI connectés au même réseau que le smartphone. En récapitulant, nous aurons finalement besoin de:

  • 5 accéléromètres adxl335.
  • un arduino Mega
  • un module WIFI
  • des fils pour la liaison.

Calendrier prévisionnel

Liste des tâches à effectuer

Etude et choix des accéléromètres

  • fonctionnement : accéléromètres à sortie analogique. Nous aurons donc besoin de 3 sorties analogiques par capteur (donc 3*5 sorties analogiques)
  • type de données collectées: force gravitationnelle selon les trois axes qu'il faudra transformer de telle sorte à avoir l'inclinaison de l'accéléromètre par rapport à l'axe x, y et z


  • mise en œuvre du programme d'acquisition.

Moyen d'affichage des résultats

  • si position correcte par rapport à celle idéale ;
  • envoi des résultats sur un smartphone.

Réalisation d'un prototype

  • identification et acquisition de la position idéale à l'aide des accéléromètres placées le long de la colonne vertébrale;
  • notification au patient (à travers le smartphone) lorsqu'une position différente de celle idéale a été détectée.

Calendrier

tâches à réaliser

Tâche Avancement Commentaires
acquisition des données 10DOF Terminé
connexion au WIFI (esp9266) Terminé connexion à un wifi standard prédéfinit lors de la programmation
pages application smartphone Terminé
envois et réception de données sur smartphone Terminé terminé et testé
acquisition des données de l'accéléromètre avec l'arduino mini Terminé donnée récupérer à partir de 2 accéléromètre mais on peut en ajouter plus
liaison série arduino mini et esp8266 testé Communication réalisé mais quelque amélioration à faire, il faut optimiser le code
mise en commun de la partie wifi et acquisition de données Inachevé la mise en commun pose quelque problème notamment la réception de donnée non cohérente par le smartphone

Feuille d'heures

Tâche Prélude Heures S1 Heures S2 Heures S3 Heures S4 Heures S5 Heures S6 Heures S7 Heures S8 Heures S9 Heures S10 + Heures supplémentairements Total
Définition cahier des charges 2H 8H
documentation 2h 4h 4h
liste du matériel 2h 6h
étude du module Wi-fi 8H 2H 4H 12h
étude, programmation, câblage du 10 DOF 4H 8H
Accéléromètre 2H étude 3H schématique 2H 12h
liaison arduino esp 16H
étude et programmation arduino mini 16H
application mobile 2H 4H 4H 10h 10H

Avancement du Projet

Semaine 1

Nous avons été confronté à différents choix matériel notamment dans la référence des accéléromètres ou encore le moyen de transmission des données.

L'accéléromètre doit être assez précis pour des petites variations de position. Après avoir parcouru les catalogues de fournisseurs nous avons trouvé le ADXL335.

De plus, nous devions choisir le mode de transmission des données vers un smartphone. Nous avions le choix entre un module Bluetooth et un module wifi. Le module Bluetooth est plus rapide que le module bluetooth. Cependant, ce dernier ne consomme pas beaucoup de charge de la batterie du smartphone mais il fonctionne essentiellement sur de petites distances et avec des données de petite taille. En revanche le module WIFI lui consomme beaucoup plus de batterie mais couvre des distances beaucoup plus grandes ainsi que des tailles de données beaucoup plus importantes.

Finalement, nous avons opté pour le module WIFI pour limiter le moins possible l'utilisateur en ce qui concerne la distance entre les appareils et le volume de données transmis.

  • Confirmation de la liste de matériel:
    • accéléromètre ADXL335
    • Smartphone sous Android
    • 15 longs fils mâle-femelle, mâle-mâle
    • Arduino pro -mini
    • Module WIFI

Semaine 2

Réalisation d'un cahier des charges fonctionnelles avec les outils de gestions de projet telle que le FAST, la bête à cornes, SADT. cahier des charges fonctionnels

Cad1 1.PNG Cad1.PNG

Semaine 3

En début de semaine, nous avons reçus un premier capteur, l’accéléromètre 10 DOF, ainsi que l'arduino MEGA qui sera utilisé pour l’acquisition des données. L'accéléromètre 10DOF incorpore un gyroscope et un magnétomètre. Ceux-ci nous permettront d'avoir une meilleure précision des mesures notamment avec la mesure des orientations (vitesses angulaires).

Nous avons ensuite étudié le capteur et réalisé le premier montage en connectant ce capteur de manière à pouvoir lire les données récupérées en direct sur l'ordinateur.

10dof.PNG

Nous nous sommes également intéressé au calcule de l'angle à partir de l’accélération. Prenons l'exemple de l’accéléromètre penché de la manière suivante.

Exemple5.PNG

Le triangle G,Gx Gz forme un triangle rectangle, dans notre cas nous avons Gx,Gy et Gz qui sont les valeurs du vecteur gravitationnel G sur les trois axes et nous devons déduire 𝝰 (l’angle que fait Gx avec l’axe x), 𝝋 (l’angle que fait Gy avec l’axe y) et ᴪ (l’angle que fait Gz avec l’axe z). La norme de G est Norme2.PNG On récupére ensuite chaque angle de la manière suivante: Calcule angle.PNG

Nous avons ensuite réalisé un premier programme afin de lire les données du 10DOF que nous testerons la semaine suivante.

Semaine 4

Nous avons débuté le traitement des données directement sur le MEGA en réalisant de code de récupération de l'angle réalisé par l'accéléromètre.( Dans le code suivant nous avons uniquement l'acquisition des données)

10dof code.PNG

Nous nous sommes rendus compte que les calculs ne sont pas réalisés correctement par le MEGA. En effet la mesure de l'angle n'était pas précis car le MEGA n'a pas assez de puissance de calcul pour faire les différentes divisions.

Exempleaccelero.PNG

Nous avons donc décidé que le MEGA servira uniquement à récupérer les données et à les envoyer via module WIFI. Ce sera donc à l'application Android d'effectuer le traitement des données.

Nous avons ensuite étudié le module WIFI ESP8266 que nous utiliserons, afin de nous faire une idée de son utilisation.

Nous avons également installé les logiciels nécessaires ( Android studio,... )

Semaine 5

Nous nous sommes intéressées au module wifi, en commençant par lire la fiche technique de l'esp 8266, nous avons également cherché les différents types d'exemples .

Des recherches sur le mode de connexion entre le smartphone et le Mega à travers le module WIFI ont également été effectuer dans le but de se faire une idée, nous hésitons sur l'utilisation de Sockets UDP , ou de réaliser une transmission en TCP .

Le programme réalisée lors de la séance précédente a été testé, notamment les tests de récupération des données de l'accéléromètre 10-DOF sur le Mega.

Le code pour les autres accéléromètres en attendant la livraison de l'ADXL335 a également été entamé.

Nous avons également rencontré un certain nombre de problème :

Afin se connecter en WIFI à partir de n’importe où, nous avons décidé de se connecter premièrement à un réseau standard (point d'accès fourni par le smartphone dans un premier temps) puis de modifier le réseau sur lequel nous sommes connecté à partir du smartphone. Ce dernier enverra le SSID et le mot de passe du nouveau réseau souhaité au module et on modifiera le paramètre de cette manière. Connection.PNG

La possibilité et l'utilité de l'ajout de l'acquisition des données du gyroscope pour avoir plus de précision sur l'accéléromètre 10-DOF qui sera sur la tête ( gérer les rotations).


En parallèle, nous avons également avancé avec la création d'une application android pour la réception et l'affichage de données. Nous avons décidé de:

  • faire une page d'accueil dans laquelle le kinésithérapeute devra appuyer sur un bouton lorsqu'il aura bien positionné le patient pour enregistrer la bonne position.
  • à l'appui du bouton, le smartphone va contacter le module WIFI à travers un message broadcast (en utilisant une communication UDP) dans le réseau.
  • Le MODULE WIFI, qui est déjà en attente d'une trame venant du smartphone, reçoit le message broadcast, extrait l'adresse IP du smartphone, puis, lui envoie des données du capteur.
  • le smartphone, à son tour va utiliser ces données pour calculer les angles d'inclinaison sur les différents axes et les afficher. Notons que les premiers angles calculés sont ceux correspondant à la bonne position.
  • A intervalle régulier, le module ESP va envoyer de nouvelles données que le smartphone va traiter et comparer avec les angles de la bonne position et prévenir le patient si la position a changer.

Transmition.PNG

Semaine 6

  • Réception du matériel

ADXL345.PNG

Nous avons commencé par étudier l'accéléromètre reçu, en effet la référence de ce dernier est ADXL345 et est digital à l’inverse de celui choisi qui était analogique. De ce fait, nous avons modifié une partie du cahier des charges.

Les accéléromètres adxl345 sont alimentés en 3.3V et sont digitaux. Par conséquent, nous n'aurons plus besoin de sortie analogique.

  • fonctionnement : accéléromètres digitaux pouvant fonctionner en SPI comme en I2C et supportant 3.3V. Résolution: 10 bits, régler en mode +/-2g. Donc les valeurs de notre registre de données seront dans la plage [-512 ,512]. Mais puisque nous ne mesurons que la force gravitationnelle, nous aurons des valeurs comprises entre [-256,256] qui est la plage correspondant à -/1g. 1g correspond à la valeur de 9.80m/s2.
  • type de données collectées: des entiers de -512 à 512 qu'il faudra transformer de telle sorte à avoir l'inclinaison de l'accéléromètre selon l'axe x, y et z

L'établissement des activités nécessairement et documentation sur le choix des sockets à utiliser pour l'envoi des données a également été entamé.

Coté Smartphone:

  • Créations de la page d'accueil et de la page de visualisation des angles d'inclinaisons

Semaine 7

Nous avons réalisé l'étude de l'accéléromètre digital, nous avons choisis de travailler avec le mode SPI qui consiste à donner la parole à chaque accéléromètre l'un après l'autre en alimentant chaque pin CS l'un après l'autre. ( Le mode SPI utilise les ports digitaux )

Seulement les pins de l’accéléromètre n'acceptent que des tensions de 3.3V alors que ceux du Mega fournissent des tensions de 5v. Nous aurons donc besoin d'un mécanisme de régulation des tensions en sortie de Mega.

Nous nous sommes alors documenté sur les circuits de régulations et conversions de tension. Nous devons réaliser un dispositif de préférence réversible qui fourni une tension de 3.3v en sortie lorsqu'on lui injecte une tension de 5v en entré.

Les premières connections à partir se l'esp8266. Nous nous sommes donc connecté à notre téléphone utilisé comme point d’accès.

Espconnect.PNG

Semaine 8

Nous avons réalisé une carte électronique grâce au logiciel fritzing pour réaliser l’adaptation de tensions entre l’accéléromètre adxl345 et la carte MEGA. En effet l'accéléromètre supporte des tensions maximales de 3.3V alors que le MEGA donne en sortie 5V.

Carte elec1.PNG

Coté Smartphone:

  • création de la page d'accueil avec implémentation du code pour la communication UDP entre le smartphone et l'ESP8266.

Page daccueil.jpg

Nous avons également commencé la transmission de donnée avec le smartphone en fixant des valeur à envoyer. Dans la photo suivante, on peut voir l'esp connecté et attendant le message venant du smartphone.

Wifi conect.png

Semaine 9

Nous avons testé la carte électronique faite la semaine précédente.

Carte elec2.PNG

Afin de tester la carte, nous avons alimenter les pins d’entrée par des 5v et avons observé la sortie du circuit. Malheureusement, seulement un pin en sortie fournissait une tension de 3.3V. Elle ne fonctionne pas et nous n'avons pas pu comprendre pourquoi.

Par conséquent, nous avons changé de microcontrôleur. Nous avons reçu un arduino pro mini 3.3V compatible avec nos capteurs ( mais qui ne l'est pas avec le 10DOF ). Nous commençons par conséquent à recueillir les données du capteurs. Pour cela, nous avons utilisé une librairie pour les ADXL345. La première étape est de sélectionner le chip Select en définissant un ADXL grâce à la fonction suivante: Def adxl.PNG Cette fonction prend en paramètre le pin lié au chip Select de accéléromètre.

Ensuite on récupère les données grâce à la fonction readaccel comme suit: Readaccel.PNG La fonction stocke alors les valeurs lues par l'accéléromètre dans x,y et z. 

code :
Codemini1.PNG

Codemini2.PNG

Nous réalisons ensuite le montage suivant de manière à pouvoir lire sur le port série les valeurs .

Montageaccel.PNG


Partie smartphone: succès de la connexion au wi-fi partagé d'un smartphone. Coté ESP comme coté smartphone.

Affichage valeur.jpg

Semaine 10

Etude de la partie communication entre l'arduino pro mini et l'ESP8266 pour l'envoie des données du capteur

Nous avons implémenté le module Wifi de manière à ce que l’on puisse recevoir les données des accélérations reçus par l’arduino mini.7

Pour cela, nous avons utilisée la bibliothèque SoftwareSerial d’arduino et avons défini deux liaisons série (l'une du côté du mini et l’autre du coté esp).Le mini envois un “a” indiquant à l'esp qu'il commence à envoyer une série de données.Ensuite on ramène les valeurs de l'accéléromètre sur l'échelle de g (gravitation terrestre ) grâce à un produit en croix . Pour finir, nous envoyons les données grâce à un serial write qui écrit sur les pins de l’esp ( pin 14 RX et 12 TX).

Du côté de l’esp, on définit une liaison du nom de swSer au même baudrate que la précédente (9600). On attend la réception de 72 ( l'équivalent de ‘a’ en integer) indiquant que l’on commence à transmettre des données de l'accéléromètre. Une fois ce nombre reçu on incrémente un compteur à chaque réception d’un chiffre et à partir de la valeur de ce compteur nous plaçons la donnée dans la variable qui la définit ( la première donnée est celle de x1 donc si compteur est à 1 on place la valeur lue par swSer.read dans la variable x1 )

Mise en commun de la partie Wifi et arduino mini

L’union de ces deux partie n'est pas un succès dans le sens ou bien que la connexion aboutit, les donnée qui sont envoyé au smartphone ne sont pas celle envoyé par le mini. Il se pourrait qu'il y ai un problème dans le software serial mis en place entre les deux éléments. Pour résoudre ce problème il faudrait optimiser le code au maximum en enlevant tous ce qui pourrait paraître excédent.

Fichiers rendus

Rapport de projet : Fichier:Rapport Fahem Diop.pdf

Code de la partie smartphone: [1]

Code de la partie arduino : [2]

Code de la partie esp: [3]

Récupérée de « https://projets-ima.plil.fr/mediawiki/index.php?title=IMA4_2016/2017_P18&oldid=43894 »