Wiki d'activités IMA - Contributions de l’utilisateur [fr]

P5 IOT 2017

2018-01-29T02:49:52Z

Mdiop : /* Détail du travail de la cinquième séance */

P5 IOT 2017

2018-01-29T02:48:10Z

Mdiop : /* Détail du travail de la sixième séance */

=Présentation du sujet =

==Contexte==

Nous effectuons ce projet dans le cadre du module internet des objets (Internet of things).

L'objectif de ce module est de créer l'objet connecté de notre choix.

Nous avons donc choisi de créer un objet en rapport avec la sécurité routière: le système Safe&Drive.

==Description du projet==

Pour veiller au respect des distances de sécurité, le système S&D va tout d'abord évaluer la distance entre votre voiture et celle qui vous suit.

Grâce au GPS intégré, la distance de sécurité à respecter sera calculée en fonction de votre vitesse de circulation.

Si cette distance de sécurité n'est pas respectée, un message de mise en garde sera affiché sur votre pare-brise arrière à destination du conducteur qui vous suit de trop prêt.

Bien évidemment, ce message ne sera envoyé qu'après confirmation de l'utilisateur depuis l'application mobile du système Safe&Drive.

En mode marche arrière, le système devient une aide à la manœuvre avec une caméra de recul et un détecteur d'obstacle.

=Réalisation=

==Matériel utilisé==

* Raspberry Pi
* Arduino Uno
* Arduino Mega2560
* SparkFun GPS Shield
* Adafruit 64x32 RGB LED Matrix - 5mm pitch
* Garmin LIDAR-Lite v3

==Suivi de réalisation==
{| class="wikitable alternance centre"
|-
! scope="row" | Séance 1 (08/01/2018)
| Choix de l'objet + Choix du matériel
|-
! scope="row" | Séance 2 (09/01/2018)
| Circuit shield pour la matrice LED + Test Li-DAR Lite
|-
! scope="row" | Séance 3 (16/01/2018)
| Circuit shield pour la matrice LED + Test du shield GPS
|-
! scope="row" | Séance 4 (17/01/2018)
| Circuit shield pour la matrice LED + Test Shield GPS
|-
! scope="row" | Séance 5 (22/01/2018)
| Soudage circuit shield pour la matrice LED + Test LED Matrix + RaspberryPI + Application mobile
|-
! scope="row" | Séance 6 (24/01/2018)
| Finitions + Resolutions des problèmes + Préparation orale (+poster)
|}

==Détail du travail de la première séance==

Pour choisir notre projet nous avons débuté en faisant un pseudo-brainstorming duquel est ressorti 4 projets.

Nous donc dû réduire notre choix à un seul de ces quatre possibilités.

Notre choix final s'est donc porté sur le système Safe&Drive.

Après avoir affiné les divers fonctionnalités de notre projet, nous avons commencé à réunir le matériel dont nous aurions besoin.

==Détail du travail de la deuxième séance==

* Début de la création du shield de la matrice de LED qui viendra se positionner sur l’Arduino Mega2560.

* Test du capteur optique LI-DAR Lite et codage du programme pour le calcul de distance.

<pre>

LIDARLite Arduino Library
GetDistanceI2c

This example shows how to initialize, configure, and read distance from a
LIDAR-Lite connected over the I2C interface.

Connections:
LIDAR-Lite 5 Vdc (red) to Arduino 5v
LIDAR-Lite I2C SCL (green) to Arduino SCL
LIDAR-Lite I2C SDA (blue) to Arduino SDA
LIDAR-Lite Ground (black) to Arduino GND

(Capacitor recommended to mitigate inrush current when device is enabled)
680uF capacitor (+) to Arduino 5v
680uF capacitor (-) to Arduino GND

See the Operation Manual for wiring diagrams and more information:
http://www.robotshop.com/media/files/pdf2/pli-06-instruction.pdf

-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

#include <Wire.h>
#include <LIDARLite.h>

LIDARLite myLidarLite;
int distance_reelle ;

void setup()
{
Serial.begin(9600); // Initialize serial connection to display distance readings

myLidarLite.begin(0, true); // Set configuration to default and I2C to 400 kHz

myLidarLite.configure(0); // Change this number to try out alternate configurations
}

void loop()
{

// Take a measurement with receiver bias correction and print to serial terminal
distance_reelle = (myLidarLite.distance());
if(distance_reelle < 1)
{
Serial.println('O');
}
else
{
Serial.println('N');
}
}

</pre>

==Détail du travail de la troisième séance==

* Poursuite de la création du circuit (shield) pour la matrice LED.
Cela n'a pas été une tâche facile en raison de la répartition des différentes pâtes dont nous avions besoin et des liaisons à effectuer.

* Test du GPS et codage du programme de calcul de vitesse.
Nous avons rencontré des problèmes avec le GPS, celui-ci ne renvoyait des message d'erreurs "NO GPS DETECTED" ou bien des données nulles du type "Date: 00/00/0000".

==Détail du travail de la quatrième séance==

* Finition du circuit (shield) pour la matrice LED et envoi de la demande de fabrication

Nous avons rencontré un problème avec le logiciel nous avons donc dû refaire entièrement le circuit, cela nous a pas mal retardé dans notre projet.

[[Fichier:Circuitp5.jpg|200px|]]
[[Fichier:circuit_bottom.jpg|200px|]]

* Test du GPS et résolution des problèmes.
Nous avons rencontré beaucoup de problèmes avec le GPS, celui-ci se connectait bien aux satellites mais ne nous renvoyait que des données nulles ou bien un message d'erreur.

Il s'est en faite avéré que selon la position du GPS receiver sur le shield celui-ci affichait ou non les données.

Le problème a donc été résolu. Voici le code:

<pre>}

#include <TinyGPS++.h>
#include <SoftwareSerial.h>
#include <Wire.h>
/*
This example uses software serial and the TinyGPS++ library by Mikal Hart
Based on TinyGPSPlus/DeviceExample.ino by Mikal Hart
Modified by acavis
*/

// Choose two Arduino pins to use for software serial
// The GPS Shield uses D2 and D3 by default when in DLINE mode
int RXPin = 50;
int TXPin = 3;

// The Skytaq EM-506 GPS module included in the GPS Shield Kit
// uses 4800 baud by default
int GPSBaud = 4800;

// Create a TinyGPS++ object called "gps"
TinyGPSPlus gps;

// Create a software serial port called "gpsSerial"
SoftwareSerial gpsSerial(RXPin, TXPin);

void setup()
{
// Start the Arduino hardware serial port at 9600 baud
Serial.begin(9600);

// Start the software serial port at the GPS's default baud
gpsSerial.begin(GPSBaud);

Serial.println(F("DeviceExample.ino"));
Serial.println(F("A simple demonstration of TinyGPS++ with an attached GPS module"));
Serial.print(F("Testing TinyGPS++ library v. ")); Serial.println(TinyGPSPlus::libraryVersion());
Serial.println(F("by Mikal Hart"));
Serial.println();

}

void loop()
{
// This sketch displays information every time a new sentence is correctly encoded.
while (gpsSerial.available() > 0)
if (gps.encode(gpsSerial.read()))
displayInfo();

// If 5000 milliseconds pass and there are no characters coming in
// over the software serial port, show a "No GPS detected" error
if (millis() > 5000 && gps.charsProcessed() < 10)
{
Serial.println(F("No GPS detected"));
while(true);
}
}

void displayInfo()
{
Serial.print(F("Speed: "));
if (gps.speed.isValid())
{
Serial.print(gps.speed.kmph(), 6);
}
else
{
Serial.print(F("INVALID"));
}

Serial.println();

secure_dist = (gps.speed.kmph()/10)*6;
Serial.print("distance de sécurite (en m)= ");
Serial.print(secure_dist);
Serial.println();

}

</pre>

==Détail du travail de la cinquième séance==
* Soudage des barrettes et des ponts sur le circuit pour la Matrice LED (Shield)

* Test de la matrice LED et codage du programme pour l'affichage d'un message personnalisé coloré
Message choisi: Ne me collez pas au cul, PUTAIN!!
Voici le code pour l'affichage du message. Celle-ci se fait grâce à un liaison série entre la raspberry Pi (RPI) et la matrice de de LED connectée à l’arduino Mega à travers le shield.

Voici le code pour l'affichage:

<pre>

/***************************************************
*
*NOTE THIS CAN ONLY BE USED ON A MEGA! NOT ENOUGH RAM ON UNO!
*
***************************************************
* 64x32 RGB LED Matrix - 4mm pitch
* ****************************************************
* testshapes demo for RGBmatrixPanel library.
* Demonstrates the drawing abilities of the RGBmatrixPanel library.
* For 32x64 RGB LED matrix.

* @author lg.gang(lg.gang@qq.com)
* @version V1.0
* @date 2016-9-6

* GNU Lesser General Public License.
* See <http://www.gnu.org/licenses/> for details.
* All above must be included in any redistribution
* ****************************************************/
#include <Adafruit_GFX.h> // Core graphics library
#include <RGBmatrixPanel.h> // Hardware-specific library

#define CLK 11
#define OE 9
#define LAT 10

#define A A0
#define B A1
#define C A2
#define D A3

RGBmatrixPanel matrix(A, B, C, D, CLK, LAT, OE, false, 64);
char msg;

void setup() {
Serial.begin(9600);
delay(1000);
matrix.begin();

}

void loop() {

// draw a pixel in solid white
//matrix.drawPixel(0, 0, matrix.Color333(7, 7, 7));
//delay(5000);

// fix the screen with green
//matrix.fillRect(0, 0, matrix.width(), matrix.height(), matrix.Color333(0, 7, 0));
//delay(5000);

// fix the screen with white
//matrix.fillRect(0, 0, matrix.width(), matrix.height(), matrix.Color333(7, 7, 7));
//delay(5000);

// fix the screen with red
//matrix.fillRect(0, 0, matrix.width(), matrix.height(), matrix.Color333(7, 0, 0));
//delay(5000);

// fix the screen with blue
//matrix.fillRect(0, 0, matrix.width(), matrix.height(), matrix.Color333(0, 0, 7));
//delay(5000);
// fill the screen with 'black'
//matrix.fillScreen(matrix.Color333(0, 0, 0));

// draw a box in yellow
//matrix.drawRect(0, 0, matrix.width(), matrix.height(), matrix.Color333(7, 7, 0));
//delay(5000);

// draw a box in fuchsia
//matrix.drawRect(5, 5, 53, 23, matrix.Color333(7, 0, 7));
//delay(5000);

// draw a box in yellow
//matrix.drawRect(10, 10, 43, 13, matrix.Color333(7, 1, 3));
//delay(5000);

// draw an 'X' in red
//matrix.drawLine(0, 0, matrix.width()-1, matrix.height()-1, matrix.Color333(7, 0, 0));
//matrix.drawLine(matrix.width()-1, 0, 0, matrix.height()-1, matrix.Color333(7, 0, 0));
//delay(5000);

// draw a blue circle
//matrix.drawCircle(10, 10, 10, matrix.Color333(0, 0, 7));
//delay(5000);

// fill a violet circle
//matrix.fillCircle(40, 21, 10, matrix.Color333(7, 0, 7));
//delay(5000);

// fill the screen with 'black'
//matrix.fillScreen(matrix.Color333(0, 0, 0));

while (Serial.available() > 0) {

//msg = Serial.read();

//Serial.print(msg);
if(Serial.read() == 'o'){
// draw some text!
matrix.setTextSize(1); // size 1 == 8 pixels high
matrix.setTextWrap(false); // Don't wrap at end of line - will do ourselves
matrix.setCursor(3, 0); // start at top left, with 3 pixel of spacing
uint8_t w = 0;
char *str = " Ne me collez";
for (w=0; w<10; w++) {
matrix.setTextColor(Wheel(w));
matrix.print(str[w]);
}

matrix.setCursor(13, 8); // next line
for (w=10; w<17; w++) {
matrix.setTextColor(Wheel(w));
matrix.print(str[w]);
}

matrix.println();
matrix.setCursor(2, 16);
matrix.setTextColor(matrix.Color333(7,1,0));
matrix.print('p');
matrix.setTextColor(matrix.Color333(7,3,0));
matrix.print('a');
matrix.setTextColor(matrix.Color333(7,7,0));
matrix.print('s');
matrix.setTextColor(matrix.Color333(4,7,0));
matrix.print(' ');
matrix.setTextColor(matrix.Color333(0,7,0));
matrix.print('a');
matrix.setTextColor(matrix.Color333(0,7,7));
matrix.print('u');
matrix.setTextColor(matrix.Color333(0,4,7));
matrix.print(' ');
matrix.setTextColor(matrix.Color333(7,0,0));
matrix.print('c');
matrix.setTextColor(matrix.Color333(7,0,0));
matrix.print('u');
matrix.setTextColor(matrix.Color333(7,0,0));
matrix.print('l');
//matrix.setTextColor(matrix.Color333(7,7,7));
//matrix.println("pas au Cul");

// print each letter with a rainbow color
matrix.setCursor(3, 24);
matrix.setTextColor(matrix.Color333(7,0,0));
matrix.print(' ');
matrix.setTextColor(matrix.Color333(7,1,0));
matrix.print('P');
matrix.setTextColor(matrix.Color333(7,3,0));
matrix.print('U');
matrix.setTextColor(matrix.Color333(4,7,0));
matrix.print('T');
matrix.setTextColor(matrix.Color333(0,7,0));
matrix.print('A');
matrix.setTextColor(matrix.Color333(0,7,7));
matrix.print('I');
matrix.setTextColor(matrix.Color333(0,4,7));
matrix.print('N');
matrix.setTextColor(matrix.Color333(0,0,7));
matrix.print('!');
matrix.setTextColor(matrix.Color333(4,0,7));
matrix.print('!');
matrix.setTextColor(matrix.Color333(7,0,4));
matrix.println(' ');
//delay(50000);

} else {matrix.fillScreen(0);}
}

}

// Input a value 0 to 24 to get a color value.
// The colours are a transition r - g - b - back to r.
uint16_t Wheel(byte WheelPos) {
if(WheelPos < 8) {
return matrix.Color333(7 - WheelPos, WheelPos, 0);
} else if(WheelPos < 16) {
WheelPos -= 8;
return matrix.Color333(0, 7-WheelPos, WheelPos);
} else {
WheelPos -= 16;
return matrix.Color333(0, WheelPos, 7 - WheelPos);
}
}

</pre>

* Configuartion de la RPI

La raspberry pi (RPI) est chargé de recueillir la confirmation de l'utilisateur à travers l'application mobile, une fois ceci fait, elle lit les données envoyées provenant du traitement d'information sur la distance de sécurité et celle réelle avant de les envoyé vers le programme traitant de l'affichage du message. En fonction du message envoyé (dans notre cas c'est un caractère: 'O' ou 'o' si le message doit être envoyé et 'n' ou 'N' si c'est le contraire). Voici le code:

<pre>

from bluetooth import *
import time
import serial

server_sock=BluetoothSocket( RFCOMM )
server_sock.bind(("",PORT_ANY))
server_sock.listen(1)

port = server_sock.getsockname()[1]

uuid = "94f39d29-7d6d-437d-973b-fba39e49d4ee"

advertise_service( server_sock, "SampleServer",
service_id = uuid,
service_classes = [ uuid, SERIAL_PORT_CLASS ],
profiles = [ SERIAL_PORT_PROFILE ],
# protocols = [ OBEX_UUID ]
)

print("Waiting for connection on RFCOMM channel %d" % port)

client_sock, client_info = server_sock.accept()
print("Accepted connection from ", client_info)

ser0 = serial.Serial('/dev/ttyACM0')
Ser1 = serial.SERIAL('/dev/ttyACM1')

try:
while True:
data = ""
client_sock.recv(data)
data2 = ser1.read();
if data2 == 'O'
ser0.write('o')
if data2 == 'N'
ser0.write('n')
except IOError:
pass

print("disconnected")

client_sock.close()
server_sock.close()
print("all done")
</pre>

* Codage de l'application Mobile
Elle a pour but de permettre à l'utilisateur de se connecter, via bluetooth, à la RPI et de lui envoyer sa confirmation. Celui-ci peut également se déconnecter, s'il le souhaite.
[[Fichier:Appli iot.PNG|200px|]]

==Détail du travail de la sixième séance==
* Test du fonctionnement du système complet
Problèmes rencontrés:
on a eu plusieurs bugs sur la partie RPI. On a eu du mal à faire les liaisons série entre les deux arduino.

* Préparation de l'oral et finition du poster

=Rendu=

==Poster==
Version électronique du poster :
[[Fichier:2017_IOT_P5_poster.png|center|500px]]

==Fichiers rendus==

Notre application : [[Media:Rendu.zip]]

P5 IOT 2017

2018-01-29T02:47:48Z

Mdiop : /* Fichiers rendus */

=Présentation du sujet =

==Contexte==

Nous effectuons ce projet dans le cadre du module internet des objets (Internet of things).

L'objectif de ce module est de créer l'objet connecté de notre choix.

Nous avons donc choisi de créer un objet en rapport avec la sécurité routière: le système Safe&Drive.

==Description du projet==

Pour veiller au respect des distances de sécurité, le système S&D va tout d'abord évaluer la distance entre votre voiture et celle qui vous suit.

Grâce au GPS intégré, la distance de sécurité à respecter sera calculée en fonction de votre vitesse de circulation.

Si cette distance de sécurité n'est pas respectée, un message de mise en garde sera affiché sur votre pare-brise arrière à destination du conducteur qui vous suit de trop prêt.

Bien évidemment, ce message ne sera envoyé qu'après confirmation de l'utilisateur depuis l'application mobile du système Safe&Drive.

En mode marche arrière, le système devient une aide à la manœuvre avec une caméra de recul et un détecteur d'obstacle.

=Réalisation=

==Matériel utilisé==

* Raspberry Pi
* Arduino Uno
* Arduino Mega2560
* SparkFun GPS Shield
* Adafruit 64x32 RGB LED Matrix - 5mm pitch
* Garmin LIDAR-Lite v3

==Suivi de réalisation==
{| class="wikitable alternance centre"
|-
! scope="row" | Séance 1 (08/01/2018)
| Choix de l'objet + Choix du matériel
|-
! scope="row" | Séance 2 (09/01/2018)
| Circuit shield pour la matrice LED + Test Li-DAR Lite
|-
! scope="row" | Séance 3 (16/01/2018)
| Circuit shield pour la matrice LED + Test du shield GPS
|-
! scope="row" | Séance 4 (17/01/2018)
| Circuit shield pour la matrice LED + Test Shield GPS
|-
! scope="row" | Séance 5 (22/01/2018)
| Soudage circuit shield pour la matrice LED + Test LED Matrix + RaspberryPI + Application mobile
|-
! scope="row" | Séance 6 (24/01/2018)
| Finitions + Resolutions des problèmes + Préparation orale (+poster)
|}

==Détail du travail de la première séance==

Pour choisir notre projet nous avons débuté en faisant un pseudo-brainstorming duquel est ressorti 4 projets.

Nous donc dû réduire notre choix à un seul de ces quatre possibilités.

Notre choix final s'est donc porté sur le système Safe&Drive.

Après avoir affiné les divers fonctionnalités de notre projet, nous avons commencé à réunir le matériel dont nous aurions besoin.

==Détail du travail de la deuxième séance==

* Début de la création du shield de la matrice de LED qui viendra se positionner sur l’Arduino Mega2560.

* Test du capteur optique LI-DAR Lite et codage du programme pour le calcul de distance.

<pre>

LIDARLite Arduino Library
GetDistanceI2c

This example shows how to initialize, configure, and read distance from a
LIDAR-Lite connected over the I2C interface.

Connections:
LIDAR-Lite 5 Vdc (red) to Arduino 5v
LIDAR-Lite I2C SCL (green) to Arduino SCL
LIDAR-Lite I2C SDA (blue) to Arduino SDA
LIDAR-Lite Ground (black) to Arduino GND

(Capacitor recommended to mitigate inrush current when device is enabled)
680uF capacitor (+) to Arduino 5v
680uF capacitor (-) to Arduino GND

See the Operation Manual for wiring diagrams and more information:
http://www.robotshop.com/media/files/pdf2/pli-06-instruction.pdf

-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

#include <Wire.h>
#include <LIDARLite.h>

LIDARLite myLidarLite;
int distance_reelle ;

void setup()
{
Serial.begin(9600); // Initialize serial connection to display distance readings

myLidarLite.begin(0, true); // Set configuration to default and I2C to 400 kHz

myLidarLite.configure(0); // Change this number to try out alternate configurations
}

void loop()
{

// Take a measurement with receiver bias correction and print to serial terminal
distance_reelle = (myLidarLite.distance());
if(distance_reelle < 1)
{
Serial.println('O');
}
else
{
Serial.println('N');
}
}

</pre>

==Détail du travail de la troisième séance==

* Poursuite de la création du circuit (shield) pour la matrice LED.
Cela n'a pas été une tâche facile en raison de la répartition des différentes pâtes dont nous avions besoin et des liaisons à effectuer.

* Test du GPS et codage du programme de calcul de vitesse.
Nous avons rencontré des problèmes avec le GPS, celui-ci ne renvoyait des message d'erreurs "NO GPS DETECTED" ou bien des données nulles du type "Date: 00/00/0000".

==Détail du travail de la quatrième séance==

* Finition du circuit (shield) pour la matrice LED et envoi de la demande de fabrication

Nous avons rencontré un problème avec le logiciel nous avons donc dû refaire entièrement le circuit, cela nous a pas mal retardé dans notre projet.

[[Fichier:Circuitp5.jpg|200px|]]
[[Fichier:circuit_bottom.jpg|200px|]]

* Test du GPS et résolution des problèmes.
Nous avons rencontré beaucoup de problèmes avec le GPS, celui-ci se connectait bien aux satellites mais ne nous renvoyait que des données nulles ou bien un message d'erreur.

Il s'est en faite avéré que selon la position du GPS receiver sur le shield celui-ci affichait ou non les données.

Le problème a donc été résolu. Voici le code:

<pre>}

#include <TinyGPS++.h>
#include <SoftwareSerial.h>
#include <Wire.h>
/*
This example uses software serial and the TinyGPS++ library by Mikal Hart
Based on TinyGPSPlus/DeviceExample.ino by Mikal Hart
Modified by acavis
*/

// Choose two Arduino pins to use for software serial
// The GPS Shield uses D2 and D3 by default when in DLINE mode
int RXPin = 50;
int TXPin = 3;

// The Skytaq EM-506 GPS module included in the GPS Shield Kit
// uses 4800 baud by default
int GPSBaud = 4800;

// Create a TinyGPS++ object called "gps"
TinyGPSPlus gps;

// Create a software serial port called "gpsSerial"
SoftwareSerial gpsSerial(RXPin, TXPin);

void setup()
{
// Start the Arduino hardware serial port at 9600 baud
Serial.begin(9600);

// Start the software serial port at the GPS's default baud
gpsSerial.begin(GPSBaud);

Serial.println(F("DeviceExample.ino"));
Serial.println(F("A simple demonstration of TinyGPS++ with an attached GPS module"));
Serial.print(F("Testing TinyGPS++ library v. ")); Serial.println(TinyGPSPlus::libraryVersion());
Serial.println(F("by Mikal Hart"));
Serial.println();

}

void loop()
{
// This sketch displays information every time a new sentence is correctly encoded.
while (gpsSerial.available() > 0)
if (gps.encode(gpsSerial.read()))
displayInfo();

// If 5000 milliseconds pass and there are no characters coming in
// over the software serial port, show a "No GPS detected" error
if (millis() > 5000 && gps.charsProcessed() < 10)
{
Serial.println(F("No GPS detected"));
while(true);
}
}

void displayInfo()
{
Serial.print(F("Speed: "));
if (gps.speed.isValid())
{
Serial.print(gps.speed.kmph(), 6);
}
else
{
Serial.print(F("INVALID"));
}

Serial.println();

secure_dist = (gps.speed.kmph()/10)*6;
Serial.print("distance de sécurite (en m)= ");
Serial.print(secure_dist);
Serial.println();

}

</pre>

==Détail du travail de la cinquième séance==
* Soudage des barrettes et des ponts sur le circuit pour la Matrice LED (Shield)

* Test de la matrice LED et codage du programme pour l'affichage d'un message personnalisé coloré
Message choisi: Ne me collez pas au cul, PUTAIN!!
Voici le code pour l'affichage du message. Celle-ci se fait grâce à un liaison série entre la raspberry Pi (RPI) et la matrice de de LED connectée à l’arduino Mega à travers le shield.

Voici le code pour l'affichage:

<pre>

/***************************************************
*
*NOTE THIS CAN ONLY BE USED ON A MEGA! NOT ENOUGH RAM ON UNO!
*
***************************************************
* 64x32 RGB LED Matrix - 4mm pitch
* ****************************************************
* testshapes demo for RGBmatrixPanel library.
* Demonstrates the drawing abilities of the RGBmatrixPanel library.
* For 32x64 RGB LED matrix.

* @author lg.gang(lg.gang@qq.com)
* @version V1.0
* @date 2016-9-6

* GNU Lesser General Public License.
* See <http://www.gnu.org/licenses/> for details.
* All above must be included in any redistribution
* ****************************************************/
#include <Adafruit_GFX.h> // Core graphics library
#include <RGBmatrixPanel.h> // Hardware-specific library

#define CLK 11
#define OE 9
#define LAT 10

#define A A0
#define B A1
#define C A2
#define D A3

RGBmatrixPanel matrix(A, B, C, D, CLK, LAT, OE, false, 64);
char msg;

void setup() {
Serial.begin(9600);
delay(1000);
matrix.begin();

}

void loop() {

// draw a pixel in solid white
//matrix.drawPixel(0, 0, matrix.Color333(7, 7, 7));
//delay(5000);

// fix the screen with green
//matrix.fillRect(0, 0, matrix.width(), matrix.height(), matrix.Color333(0, 7, 0));
//delay(5000);

// fix the screen with white
//matrix.fillRect(0, 0, matrix.width(), matrix.height(), matrix.Color333(7, 7, 7));
//delay(5000);

// fix the screen with red
//matrix.fillRect(0, 0, matrix.width(), matrix.height(), matrix.Color333(7, 0, 0));
//delay(5000);

// fix the screen with blue
//matrix.fillRect(0, 0, matrix.width(), matrix.height(), matrix.Color333(0, 0, 7));
//delay(5000);
// fill the screen with 'black'
//matrix.fillScreen(matrix.Color333(0, 0, 0));

// draw a box in yellow
//matrix.drawRect(0, 0, matrix.width(), matrix.height(), matrix.Color333(7, 7, 0));
//delay(5000);

// draw a box in fuchsia
//matrix.drawRect(5, 5, 53, 23, matrix.Color333(7, 0, 7));
//delay(5000);

// draw a box in yellow
//matrix.drawRect(10, 10, 43, 13, matrix.Color333(7, 1, 3));
//delay(5000);

// draw an 'X' in red
//matrix.drawLine(0, 0, matrix.width()-1, matrix.height()-1, matrix.Color333(7, 0, 0));
//matrix.drawLine(matrix.width()-1, 0, 0, matrix.height()-1, matrix.Color333(7, 0, 0));
//delay(5000);

// draw a blue circle
//matrix.drawCircle(10, 10, 10, matrix.Color333(0, 0, 7));
//delay(5000);

// fill a violet circle
//matrix.fillCircle(40, 21, 10, matrix.Color333(7, 0, 7));
//delay(5000);

// fill the screen with 'black'
//matrix.fillScreen(matrix.Color333(0, 0, 0));

while (Serial.available() > 0) {

//msg = Serial.read();

//Serial.print(msg);
if(Serial.read() == 'o'){
// draw some text!
matrix.setTextSize(1); // size 1 == 8 pixels high
matrix.setTextWrap(false); // Don't wrap at end of line - will do ourselves
matrix.setCursor(3, 0); // start at top left, with 3 pixel of spacing
uint8_t w = 0;
char *str = " Ne me collez";
for (w=0; w<10; w++) {
matrix.setTextColor(Wheel(w));
matrix.print(str[w]);
}

matrix.setCursor(13, 8); // next line
for (w=10; w<17; w++) {
matrix.setTextColor(Wheel(w));
matrix.print(str[w]);
}

matrix.println();
matrix.setCursor(2, 16);
matrix.setTextColor(matrix.Color333(7,1,0));
matrix.print('p');
matrix.setTextColor(matrix.Color333(7,3,0));
matrix.print('a');
matrix.setTextColor(matrix.Color333(7,7,0));
matrix.print('s');
matrix.setTextColor(matrix.Color333(4,7,0));
matrix.print(' ');
matrix.setTextColor(matrix.Color333(0,7,0));
matrix.print('a');
matrix.setTextColor(matrix.Color333(0,7,7));
matrix.print('u');
matrix.setTextColor(matrix.Color333(0,4,7));
matrix.print(' ');
matrix.setTextColor(matrix.Color333(7,0,0));
matrix.print('c');
matrix.setTextColor(matrix.Color333(7,0,0));
matrix.print('u');
matrix.setTextColor(matrix.Color333(7,0,0));
matrix.print('l');
//matrix.setTextColor(matrix.Color333(7,7,7));
//matrix.println("pas au Cul");

// print each letter with a rainbow color
matrix.setCursor(3, 24);
matrix.setTextColor(matrix.Color333(7,0,0));
matrix.print(' ');
matrix.setTextColor(matrix.Color333(7,1,0));
matrix.print('P');
matrix.setTextColor(matrix.Color333(7,3,0));
matrix.print('U');
matrix.setTextColor(matrix.Color333(4,7,0));
matrix.print('T');
matrix.setTextColor(matrix.Color333(0,7,0));
matrix.print('A');
matrix.setTextColor(matrix.Color333(0,7,7));
matrix.print('I');
matrix.setTextColor(matrix.Color333(0,4,7));
matrix.print('N');
matrix.setTextColor(matrix.Color333(0,0,7));
matrix.print('!');
matrix.setTextColor(matrix.Color333(4,0,7));
matrix.print('!');
matrix.setTextColor(matrix.Color333(7,0,4));
matrix.println(' ');
//delay(50000);

} else {matrix.fillScreen(0);}
}

}

// Input a value 0 to 24 to get a color value.
// The colours are a transition r - g - b - back to r.
uint16_t Wheel(byte WheelPos) {
if(WheelPos < 8) {
return matrix.Color333(7 - WheelPos, WheelPos, 0);
} else if(WheelPos < 16) {
WheelPos -= 8;
return matrix.Color333(0, 7-WheelPos, WheelPos);
} else {
WheelPos -= 16;
return matrix.Color333(0, WheelPos, 7 - WheelPos);
}
}

</pre>

* Configuartion de la RPI

La raspberry pi (RPI) est chargé de recueillir la confirmation de l'utilisateur à travers l'application mobile, une fois ceci fait, elle lit les données envoyées provenant du traitement d'information sur la distance de sécurité et celle réelle avant de les envoyé vers le programme traitant de l'affichage du message. En fonction du message envoyé (dans notre cas c'est un caractère: 'O' ou 'o' si le message doit être envoyé et 'n' ou 'N' si c'est le contraire). Voici le code:

<pre>

from bluetooth import *
import time
import serial

server_sock=BluetoothSocket( RFCOMM )
server_sock.bind(("",PORT_ANY))
server_sock.listen(1)

port = server_sock.getsockname()[1]

uuid = "94f39d29-7d6d-437d-973b-fba39e49d4ee"

advertise_service( server_sock, "SampleServer",
service_id = uuid,
service_classes = [ uuid, SERIAL_PORT_CLASS ],
profiles = [ SERIAL_PORT_PROFILE ],
# protocols = [ OBEX_UUID ]
)

print("Waiting for connection on RFCOMM channel %d" % port)

client_sock, client_info = server_sock.accept()
print("Accepted connection from ", client_info)

ser0 = serial.Serial('/dev/ttyACM0')
Ser1 = serial.SERIAL('/dev/ttyACM1')

try:
while True:
data = ""
client_sock.recv(data)
data2 = ser1.read();
if data2 == 'O'
ser0.write('o')
if data2 == 'N'
ser0.write('n')
except IOError:
pass

print("disconnected")

client_sock.close()
server_sock.close()
print("all done")
</pre>

* Codage de l'application Mobile
Elle a pour but de permettre à l'utilisateur de se connecter, via bluetooth, à la RPI et de lui envoyer sa confirmation. Celui-ci peut également se déconnecter, s'il le souhaite.
[[Fichier:Appli iot.PNG|200px|]]

==Détail du travail de la sixième séance==
* Test du fonctionnement du système complet
Problèmes rencontrés:
on a eu plusieurs bug sur la partie RPI. On a eu du mal à faire les liaisons série entre les deux arduino.

* Préparation de l'oral et finition du poster

=Rendu=

==Poster==
Version électronique du poster :
[[Fichier:2017_IOT_P5_poster.png|center|500px]]

==Fichiers rendus==

Notre application : [[Media:Rendu.zip]]

Fichier:Rendu.zip

2018-01-29T02:47:15Z

Mdiop :

P5 IOT 2017

2018-01-29T02:40:27Z

Mdiop : /* Détail du travail de la sixième séance */

=Présentation du sujet =

==Contexte==

Nous effectuons ce projet dans le cadre du module internet des objets (Internet of things).

L'objectif de ce module est de créer l'objet connecté de notre choix.

Nous avons donc choisi de créer un objet en rapport avec la sécurité routière: le système Safe&Drive.

==Description du projet==

Pour veiller au respect des distances de sécurité, le système S&D va tout d'abord évaluer la distance entre votre voiture et celle qui vous suit.

Grâce au GPS intégré, la distance de sécurité à respecter sera calculée en fonction de votre vitesse de circulation.

Si cette distance de sécurité n'est pas respectée, un message de mise en garde sera affiché sur votre pare-brise arrière à destination du conducteur qui vous suit de trop prêt.

Bien évidemment, ce message ne sera envoyé qu'après confirmation de l'utilisateur depuis l'application mobile du système Safe&Drive.

En mode marche arrière, le système devient une aide à la manœuvre avec une caméra de recul et un détecteur d'obstacle.

=Réalisation=

==Matériel utilisé==

* Raspberry Pi
* Arduino Uno
* Arduino Mega2560
* SparkFun GPS Shield
* Adafruit 64x32 RGB LED Matrix - 5mm pitch
* Garmin LIDAR-Lite v3

==Suivi de réalisation==
{| class="wikitable alternance centre"
|-
! scope="row" | Séance 1 (08/01/2018)
| Choix de l'objet + Choix du matériel
|-
! scope="row" | Séance 2 (09/01/2018)
| Circuit shield pour la matrice LED + Test Li-DAR Lite
|-
! scope="row" | Séance 3 (16/01/2018)
| Circuit shield pour la matrice LED + Test du shield GPS
|-
! scope="row" | Séance 4 (17/01/2018)
| Circuit shield pour la matrice LED + Test Shield GPS
|-
! scope="row" | Séance 5 (22/01/2018)
| Soudage circuit shield pour la matrice LED + Test LED Matrix + RaspberryPI + Application mobile
|-
! scope="row" | Séance 6 (24/01/2018)
| Finitions + Resolutions des problèmes + Préparation orale (+poster)
|}

==Détail du travail de la première séance==

Pour choisir notre projet nous avons débuté en faisant un pseudo-brainstorming duquel est ressorti 4 projets.

Nous donc dû réduire notre choix à un seul de ces quatre possibilités.

Notre choix final s'est donc porté sur le système Safe&Drive.

Après avoir affiné les divers fonctionnalités de notre projet, nous avons commencé à réunir le matériel dont nous aurions besoin.

==Détail du travail de la deuxième séance==

* Début de la création du shield de la matrice de LED qui viendra se positionner sur l’Arduino Mega2560.

* Test du capteur optique LI-DAR Lite et codage du programme pour le calcul de distance.

<pre>

LIDARLite Arduino Library
GetDistanceI2c

This example shows how to initialize, configure, and read distance from a
LIDAR-Lite connected over the I2C interface.

Connections:
LIDAR-Lite 5 Vdc (red) to Arduino 5v
LIDAR-Lite I2C SCL (green) to Arduino SCL
LIDAR-Lite I2C SDA (blue) to Arduino SDA
LIDAR-Lite Ground (black) to Arduino GND

(Capacitor recommended to mitigate inrush current when device is enabled)
680uF capacitor (+) to Arduino 5v
680uF capacitor (-) to Arduino GND

See the Operation Manual for wiring diagrams and more information:
http://www.robotshop.com/media/files/pdf2/pli-06-instruction.pdf

-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

#include <Wire.h>
#include <LIDARLite.h>

LIDARLite myLidarLite;
int distance_reelle ;

void setup()
{
Serial.begin(9600); // Initialize serial connection to display distance readings

myLidarLite.begin(0, true); // Set configuration to default and I2C to 400 kHz

myLidarLite.configure(0); // Change this number to try out alternate configurations
}

void loop()
{

// Take a measurement with receiver bias correction and print to serial terminal
distance_reelle = (myLidarLite.distance());
if(distance_reelle < 1)
{
Serial.println('O');
}
else
{
Serial.println('N');
}
}

</pre>

==Détail du travail de la troisième séance==

* Poursuite de la création du circuit (shield) pour la matrice LED.
Cela n'a pas été une tâche facile en raison de la répartition des différentes pâtes dont nous avions besoin et des liaisons à effectuer.

* Test du GPS et codage du programme de calcul de vitesse.
Nous avons rencontré des problèmes avec le GPS, celui-ci ne renvoyait des message d'erreurs "NO GPS DETECTED" ou bien des données nulles du type "Date: 00/00/0000".

==Détail du travail de la quatrième séance==

* Finition du circuit (shield) pour la matrice LED et envoi de la demande de fabrication

Nous avons rencontré un problème avec le logiciel nous avons donc dû refaire entièrement le circuit, cela nous a pas mal retardé dans notre projet.

[[Fichier:Circuitp5.jpg|200px|]]
[[Fichier:circuit_bottom.jpg|200px|]]

* Test du GPS et résolution des problèmes.
Nous avons rencontré beaucoup de problèmes avec le GPS, celui-ci se connectait bien aux satellites mais ne nous renvoyait que des données nulles ou bien un message d'erreur.

Il s'est en faite avéré que selon la position du GPS receiver sur le shield celui-ci affichait ou non les données.

Le problème a donc été résolu. Voici le code:

<pre>}

#include <TinyGPS++.h>
#include <SoftwareSerial.h>
#include <Wire.h>
/*
This example uses software serial and the TinyGPS++ library by Mikal Hart
Based on TinyGPSPlus/DeviceExample.ino by Mikal Hart
Modified by acavis
*/

// Choose two Arduino pins to use for software serial
// The GPS Shield uses D2 and D3 by default when in DLINE mode
int RXPin = 50;
int TXPin = 3;

// The Skytaq EM-506 GPS module included in the GPS Shield Kit
// uses 4800 baud by default
int GPSBaud = 4800;

// Create a TinyGPS++ object called "gps"
TinyGPSPlus gps;

// Create a software serial port called "gpsSerial"
SoftwareSerial gpsSerial(RXPin, TXPin);

void setup()
{
// Start the Arduino hardware serial port at 9600 baud
Serial.begin(9600);

// Start the software serial port at the GPS's default baud
gpsSerial.begin(GPSBaud);

Serial.println(F("DeviceExample.ino"));
Serial.println(F("A simple demonstration of TinyGPS++ with an attached GPS module"));
Serial.print(F("Testing TinyGPS++ library v. ")); Serial.println(TinyGPSPlus::libraryVersion());
Serial.println(F("by Mikal Hart"));
Serial.println();

}

void loop()
{
// This sketch displays information every time a new sentence is correctly encoded.
while (gpsSerial.available() > 0)
if (gps.encode(gpsSerial.read()))
displayInfo();

// If 5000 milliseconds pass and there are no characters coming in
// over the software serial port, show a "No GPS detected" error
if (millis() > 5000 && gps.charsProcessed() < 10)
{
Serial.println(F("No GPS detected"));
while(true);
}
}

void displayInfo()
{
Serial.print(F("Speed: "));
if (gps.speed.isValid())
{
Serial.print(gps.speed.kmph(), 6);
}
else
{
Serial.print(F("INVALID"));
}

Serial.println();

secure_dist = (gps.speed.kmph()/10)*6;
Serial.print("distance de sécurite (en m)= ");
Serial.print(secure_dist);
Serial.println();

}

</pre>

==Détail du travail de la cinquième séance==
* Soudage des barrettes et des ponts sur le circuit pour la Matrice LED (Shield)

* Test de la matrice LED et codage du programme pour l'affichage d'un message personnalisé coloré
Message choisi: Ne me collez pas au cul, PUTAIN!!
Voici le code pour l'affichage du message. Celle-ci se fait grâce à un liaison série entre la raspberry Pi (RPI) et la matrice de de LED connectée à l’arduino Mega à travers le shield.

Voici le code pour l'affichage:

<pre>

/***************************************************
*
*NOTE THIS CAN ONLY BE USED ON A MEGA! NOT ENOUGH RAM ON UNO!
*
***************************************************
* 64x32 RGB LED Matrix - 4mm pitch
* ****************************************************
* testshapes demo for RGBmatrixPanel library.
* Demonstrates the drawing abilities of the RGBmatrixPanel library.
* For 32x64 RGB LED matrix.

* @author lg.gang(lg.gang@qq.com)
* @version V1.0
* @date 2016-9-6

* GNU Lesser General Public License.
* See <http://www.gnu.org/licenses/> for details.
* All above must be included in any redistribution
* ****************************************************/
#include <Adafruit_GFX.h> // Core graphics library
#include <RGBmatrixPanel.h> // Hardware-specific library

#define CLK 11
#define OE 9
#define LAT 10

#define A A0
#define B A1
#define C A2
#define D A3

RGBmatrixPanel matrix(A, B, C, D, CLK, LAT, OE, false, 64);
char msg;

void setup() {
Serial.begin(9600);
delay(1000);
matrix.begin();

}

void loop() {

// draw a pixel in solid white
//matrix.drawPixel(0, 0, matrix.Color333(7, 7, 7));
//delay(5000);

// fix the screen with green
//matrix.fillRect(0, 0, matrix.width(), matrix.height(), matrix.Color333(0, 7, 0));
//delay(5000);

// fix the screen with white
//matrix.fillRect(0, 0, matrix.width(), matrix.height(), matrix.Color333(7, 7, 7));
//delay(5000);

// fix the screen with red
//matrix.fillRect(0, 0, matrix.width(), matrix.height(), matrix.Color333(7, 0, 0));
//delay(5000);

// fix the screen with blue
//matrix.fillRect(0, 0, matrix.width(), matrix.height(), matrix.Color333(0, 0, 7));
//delay(5000);
// fill the screen with 'black'
//matrix.fillScreen(matrix.Color333(0, 0, 0));

// draw a box in yellow
//matrix.drawRect(0, 0, matrix.width(), matrix.height(), matrix.Color333(7, 7, 0));
//delay(5000);

// draw a box in fuchsia
//matrix.drawRect(5, 5, 53, 23, matrix.Color333(7, 0, 7));
//delay(5000);

// draw a box in yellow
//matrix.drawRect(10, 10, 43, 13, matrix.Color333(7, 1, 3));
//delay(5000);

// draw an 'X' in red
//matrix.drawLine(0, 0, matrix.width()-1, matrix.height()-1, matrix.Color333(7, 0, 0));
//matrix.drawLine(matrix.width()-1, 0, 0, matrix.height()-1, matrix.Color333(7, 0, 0));
//delay(5000);

// draw a blue circle
//matrix.drawCircle(10, 10, 10, matrix.Color333(0, 0, 7));
//delay(5000);

// fill a violet circle
//matrix.fillCircle(40, 21, 10, matrix.Color333(7, 0, 7));
//delay(5000);

// fill the screen with 'black'
//matrix.fillScreen(matrix.Color333(0, 0, 0));

while (Serial.available() > 0) {

//msg = Serial.read();

//Serial.print(msg);
if(Serial.read() == 'o'){
// draw some text!
matrix.setTextSize(1); // size 1 == 8 pixels high
matrix.setTextWrap(false); // Don't wrap at end of line - will do ourselves
matrix.setCursor(3, 0); // start at top left, with 3 pixel of spacing
uint8_t w = 0;
char *str = " Ne me collez";
for (w=0; w<10; w++) {
matrix.setTextColor(Wheel(w));
matrix.print(str[w]);
}

matrix.setCursor(13, 8); // next line
for (w=10; w<17; w++) {
matrix.setTextColor(Wheel(w));
matrix.print(str[w]);
}

matrix.println();
matrix.setCursor(2, 16);
matrix.setTextColor(matrix.Color333(7,1,0));
matrix.print('p');
matrix.setTextColor(matrix.Color333(7,3,0));
matrix.print('a');
matrix.setTextColor(matrix.Color333(7,7,0));
matrix.print('s');
matrix.setTextColor(matrix.Color333(4,7,0));
matrix.print(' ');
matrix.setTextColor(matrix.Color333(0,7,0));
matrix.print('a');
matrix.setTextColor(matrix.Color333(0,7,7));
matrix.print('u');
matrix.setTextColor(matrix.Color333(0,4,7));
matrix.print(' ');
matrix.setTextColor(matrix.Color333(7,0,0));
matrix.print('c');
matrix.setTextColor(matrix.Color333(7,0,0));
matrix.print('u');
matrix.setTextColor(matrix.Color333(7,0,0));
matrix.print('l');
//matrix.setTextColor(matrix.Color333(7,7,7));
//matrix.println("pas au Cul");

// print each letter with a rainbow color
matrix.setCursor(3, 24);
matrix.setTextColor(matrix.Color333(7,0,0));
matrix.print(' ');
matrix.setTextColor(matrix.Color333(7,1,0));
matrix.print('P');
matrix.setTextColor(matrix.Color333(7,3,0));
matrix.print('U');
matrix.setTextColor(matrix.Color333(4,7,0));
matrix.print('T');
matrix.setTextColor(matrix.Color333(0,7,0));
matrix.print('A');
matrix.setTextColor(matrix.Color333(0,7,7));
matrix.print('I');
matrix.setTextColor(matrix.Color333(0,4,7));
matrix.print('N');
matrix.setTextColor(matrix.Color333(0,0,7));
matrix.print('!');
matrix.setTextColor(matrix.Color333(4,0,7));
matrix.print('!');
matrix.setTextColor(matrix.Color333(7,0,4));
matrix.println(' ');
//delay(50000);

} else {matrix.fillScreen(0);}
}

}

// Input a value 0 to 24 to get a color value.
// The colours are a transition r - g - b - back to r.
uint16_t Wheel(byte WheelPos) {
if(WheelPos < 8) {
return matrix.Color333(7 - WheelPos, WheelPos, 0);
} else if(WheelPos < 16) {
WheelPos -= 8;
return matrix.Color333(0, 7-WheelPos, WheelPos);
} else {
WheelPos -= 16;
return matrix.Color333(0, WheelPos, 7 - WheelPos);
}
}

</pre>

* Configuartion de la RPI

La raspberry pi (RPI) est chargé de recueillir la confirmation de l'utilisateur à travers l'application mobile, une fois ceci fait, elle lit les données envoyées provenant du traitement d'information sur la distance de sécurité et celle réelle avant de les envoyé vers le programme traitant de l'affichage du message. En fonction du message envoyé (dans notre cas c'est un caractère: 'O' ou 'o' si le message doit être envoyé et 'n' ou 'N' si c'est le contraire). Voici le code:

<pre>

from bluetooth import *
import time
import serial

server_sock=BluetoothSocket( RFCOMM )
server_sock.bind(("",PORT_ANY))
server_sock.listen(1)

port = server_sock.getsockname()[1]

uuid = "94f39d29-7d6d-437d-973b-fba39e49d4ee"

advertise_service( server_sock, "SampleServer",
service_id = uuid,
service_classes = [ uuid, SERIAL_PORT_CLASS ],
profiles = [ SERIAL_PORT_PROFILE ],
# protocols = [ OBEX_UUID ]
)

print("Waiting for connection on RFCOMM channel %d" % port)

client_sock, client_info = server_sock.accept()
print("Accepted connection from ", client_info)

ser0 = serial.Serial('/dev/ttyACM0')
Ser1 = serial.SERIAL('/dev/ttyACM1')

try:
while True:
data = ""
client_sock.recv(data)
data2 = ser1.read();
if data2 == 'O'
ser0.write('o')
if data2 == 'N'
ser0.write('n')
except IOError:
pass

print("disconnected")

client_sock.close()
server_sock.close()
print("all done")
</pre>

* Codage de l'application Mobile
Elle a pour but de permettre à l'utilisateur de se connecter, via bluetooth, à la RPI et de lui envoyer sa confirmation. Celui-ci peut également se déconnecter, s'il le souhaite.
[[Fichier:Appli iot.PNG|200px|]]

==Détail du travail de la sixième séance==
* Test du fonctionnement du système complet
Problèmes rencontrés:
on a eu plusieurs bug sur la partie RPI. On a eu du mal à faire les liaisons série entre les deux arduino.

* Préparation de l'oral et finition du poster

=Rendu=

==Poster==
Version électronique du poster :
[[Fichier:2017_IOT_P5_poster.png|center|500px]]

==Fichiers rendus==

Notre application : [[Media:2017_IOT_P0_application.zip]]

P5 IOT 2017

2018-01-29T02:38:54Z

Mdiop : /* Détail du travail de la cinquième séance */

=Présentation du sujet =

==Contexte==

Nous effectuons ce projet dans le cadre du module internet des objets (Internet of things).

L'objectif de ce module est de créer l'objet connecté de notre choix.

Nous avons donc choisi de créer un objet en rapport avec la sécurité routière: le système Safe&Drive.

==Description du projet==

Pour veiller au respect des distances de sécurité, le système S&D va tout d'abord évaluer la distance entre votre voiture et celle qui vous suit.

Grâce au GPS intégré, la distance de sécurité à respecter sera calculée en fonction de votre vitesse de circulation.

Si cette distance de sécurité n'est pas respectée, un message de mise en garde sera affiché sur votre pare-brise arrière à destination du conducteur qui vous suit de trop prêt.

Bien évidemment, ce message ne sera envoyé qu'après confirmation de l'utilisateur depuis l'application mobile du système Safe&Drive.

En mode marche arrière, le système devient une aide à la manœuvre avec une caméra de recul et un détecteur d'obstacle.

=Réalisation=

==Matériel utilisé==

* Raspberry Pi
* Arduino Uno
* Arduino Mega2560
* SparkFun GPS Shield
* Adafruit 64x32 RGB LED Matrix - 5mm pitch
* Garmin LIDAR-Lite v3

==Suivi de réalisation==
{| class="wikitable alternance centre"
|-
! scope="row" | Séance 1 (08/01/2018)
| Choix de l'objet + Choix du matériel
|-
! scope="row" | Séance 2 (09/01/2018)
| Circuit shield pour la matrice LED + Test Li-DAR Lite
|-
! scope="row" | Séance 3 (16/01/2018)
| Circuit shield pour la matrice LED + Test du shield GPS
|-
! scope="row" | Séance 4 (17/01/2018)
| Circuit shield pour la matrice LED + Test Shield GPS
|-
! scope="row" | Séance 5 (22/01/2018)
| Soudage circuit shield pour la matrice LED + Test LED Matrix + RaspberryPI + Application mobile
|-
! scope="row" | Séance 6 (24/01/2018)
| Finitions + Resolutions des problèmes + Préparation orale (+poster)
|}

==Détail du travail de la première séance==

Pour choisir notre projet nous avons débuté en faisant un pseudo-brainstorming duquel est ressorti 4 projets.

Nous donc dû réduire notre choix à un seul de ces quatre possibilités.

Notre choix final s'est donc porté sur le système Safe&Drive.

Après avoir affiné les divers fonctionnalités de notre projet, nous avons commencé à réunir le matériel dont nous aurions besoin.

==Détail du travail de la deuxième séance==

* Début de la création du shield de la matrice de LED qui viendra se positionner sur l’Arduino Mega2560.

* Test du capteur optique LI-DAR Lite et codage du programme pour le calcul de distance.

<pre>

LIDARLite Arduino Library
GetDistanceI2c

This example shows how to initialize, configure, and read distance from a
LIDAR-Lite connected over the I2C interface.

Connections:
LIDAR-Lite 5 Vdc (red) to Arduino 5v
LIDAR-Lite I2C SCL (green) to Arduino SCL
LIDAR-Lite I2C SDA (blue) to Arduino SDA
LIDAR-Lite Ground (black) to Arduino GND

(Capacitor recommended to mitigate inrush current when device is enabled)
680uF capacitor (+) to Arduino 5v
680uF capacitor (-) to Arduino GND

See the Operation Manual for wiring diagrams and more information:
http://www.robotshop.com/media/files/pdf2/pli-06-instruction.pdf

-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

#include <Wire.h>
#include <LIDARLite.h>

LIDARLite myLidarLite;
int distance_reelle ;

void setup()
{
Serial.begin(9600); // Initialize serial connection to display distance readings

myLidarLite.begin(0, true); // Set configuration to default and I2C to 400 kHz

myLidarLite.configure(0); // Change this number to try out alternate configurations
}

void loop()
{

// Take a measurement with receiver bias correction and print to serial terminal
distance_reelle = (myLidarLite.distance());
if(distance_reelle < 1)
{
Serial.println('O');
}
else
{
Serial.println('N');
}
}

</pre>

==Détail du travail de la troisième séance==

* Poursuite de la création du circuit (shield) pour la matrice LED.
Cela n'a pas été une tâche facile en raison de la répartition des différentes pâtes dont nous avions besoin et des liaisons à effectuer.

* Test du GPS et codage du programme de calcul de vitesse.
Nous avons rencontré des problèmes avec le GPS, celui-ci ne renvoyait des message d'erreurs "NO GPS DETECTED" ou bien des données nulles du type "Date: 00/00/0000".

==Détail du travail de la quatrième séance==

* Finition du circuit (shield) pour la matrice LED et envoi de la demande de fabrication

Nous avons rencontré un problème avec le logiciel nous avons donc dû refaire entièrement le circuit, cela nous a pas mal retardé dans notre projet.

[[Fichier:Circuitp5.jpg|200px|]]
[[Fichier:circuit_bottom.jpg|200px|]]

* Test du GPS et résolution des problèmes.
Nous avons rencontré beaucoup de problèmes avec le GPS, celui-ci se connectait bien aux satellites mais ne nous renvoyait que des données nulles ou bien un message d'erreur.

Il s'est en faite avéré que selon la position du GPS receiver sur le shield celui-ci affichait ou non les données.

Le problème a donc été résolu. Voici le code:

<pre>}

#include <TinyGPS++.h>
#include <SoftwareSerial.h>
#include <Wire.h>
/*
This example uses software serial and the TinyGPS++ library by Mikal Hart
Based on TinyGPSPlus/DeviceExample.ino by Mikal Hart
Modified by acavis
*/

// Choose two Arduino pins to use for software serial
// The GPS Shield uses D2 and D3 by default when in DLINE mode
int RXPin = 50;
int TXPin = 3;

// The Skytaq EM-506 GPS module included in the GPS Shield Kit
// uses 4800 baud by default
int GPSBaud = 4800;

// Create a TinyGPS++ object called "gps"
TinyGPSPlus gps;

// Create a software serial port called "gpsSerial"
SoftwareSerial gpsSerial(RXPin, TXPin);

void setup()
{
// Start the Arduino hardware serial port at 9600 baud
Serial.begin(9600);

// Start the software serial port at the GPS's default baud
gpsSerial.begin(GPSBaud);

Serial.println(F("DeviceExample.ino"));
Serial.println(F("A simple demonstration of TinyGPS++ with an attached GPS module"));
Serial.print(F("Testing TinyGPS++ library v. ")); Serial.println(TinyGPSPlus::libraryVersion());
Serial.println(F("by Mikal Hart"));
Serial.println();

}

void loop()
{
// This sketch displays information every time a new sentence is correctly encoded.
while (gpsSerial.available() > 0)
if (gps.encode(gpsSerial.read()))
displayInfo();

// If 5000 milliseconds pass and there are no characters coming in
// over the software serial port, show a "No GPS detected" error
if (millis() > 5000 && gps.charsProcessed() < 10)
{
Serial.println(F("No GPS detected"));
while(true);
}
}

void displayInfo()
{
Serial.print(F("Speed: "));
if (gps.speed.isValid())
{
Serial.print(gps.speed.kmph(), 6);
}
else
{
Serial.print(F("INVALID"));
}

Serial.println();

secure_dist = (gps.speed.kmph()/10)*6;
Serial.print("distance de sécurite (en m)= ");
Serial.print(secure_dist);
Serial.println();

}

</pre>

==Détail du travail de la cinquième séance==
* Soudage des barrettes et des ponts sur le circuit pour la Matrice LED (Shield)

* Test de la matrice LED et codage du programme pour l'affichage d'un message personnalisé coloré
Message choisi: Ne me collez pas au cul, PUTAIN!!
Voici le code pour l'affichage du message. Celle-ci se fait grâce à un liaison série entre la raspberry Pi (RPI) et la matrice de de LED connectée à l’arduino Mega à travers le shield.

Voici le code pour l'affichage:

<pre>

/***************************************************
*
*NOTE THIS CAN ONLY BE USED ON A MEGA! NOT ENOUGH RAM ON UNO!
*
***************************************************
* 64x32 RGB LED Matrix - 4mm pitch
* ****************************************************
* testshapes demo for RGBmatrixPanel library.
* Demonstrates the drawing abilities of the RGBmatrixPanel library.
* For 32x64 RGB LED matrix.

* @author lg.gang(lg.gang@qq.com)
* @version V1.0
* @date 2016-9-6

* GNU Lesser General Public License.
* See <http://www.gnu.org/licenses/> for details.
* All above must be included in any redistribution
* ****************************************************/
#include <Adafruit_GFX.h> // Core graphics library
#include <RGBmatrixPanel.h> // Hardware-specific library

#define CLK 11
#define OE 9
#define LAT 10

#define A A0
#define B A1
#define C A2
#define D A3

RGBmatrixPanel matrix(A, B, C, D, CLK, LAT, OE, false, 64);
char msg;

void setup() {
Serial.begin(9600);
delay(1000);
matrix.begin();

}

void loop() {

// draw a pixel in solid white
//matrix.drawPixel(0, 0, matrix.Color333(7, 7, 7));
//delay(5000);

// fix the screen with green
//matrix.fillRect(0, 0, matrix.width(), matrix.height(), matrix.Color333(0, 7, 0));
//delay(5000);

// fix the screen with white
//matrix.fillRect(0, 0, matrix.width(), matrix.height(), matrix.Color333(7, 7, 7));
//delay(5000);

// fix the screen with red
//matrix.fillRect(0, 0, matrix.width(), matrix.height(), matrix.Color333(7, 0, 0));
//delay(5000);

// fix the screen with blue
//matrix.fillRect(0, 0, matrix.width(), matrix.height(), matrix.Color333(0, 0, 7));
//delay(5000);
// fill the screen with 'black'
//matrix.fillScreen(matrix.Color333(0, 0, 0));

// draw a box in yellow
//matrix.drawRect(0, 0, matrix.width(), matrix.height(), matrix.Color333(7, 7, 0));
//delay(5000);

// draw a box in fuchsia
//matrix.drawRect(5, 5, 53, 23, matrix.Color333(7, 0, 7));
//delay(5000);

// draw a box in yellow
//matrix.drawRect(10, 10, 43, 13, matrix.Color333(7, 1, 3));
//delay(5000);

// draw an 'X' in red
//matrix.drawLine(0, 0, matrix.width()-1, matrix.height()-1, matrix.Color333(7, 0, 0));
//matrix.drawLine(matrix.width()-1, 0, 0, matrix.height()-1, matrix.Color333(7, 0, 0));
//delay(5000);

// draw a blue circle
//matrix.drawCircle(10, 10, 10, matrix.Color333(0, 0, 7));
//delay(5000);

// fill a violet circle
//matrix.fillCircle(40, 21, 10, matrix.Color333(7, 0, 7));
//delay(5000);

// fill the screen with 'black'
//matrix.fillScreen(matrix.Color333(0, 0, 0));

while (Serial.available() > 0) {

//msg = Serial.read();

//Serial.print(msg);
if(Serial.read() == 'o'){
// draw some text!
matrix.setTextSize(1); // size 1 == 8 pixels high
matrix.setTextWrap(false); // Don't wrap at end of line - will do ourselves
matrix.setCursor(3, 0); // start at top left, with 3 pixel of spacing
uint8_t w = 0;
char *str = " Ne me collez";
for (w=0; w<10; w++) {
matrix.setTextColor(Wheel(w));
matrix.print(str[w]);
}

matrix.setCursor(13, 8); // next line
for (w=10; w<17; w++) {
matrix.setTextColor(Wheel(w));
matrix.print(str[w]);
}

matrix.println();
matrix.setCursor(2, 16);
matrix.setTextColor(matrix.Color333(7,1,0));
matrix.print('p');
matrix.setTextColor(matrix.Color333(7,3,0));
matrix.print('a');
matrix.setTextColor(matrix.Color333(7,7,0));
matrix.print('s');
matrix.setTextColor(matrix.Color333(4,7,0));
matrix.print(' ');
matrix.setTextColor(matrix.Color333(0,7,0));
matrix.print('a');
matrix.setTextColor(matrix.Color333(0,7,7));
matrix.print('u');
matrix.setTextColor(matrix.Color333(0,4,7));
matrix.print(' ');
matrix.setTextColor(matrix.Color333(7,0,0));
matrix.print('c');
matrix.setTextColor(matrix.Color333(7,0,0));
matrix.print('u');
matrix.setTextColor(matrix.Color333(7,0,0));
matrix.print('l');
//matrix.setTextColor(matrix.Color333(7,7,7));
//matrix.println("pas au Cul");

// print each letter with a rainbow color
matrix.setCursor(3, 24);
matrix.setTextColor(matrix.Color333(7,0,0));
matrix.print(' ');
matrix.setTextColor(matrix.Color333(7,1,0));
matrix.print('P');
matrix.setTextColor(matrix.Color333(7,3,0));
matrix.print('U');
matrix.setTextColor(matrix.Color333(4,7,0));
matrix.print('T');
matrix.setTextColor(matrix.Color333(0,7,0));
matrix.print('A');
matrix.setTextColor(matrix.Color333(0,7,7));
matrix.print('I');
matrix.setTextColor(matrix.Color333(0,4,7));
matrix.print('N');
matrix.setTextColor(matrix.Color333(0,0,7));
matrix.print('!');
matrix.setTextColor(matrix.Color333(4,0,7));
matrix.print('!');
matrix.setTextColor(matrix.Color333(7,0,4));
matrix.println(' ');
//delay(50000);

} else {matrix.fillScreen(0);}
}

}

// Input a value 0 to 24 to get a color value.
// The colours are a transition r - g - b - back to r.
uint16_t Wheel(byte WheelPos) {
if(WheelPos < 8) {
return matrix.Color333(7 - WheelPos, WheelPos, 0);
} else if(WheelPos < 16) {
WheelPos -= 8;
return matrix.Color333(0, 7-WheelPos, WheelPos);
} else {
WheelPos -= 16;
return matrix.Color333(0, WheelPos, 7 - WheelPos);
}
}

</pre>

* Configuartion de la RPI

La raspberry pi (RPI) est chargé de recueillir la confirmation de l'utilisateur à travers l'application mobile, une fois ceci fait, elle lit les données envoyées provenant du traitement d'information sur la distance de sécurité et celle réelle avant de les envoyé vers le programme traitant de l'affichage du message. En fonction du message envoyé (dans notre cas c'est un caractère: 'O' ou 'o' si le message doit être envoyé et 'n' ou 'N' si c'est le contraire). Voici le code:

<pre>

from bluetooth import *
import time
import serial

server_sock=BluetoothSocket( RFCOMM )
server_sock.bind(("",PORT_ANY))
server_sock.listen(1)

port = server_sock.getsockname()[1]

uuid = "94f39d29-7d6d-437d-973b-fba39e49d4ee"

advertise_service( server_sock, "SampleServer",
service_id = uuid,
service_classes = [ uuid, SERIAL_PORT_CLASS ],
profiles = [ SERIAL_PORT_PROFILE ],
# protocols = [ OBEX_UUID ]
)

print("Waiting for connection on RFCOMM channel %d" % port)

client_sock, client_info = server_sock.accept()
print("Accepted connection from ", client_info)

ser0 = serial.Serial('/dev/ttyACM0')
Ser1 = serial.SERIAL('/dev/ttyACM1')

try:
while True:
data = ""
client_sock.recv(data)
data2 = ser1.read();
if data2 == 'O'
ser0.write('o')
if data2 == 'N'
ser0.write('n')
except IOError:
pass

print("disconnected")

client_sock.close()
server_sock.close()
print("all done")
</pre>

* Codage de l'application Mobile
Elle a pour but de permettre à l'utilisateur de se connecter, via bluetooth, à la RPI et de lui envoyer sa confirmation. Celui-ci peut également se déconnecter, s'il le souhaite.
[[Fichier:Appli iot.PNG|200px|]]

==Détail du travail de la sixième séance==
* Test du fonctionnement du système complet
Problèmes rencontrés:

'''[Partie ARAME]'''

''[INSERER Code final]''

* Préparation de l'oral et finition du poster

=Rendu=

==Poster==
Version électronique du poster :
[[Fichier:2017_IOT_P5_poster.png|center|500px]]

==Fichiers rendus==

Notre application : [[Media:2017_IOT_P0_application.zip]]

P5 IOT 2017

2018-01-29T02:35:49Z

Mdiop : /* Détail du travail de la cinquième séance */

=Présentation du sujet =

==Contexte==

Nous effectuons ce projet dans le cadre du module internet des objets (Internet of things).

L'objectif de ce module est de créer l'objet connecté de notre choix.

Nous avons donc choisi de créer un objet en rapport avec la sécurité routière: le système Safe&Drive.

==Description du projet==

Pour veiller au respect des distances de sécurité, le système S&D va tout d'abord évaluer la distance entre votre voiture et celle qui vous suit.

Grâce au GPS intégré, la distance de sécurité à respecter sera calculée en fonction de votre vitesse de circulation.

Si cette distance de sécurité n'est pas respectée, un message de mise en garde sera affiché sur votre pare-brise arrière à destination du conducteur qui vous suit de trop prêt.

Bien évidemment, ce message ne sera envoyé qu'après confirmation de l'utilisateur depuis l'application mobile du système Safe&Drive.

En mode marche arrière, le système devient une aide à la manœuvre avec une caméra de recul et un détecteur d'obstacle.

=Réalisation=

==Matériel utilisé==

* Raspberry Pi
* Arduino Uno
* Arduino Mega2560
* SparkFun GPS Shield
* Adafruit 64x32 RGB LED Matrix - 5mm pitch
* Garmin LIDAR-Lite v3

==Suivi de réalisation==
{| class="wikitable alternance centre"
|-
! scope="row" | Séance 1 (08/01/2018)
| Choix de l'objet + Choix du matériel
|-
! scope="row" | Séance 2 (09/01/2018)
| Circuit shield pour la matrice LED + Test Li-DAR Lite
|-
! scope="row" | Séance 3 (16/01/2018)
| Circuit shield pour la matrice LED + Test du shield GPS
|-
! scope="row" | Séance 4 (17/01/2018)
| Circuit shield pour la matrice LED + Test Shield GPS
|-
! scope="row" | Séance 5 (22/01/2018)
| Soudage circuit shield pour la matrice LED + Test LED Matrix + RaspberryPI + Application mobile
|-
! scope="row" | Séance 6 (24/01/2018)
| Finitions + Resolutions des problèmes + Préparation orale (+poster)
|}

==Détail du travail de la première séance==

Pour choisir notre projet nous avons débuté en faisant un pseudo-brainstorming duquel est ressorti 4 projets.

Nous donc dû réduire notre choix à un seul de ces quatre possibilités.

Notre choix final s'est donc porté sur le système Safe&Drive.

Après avoir affiné les divers fonctionnalités de notre projet, nous avons commencé à réunir le matériel dont nous aurions besoin.

==Détail du travail de la deuxième séance==

* Début de la création du shield de la matrice de LED qui viendra se positionner sur l’Arduino Mega2560.

* Test du capteur optique LI-DAR Lite et codage du programme pour le calcul de distance.

<pre>

LIDARLite Arduino Library
GetDistanceI2c

This example shows how to initialize, configure, and read distance from a
LIDAR-Lite connected over the I2C interface.

Connections:
LIDAR-Lite 5 Vdc (red) to Arduino 5v
LIDAR-Lite I2C SCL (green) to Arduino SCL
LIDAR-Lite I2C SDA (blue) to Arduino SDA
LIDAR-Lite Ground (black) to Arduino GND

(Capacitor recommended to mitigate inrush current when device is enabled)
680uF capacitor (+) to Arduino 5v
680uF capacitor (-) to Arduino GND

See the Operation Manual for wiring diagrams and more information:
http://www.robotshop.com/media/files/pdf2/pli-06-instruction.pdf

-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

#include <Wire.h>
#include <LIDARLite.h>

LIDARLite myLidarLite;
int distance_reelle ;

void setup()
{
Serial.begin(9600); // Initialize serial connection to display distance readings

myLidarLite.begin(0, true); // Set configuration to default and I2C to 400 kHz

myLidarLite.configure(0); // Change this number to try out alternate configurations
}

void loop()
{

// Take a measurement with receiver bias correction and print to serial terminal
distance_reelle = (myLidarLite.distance());
if(distance_reelle < 1)
{
Serial.println('O');
}
else
{
Serial.println('N');
}
}

</pre>

==Détail du travail de la troisième séance==

* Poursuite de la création du circuit (shield) pour la matrice LED.
Cela n'a pas été une tâche facile en raison de la répartition des différentes pâtes dont nous avions besoin et des liaisons à effectuer.

* Test du GPS et codage du programme de calcul de vitesse.
Nous avons rencontré des problèmes avec le GPS, celui-ci ne renvoyait des message d'erreurs "NO GPS DETECTED" ou bien des données nulles du type "Date: 00/00/0000".

==Détail du travail de la quatrième séance==

* Finition du circuit (shield) pour la matrice LED et envoi de la demande de fabrication

Nous avons rencontré un problème avec le logiciel nous avons donc dû refaire entièrement le circuit, cela nous a pas mal retardé dans notre projet.

[[Fichier:Circuitp5.jpg|200px|]]
[[Fichier:circuit_bottom.jpg|200px|]]

* Test du GPS et résolution des problèmes.
Nous avons rencontré beaucoup de problèmes avec le GPS, celui-ci se connectait bien aux satellites mais ne nous renvoyait que des données nulles ou bien un message d'erreur.

Il s'est en faite avéré que selon la position du GPS receiver sur le shield celui-ci affichait ou non les données.

Le problème a donc été résolu. Voici le code:

<pre>}

#include <TinyGPS++.h>
#include <SoftwareSerial.h>
#include <Wire.h>
/*
This example uses software serial and the TinyGPS++ library by Mikal Hart
Based on TinyGPSPlus/DeviceExample.ino by Mikal Hart
Modified by acavis
*/

// Choose two Arduino pins to use for software serial
// The GPS Shield uses D2 and D3 by default when in DLINE mode
int RXPin = 50;
int TXPin = 3;

// The Skytaq EM-506 GPS module included in the GPS Shield Kit
// uses 4800 baud by default
int GPSBaud = 4800;

// Create a TinyGPS++ object called "gps"
TinyGPSPlus gps;

// Create a software serial port called "gpsSerial"
SoftwareSerial gpsSerial(RXPin, TXPin);

void setup()
{
// Start the Arduino hardware serial port at 9600 baud
Serial.begin(9600);

// Start the software serial port at the GPS's default baud
gpsSerial.begin(GPSBaud);

Serial.println(F("DeviceExample.ino"));
Serial.println(F("A simple demonstration of TinyGPS++ with an attached GPS module"));
Serial.print(F("Testing TinyGPS++ library v. ")); Serial.println(TinyGPSPlus::libraryVersion());
Serial.println(F("by Mikal Hart"));
Serial.println();

}

void loop()
{
// This sketch displays information every time a new sentence is correctly encoded.
while (gpsSerial.available() > 0)
if (gps.encode(gpsSerial.read()))
displayInfo();

// If 5000 milliseconds pass and there are no characters coming in
// over the software serial port, show a "No GPS detected" error
if (millis() > 5000 && gps.charsProcessed() < 10)
{
Serial.println(F("No GPS detected"));
while(true);
}
}

void displayInfo()
{
Serial.print(F("Speed: "));
if (gps.speed.isValid())
{
Serial.print(gps.speed.kmph(), 6);
}
else
{
Serial.print(F("INVALID"));
}

Serial.println();

secure_dist = (gps.speed.kmph()/10)*6;
Serial.print("distance de sécurite (en m)= ");
Serial.print(secure_dist);
Serial.println();

}

</pre>

==Détail du travail de la cinquième séance==
* Soudage des barrettes et des ponts sur le circuit pour la Matrice LED (Shield)

* Test de la matrice LED et codage du programme pour l'affichage d'un message personnalisé coloré
Message choisi: Ne me collez pas au cul, PUTAIN!!
Voici le code pour l'affichage du message. Celle-ci se fait grâce à un liaison série entre la raspberry Pi (RPI) et la matrice de de LED connectée à l’arduino Mega à travers le shield.

Voici le code pour l'affichage:

<pre>

/***************************************************
*
*NOTE THIS CAN ONLY BE USED ON A MEGA! NOT ENOUGH RAM ON UNO!
*
***************************************************
* 64x32 RGB LED Matrix - 4mm pitch
* ****************************************************
* testshapes demo for RGBmatrixPanel library.
* Demonstrates the drawing abilities of the RGBmatrixPanel library.
* For 32x64 RGB LED matrix.

* @author lg.gang(lg.gang@qq.com)
* @version V1.0
* @date 2016-9-6

* GNU Lesser General Public License.
* See <http://www.gnu.org/licenses/> for details.
* All above must be included in any redistribution
* ****************************************************/
#include <Adafruit_GFX.h> // Core graphics library
#include <RGBmatrixPanel.h> // Hardware-specific library

#define CLK 11
#define OE 9
#define LAT 10

#define A A0
#define B A1
#define C A2
#define D A3

RGBmatrixPanel matrix(A, B, C, D, CLK, LAT, OE, false, 64);
char msg;

void setup() {
Serial.begin(9600);
delay(1000);
matrix.begin();

}

void loop() {

// draw a pixel in solid white
//matrix.drawPixel(0, 0, matrix.Color333(7, 7, 7));
//delay(5000);

// fix the screen with green
//matrix.fillRect(0, 0, matrix.width(), matrix.height(), matrix.Color333(0, 7, 0));
//delay(5000);

// fix the screen with white
//matrix.fillRect(0, 0, matrix.width(), matrix.height(), matrix.Color333(7, 7, 7));
//delay(5000);

// fix the screen with red
//matrix.fillRect(0, 0, matrix.width(), matrix.height(), matrix.Color333(7, 0, 0));
//delay(5000);

// fix the screen with blue
//matrix.fillRect(0, 0, matrix.width(), matrix.height(), matrix.Color333(0, 0, 7));
//delay(5000);
// fill the screen with 'black'
//matrix.fillScreen(matrix.Color333(0, 0, 0));

// draw a box in yellow
//matrix.drawRect(0, 0, matrix.width(), matrix.height(), matrix.Color333(7, 7, 0));
//delay(5000);

// draw a box in fuchsia
//matrix.drawRect(5, 5, 53, 23, matrix.Color333(7, 0, 7));
//delay(5000);

// draw a box in yellow
//matrix.drawRect(10, 10, 43, 13, matrix.Color333(7, 1, 3));
//delay(5000);

// draw an 'X' in red
//matrix.drawLine(0, 0, matrix.width()-1, matrix.height()-1, matrix.Color333(7, 0, 0));
//matrix.drawLine(matrix.width()-1, 0, 0, matrix.height()-1, matrix.Color333(7, 0, 0));
//delay(5000);

// draw a blue circle
//matrix.drawCircle(10, 10, 10, matrix.Color333(0, 0, 7));
//delay(5000);

// fill a violet circle
//matrix.fillCircle(40, 21, 10, matrix.Color333(7, 0, 7));
//delay(5000);

// fill the screen with 'black'
//matrix.fillScreen(matrix.Color333(0, 0, 0));

while (Serial.available() > 0) {

//msg = Serial.read();

//Serial.print(msg);
if(Serial.read() == 'o'){
// draw some text!
matrix.setTextSize(1); // size 1 == 8 pixels high
matrix.setTextWrap(false); // Don't wrap at end of line - will do ourselves
matrix.setCursor(3, 0); // start at top left, with 3 pixel of spacing
uint8_t w = 0;
char *str = " Ne me collez";
for (w=0; w<10; w++) {
matrix.setTextColor(Wheel(w));
matrix.print(str[w]);
}

matrix.setCursor(13, 8); // next line
for (w=10; w<17; w++) {
matrix.setTextColor(Wheel(w));
matrix.print(str[w]);
}

matrix.println();
matrix.setCursor(2, 16);
matrix.setTextColor(matrix.Color333(7,1,0));
matrix.print('p');
matrix.setTextColor(matrix.Color333(7,3,0));
matrix.print('a');
matrix.setTextColor(matrix.Color333(7,7,0));
matrix.print('s');
matrix.setTextColor(matrix.Color333(4,7,0));
matrix.print(' ');
matrix.setTextColor(matrix.Color333(0,7,0));
matrix.print('a');
matrix.setTextColor(matrix.Color333(0,7,7));
matrix.print('u');
matrix.setTextColor(matrix.Color333(0,4,7));
matrix.print(' ');
matrix.setTextColor(matrix.Color333(7,0,0));
matrix.print('c');
matrix.setTextColor(matrix.Color333(7,0,0));
matrix.print('u');
matrix.setTextColor(matrix.Color333(7,0,0));
matrix.print('l');
//matrix.setTextColor(matrix.Color333(7,7,7));
//matrix.println("pas au Cul");

// print each letter with a rainbow color
matrix.setCursor(3, 24);
matrix.setTextColor(matrix.Color333(7,0,0));
matrix.print(' ');
matrix.setTextColor(matrix.Color333(7,1,0));
matrix.print('P');
matrix.setTextColor(matrix.Color333(7,3,0));
matrix.print('U');
matrix.setTextColor(matrix.Color333(4,7,0));
matrix.print('T');
matrix.setTextColor(matrix.Color333(0,7,0));
matrix.print('A');
matrix.setTextColor(matrix.Color333(0,7,7));
matrix.print('I');
matrix.setTextColor(matrix.Color333(0,4,7));
matrix.print('N');
matrix.setTextColor(matrix.Color333(0,0,7));
matrix.print('!');
matrix.setTextColor(matrix.Color333(4,0,7));
matrix.print('!');
matrix.setTextColor(matrix.Color333(7,0,4));
matrix.println(' ');
//delay(50000);

} else {matrix.fillScreen(0);}
}

}

// Input a value 0 to 24 to get a color value.
// The colours are a transition r - g - b - back to r.
uint16_t Wheel(byte WheelPos) {
if(WheelPos < 8) {
return matrix.Color333(7 - WheelPos, WheelPos, 0);
} else if(WheelPos < 16) {
WheelPos -= 8;
return matrix.Color333(0, 7-WheelPos, WheelPos);
} else {
WheelPos -= 16;
return matrix.Color333(0, WheelPos, 7 - WheelPos);
}
}

</pre>

* Configuartion de la RPI

La raspberry pi (RPI) est chargé de recueillir la confirmation de l'utilisateur à travers l'application mobile, une fois ceci fait, elle lit les données envoyées provenant du traitement d'information sur la distance de sécurité et celle réelle avant de les envoyé vers le programme traitant de l'affichage du message. En fonction du message envoyé (dans notre cas c'est un caractère: 'O' ou 'o' si le message doit être envoyé et 'n' ou 'N' si c'est le contraire). Voici le code:

<pre>

from bluetooth import *
import time
import serial

server_sock=BluetoothSocket( RFCOMM )
server_sock.bind(("",PORT_ANY))
server_sock.listen(1)

port = server_sock.getsockname()[1]

uuid = "94f39d29-7d6d-437d-973b-fba39e49d4ee"

advertise_service( server_sock, "SampleServer",
service_id = uuid,
service_classes = [ uuid, SERIAL_PORT_CLASS ],
profiles = [ SERIAL_PORT_PROFILE ],
# protocols = [ OBEX_UUID ]
)

print("Waiting for connection on RFCOMM channel %d" % port)

client_sock, client_info = server_sock.accept()
print("Accepted connection from ", client_info)

ser0 = serial.Serial('/dev/ttyACM0')
Ser1 = serial.SERIAL('/dev/ttyACM1')

try:
while True:
data = ""
client_sock.recv(data)
data2 = ser1.read();
if data2 == 'O'
ser0.write('o')
if data2 == 'N'
ser0.write('n')
except IOError:
pass

print("disconnected")

client_sock.close()
server_sock.close()
print("all done")
</pre>

* Codage de l'application Mobile
Elle a pour but de permettre à l'utilisateur de se connecter, via bluetooth, à la RPI et de lui envoyer sa confirmation. Celui-ci peut également se déconnecter, s'il le souhaite.
[[Fichier:Appli_iot.png|200px|]]

==Détail du travail de la sixième séance==
* Test du fonctionnement du système complet
Problèmes rencontrés:

'''[Partie ARAME]'''

''[INSERER Code final]''

* Préparation de l'oral et finition du poster

=Rendu=

==Poster==
Version électronique du poster :
[[Fichier:2017_IOT_P5_poster.png|center|500px]]

==Fichiers rendus==

Notre application : [[Media:2017_IOT_P0_application.zip]]

P5 IOT 2017

2018-01-29T02:34:58Z

Mdiop : /* Détail du travail de la cinquième séance */

=Présentation du sujet =

==Contexte==

Nous effectuons ce projet dans le cadre du module internet des objets (Internet of things).

L'objectif de ce module est de créer l'objet connecté de notre choix.

Nous avons donc choisi de créer un objet en rapport avec la sécurité routière: le système Safe&Drive.

==Description du projet==

Pour veiller au respect des distances de sécurité, le système S&D va tout d'abord évaluer la distance entre votre voiture et celle qui vous suit.

Grâce au GPS intégré, la distance de sécurité à respecter sera calculée en fonction de votre vitesse de circulation.

Si cette distance de sécurité n'est pas respectée, un message de mise en garde sera affiché sur votre pare-brise arrière à destination du conducteur qui vous suit de trop prêt.

Bien évidemment, ce message ne sera envoyé qu'après confirmation de l'utilisateur depuis l'application mobile du système Safe&Drive.

En mode marche arrière, le système devient une aide à la manœuvre avec une caméra de recul et un détecteur d'obstacle.

=Réalisation=

==Matériel utilisé==

* Raspberry Pi
* Arduino Uno
* Arduino Mega2560
* SparkFun GPS Shield
* Adafruit 64x32 RGB LED Matrix - 5mm pitch
* Garmin LIDAR-Lite v3

==Suivi de réalisation==
{| class="wikitable alternance centre"
|-
! scope="row" | Séance 1 (08/01/2018)
| Choix de l'objet + Choix du matériel
|-
! scope="row" | Séance 2 (09/01/2018)
| Circuit shield pour la matrice LED + Test Li-DAR Lite
|-
! scope="row" | Séance 3 (16/01/2018)
| Circuit shield pour la matrice LED + Test du shield GPS
|-
! scope="row" | Séance 4 (17/01/2018)
| Circuit shield pour la matrice LED + Test Shield GPS
|-
! scope="row" | Séance 5 (22/01/2018)
| Soudage circuit shield pour la matrice LED + Test LED Matrix + RaspberryPI + Application mobile
|-
! scope="row" | Séance 6 (24/01/2018)
| Finitions + Resolutions des problèmes + Préparation orale (+poster)
|}

==Détail du travail de la première séance==

Pour choisir notre projet nous avons débuté en faisant un pseudo-brainstorming duquel est ressorti 4 projets.

Nous donc dû réduire notre choix à un seul de ces quatre possibilités.

Notre choix final s'est donc porté sur le système Safe&Drive.

Après avoir affiné les divers fonctionnalités de notre projet, nous avons commencé à réunir le matériel dont nous aurions besoin.

==Détail du travail de la deuxième séance==

* Début de la création du shield de la matrice de LED qui viendra se positionner sur l’Arduino Mega2560.

* Test du capteur optique LI-DAR Lite et codage du programme pour le calcul de distance.

<pre>

LIDARLite Arduino Library
GetDistanceI2c

This example shows how to initialize, configure, and read distance from a
LIDAR-Lite connected over the I2C interface.

Connections:
LIDAR-Lite 5 Vdc (red) to Arduino 5v
LIDAR-Lite I2C SCL (green) to Arduino SCL
LIDAR-Lite I2C SDA (blue) to Arduino SDA
LIDAR-Lite Ground (black) to Arduino GND

(Capacitor recommended to mitigate inrush current when device is enabled)
680uF capacitor (+) to Arduino 5v
680uF capacitor (-) to Arduino GND

See the Operation Manual for wiring diagrams and more information:
http://www.robotshop.com/media/files/pdf2/pli-06-instruction.pdf

-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

#include <Wire.h>
#include <LIDARLite.h>

LIDARLite myLidarLite;
int distance_reelle ;

void setup()
{
Serial.begin(9600); // Initialize serial connection to display distance readings

myLidarLite.begin(0, true); // Set configuration to default and I2C to 400 kHz

myLidarLite.configure(0); // Change this number to try out alternate configurations
}

void loop()
{

// Take a measurement with receiver bias correction and print to serial terminal
distance_reelle = (myLidarLite.distance());
if(distance_reelle < 1)
{
Serial.println('O');
}
else
{
Serial.println('N');
}
}

</pre>

==Détail du travail de la troisième séance==

* Poursuite de la création du circuit (shield) pour la matrice LED.
Cela n'a pas été une tâche facile en raison de la répartition des différentes pâtes dont nous avions besoin et des liaisons à effectuer.

* Test du GPS et codage du programme de calcul de vitesse.
Nous avons rencontré des problèmes avec le GPS, celui-ci ne renvoyait des message d'erreurs "NO GPS DETECTED" ou bien des données nulles du type "Date: 00/00/0000".

==Détail du travail de la quatrième séance==

* Finition du circuit (shield) pour la matrice LED et envoi de la demande de fabrication

Nous avons rencontré un problème avec le logiciel nous avons donc dû refaire entièrement le circuit, cela nous a pas mal retardé dans notre projet.

[[Fichier:Circuitp5.jpg|200px|]]
[[Fichier:circuit_bottom.jpg|200px|]]

* Test du GPS et résolution des problèmes.
Nous avons rencontré beaucoup de problèmes avec le GPS, celui-ci se connectait bien aux satellites mais ne nous renvoyait que des données nulles ou bien un message d'erreur.

Il s'est en faite avéré que selon la position du GPS receiver sur le shield celui-ci affichait ou non les données.

Le problème a donc été résolu. Voici le code:

<pre>}

#include <TinyGPS++.h>
#include <SoftwareSerial.h>
#include <Wire.h>
/*
This example uses software serial and the TinyGPS++ library by Mikal Hart
Based on TinyGPSPlus/DeviceExample.ino by Mikal Hart
Modified by acavis
*/

// Choose two Arduino pins to use for software serial
// The GPS Shield uses D2 and D3 by default when in DLINE mode
int RXPin = 50;
int TXPin = 3;

// The Skytaq EM-506 GPS module included in the GPS Shield Kit
// uses 4800 baud by default
int GPSBaud = 4800;

// Create a TinyGPS++ object called "gps"
TinyGPSPlus gps;

// Create a software serial port called "gpsSerial"
SoftwareSerial gpsSerial(RXPin, TXPin);

void setup()
{
// Start the Arduino hardware serial port at 9600 baud
Serial.begin(9600);

// Start the software serial port at the GPS's default baud
gpsSerial.begin(GPSBaud);

Serial.println(F("DeviceExample.ino"));
Serial.println(F("A simple demonstration of TinyGPS++ with an attached GPS module"));
Serial.print(F("Testing TinyGPS++ library v. ")); Serial.println(TinyGPSPlus::libraryVersion());
Serial.println(F("by Mikal Hart"));
Serial.println();

}

void loop()
{
// This sketch displays information every time a new sentence is correctly encoded.
while (gpsSerial.available() > 0)
if (gps.encode(gpsSerial.read()))
displayInfo();

// If 5000 milliseconds pass and there are no characters coming in
// over the software serial port, show a "No GPS detected" error
if (millis() > 5000 && gps.charsProcessed() < 10)
{
Serial.println(F("No GPS detected"));
while(true);
}
}

void displayInfo()
{
Serial.print(F("Speed: "));
if (gps.speed.isValid())
{
Serial.print(gps.speed.kmph(), 6);
}
else
{
Serial.print(F("INVALID"));
}

Serial.println();

secure_dist = (gps.speed.kmph()/10)*6;
Serial.print("distance de sécurite (en m)= ");
Serial.print(secure_dist);
Serial.println();

}

</pre>

==Détail du travail de la cinquième séance==
* Soudage des barrettes et des ponts sur le circuit pour la Matrice LED (Shield)

* Test de la matrice LED et codage du programme pour l'affichage d'un message personnalisé coloré
Message choisi: Ne me collez pas au cul, PUTAIN!!
Voici le code pour l'affichage du message. Celle-ci se fait grâce à un liaison série entre la raspberry Pi (RPI) et la matrice de de LED connectée à l’arduino Mega à travers le shield.

Voici le code pour l'affichage:

<pre>

/***************************************************
*
*NOTE THIS CAN ONLY BE USED ON A MEGA! NOT ENOUGH RAM ON UNO!
*
***************************************************
* 64x32 RGB LED Matrix - 4mm pitch
* ****************************************************
* testshapes demo for RGBmatrixPanel library.
* Demonstrates the drawing abilities of the RGBmatrixPanel library.
* For 32x64 RGB LED matrix.

* @author lg.gang(lg.gang@qq.com)
* @version V1.0
* @date 2016-9-6

* GNU Lesser General Public License.
* See <http://www.gnu.org/licenses/> for details.
* All above must be included in any redistribution
* ****************************************************/
#include <Adafruit_GFX.h> // Core graphics library
#include <RGBmatrixPanel.h> // Hardware-specific library

#define CLK 11
#define OE 9
#define LAT 10

#define A A0
#define B A1
#define C A2
#define D A3

RGBmatrixPanel matrix(A, B, C, D, CLK, LAT, OE, false, 64);
char msg;

void setup() {
Serial.begin(9600);
delay(1000);
matrix.begin();

}

void loop() {

// draw a pixel in solid white
//matrix.drawPixel(0, 0, matrix.Color333(7, 7, 7));
//delay(5000);

// fix the screen with green
//matrix.fillRect(0, 0, matrix.width(), matrix.height(), matrix.Color333(0, 7, 0));
//delay(5000);

// fix the screen with white
//matrix.fillRect(0, 0, matrix.width(), matrix.height(), matrix.Color333(7, 7, 7));
//delay(5000);

// fix the screen with red
//matrix.fillRect(0, 0, matrix.width(), matrix.height(), matrix.Color333(7, 0, 0));
//delay(5000);

// fix the screen with blue
//matrix.fillRect(0, 0, matrix.width(), matrix.height(), matrix.Color333(0, 0, 7));
//delay(5000);
// fill the screen with 'black'
//matrix.fillScreen(matrix.Color333(0, 0, 0));

// draw a box in yellow
//matrix.drawRect(0, 0, matrix.width(), matrix.height(), matrix.Color333(7, 7, 0));
//delay(5000);

// draw a box in fuchsia
//matrix.drawRect(5, 5, 53, 23, matrix.Color333(7, 0, 7));
//delay(5000);

// draw a box in yellow
//matrix.drawRect(10, 10, 43, 13, matrix.Color333(7, 1, 3));
//delay(5000);

// draw an 'X' in red
//matrix.drawLine(0, 0, matrix.width()-1, matrix.height()-1, matrix.Color333(7, 0, 0));
//matrix.drawLine(matrix.width()-1, 0, 0, matrix.height()-1, matrix.Color333(7, 0, 0));
//delay(5000);

// draw a blue circle
//matrix.drawCircle(10, 10, 10, matrix.Color333(0, 0, 7));
//delay(5000);

// fill a violet circle
//matrix.fillCircle(40, 21, 10, matrix.Color333(7, 0, 7));
//delay(5000);

// fill the screen with 'black'
//matrix.fillScreen(matrix.Color333(0, 0, 0));

while (Serial.available() > 0) {

//msg = Serial.read();

//Serial.print(msg);
if(Serial.read() == 'o'){
// draw some text!
matrix.setTextSize(1); // size 1 == 8 pixels high
matrix.setTextWrap(false); // Don't wrap at end of line - will do ourselves
matrix.setCursor(3, 0); // start at top left, with 3 pixel of spacing
uint8_t w = 0;
char *str = " Ne me collez";
for (w=0; w<10; w++) {
matrix.setTextColor(Wheel(w));
matrix.print(str[w]);
}

matrix.setCursor(13, 8); // next line
for (w=10; w<17; w++) {
matrix.setTextColor(Wheel(w));
matrix.print(str[w]);
}

matrix.println();
matrix.setCursor(2, 16);
matrix.setTextColor(matrix.Color333(7,1,0));
matrix.print('p');
matrix.setTextColor(matrix.Color333(7,3,0));
matrix.print('a');
matrix.setTextColor(matrix.Color333(7,7,0));
matrix.print('s');
matrix.setTextColor(matrix.Color333(4,7,0));
matrix.print(' ');
matrix.setTextColor(matrix.Color333(0,7,0));
matrix.print('a');
matrix.setTextColor(matrix.Color333(0,7,7));
matrix.print('u');
matrix.setTextColor(matrix.Color333(0,4,7));
matrix.print(' ');
matrix.setTextColor(matrix.Color333(7,0,0));
matrix.print('c');
matrix.setTextColor(matrix.Color333(7,0,0));
matrix.print('u');
matrix.setTextColor(matrix.Color333(7,0,0));
matrix.print('l');
//matrix.setTextColor(matrix.Color333(7,7,7));
//matrix.println("pas au Cul");

// print each letter with a rainbow color
matrix.setCursor(3, 24);
matrix.setTextColor(matrix.Color333(7,0,0));
matrix.print(' ');
matrix.setTextColor(matrix.Color333(7,1,0));
matrix.print('P');
matrix.setTextColor(matrix.Color333(7,3,0));
matrix.print('U');
matrix.setTextColor(matrix.Color333(4,7,0));
matrix.print('T');
matrix.setTextColor(matrix.Color333(0,7,0));
matrix.print('A');
matrix.setTextColor(matrix.Color333(0,7,7));
matrix.print('I');
matrix.setTextColor(matrix.Color333(0,4,7));
matrix.print('N');
matrix.setTextColor(matrix.Color333(0,0,7));
matrix.print('!');
matrix.setTextColor(matrix.Color333(4,0,7));
matrix.print('!');
matrix.setTextColor(matrix.Color333(7,0,4));
matrix.println(' ');
//delay(50000);

} else {matrix.fillScreen(0);}
}

}

// Input a value 0 to 24 to get a color value.
// The colours are a transition r - g - b - back to r.
uint16_t Wheel(byte WheelPos) {
if(WheelPos < 8) {
return matrix.Color333(7 - WheelPos, WheelPos, 0);
} else if(WheelPos < 16) {
WheelPos -= 8;
return matrix.Color333(0, 7-WheelPos, WheelPos);
} else {
WheelPos -= 16;
return matrix.Color333(0, WheelPos, 7 - WheelPos);
}
}

</pre>

* Configuartion de la RPI

La raspberry pi (RPI) est chargé de recueillir la confirmation de l'utilisateur à travers l'application mobile, une fois ceci fait, elle lit les données envoyées provenant du traitement d'information sur la distance de sécurité et celle réelle avant de les envoyé vers le programme traitant de l'affichage du message. En fonction du message envoyé (dans notre cas c'est un caractère: 'O' ou 'o' si le message doit être envoyé et 'n' ou 'N' si c'est le contraire). Voici le code:

<pre>

from bluetooth import *
import time
import serial

server_sock=BluetoothSocket( RFCOMM )
server_sock.bind(("",PORT_ANY))
server_sock.listen(1)

port = server_sock.getsockname()[1]

uuid = "94f39d29-7d6d-437d-973b-fba39e49d4ee"

advertise_service( server_sock, "SampleServer",
service_id = uuid,
service_classes = [ uuid, SERIAL_PORT_CLASS ],
profiles = [ SERIAL_PORT_PROFILE ],
# protocols = [ OBEX_UUID ]
)

print("Waiting for connection on RFCOMM channel %d" % port)

client_sock, client_info = server_sock.accept()
print("Accepted connection from ", client_info)

ser0 = serial.Serial('/dev/ttyACM0')
Ser1 = serial.SERIAL('/dev/ttyACM1')

try:
while True:
data = ""
client_sock.recv(data)
data2 = ser1.read();
if data2 == 'O'
ser0.write('o')
if data2 == 'N'
ser0.write('n')
except IOError:
pass

print("disconnected")

client_sock.close()
server_sock.close()
print("all done")
</pre>

* Codage de l'application Mobile
Elle a pour but de permettre à l'utilisateur de se connecter, via bluetooth, à la RPI et de lui envoyer sa confirmation. Celui-ci peut également se déconnecter, s'il le souhaite.
[[Fichier:Appli_iot.png|200px]]

==Détail du travail de la sixième séance==
* Test du fonctionnement du système complet
Problèmes rencontrés:

'''[Partie ARAME]'''

''[INSERER Code final]''

* Préparation de l'oral et finition du poster

=Rendu=

==Poster==
Version électronique du poster :
[[Fichier:2017_IOT_P5_poster.png|center|500px]]

==Fichiers rendus==

Notre application : [[Media:2017_IOT_P0_application.zip]]

Fichier:Panneau.jpg

2018-01-29T02:33:07Z

Mdiop :

Fichier:Appli iot.PNG

2018-01-29T02:32:45Z

Mdiop :

P5 IOT 2017

2018-01-29T02:31:46Z

Mdiop : /* Détail du travail de la cinquième séance */

=Présentation du sujet =

==Contexte==

Nous effectuons ce projet dans le cadre du module internet des objets (Internet of things).

L'objectif de ce module est de créer l'objet connecté de notre choix.

Nous avons donc choisi de créer un objet en rapport avec la sécurité routière: le système Safe&Drive.

==Description du projet==

Pour veiller au respect des distances de sécurité, le système S&D va tout d'abord évaluer la distance entre votre voiture et celle qui vous suit.

Grâce au GPS intégré, la distance de sécurité à respecter sera calculée en fonction de votre vitesse de circulation.

Si cette distance de sécurité n'est pas respectée, un message de mise en garde sera affiché sur votre pare-brise arrière à destination du conducteur qui vous suit de trop prêt.

Bien évidemment, ce message ne sera envoyé qu'après confirmation de l'utilisateur depuis l'application mobile du système Safe&Drive.

En mode marche arrière, le système devient une aide à la manœuvre avec une caméra de recul et un détecteur d'obstacle.

=Réalisation=

==Matériel utilisé==

* Raspberry Pi
* Arduino Uno
* Arduino Mega2560
* SparkFun GPS Shield
* Adafruit 64x32 RGB LED Matrix - 5mm pitch
* Garmin LIDAR-Lite v3

==Suivi de réalisation==
{| class="wikitable alternance centre"
|-
! scope="row" | Séance 1 (08/01/2018)
| Choix de l'objet + Choix du matériel
|-
! scope="row" | Séance 2 (09/01/2018)
| Circuit shield pour la matrice LED + Test Li-DAR Lite
|-
! scope="row" | Séance 3 (16/01/2018)
| Circuit shield pour la matrice LED + Test du shield GPS
|-
! scope="row" | Séance 4 (17/01/2018)
| Circuit shield pour la matrice LED + Test Shield GPS
|-
! scope="row" | Séance 5 (22/01/2018)
| Soudage circuit shield pour la matrice LED + Test LED Matrix + RaspberryPI + Application mobile
|-
! scope="row" | Séance 6 (24/01/2018)
| Finitions + Resolutions des problèmes + Préparation orale (+poster)
|}

==Détail du travail de la première séance==

Pour choisir notre projet nous avons débuté en faisant un pseudo-brainstorming duquel est ressorti 4 projets.

Nous donc dû réduire notre choix à un seul de ces quatre possibilités.

Notre choix final s'est donc porté sur le système Safe&Drive.

Après avoir affiné les divers fonctionnalités de notre projet, nous avons commencé à réunir le matériel dont nous aurions besoin.

==Détail du travail de la deuxième séance==

* Début de la création du shield de la matrice de LED qui viendra se positionner sur l’Arduino Mega2560.

* Test du capteur optique LI-DAR Lite et codage du programme pour le calcul de distance.

<pre>

LIDARLite Arduino Library
GetDistanceI2c

This example shows how to initialize, configure, and read distance from a
LIDAR-Lite connected over the I2C interface.

Connections:
LIDAR-Lite 5 Vdc (red) to Arduino 5v
LIDAR-Lite I2C SCL (green) to Arduino SCL
LIDAR-Lite I2C SDA (blue) to Arduino SDA
LIDAR-Lite Ground (black) to Arduino GND

(Capacitor recommended to mitigate inrush current when device is enabled)
680uF capacitor (+) to Arduino 5v
680uF capacitor (-) to Arduino GND

See the Operation Manual for wiring diagrams and more information:
http://www.robotshop.com/media/files/pdf2/pli-06-instruction.pdf

-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

#include <Wire.h>
#include <LIDARLite.h>

LIDARLite myLidarLite;
int distance_reelle ;

void setup()
{
Serial.begin(9600); // Initialize serial connection to display distance readings

myLidarLite.begin(0, true); // Set configuration to default and I2C to 400 kHz

myLidarLite.configure(0); // Change this number to try out alternate configurations
}

void loop()
{

// Take a measurement with receiver bias correction and print to serial terminal
distance_reelle = (myLidarLite.distance());
if(distance_reelle < 1)
{
Serial.println('O');
}
else
{
Serial.println('N');
}
}

</pre>

==Détail du travail de la troisième séance==

* Poursuite de la création du circuit (shield) pour la matrice LED.
Cela n'a pas été une tâche facile en raison de la répartition des différentes pâtes dont nous avions besoin et des liaisons à effectuer.

* Test du GPS et codage du programme de calcul de vitesse.
Nous avons rencontré des problèmes avec le GPS, celui-ci ne renvoyait des message d'erreurs "NO GPS DETECTED" ou bien des données nulles du type "Date: 00/00/0000".

==Détail du travail de la quatrième séance==

* Finition du circuit (shield) pour la matrice LED et envoi de la demande de fabrication

Nous avons rencontré un problème avec le logiciel nous avons donc dû refaire entièrement le circuit, cela nous a pas mal retardé dans notre projet.

[[Fichier:Circuitp5.jpg|200px|]]
[[Fichier:circuit_bottom.jpg|200px|]]

* Test du GPS et résolution des problèmes.
Nous avons rencontré beaucoup de problèmes avec le GPS, celui-ci se connectait bien aux satellites mais ne nous renvoyait que des données nulles ou bien un message d'erreur.

Il s'est en faite avéré que selon la position du GPS receiver sur le shield celui-ci affichait ou non les données.

Le problème a donc été résolu. Voici le code:

<pre>}

#include <TinyGPS++.h>
#include <SoftwareSerial.h>
#include <Wire.h>
/*
This example uses software serial and the TinyGPS++ library by Mikal Hart
Based on TinyGPSPlus/DeviceExample.ino by Mikal Hart
Modified by acavis
*/

// Choose two Arduino pins to use for software serial
// The GPS Shield uses D2 and D3 by default when in DLINE mode
int RXPin = 50;
int TXPin = 3;

// The Skytaq EM-506 GPS module included in the GPS Shield Kit
// uses 4800 baud by default
int GPSBaud = 4800;

// Create a TinyGPS++ object called "gps"
TinyGPSPlus gps;

// Create a software serial port called "gpsSerial"
SoftwareSerial gpsSerial(RXPin, TXPin);

void setup()
{
// Start the Arduino hardware serial port at 9600 baud
Serial.begin(9600);

// Start the software serial port at the GPS's default baud
gpsSerial.begin(GPSBaud);

Serial.println(F("DeviceExample.ino"));
Serial.println(F("A simple demonstration of TinyGPS++ with an attached GPS module"));
Serial.print(F("Testing TinyGPS++ library v. ")); Serial.println(TinyGPSPlus::libraryVersion());
Serial.println(F("by Mikal Hart"));
Serial.println();

}

void loop()
{
// This sketch displays information every time a new sentence is correctly encoded.
while (gpsSerial.available() > 0)
if (gps.encode(gpsSerial.read()))
displayInfo();

// If 5000 milliseconds pass and there are no characters coming in
// over the software serial port, show a "No GPS detected" error
if (millis() > 5000 && gps.charsProcessed() < 10)
{
Serial.println(F("No GPS detected"));
while(true);
}
}

void displayInfo()
{
Serial.print(F("Speed: "));
if (gps.speed.isValid())
{
Serial.print(gps.speed.kmph(), 6);
}
else
{
Serial.print(F("INVALID"));
}

Serial.println();

secure_dist = (gps.speed.kmph()/10)*6;
Serial.print("distance de sécurite (en m)= ");
Serial.print(secure_dist);
Serial.println();

}

</pre>

==Détail du travail de la cinquième séance==
* Soudage des barrettes et des ponts sur le circuit pour la Matrice LED (Shield)

* Test de la matrice LED et codage du programme pour l'affichage d'un message personnalisé coloré
Message choisi: Ne me collez pas au cul, PUTAIN!!
Voici le code pour l'affichage du message. Celle-ci se fait grâce à un liaison série entre la raspberry Pi (RPI) et la matrice de de LED connectée à l’arduino Mega à travers le shield.

Voici le code pour l'affichage:

<pre>

/***************************************************
*
*NOTE THIS CAN ONLY BE USED ON A MEGA! NOT ENOUGH RAM ON UNO!
*
***************************************************
* 64x32 RGB LED Matrix - 4mm pitch
* ****************************************************
* testshapes demo for RGBmatrixPanel library.
* Demonstrates the drawing abilities of the RGBmatrixPanel library.
* For 32x64 RGB LED matrix.

* @author lg.gang(lg.gang@qq.com)
* @version V1.0
* @date 2016-9-6

* GNU Lesser General Public License.
* See <http://www.gnu.org/licenses/> for details.
* All above must be included in any redistribution
* ****************************************************/
#include <Adafruit_GFX.h> // Core graphics library
#include <RGBmatrixPanel.h> // Hardware-specific library

#define CLK 11
#define OE 9
#define LAT 10

#define A A0
#define B A1
#define C A2
#define D A3

RGBmatrixPanel matrix(A, B, C, D, CLK, LAT, OE, false, 64);
char msg;

void setup() {
Serial.begin(9600);
delay(1000);
matrix.begin();

}

void loop() {

// draw a pixel in solid white
//matrix.drawPixel(0, 0, matrix.Color333(7, 7, 7));
//delay(5000);

// fix the screen with green
//matrix.fillRect(0, 0, matrix.width(), matrix.height(), matrix.Color333(0, 7, 0));
//delay(5000);

// fix the screen with white
//matrix.fillRect(0, 0, matrix.width(), matrix.height(), matrix.Color333(7, 7, 7));
//delay(5000);

// fix the screen with red
//matrix.fillRect(0, 0, matrix.width(), matrix.height(), matrix.Color333(7, 0, 0));
//delay(5000);

// fix the screen with blue
//matrix.fillRect(0, 0, matrix.width(), matrix.height(), matrix.Color333(0, 0, 7));
//delay(5000);
// fill the screen with 'black'
//matrix.fillScreen(matrix.Color333(0, 0, 0));

// draw a box in yellow
//matrix.drawRect(0, 0, matrix.width(), matrix.height(), matrix.Color333(7, 7, 0));
//delay(5000);

// draw a box in fuchsia
//matrix.drawRect(5, 5, 53, 23, matrix.Color333(7, 0, 7));
//delay(5000);

// draw a box in yellow
//matrix.drawRect(10, 10, 43, 13, matrix.Color333(7, 1, 3));
//delay(5000);

// draw an 'X' in red
//matrix.drawLine(0, 0, matrix.width()-1, matrix.height()-1, matrix.Color333(7, 0, 0));
//matrix.drawLine(matrix.width()-1, 0, 0, matrix.height()-1, matrix.Color333(7, 0, 0));
//delay(5000);

// draw a blue circle
//matrix.drawCircle(10, 10, 10, matrix.Color333(0, 0, 7));
//delay(5000);

// fill a violet circle
//matrix.fillCircle(40, 21, 10, matrix.Color333(7, 0, 7));
//delay(5000);

// fill the screen with 'black'
//matrix.fillScreen(matrix.Color333(0, 0, 0));

while (Serial.available() > 0) {

//msg = Serial.read();

//Serial.print(msg);
if(Serial.read() == 'o'){
// draw some text!
matrix.setTextSize(1); // size 1 == 8 pixels high
matrix.setTextWrap(false); // Don't wrap at end of line - will do ourselves
matrix.setCursor(3, 0); // start at top left, with 3 pixel of spacing
uint8_t w = 0;
char *str = " Ne me collez";
for (w=0; w<10; w++) {
matrix.setTextColor(Wheel(w));
matrix.print(str[w]);
}

matrix.setCursor(13, 8); // next line
for (w=10; w<17; w++) {
matrix.setTextColor(Wheel(w));
matrix.print(str[w]);
}

matrix.println();
matrix.setCursor(2, 16);
matrix.setTextColor(matrix.Color333(7,1,0));
matrix.print('p');
matrix.setTextColor(matrix.Color333(7,3,0));
matrix.print('a');
matrix.setTextColor(matrix.Color333(7,7,0));
matrix.print('s');
matrix.setTextColor(matrix.Color333(4,7,0));
matrix.print(' ');
matrix.setTextColor(matrix.Color333(0,7,0));
matrix.print('a');
matrix.setTextColor(matrix.Color333(0,7,7));
matrix.print('u');
matrix.setTextColor(matrix.Color333(0,4,7));
matrix.print(' ');
matrix.setTextColor(matrix.Color333(7,0,0));
matrix.print('c');
matrix.setTextColor(matrix.Color333(7,0,0));
matrix.print('u');
matrix.setTextColor(matrix.Color333(7,0,0));
matrix.print('l');
//matrix.setTextColor(matrix.Color333(7,7,7));
//matrix.println("pas au Cul");

// print each letter with a rainbow color
matrix.setCursor(3, 24);
matrix.setTextColor(matrix.Color333(7,0,0));
matrix.print(' ');
matrix.setTextColor(matrix.Color333(7,1,0));
matrix.print('P');
matrix.setTextColor(matrix.Color333(7,3,0));
matrix.print('U');
matrix.setTextColor(matrix.Color333(4,7,0));
matrix.print('T');
matrix.setTextColor(matrix.Color333(0,7,0));
matrix.print('A');
matrix.setTextColor(matrix.Color333(0,7,7));
matrix.print('I');
matrix.setTextColor(matrix.Color333(0,4,7));
matrix.print('N');
matrix.setTextColor(matrix.Color333(0,0,7));
matrix.print('!');
matrix.setTextColor(matrix.Color333(4,0,7));
matrix.print('!');
matrix.setTextColor(matrix.Color333(7,0,4));
matrix.println(' ');
//delay(50000);

} else {matrix.fillScreen(0);}
}

}

// Input a value 0 to 24 to get a color value.
// The colours are a transition r - g - b - back to r.
uint16_t Wheel(byte WheelPos) {
if(WheelPos < 8) {
return matrix.Color333(7 - WheelPos, WheelPos, 0);
} else if(WheelPos < 16) {
WheelPos -= 8;
return matrix.Color333(0, 7-WheelPos, WheelPos);
} else {
WheelPos -= 16;
return matrix.Color333(0, WheelPos, 7 - WheelPos);
}
}

</pre>

* Configuartion de la RPI

La raspberry pi (RPI) est chargé de recueillir la confirmation de l'utilisateur à travers l'application mobile, une fois ceci fait, elle lit les données envoyées provenant du traitement d'information sur la distance de sécurité et celle réelle avant de les envoyé vers le programme traitant de l'affichage du message. En fonction du message envoyé (dans notre cas c'est un caractère: 'O' ou 'o' si le message doit être envoyé et 'n' ou 'N' si c'est le contraire). Voici le code:

<pre>

from bluetooth import *
import time
import serial

server_sock=BluetoothSocket( RFCOMM )
server_sock.bind(("",PORT_ANY))
server_sock.listen(1)

port = server_sock.getsockname()[1]

uuid = "94f39d29-7d6d-437d-973b-fba39e49d4ee"

advertise_service( server_sock, "SampleServer",
service_id = uuid,
service_classes = [ uuid, SERIAL_PORT_CLASS ],
profiles = [ SERIAL_PORT_PROFILE ],
# protocols = [ OBEX_UUID ]
)

print("Waiting for connection on RFCOMM channel %d" % port)

client_sock, client_info = server_sock.accept()
print("Accepted connection from ", client_info)

ser0 = serial.Serial('/dev/ttyACM0')
Ser1 = serial.SERIAL('/dev/ttyACM1')

try:
while True:
data = ""
client_sock.recv(data)
data2 = ser1.read();
if data2 == 'O'
ser0.write('o')
if data2 == 'N'
ser0.write('n')
except IOError:
pass

print("disconnected")

client_sock.close()
server_sock.close()
print("all done")
</pre>

* Codage de l'application Mobile
Elle a pour but de permettre à l'utilisateur de se connecter, via bluetooth, à la RPI et de lui envoyer sa confirmation. Celui-ci peut également se déconnecter, s'il le souhaite.

==Détail du travail de la sixième séance==
* Test du fonctionnement du système complet
Problèmes rencontrés:

'''[Partie ARAME]'''

''[INSERER Code final]''

* Préparation de l'oral et finition du poster

=Rendu=

==Poster==
Version électronique du poster :
[[Fichier:2017_IOT_P5_poster.png|center|500px]]

==Fichiers rendus==

Notre application : [[Media:2017_IOT_P0_application.zip]]

P5 IOT 2017

2018-01-29T02:03:03Z

Mdiop : /* Détail du travail de la cinquième séance */

=Présentation du sujet =

==Contexte==

Nous effectuons ce projet dans le cadre du module internet des objets (Internet of things).

L'objectif de ce module est de créer l'objet connecté de notre choix.

Nous avons donc choisi de créer un objet en rapport avec la sécurité routière: le système Safe&Drive.

==Description du projet==

Pour veiller au respect des distances de sécurité, le système S&D va tout d'abord évaluer la distance entre votre voiture et celle qui vous suit.

Grâce au GPS intégré, la distance de sécurité à respecter sera calculée en fonction de votre vitesse de circulation.

Si cette distance de sécurité n'est pas respectée, un message de mise en garde sera affiché sur votre pare-brise arrière à destination du conducteur qui vous suit de trop prêt.

Bien évidemment, ce message ne sera envoyé qu'après confirmation de l'utilisateur depuis l'application mobile du système Safe&Drive.

En mode marche arrière, le système devient une aide à la manœuvre avec une caméra de recul et un détecteur d'obstacle.

=Réalisation=

==Matériel utilisé==

* Raspberry Pi
* Arduino Uno
* Arduino Mega2560
* SparkFun GPS Shield
* Adafruit 64x32 RGB LED Matrix - 5mm pitch
* Garmin LIDAR-Lite v3

==Suivi de réalisation==
{| class="wikitable alternance centre"
|-
! scope="row" | Séance 1 (08/01/2018)
| Choix de l'objet + Choix du matériel
|-
! scope="row" | Séance 2 (09/01/2018)
| Circuit shield pour la matrice LED + Test Li-DAR Lite
|-
! scope="row" | Séance 3 (16/01/2018)
| Circuit shield pour la matrice LED + Test du shield GPS
|-
! scope="row" | Séance 4 (17/01/2018)
| Circuit shield pour la matrice LED + Test Shield GPS
|-
! scope="row" | Séance 5 (22/01/2018)
| Soudage circuit shield pour la matrice LED + Test LED Matrix + RaspberryPI + Application mobile
|-
! scope="row" | Séance 6 (24/01/2018)
| Finitions + Resolutions des problèmes + Préparation orale (+poster)
|}

==Détail du travail de la première séance==

Pour choisir notre projet nous avons débuté en faisant un pseudo-brainstorming duquel est ressorti 4 projets.

Nous donc dû réduire notre choix à un seul de ces quatre possibilités.

Notre choix final s'est donc porté sur le système Safe&Drive.

Après avoir affiné les divers fonctionnalités de notre projet, nous avons commencé à réunir le matériel dont nous aurions besoin.

==Détail du travail de la deuxième séance==

* Début de la création du shield de la matrice de LED qui viendra se positionner sur l’Arduino Mega2560.

* Test du capteur optique LI-DAR Lite et codage du programme pour le calcul de distance.

<pre>

LIDARLite Arduino Library
GetDistanceI2c

This example shows how to initialize, configure, and read distance from a
LIDAR-Lite connected over the I2C interface.

Connections:
LIDAR-Lite 5 Vdc (red) to Arduino 5v
LIDAR-Lite I2C SCL (green) to Arduino SCL
LIDAR-Lite I2C SDA (blue) to Arduino SDA
LIDAR-Lite Ground (black) to Arduino GND

(Capacitor recommended to mitigate inrush current when device is enabled)
680uF capacitor (+) to Arduino 5v
680uF capacitor (-) to Arduino GND

See the Operation Manual for wiring diagrams and more information:
http://www.robotshop.com/media/files/pdf2/pli-06-instruction.pdf

-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

#include <Wire.h>
#include <LIDARLite.h>

LIDARLite myLidarLite;
int distance_reelle ;

void setup()
{
Serial.begin(9600); // Initialize serial connection to display distance readings

myLidarLite.begin(0, true); // Set configuration to default and I2C to 400 kHz

myLidarLite.configure(0); // Change this number to try out alternate configurations
}

void loop()
{

// Take a measurement with receiver bias correction and print to serial terminal
distance_reelle = (myLidarLite.distance());
if(distance_reelle < 1)
{
Serial.println('O');
}
else
{
Serial.println('N');
}
}

</pre>

==Détail du travail de la troisième séance==

* Poursuite de la création du circuit (shield) pour la matrice LED.
Cela n'a pas été une tâche facile en raison de la répartition des différentes pâtes dont nous avions besoin et des liaisons à effectuer.

* Test du GPS et codage du programme de calcul de vitesse.
Nous avons rencontré des problèmes avec le GPS, celui-ci ne renvoyait des message d'erreurs "NO GPS DETECTED" ou bien des données nulles du type "Date: 00/00/0000".

==Détail du travail de la quatrième séance==

* Finition du circuit (shield) pour la matrice LED et envoi de la demande de fabrication

Nous avons rencontré un problème avec le logiciel nous avons donc dû refaire entièrement le circuit, cela nous a pas mal retardé dans notre projet.

[[Fichier:Circuitp5.jpg|200px|]]
[[Fichier:circuit_bottom.jpg|200px|]]

* Test du GPS et résolution des problèmes.
Nous avons rencontré beaucoup de problèmes avec le GPS, celui-ci se connectait bien aux satellites mais ne nous renvoyait que des données nulles ou bien un message d'erreur.

Il s'est en faite avéré que selon la position du GPS receiver sur le shield celui-ci affichait ou non les données.

Le problème a donc été résolu. Voici le code:

<pre>}

#include <TinyGPS++.h>
#include <SoftwareSerial.h>
#include <Wire.h>
/*
This example uses software serial and the TinyGPS++ library by Mikal Hart
Based on TinyGPSPlus/DeviceExample.ino by Mikal Hart
Modified by acavis
*/

// Choose two Arduino pins to use for software serial
// The GPS Shield uses D2 and D3 by default when in DLINE mode
int RXPin = 50;
int TXPin = 3;

// The Skytaq EM-506 GPS module included in the GPS Shield Kit
// uses 4800 baud by default
int GPSBaud = 4800;

// Create a TinyGPS++ object called "gps"
TinyGPSPlus gps;

// Create a software serial port called "gpsSerial"
SoftwareSerial gpsSerial(RXPin, TXPin);

void setup()
{
// Start the Arduino hardware serial port at 9600 baud
Serial.begin(9600);

// Start the software serial port at the GPS's default baud
gpsSerial.begin(GPSBaud);

Serial.println(F("DeviceExample.ino"));
Serial.println(F("A simple demonstration of TinyGPS++ with an attached GPS module"));
Serial.print(F("Testing TinyGPS++ library v. ")); Serial.println(TinyGPSPlus::libraryVersion());
Serial.println(F("by Mikal Hart"));
Serial.println();

}

void loop()
{
// This sketch displays information every time a new sentence is correctly encoded.
while (gpsSerial.available() > 0)
if (gps.encode(gpsSerial.read()))
displayInfo();

// If 5000 milliseconds pass and there are no characters coming in
// over the software serial port, show a "No GPS detected" error
if (millis() > 5000 && gps.charsProcessed() < 10)
{
Serial.println(F("No GPS detected"));
while(true);
}
}

void displayInfo()
{
Serial.print(F("Speed: "));
if (gps.speed.isValid())
{
Serial.print(gps.speed.kmph(), 6);
}
else
{
Serial.print(F("INVALID"));
}

Serial.println();

secure_dist = (gps.speed.kmph()/10)*6;
Serial.print("distance de sécurite (en m)= ");
Serial.print(secure_dist);
Serial.println();

}

</pre>

==Détail du travail de la cinquième séance==
* Soudage des barrettes et des ponts sur le circuit pour la Matrice LED (Shield)

* Test de la matrice LED et codage du programme pour l'affichage d'un message personnalisé coloré
Message choisi: Ne me collez pas au cul, PUTAIN!!
Voici le code pour l'affichage du message. Celle-ci se fait grâce à un liaison série entre la raspberry Pi (RPI) et la matrice de de LED connectée à l’arduino Mega à travers le shield.

Voici le code pour l'affichage:

<pre>

/***************************************************
*
*NOTE THIS CAN ONLY BE USED ON A MEGA! NOT ENOUGH RAM ON UNO!
*
***************************************************
* 64x32 RGB LED Matrix - 4mm pitch
* ****************************************************
* testshapes demo for RGBmatrixPanel library.
* Demonstrates the drawing abilities of the RGBmatrixPanel library.
* For 32x64 RGB LED matrix.

* @author lg.gang(lg.gang@qq.com)
* @version V1.0
* @date 2016-9-6

* GNU Lesser General Public License.
* See <http://www.gnu.org/licenses/> for details.
* All above must be included in any redistribution
* ****************************************************/
#include <Adafruit_GFX.h> // Core graphics library
#include <RGBmatrixPanel.h> // Hardware-specific library

#define CLK 11
#define OE 9
#define LAT 10

#define A A0
#define B A1
#define C A2
#define D A3

RGBmatrixPanel matrix(A, B, C, D, CLK, LAT, OE, false, 64);
char msg;

void setup() {
Serial.begin(9600);
delay(1000);
matrix.begin();

}

void loop() {

// draw a pixel in solid white
//matrix.drawPixel(0, 0, matrix.Color333(7, 7, 7));
//delay(5000);

// fix the screen with green
//matrix.fillRect(0, 0, matrix.width(), matrix.height(), matrix.Color333(0, 7, 0));
//delay(5000);

// fix the screen with white
//matrix.fillRect(0, 0, matrix.width(), matrix.height(), matrix.Color333(7, 7, 7));
//delay(5000);

// fix the screen with red
//matrix.fillRect(0, 0, matrix.width(), matrix.height(), matrix.Color333(7, 0, 0));
//delay(5000);

// fix the screen with blue
//matrix.fillRect(0, 0, matrix.width(), matrix.height(), matrix.Color333(0, 0, 7));
//delay(5000);
// fill the screen with 'black'
//matrix.fillScreen(matrix.Color333(0, 0, 0));

// draw a box in yellow
//matrix.drawRect(0, 0, matrix.width(), matrix.height(), matrix.Color333(7, 7, 0));
//delay(5000);

// draw a box in fuchsia
//matrix.drawRect(5, 5, 53, 23, matrix.Color333(7, 0, 7));
//delay(5000);

// draw a box in yellow
//matrix.drawRect(10, 10, 43, 13, matrix.Color333(7, 1, 3));
//delay(5000);

// draw an 'X' in red
//matrix.drawLine(0, 0, matrix.width()-1, matrix.height()-1, matrix.Color333(7, 0, 0));
//matrix.drawLine(matrix.width()-1, 0, 0, matrix.height()-1, matrix.Color333(7, 0, 0));
//delay(5000);

// draw a blue circle
//matrix.drawCircle(10, 10, 10, matrix.Color333(0, 0, 7));
//delay(5000);

// fill a violet circle
//matrix.fillCircle(40, 21, 10, matrix.Color333(7, 0, 7));
//delay(5000);

// fill the screen with 'black'
//matrix.fillScreen(matrix.Color333(0, 0, 0));

while (Serial.available() > 0) {

//msg = Serial.read();

//Serial.print(msg);
if(Serial.read() == 'o'){
// draw some text!
matrix.setTextSize(1); // size 1 == 8 pixels high
matrix.setTextWrap(false); // Don't wrap at end of line - will do ourselves
matrix.setCursor(3, 0); // start at top left, with 3 pixel of spacing
uint8_t w = 0;
char *str = " Ne me collez";
for (w=0; w<10; w++) {
matrix.setTextColor(Wheel(w));
matrix.print(str[w]);
}

matrix.setCursor(13, 8); // next line
for (w=10; w<17; w++) {
matrix.setTextColor(Wheel(w));
matrix.print(str[w]);
}

matrix.println();
matrix.setCursor(2, 16);
matrix.setTextColor(matrix.Color333(7,1,0));
matrix.print('p');
matrix.setTextColor(matrix.Color333(7,3,0));
matrix.print('a');
matrix.setTextColor(matrix.Color333(7,7,0));
matrix.print('s');
matrix.setTextColor(matrix.Color333(4,7,0));
matrix.print(' ');
matrix.setTextColor(matrix.Color333(0,7,0));
matrix.print('a');
matrix.setTextColor(matrix.Color333(0,7,7));
matrix.print('u');
matrix.setTextColor(matrix.Color333(0,4,7));
matrix.print(' ');
matrix.setTextColor(matrix.Color333(7,0,0));
matrix.print('c');
matrix.setTextColor(matrix.Color333(7,0,0));
matrix.print('u');
matrix.setTextColor(matrix.Color333(7,0,0));
matrix.print('l');
//matrix.setTextColor(matrix.Color333(7,7,7));
//matrix.println("pas au Cul");

// print each letter with a rainbow color
matrix.setCursor(3, 24);
matrix.setTextColor(matrix.Color333(7,0,0));
matrix.print(' ');
matrix.setTextColor(matrix.Color333(7,1,0));
matrix.print('P');
matrix.setTextColor(matrix.Color333(7,3,0));
matrix.print('U');
matrix.setTextColor(matrix.Color333(4,7,0));
matrix.print('T');
matrix.setTextColor(matrix.Color333(0,7,0));
matrix.print('A');
matrix.setTextColor(matrix.Color333(0,7,7));
matrix.print('I');
matrix.setTextColor(matrix.Color333(0,4,7));
matrix.print('N');
matrix.setTextColor(matrix.Color333(0,0,7));
matrix.print('!');
matrix.setTextColor(matrix.Color333(4,0,7));
matrix.print('!');
matrix.setTextColor(matrix.Color333(7,0,4));
matrix.println(' ');
//delay(50000);

} else {matrix.fillScreen(0);}
}

}

// Input a value 0 to 24 to get a color value.
// The colours are a transition r - g - b - back to r.
uint16_t Wheel(byte WheelPos) {
if(WheelPos < 8) {
return matrix.Color333(7 - WheelPos, WheelPos, 0);
} else if(WheelPos < 16) {
WheelPos -= 8;
return matrix.Color333(0, 7-WheelPos, WheelPos);
} else {
WheelPos -= 16;
return matrix.Color333(0, WheelPos, 7 - WheelPos);
}
}

</pre>

* Configuartion de la RPI

La raspberry pi (RPI) est chargé de recueillir la confirmation de l'utilisateur à travers l'application mobile, une fois ceci fait, elle lit les données envoyées provenant du traitement d'information sur la distance de sécurité et celle réelle avant de les envoyé vers le programme traitant de l'affichage du message. En fonction du message envoyé (dans notre cas c'est un caractère: 'O' ou 'o' si le message doit être envoyé et 'n' ou 'N' si c'est le contraire). Voici le code:

<pre>

</pre>

* Codage de l'application Mobile
'''[PARTIE ARAME]'''

''[INSERER CODE APPLI]''

==Détail du travail de la sixième séance==
* Test du fonctionnement du système complet
Problèmes rencontrés:

'''[Partie ARAME]'''

''[INSERER Code final]''

* Préparation de l'oral et finition du poster

=Rendu=

==Poster==
Version électronique du poster :
[[Fichier:2017_IOT_P5_poster.png|center|500px]]

==Fichiers rendus==

Notre application : [[Media:2017_IOT_P0_application.zip]]

P5 IOT 2017

2018-01-29T01:47:42Z

Mdiop : /* Détail du travail de la quatrième séance */

P5 IOT 2017

2018-01-29T01:45:29Z

Mdiop : /* Détail du travail de la quatrième séance */

Fichier:Circuit bottom.jpg

2018-01-29T01:37:13Z

Mdiop :

P5 IOT 2017

2018-01-29T01:34:15Z

Mdiop : /* Détail du travail de la quatrième séance */

P5 IOT 2017

2018-01-29T01:33:18Z

Mdiop : /* Détail du travail de la quatrième séance */

P5 IOT 2017

2018-01-29T01:31:30Z

Mdiop : /* Détail du travail de la quatrième séance */

Fichier:Circuitp5.jpg

2018-01-29T01:30:09Z

Mdiop :

P5 IOT 2017

2018-01-29T01:28:07Z

Mdiop : /* Détail du travail de la quatrième séance */

P5 IOT 2017

2018-01-29T01:22:34Z

Mdiop : /* Détail du travail de la deuxième séance */

P5 IOT 2017

2018-01-29T01:21:34Z

Mdiop : /* Détail du travail de la deuxième séance */

P5 IOT 2017

2018-01-29T01:15:35Z

Mdiop : /* Détail du travail de la deuxième séance */

Fichier:IotLidar.doc

2018-01-29T01:14:01Z

Mdiop :

P5 IOT 2017

2018-01-08T17:13:03Z

Mdiop : /* Description du projet */

=Présentation du sujet =

==Contexte==
Nous effectuons ce projet dans le cadre du module internet des objets (Internet of things).
L'objectif de ce module est de créer un objet connecté de notre choix.

==Description du projet==
Combiné avec une application sur smartphone, le capteur de voiture connecté permettra d'effectuer les actions suivantes:
Détecter la distance entre sa voiture et celle de derrière
Si la distance de sécurité n'est pas respectée, affichage d'un message personnalisé (après confirmation par le conducteur)
Calcul de la distance de sécurité que la voiture de derrière doit respecter en fonction de la vitesse du véhicule (Détection GPS)
Aide à la manœuvre en marche-arrière (Détection d’obstacle)+ Signal sonore

=Réalisation=

==Matériel utilisé==

* Matériel 1
* Matériel 2
* ...

==Suivi de réalisation==
{| class="wikitable alternance centre"
|-
! scope="row" | Séance 1 (08/01/2018)
| activité ...
|-
! scope="row" | Séance 2 (09/01/2018)
| activité ...
|-
! scope="row" | Séance 3 (16/01/2018)
| activité ...
|-
! scope="row" | Séance 4 (17/01/2018)
| activité ...
|-
! scope="row" | Séance 5 (22/01/2018)
| activité ...
|-
! scope="row" | Séance 6 (24/01/2018)
| activité ...
|}

==Détail du travail de la première séance==
Exemple d'inclusion d'image :
[[Fichier:2017_IOT_P0_circuit.png|center|400px|Un circuit]]

==Détail du travail de la deuxième séance==

==Détail du travail de la troisième séance==

==Détail du travail de la quatrième séance==

==Détail du travail de la cinquième séance==

==Détail du travail de la sixième séance==

=Rendu=

==Poster==
Version électronique du poster :
[[Fichier:2017_IOT_P0_poster.png|center|500px|Notre poster]]

==Fichiers rendus==

Notre application : [[Media:2017_IOT_P0_application.zip]]

P5 IOT 2017

2018-01-08T17:10:37Z

Mdiop : /* Description du projet */

=Présentation du sujet =

==Contexte==
Nous effectuons ce projet dans le cadre du module internet des objets (Internet of things).
L'objectif de ce module est de créer un objet connecté de notre choix.

==Description du projet==
Combiné avec une application sur smartphone, le capteur de voiture connecté permettra d'effectuer les actions suivantes:
Détecter la distance entre sa voiture et celle de derrière
Si la distance de sécurité n'est pas respectée, affichage d'un message personnalisé
Calcul de la distance de sécurité que la voiture de derrière doit respecter en fonction de la vitesse du véhicule (Détection GPS)
Aide à la manœuvre en marche-arrière (Détection d’obstacle)

=Réalisation=

==Matériel utilisé==

* Matériel 1
* Matériel 2
* ...

==Suivi de réalisation==
{| class="wikitable alternance centre"
|-
! scope="row" | Séance 1 (08/01/2018)
| activité ...
|-
! scope="row" | Séance 2 (09/01/2018)
| activité ...
|-
! scope="row" | Séance 3 (16/01/2018)
| activité ...
|-
! scope="row" | Séance 4 (17/01/2018)
| activité ...
|-
! scope="row" | Séance 5 (22/01/2018)
| activité ...
|-
! scope="row" | Séance 6 (24/01/2018)
| activité ...
|}

==Détail du travail de la première séance==
Exemple d'inclusion d'image :
[[Fichier:2017_IOT_P0_circuit.png|center|400px|Un circuit]]

==Détail du travail de la deuxième séance==

==Détail du travail de la troisième séance==

==Détail du travail de la quatrième séance==

==Détail du travail de la cinquième séance==

==Détail du travail de la sixième séance==

=Rendu=

==Poster==
Version électronique du poster :
[[Fichier:2017_IOT_P0_poster.png|center|500px|Notre poster]]

==Fichiers rendus==

Notre application : [[Media:2017_IOT_P0_application.zip]]

P5 IOT 2017

2018-01-08T17:09:56Z

Mdiop : /* Description du projet */

=Présentation du sujet =

==Contexte==
Nous effectuons ce projet dans le cadre du module internet des objets (Internet of things).
L'objectif de ce module est de créer un objet connecté de notre choix.

==Description du projet==
Combiné avec une application sur smartphone, le capteur de voiture connecté permettra d'effectuer les actions suivantes:
-- Détecter la distance entre sa voiture et celle de derrière
- Si la distance de sécurité n'est pas respectée, affichage d'un message personnalisé
- Calcul de la distance de sécurité que la voiture de derrière doit respecter en fonction de la vitesse du véhicule (Détection GPS)
- Aide à la manœuvre en marche-arrière (Détection d’obstacle)

=Réalisation=

==Matériel utilisé==

* Matériel 1
* Matériel 2
* ...

==Suivi de réalisation==
{| class="wikitable alternance centre"
|-
! scope="row" | Séance 1 (08/01/2018)
| activité ...
|-
! scope="row" | Séance 2 (09/01/2018)
| activité ...
|-
! scope="row" | Séance 3 (16/01/2018)
| activité ...
|-
! scope="row" | Séance 4 (17/01/2018)
| activité ...
|-
! scope="row" | Séance 5 (22/01/2018)
| activité ...
|-
! scope="row" | Séance 6 (24/01/2018)
| activité ...
|}

==Détail du travail de la première séance==
Exemple d'inclusion d'image :
[[Fichier:2017_IOT_P0_circuit.png|center|400px|Un circuit]]

==Détail du travail de la deuxième séance==

==Détail du travail de la troisième séance==

==Détail du travail de la quatrième séance==

==Détail du travail de la cinquième séance==

==Détail du travail de la sixième séance==

=Rendu=

==Poster==
Version électronique du poster :
[[Fichier:2017_IOT_P0_poster.png|center|500px|Notre poster]]

==Fichiers rendus==

Notre application : [[Media:2017_IOT_P0_application.zip]]

P5 IOT 2017

2018-01-08T17:08:27Z

Mdiop : /* Description du projet */

=Présentation du sujet =

==Contexte==
Nous effectuons ce projet dans le cadre du module internet des objets (Internet of things).
L'objectif de ce module est de créer un objet connecté de notre choix.

==Description du projet==
Combiné avec une application sur smartphone, le capteur de voiture connecté permettra d'effectuer les actions suivantes:
- Détecter la distance entre sa voiture et celle de derrière
- Si la distance de sécurité n'est pas respectée, affichage d'un message personnalisé
- Calcul de la distance de sécurité que la voiture de derrière doit respecter en fonction de la vitesse du véhicule (Détection GPS)
- Aide à la manœuvre en marche-arrière (Détection d’obstacle)

=Réalisation=

==Matériel utilisé==

* Matériel 1
* Matériel 2
* ...

==Suivi de réalisation==
{| class="wikitable alternance centre"
|-
! scope="row" | Séance 1 (08/01/2018)
| activité ...
|-
! scope="row" | Séance 2 (09/01/2018)
| activité ...
|-
! scope="row" | Séance 3 (16/01/2018)
| activité ...
|-
! scope="row" | Séance 4 (17/01/2018)
| activité ...
|-
! scope="row" | Séance 5 (22/01/2018)
| activité ...
|-
! scope="row" | Séance 6 (24/01/2018)
| activité ...
|}

==Détail du travail de la première séance==
Exemple d'inclusion d'image :
[[Fichier:2017_IOT_P0_circuit.png|center|400px|Un circuit]]

==Détail du travail de la deuxième séance==

==Détail du travail de la troisième séance==

==Détail du travail de la quatrième séance==

==Détail du travail de la cinquième séance==

==Détail du travail de la sixième séance==

=Rendu=

==Poster==
Version électronique du poster :
[[Fichier:2017_IOT_P0_poster.png|center|500px|Notre poster]]

==Fichiers rendus==

Notre application : [[Media:2017_IOT_P0_application.zip]]

P5 IOT 2017

2018-01-08T16:59:07Z

Mdiop : /* Contexte */

=Présentation du sujet =

==Contexte==
Nous effectuons ce projet dans le cadre du module internet des objets (Internet of things).
L'objectif de ce module est de créer un objet connecté de notre choix.

==Description du projet==

=Réalisation=

==Matériel utilisé==

* Matériel 1
* Matériel 2
* ...

==Suivi de réalisation==
{| class="wikitable alternance centre"
|-
! scope="row" | Séance 1 (08/01/2018)
| activité ...
|-
! scope="row" | Séance 2 (09/01/2018)
| activité ...
|-
! scope="row" | Séance 3 (16/01/2018)
| activité ...
|-
! scope="row" | Séance 4 (17/01/2018)
| activité ...
|-
! scope="row" | Séance 5 (22/01/2018)
| activité ...
|-
! scope="row" | Séance 6 (24/01/2018)
| activité ...
|}

==Détail du travail de la première séance==
Exemple d'inclusion d'image :
[[Fichier:2017_IOT_P0_circuit.png|center|400px|Un circuit]]

==Détail du travail de la deuxième séance==

==Détail du travail de la troisième séance==

==Détail du travail de la quatrième séance==

==Détail du travail de la cinquième séance==

==Détail du travail de la sixième séance==

=Rendu=

==Poster==
Version électronique du poster :
[[Fichier:2017_IOT_P0_poster.png|center|500px|Notre poster]]

==Fichiers rendus==

Notre application : [[Media:2017_IOT_P0_application.zip]]

Option Internet des objets 2017/2018

2018-01-08T16:55:47Z

Mdiop : /* Répartition des binômes */

= Répartition des binômes =

Ecrivez vos noms sous le format exact "Prénom Nom", séparez vos noms par des virgules. Modifiez aussi l'intitulé de votre projet.

{| class="wikitable"
! Projet !! Elèves
|-
| [[P1_IOT_2017|Plaisir connecté ]] || Benoît Verhaeghe, Simon Fourquez
|-
| [[P2_IOT_2017|Lunettes bien-être]] || Nastassia Kaugarenia, Romain Houppeaux, Edmur Lopes
|-
| [[P3_IOT_2017|Patch connecté pour matériel sportif]] || Maerten Clément, Bouissou Cyprien
|-
| [[P4_IOT_2017|Veilleuse mobile]] || Maher Bencherif, Bacem Hagui
|-
| [[P5_IOT_2017|Capteur voiture connecté]] || Laurène GUILLONNET, Mame Arame DIOP
|-
| [[P6_IOT_2017|Intitulé du projet 6]] || Prénom Nom, Prénom Nom
|-
|}

IMA4 2016/2017 P18

2017-05-20T21:10:36Z

Mdiop : /* Fichiers rendus */

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

{| class="wikitable"
!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==

{| 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 + 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 bete à corne, 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]

IMA4 2016/2017 P18

2017-05-20T21:10:15Z

Mdiop : /* Fichiers rendus */

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

{| class="wikitable"
!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==

{| 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 + 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 bete à corne, 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]

IMA4 2016/2017 P18

2017-05-20T20:42:44Z

Mdiop : /* Fichiers rendus */

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

{| class="wikitable"
!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==

{| 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 + 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 bete à corne, 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 et esp: [[https://drive.google.com/open?id=0B-4pCR18G57KbDA0ejlSTm1YZmM] fichier zip ]

IMA4 2016/2017 P18

2017-05-20T15:32:27Z

Mdiop : /* Semaine 8 */

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

{| class="wikitable"
!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==

{| 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 + 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 bete à corne, 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 devrons nous servir des ports digitaux du MEGA et choisir l’accéléromètre à partir duquel nous récupérons les données grâce à un chip select. Pour cela nous devrons utiliser la bibliothèque SPI.h et brancher le pin CS de l'accéléromètre à des pin digitaux du mega.

Mais les pin de l'accéleromè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.

===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 rencontrons des problèmes en ce qui concerne la l'implémentation du programme coté ESP.

===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 serie de données.Ensuite on ramène les valeurs de l'accéléromètre sur l'échelle de g (gravitation terrestre ) gracz à 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 )

===Fichiers rendus===

rapport de projet : [[Fichier:Rapport_Fahem_Diop.pdf]]
Code de la partie smartphone: [[Fichier:]]

IMA4 2016/2017 P18

2017-05-20T15:31:45Z

Mdiop : /* Semaine 9 */

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

{| class="wikitable"
!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==

{| 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 + 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 bete à corne, 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 devrons nous servir des ports digitaux du MEGA et choisir l’accéléromètre à partir duquel nous récupérons les données grâce à un chip select. Pour cela nous devrons utiliser la bibliothèque SPI.h et brancher le pin CS de l'accéléromètre à des pin digitaux du mega.

Mais les pin de l'accéleromè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.

===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]]
* Nous rencontrons des problèmes en ce qui concerne la l'implémentation du programme coté ESP.

===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 serie de données.Ensuite on ramène les valeurs de l'accéléromètre sur l'échelle de g (gravitation terrestre ) gracz à 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 )

===Fichiers rendus===

rapport de projet : [[Fichier:Rapport_Fahem_Diop.pdf]]
Code de la partie smartphone: [[Fichier:]]

IMA4 2016/2017 P18

2017-05-20T15:31:07Z

Mdiop : /* Semaine 9 */

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

{| class="wikitable"
!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==

{| 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 + 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 bete à corne, 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 devrons nous servir des ports digitaux du MEGA et choisir l’accéléromètre à partir duquel nous récupérons les données grâce à un chip select. Pour cela nous devrons utiliser la bibliothèque SPI.h et brancher le pin CS de l'accéléromètre à des pin digitaux du mega.

Mais les pin de l'accéleromè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.

===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]]
* Nous rencontrons des problèmes en ce qui concerne la l'implémentation du programme coté ESP.

===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 serie de données.Ensuite on ramène les valeurs de l'accéléromètre sur l'échelle de g (gravitation terrestre ) gracz à 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 )

===Fichiers rendus===

rapport de projet : [[Fichier:Rapport_Fahem_Diop.pdf]]
Code de la partie smartphone: [[Fichier:]]

IMA4 2016/2017 P18

2017-05-20T15:30:24Z

Mdiop : /* Semaine 9 */

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

{| class="wikitable"
!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==

{| 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 + 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 bete à corne, 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 devrons nous servir des ports digitaux du MEGA et choisir l’accéléromètre à partir duquel nous récupérons les données grâce à un chip select. Pour cela nous devrons utiliser la bibliothèque SPI.h et brancher le pin CS de l'accéléromètre à des pin digitaux du mega.

Mais les pin de l'accéleromè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.

===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]]
* Nous rencontrons des problèmes en ce qui concerne la l'implémentation du programme coté ESP.

===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 | 400px]]

===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 serie de données.Ensuite on ramène les valeurs de l'accéléromètre sur l'échelle de g (gravitation terrestre ) gracz à 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 )

===Fichiers rendus===

rapport de projet : [[Fichier:Rapport_Fahem_Diop.pdf]]
Code de la partie smartphone: [[Fichier:]]

IMA4 2016/2017 P18

2017-05-20T15:23:57Z

Mdiop : /* Semaine 9 */

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

{| class="wikitable"
!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==

{| 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 + 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 bete à corne, 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 devrons nous servir des ports digitaux du MEGA et choisir l’accéléromètre à partir duquel nous récupérons les données grâce à un chip select. Pour cela nous devrons utiliser la bibliothèque SPI.h et brancher le pin CS de l'accéléromètre à des pin digitaux du mega.

Mais les pin de l'accéleromè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.

===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]]
* Nous rencontrons des problèmes en ce qui concerne la l'implémentation du programme coté ESP.

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

===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 serie de données.Ensuite on ramène les valeurs de l'accéléromètre sur l'échelle de g (gravitation terrestre ) gracz à 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 )

===Fichiers rendus===

rapport de projet : [[Fichier:Rapport_Fahem_Diop.pdf]]
Code de la partie smartphone: [[Fichier:]]

Fichier:Affichage valeur.jpg

2017-05-20T15:21:57Z

Mdiop : Valeurs des angles idéaux et des angles actuels qui traduisent la position du patient

Valeurs des angles idéaux et des angles actuels qui traduisent la position du patient

Fichier:Page daccueil.jpg

2017-05-20T15:17:23Z

Mdiop : a téléversé une nouvelle version de « Fichier:Page daccueil.jpg »

Page d'accueil de l'app pour l'affichage des angles d'inclinaison.

Fichier:Page daccueil.jpg

2017-05-20T15:14:42Z

Mdiop : a téléversé une nouvelle version de « Fichier:Page daccueil.jpg »

Page d'accueil de l'app pour l'affichage des angles d'inclinaison.

IMA4 2016/2017 P18

2017-05-20T15:12:41Z

Mdiop : /* Semaine 8 */

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

{| class="wikitable"
!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==

{| 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 + 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 bete à corne, 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 devrons nous servir des ports digitaux du MEGA et choisir l’accéléromètre à partir duquel nous récupérons les données grâce à un chip select. Pour cela nous devrons utiliser la bibliothèque SPI.h et brancher le pin CS de l'accéléromètre à des pin digitaux du mega.

Mais les pin de l'accéleromè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.

===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]]
* Nous rencontrons des problèmes en ce qui concerne la l'implémentation du programme coté ESP.

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

===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 serie de données.Ensuite on ramène les valeurs de l'accéléromètre sur l'échelle de g (gravitation terrestre ) gracz à 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 )

===Fichiers rendus===

rapport de projet : [[Fichier:Rapport_Fahem_Diop.pdf]]
Code de la partie smartphone: [[Fichier:]]

Fichier:Page daccueil.jpg

2017-05-20T15:10:56Z

Mdiop : Page d'accueil de l'app pour l'affichage des angles d'inclinaison.

Page d'accueil de l'app pour l'affichage des angles d'inclinaison.

IMA4 2016/2017 P18

2017-05-20T15:05:30Z

Mdiop : /* Fichiers rendus */

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

{| class="wikitable"
!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==

{| 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 + 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 bete à corne, 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 devrons nous servir des ports digitaux du MEGA et choisir l’accéléromètre à partir duquel nous récupérons les données grâce à un chip select. Pour cela nous devrons utiliser la bibliothèque SPI.h et brancher le pin CS de l'accéléromètre à des pin digitaux du mega.

Mais les pin de l'accéleromè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.

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

* Nous rencontrons des problèmes en ce qui concerne la l'implémentation du programme coté ESP.

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

===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 serie de données.Ensuite on ramène les valeurs de l'accéléromètre sur l'échelle de g (gravitation terrestre ) gracz à 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 )

===Fichiers rendus===

rapport de projet : [[Fichier:Rapport_Fahem_Diop.pdf]]
Code de la partie smartphone: [[Fichier:]]

IMA4 2016/2017 P18

2017-05-20T15:05:07Z

Mdiop : /* Fichiers rendus */

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

{| class="wikitable"
!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==

{| 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 + 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 bete à corne, 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 devrons nous servir des ports digitaux du MEGA et choisir l’accéléromètre à partir duquel nous récupérons les données grâce à un chip select. Pour cela nous devrons utiliser la bibliothèque SPI.h et brancher le pin CS de l'accéléromètre à des pin digitaux du mega.

Mais les pin de l'accéleromè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.

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

* Nous rencontrons des problèmes en ce qui concerne la l'implémentation du programme coté ESP.

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

===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 serie de données.Ensuite on ramène les valeurs de l'accéléromètre sur l'échelle de g (gravitation terrestre ) gracz à 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 )

===Fichiers rendus===

rapport de projet : [[Fichier:Rapport_Fahem_Diop.pdf]]
Code de la partie smartphone: [[Fichier:Exemple.jpg]]

IMA4 2016/2017 P18

2017-05-20T14:57:22Z

Mdiop : /* Semaine 8 */

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

{| class="wikitable"
!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==

{| 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 + 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 bete à corne, 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 devrons nous servir des ports digitaux du MEGA et choisir l’accéléromètre à partir duquel nous récupérons les données grâce à un chip select. Pour cela nous devrons utiliser la bibliothèque SPI.h et brancher le pin CS de l'accéléromètre à des pin digitaux du mega.

Mais les pin de l'accéleromè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.

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

* Nous rencontrons des problèmes en ce qui concerne la l'implémentation du programme coté ESP.

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

===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 serie de données.Ensuite on ramène les valeurs de l'accéléromètre sur l'échelle de g (gravitation terrestre ) gracz à 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 )

===Fichiers rendus===

rapport de projet : [[Fichier:Rapport_Fahem_Diop.pdf]]

IMA4 2016/2017 P18

2017-05-20T14:42:38Z

Mdiop : /* Semaine 8 */

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

{| class="wikitable"
!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==

{| 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 + 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 bete à corne, 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 devrons nous servir des ports digitaux du MEGA et choisir l’accéléromètre à partir duquel nous récupérons les données grâce à un chip select. Pour cela nous devrons utiliser la bibliothèque SPI.h et brancher le pin CS de l'accéléromètre à des pin digitaux du mega.

Mais les pin de l'accéleromè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.

===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:Exemple.jpg]]

* Nous rencontrons des problèmes en ce qui concerne la l'implémentation du programme coté ESP.

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

===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 serie de données.Ensuite on ramène les valeurs de l'accéléromètre sur l'échelle de g (gravitation terrestre ) gracz à 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 )

===Fichiers rendus===

rapport de projet : [[Fichier:Rapport_Fahem_Diop.pdf]]

IMA4 2016/2017 P18

2017-05-20T14:39:44Z

Mdiop : /* Semaine 7 */

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

{| class="wikitable"
!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==

{| 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 + 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 bete à corne, 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 devrons nous servir des ports digitaux du MEGA et choisir l’accéléromètre à partir duquel nous récupérons les données grâce à un chip select. Pour cela nous devrons utiliser la bibliothèque SPI.h et brancher le pin CS de l'accéléromètre à des pin digitaux du mega.

Mais les pin de l'accéleromè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.

===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.
* Nous rencontrons des problèmes en ce qui concerne la l'implémentation du programme coté ESP.

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

===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 serie de données.Ensuite on ramène les valeurs de l'accéléromètre sur l'échelle de g (gravitation terrestre ) gracz à 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 )

===Fichiers rendus===

rapport de projet : [[Fichier:Rapport_Fahem_Diop.pdf]]

IMA4 2016/2017 P18

2017-05-10T01:07:30Z

Mdiop : /* Semaine 9 */

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

==Feuille d'heures==

{| 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
|-
| 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
|
|
|-
| application mobile
|
|
|
|
|
|2H
|4H
|4H
|
|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 bete à corne, 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| 500px ]]

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.

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| 200px ]]

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

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

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

*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

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 devrons nous servir des ports digitales du MEGA et choisir l’accéléromètre à partir duquel nous récupérons les données grâce à un chip select. Pour cela nous devrons utiliser la bibliothèque SPI.h et brancher le CS de l'accéléromètre à des digital pin du mega.

Le deuxième problème survenue est dans la tension limite de l'accéléromètre, en effet ce dernier ne peut supporter que du 3.3V, hors la carte MEGA, elle, délivre du 5V.

De plus le signal sortant de l'accéléromètre est de l'ordre du 3.3V ce qui pourrais être problématique au niveau de la sensibilité du MEGA qui pourrais alors détecter des données biaisées. Nous serons donc amené à réaliser une carte pour faire l'adaptation d'impédance entre la carte MEGA et l'accéléromètre.

===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 rencontrons des problèmes en ce qui concerne la l'implémentation du programme coté ESP.

===Semaine 9===

Nous avons testé la carte électronique faite la semaine précédente. Elle ne fonctionne pas et nous n'avons pas pu comprendre pourquoi. Par conséquent, nous avons changé de microcontrolleur. Nous avons reçu un arduino pro mini 3.3V compatible avec nos capteurs. Nous commençons par conséquent à recueillir les données du capteurs.

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

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

IMA4 2016/2017 P18

2017-05-10T01:05:13Z

Mdiop : /* Semaine 6 */