IMA4 2016/2017 P18 : Différence entre versions
(→Semaine 10) |
(→Semaine 2) |
||
(24 révisions intermédiaires par 3 utilisateurs non affichées) | |||
Ligne 229 : | Ligne 229 : | ||
*Confirmation de la liste de matériel: | *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=== | ===Semaine 2=== | ||
− | Réalisation d'un cahier des charges fonctionnelles avec les outils de gestions de projet telle que le FAST, la | + | 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] | [https://docs.google.com/document/d/1e6291kst6O6Ic0IWnadg5l10HiiZeqsw72GxfXC7O7U/edit cahier des charges fonctionnels] | ||
Ligne 329 : | Ligne 329 : | ||
===Semaine 7=== | ===Semaine 7=== | ||
− | Nous avons réalisé l'étude de l'accéléromètre digital, nous | + | 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=== | ===Semaine 8=== | ||
Ligne 345 : | Ligne 347 : | ||
* création de la page d'accueil avec implémentation du code pour la communication UDP entre le smartphone et l'ESP8266. | * 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=== | ===Semaine 9=== | ||
Ligne 379 : | Ligne 387 : | ||
Partie smartphone: | Partie smartphone: | ||
succès de la connexion au wi-fi partagé d'un smartphone. Coté ESP comme coté 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=== | ===Semaine 10=== | ||
Ligne 386 : | Ligne 396 : | ||
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 | 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 | + | 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 ) | 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=== | ===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
Sommaire
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
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.
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.
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 On récupére ensuite chaque angle de la manière suivante:
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)
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.
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.
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.
Semaine 6
- Réception du matériel
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.
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.
Coté Smartphone:
- création de la page d'accueil avec implémentation du code pour la communication UDP entre le smartphone et l'ESP8266.
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.
Semaine 9
Nous avons testé la carte électronique faite la semaine précédente.
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: 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: La fonction stocke alors les valeurs lues par l'accéléromètre dans x,y et z.
code :
Nous réalisons ensuite le montage suivant de manière à pouvoir lire sur le port série les valeurs .
Partie smartphone:
succès de la connexion au wi-fi partagé d'un smartphone. Coté ESP comme coté smartphone.
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]