Wiki de Projets IMA - Contributions de l’utilisateur [fr]

IMA4 2017/2018 P35

2018-05-05T20:27:04Z

Tgracias : /* Programmation */

__TOC__
 

=Présentation générale: Manette modulable=

==Description==

Tout le monde joue aux jeux vidéo cependant, les manettes ne sont pas adaptées aux personnes ayant un handicap pouvant toucher les bras ou les mains.
C’est le cas, de plusieurs patients dans les centres de soins et de rééducation.

Pour ce projet IMA4, nous travaillerons avec le centre SSR (soin de suite et de réadaptation) Marc Sautelet de Villeneuve d’Ascq.
Un adolescent, patient de Marc Sautelet, est passionné par les jeux vidéo. En effet, ayant perdu la motricité d’une partie de son corps, il ne peut pas jouer à deux mains. Pour cela, il bloque la manette entre son épaule et son coude, usant de la mâchoire et des doigts pour contrôler les
joysticks et les boutons. Cet exercice peut s’avérer fatiguant et pénible.

Ainsi, nous chercherons à concevoir une manette PS4 adaptée au handicap de l’adolescent.
Cette manette devra aussi être adaptée pour d’autres patients présentant également des handicaps moteurs. Ainsi nous prendrons pour cibles: tous les patients du centre voulant jouer; et non pas que les enfants et adolescents.

 

{| class="wikitable centre" width="80%"
|+
|-
| width="23%" |
Membre du projet
| width="34%" |
Transley Gracias et Camille Saad
|-
| width="23%" |
Cible
| width="34%" |
Patient présentant un handicap moteur
|-
|width="23%" |
Période du projet
| width="34%" |
janvier 2018 - mai 2018
|-
|width="23%" |
Partenaire/Client
| width="34%" |
Centre SSR Marc Sautelet à Villeneuve d'Ascq
|}

==Objectifs==

Ce projet a pour objectif de créer un prototype de manette qui puisse interagir avec la console PS4 et dont le paramétrage se fait à l’aide d’une application mobile et/ou web. Cette manette devra suivre les demandes du patient ainsi que des aides-soignantes du centre, dans la mesure du possible.

Plus précisément, pour le premier prototype, nous mettrons en œuvre l'utilisation de quelques boutons spécifiques:

* Un joystick (type L/R)
* Quelques boutons poussoirs (type Croix/Triangle/Carré/Rond/R1/L1/Start/...)
* Des boutons gâchettes progressives (type L2/R2).

Le but serait donc dans un premier temps de rendre fonctionnel un bouton de chaque type, puis de les multiplier une fois cela fait. Tous ces boutons réunis constituent une manette fonctionnelle.Ainsi, la manette sera ajustable, c’est à dire qu’elle devra s’adapter aux différents handicaps moteurs possibles.

=Analyse du projet=

==Positionnement par rapport à l'existant==

Notre prototype aura une présentation unique par rapport à l’existant. En effet, les concurrents et produits existants ciblent pour la majorité un seul handicap. Cela
engendre une solution fermée à beaucoup de patients. Notre projet propose une mobilité des mouvements et également un choix large dans la composition et le
design de notre manette.
Le patient n’est pas retreint à jouer à une seule main, à utiliser beaucoup de force...Il y a moins de technique dans la manipulation et on ne joue pas avec une
manette adaptée uniquement pour un droitier ou un gaucher. Cependant, cela nous limitera peut-être dans le choix possible des types de jeux. Tout comme les autres
manettes adapté, l’utilisateur nécessitera un peu d’entrainement.

==Analyse du premier concurrent==

Jouer aux jeux vidéo à une main n’est pas une idée d’aujourd’hui. En 1990, Nintendo propose le Power Glove. Mais il tombe très rapidement aux oubliettes suite à des problèmes techniques.

Un autre gant a fait son apparition quelques années plus tard. Celui-ci, plus technique, il faut office de manette Play Station: le Reality Quest Power Glove.Cette idée de manette-gant, permet de jouer à la PS avec une seule main, elle a était conçue et présentée pour les E3, un salon d’exposition de gaming.Le gant est conçu pour contrôler l’équivalent des 14 boutons et 2 joysticks à l’aide d’une seule main. La « manette » est fixée dans la pomme de la main. L’utilisateur contrôle les mouvements verticaux et horizontaux en pivotant le poignet, et utilisent les 4 boutons d’action principaux et L1/R1 avec les doigts. Les autres boutons sont accessibles par un seul bouton rond contrôlé par le pouce.
La manette est adaptée pour beaucoup de jeux vidéo, dont les plus simples sont les jeux de voitures et de combats (arcade).

; Problèmes:
*Besoin de toute la motricité de la main, c’est-à-dire que si le patient à un doigt paralysé ou manquant, il ne pourra pas jouer avec ce gant
*Design obligatoirement droitier
*Les boutons de contrôle sont peu sensibles et peuvent nécessiter de la force
*Design compliqué et nécessitant beaucoup d’entrainement.

;Lien : https://www.youtube.com/watch?v=qV0SxSJDCYg

 
==Analyse du second concurrent==

Ben Heck, de son vrai nom Benjamin J.Heckendorn, est un concepteur de mods de consoles (mods pour modification, soit « manettes modifiées ») et une star
du net grâce à ses vidéos tutoriels.Il propose alors énormément de produits adaptés ou dérivés en guise de manettes.
Parmi les mods qu’il a réalisé, il a modifié une manette de PS4 afin de la rendre accessible à une personne ne pouvant jouer qu’à une main. Pour cela, il a déplacé les boutons en respectant l’ergonomie de la main valide et modifie les connexions. Il peut lui arriver de rajouter des boutons pour en remplacer un autre. Il réalise également le même système avec la Xbox. Sur la photo ci-dessous, il a adapté la manette pour un droitier.

; Problèmes:
*Besoin de toute la motricité de la main, c’est-à-dire que si le patient à un doigt paralysé ou manquant, il ne pourra pas jouer avec cette ma
*Design obligatoirement droitier ou gaucher, une modification = une manette= une personne
*Besoin obligé du pouce et de l’index, même si avantage : 3 doigts nécessaire.

;Lien :: https://www.youtube.com/watch?v=LieHIscadjk

==Scénario d'usage du produit ou du concept envisagé==

La technologie est ,aujourd’hui, omniprésente dans notre vie. Les consoles de jeux ont envahies les maisons avec plus de 7 personnes sur 10 jouant aux jeux vidéos sur consoles en France (chiffre de l’Express). 0,18% des français sont handicapés cela représente 12 millions de français. Dans ce chiffre, 13,4% des personnes ont un handicap moteur. En 2017, les grands groupes comme Sony ou Microsoft avec respectivement PlayStation et Xbox ne permettent pas à tout le monde de jouer avec une manette. Les manettes sont prévues pour des personnes ayant leurs membres valides, plus précisément les mains et les bras.

Après un accident de voiture, un jeune garçon a perdu la motricité d’un côté du corps. Passionné de jeux vidéo, il se retrouve avec des difficultés à jouer sur sa console PS4. Ingénieux, il utilise la manette en la coinçant entre son épaule et le creux du cou. Usant de la mâchoire et de sa main valide pour contrôler les joysticks et les boutons. L'exercice étant inconfortable et fatiguant il eu l’idée de proposer à des futurs ingénieurs de lui proposer une manette adaptée à son handicap.

Les deux pré-ingénieurs ,avec leur tuteur, ont une idée révolutionnaire : La manette modulable ! Elle permettrait au jeune garçon, ainsi que d’autres joueurs, de pouvoir continuer de s’amuser ou même de commencer à jouer au jeux sur console.
Cette manette aidera fortement dans les centre de rééducation pour faire passer le temps et donner du plaisir à des personnes qui ne peuvent plus s’amuser avec leur console traditionnelle. Elle pourra aussi ouvrir de nouvelles possibilités pour certaines personnes qui n’auraient jamais essayé jusqu'à présent.
Comme son nom l'indique, elle sera modulaire et s'adaptera à différents handicaps. Accompagnée de son application d’initialisation, elle sera accessible aussi bien aux enfants, patients, parents et aides soignantes.

Quelques mois plus tard...Le jeune patient fan de Need For Speed, peut maintenant piloter sa voiture comme un vrai professionnel grâce à l'un des joysticks qu'il utilisera avec sa main valide et il pourra accélérer à des vitesses folles à l'aide de boutons poussoirs au niveau de son pied valide et gagner la partie. Son ami venu lui rendre visite, pourra en lieu et place des aides soignantes configurer à l'aide de la tablette (portable) la manette du patient.
Si le patient change de jeu pour Tekken et que la configuration des modules ne lui convient plus, il peut interchanger les éléments de la manette selon son envie et son confort. Ainsi il peut faire sauter son personnage, il utilisera un module bouton supplémentaire, qu'il actionnera avec le poing.

==Fonctionnement==

Suite à une analyse fonctionnelle et à la formulation de notre projet, nous avons pu définir le fonctionnement de notre système. Notre produit, la manette, doit être accessible d’après nos objectifs à différents types de handicaps moteurs. Ainsi, l’idéal serait de concevoir une manette modulable afin qu’elle puisse s’adapter à toutes les situations. Ce n’est plus au patient de s’adapter à la manette mais à la manette de s’adapter au patient.
Cela signifie que la manette sera, dans la limite du possible et de la sensibilité du corps du patient, composée de plusieurs parties dites « modules » comportant un ou plusieurs actionneurs (boutons, joysticks, gâchettes...). Ces modules seront déplaçables afin d’être utilisé avec différents membres du corps : un doigt, une main,
une jambe ou même un pied. Il suffira de les connectés entre eux suivant l’organisation souhaitée, le Gameplay du jeu ou en fonction du handicap. Le tout sera relié à une application.
L’application sera alors mise en place pour connecter les différentes parties du point de vue software pour prérégler la manette en fonction du patient. Il pourra alors choisir les boutons en fonction du jeu, de ses mouvements mais aussi choisir la sensibilité.

L’application et les modules devront être intuitifs et faciles d’utilisation. De cette manière des utilisateurs non avertis dans le domaine informatique ou jeunes pourront eux-mêmes gérer les connexions.

==Réponse à la question difficile==

'''Question : Comment interconnecter les différents modules de la manette ?'''

Il nous faut pour ce projet interconnecter les modules modélisant la manette qui seront connectés à la consoles PS4 via une Raspberry Pi 3.
Le choix de la Raspberry Pi 3 nous permet d'utiliser son module Bluetooth pour communiquer avec la PS4, ce choix est plus adaptée au projet que du filaire.
Concernant l'interconnexion des modules, nous travaillerons en deux étapes "preuves concept" : filaire et sans fils (Bluetooth).

'''Objectif 1 : Preuve concept filaire'''

Dans cette première partie de projet, nous souhaitons avoir une 1ère preuve de prototype rapidement. Nous nous concentrerons alors sur la communication entre la RPi3 et la PS4 ainsi que sur la conception des modules. Pour les modules, nous réaliserons des cartes électronique pour chaque module avec un micro-contrôleur. La communication filaire nous permettra d'interconnecter les modules à la RPi3 avec un bus SPI.

'''Objectif 2: preuve concept sans fils'''

Une deuxième étape du projet est la réalisation de la solution idéale sans fils. Celle-ci pourra commencer à être développée petit à petit en parallèle avec l'objectif 1. Le but ici, est d'interconnecter les modules en Bluetooth. Nous avons choisi le Bluetooth pour garder une connexion commune sur toute la chaîne.
Nous rajouterons alors un module bluetooth à chaque module de la manette.

'''Objectif 3: possibilité d'adapter les boutons (capuchon en 3D)'''

=Préparation du projet=

==Cahier des charges==

''Chef de projet:'' Alexandre Boé 
''Responsables:'' Xavier Redon, Thomas Vantroys 
''Partenariat:'' Marc Sautelet (non etablie) 
''Elèves-ingénieurs:'' Camille Saâd, Transley Gracias 

'''Sujet :''' Manette modulable pour personne à déficience moteur compatible PlayStation 4 

===Objectifs principal (1er POC) : ===
Faire transmettre des informations issus des actionneurs (ex:boutons poussoires) via des arduinos jusqu’à la Raspberry Pi 3 en SPI. 
Envoyer les données reçues vers la PS4 en USB 

===Objectifs secondaire (2e POC):===
Créer des modules avec un microcontrôleur et une puce bluetooth pour permettre une meilleurs flexibilité (c-àd pouvoirs avoir une meilleure ergonomie et une connexion sans fil) 
Connecter la Raspberry Pi 3 en Bluetooth à la PS4 

[[Fichier: beteacorne.jpg||middle|600px|Bete a corne manette]]

==Choix techniques : matériel et logiciel==

===Liste de matériel :===

'''Modules boutons/joysticks/gachettes'''

3 Push buttons : 
- O X Y Carré R3 L3 
- Guide PS 
- start/back 
--> 0,45€/unité TTC [https://www.gotronic.fr/art-bp-miniature-krs1273-16976.htm] 

1 Thumbstick original: 
Joystick analogique 4 directions --> 4,25€/unité TTC [https://www.gotronic.fr/art-joystick-analogique-4-directions-19063.htm] 

1 buttons trigger L1 L2 => 1x Thumbstick original''' 

'''Cartes Atmega328p /connexion spi/'''

3 Arduino UNO 
1 Arduino UNO atmega328p retirable 
4 capacite 22pF traversantes 
2 resistances 10 kOhm traversantes (à récupérer) 
2 oscillateurs quartz 16MHz traversante 
2 atmega328p-pu et support 

'''Cartes module bluetooth nrf52810 '''

6 capacités 100nF 0603 
6 capacités 12pF 0603 
2 capacités 4,7pF 0603 
2 capacités 1µF 0603 
2 capacités 100pF=0,1nF 0603 (à récupérer) 
2 capacités 0,8pF 0603 (a acheter, commande en cours) 
2 inductance 3,9nH 0603 (a acheter, commande en cours) 
2 oscillateur quartz 32 MHz 

''' Connexions et autres '''

1 Led RGB neopixel [https://www.adafruit.com/product/1734] 
1 Raspberry Pi 3 
--> ~36,23€/unité TTC [https://fr.rs-online.com/web/p/processor-microcontroller-development-kits/8968660/?src=raspberrypi] 
1 Raspberry Pi Zero W (commandée) [https://www.raspberrypi.org/products/raspberry-pi-zero-w/] 
6 Alimentations 5V ou 3,3V 
par exemple, 12 piles de type CR2016 3V rechargeables ou 24 piles AAA 1,5 V rechargeables
5 modules Bluetooth nrf de Nordic : nRF52810-QFAA-R 
--> 3,17€/unité + frais expédition [https://www.mouser.fr/productdetail/nordic-semiconductor/nrf52810-qfaa-r?qs=sGAEpiMZZMve4%2FbfQkoj%252bG%2FosjLoe2oghFQwQllMrQ4%3D]
5 Lignes broches mâles 

===Logiciels:===

- IDE arduino
- Altium
- FreeCAD ou Inkscape

==Liste des tâches à effectuer==

'''Etape 1 : Gestion du projet'''

* Définition des cahiers des charges fonctionnel et technique, choix d'orientation...
* Recherche techniques sur les différentes connexions possibles entre les modules, la RPi 3 et la console PS4
#Recherche connexion SPI entre les modules et la RPi3
# Recherche connexion bluetooth entre la RPi3 et la PS4
# Recherche connexion bluetooth pour les modules
# Recherche carte avec montage Atmega328P-PU et anticipation module bluetooth
* Détermination du matériel nécessaire
* Réflexion sur l'application

'''Etape 2: Réalisation du projet'''

'''Partie 1: Preuve concept manette en filaire'''

* Conception de cartes électroniques pour 2 modules (/!\ prévoir modules bluetooth)
* Réalisation connexion SPI avec 2 modules : programmation des Atmega328p en liaison série.
* Si tests concluant, ajouter des modules jusqu'à en avoir 5 (1 pour chaque type de boutons)
* Connexion bluetooth entre la PS4 et la RPi3
* Réalisation du support des modules avec fixations possibles (imprimante 3D)

'''Partie 2: Preuve concept manette en bluetooth'''

* Ajout des modules bluetooth aux cartes électroniques
* Connexion bluetooth entre les modules

'''Partie 3: Application Android : paramétrage de la manette'''

* Créer une application sur tablette ou smartphone (Android) afin de configurer la manette aux besoins (inter-connexion des modules et console)

==Calendrier prévisionnel==

{| class="wikitable centre" width="80%"
|+
|-
| width="23%" |
'''Date'''
| width="34%" |
'''Tache à réaliser''' 
|-
| width="23%" |
17/01/18-24/01/18
| width="34%" |
Faire des recherches sur les différentes interconnexions du système : Bluetooth, RPi-Atmega328 (SPI), RPi-PS4
Continuer liste des taches, matériel, Début recherches + réflexion fixation support des modules
|-
|width="23%" |
31/01/18
| width="34%" |
Recherche technique connexion PS4-RPi3 et connexion SPI RPi3-Module + code
|-
|width="23%" |
31/01/18-07/03/18
| width="34%" |
Réalisation 1er prototype (+ début prototype 2)
|-
|width="23%" |
07/03/18
| width="34%" |
Seance 7 : Test prototype filaire
|-
|width="23%" |
07/03/18-09/05/18
| width="34%" |
Réalisation 2eme prototype + application Android
|-
|width="23%" |
09/05/18
| width="34%" |
Seance 14 : Test prototype Bluetooth
|-
|width="23%" |
14/05/18
| width="34%" |
Video projet
|-
|width="23%" |
15/05/18
| width="34%" |
Finalisation projet et Rapport
|-
|width="23%" |
16/05/18-17/05/18
| width="34%" |
Soutenances Projet
|}

=Réalisation du Projet=

==Feuille d'heures ==

Voici le tableau d'heures du binôme:

{| 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 S11 !! Heures S12 !! Heures S13et+ !! Total
|-
| Analyse du projet
| 10
| 2
| 1
| 1
| 1
|
|
|
|
|
|
|
| 20min
|
| 15h20
|-
| Cherches techniques
|
| 3
| 4
| 4
| 2
| 2
| 1
|
|
|
| 1
| 1
|
|
| 18
|-
| Rédaction du wiki et rapport de projet
|
| 1
| 1
| 1
| 1
| 30min
| 1
|
| 2
| 30min
| 30min
|
| 2
|
| 10h30
|-
| Programmation
|
|
|
|
| 3
| 2
| 3
| 5
| 4
| 7
| 8
| 6
| 5
|
| 43
|-
| Cartes électroniques
|
|
|
|
|
| 6
| 8
| 4
| 6
| 2
| 1
| 2
| 2
|
| 31
|-
| Application
|
|
|
|
|
|
|
|
|
|
|
|
|-
|-
| Total Semaine
| 10
| 6
| 6
| 6
| 7
| 10h30
| 13
| 9
| 12
| 9h30
| 10h30
| 9
| 9h20
|
| '''117h50'''
|}

==Prologue==

Avant la réalisation et conception d'un projet, il est important d'analyser celui-ci. Nous avons allons consacré le prologue à l'analyse fonctionnelle de la manette. Nous avons également eu une réflexion sur l'analyse technique, cela nous a permis de réaliser une liste de matériel. Il est important de définir les objectifs ainsi que les besoins afin de ne rien oublier. (Voir ci-dessus Analyse projet)
Nous avons également organisé notre travail, pour le partage de documents de recherches et la rédaction de compte-rendu final nous avons réalisé un google drive. Par la suite, nous créerons un projet Git.

Durant ce temps, nous avons décidé de réaliser 5 modules. Les modules sont les différents boutons de la manettes qui nous pourrons placer selon nos choix (boutons modulaires) pour notre prototype projet pour chaque type des boutons d'une manette PS4. Ces modules devrons être connectés à la console et interconnectés. Le tout sera lié à une application Android. Suite à quelques recherches et nos analyses, nous avons décidé les points suivants :

- On commencera avec 2 modules et on les multipliera par la suite.
- Les premiers tests sont réalisés avec des boutons petits pour assurer leur caractéristique "modulaires", par la suite nous pourrons ajouter des capuchons de taille plus importante (imprimante 3D ou achat)
- Conception modules : réalisation de carte avec un microcontrôleur atmega328 programmable pour chaque module (anticiper le module Bluetooth)
- Projet en 2 parties : prototype filaire et prototype Bluetooth
# Prototype filaire : connexions entre les modules et la RPi3 en SPI, connexion Rpi3-PS4 en Bluetooth, avec l'application en filaire à la RPi3
# Prototype Bluetooth: connexion Bluetooth entre modules-RPi3-PS4-apllication

[[Fichier: structuremanette.png||center|400px|Concept manette modulable]]

==Semaine 1==

Durant la séance, nous nous sommes concentrés les recherches afin de définir clairement le cahier des charges technique. Il s'agit des réalisations à mettre en œuvre pour les inter-connexions des éléments de la manette.
Ainsi, nous avons fait des recherches sur :

===Connexion SPI entre les modules (Atmega328p) et la RPi3===

SPI: Serial périphérique interface BUS

[[Fichier: yWGmW.png||right|200px|Concept manette modulable]]
Comme indiqué sur l'image ci-dessus, la Raspberry pi 3 peut communiquer en SPI avec ses broches CS0 (24), CS1 (26), SCLK (23), MISO (21), MOSI (19). Celles-ci permettent de communiquer avec un ou plusieurs esclaves (dans notre cas, des Atmega328p) en reliant directement les broches concernées de la RPi3 à celles des composants esclaves.
Chaque broche CS0 (24) ou CS1 (26) ne peut être connectée qu'à l'entrée SS (aussi appelé CS) d'un seul esclave.
C'est a dire que chaque CS est lié à un esclave afin de choisir avec lequel la communication est établie à un moment donné, et les MISO sont reliées entre elles en cascade, de même pour les SCLK et les MOSI. On peut noter que le maître impose la fréquence d’horloge et sélectionne l’esclave auquel les données sont envoyées. 8 MHz est le plus rapide supportable a 3,3V

[[Fichier: fonctionnementSPI.png||right|200px|Connexion SPI multi-esclaves]]

Voici un schéma du fonctionnement souhaité :

Comme nous souhaitons avoir 5 modules environ il nous faudra rajouter un composant en plus afin d'augmenter les possibilités de sélection, par exemple des démultiplexeurs.
Dans un premier temps nous essaierons avec 2 esclaves, puis on augmentera le nombre.

===Connexion Bluetooth PS4-RPi3===

Les recherches portent également sur la connexion entre la manette PS4 et la console. Elles concernent le protocole de communication via Bluetooth

Caracteristique pour la PS4: Bluetooth®v4.0, Qualcomm Atheros AR3002 Buetooth LE: 2,4-2,5 GHz 

Caracteristique de la connexion : 

*Vitesse de transmission >> 3 Mbit/s 8N1
*Relevé tous les 1.3 millisecond (peut-être)
*Chaque manette à une adresse unique BD_ADDR qui correspond à l’adresse MAC de la carte Réseau
*Protocole de détection est le SDP basé sur une emission reception PDU
*L’Attribut ID est representer en TLV Type Length Value
*Communication HCI ACL Data Packet

===Rélisation des cartes électroniques===

matériel nécessaire pour un PCB : 

*breadboard
*câbles
*1 x 10k Ohm résistance
*Quartz 16Mhz clock crystal
*2 x 22 pF capaciteurs
*Atmega328P-PU

Ressources:
[[https://www.arduino.cc/en/Main/Standalone]]
[[http://www.eprojectszone.com/atmega-328-pu-standalone/]]
[[https://www.arduino.cc/en/Tutorial/ArduinoToBreadboard]]

==Semaine 2==

Durant la semaine deux et durant la séance, nous avons continué et approfondie nos recherches sur le projet. Nous avons pu ainsi affiner nos taches de réalisation et donc notre cahier des charges.

===Connexion aux modules: SPI et Bluetooth ===

 CORRIGER

voir https://peip-ima.plil.fr/mediawiki/index.php/BE_2017-2018#Configuration_du_syst.C3.A8me_embarqu.C3.A9

(sudo apt-get install pi-bluetooth)

''connexion sur la raspberry par ssh:''
su
update-rc.d ssh enable
invoke-rc.d ssh start
ssh pi@172.26.79.1XX

''bluetooth''
bluetoothctl
agent on
default-agent
scan on
pair [device Bluetooth address] (exemple: pair XX:XX:XX:XX:XX:XX )

''NOUVELLE REFLEXION : Connexion SPI entre les modules (Atmega328p) et la RPi3 --> MODULES BLUETOOTH''

Si multi-esclaves= plusieurs modules :
Il faut ajouter des sélections pour les SPI → démultiplexeurs OU ne pas utiliser les CS0 et CS1, et plutôt des pins entrée/sortie de la RPi3 lié au SS comme ça on choisit direct le module esclave voulu.

'''IMPORTANT:''' Nous avons étudié à nouveau la datasheet de notre module bluetooth nrf de Nordik. Le module bluetooth comporte déjà un microprocesseur !
Un module plutôt peut donc jouer le rôle de notre atmega328p. Il n'y a alors pas besoin de réaliser des cartes électroniques de type arduino standalone. Nos PCB regrouperont alors uniquement l'alimentation, un actionneur (bouton, joystick), le module bluetooth et les broches de connexion si besoin...

Cette séance nous a alors permise de revoir entièrement le matériel nécessaire. Notre liste de matériel nous semble alors plus réfléchie et limitée au nécessaire.

===Connexion Bluetooth PS4-RPi3===

Suite à nos recherches de la semaine précédente, nous avons sélectionné deux sites bien renseignés :

SITES

Ils nous ont permis de comprendre la communication entre la manette et la console. En effet, ils nous expliquent les échanges de trames Bluetooth.
EXPLICATIONS 1 exemple 

==Semaine 3 : Début premier prototype==

===Connexion SPI RPi3-Arduino===

Comme vu durant les semaines précédentes, nous souhaitons réaliser une connexion Multi-esclaves en SPI entre la Raspberry pi et plusieurs modules.
Cette semaine nous avons vu que la réalisation de notre premier prototype doit aller vite. Il ne nous est pas nécessaire d’attendre les modules bluetooth si il nous faut dans cette partie uniquement utiliser son microprocesseur. Ainsi pour chaque module nous utilisons une arduino UNO. Nous réaliserons les programmes en C afin de pouvoir les réutiliser avec les modules bluetooth par la suite.
Une fois la connexion réalisable nous adapterons les programmes aux modules bluetooth Nordik. En effet, ceux-ci comporte déjà un microprocesseur, le module peut jouer le rôle de notre atmega328p. Il n'y a aurait alors pas besoin de réaliser des cartes électroniques arduino standalone sur PCB, mais directement des cartes électronique avec le module et le module voulu (bouton, joystick...) et l'alimentation.
Durant la séance nous avons alors revu la liste de matériel nécessaire.

[[Fichier: prototype1.jpeg||center|600px|connexion filaire prototype 1 filaire arduino]]

Durant la séance, nous avons recherches des exemples de codes et de librairies pour Arduino SPI et RaspberryPI SPI.

Nous avons également commencé le programme de la connexion SPI pour l'arduino et récupéré les bibliothéques SPI.h avec SPI.c. Nous nous sommes alors concentrer à les comprendre, pour pouvoir l'utiliser.

===Réalisation du projet Git===

Création du projet IMA4_Projet35_ManetteModulable sur Git et partage de celui-ci.
Les premiers dossier crées cette la séance :
-Arduino (connexion SPI arduino) : ProtoSpi.c + dossier librairie SPI + Makefile
-RPI (dossier codes pour Rpi)
-Readme.md
Ces dossiers seront amenés à être modifiés au cours des séances.

===Protocole Bluetooth PS4===

Suite à l'étude des trames Bluetooth, on a pu voir que ces dernières étaient incomplètes. Le modèle de communication étant propriétaire, on n'y a pas accès directement. Cela nous empêche donc de mettre en oeuvre cette communication.
 Déveloper

On a décidé de commencer par une connexion USB (pour laquelle on dispose de toutes les informations) celle-ci étant plus complète.

==Semaine 4==

Pour le prototype 1 FILAIRE nous réaliserons les étapes suivantes :

#Réalisation du programme SPI pour arduino
#Réalisation du programme SPI pour la RPi
#Connexion USB avec la PS4 ou ordinateur
#Réalisation de cartes électroniques atmega328p-pu standalone (remplacer les Arduinos)
#Remplacer les "PCB arduino" par le module bluetooth et adapter la connexion
#Conception 3D de la délimitation 1 axe pour le joystick "gâchette"
#Réalisation de l'application Androïde.

Une fois ces étapes réalisées nous auront alors une preuve de concept filaire et nous pourrons alors passer à une connexion bluetooth.
Le passage à la connexion bluetooth sera le deuxième prototype et le cas idéal de la réalisation de la manette modulable.

===Mise à jour Matériel===

- Modéliser les boutons gâchettes L1/2 R1/2 de la manette PS4 (boutons sensibles à la pression) --> un joystick dont nous bloquerons un axe (imprimante 3D)
- Remplacer la RPi 3 par une Rpi zero W qui nous permettrait de réaliser plus facilement une connexion USB tout en gardant l'avantage du bluetooth.
- Choix de l’alimentation pour les 5 modules Bluetooth: nécessitent 3V --> utiliser des piles rechargeables 1,2V AAA plutôt que piles rondes 3V.

Nous avons également besoin du matériel cité en semaine 1 pour réaliser des cartes électroniques atmega328p-pu standalone. ( nous revenons alors sur les décisions de la semaine 3)

===Connexion SPI RPi3-Arduino===

Montage Raspberrypi et 1 arduino en PSI + 1 bouton + 1 led.
Voici le choix des branchements :

MASTER = RPi
SLAVE= Arduino

'''SPI sur Arduino:'''
MOSI -> GPIO11 //PB3 //master OUT to the slave IN
MISO -> GPIO12 //PB4 //slave OUT to the master IN
SCLK -> GPIO13 //PB5 //serial clock
SS -> GPIO10 //PB2 //slave select
'''Led, bouton et autre...'''
LED --> GPIO6 //PD6
GND
+5V (if required)
'''SPI sur la Raspberry Pi'''
SPIO MOSI -> PIN19
SPIO MISO -> PIN21
SCLK -> PIN23
SPIO CS0 -> PIN24

Continuation du code pour faire clignoter Led branchée à une arduino depuis la Rpi, en connexion SPI.

===Connexion USB PS4-RPi3===
Durant cette, nous avons regardé comment faire cohabiter bluetooth, Application Androïd, USB, PS4, SPI et les module.

Il est alors important de savoir comment utiliser le port série sur la RPi3, soit utiliser les UART.

Nous avons réaliser qu'il n'était pas aussi simple d'utiliser le port serie USB de la Raspberry Pi 3, en effet le SoC est un BCM2837 .
De plus nous ne pouvons pas utiliser le même port pour l'alimentation et la connexion.

Il nous faut alors trouver une alternative ou une solution à ce problème.

==Semaine 5==

===Programmation: Réflexion définitives prototypes filaire ===

La semaine dernière, nous avons rencontré une difficulté liée aux ports séries UART.
Une des solutions à cette difficulté serait d'utiliser une RPi ZERO W à défaut d'une RPi 3. On pourrait alors avoir un port d'alimentation avec connexion USB mais également retrouver la connexion Bluetooth dont nous avons besoin.

Ensuite, nous avons continué la réalisation du prototype filaire par l'avancé du code SPI ainsi que les recherches concernant le protocole PS4.

La Raspberry Pi zero W peut également être utile pour la connexion entre la PS4 et les différents modules en jouant le rôle d'intermédiaire. Nous avons alors commandé une Rpi zero W pour notre projet.
En attendant la réception de la commande, nous nous sommes penché sur les recherches pour les programmes et la configuration nécessaire à l'utilisation de la RPi zero W.

===Electronique===

[[Fichier: bouton_c1.jpg|100px|thumb|left|PCB bouton]]
[[Fichier: arduinobb.jpg|200px|thumb|right|atmega328p-pu branchement test]]

Du coté électronique, nous avons réalisé sur fritzing certaines cartes électroniques. Les Arduino Uno servant actuellement de test, seront remplacées par des PCB atmega328p-pu standalone avec des broches permettant les branchements nécessaires SPI ou encore aux modules "boutons/joystick". Pour les boutons, nous avons également réalisé un pcb afin de faciliter les branchements.

Il nous faut alors également une 3eme carte qui nous sera nécessaire pour la réalisation du prototype sans fil. Dans notre liste de matériel, nous avons des composants nrf52810 bluetooth, ceci doivent être soudé avec les capacités de protection mais également des broches de communication. Nous avons alors commencé cette carte électronique sur Altium avec le fichier projet PCB du distributeur à modifier.

[[Fichier: Arduino_c1.jpg|100px|thumb|center|PCB atmega328p-pu]]

=== Construction 3D ===

Enfin, nous avons commencé à réaliser des boîtiers 3D pour certains modules. Par exemple, comme nous l'avions vu précédemment, un des joysticks servira de bouton-gâchette en utilisant un seul de ses axes. Il nous faut alors réaliser un boitier qui bloque l'un des axes, mais également une tige qui nous permettra de pousser le joystick de manière simplifiée.

==Semaine 6==

===Programmation: configuration RPi Zero W ===

Ayant reçu la Raspberry Pi zero W en début de semaine, nous nous sommes concentrés sur la programmation et la configuration de celle-ci.
Cette partie étant compliquée, elle nous a pris du temps. En effet, il était difficile de connecter la RPi en SSH car il n'est pas possible d'y connecter un clavier directement et on avait besoin de la prise OTG pour "interfacer" la manette.

===Electronique: PCB nrf52810===

Les cartes réalisées en semaine 5 sont validées et en attente de réalisation.

Cette semaine a permis la réalisation et la finalisation de la carte électronique nrf52810. Il nous a fallu recommencé cette carte deux fois. En effet, une fois finie sur Altium nous avons réalisé que les empreintes des CMS sur PCB fourni par le constructeur ne correspondent pas au matériel CMS de l'école. Face à cette inattention de notre part, nous avons décidé de refaire entièrement la carte électronique sur fritzing. Ayant la datasheet et des plans d'inspiration PCB, nous avons pu refaire la carte entièrement.
Sur celle-ci nous avons ajouté des broches de connexion au besoin, un branchement Jtag et ICSP pour la programmation et la connexion SPI.
La carte est en attente de validation, puis validation.

[[Fichier: nrf52810_circuit2.jpg||center|400px|PCB carte nrf52810]]

===Révision matériel ===

Pour la réalisation de nos composants électroniques, il nous a fallu faire une révision des composants disponibles à l'école:
(les quantités indiquées ci-dessous pourront être augmentée si nécessaire,pour avoir dans l'idéal un module de chaque type de la manette, ici on se concentre sur BOUTON et JOYSTICK)

'''Cartes Arduino:'''
* 4 capacite 22pF traversantes
* 2 resistances 10 kOhm traversantes (à récupérer)
* 2 oscillateurs quartz 16MHz traversante
* 2 atmega328p-pu et support

'''Cartes nrf52810'''
* 6 capacités 100nF 0603
* 6 capacités 12pF 0603
* 2 capacités 4,7pF 0603
* 2 capacités 1µF 0603
* 2 capacités 100pF=0,1nF 0603 (à récupérer)
* 2 capacités 0,8pF 0603 (commande en cours)
* 2 inductance 3,9nH 0603 (commande en cours)
* 2 oscillateur quartz 32 MHz

'''Cartes modules Boutons'''
* un sachet de broches mâles (qu'on utilisera également pour les autres cartes, à récupérer/acheté)

Nous avons alors mis-à-jour la liste de composant située plus haut, ainsi que celle de la page IMA4 2017/2018 [https://projets-ima.plil.fr/mediawiki/index.php/Projets_IMA4_SC_%26_SA_2017/2018]

==Semaine 7==

===Programmation: connexion wifi RPi Zero W et Bootloader sur Atmega328p-pu ===

Pendant cette semaine, nous avons continué la programmation et la configuration des Raspberry Pi 3 et Zero W. Concernant la configuration ssh, nous avons utilisé un téléphone en guise de point d’accès à la RPi Zero W en wifi.
Nous avons aussi directement configurer l'OS Jessie, utilisé pour la RPi Zero. On a modifié le fichier cmd.txt et ...pour pouvoir programmer un USB gadget sur le port OTG.
Ci-dessus expliquer fichiers

Nous avons également continuer les programmes de récupération de données : état des boutons et du joystick. Ces programmes sont appliqué sur l'atmega328p-pu standalone sur la plaque d'essai en attendant que le PCB soit opérationnel.
Pour pouvoir programmer l'atemega328p-pu comme une arduino UNO, il nous faut suivre plusieurs étapes :

'''1.Flasher le Bootloader'''
Nous avons 2 Atmega328p-pu neufs, ainsi il nous faut flasher le bootloader sur chacun d'eux afin de pouvoir les utiliser et les programmer sur une breadboard dans un montage minimaliste arduino-standalone.
Pour cela, on peut utiliser une carte arduino UNO. On vérifie le port et le type de carte sélectionnés dans le menu >Outils. Sur cette carte on téléverse le fichier arduinoISP.ino qui se trouve dans les exemples en étant en progrmamateur AVr ISP mkll (>outils>programmateur)
Puis on met l'atmega328p-pu qui nous intéresse sur le suppor socket de la carte. On change de nouveau le programmateur pour Arduino as ISP et on fait >tools>burn bootloader, soit >graver la sequence d'initialisation.
Ces étapes faites, on peut retirer notre microcontroleur et le replacer correctement dans le montage.

'''2.Programmation atmega328 sur breadboard'''
Une fois l'atmega328p-pu préparé, on peut le programmer. On peut le faire simplement à l'aide de la carte arduino UNO utilisée précédemment.On branche les Tx et Rx en commun ainsi que le reset, le GND et le VCC.

Nous avons réaliser des codes basiques tels que le clignotement d'une led rouge ou encore l'affichage de "hello world" sur le moniteur série pour vérifier la bonne fonctionnalité du montage. Cela fait nous avons pu écrire sous Arduino IDE le code de lecture des états.

[[Fichier: montage_BB_test.jpg||left|200px|programmation modules arduino sur breadboard]]

===Electronique : soudure carte de test modules ===

Comme nous l'avons déja vu lors de la réalisation des PCB, si l'on souhaite programmer un atmega328p-pu en bootloader, le montage est simple. Il peut être minimaliste en utilisant une arduino UNO, un atmega328, une breadboard et 3 composants: 1 quartz 16MHZ crystal, 1 résistance 10kOhm et 2 capacitors céramiques de 22pF.
Durant la semaine 7, nous avons soudé les composants traversants de la carte électronique correspondant à ce montage ainsi que le PCB du bouton.

==Semaine 8==

===Programmation ===
Après moult recherche sur les différents site web bien fournis pour le coups on as pu trouvé une amorce à la programmation de l'OTG via un script qui agit au niveau du kernel dans le sous dossier usg_gadget. Ce script donne les informations nécessaires pour pouvoirs échangé les données.
Avec le script trouvé et les informations des sites web décryptant les trames de la manette, on a toujours pas réussit à faire passer notre RPi Zero W pour une manette de PS4. Néanmoins il nous manque la trame HID complète de la manette pour avoir un test effectif.

===Electronique : Correction soudure et soudure CMS===

Durant cette semaine, nous avions souhaité programmer la carte électronique atmega328p-pu. Cependant, nous avons réaliser que nous avions fait une erreur lors de l'envoie du PCB à la production. En effet, celui-ci avait été fait en Top sur le logiciel Fritzing et non en Bottom. Hors nous avions soudé les composants (durant la semaine 7) comme pour un circuit imprimé en bottom, l'atmega328p-pu se retrouve alors inversé par rapport aux pistes.
Comme solution, nous avons choisi de souder un deuxième support pour l'atmega328 de l'autre coté de la carte avant de la refaire au propre. En effet, avant de la refaire il nous faut vérifier si la carte est bien programmable.
Une fois cela fait nous avions pu programmer la carte mais, nous avions également réalisé la pin 2 de l'atmega328 était prise par le bouton poussoir. Or, nous avons besoin des pin 2 et 3 pour le RX et TX permettant la programmation de l'atmega à partir d'une arduino, les pistes branchement RX-TX n'ont également pas été prévus pour le téléversement des programmes sur la carte. Il nous faut alors couper une piste et souder des câbles pour utiliser toutes les pistes souhaitées.

[[Fichier: correction_proto_PCB.jpg||right|300px|PCB arduino correction]]

Durant cette semaine, nous avons également souhaité souder les CMS et le composant bluetooth nrf52810 sur la carte imprimé et reçu lors de la semaine 7. Pour cela, nous avons convenu de travailler dans la C202 durant la séance du mercredi.

[[Fichier: PCB_nrf52810.jpg||left|400px|carte electroniques imprimées]]

====Comment souder des CMS ?====

les CMS sont des composants montés en surface c'est à dire qu'ils sont montés du même côté que les pistes cuivrées (à l'opposé des composants traversants) et sont de petite tailles souvent de l'ordre du millimètre. La taille est déterminée par 4 chiffres : les 2 premiers pour la longueur et les 2 derniers pour la largeur. On a du 1206,0805,0603 ou encore 0402. Il est même possible de trouver plus petit. A l'école nous utilisons souvent du 0603, c'est le cas de nos composants.
Pour souder des CMS 0603, il nous faut utiliser une autre méthode qui n'est pas le fer à souder :
# Préparer la veille la pâte à braser la veille (dans une seringue)
# Gommer la carte pour éviter l'oxydation (attention à ne pas retirer les miettes de gomme en soufflant dessus)
# Appliquer avec la seringue la pâte sur les empreintes et piste souhaitées. Pour les endroits difficile à atteindre ou avec 2 pistes proches les unes des autres, il est possible de mettre la même goutte de pâte sur les 2 pistes. Cela de causera pas de court-circuit par la suite. En effet, la pâte est composée d’alliage qui sous la chaleur va se fluidifier et se coller uniquement aux pistes métallique. Le reste fondera sous la chaleur du four.
# Appliquer les CMS sur la pâte au fur et à mesure (attention ! ne jamais toucher les CMS avec les doigts, tjrs utiliser une pince)
# Mettre au four

====Bilan soudure nrf52810====

Cependant, une fois le matériel nécessaire préparé, et la pâte mise sur les pistes souhaitées, au moment de déposer le composant, nous avons réalisé que celui-ci était beaucoup plus petit que l'empreinte sur le PCB. Il s'agit d'un composant boitier QFN48. Fritzing ne proposant au plus proche des boitiers QFN24 ou LQFP48, celui-ci a basculé automatiquement pour un boitier LQFN48, de dimension plus grande. Face à ce manque de vigilance, nous avions cependant commencer par le nrf52810 (composant concerné) évitant ainsi de gaspiller d'autres CMS.
Nous avons souhaité refaire la carte sous Altium à partir des fichiers fournis par le concepteur (chose que nous avons commencé à faire aux alentours de la semaine 5)
Après la réalisation du schématic, et de la modification des empreintes de capacités, inductances et autres composants de 0402 à 0603. Notre matériel ne permettant que des empreintes 0603.

Lors du routage, une erreur de chevauchement des pistes est notifiée par Altium au niveau du nrf52810. Celles-ci ne présentent pas d'angles et sont déjà de taille 8mil, il nous faut alors passer les pistes en 6mil. Mais 8mil est la taille minimale pour la production à Polytech, nous avons regardé pour envoyer les cartes à faire ailleurs mais le 6mil n'est pas beaucoup conseillé. De plus, il n'est peut-être pas judicieux de continuer avec le composant microcontrôleur-bluetooth Nrf52810 qui prend du temps, donc la carte est difficilement réalisable et peut-être très long à programmer.

Ainsi en cette fin de semaine, nous avons décider face à l'avancer du projet de laisser les nrf52810 de coté et de les remplacer par des modules sans fils plus simples d'utilisation et complets. Ainsi nous aurions plus de chance d'avoir une connexion sans fils entre les modules. Nous pourrions par exemples utiliser des Xbee, des modules Rf...

==Semaine 9==

====Programmation: PS4 et 1er Test SPI sur atmega328p====

'''Raspberry Pi Zero W et PS4'''

Les premiers tests sur Windows ne nous donner pas satisfaction. En effet, l'ordinateur détectait bien le nouvel appareil avec son nom mais l'origine rester inconnue.

Lors des tests sur Linux on a pu voir des erreurs via la commande 'dmesg' :

[193229.758782] usb 4-1.2: new high-speed USB device number 6 using ehci-pci
[193230.270780] usb 4-1.2: new high-speed USB device number 7 using ehci-pci
[193235.510842] usb 4-1.2: device descriptor read/64, error -110
[193251.127043] usb 4-1.2: device descriptor read/64, error -110
[193251.315043] usb 4-1.2: new high-speed USB device number 8 using ehci-pci
[193256.503135] usb 4-1.2: device descriptor read/64, error -110
[193272.119331] usb 4-1.2: device descriptor read/64, error -110
[193272.307331] usb 4-1.2: new high-speed USB device number 9 using ehci-pci
[193282.999473] usb 4-1.2: device not accepting address 9, error -110
[193283.079485] usb 4-1.2: new high-speed USB device number 10 using ehci-pci
[193293.751588] usb 4-1.2: device not accepting address 10, error -110
[193293.751771] usb 4-1-port2: unable to enumerate USB device
[193387.196861] usb 4-1.2: new high-speed USB device number 11 using ehci-pci
[193392.440941] usb 4-1.2: device descriptor read/64, error -110
[193407.933152] usb 4-1.1: new high-speed USB device number 12 using ehci-pci
[193413.177227] usb 4-1.1: device descriptor read/64, error -110

'''Modules Atmega328p et SPI'''

Une carte PCB arduino fonctionnant, nous pouvons la programme pour simuler un module. Celle-ci a été designée afin de s'adapter au module que l'on souhaite. Il suffit de brancher le bouton, le joystick ou autre élèment de manette souhaité.
Cette semaine ci, nous avons alors configurer la partie communication SPI pour l'arduino.

'''Que voulons-nous faire avec les atmegas ?'''
Les cartes électroniques atmega328p vont nous permettre de recevoir les requêtes SPI envoyées par la raspberry pi et d'y répondre. La Raspberry enverra un message, par exemple "1", et l'Arduino lira alors l'état du module qui lui est connecté. Une fois l'état récupéré elle le renvoie à la raspberry pi.

Durant cette semaine, nous avons programmé l'atmega afin qu'il soit en esclave, qu'il reçoive un de la RPi "1" et retourne une valeur sauvegardé "int envoi". Nous avons également commencé les tests pour la lecture de l'état d'un bouton (d'après les tests réalisés les semaines précédentes).

'''Code'''
Comme nous l'avons vu précedement lors de nos recherches (semaines 1 à 4) :
La communication SPI nécessite l'utilisation des pins:

MOSI -> GPIO11 //PB3 //master OUT to the slave IN
MISO -> GPIO12 //PB4 //slave OUT to the master IN
SCLK -> GPIO13 //PB5 //serial clock
SS -> GPIO10 //PB2 //slave select

Il faut également paramétrer l'atmega328p en Slave. On note que dans un premier temps, le programme sera codé avec l'arduino IDE (fichiers .ino). Une fois l'ensemble SPI RaspberryPi-Arduino fonctionnant, on remplacera ces codes par du langage C ou C++.

Pour faire la connexion SPI sur l'atmega328p, on utilise la librairie arduino SPI.h, on a alors directement les fonctions nécessaires intervenant sur les registres souhaités : SPCR (spi control register), SPSR (spi status register) et SPDR (spi data register).

#include <SPI.h>

Il est important d'initialise d'abord le setup et on active le port série pour pourvoir utiliser le moniteur série. (Cela servira à verifier la valeur envoyée par la RPi)

void setup (void)
{
Serial.begin (9600);
pinMode(MISO, OUTPUT); //configuration en esclave *master in slave out*
pinMode(buttonPin,INPUT); //config pin bouton
// turn on SPI in slave mode
SPCR |= _BV(SPE);
// preparation interruptions
pos = 0; // buffer empty
process_it = false;
// activation interruptions
SPI.attachInterrupt();
}

On oublie pas de déclarer les interruptions afin de bien lire la requête reçue.

// SPI interrupt routine
ISR (SPI_STC_vect)
{
byte c = SPDR; // grab byte from SPI Data Register
// add to buffer if room
if (pos < sizeof buf)
{
buf [pos++] = c;
// example: newline means time to process buffer
if (c == '\n')
process_it = true;
} // end of room available
} // end of interrupt routine SPI_STC_vect

Dans la loop main, on traite la requête et on utilise '''SPI.transfer(envoi);''' pour transferer à la RPi les données souhaitées.

Durant cette semaine, nous avons également commencé des programmes de test SPI pour la RPi. Il s'agit principalement de programmes de tests tout faits permettant de vérifier la connexion entre cette dernière et l'arduino. Par exemple, la RPI envoie "bonjour" et l'arduino lui retourne ce qu'elle reçoit, soit "bonjour". Sans succés alors.

====Electronique : Fritzing révision====

Lors de la semaine, le modèle PCB de la carte arduino a été réalisé de nouveau sous fritzing avec les broches et connections manquantes. Nous avons également revu la configuration du bouton reset et ajouté une led d'état de l'alimentation. Nous avons ainsi envoyé deux cartes identiques à la réalisation.
La carte déjà soudée lors des derniers jours fonctionnant, elle nous sert de prototype de programmation. Nous pouvons ainsi avancer à la fois sur la programmation des modules mais aussi sur leur réalisation.

==Semaine 10==

====Programmation : PS4 et SPI sur RPi====

'''Raspberry Pi Zero W et PS4'''

Cette semaine, pour tester la prise OTG nous avons décider de lancer un script qui est habituellement utilisé. Nous avons choisi le script Serial Adapter qui est censé permettre de se connecter à la RPi Zero W en SSH via ce port.
Après quelque modifications et plusieurs petits bugs, nous avons réussir à faire fonctionner le ssh via le port OTG. Donc le problème était le même, notre script mélangé avec les informations sur la PS4 n'était toujours pas fonctionnel.

Pour faire la liaison entre les deux parties nous avons aussi commencé à programmer une application qui permet de configurer les modules au niveau de la RPi Zero W.

'''Modules Raspberry PI et SPI'''

Durant cette semaine, pour la partie Atmega328p-Modules, nous nous sommes concentrés sur la programmation de la communication SPI avec la raspberry pi. Cette semaine a permis une étude plus approfondit sur le fonctionnement pour la RPi.

On rappelle, comme vu des semaines 1 à 4, pour la RPI3 (tout comme la RPi Zero W) utilise les broches : SCLK (23), MISO(21), MOSI (19) et SPI CS0 (24), SPI CS1 (26).
On la programme en Master. A l'aide des fichiers tests d'inspiration, on pourra directement programmer la RPi en C. Lors de la réalisation du code, il y a 3 étapes : l'initialisation/parametrage en SPI pour être maître, l'envoie de la requête puis la réception de données en retour.

Programmant en C, il ne faut pas oublier les librairies suivantes :

#include <stdint.h>
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
#include <getopt.h>
#include <fcntl.h>
#include <sys/ioctl.h>
#include <linux/types.h>
#include <linux/spi/spidev.h> //pour SPI

On va déclarer des variables globales permettant le paramétrage :

static const char *device = "/dev/spidev0.0"; //si on veut CS0 pour atteindre notre SS
static uint8_t mode; //mode est par défaut à 0
static uint8_t bits = 8; //bits par mot échangé
static uint32_t speed = 500000;
static uint16_t delay;

Dans notre main, on ouvre le port (la connexion) au device souhaité, on vérifie les paramètres (registres, connexions...) puis exécute la fonction transfer(fd). transfer(fd) transmet la requête et s'occupe de la réception.

fd = open(device, O_RDWR);
transfer(fd);
close(fd);

==Semaine 11==

====Programmation: PS4, SSH et tests SPI (RPi3&Atemga328p)====

'''Raspberry Pi Zero W et PS4'''
Lors de recherche supplémentaire, nous avons essayer de voir s'il un pilote de gestion du périphérique serait nécessaire à la connexion de notre pseudo manette.

'''Raspberry PI, Atmega328p et SPI'''

Afin de facilité la programmation en utilisant Ethernet, nous avons installer et configuré la RPi pour l'utiliser en SSH depuis les ordinateurs de la E306. En effet, SSH permet de se connecter à distance sur une machine en utilisant un compte utilisateur de la dite machine. En mettant ssh, on pourra directement agir sur les fichiers de la raspberry depuis un terminal de notre PC. Pour cela, on a d'abord vérifier l'adresse IP de notre raspberry pi : 172.26.145.106 avec un écran mais on peut aussi utiliser les commandes ip a et ifconfig. Puis activer le ssh sur la raspberry pi.
On modifie alors le fichier config.txt mais également etc/network/interfaces pour configurer la bonne interface Ethernet sur la raspberry pi.

[[Fichier: configSSH_raspi.png||left|300px|config ssh ethernet]]

Il nous suffit alors de taper la commande : ssh pi@172.26.145.106 pour accéder à notre RPi.

Nous avons continué à réaliser la communication SPI avec des tests entre une arduino UNO et la RPI3. Nous avons commencé par des tests simples inspirés des études de deux semaines précédentes et modulés selon notre utilité.
Nous arrivons alors à lire l'état envoyer "bonjour" et recevoir "ça va" ou encore "1" et recevoir "3". Il faut noter que le SPI échange des trames, la RPI reçoit alors des hexadécimaux.
Nous avons alors continué pour recevoir l'état du bouton ou du joystick lors de l'envoie de "1" sur l'Arduino328p. La semaine prochaine nous testerons ces même codes fonctionnels sur les cartes atmeg327p.

A la fin de cette semaine, nous avons alors des codes Arduino-SPI (.ino) et des codes Raspberry-SPI (.c) permettant l'échange de données. Le but est maintenant de l'adapter aux cartes imprimées et de le rendre pleinement fonctionnel pour plusieurs cartes à la fois, puis ajouter une boucle de vérification en continue jusqu'à une deuxième requête de la RPi.

====Electronique: réalisation au propres des PCB modules====

Suite à une nouvelle erreur de réalisation cartes électronique, nous avons refait et renvoyé à nouveau les cartes imprimées atmega328p.
Nous les souhaitons au propre pour une version finale. Une fois celle-ci imprimées nous pourrons en avoir 3 , un pour chaque module. Les cartes étaient bien imprimées en bottom mais lors du passage des traversants de bottom à top, le logiciel ne les a pas fait miroiter. Par manque d'attention nous avons alors envoyé les fichiers gerber pour des cartes ayant les composants du même coté que la couche de cuivre.
Les cartes électroniques actuelles sont alors correctes et fonctionnelles mais difficile à souder. Pour eviter les erreurs et continuer sur des prototypes de carte nous préférons attendre en nous concentrant sur la programmation PSI de la Raspberry Pi.

==Semaine 12==

====Programmation====

'''Raspberry Pi Zero W et PS4'''

Cette semaine nous avons décidé de prendre un cap temporaire. On a utiliser un script pour faire un pseudo clavier/souris pour essayer d'envoyer nos données puis modifier petit à petit jusqu'a avoir un script/programme compatible PC. Il devra ce faire passer pour un Joystick donc une manette classique.

'''Raspberry PI, Atmega328p et SPI'''

- réflexion: penser à faire boucler sur l'arduino une fois la requête reçu, ça veut dire que la manette est ON et donc vérifier continuellement les modules sur chaque atmega.
- SPI raspberry pi - arduino recuperation état du bouton avec les cartes modules (/!\ récuperation à faire dans une variable)

-SSH perso
adresse Rasppi: 192.168.137.10

====Electronique: Finalisation soudure Modules====

Soudure au propre et finale d'une carte atmega328p et donc envoie pour la réalisation de 2 autres cartes similaires et récupération de matériel
Soudure des 2 autres cartes, + tests sur les états = fonctionnelles.
On a donc bien 3 cartes pour les 3 modules de types différents (1 bouton, 1 joystick, 1 gachette)
PCB pour les 2 joysticks (qui serviront de thumbstick et gachette)

==Semaine 13 et plus==

====Programmation====

'''Raspberry Pi Zero W et PS4'''

L'objectif de cette dernière semaine étant donc de faire une POC sur PC puis migrer doucement vers un usb_gadget compatible PS4 sachant que les clavier sont déjà utiliser par les PS4 (pas forcément pour jouer).

'''Modules Atmega328p et SPI'''

====Electronique====

=Documents Rendus=

(à mettre rapport + git + drive)

=Datasheets=

IMA4 2017/2018 P35

2018-05-05T20:25:10Z

Tgracias : /* Programmation */

__TOC__
 

=Présentation générale: Manette modulable=

==Description==

Tout le monde joue aux jeux vidéo cependant, les manettes ne sont pas adaptées aux personnes ayant un handicap pouvant toucher les bras ou les mains.
C’est le cas, de plusieurs patients dans les centres de soins et de rééducation.

Pour ce projet IMA4, nous travaillerons avec le centre SSR (soin de suite et de réadaptation) Marc Sautelet de Villeneuve d’Ascq.
Un adolescent, patient de Marc Sautelet, est passionné par les jeux vidéo. En effet, ayant perdu la motricité d’une partie de son corps, il ne peut pas jouer à deux mains. Pour cela, il bloque la manette entre son épaule et son coude, usant de la mâchoire et des doigts pour contrôler les
joysticks et les boutons. Cet exercice peut s’avérer fatiguant et pénible.

Ainsi, nous chercherons à concevoir une manette PS4 adaptée au handicap de l’adolescent.
Cette manette devra aussi être adaptée pour d’autres patients présentant également des handicaps moteurs. Ainsi nous prendrons pour cibles: tous les patients du centre voulant jouer; et non pas que les enfants et adolescents.

 

{| class="wikitable centre" width="80%"
|+
|-
| width="23%" |
Membre du projet
| width="34%" |
Transley Gracias et Camille Saad
|-
| width="23%" |
Cible
| width="34%" |
Patient présentant un handicap moteur
|-
|width="23%" |
Période du projet
| width="34%" |
janvier 2018 - mai 2018
|-
|width="23%" |
Partenaire/Client
| width="34%" |
Centre SSR Marc Sautelet à Villeneuve d'Ascq
|}

==Objectifs==

Ce projet a pour objectif de créer un prototype de manette qui puisse interagir avec la console PS4 et dont le paramétrage se fait à l’aide d’une application mobile et/ou web. Cette manette devra suivre les demandes du patient ainsi que des aides-soignantes du centre, dans la mesure du possible.

Plus précisément, pour le premier prototype, nous mettrons en œuvre l'utilisation de quelques boutons spécifiques:

* Un joystick (type L/R)
* Quelques boutons poussoirs (type Croix/Triangle/Carré/Rond/R1/L1/Start/...)
* Des boutons gâchettes progressives (type L2/R2).

Le but serait donc dans un premier temps de rendre fonctionnel un bouton de chaque type, puis de les multiplier une fois cela fait. Tous ces boutons réunis constituent une manette fonctionnelle.Ainsi, la manette sera ajustable, c’est à dire qu’elle devra s’adapter aux différents handicaps moteurs possibles.

=Analyse du projet=

==Positionnement par rapport à l'existant==

Notre prototype aura une présentation unique par rapport à l’existant. En effet, les concurrents et produits existants ciblent pour la majorité un seul handicap. Cela
engendre une solution fermée à beaucoup de patients. Notre projet propose une mobilité des mouvements et également un choix large dans la composition et le
design de notre manette.
Le patient n’est pas retreint à jouer à une seule main, à utiliser beaucoup de force...Il y a moins de technique dans la manipulation et on ne joue pas avec une
manette adaptée uniquement pour un droitier ou un gaucher. Cependant, cela nous limitera peut-être dans le choix possible des types de jeux. Tout comme les autres
manettes adapté, l’utilisateur nécessitera un peu d’entrainement.

==Analyse du premier concurrent==

Jouer aux jeux vidéo à une main n’est pas une idée d’aujourd’hui. En 1990, Nintendo propose le Power Glove. Mais il tombe très rapidement aux oubliettes suite à des problèmes techniques.

Un autre gant a fait son apparition quelques années plus tard. Celui-ci, plus technique, il faut office de manette Play Station: le Reality Quest Power Glove.Cette idée de manette-gant, permet de jouer à la PS avec une seule main, elle a était conçue et présentée pour les E3, un salon d’exposition de gaming.Le gant est conçu pour contrôler l’équivalent des 14 boutons et 2 joysticks à l’aide d’une seule main. La « manette » est fixée dans la pomme de la main. L’utilisateur contrôle les mouvements verticaux et horizontaux en pivotant le poignet, et utilisent les 4 boutons d’action principaux et L1/R1 avec les doigts. Les autres boutons sont accessibles par un seul bouton rond contrôlé par le pouce.
La manette est adaptée pour beaucoup de jeux vidéo, dont les plus simples sont les jeux de voitures et de combats (arcade).

; Problèmes:
*Besoin de toute la motricité de la main, c’est-à-dire que si le patient à un doigt paralysé ou manquant, il ne pourra pas jouer avec ce gant
*Design obligatoirement droitier
*Les boutons de contrôle sont peu sensibles et peuvent nécessiter de la force
*Design compliqué et nécessitant beaucoup d’entrainement.

;Lien : https://www.youtube.com/watch?v=qV0SxSJDCYg

 
==Analyse du second concurrent==

Ben Heck, de son vrai nom Benjamin J.Heckendorn, est un concepteur de mods de consoles (mods pour modification, soit « manettes modifiées ») et une star
du net grâce à ses vidéos tutoriels.Il propose alors énormément de produits adaptés ou dérivés en guise de manettes.
Parmi les mods qu’il a réalisé, il a modifié une manette de PS4 afin de la rendre accessible à une personne ne pouvant jouer qu’à une main. Pour cela, il a déplacé les boutons en respectant l’ergonomie de la main valide et modifie les connexions. Il peut lui arriver de rajouter des boutons pour en remplacer un autre. Il réalise également le même système avec la Xbox. Sur la photo ci-dessous, il a adapté la manette pour un droitier.

; Problèmes:
*Besoin de toute la motricité de la main, c’est-à-dire que si le patient à un doigt paralysé ou manquant, il ne pourra pas jouer avec cette ma
*Design obligatoirement droitier ou gaucher, une modification = une manette= une personne
*Besoin obligé du pouce et de l’index, même si avantage : 3 doigts nécessaire.

;Lien :: https://www.youtube.com/watch?v=LieHIscadjk

==Scénario d'usage du produit ou du concept envisagé==

La technologie est ,aujourd’hui, omniprésente dans notre vie. Les consoles de jeux ont envahies les maisons avec plus de 7 personnes sur 10 jouant aux jeux vidéos sur consoles en France (chiffre de l’Express). 0,18% des français sont handicapés cela représente 12 millions de français. Dans ce chiffre, 13,4% des personnes ont un handicap moteur. En 2017, les grands groupes comme Sony ou Microsoft avec respectivement PlayStation et Xbox ne permettent pas à tout le monde de jouer avec une manette. Les manettes sont prévues pour des personnes ayant leurs membres valides, plus précisément les mains et les bras.

Après un accident de voiture, un jeune garçon a perdu la motricité d’un côté du corps. Passionné de jeux vidéo, il se retrouve avec des difficultés à jouer sur sa console PS4. Ingénieux, il utilise la manette en la coinçant entre son épaule et le creux du cou. Usant de la mâchoire et de sa main valide pour contrôler les joysticks et les boutons. L'exercice étant inconfortable et fatiguant il eu l’idée de proposer à des futurs ingénieurs de lui proposer une manette adaptée à son handicap.

Les deux pré-ingénieurs ,avec leur tuteur, ont une idée révolutionnaire : La manette modulable ! Elle permettrait au jeune garçon, ainsi que d’autres joueurs, de pouvoir continuer de s’amuser ou même de commencer à jouer au jeux sur console.
Cette manette aidera fortement dans les centre de rééducation pour faire passer le temps et donner du plaisir à des personnes qui ne peuvent plus s’amuser avec leur console traditionnelle. Elle pourra aussi ouvrir de nouvelles possibilités pour certaines personnes qui n’auraient jamais essayé jusqu'à présent.
Comme son nom l'indique, elle sera modulaire et s'adaptera à différents handicaps. Accompagnée de son application d’initialisation, elle sera accessible aussi bien aux enfants, patients, parents et aides soignantes.

Quelques mois plus tard...Le jeune patient fan de Need For Speed, peut maintenant piloter sa voiture comme un vrai professionnel grâce à l'un des joysticks qu'il utilisera avec sa main valide et il pourra accélérer à des vitesses folles à l'aide de boutons poussoirs au niveau de son pied valide et gagner la partie. Son ami venu lui rendre visite, pourra en lieu et place des aides soignantes configurer à l'aide de la tablette (portable) la manette du patient.
Si le patient change de jeu pour Tekken et que la configuration des modules ne lui convient plus, il peut interchanger les éléments de la manette selon son envie et son confort. Ainsi il peut faire sauter son personnage, il utilisera un module bouton supplémentaire, qu'il actionnera avec le poing.

==Fonctionnement==

Suite à une analyse fonctionnelle et à la formulation de notre projet, nous avons pu définir le fonctionnement de notre système. Notre produit, la manette, doit être accessible d’après nos objectifs à différents types de handicaps moteurs. Ainsi, l’idéal serait de concevoir une manette modulable afin qu’elle puisse s’adapter à toutes les situations. Ce n’est plus au patient de s’adapter à la manette mais à la manette de s’adapter au patient.
Cela signifie que la manette sera, dans la limite du possible et de la sensibilité du corps du patient, composée de plusieurs parties dites « modules » comportant un ou plusieurs actionneurs (boutons, joysticks, gâchettes...). Ces modules seront déplaçables afin d’être utilisé avec différents membres du corps : un doigt, une main,
une jambe ou même un pied. Il suffira de les connectés entre eux suivant l’organisation souhaitée, le Gameplay du jeu ou en fonction du handicap. Le tout sera relié à une application.
L’application sera alors mise en place pour connecter les différentes parties du point de vue software pour prérégler la manette en fonction du patient. Il pourra alors choisir les boutons en fonction du jeu, de ses mouvements mais aussi choisir la sensibilité.

L’application et les modules devront être intuitifs et faciles d’utilisation. De cette manière des utilisateurs non avertis dans le domaine informatique ou jeunes pourront eux-mêmes gérer les connexions.

==Réponse à la question difficile==

'''Question : Comment interconnecter les différents modules de la manette ?'''

Il nous faut pour ce projet interconnecter les modules modélisant la manette qui seront connectés à la consoles PS4 via une Raspberry Pi 3.
Le choix de la Raspberry Pi 3 nous permet d'utiliser son module Bluetooth pour communiquer avec la PS4, ce choix est plus adaptée au projet que du filaire.
Concernant l'interconnexion des modules, nous travaillerons en deux étapes "preuves concept" : filaire et sans fils (Bluetooth).

'''Objectif 1 : Preuve concept filaire'''

Dans cette première partie de projet, nous souhaitons avoir une 1ère preuve de prototype rapidement. Nous nous concentrerons alors sur la communication entre la RPi3 et la PS4 ainsi que sur la conception des modules. Pour les modules, nous réaliserons des cartes électronique pour chaque module avec un micro-contrôleur. La communication filaire nous permettra d'interconnecter les modules à la RPi3 avec un bus SPI.

'''Objectif 2: preuve concept sans fils'''

Une deuxième étape du projet est la réalisation de la solution idéale sans fils. Celle-ci pourra commencer à être développée petit à petit en parallèle avec l'objectif 1. Le but ici, est d'interconnecter les modules en Bluetooth. Nous avons choisi le Bluetooth pour garder une connexion commune sur toute la chaîne.
Nous rajouterons alors un module bluetooth à chaque module de la manette.

'''Objectif 3: possibilité d'adapter les boutons (capuchon en 3D)'''

=Préparation du projet=

==Cahier des charges==

''Chef de projet:'' Alexandre Boé 
''Responsables:'' Xavier Redon, Thomas Vantroys 
''Partenariat:'' Marc Sautelet (non etablie) 
''Elèves-ingénieurs:'' Camille Saâd, Transley Gracias 

'''Sujet :''' Manette modulable pour personne à déficience moteur compatible PlayStation 4 

===Objectifs principal (1er POC) : ===
Faire transmettre des informations issus des actionneurs (ex:boutons poussoires) via des arduinos jusqu’à la Raspberry Pi 3 en SPI. 
Envoyer les données reçues vers la PS4 en USB 

===Objectifs secondaire (2e POC):===
Créer des modules avec un microcontrôleur et une puce bluetooth pour permettre une meilleurs flexibilité (c-àd pouvoirs avoir une meilleure ergonomie et une connexion sans fil) 
Connecter la Raspberry Pi 3 en Bluetooth à la PS4 

[[Fichier: beteacorne.jpg||middle|600px|Bete a corne manette]]

==Choix techniques : matériel et logiciel==

===Liste de matériel :===

'''Modules boutons/joysticks/gachettes'''

3 Push buttons : 
- O X Y Carré R3 L3 
- Guide PS 
- start/back 
--> 0,45€/unité TTC [https://www.gotronic.fr/art-bp-miniature-krs1273-16976.htm] 

1 Thumbstick original: 
Joystick analogique 4 directions --> 4,25€/unité TTC [https://www.gotronic.fr/art-joystick-analogique-4-directions-19063.htm] 

1 buttons trigger L1 L2 => 1x Thumbstick original''' 

'''Cartes Atmega328p /connexion spi/'''

3 Arduino UNO 
1 Arduino UNO atmega328p retirable 
4 capacite 22pF traversantes 
2 resistances 10 kOhm traversantes (à récupérer) 
2 oscillateurs quartz 16MHz traversante 
2 atmega328p-pu et support 

'''Cartes module bluetooth nrf52810 '''

6 capacités 100nF 0603 
6 capacités 12pF 0603 
2 capacités 4,7pF 0603 
2 capacités 1µF 0603 
2 capacités 100pF=0,1nF 0603 (à récupérer) 
2 capacités 0,8pF 0603 (a acheter, commande en cours) 
2 inductance 3,9nH 0603 (a acheter, commande en cours) 
2 oscillateur quartz 32 MHz 

''' Connexions et autres '''

1 Led RGB neopixel [https://www.adafruit.com/product/1734] 
1 Raspberry Pi 3 
--> ~36,23€/unité TTC [https://fr.rs-online.com/web/p/processor-microcontroller-development-kits/8968660/?src=raspberrypi] 
1 Raspberry Pi Zero W (commandée) [https://www.raspberrypi.org/products/raspberry-pi-zero-w/] 
6 Alimentations 5V ou 3,3V 
par exemple, 12 piles de type CR2016 3V rechargeables ou 24 piles AAA 1,5 V rechargeables
5 modules Bluetooth nrf de Nordic : nRF52810-QFAA-R 
--> 3,17€/unité + frais expédition [https://www.mouser.fr/productdetail/nordic-semiconductor/nrf52810-qfaa-r?qs=sGAEpiMZZMve4%2FbfQkoj%252bG%2FosjLoe2oghFQwQllMrQ4%3D]
5 Lignes broches mâles 

===Logiciels:===

- IDE arduino
- Altium
- FreeCAD ou Inkscape

==Liste des tâches à effectuer==

'''Etape 1 : Gestion du projet'''

* Définition des cahiers des charges fonctionnel et technique, choix d'orientation...
* Recherche techniques sur les différentes connexions possibles entre les modules, la RPi 3 et la console PS4
#Recherche connexion SPI entre les modules et la RPi3
# Recherche connexion bluetooth entre la RPi3 et la PS4
# Recherche connexion bluetooth pour les modules
# Recherche carte avec montage Atmega328P-PU et anticipation module bluetooth
* Détermination du matériel nécessaire
* Réflexion sur l'application

'''Etape 2: Réalisation du projet'''

'''Partie 1: Preuve concept manette en filaire'''

* Conception de cartes électroniques pour 2 modules (/!\ prévoir modules bluetooth)
* Réalisation connexion SPI avec 2 modules : programmation des Atmega328p en liaison série.
* Si tests concluant, ajouter des modules jusqu'à en avoir 5 (1 pour chaque type de boutons)
* Connexion bluetooth entre la PS4 et la RPi3
* Réalisation du support des modules avec fixations possibles (imprimante 3D)

'''Partie 2: Preuve concept manette en bluetooth'''

* Ajout des modules bluetooth aux cartes électroniques
* Connexion bluetooth entre les modules

'''Partie 3: Application Android : paramétrage de la manette'''

* Créer une application sur tablette ou smartphone (Android) afin de configurer la manette aux besoins (inter-connexion des modules et console)

==Calendrier prévisionnel==

{| class="wikitable centre" width="80%"
|+
|-
| width="23%" |
'''Date'''
| width="34%" |
'''Tache à réaliser''' 
|-
| width="23%" |
17/01/18-24/01/18
| width="34%" |
Faire des recherches sur les différentes interconnexions du système : Bluetooth, RPi-Atmega328 (SPI), RPi-PS4
Continuer liste des taches, matériel, Début recherches + réflexion fixation support des modules
|-
|width="23%" |
31/01/18
| width="34%" |
Recherche technique connexion PS4-RPi3 et connexion SPI RPi3-Module + code
|-
|width="23%" |
31/01/18-07/03/18
| width="34%" |
Réalisation 1er prototype (+ début prototype 2)
|-
|width="23%" |
07/03/18
| width="34%" |
Seance 7 : Test prototype filaire
|-
|width="23%" |
07/03/18-09/05/18
| width="34%" |
Réalisation 2eme prototype + application Android
|-
|width="23%" |
09/05/18
| width="34%" |
Seance 14 : Test prototype Bluetooth
|-
|width="23%" |
14/05/18
| width="34%" |
Video projet
|-
|width="23%" |
15/05/18
| width="34%" |
Finalisation projet et Rapport
|-
|width="23%" |
16/05/18-17/05/18
| width="34%" |
Soutenances Projet
|}

=Réalisation du Projet=

==Feuille d'heures ==

Voici le tableau d'heures du binôme:

{| 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 S11 !! Heures S12 !! Heures S13et+ !! Total
|-
| Analyse du projet
| 10
| 2
| 1
| 1
| 1
|
|
|
|
|
|
|
| 20min
|
| 15h20
|-
| Cherches techniques
|
| 3
| 4
| 4
| 2
| 2
| 1
|
|
|
| 1
| 1
|
|
| 18
|-
| Rédaction du wiki et rapport de projet
|
| 1
| 1
| 1
| 1
| 30min
| 1
|
| 2
| 30min
| 30min
|
| 2
|
| 10h30
|-
| Programmation
|
|
|
|
| 3
| 2
| 3
| 5
| 4
| 7
| 8
| 6
| 5
|
| 43
|-
| Cartes électroniques
|
|
|
|
|
| 6
| 8
| 4
| 6
| 2
| 1
| 2
| 2
|
| 31
|-
| Application
|
|
|
|
|
|
|
|
|
|
|
|
|-
|-
| Total Semaine
| 10
| 6
| 6
| 6
| 7
| 10h30
| 13
| 9
| 12
| 9h30
| 10h30
| 9
| 9h20
|
| '''117h50'''
|}

==Prologue==

Avant la réalisation et conception d'un projet, il est important d'analyser celui-ci. Nous avons allons consacré le prologue à l'analyse fonctionnelle de la manette. Nous avons également eu une réflexion sur l'analyse technique, cela nous a permis de réaliser une liste de matériel. Il est important de définir les objectifs ainsi que les besoins afin de ne rien oublier. (Voir ci-dessus Analyse projet)
Nous avons également organisé notre travail, pour le partage de documents de recherches et la rédaction de compte-rendu final nous avons réalisé un google drive. Par la suite, nous créerons un projet Git.

Durant ce temps, nous avons décidé de réaliser 5 modules. Les modules sont les différents boutons de la manettes qui nous pourrons placer selon nos choix (boutons modulaires) pour notre prototype projet pour chaque type des boutons d'une manette PS4. Ces modules devrons être connectés à la console et interconnectés. Le tout sera lié à une application Android. Suite à quelques recherches et nos analyses, nous avons décidé les points suivants :

- On commencera avec 2 modules et on les multipliera par la suite.
- Les premiers tests sont réalisés avec des boutons petits pour assurer leur caractéristique "modulaires", par la suite nous pourrons ajouter des capuchons de taille plus importante (imprimante 3D ou achat)
- Conception modules : réalisation de carte avec un microcontrôleur atmega328 programmable pour chaque module (anticiper le module Bluetooth)
- Projet en 2 parties : prototype filaire et prototype Bluetooth
# Prototype filaire : connexions entre les modules et la RPi3 en SPI, connexion Rpi3-PS4 en Bluetooth, avec l'application en filaire à la RPi3
# Prototype Bluetooth: connexion Bluetooth entre modules-RPi3-PS4-apllication

[[Fichier: structuremanette.png||center|400px|Concept manette modulable]]

==Semaine 1==

Durant la séance, nous nous sommes concentrés les recherches afin de définir clairement le cahier des charges technique. Il s'agit des réalisations à mettre en œuvre pour les inter-connexions des éléments de la manette.
Ainsi, nous avons fait des recherches sur :

===Connexion SPI entre les modules (Atmega328p) et la RPi3===

SPI: Serial périphérique interface BUS

[[Fichier: yWGmW.png||right|200px|Concept manette modulable]]
Comme indiqué sur l'image ci-dessus, la Raspberry pi 3 peut communiquer en SPI avec ses broches CS0 (24), CS1 (26), SCLK (23), MISO (21), MOSI (19). Celles-ci permettent de communiquer avec un ou plusieurs esclaves (dans notre cas, des Atmega328p) en reliant directement les broches concernées de la RPi3 à celles des composants esclaves.
Chaque broche CS0 (24) ou CS1 (26) ne peut être connectée qu'à l'entrée SS (aussi appelé CS) d'un seul esclave.
C'est a dire que chaque CS est lié à un esclave afin de choisir avec lequel la communication est établie à un moment donné, et les MISO sont reliées entre elles en cascade, de même pour les SCLK et les MOSI. On peut noter que le maître impose la fréquence d’horloge et sélectionne l’esclave auquel les données sont envoyées. 8 MHz est le plus rapide supportable a 3,3V

[[Fichier: fonctionnementSPI.png||right|200px|Connexion SPI multi-esclaves]]

Voici un schéma du fonctionnement souhaité :

Comme nous souhaitons avoir 5 modules environ il nous faudra rajouter un composant en plus afin d'augmenter les possibilités de sélection, par exemple des démultiplexeurs.
Dans un premier temps nous essaierons avec 2 esclaves, puis on augmentera le nombre.

===Connexion Bluetooth PS4-RPi3===

Les recherches portent également sur la connexion entre la manette PS4 et la console. Elles concernent le protocole de communication via Bluetooth

Caracteristique pour la PS4: Bluetooth®v4.0, Qualcomm Atheros AR3002 Buetooth LE: 2,4-2,5 GHz 

Caracteristique de la connexion : 

*Vitesse de transmission >> 3 Mbit/s 8N1
*Relevé tous les 1.3 millisecond (peut-être)
*Chaque manette à une adresse unique BD_ADDR qui correspond à l’adresse MAC de la carte Réseau
*Protocole de détection est le SDP basé sur une emission reception PDU
*L’Attribut ID est representer en TLV Type Length Value
*Communication HCI ACL Data Packet

===Rélisation des cartes électroniques===

matériel nécessaire pour un PCB : 

*breadboard
*câbles
*1 x 10k Ohm résistance
*Quartz 16Mhz clock crystal
*2 x 22 pF capaciteurs
*Atmega328P-PU

Ressources:
[[https://www.arduino.cc/en/Main/Standalone]]
[[http://www.eprojectszone.com/atmega-328-pu-standalone/]]
[[https://www.arduino.cc/en/Tutorial/ArduinoToBreadboard]]

==Semaine 2==

Durant la semaine deux et durant la séance, nous avons continué et approfondie nos recherches sur le projet. Nous avons pu ainsi affiner nos taches de réalisation et donc notre cahier des charges.

===Connexion aux modules: SPI et Bluetooth ===

 CORRIGER

voir https://peip-ima.plil.fr/mediawiki/index.php/BE_2017-2018#Configuration_du_syst.C3.A8me_embarqu.C3.A9

(sudo apt-get install pi-bluetooth)

''connexion sur la raspberry par ssh:''
su
update-rc.d ssh enable
invoke-rc.d ssh start
ssh pi@172.26.79.1XX

''bluetooth''
bluetoothctl
agent on
default-agent
scan on
pair [device Bluetooth address] (exemple: pair XX:XX:XX:XX:XX:XX )

''NOUVELLE REFLEXION : Connexion SPI entre les modules (Atmega328p) et la RPi3 --> MODULES BLUETOOTH''

Si multi-esclaves= plusieurs modules :
Il faut ajouter des sélections pour les SPI → démultiplexeurs OU ne pas utiliser les CS0 et CS1, et plutôt des pins entrée/sortie de la RPi3 lié au SS comme ça on choisit direct le module esclave voulu.

'''IMPORTANT:''' Nous avons étudié à nouveau la datasheet de notre module bluetooth nrf de Nordik. Le module bluetooth comporte déjà un microprocesseur !
Un module plutôt peut donc jouer le rôle de notre atmega328p. Il n'y a alors pas besoin de réaliser des cartes électroniques de type arduino standalone. Nos PCB regrouperont alors uniquement l'alimentation, un actionneur (bouton, joystick), le module bluetooth et les broches de connexion si besoin...

Cette séance nous a alors permise de revoir entièrement le matériel nécessaire. Notre liste de matériel nous semble alors plus réfléchie et limitée au nécessaire.

===Connexion Bluetooth PS4-RPi3===

Suite à nos recherches de la semaine précédente, nous avons sélectionné deux sites bien renseignés :

SITES

Ils nous ont permis de comprendre la communication entre la manette et la console. En effet, ils nous expliquent les échanges de trames Bluetooth.
EXPLICATIONS 1 exemple 

==Semaine 3 : Début premier prototype==

===Connexion SPI RPi3-Arduino===

Comme vu durant les semaines précédentes, nous souhaitons réaliser une connexion Multi-esclaves en SPI entre la Raspberry pi et plusieurs modules.
Cette semaine nous avons vu que la réalisation de notre premier prototype doit aller vite. Il ne nous est pas nécessaire d’attendre les modules bluetooth si il nous faut dans cette partie uniquement utiliser son microprocesseur. Ainsi pour chaque module nous utilisons une arduino UNO. Nous réaliserons les programmes en C afin de pouvoir les réutiliser avec les modules bluetooth par la suite.
Une fois la connexion réalisable nous adapterons les programmes aux modules bluetooth Nordik. En effet, ceux-ci comporte déjà un microprocesseur, le module peut jouer le rôle de notre atmega328p. Il n'y a aurait alors pas besoin de réaliser des cartes électroniques arduino standalone sur PCB, mais directement des cartes électronique avec le module et le module voulu (bouton, joystick...) et l'alimentation.
Durant la séance nous avons alors revu la liste de matériel nécessaire.

[[Fichier: prototype1.jpeg||center|600px|connexion filaire prototype 1 filaire arduino]]

Durant la séance, nous avons recherches des exemples de codes et de librairies pour Arduino SPI et RaspberryPI SPI.

Nous avons également commencé le programme de la connexion SPI pour l'arduino et récupéré les bibliothéques SPI.h avec SPI.c. Nous nous sommes alors concentrer à les comprendre, pour pouvoir l'utiliser.

===Réalisation du projet Git===

Création du projet IMA4_Projet35_ManetteModulable sur Git et partage de celui-ci.
Les premiers dossier crées cette la séance :
-Arduino (connexion SPI arduino) : ProtoSpi.c + dossier librairie SPI + Makefile
-RPI (dossier codes pour Rpi)
-Readme.md
Ces dossiers seront amenés à être modifiés au cours des séances.

===Protocole Bluetooth PS4===

Suite à l'étude des trames Bluetooth, on a pu voir que ces dernières étaient incomplètes. Le modèle de communication étant propriétaire, on n'y a pas accès directement. Cela nous empêche donc de mettre en oeuvre cette communication.
 Déveloper

On a décidé de commencer par une connexion USB (pour laquelle on dispose de toutes les informations) celle-ci étant plus complète.

==Semaine 4==

Pour le prototype 1 FILAIRE nous réaliserons les étapes suivantes :

#Réalisation du programme SPI pour arduino
#Réalisation du programme SPI pour la RPi
#Connexion USB avec la PS4 ou ordinateur
#Réalisation de cartes électroniques atmega328p-pu standalone (remplacer les Arduinos)
#Remplacer les "PCB arduino" par le module bluetooth et adapter la connexion
#Conception 3D de la délimitation 1 axe pour le joystick "gâchette"
#Réalisation de l'application Androïde.

Une fois ces étapes réalisées nous auront alors une preuve de concept filaire et nous pourrons alors passer à une connexion bluetooth.
Le passage à la connexion bluetooth sera le deuxième prototype et le cas idéal de la réalisation de la manette modulable.

===Mise à jour Matériel===

- Modéliser les boutons gâchettes L1/2 R1/2 de la manette PS4 (boutons sensibles à la pression) --> un joystick dont nous bloquerons un axe (imprimante 3D)
- Remplacer la RPi 3 par une Rpi zero W qui nous permettrait de réaliser plus facilement une connexion USB tout en gardant l'avantage du bluetooth.
- Choix de l’alimentation pour les 5 modules Bluetooth: nécessitent 3V --> utiliser des piles rechargeables 1,2V AAA plutôt que piles rondes 3V.

Nous avons également besoin du matériel cité en semaine 1 pour réaliser des cartes électroniques atmega328p-pu standalone. ( nous revenons alors sur les décisions de la semaine 3)

===Connexion SPI RPi3-Arduino===

Montage Raspberrypi et 1 arduino en PSI + 1 bouton + 1 led.
Voici le choix des branchements :

MASTER = RPi
SLAVE= Arduino

'''SPI sur Arduino:'''
MOSI -> GPIO11 //PB3 //master OUT to the slave IN
MISO -> GPIO12 //PB4 //slave OUT to the master IN
SCLK -> GPIO13 //PB5 //serial clock
SS -> GPIO10 //PB2 //slave select
'''Led, bouton et autre...'''
LED --> GPIO6 //PD6
GND
+5V (if required)
'''SPI sur la Raspberry Pi'''
SPIO MOSI -> PIN19
SPIO MISO -> PIN21
SCLK -> PIN23
SPIO CS0 -> PIN24

Continuation du code pour faire clignoter Led branchée à une arduino depuis la Rpi, en connexion SPI.

===Connexion USB PS4-RPi3===
Durant cette, nous avons regardé comment faire cohabiter bluetooth, Application Androïd, USB, PS4, SPI et les module.

Il est alors important de savoir comment utiliser le port série sur la RPi3, soit utiliser les UART.

Nous avons réaliser qu'il n'était pas aussi simple d'utiliser le port serie USB de la Raspberry Pi 3, en effet le SoC est un BCM2837 .
De plus nous ne pouvons pas utiliser le même port pour l'alimentation et la connexion.

Il nous faut alors trouver une alternative ou une solution à ce problème.

==Semaine 5==

===Programmation: Réflexion définitives prototypes filaire ===

La semaine dernière, nous avons rencontré une difficulté liée aux ports séries UART.
Une des solutions à cette difficulté serait d'utiliser une RPi ZERO W à défaut d'une RPi 3. On pourrait alors avoir un port d'alimentation avec connexion USB mais également retrouver la connexion Bluetooth dont nous avons besoin.

Ensuite, nous avons continué la réalisation du prototype filaire par l'avancé du code SPI ainsi que les recherches concernant le protocole PS4.

La Raspberry Pi zero W peut également être utile pour la connexion entre la PS4 et les différents modules en jouant le rôle d'intermédiaire. Nous avons alors commandé une Rpi zero W pour notre projet.
En attendant la réception de la commande, nous nous sommes penché sur les recherches pour les programmes et la configuration nécessaire à l'utilisation de la RPi zero W.

===Electronique===

[[Fichier: bouton_c1.jpg|100px|thumb|left|PCB bouton]]
[[Fichier: arduinobb.jpg|200px|thumb|right|atmega328p-pu branchement test]]

Du coté électronique, nous avons réalisé sur fritzing certaines cartes électroniques. Les Arduino Uno servant actuellement de test, seront remplacées par des PCB atmega328p-pu standalone avec des broches permettant les branchements nécessaires SPI ou encore aux modules "boutons/joystick". Pour les boutons, nous avons également réalisé un pcb afin de faciliter les branchements.

Il nous faut alors également une 3eme carte qui nous sera nécessaire pour la réalisation du prototype sans fil. Dans notre liste de matériel, nous avons des composants nrf52810 bluetooth, ceci doivent être soudé avec les capacités de protection mais également des broches de communication. Nous avons alors commencé cette carte électronique sur Altium avec le fichier projet PCB du distributeur à modifier.

[[Fichier: Arduino_c1.jpg|100px|thumb|center|PCB atmega328p-pu]]

=== Construction 3D ===

Enfin, nous avons commencé à réaliser des boîtiers 3D pour certains modules. Par exemple, comme nous l'avions vu précédemment, un des joysticks servira de bouton-gâchette en utilisant un seul de ses axes. Il nous faut alors réaliser un boitier qui bloque l'un des axes, mais également une tige qui nous permettra de pousser le joystick de manière simplifiée.

==Semaine 6==

===Programmation: configuration RPi Zero W ===

Ayant reçu la Raspberry Pi zero W en début de semaine, nous nous sommes concentrés sur la programmation et la configuration de celle-ci.
Cette partie étant compliquée, elle nous a pris du temps. En effet, il était difficile de connecter la RPi en SSH car il n'est pas possible d'y connecter un clavier directement et on avait besoin de la prise OTG pour "interfacer" la manette.

===Electronique: PCB nrf52810===

Les cartes réalisées en semaine 5 sont validées et en attente de réalisation.

Cette semaine a permis la réalisation et la finalisation de la carte électronique nrf52810. Il nous a fallu recommencé cette carte deux fois. En effet, une fois finie sur Altium nous avons réalisé que les empreintes des CMS sur PCB fourni par le constructeur ne correspondent pas au matériel CMS de l'école. Face à cette inattention de notre part, nous avons décidé de refaire entièrement la carte électronique sur fritzing. Ayant la datasheet et des plans d'inspiration PCB, nous avons pu refaire la carte entièrement.
Sur celle-ci nous avons ajouté des broches de connexion au besoin, un branchement Jtag et ICSP pour la programmation et la connexion SPI.
La carte est en attente de validation, puis validation.

[[Fichier: nrf52810_circuit2.jpg||center|400px|PCB carte nrf52810]]

===Révision matériel ===

Pour la réalisation de nos composants électroniques, il nous a fallu faire une révision des composants disponibles à l'école:
(les quantités indiquées ci-dessous pourront être augmentée si nécessaire,pour avoir dans l'idéal un module de chaque type de la manette, ici on se concentre sur BOUTON et JOYSTICK)

'''Cartes Arduino:'''
* 4 capacite 22pF traversantes
* 2 resistances 10 kOhm traversantes (à récupérer)
* 2 oscillateurs quartz 16MHz traversante
* 2 atmega328p-pu et support

'''Cartes nrf52810'''
* 6 capacités 100nF 0603
* 6 capacités 12pF 0603
* 2 capacités 4,7pF 0603
* 2 capacités 1µF 0603
* 2 capacités 100pF=0,1nF 0603 (à récupérer)
* 2 capacités 0,8pF 0603 (commande en cours)
* 2 inductance 3,9nH 0603 (commande en cours)
* 2 oscillateur quartz 32 MHz

'''Cartes modules Boutons'''
* un sachet de broches mâles (qu'on utilisera également pour les autres cartes, à récupérer/acheté)

Nous avons alors mis-à-jour la liste de composant située plus haut, ainsi que celle de la page IMA4 2017/2018 [https://projets-ima.plil.fr/mediawiki/index.php/Projets_IMA4_SC_%26_SA_2017/2018]

==Semaine 7==

===Programmation: connexion wifi RPi Zero W et Bootloader sur Atmega328p-pu ===

Pendant cette semaine, nous avons continué la programmation et la configuration des Raspberry Pi 3 et Zero W. Concernant la configuration ssh, nous avons utilisé un téléphone en guise de point d’accès à la RPi Zero W en wifi.
Nous avons aussi directement configurer l'OS Jessie, utilisé pour la RPi Zero. On a modifié le fichier cmd.txt et ...pour pouvoir programmer un USB gadget sur le port OTG.
Ci-dessus expliquer fichiers

Nous avons également continuer les programmes de récupération de données : état des boutons et du joystick. Ces programmes sont appliqué sur l'atmega328p-pu standalone sur la plaque d'essai en attendant que le PCB soit opérationnel.
Pour pouvoir programmer l'atemega328p-pu comme une arduino UNO, il nous faut suivre plusieurs étapes :

'''1.Flasher le Bootloader'''
Nous avons 2 Atmega328p-pu neufs, ainsi il nous faut flasher le bootloader sur chacun d'eux afin de pouvoir les utiliser et les programmer sur une breadboard dans un montage minimaliste arduino-standalone.
Pour cela, on peut utiliser une carte arduino UNO. On vérifie le port et le type de carte sélectionnés dans le menu >Outils. Sur cette carte on téléverse le fichier arduinoISP.ino qui se trouve dans les exemples en étant en progrmamateur AVr ISP mkll (>outils>programmateur)
Puis on met l'atmega328p-pu qui nous intéresse sur le suppor socket de la carte. On change de nouveau le programmateur pour Arduino as ISP et on fait >tools>burn bootloader, soit >graver la sequence d'initialisation.
Ces étapes faites, on peut retirer notre microcontroleur et le replacer correctement dans le montage.

'''2.Programmation atmega328 sur breadboard'''
Une fois l'atmega328p-pu préparé, on peut le programmer. On peut le faire simplement à l'aide de la carte arduino UNO utilisée précédemment.On branche les Tx et Rx en commun ainsi que le reset, le GND et le VCC.

Nous avons réaliser des codes basiques tels que le clignotement d'une led rouge ou encore l'affichage de "hello world" sur le moniteur série pour vérifier la bonne fonctionnalité du montage. Cela fait nous avons pu écrire sous Arduino IDE le code de lecture des états.

[[Fichier: montage_BB_test.jpg||left|200px|programmation modules arduino sur breadboard]]

===Electronique : soudure carte de test modules ===

Comme nous l'avons déja vu lors de la réalisation des PCB, si l'on souhaite programmer un atmega328p-pu en bootloader, le montage est simple. Il peut être minimaliste en utilisant une arduino UNO, un atmega328, une breadboard et 3 composants: 1 quartz 16MHZ crystal, 1 résistance 10kOhm et 2 capacitors céramiques de 22pF.
Durant la semaine 7, nous avons soudé les composants traversants de la carte électronique correspondant à ce montage ainsi que le PCB du bouton.

==Semaine 8==

===Programmation ===
Après moult recherche sur les différents site web bien fournis pour le coups on as pu trouvé une amorce à la programmation de l'OTG via un script qui agit au niveau du kernel dans le sous dossier usg_gadget. Ce script donne les informations nécessaires pour pouvoirs échangé les données.
Avec le script trouvé et les informations des sites web décryptant les trames de la manette, on a toujours pas réussit à faire passer notre RPi Zero W pour une manette de PS4. Néanmoins il nous manque la trame HID complète de la manette pour avoir un test effectif.

===Electronique : Correction soudure et soudure CMS===

Durant cette semaine, nous avions souhaité programmer la carte électronique atmega328p-pu. Cependant, nous avons réaliser que nous avions fait une erreur lors de l'envoie du PCB à la production. En effet, celui-ci avait été fait en Top sur le logiciel Fritzing et non en Bottom. Hors nous avions soudé les composants (durant la semaine 7) comme pour un circuit imprimé en bottom, l'atmega328p-pu se retrouve alors inversé par rapport aux pistes.
Comme solution, nous avons choisi de souder un deuxième support pour l'atmega328 de l'autre coté de la carte avant de la refaire au propre. En effet, avant de la refaire il nous faut vérifier si la carte est bien programmable.
Une fois cela fait nous avions pu programmer la carte mais, nous avions également réalisé la pin 2 de l'atmega328 était prise par le bouton poussoir. Or, nous avons besoin des pin 2 et 3 pour le RX et TX permettant la programmation de l'atmega à partir d'une arduino, les pistes branchement RX-TX n'ont également pas été prévus pour le téléversement des programmes sur la carte. Il nous faut alors couper une piste et souder des câbles pour utiliser toutes les pistes souhaitées.

[[Fichier: correction_proto_PCB.jpg||right|300px|PCB arduino correction]]

Durant cette semaine, nous avons également souhaité souder les CMS et le composant bluetooth nrf52810 sur la carte imprimé et reçu lors de la semaine 7. Pour cela, nous avons convenu de travailler dans la C202 durant la séance du mercredi.

[[Fichier: PCB_nrf52810.jpg||left|400px|carte electroniques imprimées]]

====Comment souder des CMS ?====

les CMS sont des composants montés en surface c'est à dire qu'ils sont montés du même côté que les pistes cuivrées (à l'opposé des composants traversants) et sont de petite tailles souvent de l'ordre du millimètre. La taille est déterminée par 4 chiffres : les 2 premiers pour la longueur et les 2 derniers pour la largeur. On a du 1206,0805,0603 ou encore 0402. Il est même possible de trouver plus petit. A l'école nous utilisons souvent du 0603, c'est le cas de nos composants.
Pour souder des CMS 0603, il nous faut utiliser une autre méthode qui n'est pas le fer à souder :
# Préparer la veille la pâte à braser la veille (dans une seringue)
# Gommer la carte pour éviter l'oxydation (attention à ne pas retirer les miettes de gomme en soufflant dessus)
# Appliquer avec la seringue la pâte sur les empreintes et piste souhaitées. Pour les endroits difficile à atteindre ou avec 2 pistes proches les unes des autres, il est possible de mettre la même goutte de pâte sur les 2 pistes. Cela de causera pas de court-circuit par la suite. En effet, la pâte est composée d’alliage qui sous la chaleur va se fluidifier et se coller uniquement aux pistes métallique. Le reste fondera sous la chaleur du four.
# Appliquer les CMS sur la pâte au fur et à mesure (attention ! ne jamais toucher les CMS avec les doigts, tjrs utiliser une pince)
# Mettre au four

====Bilan soudure nrf52810====

Cependant, une fois le matériel nécessaire préparé, et la pâte mise sur les pistes souhaitées, au moment de déposer le composant, nous avons réalisé que celui-ci était beaucoup plus petit que l'empreinte sur le PCB. Il s'agit d'un composant boitier QFN48. Fritzing ne proposant au plus proche des boitiers QFN24 ou LQFP48, celui-ci a basculé automatiquement pour un boitier LQFN48, de dimension plus grande. Face à ce manque de vigilance, nous avions cependant commencer par le nrf52810 (composant concerné) évitant ainsi de gaspiller d'autres CMS.
Nous avons souhaité refaire la carte sous Altium à partir des fichiers fournis par le concepteur (chose que nous avons commencé à faire aux alentours de la semaine 5)
Après la réalisation du schématic, et de la modification des empreintes de capacités, inductances et autres composants de 0402 à 0603. Notre matériel ne permettant que des empreintes 0603.

Lors du routage, une erreur de chevauchement des pistes est notifiée par Altium au niveau du nrf52810. Celles-ci ne présentent pas d'angles et sont déjà de taille 8mil, il nous faut alors passer les pistes en 6mil. Mais 8mil est la taille minimale pour la production à Polytech, nous avons regardé pour envoyer les cartes à faire ailleurs mais le 6mil n'est pas beaucoup conseillé. De plus, il n'est peut-être pas judicieux de continuer avec le composant microcontrôleur-bluetooth Nrf52810 qui prend du temps, donc la carte est difficilement réalisable et peut-être très long à programmer.

Ainsi en cette fin de semaine, nous avons décider face à l'avancer du projet de laisser les nrf52810 de coté et de les remplacer par des modules sans fils plus simples d'utilisation et complets. Ainsi nous aurions plus de chance d'avoir une connexion sans fils entre les modules. Nous pourrions par exemples utiliser des Xbee, des modules Rf...

==Semaine 9==

====Programmation: PS4 et 1er Test SPI sur atmega328p====

'''Raspberry Pi Zero W et PS4'''

Les premiers tests sur Windows ne nous donner pas satisfaction. En effet, l'ordinateur détectait bien le nouvel appareil avec son nom mais l'origine rester inconnue.

Lors des tests sur Linux on a pu voir des erreurs via la commande 'dmesg' :

[193229.758782] usb 4-1.2: new high-speed USB device number 6 using ehci-pci
[193230.270780] usb 4-1.2: new high-speed USB device number 7 using ehci-pci
[193235.510842] usb 4-1.2: device descriptor read/64, error -110
[193251.127043] usb 4-1.2: device descriptor read/64, error -110
[193251.315043] usb 4-1.2: new high-speed USB device number 8 using ehci-pci
[193256.503135] usb 4-1.2: device descriptor read/64, error -110
[193272.119331] usb 4-1.2: device descriptor read/64, error -110
[193272.307331] usb 4-1.2: new high-speed USB device number 9 using ehci-pci
[193282.999473] usb 4-1.2: device not accepting address 9, error -110
[193283.079485] usb 4-1.2: new high-speed USB device number 10 using ehci-pci
[193293.751588] usb 4-1.2: device not accepting address 10, error -110
[193293.751771] usb 4-1-port2: unable to enumerate USB device
[193387.196861] usb 4-1.2: new high-speed USB device number 11 using ehci-pci
[193392.440941] usb 4-1.2: device descriptor read/64, error -110
[193407.933152] usb 4-1.1: new high-speed USB device number 12 using ehci-pci
[193413.177227] usb 4-1.1: device descriptor read/64, error -110

'''Modules Atmega328p et SPI'''

Une carte PCB arduino fonctionnant, nous pouvons la programme pour simuler un module. Celle-ci a été designée afin de s'adapter au module que l'on souhaite. Il suffit de brancher le bouton, le joystick ou autre élèment de manette souhaité.
Cette semaine ci, nous avons alors configurer la partie communication SPI pour l'arduino.

'''Que voulons-nous faire avec les atmegas ?'''
Les cartes électroniques atmega328p vont nous permettre de recevoir les requêtes SPI envoyées par la raspberry pi et d'y répondre. La Raspberry enverra un message, par exemple "1", et l'Arduino lira alors l'état du module qui lui est connecté. Une fois l'état récupéré elle le renvoie à la raspberry pi.

Durant cette semaine, nous avons programmé l'atmega afin qu'il soit en esclave, qu'il reçoive un de la RPi "1" et retourne une valeur sauvegardé "int envoi". Nous avons également commencé les tests pour la lecture de l'état d'un bouton (d'après les tests réalisés les semaines précédentes).

'''Code'''
Comme nous l'avons vu précedement lors de nos recherches (semaines 1 à 4) :
La communication SPI nécessite l'utilisation des pins:

MOSI -> GPIO11 //PB3 //master OUT to the slave IN
MISO -> GPIO12 //PB4 //slave OUT to the master IN
SCLK -> GPIO13 //PB5 //serial clock
SS -> GPIO10 //PB2 //slave select

Il faut également paramétrer l'atmega328p en Slave. On note que dans un premier temps, le programme sera codé avec l'arduino IDE (fichiers .ino). Une fois l'ensemble SPI RaspberryPi-Arduino fonctionnant, on remplacera ces codes par du langage C ou C++.

Pour faire la connexion SPI sur l'atmega328p, on utilise la librairie arduino SPI.h, on a alors directement les fonctions nécessaires intervenant sur les registres souhaités : SPCR (spi control register), SPSR (spi status register) et SPDR (spi data register).

#include <SPI.h>

Il est important d'initialise d'abord le setup et on active le port série pour pourvoir utiliser le moniteur série. (Cela servira à verifier la valeur envoyée par la RPi)

void setup (void)
{
Serial.begin (9600);
pinMode(MISO, OUTPUT); //configuration en esclave *master in slave out*
pinMode(buttonPin,INPUT); //config pin bouton
// turn on SPI in slave mode
SPCR |= _BV(SPE);
// preparation interruptions
pos = 0; // buffer empty
process_it = false;
// activation interruptions
SPI.attachInterrupt();
}

On oublie pas de déclarer les interruptions afin de bien lire la requête reçue.

// SPI interrupt routine
ISR (SPI_STC_vect)
{
byte c = SPDR; // grab byte from SPI Data Register
// add to buffer if room
if (pos < sizeof buf)
{
buf [pos++] = c;
// example: newline means time to process buffer
if (c == '\n')
process_it = true;
} // end of room available
} // end of interrupt routine SPI_STC_vect

Dans la loop main, on traite la requête et on utilise '''SPI.transfer(envoi);''' pour transferer à la RPi les données souhaitées.

Durant cette semaine, nous avons également commencé des programmes de test SPI pour la RPi. Il s'agit principalement de programmes de tests tout faits permettant de vérifier la connexion entre cette dernière et l'arduino. Par exemple, la RPI envoie "bonjour" et l'arduino lui retourne ce qu'elle reçoit, soit "bonjour". Sans succés alors.

====Electronique : Fritzing révision====

Lors de la semaine, le modèle PCB de la carte arduino a été réalisé de nouveau sous fritzing avec les broches et connections manquantes. Nous avons également revu la configuration du bouton reset et ajouté une led d'état de l'alimentation. Nous avons ainsi envoyé deux cartes identiques à la réalisation.
La carte déjà soudée lors des derniers jours fonctionnant, elle nous sert de prototype de programmation. Nous pouvons ainsi avancer à la fois sur la programmation des modules mais aussi sur leur réalisation.

==Semaine 10==

====Programmation : PS4 et SPI sur RPi====

'''Raspberry Pi Zero W et PS4'''

Cette semaine, pour tester la prise OTG nous avons décider de lancer un script qui est habituellement utilisé. Nous avons choisi le script Serial Adapter qui est censé permettre de se connecter à la RPi Zero W en SSH via ce port.
Après quelque modifications et plusieurs petits bugs, nous avons réussir à faire fonctionner le ssh via le port OTG. Donc le problème était le même, notre script mélangé avec les informations sur la PS4 n'était toujours pas fonctionnel.

Pour faire la liaison entre les deux parties nous avons aussi commencé à programmer une application qui permet de configurer les modules au niveau de la RPi Zero W.

'''Modules Raspberry PI et SPI'''

Durant cette semaine, pour la partie Atmega328p-Modules, nous nous sommes concentrés sur la programmation de la communication SPI avec la raspberry pi. Cette semaine a permis une étude plus approfondit sur le fonctionnement pour la RPi.

On rappelle, comme vu des semaines 1 à 4, pour la RPI3 (tout comme la RPi Zero W) utilise les broches : SCLK (23), MISO(21), MOSI (19) et SPI CS0 (24), SPI CS1 (26).
On la programme en Master. A l'aide des fichiers tests d'inspiration, on pourra directement programmer la RPi en C. Lors de la réalisation du code, il y a 3 étapes : l'initialisation/parametrage en SPI pour être maître, l'envoie de la requête puis la réception de données en retour.

Programmant en C, il ne faut pas oublier les librairies suivantes :

#include <stdint.h>
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
#include <getopt.h>
#include <fcntl.h>
#include <sys/ioctl.h>
#include <linux/types.h>
#include <linux/spi/spidev.h> //pour SPI

On va déclarer des variables globales permettant le paramétrage :

static const char *device = "/dev/spidev0.0"; //si on veut CS0 pour atteindre notre SS
static uint8_t mode; //mode est par défaut à 0
static uint8_t bits = 8; //bits par mot échangé
static uint32_t speed = 500000;
static uint16_t delay;

Dans notre main, on ouvre le port (la connexion) au device souhaité, on vérifie les paramètres (registres, connexions...) puis exécute la fonction transfer(fd). transfer(fd) transmet la requête et s'occupe de la réception.

fd = open(device, O_RDWR);
transfer(fd);
close(fd);

==Semaine 11==

====Programmation: PS4, SSH et tests SPI (RPi3&Atemga328p)====

'''Raspberry Pi Zero W et PS4'''
Lors de recherche supplémentaire, nous avons essayer de voir s'il un pilote de gestion du périphérique serait nécessaire à la connexion de notre pseudo manette.

'''Raspberry PI, Atmega328p et SPI'''

Afin de facilité la programmation en utilisant Ethernet, nous avons installer et configuré la RPi pour l'utiliser en SSH depuis les ordinateurs de la E306. En effet, SSH permet de se connecter à distance sur une machine en utilisant un compte utilisateur de la dite machine. En mettant ssh, on pourra directement agir sur les fichiers de la raspberry depuis un terminal de notre PC. Pour cela, on a d'abord vérifier l'adresse IP de notre raspberry pi : 172.26.145.106 avec un écran mais on peut aussi utiliser les commandes ip a et ifconfig. Puis activer le ssh sur la raspberry pi.
On modifie alors le fichier config.txt mais également etc/network/interfaces pour configurer la bonne interface Ethernet sur la raspberry pi.

[[Fichier: configSSH_raspi.png||left|300px|config ssh ethernet]]

Il nous suffit alors de taper la commande : ssh pi@172.26.145.106 pour accéder à notre RPi.

Nous avons continué à réaliser la communication SPI avec des tests entre une arduino UNO et la RPI3. Nous avons commencé par des tests simples inspirés des études de deux semaines précédentes et modulés selon notre utilité.
Nous arrivons alors à lire l'état envoyer "bonjour" et recevoir "ça va" ou encore "1" et recevoir "3". Il faut noter que le SPI échange des trames, la RPI reçoit alors des hexadécimaux.
Nous avons alors continué pour recevoir l'état du bouton ou du joystick lors de l'envoie de "1" sur l'Arduino328p. La semaine prochaine nous testerons ces même codes fonctionnels sur les cartes atmeg327p.

A la fin de cette semaine, nous avons alors des codes Arduino-SPI (.ino) et des codes Raspberry-SPI (.c) permettant l'échange de données. Le but est maintenant de l'adapter aux cartes imprimées et de le rendre pleinement fonctionnel pour plusieurs cartes à la fois, puis ajouter une boucle de vérification en continue jusqu'à une deuxième requête de la RPi.

====Electronique: réalisation au propres des PCB modules====

Suite à une nouvelle erreur de réalisation cartes électronique, nous avons refait et renvoyé à nouveau les cartes imprimées atmega328p.
Nous les souhaitons au propre pour une version finale. Une fois celle-ci imprimées nous pourrons en avoir 3 , un pour chaque module. Les cartes étaient bien imprimées en bottom mais lors du passage des traversants de bottom à top, le logiciel ne les a pas fait miroiter. Par manque d'attention nous avons alors envoyé les fichiers gerber pour des cartes ayant les composants du même coté que la couche de cuivre.
Les cartes électroniques actuelles sont alors correctes et fonctionnelles mais difficile à souder. Pour eviter les erreurs et continuer sur des prototypes de carte nous préférons attendre en nous concentrant sur la programmation PSI de la Raspberry Pi.

==Semaine 12==

====Programmation====

'''Raspberry Pi Zero W et PS4'''

Cette semaine nous avons décidé de prendre un cap temporaire. On a utiliser un script pour faire un pseudo clavier/souris pour essayer d'envoyer nos données puis modifier petit à petit jusqu'a avoir un script/programme compatible PC. Il devra ce faire passer pour un Joystick donc une manette classique.

'''Raspberry PI, Atmega328p et SPI'''

- réflexion: penser à faire boucler sur l'arduino une fois la requête reçu, ça veut dire que la manette est ON et donc vérifier continuellement les modules sur chaque atmega.
- SPI raspberry pi - arduino recuperation état du bouton avec les cartes modules (/!\ récuperation à faire dans une variable)

-SSH perso
adresse Rasppi: 192.168.137.10

====Electronique: Finalisation soudure Modules====

Soudure au propre et finale d'une carte atmega328p et donc envoie pour la réalisation de 2 autres cartes similaires et récupération de matériel
Soudure des 2 autres cartes, + tests sur les états = fonctionnelles.
On a donc bien 3 cartes pour les 3 modules de types différents (1 bouton, 1 joystick, 1 gachette)
PCB pour les 2 joysticks (qui serviront de thumbstick et gachette)

==Semaine 13 et plus==

====Programmation====

'''Raspberry Pi Zero W et PS4'''

'''Modules Atmega328p et SPI'''

====Electronique====

=Documents Rendus=

(à mettre rapport + git + drive)

=Datasheets=

IMA4 2017/2018 P35

2018-05-05T20:21:12Z

Tgracias : /* Programmation: PS4, SSH et tests SPI (RPi3&Atemga328p) */

__TOC__
 

=Présentation générale: Manette modulable=

==Description==

Tout le monde joue aux jeux vidéo cependant, les manettes ne sont pas adaptées aux personnes ayant un handicap pouvant toucher les bras ou les mains.
C’est le cas, de plusieurs patients dans les centres de soins et de rééducation.

Pour ce projet IMA4, nous travaillerons avec le centre SSR (soin de suite et de réadaptation) Marc Sautelet de Villeneuve d’Ascq.
Un adolescent, patient de Marc Sautelet, est passionné par les jeux vidéo. En effet, ayant perdu la motricité d’une partie de son corps, il ne peut pas jouer à deux mains. Pour cela, il bloque la manette entre son épaule et son coude, usant de la mâchoire et des doigts pour contrôler les
joysticks et les boutons. Cet exercice peut s’avérer fatiguant et pénible.

Ainsi, nous chercherons à concevoir une manette PS4 adaptée au handicap de l’adolescent.
Cette manette devra aussi être adaptée pour d’autres patients présentant également des handicaps moteurs. Ainsi nous prendrons pour cibles: tous les patients du centre voulant jouer; et non pas que les enfants et adolescents.

 

{| class="wikitable centre" width="80%"
|+
|-
| width="23%" |
Membre du projet
| width="34%" |
Transley Gracias et Camille Saad
|-
| width="23%" |
Cible
| width="34%" |
Patient présentant un handicap moteur
|-
|width="23%" |
Période du projet
| width="34%" |
janvier 2018 - mai 2018
|-
|width="23%" |
Partenaire/Client
| width="34%" |
Centre SSR Marc Sautelet à Villeneuve d'Ascq
|}

==Objectifs==

Ce projet a pour objectif de créer un prototype de manette qui puisse interagir avec la console PS4 et dont le paramétrage se fait à l’aide d’une application mobile et/ou web. Cette manette devra suivre les demandes du patient ainsi que des aides-soignantes du centre, dans la mesure du possible.

Plus précisément, pour le premier prototype, nous mettrons en œuvre l'utilisation de quelques boutons spécifiques:

* Un joystick (type L/R)
* Quelques boutons poussoirs (type Croix/Triangle/Carré/Rond/R1/L1/Start/...)
* Des boutons gâchettes progressives (type L2/R2).

Le but serait donc dans un premier temps de rendre fonctionnel un bouton de chaque type, puis de les multiplier une fois cela fait. Tous ces boutons réunis constituent une manette fonctionnelle.Ainsi, la manette sera ajustable, c’est à dire qu’elle devra s’adapter aux différents handicaps moteurs possibles.

=Analyse du projet=

==Positionnement par rapport à l'existant==

Notre prototype aura une présentation unique par rapport à l’existant. En effet, les concurrents et produits existants ciblent pour la majorité un seul handicap. Cela
engendre une solution fermée à beaucoup de patients. Notre projet propose une mobilité des mouvements et également un choix large dans la composition et le
design de notre manette.
Le patient n’est pas retreint à jouer à une seule main, à utiliser beaucoup de force...Il y a moins de technique dans la manipulation et on ne joue pas avec une
manette adaptée uniquement pour un droitier ou un gaucher. Cependant, cela nous limitera peut-être dans le choix possible des types de jeux. Tout comme les autres
manettes adapté, l’utilisateur nécessitera un peu d’entrainement.

==Analyse du premier concurrent==

Jouer aux jeux vidéo à une main n’est pas une idée d’aujourd’hui. En 1990, Nintendo propose le Power Glove. Mais il tombe très rapidement aux oubliettes suite à des problèmes techniques.

Un autre gant a fait son apparition quelques années plus tard. Celui-ci, plus technique, il faut office de manette Play Station: le Reality Quest Power Glove.Cette idée de manette-gant, permet de jouer à la PS avec une seule main, elle a était conçue et présentée pour les E3, un salon d’exposition de gaming.Le gant est conçu pour contrôler l’équivalent des 14 boutons et 2 joysticks à l’aide d’une seule main. La « manette » est fixée dans la pomme de la main. L’utilisateur contrôle les mouvements verticaux et horizontaux en pivotant le poignet, et utilisent les 4 boutons d’action principaux et L1/R1 avec les doigts. Les autres boutons sont accessibles par un seul bouton rond contrôlé par le pouce.
La manette est adaptée pour beaucoup de jeux vidéo, dont les plus simples sont les jeux de voitures et de combats (arcade).

; Problèmes:
*Besoin de toute la motricité de la main, c’est-à-dire que si le patient à un doigt paralysé ou manquant, il ne pourra pas jouer avec ce gant
*Design obligatoirement droitier
*Les boutons de contrôle sont peu sensibles et peuvent nécessiter de la force
*Design compliqué et nécessitant beaucoup d’entrainement.

;Lien : https://www.youtube.com/watch?v=qV0SxSJDCYg

 
==Analyse du second concurrent==

Ben Heck, de son vrai nom Benjamin J.Heckendorn, est un concepteur de mods de consoles (mods pour modification, soit « manettes modifiées ») et une star
du net grâce à ses vidéos tutoriels.Il propose alors énormément de produits adaptés ou dérivés en guise de manettes.
Parmi les mods qu’il a réalisé, il a modifié une manette de PS4 afin de la rendre accessible à une personne ne pouvant jouer qu’à une main. Pour cela, il a déplacé les boutons en respectant l’ergonomie de la main valide et modifie les connexions. Il peut lui arriver de rajouter des boutons pour en remplacer un autre. Il réalise également le même système avec la Xbox. Sur la photo ci-dessous, il a adapté la manette pour un droitier.

; Problèmes:
*Besoin de toute la motricité de la main, c’est-à-dire que si le patient à un doigt paralysé ou manquant, il ne pourra pas jouer avec cette ma
*Design obligatoirement droitier ou gaucher, une modification = une manette= une personne
*Besoin obligé du pouce et de l’index, même si avantage : 3 doigts nécessaire.

;Lien :: https://www.youtube.com/watch?v=LieHIscadjk

==Scénario d'usage du produit ou du concept envisagé==

La technologie est ,aujourd’hui, omniprésente dans notre vie. Les consoles de jeux ont envahies les maisons avec plus de 7 personnes sur 10 jouant aux jeux vidéos sur consoles en France (chiffre de l’Express). 0,18% des français sont handicapés cela représente 12 millions de français. Dans ce chiffre, 13,4% des personnes ont un handicap moteur. En 2017, les grands groupes comme Sony ou Microsoft avec respectivement PlayStation et Xbox ne permettent pas à tout le monde de jouer avec une manette. Les manettes sont prévues pour des personnes ayant leurs membres valides, plus précisément les mains et les bras.

Après un accident de voiture, un jeune garçon a perdu la motricité d’un côté du corps. Passionné de jeux vidéo, il se retrouve avec des difficultés à jouer sur sa console PS4. Ingénieux, il utilise la manette en la coinçant entre son épaule et le creux du cou. Usant de la mâchoire et de sa main valide pour contrôler les joysticks et les boutons. L'exercice étant inconfortable et fatiguant il eu l’idée de proposer à des futurs ingénieurs de lui proposer une manette adaptée à son handicap.

Les deux pré-ingénieurs ,avec leur tuteur, ont une idée révolutionnaire : La manette modulable ! Elle permettrait au jeune garçon, ainsi que d’autres joueurs, de pouvoir continuer de s’amuser ou même de commencer à jouer au jeux sur console.
Cette manette aidera fortement dans les centre de rééducation pour faire passer le temps et donner du plaisir à des personnes qui ne peuvent plus s’amuser avec leur console traditionnelle. Elle pourra aussi ouvrir de nouvelles possibilités pour certaines personnes qui n’auraient jamais essayé jusqu'à présent.
Comme son nom l'indique, elle sera modulaire et s'adaptera à différents handicaps. Accompagnée de son application d’initialisation, elle sera accessible aussi bien aux enfants, patients, parents et aides soignantes.

Quelques mois plus tard...Le jeune patient fan de Need For Speed, peut maintenant piloter sa voiture comme un vrai professionnel grâce à l'un des joysticks qu'il utilisera avec sa main valide et il pourra accélérer à des vitesses folles à l'aide de boutons poussoirs au niveau de son pied valide et gagner la partie. Son ami venu lui rendre visite, pourra en lieu et place des aides soignantes configurer à l'aide de la tablette (portable) la manette du patient.
Si le patient change de jeu pour Tekken et que la configuration des modules ne lui convient plus, il peut interchanger les éléments de la manette selon son envie et son confort. Ainsi il peut faire sauter son personnage, il utilisera un module bouton supplémentaire, qu'il actionnera avec le poing.

==Fonctionnement==

Suite à une analyse fonctionnelle et à la formulation de notre projet, nous avons pu définir le fonctionnement de notre système. Notre produit, la manette, doit être accessible d’après nos objectifs à différents types de handicaps moteurs. Ainsi, l’idéal serait de concevoir une manette modulable afin qu’elle puisse s’adapter à toutes les situations. Ce n’est plus au patient de s’adapter à la manette mais à la manette de s’adapter au patient.
Cela signifie que la manette sera, dans la limite du possible et de la sensibilité du corps du patient, composée de plusieurs parties dites « modules » comportant un ou plusieurs actionneurs (boutons, joysticks, gâchettes...). Ces modules seront déplaçables afin d’être utilisé avec différents membres du corps : un doigt, une main,
une jambe ou même un pied. Il suffira de les connectés entre eux suivant l’organisation souhaitée, le Gameplay du jeu ou en fonction du handicap. Le tout sera relié à une application.
L’application sera alors mise en place pour connecter les différentes parties du point de vue software pour prérégler la manette en fonction du patient. Il pourra alors choisir les boutons en fonction du jeu, de ses mouvements mais aussi choisir la sensibilité.

L’application et les modules devront être intuitifs et faciles d’utilisation. De cette manière des utilisateurs non avertis dans le domaine informatique ou jeunes pourront eux-mêmes gérer les connexions.

==Réponse à la question difficile==

'''Question : Comment interconnecter les différents modules de la manette ?'''

Il nous faut pour ce projet interconnecter les modules modélisant la manette qui seront connectés à la consoles PS4 via une Raspberry Pi 3.
Le choix de la Raspberry Pi 3 nous permet d'utiliser son module Bluetooth pour communiquer avec la PS4, ce choix est plus adaptée au projet que du filaire.
Concernant l'interconnexion des modules, nous travaillerons en deux étapes "preuves concept" : filaire et sans fils (Bluetooth).

'''Objectif 1 : Preuve concept filaire'''

Dans cette première partie de projet, nous souhaitons avoir une 1ère preuve de prototype rapidement. Nous nous concentrerons alors sur la communication entre la RPi3 et la PS4 ainsi que sur la conception des modules. Pour les modules, nous réaliserons des cartes électronique pour chaque module avec un micro-contrôleur. La communication filaire nous permettra d'interconnecter les modules à la RPi3 avec un bus SPI.

'''Objectif 2: preuve concept sans fils'''

Une deuxième étape du projet est la réalisation de la solution idéale sans fils. Celle-ci pourra commencer à être développée petit à petit en parallèle avec l'objectif 1. Le but ici, est d'interconnecter les modules en Bluetooth. Nous avons choisi le Bluetooth pour garder une connexion commune sur toute la chaîne.
Nous rajouterons alors un module bluetooth à chaque module de la manette.

'''Objectif 3: possibilité d'adapter les boutons (capuchon en 3D)'''

=Préparation du projet=

==Cahier des charges==

''Chef de projet:'' Alexandre Boé 
''Responsables:'' Xavier Redon, Thomas Vantroys 
''Partenariat:'' Marc Sautelet (non etablie) 
''Elèves-ingénieurs:'' Camille Saâd, Transley Gracias 

'''Sujet :''' Manette modulable pour personne à déficience moteur compatible PlayStation 4 

===Objectifs principal (1er POC) : ===
Faire transmettre des informations issus des actionneurs (ex:boutons poussoires) via des arduinos jusqu’à la Raspberry Pi 3 en SPI. 
Envoyer les données reçues vers la PS4 en USB 

===Objectifs secondaire (2e POC):===
Créer des modules avec un microcontrôleur et une puce bluetooth pour permettre une meilleurs flexibilité (c-àd pouvoirs avoir une meilleure ergonomie et une connexion sans fil) 
Connecter la Raspberry Pi 3 en Bluetooth à la PS4 

[[Fichier: beteacorne.jpg||middle|600px|Bete a corne manette]]

==Choix techniques : matériel et logiciel==

===Liste de matériel :===

'''Modules boutons/joysticks/gachettes'''

3 Push buttons : 
- O X Y Carré R3 L3 
- Guide PS 
- start/back 
--> 0,45€/unité TTC [https://www.gotronic.fr/art-bp-miniature-krs1273-16976.htm] 

1 Thumbstick original: 
Joystick analogique 4 directions --> 4,25€/unité TTC [https://www.gotronic.fr/art-joystick-analogique-4-directions-19063.htm] 

1 buttons trigger L1 L2 => 1x Thumbstick original''' 

'''Cartes Atmega328p /connexion spi/'''

3 Arduino UNO 
1 Arduino UNO atmega328p retirable 
4 capacite 22pF traversantes 
2 resistances 10 kOhm traversantes (à récupérer) 
2 oscillateurs quartz 16MHz traversante 
2 atmega328p-pu et support 

'''Cartes module bluetooth nrf52810 '''

6 capacités 100nF 0603 
6 capacités 12pF 0603 
2 capacités 4,7pF 0603 
2 capacités 1µF 0603 
2 capacités 100pF=0,1nF 0603 (à récupérer) 
2 capacités 0,8pF 0603 (a acheter, commande en cours) 
2 inductance 3,9nH 0603 (a acheter, commande en cours) 
2 oscillateur quartz 32 MHz 

''' Connexions et autres '''

1 Led RGB neopixel [https://www.adafruit.com/product/1734] 
1 Raspberry Pi 3 
--> ~36,23€/unité TTC [https://fr.rs-online.com/web/p/processor-microcontroller-development-kits/8968660/?src=raspberrypi] 
1 Raspberry Pi Zero W (commandée) [https://www.raspberrypi.org/products/raspberry-pi-zero-w/] 
6 Alimentations 5V ou 3,3V 
par exemple, 12 piles de type CR2016 3V rechargeables ou 24 piles AAA 1,5 V rechargeables
5 modules Bluetooth nrf de Nordic : nRF52810-QFAA-R 
--> 3,17€/unité + frais expédition [https://www.mouser.fr/productdetail/nordic-semiconductor/nrf52810-qfaa-r?qs=sGAEpiMZZMve4%2FbfQkoj%252bG%2FosjLoe2oghFQwQllMrQ4%3D]
5 Lignes broches mâles 

===Logiciels:===

- IDE arduino
- Altium
- FreeCAD ou Inkscape

==Liste des tâches à effectuer==

'''Etape 1 : Gestion du projet'''

* Définition des cahiers des charges fonctionnel et technique, choix d'orientation...
* Recherche techniques sur les différentes connexions possibles entre les modules, la RPi 3 et la console PS4
#Recherche connexion SPI entre les modules et la RPi3
# Recherche connexion bluetooth entre la RPi3 et la PS4
# Recherche connexion bluetooth pour les modules
# Recherche carte avec montage Atmega328P-PU et anticipation module bluetooth
* Détermination du matériel nécessaire
* Réflexion sur l'application

'''Etape 2: Réalisation du projet'''

'''Partie 1: Preuve concept manette en filaire'''

* Conception de cartes électroniques pour 2 modules (/!\ prévoir modules bluetooth)
* Réalisation connexion SPI avec 2 modules : programmation des Atmega328p en liaison série.
* Si tests concluant, ajouter des modules jusqu'à en avoir 5 (1 pour chaque type de boutons)
* Connexion bluetooth entre la PS4 et la RPi3
* Réalisation du support des modules avec fixations possibles (imprimante 3D)

'''Partie 2: Preuve concept manette en bluetooth'''

* Ajout des modules bluetooth aux cartes électroniques
* Connexion bluetooth entre les modules

'''Partie 3: Application Android : paramétrage de la manette'''

* Créer une application sur tablette ou smartphone (Android) afin de configurer la manette aux besoins (inter-connexion des modules et console)

==Calendrier prévisionnel==

{| class="wikitable centre" width="80%"
|+
|-
| width="23%" |
'''Date'''
| width="34%" |
'''Tache à réaliser''' 
|-
| width="23%" |
17/01/18-24/01/18
| width="34%" |
Faire des recherches sur les différentes interconnexions du système : Bluetooth, RPi-Atmega328 (SPI), RPi-PS4
Continuer liste des taches, matériel, Début recherches + réflexion fixation support des modules
|-
|width="23%" |
31/01/18
| width="34%" |
Recherche technique connexion PS4-RPi3 et connexion SPI RPi3-Module + code
|-
|width="23%" |
31/01/18-07/03/18
| width="34%" |
Réalisation 1er prototype (+ début prototype 2)
|-
|width="23%" |
07/03/18
| width="34%" |
Seance 7 : Test prototype filaire
|-
|width="23%" |
07/03/18-09/05/18
| width="34%" |
Réalisation 2eme prototype + application Android
|-
|width="23%" |
09/05/18
| width="34%" |
Seance 14 : Test prototype Bluetooth
|-
|width="23%" |
14/05/18
| width="34%" |
Video projet
|-
|width="23%" |
15/05/18
| width="34%" |
Finalisation projet et Rapport
|-
|width="23%" |
16/05/18-17/05/18
| width="34%" |
Soutenances Projet
|}

=Réalisation du Projet=

==Feuille d'heures ==

Voici le tableau d'heures du binôme:

{| 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 S11 !! Heures S12 !! Heures S13et+ !! Total
|-
| Analyse du projet
| 10
| 2
| 1
| 1
| 1
|
|
|
|
|
|
|
| 20min
|
| 15h20
|-
| Cherches techniques
|
| 3
| 4
| 4
| 2
| 2
| 1
|
|
|
| 1
| 1
|
|
| 18
|-
| Rédaction du wiki et rapport de projet
|
| 1
| 1
| 1
| 1
| 30min
| 1
|
| 2
| 30min
| 30min
|
| 2
|
| 10h30
|-
| Programmation
|
|
|
|
| 3
| 2
| 3
| 5
| 4
| 7
| 8
| 6
| 5
|
| 43
|-
| Cartes électroniques
|
|
|
|
|
| 6
| 8
| 4
| 6
| 2
| 1
| 2
| 2
|
| 31
|-
| Application
|
|
|
|
|
|
|
|
|
|
|
|
|-
|-
| Total Semaine
| 10
| 6
| 6
| 6
| 7
| 10h30
| 13
| 9
| 12
| 9h30
| 10h30
| 9
| 9h20
|
| '''117h50'''
|}

==Prologue==

Avant la réalisation et conception d'un projet, il est important d'analyser celui-ci. Nous avons allons consacré le prologue à l'analyse fonctionnelle de la manette. Nous avons également eu une réflexion sur l'analyse technique, cela nous a permis de réaliser une liste de matériel. Il est important de définir les objectifs ainsi que les besoins afin de ne rien oublier. (Voir ci-dessus Analyse projet)
Nous avons également organisé notre travail, pour le partage de documents de recherches et la rédaction de compte-rendu final nous avons réalisé un google drive. Par la suite, nous créerons un projet Git.

Durant ce temps, nous avons décidé de réaliser 5 modules. Les modules sont les différents boutons de la manettes qui nous pourrons placer selon nos choix (boutons modulaires) pour notre prototype projet pour chaque type des boutons d'une manette PS4. Ces modules devrons être connectés à la console et interconnectés. Le tout sera lié à une application Android. Suite à quelques recherches et nos analyses, nous avons décidé les points suivants :

- On commencera avec 2 modules et on les multipliera par la suite.
- Les premiers tests sont réalisés avec des boutons petits pour assurer leur caractéristique "modulaires", par la suite nous pourrons ajouter des capuchons de taille plus importante (imprimante 3D ou achat)
- Conception modules : réalisation de carte avec un microcontrôleur atmega328 programmable pour chaque module (anticiper le module Bluetooth)
- Projet en 2 parties : prototype filaire et prototype Bluetooth
# Prototype filaire : connexions entre les modules et la RPi3 en SPI, connexion Rpi3-PS4 en Bluetooth, avec l'application en filaire à la RPi3
# Prototype Bluetooth: connexion Bluetooth entre modules-RPi3-PS4-apllication

[[Fichier: structuremanette.png||center|400px|Concept manette modulable]]

==Semaine 1==

Durant la séance, nous nous sommes concentrés les recherches afin de définir clairement le cahier des charges technique. Il s'agit des réalisations à mettre en œuvre pour les inter-connexions des éléments de la manette.
Ainsi, nous avons fait des recherches sur :

===Connexion SPI entre les modules (Atmega328p) et la RPi3===

SPI: Serial périphérique interface BUS

[[Fichier: yWGmW.png||right|200px|Concept manette modulable]]
Comme indiqué sur l'image ci-dessus, la Raspberry pi 3 peut communiquer en SPI avec ses broches CS0 (24), CS1 (26), SCLK (23), MISO (21), MOSI (19). Celles-ci permettent de communiquer avec un ou plusieurs esclaves (dans notre cas, des Atmega328p) en reliant directement les broches concernées de la RPi3 à celles des composants esclaves.
Chaque broche CS0 (24) ou CS1 (26) ne peut être connectée qu'à l'entrée SS (aussi appelé CS) d'un seul esclave.
C'est a dire que chaque CS est lié à un esclave afin de choisir avec lequel la communication est établie à un moment donné, et les MISO sont reliées entre elles en cascade, de même pour les SCLK et les MOSI. On peut noter que le maître impose la fréquence d’horloge et sélectionne l’esclave auquel les données sont envoyées. 8 MHz est le plus rapide supportable a 3,3V

[[Fichier: fonctionnementSPI.png||right|200px|Connexion SPI multi-esclaves]]

Voici un schéma du fonctionnement souhaité :

Comme nous souhaitons avoir 5 modules environ il nous faudra rajouter un composant en plus afin d'augmenter les possibilités de sélection, par exemple des démultiplexeurs.
Dans un premier temps nous essaierons avec 2 esclaves, puis on augmentera le nombre.

===Connexion Bluetooth PS4-RPi3===

Les recherches portent également sur la connexion entre la manette PS4 et la console. Elles concernent le protocole de communication via Bluetooth

Caracteristique pour la PS4: Bluetooth®v4.0, Qualcomm Atheros AR3002 Buetooth LE: 2,4-2,5 GHz 

Caracteristique de la connexion : 

*Vitesse de transmission >> 3 Mbit/s 8N1
*Relevé tous les 1.3 millisecond (peut-être)
*Chaque manette à une adresse unique BD_ADDR qui correspond à l’adresse MAC de la carte Réseau
*Protocole de détection est le SDP basé sur une emission reception PDU
*L’Attribut ID est representer en TLV Type Length Value
*Communication HCI ACL Data Packet

===Rélisation des cartes électroniques===

matériel nécessaire pour un PCB : 

*breadboard
*câbles
*1 x 10k Ohm résistance
*Quartz 16Mhz clock crystal
*2 x 22 pF capaciteurs
*Atmega328P-PU

Ressources:
[[https://www.arduino.cc/en/Main/Standalone]]
[[http://www.eprojectszone.com/atmega-328-pu-standalone/]]
[[https://www.arduino.cc/en/Tutorial/ArduinoToBreadboard]]

==Semaine 2==

Durant la semaine deux et durant la séance, nous avons continué et approfondie nos recherches sur le projet. Nous avons pu ainsi affiner nos taches de réalisation et donc notre cahier des charges.

===Connexion aux modules: SPI et Bluetooth ===

 CORRIGER

voir https://peip-ima.plil.fr/mediawiki/index.php/BE_2017-2018#Configuration_du_syst.C3.A8me_embarqu.C3.A9

(sudo apt-get install pi-bluetooth)

''connexion sur la raspberry par ssh:''
su
update-rc.d ssh enable
invoke-rc.d ssh start
ssh pi@172.26.79.1XX

''bluetooth''
bluetoothctl
agent on
default-agent
scan on
pair [device Bluetooth address] (exemple: pair XX:XX:XX:XX:XX:XX )

''NOUVELLE REFLEXION : Connexion SPI entre les modules (Atmega328p) et la RPi3 --> MODULES BLUETOOTH''

Si multi-esclaves= plusieurs modules :
Il faut ajouter des sélections pour les SPI → démultiplexeurs OU ne pas utiliser les CS0 et CS1, et plutôt des pins entrée/sortie de la RPi3 lié au SS comme ça on choisit direct le module esclave voulu.

'''IMPORTANT:''' Nous avons étudié à nouveau la datasheet de notre module bluetooth nrf de Nordik. Le module bluetooth comporte déjà un microprocesseur !
Un module plutôt peut donc jouer le rôle de notre atmega328p. Il n'y a alors pas besoin de réaliser des cartes électroniques de type arduino standalone. Nos PCB regrouperont alors uniquement l'alimentation, un actionneur (bouton, joystick), le module bluetooth et les broches de connexion si besoin...

Cette séance nous a alors permise de revoir entièrement le matériel nécessaire. Notre liste de matériel nous semble alors plus réfléchie et limitée au nécessaire.

===Connexion Bluetooth PS4-RPi3===

Suite à nos recherches de la semaine précédente, nous avons sélectionné deux sites bien renseignés :

SITES

Ils nous ont permis de comprendre la communication entre la manette et la console. En effet, ils nous expliquent les échanges de trames Bluetooth.
EXPLICATIONS 1 exemple 

==Semaine 3 : Début premier prototype==

===Connexion SPI RPi3-Arduino===

Comme vu durant les semaines précédentes, nous souhaitons réaliser une connexion Multi-esclaves en SPI entre la Raspberry pi et plusieurs modules.
Cette semaine nous avons vu que la réalisation de notre premier prototype doit aller vite. Il ne nous est pas nécessaire d’attendre les modules bluetooth si il nous faut dans cette partie uniquement utiliser son microprocesseur. Ainsi pour chaque module nous utilisons une arduino UNO. Nous réaliserons les programmes en C afin de pouvoir les réutiliser avec les modules bluetooth par la suite.
Une fois la connexion réalisable nous adapterons les programmes aux modules bluetooth Nordik. En effet, ceux-ci comporte déjà un microprocesseur, le module peut jouer le rôle de notre atmega328p. Il n'y a aurait alors pas besoin de réaliser des cartes électroniques arduino standalone sur PCB, mais directement des cartes électronique avec le module et le module voulu (bouton, joystick...) et l'alimentation.
Durant la séance nous avons alors revu la liste de matériel nécessaire.

[[Fichier: prototype1.jpeg||center|600px|connexion filaire prototype 1 filaire arduino]]

Durant la séance, nous avons recherches des exemples de codes et de librairies pour Arduino SPI et RaspberryPI SPI.

Nous avons également commencé le programme de la connexion SPI pour l'arduino et récupéré les bibliothéques SPI.h avec SPI.c. Nous nous sommes alors concentrer à les comprendre, pour pouvoir l'utiliser.

===Réalisation du projet Git===

Création du projet IMA4_Projet35_ManetteModulable sur Git et partage de celui-ci.
Les premiers dossier crées cette la séance :
-Arduino (connexion SPI arduino) : ProtoSpi.c + dossier librairie SPI + Makefile
-RPI (dossier codes pour Rpi)
-Readme.md
Ces dossiers seront amenés à être modifiés au cours des séances.

===Protocole Bluetooth PS4===

Suite à l'étude des trames Bluetooth, on a pu voir que ces dernières étaient incomplètes. Le modèle de communication étant propriétaire, on n'y a pas accès directement. Cela nous empêche donc de mettre en oeuvre cette communication.
 Déveloper

On a décidé de commencer par une connexion USB (pour laquelle on dispose de toutes les informations) celle-ci étant plus complète.

==Semaine 4==

Pour le prototype 1 FILAIRE nous réaliserons les étapes suivantes :

#Réalisation du programme SPI pour arduino
#Réalisation du programme SPI pour la RPi
#Connexion USB avec la PS4 ou ordinateur
#Réalisation de cartes électroniques atmega328p-pu standalone (remplacer les Arduinos)
#Remplacer les "PCB arduino" par le module bluetooth et adapter la connexion
#Conception 3D de la délimitation 1 axe pour le joystick "gâchette"
#Réalisation de l'application Androïde.

Une fois ces étapes réalisées nous auront alors une preuve de concept filaire et nous pourrons alors passer à une connexion bluetooth.
Le passage à la connexion bluetooth sera le deuxième prototype et le cas idéal de la réalisation de la manette modulable.

===Mise à jour Matériel===

- Modéliser les boutons gâchettes L1/2 R1/2 de la manette PS4 (boutons sensibles à la pression) --> un joystick dont nous bloquerons un axe (imprimante 3D)
- Remplacer la RPi 3 par une Rpi zero W qui nous permettrait de réaliser plus facilement une connexion USB tout en gardant l'avantage du bluetooth.
- Choix de l’alimentation pour les 5 modules Bluetooth: nécessitent 3V --> utiliser des piles rechargeables 1,2V AAA plutôt que piles rondes 3V.

Nous avons également besoin du matériel cité en semaine 1 pour réaliser des cartes électroniques atmega328p-pu standalone. ( nous revenons alors sur les décisions de la semaine 3)

===Connexion SPI RPi3-Arduino===

Montage Raspberrypi et 1 arduino en PSI + 1 bouton + 1 led.
Voici le choix des branchements :

MASTER = RPi
SLAVE= Arduino

'''SPI sur Arduino:'''
MOSI -> GPIO11 //PB3 //master OUT to the slave IN
MISO -> GPIO12 //PB4 //slave OUT to the master IN
SCLK -> GPIO13 //PB5 //serial clock
SS -> GPIO10 //PB2 //slave select
'''Led, bouton et autre...'''
LED --> GPIO6 //PD6
GND
+5V (if required)
'''SPI sur la Raspberry Pi'''
SPIO MOSI -> PIN19
SPIO MISO -> PIN21
SCLK -> PIN23
SPIO CS0 -> PIN24

Continuation du code pour faire clignoter Led branchée à une arduino depuis la Rpi, en connexion SPI.

===Connexion USB PS4-RPi3===
Durant cette, nous avons regardé comment faire cohabiter bluetooth, Application Androïd, USB, PS4, SPI et les module.

Il est alors important de savoir comment utiliser le port série sur la RPi3, soit utiliser les UART.

Nous avons réaliser qu'il n'était pas aussi simple d'utiliser le port serie USB de la Raspberry Pi 3, en effet le SoC est un BCM2837 .
De plus nous ne pouvons pas utiliser le même port pour l'alimentation et la connexion.

Il nous faut alors trouver une alternative ou une solution à ce problème.

==Semaine 5==

===Programmation: Réflexion définitives prototypes filaire ===

La semaine dernière, nous avons rencontré une difficulté liée aux ports séries UART.
Une des solutions à cette difficulté serait d'utiliser une RPi ZERO W à défaut d'une RPi 3. On pourrait alors avoir un port d'alimentation avec connexion USB mais également retrouver la connexion Bluetooth dont nous avons besoin.

Ensuite, nous avons continué la réalisation du prototype filaire par l'avancé du code SPI ainsi que les recherches concernant le protocole PS4.

La Raspberry Pi zero W peut également être utile pour la connexion entre la PS4 et les différents modules en jouant le rôle d'intermédiaire. Nous avons alors commandé une Rpi zero W pour notre projet.
En attendant la réception de la commande, nous nous sommes penché sur les recherches pour les programmes et la configuration nécessaire à l'utilisation de la RPi zero W.

===Electronique===

[[Fichier: bouton_c1.jpg|100px|thumb|left|PCB bouton]]
[[Fichier: arduinobb.jpg|200px|thumb|right|atmega328p-pu branchement test]]

Du coté électronique, nous avons réalisé sur fritzing certaines cartes électroniques. Les Arduino Uno servant actuellement de test, seront remplacées par des PCB atmega328p-pu standalone avec des broches permettant les branchements nécessaires SPI ou encore aux modules "boutons/joystick". Pour les boutons, nous avons également réalisé un pcb afin de faciliter les branchements.

Il nous faut alors également une 3eme carte qui nous sera nécessaire pour la réalisation du prototype sans fil. Dans notre liste de matériel, nous avons des composants nrf52810 bluetooth, ceci doivent être soudé avec les capacités de protection mais également des broches de communication. Nous avons alors commencé cette carte électronique sur Altium avec le fichier projet PCB du distributeur à modifier.

[[Fichier: Arduino_c1.jpg|100px|thumb|center|PCB atmega328p-pu]]

=== Construction 3D ===

Enfin, nous avons commencé à réaliser des boîtiers 3D pour certains modules. Par exemple, comme nous l'avions vu précédemment, un des joysticks servira de bouton-gâchette en utilisant un seul de ses axes. Il nous faut alors réaliser un boitier qui bloque l'un des axes, mais également une tige qui nous permettra de pousser le joystick de manière simplifiée.

==Semaine 6==

===Programmation: configuration RPi Zero W ===

Ayant reçu la Raspberry Pi zero W en début de semaine, nous nous sommes concentrés sur la programmation et la configuration de celle-ci.
Cette partie étant compliquée, elle nous a pris du temps. En effet, il était difficile de connecter la RPi en SSH car il n'est pas possible d'y connecter un clavier directement et on avait besoin de la prise OTG pour "interfacer" la manette.

===Electronique: PCB nrf52810===

Les cartes réalisées en semaine 5 sont validées et en attente de réalisation.

Cette semaine a permis la réalisation et la finalisation de la carte électronique nrf52810. Il nous a fallu recommencé cette carte deux fois. En effet, une fois finie sur Altium nous avons réalisé que les empreintes des CMS sur PCB fourni par le constructeur ne correspondent pas au matériel CMS de l'école. Face à cette inattention de notre part, nous avons décidé de refaire entièrement la carte électronique sur fritzing. Ayant la datasheet et des plans d'inspiration PCB, nous avons pu refaire la carte entièrement.
Sur celle-ci nous avons ajouté des broches de connexion au besoin, un branchement Jtag et ICSP pour la programmation et la connexion SPI.
La carte est en attente de validation, puis validation.

[[Fichier: nrf52810_circuit2.jpg||center|400px|PCB carte nrf52810]]

===Révision matériel ===

Pour la réalisation de nos composants électroniques, il nous a fallu faire une révision des composants disponibles à l'école:
(les quantités indiquées ci-dessous pourront être augmentée si nécessaire,pour avoir dans l'idéal un module de chaque type de la manette, ici on se concentre sur BOUTON et JOYSTICK)

'''Cartes Arduino:'''
* 4 capacite 22pF traversantes
* 2 resistances 10 kOhm traversantes (à récupérer)
* 2 oscillateurs quartz 16MHz traversante
* 2 atmega328p-pu et support

'''Cartes nrf52810'''
* 6 capacités 100nF 0603
* 6 capacités 12pF 0603
* 2 capacités 4,7pF 0603
* 2 capacités 1µF 0603
* 2 capacités 100pF=0,1nF 0603 (à récupérer)
* 2 capacités 0,8pF 0603 (commande en cours)
* 2 inductance 3,9nH 0603 (commande en cours)
* 2 oscillateur quartz 32 MHz

'''Cartes modules Boutons'''
* un sachet de broches mâles (qu'on utilisera également pour les autres cartes, à récupérer/acheté)

Nous avons alors mis-à-jour la liste de composant située plus haut, ainsi que celle de la page IMA4 2017/2018 [https://projets-ima.plil.fr/mediawiki/index.php/Projets_IMA4_SC_%26_SA_2017/2018]

==Semaine 7==

===Programmation: connexion wifi RPi Zero W et Bootloader sur Atmega328p-pu ===

Pendant cette semaine, nous avons continué la programmation et la configuration des Raspberry Pi 3 et Zero W. Concernant la configuration ssh, nous avons utilisé un téléphone en guise de point d’accès à la RPi Zero W en wifi.
Nous avons aussi directement configurer l'OS Jessie, utilisé pour la RPi Zero. On a modifié le fichier cmd.txt et ...pour pouvoir programmer un USB gadget sur le port OTG.
Ci-dessus expliquer fichiers

Nous avons également continuer les programmes de récupération de données : état des boutons et du joystick. Ces programmes sont appliqué sur l'atmega328p-pu standalone sur la plaque d'essai en attendant que le PCB soit opérationnel.
Pour pouvoir programmer l'atemega328p-pu comme une arduino UNO, il nous faut suivre plusieurs étapes :

'''1.Flasher le Bootloader'''
Nous avons 2 Atmega328p-pu neufs, ainsi il nous faut flasher le bootloader sur chacun d'eux afin de pouvoir les utiliser et les programmer sur une breadboard dans un montage minimaliste arduino-standalone.
Pour cela, on peut utiliser une carte arduino UNO. On vérifie le port et le type de carte sélectionnés dans le menu >Outils. Sur cette carte on téléverse le fichier arduinoISP.ino qui se trouve dans les exemples en étant en progrmamateur AVr ISP mkll (>outils>programmateur)
Puis on met l'atmega328p-pu qui nous intéresse sur le suppor socket de la carte. On change de nouveau le programmateur pour Arduino as ISP et on fait >tools>burn bootloader, soit >graver la sequence d'initialisation.
Ces étapes faites, on peut retirer notre microcontroleur et le replacer correctement dans le montage.

'''2.Programmation atmega328 sur breadboard'''
Une fois l'atmega328p-pu préparé, on peut le programmer. On peut le faire simplement à l'aide de la carte arduino UNO utilisée précédemment.On branche les Tx et Rx en commun ainsi que le reset, le GND et le VCC.

Nous avons réaliser des codes basiques tels que le clignotement d'une led rouge ou encore l'affichage de "hello world" sur le moniteur série pour vérifier la bonne fonctionnalité du montage. Cela fait nous avons pu écrire sous Arduino IDE le code de lecture des états.

[[Fichier: montage_BB_test.jpg||left|200px|programmation modules arduino sur breadboard]]

===Electronique : soudure carte de test modules ===

Comme nous l'avons déja vu lors de la réalisation des PCB, si l'on souhaite programmer un atmega328p-pu en bootloader, le montage est simple. Il peut être minimaliste en utilisant une arduino UNO, un atmega328, une breadboard et 3 composants: 1 quartz 16MHZ crystal, 1 résistance 10kOhm et 2 capacitors céramiques de 22pF.
Durant la semaine 7, nous avons soudé les composants traversants de la carte électronique correspondant à ce montage ainsi que le PCB du bouton.

==Semaine 8==

===Programmation ===
Après moult recherche sur les différents site web bien fournis pour le coups on as pu trouvé une amorce à la programmation de l'OTG via un script qui agit au niveau du kernel dans le sous dossier usg_gadget. Ce script donne les informations nécessaires pour pouvoirs échangé les données.
Avec le script trouvé et les informations des sites web décryptant les trames de la manette, on a toujours pas réussit à faire passer notre RPi Zero W pour une manette de PS4. Néanmoins il nous manque la trame HID complète de la manette pour avoir un test effectif.

===Electronique : Correction soudure et soudure CMS===

Durant cette semaine, nous avions souhaité programmer la carte électronique atmega328p-pu. Cependant, nous avons réaliser que nous avions fait une erreur lors de l'envoie du PCB à la production. En effet, celui-ci avait été fait en Top sur le logiciel Fritzing et non en Bottom. Hors nous avions soudé les composants (durant la semaine 7) comme pour un circuit imprimé en bottom, l'atmega328p-pu se retrouve alors inversé par rapport aux pistes.
Comme solution, nous avons choisi de souder un deuxième support pour l'atmega328 de l'autre coté de la carte avant de la refaire au propre. En effet, avant de la refaire il nous faut vérifier si la carte est bien programmable.
Une fois cela fait nous avions pu programmer la carte mais, nous avions également réalisé la pin 2 de l'atmega328 était prise par le bouton poussoir. Or, nous avons besoin des pin 2 et 3 pour le RX et TX permettant la programmation de l'atmega à partir d'une arduino, les pistes branchement RX-TX n'ont également pas été prévus pour le téléversement des programmes sur la carte. Il nous faut alors couper une piste et souder des câbles pour utiliser toutes les pistes souhaitées.

[[Fichier: correction_proto_PCB.jpg||right|300px|PCB arduino correction]]

Durant cette semaine, nous avons également souhaité souder les CMS et le composant bluetooth nrf52810 sur la carte imprimé et reçu lors de la semaine 7. Pour cela, nous avons convenu de travailler dans la C202 durant la séance du mercredi.

[[Fichier: PCB_nrf52810.jpg||left|400px|carte electroniques imprimées]]

====Comment souder des CMS ?====

les CMS sont des composants montés en surface c'est à dire qu'ils sont montés du même côté que les pistes cuivrées (à l'opposé des composants traversants) et sont de petite tailles souvent de l'ordre du millimètre. La taille est déterminée par 4 chiffres : les 2 premiers pour la longueur et les 2 derniers pour la largeur. On a du 1206,0805,0603 ou encore 0402. Il est même possible de trouver plus petit. A l'école nous utilisons souvent du 0603, c'est le cas de nos composants.
Pour souder des CMS 0603, il nous faut utiliser une autre méthode qui n'est pas le fer à souder :
# Préparer la veille la pâte à braser la veille (dans une seringue)
# Gommer la carte pour éviter l'oxydation (attention à ne pas retirer les miettes de gomme en soufflant dessus)
# Appliquer avec la seringue la pâte sur les empreintes et piste souhaitées. Pour les endroits difficile à atteindre ou avec 2 pistes proches les unes des autres, il est possible de mettre la même goutte de pâte sur les 2 pistes. Cela de causera pas de court-circuit par la suite. En effet, la pâte est composée d’alliage qui sous la chaleur va se fluidifier et se coller uniquement aux pistes métallique. Le reste fondera sous la chaleur du four.
# Appliquer les CMS sur la pâte au fur et à mesure (attention ! ne jamais toucher les CMS avec les doigts, tjrs utiliser une pince)
# Mettre au four

====Bilan soudure nrf52810====

Cependant, une fois le matériel nécessaire préparé, et la pâte mise sur les pistes souhaitées, au moment de déposer le composant, nous avons réalisé que celui-ci était beaucoup plus petit que l'empreinte sur le PCB. Il s'agit d'un composant boitier QFN48. Fritzing ne proposant au plus proche des boitiers QFN24 ou LQFP48, celui-ci a basculé automatiquement pour un boitier LQFN48, de dimension plus grande. Face à ce manque de vigilance, nous avions cependant commencer par le nrf52810 (composant concerné) évitant ainsi de gaspiller d'autres CMS.
Nous avons souhaité refaire la carte sous Altium à partir des fichiers fournis par le concepteur (chose que nous avons commencé à faire aux alentours de la semaine 5)
Après la réalisation du schématic, et de la modification des empreintes de capacités, inductances et autres composants de 0402 à 0603. Notre matériel ne permettant que des empreintes 0603.

Lors du routage, une erreur de chevauchement des pistes est notifiée par Altium au niveau du nrf52810. Celles-ci ne présentent pas d'angles et sont déjà de taille 8mil, il nous faut alors passer les pistes en 6mil. Mais 8mil est la taille minimale pour la production à Polytech, nous avons regardé pour envoyer les cartes à faire ailleurs mais le 6mil n'est pas beaucoup conseillé. De plus, il n'est peut-être pas judicieux de continuer avec le composant microcontrôleur-bluetooth Nrf52810 qui prend du temps, donc la carte est difficilement réalisable et peut-être très long à programmer.

Ainsi en cette fin de semaine, nous avons décider face à l'avancer du projet de laisser les nrf52810 de coté et de les remplacer par des modules sans fils plus simples d'utilisation et complets. Ainsi nous aurions plus de chance d'avoir une connexion sans fils entre les modules. Nous pourrions par exemples utiliser des Xbee, des modules Rf...

==Semaine 9==

====Programmation: PS4 et 1er Test SPI sur atmega328p====

'''Raspberry Pi Zero W et PS4'''

Les premiers tests sur Windows ne nous donner pas satisfaction. En effet, l'ordinateur détectait bien le nouvel appareil avec son nom mais l'origine rester inconnue.

Lors des tests sur Linux on a pu voir des erreurs via la commande 'dmesg' :

[193229.758782] usb 4-1.2: new high-speed USB device number 6 using ehci-pci
[193230.270780] usb 4-1.2: new high-speed USB device number 7 using ehci-pci
[193235.510842] usb 4-1.2: device descriptor read/64, error -110
[193251.127043] usb 4-1.2: device descriptor read/64, error -110
[193251.315043] usb 4-1.2: new high-speed USB device number 8 using ehci-pci
[193256.503135] usb 4-1.2: device descriptor read/64, error -110
[193272.119331] usb 4-1.2: device descriptor read/64, error -110
[193272.307331] usb 4-1.2: new high-speed USB device number 9 using ehci-pci
[193282.999473] usb 4-1.2: device not accepting address 9, error -110
[193283.079485] usb 4-1.2: new high-speed USB device number 10 using ehci-pci
[193293.751588] usb 4-1.2: device not accepting address 10, error -110
[193293.751771] usb 4-1-port2: unable to enumerate USB device
[193387.196861] usb 4-1.2: new high-speed USB device number 11 using ehci-pci
[193392.440941] usb 4-1.2: device descriptor read/64, error -110
[193407.933152] usb 4-1.1: new high-speed USB device number 12 using ehci-pci
[193413.177227] usb 4-1.1: device descriptor read/64, error -110

'''Modules Atmega328p et SPI'''

Une carte PCB arduino fonctionnant, nous pouvons la programme pour simuler un module. Celle-ci a été designée afin de s'adapter au module que l'on souhaite. Il suffit de brancher le bouton, le joystick ou autre élèment de manette souhaité.
Cette semaine ci, nous avons alors configurer la partie communication SPI pour l'arduino.

'''Que voulons-nous faire avec les atmegas ?'''
Les cartes électroniques atmega328p vont nous permettre de recevoir les requêtes SPI envoyées par la raspberry pi et d'y répondre. La Raspberry enverra un message, par exemple "1", et l'Arduino lira alors l'état du module qui lui est connecté. Une fois l'état récupéré elle le renvoie à la raspberry pi.

Durant cette semaine, nous avons programmé l'atmega afin qu'il soit en esclave, qu'il reçoive un de la RPi "1" et retourne une valeur sauvegardé "int envoi". Nous avons également commencé les tests pour la lecture de l'état d'un bouton (d'après les tests réalisés les semaines précédentes).

'''Code'''
Comme nous l'avons vu précedement lors de nos recherches (semaines 1 à 4) :
La communication SPI nécessite l'utilisation des pins:

MOSI -> GPIO11 //PB3 //master OUT to the slave IN
MISO -> GPIO12 //PB4 //slave OUT to the master IN
SCLK -> GPIO13 //PB5 //serial clock
SS -> GPIO10 //PB2 //slave select

Il faut également paramétrer l'atmega328p en Slave. On note que dans un premier temps, le programme sera codé avec l'arduino IDE (fichiers .ino). Une fois l'ensemble SPI RaspberryPi-Arduino fonctionnant, on remplacera ces codes par du langage C ou C++.

Pour faire la connexion SPI sur l'atmega328p, on utilise la librairie arduino SPI.h, on a alors directement les fonctions nécessaires intervenant sur les registres souhaités : SPCR (spi control register), SPSR (spi status register) et SPDR (spi data register).

#include <SPI.h>

Il est important d'initialise d'abord le setup et on active le port série pour pourvoir utiliser le moniteur série. (Cela servira à verifier la valeur envoyée par la RPi)

void setup (void)
{
Serial.begin (9600);
pinMode(MISO, OUTPUT); //configuration en esclave *master in slave out*
pinMode(buttonPin,INPUT); //config pin bouton
// turn on SPI in slave mode
SPCR |= _BV(SPE);
// preparation interruptions
pos = 0; // buffer empty
process_it = false;
// activation interruptions
SPI.attachInterrupt();
}

On oublie pas de déclarer les interruptions afin de bien lire la requête reçue.

// SPI interrupt routine
ISR (SPI_STC_vect)
{
byte c = SPDR; // grab byte from SPI Data Register
// add to buffer if room
if (pos < sizeof buf)
{
buf [pos++] = c;
// example: newline means time to process buffer
if (c == '\n')
process_it = true;
} // end of room available
} // end of interrupt routine SPI_STC_vect

Dans la loop main, on traite la requête et on utilise '''SPI.transfer(envoi);''' pour transferer à la RPi les données souhaitées.

Durant cette semaine, nous avons également commencé des programmes de test SPI pour la RPi. Il s'agit principalement de programmes de tests tout faits permettant de vérifier la connexion entre cette dernière et l'arduino. Par exemple, la RPI envoie "bonjour" et l'arduino lui retourne ce qu'elle reçoit, soit "bonjour". Sans succés alors.

====Electronique : Fritzing révision====

Lors de la semaine, le modèle PCB de la carte arduino a été réalisé de nouveau sous fritzing avec les broches et connections manquantes. Nous avons également revu la configuration du bouton reset et ajouté une led d'état de l'alimentation. Nous avons ainsi envoyé deux cartes identiques à la réalisation.
La carte déjà soudée lors des derniers jours fonctionnant, elle nous sert de prototype de programmation. Nous pouvons ainsi avancer à la fois sur la programmation des modules mais aussi sur leur réalisation.

==Semaine 10==

====Programmation : PS4 et SPI sur RPi====

'''Raspberry Pi Zero W et PS4'''

Cette semaine, pour tester la prise OTG nous avons décider de lancer un script qui est habituellement utilisé. Nous avons choisi le script Serial Adapter qui est censé permettre de se connecter à la RPi Zero W en SSH via ce port.
Après quelque modifications et plusieurs petits bugs, nous avons réussir à faire fonctionner le ssh via le port OTG. Donc le problème était le même, notre script mélangé avec les informations sur la PS4 n'était toujours pas fonctionnel.

Pour faire la liaison entre les deux parties nous avons aussi commencé à programmer une application qui permet de configurer les modules au niveau de la RPi Zero W.

'''Modules Raspberry PI et SPI'''

Durant cette semaine, pour la partie Atmega328p-Modules, nous nous sommes concentrés sur la programmation de la communication SPI avec la raspberry pi. Cette semaine a permis une étude plus approfondit sur le fonctionnement pour la RPi.

On rappelle, comme vu des semaines 1 à 4, pour la RPI3 (tout comme la RPi Zero W) utilise les broches : SCLK (23), MISO(21), MOSI (19) et SPI CS0 (24), SPI CS1 (26).
On la programme en Master. A l'aide des fichiers tests d'inspiration, on pourra directement programmer la RPi en C. Lors de la réalisation du code, il y a 3 étapes : l'initialisation/parametrage en SPI pour être maître, l'envoie de la requête puis la réception de données en retour.

Programmant en C, il ne faut pas oublier les librairies suivantes :

#include <stdint.h>
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
#include <getopt.h>
#include <fcntl.h>
#include <sys/ioctl.h>
#include <linux/types.h>
#include <linux/spi/spidev.h> //pour SPI

On va déclarer des variables globales permettant le paramétrage :

static const char *device = "/dev/spidev0.0"; //si on veut CS0 pour atteindre notre SS
static uint8_t mode; //mode est par défaut à 0
static uint8_t bits = 8; //bits par mot échangé
static uint32_t speed = 500000;
static uint16_t delay;

Dans notre main, on ouvre le port (la connexion) au device souhaité, on vérifie les paramètres (registres, connexions...) puis exécute la fonction transfer(fd). transfer(fd) transmet la requête et s'occupe de la réception.

fd = open(device, O_RDWR);
transfer(fd);
close(fd);

==Semaine 11==

====Programmation: PS4, SSH et tests SPI (RPi3&Atemga328p)====

'''Raspberry Pi Zero W et PS4'''
Lors de recherche supplémentaire, nous avons essayer de voir s'il un pilote de gestion du périphérique serait nécessaire à la connexion de notre pseudo manette.

'''Raspberry PI, Atmega328p et SPI'''

Afin de facilité la programmation en utilisant Ethernet, nous avons installer et configuré la RPi pour l'utiliser en SSH depuis les ordinateurs de la E306. En effet, SSH permet de se connecter à distance sur une machine en utilisant un compte utilisateur de la dite machine. En mettant ssh, on pourra directement agir sur les fichiers de la raspberry depuis un terminal de notre PC. Pour cela, on a d'abord vérifier l'adresse IP de notre raspberry pi : 172.26.145.106 avec un écran mais on peut aussi utiliser les commandes ip a et ifconfig. Puis activer le ssh sur la raspberry pi.
On modifie alors le fichier config.txt mais également etc/network/interfaces pour configurer la bonne interface Ethernet sur la raspberry pi.

[[Fichier: configSSH_raspi.png||left|300px|config ssh ethernet]]

Il nous suffit alors de taper la commande : ssh pi@172.26.145.106 pour accéder à notre RPi.

Nous avons continué à réaliser la communication SPI avec des tests entre une arduino UNO et la RPI3. Nous avons commencé par des tests simples inspirés des études de deux semaines précédentes et modulés selon notre utilité.
Nous arrivons alors à lire l'état envoyer "bonjour" et recevoir "ça va" ou encore "1" et recevoir "3". Il faut noter que le SPI échange des trames, la RPI reçoit alors des hexadécimaux.
Nous avons alors continué pour recevoir l'état du bouton ou du joystick lors de l'envoie de "1" sur l'Arduino328p. La semaine prochaine nous testerons ces même codes fonctionnels sur les cartes atmeg327p.

A la fin de cette semaine, nous avons alors des codes Arduino-SPI (.ino) et des codes Raspberry-SPI (.c) permettant l'échange de données. Le but est maintenant de l'adapter aux cartes imprimées et de le rendre pleinement fonctionnel pour plusieurs cartes à la fois, puis ajouter une boucle de vérification en continue jusqu'à une deuxième requête de la RPi.

====Electronique: réalisation au propres des PCB modules====

Suite à une nouvelle erreur de réalisation cartes électronique, nous avons refait et renvoyé à nouveau les cartes imprimées atmega328p.
Nous les souhaitons au propre pour une version finale. Une fois celle-ci imprimées nous pourrons en avoir 3 , un pour chaque module. Les cartes étaient bien imprimées en bottom mais lors du passage des traversants de bottom à top, le logiciel ne les a pas fait miroiter. Par manque d'attention nous avons alors envoyé les fichiers gerber pour des cartes ayant les composants du même coté que la couche de cuivre.
Les cartes électroniques actuelles sont alors correctes et fonctionnelles mais difficile à souder. Pour eviter les erreurs et continuer sur des prototypes de carte nous préférons attendre en nous concentrant sur la programmation PSI de la Raspberry Pi.

==Semaine 12==

====Programmation====

'''Raspberry Pi Zero W et PS4'''

'''Raspberry PI, Atmega328p et SPI'''

- réflexion: penser à faire boucler sur l'arduino une fois la requête reçu, ça veut dire que la manette est ON et donc vérifier continuellement les modules sur chaque atmega.
- SPI raspberry pi - arduino recuperation état du bouton avec les cartes modules (/!\ récuperation à faire dans une variable)

-SSH perso
adresse Rasppi: 192.168.137.10

====Electronique: Finalisation soudure Modules====

Soudure au propre et finale d'une carte atmega328p et donc envoie pour la réalisation de 2 autres cartes similaires et récupération de matériel
Soudure des 2 autres cartes, + tests sur les états = fonctionnelles.
On a donc bien 3 cartes pour les 3 modules de types différents (1 bouton, 1 joystick, 1 gachette)
PCB pour les 2 joysticks (qui serviront de thumbstick et gachette)

==Semaine 13 et plus==

====Programmation====

'''Raspberry Pi Zero W et PS4'''

'''Modules Atmega328p et SPI'''

====Electronique====

=Documents Rendus=

(à mettre rapport + git + drive)

=Datasheets=

IMA4 2017/2018 P35

2018-05-05T20:17:18Z

Tgracias : /* Programmation : PS4 et SPI sur RPi */

__TOC__
 

=Présentation générale: Manette modulable=

==Description==

Tout le monde joue aux jeux vidéo cependant, les manettes ne sont pas adaptées aux personnes ayant un handicap pouvant toucher les bras ou les mains.
C’est le cas, de plusieurs patients dans les centres de soins et de rééducation.

Pour ce projet IMA4, nous travaillerons avec le centre SSR (soin de suite et de réadaptation) Marc Sautelet de Villeneuve d’Ascq.
Un adolescent, patient de Marc Sautelet, est passionné par les jeux vidéo. En effet, ayant perdu la motricité d’une partie de son corps, il ne peut pas jouer à deux mains. Pour cela, il bloque la manette entre son épaule et son coude, usant de la mâchoire et des doigts pour contrôler les
joysticks et les boutons. Cet exercice peut s’avérer fatiguant et pénible.

Ainsi, nous chercherons à concevoir une manette PS4 adaptée au handicap de l’adolescent.
Cette manette devra aussi être adaptée pour d’autres patients présentant également des handicaps moteurs. Ainsi nous prendrons pour cibles: tous les patients du centre voulant jouer; et non pas que les enfants et adolescents.

 

{| class="wikitable centre" width="80%"
|+
|-
| width="23%" |
Membre du projet
| width="34%" |
Transley Gracias et Camille Saad
|-
| width="23%" |
Cible
| width="34%" |
Patient présentant un handicap moteur
|-
|width="23%" |
Période du projet
| width="34%" |
janvier 2018 - mai 2018
|-
|width="23%" |
Partenaire/Client
| width="34%" |
Centre SSR Marc Sautelet à Villeneuve d'Ascq
|}

==Objectifs==

Ce projet a pour objectif de créer un prototype de manette qui puisse interagir avec la console PS4 et dont le paramétrage se fait à l’aide d’une application mobile et/ou web. Cette manette devra suivre les demandes du patient ainsi que des aides-soignantes du centre, dans la mesure du possible.

Plus précisément, pour le premier prototype, nous mettrons en œuvre l'utilisation de quelques boutons spécifiques:

* Un joystick (type L/R)
* Quelques boutons poussoirs (type Croix/Triangle/Carré/Rond/R1/L1/Start/...)
* Des boutons gâchettes progressives (type L2/R2).

Le but serait donc dans un premier temps de rendre fonctionnel un bouton de chaque type, puis de les multiplier une fois cela fait. Tous ces boutons réunis constituent une manette fonctionnelle.Ainsi, la manette sera ajustable, c’est à dire qu’elle devra s’adapter aux différents handicaps moteurs possibles.

=Analyse du projet=

==Positionnement par rapport à l'existant==

Notre prototype aura une présentation unique par rapport à l’existant. En effet, les concurrents et produits existants ciblent pour la majorité un seul handicap. Cela
engendre une solution fermée à beaucoup de patients. Notre projet propose une mobilité des mouvements et également un choix large dans la composition et le
design de notre manette.
Le patient n’est pas retreint à jouer à une seule main, à utiliser beaucoup de force...Il y a moins de technique dans la manipulation et on ne joue pas avec une
manette adaptée uniquement pour un droitier ou un gaucher. Cependant, cela nous limitera peut-être dans le choix possible des types de jeux. Tout comme les autres
manettes adapté, l’utilisateur nécessitera un peu d’entrainement.

==Analyse du premier concurrent==

Jouer aux jeux vidéo à une main n’est pas une idée d’aujourd’hui. En 1990, Nintendo propose le Power Glove. Mais il tombe très rapidement aux oubliettes suite à des problèmes techniques.

Un autre gant a fait son apparition quelques années plus tard. Celui-ci, plus technique, il faut office de manette Play Station: le Reality Quest Power Glove.Cette idée de manette-gant, permet de jouer à la PS avec une seule main, elle a était conçue et présentée pour les E3, un salon d’exposition de gaming.Le gant est conçu pour contrôler l’équivalent des 14 boutons et 2 joysticks à l’aide d’une seule main. La « manette » est fixée dans la pomme de la main. L’utilisateur contrôle les mouvements verticaux et horizontaux en pivotant le poignet, et utilisent les 4 boutons d’action principaux et L1/R1 avec les doigts. Les autres boutons sont accessibles par un seul bouton rond contrôlé par le pouce.
La manette est adaptée pour beaucoup de jeux vidéo, dont les plus simples sont les jeux de voitures et de combats (arcade).

; Problèmes:
*Besoin de toute la motricité de la main, c’est-à-dire que si le patient à un doigt paralysé ou manquant, il ne pourra pas jouer avec ce gant
*Design obligatoirement droitier
*Les boutons de contrôle sont peu sensibles et peuvent nécessiter de la force
*Design compliqué et nécessitant beaucoup d’entrainement.

;Lien : https://www.youtube.com/watch?v=qV0SxSJDCYg

 
==Analyse du second concurrent==

Ben Heck, de son vrai nom Benjamin J.Heckendorn, est un concepteur de mods de consoles (mods pour modification, soit « manettes modifiées ») et une star
du net grâce à ses vidéos tutoriels.Il propose alors énormément de produits adaptés ou dérivés en guise de manettes.
Parmi les mods qu’il a réalisé, il a modifié une manette de PS4 afin de la rendre accessible à une personne ne pouvant jouer qu’à une main. Pour cela, il a déplacé les boutons en respectant l’ergonomie de la main valide et modifie les connexions. Il peut lui arriver de rajouter des boutons pour en remplacer un autre. Il réalise également le même système avec la Xbox. Sur la photo ci-dessous, il a adapté la manette pour un droitier.

; Problèmes:
*Besoin de toute la motricité de la main, c’est-à-dire que si le patient à un doigt paralysé ou manquant, il ne pourra pas jouer avec cette ma
*Design obligatoirement droitier ou gaucher, une modification = une manette= une personne
*Besoin obligé du pouce et de l’index, même si avantage : 3 doigts nécessaire.

;Lien :: https://www.youtube.com/watch?v=LieHIscadjk

==Scénario d'usage du produit ou du concept envisagé==

La technologie est ,aujourd’hui, omniprésente dans notre vie. Les consoles de jeux ont envahies les maisons avec plus de 7 personnes sur 10 jouant aux jeux vidéos sur consoles en France (chiffre de l’Express). 0,18% des français sont handicapés cela représente 12 millions de français. Dans ce chiffre, 13,4% des personnes ont un handicap moteur. En 2017, les grands groupes comme Sony ou Microsoft avec respectivement PlayStation et Xbox ne permettent pas à tout le monde de jouer avec une manette. Les manettes sont prévues pour des personnes ayant leurs membres valides, plus précisément les mains et les bras.

Après un accident de voiture, un jeune garçon a perdu la motricité d’un côté du corps. Passionné de jeux vidéo, il se retrouve avec des difficultés à jouer sur sa console PS4. Ingénieux, il utilise la manette en la coinçant entre son épaule et le creux du cou. Usant de la mâchoire et de sa main valide pour contrôler les joysticks et les boutons. L'exercice étant inconfortable et fatiguant il eu l’idée de proposer à des futurs ingénieurs de lui proposer une manette adaptée à son handicap.

Les deux pré-ingénieurs ,avec leur tuteur, ont une idée révolutionnaire : La manette modulable ! Elle permettrait au jeune garçon, ainsi que d’autres joueurs, de pouvoir continuer de s’amuser ou même de commencer à jouer au jeux sur console.
Cette manette aidera fortement dans les centre de rééducation pour faire passer le temps et donner du plaisir à des personnes qui ne peuvent plus s’amuser avec leur console traditionnelle. Elle pourra aussi ouvrir de nouvelles possibilités pour certaines personnes qui n’auraient jamais essayé jusqu'à présent.
Comme son nom l'indique, elle sera modulaire et s'adaptera à différents handicaps. Accompagnée de son application d’initialisation, elle sera accessible aussi bien aux enfants, patients, parents et aides soignantes.

Quelques mois plus tard...Le jeune patient fan de Need For Speed, peut maintenant piloter sa voiture comme un vrai professionnel grâce à l'un des joysticks qu'il utilisera avec sa main valide et il pourra accélérer à des vitesses folles à l'aide de boutons poussoirs au niveau de son pied valide et gagner la partie. Son ami venu lui rendre visite, pourra en lieu et place des aides soignantes configurer à l'aide de la tablette (portable) la manette du patient.
Si le patient change de jeu pour Tekken et que la configuration des modules ne lui convient plus, il peut interchanger les éléments de la manette selon son envie et son confort. Ainsi il peut faire sauter son personnage, il utilisera un module bouton supplémentaire, qu'il actionnera avec le poing.

==Fonctionnement==

Suite à une analyse fonctionnelle et à la formulation de notre projet, nous avons pu définir le fonctionnement de notre système. Notre produit, la manette, doit être accessible d’après nos objectifs à différents types de handicaps moteurs. Ainsi, l’idéal serait de concevoir une manette modulable afin qu’elle puisse s’adapter à toutes les situations. Ce n’est plus au patient de s’adapter à la manette mais à la manette de s’adapter au patient.
Cela signifie que la manette sera, dans la limite du possible et de la sensibilité du corps du patient, composée de plusieurs parties dites « modules » comportant un ou plusieurs actionneurs (boutons, joysticks, gâchettes...). Ces modules seront déplaçables afin d’être utilisé avec différents membres du corps : un doigt, une main,
une jambe ou même un pied. Il suffira de les connectés entre eux suivant l’organisation souhaitée, le Gameplay du jeu ou en fonction du handicap. Le tout sera relié à une application.
L’application sera alors mise en place pour connecter les différentes parties du point de vue software pour prérégler la manette en fonction du patient. Il pourra alors choisir les boutons en fonction du jeu, de ses mouvements mais aussi choisir la sensibilité.

L’application et les modules devront être intuitifs et faciles d’utilisation. De cette manière des utilisateurs non avertis dans le domaine informatique ou jeunes pourront eux-mêmes gérer les connexions.

==Réponse à la question difficile==

'''Question : Comment interconnecter les différents modules de la manette ?'''

Il nous faut pour ce projet interconnecter les modules modélisant la manette qui seront connectés à la consoles PS4 via une Raspberry Pi 3.
Le choix de la Raspberry Pi 3 nous permet d'utiliser son module Bluetooth pour communiquer avec la PS4, ce choix est plus adaptée au projet que du filaire.
Concernant l'interconnexion des modules, nous travaillerons en deux étapes "preuves concept" : filaire et sans fils (Bluetooth).

'''Objectif 1 : Preuve concept filaire'''

Dans cette première partie de projet, nous souhaitons avoir une 1ère preuve de prototype rapidement. Nous nous concentrerons alors sur la communication entre la RPi3 et la PS4 ainsi que sur la conception des modules. Pour les modules, nous réaliserons des cartes électronique pour chaque module avec un micro-contrôleur. La communication filaire nous permettra d'interconnecter les modules à la RPi3 avec un bus SPI.

'''Objectif 2: preuve concept sans fils'''

Une deuxième étape du projet est la réalisation de la solution idéale sans fils. Celle-ci pourra commencer à être développée petit à petit en parallèle avec l'objectif 1. Le but ici, est d'interconnecter les modules en Bluetooth. Nous avons choisi le Bluetooth pour garder une connexion commune sur toute la chaîne.
Nous rajouterons alors un module bluetooth à chaque module de la manette.

'''Objectif 3: possibilité d'adapter les boutons (capuchon en 3D)'''

=Préparation du projet=

==Cahier des charges==

''Chef de projet:'' Alexandre Boé 
''Responsables:'' Xavier Redon, Thomas Vantroys 
''Partenariat:'' Marc Sautelet (non etablie) 
''Elèves-ingénieurs:'' Camille Saâd, Transley Gracias 

'''Sujet :''' Manette modulable pour personne à déficience moteur compatible PlayStation 4 

===Objectifs principal (1er POC) : ===
Faire transmettre des informations issus des actionneurs (ex:boutons poussoires) via des arduinos jusqu’à la Raspberry Pi 3 en SPI. 
Envoyer les données reçues vers la PS4 en USB 

===Objectifs secondaire (2e POC):===
Créer des modules avec un microcontrôleur et une puce bluetooth pour permettre une meilleurs flexibilité (c-àd pouvoirs avoir une meilleure ergonomie et une connexion sans fil) 
Connecter la Raspberry Pi 3 en Bluetooth à la PS4 

[[Fichier: beteacorne.jpg||middle|600px|Bete a corne manette]]

==Choix techniques : matériel et logiciel==

===Liste de matériel :===

'''Modules boutons/joysticks/gachettes'''

3 Push buttons : 
- O X Y Carré R3 L3 
- Guide PS 
- start/back 
--> 0,45€/unité TTC [https://www.gotronic.fr/art-bp-miniature-krs1273-16976.htm] 

1 Thumbstick original: 
Joystick analogique 4 directions --> 4,25€/unité TTC [https://www.gotronic.fr/art-joystick-analogique-4-directions-19063.htm] 

1 buttons trigger L1 L2 => 1x Thumbstick original''' 

'''Cartes Atmega328p /connexion spi/'''

3 Arduino UNO 
1 Arduino UNO atmega328p retirable 
4 capacite 22pF traversantes 
2 resistances 10 kOhm traversantes (à récupérer) 
2 oscillateurs quartz 16MHz traversante 
2 atmega328p-pu et support 

'''Cartes module bluetooth nrf52810 '''

6 capacités 100nF 0603 
6 capacités 12pF 0603 
2 capacités 4,7pF 0603 
2 capacités 1µF 0603 
2 capacités 100pF=0,1nF 0603 (à récupérer) 
2 capacités 0,8pF 0603 (a acheter, commande en cours) 
2 inductance 3,9nH 0603 (a acheter, commande en cours) 
2 oscillateur quartz 32 MHz 

''' Connexions et autres '''

1 Led RGB neopixel [https://www.adafruit.com/product/1734] 
1 Raspberry Pi 3 
--> ~36,23€/unité TTC [https://fr.rs-online.com/web/p/processor-microcontroller-development-kits/8968660/?src=raspberrypi] 
1 Raspberry Pi Zero W (commandée) [https://www.raspberrypi.org/products/raspberry-pi-zero-w/] 
6 Alimentations 5V ou 3,3V 
par exemple, 12 piles de type CR2016 3V rechargeables ou 24 piles AAA 1,5 V rechargeables
5 modules Bluetooth nrf de Nordic : nRF52810-QFAA-R 
--> 3,17€/unité + frais expédition [https://www.mouser.fr/productdetail/nordic-semiconductor/nrf52810-qfaa-r?qs=sGAEpiMZZMve4%2FbfQkoj%252bG%2FosjLoe2oghFQwQllMrQ4%3D]
5 Lignes broches mâles 

===Logiciels:===

- IDE arduino
- Altium
- FreeCAD ou Inkscape

==Liste des tâches à effectuer==

'''Etape 1 : Gestion du projet'''

* Définition des cahiers des charges fonctionnel et technique, choix d'orientation...
* Recherche techniques sur les différentes connexions possibles entre les modules, la RPi 3 et la console PS4
#Recherche connexion SPI entre les modules et la RPi3
# Recherche connexion bluetooth entre la RPi3 et la PS4
# Recherche connexion bluetooth pour les modules
# Recherche carte avec montage Atmega328P-PU et anticipation module bluetooth
* Détermination du matériel nécessaire
* Réflexion sur l'application

'''Etape 2: Réalisation du projet'''

'''Partie 1: Preuve concept manette en filaire'''

* Conception de cartes électroniques pour 2 modules (/!\ prévoir modules bluetooth)
* Réalisation connexion SPI avec 2 modules : programmation des Atmega328p en liaison série.
* Si tests concluant, ajouter des modules jusqu'à en avoir 5 (1 pour chaque type de boutons)
* Connexion bluetooth entre la PS4 et la RPi3
* Réalisation du support des modules avec fixations possibles (imprimante 3D)

'''Partie 2: Preuve concept manette en bluetooth'''

* Ajout des modules bluetooth aux cartes électroniques
* Connexion bluetooth entre les modules

'''Partie 3: Application Android : paramétrage de la manette'''

* Créer une application sur tablette ou smartphone (Android) afin de configurer la manette aux besoins (inter-connexion des modules et console)

==Calendrier prévisionnel==

{| class="wikitable centre" width="80%"
|+
|-
| width="23%" |
'''Date'''
| width="34%" |
'''Tache à réaliser''' 
|-
| width="23%" |
17/01/18-24/01/18
| width="34%" |
Faire des recherches sur les différentes interconnexions du système : Bluetooth, RPi-Atmega328 (SPI), RPi-PS4
Continuer liste des taches, matériel, Début recherches + réflexion fixation support des modules
|-
|width="23%" |
31/01/18
| width="34%" |
Recherche technique connexion PS4-RPi3 et connexion SPI RPi3-Module + code
|-
|width="23%" |
31/01/18-07/03/18
| width="34%" |
Réalisation 1er prototype (+ début prototype 2)
|-
|width="23%" |
07/03/18
| width="34%" |
Seance 7 : Test prototype filaire
|-
|width="23%" |
07/03/18-09/05/18
| width="34%" |
Réalisation 2eme prototype + application Android
|-
|width="23%" |
09/05/18
| width="34%" |
Seance 14 : Test prototype Bluetooth
|-
|width="23%" |
14/05/18
| width="34%" |
Video projet
|-
|width="23%" |
15/05/18
| width="34%" |
Finalisation projet et Rapport
|-
|width="23%" |
16/05/18-17/05/18
| width="34%" |
Soutenances Projet
|}

=Réalisation du Projet=

==Feuille d'heures ==

Voici le tableau d'heures du binôme:

{| 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 S11 !! Heures S12 !! Heures S13et+ !! Total
|-
| Analyse du projet
| 10
| 2
| 1
| 1
| 1
|
|
|
|
|
|
|
| 20min
|
| 15h20
|-
| Cherches techniques
|
| 3
| 4
| 4
| 2
| 2
| 1
|
|
|
| 1
| 1
|
|
| 18
|-
| Rédaction du wiki et rapport de projet
|
| 1
| 1
| 1
| 1
| 30min
| 1
|
| 2
| 30min
| 30min
|
| 2
|
| 10h30
|-
| Programmation
|
|
|
|
| 3
| 2
| 3
| 5
| 4
| 7
| 8
| 6
| 5
|
| 43
|-
| Cartes électroniques
|
|
|
|
|
| 6
| 8
| 4
| 6
| 2
| 1
| 2
| 2
|
| 31
|-
| Application
|
|
|
|
|
|
|
|
|
|
|
|
|-
|-
| Total Semaine
| 10
| 6
| 6
| 6
| 7
| 10h30
| 13
| 9
| 12
| 9h30
| 10h30
| 9
| 9h20
|
| '''117h50'''
|}

==Prologue==

Avant la réalisation et conception d'un projet, il est important d'analyser celui-ci. Nous avons allons consacré le prologue à l'analyse fonctionnelle de la manette. Nous avons également eu une réflexion sur l'analyse technique, cela nous a permis de réaliser une liste de matériel. Il est important de définir les objectifs ainsi que les besoins afin de ne rien oublier. (Voir ci-dessus Analyse projet)
Nous avons également organisé notre travail, pour le partage de documents de recherches et la rédaction de compte-rendu final nous avons réalisé un google drive. Par la suite, nous créerons un projet Git.

Durant ce temps, nous avons décidé de réaliser 5 modules. Les modules sont les différents boutons de la manettes qui nous pourrons placer selon nos choix (boutons modulaires) pour notre prototype projet pour chaque type des boutons d'une manette PS4. Ces modules devrons être connectés à la console et interconnectés. Le tout sera lié à une application Android. Suite à quelques recherches et nos analyses, nous avons décidé les points suivants :

- On commencera avec 2 modules et on les multipliera par la suite.
- Les premiers tests sont réalisés avec des boutons petits pour assurer leur caractéristique "modulaires", par la suite nous pourrons ajouter des capuchons de taille plus importante (imprimante 3D ou achat)
- Conception modules : réalisation de carte avec un microcontrôleur atmega328 programmable pour chaque module (anticiper le module Bluetooth)
- Projet en 2 parties : prototype filaire et prototype Bluetooth
# Prototype filaire : connexions entre les modules et la RPi3 en SPI, connexion Rpi3-PS4 en Bluetooth, avec l'application en filaire à la RPi3
# Prototype Bluetooth: connexion Bluetooth entre modules-RPi3-PS4-apllication

[[Fichier: structuremanette.png||center|400px|Concept manette modulable]]

==Semaine 1==

Durant la séance, nous nous sommes concentrés les recherches afin de définir clairement le cahier des charges technique. Il s'agit des réalisations à mettre en œuvre pour les inter-connexions des éléments de la manette.
Ainsi, nous avons fait des recherches sur :

===Connexion SPI entre les modules (Atmega328p) et la RPi3===

SPI: Serial périphérique interface BUS

[[Fichier: yWGmW.png||right|200px|Concept manette modulable]]
Comme indiqué sur l'image ci-dessus, la Raspberry pi 3 peut communiquer en SPI avec ses broches CS0 (24), CS1 (26), SCLK (23), MISO (21), MOSI (19). Celles-ci permettent de communiquer avec un ou plusieurs esclaves (dans notre cas, des Atmega328p) en reliant directement les broches concernées de la RPi3 à celles des composants esclaves.
Chaque broche CS0 (24) ou CS1 (26) ne peut être connectée qu'à l'entrée SS (aussi appelé CS) d'un seul esclave.
C'est a dire que chaque CS est lié à un esclave afin de choisir avec lequel la communication est établie à un moment donné, et les MISO sont reliées entre elles en cascade, de même pour les SCLK et les MOSI. On peut noter que le maître impose la fréquence d’horloge et sélectionne l’esclave auquel les données sont envoyées. 8 MHz est le plus rapide supportable a 3,3V

[[Fichier: fonctionnementSPI.png||right|200px|Connexion SPI multi-esclaves]]

Voici un schéma du fonctionnement souhaité :

Comme nous souhaitons avoir 5 modules environ il nous faudra rajouter un composant en plus afin d'augmenter les possibilités de sélection, par exemple des démultiplexeurs.
Dans un premier temps nous essaierons avec 2 esclaves, puis on augmentera le nombre.

===Connexion Bluetooth PS4-RPi3===

Les recherches portent également sur la connexion entre la manette PS4 et la console. Elles concernent le protocole de communication via Bluetooth

Caracteristique pour la PS4: Bluetooth®v4.0, Qualcomm Atheros AR3002 Buetooth LE: 2,4-2,5 GHz 

Caracteristique de la connexion : 

*Vitesse de transmission >> 3 Mbit/s 8N1
*Relevé tous les 1.3 millisecond (peut-être)
*Chaque manette à une adresse unique BD_ADDR qui correspond à l’adresse MAC de la carte Réseau
*Protocole de détection est le SDP basé sur une emission reception PDU
*L’Attribut ID est representer en TLV Type Length Value
*Communication HCI ACL Data Packet

===Rélisation des cartes électroniques===

matériel nécessaire pour un PCB : 

*breadboard
*câbles
*1 x 10k Ohm résistance
*Quartz 16Mhz clock crystal
*2 x 22 pF capaciteurs
*Atmega328P-PU

Ressources:
[[https://www.arduino.cc/en/Main/Standalone]]
[[http://www.eprojectszone.com/atmega-328-pu-standalone/]]
[[https://www.arduino.cc/en/Tutorial/ArduinoToBreadboard]]

==Semaine 2==

Durant la semaine deux et durant la séance, nous avons continué et approfondie nos recherches sur le projet. Nous avons pu ainsi affiner nos taches de réalisation et donc notre cahier des charges.

===Connexion aux modules: SPI et Bluetooth ===

 CORRIGER

voir https://peip-ima.plil.fr/mediawiki/index.php/BE_2017-2018#Configuration_du_syst.C3.A8me_embarqu.C3.A9

(sudo apt-get install pi-bluetooth)

''connexion sur la raspberry par ssh:''
su
update-rc.d ssh enable
invoke-rc.d ssh start
ssh pi@172.26.79.1XX

''bluetooth''
bluetoothctl
agent on
default-agent
scan on
pair [device Bluetooth address] (exemple: pair XX:XX:XX:XX:XX:XX )

''NOUVELLE REFLEXION : Connexion SPI entre les modules (Atmega328p) et la RPi3 --> MODULES BLUETOOTH''

Si multi-esclaves= plusieurs modules :
Il faut ajouter des sélections pour les SPI → démultiplexeurs OU ne pas utiliser les CS0 et CS1, et plutôt des pins entrée/sortie de la RPi3 lié au SS comme ça on choisit direct le module esclave voulu.

'''IMPORTANT:''' Nous avons étudié à nouveau la datasheet de notre module bluetooth nrf de Nordik. Le module bluetooth comporte déjà un microprocesseur !
Un module plutôt peut donc jouer le rôle de notre atmega328p. Il n'y a alors pas besoin de réaliser des cartes électroniques de type arduino standalone. Nos PCB regrouperont alors uniquement l'alimentation, un actionneur (bouton, joystick), le module bluetooth et les broches de connexion si besoin...

Cette séance nous a alors permise de revoir entièrement le matériel nécessaire. Notre liste de matériel nous semble alors plus réfléchie et limitée au nécessaire.

===Connexion Bluetooth PS4-RPi3===

Suite à nos recherches de la semaine précédente, nous avons sélectionné deux sites bien renseignés :

SITES

Ils nous ont permis de comprendre la communication entre la manette et la console. En effet, ils nous expliquent les échanges de trames Bluetooth.
EXPLICATIONS 1 exemple 

==Semaine 3 : Début premier prototype==

===Connexion SPI RPi3-Arduino===

Comme vu durant les semaines précédentes, nous souhaitons réaliser une connexion Multi-esclaves en SPI entre la Raspberry pi et plusieurs modules.
Cette semaine nous avons vu que la réalisation de notre premier prototype doit aller vite. Il ne nous est pas nécessaire d’attendre les modules bluetooth si il nous faut dans cette partie uniquement utiliser son microprocesseur. Ainsi pour chaque module nous utilisons une arduino UNO. Nous réaliserons les programmes en C afin de pouvoir les réutiliser avec les modules bluetooth par la suite.
Une fois la connexion réalisable nous adapterons les programmes aux modules bluetooth Nordik. En effet, ceux-ci comporte déjà un microprocesseur, le module peut jouer le rôle de notre atmega328p. Il n'y a aurait alors pas besoin de réaliser des cartes électroniques arduino standalone sur PCB, mais directement des cartes électronique avec le module et le module voulu (bouton, joystick...) et l'alimentation.
Durant la séance nous avons alors revu la liste de matériel nécessaire.

[[Fichier: prototype1.jpeg||center|600px|connexion filaire prototype 1 filaire arduino]]

Durant la séance, nous avons recherches des exemples de codes et de librairies pour Arduino SPI et RaspberryPI SPI.

Nous avons également commencé le programme de la connexion SPI pour l'arduino et récupéré les bibliothéques SPI.h avec SPI.c. Nous nous sommes alors concentrer à les comprendre, pour pouvoir l'utiliser.

===Réalisation du projet Git===

Création du projet IMA4_Projet35_ManetteModulable sur Git et partage de celui-ci.
Les premiers dossier crées cette la séance :
-Arduino (connexion SPI arduino) : ProtoSpi.c + dossier librairie SPI + Makefile
-RPI (dossier codes pour Rpi)
-Readme.md
Ces dossiers seront amenés à être modifiés au cours des séances.

===Protocole Bluetooth PS4===

Suite à l'étude des trames Bluetooth, on a pu voir que ces dernières étaient incomplètes. Le modèle de communication étant propriétaire, on n'y a pas accès directement. Cela nous empêche donc de mettre en oeuvre cette communication.
 Déveloper

On a décidé de commencer par une connexion USB (pour laquelle on dispose de toutes les informations) celle-ci étant plus complète.

==Semaine 4==

Pour le prototype 1 FILAIRE nous réaliserons les étapes suivantes :

#Réalisation du programme SPI pour arduino
#Réalisation du programme SPI pour la RPi
#Connexion USB avec la PS4 ou ordinateur
#Réalisation de cartes électroniques atmega328p-pu standalone (remplacer les Arduinos)
#Remplacer les "PCB arduino" par le module bluetooth et adapter la connexion
#Conception 3D de la délimitation 1 axe pour le joystick "gâchette"
#Réalisation de l'application Androïde.

Une fois ces étapes réalisées nous auront alors une preuve de concept filaire et nous pourrons alors passer à une connexion bluetooth.
Le passage à la connexion bluetooth sera le deuxième prototype et le cas idéal de la réalisation de la manette modulable.

===Mise à jour Matériel===

- Modéliser les boutons gâchettes L1/2 R1/2 de la manette PS4 (boutons sensibles à la pression) --> un joystick dont nous bloquerons un axe (imprimante 3D)
- Remplacer la RPi 3 par une Rpi zero W qui nous permettrait de réaliser plus facilement une connexion USB tout en gardant l'avantage du bluetooth.
- Choix de l’alimentation pour les 5 modules Bluetooth: nécessitent 3V --> utiliser des piles rechargeables 1,2V AAA plutôt que piles rondes 3V.

Nous avons également besoin du matériel cité en semaine 1 pour réaliser des cartes électroniques atmega328p-pu standalone. ( nous revenons alors sur les décisions de la semaine 3)

===Connexion SPI RPi3-Arduino===

Montage Raspberrypi et 1 arduino en PSI + 1 bouton + 1 led.
Voici le choix des branchements :

MASTER = RPi
SLAVE= Arduino

'''SPI sur Arduino:'''
MOSI -> GPIO11 //PB3 //master OUT to the slave IN
MISO -> GPIO12 //PB4 //slave OUT to the master IN
SCLK -> GPIO13 //PB5 //serial clock
SS -> GPIO10 //PB2 //slave select
'''Led, bouton et autre...'''
LED --> GPIO6 //PD6
GND
+5V (if required)
'''SPI sur la Raspberry Pi'''
SPIO MOSI -> PIN19
SPIO MISO -> PIN21
SCLK -> PIN23
SPIO CS0 -> PIN24

Continuation du code pour faire clignoter Led branchée à une arduino depuis la Rpi, en connexion SPI.

===Connexion USB PS4-RPi3===
Durant cette, nous avons regardé comment faire cohabiter bluetooth, Application Androïd, USB, PS4, SPI et les module.

Il est alors important de savoir comment utiliser le port série sur la RPi3, soit utiliser les UART.

Nous avons réaliser qu'il n'était pas aussi simple d'utiliser le port serie USB de la Raspberry Pi 3, en effet le SoC est un BCM2837 .
De plus nous ne pouvons pas utiliser le même port pour l'alimentation et la connexion.

Il nous faut alors trouver une alternative ou une solution à ce problème.

==Semaine 5==

===Programmation: Réflexion définitives prototypes filaire ===

La semaine dernière, nous avons rencontré une difficulté liée aux ports séries UART.
Une des solutions à cette difficulté serait d'utiliser une RPi ZERO W à défaut d'une RPi 3. On pourrait alors avoir un port d'alimentation avec connexion USB mais également retrouver la connexion Bluetooth dont nous avons besoin.

Ensuite, nous avons continué la réalisation du prototype filaire par l'avancé du code SPI ainsi que les recherches concernant le protocole PS4.

La Raspberry Pi zero W peut également être utile pour la connexion entre la PS4 et les différents modules en jouant le rôle d'intermédiaire. Nous avons alors commandé une Rpi zero W pour notre projet.
En attendant la réception de la commande, nous nous sommes penché sur les recherches pour les programmes et la configuration nécessaire à l'utilisation de la RPi zero W.

===Electronique===

[[Fichier: bouton_c1.jpg|100px|thumb|left|PCB bouton]]
[[Fichier: arduinobb.jpg|200px|thumb|right|atmega328p-pu branchement test]]

Du coté électronique, nous avons réalisé sur fritzing certaines cartes électroniques. Les Arduino Uno servant actuellement de test, seront remplacées par des PCB atmega328p-pu standalone avec des broches permettant les branchements nécessaires SPI ou encore aux modules "boutons/joystick". Pour les boutons, nous avons également réalisé un pcb afin de faciliter les branchements.

Il nous faut alors également une 3eme carte qui nous sera nécessaire pour la réalisation du prototype sans fil. Dans notre liste de matériel, nous avons des composants nrf52810 bluetooth, ceci doivent être soudé avec les capacités de protection mais également des broches de communication. Nous avons alors commencé cette carte électronique sur Altium avec le fichier projet PCB du distributeur à modifier.

[[Fichier: Arduino_c1.jpg|100px|thumb|center|PCB atmega328p-pu]]

=== Construction 3D ===

Enfin, nous avons commencé à réaliser des boîtiers 3D pour certains modules. Par exemple, comme nous l'avions vu précédemment, un des joysticks servira de bouton-gâchette en utilisant un seul de ses axes. Il nous faut alors réaliser un boitier qui bloque l'un des axes, mais également une tige qui nous permettra de pousser le joystick de manière simplifiée.

==Semaine 6==

===Programmation: configuration RPi Zero W ===

Ayant reçu la Raspberry Pi zero W en début de semaine, nous nous sommes concentrés sur la programmation et la configuration de celle-ci.
Cette partie étant compliquée, elle nous a pris du temps. En effet, il était difficile de connecter la RPi en SSH car il n'est pas possible d'y connecter un clavier directement et on avait besoin de la prise OTG pour "interfacer" la manette.

===Electronique: PCB nrf52810===

Les cartes réalisées en semaine 5 sont validées et en attente de réalisation.

Cette semaine a permis la réalisation et la finalisation de la carte électronique nrf52810. Il nous a fallu recommencé cette carte deux fois. En effet, une fois finie sur Altium nous avons réalisé que les empreintes des CMS sur PCB fourni par le constructeur ne correspondent pas au matériel CMS de l'école. Face à cette inattention de notre part, nous avons décidé de refaire entièrement la carte électronique sur fritzing. Ayant la datasheet et des plans d'inspiration PCB, nous avons pu refaire la carte entièrement.
Sur celle-ci nous avons ajouté des broches de connexion au besoin, un branchement Jtag et ICSP pour la programmation et la connexion SPI.
La carte est en attente de validation, puis validation.

[[Fichier: nrf52810_circuit2.jpg||center|400px|PCB carte nrf52810]]

===Révision matériel ===

Pour la réalisation de nos composants électroniques, il nous a fallu faire une révision des composants disponibles à l'école:
(les quantités indiquées ci-dessous pourront être augmentée si nécessaire,pour avoir dans l'idéal un module de chaque type de la manette, ici on se concentre sur BOUTON et JOYSTICK)

'''Cartes Arduino:'''
* 4 capacite 22pF traversantes
* 2 resistances 10 kOhm traversantes (à récupérer)
* 2 oscillateurs quartz 16MHz traversante
* 2 atmega328p-pu et support

'''Cartes nrf52810'''
* 6 capacités 100nF 0603
* 6 capacités 12pF 0603
* 2 capacités 4,7pF 0603
* 2 capacités 1µF 0603
* 2 capacités 100pF=0,1nF 0603 (à récupérer)
* 2 capacités 0,8pF 0603 (commande en cours)
* 2 inductance 3,9nH 0603 (commande en cours)
* 2 oscillateur quartz 32 MHz

'''Cartes modules Boutons'''
* un sachet de broches mâles (qu'on utilisera également pour les autres cartes, à récupérer/acheté)

Nous avons alors mis-à-jour la liste de composant située plus haut, ainsi que celle de la page IMA4 2017/2018 [https://projets-ima.plil.fr/mediawiki/index.php/Projets_IMA4_SC_%26_SA_2017/2018]

==Semaine 7==

===Programmation: connexion wifi RPi Zero W et Bootloader sur Atmega328p-pu ===

Pendant cette semaine, nous avons continué la programmation et la configuration des Raspberry Pi 3 et Zero W. Concernant la configuration ssh, nous avons utilisé un téléphone en guise de point d’accès à la RPi Zero W en wifi.
Nous avons aussi directement configurer l'OS Jessie, utilisé pour la RPi Zero. On a modifié le fichier cmd.txt et ...pour pouvoir programmer un USB gadget sur le port OTG.
Ci-dessus expliquer fichiers

Nous avons également continuer les programmes de récupération de données : état des boutons et du joystick. Ces programmes sont appliqué sur l'atmega328p-pu standalone sur la plaque d'essai en attendant que le PCB soit opérationnel.
Pour pouvoir programmer l'atemega328p-pu comme une arduino UNO, il nous faut suivre plusieurs étapes :

'''1.Flasher le Bootloader'''
Nous avons 2 Atmega328p-pu neufs, ainsi il nous faut flasher le bootloader sur chacun d'eux afin de pouvoir les utiliser et les programmer sur une breadboard dans un montage minimaliste arduino-standalone.
Pour cela, on peut utiliser une carte arduino UNO. On vérifie le port et le type de carte sélectionnés dans le menu >Outils. Sur cette carte on téléverse le fichier arduinoISP.ino qui se trouve dans les exemples en étant en progrmamateur AVr ISP mkll (>outils>programmateur)
Puis on met l'atmega328p-pu qui nous intéresse sur le suppor socket de la carte. On change de nouveau le programmateur pour Arduino as ISP et on fait >tools>burn bootloader, soit >graver la sequence d'initialisation.
Ces étapes faites, on peut retirer notre microcontroleur et le replacer correctement dans le montage.

'''2.Programmation atmega328 sur breadboard'''
Une fois l'atmega328p-pu préparé, on peut le programmer. On peut le faire simplement à l'aide de la carte arduino UNO utilisée précédemment.On branche les Tx et Rx en commun ainsi que le reset, le GND et le VCC.

Nous avons réaliser des codes basiques tels que le clignotement d'une led rouge ou encore l'affichage de "hello world" sur le moniteur série pour vérifier la bonne fonctionnalité du montage. Cela fait nous avons pu écrire sous Arduino IDE le code de lecture des états.

[[Fichier: montage_BB_test.jpg||left|200px|programmation modules arduino sur breadboard]]

===Electronique : soudure carte de test modules ===

Comme nous l'avons déja vu lors de la réalisation des PCB, si l'on souhaite programmer un atmega328p-pu en bootloader, le montage est simple. Il peut être minimaliste en utilisant une arduino UNO, un atmega328, une breadboard et 3 composants: 1 quartz 16MHZ crystal, 1 résistance 10kOhm et 2 capacitors céramiques de 22pF.
Durant la semaine 7, nous avons soudé les composants traversants de la carte électronique correspondant à ce montage ainsi que le PCB du bouton.

==Semaine 8==

===Programmation ===
Après moult recherche sur les différents site web bien fournis pour le coups on as pu trouvé une amorce à la programmation de l'OTG via un script qui agit au niveau du kernel dans le sous dossier usg_gadget. Ce script donne les informations nécessaires pour pouvoirs échangé les données.
Avec le script trouvé et les informations des sites web décryptant les trames de la manette, on a toujours pas réussit à faire passer notre RPi Zero W pour une manette de PS4. Néanmoins il nous manque la trame HID complète de la manette pour avoir un test effectif.

===Electronique : Correction soudure et soudure CMS===

Durant cette semaine, nous avions souhaité programmer la carte électronique atmega328p-pu. Cependant, nous avons réaliser que nous avions fait une erreur lors de l'envoie du PCB à la production. En effet, celui-ci avait été fait en Top sur le logiciel Fritzing et non en Bottom. Hors nous avions soudé les composants (durant la semaine 7) comme pour un circuit imprimé en bottom, l'atmega328p-pu se retrouve alors inversé par rapport aux pistes.
Comme solution, nous avons choisi de souder un deuxième support pour l'atmega328 de l'autre coté de la carte avant de la refaire au propre. En effet, avant de la refaire il nous faut vérifier si la carte est bien programmable.
Une fois cela fait nous avions pu programmer la carte mais, nous avions également réalisé la pin 2 de l'atmega328 était prise par le bouton poussoir. Or, nous avons besoin des pin 2 et 3 pour le RX et TX permettant la programmation de l'atmega à partir d'une arduino, les pistes branchement RX-TX n'ont également pas été prévus pour le téléversement des programmes sur la carte. Il nous faut alors couper une piste et souder des câbles pour utiliser toutes les pistes souhaitées.

[[Fichier: correction_proto_PCB.jpg||right|300px|PCB arduino correction]]

Durant cette semaine, nous avons également souhaité souder les CMS et le composant bluetooth nrf52810 sur la carte imprimé et reçu lors de la semaine 7. Pour cela, nous avons convenu de travailler dans la C202 durant la séance du mercredi.

[[Fichier: PCB_nrf52810.jpg||left|400px|carte electroniques imprimées]]

====Comment souder des CMS ?====

les CMS sont des composants montés en surface c'est à dire qu'ils sont montés du même côté que les pistes cuivrées (à l'opposé des composants traversants) et sont de petite tailles souvent de l'ordre du millimètre. La taille est déterminée par 4 chiffres : les 2 premiers pour la longueur et les 2 derniers pour la largeur. On a du 1206,0805,0603 ou encore 0402. Il est même possible de trouver plus petit. A l'école nous utilisons souvent du 0603, c'est le cas de nos composants.
Pour souder des CMS 0603, il nous faut utiliser une autre méthode qui n'est pas le fer à souder :
# Préparer la veille la pâte à braser la veille (dans une seringue)
# Gommer la carte pour éviter l'oxydation (attention à ne pas retirer les miettes de gomme en soufflant dessus)
# Appliquer avec la seringue la pâte sur les empreintes et piste souhaitées. Pour les endroits difficile à atteindre ou avec 2 pistes proches les unes des autres, il est possible de mettre la même goutte de pâte sur les 2 pistes. Cela de causera pas de court-circuit par la suite. En effet, la pâte est composée d’alliage qui sous la chaleur va se fluidifier et se coller uniquement aux pistes métallique. Le reste fondera sous la chaleur du four.
# Appliquer les CMS sur la pâte au fur et à mesure (attention ! ne jamais toucher les CMS avec les doigts, tjrs utiliser une pince)
# Mettre au four

====Bilan soudure nrf52810====

Cependant, une fois le matériel nécessaire préparé, et la pâte mise sur les pistes souhaitées, au moment de déposer le composant, nous avons réalisé que celui-ci était beaucoup plus petit que l'empreinte sur le PCB. Il s'agit d'un composant boitier QFN48. Fritzing ne proposant au plus proche des boitiers QFN24 ou LQFP48, celui-ci a basculé automatiquement pour un boitier LQFN48, de dimension plus grande. Face à ce manque de vigilance, nous avions cependant commencer par le nrf52810 (composant concerné) évitant ainsi de gaspiller d'autres CMS.
Nous avons souhaité refaire la carte sous Altium à partir des fichiers fournis par le concepteur (chose que nous avons commencé à faire aux alentours de la semaine 5)
Après la réalisation du schématic, et de la modification des empreintes de capacités, inductances et autres composants de 0402 à 0603. Notre matériel ne permettant que des empreintes 0603.

Lors du routage, une erreur de chevauchement des pistes est notifiée par Altium au niveau du nrf52810. Celles-ci ne présentent pas d'angles et sont déjà de taille 8mil, il nous faut alors passer les pistes en 6mil. Mais 8mil est la taille minimale pour la production à Polytech, nous avons regardé pour envoyer les cartes à faire ailleurs mais le 6mil n'est pas beaucoup conseillé. De plus, il n'est peut-être pas judicieux de continuer avec le composant microcontrôleur-bluetooth Nrf52810 qui prend du temps, donc la carte est difficilement réalisable et peut-être très long à programmer.

Ainsi en cette fin de semaine, nous avons décider face à l'avancer du projet de laisser les nrf52810 de coté et de les remplacer par des modules sans fils plus simples d'utilisation et complets. Ainsi nous aurions plus de chance d'avoir une connexion sans fils entre les modules. Nous pourrions par exemples utiliser des Xbee, des modules Rf...

==Semaine 9==

====Programmation: PS4 et 1er Test SPI sur atmega328p====

'''Raspberry Pi Zero W et PS4'''

Les premiers tests sur Windows ne nous donner pas satisfaction. En effet, l'ordinateur détectait bien le nouvel appareil avec son nom mais l'origine rester inconnue.

Lors des tests sur Linux on a pu voir des erreurs via la commande 'dmesg' :

[193229.758782] usb 4-1.2: new high-speed USB device number 6 using ehci-pci
[193230.270780] usb 4-1.2: new high-speed USB device number 7 using ehci-pci
[193235.510842] usb 4-1.2: device descriptor read/64, error -110
[193251.127043] usb 4-1.2: device descriptor read/64, error -110
[193251.315043] usb 4-1.2: new high-speed USB device number 8 using ehci-pci
[193256.503135] usb 4-1.2: device descriptor read/64, error -110
[193272.119331] usb 4-1.2: device descriptor read/64, error -110
[193272.307331] usb 4-1.2: new high-speed USB device number 9 using ehci-pci
[193282.999473] usb 4-1.2: device not accepting address 9, error -110
[193283.079485] usb 4-1.2: new high-speed USB device number 10 using ehci-pci
[193293.751588] usb 4-1.2: device not accepting address 10, error -110
[193293.751771] usb 4-1-port2: unable to enumerate USB device
[193387.196861] usb 4-1.2: new high-speed USB device number 11 using ehci-pci
[193392.440941] usb 4-1.2: device descriptor read/64, error -110
[193407.933152] usb 4-1.1: new high-speed USB device number 12 using ehci-pci
[193413.177227] usb 4-1.1: device descriptor read/64, error -110

'''Modules Atmega328p et SPI'''

Une carte PCB arduino fonctionnant, nous pouvons la programme pour simuler un module. Celle-ci a été designée afin de s'adapter au module que l'on souhaite. Il suffit de brancher le bouton, le joystick ou autre élèment de manette souhaité.
Cette semaine ci, nous avons alors configurer la partie communication SPI pour l'arduino.

'''Que voulons-nous faire avec les atmegas ?'''
Les cartes électroniques atmega328p vont nous permettre de recevoir les requêtes SPI envoyées par la raspberry pi et d'y répondre. La Raspberry enverra un message, par exemple "1", et l'Arduino lira alors l'état du module qui lui est connecté. Une fois l'état récupéré elle le renvoie à la raspberry pi.

Durant cette semaine, nous avons programmé l'atmega afin qu'il soit en esclave, qu'il reçoive un de la RPi "1" et retourne une valeur sauvegardé "int envoi". Nous avons également commencé les tests pour la lecture de l'état d'un bouton (d'après les tests réalisés les semaines précédentes).

'''Code'''
Comme nous l'avons vu précedement lors de nos recherches (semaines 1 à 4) :
La communication SPI nécessite l'utilisation des pins:

MOSI -> GPIO11 //PB3 //master OUT to the slave IN
MISO -> GPIO12 //PB4 //slave OUT to the master IN
SCLK -> GPIO13 //PB5 //serial clock
SS -> GPIO10 //PB2 //slave select

Il faut également paramétrer l'atmega328p en Slave. On note que dans un premier temps, le programme sera codé avec l'arduino IDE (fichiers .ino). Une fois l'ensemble SPI RaspberryPi-Arduino fonctionnant, on remplacera ces codes par du langage C ou C++.

Pour faire la connexion SPI sur l'atmega328p, on utilise la librairie arduino SPI.h, on a alors directement les fonctions nécessaires intervenant sur les registres souhaités : SPCR (spi control register), SPSR (spi status register) et SPDR (spi data register).

#include <SPI.h>

Il est important d'initialise d'abord le setup et on active le port série pour pourvoir utiliser le moniteur série. (Cela servira à verifier la valeur envoyée par la RPi)

void setup (void)
{
Serial.begin (9600);
pinMode(MISO, OUTPUT); //configuration en esclave *master in slave out*
pinMode(buttonPin,INPUT); //config pin bouton
// turn on SPI in slave mode
SPCR |= _BV(SPE);
// preparation interruptions
pos = 0; // buffer empty
process_it = false;
// activation interruptions
SPI.attachInterrupt();
}

On oublie pas de déclarer les interruptions afin de bien lire la requête reçue.

// SPI interrupt routine
ISR (SPI_STC_vect)
{
byte c = SPDR; // grab byte from SPI Data Register
// add to buffer if room
if (pos < sizeof buf)
{
buf [pos++] = c;
// example: newline means time to process buffer
if (c == '\n')
process_it = true;
} // end of room available
} // end of interrupt routine SPI_STC_vect

Dans la loop main, on traite la requête et on utilise '''SPI.transfer(envoi);''' pour transferer à la RPi les données souhaitées.

Durant cette semaine, nous avons également commencé des programmes de test SPI pour la RPi. Il s'agit principalement de programmes de tests tout faits permettant de vérifier la connexion entre cette dernière et l'arduino. Par exemple, la RPI envoie "bonjour" et l'arduino lui retourne ce qu'elle reçoit, soit "bonjour". Sans succés alors.

====Electronique : Fritzing révision====

Lors de la semaine, le modèle PCB de la carte arduino a été réalisé de nouveau sous fritzing avec les broches et connections manquantes. Nous avons également revu la configuration du bouton reset et ajouté une led d'état de l'alimentation. Nous avons ainsi envoyé deux cartes identiques à la réalisation.
La carte déjà soudée lors des derniers jours fonctionnant, elle nous sert de prototype de programmation. Nous pouvons ainsi avancer à la fois sur la programmation des modules mais aussi sur leur réalisation.

==Semaine 10==

====Programmation : PS4 et SPI sur RPi====

'''Raspberry Pi Zero W et PS4'''

Cette semaine, pour tester la prise OTG nous avons décider de lancer un script qui est habituellement utilisé. Nous avons choisi le script Serial Adapter qui est censé permettre de se connecter à la RPi Zero W en SSH via ce port.
Après quelque modifications et plusieurs petits bugs, nous avons réussir à faire fonctionner le ssh via le port OTG. Donc le problème était le même, notre script mélangé avec les informations sur la PS4 n'était toujours pas fonctionnel.

Pour faire la liaison entre les deux parties nous avons aussi commencé à programmer une application qui permet de configurer les modules au niveau de la RPi Zero W.

'''Modules Raspberry PI et SPI'''

Durant cette semaine, pour la partie Atmega328p-Modules, nous nous sommes concentrés sur la programmation de la communication SPI avec la raspberry pi. Cette semaine a permis une étude plus approfondit sur le fonctionnement pour la RPi.

On rappelle, comme vu des semaines 1 à 4, pour la RPI3 (tout comme la RPi Zero W) utilise les broches : SCLK (23), MISO(21), MOSI (19) et SPI CS0 (24), SPI CS1 (26).
On la programme en Master. A l'aide des fichiers tests d'inspiration, on pourra directement programmer la RPi en C. Lors de la réalisation du code, il y a 3 étapes : l'initialisation/parametrage en SPI pour être maître, l'envoie de la requête puis la réception de données en retour.

Programmant en C, il ne faut pas oublier les librairies suivantes :

#include <stdint.h>
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
#include <getopt.h>
#include <fcntl.h>
#include <sys/ioctl.h>
#include <linux/types.h>
#include <linux/spi/spidev.h> //pour SPI

On va déclarer des variables globales permettant le paramétrage :

static const char *device = "/dev/spidev0.0"; //si on veut CS0 pour atteindre notre SS
static uint8_t mode; //mode est par défaut à 0
static uint8_t bits = 8; //bits par mot échangé
static uint32_t speed = 500000;
static uint16_t delay;

Dans notre main, on ouvre le port (la connexion) au device souhaité, on vérifie les paramètres (registres, connexions...) puis exécute la fonction transfer(fd). transfer(fd) transmet la requête et s'occupe de la réception.

fd = open(device, O_RDWR);
transfer(fd);
close(fd);

==Semaine 11==

====Programmation: PS4, SSH et tests SPI (RPi3&Atemga328p)====

'''Raspberry Pi Zero W et PS4'''

'''Raspberry PI, Atmega328p et SPI'''

Afin de facilité la programmation en utilisant Ethernet, nous avons installer et configuré la RPi pour l'utiliser en SSH depuis les ordinateurs de la E306. En effet, SSH permet de se connecter à distance sur une machine en utilisant un compte utilisateur de la dite machine. En mettant ssh, on pourra directement agir sur les fichiers de la raspberry depuis un terminal de notre PC. Pour cela, on a d'abord vérifier l'adresse IP de notre raspberry pi : 172.26.145.106 avec un écran mais on peut aussi utiliser les commandes ip a et ifconfig. Puis activer le ssh sur la raspberry pi.
On modifie alors le fichier config.txt mais également etc/network/interfaces pour configurer la bonne interface Ethernet sur la raspberry pi.

[[Fichier: configSSH_raspi.png||left|300px|config ssh ethernet]]

Il nous suffit alors de taper la commande : ssh pi@172.26.145.106 pour accéder à notre RPi.

Nous avons continué à réaliser la communication SPI avec des tests entre une arduino UNO et la RPI3. Nous avons commencé par des tests simples inspirés des études de deux semaines précédentes et modulés selon notre utilité.
Nous arrivons alors à lire l'état envoyer "bonjour" et recevoir "ça va" ou encore "1" et recevoir "3". Il faut noter que le SPI échange des trames, la RPI reçoit alors des hexadécimaux.
Nous avons alors continué pour recevoir l'état du bouton ou du joystick lors de l'envoie de "1" sur l'Arduino328p. La semaine prochaine nous testerons ces même codes fonctionnels sur les cartes atmeg327p.

A la fin de cette semaine, nous avons alors des codes Arduino-SPI (.ino) et des codes Raspberry-SPI (.c) permettant l'échange de données. Le but est maintenant de l'adapter aux cartes imprimées et de le rendre pleinement fonctionnel pour plusieurs cartes à la fois, puis ajouter une boucle de vérification en continue jusqu'à une deuxième requête de la RPi.

====Electronique: réalisation au propres des PCB modules====

Suite à une nouvelle erreur de réalisation cartes électronique, nous avons refait et renvoyé à nouveau les cartes imprimées atmega328p.
Nous les souhaitons au propre pour une version finale. Une fois celle-ci imprimées nous pourrons en avoir 3 , un pour chaque module. Les cartes étaient bien imprimées en bottom mais lors du passage des traversants de bottom à top, le logiciel ne les a pas fait miroiter. Par manque d'attention nous avons alors envoyé les fichiers gerber pour des cartes ayant les composants du même coté que la couche de cuivre.
Les cartes électroniques actuelles sont alors correctes et fonctionnelles mais difficile à souder. Pour eviter les erreurs et continuer sur des prototypes de carte nous préférons attendre en nous concentrant sur la programmation PSI de la Raspberry Pi.

==Semaine 12==

====Programmation====

'''Raspberry Pi Zero W et PS4'''

'''Raspberry PI, Atmega328p et SPI'''

- réflexion: penser à faire boucler sur l'arduino une fois la requête reçu, ça veut dire que la manette est ON et donc vérifier continuellement les modules sur chaque atmega.
- SPI raspberry pi - arduino recuperation état du bouton avec les cartes modules (/!\ récuperation à faire dans une variable)

-SSH perso
adresse Rasppi: 192.168.137.10

====Electronique: Finalisation soudure Modules====

Soudure au propre et finale d'une carte atmega328p et donc envoie pour la réalisation de 2 autres cartes similaires et récupération de matériel
Soudure des 2 autres cartes, + tests sur les états = fonctionnelles.
On a donc bien 3 cartes pour les 3 modules de types différents (1 bouton, 1 joystick, 1 gachette)
PCB pour les 2 joysticks (qui serviront de thumbstick et gachette)

==Semaine 13 et plus==

====Programmation====

'''Raspberry Pi Zero W et PS4'''

'''Modules Atmega328p et SPI'''

====Electronique====

=Documents Rendus=

(à mettre rapport + git + drive)

=Datasheets=

IMA4 2017/2018 P35

2018-05-05T20:14:00Z

Tgracias : /* Programmation : PS4 et SPI sur RPi */

__TOC__
 

=Présentation générale: Manette modulable=

==Description==

Tout le monde joue aux jeux vidéo cependant, les manettes ne sont pas adaptées aux personnes ayant un handicap pouvant toucher les bras ou les mains.
C’est le cas, de plusieurs patients dans les centres de soins et de rééducation.

Pour ce projet IMA4, nous travaillerons avec le centre SSR (soin de suite et de réadaptation) Marc Sautelet de Villeneuve d’Ascq.
Un adolescent, patient de Marc Sautelet, est passionné par les jeux vidéo. En effet, ayant perdu la motricité d’une partie de son corps, il ne peut pas jouer à deux mains. Pour cela, il bloque la manette entre son épaule et son coude, usant de la mâchoire et des doigts pour contrôler les
joysticks et les boutons. Cet exercice peut s’avérer fatiguant et pénible.

Ainsi, nous chercherons à concevoir une manette PS4 adaptée au handicap de l’adolescent.
Cette manette devra aussi être adaptée pour d’autres patients présentant également des handicaps moteurs. Ainsi nous prendrons pour cibles: tous les patients du centre voulant jouer; et non pas que les enfants et adolescents.

 

{| class="wikitable centre" width="80%"
|+
|-
| width="23%" |
Membre du projet
| width="34%" |
Transley Gracias et Camille Saad
|-
| width="23%" |
Cible
| width="34%" |
Patient présentant un handicap moteur
|-
|width="23%" |
Période du projet
| width="34%" |
janvier 2018 - mai 2018
|-
|width="23%" |
Partenaire/Client
| width="34%" |
Centre SSR Marc Sautelet à Villeneuve d'Ascq
|}

==Objectifs==

Ce projet a pour objectif de créer un prototype de manette qui puisse interagir avec la console PS4 et dont le paramétrage se fait à l’aide d’une application mobile et/ou web. Cette manette devra suivre les demandes du patient ainsi que des aides-soignantes du centre, dans la mesure du possible.

Plus précisément, pour le premier prototype, nous mettrons en œuvre l'utilisation de quelques boutons spécifiques:

* Un joystick (type L/R)
* Quelques boutons poussoirs (type Croix/Triangle/Carré/Rond/R1/L1/Start/...)
* Des boutons gâchettes progressives (type L2/R2).

Le but serait donc dans un premier temps de rendre fonctionnel un bouton de chaque type, puis de les multiplier une fois cela fait. Tous ces boutons réunis constituent une manette fonctionnelle.Ainsi, la manette sera ajustable, c’est à dire qu’elle devra s’adapter aux différents handicaps moteurs possibles.

=Analyse du projet=

==Positionnement par rapport à l'existant==

Notre prototype aura une présentation unique par rapport à l’existant. En effet, les concurrents et produits existants ciblent pour la majorité un seul handicap. Cela
engendre une solution fermée à beaucoup de patients. Notre projet propose une mobilité des mouvements et également un choix large dans la composition et le
design de notre manette.
Le patient n’est pas retreint à jouer à une seule main, à utiliser beaucoup de force...Il y a moins de technique dans la manipulation et on ne joue pas avec une
manette adaptée uniquement pour un droitier ou un gaucher. Cependant, cela nous limitera peut-être dans le choix possible des types de jeux. Tout comme les autres
manettes adapté, l’utilisateur nécessitera un peu d’entrainement.

==Analyse du premier concurrent==

Jouer aux jeux vidéo à une main n’est pas une idée d’aujourd’hui. En 1990, Nintendo propose le Power Glove. Mais il tombe très rapidement aux oubliettes suite à des problèmes techniques.

Un autre gant a fait son apparition quelques années plus tard. Celui-ci, plus technique, il faut office de manette Play Station: le Reality Quest Power Glove.Cette idée de manette-gant, permet de jouer à la PS avec une seule main, elle a était conçue et présentée pour les E3, un salon d’exposition de gaming.Le gant est conçu pour contrôler l’équivalent des 14 boutons et 2 joysticks à l’aide d’une seule main. La « manette » est fixée dans la pomme de la main. L’utilisateur contrôle les mouvements verticaux et horizontaux en pivotant le poignet, et utilisent les 4 boutons d’action principaux et L1/R1 avec les doigts. Les autres boutons sont accessibles par un seul bouton rond contrôlé par le pouce.
La manette est adaptée pour beaucoup de jeux vidéo, dont les plus simples sont les jeux de voitures et de combats (arcade).

; Problèmes:
*Besoin de toute la motricité de la main, c’est-à-dire que si le patient à un doigt paralysé ou manquant, il ne pourra pas jouer avec ce gant
*Design obligatoirement droitier
*Les boutons de contrôle sont peu sensibles et peuvent nécessiter de la force
*Design compliqué et nécessitant beaucoup d’entrainement.

;Lien : https://www.youtube.com/watch?v=qV0SxSJDCYg

 
==Analyse du second concurrent==

Ben Heck, de son vrai nom Benjamin J.Heckendorn, est un concepteur de mods de consoles (mods pour modification, soit « manettes modifiées ») et une star
du net grâce à ses vidéos tutoriels.Il propose alors énormément de produits adaptés ou dérivés en guise de manettes.
Parmi les mods qu’il a réalisé, il a modifié une manette de PS4 afin de la rendre accessible à une personne ne pouvant jouer qu’à une main. Pour cela, il a déplacé les boutons en respectant l’ergonomie de la main valide et modifie les connexions. Il peut lui arriver de rajouter des boutons pour en remplacer un autre. Il réalise également le même système avec la Xbox. Sur la photo ci-dessous, il a adapté la manette pour un droitier.

; Problèmes:
*Besoin de toute la motricité de la main, c’est-à-dire que si le patient à un doigt paralysé ou manquant, il ne pourra pas jouer avec cette ma
*Design obligatoirement droitier ou gaucher, une modification = une manette= une personne
*Besoin obligé du pouce et de l’index, même si avantage : 3 doigts nécessaire.

;Lien :: https://www.youtube.com/watch?v=LieHIscadjk

==Scénario d'usage du produit ou du concept envisagé==

La technologie est ,aujourd’hui, omniprésente dans notre vie. Les consoles de jeux ont envahies les maisons avec plus de 7 personnes sur 10 jouant aux jeux vidéos sur consoles en France (chiffre de l’Express). 0,18% des français sont handicapés cela représente 12 millions de français. Dans ce chiffre, 13,4% des personnes ont un handicap moteur. En 2017, les grands groupes comme Sony ou Microsoft avec respectivement PlayStation et Xbox ne permettent pas à tout le monde de jouer avec une manette. Les manettes sont prévues pour des personnes ayant leurs membres valides, plus précisément les mains et les bras.

Après un accident de voiture, un jeune garçon a perdu la motricité d’un côté du corps. Passionné de jeux vidéo, il se retrouve avec des difficultés à jouer sur sa console PS4. Ingénieux, il utilise la manette en la coinçant entre son épaule et le creux du cou. Usant de la mâchoire et de sa main valide pour contrôler les joysticks et les boutons. L'exercice étant inconfortable et fatiguant il eu l’idée de proposer à des futurs ingénieurs de lui proposer une manette adaptée à son handicap.

Les deux pré-ingénieurs ,avec leur tuteur, ont une idée révolutionnaire : La manette modulable ! Elle permettrait au jeune garçon, ainsi que d’autres joueurs, de pouvoir continuer de s’amuser ou même de commencer à jouer au jeux sur console.
Cette manette aidera fortement dans les centre de rééducation pour faire passer le temps et donner du plaisir à des personnes qui ne peuvent plus s’amuser avec leur console traditionnelle. Elle pourra aussi ouvrir de nouvelles possibilités pour certaines personnes qui n’auraient jamais essayé jusqu'à présent.
Comme son nom l'indique, elle sera modulaire et s'adaptera à différents handicaps. Accompagnée de son application d’initialisation, elle sera accessible aussi bien aux enfants, patients, parents et aides soignantes.

Quelques mois plus tard...Le jeune patient fan de Need For Speed, peut maintenant piloter sa voiture comme un vrai professionnel grâce à l'un des joysticks qu'il utilisera avec sa main valide et il pourra accélérer à des vitesses folles à l'aide de boutons poussoirs au niveau de son pied valide et gagner la partie. Son ami venu lui rendre visite, pourra en lieu et place des aides soignantes configurer à l'aide de la tablette (portable) la manette du patient.
Si le patient change de jeu pour Tekken et que la configuration des modules ne lui convient plus, il peut interchanger les éléments de la manette selon son envie et son confort. Ainsi il peut faire sauter son personnage, il utilisera un module bouton supplémentaire, qu'il actionnera avec le poing.

==Fonctionnement==

Suite à une analyse fonctionnelle et à la formulation de notre projet, nous avons pu définir le fonctionnement de notre système. Notre produit, la manette, doit être accessible d’après nos objectifs à différents types de handicaps moteurs. Ainsi, l’idéal serait de concevoir une manette modulable afin qu’elle puisse s’adapter à toutes les situations. Ce n’est plus au patient de s’adapter à la manette mais à la manette de s’adapter au patient.
Cela signifie que la manette sera, dans la limite du possible et de la sensibilité du corps du patient, composée de plusieurs parties dites « modules » comportant un ou plusieurs actionneurs (boutons, joysticks, gâchettes...). Ces modules seront déplaçables afin d’être utilisé avec différents membres du corps : un doigt, une main,
une jambe ou même un pied. Il suffira de les connectés entre eux suivant l’organisation souhaitée, le Gameplay du jeu ou en fonction du handicap. Le tout sera relié à une application.
L’application sera alors mise en place pour connecter les différentes parties du point de vue software pour prérégler la manette en fonction du patient. Il pourra alors choisir les boutons en fonction du jeu, de ses mouvements mais aussi choisir la sensibilité.

L’application et les modules devront être intuitifs et faciles d’utilisation. De cette manière des utilisateurs non avertis dans le domaine informatique ou jeunes pourront eux-mêmes gérer les connexions.

==Réponse à la question difficile==

'''Question : Comment interconnecter les différents modules de la manette ?'''

Il nous faut pour ce projet interconnecter les modules modélisant la manette qui seront connectés à la consoles PS4 via une Raspberry Pi 3.
Le choix de la Raspberry Pi 3 nous permet d'utiliser son module Bluetooth pour communiquer avec la PS4, ce choix est plus adaptée au projet que du filaire.
Concernant l'interconnexion des modules, nous travaillerons en deux étapes "preuves concept" : filaire et sans fils (Bluetooth).

'''Objectif 1 : Preuve concept filaire'''

Dans cette première partie de projet, nous souhaitons avoir une 1ère preuve de prototype rapidement. Nous nous concentrerons alors sur la communication entre la RPi3 et la PS4 ainsi que sur la conception des modules. Pour les modules, nous réaliserons des cartes électronique pour chaque module avec un micro-contrôleur. La communication filaire nous permettra d'interconnecter les modules à la RPi3 avec un bus SPI.

'''Objectif 2: preuve concept sans fils'''

Une deuxième étape du projet est la réalisation de la solution idéale sans fils. Celle-ci pourra commencer à être développée petit à petit en parallèle avec l'objectif 1. Le but ici, est d'interconnecter les modules en Bluetooth. Nous avons choisi le Bluetooth pour garder une connexion commune sur toute la chaîne.
Nous rajouterons alors un module bluetooth à chaque module de la manette.

'''Objectif 3: possibilité d'adapter les boutons (capuchon en 3D)'''

=Préparation du projet=

==Cahier des charges==

''Chef de projet:'' Alexandre Boé 
''Responsables:'' Xavier Redon, Thomas Vantroys 
''Partenariat:'' Marc Sautelet (non etablie) 
''Elèves-ingénieurs:'' Camille Saâd, Transley Gracias 

'''Sujet :''' Manette modulable pour personne à déficience moteur compatible PlayStation 4 

===Objectifs principal (1er POC) : ===
Faire transmettre des informations issus des actionneurs (ex:boutons poussoires) via des arduinos jusqu’à la Raspberry Pi 3 en SPI. 
Envoyer les données reçues vers la PS4 en USB 

===Objectifs secondaire (2e POC):===
Créer des modules avec un microcontrôleur et une puce bluetooth pour permettre une meilleurs flexibilité (c-àd pouvoirs avoir une meilleure ergonomie et une connexion sans fil) 
Connecter la Raspberry Pi 3 en Bluetooth à la PS4 

[[Fichier: beteacorne.jpg||middle|600px|Bete a corne manette]]

==Choix techniques : matériel et logiciel==

===Liste de matériel :===

'''Modules boutons/joysticks/gachettes'''

3 Push buttons : 
- O X Y Carré R3 L3 
- Guide PS 
- start/back 
--> 0,45€/unité TTC [https://www.gotronic.fr/art-bp-miniature-krs1273-16976.htm] 

1 Thumbstick original: 
Joystick analogique 4 directions --> 4,25€/unité TTC [https://www.gotronic.fr/art-joystick-analogique-4-directions-19063.htm] 

1 buttons trigger L1 L2 => 1x Thumbstick original''' 

'''Cartes Atmega328p /connexion spi/'''

3 Arduino UNO 
1 Arduino UNO atmega328p retirable 
4 capacite 22pF traversantes 
2 resistances 10 kOhm traversantes (à récupérer) 
2 oscillateurs quartz 16MHz traversante 
2 atmega328p-pu et support 

'''Cartes module bluetooth nrf52810 '''

6 capacités 100nF 0603 
6 capacités 12pF 0603 
2 capacités 4,7pF 0603 
2 capacités 1µF 0603 
2 capacités 100pF=0,1nF 0603 (à récupérer) 
2 capacités 0,8pF 0603 (a acheter, commande en cours) 
2 inductance 3,9nH 0603 (a acheter, commande en cours) 
2 oscillateur quartz 32 MHz 

''' Connexions et autres '''

1 Led RGB neopixel [https://www.adafruit.com/product/1734] 
1 Raspberry Pi 3 
--> ~36,23€/unité TTC [https://fr.rs-online.com/web/p/processor-microcontroller-development-kits/8968660/?src=raspberrypi] 
1 Raspberry Pi Zero W (commandée) [https://www.raspberrypi.org/products/raspberry-pi-zero-w/] 
6 Alimentations 5V ou 3,3V 
par exemple, 12 piles de type CR2016 3V rechargeables ou 24 piles AAA 1,5 V rechargeables
5 modules Bluetooth nrf de Nordic : nRF52810-QFAA-R 
--> 3,17€/unité + frais expédition [https://www.mouser.fr/productdetail/nordic-semiconductor/nrf52810-qfaa-r?qs=sGAEpiMZZMve4%2FbfQkoj%252bG%2FosjLoe2oghFQwQllMrQ4%3D]
5 Lignes broches mâles 

===Logiciels:===

- IDE arduino
- Altium
- FreeCAD ou Inkscape

==Liste des tâches à effectuer==

'''Etape 1 : Gestion du projet'''

* Définition des cahiers des charges fonctionnel et technique, choix d'orientation...
* Recherche techniques sur les différentes connexions possibles entre les modules, la RPi 3 et la console PS4
#Recherche connexion SPI entre les modules et la RPi3
# Recherche connexion bluetooth entre la RPi3 et la PS4
# Recherche connexion bluetooth pour les modules
# Recherche carte avec montage Atmega328P-PU et anticipation module bluetooth
* Détermination du matériel nécessaire
* Réflexion sur l'application

'''Etape 2: Réalisation du projet'''

'''Partie 1: Preuve concept manette en filaire'''

* Conception de cartes électroniques pour 2 modules (/!\ prévoir modules bluetooth)
* Réalisation connexion SPI avec 2 modules : programmation des Atmega328p en liaison série.
* Si tests concluant, ajouter des modules jusqu'à en avoir 5 (1 pour chaque type de boutons)
* Connexion bluetooth entre la PS4 et la RPi3
* Réalisation du support des modules avec fixations possibles (imprimante 3D)

'''Partie 2: Preuve concept manette en bluetooth'''

* Ajout des modules bluetooth aux cartes électroniques
* Connexion bluetooth entre les modules

'''Partie 3: Application Android : paramétrage de la manette'''

* Créer une application sur tablette ou smartphone (Android) afin de configurer la manette aux besoins (inter-connexion des modules et console)

==Calendrier prévisionnel==

{| class="wikitable centre" width="80%"
|+
|-
| width="23%" |
'''Date'''
| width="34%" |
'''Tache à réaliser''' 
|-
| width="23%" |
17/01/18-24/01/18
| width="34%" |
Faire des recherches sur les différentes interconnexions du système : Bluetooth, RPi-Atmega328 (SPI), RPi-PS4
Continuer liste des taches, matériel, Début recherches + réflexion fixation support des modules
|-
|width="23%" |
31/01/18
| width="34%" |
Recherche technique connexion PS4-RPi3 et connexion SPI RPi3-Module + code
|-
|width="23%" |
31/01/18-07/03/18
| width="34%" |
Réalisation 1er prototype (+ début prototype 2)
|-
|width="23%" |
07/03/18
| width="34%" |
Seance 7 : Test prototype filaire
|-
|width="23%" |
07/03/18-09/05/18
| width="34%" |
Réalisation 2eme prototype + application Android
|-
|width="23%" |
09/05/18
| width="34%" |
Seance 14 : Test prototype Bluetooth
|-
|width="23%" |
14/05/18
| width="34%" |
Video projet
|-
|width="23%" |
15/05/18
| width="34%" |
Finalisation projet et Rapport
|-
|width="23%" |
16/05/18-17/05/18
| width="34%" |
Soutenances Projet
|}

=Réalisation du Projet=

==Feuille d'heures ==

Voici le tableau d'heures du binôme:

{| 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 S11 !! Heures S12 !! Heures S13et+ !! Total
|-
| Analyse du projet
| 10
| 2
| 1
| 1
| 1
|
|
|
|
|
|
|
| 20min
|
| 15h20
|-
| Cherches techniques
|
| 3
| 4
| 4
| 2
| 2
| 1
|
|
|
| 1
| 1
|
|
| 18
|-
| Rédaction du wiki et rapport de projet
|
| 1
| 1
| 1
| 1
| 30min
| 1
|
| 2
| 30min
| 30min
|
| 2
|
| 10h30
|-
| Programmation
|
|
|
|
| 3
| 2
| 3
| 5
| 4
| 7
| 8
| 6
| 5
|
| 43
|-
| Cartes électroniques
|
|
|
|
|
| 6
| 8
| 4
| 6
| 2
| 1
| 2
| 2
|
| 31
|-
| Application
|
|
|
|
|
|
|
|
|
|
|
|
|-
|-
| Total Semaine
| 10
| 6
| 6
| 6
| 7
| 10h30
| 13
| 9
| 12
| 9h30
| 10h30
| 9
| 9h20
|
| '''117h50'''
|}

==Prologue==

Avant la réalisation et conception d'un projet, il est important d'analyser celui-ci. Nous avons allons consacré le prologue à l'analyse fonctionnelle de la manette. Nous avons également eu une réflexion sur l'analyse technique, cela nous a permis de réaliser une liste de matériel. Il est important de définir les objectifs ainsi que les besoins afin de ne rien oublier. (Voir ci-dessus Analyse projet)
Nous avons également organisé notre travail, pour le partage de documents de recherches et la rédaction de compte-rendu final nous avons réalisé un google drive. Par la suite, nous créerons un projet Git.

Durant ce temps, nous avons décidé de réaliser 5 modules. Les modules sont les différents boutons de la manettes qui nous pourrons placer selon nos choix (boutons modulaires) pour notre prototype projet pour chaque type des boutons d'une manette PS4. Ces modules devrons être connectés à la console et interconnectés. Le tout sera lié à une application Android. Suite à quelques recherches et nos analyses, nous avons décidé les points suivants :

- On commencera avec 2 modules et on les multipliera par la suite.
- Les premiers tests sont réalisés avec des boutons petits pour assurer leur caractéristique "modulaires", par la suite nous pourrons ajouter des capuchons de taille plus importante (imprimante 3D ou achat)
- Conception modules : réalisation de carte avec un microcontrôleur atmega328 programmable pour chaque module (anticiper le module Bluetooth)
- Projet en 2 parties : prototype filaire et prototype Bluetooth
# Prototype filaire : connexions entre les modules et la RPi3 en SPI, connexion Rpi3-PS4 en Bluetooth, avec l'application en filaire à la RPi3
# Prototype Bluetooth: connexion Bluetooth entre modules-RPi3-PS4-apllication

[[Fichier: structuremanette.png||center|400px|Concept manette modulable]]

==Semaine 1==

Durant la séance, nous nous sommes concentrés les recherches afin de définir clairement le cahier des charges technique. Il s'agit des réalisations à mettre en œuvre pour les inter-connexions des éléments de la manette.
Ainsi, nous avons fait des recherches sur :

===Connexion SPI entre les modules (Atmega328p) et la RPi3===

SPI: Serial périphérique interface BUS

[[Fichier: yWGmW.png||right|200px|Concept manette modulable]]
Comme indiqué sur l'image ci-dessus, la Raspberry pi 3 peut communiquer en SPI avec ses broches CS0 (24), CS1 (26), SCLK (23), MISO (21), MOSI (19). Celles-ci permettent de communiquer avec un ou plusieurs esclaves (dans notre cas, des Atmega328p) en reliant directement les broches concernées de la RPi3 à celles des composants esclaves.
Chaque broche CS0 (24) ou CS1 (26) ne peut être connectée qu'à l'entrée SS (aussi appelé CS) d'un seul esclave.
C'est a dire que chaque CS est lié à un esclave afin de choisir avec lequel la communication est établie à un moment donné, et les MISO sont reliées entre elles en cascade, de même pour les SCLK et les MOSI. On peut noter que le maître impose la fréquence d’horloge et sélectionne l’esclave auquel les données sont envoyées. 8 MHz est le plus rapide supportable a 3,3V

[[Fichier: fonctionnementSPI.png||right|200px|Connexion SPI multi-esclaves]]

Voici un schéma du fonctionnement souhaité :

Comme nous souhaitons avoir 5 modules environ il nous faudra rajouter un composant en plus afin d'augmenter les possibilités de sélection, par exemple des démultiplexeurs.
Dans un premier temps nous essaierons avec 2 esclaves, puis on augmentera le nombre.

===Connexion Bluetooth PS4-RPi3===

Les recherches portent également sur la connexion entre la manette PS4 et la console. Elles concernent le protocole de communication via Bluetooth

Caracteristique pour la PS4: Bluetooth®v4.0, Qualcomm Atheros AR3002 Buetooth LE: 2,4-2,5 GHz 

Caracteristique de la connexion : 

*Vitesse de transmission >> 3 Mbit/s 8N1
*Relevé tous les 1.3 millisecond (peut-être)
*Chaque manette à une adresse unique BD_ADDR qui correspond à l’adresse MAC de la carte Réseau
*Protocole de détection est le SDP basé sur une emission reception PDU
*L’Attribut ID est representer en TLV Type Length Value
*Communication HCI ACL Data Packet

===Rélisation des cartes électroniques===

matériel nécessaire pour un PCB : 

*breadboard
*câbles
*1 x 10k Ohm résistance
*Quartz 16Mhz clock crystal
*2 x 22 pF capaciteurs
*Atmega328P-PU

Ressources:
[[https://www.arduino.cc/en/Main/Standalone]]
[[http://www.eprojectszone.com/atmega-328-pu-standalone/]]
[[https://www.arduino.cc/en/Tutorial/ArduinoToBreadboard]]

==Semaine 2==

Durant la semaine deux et durant la séance, nous avons continué et approfondie nos recherches sur le projet. Nous avons pu ainsi affiner nos taches de réalisation et donc notre cahier des charges.

===Connexion aux modules: SPI et Bluetooth ===

 CORRIGER

voir https://peip-ima.plil.fr/mediawiki/index.php/BE_2017-2018#Configuration_du_syst.C3.A8me_embarqu.C3.A9

(sudo apt-get install pi-bluetooth)

''connexion sur la raspberry par ssh:''
su
update-rc.d ssh enable
invoke-rc.d ssh start
ssh pi@172.26.79.1XX

''bluetooth''
bluetoothctl
agent on
default-agent
scan on
pair [device Bluetooth address] (exemple: pair XX:XX:XX:XX:XX:XX )

''NOUVELLE REFLEXION : Connexion SPI entre les modules (Atmega328p) et la RPi3 --> MODULES BLUETOOTH''

Si multi-esclaves= plusieurs modules :
Il faut ajouter des sélections pour les SPI → démultiplexeurs OU ne pas utiliser les CS0 et CS1, et plutôt des pins entrée/sortie de la RPi3 lié au SS comme ça on choisit direct le module esclave voulu.

'''IMPORTANT:''' Nous avons étudié à nouveau la datasheet de notre module bluetooth nrf de Nordik. Le module bluetooth comporte déjà un microprocesseur !
Un module plutôt peut donc jouer le rôle de notre atmega328p. Il n'y a alors pas besoin de réaliser des cartes électroniques de type arduino standalone. Nos PCB regrouperont alors uniquement l'alimentation, un actionneur (bouton, joystick), le module bluetooth et les broches de connexion si besoin...

Cette séance nous a alors permise de revoir entièrement le matériel nécessaire. Notre liste de matériel nous semble alors plus réfléchie et limitée au nécessaire.

===Connexion Bluetooth PS4-RPi3===

Suite à nos recherches de la semaine précédente, nous avons sélectionné deux sites bien renseignés :

SITES

Ils nous ont permis de comprendre la communication entre la manette et la console. En effet, ils nous expliquent les échanges de trames Bluetooth.
EXPLICATIONS 1 exemple 

==Semaine 3 : Début premier prototype==

===Connexion SPI RPi3-Arduino===

Comme vu durant les semaines précédentes, nous souhaitons réaliser une connexion Multi-esclaves en SPI entre la Raspberry pi et plusieurs modules.
Cette semaine nous avons vu que la réalisation de notre premier prototype doit aller vite. Il ne nous est pas nécessaire d’attendre les modules bluetooth si il nous faut dans cette partie uniquement utiliser son microprocesseur. Ainsi pour chaque module nous utilisons une arduino UNO. Nous réaliserons les programmes en C afin de pouvoir les réutiliser avec les modules bluetooth par la suite.
Une fois la connexion réalisable nous adapterons les programmes aux modules bluetooth Nordik. En effet, ceux-ci comporte déjà un microprocesseur, le module peut jouer le rôle de notre atmega328p. Il n'y a aurait alors pas besoin de réaliser des cartes électroniques arduino standalone sur PCB, mais directement des cartes électronique avec le module et le module voulu (bouton, joystick...) et l'alimentation.
Durant la séance nous avons alors revu la liste de matériel nécessaire.

[[Fichier: prototype1.jpeg||center|600px|connexion filaire prototype 1 filaire arduino]]

Durant la séance, nous avons recherches des exemples de codes et de librairies pour Arduino SPI et RaspberryPI SPI.

Nous avons également commencé le programme de la connexion SPI pour l'arduino et récupéré les bibliothéques SPI.h avec SPI.c. Nous nous sommes alors concentrer à les comprendre, pour pouvoir l'utiliser.

===Réalisation du projet Git===

Création du projet IMA4_Projet35_ManetteModulable sur Git et partage de celui-ci.
Les premiers dossier crées cette la séance :
-Arduino (connexion SPI arduino) : ProtoSpi.c + dossier librairie SPI + Makefile
-RPI (dossier codes pour Rpi)
-Readme.md
Ces dossiers seront amenés à être modifiés au cours des séances.

===Protocole Bluetooth PS4===

Suite à l'étude des trames Bluetooth, on a pu voir que ces dernières étaient incomplètes. Le modèle de communication étant propriétaire, on n'y a pas accès directement. Cela nous empêche donc de mettre en oeuvre cette communication.
 Déveloper

On a décidé de commencer par une connexion USB (pour laquelle on dispose de toutes les informations) celle-ci étant plus complète.

==Semaine 4==

Pour le prototype 1 FILAIRE nous réaliserons les étapes suivantes :

#Réalisation du programme SPI pour arduino
#Réalisation du programme SPI pour la RPi
#Connexion USB avec la PS4 ou ordinateur
#Réalisation de cartes électroniques atmega328p-pu standalone (remplacer les Arduinos)
#Remplacer les "PCB arduino" par le module bluetooth et adapter la connexion
#Conception 3D de la délimitation 1 axe pour le joystick "gâchette"
#Réalisation de l'application Androïde.

Une fois ces étapes réalisées nous auront alors une preuve de concept filaire et nous pourrons alors passer à une connexion bluetooth.
Le passage à la connexion bluetooth sera le deuxième prototype et le cas idéal de la réalisation de la manette modulable.

===Mise à jour Matériel===

- Modéliser les boutons gâchettes L1/2 R1/2 de la manette PS4 (boutons sensibles à la pression) --> un joystick dont nous bloquerons un axe (imprimante 3D)
- Remplacer la RPi 3 par une Rpi zero W qui nous permettrait de réaliser plus facilement une connexion USB tout en gardant l'avantage du bluetooth.
- Choix de l’alimentation pour les 5 modules Bluetooth: nécessitent 3V --> utiliser des piles rechargeables 1,2V AAA plutôt que piles rondes 3V.

Nous avons également besoin du matériel cité en semaine 1 pour réaliser des cartes électroniques atmega328p-pu standalone. ( nous revenons alors sur les décisions de la semaine 3)

===Connexion SPI RPi3-Arduino===

Montage Raspberrypi et 1 arduino en PSI + 1 bouton + 1 led.
Voici le choix des branchements :

MASTER = RPi
SLAVE= Arduino

'''SPI sur Arduino:'''
MOSI -> GPIO11 //PB3 //master OUT to the slave IN
MISO -> GPIO12 //PB4 //slave OUT to the master IN
SCLK -> GPIO13 //PB5 //serial clock
SS -> GPIO10 //PB2 //slave select
'''Led, bouton et autre...'''
LED --> GPIO6 //PD6
GND
+5V (if required)
'''SPI sur la Raspberry Pi'''
SPIO MOSI -> PIN19
SPIO MISO -> PIN21
SCLK -> PIN23
SPIO CS0 -> PIN24

Continuation du code pour faire clignoter Led branchée à une arduino depuis la Rpi, en connexion SPI.

===Connexion USB PS4-RPi3===
Durant cette, nous avons regardé comment faire cohabiter bluetooth, Application Androïd, USB, PS4, SPI et les module.

Il est alors important de savoir comment utiliser le port série sur la RPi3, soit utiliser les UART.

Nous avons réaliser qu'il n'était pas aussi simple d'utiliser le port serie USB de la Raspberry Pi 3, en effet le SoC est un BCM2837 .
De plus nous ne pouvons pas utiliser le même port pour l'alimentation et la connexion.

Il nous faut alors trouver une alternative ou une solution à ce problème.

==Semaine 5==

===Programmation: Réflexion définitives prototypes filaire ===

La semaine dernière, nous avons rencontré une difficulté liée aux ports séries UART.
Une des solutions à cette difficulté serait d'utiliser une RPi ZERO W à défaut d'une RPi 3. On pourrait alors avoir un port d'alimentation avec connexion USB mais également retrouver la connexion Bluetooth dont nous avons besoin.

Ensuite, nous avons continué la réalisation du prototype filaire par l'avancé du code SPI ainsi que les recherches concernant le protocole PS4.

La Raspberry Pi zero W peut également être utile pour la connexion entre la PS4 et les différents modules en jouant le rôle d'intermédiaire. Nous avons alors commandé une Rpi zero W pour notre projet.
En attendant la réception de la commande, nous nous sommes penché sur les recherches pour les programmes et la configuration nécessaire à l'utilisation de la RPi zero W.

===Electronique===

[[Fichier: bouton_c1.jpg|100px|thumb|left|PCB bouton]]
[[Fichier: arduinobb.jpg|200px|thumb|right|atmega328p-pu branchement test]]

Du coté électronique, nous avons réalisé sur fritzing certaines cartes électroniques. Les Arduino Uno servant actuellement de test, seront remplacées par des PCB atmega328p-pu standalone avec des broches permettant les branchements nécessaires SPI ou encore aux modules "boutons/joystick". Pour les boutons, nous avons également réalisé un pcb afin de faciliter les branchements.

Il nous faut alors également une 3eme carte qui nous sera nécessaire pour la réalisation du prototype sans fil. Dans notre liste de matériel, nous avons des composants nrf52810 bluetooth, ceci doivent être soudé avec les capacités de protection mais également des broches de communication. Nous avons alors commencé cette carte électronique sur Altium avec le fichier projet PCB du distributeur à modifier.

[[Fichier: Arduino_c1.jpg|100px|thumb|center|PCB atmega328p-pu]]

=== Construction 3D ===

Enfin, nous avons commencé à réaliser des boîtiers 3D pour certains modules. Par exemple, comme nous l'avions vu précédemment, un des joysticks servira de bouton-gâchette en utilisant un seul de ses axes. Il nous faut alors réaliser un boitier qui bloque l'un des axes, mais également une tige qui nous permettra de pousser le joystick de manière simplifiée.

==Semaine 6==

===Programmation: configuration RPi Zero W ===

Ayant reçu la Raspberry Pi zero W en début de semaine, nous nous sommes concentrés sur la programmation et la configuration de celle-ci.
Cette partie étant compliquée, elle nous a pris du temps. En effet, il était difficile de connecter la RPi en SSH car il n'est pas possible d'y connecter un clavier directement et on avait besoin de la prise OTG pour "interfacer" la manette.

===Electronique: PCB nrf52810===

Les cartes réalisées en semaine 5 sont validées et en attente de réalisation.

Cette semaine a permis la réalisation et la finalisation de la carte électronique nrf52810. Il nous a fallu recommencé cette carte deux fois. En effet, une fois finie sur Altium nous avons réalisé que les empreintes des CMS sur PCB fourni par le constructeur ne correspondent pas au matériel CMS de l'école. Face à cette inattention de notre part, nous avons décidé de refaire entièrement la carte électronique sur fritzing. Ayant la datasheet et des plans d'inspiration PCB, nous avons pu refaire la carte entièrement.
Sur celle-ci nous avons ajouté des broches de connexion au besoin, un branchement Jtag et ICSP pour la programmation et la connexion SPI.
La carte est en attente de validation, puis validation.

[[Fichier: nrf52810_circuit2.jpg||center|400px|PCB carte nrf52810]]

===Révision matériel ===

Pour la réalisation de nos composants électroniques, il nous a fallu faire une révision des composants disponibles à l'école:
(les quantités indiquées ci-dessous pourront être augmentée si nécessaire,pour avoir dans l'idéal un module de chaque type de la manette, ici on se concentre sur BOUTON et JOYSTICK)

'''Cartes Arduino:'''
* 4 capacite 22pF traversantes
* 2 resistances 10 kOhm traversantes (à récupérer)
* 2 oscillateurs quartz 16MHz traversante
* 2 atmega328p-pu et support

'''Cartes nrf52810'''
* 6 capacités 100nF 0603
* 6 capacités 12pF 0603
* 2 capacités 4,7pF 0603
* 2 capacités 1µF 0603
* 2 capacités 100pF=0,1nF 0603 (à récupérer)
* 2 capacités 0,8pF 0603 (commande en cours)
* 2 inductance 3,9nH 0603 (commande en cours)
* 2 oscillateur quartz 32 MHz

'''Cartes modules Boutons'''
* un sachet de broches mâles (qu'on utilisera également pour les autres cartes, à récupérer/acheté)

Nous avons alors mis-à-jour la liste de composant située plus haut, ainsi que celle de la page IMA4 2017/2018 [https://projets-ima.plil.fr/mediawiki/index.php/Projets_IMA4_SC_%26_SA_2017/2018]

==Semaine 7==

===Programmation: connexion wifi RPi Zero W et Bootloader sur Atmega328p-pu ===

Pendant cette semaine, nous avons continué la programmation et la configuration des Raspberry Pi 3 et Zero W. Concernant la configuration ssh, nous avons utilisé un téléphone en guise de point d’accès à la RPi Zero W en wifi.
Nous avons aussi directement configurer l'OS Jessie, utilisé pour la RPi Zero. On a modifié le fichier cmd.txt et ...pour pouvoir programmer un USB gadget sur le port OTG.
Ci-dessus expliquer fichiers

Nous avons également continuer les programmes de récupération de données : état des boutons et du joystick. Ces programmes sont appliqué sur l'atmega328p-pu standalone sur la plaque d'essai en attendant que le PCB soit opérationnel.
Pour pouvoir programmer l'atemega328p-pu comme une arduino UNO, il nous faut suivre plusieurs étapes :

'''1.Flasher le Bootloader'''
Nous avons 2 Atmega328p-pu neufs, ainsi il nous faut flasher le bootloader sur chacun d'eux afin de pouvoir les utiliser et les programmer sur une breadboard dans un montage minimaliste arduino-standalone.
Pour cela, on peut utiliser une carte arduino UNO. On vérifie le port et le type de carte sélectionnés dans le menu >Outils. Sur cette carte on téléverse le fichier arduinoISP.ino qui se trouve dans les exemples en étant en progrmamateur AVr ISP mkll (>outils>programmateur)
Puis on met l'atmega328p-pu qui nous intéresse sur le suppor socket de la carte. On change de nouveau le programmateur pour Arduino as ISP et on fait >tools>burn bootloader, soit >graver la sequence d'initialisation.
Ces étapes faites, on peut retirer notre microcontroleur et le replacer correctement dans le montage.

'''2.Programmation atmega328 sur breadboard'''
Une fois l'atmega328p-pu préparé, on peut le programmer. On peut le faire simplement à l'aide de la carte arduino UNO utilisée précédemment.On branche les Tx et Rx en commun ainsi que le reset, le GND et le VCC.

Nous avons réaliser des codes basiques tels que le clignotement d'une led rouge ou encore l'affichage de "hello world" sur le moniteur série pour vérifier la bonne fonctionnalité du montage. Cela fait nous avons pu écrire sous Arduino IDE le code de lecture des états.

[[Fichier: montage_BB_test.jpg||left|200px|programmation modules arduino sur breadboard]]

===Electronique : soudure carte de test modules ===

Comme nous l'avons déja vu lors de la réalisation des PCB, si l'on souhaite programmer un atmega328p-pu en bootloader, le montage est simple. Il peut être minimaliste en utilisant une arduino UNO, un atmega328, une breadboard et 3 composants: 1 quartz 16MHZ crystal, 1 résistance 10kOhm et 2 capacitors céramiques de 22pF.
Durant la semaine 7, nous avons soudé les composants traversants de la carte électronique correspondant à ce montage ainsi que le PCB du bouton.

==Semaine 8==

===Programmation ===
Après moult recherche sur les différents site web bien fournis pour le coups on as pu trouvé une amorce à la programmation de l'OTG via un script qui agit au niveau du kernel dans le sous dossier usg_gadget. Ce script donne les informations nécessaires pour pouvoirs échangé les données.
Avec le script trouvé et les informations des sites web décryptant les trames de la manette, on a toujours pas réussit à faire passer notre RPi Zero W pour une manette de PS4. Néanmoins il nous manque la trame HID complète de la manette pour avoir un test effectif.

===Electronique : Correction soudure et soudure CMS===

Durant cette semaine, nous avions souhaité programmer la carte électronique atmega328p-pu. Cependant, nous avons réaliser que nous avions fait une erreur lors de l'envoie du PCB à la production. En effet, celui-ci avait été fait en Top sur le logiciel Fritzing et non en Bottom. Hors nous avions soudé les composants (durant la semaine 7) comme pour un circuit imprimé en bottom, l'atmega328p-pu se retrouve alors inversé par rapport aux pistes.
Comme solution, nous avons choisi de souder un deuxième support pour l'atmega328 de l'autre coté de la carte avant de la refaire au propre. En effet, avant de la refaire il nous faut vérifier si la carte est bien programmable.
Une fois cela fait nous avions pu programmer la carte mais, nous avions également réalisé la pin 2 de l'atmega328 était prise par le bouton poussoir. Or, nous avons besoin des pin 2 et 3 pour le RX et TX permettant la programmation de l'atmega à partir d'une arduino, les pistes branchement RX-TX n'ont également pas été prévus pour le téléversement des programmes sur la carte. Il nous faut alors couper une piste et souder des câbles pour utiliser toutes les pistes souhaitées.

[[Fichier: correction_proto_PCB.jpg||right|300px|PCB arduino correction]]

Durant cette semaine, nous avons également souhaité souder les CMS et le composant bluetooth nrf52810 sur la carte imprimé et reçu lors de la semaine 7. Pour cela, nous avons convenu de travailler dans la C202 durant la séance du mercredi.

[[Fichier: PCB_nrf52810.jpg||left|400px|carte electroniques imprimées]]

====Comment souder des CMS ?====

les CMS sont des composants montés en surface c'est à dire qu'ils sont montés du même côté que les pistes cuivrées (à l'opposé des composants traversants) et sont de petite tailles souvent de l'ordre du millimètre. La taille est déterminée par 4 chiffres : les 2 premiers pour la longueur et les 2 derniers pour la largeur. On a du 1206,0805,0603 ou encore 0402. Il est même possible de trouver plus petit. A l'école nous utilisons souvent du 0603, c'est le cas de nos composants.
Pour souder des CMS 0603, il nous faut utiliser une autre méthode qui n'est pas le fer à souder :
# Préparer la veille la pâte à braser la veille (dans une seringue)
# Gommer la carte pour éviter l'oxydation (attention à ne pas retirer les miettes de gomme en soufflant dessus)
# Appliquer avec la seringue la pâte sur les empreintes et piste souhaitées. Pour les endroits difficile à atteindre ou avec 2 pistes proches les unes des autres, il est possible de mettre la même goutte de pâte sur les 2 pistes. Cela de causera pas de court-circuit par la suite. En effet, la pâte est composée d’alliage qui sous la chaleur va se fluidifier et se coller uniquement aux pistes métallique. Le reste fondera sous la chaleur du four.
# Appliquer les CMS sur la pâte au fur et à mesure (attention ! ne jamais toucher les CMS avec les doigts, tjrs utiliser une pince)
# Mettre au four

====Bilan soudure nrf52810====

Cependant, une fois le matériel nécessaire préparé, et la pâte mise sur les pistes souhaitées, au moment de déposer le composant, nous avons réalisé que celui-ci était beaucoup plus petit que l'empreinte sur le PCB. Il s'agit d'un composant boitier QFN48. Fritzing ne proposant au plus proche des boitiers QFN24 ou LQFP48, celui-ci a basculé automatiquement pour un boitier LQFN48, de dimension plus grande. Face à ce manque de vigilance, nous avions cependant commencer par le nrf52810 (composant concerné) évitant ainsi de gaspiller d'autres CMS.
Nous avons souhaité refaire la carte sous Altium à partir des fichiers fournis par le concepteur (chose que nous avons commencé à faire aux alentours de la semaine 5)
Après la réalisation du schématic, et de la modification des empreintes de capacités, inductances et autres composants de 0402 à 0603. Notre matériel ne permettant que des empreintes 0603.

Lors du routage, une erreur de chevauchement des pistes est notifiée par Altium au niveau du nrf52810. Celles-ci ne présentent pas d'angles et sont déjà de taille 8mil, il nous faut alors passer les pistes en 6mil. Mais 8mil est la taille minimale pour la production à Polytech, nous avons regardé pour envoyer les cartes à faire ailleurs mais le 6mil n'est pas beaucoup conseillé. De plus, il n'est peut-être pas judicieux de continuer avec le composant microcontrôleur-bluetooth Nrf52810 qui prend du temps, donc la carte est difficilement réalisable et peut-être très long à programmer.

Ainsi en cette fin de semaine, nous avons décider face à l'avancer du projet de laisser les nrf52810 de coté et de les remplacer par des modules sans fils plus simples d'utilisation et complets. Ainsi nous aurions plus de chance d'avoir une connexion sans fils entre les modules. Nous pourrions par exemples utiliser des Xbee, des modules Rf...

==Semaine 9==

====Programmation: PS4 et 1er Test SPI sur atmega328p====

'''Raspberry Pi Zero W et PS4'''

Les premiers tests sur Windows ne nous donner pas satisfaction. En effet, l'ordinateur détectait bien le nouvel appareil avec son nom mais l'origine rester inconnue.

Lors des tests sur Linux on a pu voir des erreurs via la commande 'dmesg' :

[193229.758782] usb 4-1.2: new high-speed USB device number 6 using ehci-pci
[193230.270780] usb 4-1.2: new high-speed USB device number 7 using ehci-pci
[193235.510842] usb 4-1.2: device descriptor read/64, error -110
[193251.127043] usb 4-1.2: device descriptor read/64, error -110
[193251.315043] usb 4-1.2: new high-speed USB device number 8 using ehci-pci
[193256.503135] usb 4-1.2: device descriptor read/64, error -110
[193272.119331] usb 4-1.2: device descriptor read/64, error -110
[193272.307331] usb 4-1.2: new high-speed USB device number 9 using ehci-pci
[193282.999473] usb 4-1.2: device not accepting address 9, error -110
[193283.079485] usb 4-1.2: new high-speed USB device number 10 using ehci-pci
[193293.751588] usb 4-1.2: device not accepting address 10, error -110
[193293.751771] usb 4-1-port2: unable to enumerate USB device
[193387.196861] usb 4-1.2: new high-speed USB device number 11 using ehci-pci
[193392.440941] usb 4-1.2: device descriptor read/64, error -110
[193407.933152] usb 4-1.1: new high-speed USB device number 12 using ehci-pci
[193413.177227] usb 4-1.1: device descriptor read/64, error -110

'''Modules Atmega328p et SPI'''

Une carte PCB arduino fonctionnant, nous pouvons la programme pour simuler un module. Celle-ci a été designée afin de s'adapter au module que l'on souhaite. Il suffit de brancher le bouton, le joystick ou autre élèment de manette souhaité.
Cette semaine ci, nous avons alors configurer la partie communication SPI pour l'arduino.

'''Que voulons-nous faire avec les atmegas ?'''
Les cartes électroniques atmega328p vont nous permettre de recevoir les requêtes SPI envoyées par la raspberry pi et d'y répondre. La Raspberry enverra un message, par exemple "1", et l'Arduino lira alors l'état du module qui lui est connecté. Une fois l'état récupéré elle le renvoie à la raspberry pi.

Durant cette semaine, nous avons programmé l'atmega afin qu'il soit en esclave, qu'il reçoive un de la RPi "1" et retourne une valeur sauvegardé "int envoi". Nous avons également commencé les tests pour la lecture de l'état d'un bouton (d'après les tests réalisés les semaines précédentes).

'''Code'''
Comme nous l'avons vu précedement lors de nos recherches (semaines 1 à 4) :
La communication SPI nécessite l'utilisation des pins:

MOSI -> GPIO11 //PB3 //master OUT to the slave IN
MISO -> GPIO12 //PB4 //slave OUT to the master IN
SCLK -> GPIO13 //PB5 //serial clock
SS -> GPIO10 //PB2 //slave select

Il faut également paramétrer l'atmega328p en Slave. On note que dans un premier temps, le programme sera codé avec l'arduino IDE (fichiers .ino). Une fois l'ensemble SPI RaspberryPi-Arduino fonctionnant, on remplacera ces codes par du langage C ou C++.

Pour faire la connexion SPI sur l'atmega328p, on utilise la librairie arduino SPI.h, on a alors directement les fonctions nécessaires intervenant sur les registres souhaités : SPCR (spi control register), SPSR (spi status register) et SPDR (spi data register).

#include <SPI.h>

Il est important d'initialise d'abord le setup et on active le port série pour pourvoir utiliser le moniteur série. (Cela servira à verifier la valeur envoyée par la RPi)

void setup (void)
{
Serial.begin (9600);
pinMode(MISO, OUTPUT); //configuration en esclave *master in slave out*
pinMode(buttonPin,INPUT); //config pin bouton
// turn on SPI in slave mode
SPCR |= _BV(SPE);
// preparation interruptions
pos = 0; // buffer empty
process_it = false;
// activation interruptions
SPI.attachInterrupt();
}

On oublie pas de déclarer les interruptions afin de bien lire la requête reçue.

// SPI interrupt routine
ISR (SPI_STC_vect)
{
byte c = SPDR; // grab byte from SPI Data Register
// add to buffer if room
if (pos < sizeof buf)
{
buf [pos++] = c;
// example: newline means time to process buffer
if (c == '\n')
process_it = true;
} // end of room available
} // end of interrupt routine SPI_STC_vect

Dans la loop main, on traite la requête et on utilise '''SPI.transfer(envoi);''' pour transferer à la RPi les données souhaitées.

Durant cette semaine, nous avons également commencé des programmes de test SPI pour la RPi. Il s'agit principalement de programmes de tests tout faits permettant de vérifier la connexion entre cette dernière et l'arduino. Par exemple, la RPI envoie "bonjour" et l'arduino lui retourne ce qu'elle reçoit, soit "bonjour". Sans succés alors.

====Electronique : Fritzing révision====

Lors de la semaine, le modèle PCB de la carte arduino a été réalisé de nouveau sous fritzing avec les broches et connections manquantes. Nous avons également revu la configuration du bouton reset et ajouté une led d'état de l'alimentation. Nous avons ainsi envoyé deux cartes identiques à la réalisation.
La carte déjà soudée lors des derniers jours fonctionnant, elle nous sert de prototype de programmation. Nous pouvons ainsi avancer à la fois sur la programmation des modules mais aussi sur leur réalisation.

==Semaine 10==

====Programmation : PS4 et SPI sur RPi====

'''Raspberry Pi Zero W et PS4'''

Cette semaine, pour tester la prise OTG nous avons décider de lancer un script qui est habituellement utilisé. Nous avons choisi le script Serial Adapter qui est censé permettre de se connecter à la RPi Zero W en SSH via ce port.
Après quelque modifications et plusieurs petits bugs, nous avons réussir à faire fonctionner le ssh via le port OTG. Donc le problème était le même, notre script mélangé avec les informations sur la PS4 n'était toujours pas fonctionnel.

'''Modules Raspberry PI et SPI'''

Durant cette semaine, pour la partie Atmega328p-Modules, nous nous sommes concentrés sur la programmation de la communication SPI avec la raspberry pi. Cette semaine a permis une étude plus approfondit sur le fonctionnement pour la RPi.

On rappelle, comme vu des semaines 1 à 4, pour la RPI3 (tout comme la RPi Zero W) utilise les broches : SCLK (23), MISO(21), MOSI (19) et SPI CS0 (24), SPI CS1 (26).
On la programme en Master. A l'aide des fichiers tests d'inspiration, on pourra directement programmer la RPi en C. Lors de la réalisation du code, il y a 3 étapes : l'initialisation/parametrage en SPI pour être maître, l'envoie de la requête puis la réception de données en retour.

Programmant en C, il ne faut pas oublier les librairies suivantes :

#include <stdint.h>
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
#include <getopt.h>
#include <fcntl.h>
#include <sys/ioctl.h>
#include <linux/types.h>
#include <linux/spi/spidev.h> //pour SPI

On va déclarer des variables globales permettant le paramétrage :

static const char *device = "/dev/spidev0.0"; //si on veut CS0 pour atteindre notre SS
static uint8_t mode; //mode est par défaut à 0
static uint8_t bits = 8; //bits par mot échangé
static uint32_t speed = 500000;
static uint16_t delay;

Dans notre main, on ouvre le port (la connexion) au device souhaité, on vérifie les paramètres (registres, connexions...) puis exécute la fonction transfer(fd). transfer(fd) transmet la requête et s'occupe de la réception.

fd = open(device, O_RDWR);
transfer(fd);
close(fd);

==Semaine 11==

====Programmation: PS4, SSH et tests SPI (RPi3&Atemga328p)====

'''Raspberry Pi Zero W et PS4'''

'''Raspberry PI, Atmega328p et SPI'''

Afin de facilité la programmation en utilisant Ethernet, nous avons installer et configuré la RPi pour l'utiliser en SSH depuis les ordinateurs de la E306. En effet, SSH permet de se connecter à distance sur une machine en utilisant un compte utilisateur de la dite machine. En mettant ssh, on pourra directement agir sur les fichiers de la raspberry depuis un terminal de notre PC. Pour cela, on a d'abord vérifier l'adresse IP de notre raspberry pi : 172.26.145.106 avec un écran mais on peut aussi utiliser les commandes ip a et ifconfig. Puis activer le ssh sur la raspberry pi.
On modifie alors le fichier config.txt mais également etc/network/interfaces pour configurer la bonne interface Ethernet sur la raspberry pi.

[[Fichier: configSSH_raspi.png||left|300px|config ssh ethernet]]

Il nous suffit alors de taper la commande : ssh pi@172.26.145.106 pour accéder à notre RPi.

Nous avons continué à réaliser la communication SPI avec des tests entre une arduino UNO et la RPI3. Nous avons commencé par des tests simples inspirés des études de deux semaines précédentes et modulés selon notre utilité.
Nous arrivons alors à lire l'état envoyer "bonjour" et recevoir "ça va" ou encore "1" et recevoir "3". Il faut noter que le SPI échange des trames, la RPI reçoit alors des hexadécimaux.
Nous avons alors continué pour recevoir l'état du bouton ou du joystick lors de l'envoie de "1" sur l'Arduino328p. La semaine prochaine nous testerons ces même codes fonctionnels sur les cartes atmeg327p.

A la fin de cette semaine, nous avons alors des codes Arduino-SPI (.ino) et des codes Raspberry-SPI (.c) permettant l'échange de données. Le but est maintenant de l'adapter aux cartes imprimées et de le rendre pleinement fonctionnel pour plusieurs cartes à la fois, puis ajouter une boucle de vérification en continue jusqu'à une deuxième requête de la RPi.

====Electronique: réalisation au propres des PCB modules====

Suite à une nouvelle erreur de réalisation cartes électronique, nous avons refait et renvoyé à nouveau les cartes imprimées atmega328p.
Nous les souhaitons au propre pour une version finale. Une fois celle-ci imprimées nous pourrons en avoir 3 , un pour chaque module. Les cartes étaient bien imprimées en bottom mais lors du passage des traversants de bottom à top, le logiciel ne les a pas fait miroiter. Par manque d'attention nous avons alors envoyé les fichiers gerber pour des cartes ayant les composants du même coté que la couche de cuivre.
Les cartes électroniques actuelles sont alors correctes et fonctionnelles mais difficile à souder. Pour eviter les erreurs et continuer sur des prototypes de carte nous préférons attendre en nous concentrant sur la programmation PSI de la Raspberry Pi.

==Semaine 12==

====Programmation====

'''Raspberry Pi Zero W et PS4'''

'''Raspberry PI, Atmega328p et SPI'''

- réflexion: penser à faire boucler sur l'arduino une fois la requête reçu, ça veut dire que la manette est ON et donc vérifier continuellement les modules sur chaque atmega.
- SPI raspberry pi - arduino recuperation état du bouton avec les cartes modules (/!\ récuperation à faire dans une variable)

-SSH perso
adresse Rasppi: 192.168.137.10

====Electronique: Finalisation soudure Modules====

Soudure au propre et finale d'une carte atmega328p et donc envoie pour la réalisation de 2 autres cartes similaires et récupération de matériel
Soudure des 2 autres cartes, + tests sur les états = fonctionnelles.
On a donc bien 3 cartes pour les 3 modules de types différents (1 bouton, 1 joystick, 1 gachette)
PCB pour les 2 joysticks (qui serviront de thumbstick et gachette)

==Semaine 13 et plus==

====Programmation====

'''Raspberry Pi Zero W et PS4'''

'''Modules Atmega328p et SPI'''

====Electronique====

=Documents Rendus=

(à mettre rapport + git + drive)

=Datasheets=

IMA4 2017/2018 P35

2018-05-05T20:03:50Z

Tgracias : /* Programmation: PS4 et 1er Test SPI sur atmega328p */

__TOC__
 

=Présentation générale: Manette modulable=

==Description==

Tout le monde joue aux jeux vidéo cependant, les manettes ne sont pas adaptées aux personnes ayant un handicap pouvant toucher les bras ou les mains.
C’est le cas, de plusieurs patients dans les centres de soins et de rééducation.

Pour ce projet IMA4, nous travaillerons avec le centre SSR (soin de suite et de réadaptation) Marc Sautelet de Villeneuve d’Ascq.
Un adolescent, patient de Marc Sautelet, est passionné par les jeux vidéo. En effet, ayant perdu la motricité d’une partie de son corps, il ne peut pas jouer à deux mains. Pour cela, il bloque la manette entre son épaule et son coude, usant de la mâchoire et des doigts pour contrôler les
joysticks et les boutons. Cet exercice peut s’avérer fatiguant et pénible.

Ainsi, nous chercherons à concevoir une manette PS4 adaptée au handicap de l’adolescent.
Cette manette devra aussi être adaptée pour d’autres patients présentant également des handicaps moteurs. Ainsi nous prendrons pour cibles: tous les patients du centre voulant jouer; et non pas que les enfants et adolescents.

 

{| class="wikitable centre" width="80%"
|+
|-
| width="23%" |
Membre du projet
| width="34%" |
Transley Gracias et Camille Saad
|-
| width="23%" |
Cible
| width="34%" |
Patient présentant un handicap moteur
|-
|width="23%" |
Période du projet
| width="34%" |
janvier 2018 - mai 2018
|-
|width="23%" |
Partenaire/Client
| width="34%" |
Centre SSR Marc Sautelet à Villeneuve d'Ascq
|}

==Objectifs==

Ce projet a pour objectif de créer un prototype de manette qui puisse interagir avec la console PS4 et dont le paramétrage se fait à l’aide d’une application mobile et/ou web. Cette manette devra suivre les demandes du patient ainsi que des aides-soignantes du centre, dans la mesure du possible.

Plus précisément, pour le premier prototype, nous mettrons en œuvre l'utilisation de quelques boutons spécifiques:

* Un joystick (type L/R)
* Quelques boutons poussoirs (type Croix/Triangle/Carré/Rond/R1/L1/Start/...)
* Des boutons gâchettes progressives (type L2/R2).

Le but serait donc dans un premier temps de rendre fonctionnel un bouton de chaque type, puis de les multiplier une fois cela fait. Tous ces boutons réunis constituent une manette fonctionnelle.Ainsi, la manette sera ajustable, c’est à dire qu’elle devra s’adapter aux différents handicaps moteurs possibles.

=Analyse du projet=

==Positionnement par rapport à l'existant==

Notre prototype aura une présentation unique par rapport à l’existant. En effet, les concurrents et produits existants ciblent pour la majorité un seul handicap. Cela
engendre une solution fermée à beaucoup de patients. Notre projet propose une mobilité des mouvements et également un choix large dans la composition et le
design de notre manette.
Le patient n’est pas retreint à jouer à une seule main, à utiliser beaucoup de force...Il y a moins de technique dans la manipulation et on ne joue pas avec une
manette adaptée uniquement pour un droitier ou un gaucher. Cependant, cela nous limitera peut-être dans le choix possible des types de jeux. Tout comme les autres
manettes adapté, l’utilisateur nécessitera un peu d’entrainement.

==Analyse du premier concurrent==

Jouer aux jeux vidéo à une main n’est pas une idée d’aujourd’hui. En 1990, Nintendo propose le Power Glove. Mais il tombe très rapidement aux oubliettes suite à des problèmes techniques.

Un autre gant a fait son apparition quelques années plus tard. Celui-ci, plus technique, il faut office de manette Play Station: le Reality Quest Power Glove.Cette idée de manette-gant, permet de jouer à la PS avec une seule main, elle a était conçue et présentée pour les E3, un salon d’exposition de gaming.Le gant est conçu pour contrôler l’équivalent des 14 boutons et 2 joysticks à l’aide d’une seule main. La « manette » est fixée dans la pomme de la main. L’utilisateur contrôle les mouvements verticaux et horizontaux en pivotant le poignet, et utilisent les 4 boutons d’action principaux et L1/R1 avec les doigts. Les autres boutons sont accessibles par un seul bouton rond contrôlé par le pouce.
La manette est adaptée pour beaucoup de jeux vidéo, dont les plus simples sont les jeux de voitures et de combats (arcade).

; Problèmes:
*Besoin de toute la motricité de la main, c’est-à-dire que si le patient à un doigt paralysé ou manquant, il ne pourra pas jouer avec ce gant
*Design obligatoirement droitier
*Les boutons de contrôle sont peu sensibles et peuvent nécessiter de la force
*Design compliqué et nécessitant beaucoup d’entrainement.

;Lien : https://www.youtube.com/watch?v=qV0SxSJDCYg

 
==Analyse du second concurrent==

Ben Heck, de son vrai nom Benjamin J.Heckendorn, est un concepteur de mods de consoles (mods pour modification, soit « manettes modifiées ») et une star
du net grâce à ses vidéos tutoriels.Il propose alors énormément de produits adaptés ou dérivés en guise de manettes.
Parmi les mods qu’il a réalisé, il a modifié une manette de PS4 afin de la rendre accessible à une personne ne pouvant jouer qu’à une main. Pour cela, il a déplacé les boutons en respectant l’ergonomie de la main valide et modifie les connexions. Il peut lui arriver de rajouter des boutons pour en remplacer un autre. Il réalise également le même système avec la Xbox. Sur la photo ci-dessous, il a adapté la manette pour un droitier.

; Problèmes:
*Besoin de toute la motricité de la main, c’est-à-dire que si le patient à un doigt paralysé ou manquant, il ne pourra pas jouer avec cette ma
*Design obligatoirement droitier ou gaucher, une modification = une manette= une personne
*Besoin obligé du pouce et de l’index, même si avantage : 3 doigts nécessaire.

;Lien :: https://www.youtube.com/watch?v=LieHIscadjk

==Scénario d'usage du produit ou du concept envisagé==

La technologie est ,aujourd’hui, omniprésente dans notre vie. Les consoles de jeux ont envahies les maisons avec plus de 7 personnes sur 10 jouant aux jeux vidéos sur consoles en France (chiffre de l’Express). 0,18% des français sont handicapés cela représente 12 millions de français. Dans ce chiffre, 13,4% des personnes ont un handicap moteur. En 2017, les grands groupes comme Sony ou Microsoft avec respectivement PlayStation et Xbox ne permettent pas à tout le monde de jouer avec une manette. Les manettes sont prévues pour des personnes ayant leurs membres valides, plus précisément les mains et les bras.

Après un accident de voiture, un jeune garçon a perdu la motricité d’un côté du corps. Passionné de jeux vidéo, il se retrouve avec des difficultés à jouer sur sa console PS4. Ingénieux, il utilise la manette en la coinçant entre son épaule et le creux du cou. Usant de la mâchoire et de sa main valide pour contrôler les joysticks et les boutons. L'exercice étant inconfortable et fatiguant il eu l’idée de proposer à des futurs ingénieurs de lui proposer une manette adaptée à son handicap.

Les deux pré-ingénieurs ,avec leur tuteur, ont une idée révolutionnaire : La manette modulable ! Elle permettrait au jeune garçon, ainsi que d’autres joueurs, de pouvoir continuer de s’amuser ou même de commencer à jouer au jeux sur console.
Cette manette aidera fortement dans les centre de rééducation pour faire passer le temps et donner du plaisir à des personnes qui ne peuvent plus s’amuser avec leur console traditionnelle. Elle pourra aussi ouvrir de nouvelles possibilités pour certaines personnes qui n’auraient jamais essayé jusqu'à présent.
Comme son nom l'indique, elle sera modulaire et s'adaptera à différents handicaps. Accompagnée de son application d’initialisation, elle sera accessible aussi bien aux enfants, patients, parents et aides soignantes.

Quelques mois plus tard...Le jeune patient fan de Need For Speed, peut maintenant piloter sa voiture comme un vrai professionnel grâce à l'un des joysticks qu'il utilisera avec sa main valide et il pourra accélérer à des vitesses folles à l'aide de boutons poussoirs au niveau de son pied valide et gagner la partie. Son ami venu lui rendre visite, pourra en lieu et place des aides soignantes configurer à l'aide de la tablette (portable) la manette du patient.
Si le patient change de jeu pour Tekken et que la configuration des modules ne lui convient plus, il peut interchanger les éléments de la manette selon son envie et son confort. Ainsi il peut faire sauter son personnage, il utilisera un module bouton supplémentaire, qu'il actionnera avec le poing.

==Fonctionnement==

Suite à une analyse fonctionnelle et à la formulation de notre projet, nous avons pu définir le fonctionnement de notre système. Notre produit, la manette, doit être accessible d’après nos objectifs à différents types de handicaps moteurs. Ainsi, l’idéal serait de concevoir une manette modulable afin qu’elle puisse s’adapter à toutes les situations. Ce n’est plus au patient de s’adapter à la manette mais à la manette de s’adapter au patient.
Cela signifie que la manette sera, dans la limite du possible et de la sensibilité du corps du patient, composée de plusieurs parties dites « modules » comportant un ou plusieurs actionneurs (boutons, joysticks, gâchettes...). Ces modules seront déplaçables afin d’être utilisé avec différents membres du corps : un doigt, une main,
une jambe ou même un pied. Il suffira de les connectés entre eux suivant l’organisation souhaitée, le Gameplay du jeu ou en fonction du handicap. Le tout sera relié à une application.
L’application sera alors mise en place pour connecter les différentes parties du point de vue software pour prérégler la manette en fonction du patient. Il pourra alors choisir les boutons en fonction du jeu, de ses mouvements mais aussi choisir la sensibilité.

L’application et les modules devront être intuitifs et faciles d’utilisation. De cette manière des utilisateurs non avertis dans le domaine informatique ou jeunes pourront eux-mêmes gérer les connexions.

==Réponse à la question difficile==

'''Question : Comment interconnecter les différents modules de la manette ?'''

Il nous faut pour ce projet interconnecter les modules modélisant la manette qui seront connectés à la consoles PS4 via une Raspberry Pi 3.
Le choix de la Raspberry Pi 3 nous permet d'utiliser son module Bluetooth pour communiquer avec la PS4, ce choix est plus adaptée au projet que du filaire.
Concernant l'interconnexion des modules, nous travaillerons en deux étapes "preuves concept" : filaire et sans fils (Bluetooth).

'''Objectif 1 : Preuve concept filaire'''

Dans cette première partie de projet, nous souhaitons avoir une 1ère preuve de prototype rapidement. Nous nous concentrerons alors sur la communication entre la RPi3 et la PS4 ainsi que sur la conception des modules. Pour les modules, nous réaliserons des cartes électronique pour chaque module avec un micro-contrôleur. La communication filaire nous permettra d'interconnecter les modules à la RPi3 avec un bus SPI.

'''Objectif 2: preuve concept sans fils'''

Une deuxième étape du projet est la réalisation de la solution idéale sans fils. Celle-ci pourra commencer à être développée petit à petit en parallèle avec l'objectif 1. Le but ici, est d'interconnecter les modules en Bluetooth. Nous avons choisi le Bluetooth pour garder une connexion commune sur toute la chaîne.
Nous rajouterons alors un module bluetooth à chaque module de la manette.

'''Objectif 3: possibilité d'adapter les boutons (capuchon en 3D)'''

=Préparation du projet=

==Cahier des charges==

''Chef de projet:'' Alexandre Boé 
''Responsables:'' Xavier Redon, Thomas Vantroys 
''Partenariat:'' Marc Sautelet (non etablie) 
''Elèves-ingénieurs:'' Camille Saâd, Transley Gracias 

'''Sujet :''' Manette modulable pour personne à déficience moteur compatible PlayStation 4 

===Objectifs principal (1er POC) : ===
Faire transmettre des informations issus des actionneurs (ex:boutons poussoires) via des arduinos jusqu’à la Raspberry Pi 3 en SPI. 
Envoyer les données reçues vers la PS4 en USB 

===Objectifs secondaire (2e POC):===
Créer des modules avec un microcontrôleur et une puce bluetooth pour permettre une meilleurs flexibilité (c-àd pouvoirs avoir une meilleure ergonomie et une connexion sans fil) 
Connecter la Raspberry Pi 3 en Bluetooth à la PS4 

[[Fichier: beteacorne.jpg||middle|600px|Bete a corne manette]]

==Choix techniques : matériel et logiciel==

===Liste de matériel :===

'''Modules boutons/joysticks/gachettes'''

3 Push buttons : 
- O X Y Carré R3 L3 
- Guide PS 
- start/back 
--> 0,45€/unité TTC [https://www.gotronic.fr/art-bp-miniature-krs1273-16976.htm] 

1 Thumbstick original: 
Joystick analogique 4 directions --> 4,25€/unité TTC [https://www.gotronic.fr/art-joystick-analogique-4-directions-19063.htm] 

1 buttons trigger L1 L2 => 1x Thumbstick original''' 

'''Cartes Atmega328p /connexion spi/'''

3 Arduino UNO 
1 Arduino UNO atmega328p retirable 
4 capacite 22pF traversantes 
2 resistances 10 kOhm traversantes (à récupérer) 
2 oscillateurs quartz 16MHz traversante 
2 atmega328p-pu et support 

'''Cartes module bluetooth nrf52810 '''

6 capacités 100nF 0603 
6 capacités 12pF 0603 
2 capacités 4,7pF 0603 
2 capacités 1µF 0603 
2 capacités 100pF=0,1nF 0603 (à récupérer) 
2 capacités 0,8pF 0603 (a acheter, commande en cours) 
2 inductance 3,9nH 0603 (a acheter, commande en cours) 
2 oscillateur quartz 32 MHz 

''' Connexions et autres '''

1 Led RGB neopixel [https://www.adafruit.com/product/1734] 
1 Raspberry Pi 3 
--> ~36,23€/unité TTC [https://fr.rs-online.com/web/p/processor-microcontroller-development-kits/8968660/?src=raspberrypi] 
1 Raspberry Pi Zero W (commandée) [https://www.raspberrypi.org/products/raspberry-pi-zero-w/] 
6 Alimentations 5V ou 3,3V 
par exemple, 12 piles de type CR2016 3V rechargeables ou 24 piles AAA 1,5 V rechargeables
5 modules Bluetooth nrf de Nordic : nRF52810-QFAA-R 
--> 3,17€/unité + frais expédition [https://www.mouser.fr/productdetail/nordic-semiconductor/nrf52810-qfaa-r?qs=sGAEpiMZZMve4%2FbfQkoj%252bG%2FosjLoe2oghFQwQllMrQ4%3D]
5 Lignes broches mâles 

===Logiciels:===

- IDE arduino
- Altium
- FreeCAD ou Inkscape

==Liste des tâches à effectuer==

'''Etape 1 : Gestion du projet'''

* Définition des cahiers des charges fonctionnel et technique, choix d'orientation...
* Recherche techniques sur les différentes connexions possibles entre les modules, la RPi 3 et la console PS4
#Recherche connexion SPI entre les modules et la RPi3
# Recherche connexion bluetooth entre la RPi3 et la PS4
# Recherche connexion bluetooth pour les modules
# Recherche carte avec montage Atmega328P-PU et anticipation module bluetooth
* Détermination du matériel nécessaire
* Réflexion sur l'application

'''Etape 2: Réalisation du projet'''

'''Partie 1: Preuve concept manette en filaire'''

* Conception de cartes électroniques pour 2 modules (/!\ prévoir modules bluetooth)
* Réalisation connexion SPI avec 2 modules : programmation des Atmega328p en liaison série.
* Si tests concluant, ajouter des modules jusqu'à en avoir 5 (1 pour chaque type de boutons)
* Connexion bluetooth entre la PS4 et la RPi3
* Réalisation du support des modules avec fixations possibles (imprimante 3D)

'''Partie 2: Preuve concept manette en bluetooth'''

* Ajout des modules bluetooth aux cartes électroniques
* Connexion bluetooth entre les modules

'''Partie 3: Application Android : paramétrage de la manette'''

* Créer une application sur tablette ou smartphone (Android) afin de configurer la manette aux besoins (inter-connexion des modules et console)

==Calendrier prévisionnel==

{| class="wikitable centre" width="80%"
|+
|-
| width="23%" |
'''Date'''
| width="34%" |
'''Tache à réaliser''' 
|-
| width="23%" |
17/01/18-24/01/18
| width="34%" |
Faire des recherches sur les différentes interconnexions du système : Bluetooth, RPi-Atmega328 (SPI), RPi-PS4
Continuer liste des taches, matériel, Début recherches + réflexion fixation support des modules
|-
|width="23%" |
31/01/18
| width="34%" |
Recherche technique connexion PS4-RPi3 et connexion SPI RPi3-Module + code
|-
|width="23%" |
31/01/18-07/03/18
| width="34%" |
Réalisation 1er prototype (+ début prototype 2)
|-
|width="23%" |
07/03/18
| width="34%" |
Seance 7 : Test prototype filaire
|-
|width="23%" |
07/03/18-09/05/18
| width="34%" |
Réalisation 2eme prototype + application Android
|-
|width="23%" |
09/05/18
| width="34%" |
Seance 14 : Test prototype Bluetooth
|-
|width="23%" |
14/05/18
| width="34%" |
Video projet
|-
|width="23%" |
15/05/18
| width="34%" |
Finalisation projet et Rapport
|-
|width="23%" |
16/05/18-17/05/18
| width="34%" |
Soutenances Projet
|}

=Réalisation du Projet=

==Feuille d'heures ==

Voici le tableau d'heures du binôme:

{| 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 S11 !! Heures S12 !! Heures S13et+ !! Total
|-
| Analyse du projet
| 10
| 2
| 1
| 1
| 1
|
|
|
|
|
|
|
| 20min
|
| 15h20
|-
| Cherches techniques
|
| 3
| 4
| 4
| 2
| 2
| 1
|
|
|
| 1
| 1
|
|
| 18
|-
| Rédaction du wiki et rapport de projet
|
| 1
| 1
| 1
| 1
| 30min
| 1
|
| 2
| 30min
| 30min
|
| 2
|
| 10h30
|-
| Programmation
|
|
|
|
| 3
| 2
| 3
| 5
| 4
| 7
| 8
| 6
| 5
|
| 43
|-
| Cartes électroniques
|
|
|
|
|
| 6
| 8
| 4
| 6
| 2
| 1
| 2
| 2
|
| 31
|-
| Application
|
|
|
|
|
|
|
|
|
|
|
|
|-
|-
| Total Semaine
| 10
| 6
| 6
| 6
| 7
| 10h30
| 13
| 9
| 12
| 9h30
| 10h30
| 9
| 9h20
|
| '''117h50'''
|}

==Prologue==

Avant la réalisation et conception d'un projet, il est important d'analyser celui-ci. Nous avons allons consacré le prologue à l'analyse fonctionnelle de la manette. Nous avons également eu une réflexion sur l'analyse technique, cela nous a permis de réaliser une liste de matériel. Il est important de définir les objectifs ainsi que les besoins afin de ne rien oublier. (Voir ci-dessus Analyse projet)
Nous avons également organisé notre travail, pour le partage de documents de recherches et la rédaction de compte-rendu final nous avons réalisé un google drive. Par la suite, nous créerons un projet Git.

Durant ce temps, nous avons décidé de réaliser 5 modules. Les modules sont les différents boutons de la manettes qui nous pourrons placer selon nos choix (boutons modulaires) pour notre prototype projet pour chaque type des boutons d'une manette PS4. Ces modules devrons être connectés à la console et interconnectés. Le tout sera lié à une application Android. Suite à quelques recherches et nos analyses, nous avons décidé les points suivants :

- On commencera avec 2 modules et on les multipliera par la suite.
- Les premiers tests sont réalisés avec des boutons petits pour assurer leur caractéristique "modulaires", par la suite nous pourrons ajouter des capuchons de taille plus importante (imprimante 3D ou achat)
- Conception modules : réalisation de carte avec un microcontrôleur atmega328 programmable pour chaque module (anticiper le module Bluetooth)
- Projet en 2 parties : prototype filaire et prototype Bluetooth
# Prototype filaire : connexions entre les modules et la RPi3 en SPI, connexion Rpi3-PS4 en Bluetooth, avec l'application en filaire à la RPi3
# Prototype Bluetooth: connexion Bluetooth entre modules-RPi3-PS4-apllication

[[Fichier: structuremanette.png||center|400px|Concept manette modulable]]

==Semaine 1==

Durant la séance, nous nous sommes concentrés les recherches afin de définir clairement le cahier des charges technique. Il s'agit des réalisations à mettre en œuvre pour les inter-connexions des éléments de la manette.
Ainsi, nous avons fait des recherches sur :

===Connexion SPI entre les modules (Atmega328p) et la RPi3===

SPI: Serial périphérique interface BUS

[[Fichier: yWGmW.png||right|200px|Concept manette modulable]]
Comme indiqué sur l'image ci-dessus, la Raspberry pi 3 peut communiquer en SPI avec ses broches CS0 (24), CS1 (26), SCLK (23), MISO (21), MOSI (19). Celles-ci permettent de communiquer avec un ou plusieurs esclaves (dans notre cas, des Atmega328p) en reliant directement les broches concernées de la RPi3 à celles des composants esclaves.
Chaque broche CS0 (24) ou CS1 (26) ne peut être connectée qu'à l'entrée SS (aussi appelé CS) d'un seul esclave.
C'est a dire que chaque CS est lié à un esclave afin de choisir avec lequel la communication est établie à un moment donné, et les MISO sont reliées entre elles en cascade, de même pour les SCLK et les MOSI. On peut noter que le maître impose la fréquence d’horloge et sélectionne l’esclave auquel les données sont envoyées. 8 MHz est le plus rapide supportable a 3,3V

[[Fichier: fonctionnementSPI.png||right|200px|Connexion SPI multi-esclaves]]

Voici un schéma du fonctionnement souhaité :

Comme nous souhaitons avoir 5 modules environ il nous faudra rajouter un composant en plus afin d'augmenter les possibilités de sélection, par exemple des démultiplexeurs.
Dans un premier temps nous essaierons avec 2 esclaves, puis on augmentera le nombre.

===Connexion Bluetooth PS4-RPi3===

Les recherches portent également sur la connexion entre la manette PS4 et la console. Elles concernent le protocole de communication via Bluetooth

Caracteristique pour la PS4: Bluetooth®v4.0, Qualcomm Atheros AR3002 Buetooth LE: 2,4-2,5 GHz 

Caracteristique de la connexion : 

*Vitesse de transmission >> 3 Mbit/s 8N1
*Relevé tous les 1.3 millisecond (peut-être)
*Chaque manette à une adresse unique BD_ADDR qui correspond à l’adresse MAC de la carte Réseau
*Protocole de détection est le SDP basé sur une emission reception PDU
*L’Attribut ID est representer en TLV Type Length Value
*Communication HCI ACL Data Packet

===Rélisation des cartes électroniques===

matériel nécessaire pour un PCB : 

*breadboard
*câbles
*1 x 10k Ohm résistance
*Quartz 16Mhz clock crystal
*2 x 22 pF capaciteurs
*Atmega328P-PU

Ressources:
[[https://www.arduino.cc/en/Main/Standalone]]
[[http://www.eprojectszone.com/atmega-328-pu-standalone/]]
[[https://www.arduino.cc/en/Tutorial/ArduinoToBreadboard]]

==Semaine 2==

Durant la semaine deux et durant la séance, nous avons continué et approfondie nos recherches sur le projet. Nous avons pu ainsi affiner nos taches de réalisation et donc notre cahier des charges.

===Connexion aux modules: SPI et Bluetooth ===

 CORRIGER

voir https://peip-ima.plil.fr/mediawiki/index.php/BE_2017-2018#Configuration_du_syst.C3.A8me_embarqu.C3.A9

(sudo apt-get install pi-bluetooth)

''connexion sur la raspberry par ssh:''
su
update-rc.d ssh enable
invoke-rc.d ssh start
ssh pi@172.26.79.1XX

''bluetooth''
bluetoothctl
agent on
default-agent
scan on
pair [device Bluetooth address] (exemple: pair XX:XX:XX:XX:XX:XX )

''NOUVELLE REFLEXION : Connexion SPI entre les modules (Atmega328p) et la RPi3 --> MODULES BLUETOOTH''

Si multi-esclaves= plusieurs modules :
Il faut ajouter des sélections pour les SPI → démultiplexeurs OU ne pas utiliser les CS0 et CS1, et plutôt des pins entrée/sortie de la RPi3 lié au SS comme ça on choisit direct le module esclave voulu.

'''IMPORTANT:''' Nous avons étudié à nouveau la datasheet de notre module bluetooth nrf de Nordik. Le module bluetooth comporte déjà un microprocesseur !
Un module plutôt peut donc jouer le rôle de notre atmega328p. Il n'y a alors pas besoin de réaliser des cartes électroniques de type arduino standalone. Nos PCB regrouperont alors uniquement l'alimentation, un actionneur (bouton, joystick), le module bluetooth et les broches de connexion si besoin...

Cette séance nous a alors permise de revoir entièrement le matériel nécessaire. Notre liste de matériel nous semble alors plus réfléchie et limitée au nécessaire.

===Connexion Bluetooth PS4-RPi3===

Suite à nos recherches de la semaine précédente, nous avons sélectionné deux sites bien renseignés :

SITES

Ils nous ont permis de comprendre la communication entre la manette et la console. En effet, ils nous expliquent les échanges de trames Bluetooth.
EXPLICATIONS 1 exemple 

==Semaine 3 : Début premier prototype==

===Connexion SPI RPi3-Arduino===

Comme vu durant les semaines précédentes, nous souhaitons réaliser une connexion Multi-esclaves en SPI entre la Raspberry pi et plusieurs modules.
Cette semaine nous avons vu que la réalisation de notre premier prototype doit aller vite. Il ne nous est pas nécessaire d’attendre les modules bluetooth si il nous faut dans cette partie uniquement utiliser son microprocesseur. Ainsi pour chaque module nous utilisons une arduino UNO. Nous réaliserons les programmes en C afin de pouvoir les réutiliser avec les modules bluetooth par la suite.
Une fois la connexion réalisable nous adapterons les programmes aux modules bluetooth Nordik. En effet, ceux-ci comporte déjà un microprocesseur, le module peut jouer le rôle de notre atmega328p. Il n'y a aurait alors pas besoin de réaliser des cartes électroniques arduino standalone sur PCB, mais directement des cartes électronique avec le module et le module voulu (bouton, joystick...) et l'alimentation.
Durant la séance nous avons alors revu la liste de matériel nécessaire.

[[Fichier: prototype1.jpeg||center|600px|connexion filaire prototype 1 filaire arduino]]

Durant la séance, nous avons recherches des exemples de codes et de librairies pour Arduino SPI et RaspberryPI SPI.

Nous avons également commencé le programme de la connexion SPI pour l'arduino et récupéré les bibliothéques SPI.h avec SPI.c. Nous nous sommes alors concentrer à les comprendre, pour pouvoir l'utiliser.

===Réalisation du projet Git===

Création du projet IMA4_Projet35_ManetteModulable sur Git et partage de celui-ci.
Les premiers dossier crées cette la séance :
-Arduino (connexion SPI arduino) : ProtoSpi.c + dossier librairie SPI + Makefile
-RPI (dossier codes pour Rpi)
-Readme.md
Ces dossiers seront amenés à être modifiés au cours des séances.

===Protocole Bluetooth PS4===

Suite à l'étude des trames Bluetooth, on a pu voir que ces dernières étaient incomplètes. Le modèle de communication étant propriétaire, on n'y a pas accès directement. Cela nous empêche donc de mettre en oeuvre cette communication.
 Déveloper

On a décidé de commencer par une connexion USB (pour laquelle on dispose de toutes les informations) celle-ci étant plus complète.

==Semaine 4==

Pour le prototype 1 FILAIRE nous réaliserons les étapes suivantes :

#Réalisation du programme SPI pour arduino
#Réalisation du programme SPI pour la RPi
#Connexion USB avec la PS4 ou ordinateur
#Réalisation de cartes électroniques atmega328p-pu standalone (remplacer les Arduinos)
#Remplacer les "PCB arduino" par le module bluetooth et adapter la connexion
#Conception 3D de la délimitation 1 axe pour le joystick "gâchette"
#Réalisation de l'application Androïde.

Une fois ces étapes réalisées nous auront alors une preuve de concept filaire et nous pourrons alors passer à une connexion bluetooth.
Le passage à la connexion bluetooth sera le deuxième prototype et le cas idéal de la réalisation de la manette modulable.

===Mise à jour Matériel===

- Modéliser les boutons gâchettes L1/2 R1/2 de la manette PS4 (boutons sensibles à la pression) --> un joystick dont nous bloquerons un axe (imprimante 3D)
- Remplacer la RPi 3 par une Rpi zero W qui nous permettrait de réaliser plus facilement une connexion USB tout en gardant l'avantage du bluetooth.
- Choix de l’alimentation pour les 5 modules Bluetooth: nécessitent 3V --> utiliser des piles rechargeables 1,2V AAA plutôt que piles rondes 3V.

Nous avons également besoin du matériel cité en semaine 1 pour réaliser des cartes électroniques atmega328p-pu standalone. ( nous revenons alors sur les décisions de la semaine 3)

===Connexion SPI RPi3-Arduino===

Montage Raspberrypi et 1 arduino en PSI + 1 bouton + 1 led.
Voici le choix des branchements :

MASTER = RPi
SLAVE= Arduino

'''SPI sur Arduino:'''
MOSI -> GPIO11 //PB3 //master OUT to the slave IN
MISO -> GPIO12 //PB4 //slave OUT to the master IN
SCLK -> GPIO13 //PB5 //serial clock
SS -> GPIO10 //PB2 //slave select
'''Led, bouton et autre...'''
LED --> GPIO6 //PD6
GND
+5V (if required)
'''SPI sur la Raspberry Pi'''
SPIO MOSI -> PIN19
SPIO MISO -> PIN21
SCLK -> PIN23
SPIO CS0 -> PIN24

Continuation du code pour faire clignoter Led branchée à une arduino depuis la Rpi, en connexion SPI.

===Connexion USB PS4-RPi3===
Durant cette, nous avons regardé comment faire cohabiter bluetooth, Application Androïd, USB, PS4, SPI et les module.

Il est alors important de savoir comment utiliser le port série sur la RPi3, soit utiliser les UART.

Nous avons réaliser qu'il n'était pas aussi simple d'utiliser le port serie USB de la Raspberry Pi 3, en effet le SoC est un BCM2837 .
De plus nous ne pouvons pas utiliser le même port pour l'alimentation et la connexion.

Il nous faut alors trouver une alternative ou une solution à ce problème.

==Semaine 5==

===Programmation: Réflexion définitives prototypes filaire ===

La semaine dernière, nous avons rencontré une difficulté liée aux ports séries UART.
Une des solutions à cette difficulté serait d'utiliser une RPi ZERO W à défaut d'une RPi 3. On pourrait alors avoir un port d'alimentation avec connexion USB mais également retrouver la connexion Bluetooth dont nous avons besoin.

Ensuite, nous avons continué la réalisation du prototype filaire par l'avancé du code SPI ainsi que les recherches concernant le protocole PS4.

La Raspberry Pi zero W peut également être utile pour la connexion entre la PS4 et les différents modules en jouant le rôle d'intermédiaire. Nous avons alors commandé une Rpi zero W pour notre projet.
En attendant la réception de la commande, nous nous sommes penché sur les recherches pour les programmes et la configuration nécessaire à l'utilisation de la RPi zero W.

===Electronique===

[[Fichier: bouton_c1.jpg|100px|thumb|left|PCB bouton]]
[[Fichier: arduinobb.jpg|200px|thumb|right|atmega328p-pu branchement test]]

Du coté électronique, nous avons réalisé sur fritzing certaines cartes électroniques. Les Arduino Uno servant actuellement de test, seront remplacées par des PCB atmega328p-pu standalone avec des broches permettant les branchements nécessaires SPI ou encore aux modules "boutons/joystick". Pour les boutons, nous avons également réalisé un pcb afin de faciliter les branchements.

Il nous faut alors également une 3eme carte qui nous sera nécessaire pour la réalisation du prototype sans fil. Dans notre liste de matériel, nous avons des composants nrf52810 bluetooth, ceci doivent être soudé avec les capacités de protection mais également des broches de communication. Nous avons alors commencé cette carte électronique sur Altium avec le fichier projet PCB du distributeur à modifier.

[[Fichier: Arduino_c1.jpg|100px|thumb|center|PCB atmega328p-pu]]

=== Construction 3D ===

Enfin, nous avons commencé à réaliser des boîtiers 3D pour certains modules. Par exemple, comme nous l'avions vu précédemment, un des joysticks servira de bouton-gâchette en utilisant un seul de ses axes. Il nous faut alors réaliser un boitier qui bloque l'un des axes, mais également une tige qui nous permettra de pousser le joystick de manière simplifiée.

==Semaine 6==

===Programmation: configuration RPi Zero W ===

Ayant reçu la Raspberry Pi zero W en début de semaine, nous nous sommes concentrés sur la programmation et la configuration de celle-ci.
Cette partie étant compliquée, elle nous a pris du temps. En effet, il était difficile de connecter la RPi en SSH car il n'est pas possible d'y connecter un clavier directement et on avait besoin de la prise OTG pour "interfacer" la manette.

===Electronique: PCB nrf52810===

Les cartes réalisées en semaine 5 sont validées et en attente de réalisation.

Cette semaine a permis la réalisation et la finalisation de la carte électronique nrf52810. Il nous a fallu recommencé cette carte deux fois. En effet, une fois finie sur Altium nous avons réalisé que les empreintes des CMS sur PCB fourni par le constructeur ne correspondent pas au matériel CMS de l'école. Face à cette inattention de notre part, nous avons décidé de refaire entièrement la carte électronique sur fritzing. Ayant la datasheet et des plans d'inspiration PCB, nous avons pu refaire la carte entièrement.
Sur celle-ci nous avons ajouté des broches de connexion au besoin, un branchement Jtag et ICSP pour la programmation et la connexion SPI.
La carte est en attente de validation, puis validation.

[[Fichier: nrf52810_circuit2.jpg||center|400px|PCB carte nrf52810]]

===Révision matériel ===

Pour la réalisation de nos composants électroniques, il nous a fallu faire une révision des composants disponibles à l'école:
(les quantités indiquées ci-dessous pourront être augmentée si nécessaire,pour avoir dans l'idéal un module de chaque type de la manette, ici on se concentre sur BOUTON et JOYSTICK)

'''Cartes Arduino:'''
* 4 capacite 22pF traversantes
* 2 resistances 10 kOhm traversantes (à récupérer)
* 2 oscillateurs quartz 16MHz traversante
* 2 atmega328p-pu et support

'''Cartes nrf52810'''
* 6 capacités 100nF 0603
* 6 capacités 12pF 0603
* 2 capacités 4,7pF 0603
* 2 capacités 1µF 0603
* 2 capacités 100pF=0,1nF 0603 (à récupérer)
* 2 capacités 0,8pF 0603 (commande en cours)
* 2 inductance 3,9nH 0603 (commande en cours)
* 2 oscillateur quartz 32 MHz

'''Cartes modules Boutons'''
* un sachet de broches mâles (qu'on utilisera également pour les autres cartes, à récupérer/acheté)

Nous avons alors mis-à-jour la liste de composant située plus haut, ainsi que celle de la page IMA4 2017/2018 [https://projets-ima.plil.fr/mediawiki/index.php/Projets_IMA4_SC_%26_SA_2017/2018]

==Semaine 7==

===Programmation: connexion wifi RPi Zero W et Bootloader sur Atmega328p-pu ===

Pendant cette semaine, nous avons continué la programmation et la configuration des Raspberry Pi 3 et Zero W. Concernant la configuration ssh, nous avons utilisé un téléphone en guise de point d’accès à la RPi Zero W en wifi.
Nous avons aussi directement configurer l'OS Jessie, utilisé pour la RPi Zero. On a modifié le fichier cmd.txt et ...pour pouvoir programmer un USB gadget sur le port OTG.
Ci-dessus expliquer fichiers

Nous avons également continuer les programmes de récupération de données : état des boutons et du joystick. Ces programmes sont appliqué sur l'atmega328p-pu standalone sur la plaque d'essai en attendant que le PCB soit opérationnel.
Pour pouvoir programmer l'atemega328p-pu comme une arduino UNO, il nous faut suivre plusieurs étapes :

'''1.Flasher le Bootloader'''
Nous avons 2 Atmega328p-pu neufs, ainsi il nous faut flasher le bootloader sur chacun d'eux afin de pouvoir les utiliser et les programmer sur une breadboard dans un montage minimaliste arduino-standalone.
Pour cela, on peut utiliser une carte arduino UNO. On vérifie le port et le type de carte sélectionnés dans le menu >Outils. Sur cette carte on téléverse le fichier arduinoISP.ino qui se trouve dans les exemples en étant en progrmamateur AVr ISP mkll (>outils>programmateur)
Puis on met l'atmega328p-pu qui nous intéresse sur le suppor socket de la carte. On change de nouveau le programmateur pour Arduino as ISP et on fait >tools>burn bootloader, soit >graver la sequence d'initialisation.
Ces étapes faites, on peut retirer notre microcontroleur et le replacer correctement dans le montage.

'''2.Programmation atmega328 sur breadboard'''
Une fois l'atmega328p-pu préparé, on peut le programmer. On peut le faire simplement à l'aide de la carte arduino UNO utilisée précédemment.On branche les Tx et Rx en commun ainsi que le reset, le GND et le VCC.

Nous avons réaliser des codes basiques tels que le clignotement d'une led rouge ou encore l'affichage de "hello world" sur le moniteur série pour vérifier la bonne fonctionnalité du montage. Cela fait nous avons pu écrire sous Arduino IDE le code de lecture des états.

[[Fichier: montage_BB_test.jpg||left|200px|programmation modules arduino sur breadboard]]

===Electronique : soudure carte de test modules ===

Comme nous l'avons déja vu lors de la réalisation des PCB, si l'on souhaite programmer un atmega328p-pu en bootloader, le montage est simple. Il peut être minimaliste en utilisant une arduino UNO, un atmega328, une breadboard et 3 composants: 1 quartz 16MHZ crystal, 1 résistance 10kOhm et 2 capacitors céramiques de 22pF.
Durant la semaine 7, nous avons soudé les composants traversants de la carte électronique correspondant à ce montage ainsi que le PCB du bouton.

==Semaine 8==

===Programmation ===
Après moult recherche sur les différents site web bien fournis pour le coups on as pu trouvé une amorce à la programmation de l'OTG via un script qui agit au niveau du kernel dans le sous dossier usg_gadget. Ce script donne les informations nécessaires pour pouvoirs échangé les données.
Avec le script trouvé et les informations des sites web décryptant les trames de la manette, on a toujours pas réussit à faire passer notre RPi Zero W pour une manette de PS4. Néanmoins il nous manque la trame HID complète de la manette pour avoir un test effectif.

===Electronique : Correction soudure et soudure CMS===

Durant cette semaine, nous avions souhaité programmer la carte électronique atmega328p-pu. Cependant, nous avons réaliser que nous avions fait une erreur lors de l'envoie du PCB à la production. En effet, celui-ci avait été fait en Top sur le logiciel Fritzing et non en Bottom. Hors nous avions soudé les composants (durant la semaine 7) comme pour un circuit imprimé en bottom, l'atmega328p-pu se retrouve alors inversé par rapport aux pistes.
Comme solution, nous avons choisi de souder un deuxième support pour l'atmega328 de l'autre coté de la carte avant de la refaire au propre. En effet, avant de la refaire il nous faut vérifier si la carte est bien programmable.
Une fois cela fait nous avions pu programmer la carte mais, nous avions également réalisé la pin 2 de l'atmega328 était prise par le bouton poussoir. Or, nous avons besoin des pin 2 et 3 pour le RX et TX permettant la programmation de l'atmega à partir d'une arduino, les pistes branchement RX-TX n'ont également pas été prévus pour le téléversement des programmes sur la carte. Il nous faut alors couper une piste et souder des câbles pour utiliser toutes les pistes souhaitées.

[[Fichier: correction_proto_PCB.jpg||right|300px|PCB arduino correction]]

Durant cette semaine, nous avons également souhaité souder les CMS et le composant bluetooth nrf52810 sur la carte imprimé et reçu lors de la semaine 7. Pour cela, nous avons convenu de travailler dans la C202 durant la séance du mercredi.

[[Fichier: PCB_nrf52810.jpg||left|400px|carte electroniques imprimées]]

====Comment souder des CMS ?====

les CMS sont des composants montés en surface c'est à dire qu'ils sont montés du même côté que les pistes cuivrées (à l'opposé des composants traversants) et sont de petite tailles souvent de l'ordre du millimètre. La taille est déterminée par 4 chiffres : les 2 premiers pour la longueur et les 2 derniers pour la largeur. On a du 1206,0805,0603 ou encore 0402. Il est même possible de trouver plus petit. A l'école nous utilisons souvent du 0603, c'est le cas de nos composants.
Pour souder des CMS 0603, il nous faut utiliser une autre méthode qui n'est pas le fer à souder :
# Préparer la veille la pâte à braser la veille (dans une seringue)
# Gommer la carte pour éviter l'oxydation (attention à ne pas retirer les miettes de gomme en soufflant dessus)
# Appliquer avec la seringue la pâte sur les empreintes et piste souhaitées. Pour les endroits difficile à atteindre ou avec 2 pistes proches les unes des autres, il est possible de mettre la même goutte de pâte sur les 2 pistes. Cela de causera pas de court-circuit par la suite. En effet, la pâte est composée d’alliage qui sous la chaleur va se fluidifier et se coller uniquement aux pistes métallique. Le reste fondera sous la chaleur du four.
# Appliquer les CMS sur la pâte au fur et à mesure (attention ! ne jamais toucher les CMS avec les doigts, tjrs utiliser une pince)
# Mettre au four

====Bilan soudure nrf52810====

Cependant, une fois le matériel nécessaire préparé, et la pâte mise sur les pistes souhaitées, au moment de déposer le composant, nous avons réalisé que celui-ci était beaucoup plus petit que l'empreinte sur le PCB. Il s'agit d'un composant boitier QFN48. Fritzing ne proposant au plus proche des boitiers QFN24 ou LQFP48, celui-ci a basculé automatiquement pour un boitier LQFN48, de dimension plus grande. Face à ce manque de vigilance, nous avions cependant commencer par le nrf52810 (composant concerné) évitant ainsi de gaspiller d'autres CMS.
Nous avons souhaité refaire la carte sous Altium à partir des fichiers fournis par le concepteur (chose que nous avons commencé à faire aux alentours de la semaine 5)
Après la réalisation du schématic, et de la modification des empreintes de capacités, inductances et autres composants de 0402 à 0603. Notre matériel ne permettant que des empreintes 0603.

Lors du routage, une erreur de chevauchement des pistes est notifiée par Altium au niveau du nrf52810. Celles-ci ne présentent pas d'angles et sont déjà de taille 8mil, il nous faut alors passer les pistes en 6mil. Mais 8mil est la taille minimale pour la production à Polytech, nous avons regardé pour envoyer les cartes à faire ailleurs mais le 6mil n'est pas beaucoup conseillé. De plus, il n'est peut-être pas judicieux de continuer avec le composant microcontrôleur-bluetooth Nrf52810 qui prend du temps, donc la carte est difficilement réalisable et peut-être très long à programmer.

Ainsi en cette fin de semaine, nous avons décider face à l'avancer du projet de laisser les nrf52810 de coté et de les remplacer par des modules sans fils plus simples d'utilisation et complets. Ainsi nous aurions plus de chance d'avoir une connexion sans fils entre les modules. Nous pourrions par exemples utiliser des Xbee, des modules Rf...

==Semaine 9==

====Programmation: PS4 et 1er Test SPI sur atmega328p====

'''Raspberry Pi Zero W et PS4'''

Les premiers tests sur Windows ne nous donner pas satisfaction. En effet, l'ordinateur détectait bien le nouvel appareil avec son nom mais l'origine rester inconnue.

Lors des tests sur Linux on a pu voir des erreurs via la commande 'dmesg' :

[193229.758782] usb 4-1.2: new high-speed USB device number 6 using ehci-pci
[193230.270780] usb 4-1.2: new high-speed USB device number 7 using ehci-pci
[193235.510842] usb 4-1.2: device descriptor read/64, error -110
[193251.127043] usb 4-1.2: device descriptor read/64, error -110
[193251.315043] usb 4-1.2: new high-speed USB device number 8 using ehci-pci
[193256.503135] usb 4-1.2: device descriptor read/64, error -110
[193272.119331] usb 4-1.2: device descriptor read/64, error -110
[193272.307331] usb 4-1.2: new high-speed USB device number 9 using ehci-pci
[193282.999473] usb 4-1.2: device not accepting address 9, error -110
[193283.079485] usb 4-1.2: new high-speed USB device number 10 using ehci-pci
[193293.751588] usb 4-1.2: device not accepting address 10, error -110
[193293.751771] usb 4-1-port2: unable to enumerate USB device
[193387.196861] usb 4-1.2: new high-speed USB device number 11 using ehci-pci
[193392.440941] usb 4-1.2: device descriptor read/64, error -110
[193407.933152] usb 4-1.1: new high-speed USB device number 12 using ehci-pci
[193413.177227] usb 4-1.1: device descriptor read/64, error -110

'''Modules Atmega328p et SPI'''

Une carte PCB arduino fonctionnant, nous pouvons la programme pour simuler un module. Celle-ci a été designée afin de s'adapter au module que l'on souhaite. Il suffit de brancher le bouton, le joystick ou autre élèment de manette souhaité.
Cette semaine ci, nous avons alors configurer la partie communication SPI pour l'arduino.

'''Que voulons-nous faire avec les atmegas ?'''
Les cartes électroniques atmega328p vont nous permettre de recevoir les requêtes SPI envoyées par la raspberry pi et d'y répondre. La Raspberry enverra un message, par exemple "1", et l'Arduino lira alors l'état du module qui lui est connecté. Une fois l'état récupéré elle le renvoie à la raspberry pi.

Durant cette semaine, nous avons programmé l'atmega afin qu'il soit en esclave, qu'il reçoive un de la RPi "1" et retourne une valeur sauvegardé "int envoi". Nous avons également commencé les tests pour la lecture de l'état d'un bouton (d'après les tests réalisés les semaines précédentes).

'''Code'''
Comme nous l'avons vu précedement lors de nos recherches (semaines 1 à 4) :
La communication SPI nécessite l'utilisation des pins:

MOSI -> GPIO11 //PB3 //master OUT to the slave IN
MISO -> GPIO12 //PB4 //slave OUT to the master IN
SCLK -> GPIO13 //PB5 //serial clock
SS -> GPIO10 //PB2 //slave select

Il faut également paramétrer l'atmega328p en Slave. On note que dans un premier temps, le programme sera codé avec l'arduino IDE (fichiers .ino). Une fois l'ensemble SPI RaspberryPi-Arduino fonctionnant, on remplacera ces codes par du langage C ou C++.

Pour faire la connexion SPI sur l'atmega328p, on utilise la librairie arduino SPI.h, on a alors directement les fonctions nécessaires intervenant sur les registres souhaités : SPCR (spi control register), SPSR (spi status register) et SPDR (spi data register).

#include <SPI.h>

Il est important d'initialise d'abord le setup et on active le port série pour pourvoir utiliser le moniteur série. (Cela servira à verifier la valeur envoyée par la RPi)

void setup (void)
{
Serial.begin (9600);
pinMode(MISO, OUTPUT); //configuration en esclave *master in slave out*
pinMode(buttonPin,INPUT); //config pin bouton
// turn on SPI in slave mode
SPCR |= _BV(SPE);
// preparation interruptions
pos = 0; // buffer empty
process_it = false;
// activation interruptions
SPI.attachInterrupt();
}

On oublie pas de déclarer les interruptions afin de bien lire la requête reçue.

// SPI interrupt routine
ISR (SPI_STC_vect)
{
byte c = SPDR; // grab byte from SPI Data Register
// add to buffer if room
if (pos < sizeof buf)
{
buf [pos++] = c;
// example: newline means time to process buffer
if (c == '\n')
process_it = true;
} // end of room available
} // end of interrupt routine SPI_STC_vect

Dans la loop main, on traite la requête et on utilise '''SPI.transfer(envoi);''' pour transferer à la RPi les données souhaitées.

Durant cette semaine, nous avons également commencé des programmes de test SPI pour la RPi. Il s'agit principalement de programmes de tests tout faits permettant de vérifier la connexion entre cette dernière et l'arduino. Par exemple, la RPI envoie "bonjour" et l'arduino lui retourne ce qu'elle reçoit, soit "bonjour". Sans succés alors.

====Electronique : Fritzing révision====

Lors de la semaine, le modèle PCB de la carte arduino a été réalisé de nouveau sous fritzing avec les broches et connections manquantes. Nous avons également revu la configuration du bouton reset et ajouté une led d'état de l'alimentation. Nous avons ainsi envoyé deux cartes identiques à la réalisation.
La carte déjà soudée lors des derniers jours fonctionnant, elle nous sert de prototype de programmation. Nous pouvons ainsi avancer à la fois sur la programmation des modules mais aussi sur leur réalisation.

==Semaine 10==

====Programmation : PS4 et SPI sur RPi====

'''Raspberry Pi Zero W et PS4'''

'''Modules Raspberry PI et SPI'''

Durant cette semaine, pour la partie Atmega328p-Modules, nous nous sommes concentrés sur la programmation de la communication SPI avec la raspberry pi. Cette semaine a permis une étude plus approfondit sur le fonctionnement pour la RPi.

On rappelle, comme vu des semaines 1 à 4, pour la RPI3 (tout comme la RPi Zero W) utilise les broches : SCLK (23), MISO(21), MOSI (19) et SPI CS0 (24), SPI CS1 (26).
On la programme en Master. A l'aide des fichiers tests d'inspiration, on pourra directement programmer la RPi en C. Lors de la réalisation du code, il y a 3 étapes : l'initialisation/parametrage en SPI pour être maître, l'envoie de la requête puis la réception de données en retour.

Programmant en C, il ne faut pas oublier les librairies suivantes :

#include <stdint.h>
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
#include <getopt.h>
#include <fcntl.h>
#include <sys/ioctl.h>
#include <linux/types.h>
#include <linux/spi/spidev.h> //pour SPI

On va déclarer des variables globales permettant le paramétrage :

static const char *device = "/dev/spidev0.0"; //si on veut CS0 pour atteindre notre SS
static uint8_t mode; //mode est par défaut à 0
static uint8_t bits = 8; //bits par mot échangé
static uint32_t speed = 500000;
static uint16_t delay;

Dans notre main, on ouvre le port (la connexion) au device souhaité, on vérifie les paramètres (registres, connexions...) puis exécute la fonction transfer(fd). transfer(fd) transmet la requête et s'occupe de la réception.

fd = open(device, O_RDWR);
transfer(fd);
close(fd);

==Semaine 11==

====Programmation: PS4, SSH et tests SPI (RPi3&Atemga328p)====

'''Raspberry Pi Zero W et PS4'''

'''Raspberry PI, Atmega328p et SPI'''

Afin de facilité la programmation en utilisant Ethernet, nous avons installer et configuré la RPi pour l'utiliser en SSH depuis les ordinateurs de la E306. En effet, SSH permet de se connecter à distance sur une machine en utilisant un compte utilisateur de la dite machine. En mettant ssh, on pourra directement agir sur les fichiers de la raspberry depuis un terminal de notre PC. Pour cela, on a d'abord vérifier l'adresse IP de notre raspberry pi : 172.26.145.106 avec un écran mais on peut aussi utiliser les commandes ip a et ifconfig. Puis activer le ssh sur la raspberry pi.
On modifie alors le fichier config.txt mais également etc/network/interfaces pour configurer la bonne interface Ethernet sur la raspberry pi.

[[Fichier: configSSH_raspi.png||left|300px|config ssh ethernet]]

Il nous suffit alors de taper la commande : ssh pi@172.26.145.106 pour accéder à notre RPi.

Nous avons continué à réaliser la communication SPI avec des tests entre une arduino UNO et la RPI3. Nous avons commencé par des tests simples inspirés des études de deux semaines précédentes et modulés selon notre utilité.
Nous arrivons alors à lire l'état envoyer "bonjour" et recevoir "ça va" ou encore "1" et recevoir "3". Il faut noter que le SPI échange des trames, la RPI reçoit alors des hexadécimaux.
Nous avons alors continué pour recevoir l'état du bouton ou du joystick lors de l'envoie de "1" sur l'Arduino328p. La semaine prochaine nous testerons ces même codes fonctionnels sur les cartes atmeg327p.

A la fin de cette semaine, nous avons alors des codes Arduino-SPI (.ino) et des codes Raspberry-SPI (.c) permettant l'échange de données. Le but est maintenant de l'adapter aux cartes imprimées et de le rendre pleinement fonctionnel pour plusieurs cartes à la fois, puis ajouter une boucle de vérification en continue jusqu'à une deuxième requête de la RPi.

====Electronique: réalisation au propres des PCB modules====

Suite à une nouvelle erreur de réalisation cartes électronique, nous avons refait et renvoyé à nouveau les cartes imprimées atmega328p.
Nous les souhaitons au propre pour une version finale. Une fois celle-ci imprimées nous pourrons en avoir 3 , un pour chaque module. Les cartes étaient bien imprimées en bottom mais lors du passage des traversants de bottom à top, le logiciel ne les a pas fait miroiter. Par manque d'attention nous avons alors envoyé les fichiers gerber pour des cartes ayant les composants du même coté que la couche de cuivre.
Les cartes électroniques actuelles sont alors correctes et fonctionnelles mais difficile à souder. Pour eviter les erreurs et continuer sur des prototypes de carte nous préférons attendre en nous concentrant sur la programmation PSI de la Raspberry Pi.

==Semaine 12==

====Programmation====

'''Raspberry Pi Zero W et PS4'''

'''Raspberry PI, Atmega328p et SPI'''

- réflexion: penser à faire boucler sur l'arduino une fois la requête reçu, ça veut dire que la manette est ON et donc vérifier continuellement les modules sur chaque atmega.
- SPI raspberry pi - arduino recuperation état du bouton avec les cartes modules (/!\ récuperation à faire dans une variable)

-SSH perso
adresse Rasppi: 192.168.137.10

====Electronique: Finalisation soudure Modules====

Soudure au propre et finale d'une carte atmega328p et donc envoie pour la réalisation de 2 autres cartes similaires et récupération de matériel
Soudure des 2 autres cartes, + tests sur les états = fonctionnelles.
On a donc bien 3 cartes pour les 3 modules de types différents (1 bouton, 1 joystick, 1 gachette)
PCB pour les 2 joysticks (qui serviront de thumbstick et gachette)

==Semaine 13 et plus==

====Programmation====

'''Raspberry Pi Zero W et PS4'''

'''Modules Atmega328p et SPI'''

====Electronique====

=Documents Rendus=

(à mettre rapport + git + drive)

=Datasheets=

IMA4 2017/2018 P35

2018-05-05T19:58:47Z

Tgracias : /* Programmation */

__TOC__
 

=Présentation générale: Manette modulable=

==Description==

Tout le monde joue aux jeux vidéo cependant, les manettes ne sont pas adaptées aux personnes ayant un handicap pouvant toucher les bras ou les mains.
C’est le cas, de plusieurs patients dans les centres de soins et de rééducation.

Pour ce projet IMA4, nous travaillerons avec le centre SSR (soin de suite et de réadaptation) Marc Sautelet de Villeneuve d’Ascq.
Un adolescent, patient de Marc Sautelet, est passionné par les jeux vidéo. En effet, ayant perdu la motricité d’une partie de son corps, il ne peut pas jouer à deux mains. Pour cela, il bloque la manette entre son épaule et son coude, usant de la mâchoire et des doigts pour contrôler les
joysticks et les boutons. Cet exercice peut s’avérer fatiguant et pénible.

Ainsi, nous chercherons à concevoir une manette PS4 adaptée au handicap de l’adolescent.
Cette manette devra aussi être adaptée pour d’autres patients présentant également des handicaps moteurs. Ainsi nous prendrons pour cibles: tous les patients du centre voulant jouer; et non pas que les enfants et adolescents.

 

{| class="wikitable centre" width="80%"
|+
|-
| width="23%" |
Membre du projet
| width="34%" |
Transley Gracias et Camille Saad
|-
| width="23%" |
Cible
| width="34%" |
Patient présentant un handicap moteur
|-
|width="23%" |
Période du projet
| width="34%" |
janvier 2018 - mai 2018
|-
|width="23%" |
Partenaire/Client
| width="34%" |
Centre SSR Marc Sautelet à Villeneuve d'Ascq
|}

==Objectifs==

Ce projet a pour objectif de créer un prototype de manette qui puisse interagir avec la console PS4 et dont le paramétrage se fait à l’aide d’une application mobile et/ou web. Cette manette devra suivre les demandes du patient ainsi que des aides-soignantes du centre, dans la mesure du possible.

Plus précisément, pour le premier prototype, nous mettrons en œuvre l'utilisation de quelques boutons spécifiques:

* Un joystick (type L/R)
* Quelques boutons poussoirs (type Croix/Triangle/Carré/Rond/R1/L1/Start/...)
* Des boutons gâchettes progressives (type L2/R2).

Le but serait donc dans un premier temps de rendre fonctionnel un bouton de chaque type, puis de les multiplier une fois cela fait. Tous ces boutons réunis constituent une manette fonctionnelle.Ainsi, la manette sera ajustable, c’est à dire qu’elle devra s’adapter aux différents handicaps moteurs possibles.

=Analyse du projet=

==Positionnement par rapport à l'existant==

Notre prototype aura une présentation unique par rapport à l’existant. En effet, les concurrents et produits existants ciblent pour la majorité un seul handicap. Cela
engendre une solution fermée à beaucoup de patients. Notre projet propose une mobilité des mouvements et également un choix large dans la composition et le
design de notre manette.
Le patient n’est pas retreint à jouer à une seule main, à utiliser beaucoup de force...Il y a moins de technique dans la manipulation et on ne joue pas avec une
manette adaptée uniquement pour un droitier ou un gaucher. Cependant, cela nous limitera peut-être dans le choix possible des types de jeux. Tout comme les autres
manettes adapté, l’utilisateur nécessitera un peu d’entrainement.

==Analyse du premier concurrent==

Jouer aux jeux vidéo à une main n’est pas une idée d’aujourd’hui. En 1990, Nintendo propose le Power Glove. Mais il tombe très rapidement aux oubliettes suite à des problèmes techniques.

Un autre gant a fait son apparition quelques années plus tard. Celui-ci, plus technique, il faut office de manette Play Station: le Reality Quest Power Glove.Cette idée de manette-gant, permet de jouer à la PS avec une seule main, elle a était conçue et présentée pour les E3, un salon d’exposition de gaming.Le gant est conçu pour contrôler l’équivalent des 14 boutons et 2 joysticks à l’aide d’une seule main. La « manette » est fixée dans la pomme de la main. L’utilisateur contrôle les mouvements verticaux et horizontaux en pivotant le poignet, et utilisent les 4 boutons d’action principaux et L1/R1 avec les doigts. Les autres boutons sont accessibles par un seul bouton rond contrôlé par le pouce.
La manette est adaptée pour beaucoup de jeux vidéo, dont les plus simples sont les jeux de voitures et de combats (arcade).

; Problèmes:
*Besoin de toute la motricité de la main, c’est-à-dire que si le patient à un doigt paralysé ou manquant, il ne pourra pas jouer avec ce gant
*Design obligatoirement droitier
*Les boutons de contrôle sont peu sensibles et peuvent nécessiter de la force
*Design compliqué et nécessitant beaucoup d’entrainement.

;Lien : https://www.youtube.com/watch?v=qV0SxSJDCYg

 
==Analyse du second concurrent==

Ben Heck, de son vrai nom Benjamin J.Heckendorn, est un concepteur de mods de consoles (mods pour modification, soit « manettes modifiées ») et une star
du net grâce à ses vidéos tutoriels.Il propose alors énormément de produits adaptés ou dérivés en guise de manettes.
Parmi les mods qu’il a réalisé, il a modifié une manette de PS4 afin de la rendre accessible à une personne ne pouvant jouer qu’à une main. Pour cela, il a déplacé les boutons en respectant l’ergonomie de la main valide et modifie les connexions. Il peut lui arriver de rajouter des boutons pour en remplacer un autre. Il réalise également le même système avec la Xbox. Sur la photo ci-dessous, il a adapté la manette pour un droitier.

; Problèmes:
*Besoin de toute la motricité de la main, c’est-à-dire que si le patient à un doigt paralysé ou manquant, il ne pourra pas jouer avec cette ma
*Design obligatoirement droitier ou gaucher, une modification = une manette= une personne
*Besoin obligé du pouce et de l’index, même si avantage : 3 doigts nécessaire.

;Lien :: https://www.youtube.com/watch?v=LieHIscadjk

==Scénario d'usage du produit ou du concept envisagé==

La technologie est ,aujourd’hui, omniprésente dans notre vie. Les consoles de jeux ont envahies les maisons avec plus de 7 personnes sur 10 jouant aux jeux vidéos sur consoles en France (chiffre de l’Express). 0,18% des français sont handicapés cela représente 12 millions de français. Dans ce chiffre, 13,4% des personnes ont un handicap moteur. En 2017, les grands groupes comme Sony ou Microsoft avec respectivement PlayStation et Xbox ne permettent pas à tout le monde de jouer avec une manette. Les manettes sont prévues pour des personnes ayant leurs membres valides, plus précisément les mains et les bras.

Après un accident de voiture, un jeune garçon a perdu la motricité d’un côté du corps. Passionné de jeux vidéo, il se retrouve avec des difficultés à jouer sur sa console PS4. Ingénieux, il utilise la manette en la coinçant entre son épaule et le creux du cou. Usant de la mâchoire et de sa main valide pour contrôler les joysticks et les boutons. L'exercice étant inconfortable et fatiguant il eu l’idée de proposer à des futurs ingénieurs de lui proposer une manette adaptée à son handicap.

Les deux pré-ingénieurs ,avec leur tuteur, ont une idée révolutionnaire : La manette modulable ! Elle permettrait au jeune garçon, ainsi que d’autres joueurs, de pouvoir continuer de s’amuser ou même de commencer à jouer au jeux sur console.
Cette manette aidera fortement dans les centre de rééducation pour faire passer le temps et donner du plaisir à des personnes qui ne peuvent plus s’amuser avec leur console traditionnelle. Elle pourra aussi ouvrir de nouvelles possibilités pour certaines personnes qui n’auraient jamais essayé jusqu'à présent.
Comme son nom l'indique, elle sera modulaire et s'adaptera à différents handicaps. Accompagnée de son application d’initialisation, elle sera accessible aussi bien aux enfants, patients, parents et aides soignantes.

Quelques mois plus tard...Le jeune patient fan de Need For Speed, peut maintenant piloter sa voiture comme un vrai professionnel grâce à l'un des joysticks qu'il utilisera avec sa main valide et il pourra accélérer à des vitesses folles à l'aide de boutons poussoirs au niveau de son pied valide et gagner la partie. Son ami venu lui rendre visite, pourra en lieu et place des aides soignantes configurer à l'aide de la tablette (portable) la manette du patient.
Si le patient change de jeu pour Tekken et que la configuration des modules ne lui convient plus, il peut interchanger les éléments de la manette selon son envie et son confort. Ainsi il peut faire sauter son personnage, il utilisera un module bouton supplémentaire, qu'il actionnera avec le poing.

==Fonctionnement==

Suite à une analyse fonctionnelle et à la formulation de notre projet, nous avons pu définir le fonctionnement de notre système. Notre produit, la manette, doit être accessible d’après nos objectifs à différents types de handicaps moteurs. Ainsi, l’idéal serait de concevoir une manette modulable afin qu’elle puisse s’adapter à toutes les situations. Ce n’est plus au patient de s’adapter à la manette mais à la manette de s’adapter au patient.
Cela signifie que la manette sera, dans la limite du possible et de la sensibilité du corps du patient, composée de plusieurs parties dites « modules » comportant un ou plusieurs actionneurs (boutons, joysticks, gâchettes...). Ces modules seront déplaçables afin d’être utilisé avec différents membres du corps : un doigt, une main,
une jambe ou même un pied. Il suffira de les connectés entre eux suivant l’organisation souhaitée, le Gameplay du jeu ou en fonction du handicap. Le tout sera relié à une application.
L’application sera alors mise en place pour connecter les différentes parties du point de vue software pour prérégler la manette en fonction du patient. Il pourra alors choisir les boutons en fonction du jeu, de ses mouvements mais aussi choisir la sensibilité.

L’application et les modules devront être intuitifs et faciles d’utilisation. De cette manière des utilisateurs non avertis dans le domaine informatique ou jeunes pourront eux-mêmes gérer les connexions.

==Réponse à la question difficile==

'''Question : Comment interconnecter les différents modules de la manette ?'''

Il nous faut pour ce projet interconnecter les modules modélisant la manette qui seront connectés à la consoles PS4 via une Raspberry Pi 3.
Le choix de la Raspberry Pi 3 nous permet d'utiliser son module Bluetooth pour communiquer avec la PS4, ce choix est plus adaptée au projet que du filaire.
Concernant l'interconnexion des modules, nous travaillerons en deux étapes "preuves concept" : filaire et sans fils (Bluetooth).

'''Objectif 1 : Preuve concept filaire'''

Dans cette première partie de projet, nous souhaitons avoir une 1ère preuve de prototype rapidement. Nous nous concentrerons alors sur la communication entre la RPi3 et la PS4 ainsi que sur la conception des modules. Pour les modules, nous réaliserons des cartes électronique pour chaque module avec un micro-contrôleur. La communication filaire nous permettra d'interconnecter les modules à la RPi3 avec un bus SPI.

'''Objectif 2: preuve concept sans fils'''

Une deuxième étape du projet est la réalisation de la solution idéale sans fils. Celle-ci pourra commencer à être développée petit à petit en parallèle avec l'objectif 1. Le but ici, est d'interconnecter les modules en Bluetooth. Nous avons choisi le Bluetooth pour garder une connexion commune sur toute la chaîne.
Nous rajouterons alors un module bluetooth à chaque module de la manette.

'''Objectif 3: possibilité d'adapter les boutons (capuchon en 3D)'''

=Préparation du projet=

==Cahier des charges==

''Chef de projet:'' Alexandre Boé 
''Responsables:'' Xavier Redon, Thomas Vantroys 
''Partenariat:'' Marc Sautelet (non etablie) 
''Elèves-ingénieurs:'' Camille Saâd, Transley Gracias 

'''Sujet :''' Manette modulable pour personne à déficience moteur compatible PlayStation 4 

===Objectifs principal (1er POC) : ===
Faire transmettre des informations issus des actionneurs (ex:boutons poussoires) via des arduinos jusqu’à la Raspberry Pi 3 en SPI. 
Envoyer les données reçues vers la PS4 en USB 

===Objectifs secondaire (2e POC):===
Créer des modules avec un microcontrôleur et une puce bluetooth pour permettre une meilleurs flexibilité (c-àd pouvoirs avoir une meilleure ergonomie et une connexion sans fil) 
Connecter la Raspberry Pi 3 en Bluetooth à la PS4 

[[Fichier: beteacorne.jpg||middle|600px|Bete a corne manette]]

==Choix techniques : matériel et logiciel==

===Liste de matériel :===

'''Modules boutons/joysticks/gachettes'''

3 Push buttons : 
- O X Y Carré R3 L3 
- Guide PS 
- start/back 
--> 0,45€/unité TTC [https://www.gotronic.fr/art-bp-miniature-krs1273-16976.htm] 

1 Thumbstick original: 
Joystick analogique 4 directions --> 4,25€/unité TTC [https://www.gotronic.fr/art-joystick-analogique-4-directions-19063.htm] 

1 buttons trigger L1 L2 => 1x Thumbstick original''' 

'''Cartes Atmega328p /connexion spi/'''

3 Arduino UNO 
1 Arduino UNO atmega328p retirable 
4 capacite 22pF traversantes 
2 resistances 10 kOhm traversantes (à récupérer) 
2 oscillateurs quartz 16MHz traversante 
2 atmega328p-pu et support 

'''Cartes module bluetooth nrf52810 '''

6 capacités 100nF 0603 
6 capacités 12pF 0603 
2 capacités 4,7pF 0603 
2 capacités 1µF 0603 
2 capacités 100pF=0,1nF 0603 (à récupérer) 
2 capacités 0,8pF 0603 (a acheter, commande en cours) 
2 inductance 3,9nH 0603 (a acheter, commande en cours) 
2 oscillateur quartz 32 MHz 

''' Connexions et autres '''

1 Led RGB neopixel [https://www.adafruit.com/product/1734] 
1 Raspberry Pi 3 
--> ~36,23€/unité TTC [https://fr.rs-online.com/web/p/processor-microcontroller-development-kits/8968660/?src=raspberrypi] 
1 Raspberry Pi Zero W (commandée) [https://www.raspberrypi.org/products/raspberry-pi-zero-w/] 
6 Alimentations 5V ou 3,3V 
par exemple, 12 piles de type CR2016 3V rechargeables ou 24 piles AAA 1,5 V rechargeables
5 modules Bluetooth nrf de Nordic : nRF52810-QFAA-R 
--> 3,17€/unité + frais expédition [https://www.mouser.fr/productdetail/nordic-semiconductor/nrf52810-qfaa-r?qs=sGAEpiMZZMve4%2FbfQkoj%252bG%2FosjLoe2oghFQwQllMrQ4%3D]
5 Lignes broches mâles 

===Logiciels:===

- IDE arduino
- Altium
- FreeCAD ou Inkscape

==Liste des tâches à effectuer==

'''Etape 1 : Gestion du projet'''

* Définition des cahiers des charges fonctionnel et technique, choix d'orientation...
* Recherche techniques sur les différentes connexions possibles entre les modules, la RPi 3 et la console PS4
#Recherche connexion SPI entre les modules et la RPi3
# Recherche connexion bluetooth entre la RPi3 et la PS4
# Recherche connexion bluetooth pour les modules
# Recherche carte avec montage Atmega328P-PU et anticipation module bluetooth
* Détermination du matériel nécessaire
* Réflexion sur l'application

'''Etape 2: Réalisation du projet'''

'''Partie 1: Preuve concept manette en filaire'''

* Conception de cartes électroniques pour 2 modules (/!\ prévoir modules bluetooth)
* Réalisation connexion SPI avec 2 modules : programmation des Atmega328p en liaison série.
* Si tests concluant, ajouter des modules jusqu'à en avoir 5 (1 pour chaque type de boutons)
* Connexion bluetooth entre la PS4 et la RPi3
* Réalisation du support des modules avec fixations possibles (imprimante 3D)

'''Partie 2: Preuve concept manette en bluetooth'''

* Ajout des modules bluetooth aux cartes électroniques
* Connexion bluetooth entre les modules

'''Partie 3: Application Android : paramétrage de la manette'''

* Créer une application sur tablette ou smartphone (Android) afin de configurer la manette aux besoins (inter-connexion des modules et console)

==Calendrier prévisionnel==

{| class="wikitable centre" width="80%"
|+
|-
| width="23%" |
'''Date'''
| width="34%" |
'''Tache à réaliser''' 
|-
| width="23%" |
17/01/18-24/01/18
| width="34%" |
Faire des recherches sur les différentes interconnexions du système : Bluetooth, RPi-Atmega328 (SPI), RPi-PS4
Continuer liste des taches, matériel, Début recherches + réflexion fixation support des modules
|-
|width="23%" |
31/01/18
| width="34%" |
Recherche technique connexion PS4-RPi3 et connexion SPI RPi3-Module + code
|-
|width="23%" |
31/01/18-07/03/18
| width="34%" |
Réalisation 1er prototype (+ début prototype 2)
|-
|width="23%" |
07/03/18
| width="34%" |
Seance 7 : Test prototype filaire
|-
|width="23%" |
07/03/18-09/05/18
| width="34%" |
Réalisation 2eme prototype + application Android
|-
|width="23%" |
09/05/18
| width="34%" |
Seance 14 : Test prototype Bluetooth
|-
|width="23%" |
14/05/18
| width="34%" |
Video projet
|-
|width="23%" |
15/05/18
| width="34%" |
Finalisation projet et Rapport
|-
|width="23%" |
16/05/18-17/05/18
| width="34%" |
Soutenances Projet
|}

=Réalisation du Projet=

==Feuille d'heures ==

Voici le tableau d'heures du binôme:

{| 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 S11 !! Heures S12 !! Heures S13et+ !! Total
|-
| Analyse du projet
| 10
| 2
| 1
| 1
| 1
|
|
|
|
|
|
|
| 20min
|
| 15h20
|-
| Cherches techniques
|
| 3
| 4
| 4
| 2
| 2
| 1
|
|
|
| 1
| 1
|
|
| 18
|-
| Rédaction du wiki et rapport de projet
|
| 1
| 1
| 1
| 1
| 30min
| 1
|
| 2
| 30min
| 30min
|
| 2
|
| 10h30
|-
| Programmation
|
|
|
|
| 3
| 2
| 3
| 5
| 4
| 7
| 8
| 6
| 5
|
| 43
|-
| Cartes électroniques
|
|
|
|
|
| 6
| 8
| 4
| 6
| 2
| 1
| 2
| 2
|
| 31
|-
| Application
|
|
|
|
|
|
|
|
|
|
|
|
|-
|-
| Total Semaine
| 10
| 6
| 6
| 6
| 7
| 10h30
| 13
| 9
| 12
| 9h30
| 10h30
| 9
| 9h20
|
| '''117h50'''
|}

==Prologue==

Avant la réalisation et conception d'un projet, il est important d'analyser celui-ci. Nous avons allons consacré le prologue à l'analyse fonctionnelle de la manette. Nous avons également eu une réflexion sur l'analyse technique, cela nous a permis de réaliser une liste de matériel. Il est important de définir les objectifs ainsi que les besoins afin de ne rien oublier. (Voir ci-dessus Analyse projet)
Nous avons également organisé notre travail, pour le partage de documents de recherches et la rédaction de compte-rendu final nous avons réalisé un google drive. Par la suite, nous créerons un projet Git.

Durant ce temps, nous avons décidé de réaliser 5 modules. Les modules sont les différents boutons de la manettes qui nous pourrons placer selon nos choix (boutons modulaires) pour notre prototype projet pour chaque type des boutons d'une manette PS4. Ces modules devrons être connectés à la console et interconnectés. Le tout sera lié à une application Android. Suite à quelques recherches et nos analyses, nous avons décidé les points suivants :

- On commencera avec 2 modules et on les multipliera par la suite.
- Les premiers tests sont réalisés avec des boutons petits pour assurer leur caractéristique "modulaires", par la suite nous pourrons ajouter des capuchons de taille plus importante (imprimante 3D ou achat)
- Conception modules : réalisation de carte avec un microcontrôleur atmega328 programmable pour chaque module (anticiper le module Bluetooth)
- Projet en 2 parties : prototype filaire et prototype Bluetooth
# Prototype filaire : connexions entre les modules et la RPi3 en SPI, connexion Rpi3-PS4 en Bluetooth, avec l'application en filaire à la RPi3
# Prototype Bluetooth: connexion Bluetooth entre modules-RPi3-PS4-apllication

[[Fichier: structuremanette.png||center|400px|Concept manette modulable]]

==Semaine 1==

Durant la séance, nous nous sommes concentrés les recherches afin de définir clairement le cahier des charges technique. Il s'agit des réalisations à mettre en œuvre pour les inter-connexions des éléments de la manette.
Ainsi, nous avons fait des recherches sur :

===Connexion SPI entre les modules (Atmega328p) et la RPi3===

SPI: Serial périphérique interface BUS

[[Fichier: yWGmW.png||right|200px|Concept manette modulable]]
Comme indiqué sur l'image ci-dessus, la Raspberry pi 3 peut communiquer en SPI avec ses broches CS0 (24), CS1 (26), SCLK (23), MISO (21), MOSI (19). Celles-ci permettent de communiquer avec un ou plusieurs esclaves (dans notre cas, des Atmega328p) en reliant directement les broches concernées de la RPi3 à celles des composants esclaves.
Chaque broche CS0 (24) ou CS1 (26) ne peut être connectée qu'à l'entrée SS (aussi appelé CS) d'un seul esclave.
C'est a dire que chaque CS est lié à un esclave afin de choisir avec lequel la communication est établie à un moment donné, et les MISO sont reliées entre elles en cascade, de même pour les SCLK et les MOSI. On peut noter que le maître impose la fréquence d’horloge et sélectionne l’esclave auquel les données sont envoyées. 8 MHz est le plus rapide supportable a 3,3V

[[Fichier: fonctionnementSPI.png||right|200px|Connexion SPI multi-esclaves]]

Voici un schéma du fonctionnement souhaité :

Comme nous souhaitons avoir 5 modules environ il nous faudra rajouter un composant en plus afin d'augmenter les possibilités de sélection, par exemple des démultiplexeurs.
Dans un premier temps nous essaierons avec 2 esclaves, puis on augmentera le nombre.

===Connexion Bluetooth PS4-RPi3===

Les recherches portent également sur la connexion entre la manette PS4 et la console. Elles concernent le protocole de communication via Bluetooth

Caracteristique pour la PS4: Bluetooth®v4.0, Qualcomm Atheros AR3002 Buetooth LE: 2,4-2,5 GHz 

Caracteristique de la connexion : 

*Vitesse de transmission >> 3 Mbit/s 8N1
*Relevé tous les 1.3 millisecond (peut-être)
*Chaque manette à une adresse unique BD_ADDR qui correspond à l’adresse MAC de la carte Réseau
*Protocole de détection est le SDP basé sur une emission reception PDU
*L’Attribut ID est representer en TLV Type Length Value
*Communication HCI ACL Data Packet

===Rélisation des cartes électroniques===

matériel nécessaire pour un PCB : 

*breadboard
*câbles
*1 x 10k Ohm résistance
*Quartz 16Mhz clock crystal
*2 x 22 pF capaciteurs
*Atmega328P-PU

Ressources:
[[https://www.arduino.cc/en/Main/Standalone]]
[[http://www.eprojectszone.com/atmega-328-pu-standalone/]]
[[https://www.arduino.cc/en/Tutorial/ArduinoToBreadboard]]

==Semaine 2==

Durant la semaine deux et durant la séance, nous avons continué et approfondie nos recherches sur le projet. Nous avons pu ainsi affiner nos taches de réalisation et donc notre cahier des charges.

===Connexion aux modules: SPI et Bluetooth ===

 CORRIGER

voir https://peip-ima.plil.fr/mediawiki/index.php/BE_2017-2018#Configuration_du_syst.C3.A8me_embarqu.C3.A9

(sudo apt-get install pi-bluetooth)

''connexion sur la raspberry par ssh:''
su
update-rc.d ssh enable
invoke-rc.d ssh start
ssh pi@172.26.79.1XX

''bluetooth''
bluetoothctl
agent on
default-agent
scan on
pair [device Bluetooth address] (exemple: pair XX:XX:XX:XX:XX:XX )

''NOUVELLE REFLEXION : Connexion SPI entre les modules (Atmega328p) et la RPi3 --> MODULES BLUETOOTH''

Si multi-esclaves= plusieurs modules :
Il faut ajouter des sélections pour les SPI → démultiplexeurs OU ne pas utiliser les CS0 et CS1, et plutôt des pins entrée/sortie de la RPi3 lié au SS comme ça on choisit direct le module esclave voulu.

'''IMPORTANT:''' Nous avons étudié à nouveau la datasheet de notre module bluetooth nrf de Nordik. Le module bluetooth comporte déjà un microprocesseur !
Un module plutôt peut donc jouer le rôle de notre atmega328p. Il n'y a alors pas besoin de réaliser des cartes électroniques de type arduino standalone. Nos PCB regrouperont alors uniquement l'alimentation, un actionneur (bouton, joystick), le module bluetooth et les broches de connexion si besoin...

Cette séance nous a alors permise de revoir entièrement le matériel nécessaire. Notre liste de matériel nous semble alors plus réfléchie et limitée au nécessaire.

===Connexion Bluetooth PS4-RPi3===

Suite à nos recherches de la semaine précédente, nous avons sélectionné deux sites bien renseignés :

SITES

Ils nous ont permis de comprendre la communication entre la manette et la console. En effet, ils nous expliquent les échanges de trames Bluetooth.
EXPLICATIONS 1 exemple 

==Semaine 3 : Début premier prototype==

===Connexion SPI RPi3-Arduino===

Comme vu durant les semaines précédentes, nous souhaitons réaliser une connexion Multi-esclaves en SPI entre la Raspberry pi et plusieurs modules.
Cette semaine nous avons vu que la réalisation de notre premier prototype doit aller vite. Il ne nous est pas nécessaire d’attendre les modules bluetooth si il nous faut dans cette partie uniquement utiliser son microprocesseur. Ainsi pour chaque module nous utilisons une arduino UNO. Nous réaliserons les programmes en C afin de pouvoir les réutiliser avec les modules bluetooth par la suite.
Une fois la connexion réalisable nous adapterons les programmes aux modules bluetooth Nordik. En effet, ceux-ci comporte déjà un microprocesseur, le module peut jouer le rôle de notre atmega328p. Il n'y a aurait alors pas besoin de réaliser des cartes électroniques arduino standalone sur PCB, mais directement des cartes électronique avec le module et le module voulu (bouton, joystick...) et l'alimentation.
Durant la séance nous avons alors revu la liste de matériel nécessaire.

[[Fichier: prototype1.jpeg||center|600px|connexion filaire prototype 1 filaire arduino]]

Durant la séance, nous avons recherches des exemples de codes et de librairies pour Arduino SPI et RaspberryPI SPI.

Nous avons également commencé le programme de la connexion SPI pour l'arduino et récupéré les bibliothéques SPI.h avec SPI.c. Nous nous sommes alors concentrer à les comprendre, pour pouvoir l'utiliser.

===Réalisation du projet Git===

Création du projet IMA4_Projet35_ManetteModulable sur Git et partage de celui-ci.
Les premiers dossier crées cette la séance :
-Arduino (connexion SPI arduino) : ProtoSpi.c + dossier librairie SPI + Makefile
-RPI (dossier codes pour Rpi)
-Readme.md
Ces dossiers seront amenés à être modifiés au cours des séances.

===Protocole Bluetooth PS4===

Suite à l'étude des trames Bluetooth, on a pu voir que ces dernières étaient incomplètes. Le modèle de communication étant propriétaire, on n'y a pas accès directement. Cela nous empêche donc de mettre en oeuvre cette communication.
 Déveloper

On a décidé de commencer par une connexion USB (pour laquelle on dispose de toutes les informations) celle-ci étant plus complète.

==Semaine 4==

Pour le prototype 1 FILAIRE nous réaliserons les étapes suivantes :

#Réalisation du programme SPI pour arduino
#Réalisation du programme SPI pour la RPi
#Connexion USB avec la PS4 ou ordinateur
#Réalisation de cartes électroniques atmega328p-pu standalone (remplacer les Arduinos)
#Remplacer les "PCB arduino" par le module bluetooth et adapter la connexion
#Conception 3D de la délimitation 1 axe pour le joystick "gâchette"
#Réalisation de l'application Androïde.

Une fois ces étapes réalisées nous auront alors une preuve de concept filaire et nous pourrons alors passer à une connexion bluetooth.
Le passage à la connexion bluetooth sera le deuxième prototype et le cas idéal de la réalisation de la manette modulable.

===Mise à jour Matériel===

- Modéliser les boutons gâchettes L1/2 R1/2 de la manette PS4 (boutons sensibles à la pression) --> un joystick dont nous bloquerons un axe (imprimante 3D)
- Remplacer la RPi 3 par une Rpi zero W qui nous permettrait de réaliser plus facilement une connexion USB tout en gardant l'avantage du bluetooth.
- Choix de l’alimentation pour les 5 modules Bluetooth: nécessitent 3V --> utiliser des piles rechargeables 1,2V AAA plutôt que piles rondes 3V.

Nous avons également besoin du matériel cité en semaine 1 pour réaliser des cartes électroniques atmega328p-pu standalone. ( nous revenons alors sur les décisions de la semaine 3)

===Connexion SPI RPi3-Arduino===

Montage Raspberrypi et 1 arduino en PSI + 1 bouton + 1 led.
Voici le choix des branchements :

MASTER = RPi
SLAVE= Arduino

'''SPI sur Arduino:'''
MOSI -> GPIO11 //PB3 //master OUT to the slave IN
MISO -> GPIO12 //PB4 //slave OUT to the master IN
SCLK -> GPIO13 //PB5 //serial clock
SS -> GPIO10 //PB2 //slave select
'''Led, bouton et autre...'''
LED --> GPIO6 //PD6
GND
+5V (if required)
'''SPI sur la Raspberry Pi'''
SPIO MOSI -> PIN19
SPIO MISO -> PIN21
SCLK -> PIN23
SPIO CS0 -> PIN24

Continuation du code pour faire clignoter Led branchée à une arduino depuis la Rpi, en connexion SPI.

===Connexion USB PS4-RPi3===
Durant cette, nous avons regardé comment faire cohabiter bluetooth, Application Androïd, USB, PS4, SPI et les module.

Il est alors important de savoir comment utiliser le port série sur la RPi3, soit utiliser les UART.

Nous avons réaliser qu'il n'était pas aussi simple d'utiliser le port serie USB de la Raspberry Pi 3, en effet le SoC est un BCM2837 .
De plus nous ne pouvons pas utiliser le même port pour l'alimentation et la connexion.

Il nous faut alors trouver une alternative ou une solution à ce problème.

==Semaine 5==

===Programmation: Réflexion définitives prototypes filaire ===

La semaine dernière, nous avons rencontré une difficulté liée aux ports séries UART.
Une des solutions à cette difficulté serait d'utiliser une RPi ZERO W à défaut d'une RPi 3. On pourrait alors avoir un port d'alimentation avec connexion USB mais également retrouver la connexion Bluetooth dont nous avons besoin.

Ensuite, nous avons continué la réalisation du prototype filaire par l'avancé du code SPI ainsi que les recherches concernant le protocole PS4.

La Raspberry Pi zero W peut également être utile pour la connexion entre la PS4 et les différents modules en jouant le rôle d'intermédiaire. Nous avons alors commandé une Rpi zero W pour notre projet.
En attendant la réception de la commande, nous nous sommes penché sur les recherches pour les programmes et la configuration nécessaire à l'utilisation de la RPi zero W.

===Electronique===

[[Fichier: bouton_c1.jpg|100px|thumb|left|PCB bouton]]
[[Fichier: arduinobb.jpg|200px|thumb|right|atmega328p-pu branchement test]]

Du coté électronique, nous avons réalisé sur fritzing certaines cartes électroniques. Les Arduino Uno servant actuellement de test, seront remplacées par des PCB atmega328p-pu standalone avec des broches permettant les branchements nécessaires SPI ou encore aux modules "boutons/joystick". Pour les boutons, nous avons également réalisé un pcb afin de faciliter les branchements.

Il nous faut alors également une 3eme carte qui nous sera nécessaire pour la réalisation du prototype sans fil. Dans notre liste de matériel, nous avons des composants nrf52810 bluetooth, ceci doivent être soudé avec les capacités de protection mais également des broches de communication. Nous avons alors commencé cette carte électronique sur Altium avec le fichier projet PCB du distributeur à modifier.

[[Fichier: Arduino_c1.jpg|100px|thumb|center|PCB atmega328p-pu]]

=== Construction 3D ===

Enfin, nous avons commencé à réaliser des boîtiers 3D pour certains modules. Par exemple, comme nous l'avions vu précédemment, un des joysticks servira de bouton-gâchette en utilisant un seul de ses axes. Il nous faut alors réaliser un boitier qui bloque l'un des axes, mais également une tige qui nous permettra de pousser le joystick de manière simplifiée.

==Semaine 6==

===Programmation: configuration RPi Zero W ===

Ayant reçu la Raspberry Pi zero W en début de semaine, nous nous sommes concentrés sur la programmation et la configuration de celle-ci.
Cette partie étant compliquée, elle nous a pris du temps. En effet, il était difficile de connecter la RPi en SSH car il n'est pas possible d'y connecter un clavier directement et on avait besoin de la prise OTG pour "interfacer" la manette.

===Electronique: PCB nrf52810===

Les cartes réalisées en semaine 5 sont validées et en attente de réalisation.

Cette semaine a permis la réalisation et la finalisation de la carte électronique nrf52810. Il nous a fallu recommencé cette carte deux fois. En effet, une fois finie sur Altium nous avons réalisé que les empreintes des CMS sur PCB fourni par le constructeur ne correspondent pas au matériel CMS de l'école. Face à cette inattention de notre part, nous avons décidé de refaire entièrement la carte électronique sur fritzing. Ayant la datasheet et des plans d'inspiration PCB, nous avons pu refaire la carte entièrement.
Sur celle-ci nous avons ajouté des broches de connexion au besoin, un branchement Jtag et ICSP pour la programmation et la connexion SPI.
La carte est en attente de validation, puis validation.

[[Fichier: nrf52810_circuit2.jpg||center|400px|PCB carte nrf52810]]

===Révision matériel ===

Pour la réalisation de nos composants électroniques, il nous a fallu faire une révision des composants disponibles à l'école:
(les quantités indiquées ci-dessous pourront être augmentée si nécessaire,pour avoir dans l'idéal un module de chaque type de la manette, ici on se concentre sur BOUTON et JOYSTICK)

'''Cartes Arduino:'''
* 4 capacite 22pF traversantes
* 2 resistances 10 kOhm traversantes (à récupérer)
* 2 oscillateurs quartz 16MHz traversante
* 2 atmega328p-pu et support

'''Cartes nrf52810'''
* 6 capacités 100nF 0603
* 6 capacités 12pF 0603
* 2 capacités 4,7pF 0603
* 2 capacités 1µF 0603
* 2 capacités 100pF=0,1nF 0603 (à récupérer)
* 2 capacités 0,8pF 0603 (commande en cours)
* 2 inductance 3,9nH 0603 (commande en cours)
* 2 oscillateur quartz 32 MHz

'''Cartes modules Boutons'''
* un sachet de broches mâles (qu'on utilisera également pour les autres cartes, à récupérer/acheté)

Nous avons alors mis-à-jour la liste de composant située plus haut, ainsi que celle de la page IMA4 2017/2018 [https://projets-ima.plil.fr/mediawiki/index.php/Projets_IMA4_SC_%26_SA_2017/2018]

==Semaine 7==

===Programmation: connexion wifi RPi Zero W et Bootloader sur Atmega328p-pu ===

Pendant cette semaine, nous avons continué la programmation et la configuration des Raspberry Pi 3 et Zero W. Concernant la configuration ssh, nous avons utilisé un téléphone en guise de point d’accès à la RPi Zero W en wifi.
Nous avons aussi directement configurer l'OS Jessie, utilisé pour la RPi Zero. On a modifié le fichier cmd.txt et ...pour pouvoir programmer un USB gadget sur le port OTG.
Ci-dessus expliquer fichiers

Nous avons également continuer les programmes de récupération de données : état des boutons et du joystick. Ces programmes sont appliqué sur l'atmega328p-pu standalone sur la plaque d'essai en attendant que le PCB soit opérationnel.
Pour pouvoir programmer l'atemega328p-pu comme une arduino UNO, il nous faut suivre plusieurs étapes :

'''1.Flasher le Bootloader'''
Nous avons 2 Atmega328p-pu neufs, ainsi il nous faut flasher le bootloader sur chacun d'eux afin de pouvoir les utiliser et les programmer sur une breadboard dans un montage minimaliste arduino-standalone.
Pour cela, on peut utiliser une carte arduino UNO. On vérifie le port et le type de carte sélectionnés dans le menu >Outils. Sur cette carte on téléverse le fichier arduinoISP.ino qui se trouve dans les exemples en étant en progrmamateur AVr ISP mkll (>outils>programmateur)
Puis on met l'atmega328p-pu qui nous intéresse sur le suppor socket de la carte. On change de nouveau le programmateur pour Arduino as ISP et on fait >tools>burn bootloader, soit >graver la sequence d'initialisation.
Ces étapes faites, on peut retirer notre microcontroleur et le replacer correctement dans le montage.

'''2.Programmation atmega328 sur breadboard'''
Une fois l'atmega328p-pu préparé, on peut le programmer. On peut le faire simplement à l'aide de la carte arduino UNO utilisée précédemment.On branche les Tx et Rx en commun ainsi que le reset, le GND et le VCC.

Nous avons réaliser des codes basiques tels que le clignotement d'une led rouge ou encore l'affichage de "hello world" sur le moniteur série pour vérifier la bonne fonctionnalité du montage. Cela fait nous avons pu écrire sous Arduino IDE le code de lecture des états.

[[Fichier: montage_BB_test.jpg||left|200px|programmation modules arduino sur breadboard]]

===Electronique : soudure carte de test modules ===

Comme nous l'avons déja vu lors de la réalisation des PCB, si l'on souhaite programmer un atmega328p-pu en bootloader, le montage est simple. Il peut être minimaliste en utilisant une arduino UNO, un atmega328, une breadboard et 3 composants: 1 quartz 16MHZ crystal, 1 résistance 10kOhm et 2 capacitors céramiques de 22pF.
Durant la semaine 7, nous avons soudé les composants traversants de la carte électronique correspondant à ce montage ainsi que le PCB du bouton.

==Semaine 8==

===Programmation ===
Après moult recherche sur les différents site web bien fournis pour le coups on as pu trouvé une amorce à la programmation de l'OTG via un script qui agit au niveau du kernel dans le sous dossier usg_gadget. Ce script donne les informations nécessaires pour pouvoirs échangé les données.
Avec le script trouvé et les informations des sites web décryptant les trames de la manette, on a toujours pas réussit à faire passer notre RPi Zero W pour une manette de PS4. Néanmoins il nous manque la trame HID complète de la manette pour avoir un test effectif.

===Electronique : Correction soudure et soudure CMS===

Durant cette semaine, nous avions souhaité programmer la carte électronique atmega328p-pu. Cependant, nous avons réaliser que nous avions fait une erreur lors de l'envoie du PCB à la production. En effet, celui-ci avait été fait en Top sur le logiciel Fritzing et non en Bottom. Hors nous avions soudé les composants (durant la semaine 7) comme pour un circuit imprimé en bottom, l'atmega328p-pu se retrouve alors inversé par rapport aux pistes.
Comme solution, nous avons choisi de souder un deuxième support pour l'atmega328 de l'autre coté de la carte avant de la refaire au propre. En effet, avant de la refaire il nous faut vérifier si la carte est bien programmable.
Une fois cela fait nous avions pu programmer la carte mais, nous avions également réalisé la pin 2 de l'atmega328 était prise par le bouton poussoir. Or, nous avons besoin des pin 2 et 3 pour le RX et TX permettant la programmation de l'atmega à partir d'une arduino, les pistes branchement RX-TX n'ont également pas été prévus pour le téléversement des programmes sur la carte. Il nous faut alors couper une piste et souder des câbles pour utiliser toutes les pistes souhaitées.

[[Fichier: correction_proto_PCB.jpg||right|300px|PCB arduino correction]]

Durant cette semaine, nous avons également souhaité souder les CMS et le composant bluetooth nrf52810 sur la carte imprimé et reçu lors de la semaine 7. Pour cela, nous avons convenu de travailler dans la C202 durant la séance du mercredi.

[[Fichier: PCB_nrf52810.jpg||left|400px|carte electroniques imprimées]]

====Comment souder des CMS ?====

les CMS sont des composants montés en surface c'est à dire qu'ils sont montés du même côté que les pistes cuivrées (à l'opposé des composants traversants) et sont de petite tailles souvent de l'ordre du millimètre. La taille est déterminée par 4 chiffres : les 2 premiers pour la longueur et les 2 derniers pour la largeur. On a du 1206,0805,0603 ou encore 0402. Il est même possible de trouver plus petit. A l'école nous utilisons souvent du 0603, c'est le cas de nos composants.
Pour souder des CMS 0603, il nous faut utiliser une autre méthode qui n'est pas le fer à souder :
# Préparer la veille la pâte à braser la veille (dans une seringue)
# Gommer la carte pour éviter l'oxydation (attention à ne pas retirer les miettes de gomme en soufflant dessus)
# Appliquer avec la seringue la pâte sur les empreintes et piste souhaitées. Pour les endroits difficile à atteindre ou avec 2 pistes proches les unes des autres, il est possible de mettre la même goutte de pâte sur les 2 pistes. Cela de causera pas de court-circuit par la suite. En effet, la pâte est composée d’alliage qui sous la chaleur va se fluidifier et se coller uniquement aux pistes métallique. Le reste fondera sous la chaleur du four.
# Appliquer les CMS sur la pâte au fur et à mesure (attention ! ne jamais toucher les CMS avec les doigts, tjrs utiliser une pince)
# Mettre au four

====Bilan soudure nrf52810====

Cependant, une fois le matériel nécessaire préparé, et la pâte mise sur les pistes souhaitées, au moment de déposer le composant, nous avons réalisé que celui-ci était beaucoup plus petit que l'empreinte sur le PCB. Il s'agit d'un composant boitier QFN48. Fritzing ne proposant au plus proche des boitiers QFN24 ou LQFP48, celui-ci a basculé automatiquement pour un boitier LQFN48, de dimension plus grande. Face à ce manque de vigilance, nous avions cependant commencer par le nrf52810 (composant concerné) évitant ainsi de gaspiller d'autres CMS.
Nous avons souhaité refaire la carte sous Altium à partir des fichiers fournis par le concepteur (chose que nous avons commencé à faire aux alentours de la semaine 5)
Après la réalisation du schématic, et de la modification des empreintes de capacités, inductances et autres composants de 0402 à 0603. Notre matériel ne permettant que des empreintes 0603.

Lors du routage, une erreur de chevauchement des pistes est notifiée par Altium au niveau du nrf52810. Celles-ci ne présentent pas d'angles et sont déjà de taille 8mil, il nous faut alors passer les pistes en 6mil. Mais 8mil est la taille minimale pour la production à Polytech, nous avons regardé pour envoyer les cartes à faire ailleurs mais le 6mil n'est pas beaucoup conseillé. De plus, il n'est peut-être pas judicieux de continuer avec le composant microcontrôleur-bluetooth Nrf52810 qui prend du temps, donc la carte est difficilement réalisable et peut-être très long à programmer.

Ainsi en cette fin de semaine, nous avons décider face à l'avancer du projet de laisser les nrf52810 de coté et de les remplacer par des modules sans fils plus simples d'utilisation et complets. Ainsi nous aurions plus de chance d'avoir une connexion sans fils entre les modules. Nous pourrions par exemples utiliser des Xbee, des modules Rf...

==Semaine 9==

====Programmation: PS4 et 1er Test SPI sur atmega328p====

'''Raspberry Pi Zero W et PS4'''

'''Modules Atmega328p et SPI'''

Une carte PCB arduino fonctionnant, nous pouvons la programme pour simuler un module. Celle-ci a été designée afin de s'adapter au module que l'on souhaite. Il suffit de brancher le bouton, le joystick ou autre élèment de manette souhaité.
Cette semaine ci, nous avons alors configurer la partie communication SPI pour l'arduino.

'''Que voulons-nous faire avec les atmegas ?'''
Les cartes électroniques atmega328p vont nous permettre de recevoir les requêtes SPI envoyées par la raspberry pi et d'y répondre. La Raspberry enverra un message, par exemple "1", et l'Arduino lira alors l'état du module qui lui est connecté. Une fois l'état récupéré elle le renvoie à la raspberry pi.

Durant cette semaine, nous avons programmé l'atmega afin qu'il soit en esclave, qu'il reçoive un de la RPi "1" et retourne une valeur sauvegardé "int envoi". Nous avons également commencé les tests pour la lecture de l'état d'un bouton (d'après les tests réalisés les semaines précédentes).

'''Code'''
Comme nous l'avons vu précedement lors de nos recherches (semaines 1 à 4) :
La communication SPI nécessite l'utilisation des pins:

MOSI -> GPIO11 //PB3 //master OUT to the slave IN
MISO -> GPIO12 //PB4 //slave OUT to the master IN
SCLK -> GPIO13 //PB5 //serial clock
SS -> GPIO10 //PB2 //slave select

Il faut également paramétrer l'atmega328p en Slave. On note que dans un premier temps, le programme sera codé avec l'arduino IDE (fichiers .ino). Une fois l'ensemble SPI RaspberryPi-Arduino fonctionnant, on remplacera ces codes par du langage C ou C++.

Pour faire la connexion SPI sur l'atmega328p, on utilise la librairie arduino SPI.h, on a alors directement les fonctions nécessaires intervenant sur les registres souhaités : SPCR (spi control register), SPSR (spi status register) et SPDR (spi data register).

#include <SPI.h>

Il est important d'initialise d'abord le setup et on active le port série pour pourvoir utiliser le moniteur série. (Cela servira à verifier la valeur envoyée par la RPi)

void setup (void)
{
Serial.begin (9600);
pinMode(MISO, OUTPUT); //configuration en esclave *master in slave out*
pinMode(buttonPin,INPUT); //config pin bouton
// turn on SPI in slave mode
SPCR |= _BV(SPE);
// preparation interruptions
pos = 0; // buffer empty
process_it = false;
// activation interruptions
SPI.attachInterrupt();
}

On oublie pas de déclarer les interruptions afin de bien lire la requête reçue.

// SPI interrupt routine
ISR (SPI_STC_vect)
{
byte c = SPDR; // grab byte from SPI Data Register
// add to buffer if room
if (pos < sizeof buf)
{
buf [pos++] = c;
// example: newline means time to process buffer
if (c == '\n')
process_it = true;
} // end of room available
} // end of interrupt routine SPI_STC_vect

Dans la loop main, on traite la requête et on utilise '''SPI.transfer(envoi);''' pour transferer à la RPi les données souhaitées.

Durant cette semaine, nous avons également commencé des programmes de test SPI pour la RPi. Il s'agit principalement de programmes de tests tout faits permettant de vérifier la connexion entre cette dernière et l'arduino. Par exemple, la RPI envoie "bonjour" et l'arduino lui retourne ce qu'elle reçoit, soit "bonjour". Sans succés alors.

====Electronique : Fritzing révision====

Lors de la semaine, le modèle PCB de la carte arduino a été réalisé de nouveau sous fritzing avec les broches et connections manquantes. Nous avons également revu la configuration du bouton reset et ajouté une led d'état de l'alimentation. Nous avons ainsi envoyé deux cartes identiques à la réalisation.
La carte déjà soudée lors des derniers jours fonctionnant, elle nous sert de prototype de programmation. Nous pouvons ainsi avancer à la fois sur la programmation des modules mais aussi sur leur réalisation.

==Semaine 10==

====Programmation : PS4 et SPI sur RPi====

'''Raspberry Pi Zero W et PS4'''

'''Modules Raspberry PI et SPI'''

Durant cette semaine, pour la partie Atmega328p-Modules, nous nous sommes concentrés sur la programmation de la communication SPI avec la raspberry pi. Cette semaine a permis une étude plus approfondit sur le fonctionnement pour la RPi.

On rappelle, comme vu des semaines 1 à 4, pour la RPI3 (tout comme la RPi Zero W) utilise les broches : SCLK (23), MISO(21), MOSI (19) et SPI CS0 (24), SPI CS1 (26).
On la programme en Master. A l'aide des fichiers tests d'inspiration, on pourra directement programmer la RPi en C. Lors de la réalisation du code, il y a 3 étapes : l'initialisation/parametrage en SPI pour être maître, l'envoie de la requête puis la réception de données en retour.

Programmant en C, il ne faut pas oublier les librairies suivantes :

#include <stdint.h>
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
#include <getopt.h>
#include <fcntl.h>
#include <sys/ioctl.h>
#include <linux/types.h>
#include <linux/spi/spidev.h> //pour SPI

On va déclarer des variables globales permettant le paramétrage :

static const char *device = "/dev/spidev0.0"; //si on veut CS0 pour atteindre notre SS
static uint8_t mode; //mode est par défaut à 0
static uint8_t bits = 8; //bits par mot échangé
static uint32_t speed = 500000;
static uint16_t delay;

Dans notre main, on ouvre le port (la connexion) au device souhaité, on vérifie les paramètres (registres, connexions...) puis exécute la fonction transfer(fd). transfer(fd) transmet la requête et s'occupe de la réception.

fd = open(device, O_RDWR);
transfer(fd);
close(fd);

==Semaine 11==

====Programmation: PS4, SSH et tests SPI (RPi3&Atemga328p)====

'''Raspberry Pi Zero W et PS4'''

'''Raspberry PI, Atmega328p et SPI'''

Afin de facilité la programmation en utilisant Ethernet, nous avons installer et configuré la RPi pour l'utiliser en SSH depuis les ordinateurs de la E306. En effet, SSH permet de se connecter à distance sur une machine en utilisant un compte utilisateur de la dite machine. En mettant ssh, on pourra directement agir sur les fichiers de la raspberry depuis un terminal de notre PC. Pour cela, on a d'abord vérifier l'adresse IP de notre raspberry pi : 172.26.145.106 avec un écran mais on peut aussi utiliser les commandes ip a et ifconfig. Puis activer le ssh sur la raspberry pi.
On modifie alors le fichier config.txt mais également etc/network/interfaces pour configurer la bonne interface Ethernet sur la raspberry pi.

[[Fichier: configSSH_raspi.png||left|300px|config ssh ethernet]]

Il nous suffit alors de taper la commande : ssh pi@172.26.145.106 pour accéder à notre RPi.

Nous avons continué à réaliser la communication SPI avec des tests entre une arduino UNO et la RPI3. Nous avons commencé par des tests simples inspirés des études de deux semaines précédentes et modulés selon notre utilité.
Nous arrivons alors à lire l'état envoyer "bonjour" et recevoir "ça va" ou encore "1" et recevoir "3". Il faut noter que le SPI échange des trames, la RPI reçoit alors des hexadécimaux.
Nous avons alors continué pour recevoir l'état du bouton ou du joystick lors de l'envoie de "1" sur l'Arduino328p. La semaine prochaine nous testerons ces même codes fonctionnels sur les cartes atmeg327p.

A la fin de cette semaine, nous avons alors des codes Arduino-SPI (.ino) et des codes Raspberry-SPI (.c) permettant l'échange de données. Le but est maintenant de l'adapter aux cartes imprimées et de le rendre pleinement fonctionnel pour plusieurs cartes à la fois, puis ajouter une boucle de vérification en continue jusqu'à une deuxième requête de la RPi.

====Electronique: réalisation au propres des PCB modules====

Suite à une nouvelle erreur de réalisation cartes électronique, nous avons refait et renvoyé à nouveau les cartes imprimées atmega328p.
Nous les souhaitons au propre pour une version finale. Une fois celle-ci imprimées nous pourrons en avoir 3 , un pour chaque module. Les cartes étaient bien imprimées en bottom mais lors du passage des traversants de bottom à top, le logiciel ne les a pas fait miroiter. Par manque d'attention nous avons alors envoyé les fichiers gerber pour des cartes ayant les composants du même coté que la couche de cuivre.
Les cartes électroniques actuelles sont alors correctes et fonctionnelles mais difficile à souder. Pour eviter les erreurs et continuer sur des prototypes de carte nous préférons attendre en nous concentrant sur la programmation PSI de la Raspberry Pi.

==Semaine 12==

====Programmation====

'''Raspberry Pi Zero W et PS4'''

'''Raspberry PI, Atmega328p et SPI'''

- réflexion: penser à faire boucler sur l'arduino une fois la requête reçu, ça veut dire que la manette est ON et donc vérifier continuellement les modules sur chaque atmega.
- SPI raspberry pi - arduino recuperation état du bouton avec les cartes modules (/!\ récuperation à faire dans une variable)

-SSH perso
adresse Rasppi: 192.168.137.10

====Electronique: Finalisation soudure Modules====

Soudure au propre et finale d'une carte atmega328p et donc envoie pour la réalisation de 2 autres cartes similaires et récupération de matériel
Soudure des 2 autres cartes, + tests sur les états = fonctionnelles.
On a donc bien 3 cartes pour les 3 modules de types différents (1 bouton, 1 joystick, 1 gachette)
PCB pour les 2 joysticks (qui serviront de thumbstick et gachette)

==Semaine 13 et plus==

====Programmation====

'''Raspberry Pi Zero W et PS4'''

'''Modules Atmega328p et SPI'''

====Electronique====

=Documents Rendus=

(à mettre rapport + git + drive)

=Datasheets=

IMA4 2017/2018 P35

2018-05-05T19:02:28Z

Tgracias : /* Semaine 7 */

__TOC__
 

=Présentation générale: Manette modulable=

==Description==

Tout le monde joue aux jeux vidéo cependant, les manettes ne sont pas adaptées aux personnes ayant un handicap pouvant toucher les bras ou les mains.
C’est le cas, de plusieurs patients dans les centres de soins et de rééducation.

Pour ce projet IMA4, nous travaillerons avec le centre SSR (soin de suite et de réadaptation) Marc Sautelet de Villeneuve d’Ascq.
Un adolescent, patient de Marc Sautelet, est passionné par les jeux vidéo. En effet, ayant perdu la motricité d’une partie de son corps, il ne peut pas jouer à deux mains. Pour cela, il bloque la manette entre son épaule et son coude, usant de la mâchoire et des doigts pour contrôler les
joysticks et les boutons. Cet exercice peut s’avérer fatiguant et pénible.

Ainsi, nous chercherons à concevoir une manette PS4 adaptée au handicap de l’adolescent.
Cette manette devra aussi être adaptée pour d’autres patients présentant également des handicaps moteurs. Ainsi nous prendrons pour cibles: tous les patients du centre voulant jouer; et non pas que les enfants et adolescents.

 

{| class="wikitable centre" width="80%"
|+
|-
| width="23%" |
Membre du projet
| width="34%" |
Transley Gracias et Camille Saad
|-
| width="23%" |
Cible
| width="34%" |
Patient présentant un handicap moteur
|-
|width="23%" |
Période du projet
| width="34%" |
janvier 2018 - mai 2018
|-
|width="23%" |
Partenaire/Client
| width="34%" |
Centre SSR Marc Sautelet à Villeneuve d'Ascq
|}

==Objectifs==

Ce projet a pour objectif de créer un prototype de manette qui puisse interagir avec la console PS4 et dont le paramétrage se fait à l’aide d’une application mobile et/ou web. Cette manette devra suivre les demandes du patient ainsi que des aides-soignantes du centre, dans la mesure du possible.

Plus précisément, pour le premier prototype, nous mettrons en œuvre l'utilisation de quelques boutons spécifiques:

* Un joystick (type L/R)
* Quelques boutons poussoirs (type Croix/Triangle/Carré/Rond/R1/L1/Start/...)
* Des boutons gâchettes progressives (type L2/R2).

Le but serait donc dans un premier temps de rendre fonctionnel un bouton de chaque type, puis de les multiplier une fois cela fait. Tous ces boutons réunis constituent une manette fonctionnelle.Ainsi, la manette sera ajustable, c’est à dire qu’elle devra s’adapter aux différents handicaps moteurs possibles.

=Analyse du projet=

==Positionnement par rapport à l'existant==

Notre prototype aura une présentation unique par rapport à l’existant. En effet, les concurrents et produits existants ciblent pour la majorité un seul handicap. Cela
engendre une solution fermée à beaucoup de patients. Notre projet propose une mobilité des mouvements et également un choix large dans la composition et le
design de notre manette.
Le patient n’est pas retreint à jouer à une seule main, à utiliser beaucoup de force...Il y a moins de technique dans la manipulation et on ne joue pas avec une
manette adaptée uniquement pour un droitier ou un gaucher. Cependant, cela nous limitera peut-être dans le choix possible des types de jeux. Tout comme les autres
manettes adapté, l’utilisateur nécessitera un peu d’entrainement.

==Analyse du premier concurrent==

Jouer aux jeux vidéo à une main n’est pas une idée d’aujourd’hui. En 1990, Nintendo propose le Power Glove. Mais il tombe très rapidement aux oubliettes suite à des problèmes techniques.

Un autre gant a fait son apparition quelques années plus tard. Celui-ci, plus technique, il faut office de manette Play Station: le Reality Quest Power Glove.Cette idée de manette-gant, permet de jouer à la PS avec une seule main, elle a était conçue et présentée pour les E3, un salon d’exposition de gaming.Le gant est conçu pour contrôler l’équivalent des 14 boutons et 2 joysticks à l’aide d’une seule main. La « manette » est fixée dans la pomme de la main. L’utilisateur contrôle les mouvements verticaux et horizontaux en pivotant le poignet, et utilisent les 4 boutons d’action principaux et L1/R1 avec les doigts. Les autres boutons sont accessibles par un seul bouton rond contrôlé par le pouce.
La manette est adaptée pour beaucoup de jeux vidéo, dont les plus simples sont les jeux de voitures et de combats (arcade).

; Problèmes:
*Besoin de toute la motricité de la main, c’est-à-dire que si le patient à un doigt paralysé ou manquant, il ne pourra pas jouer avec ce gant
*Design obligatoirement droitier
*Les boutons de contrôle sont peu sensibles et peuvent nécessiter de la force
*Design compliqué et nécessitant beaucoup d’entrainement.

;Lien : https://www.youtube.com/watch?v=qV0SxSJDCYg

 
==Analyse du second concurrent==

Ben Heck, de son vrai nom Benjamin J.Heckendorn, est un concepteur de mods de consoles (mods pour modification, soit « manettes modifiées ») et une star
du net grâce à ses vidéos tutoriels.Il propose alors énormément de produits adaptés ou dérivés en guise de manettes.
Parmi les mods qu’il a réalisé, il a modifié une manette de PS4 afin de la rendre accessible à une personne ne pouvant jouer qu’à une main. Pour cela, il a déplacé les boutons en respectant l’ergonomie de la main valide et modifie les connexions. Il peut lui arriver de rajouter des boutons pour en remplacer un autre. Il réalise également le même système avec la Xbox. Sur la photo ci-dessous, il a adapté la manette pour un droitier.

; Problèmes:
*Besoin de toute la motricité de la main, c’est-à-dire que si le patient à un doigt paralysé ou manquant, il ne pourra pas jouer avec cette ma
*Design obligatoirement droitier ou gaucher, une modification = une manette= une personne
*Besoin obligé du pouce et de l’index, même si avantage : 3 doigts nécessaire.

;Lien :: https://www.youtube.com/watch?v=LieHIscadjk

==Scénario d'usage du produit ou du concept envisagé==

La technologie est ,aujourd’hui, omniprésente dans notre vie. Les consoles de jeux ont envahies les maisons avec plus de 7 personnes sur 10 jouant aux jeux vidéos sur consoles en France (chiffre de l’Express). 0,18% des français sont handicapés cela représente 12 millions de français. Dans ce chiffre, 13,4% des personnes ont un handicap moteur. En 2017, les grands groupes comme Sony ou Microsoft avec respectivement PlayStation et Xbox ne permettent pas à tout le monde de jouer avec une manette. Les manettes sont prévues pour des personnes ayant leurs membres valides, plus précisément les mains et les bras.

Après un accident de voiture, un jeune garçon a perdu la motricité d’un côté du corps. Passionné de jeux vidéo, il se retrouve avec des difficultés à jouer sur sa console PS4. Ingénieux, il utilise la manette en la coinçant entre son épaule et le creux du cou. Usant de la mâchoire et de sa main valide pour contrôler les joysticks et les boutons. L'exercice étant inconfortable et fatiguant il eu l’idée de proposer à des futurs ingénieurs de lui proposer une manette adaptée à son handicap.

Les deux pré-ingénieurs ,avec leur tuteur, ont une idée révolutionnaire : La manette modulable ! Elle permettrait au jeune garçon, ainsi que d’autres joueurs, de pouvoir continuer de s’amuser ou même de commencer à jouer au jeux sur console.
Cette manette aidera fortement dans les centre de rééducation pour faire passer le temps et donner du plaisir à des personnes qui ne peuvent plus s’amuser avec leur console traditionnelle. Elle pourra aussi ouvrir de nouvelles possibilités pour certaines personnes qui n’auraient jamais essayé jusqu'à présent.
Comme son nom l'indique, elle sera modulaire et s'adaptera à différents handicaps. Accompagnée de son application d’initialisation, elle sera accessible aussi bien aux enfants, patients, parents et aides soignantes.

Quelques mois plus tard...Le jeune patient fan de Need For Speed, peut maintenant piloter sa voiture comme un vrai professionnel grâce à l'un des joysticks qu'il utilisera avec sa main valide et il pourra accélérer à des vitesses folles à l'aide de boutons poussoirs au niveau de son pied valide et gagner la partie. Son ami venu lui rendre visite, pourra en lieu et place des aides soignantes configurer à l'aide de la tablette (portable) la manette du patient.
Si le patient change de jeu pour Tekken et que la configuration des modules ne lui convient plus, il peut interchanger les éléments de la manette selon son envie et son confort. Ainsi il peut faire sauter son personnage, il utilisera un module bouton supplémentaire, qu'il actionnera avec le poing.

==Fonctionnement==

Suite à une analyse fonctionnelle et à la formulation de notre projet, nous avons pu définir le fonctionnement de notre système. Notre produit, la manette, doit être accessible d’après nos objectifs à différents types de handicaps moteurs. Ainsi, l’idéal serait de concevoir une manette modulable afin qu’elle puisse s’adapter à toutes les situations. Ce n’est plus au patient de s’adapter à la manette mais à la manette de s’adapter au patient.
Cela signifie que la manette sera, dans la limite du possible et de la sensibilité du corps du patient, composée de plusieurs parties dites « modules » comportant un ou plusieurs actionneurs (boutons, joysticks, gâchettes...). Ces modules seront déplaçables afin d’être utilisé avec différents membres du corps : un doigt, une main,
une jambe ou même un pied. Il suffira de les connectés entre eux suivant l’organisation souhaitée, le Gameplay du jeu ou en fonction du handicap. Le tout sera relié à une application.
L’application sera alors mise en place pour connecter les différentes parties du point de vue software pour prérégler la manette en fonction du patient. Il pourra alors choisir les boutons en fonction du jeu, de ses mouvements mais aussi choisir la sensibilité.

L’application et les modules devront être intuitifs et faciles d’utilisation. De cette manière des utilisateurs non avertis dans le domaine informatique ou jeunes pourront eux-mêmes gérer les connexions.

==Réponse à la question difficile==

'''Question : Comment interconnecter les différents modules de la manette ?'''

Il nous faut pour ce projet interconnecter les modules modélisant la manette qui seront connectés à la consoles PS4 via une Raspberry Pi 3.
Le choix de la Raspberry Pi 3 nous permet d'utiliser son module Bluetooth pour communiquer avec la PS4, ce choix est plus adaptée au projet que du filaire.
Concernant l'interconnexion des modules, nous travaillerons en deux étapes "preuves concept" : filaire et sans fils (Bluetooth).

'''Objectif 1 : Preuve concept filaire'''

Dans cette première partie de projet, nous souhaitons avoir une 1ère preuve de prototype rapidement. Nous nous concentrerons alors sur la communication entre la RPi3 et la PS4 ainsi que sur la conception des modules. Pour les modules, nous réaliserons des cartes électronique pour chaque module avec un micro-contrôleur. La communication filaire nous permettra d'interconnecter les modules à la RPi3 avec un bus SPI.

'''Objectif 2: preuve concept sans fils'''

Une deuxième étape du projet est la réalisation de la solution idéale sans fils. Celle-ci pourra commencer à être développée petit à petit en parallèle avec l'objectif 1. Le but ici, est d'interconnecter les modules en Bluetooth. Nous avons choisi le Bluetooth pour garder une connexion commune sur toute la chaîne.
Nous rajouterons alors un module bluetooth à chaque module de la manette.

'''Objectif 3: possibilité d'adapter les boutons (capuchon en 3D)'''

=Préparation du projet=

==Cahier des charges==

''Chef de projet:'' Alexandre Boé 
''Responsables:'' Xavier Redon, Thomas Vantroys 
''Partenariat:'' Marc Sautelet (non etablie) 
''Elèves-ingénieurs:'' Camille Saâd, Transley Gracias 

'''Sujet :''' Manette modulable pour personne à déficience moteur compatible PlayStation 4 

===Objectifs principal (1er POC) : ===
Faire transmettre des informations issus des actionneurs (ex:boutons poussoires) via des arduinos jusqu’à la Raspberry Pi 3 en SPI. 
Envoyer les données reçues vers la PS4 en USB 

===Objectifs secondaire (2e POC):===
Créer des modules avec un microcontrôleur et une puce bluetooth pour permettre une meilleurs flexibilité (c-àd pouvoirs avoir une meilleure ergonomie et une connexion sans fil) 
Connecter la Raspberry Pi 3 en Bluetooth à la PS4 

[[Fichier: beteacorne.jpg||middle|600px|Bete a corne manette]]

==Choix techniques : matériel et logiciel==

===Liste de matériel :===

'''Modules boutons/joysticks/gachettes'''

3 Push buttons : 
- O X Y Carré R3 L3 
- Guide PS 
- start/back 
--> 0,45€/unité TTC [https://www.gotronic.fr/art-bp-miniature-krs1273-16976.htm] 

1 Thumbstick original: 
Joystick analogique 4 directions --> 4,25€/unité TTC [https://www.gotronic.fr/art-joystick-analogique-4-directions-19063.htm] 

1 buttons trigger L1 L2 => 1x Thumbstick original''' 

'''Cartes Atmega328p /connexion spi/'''

3 Arduino UNO 
1 Arduino UNO atmega328p retirable 
4 capacite 22pF traversantes 
2 resistances 10 kOhm traversantes (à récupérer) 
2 oscillateurs quartz 16MHz traversante 
2 atmega328p-pu et support 

'''Cartes module bluetooth nrf52810 '''

6 capacités 100nF 0603 
6 capacités 12pF 0603 
2 capacités 4,7pF 0603 
2 capacités 1µF 0603 
2 capacités 100pF=0,1nF 0603 (à récupérer) 
2 capacités 0,8pF 0603 (a acheter, commande en cours) 
2 inductance 3,9nH 0603 (a acheter, commande en cours) 
2 oscillateur quartz 32 MHz 

''' Connexions et autres '''

1 Led RGB neopixel [https://www.adafruit.com/product/1734] 
1 Raspberry Pi 3 
--> ~36,23€/unité TTC [https://fr.rs-online.com/web/p/processor-microcontroller-development-kits/8968660/?src=raspberrypi] 
1 Raspberry Pi Zero W (commandée) [https://www.raspberrypi.org/products/raspberry-pi-zero-w/] 
6 Alimentations 5V ou 3,3V 
par exemple, 12 piles de type CR2016 3V rechargeables ou 24 piles AAA 1,5 V rechargeables
5 modules Bluetooth nrf de Nordic : nRF52810-QFAA-R 
--> 3,17€/unité + frais expédition [https://www.mouser.fr/productdetail/nordic-semiconductor/nrf52810-qfaa-r?qs=sGAEpiMZZMve4%2FbfQkoj%252bG%2FosjLoe2oghFQwQllMrQ4%3D]
5 Lignes broches mâles 

===Logiciels:===

- IDE arduino
- Altium
- FreeCAD ou Inkscape

==Liste des tâches à effectuer==

'''Etape 1 : Gestion du projet'''

* Définition des cahiers des charges fonctionnel et technique, choix d'orientation...
* Recherche techniques sur les différentes connexions possibles entre les modules, la RPi 3 et la console PS4
#Recherche connexion SPI entre les modules et la RPi3
# Recherche connexion bluetooth entre la RPi3 et la PS4
# Recherche connexion bluetooth pour les modules
# Recherche carte avec montage Atmega328P-PU et anticipation module bluetooth
* Détermination du matériel nécessaire
* Réflexion sur l'application

'''Etape 2: Réalisation du projet'''

'''Partie 1: Preuve concept manette en filaire'''

* Conception de cartes électroniques pour 2 modules (/!\ prévoir modules bluetooth)
* Réalisation connexion SPI avec 2 modules : programmation des Atmega328p en liaison série.
* Si tests concluant, ajouter des modules jusqu'à en avoir 5 (1 pour chaque type de boutons)
* Connexion bluetooth entre la PS4 et la RPi3
* Réalisation du support des modules avec fixations possibles (imprimante 3D)

'''Partie 2: Preuve concept manette en bluetooth'''

* Ajout des modules bluetooth aux cartes électroniques
* Connexion bluetooth entre les modules

'''Partie 3: Application Android : paramétrage de la manette'''

* Créer une application sur tablette ou smartphone (Android) afin de configurer la manette aux besoins (inter-connexion des modules et console)

==Calendrier prévisionnel==

{| class="wikitable centre" width="80%"
|+
|-
| width="23%" |
'''Date'''
| width="34%" |
'''Tache à réaliser''' 
|-
| width="23%" |
17/01/18-24/01/18
| width="34%" |
Faire des recherches sur les différentes interconnexions du système : Bluetooth, RPi-Atmega328 (SPI), RPi-PS4
Continuer liste des taches, matériel, Début recherches + réflexion fixation support des modules
|-
|width="23%" |
31/01/18
| width="34%" |
Recherche technique connexion PS4-RPi3 et connexion SPI RPi3-Module + code
|-
|width="23%" |
31/01/18-07/03/18
| width="34%" |
Réalisation 1er prototype (+ début prototype 2)
|-
|width="23%" |
07/03/18
| width="34%" |
Seance 7 : Test prototype filaire
|-
|width="23%" |
07/03/18-09/05/18
| width="34%" |
Réalisation 2eme prototype + application Android
|-
|width="23%" |
09/05/18
| width="34%" |
Seance 14 : Test prototype Bluetooth
|-
|width="23%" |
14/05/18
| width="34%" |
Video projet
|-
|width="23%" |
15/05/18
| width="34%" |
Finalisation projet et Rapport
|-
|width="23%" |
16/05/18-17/05/18
| width="34%" |
Soutenances Projet
|}

=Réalisation du Projet=

==Feuille d'heures ==

Voici le tableau d'heures du binôme:

{| 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 S11 !! Heures S12 !! Heures S13et+ !! Total
|-
| Analyse du projet
| 10
| 2
| 1
| 1
| 1
|
|
|
|
|
|
|
| 20min
|
| 15h20
|-
| Cherches techniques
|
| 3
| 4
| 4
| 2
| 2
| 1
|
|
|
| 1
| 1
|
|
| 18
|-
| Rédaction du wiki et rapport de projet
|
| 1
| 1
| 1
| 1
| 30min
| 1
|
| 2
| 30min
| 30min
|
| 2
|
| 10h30
|-
| Programmation
|
|
|
|
| 3
| 2
| 3
| 5
| 4
| 7
| 8
| 6
| 5
|
| 43
|-
| Cartes électroniques
|
|
|
|
|
| 6
| 8
| 4
| 6
| 2
| 1
| 2
| 2
|
| 31
|-
| Application
|
|
|
|
|
|
|
|
|
|
|
|
|-
|-
| Total Semaine
| 10
| 6
| 6
| 6
| 7
| 10h30
| 13
| 9
| 12
| 9h30
| 10h30
| 9
| 9h20
|
| '''117h50'''
|}

==Prologue==

Avant la réalisation et conception d'un projet, il est important d'analyser celui-ci. Nous avons allons consacré le prologue à l'analyse fonctionnelle de la manette. Nous avons également eu une réflexion sur l'analyse technique, cela nous a permis de réaliser une liste de matériel. Il est important de définir les objectifs ainsi que les besoins afin de ne rien oublier. (Voir ci-dessus Analyse projet)
Nous avons également organisé notre travail, pour le partage de documents de recherches et la rédaction de compte-rendu final nous avons réalisé un google drive. Par la suite, nous créerons un projet Git.

Durant ce temps, nous avons décidé de réaliser 5 modules. Les modules sont les différents boutons de la manettes qui nous pourrons placer selon nos choix (boutons modulaires) pour notre prototype projet pour chaque type des boutons d'une manette PS4. Ces modules devrons être connectés à la console et interconnectés. Le tout sera lié à une application Android. Suite à quelques recherches et nos analyses, nous avons décidé les points suivants :

- On commencera avec 2 modules et on les multipliera par la suite.
- Les premiers tests sont réalisés avec des boutons petits pour assurer leur caractéristique "modulaires", par la suite nous pourrons ajouter des capuchons de taille plus importante (imprimante 3D ou achat)
- Conception modules : réalisation de carte avec un microcontrôleur atmega328 programmable pour chaque module (anticiper le module Bluetooth)
- Projet en 2 parties : prototype filaire et prototype Bluetooth
# Prototype filaire : connexions entre les modules et la RPi3 en SPI, connexion Rpi3-PS4 en Bluetooth, avec l'application en filaire à la RPi3
# Prototype Bluetooth: connexion Bluetooth entre modules-RPi3-PS4-apllication

[[Fichier: structuremanette.png||center|400px|Concept manette modulable]]

==Semaine 1==

Durant la séance, nous nous sommes concentrés les recherches afin de définir clairement le cahier des charges technique. Il s'agit des réalisations à mettre en œuvre pour les inter-connexions des éléments de la manette.
Ainsi, nous avons fait des recherches sur :

===Connexion SPI entre les modules (Atmega328p) et la RPi3===

SPI: Serial périphérique interface BUS

[[Fichier: yWGmW.png||right|200px|Concept manette modulable]]
Comme indiqué sur l'image ci-dessus, la Raspberry pi 3 peut communiquer en SPI avec ses broches CS0 (24), CS1 (26), SCLK (23), MISO (21), MOSI (19). Celles-ci permettent de communiquer avec un ou plusieurs esclaves (dans notre cas, des Atmega328p) en reliant directement les broches concernées de la RPi3 à celles des composants esclaves.
Chaque broche CS0 (24) ou CS1 (26) ne peut être connectée qu'à l'entrée SS (aussi appelé CS) d'un seul esclave.
C'est a dire que chaque CS est lié à un esclave afin de choisir avec lequel la communication est établie à un moment donné, et les MISO sont reliées entre elles en cascade, de même pour les SCLK et les MOSI. On peut noter que le maître impose la fréquence d’horloge et sélectionne l’esclave auquel les données sont envoyées. 8 MHz est le plus rapide supportable a 3,3V

[[Fichier: fonctionnementSPI.png||right|200px|Connexion SPI multi-esclaves]]

Voici un schéma du fonctionnement souhaité :

Comme nous souhaitons avoir 5 modules environ il nous faudra rajouter un composant en plus afin d'augmenter les possibilités de sélection, par exemple des démultiplexeurs.
Dans un premier temps nous essaierons avec 2 esclaves, puis on augmentera le nombre.

===Connexion Bluetooth PS4-RPi3===

Les recherches portent également sur la connexion entre la manette PS4 et la console. Elles concernent le protocole de communication via Bluetooth

Caracteristique pour la PS4: Bluetooth®v4.0, Qualcomm Atheros AR3002 Buetooth LE: 2,4-2,5 GHz 

Caracteristique de la connexion : 

*Vitesse de transmission >> 3 Mbit/s 8N1
*Relevé tous les 1.3 millisecond (peut-être)
*Chaque manette à une adresse unique BD_ADDR qui correspond à l’adresse MAC de la carte Réseau
*Protocole de détection est le SDP basé sur une emission reception PDU
*L’Attribut ID est representer en TLV Type Length Value
*Communication HCI ACL Data Packet

===Rélisation des cartes électroniques===

matériel nécessaire pour un PCB : 

*breadboard
*câbles
*1 x 10k Ohm résistance
*Quartz 16Mhz clock crystal
*2 x 22 pF capaciteurs
*Atmega328P-PU

Ressources:
[[https://www.arduino.cc/en/Main/Standalone]]
[[http://www.eprojectszone.com/atmega-328-pu-standalone/]]
[[https://www.arduino.cc/en/Tutorial/ArduinoToBreadboard]]

==Semaine 2==

Durant la semaine deux et durant la séance, nous avons continué et approfondie nos recherches sur le projet. Nous avons pu ainsi affiner nos taches de réalisation et donc notre cahier des charges.

===Connexion aux modules: SPI et Bluetooth ===

 CORRIGER

voir https://peip-ima.plil.fr/mediawiki/index.php/BE_2017-2018#Configuration_du_syst.C3.A8me_embarqu.C3.A9

(sudo apt-get install pi-bluetooth)

''connexion sur la raspberry par ssh:''
su
update-rc.d ssh enable
invoke-rc.d ssh start
ssh pi@172.26.79.1XX

''bluetooth''
bluetoothctl
agent on
default-agent
scan on
pair [device Bluetooth address] (exemple: pair XX:XX:XX:XX:XX:XX )

''NOUVELLE REFLEXION : Connexion SPI entre les modules (Atmega328p) et la RPi3 --> MODULES BLUETOOTH''

Si multi-esclaves= plusieurs modules :
Il faut ajouter des sélections pour les SPI → démultiplexeurs OU ne pas utiliser les CS0 et CS1, et plutôt des pins entrée/sortie de la RPi3 lié au SS comme ça on choisit direct le module esclave voulu.

'''IMPORTANT:''' Nous avons étudié à nouveau la datasheet de notre module bluetooth nrf de Nordik. Le module bluetooth comporte déjà un microprocesseur !
Un module plutôt peut donc jouer le rôle de notre atmega328p. Il n'y a alors pas besoin de réaliser des cartes électroniques de type arduino standalone. Nos PCB regrouperont alors uniquement l'alimentation, un actionneur (bouton, joystick), le module bluetooth et les broches de connexion si besoin...

Cette séance nous a alors permise de revoir entièrement le matériel nécessaire. Notre liste de matériel nous semble alors plus réfléchie et limitée au nécessaire.

===Connexion Bluetooth PS4-RPi3===

Suite à nos recherches de la semaine précédente, nous avons sélectionné deux sites bien renseignés :

SITES

Ils nous ont permis de comprendre la communication entre la manette et la console. En effet, ils nous expliquent les échanges de trames Bluetooth.
EXPLICATIONS 1 exemple 

==Semaine 3 : Début premier prototype==

===Connexion SPI RPi3-Arduino===

Comme vu durant les semaines précédentes, nous souhaitons réaliser une connexion Multi-esclaves en SPI entre la Raspberry pi et plusieurs modules.
Cette semaine nous avons vu que la réalisation de notre premier prototype doit aller vite. Il ne nous est pas nécessaire d’attendre les modules bluetooth si il nous faut dans cette partie uniquement utiliser son microprocesseur. Ainsi pour chaque module nous utilisons une arduino UNO. Nous réaliserons les programmes en C afin de pouvoir les réutiliser avec les modules bluetooth par la suite.
Une fois la connexion réalisable nous adapterons les programmes aux modules bluetooth Nordik. En effet, ceux-ci comporte déjà un microprocesseur, le module peut jouer le rôle de notre atmega328p. Il n'y a aurait alors pas besoin de réaliser des cartes électroniques arduino standalone sur PCB, mais directement des cartes électronique avec le module et le module voulu (bouton, joystick...) et l'alimentation.
Durant la séance nous avons alors revu la liste de matériel nécessaire.

[[Fichier: prototype1.jpeg||center|600px|connexion filaire prototype 1 filaire arduino]]

Durant la séance, nous avons recherches des exemples de codes et de librairies pour Arduino SPI et RaspberryPI SPI.

Nous avons également commencé le programme de la connexion SPI pour l'arduino et récupéré les bibliothéques SPI.h avec SPI.c. Nous nous sommes alors concentrer à les comprendre, pour pouvoir l'utiliser.

===Réalisation du projet Git===

Création du projet IMA4_Projet35_ManetteModulable sur Git et partage de celui-ci.
Les premiers dossier crées cette la séance :
-Arduino (connexion SPI arduino) : ProtoSpi.c + dossier librairie SPI + Makefile
-RPI (dossier codes pour Rpi)
-Readme.md
Ces dossiers seront amenés à être modifiés au cours des séances.

===Protocole Bluetooth PS4===

Suite à l'étude des trames Bluetooth, on a pu voir que ces dernières étaient incomplètes. Le modèle de communication étant propriétaire, on n'y a pas accès directement. Cela nous empêche donc de mettre en oeuvre cette communication.
 Déveloper

On a décidé de commencer par une connexion USB (pour laquelle on dispose de toutes les informations) celle-ci étant plus complète.

==Semaine 4==

Pour le prototype 1 FILAIRE nous réaliserons les étapes suivantes :

#Réalisation du programme SPI pour arduino
#Réalisation du programme SPI pour la RPi
#Connexion USB avec la PS4 ou ordinateur
#Réalisation de cartes électroniques atmega328p-pu standalone (remplacer les Arduinos)
#Remplacer les "PCB arduino" par le module bluetooth et adapter la connexion
#Conception 3D de la délimitation 1 axe pour le joystick "gâchette"
#Réalisation de l'application Androïde.

Une fois ces étapes réalisées nous auront alors une preuve de concept filaire et nous pourrons alors passer à une connexion bluetooth.
Le passage à la connexion bluetooth sera le deuxième prototype et le cas idéal de la réalisation de la manette modulable.

===Mise à jour Matériel===

- Modéliser les boutons gâchettes L1/2 R1/2 de la manette PS4 (boutons sensibles à la pression) --> un joystick dont nous bloquerons un axe (imprimante 3D)
- Remplacer la RPi 3 par une Rpi zero W qui nous permettrait de réaliser plus facilement une connexion USB tout en gardant l'avantage du bluetooth.
- Choix de l’alimentation pour les 5 modules Bluetooth: nécessitent 3V --> utiliser des piles rechargeables 1,2V AAA plutôt que piles rondes 3V.

Nous avons également besoin du matériel cité en semaine 1 pour réaliser des cartes électroniques atmega328p-pu standalone. ( nous revenons alors sur les décisions de la semaine 3)

===Connexion SPI RPi3-Arduino===

Montage Raspberrypi et 1 arduino en PSI + 1 bouton + 1 led.
Voici le choix des branchements :

MASTER = RPi
SLAVE= Arduino

'''SPI sur Arduino:'''
MOSI -> GPIO11 //PB3 //master OUT to the slave IN
MISO -> GPIO12 //PB4 //slave OUT to the master IN
SCLK -> GPIO13 //PB5 //serial clock
SS -> GPIO10 //PB2 //slave select
'''Led, bouton et autre...'''
LED --> GPIO6 //PD6
GND
+5V (if required)
'''SPI sur la Raspberry Pi'''
SPIO MOSI -> PIN19
SPIO MISO -> PIN21
SCLK -> PIN23
SPIO CS0 -> PIN24

Continuation du code pour faire clignoter Led branchée à une arduino depuis la Rpi, en connexion SPI.

===Connexion USB PS4-RPi3===
Durant cette, nous avons regardé comment faire cohabiter bluetooth, Application Androïd, USB, PS4, SPI et les module.

Il est alors important de savoir comment utiliser le port série sur la RPi3, soit utiliser les UART.

Nous avons réaliser qu'il n'était pas aussi simple d'utiliser le port serie USB de la Raspberry Pi 3, en effet le SoC est un BCM2837 .
De plus nous ne pouvons pas utiliser le même port pour l'alimentation et la connexion.

Il nous faut alors trouver une alternative ou une solution à ce problème.

==Semaine 5==

===Programmation: Réflexion définitives prototypes filaire ===

La semaine dernière, nous avons rencontré une difficulté liée aux ports séries UART.
Une des solutions à cette difficulté serait d'utiliser une RPi ZERO W à défaut d'une RPi 3. On pourrait alors avoir un port d'alimentation avec connexion USB mais également retrouver la connexion Bluetooth dont nous avons besoin.

Ensuite, nous avons continué la réalisation du prototype filaire par l'avancé du code SPI ainsi que les recherches concernant le protocole PS4.

La Raspberry Pi zero W peut également être utile pour la connexion entre la PS4 et les différents modules en jouant le rôle d'intermédiaire. Nous avons alors commandé une Rpi zero W pour notre projet.
En attendant la réception de la commande, nous nous sommes penché sur les recherches pour les programmes et la configuration nécessaire à l'utilisation de la RPi zero W.

===Electronique===

[[Fichier: bouton_c1.jpg|100px|thumb|left|PCB bouton]]
[[Fichier: arduinobb.jpg|200px|thumb|right|atmega328p-pu branchement test]]

Du coté électronique, nous avons réalisé sur fritzing certaines cartes électroniques. Les Arduino Uno servant actuellement de test, seront remplacées par des PCB atmega328p-pu standalone avec des broches permettant les branchements nécessaires SPI ou encore aux modules "boutons/joystick". Pour les boutons, nous avons également réalisé un pcb afin de faciliter les branchements.

Il nous faut alors également une 3eme carte qui nous sera nécessaire pour la réalisation du prototype sans fil. Dans notre liste de matériel, nous avons des composants nrf52810 bluetooth, ceci doivent être soudé avec les capacités de protection mais également des broches de communication. Nous avons alors commencé cette carte électronique sur Altium avec le fichier projet PCB du distributeur à modifier.

[[Fichier: Arduino_c1.jpg|100px|thumb|center|PCB atmega328p-pu]]

=== Construction 3D ===

Enfin, nous avons commencé à réaliser des boîtiers 3D pour certains modules. Par exemple, comme nous l'avions vu précédemment, un des joysticks servira de bouton-gâchette en utilisant un seul de ses axes. Il nous faut alors réaliser un boitier qui bloque l'un des axes, mais également une tige qui nous permettra de pousser le joystick de manière simplifiée.

==Semaine 6==

===Programmation: configuration RPi Zero W ===

Ayant reçu la Raspberry Pi zero W en début de semaine, nous nous sommes concentrés sur la programmation et la configuration de celle-ci.
Cette partie étant compliquée, elle nous a pris du temps. En effet, il était difficile de connecter la RPi en SSH car il n'est pas possible d'y connecter un clavier directement et on avait besoin de la prise OTG pour "interfacer" la manette.

===Electronique: PCB nrf52810===

Les cartes réalisées en semaine 5 sont validées et en attente de réalisation.

Cette semaine a permis la réalisation et la finalisation de la carte électronique nrf52810. Il nous a fallu recommencé cette carte deux fois. En effet, une fois finie sur Altium nous avons réalisé que les empreintes des CMS sur PCB fourni par le constructeur ne correspondent pas au matériel CMS de l'école. Face à cette inattention de notre part, nous avons décidé de refaire entièrement la carte électronique sur fritzing. Ayant la datasheet et des plans d'inspiration PCB, nous avons pu refaire la carte entièrement.
Sur celle-ci nous avons ajouté des broches de connexion au besoin, un branchement Jtag et ICSP pour la programmation et la connexion SPI.
La carte est en attente de validation, puis validation.

[[Fichier: nrf52810_circuit2.jpg||center|400px|PCB carte nrf52810]]

===Révision matériel ===

Pour la réalisation de nos composants électroniques, il nous a fallu faire une révision des composants disponibles à l'école:
(les quantités indiquées ci-dessous pourront être augmentée si nécessaire,pour avoir dans l'idéal un module de chaque type de la manette, ici on se concentre sur BOUTON et JOYSTICK)

'''Cartes Arduino:'''
* 4 capacite 22pF traversantes
* 2 resistances 10 kOhm traversantes (à récupérer)
* 2 oscillateurs quartz 16MHz traversante
* 2 atmega328p-pu et support

'''Cartes nrf52810'''
* 6 capacités 100nF 0603
* 6 capacités 12pF 0603
* 2 capacités 4,7pF 0603
* 2 capacités 1µF 0603
* 2 capacités 100pF=0,1nF 0603 (à récupérer)
* 2 capacités 0,8pF 0603 (commande en cours)
* 2 inductance 3,9nH 0603 (commande en cours)
* 2 oscillateur quartz 32 MHz

'''Cartes modules Boutons'''
* un sachet de broches mâles (qu'on utilisera également pour les autres cartes, à récupérer/acheté)

Nous avons alors mis-à-jour la liste de composant située plus haut, ainsi que celle de la page IMA4 2017/2018 [https://projets-ima.plil.fr/mediawiki/index.php/Projets_IMA4_SC_%26_SA_2017/2018]

==Semaine 7==

===Programmation: connexion wifi RPi Zero W et Bootloader sur Atmega328p-pu ===

Pendant cette semaine, nous avons continué la programmation et la configuration des Raspberry Pi 3 et Zero W. Concernant la configuration ssh, nous avons utilisé un téléphone en guise de point d’accès à la RPi Zero W en wifi.
Nous avons aussi directement configurer l'OS Jessie, utilisé pour la RPi Zero. On a modifié le fichier cmd.txt et ...pour pouvoir programmer un USB gadget sur le port OTG.
Ci-dessus expliquer fichiers

Nous avons également continuer les programmes de récupération de données : état des boutons et du joystick. Ces programmes sont appliqué sur l'atmega328p-pu standalone sur la plaque d'essai en attendant que le PCB soit opérationnel.
Pour pouvoir programmer l'atemega328p-pu comme une arduino UNO, il nous faut suivre plusieurs étapes :

'''1.Flasher le Bootloader'''
Nous avons 2 Atmega328p-pu neufs, ainsi il nous faut flasher le bootloader sur chacun d'eux afin de pouvoir les utiliser et les programmer sur une breadboard dans un montage minimaliste arduino-standalone.
Pour cela, on peut utiliser une carte arduino UNO. On vérifie le port et le type de carte sélectionnés dans le menu >Outils. Sur cette carte on téléverse le fichier arduinoISP.ino qui se trouve dans les exemples en étant en progrmamateur AVr ISP mkll (>outils>programmateur)
Puis on met l'atmega328p-pu qui nous intéresse sur le suppor socket de la carte. On change de nouveau le programmateur pour Arduino as ISP et on fait >tools>burn bootloader, soit >graver la sequence d'initialisation.
Ces étapes faites, on peut retirer notre microcontroleur et le replacer correctement dans le montage.

'''2.Programmation atmega328 sur breadboard'''
Une fois l'atmega328p-pu préparé, on peut le programmer. On peut le faire simplement à l'aide de la carte arduino UNO utilisée précédemment.On branche les Tx et Rx en commun ainsi que le reset, le GND et le VCC.

Nous avons réaliser des codes basiques tels que le clignotement d'une led rouge ou encore l'affichage de "hello world" sur le moniteur série pour vérifier la bonne fonctionnalité du montage. Cela fait nous avons pu écrire sous Arduino IDE le code de lecture des états.

[[Fichier: montage_BB_test.jpg||left|200px|programmation modules arduino sur breadboard]]

===Electronique : soudure carte de test modules ===

Comme nous l'avons déja vu lors de la réalisation des PCB, si l'on souhaite programmer un atmega328p-pu en bootloader, le montage est simple. Il peut être minimaliste en utilisant une arduino UNO, un atmega328, une breadboard et 3 composants: 1 quartz 16MHZ crystal, 1 résistance 10kOhm et 2 capacitors céramiques de 22pF.
Durant la semaine 7, nous avons soudé les composants traversants de la carte électronique correspondant à ce montage ainsi que le PCB du bouton.

==Semaine 8==

===Programmation ===

===Electronique : Correction soudure et soudure CMS===

Durant cette semaine, nous avions souhaité programmer la carte électronique atmega328p-pu. Cependant, nous avons réaliser que nous avions fait une erreur lors de l'envoie du PCB à la production. En effet, celui-ci avait été fait en Top sur le logiciel Fritzing et non en Bottom. Hors nous avions soudé les composants (durant la semaine 7) comme pour un circuit imprimé en bottom, l'atmega328p-pu se retrouve alors inversé par rapport aux pistes.
Comme solution, nous avons choisi de souder un deuxième support pour l'atmega328 de l'autre coté de la carte avant de la refaire au propre. En effet, avant de la refaire il nous faut vérifier si la carte est bien programmable.
Une fois cela fait nous avions pu programmer la carte mais, nous avions également réalisé la pin 2 de l'atmega328 était prise par le bouton poussoir. Or, nous avons besoin des pin 2 et 3 pour le RX et TX permettant la programmation de l'atmega à partir d'une arduino, les pistes branchement RX-TX n'ont également pas été prévus pour le téléversement des programmes sur la carte. Il nous faut alors couper une piste et souder des câbles pour utiliser toutes les pistes souhaitées.

[[Fichier: correction_proto_PCB.jpg||right|300px|PCB arduino correction]]

Durant cette semaine, nous avons également souhaité souder les CMS et le composant bluetooth nrf52810 sur la carte imprimé et reçu lors de la semaine 7. Pour cela, nous avons convenu de travailler dans la C202 durant la séance du mercredi.

[[Fichier: PCB_nrf52810.jpg||left|400px|carte electroniques imprimées]]

====Comment souder des CMS ?====

les CMS sont des composants montés en surface c'est à dire qu'ils sont montés du même côté que les pistes cuivrées (à l'opposé des composants traversants) et sont de petite tailles souvent de l'ordre du millimètre. La taille est déterminée par 4 chiffres : les 2 premiers pour la longueur et les 2 derniers pour la largeur. On a du 1206,0805,0603 ou encore 0402. Il est même possible de trouver plus petit. A l'école nous utilisons souvent du 0603, c'est le cas de nos composants.
Pour souder des CMS 0603, il nous faut utiliser une autre méthode qui n'est pas le fer à souder :
# Préparer la veille la pâte à braser la veille (dans une seringue)
# Gommer la carte pour éviter l'oxydation (attention à ne pas retirer les miettes de gomme en soufflant dessus)
# Appliquer avec la seringue la pâte sur les empreintes et piste souhaitées. Pour les endroits difficile à atteindre ou avec 2 pistes proches les unes des autres, il est possible de mettre la même goutte de pâte sur les 2 pistes. Cela de causera pas de court-circuit par la suite. En effet, la pâte est composée d’alliage qui sous la chaleur va se fluidifier et se coller uniquement aux pistes métallique. Le reste fondera sous la chaleur du four.
# Appliquer les CMS sur la pâte au fur et à mesure (attention ! ne jamais toucher les CMS avec les doigts, tjrs utiliser une pince)
# Mettre au four

====Bilan soudure nrf52810====

Cependant, une fois le matériel nécessaire préparé, et la pâte mise sur les pistes souhaitées, au moment de déposer le composant, nous avons réalisé que celui-ci était beaucoup plus petit que l'empreinte sur le PCB. Il s'agit d'un composant boitier QFN48. Fritzing ne proposant au plus proche des boitiers QFN24 ou LQFP48, celui-ci a basculé automatiquement pour un boitier LQFN48, de dimension plus grande. Face à ce manque de vigilance, nous avions cependant commencer par le nrf52810 (composant concerné) évitant ainsi de gaspiller d'autres CMS.
Nous avons souhaité refaire la carte sous Altium à partir des fichiers fournis par le concepteur (chose que nous avons commencé à faire aux alentours de la semaine 5)
Après la réalisation du schématic, et de la modification des empreintes de capacités, inductances et autres composants de 0402 à 0603. Notre matériel ne permettant que des empreintes 0603.

Lors du routage, une erreur de chevauchement des pistes est notifiée par Altium au niveau du nrf52810. Celles-ci ne présentent pas d'angles et sont déjà de taille 8mil, il nous faut alors passer les pistes en 6mil. Mais 8mil est la taille minimale pour la production à Polytech, nous avons regardé pour envoyer les cartes à faire ailleurs mais le 6mil n'est pas beaucoup conseillé. De plus, il n'est peut-être pas judicieux de continuer avec le composant microcontrôleur-bluetooth Nrf52810 qui prend du temps, donc la carte est difficilement réalisable et peut-être très long à programmer.

Ainsi en cette fin de semaine, nous avons décider face à l'avancer du projet de laisser les nrf52810 de coté et de les remplacer par des modules sans fils plus simples d'utilisation et complets. Ainsi nous aurions plus de chance d'avoir une connexion sans fils entre les modules. Nous pourrions par exemples utiliser des Xbee, des modules Rf...

==Semaine 9==

====Programmation: PS4 et 1er Test SPI sur atmega328p====

'''Raspberry Pi Zero W et PS4'''

'''Modules Atmega328p et SPI'''

Une carte PCB arduino fonctionnant, nous pouvons la programme pour simuler un module. Celle-ci a été designée afin de s'adapter au module que l'on souhaite. Il suffit de brancher le bouton, le joystick ou autre élèment de manette souhaité.
Cette semaine ci, nous avons alors configurer la partie communication SPI pour l'arduino.

'''Que voulons-nous faire avec les atmegas ?'''
Les cartes électroniques atmega328p vont nous permettre de recevoir les requêtes SPI envoyées par la raspberry pi et d'y répondre. La Raspberry enverra un message, par exemple "1", et l'Arduino lira alors l'état du module qui lui est connecté. Une fois l'état récupéré elle le renvoie à la raspberry pi.

Durant cette semaine, nous avons programmé l'atmega afin qu'il soit en esclave, qu'il reçoive un de la RPi "1" et retourne une valeur sauvegardé "int envoi". Nous avons également commencé les tests pour la lecture de l'état d'un bouton (d'après les tests réalisés les semaines précédentes).

'''Code'''
Comme nous l'avons vu précedement lors de nos recherches (semaines 1 à 4) :
La communication SPI nécessite l'utilisation des pins:

MOSI -> GPIO11 //PB3 //master OUT to the slave IN
MISO -> GPIO12 //PB4 //slave OUT to the master IN
SCLK -> GPIO13 //PB5 //serial clock
SS -> GPIO10 //PB2 //slave select

Il faut également paramétrer l'atmega328p en Slave. On note que dans un premier temps, le programme sera codé avec l'arduino IDE (fichiers .ino). Une fois l'ensemble SPI RaspberryPi-Arduino fonctionnant, on remplacera ces codes par du langage C ou C++.

Pour faire la connexion SPI sur l'atmega328p, on utilise la librairie arduino SPI.h, on a alors directement les fonctions nécessaires intervenant sur les registres souhaités : SPCR (spi control register), SPSR (spi status register) et SPDR (spi data register).

#include <SPI.h>

Il est important d'initialise d'abord le setup et on active le port série pour pourvoir utiliser le moniteur série. (Cela servira à verifier la valeur envoyée par la RPi)

void setup (void)
{
Serial.begin (9600);
pinMode(MISO, OUTPUT); //configuration en esclave *master in slave out*
pinMode(buttonPin,INPUT); //config pin bouton
// turn on SPI in slave mode
SPCR |= _BV(SPE);
// preparation interruptions
pos = 0; // buffer empty
process_it = false;
// activation interruptions
SPI.attachInterrupt();
}

On oublie pas de déclarer les interruptions afin de bien lire la requête reçue.

// SPI interrupt routine
ISR (SPI_STC_vect)
{
byte c = SPDR; // grab byte from SPI Data Register
// add to buffer if room
if (pos < sizeof buf)
{
buf [pos++] = c;
// example: newline means time to process buffer
if (c == '\n')
process_it = true;
} // end of room available
} // end of interrupt routine SPI_STC_vect

Dans la loop main, on traite la requête et on utilise '''SPI.transfer(envoi);''' pour transferer à la RPi les données souhaitées.

Durant cette semaine, nous avons également commencé des programmes de test SPI pour la RPi. Il s'agit principalement de programmes de tests tout faits permettant de vérifier la connexion entre cette dernière et l'arduino. Par exemple, la RPI envoie "bonjour" et l'arduino lui retourne ce qu'elle reçoit, soit "bonjour". Sans succés alors.

====Electronique : Fritzing révision====

Lors de la semaine, le modèle PCB de la carte arduino a été réalisé de nouveau sous fritzing avec les broches et connections manquantes. Nous avons également revu la configuration du bouton reset et ajouté une led d'état de l'alimentation. Nous avons ainsi envoyé deux cartes identiques à la réalisation.
La carte déjà soudée lors des derniers jours fonctionnant, elle nous sert de prototype de programmation. Nous pouvons ainsi avancer à la fois sur la programmation des modules mais aussi sur leur réalisation.

==Semaine 10==

====Programmation : PS4 et SPI sur RPi====

'''Raspberry Pi Zero W et PS4'''

'''Modules Raspberry PI et SPI'''

Durant cette semaine, pour la partie Atmega328p-Modules, nous nous sommes concentrés sur la programmation de la communication SPI avec la raspberry pi. Cette semaine a permis une étude plus approfondit sur le fonctionnement pour la RPi.

On rappelle, comme vu des semaines 1 à 4, pour la RPI3 (tout comme la RPi Zero W) utilise les broches : SCLK (23), MISO(21), MOSI (19) et SPI CS0 (24), SPI CS1 (26).
On la programme en Master. A l'aide des fichiers tests d'inspiration, on pourra directement programmer la RPi en C. Lors de la réalisation du code, il y a 3 étapes : l'initialisation/parametrage en SPI pour être maître, l'envoie de la requête puis la réception de données en retour.

Programmant en C, il ne faut pas oublier les librairies suivantes :

#include <stdint.h>
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
#include <getopt.h>
#include <fcntl.h>
#include <sys/ioctl.h>
#include <linux/types.h>
#include <linux/spi/spidev.h> //pour SPI

On va déclarer des variables globales permettant le paramétrage :

static const char *device = "/dev/spidev0.0"; //si on veut CS0 pour atteindre notre SS
static uint8_t mode; //mode est par défaut à 0
static uint8_t bits = 8; //bits par mot échangé
static uint32_t speed = 500000;
static uint16_t delay;

Dans notre main, on ouvre le port (la connexion) au device souhaité, on vérifie les paramètres (registres, connexions...) puis exécute la fonction transfer(fd). transfer(fd) transmet la requête et s'occupe de la réception.

fd = open(device, O_RDWR);
transfer(fd);
close(fd);

==Semaine 11==

====Programmation: PS4, SSH et tests SPI (RPi3&Atemga328p)====

'''Raspberry Pi Zero W et PS4'''

'''Raspberry PI, Atmega328p et SPI'''

Afin de facilité la programmation en utilisant Ethernet, nous avons installer et configuré la RPi pour l'utiliser en SSH depuis les ordinateurs de la E306. En effet, SSH permet de se connecter à distance sur une machine en utilisant un compte utilisateur de la dite machine. En mettant ssh, on pourra directement agir sur les fichiers de la raspberry depuis un terminal de notre PC. Pour cela, on a d'abord vérifier l'adresse IP de notre raspberry pi : 172.26.145.106 avec un écran mais on peut aussi utiliser les commandes ip a et ifconfig. Puis activer le ssh sur la raspberry pi.
On modifie alors le fichier config.txt mais également etc/network/interfaces pour configurer la bonne interface Ethernet sur la raspberry pi.

[[Fichier: configSSH_raspi.png||left|300px|config ssh ethernet]]

Il nous suffit alors de taper la commande : ssh pi@172.26.145.106 pour accéder à notre RPi.

Nous avons continué à réaliser la communication SPI avec des tests entre une arduino UNO et la RPI3. Nous avons commencé par des tests simples inspirés des études de deux semaines précédentes et modulés selon notre utilité.
Nous arrivons alors à lire l'état envoyer "bonjour" et recevoir "ça va" ou encore "1" et recevoir "3". Il faut noter que le SPI échange des trames, la RPI reçoit alors des hexadécimaux.
Nous avons alors continué pour recevoir l'état du bouton ou du joystick lors de l'envoie de "1" sur l'Arduino328p. La semaine prochaine nous testerons ces même codes fonctionnels sur les cartes atmeg327p.

A la fin de cette semaine, nous avons alors des codes Arduino-SPI (.ino) et des codes Raspberry-SPI (.c) permettant l'échange de données. Le but est maintenant de l'adapter aux cartes imprimées et de le rendre pleinement fonctionnel pour plusieurs cartes à la fois, puis ajouter une boucle de vérification en continue jusqu'à une deuxième requête de la RPi.

====Electronique: réalisation au propres des PCB modules====

Suite à une nouvelle erreur de réalisation cartes électronique, nous avons refait et renvoyé à nouveau les cartes imprimées atmega328p.
Nous les souhaitons au propre pour une version finale. Une fois celle-ci imprimées nous pourrons en avoir 3 , un pour chaque module. Les cartes étaient bien imprimées en bottom mais lors du passage des traversants de bottom à top, le logiciel ne les a pas fait miroiter. Par manque d'attention nous avons alors envoyé les fichiers gerber pour des cartes ayant les composants du même coté que la couche de cuivre.
Les cartes électroniques actuelles sont alors correctes et fonctionnelles mais difficile à souder. Pour eviter les erreurs et continuer sur des prototypes de carte nous préférons attendre en nous concentrant sur la programmation PSI de la Raspberry Pi.

==Semaine 12==

====Programmation====

'''Raspberry Pi Zero W et PS4'''

'''Raspberry PI, Atmega328p et SPI'''

- réflexion: penser à faire boucler sur l'arduino une fois la requête reçu, ça veut dire que la manette est ON et donc vérifier continuellement les modules sur chaque atmega.
- SPI raspberry pi - arduino recuperation état du bouton avec les cartes modules (/!\ récuperation à faire dans une variable)

-SSH perso
adresse Rasppi: 192.168.137.10

====Electronique: Finalisation soudure Modules====

Soudure au propre et finale d'une carte atmega328p et donc envoie pour la réalisation de 2 autres cartes similaires et récupération de matériel
Soudure des 2 autres cartes, + tests sur les états = fonctionnelles.
On a donc bien 3 cartes pour les 3 modules de types différents (1 bouton, 1 joystick, 1 gachette)
PCB pour les 2 joysticks (qui serviront de thumbstick et gachette)

==Semaine 13 et plus==

====Programmation====

'''Raspberry Pi Zero W et PS4'''

'''Modules Atmega328p et SPI'''

====Electronique====

=Documents Rendus=

(à mettre rapport + git + drive)

=Datasheets=

IMA4 2017/2018 P35

2018-05-05T18:54:34Z

Tgracias : /* Programmation: configuration RPi Zero W */

__TOC__
 

=Présentation générale: Manette modulable=

==Description==

Tout le monde joue aux jeux vidéo cependant, les manettes ne sont pas adaptées aux personnes ayant un handicap pouvant toucher les bras ou les mains.
C’est le cas, de plusieurs patients dans les centres de soins et de rééducation.

Pour ce projet IMA4, nous travaillerons avec le centre SSR (soin de suite et de réadaptation) Marc Sautelet de Villeneuve d’Ascq.
Un adolescent, patient de Marc Sautelet, est passionné par les jeux vidéo. En effet, ayant perdu la motricité d’une partie de son corps, il ne peut pas jouer à deux mains. Pour cela, il bloque la manette entre son épaule et son coude, usant de la mâchoire et des doigts pour contrôler les
joysticks et les boutons. Cet exercice peut s’avérer fatiguant et pénible.

Ainsi, nous chercherons à concevoir une manette PS4 adaptée au handicap de l’adolescent.
Cette manette devra aussi être adaptée pour d’autres patients présentant également des handicaps moteurs. Ainsi nous prendrons pour cibles: tous les patients du centre voulant jouer; et non pas que les enfants et adolescents.

 

{| class="wikitable centre" width="80%"
|+
|-
| width="23%" |
Membre du projet
| width="34%" |
Transley Gracias et Camille Saad
|-
| width="23%" |
Cible
| width="34%" |
Patient présentant un handicap moteur
|-
|width="23%" |
Période du projet
| width="34%" |
janvier 2018 - mai 2018
|-
|width="23%" |
Partenaire/Client
| width="34%" |
Centre SSR Marc Sautelet à Villeneuve d'Ascq
|}

==Objectifs==

Ce projet a pour objectif de créer un prototype de manette qui puisse interagir avec la console PS4 et dont le paramétrage se fait à l’aide d’une application mobile et/ou web. Cette manette devra suivre les demandes du patient ainsi que des aides-soignantes du centre, dans la mesure du possible.

Plus précisément, pour le premier prototype, nous mettrons en œuvre l'utilisation de quelques boutons spécifiques:

* Un joystick (type L/R)
* Quelques boutons poussoirs (type Croix/Triangle/Carré/Rond/R1/L1/Start/...)
* Des boutons gâchettes progressives (type L2/R2).

Le but serait donc dans un premier temps de rendre fonctionnel un bouton de chaque type, puis de les multiplier une fois cela fait. Tous ces boutons réunis constituent une manette fonctionnelle.Ainsi, la manette sera ajustable, c’est à dire qu’elle devra s’adapter aux différents handicaps moteurs possibles.

=Analyse du projet=

==Positionnement par rapport à l'existant==

Notre prototype aura une présentation unique par rapport à l’existant. En effet, les concurrents et produits existants ciblent pour la majorité un seul handicap. Cela
engendre une solution fermée à beaucoup de patients. Notre projet propose une mobilité des mouvements et également un choix large dans la composition et le
design de notre manette.
Le patient n’est pas retreint à jouer à une seule main, à utiliser beaucoup de force...Il y a moins de technique dans la manipulation et on ne joue pas avec une
manette adaptée uniquement pour un droitier ou un gaucher. Cependant, cela nous limitera peut-être dans le choix possible des types de jeux. Tout comme les autres
manettes adapté, l’utilisateur nécessitera un peu d’entrainement.

==Analyse du premier concurrent==

Jouer aux jeux vidéo à une main n’est pas une idée d’aujourd’hui. En 1990, Nintendo propose le Power Glove. Mais il tombe très rapidement aux oubliettes suite à des problèmes techniques.

Un autre gant a fait son apparition quelques années plus tard. Celui-ci, plus technique, il faut office de manette Play Station: le Reality Quest Power Glove.Cette idée de manette-gant, permet de jouer à la PS avec une seule main, elle a était conçue et présentée pour les E3, un salon d’exposition de gaming.Le gant est conçu pour contrôler l’équivalent des 14 boutons et 2 joysticks à l’aide d’une seule main. La « manette » est fixée dans la pomme de la main. L’utilisateur contrôle les mouvements verticaux et horizontaux en pivotant le poignet, et utilisent les 4 boutons d’action principaux et L1/R1 avec les doigts. Les autres boutons sont accessibles par un seul bouton rond contrôlé par le pouce.
La manette est adaptée pour beaucoup de jeux vidéo, dont les plus simples sont les jeux de voitures et de combats (arcade).

; Problèmes:
*Besoin de toute la motricité de la main, c’est-à-dire que si le patient à un doigt paralysé ou manquant, il ne pourra pas jouer avec ce gant
*Design obligatoirement droitier
*Les boutons de contrôle sont peu sensibles et peuvent nécessiter de la force
*Design compliqué et nécessitant beaucoup d’entrainement.

;Lien : https://www.youtube.com/watch?v=qV0SxSJDCYg

 
==Analyse du second concurrent==

Ben Heck, de son vrai nom Benjamin J.Heckendorn, est un concepteur de mods de consoles (mods pour modification, soit « manettes modifiées ») et une star
du net grâce à ses vidéos tutoriels.Il propose alors énormément de produits adaptés ou dérivés en guise de manettes.
Parmi les mods qu’il a réalisé, il a modifié une manette de PS4 afin de la rendre accessible à une personne ne pouvant jouer qu’à une main. Pour cela, il a déplacé les boutons en respectant l’ergonomie de la main valide et modifie les connexions. Il peut lui arriver de rajouter des boutons pour en remplacer un autre. Il réalise également le même système avec la Xbox. Sur la photo ci-dessous, il a adapté la manette pour un droitier.

; Problèmes:
*Besoin de toute la motricité de la main, c’est-à-dire que si le patient à un doigt paralysé ou manquant, il ne pourra pas jouer avec cette ma
*Design obligatoirement droitier ou gaucher, une modification = une manette= une personne
*Besoin obligé du pouce et de l’index, même si avantage : 3 doigts nécessaire.

;Lien :: https://www.youtube.com/watch?v=LieHIscadjk

==Scénario d'usage du produit ou du concept envisagé==

La technologie est ,aujourd’hui, omniprésente dans notre vie. Les consoles de jeux ont envahies les maisons avec plus de 7 personnes sur 10 jouant aux jeux vidéos sur consoles en France (chiffre de l’Express). 0,18% des français sont handicapés cela représente 12 millions de français. Dans ce chiffre, 13,4% des personnes ont un handicap moteur. En 2017, les grands groupes comme Sony ou Microsoft avec respectivement PlayStation et Xbox ne permettent pas à tout le monde de jouer avec une manette. Les manettes sont prévues pour des personnes ayant leurs membres valides, plus précisément les mains et les bras.

Après un accident de voiture, un jeune garçon a perdu la motricité d’un côté du corps. Passionné de jeux vidéo, il se retrouve avec des difficultés à jouer sur sa console PS4. Ingénieux, il utilise la manette en la coinçant entre son épaule et le creux du cou. Usant de la mâchoire et de sa main valide pour contrôler les joysticks et les boutons. L'exercice étant inconfortable et fatiguant il eu l’idée de proposer à des futurs ingénieurs de lui proposer une manette adaptée à son handicap.

Les deux pré-ingénieurs ,avec leur tuteur, ont une idée révolutionnaire : La manette modulable ! Elle permettrait au jeune garçon, ainsi que d’autres joueurs, de pouvoir continuer de s’amuser ou même de commencer à jouer au jeux sur console.
Cette manette aidera fortement dans les centre de rééducation pour faire passer le temps et donner du plaisir à des personnes qui ne peuvent plus s’amuser avec leur console traditionnelle. Elle pourra aussi ouvrir de nouvelles possibilités pour certaines personnes qui n’auraient jamais essayé jusqu'à présent.
Comme son nom l'indique, elle sera modulaire et s'adaptera à différents handicaps. Accompagnée de son application d’initialisation, elle sera accessible aussi bien aux enfants, patients, parents et aides soignantes.

Quelques mois plus tard...Le jeune patient fan de Need For Speed, peut maintenant piloter sa voiture comme un vrai professionnel grâce à l'un des joysticks qu'il utilisera avec sa main valide et il pourra accélérer à des vitesses folles à l'aide de boutons poussoirs au niveau de son pied valide et gagner la partie. Son ami venu lui rendre visite, pourra en lieu et place des aides soignantes configurer à l'aide de la tablette (portable) la manette du patient.
Si le patient change de jeu pour Tekken et que la configuration des modules ne lui convient plus, il peut interchanger les éléments de la manette selon son envie et son confort. Ainsi il peut faire sauter son personnage, il utilisera un module bouton supplémentaire, qu'il actionnera avec le poing.

==Fonctionnement==

Suite à une analyse fonctionnelle et à la formulation de notre projet, nous avons pu définir le fonctionnement de notre système. Notre produit, la manette, doit être accessible d’après nos objectifs à différents types de handicaps moteurs. Ainsi, l’idéal serait de concevoir une manette modulable afin qu’elle puisse s’adapter à toutes les situations. Ce n’est plus au patient de s’adapter à la manette mais à la manette de s’adapter au patient.
Cela signifie que la manette sera, dans la limite du possible et de la sensibilité du corps du patient, composée de plusieurs parties dites « modules » comportant un ou plusieurs actionneurs (boutons, joysticks, gâchettes...). Ces modules seront déplaçables afin d’être utilisé avec différents membres du corps : un doigt, une main,
une jambe ou même un pied. Il suffira de les connectés entre eux suivant l’organisation souhaitée, le Gameplay du jeu ou en fonction du handicap. Le tout sera relié à une application.
L’application sera alors mise en place pour connecter les différentes parties du point de vue software pour prérégler la manette en fonction du patient. Il pourra alors choisir les boutons en fonction du jeu, de ses mouvements mais aussi choisir la sensibilité.

L’application et les modules devront être intuitifs et faciles d’utilisation. De cette manière des utilisateurs non avertis dans le domaine informatique ou jeunes pourront eux-mêmes gérer les connexions.

==Réponse à la question difficile==

'''Question : Comment interconnecter les différents modules de la manette ?'''

Il nous faut pour ce projet interconnecter les modules modélisant la manette qui seront connectés à la consoles PS4 via une Raspberry Pi 3.
Le choix de la Raspberry Pi 3 nous permet d'utiliser son module Bluetooth pour communiquer avec la PS4, ce choix est plus adaptée au projet que du filaire.
Concernant l'interconnexion des modules, nous travaillerons en deux étapes "preuves concept" : filaire et sans fils (Bluetooth).

'''Objectif 1 : Preuve concept filaire'''

Dans cette première partie de projet, nous souhaitons avoir une 1ère preuve de prototype rapidement. Nous nous concentrerons alors sur la communication entre la RPi3 et la PS4 ainsi que sur la conception des modules. Pour les modules, nous réaliserons des cartes électronique pour chaque module avec un micro-contrôleur. La communication filaire nous permettra d'interconnecter les modules à la RPi3 avec un bus SPI.

'''Objectif 2: preuve concept sans fils'''

Une deuxième étape du projet est la réalisation de la solution idéale sans fils. Celle-ci pourra commencer à être développée petit à petit en parallèle avec l'objectif 1. Le but ici, est d'interconnecter les modules en Bluetooth. Nous avons choisi le Bluetooth pour garder une connexion commune sur toute la chaîne.
Nous rajouterons alors un module bluetooth à chaque module de la manette.

'''Objectif 3: possibilité d'adapter les boutons (capuchon en 3D)'''

=Préparation du projet=

==Cahier des charges==

''Chef de projet:'' Alexandre Boé 
''Responsables:'' Xavier Redon, Thomas Vantroys 
''Partenariat:'' Marc Sautelet (non etablie) 
''Elèves-ingénieurs:'' Camille Saâd, Transley Gracias 

'''Sujet :''' Manette modulable pour personne à déficience moteur compatible PlayStation 4 

===Objectifs principal (1er POC) : ===
Faire transmettre des informations issus des actionneurs (ex:boutons poussoires) via des arduinos jusqu’à la Raspberry Pi 3 en SPI. 
Envoyer les données reçues vers la PS4 en USB 

===Objectifs secondaire (2e POC):===
Créer des modules avec un microcontrôleur et une puce bluetooth pour permettre une meilleurs flexibilité (c-àd pouvoirs avoir une meilleure ergonomie et une connexion sans fil) 
Connecter la Raspberry Pi 3 en Bluetooth à la PS4 

[[Fichier: beteacorne.jpg||middle|600px|Bete a corne manette]]

==Choix techniques : matériel et logiciel==

===Liste de matériel :===

'''Modules boutons/joysticks/gachettes'''

3 Push buttons : 
- O X Y Carré R3 L3 
- Guide PS 
- start/back 
--> 0,45€/unité TTC [https://www.gotronic.fr/art-bp-miniature-krs1273-16976.htm] 

1 Thumbstick original: 
Joystick analogique 4 directions --> 4,25€/unité TTC [https://www.gotronic.fr/art-joystick-analogique-4-directions-19063.htm] 

1 buttons trigger L1 L2 => 1x Thumbstick original''' 

'''Cartes Atmega328p /connexion spi/'''

3 Arduino UNO 
1 Arduino UNO atmega328p retirable 
4 capacite 22pF traversantes 
2 resistances 10 kOhm traversantes (à récupérer) 
2 oscillateurs quartz 16MHz traversante 
2 atmega328p-pu et support 

'''Cartes module bluetooth nrf52810 '''

6 capacités 100nF 0603 
6 capacités 12pF 0603 
2 capacités 4,7pF 0603 
2 capacités 1µF 0603 
2 capacités 100pF=0,1nF 0603 (à récupérer) 
2 capacités 0,8pF 0603 (a acheter, commande en cours) 
2 inductance 3,9nH 0603 (a acheter, commande en cours) 
2 oscillateur quartz 32 MHz 

''' Connexions et autres '''

1 Led RGB neopixel [https://www.adafruit.com/product/1734] 
1 Raspberry Pi 3 
--> ~36,23€/unité TTC [https://fr.rs-online.com/web/p/processor-microcontroller-development-kits/8968660/?src=raspberrypi] 
1 Raspberry Pi Zero W (commandée) [https://www.raspberrypi.org/products/raspberry-pi-zero-w/] 
6 Alimentations 5V ou 3,3V 
par exemple, 12 piles de type CR2016 3V rechargeables ou 24 piles AAA 1,5 V rechargeables
5 modules Bluetooth nrf de Nordic : nRF52810-QFAA-R 
--> 3,17€/unité + frais expédition [https://www.mouser.fr/productdetail/nordic-semiconductor/nrf52810-qfaa-r?qs=sGAEpiMZZMve4%2FbfQkoj%252bG%2FosjLoe2oghFQwQllMrQ4%3D]
5 Lignes broches mâles 

===Logiciels:===

- IDE arduino
- Altium
- FreeCAD ou Inkscape

==Liste des tâches à effectuer==

'''Etape 1 : Gestion du projet'''

* Définition des cahiers des charges fonctionnel et technique, choix d'orientation...
* Recherche techniques sur les différentes connexions possibles entre les modules, la RPi 3 et la console PS4
#Recherche connexion SPI entre les modules et la RPi3
# Recherche connexion bluetooth entre la RPi3 et la PS4
# Recherche connexion bluetooth pour les modules
# Recherche carte avec montage Atmega328P-PU et anticipation module bluetooth
* Détermination du matériel nécessaire
* Réflexion sur l'application

'''Etape 2: Réalisation du projet'''

'''Partie 1: Preuve concept manette en filaire'''

* Conception de cartes électroniques pour 2 modules (/!\ prévoir modules bluetooth)
* Réalisation connexion SPI avec 2 modules : programmation des Atmega328p en liaison série.
* Si tests concluant, ajouter des modules jusqu'à en avoir 5 (1 pour chaque type de boutons)
* Connexion bluetooth entre la PS4 et la RPi3
* Réalisation du support des modules avec fixations possibles (imprimante 3D)

'''Partie 2: Preuve concept manette en bluetooth'''

* Ajout des modules bluetooth aux cartes électroniques
* Connexion bluetooth entre les modules

'''Partie 3: Application Android : paramétrage de la manette'''

* Créer une application sur tablette ou smartphone (Android) afin de configurer la manette aux besoins (inter-connexion des modules et console)

==Calendrier prévisionnel==

{| class="wikitable centre" width="80%"
|+
|-
| width="23%" |
'''Date'''
| width="34%" |
'''Tache à réaliser''' 
|-
| width="23%" |
17/01/18-24/01/18
| width="34%" |
Faire des recherches sur les différentes interconnexions du système : Bluetooth, RPi-Atmega328 (SPI), RPi-PS4
Continuer liste des taches, matériel, Début recherches + réflexion fixation support des modules
|-
|width="23%" |
31/01/18
| width="34%" |
Recherche technique connexion PS4-RPi3 et connexion SPI RPi3-Module + code
|-
|width="23%" |
31/01/18-07/03/18
| width="34%" |
Réalisation 1er prototype (+ début prototype 2)
|-
|width="23%" |
07/03/18
| width="34%" |
Seance 7 : Test prototype filaire
|-
|width="23%" |
07/03/18-09/05/18
| width="34%" |
Réalisation 2eme prototype + application Android
|-
|width="23%" |
09/05/18
| width="34%" |
Seance 14 : Test prototype Bluetooth
|-
|width="23%" |
14/05/18
| width="34%" |
Video projet
|-
|width="23%" |
15/05/18
| width="34%" |
Finalisation projet et Rapport
|-
|width="23%" |
16/05/18-17/05/18
| width="34%" |
Soutenances Projet
|}

=Réalisation du Projet=

==Feuille d'heures ==

Voici le tableau d'heures du binôme:

{| 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 S11 !! Heures S12 !! Heures S13et+ !! Total
|-
| Analyse du projet
| 10
| 2
| 1
| 1
| 1
|
|
|
|
|
|
|
| 20min
|
| 15h20
|-
| Cherches techniques
|
| 3
| 4
| 4
| 2
| 2
| 1
|
|
|
| 1
| 1
|
|
| 18
|-
| Rédaction du wiki et rapport de projet
|
| 1
| 1
| 1
| 1
| 30min
| 1
|
| 2
| 30min
| 30min
|
| 2
|
| 10h30
|-
| Programmation
|
|
|
|
| 3
| 2
| 3
| 5
| 4
| 7
| 8
| 6
| 5
|
| 43
|-
| Cartes électroniques
|
|
|
|
|
| 6
| 8
| 4
| 6
| 2
| 1
| 2
| 2
|
| 31
|-
| Application
|
|
|
|
|
|
|
|
|
|
|
|
|-
|-
| Total Semaine
| 10
| 6
| 6
| 6
| 7
| 10h30
| 13
| 9
| 12
| 9h30
| 10h30
| 9
| 9h20
|
| '''117h50'''
|}

==Prologue==

Avant la réalisation et conception d'un projet, il est important d'analyser celui-ci. Nous avons allons consacré le prologue à l'analyse fonctionnelle de la manette. Nous avons également eu une réflexion sur l'analyse technique, cela nous a permis de réaliser une liste de matériel. Il est important de définir les objectifs ainsi que les besoins afin de ne rien oublier. (Voir ci-dessus Analyse projet)
Nous avons également organisé notre travail, pour le partage de documents de recherches et la rédaction de compte-rendu final nous avons réalisé un google drive. Par la suite, nous créerons un projet Git.

Durant ce temps, nous avons décidé de réaliser 5 modules. Les modules sont les différents boutons de la manettes qui nous pourrons placer selon nos choix (boutons modulaires) pour notre prototype projet pour chaque type des boutons d'une manette PS4. Ces modules devrons être connectés à la console et interconnectés. Le tout sera lié à une application Android. Suite à quelques recherches et nos analyses, nous avons décidé les points suivants :

- On commencera avec 2 modules et on les multipliera par la suite.
- Les premiers tests sont réalisés avec des boutons petits pour assurer leur caractéristique "modulaires", par la suite nous pourrons ajouter des capuchons de taille plus importante (imprimante 3D ou achat)
- Conception modules : réalisation de carte avec un microcontrôleur atmega328 programmable pour chaque module (anticiper le module Bluetooth)
- Projet en 2 parties : prototype filaire et prototype Bluetooth
# Prototype filaire : connexions entre les modules et la RPi3 en SPI, connexion Rpi3-PS4 en Bluetooth, avec l'application en filaire à la RPi3
# Prototype Bluetooth: connexion Bluetooth entre modules-RPi3-PS4-apllication

[[Fichier: structuremanette.png||center|400px|Concept manette modulable]]

==Semaine 1==

Durant la séance, nous nous sommes concentrés les recherches afin de définir clairement le cahier des charges technique. Il s'agit des réalisations à mettre en œuvre pour les inter-connexions des éléments de la manette.
Ainsi, nous avons fait des recherches sur :

===Connexion SPI entre les modules (Atmega328p) et la RPi3===

SPI: Serial périphérique interface BUS

[[Fichier: yWGmW.png||right|200px|Concept manette modulable]]
Comme indiqué sur l'image ci-dessus, la Raspberry pi 3 peut communiquer en SPI avec ses broches CS0 (24), CS1 (26), SCLK (23), MISO (21), MOSI (19). Celles-ci permettent de communiquer avec un ou plusieurs esclaves (dans notre cas, des Atmega328p) en reliant directement les broches concernées de la RPi3 à celles des composants esclaves.
Chaque broche CS0 (24) ou CS1 (26) ne peut être connectée qu'à l'entrée SS (aussi appelé CS) d'un seul esclave.
C'est a dire que chaque CS est lié à un esclave afin de choisir avec lequel la communication est établie à un moment donné, et les MISO sont reliées entre elles en cascade, de même pour les SCLK et les MOSI. On peut noter que le maître impose la fréquence d’horloge et sélectionne l’esclave auquel les données sont envoyées. 8 MHz est le plus rapide supportable a 3,3V

[[Fichier: fonctionnementSPI.png||right|200px|Connexion SPI multi-esclaves]]

Voici un schéma du fonctionnement souhaité :

Comme nous souhaitons avoir 5 modules environ il nous faudra rajouter un composant en plus afin d'augmenter les possibilités de sélection, par exemple des démultiplexeurs.
Dans un premier temps nous essaierons avec 2 esclaves, puis on augmentera le nombre.

===Connexion Bluetooth PS4-RPi3===

Les recherches portent également sur la connexion entre la manette PS4 et la console. Elles concernent le protocole de communication via Bluetooth

Caracteristique pour la PS4: Bluetooth®v4.0, Qualcomm Atheros AR3002 Buetooth LE: 2,4-2,5 GHz 

Caracteristique de la connexion : 

*Vitesse de transmission >> 3 Mbit/s 8N1
*Relevé tous les 1.3 millisecond (peut-être)
*Chaque manette à une adresse unique BD_ADDR qui correspond à l’adresse MAC de la carte Réseau
*Protocole de détection est le SDP basé sur une emission reception PDU
*L’Attribut ID est representer en TLV Type Length Value
*Communication HCI ACL Data Packet

===Rélisation des cartes électroniques===

matériel nécessaire pour un PCB : 

*breadboard
*câbles
*1 x 10k Ohm résistance
*Quartz 16Mhz clock crystal
*2 x 22 pF capaciteurs
*Atmega328P-PU

Ressources:
[[https://www.arduino.cc/en/Main/Standalone]]
[[http://www.eprojectszone.com/atmega-328-pu-standalone/]]
[[https://www.arduino.cc/en/Tutorial/ArduinoToBreadboard]]

==Semaine 2==

Durant la semaine deux et durant la séance, nous avons continué et approfondie nos recherches sur le projet. Nous avons pu ainsi affiner nos taches de réalisation et donc notre cahier des charges.

===Connexion aux modules: SPI et Bluetooth ===

 CORRIGER

voir https://peip-ima.plil.fr/mediawiki/index.php/BE_2017-2018#Configuration_du_syst.C3.A8me_embarqu.C3.A9

(sudo apt-get install pi-bluetooth)

''connexion sur la raspberry par ssh:''
su
update-rc.d ssh enable
invoke-rc.d ssh start
ssh pi@172.26.79.1XX

''bluetooth''
bluetoothctl
agent on
default-agent
scan on
pair [device Bluetooth address] (exemple: pair XX:XX:XX:XX:XX:XX )

''NOUVELLE REFLEXION : Connexion SPI entre les modules (Atmega328p) et la RPi3 --> MODULES BLUETOOTH''

Si multi-esclaves= plusieurs modules :
Il faut ajouter des sélections pour les SPI → démultiplexeurs OU ne pas utiliser les CS0 et CS1, et plutôt des pins entrée/sortie de la RPi3 lié au SS comme ça on choisit direct le module esclave voulu.

'''IMPORTANT:''' Nous avons étudié à nouveau la datasheet de notre module bluetooth nrf de Nordik. Le module bluetooth comporte déjà un microprocesseur !
Un module plutôt peut donc jouer le rôle de notre atmega328p. Il n'y a alors pas besoin de réaliser des cartes électroniques de type arduino standalone. Nos PCB regrouperont alors uniquement l'alimentation, un actionneur (bouton, joystick), le module bluetooth et les broches de connexion si besoin...

Cette séance nous a alors permise de revoir entièrement le matériel nécessaire. Notre liste de matériel nous semble alors plus réfléchie et limitée au nécessaire.

===Connexion Bluetooth PS4-RPi3===

Suite à nos recherches de la semaine précédente, nous avons sélectionné deux sites bien renseignés :

SITES

Ils nous ont permis de comprendre la communication entre la manette et la console. En effet, ils nous expliquent les échanges de trames Bluetooth.
EXPLICATIONS 1 exemple 

==Semaine 3 : Début premier prototype==

===Connexion SPI RPi3-Arduino===

Comme vu durant les semaines précédentes, nous souhaitons réaliser une connexion Multi-esclaves en SPI entre la Raspberry pi et plusieurs modules.
Cette semaine nous avons vu que la réalisation de notre premier prototype doit aller vite. Il ne nous est pas nécessaire d’attendre les modules bluetooth si il nous faut dans cette partie uniquement utiliser son microprocesseur. Ainsi pour chaque module nous utilisons une arduino UNO. Nous réaliserons les programmes en C afin de pouvoir les réutiliser avec les modules bluetooth par la suite.
Une fois la connexion réalisable nous adapterons les programmes aux modules bluetooth Nordik. En effet, ceux-ci comporte déjà un microprocesseur, le module peut jouer le rôle de notre atmega328p. Il n'y a aurait alors pas besoin de réaliser des cartes électroniques arduino standalone sur PCB, mais directement des cartes électronique avec le module et le module voulu (bouton, joystick...) et l'alimentation.
Durant la séance nous avons alors revu la liste de matériel nécessaire.

[[Fichier: prototype1.jpeg||center|600px|connexion filaire prototype 1 filaire arduino]]

Durant la séance, nous avons recherches des exemples de codes et de librairies pour Arduino SPI et RaspberryPI SPI.

Nous avons également commencé le programme de la connexion SPI pour l'arduino et récupéré les bibliothéques SPI.h avec SPI.c. Nous nous sommes alors concentrer à les comprendre, pour pouvoir l'utiliser.

===Réalisation du projet Git===

Création du projet IMA4_Projet35_ManetteModulable sur Git et partage de celui-ci.
Les premiers dossier crées cette la séance :
-Arduino (connexion SPI arduino) : ProtoSpi.c + dossier librairie SPI + Makefile
-RPI (dossier codes pour Rpi)
-Readme.md
Ces dossiers seront amenés à être modifiés au cours des séances.

===Protocole Bluetooth PS4===

Suite à l'étude des trames Bluetooth, on a pu voir que ces dernières étaient incomplètes. Le modèle de communication étant propriétaire, on n'y a pas accès directement. Cela nous empêche donc de mettre en oeuvre cette communication.
 Déveloper

On a décidé de commencer par une connexion USB (pour laquelle on dispose de toutes les informations) celle-ci étant plus complète.

==Semaine 4==

Pour le prototype 1 FILAIRE nous réaliserons les étapes suivantes :

#Réalisation du programme SPI pour arduino
#Réalisation du programme SPI pour la RPi
#Connexion USB avec la PS4 ou ordinateur
#Réalisation de cartes électroniques atmega328p-pu standalone (remplacer les Arduinos)
#Remplacer les "PCB arduino" par le module bluetooth et adapter la connexion
#Conception 3D de la délimitation 1 axe pour le joystick "gâchette"
#Réalisation de l'application Androïde.

Une fois ces étapes réalisées nous auront alors une preuve de concept filaire et nous pourrons alors passer à une connexion bluetooth.
Le passage à la connexion bluetooth sera le deuxième prototype et le cas idéal de la réalisation de la manette modulable.

===Mise à jour Matériel===

- Modéliser les boutons gâchettes L1/2 R1/2 de la manette PS4 (boutons sensibles à la pression) --> un joystick dont nous bloquerons un axe (imprimante 3D)
- Remplacer la RPi 3 par une Rpi zero W qui nous permettrait de réaliser plus facilement une connexion USB tout en gardant l'avantage du bluetooth.
- Choix de l’alimentation pour les 5 modules Bluetooth: nécessitent 3V --> utiliser des piles rechargeables 1,2V AAA plutôt que piles rondes 3V.

Nous avons également besoin du matériel cité en semaine 1 pour réaliser des cartes électroniques atmega328p-pu standalone. ( nous revenons alors sur les décisions de la semaine 3)

===Connexion SPI RPi3-Arduino===

Montage Raspberrypi et 1 arduino en PSI + 1 bouton + 1 led.
Voici le choix des branchements :

MASTER = RPi
SLAVE= Arduino

'''SPI sur Arduino:'''
MOSI -> GPIO11 //PB3 //master OUT to the slave IN
MISO -> GPIO12 //PB4 //slave OUT to the master IN
SCLK -> GPIO13 //PB5 //serial clock
SS -> GPIO10 //PB2 //slave select
'''Led, bouton et autre...'''
LED --> GPIO6 //PD6
GND
+5V (if required)
'''SPI sur la Raspberry Pi'''
SPIO MOSI -> PIN19
SPIO MISO -> PIN21
SCLK -> PIN23
SPIO CS0 -> PIN24

Continuation du code pour faire clignoter Led branchée à une arduino depuis la Rpi, en connexion SPI.

===Connexion USB PS4-RPi3===
Durant cette, nous avons regardé comment faire cohabiter bluetooth, Application Androïd, USB, PS4, SPI et les module.

Il est alors important de savoir comment utiliser le port série sur la RPi3, soit utiliser les UART.

Nous avons réaliser qu'il n'était pas aussi simple d'utiliser le port serie USB de la Raspberry Pi 3, en effet le SoC est un BCM2837 .
De plus nous ne pouvons pas utiliser le même port pour l'alimentation et la connexion.

Il nous faut alors trouver une alternative ou une solution à ce problème.

==Semaine 5==

===Programmation: Réflexion définitives prototypes filaire ===

La semaine dernière, nous avons rencontré une difficulté liée aux ports séries UART.
Une des solutions à cette difficulté serait d'utiliser une RPi ZERO W à défaut d'une RPi 3. On pourrait alors avoir un port d'alimentation avec connexion USB mais également retrouver la connexion Bluetooth dont nous avons besoin.

Ensuite, nous avons continué la réalisation du prototype filaire par l'avancé du code SPI ainsi que les recherches concernant le protocole PS4.

La Raspberry Pi zero W peut également être utile pour la connexion entre la PS4 et les différents modules en jouant le rôle d'intermédiaire. Nous avons alors commandé une Rpi zero W pour notre projet.
En attendant la réception de la commande, nous nous sommes penché sur les recherches pour les programmes et la configuration nécessaire à l'utilisation de la RPi zero W.

===Electronique===

[[Fichier: bouton_c1.jpg|100px|thumb|left|PCB bouton]]
[[Fichier: arduinobb.jpg|200px|thumb|right|atmega328p-pu branchement test]]

Du coté électronique, nous avons réalisé sur fritzing certaines cartes électroniques. Les Arduino Uno servant actuellement de test, seront remplacées par des PCB atmega328p-pu standalone avec des broches permettant les branchements nécessaires SPI ou encore aux modules "boutons/joystick". Pour les boutons, nous avons également réalisé un pcb afin de faciliter les branchements.

Il nous faut alors également une 3eme carte qui nous sera nécessaire pour la réalisation du prototype sans fil. Dans notre liste de matériel, nous avons des composants nrf52810 bluetooth, ceci doivent être soudé avec les capacités de protection mais également des broches de communication. Nous avons alors commencé cette carte électronique sur Altium avec le fichier projet PCB du distributeur à modifier.

[[Fichier: Arduino_c1.jpg|100px|thumb|center|PCB atmega328p-pu]]

=== Construction 3D ===

Enfin, nous avons commencé à réaliser des boîtiers 3D pour certains modules. Par exemple, comme nous l'avions vu précédemment, un des joysticks servira de bouton-gâchette en utilisant un seul de ses axes. Il nous faut alors réaliser un boitier qui bloque l'un des axes, mais également une tige qui nous permettra de pousser le joystick de manière simplifiée.

==Semaine 6==

===Programmation: configuration RPi Zero W ===

Ayant reçu la Raspberry Pi zero W en début de semaine, nous nous sommes concentrés sur la programmation et la configuration de celle-ci.
Cette partie étant compliquée, elle nous a pris du temps. En effet, il était difficile de connecter la RPi en SSH car il n'est pas possible d'y connecter un clavier directement et on avait besoin de la prise OTG pour "interfacer" la manette.

===Electronique: PCB nrf52810===

Les cartes réalisées en semaine 5 sont validées et en attente de réalisation.

Cette semaine a permis la réalisation et la finalisation de la carte électronique nrf52810. Il nous a fallu recommencé cette carte deux fois. En effet, une fois finie sur Altium nous avons réalisé que les empreintes des CMS sur PCB fourni par le constructeur ne correspondent pas au matériel CMS de l'école. Face à cette inattention de notre part, nous avons décidé de refaire entièrement la carte électronique sur fritzing. Ayant la datasheet et des plans d'inspiration PCB, nous avons pu refaire la carte entièrement.
Sur celle-ci nous avons ajouté des broches de connexion au besoin, un branchement Jtag et ICSP pour la programmation et la connexion SPI.
La carte est en attente de validation, puis validation.

[[Fichier: nrf52810_circuit2.jpg||center|400px|PCB carte nrf52810]]

===Révision matériel ===

Pour la réalisation de nos composants électroniques, il nous a fallu faire une révision des composants disponibles à l'école:
(les quantités indiquées ci-dessous pourront être augmentée si nécessaire,pour avoir dans l'idéal un module de chaque type de la manette, ici on se concentre sur BOUTON et JOYSTICK)

'''Cartes Arduino:'''
* 4 capacite 22pF traversantes
* 2 resistances 10 kOhm traversantes (à récupérer)
* 2 oscillateurs quartz 16MHz traversante
* 2 atmega328p-pu et support

'''Cartes nrf52810'''
* 6 capacités 100nF 0603
* 6 capacités 12pF 0603
* 2 capacités 4,7pF 0603
* 2 capacités 1µF 0603
* 2 capacités 100pF=0,1nF 0603 (à récupérer)
* 2 capacités 0,8pF 0603 (commande en cours)
* 2 inductance 3,9nH 0603 (commande en cours)
* 2 oscillateur quartz 32 MHz

'''Cartes modules Boutons'''
* un sachet de broches mâles (qu'on utilisera également pour les autres cartes, à récupérer/acheté)

Nous avons alors mis-à-jour la liste de composant située plus haut, ainsi que celle de la page IMA4 2017/2018 [https://projets-ima.plil.fr/mediawiki/index.php/Projets_IMA4_SC_%26_SA_2017/2018]

==Semaine 7==

===Programmation: connexion wifi RPi Zero W et Bootloader sur Atmega328p-pu ===

Pendant cette semaine, nous avons continué la programmation et la configuration des Raspberry Pi 3 et Zero W afin de les utiliser en connexion Wifi.

Nous avons également continuer les programmes de récupération de données : état des boutons et du joystick. Ces programmes sont appliqué sur l'atmega328p-pu standalone sur la plaque d'essai en attendant que le PCB soit opérationnel.
Pour pouvoir programmer l'atemega328p-pu comme une arduino UNO, il nous faut suivre plusieurs étapes :

'''1.Flasher le Bootloader'''
Nous avons 2 Atmega328p-pu neufs, ainsi il nous faut flasher le bootloader sur chacun d'eux afin de pouvoir les utiliser et les programmer sur une breadboard dans un montage minimaliste arduino-standalone.
Pour cela, on peut utiliser une carte arduino UNO. On vérifie le port et le type de carte sélectionnés dans le menu >Outils. Sur cette carte on téléverse le fichier arduinoISP.ino qui se trouve dans les exemples en étant en progrmamateur AVr ISP mkll (>outils>programmateur)
Puis on met l'atmega328p-pu qui nous intéresse sur le suppor socket de la carte. On change de nouveau le programmateur pour Arduino as ISP et on fait >tools>burn bootloader, soit >graver la sequence d'initialisation.
Ces étapes faites, on peut retirer notre microcontroleur et le replacer correctement dans le montage.

'''2.Programmation atmega328 sur breadboard'''
Une fois l'atmega328p-pu préparé, on peut le programmer. On peut le faire simplement à l'aide de la carte arduino UNO utilisée précédemment.On branche les Tx et Rx en commun ainsi que le reset, le GND et le VCC.

Nous avons réaliser des codes basiques tels que le clignotement d'une led rouge ou encore l'affichage de "hello world" sur le moniteur série pour vérifier la bonne fonctionnalité du montage. Cela fait nous avons pu écrire sous Arduino IDE le code de lecture des états.

[[Fichier: montage_BB_test.jpg||left|200px|programmation modules arduino sur breadboard]]

===Electronique : soudure carte de test modules ===

Comme nous l'avons déja vu lors de la réalisation des PCB, si l'on souhaite programmer un atmega328p-pu en bootloader, le montage est simple. Il peut être minimaliste en utilisant une arduino UNO, un atmega328, une breadboard et 3 composants: 1 quartz 16MHZ crystal, 1 résistance 10kOhm et 2 capacitors céramiques de 22pF.
Durant la semaine 7, nous avons soudé les composants traversants de la carte électronique correspondant à ce montage ainsi que le PCB du bouton.

==Semaine 8==

===Programmation ===

===Electronique : Correction soudure et soudure CMS===

Durant cette semaine, nous avions souhaité programmer la carte électronique atmega328p-pu. Cependant, nous avons réaliser que nous avions fait une erreur lors de l'envoie du PCB à la production. En effet, celui-ci avait été fait en Top sur le logiciel Fritzing et non en Bottom. Hors nous avions soudé les composants (durant la semaine 7) comme pour un circuit imprimé en bottom, l'atmega328p-pu se retrouve alors inversé par rapport aux pistes.
Comme solution, nous avons choisi de souder un deuxième support pour l'atmega328 de l'autre coté de la carte avant de la refaire au propre. En effet, avant de la refaire il nous faut vérifier si la carte est bien programmable.
Une fois cela fait nous avions pu programmer la carte mais, nous avions également réalisé la pin 2 de l'atmega328 était prise par le bouton poussoir. Or, nous avons besoin des pin 2 et 3 pour le RX et TX permettant la programmation de l'atmega à partir d'une arduino, les pistes branchement RX-TX n'ont également pas été prévus pour le téléversement des programmes sur la carte. Il nous faut alors couper une piste et souder des câbles pour utiliser toutes les pistes souhaitées.

[[Fichier: correction_proto_PCB.jpg||right|300px|PCB arduino correction]]

Durant cette semaine, nous avons également souhaité souder les CMS et le composant bluetooth nrf52810 sur la carte imprimé et reçu lors de la semaine 7. Pour cela, nous avons convenu de travailler dans la C202 durant la séance du mercredi.

[[Fichier: PCB_nrf52810.jpg||left|400px|carte electroniques imprimées]]

====Comment souder des CMS ?====

les CMS sont des composants montés en surface c'est à dire qu'ils sont montés du même côté que les pistes cuivrées (à l'opposé des composants traversants) et sont de petite tailles souvent de l'ordre du millimètre. La taille est déterminée par 4 chiffres : les 2 premiers pour la longueur et les 2 derniers pour la largeur. On a du 1206,0805,0603 ou encore 0402. Il est même possible de trouver plus petit. A l'école nous utilisons souvent du 0603, c'est le cas de nos composants.
Pour souder des CMS 0603, il nous faut utiliser une autre méthode qui n'est pas le fer à souder :
# Préparer la veille la pâte à braser la veille (dans une seringue)
# Gommer la carte pour éviter l'oxydation (attention à ne pas retirer les miettes de gomme en soufflant dessus)
# Appliquer avec la seringue la pâte sur les empreintes et piste souhaitées. Pour les endroits difficile à atteindre ou avec 2 pistes proches les unes des autres, il est possible de mettre la même goutte de pâte sur les 2 pistes. Cela de causera pas de court-circuit par la suite. En effet, la pâte est composée d’alliage qui sous la chaleur va se fluidifier et se coller uniquement aux pistes métallique. Le reste fondera sous la chaleur du four.
# Appliquer les CMS sur la pâte au fur et à mesure (attention ! ne jamais toucher les CMS avec les doigts, tjrs utiliser une pince)
# Mettre au four

====Bilan soudure nrf52810====

Cependant, une fois le matériel nécessaire préparé, et la pâte mise sur les pistes souhaitées, au moment de déposer le composant, nous avons réalisé que celui-ci était beaucoup plus petit que l'empreinte sur le PCB. Il s'agit d'un composant boitier QFN48. Fritzing ne proposant au plus proche des boitiers QFN24 ou LQFP48, celui-ci a basculé automatiquement pour un boitier LQFN48, de dimension plus grande. Face à ce manque de vigilance, nous avions cependant commencer par le nrf52810 (composant concerné) évitant ainsi de gaspiller d'autres CMS.
Nous avons souhaité refaire la carte sous Altium à partir des fichiers fournis par le concepteur (chose que nous avons commencé à faire aux alentours de la semaine 5)
Après la réalisation du schématic, et de la modification des empreintes de capacités, inductances et autres composants de 0402 à 0603. Notre matériel ne permettant que des empreintes 0603.

Lors du routage, une erreur de chevauchement des pistes est notifiée par Altium au niveau du nrf52810. Celles-ci ne présentent pas d'angles et sont déjà de taille 8mil, il nous faut alors passer les pistes en 6mil. Mais 8mil est la taille minimale pour la production à Polytech, nous avons regardé pour envoyer les cartes à faire ailleurs mais le 6mil n'est pas beaucoup conseillé. De plus, il n'est peut-être pas judicieux de continuer avec le composant microcontrôleur-bluetooth Nrf52810 qui prend du temps, donc la carte est difficilement réalisable et peut-être très long à programmer.

Ainsi en cette fin de semaine, nous avons décider face à l'avancer du projet de laisser les nrf52810 de coté et de les remplacer par des modules sans fils plus simples d'utilisation et complets. Ainsi nous aurions plus de chance d'avoir une connexion sans fils entre les modules. Nous pourrions par exemples utiliser des Xbee, des modules Rf...

==Semaine 9==

====Programmation: PS4 et 1er Test SPI sur atmega328p====

'''Raspberry Pi Zero W et PS4'''

'''Modules Atmega328p et SPI'''

Une carte PCB arduino fonctionnant, nous pouvons la programme pour simuler un module. Celle-ci a été designée afin de s'adapter au module que l'on souhaite. Il suffit de brancher le bouton, le joystick ou autre élèment de manette souhaité.
Cette semaine ci, nous avons alors configurer la partie communication SPI pour l'arduino.

'''Que voulons-nous faire avec les atmegas ?'''
Les cartes électroniques atmega328p vont nous permettre de recevoir les requêtes SPI envoyées par la raspberry pi et d'y répondre. La Raspberry enverra un message, par exemple "1", et l'Arduino lira alors l'état du module qui lui est connecté. Une fois l'état récupéré elle le renvoie à la raspberry pi.

Durant cette semaine, nous avons programmé l'atmega afin qu'il soit en esclave, qu'il reçoive un de la RPi "1" et retourne une valeur sauvegardé "int envoi". Nous avons également commencé les tests pour la lecture de l'état d'un bouton (d'après les tests réalisés les semaines précédentes).

'''Code'''
Comme nous l'avons vu précedement lors de nos recherches (semaines 1 à 4) :
La communication SPI nécessite l'utilisation des pins:

MOSI -> GPIO11 //PB3 //master OUT to the slave IN
MISO -> GPIO12 //PB4 //slave OUT to the master IN
SCLK -> GPIO13 //PB5 //serial clock
SS -> GPIO10 //PB2 //slave select

Il faut également paramétrer l'atmega328p en Slave. On note que dans un premier temps, le programme sera codé avec l'arduino IDE (fichiers .ino). Une fois l'ensemble SPI RaspberryPi-Arduino fonctionnant, on remplacera ces codes par du langage C ou C++.

Pour faire la connexion SPI sur l'atmega328p, on utilise la librairie arduino SPI.h, on a alors directement les fonctions nécessaires intervenant sur les registres souhaités : SPCR (spi control register), SPSR (spi status register) et SPDR (spi data register).

#include <SPI.h>

Il est important d'initialise d'abord le setup et on active le port série pour pourvoir utiliser le moniteur série. (Cela servira à verifier la valeur envoyée par la RPi)

void setup (void)
{
Serial.begin (9600);
pinMode(MISO, OUTPUT); //configuration en esclave *master in slave out*
pinMode(buttonPin,INPUT); //config pin bouton
// turn on SPI in slave mode
SPCR |= _BV(SPE);
// preparation interruptions
pos = 0; // buffer empty
process_it = false;
// activation interruptions
SPI.attachInterrupt();
}

On oublie pas de déclarer les interruptions afin de bien lire la requête reçue.

// SPI interrupt routine
ISR (SPI_STC_vect)
{
byte c = SPDR; // grab byte from SPI Data Register
// add to buffer if room
if (pos < sizeof buf)
{
buf [pos++] = c;
// example: newline means time to process buffer
if (c == '\n')
process_it = true;
} // end of room available
} // end of interrupt routine SPI_STC_vect

Dans la loop main, on traite la requête et on utilise '''SPI.transfer(envoi);''' pour transferer à la RPi les données souhaitées.

Durant cette semaine, nous avons également commencé des programmes de test SPI pour la RPi. Il s'agit principalement de programmes de tests tout faits permettant de vérifier la connexion entre cette dernière et l'arduino. Par exemple, la RPI envoie "bonjour" et l'arduino lui retourne ce qu'elle reçoit, soit "bonjour". Sans succés alors.

====Electronique : Fritzing révision====

Lors de la semaine, le modèle PCB de la carte arduino a été réalisé de nouveau sous fritzing avec les broches et connections manquantes. Nous avons également revu la configuration du bouton reset et ajouté une led d'état de l'alimentation. Nous avons ainsi envoyé deux cartes identiques à la réalisation.
La carte déjà soudée lors des derniers jours fonctionnant, elle nous sert de prototype de programmation. Nous pouvons ainsi avancer à la fois sur la programmation des modules mais aussi sur leur réalisation.

==Semaine 10==

====Programmation : PS4 et SPI sur RPi====

'''Raspberry Pi Zero W et PS4'''

'''Modules Raspberry PI et SPI'''

Durant cette semaine, pour la partie Atmega328p-Modules, nous nous sommes concentrés sur la programmation de la communication SPI avec la raspberry pi. Cette semaine a permis une étude plus approfondit sur le fonctionnement pour la RPi.

On rappelle, comme vu des semaines 1 à 4, pour la RPI3 (tout comme la RPi Zero W) utilise les broches : SCLK (23), MISO(21), MOSI (19) et SPI CS0 (24), SPI CS1 (26).
On la programme en Master. A l'aide des fichiers tests d'inspiration, on pourra directement programmer la RPi en C. Lors de la réalisation du code, il y a 3 étapes : l'initialisation/parametrage en SPI pour être maître, l'envoie de la requête puis la réception de données en retour.

Programmant en C, il ne faut pas oublier les librairies suivantes :

#include <stdint.h>
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
#include <getopt.h>
#include <fcntl.h>
#include <sys/ioctl.h>
#include <linux/types.h>
#include <linux/spi/spidev.h> //pour SPI

On va déclarer des variables globales permettant le paramétrage :

static const char *device = "/dev/spidev0.0"; //si on veut CS0 pour atteindre notre SS
static uint8_t mode; //mode est par défaut à 0
static uint8_t bits = 8; //bits par mot échangé
static uint32_t speed = 500000;
static uint16_t delay;

Dans notre main, on ouvre le port (la connexion) au device souhaité, on vérifie les paramètres (registres, connexions...) puis exécute la fonction transfer(fd). transfer(fd) transmet la requête et s'occupe de la réception.

fd = open(device, O_RDWR);
transfer(fd);
close(fd);

==Semaine 11==

====Programmation: PS4, SSH et tests SPI (RPi3&Atemga328p)====

'''Raspberry Pi Zero W et PS4'''

'''Raspberry PI, Atmega328p et SPI'''

Afin de facilité la programmation en utilisant Ethernet, nous avons installer et configuré la RPi pour l'utiliser en SSH depuis les ordinateurs de la E306. En effet, SSH permet de se connecter à distance sur une machine en utilisant un compte utilisateur de la dite machine. En mettant ssh, on pourra directement agir sur les fichiers de la raspberry depuis un terminal de notre PC. Pour cela, on a d'abord vérifier l'adresse IP de notre raspberry pi : 172.26.145.106 avec un écran mais on peut aussi utiliser les commandes ip a et ifconfig. Puis activer le ssh sur la raspberry pi.
On modifie alors le fichier config.txt mais également etc/network/interfaces pour configurer la bonne interface Ethernet sur la raspberry pi.

[[Fichier: configSSH_raspi.png||left|300px|config ssh ethernet]]

Il nous suffit alors de taper la commande : ssh pi@172.26.145.106 pour accéder à notre RPi.

Nous avons continué à réaliser la communication SPI avec des tests entre une arduino UNO et la RPI3. Nous avons commencé par des tests simples inspirés des études de deux semaines précédentes et modulés selon notre utilité.
Nous arrivons alors à lire l'état envoyer "bonjour" et recevoir "ça va" ou encore "1" et recevoir "3". Il faut noter que le SPI échange des trames, la RPI reçoit alors des hexadécimaux.
Nous avons alors continué pour recevoir l'état du bouton ou du joystick lors de l'envoie de "1" sur l'Arduino328p. La semaine prochaine nous testerons ces même codes fonctionnels sur les cartes atmeg327p.

A la fin de cette semaine, nous avons alors des codes Arduino-SPI (.ino) et des codes Raspberry-SPI (.c) permettant l'échange de données. Le but est maintenant de l'adapter aux cartes imprimées et de le rendre pleinement fonctionnel pour plusieurs cartes à la fois, puis ajouter une boucle de vérification en continue jusqu'à une deuxième requête de la RPi.

====Electronique: réalisation au propres des PCB modules====

Suite à une nouvelle erreur de réalisation cartes électronique, nous avons refait et renvoyé à nouveau les cartes imprimées atmega328p.
Nous les souhaitons au propre pour une version finale. Une fois celle-ci imprimées nous pourrons en avoir 3 , un pour chaque module. Les cartes étaient bien imprimées en bottom mais lors du passage des traversants de bottom à top, le logiciel ne les a pas fait miroiter. Par manque d'attention nous avons alors envoyé les fichiers gerber pour des cartes ayant les composants du même coté que la couche de cuivre.
Les cartes électroniques actuelles sont alors correctes et fonctionnelles mais difficile à souder. Pour eviter les erreurs et continuer sur des prototypes de carte nous préférons attendre en nous concentrant sur la programmation PSI de la Raspberry Pi.

==Semaine 12==

====Programmation====

'''Raspberry Pi Zero W et PS4'''

'''Raspberry PI, Atmega328p et SPI'''

- réflexion: penser à faire boucler sur l'arduino une fois la requête reçu, ça veut dire que la manette est ON et donc vérifier continuellement les modules sur chaque atmega.
- SPI raspberry pi - arduino recuperation état du bouton avec les cartes modules (/!\ récuperation à faire dans une variable)

-SSH perso
adresse Rasppi: 192.168.137.10

====Electronique: Finalisation soudure Modules====

Soudure au propre et finale d'une carte atmega328p et donc envoie pour la réalisation de 2 autres cartes similaires et récupération de matériel
Soudure des 2 autres cartes, + tests sur les états = fonctionnelles.
On a donc bien 3 cartes pour les 3 modules de types différents (1 bouton, 1 joystick, 1 gachette)
PCB pour les 2 joysticks (qui serviront de thumbstick et gachette)

==Semaine 13 et plus==

====Programmation====

'''Raspberry Pi Zero W et PS4'''

'''Modules Atmega328p et SPI'''

====Electronique====

=Documents Rendus=

(à mettre rapport + git + drive)

=Datasheets=

IMA4 2017/2018 P35

2018-05-05T18:47:13Z

Tgracias : /* Programmation: Réflexion définitives prototypes filaire */

__TOC__
 

=Présentation générale: Manette modulable=

==Description==

Tout le monde joue aux jeux vidéo cependant, les manettes ne sont pas adaptées aux personnes ayant un handicap pouvant toucher les bras ou les mains.
C’est le cas, de plusieurs patients dans les centres de soins et de rééducation.

Pour ce projet IMA4, nous travaillerons avec le centre SSR (soin de suite et de réadaptation) Marc Sautelet de Villeneuve d’Ascq.
Un adolescent, patient de Marc Sautelet, est passionné par les jeux vidéo. En effet, ayant perdu la motricité d’une partie de son corps, il ne peut pas jouer à deux mains. Pour cela, il bloque la manette entre son épaule et son coude, usant de la mâchoire et des doigts pour contrôler les
joysticks et les boutons. Cet exercice peut s’avérer fatiguant et pénible.

Ainsi, nous chercherons à concevoir une manette PS4 adaptée au handicap de l’adolescent.
Cette manette devra aussi être adaptée pour d’autres patients présentant également des handicaps moteurs. Ainsi nous prendrons pour cibles: tous les patients du centre voulant jouer; et non pas que les enfants et adolescents.

 

{| class="wikitable centre" width="80%"
|+
|-
| width="23%" |
Membre du projet
| width="34%" |
Transley Gracias et Camille Saad
|-
| width="23%" |
Cible
| width="34%" |
Patient présentant un handicap moteur
|-
|width="23%" |
Période du projet
| width="34%" |
janvier 2018 - mai 2018
|-
|width="23%" |
Partenaire/Client
| width="34%" |
Centre SSR Marc Sautelet à Villeneuve d'Ascq
|}

==Objectifs==

Ce projet a pour objectif de créer un prototype de manette qui puisse interagir avec la console PS4 et dont le paramétrage se fait à l’aide d’une application mobile et/ou web. Cette manette devra suivre les demandes du patient ainsi que des aides-soignantes du centre, dans la mesure du possible.

Plus précisément, pour le premier prototype, nous mettrons en œuvre l'utilisation de quelques boutons spécifiques:

* Un joystick (type L/R)
* Quelques boutons poussoirs (type Croix/Triangle/Carré/Rond/R1/L1/Start/...)
* Des boutons gâchettes progressives (type L2/R2).

Le but serait donc dans un premier temps de rendre fonctionnel un bouton de chaque type, puis de les multiplier une fois cela fait. Tous ces boutons réunis constituent une manette fonctionnelle.Ainsi, la manette sera ajustable, c’est à dire qu’elle devra s’adapter aux différents handicaps moteurs possibles.

=Analyse du projet=

==Positionnement par rapport à l'existant==

Notre prototype aura une présentation unique par rapport à l’existant. En effet, les concurrents et produits existants ciblent pour la majorité un seul handicap. Cela
engendre une solution fermée à beaucoup de patients. Notre projet propose une mobilité des mouvements et également un choix large dans la composition et le
design de notre manette.
Le patient n’est pas retreint à jouer à une seule main, à utiliser beaucoup de force...Il y a moins de technique dans la manipulation et on ne joue pas avec une
manette adaptée uniquement pour un droitier ou un gaucher. Cependant, cela nous limitera peut-être dans le choix possible des types de jeux. Tout comme les autres
manettes adapté, l’utilisateur nécessitera un peu d’entrainement.

==Analyse du premier concurrent==

Jouer aux jeux vidéo à une main n’est pas une idée d’aujourd’hui. En 1990, Nintendo propose le Power Glove. Mais il tombe très rapidement aux oubliettes suite à des problèmes techniques.

Un autre gant a fait son apparition quelques années plus tard. Celui-ci, plus technique, il faut office de manette Play Station: le Reality Quest Power Glove.Cette idée de manette-gant, permet de jouer à la PS avec une seule main, elle a était conçue et présentée pour les E3, un salon d’exposition de gaming.Le gant est conçu pour contrôler l’équivalent des 14 boutons et 2 joysticks à l’aide d’une seule main. La « manette » est fixée dans la pomme de la main. L’utilisateur contrôle les mouvements verticaux et horizontaux en pivotant le poignet, et utilisent les 4 boutons d’action principaux et L1/R1 avec les doigts. Les autres boutons sont accessibles par un seul bouton rond contrôlé par le pouce.
La manette est adaptée pour beaucoup de jeux vidéo, dont les plus simples sont les jeux de voitures et de combats (arcade).

; Problèmes:
*Besoin de toute la motricité de la main, c’est-à-dire que si le patient à un doigt paralysé ou manquant, il ne pourra pas jouer avec ce gant
*Design obligatoirement droitier
*Les boutons de contrôle sont peu sensibles et peuvent nécessiter de la force
*Design compliqué et nécessitant beaucoup d’entrainement.

;Lien : https://www.youtube.com/watch?v=qV0SxSJDCYg

 
==Analyse du second concurrent==

Ben Heck, de son vrai nom Benjamin J.Heckendorn, est un concepteur de mods de consoles (mods pour modification, soit « manettes modifiées ») et une star
du net grâce à ses vidéos tutoriels.Il propose alors énormément de produits adaptés ou dérivés en guise de manettes.
Parmi les mods qu’il a réalisé, il a modifié une manette de PS4 afin de la rendre accessible à une personne ne pouvant jouer qu’à une main. Pour cela, il a déplacé les boutons en respectant l’ergonomie de la main valide et modifie les connexions. Il peut lui arriver de rajouter des boutons pour en remplacer un autre. Il réalise également le même système avec la Xbox. Sur la photo ci-dessous, il a adapté la manette pour un droitier.

; Problèmes:
*Besoin de toute la motricité de la main, c’est-à-dire que si le patient à un doigt paralysé ou manquant, il ne pourra pas jouer avec cette ma
*Design obligatoirement droitier ou gaucher, une modification = une manette= une personne
*Besoin obligé du pouce et de l’index, même si avantage : 3 doigts nécessaire.

;Lien :: https://www.youtube.com/watch?v=LieHIscadjk

==Scénario d'usage du produit ou du concept envisagé==

La technologie est ,aujourd’hui, omniprésente dans notre vie. Les consoles de jeux ont envahies les maisons avec plus de 7 personnes sur 10 jouant aux jeux vidéos sur consoles en France (chiffre de l’Express). 0,18% des français sont handicapés cela représente 12 millions de français. Dans ce chiffre, 13,4% des personnes ont un handicap moteur. En 2017, les grands groupes comme Sony ou Microsoft avec respectivement PlayStation et Xbox ne permettent pas à tout le monde de jouer avec une manette. Les manettes sont prévues pour des personnes ayant leurs membres valides, plus précisément les mains et les bras.

Après un accident de voiture, un jeune garçon a perdu la motricité d’un côté du corps. Passionné de jeux vidéo, il se retrouve avec des difficultés à jouer sur sa console PS4. Ingénieux, il utilise la manette en la coinçant entre son épaule et le creux du cou. Usant de la mâchoire et de sa main valide pour contrôler les joysticks et les boutons. L'exercice étant inconfortable et fatiguant il eu l’idée de proposer à des futurs ingénieurs de lui proposer une manette adaptée à son handicap.

Les deux pré-ingénieurs ,avec leur tuteur, ont une idée révolutionnaire : La manette modulable ! Elle permettrait au jeune garçon, ainsi que d’autres joueurs, de pouvoir continuer de s’amuser ou même de commencer à jouer au jeux sur console.
Cette manette aidera fortement dans les centre de rééducation pour faire passer le temps et donner du plaisir à des personnes qui ne peuvent plus s’amuser avec leur console traditionnelle. Elle pourra aussi ouvrir de nouvelles possibilités pour certaines personnes qui n’auraient jamais essayé jusqu'à présent.
Comme son nom l'indique, elle sera modulaire et s'adaptera à différents handicaps. Accompagnée de son application d’initialisation, elle sera accessible aussi bien aux enfants, patients, parents et aides soignantes.

Quelques mois plus tard...Le jeune patient fan de Need For Speed, peut maintenant piloter sa voiture comme un vrai professionnel grâce à l'un des joysticks qu'il utilisera avec sa main valide et il pourra accélérer à des vitesses folles à l'aide de boutons poussoirs au niveau de son pied valide et gagner la partie. Son ami venu lui rendre visite, pourra en lieu et place des aides soignantes configurer à l'aide de la tablette (portable) la manette du patient.
Si le patient change de jeu pour Tekken et que la configuration des modules ne lui convient plus, il peut interchanger les éléments de la manette selon son envie et son confort. Ainsi il peut faire sauter son personnage, il utilisera un module bouton supplémentaire, qu'il actionnera avec le poing.

==Fonctionnement==

Suite à une analyse fonctionnelle et à la formulation de notre projet, nous avons pu définir le fonctionnement de notre système. Notre produit, la manette, doit être accessible d’après nos objectifs à différents types de handicaps moteurs. Ainsi, l’idéal serait de concevoir une manette modulable afin qu’elle puisse s’adapter à toutes les situations. Ce n’est plus au patient de s’adapter à la manette mais à la manette de s’adapter au patient.
Cela signifie que la manette sera, dans la limite du possible et de la sensibilité du corps du patient, composée de plusieurs parties dites « modules » comportant un ou plusieurs actionneurs (boutons, joysticks, gâchettes...). Ces modules seront déplaçables afin d’être utilisé avec différents membres du corps : un doigt, une main,
une jambe ou même un pied. Il suffira de les connectés entre eux suivant l’organisation souhaitée, le Gameplay du jeu ou en fonction du handicap. Le tout sera relié à une application.
L’application sera alors mise en place pour connecter les différentes parties du point de vue software pour prérégler la manette en fonction du patient. Il pourra alors choisir les boutons en fonction du jeu, de ses mouvements mais aussi choisir la sensibilité.

L’application et les modules devront être intuitifs et faciles d’utilisation. De cette manière des utilisateurs non avertis dans le domaine informatique ou jeunes pourront eux-mêmes gérer les connexions.

==Réponse à la question difficile==

'''Question : Comment interconnecter les différents modules de la manette ?'''

Il nous faut pour ce projet interconnecter les modules modélisant la manette qui seront connectés à la consoles PS4 via une Raspberry Pi 3.
Le choix de la Raspberry Pi 3 nous permet d'utiliser son module Bluetooth pour communiquer avec la PS4, ce choix est plus adaptée au projet que du filaire.
Concernant l'interconnexion des modules, nous travaillerons en deux étapes "preuves concept" : filaire et sans fils (Bluetooth).

'''Objectif 1 : Preuve concept filaire'''

Dans cette première partie de projet, nous souhaitons avoir une 1ère preuve de prototype rapidement. Nous nous concentrerons alors sur la communication entre la RPi3 et la PS4 ainsi que sur la conception des modules. Pour les modules, nous réaliserons des cartes électronique pour chaque module avec un micro-contrôleur. La communication filaire nous permettra d'interconnecter les modules à la RPi3 avec un bus SPI.

'''Objectif 2: preuve concept sans fils'''

Une deuxième étape du projet est la réalisation de la solution idéale sans fils. Celle-ci pourra commencer à être développée petit à petit en parallèle avec l'objectif 1. Le but ici, est d'interconnecter les modules en Bluetooth. Nous avons choisi le Bluetooth pour garder une connexion commune sur toute la chaîne.
Nous rajouterons alors un module bluetooth à chaque module de la manette.

'''Objectif 3: possibilité d'adapter les boutons (capuchon en 3D)'''

=Préparation du projet=

==Cahier des charges==

''Chef de projet:'' Alexandre Boé 
''Responsables:'' Xavier Redon, Thomas Vantroys 
''Partenariat:'' Marc Sautelet (non etablie) 
''Elèves-ingénieurs:'' Camille Saâd, Transley Gracias 

'''Sujet :''' Manette modulable pour personne à déficience moteur compatible PlayStation 4 

===Objectifs principal (1er POC) : ===
Faire transmettre des informations issus des actionneurs (ex:boutons poussoires) via des arduinos jusqu’à la Raspberry Pi 3 en SPI. 
Envoyer les données reçues vers la PS4 en USB 

===Objectifs secondaire (2e POC):===
Créer des modules avec un microcontrôleur et une puce bluetooth pour permettre une meilleurs flexibilité (c-àd pouvoirs avoir une meilleure ergonomie et une connexion sans fil) 
Connecter la Raspberry Pi 3 en Bluetooth à la PS4 

[[Fichier: beteacorne.jpg||middle|600px|Bete a corne manette]]

==Choix techniques : matériel et logiciel==

===Liste de matériel :===

'''Modules boutons/joysticks/gachettes'''

3 Push buttons : 
- O X Y Carré R3 L3 
- Guide PS 
- start/back 
--> 0,45€/unité TTC [https://www.gotronic.fr/art-bp-miniature-krs1273-16976.htm] 

1 Thumbstick original: 
Joystick analogique 4 directions --> 4,25€/unité TTC [https://www.gotronic.fr/art-joystick-analogique-4-directions-19063.htm] 

1 buttons trigger L1 L2 => 1x Thumbstick original''' 

'''Cartes Atmega328p /connexion spi/'''

3 Arduino UNO 
1 Arduino UNO atmega328p retirable 
4 capacite 22pF traversantes 
2 resistances 10 kOhm traversantes (à récupérer) 
2 oscillateurs quartz 16MHz traversante 
2 atmega328p-pu et support 

'''Cartes module bluetooth nrf52810 '''

6 capacités 100nF 0603 
6 capacités 12pF 0603 
2 capacités 4,7pF 0603 
2 capacités 1µF 0603 
2 capacités 100pF=0,1nF 0603 (à récupérer) 
2 capacités 0,8pF 0603 (a acheter, commande en cours) 
2 inductance 3,9nH 0603 (a acheter, commande en cours) 
2 oscillateur quartz 32 MHz 

''' Connexions et autres '''

1 Led RGB neopixel [https://www.adafruit.com/product/1734] 
1 Raspberry Pi 3 
--> ~36,23€/unité TTC [https://fr.rs-online.com/web/p/processor-microcontroller-development-kits/8968660/?src=raspberrypi] 
1 Raspberry Pi Zero W (commandée) [https://www.raspberrypi.org/products/raspberry-pi-zero-w/] 
6 Alimentations 5V ou 3,3V 
par exemple, 12 piles de type CR2016 3V rechargeables ou 24 piles AAA 1,5 V rechargeables
5 modules Bluetooth nrf de Nordic : nRF52810-QFAA-R 
--> 3,17€/unité + frais expédition [https://www.mouser.fr/productdetail/nordic-semiconductor/nrf52810-qfaa-r?qs=sGAEpiMZZMve4%2FbfQkoj%252bG%2FosjLoe2oghFQwQllMrQ4%3D]
5 Lignes broches mâles 

===Logiciels:===

- IDE arduino
- Altium
- FreeCAD ou Inkscape

==Liste des tâches à effectuer==

'''Etape 1 : Gestion du projet'''

* Définition des cahiers des charges fonctionnel et technique, choix d'orientation...
* Recherche techniques sur les différentes connexions possibles entre les modules, la RPi 3 et la console PS4
#Recherche connexion SPI entre les modules et la RPi3
# Recherche connexion bluetooth entre la RPi3 et la PS4
# Recherche connexion bluetooth pour les modules
# Recherche carte avec montage Atmega328P-PU et anticipation module bluetooth
* Détermination du matériel nécessaire
* Réflexion sur l'application

'''Etape 2: Réalisation du projet'''

'''Partie 1: Preuve concept manette en filaire'''

* Conception de cartes électroniques pour 2 modules (/!\ prévoir modules bluetooth)
* Réalisation connexion SPI avec 2 modules : programmation des Atmega328p en liaison série.
* Si tests concluant, ajouter des modules jusqu'à en avoir 5 (1 pour chaque type de boutons)
* Connexion bluetooth entre la PS4 et la RPi3
* Réalisation du support des modules avec fixations possibles (imprimante 3D)

'''Partie 2: Preuve concept manette en bluetooth'''

* Ajout des modules bluetooth aux cartes électroniques
* Connexion bluetooth entre les modules

'''Partie 3: Application Android : paramétrage de la manette'''

* Créer une application sur tablette ou smartphone (Android) afin de configurer la manette aux besoins (inter-connexion des modules et console)

==Calendrier prévisionnel==

{| class="wikitable centre" width="80%"
|+
|-
| width="23%" |
'''Date'''
| width="34%" |
'''Tache à réaliser''' 
|-
| width="23%" |
17/01/18-24/01/18
| width="34%" |
Faire des recherches sur les différentes interconnexions du système : Bluetooth, RPi-Atmega328 (SPI), RPi-PS4
Continuer liste des taches, matériel, Début recherches + réflexion fixation support des modules
|-
|width="23%" |
31/01/18
| width="34%" |
Recherche technique connexion PS4-RPi3 et connexion SPI RPi3-Module + code
|-
|width="23%" |
31/01/18-07/03/18
| width="34%" |
Réalisation 1er prototype (+ début prototype 2)
|-
|width="23%" |
07/03/18
| width="34%" |
Seance 7 : Test prototype filaire
|-
|width="23%" |
07/03/18-09/05/18
| width="34%" |
Réalisation 2eme prototype + application Android
|-
|width="23%" |
09/05/18
| width="34%" |
Seance 14 : Test prototype Bluetooth
|-
|width="23%" |
14/05/18
| width="34%" |
Video projet
|-
|width="23%" |
15/05/18
| width="34%" |
Finalisation projet et Rapport
|-
|width="23%" |
16/05/18-17/05/18
| width="34%" |
Soutenances Projet
|}

=Réalisation du Projet=

==Feuille d'heures ==

Voici le tableau d'heures du binôme:

{| 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 S11 !! Heures S12 !! Heures S13et+ !! Total
|-
| Analyse du projet
| 10
| 2
| 1
| 1
| 1
|
|
|
|
|
|
|
| 20min
|
| 15h20
|-
| Cherches techniques
|
| 3
| 4
| 4
| 2
| 2
| 1
|
|
|
| 1
| 1
|
|
| 18
|-
| Rédaction du wiki et rapport de projet
|
| 1
| 1
| 1
| 1
| 30min
| 1
|
| 2
| 30min
| 30min
|
| 2
|
| 10h30
|-
| Programmation
|
|
|
|
| 3
| 2
| 3
| 5
| 4
| 7
| 8
| 6
| 5
|
| 43
|-
| Cartes électroniques
|
|
|
|
|
| 6
| 8
| 4
| 6
| 2
| 1
| 2
| 2
|
| 31
|-
| Application
|
|
|
|
|
|
|
|
|
|
|
|
|-
|-
| Total Semaine
| 10
| 6
| 6
| 6
| 7
| 10h30
| 13
| 9
| 12
| 9h30
| 10h30
| 9
| 9h20
|
| '''117h50'''
|}

==Prologue==

Avant la réalisation et conception d'un projet, il est important d'analyser celui-ci. Nous avons allons consacré le prologue à l'analyse fonctionnelle de la manette. Nous avons également eu une réflexion sur l'analyse technique, cela nous a permis de réaliser une liste de matériel. Il est important de définir les objectifs ainsi que les besoins afin de ne rien oublier. (Voir ci-dessus Analyse projet)
Nous avons également organisé notre travail, pour le partage de documents de recherches et la rédaction de compte-rendu final nous avons réalisé un google drive. Par la suite, nous créerons un projet Git.

Durant ce temps, nous avons décidé de réaliser 5 modules. Les modules sont les différents boutons de la manettes qui nous pourrons placer selon nos choix (boutons modulaires) pour notre prototype projet pour chaque type des boutons d'une manette PS4. Ces modules devrons être connectés à la console et interconnectés. Le tout sera lié à une application Android. Suite à quelques recherches et nos analyses, nous avons décidé les points suivants :

- On commencera avec 2 modules et on les multipliera par la suite.
- Les premiers tests sont réalisés avec des boutons petits pour assurer leur caractéristique "modulaires", par la suite nous pourrons ajouter des capuchons de taille plus importante (imprimante 3D ou achat)
- Conception modules : réalisation de carte avec un microcontrôleur atmega328 programmable pour chaque module (anticiper le module Bluetooth)
- Projet en 2 parties : prototype filaire et prototype Bluetooth
# Prototype filaire : connexions entre les modules et la RPi3 en SPI, connexion Rpi3-PS4 en Bluetooth, avec l'application en filaire à la RPi3
# Prototype Bluetooth: connexion Bluetooth entre modules-RPi3-PS4-apllication

[[Fichier: structuremanette.png||center|400px|Concept manette modulable]]

==Semaine 1==

Durant la séance, nous nous sommes concentrés les recherches afin de définir clairement le cahier des charges technique. Il s'agit des réalisations à mettre en œuvre pour les inter-connexions des éléments de la manette.
Ainsi, nous avons fait des recherches sur :

===Connexion SPI entre les modules (Atmega328p) et la RPi3===

SPI: Serial périphérique interface BUS

[[Fichier: yWGmW.png||right|200px|Concept manette modulable]]
Comme indiqué sur l'image ci-dessus, la Raspberry pi 3 peut communiquer en SPI avec ses broches CS0 (24), CS1 (26), SCLK (23), MISO (21), MOSI (19). Celles-ci permettent de communiquer avec un ou plusieurs esclaves (dans notre cas, des Atmega328p) en reliant directement les broches concernées de la RPi3 à celles des composants esclaves.
Chaque broche CS0 (24) ou CS1 (26) ne peut être connectée qu'à l'entrée SS (aussi appelé CS) d'un seul esclave.
C'est a dire que chaque CS est lié à un esclave afin de choisir avec lequel la communication est établie à un moment donné, et les MISO sont reliées entre elles en cascade, de même pour les SCLK et les MOSI. On peut noter que le maître impose la fréquence d’horloge et sélectionne l’esclave auquel les données sont envoyées. 8 MHz est le plus rapide supportable a 3,3V

[[Fichier: fonctionnementSPI.png||right|200px|Connexion SPI multi-esclaves]]

Voici un schéma du fonctionnement souhaité :

Comme nous souhaitons avoir 5 modules environ il nous faudra rajouter un composant en plus afin d'augmenter les possibilités de sélection, par exemple des démultiplexeurs.
Dans un premier temps nous essaierons avec 2 esclaves, puis on augmentera le nombre.

===Connexion Bluetooth PS4-RPi3===

Les recherches portent également sur la connexion entre la manette PS4 et la console. Elles concernent le protocole de communication via Bluetooth

Caracteristique pour la PS4: Bluetooth®v4.0, Qualcomm Atheros AR3002 Buetooth LE: 2,4-2,5 GHz 

Caracteristique de la connexion : 

*Vitesse de transmission >> 3 Mbit/s 8N1
*Relevé tous les 1.3 millisecond (peut-être)
*Chaque manette à une adresse unique BD_ADDR qui correspond à l’adresse MAC de la carte Réseau
*Protocole de détection est le SDP basé sur une emission reception PDU
*L’Attribut ID est representer en TLV Type Length Value
*Communication HCI ACL Data Packet

===Rélisation des cartes électroniques===

matériel nécessaire pour un PCB : 

*breadboard
*câbles
*1 x 10k Ohm résistance
*Quartz 16Mhz clock crystal
*2 x 22 pF capaciteurs
*Atmega328P-PU

Ressources:
[[https://www.arduino.cc/en/Main/Standalone]]
[[http://www.eprojectszone.com/atmega-328-pu-standalone/]]
[[https://www.arduino.cc/en/Tutorial/ArduinoToBreadboard]]

==Semaine 2==

Durant la semaine deux et durant la séance, nous avons continué et approfondie nos recherches sur le projet. Nous avons pu ainsi affiner nos taches de réalisation et donc notre cahier des charges.

===Connexion aux modules: SPI et Bluetooth ===

 CORRIGER

voir https://peip-ima.plil.fr/mediawiki/index.php/BE_2017-2018#Configuration_du_syst.C3.A8me_embarqu.C3.A9

(sudo apt-get install pi-bluetooth)

''connexion sur la raspberry par ssh:''
su
update-rc.d ssh enable
invoke-rc.d ssh start
ssh pi@172.26.79.1XX

''bluetooth''
bluetoothctl
agent on
default-agent
scan on
pair [device Bluetooth address] (exemple: pair XX:XX:XX:XX:XX:XX )

''NOUVELLE REFLEXION : Connexion SPI entre les modules (Atmega328p) et la RPi3 --> MODULES BLUETOOTH''

Si multi-esclaves= plusieurs modules :
Il faut ajouter des sélections pour les SPI → démultiplexeurs OU ne pas utiliser les CS0 et CS1, et plutôt des pins entrée/sortie de la RPi3 lié au SS comme ça on choisit direct le module esclave voulu.

'''IMPORTANT:''' Nous avons étudié à nouveau la datasheet de notre module bluetooth nrf de Nordik. Le module bluetooth comporte déjà un microprocesseur !
Un module plutôt peut donc jouer le rôle de notre atmega328p. Il n'y a alors pas besoin de réaliser des cartes électroniques de type arduino standalone. Nos PCB regrouperont alors uniquement l'alimentation, un actionneur (bouton, joystick), le module bluetooth et les broches de connexion si besoin...

Cette séance nous a alors permise de revoir entièrement le matériel nécessaire. Notre liste de matériel nous semble alors plus réfléchie et limitée au nécessaire.

===Connexion Bluetooth PS4-RPi3===

Suite à nos recherches de la semaine précédente, nous avons sélectionné deux sites bien renseignés :

SITES

Ils nous ont permis de comprendre la communication entre la manette et la console. En effet, ils nous expliquent les échanges de trames Bluetooth.
EXPLICATIONS 1 exemple 

==Semaine 3 : Début premier prototype==

===Connexion SPI RPi3-Arduino===

Comme vu durant les semaines précédentes, nous souhaitons réaliser une connexion Multi-esclaves en SPI entre la Raspberry pi et plusieurs modules.
Cette semaine nous avons vu que la réalisation de notre premier prototype doit aller vite. Il ne nous est pas nécessaire d’attendre les modules bluetooth si il nous faut dans cette partie uniquement utiliser son microprocesseur. Ainsi pour chaque module nous utilisons une arduino UNO. Nous réaliserons les programmes en C afin de pouvoir les réutiliser avec les modules bluetooth par la suite.
Une fois la connexion réalisable nous adapterons les programmes aux modules bluetooth Nordik. En effet, ceux-ci comporte déjà un microprocesseur, le module peut jouer le rôle de notre atmega328p. Il n'y a aurait alors pas besoin de réaliser des cartes électroniques arduino standalone sur PCB, mais directement des cartes électronique avec le module et le module voulu (bouton, joystick...) et l'alimentation.
Durant la séance nous avons alors revu la liste de matériel nécessaire.

[[Fichier: prototype1.jpeg||center|600px|connexion filaire prototype 1 filaire arduino]]

Durant la séance, nous avons recherches des exemples de codes et de librairies pour Arduino SPI et RaspberryPI SPI.

Nous avons également commencé le programme de la connexion SPI pour l'arduino et récupéré les bibliothéques SPI.h avec SPI.c. Nous nous sommes alors concentrer à les comprendre, pour pouvoir l'utiliser.

===Réalisation du projet Git===

Création du projet IMA4_Projet35_ManetteModulable sur Git et partage de celui-ci.
Les premiers dossier crées cette la séance :
-Arduino (connexion SPI arduino) : ProtoSpi.c + dossier librairie SPI + Makefile
-RPI (dossier codes pour Rpi)
-Readme.md
Ces dossiers seront amenés à être modifiés au cours des séances.

===Protocole Bluetooth PS4===

Suite à l'étude des trames Bluetooth, on a pu voir que ces dernières étaient incomplètes. Le modèle de communication étant propriétaire, on n'y a pas accès directement. Cela nous empêche donc de mettre en oeuvre cette communication.
 Déveloper

On a décidé de commencer par une connexion USB (pour laquelle on dispose de toutes les informations) celle-ci étant plus complète.

==Semaine 4==

Pour le prototype 1 FILAIRE nous réaliserons les étapes suivantes :

#Réalisation du programme SPI pour arduino
#Réalisation du programme SPI pour la RPi
#Connexion USB avec la PS4 ou ordinateur
#Réalisation de cartes électroniques atmega328p-pu standalone (remplacer les Arduinos)
#Remplacer les "PCB arduino" par le module bluetooth et adapter la connexion
#Conception 3D de la délimitation 1 axe pour le joystick "gâchette"
#Réalisation de l'application Androïde.

Une fois ces étapes réalisées nous auront alors une preuve de concept filaire et nous pourrons alors passer à une connexion bluetooth.
Le passage à la connexion bluetooth sera le deuxième prototype et le cas idéal de la réalisation de la manette modulable.

===Mise à jour Matériel===

- Modéliser les boutons gâchettes L1/2 R1/2 de la manette PS4 (boutons sensibles à la pression) --> un joystick dont nous bloquerons un axe (imprimante 3D)
- Remplacer la RPi 3 par une Rpi zero W qui nous permettrait de réaliser plus facilement une connexion USB tout en gardant l'avantage du bluetooth.
- Choix de l’alimentation pour les 5 modules Bluetooth: nécessitent 3V --> utiliser des piles rechargeables 1,2V AAA plutôt que piles rondes 3V.

Nous avons également besoin du matériel cité en semaine 1 pour réaliser des cartes électroniques atmega328p-pu standalone. ( nous revenons alors sur les décisions de la semaine 3)

===Connexion SPI RPi3-Arduino===

Montage Raspberrypi et 1 arduino en PSI + 1 bouton + 1 led.
Voici le choix des branchements :

MASTER = RPi
SLAVE= Arduino

'''SPI sur Arduino:'''
MOSI -> GPIO11 //PB3 //master OUT to the slave IN
MISO -> GPIO12 //PB4 //slave OUT to the master IN
SCLK -> GPIO13 //PB5 //serial clock
SS -> GPIO10 //PB2 //slave select
'''Led, bouton et autre...'''
LED --> GPIO6 //PD6
GND
+5V (if required)
'''SPI sur la Raspberry Pi'''
SPIO MOSI -> PIN19
SPIO MISO -> PIN21
SCLK -> PIN23
SPIO CS0 -> PIN24

Continuation du code pour faire clignoter Led branchée à une arduino depuis la Rpi, en connexion SPI.

===Connexion USB PS4-RPi3===
Durant cette, nous avons regardé comment faire cohabiter bluetooth, Application Androïd, USB, PS4, SPI et les module.

Il est alors important de savoir comment utiliser le port série sur la RPi3, soit utiliser les UART.

Nous avons réaliser qu'il n'était pas aussi simple d'utiliser le port serie USB de la Raspberry Pi 3, en effet le SoC est un BCM2837 .
De plus nous ne pouvons pas utiliser le même port pour l'alimentation et la connexion.

Il nous faut alors trouver une alternative ou une solution à ce problème.

==Semaine 5==

===Programmation: Réflexion définitives prototypes filaire ===

La semaine dernière, nous avons rencontré une difficulté liée aux ports séries UART.
Une des solutions à cette difficulté serait d'utiliser une RPi ZERO W à défaut d'une RPi 3. On pourrait alors avoir un port d'alimentation avec connexion USB mais également retrouver la connexion Bluetooth dont nous avons besoin.

Ensuite, nous avons continué la réalisation du prototype filaire par l'avancé du code SPI ainsi que les recherches concernant le protocole PS4.

La Raspberry Pi zero W peut également être utile pour la connexion entre la PS4 et les différents modules en jouant le rôle d'intermédiaire. Nous avons alors commandé une Rpi zero W pour notre projet.
En attendant la réception de la commande, nous nous sommes penché sur les recherches pour les programmes et la configuration nécessaire à l'utilisation de la RPi zero W.

===Electronique===

[[Fichier: bouton_c1.jpg|100px|thumb|left|PCB bouton]]
[[Fichier: arduinobb.jpg|200px|thumb|right|atmega328p-pu branchement test]]

Du coté électronique, nous avons réalisé sur fritzing certaines cartes électroniques. Les Arduino Uno servant actuellement de test, seront remplacées par des PCB atmega328p-pu standalone avec des broches permettant les branchements nécessaires SPI ou encore aux modules "boutons/joystick". Pour les boutons, nous avons également réalisé un pcb afin de faciliter les branchements.

Il nous faut alors également une 3eme carte qui nous sera nécessaire pour la réalisation du prototype sans fil. Dans notre liste de matériel, nous avons des composants nrf52810 bluetooth, ceci doivent être soudé avec les capacités de protection mais également des broches de communication. Nous avons alors commencé cette carte électronique sur Altium avec le fichier projet PCB du distributeur à modifier.

[[Fichier: Arduino_c1.jpg|100px|thumb|center|PCB atmega328p-pu]]

=== Construction 3D ===

Enfin, nous avons commencé à réaliser des boîtiers 3D pour certains modules. Par exemple, comme nous l'avions vu précédemment, un des joysticks servira de bouton-gâchette en utilisant un seul de ses axes. Il nous faut alors réaliser un boitier qui bloque l'un des axes, mais également une tige qui nous permettra de pousser le joystick de manière simplifiée.

==Semaine 6==

===Programmation: configuration RPi Zero W ===

Ayant reçu la Raspberry Pi zero W en début de semaine, nous nous sommes concentrés sur la programmation et la configuration de celle-ci.

===Electronique: PCB nrf52810===

Les cartes réalisées en semaine 5 sont validées et en attente de réalisation.

Cette semaine a permis la réalisation et la finalisation de la carte électronique nrf52810. Il nous a fallu recommencé cette carte deux fois. En effet, une fois finie sur Altium nous avons réalisé que les empreintes des CMS sur PCB fourni par le constructeur ne correspondent pas au matériel CMS de l'école. Face à cette inattention de notre part, nous avons décidé de refaire entièrement la carte électronique sur fritzing. Ayant la datasheet et des plans d'inspiration PCB, nous avons pu refaire la carte entièrement.
Sur celle-ci nous avons ajouté des broches de connexion au besoin, un branchement Jtag et ICSP pour la programmation et la connexion SPI.
La carte est en attente de validation, puis validation.

[[Fichier: nrf52810_circuit2.jpg||center|400px|PCB carte nrf52810]]

===Révision matériel ===

Pour la réalisation de nos composants électroniques, il nous a fallu faire une révision des composants disponibles à l'école:
(les quantités indiquées ci-dessous pourront être augmentée si nécessaire,pour avoir dans l'idéal un module de chaque type de la manette, ici on se concentre sur BOUTON et JOYSTICK)

'''Cartes Arduino:'''
* 4 capacite 22pF traversantes
* 2 resistances 10 kOhm traversantes (à récupérer)
* 2 oscillateurs quartz 16MHz traversante
* 2 atmega328p-pu et support

'''Cartes nrf52810'''
* 6 capacités 100nF 0603
* 6 capacités 12pF 0603
* 2 capacités 4,7pF 0603
* 2 capacités 1µF 0603
* 2 capacités 100pF=0,1nF 0603 (à récupérer)
* 2 capacités 0,8pF 0603 (commande en cours)
* 2 inductance 3,9nH 0603 (commande en cours)
* 2 oscillateur quartz 32 MHz

'''Cartes modules Boutons'''
* un sachet de broches mâles (qu'on utilisera également pour les autres cartes, à récupérer/acheté)

Nous avons alors mis-à-jour la liste de composant située plus haut, ainsi que celle de la page IMA4 2017/2018 [https://projets-ima.plil.fr/mediawiki/index.php/Projets_IMA4_SC_%26_SA_2017/2018]

==Semaine 7==

===Programmation: connexion wifi RPi Zero W et Bootloader sur Atmega328p-pu ===

Pendant cette semaine, nous avons continué la programmation et la configuration des Raspberry Pi 3 et Zero W afin de les utiliser en connexion Wifi.

Nous avons également continuer les programmes de récupération de données : état des boutons et du joystick. Ces programmes sont appliqué sur l'atmega328p-pu standalone sur la plaque d'essai en attendant que le PCB soit opérationnel.
Pour pouvoir programmer l'atemega328p-pu comme une arduino UNO, il nous faut suivre plusieurs étapes :

'''1.Flasher le Bootloader'''
Nous avons 2 Atmega328p-pu neufs, ainsi il nous faut flasher le bootloader sur chacun d'eux afin de pouvoir les utiliser et les programmer sur une breadboard dans un montage minimaliste arduino-standalone.
Pour cela, on peut utiliser une carte arduino UNO. On vérifie le port et le type de carte sélectionnés dans le menu >Outils. Sur cette carte on téléverse le fichier arduinoISP.ino qui se trouve dans les exemples en étant en progrmamateur AVr ISP mkll (>outils>programmateur)
Puis on met l'atmega328p-pu qui nous intéresse sur le suppor socket de la carte. On change de nouveau le programmateur pour Arduino as ISP et on fait >tools>burn bootloader, soit >graver la sequence d'initialisation.
Ces étapes faites, on peut retirer notre microcontroleur et le replacer correctement dans le montage.

'''2.Programmation atmega328 sur breadboard'''
Une fois l'atmega328p-pu préparé, on peut le programmer. On peut le faire simplement à l'aide de la carte arduino UNO utilisée précédemment.On branche les Tx et Rx en commun ainsi que le reset, le GND et le VCC.

Nous avons réaliser des codes basiques tels que le clignotement d'une led rouge ou encore l'affichage de "hello world" sur le moniteur série pour vérifier la bonne fonctionnalité du montage. Cela fait nous avons pu écrire sous Arduino IDE le code de lecture des états.

[[Fichier: montage_BB_test.jpg||left|200px|programmation modules arduino sur breadboard]]

===Electronique : soudure carte de test modules ===

Comme nous l'avons déja vu lors de la réalisation des PCB, si l'on souhaite programmer un atmega328p-pu en bootloader, le montage est simple. Il peut être minimaliste en utilisant une arduino UNO, un atmega328, une breadboard et 3 composants: 1 quartz 16MHZ crystal, 1 résistance 10kOhm et 2 capacitors céramiques de 22pF.
Durant la semaine 7, nous avons soudé les composants traversants de la carte électronique correspondant à ce montage ainsi que le PCB du bouton.

==Semaine 8==

===Programmation ===

===Electronique : Correction soudure et soudure CMS===

Durant cette semaine, nous avions souhaité programmer la carte électronique atmega328p-pu. Cependant, nous avons réaliser que nous avions fait une erreur lors de l'envoie du PCB à la production. En effet, celui-ci avait été fait en Top sur le logiciel Fritzing et non en Bottom. Hors nous avions soudé les composants (durant la semaine 7) comme pour un circuit imprimé en bottom, l'atmega328p-pu se retrouve alors inversé par rapport aux pistes.
Comme solution, nous avons choisi de souder un deuxième support pour l'atmega328 de l'autre coté de la carte avant de la refaire au propre. En effet, avant de la refaire il nous faut vérifier si la carte est bien programmable.
Une fois cela fait nous avions pu programmer la carte mais, nous avions également réalisé la pin 2 de l'atmega328 était prise par le bouton poussoir. Or, nous avons besoin des pin 2 et 3 pour le RX et TX permettant la programmation de l'atmega à partir d'une arduino, les pistes branchement RX-TX n'ont également pas été prévus pour le téléversement des programmes sur la carte. Il nous faut alors couper une piste et souder des câbles pour utiliser toutes les pistes souhaitées.

[[Fichier: correction_proto_PCB.jpg||right|300px|PCB arduino correction]]

Durant cette semaine, nous avons également souhaité souder les CMS et le composant bluetooth nrf52810 sur la carte imprimé et reçu lors de la semaine 7. Pour cela, nous avons convenu de travailler dans la C202 durant la séance du mercredi.

[[Fichier: PCB_nrf52810.jpg||left|400px|carte electroniques imprimées]]

====Comment souder des CMS ?====

les CMS sont des composants montés en surface c'est à dire qu'ils sont montés du même côté que les pistes cuivrées (à l'opposé des composants traversants) et sont de petite tailles souvent de l'ordre du millimètre. La taille est déterminée par 4 chiffres : les 2 premiers pour la longueur et les 2 derniers pour la largeur. On a du 1206,0805,0603 ou encore 0402. Il est même possible de trouver plus petit. A l'école nous utilisons souvent du 0603, c'est le cas de nos composants.
Pour souder des CMS 0603, il nous faut utiliser une autre méthode qui n'est pas le fer à souder :
# Préparer la veille la pâte à braser la veille (dans une seringue)
# Gommer la carte pour éviter l'oxydation (attention à ne pas retirer les miettes de gomme en soufflant dessus)
# Appliquer avec la seringue la pâte sur les empreintes et piste souhaitées. Pour les endroits difficile à atteindre ou avec 2 pistes proches les unes des autres, il est possible de mettre la même goutte de pâte sur les 2 pistes. Cela de causera pas de court-circuit par la suite. En effet, la pâte est composée d’alliage qui sous la chaleur va se fluidifier et se coller uniquement aux pistes métallique. Le reste fondera sous la chaleur du four.
# Appliquer les CMS sur la pâte au fur et à mesure (attention ! ne jamais toucher les CMS avec les doigts, tjrs utiliser une pince)
# Mettre au four

====Bilan soudure nrf52810====

Cependant, une fois le matériel nécessaire préparé, et la pâte mise sur les pistes souhaitées, au moment de déposer le composant, nous avons réalisé que celui-ci était beaucoup plus petit que l'empreinte sur le PCB. Il s'agit d'un composant boitier QFN48. Fritzing ne proposant au plus proche des boitiers QFN24 ou LQFP48, celui-ci a basculé automatiquement pour un boitier LQFN48, de dimension plus grande. Face à ce manque de vigilance, nous avions cependant commencer par le nrf52810 (composant concerné) évitant ainsi de gaspiller d'autres CMS.
Nous avons souhaité refaire la carte sous Altium à partir des fichiers fournis par le concepteur (chose que nous avons commencé à faire aux alentours de la semaine 5)
Après la réalisation du schématic, et de la modification des empreintes de capacités, inductances et autres composants de 0402 à 0603. Notre matériel ne permettant que des empreintes 0603.

Lors du routage, une erreur de chevauchement des pistes est notifiée par Altium au niveau du nrf52810. Celles-ci ne présentent pas d'angles et sont déjà de taille 8mil, il nous faut alors passer les pistes en 6mil. Mais 8mil est la taille minimale pour la production à Polytech, nous avons regardé pour envoyer les cartes à faire ailleurs mais le 6mil n'est pas beaucoup conseillé. De plus, il n'est peut-être pas judicieux de continuer avec le composant microcontrôleur-bluetooth Nrf52810 qui prend du temps, donc la carte est difficilement réalisable et peut-être très long à programmer.

Ainsi en cette fin de semaine, nous avons décider face à l'avancer du projet de laisser les nrf52810 de coté et de les remplacer par des modules sans fils plus simples d'utilisation et complets. Ainsi nous aurions plus de chance d'avoir une connexion sans fils entre les modules. Nous pourrions par exemples utiliser des Xbee, des modules Rf...

==Semaine 9==

====Programmation: PS4 et 1er Test SPI sur atmega328p====

'''Raspberry Pi Zero W et PS4'''

'''Modules Atmega328p et SPI'''

Une carte PCB arduino fonctionnant, nous pouvons la programme pour simuler un module. Celle-ci a été designée afin de s'adapter au module que l'on souhaite. Il suffit de brancher le bouton, le joystick ou autre élèment de manette souhaité.
Cette semaine ci, nous avons alors configurer la partie communication SPI pour l'arduino.

'''Que voulons-nous faire avec les atmegas ?'''
Les cartes électroniques atmega328p vont nous permettre de recevoir les requêtes SPI envoyées par la raspberry pi et d'y répondre. La Raspberry enverra un message, par exemple "1", et l'Arduino lira alors l'état du module qui lui est connecté. Une fois l'état récupéré elle le renvoie à la raspberry pi.

Durant cette semaine, nous avons programmé l'atmega afin qu'il soit en esclave, qu'il reçoive un de la RPi "1" et retourne une valeur sauvegardé "int envoi". Nous avons également commencé les tests pour la lecture de l'état d'un bouton (d'après les tests réalisés les semaines précédentes).

'''Code'''
Comme nous l'avons vu précedement lors de nos recherches (semaines 1 à 4) :
La communication SPI nécessite l'utilisation des pins:

MOSI -> GPIO11 //PB3 //master OUT to the slave IN
MISO -> GPIO12 //PB4 //slave OUT to the master IN
SCLK -> GPIO13 //PB5 //serial clock
SS -> GPIO10 //PB2 //slave select

Il faut également paramétrer l'atmega328p en Slave. On note que dans un premier temps, le programme sera codé avec l'arduino IDE (fichiers .ino). Une fois l'ensemble SPI RaspberryPi-Arduino fonctionnant, on remplacera ces codes par du langage C ou C++.

Pour faire la connexion SPI sur l'atmega328p, on utilise la librairie arduino SPI.h, on a alors directement les fonctions nécessaires intervenant sur les registres souhaités : SPCR (spi control register), SPSR (spi status register) et SPDR (spi data register).

#include <SPI.h>

Il est important d'initialise d'abord le setup et on active le port série pour pourvoir utiliser le moniteur série. (Cela servira à verifier la valeur envoyée par la RPi)

void setup (void)
{
Serial.begin (9600);
pinMode(MISO, OUTPUT); //configuration en esclave *master in slave out*
pinMode(buttonPin,INPUT); //config pin bouton
// turn on SPI in slave mode
SPCR |= _BV(SPE);
// preparation interruptions
pos = 0; // buffer empty
process_it = false;
// activation interruptions
SPI.attachInterrupt();
}

On oublie pas de déclarer les interruptions afin de bien lire la requête reçue.

// SPI interrupt routine
ISR (SPI_STC_vect)
{
byte c = SPDR; // grab byte from SPI Data Register
// add to buffer if room
if (pos < sizeof buf)
{
buf [pos++] = c;
// example: newline means time to process buffer
if (c == '\n')
process_it = true;
} // end of room available
} // end of interrupt routine SPI_STC_vect

Dans la loop main, on traite la requête et on utilise '''SPI.transfer(envoi);''' pour transferer à la RPi les données souhaitées.

Durant cette semaine, nous avons également commencé des programmes de test SPI pour la RPi. Il s'agit principalement de programmes de tests tout faits permettant de vérifier la connexion entre cette dernière et l'arduino. Par exemple, la RPI envoie "bonjour" et l'arduino lui retourne ce qu'elle reçoit, soit "bonjour". Sans succés alors.

====Electronique : Fritzing révision====

Lors de la semaine, le modèle PCB de la carte arduino a été réalisé de nouveau sous fritzing avec les broches et connections manquantes. Nous avons également revu la configuration du bouton reset et ajouté une led d'état de l'alimentation. Nous avons ainsi envoyé deux cartes identiques à la réalisation.
La carte déjà soudée lors des derniers jours fonctionnant, elle nous sert de prototype de programmation. Nous pouvons ainsi avancer à la fois sur la programmation des modules mais aussi sur leur réalisation.

==Semaine 10==

====Programmation : PS4 et SPI sur RPi====

'''Raspberry Pi Zero W et PS4'''

'''Modules Raspberry PI et SPI'''

Durant cette semaine, pour la partie Atmega328p-Modules, nous nous sommes concentrés sur la programmation de la communication SPI avec la raspberry pi. Cette semaine a permis une étude plus approfondit sur le fonctionnement pour la RPi.

On rappelle, comme vu des semaines 1 à 4, pour la RPI3 (tout comme la RPi Zero W) utilise les broches : SCLK (23), MISO(21), MOSI (19) et SPI CS0 (24), SPI CS1 (26).
On la programme en Master. A l'aide des fichiers tests d'inspiration, on pourra directement programmer la RPi en C. Lors de la réalisation du code, il y a 3 étapes : l'initialisation/parametrage en SPI pour être maître, l'envoie de la requête puis la réception de données en retour.

Programmant en C, il ne faut pas oublier les librairies suivantes :

#include <stdint.h>
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
#include <getopt.h>
#include <fcntl.h>
#include <sys/ioctl.h>
#include <linux/types.h>
#include <linux/spi/spidev.h> //pour SPI

On va déclarer des variables globales permettant le paramétrage :

static const char *device = "/dev/spidev0.0"; //si on veut CS0 pour atteindre notre SS
static uint8_t mode; //mode est par défaut à 0
static uint8_t bits = 8; //bits par mot échangé
static uint32_t speed = 500000;
static uint16_t delay;

Dans notre main, on ouvre le port (la connexion) au device souhaité, on vérifie les paramètres (registres, connexions...) puis exécute la fonction transfer(fd). transfer(fd) transmet la requête et s'occupe de la réception.

fd = open(device, O_RDWR);
transfer(fd);
close(fd);

==Semaine 11==

====Programmation: PS4, SSH et tests SPI (RPi3&Atemga328p)====

'''Raspberry Pi Zero W et PS4'''

'''Raspberry PI, Atmega328p et SPI'''

Afin de facilité la programmation en utilisant Ethernet, nous avons installer et configuré la RPi pour l'utiliser en SSH depuis les ordinateurs de la E306. En effet, SSH permet de se connecter à distance sur une machine en utilisant un compte utilisateur de la dite machine. En mettant ssh, on pourra directement agir sur les fichiers de la raspberry depuis un terminal de notre PC. Pour cela, on a d'abord vérifier l'adresse IP de notre raspberry pi : 172.26.145.106 avec un écran mais on peut aussi utiliser les commandes ip a et ifconfig. Puis activer le ssh sur la raspberry pi.
On modifie alors le fichier config.txt mais également etc/network/interfaces pour configurer la bonne interface Ethernet sur la raspberry pi.

[[Fichier: configSSH_raspi.png||left|300px|config ssh ethernet]]

Il nous suffit alors de taper la commande : ssh pi@172.26.145.106 pour accéder à notre RPi.

Nous avons continué à réaliser la communication SPI avec des tests entre une arduino UNO et la RPI3. Nous avons commencé par des tests simples inspirés des études de deux semaines précédentes et modulés selon notre utilité.
Nous arrivons alors à lire l'état envoyer "bonjour" et recevoir "ça va" ou encore "1" et recevoir "3". Il faut noter que le SPI échange des trames, la RPI reçoit alors des hexadécimaux.
Nous avons alors continué pour recevoir l'état du bouton ou du joystick lors de l'envoie de "1" sur l'Arduino328p. La semaine prochaine nous testerons ces même codes fonctionnels sur les cartes atmeg327p.

A la fin de cette semaine, nous avons alors des codes Arduino-SPI (.ino) et des codes Raspberry-SPI (.c) permettant l'échange de données. Le but est maintenant de l'adapter aux cartes imprimées et de le rendre pleinement fonctionnel pour plusieurs cartes à la fois, puis ajouter une boucle de vérification en continue jusqu'à une deuxième requête de la RPi.

====Electronique: réalisation au propres des PCB modules====

Suite à une nouvelle erreur de réalisation cartes électronique, nous avons refait et renvoyé à nouveau les cartes imprimées atmega328p.
Nous les souhaitons au propre pour une version finale. Une fois celle-ci imprimées nous pourrons en avoir 3 , un pour chaque module. Les cartes étaient bien imprimées en bottom mais lors du passage des traversants de bottom à top, le logiciel ne les a pas fait miroiter. Par manque d'attention nous avons alors envoyé les fichiers gerber pour des cartes ayant les composants du même coté que la couche de cuivre.
Les cartes électroniques actuelles sont alors correctes et fonctionnelles mais difficile à souder. Pour eviter les erreurs et continuer sur des prototypes de carte nous préférons attendre en nous concentrant sur la programmation PSI de la Raspberry Pi.

==Semaine 12==

====Programmation====

'''Raspberry Pi Zero W et PS4'''

'''Raspberry PI, Atmega328p et SPI'''

- réflexion: penser à faire boucler sur l'arduino une fois la requête reçu, ça veut dire que la manette est ON et donc vérifier continuellement les modules sur chaque atmega.
- SPI raspberry pi - arduino recuperation état du bouton avec les cartes modules (/!\ récuperation à faire dans une variable)

-SSH perso
adresse Rasppi: 192.168.137.10

====Electronique: Finalisation soudure Modules====

Soudure au propre et finale d'une carte atmega328p et donc envoie pour la réalisation de 2 autres cartes similaires et récupération de matériel
Soudure des 2 autres cartes, + tests sur les états = fonctionnelles.
On a donc bien 3 cartes pour les 3 modules de types différents (1 bouton, 1 joystick, 1 gachette)
PCB pour les 2 joysticks (qui serviront de thumbstick et gachette)

==Semaine 13 et plus==

====Programmation====

'''Raspberry Pi Zero W et PS4'''

'''Modules Atmega328p et SPI'''

====Electronique====

=Documents Rendus=

(à mettre rapport + git + drive)

=Datasheets=

IMA4 2017/2018 P35

2018-05-05T18:45:41Z

Tgracias : /* Semaine 5 */

__TOC__
 

=Présentation générale: Manette modulable=

==Description==

Tout le monde joue aux jeux vidéo cependant, les manettes ne sont pas adaptées aux personnes ayant un handicap pouvant toucher les bras ou les mains.
C’est le cas, de plusieurs patients dans les centres de soins et de rééducation.

Pour ce projet IMA4, nous travaillerons avec le centre SSR (soin de suite et de réadaptation) Marc Sautelet de Villeneuve d’Ascq.
Un adolescent, patient de Marc Sautelet, est passionné par les jeux vidéo. En effet, ayant perdu la motricité d’une partie de son corps, il ne peut pas jouer à deux mains. Pour cela, il bloque la manette entre son épaule et son coude, usant de la mâchoire et des doigts pour contrôler les
joysticks et les boutons. Cet exercice peut s’avérer fatiguant et pénible.

Ainsi, nous chercherons à concevoir une manette PS4 adaptée au handicap de l’adolescent.
Cette manette devra aussi être adaptée pour d’autres patients présentant également des handicaps moteurs. Ainsi nous prendrons pour cibles: tous les patients du centre voulant jouer; et non pas que les enfants et adolescents.

 

{| class="wikitable centre" width="80%"
|+
|-
| width="23%" |
Membre du projet
| width="34%" |
Transley Gracias et Camille Saad
|-
| width="23%" |
Cible
| width="34%" |
Patient présentant un handicap moteur
|-
|width="23%" |
Période du projet
| width="34%" |
janvier 2018 - mai 2018
|-
|width="23%" |
Partenaire/Client
| width="34%" |
Centre SSR Marc Sautelet à Villeneuve d'Ascq
|}

==Objectifs==

Ce projet a pour objectif de créer un prototype de manette qui puisse interagir avec la console PS4 et dont le paramétrage se fait à l’aide d’une application mobile et/ou web. Cette manette devra suivre les demandes du patient ainsi que des aides-soignantes du centre, dans la mesure du possible.

Plus précisément, pour le premier prototype, nous mettrons en œuvre l'utilisation de quelques boutons spécifiques:

* Un joystick (type L/R)
* Quelques boutons poussoirs (type Croix/Triangle/Carré/Rond/R1/L1/Start/...)
* Des boutons gâchettes progressives (type L2/R2).

Le but serait donc dans un premier temps de rendre fonctionnel un bouton de chaque type, puis de les multiplier une fois cela fait. Tous ces boutons réunis constituent une manette fonctionnelle.Ainsi, la manette sera ajustable, c’est à dire qu’elle devra s’adapter aux différents handicaps moteurs possibles.

=Analyse du projet=

==Positionnement par rapport à l'existant==

Notre prototype aura une présentation unique par rapport à l’existant. En effet, les concurrents et produits existants ciblent pour la majorité un seul handicap. Cela
engendre une solution fermée à beaucoup de patients. Notre projet propose une mobilité des mouvements et également un choix large dans la composition et le
design de notre manette.
Le patient n’est pas retreint à jouer à une seule main, à utiliser beaucoup de force...Il y a moins de technique dans la manipulation et on ne joue pas avec une
manette adaptée uniquement pour un droitier ou un gaucher. Cependant, cela nous limitera peut-être dans le choix possible des types de jeux. Tout comme les autres
manettes adapté, l’utilisateur nécessitera un peu d’entrainement.

==Analyse du premier concurrent==

Jouer aux jeux vidéo à une main n’est pas une idée d’aujourd’hui. En 1990, Nintendo propose le Power Glove. Mais il tombe très rapidement aux oubliettes suite à des problèmes techniques.

Un autre gant a fait son apparition quelques années plus tard. Celui-ci, plus technique, il faut office de manette Play Station: le Reality Quest Power Glove.Cette idée de manette-gant, permet de jouer à la PS avec une seule main, elle a était conçue et présentée pour les E3, un salon d’exposition de gaming.Le gant est conçu pour contrôler l’équivalent des 14 boutons et 2 joysticks à l’aide d’une seule main. La « manette » est fixée dans la pomme de la main. L’utilisateur contrôle les mouvements verticaux et horizontaux en pivotant le poignet, et utilisent les 4 boutons d’action principaux et L1/R1 avec les doigts. Les autres boutons sont accessibles par un seul bouton rond contrôlé par le pouce.
La manette est adaptée pour beaucoup de jeux vidéo, dont les plus simples sont les jeux de voitures et de combats (arcade).

; Problèmes:
*Besoin de toute la motricité de la main, c’est-à-dire que si le patient à un doigt paralysé ou manquant, il ne pourra pas jouer avec ce gant
*Design obligatoirement droitier
*Les boutons de contrôle sont peu sensibles et peuvent nécessiter de la force
*Design compliqué et nécessitant beaucoup d’entrainement.

;Lien : https://www.youtube.com/watch?v=qV0SxSJDCYg

 
==Analyse du second concurrent==

Ben Heck, de son vrai nom Benjamin J.Heckendorn, est un concepteur de mods de consoles (mods pour modification, soit « manettes modifiées ») et une star
du net grâce à ses vidéos tutoriels.Il propose alors énormément de produits adaptés ou dérivés en guise de manettes.
Parmi les mods qu’il a réalisé, il a modifié une manette de PS4 afin de la rendre accessible à une personne ne pouvant jouer qu’à une main. Pour cela, il a déplacé les boutons en respectant l’ergonomie de la main valide et modifie les connexions. Il peut lui arriver de rajouter des boutons pour en remplacer un autre. Il réalise également le même système avec la Xbox. Sur la photo ci-dessous, il a adapté la manette pour un droitier.

; Problèmes:
*Besoin de toute la motricité de la main, c’est-à-dire que si le patient à un doigt paralysé ou manquant, il ne pourra pas jouer avec cette ma
*Design obligatoirement droitier ou gaucher, une modification = une manette= une personne
*Besoin obligé du pouce et de l’index, même si avantage : 3 doigts nécessaire.

;Lien :: https://www.youtube.com/watch?v=LieHIscadjk

==Scénario d'usage du produit ou du concept envisagé==

La technologie est ,aujourd’hui, omniprésente dans notre vie. Les consoles de jeux ont envahies les maisons avec plus de 7 personnes sur 10 jouant aux jeux vidéos sur consoles en France (chiffre de l’Express). 0,18% des français sont handicapés cela représente 12 millions de français. Dans ce chiffre, 13,4% des personnes ont un handicap moteur. En 2017, les grands groupes comme Sony ou Microsoft avec respectivement PlayStation et Xbox ne permettent pas à tout le monde de jouer avec une manette. Les manettes sont prévues pour des personnes ayant leurs membres valides, plus précisément les mains et les bras.

Après un accident de voiture, un jeune garçon a perdu la motricité d’un côté du corps. Passionné de jeux vidéo, il se retrouve avec des difficultés à jouer sur sa console PS4. Ingénieux, il utilise la manette en la coinçant entre son épaule et le creux du cou. Usant de la mâchoire et de sa main valide pour contrôler les joysticks et les boutons. L'exercice étant inconfortable et fatiguant il eu l’idée de proposer à des futurs ingénieurs de lui proposer une manette adaptée à son handicap.

Les deux pré-ingénieurs ,avec leur tuteur, ont une idée révolutionnaire : La manette modulable ! Elle permettrait au jeune garçon, ainsi que d’autres joueurs, de pouvoir continuer de s’amuser ou même de commencer à jouer au jeux sur console.
Cette manette aidera fortement dans les centre de rééducation pour faire passer le temps et donner du plaisir à des personnes qui ne peuvent plus s’amuser avec leur console traditionnelle. Elle pourra aussi ouvrir de nouvelles possibilités pour certaines personnes qui n’auraient jamais essayé jusqu'à présent.
Comme son nom l'indique, elle sera modulaire et s'adaptera à différents handicaps. Accompagnée de son application d’initialisation, elle sera accessible aussi bien aux enfants, patients, parents et aides soignantes.

Quelques mois plus tard...Le jeune patient fan de Need For Speed, peut maintenant piloter sa voiture comme un vrai professionnel grâce à l'un des joysticks qu'il utilisera avec sa main valide et il pourra accélérer à des vitesses folles à l'aide de boutons poussoirs au niveau de son pied valide et gagner la partie. Son ami venu lui rendre visite, pourra en lieu et place des aides soignantes configurer à l'aide de la tablette (portable) la manette du patient.
Si le patient change de jeu pour Tekken et que la configuration des modules ne lui convient plus, il peut interchanger les éléments de la manette selon son envie et son confort. Ainsi il peut faire sauter son personnage, il utilisera un module bouton supplémentaire, qu'il actionnera avec le poing.

==Fonctionnement==

Suite à une analyse fonctionnelle et à la formulation de notre projet, nous avons pu définir le fonctionnement de notre système. Notre produit, la manette, doit être accessible d’après nos objectifs à différents types de handicaps moteurs. Ainsi, l’idéal serait de concevoir une manette modulable afin qu’elle puisse s’adapter à toutes les situations. Ce n’est plus au patient de s’adapter à la manette mais à la manette de s’adapter au patient.
Cela signifie que la manette sera, dans la limite du possible et de la sensibilité du corps du patient, composée de plusieurs parties dites « modules » comportant un ou plusieurs actionneurs (boutons, joysticks, gâchettes...). Ces modules seront déplaçables afin d’être utilisé avec différents membres du corps : un doigt, une main,
une jambe ou même un pied. Il suffira de les connectés entre eux suivant l’organisation souhaitée, le Gameplay du jeu ou en fonction du handicap. Le tout sera relié à une application.
L’application sera alors mise en place pour connecter les différentes parties du point de vue software pour prérégler la manette en fonction du patient. Il pourra alors choisir les boutons en fonction du jeu, de ses mouvements mais aussi choisir la sensibilité.

L’application et les modules devront être intuitifs et faciles d’utilisation. De cette manière des utilisateurs non avertis dans le domaine informatique ou jeunes pourront eux-mêmes gérer les connexions.

==Réponse à la question difficile==

'''Question : Comment interconnecter les différents modules de la manette ?'''

Il nous faut pour ce projet interconnecter les modules modélisant la manette qui seront connectés à la consoles PS4 via une Raspberry Pi 3.
Le choix de la Raspberry Pi 3 nous permet d'utiliser son module Bluetooth pour communiquer avec la PS4, ce choix est plus adaptée au projet que du filaire.
Concernant l'interconnexion des modules, nous travaillerons en deux étapes "preuves concept" : filaire et sans fils (Bluetooth).

'''Objectif 1 : Preuve concept filaire'''

Dans cette première partie de projet, nous souhaitons avoir une 1ère preuve de prototype rapidement. Nous nous concentrerons alors sur la communication entre la RPi3 et la PS4 ainsi que sur la conception des modules. Pour les modules, nous réaliserons des cartes électronique pour chaque module avec un micro-contrôleur. La communication filaire nous permettra d'interconnecter les modules à la RPi3 avec un bus SPI.

'''Objectif 2: preuve concept sans fils'''

Une deuxième étape du projet est la réalisation de la solution idéale sans fils. Celle-ci pourra commencer à être développée petit à petit en parallèle avec l'objectif 1. Le but ici, est d'interconnecter les modules en Bluetooth. Nous avons choisi le Bluetooth pour garder une connexion commune sur toute la chaîne.
Nous rajouterons alors un module bluetooth à chaque module de la manette.

'''Objectif 3: possibilité d'adapter les boutons (capuchon en 3D)'''

=Préparation du projet=

==Cahier des charges==

''Chef de projet:'' Alexandre Boé 
''Responsables:'' Xavier Redon, Thomas Vantroys 
''Partenariat:'' Marc Sautelet (non etablie) 
''Elèves-ingénieurs:'' Camille Saâd, Transley Gracias 

'''Sujet :''' Manette modulable pour personne à déficience moteur compatible PlayStation 4 

===Objectifs principal (1er POC) : ===
Faire transmettre des informations issus des actionneurs (ex:boutons poussoires) via des arduinos jusqu’à la Raspberry Pi 3 en SPI. 
Envoyer les données reçues vers la PS4 en USB 

===Objectifs secondaire (2e POC):===
Créer des modules avec un microcontrôleur et une puce bluetooth pour permettre une meilleurs flexibilité (c-àd pouvoirs avoir une meilleure ergonomie et une connexion sans fil) 
Connecter la Raspberry Pi 3 en Bluetooth à la PS4 

[[Fichier: beteacorne.jpg||middle|600px|Bete a corne manette]]

==Choix techniques : matériel et logiciel==

===Liste de matériel :===

'''Modules boutons/joysticks/gachettes'''

3 Push buttons : 
- O X Y Carré R3 L3 
- Guide PS 
- start/back 
--> 0,45€/unité TTC [https://www.gotronic.fr/art-bp-miniature-krs1273-16976.htm] 

1 Thumbstick original: 
Joystick analogique 4 directions --> 4,25€/unité TTC [https://www.gotronic.fr/art-joystick-analogique-4-directions-19063.htm] 

1 buttons trigger L1 L2 => 1x Thumbstick original''' 

'''Cartes Atmega328p /connexion spi/'''

3 Arduino UNO 
1 Arduino UNO atmega328p retirable 
4 capacite 22pF traversantes 
2 resistances 10 kOhm traversantes (à récupérer) 
2 oscillateurs quartz 16MHz traversante 
2 atmega328p-pu et support 

'''Cartes module bluetooth nrf52810 '''

6 capacités 100nF 0603 
6 capacités 12pF 0603 
2 capacités 4,7pF 0603 
2 capacités 1µF 0603 
2 capacités 100pF=0,1nF 0603 (à récupérer) 
2 capacités 0,8pF 0603 (a acheter, commande en cours) 
2 inductance 3,9nH 0603 (a acheter, commande en cours) 
2 oscillateur quartz 32 MHz 

''' Connexions et autres '''

1 Led RGB neopixel [https://www.adafruit.com/product/1734] 
1 Raspberry Pi 3 
--> ~36,23€/unité TTC [https://fr.rs-online.com/web/p/processor-microcontroller-development-kits/8968660/?src=raspberrypi] 
1 Raspberry Pi Zero W (commandée) [https://www.raspberrypi.org/products/raspberry-pi-zero-w/] 
6 Alimentations 5V ou 3,3V 
par exemple, 12 piles de type CR2016 3V rechargeables ou 24 piles AAA 1,5 V rechargeables
5 modules Bluetooth nrf de Nordic : nRF52810-QFAA-R 
--> 3,17€/unité + frais expédition [https://www.mouser.fr/productdetail/nordic-semiconductor/nrf52810-qfaa-r?qs=sGAEpiMZZMve4%2FbfQkoj%252bG%2FosjLoe2oghFQwQllMrQ4%3D]
5 Lignes broches mâles 

===Logiciels:===

- IDE arduino
- Altium
- FreeCAD ou Inkscape

==Liste des tâches à effectuer==

'''Etape 1 : Gestion du projet'''

* Définition des cahiers des charges fonctionnel et technique, choix d'orientation...
* Recherche techniques sur les différentes connexions possibles entre les modules, la RPi 3 et la console PS4
#Recherche connexion SPI entre les modules et la RPi3
# Recherche connexion bluetooth entre la RPi3 et la PS4
# Recherche connexion bluetooth pour les modules
# Recherche carte avec montage Atmega328P-PU et anticipation module bluetooth
* Détermination du matériel nécessaire
* Réflexion sur l'application

'''Etape 2: Réalisation du projet'''

'''Partie 1: Preuve concept manette en filaire'''

* Conception de cartes électroniques pour 2 modules (/!\ prévoir modules bluetooth)
* Réalisation connexion SPI avec 2 modules : programmation des Atmega328p en liaison série.
* Si tests concluant, ajouter des modules jusqu'à en avoir 5 (1 pour chaque type de boutons)
* Connexion bluetooth entre la PS4 et la RPi3
* Réalisation du support des modules avec fixations possibles (imprimante 3D)

'''Partie 2: Preuve concept manette en bluetooth'''

* Ajout des modules bluetooth aux cartes électroniques
* Connexion bluetooth entre les modules

'''Partie 3: Application Android : paramétrage de la manette'''

* Créer une application sur tablette ou smartphone (Android) afin de configurer la manette aux besoins (inter-connexion des modules et console)

==Calendrier prévisionnel==

{| class="wikitable centre" width="80%"
|+
|-
| width="23%" |
'''Date'''
| width="34%" |
'''Tache à réaliser''' 
|-
| width="23%" |
17/01/18-24/01/18
| width="34%" |
Faire des recherches sur les différentes interconnexions du système : Bluetooth, RPi-Atmega328 (SPI), RPi-PS4
Continuer liste des taches, matériel, Début recherches + réflexion fixation support des modules
|-
|width="23%" |
31/01/18
| width="34%" |
Recherche technique connexion PS4-RPi3 et connexion SPI RPi3-Module + code
|-
|width="23%" |
31/01/18-07/03/18
| width="34%" |
Réalisation 1er prototype (+ début prototype 2)
|-
|width="23%" |
07/03/18
| width="34%" |
Seance 7 : Test prototype filaire
|-
|width="23%" |
07/03/18-09/05/18
| width="34%" |
Réalisation 2eme prototype + application Android
|-
|width="23%" |
09/05/18
| width="34%" |
Seance 14 : Test prototype Bluetooth
|-
|width="23%" |
14/05/18
| width="34%" |
Video projet
|-
|width="23%" |
15/05/18
| width="34%" |
Finalisation projet et Rapport
|-
|width="23%" |
16/05/18-17/05/18
| width="34%" |
Soutenances Projet
|}

=Réalisation du Projet=

==Feuille d'heures ==

Voici le tableau d'heures du binôme:

{| 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 S11 !! Heures S12 !! Heures S13et+ !! Total
|-
| Analyse du projet
| 10
| 2
| 1
| 1
| 1
|
|
|
|
|
|
|
| 20min
|
| 15h20
|-
| Cherches techniques
|
| 3
| 4
| 4
| 2
| 2
| 1
|
|
|
| 1
| 1
|
|
| 18
|-
| Rédaction du wiki et rapport de projet
|
| 1
| 1
| 1
| 1
| 30min
| 1
|
| 2
| 30min
| 30min
|
| 2
|
| 10h30
|-
| Programmation
|
|
|
|
| 3
| 2
| 3
| 5
| 4
| 7
| 8
| 6
| 5
|
| 43
|-
| Cartes électroniques
|
|
|
|
|
| 6
| 8
| 4
| 6
| 2
| 1
| 2
| 2
|
| 31
|-
| Application
|
|
|
|
|
|
|
|
|
|
|
|
|-
|-
| Total Semaine
| 10
| 6
| 6
| 6
| 7
| 10h30
| 13
| 9
| 12
| 9h30
| 10h30
| 9
| 9h20
|
| '''117h50'''
|}

==Prologue==

Avant la réalisation et conception d'un projet, il est important d'analyser celui-ci. Nous avons allons consacré le prologue à l'analyse fonctionnelle de la manette. Nous avons également eu une réflexion sur l'analyse technique, cela nous a permis de réaliser une liste de matériel. Il est important de définir les objectifs ainsi que les besoins afin de ne rien oublier. (Voir ci-dessus Analyse projet)
Nous avons également organisé notre travail, pour le partage de documents de recherches et la rédaction de compte-rendu final nous avons réalisé un google drive. Par la suite, nous créerons un projet Git.

Durant ce temps, nous avons décidé de réaliser 5 modules. Les modules sont les différents boutons de la manettes qui nous pourrons placer selon nos choix (boutons modulaires) pour notre prototype projet pour chaque type des boutons d'une manette PS4. Ces modules devrons être connectés à la console et interconnectés. Le tout sera lié à une application Android. Suite à quelques recherches et nos analyses, nous avons décidé les points suivants :

- On commencera avec 2 modules et on les multipliera par la suite.
- Les premiers tests sont réalisés avec des boutons petits pour assurer leur caractéristique "modulaires", par la suite nous pourrons ajouter des capuchons de taille plus importante (imprimante 3D ou achat)
- Conception modules : réalisation de carte avec un microcontrôleur atmega328 programmable pour chaque module (anticiper le module Bluetooth)
- Projet en 2 parties : prototype filaire et prototype Bluetooth
# Prototype filaire : connexions entre les modules et la RPi3 en SPI, connexion Rpi3-PS4 en Bluetooth, avec l'application en filaire à la RPi3
# Prototype Bluetooth: connexion Bluetooth entre modules-RPi3-PS4-apllication

[[Fichier: structuremanette.png||center|400px|Concept manette modulable]]

==Semaine 1==

Durant la séance, nous nous sommes concentrés les recherches afin de définir clairement le cahier des charges technique. Il s'agit des réalisations à mettre en œuvre pour les inter-connexions des éléments de la manette.
Ainsi, nous avons fait des recherches sur :

===Connexion SPI entre les modules (Atmega328p) et la RPi3===

SPI: Serial périphérique interface BUS

[[Fichier: yWGmW.png||right|200px|Concept manette modulable]]
Comme indiqué sur l'image ci-dessus, la Raspberry pi 3 peut communiquer en SPI avec ses broches CS0 (24), CS1 (26), SCLK (23), MISO (21), MOSI (19). Celles-ci permettent de communiquer avec un ou plusieurs esclaves (dans notre cas, des Atmega328p) en reliant directement les broches concernées de la RPi3 à celles des composants esclaves.
Chaque broche CS0 (24) ou CS1 (26) ne peut être connectée qu'à l'entrée SS (aussi appelé CS) d'un seul esclave.
C'est a dire que chaque CS est lié à un esclave afin de choisir avec lequel la communication est établie à un moment donné, et les MISO sont reliées entre elles en cascade, de même pour les SCLK et les MOSI. On peut noter que le maître impose la fréquence d’horloge et sélectionne l’esclave auquel les données sont envoyées. 8 MHz est le plus rapide supportable a 3,3V

[[Fichier: fonctionnementSPI.png||right|200px|Connexion SPI multi-esclaves]]

Voici un schéma du fonctionnement souhaité :

Comme nous souhaitons avoir 5 modules environ il nous faudra rajouter un composant en plus afin d'augmenter les possibilités de sélection, par exemple des démultiplexeurs.
Dans un premier temps nous essaierons avec 2 esclaves, puis on augmentera le nombre.

===Connexion Bluetooth PS4-RPi3===

Les recherches portent également sur la connexion entre la manette PS4 et la console. Elles concernent le protocole de communication via Bluetooth

Caracteristique pour la PS4: Bluetooth®v4.0, Qualcomm Atheros AR3002 Buetooth LE: 2,4-2,5 GHz 

Caracteristique de la connexion : 

*Vitesse de transmission >> 3 Mbit/s 8N1
*Relevé tous les 1.3 millisecond (peut-être)
*Chaque manette à une adresse unique BD_ADDR qui correspond à l’adresse MAC de la carte Réseau
*Protocole de détection est le SDP basé sur une emission reception PDU
*L’Attribut ID est representer en TLV Type Length Value
*Communication HCI ACL Data Packet

===Rélisation des cartes électroniques===

matériel nécessaire pour un PCB : 

*breadboard
*câbles
*1 x 10k Ohm résistance
*Quartz 16Mhz clock crystal
*2 x 22 pF capaciteurs
*Atmega328P-PU

Ressources:
[[https://www.arduino.cc/en/Main/Standalone]]
[[http://www.eprojectszone.com/atmega-328-pu-standalone/]]
[[https://www.arduino.cc/en/Tutorial/ArduinoToBreadboard]]

==Semaine 2==

Durant la semaine deux et durant la séance, nous avons continué et approfondie nos recherches sur le projet. Nous avons pu ainsi affiner nos taches de réalisation et donc notre cahier des charges.

===Connexion aux modules: SPI et Bluetooth ===

 CORRIGER

voir https://peip-ima.plil.fr/mediawiki/index.php/BE_2017-2018#Configuration_du_syst.C3.A8me_embarqu.C3.A9

(sudo apt-get install pi-bluetooth)

''connexion sur la raspberry par ssh:''
su
update-rc.d ssh enable
invoke-rc.d ssh start
ssh pi@172.26.79.1XX

''bluetooth''
bluetoothctl
agent on
default-agent
scan on
pair [device Bluetooth address] (exemple: pair XX:XX:XX:XX:XX:XX )

''NOUVELLE REFLEXION : Connexion SPI entre les modules (Atmega328p) et la RPi3 --> MODULES BLUETOOTH''

Si multi-esclaves= plusieurs modules :
Il faut ajouter des sélections pour les SPI → démultiplexeurs OU ne pas utiliser les CS0 et CS1, et plutôt des pins entrée/sortie de la RPi3 lié au SS comme ça on choisit direct le module esclave voulu.

'''IMPORTANT:''' Nous avons étudié à nouveau la datasheet de notre module bluetooth nrf de Nordik. Le module bluetooth comporte déjà un microprocesseur !
Un module plutôt peut donc jouer le rôle de notre atmega328p. Il n'y a alors pas besoin de réaliser des cartes électroniques de type arduino standalone. Nos PCB regrouperont alors uniquement l'alimentation, un actionneur (bouton, joystick), le module bluetooth et les broches de connexion si besoin...

Cette séance nous a alors permise de revoir entièrement le matériel nécessaire. Notre liste de matériel nous semble alors plus réfléchie et limitée au nécessaire.

===Connexion Bluetooth PS4-RPi3===

Suite à nos recherches de la semaine précédente, nous avons sélectionné deux sites bien renseignés :

SITES

Ils nous ont permis de comprendre la communication entre la manette et la console. En effet, ils nous expliquent les échanges de trames Bluetooth.
EXPLICATIONS 1 exemple 

==Semaine 3 : Début premier prototype==

===Connexion SPI RPi3-Arduino===

Comme vu durant les semaines précédentes, nous souhaitons réaliser une connexion Multi-esclaves en SPI entre la Raspberry pi et plusieurs modules.
Cette semaine nous avons vu que la réalisation de notre premier prototype doit aller vite. Il ne nous est pas nécessaire d’attendre les modules bluetooth si il nous faut dans cette partie uniquement utiliser son microprocesseur. Ainsi pour chaque module nous utilisons une arduino UNO. Nous réaliserons les programmes en C afin de pouvoir les réutiliser avec les modules bluetooth par la suite.
Une fois la connexion réalisable nous adapterons les programmes aux modules bluetooth Nordik. En effet, ceux-ci comporte déjà un microprocesseur, le module peut jouer le rôle de notre atmega328p. Il n'y a aurait alors pas besoin de réaliser des cartes électroniques arduino standalone sur PCB, mais directement des cartes électronique avec le module et le module voulu (bouton, joystick...) et l'alimentation.
Durant la séance nous avons alors revu la liste de matériel nécessaire.

[[Fichier: prototype1.jpeg||center|600px|connexion filaire prototype 1 filaire arduino]]

Durant la séance, nous avons recherches des exemples de codes et de librairies pour Arduino SPI et RaspberryPI SPI.

Nous avons également commencé le programme de la connexion SPI pour l'arduino et récupéré les bibliothéques SPI.h avec SPI.c. Nous nous sommes alors concentrer à les comprendre, pour pouvoir l'utiliser.

===Réalisation du projet Git===

Création du projet IMA4_Projet35_ManetteModulable sur Git et partage de celui-ci.
Les premiers dossier crées cette la séance :
-Arduino (connexion SPI arduino) : ProtoSpi.c + dossier librairie SPI + Makefile
-RPI (dossier codes pour Rpi)
-Readme.md
Ces dossiers seront amenés à être modifiés au cours des séances.

===Protocole Bluetooth PS4===

Suite à l'étude des trames Bluetooth, on a pu voir que ces dernières étaient incomplètes. Le modèle de communication étant propriétaire, on n'y a pas accès directement. Cela nous empêche donc de mettre en oeuvre cette communication.
 Déveloper

On a décidé de commencer par une connexion USB (pour laquelle on dispose de toutes les informations) celle-ci étant plus complète.

==Semaine 4==

Pour le prototype 1 FILAIRE nous réaliserons les étapes suivantes :

#Réalisation du programme SPI pour arduino
#Réalisation du programme SPI pour la RPi
#Connexion USB avec la PS4 ou ordinateur
#Réalisation de cartes électroniques atmega328p-pu standalone (remplacer les Arduinos)
#Remplacer les "PCB arduino" par le module bluetooth et adapter la connexion
#Conception 3D de la délimitation 1 axe pour le joystick "gâchette"
#Réalisation de l'application Androïde.

Une fois ces étapes réalisées nous auront alors une preuve de concept filaire et nous pourrons alors passer à une connexion bluetooth.
Le passage à la connexion bluetooth sera le deuxième prototype et le cas idéal de la réalisation de la manette modulable.

===Mise à jour Matériel===

- Modéliser les boutons gâchettes L1/2 R1/2 de la manette PS4 (boutons sensibles à la pression) --> un joystick dont nous bloquerons un axe (imprimante 3D)
- Remplacer la RPi 3 par une Rpi zero W qui nous permettrait de réaliser plus facilement une connexion USB tout en gardant l'avantage du bluetooth.
- Choix de l’alimentation pour les 5 modules Bluetooth: nécessitent 3V --> utiliser des piles rechargeables 1,2V AAA plutôt que piles rondes 3V.

Nous avons également besoin du matériel cité en semaine 1 pour réaliser des cartes électroniques atmega328p-pu standalone. ( nous revenons alors sur les décisions de la semaine 3)

===Connexion SPI RPi3-Arduino===

Montage Raspberrypi et 1 arduino en PSI + 1 bouton + 1 led.
Voici le choix des branchements :

MASTER = RPi
SLAVE= Arduino

'''SPI sur Arduino:'''
MOSI -> GPIO11 //PB3 //master OUT to the slave IN
MISO -> GPIO12 //PB4 //slave OUT to the master IN
SCLK -> GPIO13 //PB5 //serial clock
SS -> GPIO10 //PB2 //slave select
'''Led, bouton et autre...'''
LED --> GPIO6 //PD6
GND
+5V (if required)
'''SPI sur la Raspberry Pi'''
SPIO MOSI -> PIN19
SPIO MISO -> PIN21
SCLK -> PIN23
SPIO CS0 -> PIN24

Continuation du code pour faire clignoter Led branchée à une arduino depuis la Rpi, en connexion SPI.

===Connexion USB PS4-RPi3===
Durant cette, nous avons regardé comment faire cohabiter bluetooth, Application Androïd, USB, PS4, SPI et les module.

Il est alors important de savoir comment utiliser le port série sur la RPi3, soit utiliser les UART.

Nous avons réaliser qu'il n'était pas aussi simple d'utiliser le port serie USB de la Raspberry Pi 3, en effet le SoC est un BCM2837 .
De plus nous ne pouvons pas utiliser le même port pour l'alimentation et la connexion.

Il nous faut alors trouver une alternative ou une solution à ce problème.

==Semaine 5==

===Programmation: Réflexion définitives prototypes filaire ===

La semaine dernière, nous avons rencontré une difficulté liée aux ports séries UART.
Une des solutions à cette difficulté serait d'utiliser une RPi ZERO W à défaut d'une RPi 3. On pourrait alors avoir un port d'alimentation avec connexion USB mais également retrouver la connexion Bluetooth dont nous avons besoin.

Ensuite, nous avons continué la réalisation du prototype filaire par l'avancé du code SPI ainsi que les recherches concernant le protocole PS4.

La Raspberry Pi zero W peut également être utile pour la connexion entre la PS4 et les différents modules en jouant le rôle d'intermédiaire. Nous avons alors commandé une Rpi zero W pour notre projet.
Cela nous permet d'utiliser le bluetooth mais également de réaliser un réseau local sans fil. Ce qui peut être pratique dans la mesure où notre projet est modulable.
En attendant la réception de la commande, nous nous sommes penché sur les recherches pour les programmes et la configuration nécessaire à l'utilisation de la RPi zero W.

===Electronique===

[[Fichier: bouton_c1.jpg|100px|thumb|left|PCB bouton]]
[[Fichier: arduinobb.jpg|200px|thumb|right|atmega328p-pu branchement test]]

Du coté électronique, nous avons réalisé sur fritzing certaines cartes électroniques. Les Arduino Uno servant actuellement de test, seront remplacées par des PCB atmega328p-pu standalone avec des broches permettant les branchements nécessaires SPI ou encore aux modules "boutons/joystick". Pour les boutons, nous avons également réalisé un pcb afin de faciliter les branchements.

Il nous faut alors également une 3eme carte qui nous sera nécessaire pour la réalisation du prototype sans fil. Dans notre liste de matériel, nous avons des composants nrf52810 bluetooth, ceci doivent être soudé avec les capacités de protection mais également des broches de communication. Nous avons alors commencé cette carte électronique sur Altium avec le fichier projet PCB du distributeur à modifier.

[[Fichier: Arduino_c1.jpg|100px|thumb|center|PCB atmega328p-pu]]

=== Construction 3D ===

Enfin, nous avons commencé à réaliser des boîtiers 3D pour certains modules. Par exemple, comme nous l'avions vu précédemment, un des joysticks servira de bouton-gâchette en utilisant un seul de ses axes. Il nous faut alors réaliser un boitier qui bloque l'un des axes, mais également une tige qui nous permettra de pousser le joystick de manière simplifiée.

==Semaine 6==

===Programmation: configuration RPi Zero W ===

Ayant reçu la Raspberry Pi zero W en début de semaine, nous nous sommes concentrés sur la programmation et la configuration de celle-ci.

===Electronique: PCB nrf52810===

Les cartes réalisées en semaine 5 sont validées et en attente de réalisation.

Cette semaine a permis la réalisation et la finalisation de la carte électronique nrf52810. Il nous a fallu recommencé cette carte deux fois. En effet, une fois finie sur Altium nous avons réalisé que les empreintes des CMS sur PCB fourni par le constructeur ne correspondent pas au matériel CMS de l'école. Face à cette inattention de notre part, nous avons décidé de refaire entièrement la carte électronique sur fritzing. Ayant la datasheet et des plans d'inspiration PCB, nous avons pu refaire la carte entièrement.
Sur celle-ci nous avons ajouté des broches de connexion au besoin, un branchement Jtag et ICSP pour la programmation et la connexion SPI.
La carte est en attente de validation, puis validation.

[[Fichier: nrf52810_circuit2.jpg||center|400px|PCB carte nrf52810]]

===Révision matériel ===

Pour la réalisation de nos composants électroniques, il nous a fallu faire une révision des composants disponibles à l'école:
(les quantités indiquées ci-dessous pourront être augmentée si nécessaire,pour avoir dans l'idéal un module de chaque type de la manette, ici on se concentre sur BOUTON et JOYSTICK)

'''Cartes Arduino:'''
* 4 capacite 22pF traversantes
* 2 resistances 10 kOhm traversantes (à récupérer)
* 2 oscillateurs quartz 16MHz traversante
* 2 atmega328p-pu et support

'''Cartes nrf52810'''
* 6 capacités 100nF 0603
* 6 capacités 12pF 0603
* 2 capacités 4,7pF 0603
* 2 capacités 1µF 0603
* 2 capacités 100pF=0,1nF 0603 (à récupérer)
* 2 capacités 0,8pF 0603 (commande en cours)
* 2 inductance 3,9nH 0603 (commande en cours)
* 2 oscillateur quartz 32 MHz

'''Cartes modules Boutons'''
* un sachet de broches mâles (qu'on utilisera également pour les autres cartes, à récupérer/acheté)

Nous avons alors mis-à-jour la liste de composant située plus haut, ainsi que celle de la page IMA4 2017/2018 [https://projets-ima.plil.fr/mediawiki/index.php/Projets_IMA4_SC_%26_SA_2017/2018]

==Semaine 7==

===Programmation: connexion wifi RPi Zero W et Bootloader sur Atmega328p-pu ===

Pendant cette semaine, nous avons continué la programmation et la configuration des Raspberry Pi 3 et Zero W afin de les utiliser en connexion Wifi.

Nous avons également continuer les programmes de récupération de données : état des boutons et du joystick. Ces programmes sont appliqué sur l'atmega328p-pu standalone sur la plaque d'essai en attendant que le PCB soit opérationnel.
Pour pouvoir programmer l'atemega328p-pu comme une arduino UNO, il nous faut suivre plusieurs étapes :

'''1.Flasher le Bootloader'''
Nous avons 2 Atmega328p-pu neufs, ainsi il nous faut flasher le bootloader sur chacun d'eux afin de pouvoir les utiliser et les programmer sur une breadboard dans un montage minimaliste arduino-standalone.
Pour cela, on peut utiliser une carte arduino UNO. On vérifie le port et le type de carte sélectionnés dans le menu >Outils. Sur cette carte on téléverse le fichier arduinoISP.ino qui se trouve dans les exemples en étant en progrmamateur AVr ISP mkll (>outils>programmateur)
Puis on met l'atmega328p-pu qui nous intéresse sur le suppor socket de la carte. On change de nouveau le programmateur pour Arduino as ISP et on fait >tools>burn bootloader, soit >graver la sequence d'initialisation.
Ces étapes faites, on peut retirer notre microcontroleur et le replacer correctement dans le montage.

'''2.Programmation atmega328 sur breadboard'''
Une fois l'atmega328p-pu préparé, on peut le programmer. On peut le faire simplement à l'aide de la carte arduino UNO utilisée précédemment.On branche les Tx et Rx en commun ainsi que le reset, le GND et le VCC.

Nous avons réaliser des codes basiques tels que le clignotement d'une led rouge ou encore l'affichage de "hello world" sur le moniteur série pour vérifier la bonne fonctionnalité du montage. Cela fait nous avons pu écrire sous Arduino IDE le code de lecture des états.

[[Fichier: montage_BB_test.jpg||left|200px|programmation modules arduino sur breadboard]]

===Electronique : soudure carte de test modules ===

Comme nous l'avons déja vu lors de la réalisation des PCB, si l'on souhaite programmer un atmega328p-pu en bootloader, le montage est simple. Il peut être minimaliste en utilisant une arduino UNO, un atmega328, une breadboard et 3 composants: 1 quartz 16MHZ crystal, 1 résistance 10kOhm et 2 capacitors céramiques de 22pF.
Durant la semaine 7, nous avons soudé les composants traversants de la carte électronique correspondant à ce montage ainsi que le PCB du bouton.

==Semaine 8==

===Programmation ===

===Electronique : Correction soudure et soudure CMS===

Durant cette semaine, nous avions souhaité programmer la carte électronique atmega328p-pu. Cependant, nous avons réaliser que nous avions fait une erreur lors de l'envoie du PCB à la production. En effet, celui-ci avait été fait en Top sur le logiciel Fritzing et non en Bottom. Hors nous avions soudé les composants (durant la semaine 7) comme pour un circuit imprimé en bottom, l'atmega328p-pu se retrouve alors inversé par rapport aux pistes.
Comme solution, nous avons choisi de souder un deuxième support pour l'atmega328 de l'autre coté de la carte avant de la refaire au propre. En effet, avant de la refaire il nous faut vérifier si la carte est bien programmable.
Une fois cela fait nous avions pu programmer la carte mais, nous avions également réalisé la pin 2 de l'atmega328 était prise par le bouton poussoir. Or, nous avons besoin des pin 2 et 3 pour le RX et TX permettant la programmation de l'atmega à partir d'une arduino, les pistes branchement RX-TX n'ont également pas été prévus pour le téléversement des programmes sur la carte. Il nous faut alors couper une piste et souder des câbles pour utiliser toutes les pistes souhaitées.

[[Fichier: correction_proto_PCB.jpg||right|300px|PCB arduino correction]]

Durant cette semaine, nous avons également souhaité souder les CMS et le composant bluetooth nrf52810 sur la carte imprimé et reçu lors de la semaine 7. Pour cela, nous avons convenu de travailler dans la C202 durant la séance du mercredi.

[[Fichier: PCB_nrf52810.jpg||left|400px|carte electroniques imprimées]]

====Comment souder des CMS ?====

les CMS sont des composants montés en surface c'est à dire qu'ils sont montés du même côté que les pistes cuivrées (à l'opposé des composants traversants) et sont de petite tailles souvent de l'ordre du millimètre. La taille est déterminée par 4 chiffres : les 2 premiers pour la longueur et les 2 derniers pour la largeur. On a du 1206,0805,0603 ou encore 0402. Il est même possible de trouver plus petit. A l'école nous utilisons souvent du 0603, c'est le cas de nos composants.
Pour souder des CMS 0603, il nous faut utiliser une autre méthode qui n'est pas le fer à souder :
# Préparer la veille la pâte à braser la veille (dans une seringue)
# Gommer la carte pour éviter l'oxydation (attention à ne pas retirer les miettes de gomme en soufflant dessus)
# Appliquer avec la seringue la pâte sur les empreintes et piste souhaitées. Pour les endroits difficile à atteindre ou avec 2 pistes proches les unes des autres, il est possible de mettre la même goutte de pâte sur les 2 pistes. Cela de causera pas de court-circuit par la suite. En effet, la pâte est composée d’alliage qui sous la chaleur va se fluidifier et se coller uniquement aux pistes métallique. Le reste fondera sous la chaleur du four.
# Appliquer les CMS sur la pâte au fur et à mesure (attention ! ne jamais toucher les CMS avec les doigts, tjrs utiliser une pince)
# Mettre au four

====Bilan soudure nrf52810====

Cependant, une fois le matériel nécessaire préparé, et la pâte mise sur les pistes souhaitées, au moment de déposer le composant, nous avons réalisé que celui-ci était beaucoup plus petit que l'empreinte sur le PCB. Il s'agit d'un composant boitier QFN48. Fritzing ne proposant au plus proche des boitiers QFN24 ou LQFP48, celui-ci a basculé automatiquement pour un boitier LQFN48, de dimension plus grande. Face à ce manque de vigilance, nous avions cependant commencer par le nrf52810 (composant concerné) évitant ainsi de gaspiller d'autres CMS.
Nous avons souhaité refaire la carte sous Altium à partir des fichiers fournis par le concepteur (chose que nous avons commencé à faire aux alentours de la semaine 5)
Après la réalisation du schématic, et de la modification des empreintes de capacités, inductances et autres composants de 0402 à 0603. Notre matériel ne permettant que des empreintes 0603.

Lors du routage, une erreur de chevauchement des pistes est notifiée par Altium au niveau du nrf52810. Celles-ci ne présentent pas d'angles et sont déjà de taille 8mil, il nous faut alors passer les pistes en 6mil. Mais 8mil est la taille minimale pour la production à Polytech, nous avons regardé pour envoyer les cartes à faire ailleurs mais le 6mil n'est pas beaucoup conseillé. De plus, il n'est peut-être pas judicieux de continuer avec le composant microcontrôleur-bluetooth Nrf52810 qui prend du temps, donc la carte est difficilement réalisable et peut-être très long à programmer.

Ainsi en cette fin de semaine, nous avons décider face à l'avancer du projet de laisser les nrf52810 de coté et de les remplacer par des modules sans fils plus simples d'utilisation et complets. Ainsi nous aurions plus de chance d'avoir une connexion sans fils entre les modules. Nous pourrions par exemples utiliser des Xbee, des modules Rf...

==Semaine 9==

====Programmation: PS4 et 1er Test SPI sur atmega328p====

'''Raspberry Pi Zero W et PS4'''

'''Modules Atmega328p et SPI'''

Une carte PCB arduino fonctionnant, nous pouvons la programme pour simuler un module. Celle-ci a été designée afin de s'adapter au module que l'on souhaite. Il suffit de brancher le bouton, le joystick ou autre élèment de manette souhaité.
Cette semaine ci, nous avons alors configurer la partie communication SPI pour l'arduino.

'''Que voulons-nous faire avec les atmegas ?'''
Les cartes électroniques atmega328p vont nous permettre de recevoir les requêtes SPI envoyées par la raspberry pi et d'y répondre. La Raspberry enverra un message, par exemple "1", et l'Arduino lira alors l'état du module qui lui est connecté. Une fois l'état récupéré elle le renvoie à la raspberry pi.

Durant cette semaine, nous avons programmé l'atmega afin qu'il soit en esclave, qu'il reçoive un de la RPi "1" et retourne une valeur sauvegardé "int envoi". Nous avons également commencé les tests pour la lecture de l'état d'un bouton (d'après les tests réalisés les semaines précédentes).

'''Code'''
Comme nous l'avons vu précedement lors de nos recherches (semaines 1 à 4) :
La communication SPI nécessite l'utilisation des pins:

MOSI -> GPIO11 //PB3 //master OUT to the slave IN
MISO -> GPIO12 //PB4 //slave OUT to the master IN
SCLK -> GPIO13 //PB5 //serial clock
SS -> GPIO10 //PB2 //slave select

Il faut également paramétrer l'atmega328p en Slave. On note que dans un premier temps, le programme sera codé avec l'arduino IDE (fichiers .ino). Une fois l'ensemble SPI RaspberryPi-Arduino fonctionnant, on remplacera ces codes par du langage C ou C++.

Pour faire la connexion SPI sur l'atmega328p, on utilise la librairie arduino SPI.h, on a alors directement les fonctions nécessaires intervenant sur les registres souhaités : SPCR (spi control register), SPSR (spi status register) et SPDR (spi data register).

#include <SPI.h>

Il est important d'initialise d'abord le setup et on active le port série pour pourvoir utiliser le moniteur série. (Cela servira à verifier la valeur envoyée par la RPi)

void setup (void)
{
Serial.begin (9600);
pinMode(MISO, OUTPUT); //configuration en esclave *master in slave out*
pinMode(buttonPin,INPUT); //config pin bouton
// turn on SPI in slave mode
SPCR |= _BV(SPE);
// preparation interruptions
pos = 0; // buffer empty
process_it = false;
// activation interruptions
SPI.attachInterrupt();
}

On oublie pas de déclarer les interruptions afin de bien lire la requête reçue.

// SPI interrupt routine
ISR (SPI_STC_vect)
{
byte c = SPDR; // grab byte from SPI Data Register
// add to buffer if room
if (pos < sizeof buf)
{
buf [pos++] = c;
// example: newline means time to process buffer
if (c == '\n')
process_it = true;
} // end of room available
} // end of interrupt routine SPI_STC_vect

Dans la loop main, on traite la requête et on utilise '''SPI.transfer(envoi);''' pour transferer à la RPi les données souhaitées.

Durant cette semaine, nous avons également commencé des programmes de test SPI pour la RPi. Il s'agit principalement de programmes de tests tout faits permettant de vérifier la connexion entre cette dernière et l'arduino. Par exemple, la RPI envoie "bonjour" et l'arduino lui retourne ce qu'elle reçoit, soit "bonjour". Sans succés alors.

====Electronique : Fritzing révision====

Lors de la semaine, le modèle PCB de la carte arduino a été réalisé de nouveau sous fritzing avec les broches et connections manquantes. Nous avons également revu la configuration du bouton reset et ajouté une led d'état de l'alimentation. Nous avons ainsi envoyé deux cartes identiques à la réalisation.
La carte déjà soudée lors des derniers jours fonctionnant, elle nous sert de prototype de programmation. Nous pouvons ainsi avancer à la fois sur la programmation des modules mais aussi sur leur réalisation.

==Semaine 10==

====Programmation : PS4 et SPI sur RPi====

'''Raspberry Pi Zero W et PS4'''

'''Modules Raspberry PI et SPI'''

Durant cette semaine, pour la partie Atmega328p-Modules, nous nous sommes concentrés sur la programmation de la communication SPI avec la raspberry pi. Cette semaine a permis une étude plus approfondit sur le fonctionnement pour la RPi.

On rappelle, comme vu des semaines 1 à 4, pour la RPI3 (tout comme la RPi Zero W) utilise les broches : SCLK (23), MISO(21), MOSI (19) et SPI CS0 (24), SPI CS1 (26).
On la programme en Master. A l'aide des fichiers tests d'inspiration, on pourra directement programmer la RPi en C. Lors de la réalisation du code, il y a 3 étapes : l'initialisation/parametrage en SPI pour être maître, l'envoie de la requête puis la réception de données en retour.

Programmant en C, il ne faut pas oublier les librairies suivantes :

#include <stdint.h>
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
#include <getopt.h>
#include <fcntl.h>
#include <sys/ioctl.h>
#include <linux/types.h>
#include <linux/spi/spidev.h> //pour SPI

On va déclarer des variables globales permettant le paramétrage :

static const char *device = "/dev/spidev0.0"; //si on veut CS0 pour atteindre notre SS
static uint8_t mode; //mode est par défaut à 0
static uint8_t bits = 8; //bits par mot échangé
static uint32_t speed = 500000;
static uint16_t delay;

Dans notre main, on ouvre le port (la connexion) au device souhaité, on vérifie les paramètres (registres, connexions...) puis exécute la fonction transfer(fd). transfer(fd) transmet la requête et s'occupe de la réception.

fd = open(device, O_RDWR);
transfer(fd);
close(fd);

==Semaine 11==

====Programmation: PS4, SSH et tests SPI (RPi3&Atemga328p)====

'''Raspberry Pi Zero W et PS4'''

'''Raspberry PI, Atmega328p et SPI'''

Afin de facilité la programmation en utilisant Ethernet, nous avons installer et configuré la RPi pour l'utiliser en SSH depuis les ordinateurs de la E306. En effet, SSH permet de se connecter à distance sur une machine en utilisant un compte utilisateur de la dite machine. En mettant ssh, on pourra directement agir sur les fichiers de la raspberry depuis un terminal de notre PC. Pour cela, on a d'abord vérifier l'adresse IP de notre raspberry pi : 172.26.145.106 avec un écran mais on peut aussi utiliser les commandes ip a et ifconfig. Puis activer le ssh sur la raspberry pi.
On modifie alors le fichier config.txt mais également etc/network/interfaces pour configurer la bonne interface Ethernet sur la raspberry pi.

[[Fichier: configSSH_raspi.png||left|300px|config ssh ethernet]]

Il nous suffit alors de taper la commande : ssh pi@172.26.145.106 pour accéder à notre RPi.

Nous avons continué à réaliser la communication SPI avec des tests entre une arduino UNO et la RPI3. Nous avons commencé par des tests simples inspirés des études de deux semaines précédentes et modulés selon notre utilité.
Nous arrivons alors à lire l'état envoyer "bonjour" et recevoir "ça va" ou encore "1" et recevoir "3". Il faut noter que le SPI échange des trames, la RPI reçoit alors des hexadécimaux.
Nous avons alors continué pour recevoir l'état du bouton ou du joystick lors de l'envoie de "1" sur l'Arduino328p. La semaine prochaine nous testerons ces même codes fonctionnels sur les cartes atmeg327p.

A la fin de cette semaine, nous avons alors des codes Arduino-SPI (.ino) et des codes Raspberry-SPI (.c) permettant l'échange de données. Le but est maintenant de l'adapter aux cartes imprimées et de le rendre pleinement fonctionnel pour plusieurs cartes à la fois, puis ajouter une boucle de vérification en continue jusqu'à une deuxième requête de la RPi.

====Electronique: réalisation au propres des PCB modules====

Suite à une nouvelle erreur de réalisation cartes électronique, nous avons refait et renvoyé à nouveau les cartes imprimées atmega328p.
Nous les souhaitons au propre pour une version finale. Une fois celle-ci imprimées nous pourrons en avoir 3 , un pour chaque module. Les cartes étaient bien imprimées en bottom mais lors du passage des traversants de bottom à top, le logiciel ne les a pas fait miroiter. Par manque d'attention nous avons alors envoyé les fichiers gerber pour des cartes ayant les composants du même coté que la couche de cuivre.
Les cartes électroniques actuelles sont alors correctes et fonctionnelles mais difficile à souder. Pour eviter les erreurs et continuer sur des prototypes de carte nous préférons attendre en nous concentrant sur la programmation PSI de la Raspberry Pi.

==Semaine 12==

====Programmation====

'''Raspberry Pi Zero W et PS4'''

'''Raspberry PI, Atmega328p et SPI'''

- réflexion: penser à faire boucler sur l'arduino une fois la requête reçu, ça veut dire que la manette est ON et donc vérifier continuellement les modules sur chaque atmega.
- SPI raspberry pi - arduino recuperation état du bouton avec les cartes modules (/!\ récuperation à faire dans une variable)

-SSH perso
adresse Rasppi: 192.168.137.10

====Electronique: Finalisation soudure Modules====

Soudure au propre et finale d'une carte atmega328p et donc envoie pour la réalisation de 2 autres cartes similaires et récupération de matériel
Soudure des 2 autres cartes, + tests sur les états = fonctionnelles.
On a donc bien 3 cartes pour les 3 modules de types différents (1 bouton, 1 joystick, 1 gachette)
PCB pour les 2 joysticks (qui serviront de thumbstick et gachette)

==Semaine 13 et plus==

====Programmation====

'''Raspberry Pi Zero W et PS4'''

'''Modules Atmega328p et SPI'''

====Electronique====

=Documents Rendus=

(à mettre rapport + git + drive)

=Datasheets=

IMA4 2017/2018 P35

2018-05-05T18:37:57Z

Tgracias : /* Connexion USB PS4-RPi3 */

__TOC__
 

=Présentation générale: Manette modulable=

==Description==

Tout le monde joue aux jeux vidéo cependant, les manettes ne sont pas adaptées aux personnes ayant un handicap pouvant toucher les bras ou les mains.
C’est le cas, de plusieurs patients dans les centres de soins et de rééducation.

Pour ce projet IMA4, nous travaillerons avec le centre SSR (soin de suite et de réadaptation) Marc Sautelet de Villeneuve d’Ascq.
Un adolescent, patient de Marc Sautelet, est passionné par les jeux vidéo. En effet, ayant perdu la motricité d’une partie de son corps, il ne peut pas jouer à deux mains. Pour cela, il bloque la manette entre son épaule et son coude, usant de la mâchoire et des doigts pour contrôler les
joysticks et les boutons. Cet exercice peut s’avérer fatiguant et pénible.

Ainsi, nous chercherons à concevoir une manette PS4 adaptée au handicap de l’adolescent.
Cette manette devra aussi être adaptée pour d’autres patients présentant également des handicaps moteurs. Ainsi nous prendrons pour cibles: tous les patients du centre voulant jouer; et non pas que les enfants et adolescents.

 

{| class="wikitable centre" width="80%"
|+
|-
| width="23%" |
Membre du projet
| width="34%" |
Transley Gracias et Camille Saad
|-
| width="23%" |
Cible
| width="34%" |
Patient présentant un handicap moteur
|-
|width="23%" |
Période du projet
| width="34%" |
janvier 2018 - mai 2018
|-
|width="23%" |
Partenaire/Client
| width="34%" |
Centre SSR Marc Sautelet à Villeneuve d'Ascq
|}

==Objectifs==

Ce projet a pour objectif de créer un prototype de manette qui puisse interagir avec la console PS4 et dont le paramétrage se fait à l’aide d’une application mobile et/ou web. Cette manette devra suivre les demandes du patient ainsi que des aides-soignantes du centre, dans la mesure du possible.

Plus précisément, pour le premier prototype, nous mettrons en œuvre l'utilisation de quelques boutons spécifiques:

* Un joystick (type L/R)
* Quelques boutons poussoirs (type Croix/Triangle/Carré/Rond/R1/L1/Start/...)
* Des boutons gâchettes progressives (type L2/R2).

Le but serait donc dans un premier temps de rendre fonctionnel un bouton de chaque type, puis de les multiplier une fois cela fait. Tous ces boutons réunis constituent une manette fonctionnelle.Ainsi, la manette sera ajustable, c’est à dire qu’elle devra s’adapter aux différents handicaps moteurs possibles.

=Analyse du projet=

==Positionnement par rapport à l'existant==

Notre prototype aura une présentation unique par rapport à l’existant. En effet, les concurrents et produits existants ciblent pour la majorité un seul handicap. Cela
engendre une solution fermée à beaucoup de patients. Notre projet propose une mobilité des mouvements et également un choix large dans la composition et le
design de notre manette.
Le patient n’est pas retreint à jouer à une seule main, à utiliser beaucoup de force...Il y a moins de technique dans la manipulation et on ne joue pas avec une
manette adaptée uniquement pour un droitier ou un gaucher. Cependant, cela nous limitera peut-être dans le choix possible des types de jeux. Tout comme les autres
manettes adapté, l’utilisateur nécessitera un peu d’entrainement.

==Analyse du premier concurrent==

Jouer aux jeux vidéo à une main n’est pas une idée d’aujourd’hui. En 1990, Nintendo propose le Power Glove. Mais il tombe très rapidement aux oubliettes suite à des problèmes techniques.

Un autre gant a fait son apparition quelques années plus tard. Celui-ci, plus technique, il faut office de manette Play Station: le Reality Quest Power Glove.Cette idée de manette-gant, permet de jouer à la PS avec une seule main, elle a était conçue et présentée pour les E3, un salon d’exposition de gaming.Le gant est conçu pour contrôler l’équivalent des 14 boutons et 2 joysticks à l’aide d’une seule main. La « manette » est fixée dans la pomme de la main. L’utilisateur contrôle les mouvements verticaux et horizontaux en pivotant le poignet, et utilisent les 4 boutons d’action principaux et L1/R1 avec les doigts. Les autres boutons sont accessibles par un seul bouton rond contrôlé par le pouce.
La manette est adaptée pour beaucoup de jeux vidéo, dont les plus simples sont les jeux de voitures et de combats (arcade).

; Problèmes:
*Besoin de toute la motricité de la main, c’est-à-dire que si le patient à un doigt paralysé ou manquant, il ne pourra pas jouer avec ce gant
*Design obligatoirement droitier
*Les boutons de contrôle sont peu sensibles et peuvent nécessiter de la force
*Design compliqué et nécessitant beaucoup d’entrainement.

;Lien : https://www.youtube.com/watch?v=qV0SxSJDCYg

 
==Analyse du second concurrent==

Ben Heck, de son vrai nom Benjamin J.Heckendorn, est un concepteur de mods de consoles (mods pour modification, soit « manettes modifiées ») et une star
du net grâce à ses vidéos tutoriels.Il propose alors énormément de produits adaptés ou dérivés en guise de manettes.
Parmi les mods qu’il a réalisé, il a modifié une manette de PS4 afin de la rendre accessible à une personne ne pouvant jouer qu’à une main. Pour cela, il a déplacé les boutons en respectant l’ergonomie de la main valide et modifie les connexions. Il peut lui arriver de rajouter des boutons pour en remplacer un autre. Il réalise également le même système avec la Xbox. Sur la photo ci-dessous, il a adapté la manette pour un droitier.

; Problèmes:
*Besoin de toute la motricité de la main, c’est-à-dire que si le patient à un doigt paralysé ou manquant, il ne pourra pas jouer avec cette ma
*Design obligatoirement droitier ou gaucher, une modification = une manette= une personne
*Besoin obligé du pouce et de l’index, même si avantage : 3 doigts nécessaire.

;Lien :: https://www.youtube.com/watch?v=LieHIscadjk

==Scénario d'usage du produit ou du concept envisagé==

La technologie est ,aujourd’hui, omniprésente dans notre vie. Les consoles de jeux ont envahies les maisons avec plus de 7 personnes sur 10 jouant aux jeux vidéos sur consoles en France (chiffre de l’Express). 0,18% des français sont handicapés cela représente 12 millions de français. Dans ce chiffre, 13,4% des personnes ont un handicap moteur. En 2017, les grands groupes comme Sony ou Microsoft avec respectivement PlayStation et Xbox ne permettent pas à tout le monde de jouer avec une manette. Les manettes sont prévues pour des personnes ayant leurs membres valides, plus précisément les mains et les bras.

Après un accident de voiture, un jeune garçon a perdu la motricité d’un côté du corps. Passionné de jeux vidéo, il se retrouve avec des difficultés à jouer sur sa console PS4. Ingénieux, il utilise la manette en la coinçant entre son épaule et le creux du cou. Usant de la mâchoire et de sa main valide pour contrôler les joysticks et les boutons. L'exercice étant inconfortable et fatiguant il eu l’idée de proposer à des futurs ingénieurs de lui proposer une manette adaptée à son handicap.

Les deux pré-ingénieurs ,avec leur tuteur, ont une idée révolutionnaire : La manette modulable ! Elle permettrait au jeune garçon, ainsi que d’autres joueurs, de pouvoir continuer de s’amuser ou même de commencer à jouer au jeux sur console.
Cette manette aidera fortement dans les centre de rééducation pour faire passer le temps et donner du plaisir à des personnes qui ne peuvent plus s’amuser avec leur console traditionnelle. Elle pourra aussi ouvrir de nouvelles possibilités pour certaines personnes qui n’auraient jamais essayé jusqu'à présent.
Comme son nom l'indique, elle sera modulaire et s'adaptera à différents handicaps. Accompagnée de son application d’initialisation, elle sera accessible aussi bien aux enfants, patients, parents et aides soignantes.

Quelques mois plus tard...Le jeune patient fan de Need For Speed, peut maintenant piloter sa voiture comme un vrai professionnel grâce à l'un des joysticks qu'il utilisera avec sa main valide et il pourra accélérer à des vitesses folles à l'aide de boutons poussoirs au niveau de son pied valide et gagner la partie. Son ami venu lui rendre visite, pourra en lieu et place des aides soignantes configurer à l'aide de la tablette (portable) la manette du patient.
Si le patient change de jeu pour Tekken et que la configuration des modules ne lui convient plus, il peut interchanger les éléments de la manette selon son envie et son confort. Ainsi il peut faire sauter son personnage, il utilisera un module bouton supplémentaire, qu'il actionnera avec le poing.

==Fonctionnement==

Suite à une analyse fonctionnelle et à la formulation de notre projet, nous avons pu définir le fonctionnement de notre système. Notre produit, la manette, doit être accessible d’après nos objectifs à différents types de handicaps moteurs. Ainsi, l’idéal serait de concevoir une manette modulable afin qu’elle puisse s’adapter à toutes les situations. Ce n’est plus au patient de s’adapter à la manette mais à la manette de s’adapter au patient.
Cela signifie que la manette sera, dans la limite du possible et de la sensibilité du corps du patient, composée de plusieurs parties dites « modules » comportant un ou plusieurs actionneurs (boutons, joysticks, gâchettes...). Ces modules seront déplaçables afin d’être utilisé avec différents membres du corps : un doigt, une main,
une jambe ou même un pied. Il suffira de les connectés entre eux suivant l’organisation souhaitée, le Gameplay du jeu ou en fonction du handicap. Le tout sera relié à une application.
L’application sera alors mise en place pour connecter les différentes parties du point de vue software pour prérégler la manette en fonction du patient. Il pourra alors choisir les boutons en fonction du jeu, de ses mouvements mais aussi choisir la sensibilité.

L’application et les modules devront être intuitifs et faciles d’utilisation. De cette manière des utilisateurs non avertis dans le domaine informatique ou jeunes pourront eux-mêmes gérer les connexions.

==Réponse à la question difficile==

'''Question : Comment interconnecter les différents modules de la manette ?'''

Il nous faut pour ce projet interconnecter les modules modélisant la manette qui seront connectés à la consoles PS4 via une Raspberry Pi 3.
Le choix de la Raspberry Pi 3 nous permet d'utiliser son module Bluetooth pour communiquer avec la PS4, ce choix est plus adaptée au projet que du filaire.
Concernant l'interconnexion des modules, nous travaillerons en deux étapes "preuves concept" : filaire et sans fils (Bluetooth).

'''Objectif 1 : Preuve concept filaire'''

Dans cette première partie de projet, nous souhaitons avoir une 1ère preuve de prototype rapidement. Nous nous concentrerons alors sur la communication entre la RPi3 et la PS4 ainsi que sur la conception des modules. Pour les modules, nous réaliserons des cartes électronique pour chaque module avec un micro-contrôleur. La communication filaire nous permettra d'interconnecter les modules à la RPi3 avec un bus SPI.

'''Objectif 2: preuve concept sans fils'''

Une deuxième étape du projet est la réalisation de la solution idéale sans fils. Celle-ci pourra commencer à être développée petit à petit en parallèle avec l'objectif 1. Le but ici, est d'interconnecter les modules en Bluetooth. Nous avons choisi le Bluetooth pour garder une connexion commune sur toute la chaîne.
Nous rajouterons alors un module bluetooth à chaque module de la manette.

'''Objectif 3: possibilité d'adapter les boutons (capuchon en 3D)'''

=Préparation du projet=

==Cahier des charges==

''Chef de projet:'' Alexandre Boé 
''Responsables:'' Xavier Redon, Thomas Vantroys 
''Partenariat:'' Marc Sautelet (non etablie) 
''Elèves-ingénieurs:'' Camille Saâd, Transley Gracias 

'''Sujet :''' Manette modulable pour personne à déficience moteur compatible PlayStation 4 

===Objectifs principal (1er POC) : ===
Faire transmettre des informations issus des actionneurs (ex:boutons poussoires) via des arduinos jusqu’à la Raspberry Pi 3 en SPI. 
Envoyer les données reçues vers la PS4 en USB 

===Objectifs secondaire (2e POC):===
Créer des modules avec un microcontrôleur et une puce bluetooth pour permettre une meilleurs flexibilité (c-àd pouvoirs avoir une meilleure ergonomie et une connexion sans fil) 
Connecter la Raspberry Pi 3 en Bluetooth à la PS4 

[[Fichier: beteacorne.jpg||middle|600px|Bete a corne manette]]

==Choix techniques : matériel et logiciel==

===Liste de matériel :===

'''Modules boutons/joysticks/gachettes'''

3 Push buttons : 
- O X Y Carré R3 L3 
- Guide PS 
- start/back 
--> 0,45€/unité TTC [https://www.gotronic.fr/art-bp-miniature-krs1273-16976.htm] 

1 Thumbstick original: 
Joystick analogique 4 directions --> 4,25€/unité TTC [https://www.gotronic.fr/art-joystick-analogique-4-directions-19063.htm] 

1 buttons trigger L1 L2 => 1x Thumbstick original''' 

'''Cartes Atmega328p /connexion spi/'''

3 Arduino UNO 
1 Arduino UNO atmega328p retirable 
4 capacite 22pF traversantes 
2 resistances 10 kOhm traversantes (à récupérer) 
2 oscillateurs quartz 16MHz traversante 
2 atmega328p-pu et support 

'''Cartes module bluetooth nrf52810 '''

6 capacités 100nF 0603 
6 capacités 12pF 0603 
2 capacités 4,7pF 0603 
2 capacités 1µF 0603 
2 capacités 100pF=0,1nF 0603 (à récupérer) 
2 capacités 0,8pF 0603 (a acheter, commande en cours) 
2 inductance 3,9nH 0603 (a acheter, commande en cours) 
2 oscillateur quartz 32 MHz 

''' Connexions et autres '''

1 Led RGB neopixel [https://www.adafruit.com/product/1734] 
1 Raspberry Pi 3 
--> ~36,23€/unité TTC [https://fr.rs-online.com/web/p/processor-microcontroller-development-kits/8968660/?src=raspberrypi] 
1 Raspberry Pi Zero W (commandée) [https://www.raspberrypi.org/products/raspberry-pi-zero-w/] 
6 Alimentations 5V ou 3,3V 
par exemple, 12 piles de type CR2016 3V rechargeables ou 24 piles AAA 1,5 V rechargeables
5 modules Bluetooth nrf de Nordic : nRF52810-QFAA-R 
--> 3,17€/unité + frais expédition [https://www.mouser.fr/productdetail/nordic-semiconductor/nrf52810-qfaa-r?qs=sGAEpiMZZMve4%2FbfQkoj%252bG%2FosjLoe2oghFQwQllMrQ4%3D]
5 Lignes broches mâles 

===Logiciels:===

- IDE arduino
- Altium
- FreeCAD ou Inkscape

==Liste des tâches à effectuer==

'''Etape 1 : Gestion du projet'''

* Définition des cahiers des charges fonctionnel et technique, choix d'orientation...
* Recherche techniques sur les différentes connexions possibles entre les modules, la RPi 3 et la console PS4
#Recherche connexion SPI entre les modules et la RPi3
# Recherche connexion bluetooth entre la RPi3 et la PS4
# Recherche connexion bluetooth pour les modules
# Recherche carte avec montage Atmega328P-PU et anticipation module bluetooth
* Détermination du matériel nécessaire
* Réflexion sur l'application

'''Etape 2: Réalisation du projet'''

'''Partie 1: Preuve concept manette en filaire'''

* Conception de cartes électroniques pour 2 modules (/!\ prévoir modules bluetooth)
* Réalisation connexion SPI avec 2 modules : programmation des Atmega328p en liaison série.
* Si tests concluant, ajouter des modules jusqu'à en avoir 5 (1 pour chaque type de boutons)
* Connexion bluetooth entre la PS4 et la RPi3
* Réalisation du support des modules avec fixations possibles (imprimante 3D)

'''Partie 2: Preuve concept manette en bluetooth'''

* Ajout des modules bluetooth aux cartes électroniques
* Connexion bluetooth entre les modules

'''Partie 3: Application Android : paramétrage de la manette'''

* Créer une application sur tablette ou smartphone (Android) afin de configurer la manette aux besoins (inter-connexion des modules et console)

==Calendrier prévisionnel==

{| class="wikitable centre" width="80%"
|+
|-
| width="23%" |
'''Date'''
| width="34%" |
'''Tache à réaliser''' 
|-
| width="23%" |
17/01/18-24/01/18
| width="34%" |
Faire des recherches sur les différentes interconnexions du système : Bluetooth, RPi-Atmega328 (SPI), RPi-PS4
Continuer liste des taches, matériel, Début recherches + réflexion fixation support des modules
|-
|width="23%" |
31/01/18
| width="34%" |
Recherche technique connexion PS4-RPi3 et connexion SPI RPi3-Module + code
|-
|width="23%" |
31/01/18-07/03/18
| width="34%" |
Réalisation 1er prototype (+ début prototype 2)
|-
|width="23%" |
07/03/18
| width="34%" |
Seance 7 : Test prototype filaire
|-
|width="23%" |
07/03/18-09/05/18
| width="34%" |
Réalisation 2eme prototype + application Android
|-
|width="23%" |
09/05/18
| width="34%" |
Seance 14 : Test prototype Bluetooth
|-
|width="23%" |
14/05/18
| width="34%" |
Video projet
|-
|width="23%" |
15/05/18
| width="34%" |
Finalisation projet et Rapport
|-
|width="23%" |
16/05/18-17/05/18
| width="34%" |
Soutenances Projet
|}

=Réalisation du Projet=

==Feuille d'heures ==

Voici le tableau d'heures du binôme:

{| 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 S11 !! Heures S12 !! Heures S13et+ !! Total
|-
| Analyse du projet
| 10
| 2
| 1
| 1
| 1
|
|
|
|
|
|
|
| 20min
|
| 15h20
|-
| Cherches techniques
|
| 3
| 4
| 4
| 2
| 2
| 1
|
|
|
| 1
| 1
|
|
| 18
|-
| Rédaction du wiki et rapport de projet
|
| 1
| 1
| 1
| 1
| 30min
| 1
|
| 2
| 30min
| 30min
|
| 2
|
| 10h30
|-
| Programmation
|
|
|
|
| 3
| 2
| 3
| 5
| 4
| 7
| 8
| 6
| 5
|
| 43
|-
| Cartes électroniques
|
|
|
|
|
| 6
| 8
| 4
| 6
| 2
| 1
| 2
| 2
|
| 31
|-
| Application
|
|
|
|
|
|
|
|
|
|
|
|
|-
|-
| Total Semaine
| 10
| 6
| 6
| 6
| 7
| 10h30
| 13
| 9
| 12
| 9h30
| 10h30
| 9
| 9h20
|
| '''117h50'''
|}

==Prologue==

Avant la réalisation et conception d'un projet, il est important d'analyser celui-ci. Nous avons allons consacré le prologue à l'analyse fonctionnelle de la manette. Nous avons également eu une réflexion sur l'analyse technique, cela nous a permis de réaliser une liste de matériel. Il est important de définir les objectifs ainsi que les besoins afin de ne rien oublier. (Voir ci-dessus Analyse projet)
Nous avons également organisé notre travail, pour le partage de documents de recherches et la rédaction de compte-rendu final nous avons réalisé un google drive. Par la suite, nous créerons un projet Git.

Durant ce temps, nous avons décidé de réaliser 5 modules. Les modules sont les différents boutons de la manettes qui nous pourrons placer selon nos choix (boutons modulaires) pour notre prototype projet pour chaque type des boutons d'une manette PS4. Ces modules devrons être connectés à la console et interconnectés. Le tout sera lié à une application Android. Suite à quelques recherches et nos analyses, nous avons décidé les points suivants :

- On commencera avec 2 modules et on les multipliera par la suite.
- Les premiers tests sont réalisés avec des boutons petits pour assurer leur caractéristique "modulaires", par la suite nous pourrons ajouter des capuchons de taille plus importante (imprimante 3D ou achat)
- Conception modules : réalisation de carte avec un microcontrôleur atmega328 programmable pour chaque module (anticiper le module Bluetooth)
- Projet en 2 parties : prototype filaire et prototype Bluetooth
# Prototype filaire : connexions entre les modules et la RPi3 en SPI, connexion Rpi3-PS4 en Bluetooth, avec l'application en filaire à la RPi3
# Prototype Bluetooth: connexion Bluetooth entre modules-RPi3-PS4-apllication

[[Fichier: structuremanette.png||center|400px|Concept manette modulable]]

==Semaine 1==

Durant la séance, nous nous sommes concentrés les recherches afin de définir clairement le cahier des charges technique. Il s'agit des réalisations à mettre en œuvre pour les inter-connexions des éléments de la manette.
Ainsi, nous avons fait des recherches sur :

===Connexion SPI entre les modules (Atmega328p) et la RPi3===

SPI: Serial périphérique interface BUS

[[Fichier: yWGmW.png||right|200px|Concept manette modulable]]
Comme indiqué sur l'image ci-dessus, la Raspberry pi 3 peut communiquer en SPI avec ses broches CS0 (24), CS1 (26), SCLK (23), MISO (21), MOSI (19). Celles-ci permettent de communiquer avec un ou plusieurs esclaves (dans notre cas, des Atmega328p) en reliant directement les broches concernées de la RPi3 à celles des composants esclaves.
Chaque broche CS0 (24) ou CS1 (26) ne peut être connectée qu'à l'entrée SS (aussi appelé CS) d'un seul esclave.
C'est a dire que chaque CS est lié à un esclave afin de choisir avec lequel la communication est établie à un moment donné, et les MISO sont reliées entre elles en cascade, de même pour les SCLK et les MOSI. On peut noter que le maître impose la fréquence d’horloge et sélectionne l’esclave auquel les données sont envoyées. 8 MHz est le plus rapide supportable a 3,3V

[[Fichier: fonctionnementSPI.png||right|200px|Connexion SPI multi-esclaves]]

Voici un schéma du fonctionnement souhaité :

Comme nous souhaitons avoir 5 modules environ il nous faudra rajouter un composant en plus afin d'augmenter les possibilités de sélection, par exemple des démultiplexeurs.
Dans un premier temps nous essaierons avec 2 esclaves, puis on augmentera le nombre.

===Connexion Bluetooth PS4-RPi3===

Les recherches portent également sur la connexion entre la manette PS4 et la console. Elles concernent le protocole de communication via Bluetooth

Caracteristique pour la PS4: Bluetooth®v4.0, Qualcomm Atheros AR3002 Buetooth LE: 2,4-2,5 GHz 

Caracteristique de la connexion : 

*Vitesse de transmission >> 3 Mbit/s 8N1
*Relevé tous les 1.3 millisecond (peut-être)
*Chaque manette à une adresse unique BD_ADDR qui correspond à l’adresse MAC de la carte Réseau
*Protocole de détection est le SDP basé sur une emission reception PDU
*L’Attribut ID est representer en TLV Type Length Value
*Communication HCI ACL Data Packet

===Rélisation des cartes électroniques===

matériel nécessaire pour un PCB : 

*breadboard
*câbles
*1 x 10k Ohm résistance
*Quartz 16Mhz clock crystal
*2 x 22 pF capaciteurs
*Atmega328P-PU

Ressources:
[[https://www.arduino.cc/en/Main/Standalone]]
[[http://www.eprojectszone.com/atmega-328-pu-standalone/]]
[[https://www.arduino.cc/en/Tutorial/ArduinoToBreadboard]]

==Semaine 2==

Durant la semaine deux et durant la séance, nous avons continué et approfondie nos recherches sur le projet. Nous avons pu ainsi affiner nos taches de réalisation et donc notre cahier des charges.

===Connexion aux modules: SPI et Bluetooth ===

 CORRIGER

voir https://peip-ima.plil.fr/mediawiki/index.php/BE_2017-2018#Configuration_du_syst.C3.A8me_embarqu.C3.A9

(sudo apt-get install pi-bluetooth)

''connexion sur la raspberry par ssh:''
su
update-rc.d ssh enable
invoke-rc.d ssh start
ssh pi@172.26.79.1XX

''bluetooth''
bluetoothctl
agent on
default-agent
scan on
pair [device Bluetooth address] (exemple: pair XX:XX:XX:XX:XX:XX )

''NOUVELLE REFLEXION : Connexion SPI entre les modules (Atmega328p) et la RPi3 --> MODULES BLUETOOTH''

Si multi-esclaves= plusieurs modules :
Il faut ajouter des sélections pour les SPI → démultiplexeurs OU ne pas utiliser les CS0 et CS1, et plutôt des pins entrée/sortie de la RPi3 lié au SS comme ça on choisit direct le module esclave voulu.

'''IMPORTANT:''' Nous avons étudié à nouveau la datasheet de notre module bluetooth nrf de Nordik. Le module bluetooth comporte déjà un microprocesseur !
Un module plutôt peut donc jouer le rôle de notre atmega328p. Il n'y a alors pas besoin de réaliser des cartes électroniques de type arduino standalone. Nos PCB regrouperont alors uniquement l'alimentation, un actionneur (bouton, joystick), le module bluetooth et les broches de connexion si besoin...

Cette séance nous a alors permise de revoir entièrement le matériel nécessaire. Notre liste de matériel nous semble alors plus réfléchie et limitée au nécessaire.

===Connexion Bluetooth PS4-RPi3===

Suite à nos recherches de la semaine précédente, nous avons sélectionné deux sites bien renseignés :

SITES

Ils nous ont permis de comprendre la communication entre la manette et la console. En effet, ils nous expliquent les échanges de trames Bluetooth.
EXPLICATIONS 1 exemple 

==Semaine 3 : Début premier prototype==

===Connexion SPI RPi3-Arduino===

Comme vu durant les semaines précédentes, nous souhaitons réaliser une connexion Multi-esclaves en SPI entre la Raspberry pi et plusieurs modules.
Cette semaine nous avons vu que la réalisation de notre premier prototype doit aller vite. Il ne nous est pas nécessaire d’attendre les modules bluetooth si il nous faut dans cette partie uniquement utiliser son microprocesseur. Ainsi pour chaque module nous utilisons une arduino UNO. Nous réaliserons les programmes en C afin de pouvoir les réutiliser avec les modules bluetooth par la suite.
Une fois la connexion réalisable nous adapterons les programmes aux modules bluetooth Nordik. En effet, ceux-ci comporte déjà un microprocesseur, le module peut jouer le rôle de notre atmega328p. Il n'y a aurait alors pas besoin de réaliser des cartes électroniques arduino standalone sur PCB, mais directement des cartes électronique avec le module et le module voulu (bouton, joystick...) et l'alimentation.
Durant la séance nous avons alors revu la liste de matériel nécessaire.

[[Fichier: prototype1.jpeg||center|600px|connexion filaire prototype 1 filaire arduino]]

Durant la séance, nous avons recherches des exemples de codes et de librairies pour Arduino SPI et RaspberryPI SPI.

Nous avons également commencé le programme de la connexion SPI pour l'arduino et récupéré les bibliothéques SPI.h avec SPI.c. Nous nous sommes alors concentrer à les comprendre, pour pouvoir l'utiliser.

===Réalisation du projet Git===

Création du projet IMA4_Projet35_ManetteModulable sur Git et partage de celui-ci.
Les premiers dossier crées cette la séance :
-Arduino (connexion SPI arduino) : ProtoSpi.c + dossier librairie SPI + Makefile
-RPI (dossier codes pour Rpi)
-Readme.md
Ces dossiers seront amenés à être modifiés au cours des séances.

===Protocole Bluetooth PS4===

Suite à l'étude des trames Bluetooth, on a pu voir que ces dernières étaient incomplètes. Le modèle de communication étant propriétaire, on n'y a pas accès directement. Cela nous empêche donc de mettre en oeuvre cette communication.
 Déveloper

On a décidé de commencer par une connexion USB (pour laquelle on dispose de toutes les informations) celle-ci étant plus complète.

==Semaine 4==

Pour le prototype 1 FILAIRE nous réaliserons les étapes suivantes :

#Réalisation du programme SPI pour arduino
#Réalisation du programme SPI pour la RPi
#Connexion USB avec la PS4 ou ordinateur
#Réalisation de cartes électroniques atmega328p-pu standalone (remplacer les Arduinos)
#Remplacer les "PCB arduino" par le module bluetooth et adapter la connexion
#Conception 3D de la délimitation 1 axe pour le joystick "gâchette"
#Réalisation de l'application Androïde.

Une fois ces étapes réalisées nous auront alors une preuve de concept filaire et nous pourrons alors passer à une connexion bluetooth.
Le passage à la connexion bluetooth sera le deuxième prototype et le cas idéal de la réalisation de la manette modulable.

===Mise à jour Matériel===

- Modéliser les boutons gâchettes L1/2 R1/2 de la manette PS4 (boutons sensibles à la pression) --> un joystick dont nous bloquerons un axe (imprimante 3D)
- Remplacer la RPi 3 par une Rpi zero W qui nous permettrait de réaliser plus facilement une connexion USB tout en gardant l'avantage du bluetooth.
- Choix de l’alimentation pour les 5 modules Bluetooth: nécessitent 3V --> utiliser des piles rechargeables 1,2V AAA plutôt que piles rondes 3V.

Nous avons également besoin du matériel cité en semaine 1 pour réaliser des cartes électroniques atmega328p-pu standalone. ( nous revenons alors sur les décisions de la semaine 3)

===Connexion SPI RPi3-Arduino===

Montage Raspberrypi et 1 arduino en PSI + 1 bouton + 1 led.
Voici le choix des branchements :

MASTER = RPi
SLAVE= Arduino

'''SPI sur Arduino:'''
MOSI -> GPIO11 //PB3 //master OUT to the slave IN
MISO -> GPIO12 //PB4 //slave OUT to the master IN
SCLK -> GPIO13 //PB5 //serial clock
SS -> GPIO10 //PB2 //slave select
'''Led, bouton et autre...'''
LED --> GPIO6 //PD6
GND
+5V (if required)
'''SPI sur la Raspberry Pi'''
SPIO MOSI -> PIN19
SPIO MISO -> PIN21
SCLK -> PIN23
SPIO CS0 -> PIN24

Continuation du code pour faire clignoter Led branchée à une arduino depuis la Rpi, en connexion SPI.

===Connexion USB PS4-RPi3===
Durant cette, nous avons regardé comment faire cohabiter bluetooth, Application Androïd, USB, PS4, SPI et les module.

Il est alors important de savoir comment utiliser le port série sur la RPi3, soit utiliser les UART.

Nous avons réaliser qu'il n'était pas aussi simple d'utiliser le port serie USB de la Raspberry Pi 3, en effet le SoC est un BCM2837 .
De plus nous ne pouvons pas utiliser le même port pour l'alimentation et la connexion.

Il nous faut alors trouver une alternative ou une solution à ce problème.

==Semaine 5==

===Programmation: Réflexion définitives prototypes filaire ===

Durant la semaine 5, nous avons continué la réalisation du prototype filaire par l'avancé du code SPI ainsi que les recherches concernant le protocole PS4.

Pour réaliser la connexion entre la PS4 et les différents modules, nous avons vu la semaine dernière que nous utiliserons une RPi zero W (que nous avons commandé). Celle-ci nous permet d'utiliser le bluetooth mais elle nous permet également de réaliser un réseau local sans fil. Ce qui peut être pratique dans la mesure où notre projet est modulable.
En attendant la réception de la commande, nous nous sommes penché sur les programmes et la configuration nécessaire à l'utilisation de la RPi zero W.

===Electronique===

[[Fichier: bouton_c1.jpg|100px|thumb|left|PCB bouton]]
[[Fichier: arduinobb.jpg|200px|thumb|right|atmega328p-pu branchement test]]

Du coté électronique, nous avons réalisé sur fritzing certaines cartes électroniques. Les Arduino Uno servant actuellement de test, seront remplacées par des PCB atmega328p-pu standalone avec des broches permettant les branchements nécessaires SPI ou encore aux modules "boutons/joystick". Pour les boutons, nous avons également réalisé un pcb afin de faciliter les branchements.

Il nous faut alors également une 3eme carte qui nous sera nécessaire pour la réalisation du prototype sans fil. Dans notre liste de matériel, nous avons des composants nrf52810 bluetooth, ceci doivent être soudé avec les capacités de protection mais également des broches de communication. Nous avons alors commencé cette carte électronique sur Altium avec le fichier projet PCB du distributeur à modifier.

[[Fichier: Arduino_c1.jpg|100px|thumb|center|PCB atmega328p-pu]]

=== Construction 3D ===

Enfin, nous avons commencé à réaliser des boîtiers 3D pour certains modules. Par exemple, comme nous l'avions vu précédemment, un des joysticks servira de bouton-gâchette en utilisant un seul de ses axes. Il nous faut alors réaliser un boitier qui bloque l'un des axes, mais également une tige qui nous permettra de pousser le joystick de manière simplifiée.

==Semaine 6==

===Programmation: configuration RPi Zero W ===

Ayant reçu la Raspberry Pi zero W en début de semaine, nous nous sommes concentrés sur la programmation et la configuration de celle-ci.

===Electronique: PCB nrf52810===

Les cartes réalisées en semaine 5 sont validées et en attente de réalisation.

Cette semaine a permis la réalisation et la finalisation de la carte électronique nrf52810. Il nous a fallu recommencé cette carte deux fois. En effet, une fois finie sur Altium nous avons réalisé que les empreintes des CMS sur PCB fourni par le constructeur ne correspondent pas au matériel CMS de l'école. Face à cette inattention de notre part, nous avons décidé de refaire entièrement la carte électronique sur fritzing. Ayant la datasheet et des plans d'inspiration PCB, nous avons pu refaire la carte entièrement.
Sur celle-ci nous avons ajouté des broches de connexion au besoin, un branchement Jtag et ICSP pour la programmation et la connexion SPI.
La carte est en attente de validation, puis validation.

[[Fichier: nrf52810_circuit2.jpg||center|400px|PCB carte nrf52810]]

===Révision matériel ===

Pour la réalisation de nos composants électroniques, il nous a fallu faire une révision des composants disponibles à l'école:
(les quantités indiquées ci-dessous pourront être augmentée si nécessaire,pour avoir dans l'idéal un module de chaque type de la manette, ici on se concentre sur BOUTON et JOYSTICK)

'''Cartes Arduino:'''
* 4 capacite 22pF traversantes
* 2 resistances 10 kOhm traversantes (à récupérer)
* 2 oscillateurs quartz 16MHz traversante
* 2 atmega328p-pu et support

'''Cartes nrf52810'''
* 6 capacités 100nF 0603
* 6 capacités 12pF 0603
* 2 capacités 4,7pF 0603
* 2 capacités 1µF 0603
* 2 capacités 100pF=0,1nF 0603 (à récupérer)
* 2 capacités 0,8pF 0603 (commande en cours)
* 2 inductance 3,9nH 0603 (commande en cours)
* 2 oscillateur quartz 32 MHz

'''Cartes modules Boutons'''
* un sachet de broches mâles (qu'on utilisera également pour les autres cartes, à récupérer/acheté)

Nous avons alors mis-à-jour la liste de composant située plus haut, ainsi que celle de la page IMA4 2017/2018 [https://projets-ima.plil.fr/mediawiki/index.php/Projets_IMA4_SC_%26_SA_2017/2018]

==Semaine 7==

===Programmation: connexion wifi RPi Zero W et Bootloader sur Atmega328p-pu ===

Pendant cette semaine, nous avons continué la programmation et la configuration des Raspberry Pi 3 et Zero W afin de les utiliser en connexion Wifi.

Nous avons également continuer les programmes de récupération de données : état des boutons et du joystick. Ces programmes sont appliqué sur l'atmega328p-pu standalone sur la plaque d'essai en attendant que le PCB soit opérationnel.
Pour pouvoir programmer l'atemega328p-pu comme une arduino UNO, il nous faut suivre plusieurs étapes :

'''1.Flasher le Bootloader'''
Nous avons 2 Atmega328p-pu neufs, ainsi il nous faut flasher le bootloader sur chacun d'eux afin de pouvoir les utiliser et les programmer sur une breadboard dans un montage minimaliste arduino-standalone.
Pour cela, on peut utiliser une carte arduino UNO. On vérifie le port et le type de carte sélectionnés dans le menu >Outils. Sur cette carte on téléverse le fichier arduinoISP.ino qui se trouve dans les exemples en étant en progrmamateur AVr ISP mkll (>outils>programmateur)
Puis on met l'atmega328p-pu qui nous intéresse sur le suppor socket de la carte. On change de nouveau le programmateur pour Arduino as ISP et on fait >tools>burn bootloader, soit >graver la sequence d'initialisation.
Ces étapes faites, on peut retirer notre microcontroleur et le replacer correctement dans le montage.

'''2.Programmation atmega328 sur breadboard'''
Une fois l'atmega328p-pu préparé, on peut le programmer. On peut le faire simplement à l'aide de la carte arduino UNO utilisée précédemment.On branche les Tx et Rx en commun ainsi que le reset, le GND et le VCC.

Nous avons réaliser des codes basiques tels que le clignotement d'une led rouge ou encore l'affichage de "hello world" sur le moniteur série pour vérifier la bonne fonctionnalité du montage. Cela fait nous avons pu écrire sous Arduino IDE le code de lecture des états.

[[Fichier: montage_BB_test.jpg||left|200px|programmation modules arduino sur breadboard]]

===Electronique : soudure carte de test modules ===

Comme nous l'avons déja vu lors de la réalisation des PCB, si l'on souhaite programmer un atmega328p-pu en bootloader, le montage est simple. Il peut être minimaliste en utilisant une arduino UNO, un atmega328, une breadboard et 3 composants: 1 quartz 16MHZ crystal, 1 résistance 10kOhm et 2 capacitors céramiques de 22pF.
Durant la semaine 7, nous avons soudé les composants traversants de la carte électronique correspondant à ce montage ainsi que le PCB du bouton.

==Semaine 8==

===Programmation ===

===Electronique : Correction soudure et soudure CMS===

Durant cette semaine, nous avions souhaité programmer la carte électronique atmega328p-pu. Cependant, nous avons réaliser que nous avions fait une erreur lors de l'envoie du PCB à la production. En effet, celui-ci avait été fait en Top sur le logiciel Fritzing et non en Bottom. Hors nous avions soudé les composants (durant la semaine 7) comme pour un circuit imprimé en bottom, l'atmega328p-pu se retrouve alors inversé par rapport aux pistes.
Comme solution, nous avons choisi de souder un deuxième support pour l'atmega328 de l'autre coté de la carte avant de la refaire au propre. En effet, avant de la refaire il nous faut vérifier si la carte est bien programmable.
Une fois cela fait nous avions pu programmer la carte mais, nous avions également réalisé la pin 2 de l'atmega328 était prise par le bouton poussoir. Or, nous avons besoin des pin 2 et 3 pour le RX et TX permettant la programmation de l'atmega à partir d'une arduino, les pistes branchement RX-TX n'ont également pas été prévus pour le téléversement des programmes sur la carte. Il nous faut alors couper une piste et souder des câbles pour utiliser toutes les pistes souhaitées.

[[Fichier: correction_proto_PCB.jpg||right|300px|PCB arduino correction]]

Durant cette semaine, nous avons également souhaité souder les CMS et le composant bluetooth nrf52810 sur la carte imprimé et reçu lors de la semaine 7. Pour cela, nous avons convenu de travailler dans la C202 durant la séance du mercredi.

[[Fichier: PCB_nrf52810.jpg||left|400px|carte electroniques imprimées]]

====Comment souder des CMS ?====

les CMS sont des composants montés en surface c'est à dire qu'ils sont montés du même côté que les pistes cuivrées (à l'opposé des composants traversants) et sont de petite tailles souvent de l'ordre du millimètre. La taille est déterminée par 4 chiffres : les 2 premiers pour la longueur et les 2 derniers pour la largeur. On a du 1206,0805,0603 ou encore 0402. Il est même possible de trouver plus petit. A l'école nous utilisons souvent du 0603, c'est le cas de nos composants.
Pour souder des CMS 0603, il nous faut utiliser une autre méthode qui n'est pas le fer à souder :
# Préparer la veille la pâte à braser la veille (dans une seringue)
# Gommer la carte pour éviter l'oxydation (attention à ne pas retirer les miettes de gomme en soufflant dessus)
# Appliquer avec la seringue la pâte sur les empreintes et piste souhaitées. Pour les endroits difficile à atteindre ou avec 2 pistes proches les unes des autres, il est possible de mettre la même goutte de pâte sur les 2 pistes. Cela de causera pas de court-circuit par la suite. En effet, la pâte est composée d’alliage qui sous la chaleur va se fluidifier et se coller uniquement aux pistes métallique. Le reste fondera sous la chaleur du four.
# Appliquer les CMS sur la pâte au fur et à mesure (attention ! ne jamais toucher les CMS avec les doigts, tjrs utiliser une pince)
# Mettre au four

====Bilan soudure nrf52810====

Cependant, une fois le matériel nécessaire préparé, et la pâte mise sur les pistes souhaitées, au moment de déposer le composant, nous avons réalisé que celui-ci était beaucoup plus petit que l'empreinte sur le PCB. Il s'agit d'un composant boitier QFN48. Fritzing ne proposant au plus proche des boitiers QFN24 ou LQFP48, celui-ci a basculé automatiquement pour un boitier LQFN48, de dimension plus grande. Face à ce manque de vigilance, nous avions cependant commencer par le nrf52810 (composant concerné) évitant ainsi de gaspiller d'autres CMS.
Nous avons souhaité refaire la carte sous Altium à partir des fichiers fournis par le concepteur (chose que nous avons commencé à faire aux alentours de la semaine 5)
Après la réalisation du schématic, et de la modification des empreintes de capacités, inductances et autres composants de 0402 à 0603. Notre matériel ne permettant que des empreintes 0603.

Lors du routage, une erreur de chevauchement des pistes est notifiée par Altium au niveau du nrf52810. Celles-ci ne présentent pas d'angles et sont déjà de taille 8mil, il nous faut alors passer les pistes en 6mil. Mais 8mil est la taille minimale pour la production à Polytech, nous avons regardé pour envoyer les cartes à faire ailleurs mais le 6mil n'est pas beaucoup conseillé. De plus, il n'est peut-être pas judicieux de continuer avec le composant microcontrôleur-bluetooth Nrf52810 qui prend du temps, donc la carte est difficilement réalisable et peut-être très long à programmer.

Ainsi en cette fin de semaine, nous avons décider face à l'avancer du projet de laisser les nrf52810 de coté et de les remplacer par des modules sans fils plus simples d'utilisation et complets. Ainsi nous aurions plus de chance d'avoir une connexion sans fils entre les modules. Nous pourrions par exemples utiliser des Xbee, des modules Rf...

==Semaine 9==

====Programmation: PS4 et 1er Test SPI sur atmega328p====

'''Raspberry Pi Zero W et PS4'''

'''Modules Atmega328p et SPI'''

Une carte PCB arduino fonctionnant, nous pouvons la programme pour simuler un module. Celle-ci a été designée afin de s'adapter au module que l'on souhaite. Il suffit de brancher le bouton, le joystick ou autre élèment de manette souhaité.
Cette semaine ci, nous avons alors configurer la partie communication SPI pour l'arduino.

'''Que voulons-nous faire avec les atmegas ?'''
Les cartes électroniques atmega328p vont nous permettre de recevoir les requêtes SPI envoyées par la raspberry pi et d'y répondre. La Raspberry enverra un message, par exemple "1", et l'Arduino lira alors l'état du module qui lui est connecté. Une fois l'état récupéré elle le renvoie à la raspberry pi.

Durant cette semaine, nous avons programmé l'atmega afin qu'il soit en esclave, qu'il reçoive un de la RPi "1" et retourne une valeur sauvegardé "int envoi". Nous avons également commencé les tests pour la lecture de l'état d'un bouton (d'après les tests réalisés les semaines précédentes).

'''Code'''
Comme nous l'avons vu précedement lors de nos recherches (semaines 1 à 4) :
La communication SPI nécessite l'utilisation des pins:

MOSI -> GPIO11 //PB3 //master OUT to the slave IN
MISO -> GPIO12 //PB4 //slave OUT to the master IN
SCLK -> GPIO13 //PB5 //serial clock
SS -> GPIO10 //PB2 //slave select

Il faut également paramétrer l'atmega328p en Slave. On note que dans un premier temps, le programme sera codé avec l'arduino IDE (fichiers .ino). Une fois l'ensemble SPI RaspberryPi-Arduino fonctionnant, on remplacera ces codes par du langage C ou C++.

Pour faire la connexion SPI sur l'atmega328p, on utilise la librairie arduino SPI.h, on a alors directement les fonctions nécessaires intervenant sur les registres souhaités : SPCR (spi control register), SPSR (spi status register) et SPDR (spi data register).

#include <SPI.h>

Il est important d'initialise d'abord le setup et on active le port série pour pourvoir utiliser le moniteur série. (Cela servira à verifier la valeur envoyée par la RPi)

void setup (void)
{
Serial.begin (9600);
pinMode(MISO, OUTPUT); //configuration en esclave *master in slave out*
pinMode(buttonPin,INPUT); //config pin bouton
// turn on SPI in slave mode
SPCR |= _BV(SPE);
// preparation interruptions
pos = 0; // buffer empty
process_it = false;
// activation interruptions
SPI.attachInterrupt();
}

On oublie pas de déclarer les interruptions afin de bien lire la requête reçue.

// SPI interrupt routine
ISR (SPI_STC_vect)
{
byte c = SPDR; // grab byte from SPI Data Register
// add to buffer if room
if (pos < sizeof buf)
{
buf [pos++] = c;
// example: newline means time to process buffer
if (c == '\n')
process_it = true;
} // end of room available
} // end of interrupt routine SPI_STC_vect

Dans la loop main, on traite la requête et on utilise '''SPI.transfer(envoi);''' pour transferer à la RPi les données souhaitées.

Durant cette semaine, nous avons également commencé des programmes de test SPI pour la RPi. Il s'agit principalement de programmes de tests tout faits permettant de vérifier la connexion entre cette dernière et l'arduino. Par exemple, la RPI envoie "bonjour" et l'arduino lui retourne ce qu'elle reçoit, soit "bonjour". Sans succés alors.

====Electronique : Fritzing révision====

Lors de la semaine, le modèle PCB de la carte arduino a été réalisé de nouveau sous fritzing avec les broches et connections manquantes. Nous avons également revu la configuration du bouton reset et ajouté une led d'état de l'alimentation. Nous avons ainsi envoyé deux cartes identiques à la réalisation.
La carte déjà soudée lors des derniers jours fonctionnant, elle nous sert de prototype de programmation. Nous pouvons ainsi avancer à la fois sur la programmation des modules mais aussi sur leur réalisation.

==Semaine 10==

====Programmation : PS4 et SPI sur RPi====

'''Raspberry Pi Zero W et PS4'''

'''Modules Raspberry PI et SPI'''

Durant cette semaine, pour la partie Atmega328p-Modules, nous nous sommes concentrés sur la programmation de la communication SPI avec la raspberry pi. Cette semaine a permis une étude plus approfondit sur le fonctionnement pour la RPi.

On rappelle, comme vu des semaines 1 à 4, pour la RPI3 (tout comme la RPi Zero W) utilise les broches : SCLK (23), MISO(21), MOSI (19) et SPI CS0 (24), SPI CS1 (26).
On la programme en Master. A l'aide des fichiers tests d'inspiration, on pourra directement programmer la RPi en C. Lors de la réalisation du code, il y a 3 étapes : l'initialisation/parametrage en SPI pour être maître, l'envoie de la requête puis la réception de données en retour.

Programmant en C, il ne faut pas oublier les librairies suivantes :

#include <stdint.h>
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
#include <getopt.h>
#include <fcntl.h>
#include <sys/ioctl.h>
#include <linux/types.h>
#include <linux/spi/spidev.h> //pour SPI

On va déclarer des variables globales permettant le paramétrage :

static const char *device = "/dev/spidev0.0"; //si on veut CS0 pour atteindre notre SS
static uint8_t mode; //mode est par défaut à 0
static uint8_t bits = 8; //bits par mot échangé
static uint32_t speed = 500000;
static uint16_t delay;

Dans notre main, on ouvre le port (la connexion) au device souhaité, on vérifie les paramètres (registres, connexions...) puis exécute la fonction transfer(fd). transfer(fd) transmet la requête et s'occupe de la réception.

fd = open(device, O_RDWR);
transfer(fd);
close(fd);

==Semaine 11==

====Programmation: PS4, SSH et tests SPI (RPi3&Atemga328p)====

'''Raspberry Pi Zero W et PS4'''

'''Raspberry PI, Atmega328p et SPI'''

Afin de facilité la programmation en utilisant Ethernet, nous avons installer et configuré la RPi pour l'utiliser en SSH depuis les ordinateurs de la E306. En effet, SSH permet de se connecter à distance sur une machine en utilisant un compte utilisateur de la dite machine. En mettant ssh, on pourra directement agir sur les fichiers de la raspberry depuis un terminal de notre PC. Pour cela, on a d'abord vérifier l'adresse IP de notre raspberry pi : 172.26.145.106 avec un écran mais on peut aussi utiliser les commandes ip a et ifconfig. Puis activer le ssh sur la raspberry pi.
On modifie alors le fichier config.txt mais également etc/network/interfaces pour configurer la bonne interface Ethernet sur la raspberry pi.

[[Fichier: configSSH_raspi.png||left|300px|config ssh ethernet]]

Il nous suffit alors de taper la commande : ssh pi@172.26.145.106 pour accéder à notre RPi.

Nous avons continué à réaliser la communication SPI avec des tests entre une arduino UNO et la RPI3. Nous avons commencé par des tests simples inspirés des études de deux semaines précédentes et modulés selon notre utilité.
Nous arrivons alors à lire l'état envoyer "bonjour" et recevoir "ça va" ou encore "1" et recevoir "3". Il faut noter que le SPI échange des trames, la RPI reçoit alors des hexadécimaux.
Nous avons alors continué pour recevoir l'état du bouton ou du joystick lors de l'envoie de "1" sur l'Arduino328p. La semaine prochaine nous testerons ces même codes fonctionnels sur les cartes atmeg327p.

A la fin de cette semaine, nous avons alors des codes Arduino-SPI (.ino) et des codes Raspberry-SPI (.c) permettant l'échange de données. Le but est maintenant de l'adapter aux cartes imprimées et de le rendre pleinement fonctionnel pour plusieurs cartes à la fois, puis ajouter une boucle de vérification en continue jusqu'à une deuxième requête de la RPi.

====Electronique: réalisation au propres des PCB modules====

Suite à une nouvelle erreur de réalisation cartes électronique, nous avons refait et renvoyé à nouveau les cartes imprimées atmega328p.
Nous les souhaitons au propre pour une version finale. Une fois celle-ci imprimées nous pourrons en avoir 3 , un pour chaque module. Les cartes étaient bien imprimées en bottom mais lors du passage des traversants de bottom à top, le logiciel ne les a pas fait miroiter. Par manque d'attention nous avons alors envoyé les fichiers gerber pour des cartes ayant les composants du même coté que la couche de cuivre.
Les cartes électroniques actuelles sont alors correctes et fonctionnelles mais difficile à souder. Pour eviter les erreurs et continuer sur des prototypes de carte nous préférons attendre en nous concentrant sur la programmation PSI de la Raspberry Pi.

==Semaine 12==

====Programmation====

'''Raspberry Pi Zero W et PS4'''

'''Raspberry PI, Atmega328p et SPI'''

- réflexion: penser à faire boucler sur l'arduino une fois la requête reçu, ça veut dire que la manette est ON et donc vérifier continuellement les modules sur chaque atmega.
- SPI raspberry pi - arduino recuperation état du bouton avec les cartes modules (/!\ récuperation à faire dans une variable)

-SSH perso
adresse Rasppi: 192.168.137.10

====Electronique: Finalisation soudure Modules====

Soudure au propre et finale d'une carte atmega328p et donc envoie pour la réalisation de 2 autres cartes similaires et récupération de matériel
Soudure des 2 autres cartes, + tests sur les états = fonctionnelles.
On a donc bien 3 cartes pour les 3 modules de types différents (1 bouton, 1 joystick, 1 gachette)
PCB pour les 2 joysticks (qui serviront de thumbstick et gachette)

==Semaine 13 et plus==

====Programmation====

'''Raspberry Pi Zero W et PS4'''

'''Modules Atmega328p et SPI'''

====Electronique====

=Documents Rendus=

(à mettre rapport + git + drive)

=Datasheets=

IMA4 2017/2018 P35

2018-05-05T18:32:04Z

Tgracias : /* Semaine 3 : Début premier prototype */

__TOC__
 

=Présentation générale: Manette modulable=

==Description==

Tout le monde joue aux jeux vidéo cependant, les manettes ne sont pas adaptées aux personnes ayant un handicap pouvant toucher les bras ou les mains.
C’est le cas, de plusieurs patients dans les centres de soins et de rééducation.

Pour ce projet IMA4, nous travaillerons avec le centre SSR (soin de suite et de réadaptation) Marc Sautelet de Villeneuve d’Ascq.
Un adolescent, patient de Marc Sautelet, est passionné par les jeux vidéo. En effet, ayant perdu la motricité d’une partie de son corps, il ne peut pas jouer à deux mains. Pour cela, il bloque la manette entre son épaule et son coude, usant de la mâchoire et des doigts pour contrôler les
joysticks et les boutons. Cet exercice peut s’avérer fatiguant et pénible.

Ainsi, nous chercherons à concevoir une manette PS4 adaptée au handicap de l’adolescent.
Cette manette devra aussi être adaptée pour d’autres patients présentant également des handicaps moteurs. Ainsi nous prendrons pour cibles: tous les patients du centre voulant jouer; et non pas que les enfants et adolescents.

 

{| class="wikitable centre" width="80%"
|+
|-
| width="23%" |
Membre du projet
| width="34%" |
Transley Gracias et Camille Saad
|-
| width="23%" |
Cible
| width="34%" |
Patient présentant un handicap moteur
|-
|width="23%" |
Période du projet
| width="34%" |
janvier 2018 - mai 2018
|-
|width="23%" |
Partenaire/Client
| width="34%" |
Centre SSR Marc Sautelet à Villeneuve d'Ascq
|}

==Objectifs==

Ce projet a pour objectif de créer un prototype de manette qui puisse interagir avec la console PS4 et dont le paramétrage se fait à l’aide d’une application mobile et/ou web. Cette manette devra suivre les demandes du patient ainsi que des aides-soignantes du centre, dans la mesure du possible.

Plus précisément, pour le premier prototype, nous mettrons en œuvre l'utilisation de quelques boutons spécifiques:

* Un joystick (type L/R)
* Quelques boutons poussoirs (type Croix/Triangle/Carré/Rond/R1/L1/Start/...)
* Des boutons gâchettes progressives (type L2/R2).

Le but serait donc dans un premier temps de rendre fonctionnel un bouton de chaque type, puis de les multiplier une fois cela fait. Tous ces boutons réunis constituent une manette fonctionnelle.Ainsi, la manette sera ajustable, c’est à dire qu’elle devra s’adapter aux différents handicaps moteurs possibles.

=Analyse du projet=

==Positionnement par rapport à l'existant==

Notre prototype aura une présentation unique par rapport à l’existant. En effet, les concurrents et produits existants ciblent pour la majorité un seul handicap. Cela
engendre une solution fermée à beaucoup de patients. Notre projet propose une mobilité des mouvements et également un choix large dans la composition et le
design de notre manette.
Le patient n’est pas retreint à jouer à une seule main, à utiliser beaucoup de force...Il y a moins de technique dans la manipulation et on ne joue pas avec une
manette adaptée uniquement pour un droitier ou un gaucher. Cependant, cela nous limitera peut-être dans le choix possible des types de jeux. Tout comme les autres
manettes adapté, l’utilisateur nécessitera un peu d’entrainement.

==Analyse du premier concurrent==

Jouer aux jeux vidéo à une main n’est pas une idée d’aujourd’hui. En 1990, Nintendo propose le Power Glove. Mais il tombe très rapidement aux oubliettes suite à des problèmes techniques.

Un autre gant a fait son apparition quelques années plus tard. Celui-ci, plus technique, il faut office de manette Play Station: le Reality Quest Power Glove.Cette idée de manette-gant, permet de jouer à la PS avec une seule main, elle a était conçue et présentée pour les E3, un salon d’exposition de gaming.Le gant est conçu pour contrôler l’équivalent des 14 boutons et 2 joysticks à l’aide d’une seule main. La « manette » est fixée dans la pomme de la main. L’utilisateur contrôle les mouvements verticaux et horizontaux en pivotant le poignet, et utilisent les 4 boutons d’action principaux et L1/R1 avec les doigts. Les autres boutons sont accessibles par un seul bouton rond contrôlé par le pouce.
La manette est adaptée pour beaucoup de jeux vidéo, dont les plus simples sont les jeux de voitures et de combats (arcade).

; Problèmes:
*Besoin de toute la motricité de la main, c’est-à-dire que si le patient à un doigt paralysé ou manquant, il ne pourra pas jouer avec ce gant
*Design obligatoirement droitier
*Les boutons de contrôle sont peu sensibles et peuvent nécessiter de la force
*Design compliqué et nécessitant beaucoup d’entrainement.

;Lien : https://www.youtube.com/watch?v=qV0SxSJDCYg

 
==Analyse du second concurrent==

Ben Heck, de son vrai nom Benjamin J.Heckendorn, est un concepteur de mods de consoles (mods pour modification, soit « manettes modifiées ») et une star
du net grâce à ses vidéos tutoriels.Il propose alors énormément de produits adaptés ou dérivés en guise de manettes.
Parmi les mods qu’il a réalisé, il a modifié une manette de PS4 afin de la rendre accessible à une personne ne pouvant jouer qu’à une main. Pour cela, il a déplacé les boutons en respectant l’ergonomie de la main valide et modifie les connexions. Il peut lui arriver de rajouter des boutons pour en remplacer un autre. Il réalise également le même système avec la Xbox. Sur la photo ci-dessous, il a adapté la manette pour un droitier.

; Problèmes:
*Besoin de toute la motricité de la main, c’est-à-dire que si le patient à un doigt paralysé ou manquant, il ne pourra pas jouer avec cette ma
*Design obligatoirement droitier ou gaucher, une modification = une manette= une personne
*Besoin obligé du pouce et de l’index, même si avantage : 3 doigts nécessaire.

;Lien :: https://www.youtube.com/watch?v=LieHIscadjk

==Scénario d'usage du produit ou du concept envisagé==

La technologie est ,aujourd’hui, omniprésente dans notre vie. Les consoles de jeux ont envahies les maisons avec plus de 7 personnes sur 10 jouant aux jeux vidéos sur consoles en France (chiffre de l’Express). 0,18% des français sont handicapés cela représente 12 millions de français. Dans ce chiffre, 13,4% des personnes ont un handicap moteur. En 2017, les grands groupes comme Sony ou Microsoft avec respectivement PlayStation et Xbox ne permettent pas à tout le monde de jouer avec une manette. Les manettes sont prévues pour des personnes ayant leurs membres valides, plus précisément les mains et les bras.

Après un accident de voiture, un jeune garçon a perdu la motricité d’un côté du corps. Passionné de jeux vidéo, il se retrouve avec des difficultés à jouer sur sa console PS4. Ingénieux, il utilise la manette en la coinçant entre son épaule et le creux du cou. Usant de la mâchoire et de sa main valide pour contrôler les joysticks et les boutons. L'exercice étant inconfortable et fatiguant il eu l’idée de proposer à des futurs ingénieurs de lui proposer une manette adaptée à son handicap.

Les deux pré-ingénieurs ,avec leur tuteur, ont une idée révolutionnaire : La manette modulable ! Elle permettrait au jeune garçon, ainsi que d’autres joueurs, de pouvoir continuer de s’amuser ou même de commencer à jouer au jeux sur console.
Cette manette aidera fortement dans les centre de rééducation pour faire passer le temps et donner du plaisir à des personnes qui ne peuvent plus s’amuser avec leur console traditionnelle. Elle pourra aussi ouvrir de nouvelles possibilités pour certaines personnes qui n’auraient jamais essayé jusqu'à présent.
Comme son nom l'indique, elle sera modulaire et s'adaptera à différents handicaps. Accompagnée de son application d’initialisation, elle sera accessible aussi bien aux enfants, patients, parents et aides soignantes.

Quelques mois plus tard...Le jeune patient fan de Need For Speed, peut maintenant piloter sa voiture comme un vrai professionnel grâce à l'un des joysticks qu'il utilisera avec sa main valide et il pourra accélérer à des vitesses folles à l'aide de boutons poussoirs au niveau de son pied valide et gagner la partie. Son ami venu lui rendre visite, pourra en lieu et place des aides soignantes configurer à l'aide de la tablette (portable) la manette du patient.
Si le patient change de jeu pour Tekken et que la configuration des modules ne lui convient plus, il peut interchanger les éléments de la manette selon son envie et son confort. Ainsi il peut faire sauter son personnage, il utilisera un module bouton supplémentaire, qu'il actionnera avec le poing.

==Fonctionnement==

Suite à une analyse fonctionnelle et à la formulation de notre projet, nous avons pu définir le fonctionnement de notre système. Notre produit, la manette, doit être accessible d’après nos objectifs à différents types de handicaps moteurs. Ainsi, l’idéal serait de concevoir une manette modulable afin qu’elle puisse s’adapter à toutes les situations. Ce n’est plus au patient de s’adapter à la manette mais à la manette de s’adapter au patient.
Cela signifie que la manette sera, dans la limite du possible et de la sensibilité du corps du patient, composée de plusieurs parties dites « modules » comportant un ou plusieurs actionneurs (boutons, joysticks, gâchettes...). Ces modules seront déplaçables afin d’être utilisé avec différents membres du corps : un doigt, une main,
une jambe ou même un pied. Il suffira de les connectés entre eux suivant l’organisation souhaitée, le Gameplay du jeu ou en fonction du handicap. Le tout sera relié à une application.
L’application sera alors mise en place pour connecter les différentes parties du point de vue software pour prérégler la manette en fonction du patient. Il pourra alors choisir les boutons en fonction du jeu, de ses mouvements mais aussi choisir la sensibilité.

L’application et les modules devront être intuitifs et faciles d’utilisation. De cette manière des utilisateurs non avertis dans le domaine informatique ou jeunes pourront eux-mêmes gérer les connexions.

==Réponse à la question difficile==

'''Question : Comment interconnecter les différents modules de la manette ?'''

Il nous faut pour ce projet interconnecter les modules modélisant la manette qui seront connectés à la consoles PS4 via une Raspberry Pi 3.
Le choix de la Raspberry Pi 3 nous permet d'utiliser son module Bluetooth pour communiquer avec la PS4, ce choix est plus adaptée au projet que du filaire.
Concernant l'interconnexion des modules, nous travaillerons en deux étapes "preuves concept" : filaire et sans fils (Bluetooth).

'''Objectif 1 : Preuve concept filaire'''

Dans cette première partie de projet, nous souhaitons avoir une 1ère preuve de prototype rapidement. Nous nous concentrerons alors sur la communication entre la RPi3 et la PS4 ainsi que sur la conception des modules. Pour les modules, nous réaliserons des cartes électronique pour chaque module avec un micro-contrôleur. La communication filaire nous permettra d'interconnecter les modules à la RPi3 avec un bus SPI.

'''Objectif 2: preuve concept sans fils'''

Une deuxième étape du projet est la réalisation de la solution idéale sans fils. Celle-ci pourra commencer à être développée petit à petit en parallèle avec l'objectif 1. Le but ici, est d'interconnecter les modules en Bluetooth. Nous avons choisi le Bluetooth pour garder une connexion commune sur toute la chaîne.
Nous rajouterons alors un module bluetooth à chaque module de la manette.

'''Objectif 3: possibilité d'adapter les boutons (capuchon en 3D)'''

=Préparation du projet=

==Cahier des charges==

''Chef de projet:'' Alexandre Boé 
''Responsables:'' Xavier Redon, Thomas Vantroys 
''Partenariat:'' Marc Sautelet (non etablie) 
''Elèves-ingénieurs:'' Camille Saâd, Transley Gracias 

'''Sujet :''' Manette modulable pour personne à déficience moteur compatible PlayStation 4 

===Objectifs principal (1er POC) : ===
Faire transmettre des informations issus des actionneurs (ex:boutons poussoires) via des arduinos jusqu’à la Raspberry Pi 3 en SPI. 
Envoyer les données reçues vers la PS4 en USB 

===Objectifs secondaire (2e POC):===
Créer des modules avec un microcontrôleur et une puce bluetooth pour permettre une meilleurs flexibilité (c-àd pouvoirs avoir une meilleure ergonomie et une connexion sans fil) 
Connecter la Raspberry Pi 3 en Bluetooth à la PS4 

[[Fichier: beteacorne.jpg||middle|600px|Bete a corne manette]]

==Choix techniques : matériel et logiciel==

===Liste de matériel :===

'''Modules boutons/joysticks/gachettes'''

3 Push buttons : 
- O X Y Carré R3 L3 
- Guide PS 
- start/back 
--> 0,45€/unité TTC [https://www.gotronic.fr/art-bp-miniature-krs1273-16976.htm] 

1 Thumbstick original: 
Joystick analogique 4 directions --> 4,25€/unité TTC [https://www.gotronic.fr/art-joystick-analogique-4-directions-19063.htm] 

1 buttons trigger L1 L2 => 1x Thumbstick original''' 

'''Cartes Atmega328p /connexion spi/'''

3 Arduino UNO 
1 Arduino UNO atmega328p retirable 
4 capacite 22pF traversantes 
2 resistances 10 kOhm traversantes (à récupérer) 
2 oscillateurs quartz 16MHz traversante 
2 atmega328p-pu et support 

'''Cartes module bluetooth nrf52810 '''

6 capacités 100nF 0603 
6 capacités 12pF 0603 
2 capacités 4,7pF 0603 
2 capacités 1µF 0603 
2 capacités 100pF=0,1nF 0603 (à récupérer) 
2 capacités 0,8pF 0603 (a acheter, commande en cours) 
2 inductance 3,9nH 0603 (a acheter, commande en cours) 
2 oscillateur quartz 32 MHz 

''' Connexions et autres '''

1 Led RGB neopixel [https://www.adafruit.com/product/1734] 
1 Raspberry Pi 3 
--> ~36,23€/unité TTC [https://fr.rs-online.com/web/p/processor-microcontroller-development-kits/8968660/?src=raspberrypi] 
1 Raspberry Pi Zero W (commandée) [https://www.raspberrypi.org/products/raspberry-pi-zero-w/] 
6 Alimentations 5V ou 3,3V 
par exemple, 12 piles de type CR2016 3V rechargeables ou 24 piles AAA 1,5 V rechargeables
5 modules Bluetooth nrf de Nordic : nRF52810-QFAA-R 
--> 3,17€/unité + frais expédition [https://www.mouser.fr/productdetail/nordic-semiconductor/nrf52810-qfaa-r?qs=sGAEpiMZZMve4%2FbfQkoj%252bG%2FosjLoe2oghFQwQllMrQ4%3D]
5 Lignes broches mâles 

===Logiciels:===

- IDE arduino
- Altium
- FreeCAD ou Inkscape

==Liste des tâches à effectuer==

'''Etape 1 : Gestion du projet'''

* Définition des cahiers des charges fonctionnel et technique, choix d'orientation...
* Recherche techniques sur les différentes connexions possibles entre les modules, la RPi 3 et la console PS4
#Recherche connexion SPI entre les modules et la RPi3
# Recherche connexion bluetooth entre la RPi3 et la PS4
# Recherche connexion bluetooth pour les modules
# Recherche carte avec montage Atmega328P-PU et anticipation module bluetooth
* Détermination du matériel nécessaire
* Réflexion sur l'application

'''Etape 2: Réalisation du projet'''

'''Partie 1: Preuve concept manette en filaire'''

* Conception de cartes électroniques pour 2 modules (/!\ prévoir modules bluetooth)
* Réalisation connexion SPI avec 2 modules : programmation des Atmega328p en liaison série.
* Si tests concluant, ajouter des modules jusqu'à en avoir 5 (1 pour chaque type de boutons)
* Connexion bluetooth entre la PS4 et la RPi3
* Réalisation du support des modules avec fixations possibles (imprimante 3D)

'''Partie 2: Preuve concept manette en bluetooth'''

* Ajout des modules bluetooth aux cartes électroniques
* Connexion bluetooth entre les modules

'''Partie 3: Application Android : paramétrage de la manette'''

* Créer une application sur tablette ou smartphone (Android) afin de configurer la manette aux besoins (inter-connexion des modules et console)

==Calendrier prévisionnel==

{| class="wikitable centre" width="80%"
|+
|-
| width="23%" |
'''Date'''
| width="34%" |
'''Tache à réaliser''' 
|-
| width="23%" |
17/01/18-24/01/18
| width="34%" |
Faire des recherches sur les différentes interconnexions du système : Bluetooth, RPi-Atmega328 (SPI), RPi-PS4
Continuer liste des taches, matériel, Début recherches + réflexion fixation support des modules
|-
|width="23%" |
31/01/18
| width="34%" |
Recherche technique connexion PS4-RPi3 et connexion SPI RPi3-Module + code
|-
|width="23%" |
31/01/18-07/03/18
| width="34%" |
Réalisation 1er prototype (+ début prototype 2)
|-
|width="23%" |
07/03/18
| width="34%" |
Seance 7 : Test prototype filaire
|-
|width="23%" |
07/03/18-09/05/18
| width="34%" |
Réalisation 2eme prototype + application Android
|-
|width="23%" |
09/05/18
| width="34%" |
Seance 14 : Test prototype Bluetooth
|-
|width="23%" |
14/05/18
| width="34%" |
Video projet
|-
|width="23%" |
15/05/18
| width="34%" |
Finalisation projet et Rapport
|-
|width="23%" |
16/05/18-17/05/18
| width="34%" |
Soutenances Projet
|}

=Réalisation du Projet=

==Feuille d'heures ==

Voici le tableau d'heures du binôme:

{| 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 S11 !! Heures S12 !! Heures S13et+ !! Total
|-
| Analyse du projet
| 10
| 2
| 1
| 1
| 1
|
|
|
|
|
|
|
| 20min
|
| 15h20
|-
| Cherches techniques
|
| 3
| 4
| 4
| 2
| 2
| 1
|
|
|
| 1
| 1
|
|
| 18
|-
| Rédaction du wiki et rapport de projet
|
| 1
| 1
| 1
| 1
| 30min
| 1
|
| 2
| 30min
| 30min
|
| 2
|
| 10h30
|-
| Programmation
|
|
|
|
| 3
| 2
| 3
| 5
| 4
| 7
| 8
| 6
| 5
|
| 43
|-
| Cartes électroniques
|
|
|
|
|
| 6
| 8
| 4
| 6
| 2
| 1
| 2
| 2
|
| 31
|-
| Application
|
|
|
|
|
|
|
|
|
|
|
|
|-
|-
| Total Semaine
| 10
| 6
| 6
| 6
| 7
| 10h30
| 13
| 9
| 12
| 9h30
| 10h30
| 9
| 9h20
|
| '''117h50'''
|}

==Prologue==

Avant la réalisation et conception d'un projet, il est important d'analyser celui-ci. Nous avons allons consacré le prologue à l'analyse fonctionnelle de la manette. Nous avons également eu une réflexion sur l'analyse technique, cela nous a permis de réaliser une liste de matériel. Il est important de définir les objectifs ainsi que les besoins afin de ne rien oublier. (Voir ci-dessus Analyse projet)
Nous avons également organisé notre travail, pour le partage de documents de recherches et la rédaction de compte-rendu final nous avons réalisé un google drive. Par la suite, nous créerons un projet Git.

Durant ce temps, nous avons décidé de réaliser 5 modules. Les modules sont les différents boutons de la manettes qui nous pourrons placer selon nos choix (boutons modulaires) pour notre prototype projet pour chaque type des boutons d'une manette PS4. Ces modules devrons être connectés à la console et interconnectés. Le tout sera lié à une application Android. Suite à quelques recherches et nos analyses, nous avons décidé les points suivants :

- On commencera avec 2 modules et on les multipliera par la suite.
- Les premiers tests sont réalisés avec des boutons petits pour assurer leur caractéristique "modulaires", par la suite nous pourrons ajouter des capuchons de taille plus importante (imprimante 3D ou achat)
- Conception modules : réalisation de carte avec un microcontrôleur atmega328 programmable pour chaque module (anticiper le module Bluetooth)
- Projet en 2 parties : prototype filaire et prototype Bluetooth
# Prototype filaire : connexions entre les modules et la RPi3 en SPI, connexion Rpi3-PS4 en Bluetooth, avec l'application en filaire à la RPi3
# Prototype Bluetooth: connexion Bluetooth entre modules-RPi3-PS4-apllication

[[Fichier: structuremanette.png||center|400px|Concept manette modulable]]

==Semaine 1==

Durant la séance, nous nous sommes concentrés les recherches afin de définir clairement le cahier des charges technique. Il s'agit des réalisations à mettre en œuvre pour les inter-connexions des éléments de la manette.
Ainsi, nous avons fait des recherches sur :

===Connexion SPI entre les modules (Atmega328p) et la RPi3===

SPI: Serial périphérique interface BUS

[[Fichier: yWGmW.png||right|200px|Concept manette modulable]]
Comme indiqué sur l'image ci-dessus, la Raspberry pi 3 peut communiquer en SPI avec ses broches CS0 (24), CS1 (26), SCLK (23), MISO (21), MOSI (19). Celles-ci permettent de communiquer avec un ou plusieurs esclaves (dans notre cas, des Atmega328p) en reliant directement les broches concernées de la RPi3 à celles des composants esclaves.
Chaque broche CS0 (24) ou CS1 (26) ne peut être connectée qu'à l'entrée SS (aussi appelé CS) d'un seul esclave.
C'est a dire que chaque CS est lié à un esclave afin de choisir avec lequel la communication est établie à un moment donné, et les MISO sont reliées entre elles en cascade, de même pour les SCLK et les MOSI. On peut noter que le maître impose la fréquence d’horloge et sélectionne l’esclave auquel les données sont envoyées. 8 MHz est le plus rapide supportable a 3,3V

[[Fichier: fonctionnementSPI.png||right|200px|Connexion SPI multi-esclaves]]

Voici un schéma du fonctionnement souhaité :

Comme nous souhaitons avoir 5 modules environ il nous faudra rajouter un composant en plus afin d'augmenter les possibilités de sélection, par exemple des démultiplexeurs.
Dans un premier temps nous essaierons avec 2 esclaves, puis on augmentera le nombre.

===Connexion Bluetooth PS4-RPi3===

Les recherches portent également sur la connexion entre la manette PS4 et la console. Elles concernent le protocole de communication via Bluetooth

Caracteristique pour la PS4: Bluetooth®v4.0, Qualcomm Atheros AR3002 Buetooth LE: 2,4-2,5 GHz 

Caracteristique de la connexion : 

*Vitesse de transmission >> 3 Mbit/s 8N1
*Relevé tous les 1.3 millisecond (peut-être)
*Chaque manette à une adresse unique BD_ADDR qui correspond à l’adresse MAC de la carte Réseau
*Protocole de détection est le SDP basé sur une emission reception PDU
*L’Attribut ID est representer en TLV Type Length Value
*Communication HCI ACL Data Packet

===Rélisation des cartes électroniques===

matériel nécessaire pour un PCB : 

*breadboard
*câbles
*1 x 10k Ohm résistance
*Quartz 16Mhz clock crystal
*2 x 22 pF capaciteurs
*Atmega328P-PU

Ressources:
[[https://www.arduino.cc/en/Main/Standalone]]
[[http://www.eprojectszone.com/atmega-328-pu-standalone/]]
[[https://www.arduino.cc/en/Tutorial/ArduinoToBreadboard]]

==Semaine 2==

Durant la semaine deux et durant la séance, nous avons continué et approfondie nos recherches sur le projet. Nous avons pu ainsi affiner nos taches de réalisation et donc notre cahier des charges.

===Connexion aux modules: SPI et Bluetooth ===

 CORRIGER

voir https://peip-ima.plil.fr/mediawiki/index.php/BE_2017-2018#Configuration_du_syst.C3.A8me_embarqu.C3.A9

(sudo apt-get install pi-bluetooth)

''connexion sur la raspberry par ssh:''
su
update-rc.d ssh enable
invoke-rc.d ssh start
ssh pi@172.26.79.1XX

''bluetooth''
bluetoothctl
agent on
default-agent
scan on
pair [device Bluetooth address] (exemple: pair XX:XX:XX:XX:XX:XX )

''NOUVELLE REFLEXION : Connexion SPI entre les modules (Atmega328p) et la RPi3 --> MODULES BLUETOOTH''

Si multi-esclaves= plusieurs modules :
Il faut ajouter des sélections pour les SPI → démultiplexeurs OU ne pas utiliser les CS0 et CS1, et plutôt des pins entrée/sortie de la RPi3 lié au SS comme ça on choisit direct le module esclave voulu.

'''IMPORTANT:''' Nous avons étudié à nouveau la datasheet de notre module bluetooth nrf de Nordik. Le module bluetooth comporte déjà un microprocesseur !
Un module plutôt peut donc jouer le rôle de notre atmega328p. Il n'y a alors pas besoin de réaliser des cartes électroniques de type arduino standalone. Nos PCB regrouperont alors uniquement l'alimentation, un actionneur (bouton, joystick), le module bluetooth et les broches de connexion si besoin...

Cette séance nous a alors permise de revoir entièrement le matériel nécessaire. Notre liste de matériel nous semble alors plus réfléchie et limitée au nécessaire.

===Connexion Bluetooth PS4-RPi3===

Suite à nos recherches de la semaine précédente, nous avons sélectionné deux sites bien renseignés :

SITES

Ils nous ont permis de comprendre la communication entre la manette et la console. En effet, ils nous expliquent les échanges de trames Bluetooth.
EXPLICATIONS 1 exemple 

==Semaine 3 : Début premier prototype==

===Connexion SPI RPi3-Arduino===

Comme vu durant les semaines précédentes, nous souhaitons réaliser une connexion Multi-esclaves en SPI entre la Raspberry pi et plusieurs modules.
Cette semaine nous avons vu que la réalisation de notre premier prototype doit aller vite. Il ne nous est pas nécessaire d’attendre les modules bluetooth si il nous faut dans cette partie uniquement utiliser son microprocesseur. Ainsi pour chaque module nous utilisons une arduino UNO. Nous réaliserons les programmes en C afin de pouvoir les réutiliser avec les modules bluetooth par la suite.
Une fois la connexion réalisable nous adapterons les programmes aux modules bluetooth Nordik. En effet, ceux-ci comporte déjà un microprocesseur, le module peut jouer le rôle de notre atmega328p. Il n'y a aurait alors pas besoin de réaliser des cartes électroniques arduino standalone sur PCB, mais directement des cartes électronique avec le module et le module voulu (bouton, joystick...) et l'alimentation.
Durant la séance nous avons alors revu la liste de matériel nécessaire.

[[Fichier: prototype1.jpeg||center|600px|connexion filaire prototype 1 filaire arduino]]

Durant la séance, nous avons recherches des exemples de codes et de librairies pour Arduino SPI et RaspberryPI SPI.

Nous avons également commencé le programme de la connexion SPI pour l'arduino et récupéré les bibliothéques SPI.h avec SPI.c. Nous nous sommes alors concentrer à les comprendre, pour pouvoir l'utiliser.

===Réalisation du projet Git===

Création du projet IMA4_Projet35_ManetteModulable sur Git et partage de celui-ci.
Les premiers dossier crées cette la séance :
-Arduino (connexion SPI arduino) : ProtoSpi.c + dossier librairie SPI + Makefile
-RPI (dossier codes pour Rpi)
-Readme.md
Ces dossiers seront amenés à être modifiés au cours des séances.

===Protocole Bluetooth PS4===

Suite à l'étude des trames Bluetooth, on a pu voir que ces dernières étaient incomplètes. Le modèle de communication étant propriétaire, on n'y a pas accès directement. Cela nous empêche donc de mettre en oeuvre cette communication.
 Déveloper

On a décidé de commencer par une connexion USB (pour laquelle on dispose de toutes les informations) celle-ci étant plus complète.

==Semaine 4==

Pour le prototype 1 FILAIRE nous réaliserons les étapes suivantes :

#Réalisation du programme SPI pour arduino
#Réalisation du programme SPI pour la RPi
#Connexion USB avec la PS4 ou ordinateur
#Réalisation de cartes électroniques atmega328p-pu standalone (remplacer les Arduinos)
#Remplacer les "PCB arduino" par le module bluetooth et adapter la connexion
#Conception 3D de la délimitation 1 axe pour le joystick "gâchette"
#Réalisation de l'application Androïde.

Une fois ces étapes réalisées nous auront alors une preuve de concept filaire et nous pourrons alors passer à une connexion bluetooth.
Le passage à la connexion bluetooth sera le deuxième prototype et le cas idéal de la réalisation de la manette modulable.

===Mise à jour Matériel===

- Modéliser les boutons gâchettes L1/2 R1/2 de la manette PS4 (boutons sensibles à la pression) --> un joystick dont nous bloquerons un axe (imprimante 3D)
- Remplacer la RPi 3 par une Rpi zero W qui nous permettrait de réaliser plus facilement une connexion USB tout en gardant l'avantage du bluetooth.
- Choix de l’alimentation pour les 5 modules Bluetooth: nécessitent 3V --> utiliser des piles rechargeables 1,2V AAA plutôt que piles rondes 3V.

Nous avons également besoin du matériel cité en semaine 1 pour réaliser des cartes électroniques atmega328p-pu standalone. ( nous revenons alors sur les décisions de la semaine 3)

===Connexion SPI RPi3-Arduino===

Montage Raspberrypi et 1 arduino en PSI + 1 bouton + 1 led.
Voici le choix des branchements :

MASTER = RPi
SLAVE= Arduino

'''SPI sur Arduino:'''
MOSI -> GPIO11 //PB3 //master OUT to the slave IN
MISO -> GPIO12 //PB4 //slave OUT to the master IN
SCLK -> GPIO13 //PB5 //serial clock
SS -> GPIO10 //PB2 //slave select
'''Led, bouton et autre...'''
LED --> GPIO6 //PD6
GND
+5V (if required)
'''SPI sur la Raspberry Pi'''
SPIO MOSI -> PIN19
SPIO MISO -> PIN21
SCLK -> PIN23
SPIO CS0 -> PIN24

Continuation du code pour faire clignoter Led branchée à une arduino depuis la Rpi, en connexion SPI.

===Connexion USB PS4-RPi3===

Durant la séance, nous avons regardé comment utiliser le port série sur la RPi3, soit utiliser les UART.

Nous avons réaliser qu'il n'était pas aussi simple d'utiliser le port serie USB de la Raspberry Pi 3, en effet le SoC est un BCM2837 .
De plus nous ne pouvons pas utiliser le même port pour l'alimentation et la connexion.

Une des solutions à cette difficulté serait d'utiliser une RPi ZERO W à défaut d'une RPi 3. On pourrait alors avoir un port d'alimentation avec connexion USB mais également retrouver la connexion bluetooth dont nous avons besoin.

==Semaine 5==

===Programmation: Réflexion définitives prototypes filaire ===

Durant la semaine 5, nous avons continué la réalisation du prototype filaire par l'avancé du code SPI ainsi que les recherches concernant le protocole PS4.

Pour réaliser la connexion entre la PS4 et les différents modules, nous avons vu la semaine dernière que nous utiliserons une RPi zero W (que nous avons commandé). Celle-ci nous permet d'utiliser le bluetooth mais elle nous permet également de réaliser un réseau local sans fil. Ce qui peut être pratique dans la mesure où notre projet est modulable.
En attendant la réception de la commande, nous nous sommes penché sur les programmes et la configuration nécessaire à l'utilisation de la RPi zero W.

===Electronique===

[[Fichier: bouton_c1.jpg|100px|thumb|left|PCB bouton]]
[[Fichier: arduinobb.jpg|200px|thumb|right|atmega328p-pu branchement test]]

Du coté électronique, nous avons réalisé sur fritzing certaines cartes électroniques. Les Arduino Uno servant actuellement de test, seront remplacées par des PCB atmega328p-pu standalone avec des broches permettant les branchements nécessaires SPI ou encore aux modules "boutons/joystick". Pour les boutons, nous avons également réalisé un pcb afin de faciliter les branchements.

Il nous faut alors également une 3eme carte qui nous sera nécessaire pour la réalisation du prototype sans fil. Dans notre liste de matériel, nous avons des composants nrf52810 bluetooth, ceci doivent être soudé avec les capacités de protection mais également des broches de communication. Nous avons alors commencé cette carte électronique sur Altium avec le fichier projet PCB du distributeur à modifier.

[[Fichier: Arduino_c1.jpg|100px|thumb|center|PCB atmega328p-pu]]

=== Construction 3D ===

Enfin, nous avons commencé à réaliser des boîtiers 3D pour certains modules. Par exemple, comme nous l'avions vu précédemment, un des joysticks servira de bouton-gâchette en utilisant un seul de ses axes. Il nous faut alors réaliser un boitier qui bloque l'un des axes, mais également une tige qui nous permettra de pousser le joystick de manière simplifiée.

==Semaine 6==

===Programmation: configuration RPi Zero W ===

Ayant reçu la Raspberry Pi zero W en début de semaine, nous nous sommes concentrés sur la programmation et la configuration de celle-ci.

===Electronique: PCB nrf52810===

Les cartes réalisées en semaine 5 sont validées et en attente de réalisation.

Cette semaine a permis la réalisation et la finalisation de la carte électronique nrf52810. Il nous a fallu recommencé cette carte deux fois. En effet, une fois finie sur Altium nous avons réalisé que les empreintes des CMS sur PCB fourni par le constructeur ne correspondent pas au matériel CMS de l'école. Face à cette inattention de notre part, nous avons décidé de refaire entièrement la carte électronique sur fritzing. Ayant la datasheet et des plans d'inspiration PCB, nous avons pu refaire la carte entièrement.
Sur celle-ci nous avons ajouté des broches de connexion au besoin, un branchement Jtag et ICSP pour la programmation et la connexion SPI.
La carte est en attente de validation, puis validation.

[[Fichier: nrf52810_circuit2.jpg||center|400px|PCB carte nrf52810]]

===Révision matériel ===

Pour la réalisation de nos composants électroniques, il nous a fallu faire une révision des composants disponibles à l'école:
(les quantités indiquées ci-dessous pourront être augmentée si nécessaire,pour avoir dans l'idéal un module de chaque type de la manette, ici on se concentre sur BOUTON et JOYSTICK)

'''Cartes Arduino:'''
* 4 capacite 22pF traversantes
* 2 resistances 10 kOhm traversantes (à récupérer)
* 2 oscillateurs quartz 16MHz traversante
* 2 atmega328p-pu et support

'''Cartes nrf52810'''
* 6 capacités 100nF 0603
* 6 capacités 12pF 0603
* 2 capacités 4,7pF 0603
* 2 capacités 1µF 0603
* 2 capacités 100pF=0,1nF 0603 (à récupérer)
* 2 capacités 0,8pF 0603 (commande en cours)
* 2 inductance 3,9nH 0603 (commande en cours)
* 2 oscillateur quartz 32 MHz

'''Cartes modules Boutons'''
* un sachet de broches mâles (qu'on utilisera également pour les autres cartes, à récupérer/acheté)

Nous avons alors mis-à-jour la liste de composant située plus haut, ainsi que celle de la page IMA4 2017/2018 [https://projets-ima.plil.fr/mediawiki/index.php/Projets_IMA4_SC_%26_SA_2017/2018]

==Semaine 7==

===Programmation: connexion wifi RPi Zero W et Bootloader sur Atmega328p-pu ===

Pendant cette semaine, nous avons continué la programmation et la configuration des Raspberry Pi 3 et Zero W afin de les utiliser en connexion Wifi.

Nous avons également continuer les programmes de récupération de données : état des boutons et du joystick. Ces programmes sont appliqué sur l'atmega328p-pu standalone sur la plaque d'essai en attendant que le PCB soit opérationnel.
Pour pouvoir programmer l'atemega328p-pu comme une arduino UNO, il nous faut suivre plusieurs étapes :

'''1.Flasher le Bootloader'''
Nous avons 2 Atmega328p-pu neufs, ainsi il nous faut flasher le bootloader sur chacun d'eux afin de pouvoir les utiliser et les programmer sur une breadboard dans un montage minimaliste arduino-standalone.
Pour cela, on peut utiliser une carte arduino UNO. On vérifie le port et le type de carte sélectionnés dans le menu >Outils. Sur cette carte on téléverse le fichier arduinoISP.ino qui se trouve dans les exemples en étant en progrmamateur AVr ISP mkll (>outils>programmateur)
Puis on met l'atmega328p-pu qui nous intéresse sur le suppor socket de la carte. On change de nouveau le programmateur pour Arduino as ISP et on fait >tools>burn bootloader, soit >graver la sequence d'initialisation.
Ces étapes faites, on peut retirer notre microcontroleur et le replacer correctement dans le montage.

'''2.Programmation atmega328 sur breadboard'''
Une fois l'atmega328p-pu préparé, on peut le programmer. On peut le faire simplement à l'aide de la carte arduino UNO utilisée précédemment.On branche les Tx et Rx en commun ainsi que le reset, le GND et le VCC.

Nous avons réaliser des codes basiques tels que le clignotement d'une led rouge ou encore l'affichage de "hello world" sur le moniteur série pour vérifier la bonne fonctionnalité du montage. Cela fait nous avons pu écrire sous Arduino IDE le code de lecture des états.

[[Fichier: montage_BB_test.jpg||left|200px|programmation modules arduino sur breadboard]]

===Electronique : soudure carte de test modules ===

Comme nous l'avons déja vu lors de la réalisation des PCB, si l'on souhaite programmer un atmega328p-pu en bootloader, le montage est simple. Il peut être minimaliste en utilisant une arduino UNO, un atmega328, une breadboard et 3 composants: 1 quartz 16MHZ crystal, 1 résistance 10kOhm et 2 capacitors céramiques de 22pF.
Durant la semaine 7, nous avons soudé les composants traversants de la carte électronique correspondant à ce montage ainsi que le PCB du bouton.

==Semaine 8==

===Programmation ===

===Electronique : Correction soudure et soudure CMS===

Durant cette semaine, nous avions souhaité programmer la carte électronique atmega328p-pu. Cependant, nous avons réaliser que nous avions fait une erreur lors de l'envoie du PCB à la production. En effet, celui-ci avait été fait en Top sur le logiciel Fritzing et non en Bottom. Hors nous avions soudé les composants (durant la semaine 7) comme pour un circuit imprimé en bottom, l'atmega328p-pu se retrouve alors inversé par rapport aux pistes.
Comme solution, nous avons choisi de souder un deuxième support pour l'atmega328 de l'autre coté de la carte avant de la refaire au propre. En effet, avant de la refaire il nous faut vérifier si la carte est bien programmable.
Une fois cela fait nous avions pu programmer la carte mais, nous avions également réalisé la pin 2 de l'atmega328 était prise par le bouton poussoir. Or, nous avons besoin des pin 2 et 3 pour le RX et TX permettant la programmation de l'atmega à partir d'une arduino, les pistes branchement RX-TX n'ont également pas été prévus pour le téléversement des programmes sur la carte. Il nous faut alors couper une piste et souder des câbles pour utiliser toutes les pistes souhaitées.

[[Fichier: correction_proto_PCB.jpg||right|300px|PCB arduino correction]]

Durant cette semaine, nous avons également souhaité souder les CMS et le composant bluetooth nrf52810 sur la carte imprimé et reçu lors de la semaine 7. Pour cela, nous avons convenu de travailler dans la C202 durant la séance du mercredi.

[[Fichier: PCB_nrf52810.jpg||left|400px|carte electroniques imprimées]]

====Comment souder des CMS ?====

les CMS sont des composants montés en surface c'est à dire qu'ils sont montés du même côté que les pistes cuivrées (à l'opposé des composants traversants) et sont de petite tailles souvent de l'ordre du millimètre. La taille est déterminée par 4 chiffres : les 2 premiers pour la longueur et les 2 derniers pour la largeur. On a du 1206,0805,0603 ou encore 0402. Il est même possible de trouver plus petit. A l'école nous utilisons souvent du 0603, c'est le cas de nos composants.
Pour souder des CMS 0603, il nous faut utiliser une autre méthode qui n'est pas le fer à souder :
# Préparer la veille la pâte à braser la veille (dans une seringue)
# Gommer la carte pour éviter l'oxydation (attention à ne pas retirer les miettes de gomme en soufflant dessus)
# Appliquer avec la seringue la pâte sur les empreintes et piste souhaitées. Pour les endroits difficile à atteindre ou avec 2 pistes proches les unes des autres, il est possible de mettre la même goutte de pâte sur les 2 pistes. Cela de causera pas de court-circuit par la suite. En effet, la pâte est composée d’alliage qui sous la chaleur va se fluidifier et se coller uniquement aux pistes métallique. Le reste fondera sous la chaleur du four.
# Appliquer les CMS sur la pâte au fur et à mesure (attention ! ne jamais toucher les CMS avec les doigts, tjrs utiliser une pince)
# Mettre au four

====Bilan soudure nrf52810====

Cependant, une fois le matériel nécessaire préparé, et la pâte mise sur les pistes souhaitées, au moment de déposer le composant, nous avons réalisé que celui-ci était beaucoup plus petit que l'empreinte sur le PCB. Il s'agit d'un composant boitier QFN48. Fritzing ne proposant au plus proche des boitiers QFN24 ou LQFP48, celui-ci a basculé automatiquement pour un boitier LQFN48, de dimension plus grande. Face à ce manque de vigilance, nous avions cependant commencer par le nrf52810 (composant concerné) évitant ainsi de gaspiller d'autres CMS.
Nous avons souhaité refaire la carte sous Altium à partir des fichiers fournis par le concepteur (chose que nous avons commencé à faire aux alentours de la semaine 5)
Après la réalisation du schématic, et de la modification des empreintes de capacités, inductances et autres composants de 0402 à 0603. Notre matériel ne permettant que des empreintes 0603.

Lors du routage, une erreur de chevauchement des pistes est notifiée par Altium au niveau du nrf52810. Celles-ci ne présentent pas d'angles et sont déjà de taille 8mil, il nous faut alors passer les pistes en 6mil. Mais 8mil est la taille minimale pour la production à Polytech, nous avons regardé pour envoyer les cartes à faire ailleurs mais le 6mil n'est pas beaucoup conseillé. De plus, il n'est peut-être pas judicieux de continuer avec le composant microcontrôleur-bluetooth Nrf52810 qui prend du temps, donc la carte est difficilement réalisable et peut-être très long à programmer.

Ainsi en cette fin de semaine, nous avons décider face à l'avancer du projet de laisser les nrf52810 de coté et de les remplacer par des modules sans fils plus simples d'utilisation et complets. Ainsi nous aurions plus de chance d'avoir une connexion sans fils entre les modules. Nous pourrions par exemples utiliser des Xbee, des modules Rf...

==Semaine 9==

====Programmation: PS4 et 1er Test SPI sur atmega328p====

'''Raspberry Pi Zero W et PS4'''

'''Modules Atmega328p et SPI'''

Une carte PCB arduino fonctionnant, nous pouvons la programme pour simuler un module. Celle-ci a été designée afin de s'adapter au module que l'on souhaite. Il suffit de brancher le bouton, le joystick ou autre élèment de manette souhaité.
Cette semaine ci, nous avons alors configurer la partie communication SPI pour l'arduino.

'''Que voulons-nous faire avec les atmegas ?'''
Les cartes électroniques atmega328p vont nous permettre de recevoir les requêtes SPI envoyées par la raspberry pi et d'y répondre. La Raspberry enverra un message, par exemple "1", et l'Arduino lira alors l'état du module qui lui est connecté. Une fois l'état récupéré elle le renvoie à la raspberry pi.

Durant cette semaine, nous avons programmé l'atmega afin qu'il soit en esclave, qu'il reçoive un de la RPi "1" et retourne une valeur sauvegardé "int envoi". Nous avons également commencé les tests pour la lecture de l'état d'un bouton (d'après les tests réalisés les semaines précédentes).

'''Code'''
Comme nous l'avons vu précedement lors de nos recherches (semaines 1 à 4) :
La communication SPI nécessite l'utilisation des pins:

MOSI -> GPIO11 //PB3 //master OUT to the slave IN
MISO -> GPIO12 //PB4 //slave OUT to the master IN
SCLK -> GPIO13 //PB5 //serial clock
SS -> GPIO10 //PB2 //slave select

Il faut également paramétrer l'atmega328p en Slave. On note que dans un premier temps, le programme sera codé avec l'arduino IDE (fichiers .ino). Une fois l'ensemble SPI RaspberryPi-Arduino fonctionnant, on remplacera ces codes par du langage C ou C++.

Pour faire la connexion SPI sur l'atmega328p, on utilise la librairie arduino SPI.h, on a alors directement les fonctions nécessaires intervenant sur les registres souhaités : SPCR (spi control register), SPSR (spi status register) et SPDR (spi data register).

#include <SPI.h>

Il est important d'initialise d'abord le setup et on active le port série pour pourvoir utiliser le moniteur série. (Cela servira à verifier la valeur envoyée par la RPi)

void setup (void)
{
Serial.begin (9600);
pinMode(MISO, OUTPUT); //configuration en esclave *master in slave out*
pinMode(buttonPin,INPUT); //config pin bouton
// turn on SPI in slave mode
SPCR |= _BV(SPE);
// preparation interruptions
pos = 0; // buffer empty
process_it = false;
// activation interruptions
SPI.attachInterrupt();
}

On oublie pas de déclarer les interruptions afin de bien lire la requête reçue.

// SPI interrupt routine
ISR (SPI_STC_vect)
{
byte c = SPDR; // grab byte from SPI Data Register
// add to buffer if room
if (pos < sizeof buf)
{
buf [pos++] = c;
// example: newline means time to process buffer
if (c == '\n')
process_it = true;
} // end of room available
} // end of interrupt routine SPI_STC_vect

Dans la loop main, on traite la requête et on utilise '''SPI.transfer(envoi);''' pour transferer à la RPi les données souhaitées.

Durant cette semaine, nous avons également commencé des programmes de test SPI pour la RPi. Il s'agit principalement de programmes de tests tout faits permettant de vérifier la connexion entre cette dernière et l'arduino. Par exemple, la RPI envoie "bonjour" et l'arduino lui retourne ce qu'elle reçoit, soit "bonjour". Sans succés alors.

====Electronique : Fritzing révision====

Lors de la semaine, le modèle PCB de la carte arduino a été réalisé de nouveau sous fritzing avec les broches et connections manquantes. Nous avons également revu la configuration du bouton reset et ajouté une led d'état de l'alimentation. Nous avons ainsi envoyé deux cartes identiques à la réalisation.
La carte déjà soudée lors des derniers jours fonctionnant, elle nous sert de prototype de programmation. Nous pouvons ainsi avancer à la fois sur la programmation des modules mais aussi sur leur réalisation.

==Semaine 10==

====Programmation : PS4 et SPI sur RPi====

'''Raspberry Pi Zero W et PS4'''

'''Modules Raspberry PI et SPI'''

Durant cette semaine, pour la partie Atmega328p-Modules, nous nous sommes concentrés sur la programmation de la communication SPI avec la raspberry pi. Cette semaine a permis une étude plus approfondit sur le fonctionnement pour la RPi.

On rappelle, comme vu des semaines 1 à 4, pour la RPI3 (tout comme la RPi Zero W) utilise les broches : SCLK (23), MISO(21), MOSI (19) et SPI CS0 (24), SPI CS1 (26).
On la programme en Master. A l'aide des fichiers tests d'inspiration, on pourra directement programmer la RPi en C. Lors de la réalisation du code, il y a 3 étapes : l'initialisation/parametrage en SPI pour être maître, l'envoie de la requête puis la réception de données en retour.

Programmant en C, il ne faut pas oublier les librairies suivantes :

#include <stdint.h>
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
#include <getopt.h>
#include <fcntl.h>
#include <sys/ioctl.h>
#include <linux/types.h>
#include <linux/spi/spidev.h> //pour SPI

On va déclarer des variables globales permettant le paramétrage :

static const char *device = "/dev/spidev0.0"; //si on veut CS0 pour atteindre notre SS
static uint8_t mode; //mode est par défaut à 0
static uint8_t bits = 8; //bits par mot échangé
static uint32_t speed = 500000;
static uint16_t delay;

Dans notre main, on ouvre le port (la connexion) au device souhaité, on vérifie les paramètres (registres, connexions...) puis exécute la fonction transfer(fd). transfer(fd) transmet la requête et s'occupe de la réception.

fd = open(device, O_RDWR);
transfer(fd);
close(fd);

==Semaine 11==

====Programmation: PS4, SSH et tests SPI (RPi3&Atemga328p)====

'''Raspberry Pi Zero W et PS4'''

'''Raspberry PI, Atmega328p et SPI'''

Afin de facilité la programmation en utilisant Ethernet, nous avons installer et configuré la RPi pour l'utiliser en SSH depuis les ordinateurs de la E306. En effet, SSH permet de se connecter à distance sur une machine en utilisant un compte utilisateur de la dite machine. En mettant ssh, on pourra directement agir sur les fichiers de la raspberry depuis un terminal de notre PC. Pour cela, on a d'abord vérifier l'adresse IP de notre raspberry pi : 172.26.145.106 avec un écran mais on peut aussi utiliser les commandes ip a et ifconfig. Puis activer le ssh sur la raspberry pi.
On modifie alors le fichier config.txt mais également etc/network/interfaces pour configurer la bonne interface Ethernet sur la raspberry pi.

[[Fichier: configSSH_raspi.png||left|300px|config ssh ethernet]]

Il nous suffit alors de taper la commande : ssh pi@172.26.145.106 pour accéder à notre RPi.

Nous avons continué à réaliser la communication SPI avec des tests entre une arduino UNO et la RPI3. Nous avons commencé par des tests simples inspirés des études de deux semaines précédentes et modulés selon notre utilité.
Nous arrivons alors à lire l'état envoyer "bonjour" et recevoir "ça va" ou encore "1" et recevoir "3". Il faut noter que le SPI échange des trames, la RPI reçoit alors des hexadécimaux.
Nous avons alors continué pour recevoir l'état du bouton ou du joystick lors de l'envoie de "1" sur l'Arduino328p. La semaine prochaine nous testerons ces même codes fonctionnels sur les cartes atmeg327p.

A la fin de cette semaine, nous avons alors des codes Arduino-SPI (.ino) et des codes Raspberry-SPI (.c) permettant l'échange de données. Le but est maintenant de l'adapter aux cartes imprimées et de le rendre pleinement fonctionnel pour plusieurs cartes à la fois, puis ajouter une boucle de vérification en continue jusqu'à une deuxième requête de la RPi.

====Electronique: réalisation au propres des PCB modules====

Suite à une nouvelle erreur de réalisation cartes électronique, nous avons refait et renvoyé à nouveau les cartes imprimées atmega328p.
Nous les souhaitons au propre pour une version finale. Une fois celle-ci imprimées nous pourrons en avoir 3 , un pour chaque module. Les cartes étaient bien imprimées en bottom mais lors du passage des traversants de bottom à top, le logiciel ne les a pas fait miroiter. Par manque d'attention nous avons alors envoyé les fichiers gerber pour des cartes ayant les composants du même coté que la couche de cuivre.
Les cartes électroniques actuelles sont alors correctes et fonctionnelles mais difficile à souder. Pour eviter les erreurs et continuer sur des prototypes de carte nous préférons attendre en nous concentrant sur la programmation PSI de la Raspberry Pi.

==Semaine 12==

====Programmation====

'''Raspberry Pi Zero W et PS4'''

'''Raspberry PI, Atmega328p et SPI'''

- réflexion: penser à faire boucler sur l'arduino une fois la requête reçu, ça veut dire que la manette est ON et donc vérifier continuellement les modules sur chaque atmega.
- SPI raspberry pi - arduino recuperation état du bouton avec les cartes modules (/!\ récuperation à faire dans une variable)

-SSH perso
adresse Rasppi: 192.168.137.10

====Electronique: Finalisation soudure Modules====

Soudure au propre et finale d'une carte atmega328p et donc envoie pour la réalisation de 2 autres cartes similaires et récupération de matériel
Soudure des 2 autres cartes, + tests sur les états = fonctionnelles.
On a donc bien 3 cartes pour les 3 modules de types différents (1 bouton, 1 joystick, 1 gachette)
PCB pour les 2 joysticks (qui serviront de thumbstick et gachette)

==Semaine 13 et plus==

====Programmation====

'''Raspberry Pi Zero W et PS4'''

'''Modules Atmega328p et SPI'''

====Electronique====

=Documents Rendus=

(à mettre rapport + git + drive)

=Datasheets=

IMA4 2017/2018 P35

2018-05-05T18:23:23Z

Tgracias : /* Semaine 3 : Début premier prototype */

__TOC__
 

=Présentation générale: Manette modulable=

==Description==

Tout le monde joue aux jeux vidéo cependant, les manettes ne sont pas adaptées aux personnes ayant un handicap pouvant toucher les bras ou les mains.
C’est le cas, de plusieurs patients dans les centres de soins et de rééducation.

Pour ce projet IMA4, nous travaillerons avec le centre SSR (soin de suite et de réadaptation) Marc Sautelet de Villeneuve d’Ascq.
Un adolescent, patient de Marc Sautelet, est passionné par les jeux vidéo. En effet, ayant perdu la motricité d’une partie de son corps, il ne peut pas jouer à deux mains. Pour cela, il bloque la manette entre son épaule et son coude, usant de la mâchoire et des doigts pour contrôler les
joysticks et les boutons. Cet exercice peut s’avérer fatiguant et pénible.

Ainsi, nous chercherons à concevoir une manette PS4 adaptée au handicap de l’adolescent.
Cette manette devra aussi être adaptée pour d’autres patients présentant également des handicaps moteurs. Ainsi nous prendrons pour cibles: tous les patients du centre voulant jouer; et non pas que les enfants et adolescents.

 

{| class="wikitable centre" width="80%"
|+
|-
| width="23%" |
Membre du projet
| width="34%" |
Transley Gracias et Camille Saad
|-
| width="23%" |
Cible
| width="34%" |
Patient présentant un handicap moteur
|-
|width="23%" |
Période du projet
| width="34%" |
janvier 2018 - mai 2018
|-
|width="23%" |
Partenaire/Client
| width="34%" |
Centre SSR Marc Sautelet à Villeneuve d'Ascq
|}

==Objectifs==

Ce projet a pour objectif de créer un prototype de manette qui puisse interagir avec la console PS4 et dont le paramétrage se fait à l’aide d’une application mobile et/ou web. Cette manette devra suivre les demandes du patient ainsi que des aides-soignantes du centre, dans la mesure du possible.

Plus précisément, pour le premier prototype, nous mettrons en œuvre l'utilisation de quelques boutons spécifiques:

* Un joystick (type L/R)
* Quelques boutons poussoirs (type Croix/Triangle/Carré/Rond/R1/L1/Start/...)
* Des boutons gâchettes progressives (type L2/R2).

Le but serait donc dans un premier temps de rendre fonctionnel un bouton de chaque type, puis de les multiplier une fois cela fait. Tous ces boutons réunis constituent une manette fonctionnelle.Ainsi, la manette sera ajustable, c’est à dire qu’elle devra s’adapter aux différents handicaps moteurs possibles.

=Analyse du projet=

==Positionnement par rapport à l'existant==

Notre prototype aura une présentation unique par rapport à l’existant. En effet, les concurrents et produits existants ciblent pour la majorité un seul handicap. Cela
engendre une solution fermée à beaucoup de patients. Notre projet propose une mobilité des mouvements et également un choix large dans la composition et le
design de notre manette.
Le patient n’est pas retreint à jouer à une seule main, à utiliser beaucoup de force...Il y a moins de technique dans la manipulation et on ne joue pas avec une
manette adaptée uniquement pour un droitier ou un gaucher. Cependant, cela nous limitera peut-être dans le choix possible des types de jeux. Tout comme les autres
manettes adapté, l’utilisateur nécessitera un peu d’entrainement.

==Analyse du premier concurrent==

Jouer aux jeux vidéo à une main n’est pas une idée d’aujourd’hui. En 1990, Nintendo propose le Power Glove. Mais il tombe très rapidement aux oubliettes suite à des problèmes techniques.

Un autre gant a fait son apparition quelques années plus tard. Celui-ci, plus technique, il faut office de manette Play Station: le Reality Quest Power Glove.Cette idée de manette-gant, permet de jouer à la PS avec une seule main, elle a était conçue et présentée pour les E3, un salon d’exposition de gaming.Le gant est conçu pour contrôler l’équivalent des 14 boutons et 2 joysticks à l’aide d’une seule main. La « manette » est fixée dans la pomme de la main. L’utilisateur contrôle les mouvements verticaux et horizontaux en pivotant le poignet, et utilisent les 4 boutons d’action principaux et L1/R1 avec les doigts. Les autres boutons sont accessibles par un seul bouton rond contrôlé par le pouce.
La manette est adaptée pour beaucoup de jeux vidéo, dont les plus simples sont les jeux de voitures et de combats (arcade).

; Problèmes:
*Besoin de toute la motricité de la main, c’est-à-dire que si le patient à un doigt paralysé ou manquant, il ne pourra pas jouer avec ce gant
*Design obligatoirement droitier
*Les boutons de contrôle sont peu sensibles et peuvent nécessiter de la force
*Design compliqué et nécessitant beaucoup d’entrainement.

;Lien : https://www.youtube.com/watch?v=qV0SxSJDCYg

 
==Analyse du second concurrent==

Ben Heck, de son vrai nom Benjamin J.Heckendorn, est un concepteur de mods de consoles (mods pour modification, soit « manettes modifiées ») et une star
du net grâce à ses vidéos tutoriels.Il propose alors énormément de produits adaptés ou dérivés en guise de manettes.
Parmi les mods qu’il a réalisé, il a modifié une manette de PS4 afin de la rendre accessible à une personne ne pouvant jouer qu’à une main. Pour cela, il a déplacé les boutons en respectant l’ergonomie de la main valide et modifie les connexions. Il peut lui arriver de rajouter des boutons pour en remplacer un autre. Il réalise également le même système avec la Xbox. Sur la photo ci-dessous, il a adapté la manette pour un droitier.

; Problèmes:
*Besoin de toute la motricité de la main, c’est-à-dire que si le patient à un doigt paralysé ou manquant, il ne pourra pas jouer avec cette ma
*Design obligatoirement droitier ou gaucher, une modification = une manette= une personne
*Besoin obligé du pouce et de l’index, même si avantage : 3 doigts nécessaire.

;Lien :: https://www.youtube.com/watch?v=LieHIscadjk

==Scénario d'usage du produit ou du concept envisagé==

La technologie est ,aujourd’hui, omniprésente dans notre vie. Les consoles de jeux ont envahies les maisons avec plus de 7 personnes sur 10 jouant aux jeux vidéos sur consoles en France (chiffre de l’Express). 0,18% des français sont handicapés cela représente 12 millions de français. Dans ce chiffre, 13,4% des personnes ont un handicap moteur. En 2017, les grands groupes comme Sony ou Microsoft avec respectivement PlayStation et Xbox ne permettent pas à tout le monde de jouer avec une manette. Les manettes sont prévues pour des personnes ayant leurs membres valides, plus précisément les mains et les bras.

Après un accident de voiture, un jeune garçon a perdu la motricité d’un côté du corps. Passionné de jeux vidéo, il se retrouve avec des difficultés à jouer sur sa console PS4. Ingénieux, il utilise la manette en la coinçant entre son épaule et le creux du cou. Usant de la mâchoire et de sa main valide pour contrôler les joysticks et les boutons. L'exercice étant inconfortable et fatiguant il eu l’idée de proposer à des futurs ingénieurs de lui proposer une manette adaptée à son handicap.

Les deux pré-ingénieurs ,avec leur tuteur, ont une idée révolutionnaire : La manette modulable ! Elle permettrait au jeune garçon, ainsi que d’autres joueurs, de pouvoir continuer de s’amuser ou même de commencer à jouer au jeux sur console.
Cette manette aidera fortement dans les centre de rééducation pour faire passer le temps et donner du plaisir à des personnes qui ne peuvent plus s’amuser avec leur console traditionnelle. Elle pourra aussi ouvrir de nouvelles possibilités pour certaines personnes qui n’auraient jamais essayé jusqu'à présent.
Comme son nom l'indique, elle sera modulaire et s'adaptera à différents handicaps. Accompagnée de son application d’initialisation, elle sera accessible aussi bien aux enfants, patients, parents et aides soignantes.

Quelques mois plus tard...Le jeune patient fan de Need For Speed, peut maintenant piloter sa voiture comme un vrai professionnel grâce à l'un des joysticks qu'il utilisera avec sa main valide et il pourra accélérer à des vitesses folles à l'aide de boutons poussoirs au niveau de son pied valide et gagner la partie. Son ami venu lui rendre visite, pourra en lieu et place des aides soignantes configurer à l'aide de la tablette (portable) la manette du patient.
Si le patient change de jeu pour Tekken et que la configuration des modules ne lui convient plus, il peut interchanger les éléments de la manette selon son envie et son confort. Ainsi il peut faire sauter son personnage, il utilisera un module bouton supplémentaire, qu'il actionnera avec le poing.

==Fonctionnement==

Suite à une analyse fonctionnelle et à la formulation de notre projet, nous avons pu définir le fonctionnement de notre système. Notre produit, la manette, doit être accessible d’après nos objectifs à différents types de handicaps moteurs. Ainsi, l’idéal serait de concevoir une manette modulable afin qu’elle puisse s’adapter à toutes les situations. Ce n’est plus au patient de s’adapter à la manette mais à la manette de s’adapter au patient.
Cela signifie que la manette sera, dans la limite du possible et de la sensibilité du corps du patient, composée de plusieurs parties dites « modules » comportant un ou plusieurs actionneurs (boutons, joysticks, gâchettes...). Ces modules seront déplaçables afin d’être utilisé avec différents membres du corps : un doigt, une main,
une jambe ou même un pied. Il suffira de les connectés entre eux suivant l’organisation souhaitée, le Gameplay du jeu ou en fonction du handicap. Le tout sera relié à une application.
L’application sera alors mise en place pour connecter les différentes parties du point de vue software pour prérégler la manette en fonction du patient. Il pourra alors choisir les boutons en fonction du jeu, de ses mouvements mais aussi choisir la sensibilité.

L’application et les modules devront être intuitifs et faciles d’utilisation. De cette manière des utilisateurs non avertis dans le domaine informatique ou jeunes pourront eux-mêmes gérer les connexions.

==Réponse à la question difficile==

'''Question : Comment interconnecter les différents modules de la manette ?'''

Il nous faut pour ce projet interconnecter les modules modélisant la manette qui seront connectés à la consoles PS4 via une Raspberry Pi 3.
Le choix de la Raspberry Pi 3 nous permet d'utiliser son module Bluetooth pour communiquer avec la PS4, ce choix est plus adaptée au projet que du filaire.
Concernant l'interconnexion des modules, nous travaillerons en deux étapes "preuves concept" : filaire et sans fils (Bluetooth).

'''Objectif 1 : Preuve concept filaire'''

Dans cette première partie de projet, nous souhaitons avoir une 1ère preuve de prototype rapidement. Nous nous concentrerons alors sur la communication entre la RPi3 et la PS4 ainsi que sur la conception des modules. Pour les modules, nous réaliserons des cartes électronique pour chaque module avec un micro-contrôleur. La communication filaire nous permettra d'interconnecter les modules à la RPi3 avec un bus SPI.

'''Objectif 2: preuve concept sans fils'''

Une deuxième étape du projet est la réalisation de la solution idéale sans fils. Celle-ci pourra commencer à être développée petit à petit en parallèle avec l'objectif 1. Le but ici, est d'interconnecter les modules en Bluetooth. Nous avons choisi le Bluetooth pour garder une connexion commune sur toute la chaîne.
Nous rajouterons alors un module bluetooth à chaque module de la manette.

'''Objectif 3: possibilité d'adapter les boutons (capuchon en 3D)'''

=Préparation du projet=

==Cahier des charges==

''Chef de projet:'' Alexandre Boé 
''Responsables:'' Xavier Redon, Thomas Vantroys 
''Partenariat:'' Marc Sautelet (non etablie) 
''Elèves-ingénieurs:'' Camille Saâd, Transley Gracias 

'''Sujet :''' Manette modulable pour personne à déficience moteur compatible PlayStation 4 

===Objectifs principal (1er POC) : ===
Faire transmettre des informations issus des actionneurs (ex:boutons poussoires) via des arduinos jusqu’à la Raspberry Pi 3 en SPI. 
Envoyer les données reçues vers la PS4 en USB 

===Objectifs secondaire (2e POC):===
Créer des modules avec un microcontrôleur et une puce bluetooth pour permettre une meilleurs flexibilité (c-àd pouvoirs avoir une meilleure ergonomie et une connexion sans fil) 
Connecter la Raspberry Pi 3 en Bluetooth à la PS4 

[[Fichier: beteacorne.jpg||middle|600px|Bete a corne manette]]

==Choix techniques : matériel et logiciel==

===Liste de matériel :===

'''Modules boutons/joysticks/gachettes'''

3 Push buttons : 
- O X Y Carré R3 L3 
- Guide PS 
- start/back 
--> 0,45€/unité TTC [https://www.gotronic.fr/art-bp-miniature-krs1273-16976.htm] 

1 Thumbstick original: 
Joystick analogique 4 directions --> 4,25€/unité TTC [https://www.gotronic.fr/art-joystick-analogique-4-directions-19063.htm] 

1 buttons trigger L1 L2 => 1x Thumbstick original''' 

'''Cartes Atmega328p /connexion spi/'''

3 Arduino UNO 
1 Arduino UNO atmega328p retirable 
4 capacite 22pF traversantes 
2 resistances 10 kOhm traversantes (à récupérer) 
2 oscillateurs quartz 16MHz traversante 
2 atmega328p-pu et support 

'''Cartes module bluetooth nrf52810 '''

6 capacités 100nF 0603 
6 capacités 12pF 0603 
2 capacités 4,7pF 0603 
2 capacités 1µF 0603 
2 capacités 100pF=0,1nF 0603 (à récupérer) 
2 capacités 0,8pF 0603 (a acheter, commande en cours) 
2 inductance 3,9nH 0603 (a acheter, commande en cours) 
2 oscillateur quartz 32 MHz 

''' Connexions et autres '''

1 Led RGB neopixel [https://www.adafruit.com/product/1734] 
1 Raspberry Pi 3 
--> ~36,23€/unité TTC [https://fr.rs-online.com/web/p/processor-microcontroller-development-kits/8968660/?src=raspberrypi] 
1 Raspberry Pi Zero W (commandée) [https://www.raspberrypi.org/products/raspberry-pi-zero-w/] 
6 Alimentations 5V ou 3,3V 
par exemple, 12 piles de type CR2016 3V rechargeables ou 24 piles AAA 1,5 V rechargeables
5 modules Bluetooth nrf de Nordic : nRF52810-QFAA-R 
--> 3,17€/unité + frais expédition [https://www.mouser.fr/productdetail/nordic-semiconductor/nrf52810-qfaa-r?qs=sGAEpiMZZMve4%2FbfQkoj%252bG%2FosjLoe2oghFQwQllMrQ4%3D]
5 Lignes broches mâles 

===Logiciels:===

- IDE arduino
- Altium
- FreeCAD ou Inkscape

==Liste des tâches à effectuer==

'''Etape 1 : Gestion du projet'''

* Définition des cahiers des charges fonctionnel et technique, choix d'orientation...
* Recherche techniques sur les différentes connexions possibles entre les modules, la RPi 3 et la console PS4
#Recherche connexion SPI entre les modules et la RPi3
# Recherche connexion bluetooth entre la RPi3 et la PS4
# Recherche connexion bluetooth pour les modules
# Recherche carte avec montage Atmega328P-PU et anticipation module bluetooth
* Détermination du matériel nécessaire
* Réflexion sur l'application

'''Etape 2: Réalisation du projet'''

'''Partie 1: Preuve concept manette en filaire'''

* Conception de cartes électroniques pour 2 modules (/!\ prévoir modules bluetooth)
* Réalisation connexion SPI avec 2 modules : programmation des Atmega328p en liaison série.
* Si tests concluant, ajouter des modules jusqu'à en avoir 5 (1 pour chaque type de boutons)
* Connexion bluetooth entre la PS4 et la RPi3
* Réalisation du support des modules avec fixations possibles (imprimante 3D)

'''Partie 2: Preuve concept manette en bluetooth'''

* Ajout des modules bluetooth aux cartes électroniques
* Connexion bluetooth entre les modules

'''Partie 3: Application Android : paramétrage de la manette'''

* Créer une application sur tablette ou smartphone (Android) afin de configurer la manette aux besoins (inter-connexion des modules et console)

==Calendrier prévisionnel==

{| class="wikitable centre" width="80%"
|+
|-
| width="23%" |
'''Date'''
| width="34%" |
'''Tache à réaliser''' 
|-
| width="23%" |
17/01/18-24/01/18
| width="34%" |
Faire des recherches sur les différentes interconnexions du système : Bluetooth, RPi-Atmega328 (SPI), RPi-PS4
Continuer liste des taches, matériel, Début recherches + réflexion fixation support des modules
|-
|width="23%" |
31/01/18
| width="34%" |
Recherche technique connexion PS4-RPi3 et connexion SPI RPi3-Module + code
|-
|width="23%" |
31/01/18-07/03/18
| width="34%" |
Réalisation 1er prototype (+ début prototype 2)
|-
|width="23%" |
07/03/18
| width="34%" |
Seance 7 : Test prototype filaire
|-
|width="23%" |
07/03/18-09/05/18
| width="34%" |
Réalisation 2eme prototype + application Android
|-
|width="23%" |
09/05/18
| width="34%" |
Seance 14 : Test prototype Bluetooth
|-
|width="23%" |
14/05/18
| width="34%" |
Video projet
|-
|width="23%" |
15/05/18
| width="34%" |
Finalisation projet et Rapport
|-
|width="23%" |
16/05/18-17/05/18
| width="34%" |
Soutenances Projet
|}

=Réalisation du Projet=

==Feuille d'heures ==

Voici le tableau d'heures du binôme:

{| 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 S11 !! Heures S12 !! Heures S13et+ !! Total
|-
| Analyse du projet
| 10
| 2
| 1
| 1
| 1
|
|
|
|
|
|
|
| 20min
|
| 15h20
|-
| Cherches techniques
|
| 3
| 4
| 4
| 2
| 2
| 1
|
|
|
| 1
| 1
|
|
| 18
|-
| Rédaction du wiki et rapport de projet
|
| 1
| 1
| 1
| 1
| 30min
| 1
|
| 2
| 30min
| 30min
|
| 2
|
| 10h30
|-
| Programmation
|
|
|
|
| 3
| 2
| 3
| 5
| 4
| 7
| 8
| 6
| 5
|
| 43
|-
| Cartes électroniques
|
|
|
|
|
| 6
| 8
| 4
| 6
| 2
| 1
| 2
| 2
|
| 31
|-
| Application
|
|
|
|
|
|
|
|
|
|
|
|
|-
|-
| Total Semaine
| 10
| 6
| 6
| 6
| 7
| 10h30
| 13
| 9
| 12
| 9h30
| 10h30
| 9
| 9h20
|
| '''117h50'''
|}

==Prologue==

Avant la réalisation et conception d'un projet, il est important d'analyser celui-ci. Nous avons allons consacré le prologue à l'analyse fonctionnelle de la manette. Nous avons également eu une réflexion sur l'analyse technique, cela nous a permis de réaliser une liste de matériel. Il est important de définir les objectifs ainsi que les besoins afin de ne rien oublier. (Voir ci-dessus Analyse projet)
Nous avons également organisé notre travail, pour le partage de documents de recherches et la rédaction de compte-rendu final nous avons réalisé un google drive. Par la suite, nous créerons un projet Git.

Durant ce temps, nous avons décidé de réaliser 5 modules. Les modules sont les différents boutons de la manettes qui nous pourrons placer selon nos choix (boutons modulaires) pour notre prototype projet pour chaque type des boutons d'une manette PS4. Ces modules devrons être connectés à la console et interconnectés. Le tout sera lié à une application Android. Suite à quelques recherches et nos analyses, nous avons décidé les points suivants :

- On commencera avec 2 modules et on les multipliera par la suite.
- Les premiers tests sont réalisés avec des boutons petits pour assurer leur caractéristique "modulaires", par la suite nous pourrons ajouter des capuchons de taille plus importante (imprimante 3D ou achat)
- Conception modules : réalisation de carte avec un microcontrôleur atmega328 programmable pour chaque module (anticiper le module Bluetooth)
- Projet en 2 parties : prototype filaire et prototype Bluetooth
# Prototype filaire : connexions entre les modules et la RPi3 en SPI, connexion Rpi3-PS4 en Bluetooth, avec l'application en filaire à la RPi3
# Prototype Bluetooth: connexion Bluetooth entre modules-RPi3-PS4-apllication

[[Fichier: structuremanette.png||center|400px|Concept manette modulable]]

==Semaine 1==

Durant la séance, nous nous sommes concentrés les recherches afin de définir clairement le cahier des charges technique. Il s'agit des réalisations à mettre en œuvre pour les inter-connexions des éléments de la manette.
Ainsi, nous avons fait des recherches sur :

===Connexion SPI entre les modules (Atmega328p) et la RPi3===

SPI: Serial périphérique interface BUS

[[Fichier: yWGmW.png||right|200px|Concept manette modulable]]
Comme indiqué sur l'image ci-dessus, la Raspberry pi 3 peut communiquer en SPI avec ses broches CS0 (24), CS1 (26), SCLK (23), MISO (21), MOSI (19). Celles-ci permettent de communiquer avec un ou plusieurs esclaves (dans notre cas, des Atmega328p) en reliant directement les broches concernées de la RPi3 à celles des composants esclaves.
Chaque broche CS0 (24) ou CS1 (26) ne peut être connectée qu'à l'entrée SS (aussi appelé CS) d'un seul esclave.
C'est a dire que chaque CS est lié à un esclave afin de choisir avec lequel la communication est établie à un moment donné, et les MISO sont reliées entre elles en cascade, de même pour les SCLK et les MOSI. On peut noter que le maître impose la fréquence d’horloge et sélectionne l’esclave auquel les données sont envoyées. 8 MHz est le plus rapide supportable a 3,3V

[[Fichier: fonctionnementSPI.png||right|200px|Connexion SPI multi-esclaves]]

Voici un schéma du fonctionnement souhaité :

Comme nous souhaitons avoir 5 modules environ il nous faudra rajouter un composant en plus afin d'augmenter les possibilités de sélection, par exemple des démultiplexeurs.
Dans un premier temps nous essaierons avec 2 esclaves, puis on augmentera le nombre.

===Connexion Bluetooth PS4-RPi3===

Les recherches portent également sur la connexion entre la manette PS4 et la console. Elles concernent le protocole de communication via Bluetooth

Caracteristique pour la PS4: Bluetooth®v4.0, Qualcomm Atheros AR3002 Buetooth LE: 2,4-2,5 GHz 

Caracteristique de la connexion : 

*Vitesse de transmission >> 3 Mbit/s 8N1
*Relevé tous les 1.3 millisecond (peut-être)
*Chaque manette à une adresse unique BD_ADDR qui correspond à l’adresse MAC de la carte Réseau
*Protocole de détection est le SDP basé sur une emission reception PDU
*L’Attribut ID est representer en TLV Type Length Value
*Communication HCI ACL Data Packet

===Rélisation des cartes électroniques===

matériel nécessaire pour un PCB : 

*breadboard
*câbles
*1 x 10k Ohm résistance
*Quartz 16Mhz clock crystal
*2 x 22 pF capaciteurs
*Atmega328P-PU

Ressources:
[[https://www.arduino.cc/en/Main/Standalone]]
[[http://www.eprojectszone.com/atmega-328-pu-standalone/]]
[[https://www.arduino.cc/en/Tutorial/ArduinoToBreadboard]]

==Semaine 2==

Durant la semaine deux et durant la séance, nous avons continué et approfondie nos recherches sur le projet. Nous avons pu ainsi affiner nos taches de réalisation et donc notre cahier des charges.

===Connexion aux modules: SPI et Bluetooth ===

 CORRIGER

voir https://peip-ima.plil.fr/mediawiki/index.php/BE_2017-2018#Configuration_du_syst.C3.A8me_embarqu.C3.A9

(sudo apt-get install pi-bluetooth)

''connexion sur la raspberry par ssh:''
su
update-rc.d ssh enable
invoke-rc.d ssh start
ssh pi@172.26.79.1XX

''bluetooth''
bluetoothctl
agent on
default-agent
scan on
pair [device Bluetooth address] (exemple: pair XX:XX:XX:XX:XX:XX )

''NOUVELLE REFLEXION : Connexion SPI entre les modules (Atmega328p) et la RPi3 --> MODULES BLUETOOTH''

Si multi-esclaves= plusieurs modules :
Il faut ajouter des sélections pour les SPI → démultiplexeurs OU ne pas utiliser les CS0 et CS1, et plutôt des pins entrée/sortie de la RPi3 lié au SS comme ça on choisit direct le module esclave voulu.

'''IMPORTANT:''' Nous avons étudié à nouveau la datasheet de notre module bluetooth nrf de Nordik. Le module bluetooth comporte déjà un microprocesseur !
Un module plutôt peut donc jouer le rôle de notre atmega328p. Il n'y a alors pas besoin de réaliser des cartes électroniques de type arduino standalone. Nos PCB regrouperont alors uniquement l'alimentation, un actionneur (bouton, joystick), le module bluetooth et les broches de connexion si besoin...

Cette séance nous a alors permise de revoir entièrement le matériel nécessaire. Notre liste de matériel nous semble alors plus réfléchie et limitée au nécessaire.

===Connexion Bluetooth PS4-RPi3===

Suite à nos recherches de la semaine précédente, nous avons sélectionné deux sites bien renseignés :

SITES

Ils nous ont permis de comprendre la communication entre la manette et la console. En effet, ils nous expliquent les échanges de trames Bluetooth.
EXPLICATIONS 1 exemple 

==Semaine 3 : Début premier prototype==

===Connexion SPI RPi3-Arduino===

Comme vu durant les semaines précédentes, nous souhaitons réaliser une connexion Multi-esclaves en SPI entre la Raspberry pi et plusieurs modules.
Cette semaine nous avons vu que la réalisation de notre premier prototype doit aller vite. Il ne nous est pas nécessaire d’attendre les modules bluetooth si il nous faut dans cette partie uniquement utiliser son microprocesseur. Ainsi pour chaque module nous utilisons une arduino UNO. Nous réaliserons les programmes en C afin de pouvoir les réutiliser avec les modules bluetooth par la suite.
Une fois la connexion réalisable nous adapterons les programmes aux modules bluetooth Nordik. En effet, ceux-ci comporte déjà un microprocesseur, le module peut jouer le rôle de notre atmega328p. Il n'y a aurait alors pas besoin de réaliser des cartes électroniques arduino standalone sur PCB, mais directement des cartes électronique avec le module et le module voulu (bouton, joystick...) et l'alimentation.
Durant la séance nous avons alors revu la liste de matériel nécessaire.

[[Fichier: prototype1.jpeg||center|600px|connexion filaire prototype 1 filaire arduino]]

Durant la séance, nous avons recherches des exemples de codes et de librairies pour Arduino SPI et RaspberryPI SPI.

Nous avons également commencé le programme de la connexion SPI pour l'arduino et récupéré les bibliothéques SPI.h avec SPI.c. Nous nous sommes alors concentrer à les comprendre, pour pouvoir l'utiliser.

*'''Réalisation du projet Git'''

Création du projet IMA4_Projet35_ManetteModulable sur Git et partage de celui-ci.
Les premiers dossier crées durant la séance :
-Arduino (connexion SPI arduino) : ProtoSpi.c + dossier librairie SPI + Makefile
-RPI (dossier codes pour Rpi)
-Readme.md

Le site qui détaille le protocole Bluetooth PS4n'est pas complet et de plus n'ayant pas accès à une PS4 (pour le moment) nous avons décidé de commencer par une connexion USB (pour laquelle on dispose de toutes les informations) et qu'on pourra tester plus facilement.

==Semaine 4==

Pour le prototype 1 FILAIRE nous réaliserons les étapes suivantes :

#Réalisation du programme SPI pour arduino
#Réalisation du programme SPI pour la RPi
#Connexion USB avec la PS4 ou ordinateur
#Réalisation de cartes électroniques atmega328p-pu standalone (remplacer les Arduinos)
#Remplacer les "PCB arduino" par le module bluetooth et adapter la connexion
#Conception 3D de la délimitation 1 axe pour le joystick "gâchette"
#Réalisation de l'application Androïde.

Une fois ces étapes réalisées nous auront alors une preuve de concept filaire et nous pourrons alors passer à une connexion bluetooth.
Le passage à la connexion bluetooth sera le deuxième prototype et le cas idéal de la réalisation de la manette modulable.

===Mise à jour Matériel===

- Modéliser les boutons gâchettes L1/2 R1/2 de la manette PS4 (boutons sensibles à la pression) --> un joystick dont nous bloquerons un axe (imprimante 3D)
- Remplacer la RPi 3 par une Rpi zero W qui nous permettrait de réaliser plus facilement une connexion USB tout en gardant l'avantage du bluetooth.
- Choix de l’alimentation pour les 5 modules Bluetooth: nécessitent 3V --> utiliser des piles rechargeables 1,2V AAA plutôt que piles rondes 3V.

Nous avons également besoin du matériel cité en semaine 1 pour réaliser des cartes électroniques atmega328p-pu standalone. ( nous revenons alors sur les décisions de la semaine 3)

===Connexion SPI RPi3-Arduino===

Montage Raspberrypi et 1 arduino en PSI + 1 bouton + 1 led.
Voici le choix des branchements :

MASTER = RPi
SLAVE= Arduino

'''SPI sur Arduino:'''
MOSI -> GPIO11 //PB3 //master OUT to the slave IN
MISO -> GPIO12 //PB4 //slave OUT to the master IN
SCLK -> GPIO13 //PB5 //serial clock
SS -> GPIO10 //PB2 //slave select
'''Led, bouton et autre...'''
LED --> GPIO6 //PD6
GND
+5V (if required)
'''SPI sur la Raspberry Pi'''
SPIO MOSI -> PIN19
SPIO MISO -> PIN21
SCLK -> PIN23
SPIO CS0 -> PIN24

Continuation du code pour faire clignoter Led branchée à une arduino depuis la Rpi, en connexion SPI.

===Connexion USB PS4-RPi3===

Durant la séance, nous avons regardé comment utiliser le port série sur la RPi3, soit utiliser les UART.

Nous avons réaliser qu'il n'était pas aussi simple d'utiliser le port serie USB de la Raspberry Pi 3, en effet le SoC est un BCM2837 .
De plus nous ne pouvons pas utiliser le même port pour l'alimentation et la connexion.

Une des solutions à cette difficulté serait d'utiliser une RPi ZERO W à défaut d'une RPi 3. On pourrait alors avoir un port d'alimentation avec connexion USB mais également retrouver la connexion bluetooth dont nous avons besoin.

==Semaine 5==

===Programmation: Réflexion définitives prototypes filaire ===

Durant la semaine 5, nous avons continué la réalisation du prototype filaire par l'avancé du code SPI ainsi que les recherches concernant le protocole PS4.

Pour réaliser la connexion entre la PS4 et les différents modules, nous avons vu la semaine dernière que nous utiliserons une RPi zero W (que nous avons commandé). Celle-ci nous permet d'utiliser le bluetooth mais elle nous permet également de réaliser un réseau local sans fil. Ce qui peut être pratique dans la mesure où notre projet est modulable.
En attendant la réception de la commande, nous nous sommes penché sur les programmes et la configuration nécessaire à l'utilisation de la RPi zero W.

===Electronique===

[[Fichier: bouton_c1.jpg|100px|thumb|left|PCB bouton]]
[[Fichier: arduinobb.jpg|200px|thumb|right|atmega328p-pu branchement test]]

Du coté électronique, nous avons réalisé sur fritzing certaines cartes électroniques. Les Arduino Uno servant actuellement de test, seront remplacées par des PCB atmega328p-pu standalone avec des broches permettant les branchements nécessaires SPI ou encore aux modules "boutons/joystick". Pour les boutons, nous avons également réalisé un pcb afin de faciliter les branchements.

Il nous faut alors également une 3eme carte qui nous sera nécessaire pour la réalisation du prototype sans fil. Dans notre liste de matériel, nous avons des composants nrf52810 bluetooth, ceci doivent être soudé avec les capacités de protection mais également des broches de communication. Nous avons alors commencé cette carte électronique sur Altium avec le fichier projet PCB du distributeur à modifier.

[[Fichier: Arduino_c1.jpg|100px|thumb|center|PCB atmega328p-pu]]

=== Construction 3D ===

Enfin, nous avons commencé à réaliser des boîtiers 3D pour certains modules. Par exemple, comme nous l'avions vu précédemment, un des joysticks servira de bouton-gâchette en utilisant un seul de ses axes. Il nous faut alors réaliser un boitier qui bloque l'un des axes, mais également une tige qui nous permettra de pousser le joystick de manière simplifiée.

==Semaine 6==

===Programmation: configuration RPi Zero W ===

Ayant reçu la Raspberry Pi zero W en début de semaine, nous nous sommes concentrés sur la programmation et la configuration de celle-ci.

===Electronique: PCB nrf52810===

Les cartes réalisées en semaine 5 sont validées et en attente de réalisation.

Cette semaine a permis la réalisation et la finalisation de la carte électronique nrf52810. Il nous a fallu recommencé cette carte deux fois. En effet, une fois finie sur Altium nous avons réalisé que les empreintes des CMS sur PCB fourni par le constructeur ne correspondent pas au matériel CMS de l'école. Face à cette inattention de notre part, nous avons décidé de refaire entièrement la carte électronique sur fritzing. Ayant la datasheet et des plans d'inspiration PCB, nous avons pu refaire la carte entièrement.
Sur celle-ci nous avons ajouté des broches de connexion au besoin, un branchement Jtag et ICSP pour la programmation et la connexion SPI.
La carte est en attente de validation, puis validation.

[[Fichier: nrf52810_circuit2.jpg||center|400px|PCB carte nrf52810]]

===Révision matériel ===

Pour la réalisation de nos composants électroniques, il nous a fallu faire une révision des composants disponibles à l'école:
(les quantités indiquées ci-dessous pourront être augmentée si nécessaire,pour avoir dans l'idéal un module de chaque type de la manette, ici on se concentre sur BOUTON et JOYSTICK)

'''Cartes Arduino:'''
* 4 capacite 22pF traversantes
* 2 resistances 10 kOhm traversantes (à récupérer)
* 2 oscillateurs quartz 16MHz traversante
* 2 atmega328p-pu et support

'''Cartes nrf52810'''
* 6 capacités 100nF 0603
* 6 capacités 12pF 0603
* 2 capacités 4,7pF 0603
* 2 capacités 1µF 0603
* 2 capacités 100pF=0,1nF 0603 (à récupérer)
* 2 capacités 0,8pF 0603 (commande en cours)
* 2 inductance 3,9nH 0603 (commande en cours)
* 2 oscillateur quartz 32 MHz

'''Cartes modules Boutons'''
* un sachet de broches mâles (qu'on utilisera également pour les autres cartes, à récupérer/acheté)

Nous avons alors mis-à-jour la liste de composant située plus haut, ainsi que celle de la page IMA4 2017/2018 [https://projets-ima.plil.fr/mediawiki/index.php/Projets_IMA4_SC_%26_SA_2017/2018]

==Semaine 7==

===Programmation: connexion wifi RPi Zero W et Bootloader sur Atmega328p-pu ===

Pendant cette semaine, nous avons continué la programmation et la configuration des Raspberry Pi 3 et Zero W afin de les utiliser en connexion Wifi.

Nous avons également continuer les programmes de récupération de données : état des boutons et du joystick. Ces programmes sont appliqué sur l'atmega328p-pu standalone sur la plaque d'essai en attendant que le PCB soit opérationnel.
Pour pouvoir programmer l'atemega328p-pu comme une arduino UNO, il nous faut suivre plusieurs étapes :

'''1.Flasher le Bootloader'''
Nous avons 2 Atmega328p-pu neufs, ainsi il nous faut flasher le bootloader sur chacun d'eux afin de pouvoir les utiliser et les programmer sur une breadboard dans un montage minimaliste arduino-standalone.
Pour cela, on peut utiliser une carte arduino UNO. On vérifie le port et le type de carte sélectionnés dans le menu >Outils. Sur cette carte on téléverse le fichier arduinoISP.ino qui se trouve dans les exemples en étant en progrmamateur AVr ISP mkll (>outils>programmateur)
Puis on met l'atmega328p-pu qui nous intéresse sur le suppor socket de la carte. On change de nouveau le programmateur pour Arduino as ISP et on fait >tools>burn bootloader, soit >graver la sequence d'initialisation.
Ces étapes faites, on peut retirer notre microcontroleur et le replacer correctement dans le montage.

'''2.Programmation atmega328 sur breadboard'''
Une fois l'atmega328p-pu préparé, on peut le programmer. On peut le faire simplement à l'aide de la carte arduino UNO utilisée précédemment.On branche les Tx et Rx en commun ainsi que le reset, le GND et le VCC.

Nous avons réaliser des codes basiques tels que le clignotement d'une led rouge ou encore l'affichage de "hello world" sur le moniteur série pour vérifier la bonne fonctionnalité du montage. Cela fait nous avons pu écrire sous Arduino IDE le code de lecture des états.

[[Fichier: montage_BB_test.jpg||left|200px|programmation modules arduino sur breadboard]]

===Electronique : soudure carte de test modules ===

Comme nous l'avons déja vu lors de la réalisation des PCB, si l'on souhaite programmer un atmega328p-pu en bootloader, le montage est simple. Il peut être minimaliste en utilisant une arduino UNO, un atmega328, une breadboard et 3 composants: 1 quartz 16MHZ crystal, 1 résistance 10kOhm et 2 capacitors céramiques de 22pF.
Durant la semaine 7, nous avons soudé les composants traversants de la carte électronique correspondant à ce montage ainsi que le PCB du bouton.

==Semaine 8==

===Programmation ===

===Electronique : Correction soudure et soudure CMS===

Durant cette semaine, nous avions souhaité programmer la carte électronique atmega328p-pu. Cependant, nous avons réaliser que nous avions fait une erreur lors de l'envoie du PCB à la production. En effet, celui-ci avait été fait en Top sur le logiciel Fritzing et non en Bottom. Hors nous avions soudé les composants (durant la semaine 7) comme pour un circuit imprimé en bottom, l'atmega328p-pu se retrouve alors inversé par rapport aux pistes.
Comme solution, nous avons choisi de souder un deuxième support pour l'atmega328 de l'autre coté de la carte avant de la refaire au propre. En effet, avant de la refaire il nous faut vérifier si la carte est bien programmable.
Une fois cela fait nous avions pu programmer la carte mais, nous avions également réalisé la pin 2 de l'atmega328 était prise par le bouton poussoir. Or, nous avons besoin des pin 2 et 3 pour le RX et TX permettant la programmation de l'atmega à partir d'une arduino, les pistes branchement RX-TX n'ont également pas été prévus pour le téléversement des programmes sur la carte. Il nous faut alors couper une piste et souder des câbles pour utiliser toutes les pistes souhaitées.

[[Fichier: correction_proto_PCB.jpg||right|300px|PCB arduino correction]]

Durant cette semaine, nous avons également souhaité souder les CMS et le composant bluetooth nrf52810 sur la carte imprimé et reçu lors de la semaine 7. Pour cela, nous avons convenu de travailler dans la C202 durant la séance du mercredi.

[[Fichier: PCB_nrf52810.jpg||left|400px|carte electroniques imprimées]]

====Comment souder des CMS ?====

les CMS sont des composants montés en surface c'est à dire qu'ils sont montés du même côté que les pistes cuivrées (à l'opposé des composants traversants) et sont de petite tailles souvent de l'ordre du millimètre. La taille est déterminée par 4 chiffres : les 2 premiers pour la longueur et les 2 derniers pour la largeur. On a du 1206,0805,0603 ou encore 0402. Il est même possible de trouver plus petit. A l'école nous utilisons souvent du 0603, c'est le cas de nos composants.
Pour souder des CMS 0603, il nous faut utiliser une autre méthode qui n'est pas le fer à souder :
# Préparer la veille la pâte à braser la veille (dans une seringue)
# Gommer la carte pour éviter l'oxydation (attention à ne pas retirer les miettes de gomme en soufflant dessus)
# Appliquer avec la seringue la pâte sur les empreintes et piste souhaitées. Pour les endroits difficile à atteindre ou avec 2 pistes proches les unes des autres, il est possible de mettre la même goutte de pâte sur les 2 pistes. Cela de causera pas de court-circuit par la suite. En effet, la pâte est composée d’alliage qui sous la chaleur va se fluidifier et se coller uniquement aux pistes métallique. Le reste fondera sous la chaleur du four.
# Appliquer les CMS sur la pâte au fur et à mesure (attention ! ne jamais toucher les CMS avec les doigts, tjrs utiliser une pince)
# Mettre au four

====Bilan soudure nrf52810====

Cependant, une fois le matériel nécessaire préparé, et la pâte mise sur les pistes souhaitées, au moment de déposer le composant, nous avons réalisé que celui-ci était beaucoup plus petit que l'empreinte sur le PCB. Il s'agit d'un composant boitier QFN48. Fritzing ne proposant au plus proche des boitiers QFN24 ou LQFP48, celui-ci a basculé automatiquement pour un boitier LQFN48, de dimension plus grande. Face à ce manque de vigilance, nous avions cependant commencer par le nrf52810 (composant concerné) évitant ainsi de gaspiller d'autres CMS.
Nous avons souhaité refaire la carte sous Altium à partir des fichiers fournis par le concepteur (chose que nous avons commencé à faire aux alentours de la semaine 5)
Après la réalisation du schématic, et de la modification des empreintes de capacités, inductances et autres composants de 0402 à 0603. Notre matériel ne permettant que des empreintes 0603.

Lors du routage, une erreur de chevauchement des pistes est notifiée par Altium au niveau du nrf52810. Celles-ci ne présentent pas d'angles et sont déjà de taille 8mil, il nous faut alors passer les pistes en 6mil. Mais 8mil est la taille minimale pour la production à Polytech, nous avons regardé pour envoyer les cartes à faire ailleurs mais le 6mil n'est pas beaucoup conseillé. De plus, il n'est peut-être pas judicieux de continuer avec le composant microcontrôleur-bluetooth Nrf52810 qui prend du temps, donc la carte est difficilement réalisable et peut-être très long à programmer.

Ainsi en cette fin de semaine, nous avons décider face à l'avancer du projet de laisser les nrf52810 de coté et de les remplacer par des modules sans fils plus simples d'utilisation et complets. Ainsi nous aurions plus de chance d'avoir une connexion sans fils entre les modules. Nous pourrions par exemples utiliser des Xbee, des modules Rf...

==Semaine 9==

====Programmation: PS4 et 1er Test SPI sur atmega328p====

'''Raspberry Pi Zero W et PS4'''

'''Modules Atmega328p et SPI'''

Une carte PCB arduino fonctionnant, nous pouvons la programme pour simuler un module. Celle-ci a été designée afin de s'adapter au module que l'on souhaite. Il suffit de brancher le bouton, le joystick ou autre élèment de manette souhaité.
Cette semaine ci, nous avons alors configurer la partie communication SPI pour l'arduino.

'''Que voulons-nous faire avec les atmegas ?'''
Les cartes électroniques atmega328p vont nous permettre de recevoir les requêtes SPI envoyées par la raspberry pi et d'y répondre. La Raspberry enverra un message, par exemple "1", et l'Arduino lira alors l'état du module qui lui est connecté. Une fois l'état récupéré elle le renvoie à la raspberry pi.

Durant cette semaine, nous avons programmé l'atmega afin qu'il soit en esclave, qu'il reçoive un de la RPi "1" et retourne une valeur sauvegardé "int envoi". Nous avons également commencé les tests pour la lecture de l'état d'un bouton (d'après les tests réalisés les semaines précédentes).

'''Code'''
Comme nous l'avons vu précedement lors de nos recherches (semaines 1 à 4) :
La communication SPI nécessite l'utilisation des pins:

MOSI -> GPIO11 //PB3 //master OUT to the slave IN
MISO -> GPIO12 //PB4 //slave OUT to the master IN
SCLK -> GPIO13 //PB5 //serial clock
SS -> GPIO10 //PB2 //slave select

Il faut également paramétrer l'atmega328p en Slave. On note que dans un premier temps, le programme sera codé avec l'arduino IDE (fichiers .ino). Une fois l'ensemble SPI RaspberryPi-Arduino fonctionnant, on remplacera ces codes par du langage C ou C++.

Pour faire la connexion SPI sur l'atmega328p, on utilise la librairie arduino SPI.h, on a alors directement les fonctions nécessaires intervenant sur les registres souhaités : SPCR (spi control register), SPSR (spi status register) et SPDR (spi data register).

#include <SPI.h>

Il est important d'initialise d'abord le setup et on active le port série pour pourvoir utiliser le moniteur série. (Cela servira à verifier la valeur envoyée par la RPi)

void setup (void)
{
Serial.begin (9600);
pinMode(MISO, OUTPUT); //configuration en esclave *master in slave out*
pinMode(buttonPin,INPUT); //config pin bouton
// turn on SPI in slave mode
SPCR |= _BV(SPE);
// preparation interruptions
pos = 0; // buffer empty
process_it = false;
// activation interruptions
SPI.attachInterrupt();
}

On oublie pas de déclarer les interruptions afin de bien lire la requête reçue.

// SPI interrupt routine
ISR (SPI_STC_vect)
{
byte c = SPDR; // grab byte from SPI Data Register
// add to buffer if room
if (pos < sizeof buf)
{
buf [pos++] = c;
// example: newline means time to process buffer
if (c == '\n')
process_it = true;
} // end of room available
} // end of interrupt routine SPI_STC_vect

Dans la loop main, on traite la requête et on utilise '''SPI.transfer(envoi);''' pour transferer à la RPi les données souhaitées.

Durant cette semaine, nous avons également commencé des programmes de test SPI pour la RPi. Il s'agit principalement de programmes de tests tout faits permettant de vérifier la connexion entre cette dernière et l'arduino. Par exemple, la RPI envoie "bonjour" et l'arduino lui retourne ce qu'elle reçoit, soit "bonjour". Sans succés alors.

====Electronique : Fritzing révision====

Lors de la semaine, le modèle PCB de la carte arduino a été réalisé de nouveau sous fritzing avec les broches et connections manquantes. Nous avons également revu la configuration du bouton reset et ajouté une led d'état de l'alimentation. Nous avons ainsi envoyé deux cartes identiques à la réalisation.
La carte déjà soudée lors des derniers jours fonctionnant, elle nous sert de prototype de programmation. Nous pouvons ainsi avancer à la fois sur la programmation des modules mais aussi sur leur réalisation.

==Semaine 10==

====Programmation : PS4 et SPI sur RPi====

'''Raspberry Pi Zero W et PS4'''

'''Modules Raspberry PI et SPI'''

Durant cette semaine, pour la partie Atmega328p-Modules, nous nous sommes concentrés sur la programmation de la communication SPI avec la raspberry pi. Cette semaine a permis une étude plus approfondit sur le fonctionnement pour la RPi.

On rappelle, comme vu des semaines 1 à 4, pour la RPI3 (tout comme la RPi Zero W) utilise les broches : SCLK (23), MISO(21), MOSI (19) et SPI CS0 (24), SPI CS1 (26).
On la programme en Master. A l'aide des fichiers tests d'inspiration, on pourra directement programmer la RPi en C. Lors de la réalisation du code, il y a 3 étapes : l'initialisation/parametrage en SPI pour être maître, l'envoie de la requête puis la réception de données en retour.

Programmant en C, il ne faut pas oublier les librairies suivantes :

#include <stdint.h>
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
#include <getopt.h>
#include <fcntl.h>
#include <sys/ioctl.h>
#include <linux/types.h>
#include <linux/spi/spidev.h> //pour SPI

On va déclarer des variables globales permettant le paramétrage :

static const char *device = "/dev/spidev0.0"; //si on veut CS0 pour atteindre notre SS
static uint8_t mode; //mode est par défaut à 0
static uint8_t bits = 8; //bits par mot échangé
static uint32_t speed = 500000;
static uint16_t delay;

Dans notre main, on ouvre le port (la connexion) au device souhaité, on vérifie les paramètres (registres, connexions...) puis exécute la fonction transfer(fd). transfer(fd) transmet la requête et s'occupe de la réception.

fd = open(device, O_RDWR);
transfer(fd);
close(fd);

==Semaine 11==

====Programmation: PS4, SSH et tests SPI (RPi3&Atemga328p)====

'''Raspberry Pi Zero W et PS4'''

'''Raspberry PI, Atmega328p et SPI'''

Afin de facilité la programmation en utilisant Ethernet, nous avons installer et configuré la RPi pour l'utiliser en SSH depuis les ordinateurs de la E306. En effet, SSH permet de se connecter à distance sur une machine en utilisant un compte utilisateur de la dite machine. En mettant ssh, on pourra directement agir sur les fichiers de la raspberry depuis un terminal de notre PC. Pour cela, on a d'abord vérifier l'adresse IP de notre raspberry pi : 172.26.145.106 avec un écran mais on peut aussi utiliser les commandes ip a et ifconfig. Puis activer le ssh sur la raspberry pi.
On modifie alors le fichier config.txt mais également etc/network/interfaces pour configurer la bonne interface Ethernet sur la raspberry pi.

[[Fichier: configSSH_raspi.png||left|300px|config ssh ethernet]]

Il nous suffit alors de taper la commande : ssh pi@172.26.145.106 pour accéder à notre RPi.

Nous avons continué à réaliser la communication SPI avec des tests entre une arduino UNO et la RPI3. Nous avons commencé par des tests simples inspirés des études de deux semaines précédentes et modulés selon notre utilité.
Nous arrivons alors à lire l'état envoyer "bonjour" et recevoir "ça va" ou encore "1" et recevoir "3". Il faut noter que le SPI échange des trames, la RPI reçoit alors des hexadécimaux.
Nous avons alors continué pour recevoir l'état du bouton ou du joystick lors de l'envoie de "1" sur l'Arduino328p. La semaine prochaine nous testerons ces même codes fonctionnels sur les cartes atmeg327p.

A la fin de cette semaine, nous avons alors des codes Arduino-SPI (.ino) et des codes Raspberry-SPI (.c) permettant l'échange de données. Le but est maintenant de l'adapter aux cartes imprimées et de le rendre pleinement fonctionnel pour plusieurs cartes à la fois, puis ajouter une boucle de vérification en continue jusqu'à une deuxième requête de la RPi.

====Electronique: réalisation au propres des PCB modules====

Suite à une nouvelle erreur de réalisation cartes électronique, nous avons refait et renvoyé à nouveau les cartes imprimées atmega328p.
Nous les souhaitons au propre pour une version finale. Une fois celle-ci imprimées nous pourrons en avoir 3 , un pour chaque module. Les cartes étaient bien imprimées en bottom mais lors du passage des traversants de bottom à top, le logiciel ne les a pas fait miroiter. Par manque d'attention nous avons alors envoyé les fichiers gerber pour des cartes ayant les composants du même coté que la couche de cuivre.
Les cartes électroniques actuelles sont alors correctes et fonctionnelles mais difficile à souder. Pour eviter les erreurs et continuer sur des prototypes de carte nous préférons attendre en nous concentrant sur la programmation PSI de la Raspberry Pi.

==Semaine 12==

====Programmation====

'''Raspberry Pi Zero W et PS4'''

'''Raspberry PI, Atmega328p et SPI'''

- réflexion: penser à faire boucler sur l'arduino une fois la requête reçu, ça veut dire que la manette est ON et donc vérifier continuellement les modules sur chaque atmega.
- SPI raspberry pi - arduino recuperation état du bouton avec les cartes modules (/!\ récuperation à faire dans une variable)

-SSH perso
adresse Rasppi: 192.168.137.10

====Electronique: Finalisation soudure Modules====

Soudure au propre et finale d'une carte atmega328p et donc envoie pour la réalisation de 2 autres cartes similaires et récupération de matériel
Soudure des 2 autres cartes, + tests sur les états = fonctionnelles.
On a donc bien 3 cartes pour les 3 modules de types différents (1 bouton, 1 joystick, 1 gachette)
PCB pour les 2 joysticks (qui serviront de thumbstick et gachette)

==Semaine 13 et plus==

====Programmation====

'''Raspberry Pi Zero W et PS4'''

'''Modules Atmega328p et SPI'''

====Electronique====

=Documents Rendus=

(à mettre rapport + git + drive)

=Datasheets=

IMA4 2017/2018 P35

2018-05-05T18:20:52Z

Tgracias : /* Semaine 3 : Début premier prototype */

__TOC__
 

=Présentation générale: Manette modulable=

==Description==

Tout le monde joue aux jeux vidéo cependant, les manettes ne sont pas adaptées aux personnes ayant un handicap pouvant toucher les bras ou les mains.
C’est le cas, de plusieurs patients dans les centres de soins et de rééducation.

Pour ce projet IMA4, nous travaillerons avec le centre SSR (soin de suite et de réadaptation) Marc Sautelet de Villeneuve d’Ascq.
Un adolescent, patient de Marc Sautelet, est passionné par les jeux vidéo. En effet, ayant perdu la motricité d’une partie de son corps, il ne peut pas jouer à deux mains. Pour cela, il bloque la manette entre son épaule et son coude, usant de la mâchoire et des doigts pour contrôler les
joysticks et les boutons. Cet exercice peut s’avérer fatiguant et pénible.

Ainsi, nous chercherons à concevoir une manette PS4 adaptée au handicap de l’adolescent.
Cette manette devra aussi être adaptée pour d’autres patients présentant également des handicaps moteurs. Ainsi nous prendrons pour cibles: tous les patients du centre voulant jouer; et non pas que les enfants et adolescents.

 

{| class="wikitable centre" width="80%"
|+
|-
| width="23%" |
Membre du projet
| width="34%" |
Transley Gracias et Camille Saad
|-
| width="23%" |
Cible
| width="34%" |
Patient présentant un handicap moteur
|-
|width="23%" |
Période du projet
| width="34%" |
janvier 2018 - mai 2018
|-
|width="23%" |
Partenaire/Client
| width="34%" |
Centre SSR Marc Sautelet à Villeneuve d'Ascq
|}

==Objectifs==

Ce projet a pour objectif de créer un prototype de manette qui puisse interagir avec la console PS4 et dont le paramétrage se fait à l’aide d’une application mobile et/ou web. Cette manette devra suivre les demandes du patient ainsi que des aides-soignantes du centre, dans la mesure du possible.

Plus précisément, pour le premier prototype, nous mettrons en œuvre l'utilisation de quelques boutons spécifiques:

* Un joystick (type L/R)
* Quelques boutons poussoirs (type Croix/Triangle/Carré/Rond/R1/L1/Start/...)
* Des boutons gâchettes progressives (type L2/R2).

Le but serait donc dans un premier temps de rendre fonctionnel un bouton de chaque type, puis de les multiplier une fois cela fait. Tous ces boutons réunis constituent une manette fonctionnelle.Ainsi, la manette sera ajustable, c’est à dire qu’elle devra s’adapter aux différents handicaps moteurs possibles.

=Analyse du projet=

==Positionnement par rapport à l'existant==

Notre prototype aura une présentation unique par rapport à l’existant. En effet, les concurrents et produits existants ciblent pour la majorité un seul handicap. Cela
engendre une solution fermée à beaucoup de patients. Notre projet propose une mobilité des mouvements et également un choix large dans la composition et le
design de notre manette.
Le patient n’est pas retreint à jouer à une seule main, à utiliser beaucoup de force...Il y a moins de technique dans la manipulation et on ne joue pas avec une
manette adaptée uniquement pour un droitier ou un gaucher. Cependant, cela nous limitera peut-être dans le choix possible des types de jeux. Tout comme les autres
manettes adapté, l’utilisateur nécessitera un peu d’entrainement.

==Analyse du premier concurrent==

Jouer aux jeux vidéo à une main n’est pas une idée d’aujourd’hui. En 1990, Nintendo propose le Power Glove. Mais il tombe très rapidement aux oubliettes suite à des problèmes techniques.

Un autre gant a fait son apparition quelques années plus tard. Celui-ci, plus technique, il faut office de manette Play Station: le Reality Quest Power Glove.Cette idée de manette-gant, permet de jouer à la PS avec une seule main, elle a était conçue et présentée pour les E3, un salon d’exposition de gaming.Le gant est conçu pour contrôler l’équivalent des 14 boutons et 2 joysticks à l’aide d’une seule main. La « manette » est fixée dans la pomme de la main. L’utilisateur contrôle les mouvements verticaux et horizontaux en pivotant le poignet, et utilisent les 4 boutons d’action principaux et L1/R1 avec les doigts. Les autres boutons sont accessibles par un seul bouton rond contrôlé par le pouce.
La manette est adaptée pour beaucoup de jeux vidéo, dont les plus simples sont les jeux de voitures et de combats (arcade).

; Problèmes:
*Besoin de toute la motricité de la main, c’est-à-dire que si le patient à un doigt paralysé ou manquant, il ne pourra pas jouer avec ce gant
*Design obligatoirement droitier
*Les boutons de contrôle sont peu sensibles et peuvent nécessiter de la force
*Design compliqué et nécessitant beaucoup d’entrainement.

;Lien : https://www.youtube.com/watch?v=qV0SxSJDCYg

 
==Analyse du second concurrent==

Ben Heck, de son vrai nom Benjamin J.Heckendorn, est un concepteur de mods de consoles (mods pour modification, soit « manettes modifiées ») et une star
du net grâce à ses vidéos tutoriels.Il propose alors énormément de produits adaptés ou dérivés en guise de manettes.
Parmi les mods qu’il a réalisé, il a modifié une manette de PS4 afin de la rendre accessible à une personne ne pouvant jouer qu’à une main. Pour cela, il a déplacé les boutons en respectant l’ergonomie de la main valide et modifie les connexions. Il peut lui arriver de rajouter des boutons pour en remplacer un autre. Il réalise également le même système avec la Xbox. Sur la photo ci-dessous, il a adapté la manette pour un droitier.

; Problèmes:
*Besoin de toute la motricité de la main, c’est-à-dire que si le patient à un doigt paralysé ou manquant, il ne pourra pas jouer avec cette ma
*Design obligatoirement droitier ou gaucher, une modification = une manette= une personne
*Besoin obligé du pouce et de l’index, même si avantage : 3 doigts nécessaire.

;Lien :: https://www.youtube.com/watch?v=LieHIscadjk

==Scénario d'usage du produit ou du concept envisagé==

La technologie est ,aujourd’hui, omniprésente dans notre vie. Les consoles de jeux ont envahies les maisons avec plus de 7 personnes sur 10 jouant aux jeux vidéos sur consoles en France (chiffre de l’Express). 0,18% des français sont handicapés cela représente 12 millions de français. Dans ce chiffre, 13,4% des personnes ont un handicap moteur. En 2017, les grands groupes comme Sony ou Microsoft avec respectivement PlayStation et Xbox ne permettent pas à tout le monde de jouer avec une manette. Les manettes sont prévues pour des personnes ayant leurs membres valides, plus précisément les mains et les bras.

Après un accident de voiture, un jeune garçon a perdu la motricité d’un côté du corps. Passionné de jeux vidéo, il se retrouve avec des difficultés à jouer sur sa console PS4. Ingénieux, il utilise la manette en la coinçant entre son épaule et le creux du cou. Usant de la mâchoire et de sa main valide pour contrôler les joysticks et les boutons. L'exercice étant inconfortable et fatiguant il eu l’idée de proposer à des futurs ingénieurs de lui proposer une manette adaptée à son handicap.

Les deux pré-ingénieurs ,avec leur tuteur, ont une idée révolutionnaire : La manette modulable ! Elle permettrait au jeune garçon, ainsi que d’autres joueurs, de pouvoir continuer de s’amuser ou même de commencer à jouer au jeux sur console.
Cette manette aidera fortement dans les centre de rééducation pour faire passer le temps et donner du plaisir à des personnes qui ne peuvent plus s’amuser avec leur console traditionnelle. Elle pourra aussi ouvrir de nouvelles possibilités pour certaines personnes qui n’auraient jamais essayé jusqu'à présent.
Comme son nom l'indique, elle sera modulaire et s'adaptera à différents handicaps. Accompagnée de son application d’initialisation, elle sera accessible aussi bien aux enfants, patients, parents et aides soignantes.

Quelques mois plus tard...Le jeune patient fan de Need For Speed, peut maintenant piloter sa voiture comme un vrai professionnel grâce à l'un des joysticks qu'il utilisera avec sa main valide et il pourra accélérer à des vitesses folles à l'aide de boutons poussoirs au niveau de son pied valide et gagner la partie. Son ami venu lui rendre visite, pourra en lieu et place des aides soignantes configurer à l'aide de la tablette (portable) la manette du patient.
Si le patient change de jeu pour Tekken et que la configuration des modules ne lui convient plus, il peut interchanger les éléments de la manette selon son envie et son confort. Ainsi il peut faire sauter son personnage, il utilisera un module bouton supplémentaire, qu'il actionnera avec le poing.

==Fonctionnement==

Suite à une analyse fonctionnelle et à la formulation de notre projet, nous avons pu définir le fonctionnement de notre système. Notre produit, la manette, doit être accessible d’après nos objectifs à différents types de handicaps moteurs. Ainsi, l’idéal serait de concevoir une manette modulable afin qu’elle puisse s’adapter à toutes les situations. Ce n’est plus au patient de s’adapter à la manette mais à la manette de s’adapter au patient.
Cela signifie que la manette sera, dans la limite du possible et de la sensibilité du corps du patient, composée de plusieurs parties dites « modules » comportant un ou plusieurs actionneurs (boutons, joysticks, gâchettes...). Ces modules seront déplaçables afin d’être utilisé avec différents membres du corps : un doigt, une main,
une jambe ou même un pied. Il suffira de les connectés entre eux suivant l’organisation souhaitée, le Gameplay du jeu ou en fonction du handicap. Le tout sera relié à une application.
L’application sera alors mise en place pour connecter les différentes parties du point de vue software pour prérégler la manette en fonction du patient. Il pourra alors choisir les boutons en fonction du jeu, de ses mouvements mais aussi choisir la sensibilité.

L’application et les modules devront être intuitifs et faciles d’utilisation. De cette manière des utilisateurs non avertis dans le domaine informatique ou jeunes pourront eux-mêmes gérer les connexions.

==Réponse à la question difficile==

'''Question : Comment interconnecter les différents modules de la manette ?'''

Il nous faut pour ce projet interconnecter les modules modélisant la manette qui seront connectés à la consoles PS4 via une Raspberry Pi 3.
Le choix de la Raspberry Pi 3 nous permet d'utiliser son module Bluetooth pour communiquer avec la PS4, ce choix est plus adaptée au projet que du filaire.
Concernant l'interconnexion des modules, nous travaillerons en deux étapes "preuves concept" : filaire et sans fils (Bluetooth).

'''Objectif 1 : Preuve concept filaire'''

Dans cette première partie de projet, nous souhaitons avoir une 1ère preuve de prototype rapidement. Nous nous concentrerons alors sur la communication entre la RPi3 et la PS4 ainsi que sur la conception des modules. Pour les modules, nous réaliserons des cartes électronique pour chaque module avec un micro-contrôleur. La communication filaire nous permettra d'interconnecter les modules à la RPi3 avec un bus SPI.

'''Objectif 2: preuve concept sans fils'''

Une deuxième étape du projet est la réalisation de la solution idéale sans fils. Celle-ci pourra commencer à être développée petit à petit en parallèle avec l'objectif 1. Le but ici, est d'interconnecter les modules en Bluetooth. Nous avons choisi le Bluetooth pour garder une connexion commune sur toute la chaîne.
Nous rajouterons alors un module bluetooth à chaque module de la manette.

'''Objectif 3: possibilité d'adapter les boutons (capuchon en 3D)'''

=Préparation du projet=

==Cahier des charges==

''Chef de projet:'' Alexandre Boé 
''Responsables:'' Xavier Redon, Thomas Vantroys 
''Partenariat:'' Marc Sautelet (non etablie) 
''Elèves-ingénieurs:'' Camille Saâd, Transley Gracias 

'''Sujet :''' Manette modulable pour personne à déficience moteur compatible PlayStation 4 

===Objectifs principal (1er POC) : ===
Faire transmettre des informations issus des actionneurs (ex:boutons poussoires) via des arduinos jusqu’à la Raspberry Pi 3 en SPI. 
Envoyer les données reçues vers la PS4 en USB 

===Objectifs secondaire (2e POC):===
Créer des modules avec un microcontrôleur et une puce bluetooth pour permettre une meilleurs flexibilité (c-àd pouvoirs avoir une meilleure ergonomie et une connexion sans fil) 
Connecter la Raspberry Pi 3 en Bluetooth à la PS4 

[[Fichier: beteacorne.jpg||middle|600px|Bete a corne manette]]

==Choix techniques : matériel et logiciel==

===Liste de matériel :===

'''Modules boutons/joysticks/gachettes'''

3 Push buttons : 
- O X Y Carré R3 L3 
- Guide PS 
- start/back 
--> 0,45€/unité TTC [https://www.gotronic.fr/art-bp-miniature-krs1273-16976.htm] 

1 Thumbstick original: 
Joystick analogique 4 directions --> 4,25€/unité TTC [https://www.gotronic.fr/art-joystick-analogique-4-directions-19063.htm] 

1 buttons trigger L1 L2 => 1x Thumbstick original''' 

'''Cartes Atmega328p /connexion spi/'''

3 Arduino UNO 
1 Arduino UNO atmega328p retirable 
4 capacite 22pF traversantes 
2 resistances 10 kOhm traversantes (à récupérer) 
2 oscillateurs quartz 16MHz traversante 
2 atmega328p-pu et support 

'''Cartes module bluetooth nrf52810 '''

6 capacités 100nF 0603 
6 capacités 12pF 0603 
2 capacités 4,7pF 0603 
2 capacités 1µF 0603 
2 capacités 100pF=0,1nF 0603 (à récupérer) 
2 capacités 0,8pF 0603 (a acheter, commande en cours) 
2 inductance 3,9nH 0603 (a acheter, commande en cours) 
2 oscillateur quartz 32 MHz 

''' Connexions et autres '''

1 Led RGB neopixel [https://www.adafruit.com/product/1734] 
1 Raspberry Pi 3 
--> ~36,23€/unité TTC [https://fr.rs-online.com/web/p/processor-microcontroller-development-kits/8968660/?src=raspberrypi] 
1 Raspberry Pi Zero W (commandée) [https://www.raspberrypi.org/products/raspberry-pi-zero-w/] 
6 Alimentations 5V ou 3,3V 
par exemple, 12 piles de type CR2016 3V rechargeables ou 24 piles AAA 1,5 V rechargeables
5 modules Bluetooth nrf de Nordic : nRF52810-QFAA-R 
--> 3,17€/unité + frais expédition [https://www.mouser.fr/productdetail/nordic-semiconductor/nrf52810-qfaa-r?qs=sGAEpiMZZMve4%2FbfQkoj%252bG%2FosjLoe2oghFQwQllMrQ4%3D]
5 Lignes broches mâles 

===Logiciels:===

- IDE arduino
- Altium
- FreeCAD ou Inkscape

==Liste des tâches à effectuer==

'''Etape 1 : Gestion du projet'''

* Définition des cahiers des charges fonctionnel et technique, choix d'orientation...
* Recherche techniques sur les différentes connexions possibles entre les modules, la RPi 3 et la console PS4
#Recherche connexion SPI entre les modules et la RPi3
# Recherche connexion bluetooth entre la RPi3 et la PS4
# Recherche connexion bluetooth pour les modules
# Recherche carte avec montage Atmega328P-PU et anticipation module bluetooth
* Détermination du matériel nécessaire
* Réflexion sur l'application

'''Etape 2: Réalisation du projet'''

'''Partie 1: Preuve concept manette en filaire'''

* Conception de cartes électroniques pour 2 modules (/!\ prévoir modules bluetooth)
* Réalisation connexion SPI avec 2 modules : programmation des Atmega328p en liaison série.
* Si tests concluant, ajouter des modules jusqu'à en avoir 5 (1 pour chaque type de boutons)
* Connexion bluetooth entre la PS4 et la RPi3
* Réalisation du support des modules avec fixations possibles (imprimante 3D)

'''Partie 2: Preuve concept manette en bluetooth'''

* Ajout des modules bluetooth aux cartes électroniques
* Connexion bluetooth entre les modules

'''Partie 3: Application Android : paramétrage de la manette'''

* Créer une application sur tablette ou smartphone (Android) afin de configurer la manette aux besoins (inter-connexion des modules et console)

==Calendrier prévisionnel==

{| class="wikitable centre" width="80%"
|+
|-
| width="23%" |
'''Date'''
| width="34%" |
'''Tache à réaliser''' 
|-
| width="23%" |
17/01/18-24/01/18
| width="34%" |
Faire des recherches sur les différentes interconnexions du système : Bluetooth, RPi-Atmega328 (SPI), RPi-PS4
Continuer liste des taches, matériel, Début recherches + réflexion fixation support des modules
|-
|width="23%" |
31/01/18
| width="34%" |
Recherche technique connexion PS4-RPi3 et connexion SPI RPi3-Module + code
|-
|width="23%" |
31/01/18-07/03/18
| width="34%" |
Réalisation 1er prototype (+ début prototype 2)
|-
|width="23%" |
07/03/18
| width="34%" |
Seance 7 : Test prototype filaire
|-
|width="23%" |
07/03/18-09/05/18
| width="34%" |
Réalisation 2eme prototype + application Android
|-
|width="23%" |
09/05/18
| width="34%" |
Seance 14 : Test prototype Bluetooth
|-
|width="23%" |
14/05/18
| width="34%" |
Video projet
|-
|width="23%" |
15/05/18
| width="34%" |
Finalisation projet et Rapport
|-
|width="23%" |
16/05/18-17/05/18
| width="34%" |
Soutenances Projet
|}

=Réalisation du Projet=

==Feuille d'heures ==

Voici le tableau d'heures du binôme:

{| 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 S11 !! Heures S12 !! Heures S13et+ !! Total
|-
| Analyse du projet
| 10
| 2
| 1
| 1
| 1
|
|
|
|
|
|
|
| 20min
|
| 15h20
|-
| Cherches techniques
|
| 3
| 4
| 4
| 2
| 2
| 1
|
|
|
| 1
| 1
|
|
| 18
|-
| Rédaction du wiki et rapport de projet
|
| 1
| 1
| 1
| 1
| 30min
| 1
|
| 2
| 30min
| 30min
|
| 2
|
| 10h30
|-
| Programmation
|
|
|
|
| 3
| 2
| 3
| 5
| 4
| 7
| 8
| 6
| 5
|
| 43
|-
| Cartes électroniques
|
|
|
|
|
| 6
| 8
| 4
| 6
| 2
| 1
| 2
| 2
|
| 31
|-
| Application
|
|
|
|
|
|
|
|
|
|
|
|
|-
|-
| Total Semaine
| 10
| 6
| 6
| 6
| 7
| 10h30
| 13
| 9
| 12
| 9h30
| 10h30
| 9
| 9h20
|
| '''117h50'''
|}

==Prologue==

Avant la réalisation et conception d'un projet, il est important d'analyser celui-ci. Nous avons allons consacré le prologue à l'analyse fonctionnelle de la manette. Nous avons également eu une réflexion sur l'analyse technique, cela nous a permis de réaliser une liste de matériel. Il est important de définir les objectifs ainsi que les besoins afin de ne rien oublier. (Voir ci-dessus Analyse projet)
Nous avons également organisé notre travail, pour le partage de documents de recherches et la rédaction de compte-rendu final nous avons réalisé un google drive. Par la suite, nous créerons un projet Git.

Durant ce temps, nous avons décidé de réaliser 5 modules. Les modules sont les différents boutons de la manettes qui nous pourrons placer selon nos choix (boutons modulaires) pour notre prototype projet pour chaque type des boutons d'une manette PS4. Ces modules devrons être connectés à la console et interconnectés. Le tout sera lié à une application Android. Suite à quelques recherches et nos analyses, nous avons décidé les points suivants :

- On commencera avec 2 modules et on les multipliera par la suite.
- Les premiers tests sont réalisés avec des boutons petits pour assurer leur caractéristique "modulaires", par la suite nous pourrons ajouter des capuchons de taille plus importante (imprimante 3D ou achat)
- Conception modules : réalisation de carte avec un microcontrôleur atmega328 programmable pour chaque module (anticiper le module Bluetooth)
- Projet en 2 parties : prototype filaire et prototype Bluetooth
# Prototype filaire : connexions entre les modules et la RPi3 en SPI, connexion Rpi3-PS4 en Bluetooth, avec l'application en filaire à la RPi3
# Prototype Bluetooth: connexion Bluetooth entre modules-RPi3-PS4-apllication

[[Fichier: structuremanette.png||center|400px|Concept manette modulable]]

==Semaine 1==

Durant la séance, nous nous sommes concentrés les recherches afin de définir clairement le cahier des charges technique. Il s'agit des réalisations à mettre en œuvre pour les inter-connexions des éléments de la manette.
Ainsi, nous avons fait des recherches sur :

===Connexion SPI entre les modules (Atmega328p) et la RPi3===

SPI: Serial périphérique interface BUS

[[Fichier: yWGmW.png||right|200px|Concept manette modulable]]
Comme indiqué sur l'image ci-dessus, la Raspberry pi 3 peut communiquer en SPI avec ses broches CS0 (24), CS1 (26), SCLK (23), MISO (21), MOSI (19). Celles-ci permettent de communiquer avec un ou plusieurs esclaves (dans notre cas, des Atmega328p) en reliant directement les broches concernées de la RPi3 à celles des composants esclaves.
Chaque broche CS0 (24) ou CS1 (26) ne peut être connectée qu'à l'entrée SS (aussi appelé CS) d'un seul esclave.
C'est a dire que chaque CS est lié à un esclave afin de choisir avec lequel la communication est établie à un moment donné, et les MISO sont reliées entre elles en cascade, de même pour les SCLK et les MOSI. On peut noter que le maître impose la fréquence d’horloge et sélectionne l’esclave auquel les données sont envoyées. 8 MHz est le plus rapide supportable a 3,3V

[[Fichier: fonctionnementSPI.png||right|200px|Connexion SPI multi-esclaves]]

Voici un schéma du fonctionnement souhaité :

Comme nous souhaitons avoir 5 modules environ il nous faudra rajouter un composant en plus afin d'augmenter les possibilités de sélection, par exemple des démultiplexeurs.
Dans un premier temps nous essaierons avec 2 esclaves, puis on augmentera le nombre.

===Connexion Bluetooth PS4-RPi3===

Les recherches portent également sur la connexion entre la manette PS4 et la console. Elles concernent le protocole de communication via Bluetooth

Caracteristique pour la PS4: Bluetooth®v4.0, Qualcomm Atheros AR3002 Buetooth LE: 2,4-2,5 GHz 

Caracteristique de la connexion : 

*Vitesse de transmission >> 3 Mbit/s 8N1
*Relevé tous les 1.3 millisecond (peut-être)
*Chaque manette à une adresse unique BD_ADDR qui correspond à l’adresse MAC de la carte Réseau
*Protocole de détection est le SDP basé sur une emission reception PDU
*L’Attribut ID est representer en TLV Type Length Value
*Communication HCI ACL Data Packet

===Rélisation des cartes électroniques===

matériel nécessaire pour un PCB : 

*breadboard
*câbles
*1 x 10k Ohm résistance
*Quartz 16Mhz clock crystal
*2 x 22 pF capaciteurs
*Atmega328P-PU

Ressources:
[[https://www.arduino.cc/en/Main/Standalone]]
[[http://www.eprojectszone.com/atmega-328-pu-standalone/]]
[[https://www.arduino.cc/en/Tutorial/ArduinoToBreadboard]]

==Semaine 2==

Durant la semaine deux et durant la séance, nous avons continué et approfondie nos recherches sur le projet. Nous avons pu ainsi affiner nos taches de réalisation et donc notre cahier des charges.

===Connexion aux modules: SPI et Bluetooth ===

 CORRIGER

voir https://peip-ima.plil.fr/mediawiki/index.php/BE_2017-2018#Configuration_du_syst.C3.A8me_embarqu.C3.A9

(sudo apt-get install pi-bluetooth)

''connexion sur la raspberry par ssh:''
su
update-rc.d ssh enable
invoke-rc.d ssh start
ssh pi@172.26.79.1XX

''bluetooth''
bluetoothctl
agent on
default-agent
scan on
pair [device Bluetooth address] (exemple: pair XX:XX:XX:XX:XX:XX )

''NOUVELLE REFLEXION : Connexion SPI entre les modules (Atmega328p) et la RPi3 --> MODULES BLUETOOTH''

Si multi-esclaves= plusieurs modules :
Il faut ajouter des sélections pour les SPI → démultiplexeurs OU ne pas utiliser les CS0 et CS1, et plutôt des pins entrée/sortie de la RPi3 lié au SS comme ça on choisit direct le module esclave voulu.

'''IMPORTANT:''' Nous avons étudié à nouveau la datasheet de notre module bluetooth nrf de Nordik. Le module bluetooth comporte déjà un microprocesseur !
Un module plutôt peut donc jouer le rôle de notre atmega328p. Il n'y a alors pas besoin de réaliser des cartes électroniques de type arduino standalone. Nos PCB regrouperont alors uniquement l'alimentation, un actionneur (bouton, joystick), le module bluetooth et les broches de connexion si besoin...

Cette séance nous a alors permise de revoir entièrement le matériel nécessaire. Notre liste de matériel nous semble alors plus réfléchie et limitée au nécessaire.

===Connexion Bluetooth PS4-RPi3===

Suite à nos recherches de la semaine précédente, nous avons sélectionné deux sites bien renseignés :

SITES

Ils nous ont permis de comprendre la communication entre la manette et la console. En effet, ils nous expliquent les échanges de trames Bluetooth.
EXPLICATIONS 1 exemple 

==Semaine 3 : Début premier prototype==

*'''Connexion SPI RPi3-Arduino'''

Comme vu durant les semaines précédentes, nous souhaitons réaliser une connexion Multi-esclaves en SPI entre la Raspberry pi et plusieurs modules.
Cette semaine nous avons vu que la réalisation de notre premier prototype doit aller vite. Il ne nous est pas nécessaire d’attendre les modules bluetooth si il nous faut dans cette partie uniquement utiliser son microprocesseur. Ainsi pour chaque module nous utilisons une arduino UNO. Nous réaliserons les programmes en C afin de pouvoir les réutiliser avec les modules bluetooth par la suite.
Une fois la connexion réalisable nous adapterons les programmes aux modules bluetooth Nordik. En effet, ceux-ci comporte déjà un microprocesseur, le module peut jouer le rôle de notre atmega328p. Il n'y a aurait alors pas besoin de réaliser des cartes électroniques arduino standalone sur PCB, mais directement des cartes électronique avec le module et le module voulu (bouton, joystick...) et l'alimentation.
Durant la séance nous avons alors revu la liste de matériel nécessaire.

[[Fichier: prototype1.jpeg||center|600px|connexion filaire prototype 1 filaire arduino]]

Durant la séance, nous avons recherches des exemples de codes et de librairies pour Arduino SPI et RaspberryPI SPI.

Nous avons également commencé le programme de la connexion SPI pour l'arduino et récupéré les bibliothéques SPI.h avec SPI.c. Nous nous sommes alors concentrer à les comprendre, pour pouvoir l'utiliser.

*'''Réalisation du projet Git'''

Création du projet IMA4_Projet35_ManetteModulable sur Git et partage de celui-ci.
Les premiers dossier crées durant la séance :
-Arduino (connexion SPI arduino) : ProtoSpi.c + dossier librairie SPI + Makefile
-RPI (dossier codes pour Rpi)
-Readme.md

Le site qui détaille le protocole Bluetooth PS4n'est pas complet et de plus n'ayant pas accès à une PS4 (pour le moment) nous avons décidé de commencer par une connexion USB (pour laquelle on dispose de toutes les informations) et qu'on pourra tester plus facilement.

==Semaine 4==

Pour le prototype 1 FILAIRE nous réaliserons les étapes suivantes :

#Réalisation du programme SPI pour arduino
#Réalisation du programme SPI pour la RPi
#Connexion USB avec la PS4 ou ordinateur
#Réalisation de cartes électroniques atmega328p-pu standalone (remplacer les Arduinos)
#Remplacer les "PCB arduino" par le module bluetooth et adapter la connexion
#Conception 3D de la délimitation 1 axe pour le joystick "gâchette"
#Réalisation de l'application Androïde.

Une fois ces étapes réalisées nous auront alors une preuve de concept filaire et nous pourrons alors passer à une connexion bluetooth.
Le passage à la connexion bluetooth sera le deuxième prototype et le cas idéal de la réalisation de la manette modulable.

===Mise à jour Matériel===

- Modéliser les boutons gâchettes L1/2 R1/2 de la manette PS4 (boutons sensibles à la pression) --> un joystick dont nous bloquerons un axe (imprimante 3D)
- Remplacer la RPi 3 par une Rpi zero W qui nous permettrait de réaliser plus facilement une connexion USB tout en gardant l'avantage du bluetooth.
- Choix de l’alimentation pour les 5 modules Bluetooth: nécessitent 3V --> utiliser des piles rechargeables 1,2V AAA plutôt que piles rondes 3V.

Nous avons également besoin du matériel cité en semaine 1 pour réaliser des cartes électroniques atmega328p-pu standalone. ( nous revenons alors sur les décisions de la semaine 3)

===Connexion SPI RPi3-Arduino===

Montage Raspberrypi et 1 arduino en PSI + 1 bouton + 1 led.
Voici le choix des branchements :

MASTER = RPi
SLAVE= Arduino

'''SPI sur Arduino:'''
MOSI -> GPIO11 //PB3 //master OUT to the slave IN
MISO -> GPIO12 //PB4 //slave OUT to the master IN
SCLK -> GPIO13 //PB5 //serial clock
SS -> GPIO10 //PB2 //slave select
'''Led, bouton et autre...'''
LED --> GPIO6 //PD6
GND
+5V (if required)
'''SPI sur la Raspberry Pi'''
SPIO MOSI -> PIN19
SPIO MISO -> PIN21
SCLK -> PIN23
SPIO CS0 -> PIN24

Continuation du code pour faire clignoter Led branchée à une arduino depuis la Rpi, en connexion SPI.

===Connexion USB PS4-RPi3===

Durant la séance, nous avons regardé comment utiliser le port série sur la RPi3, soit utiliser les UART.

Nous avons réaliser qu'il n'était pas aussi simple d'utiliser le port serie USB de la Raspberry Pi 3, en effet le SoC est un BCM2837 .
De plus nous ne pouvons pas utiliser le même port pour l'alimentation et la connexion.

Une des solutions à cette difficulté serait d'utiliser une RPi ZERO W à défaut d'une RPi 3. On pourrait alors avoir un port d'alimentation avec connexion USB mais également retrouver la connexion bluetooth dont nous avons besoin.

==Semaine 5==

===Programmation: Réflexion définitives prototypes filaire ===

Durant la semaine 5, nous avons continué la réalisation du prototype filaire par l'avancé du code SPI ainsi que les recherches concernant le protocole PS4.

Pour réaliser la connexion entre la PS4 et les différents modules, nous avons vu la semaine dernière que nous utiliserons une RPi zero W (que nous avons commandé). Celle-ci nous permet d'utiliser le bluetooth mais elle nous permet également de réaliser un réseau local sans fil. Ce qui peut être pratique dans la mesure où notre projet est modulable.
En attendant la réception de la commande, nous nous sommes penché sur les programmes et la configuration nécessaire à l'utilisation de la RPi zero W.

===Electronique===

[[Fichier: bouton_c1.jpg|100px|thumb|left|PCB bouton]]
[[Fichier: arduinobb.jpg|200px|thumb|right|atmega328p-pu branchement test]]

Du coté électronique, nous avons réalisé sur fritzing certaines cartes électroniques. Les Arduino Uno servant actuellement de test, seront remplacées par des PCB atmega328p-pu standalone avec des broches permettant les branchements nécessaires SPI ou encore aux modules "boutons/joystick". Pour les boutons, nous avons également réalisé un pcb afin de faciliter les branchements.

Il nous faut alors également une 3eme carte qui nous sera nécessaire pour la réalisation du prototype sans fil. Dans notre liste de matériel, nous avons des composants nrf52810 bluetooth, ceci doivent être soudé avec les capacités de protection mais également des broches de communication. Nous avons alors commencé cette carte électronique sur Altium avec le fichier projet PCB du distributeur à modifier.

[[Fichier: Arduino_c1.jpg|100px|thumb|center|PCB atmega328p-pu]]

=== Construction 3D ===

Enfin, nous avons commencé à réaliser des boîtiers 3D pour certains modules. Par exemple, comme nous l'avions vu précédemment, un des joysticks servira de bouton-gâchette en utilisant un seul de ses axes. Il nous faut alors réaliser un boitier qui bloque l'un des axes, mais également une tige qui nous permettra de pousser le joystick de manière simplifiée.

==Semaine 6==

===Programmation: configuration RPi Zero W ===

Ayant reçu la Raspberry Pi zero W en début de semaine, nous nous sommes concentrés sur la programmation et la configuration de celle-ci.

===Electronique: PCB nrf52810===

Les cartes réalisées en semaine 5 sont validées et en attente de réalisation.

Cette semaine a permis la réalisation et la finalisation de la carte électronique nrf52810. Il nous a fallu recommencé cette carte deux fois. En effet, une fois finie sur Altium nous avons réalisé que les empreintes des CMS sur PCB fourni par le constructeur ne correspondent pas au matériel CMS de l'école. Face à cette inattention de notre part, nous avons décidé de refaire entièrement la carte électronique sur fritzing. Ayant la datasheet et des plans d'inspiration PCB, nous avons pu refaire la carte entièrement.
Sur celle-ci nous avons ajouté des broches de connexion au besoin, un branchement Jtag et ICSP pour la programmation et la connexion SPI.
La carte est en attente de validation, puis validation.

[[Fichier: nrf52810_circuit2.jpg||center|400px|PCB carte nrf52810]]

===Révision matériel ===

Pour la réalisation de nos composants électroniques, il nous a fallu faire une révision des composants disponibles à l'école:
(les quantités indiquées ci-dessous pourront être augmentée si nécessaire,pour avoir dans l'idéal un module de chaque type de la manette, ici on se concentre sur BOUTON et JOYSTICK)

'''Cartes Arduino:'''
* 4 capacite 22pF traversantes
* 2 resistances 10 kOhm traversantes (à récupérer)
* 2 oscillateurs quartz 16MHz traversante
* 2 atmega328p-pu et support

'''Cartes nrf52810'''
* 6 capacités 100nF 0603
* 6 capacités 12pF 0603
* 2 capacités 4,7pF 0603
* 2 capacités 1µF 0603
* 2 capacités 100pF=0,1nF 0603 (à récupérer)
* 2 capacités 0,8pF 0603 (commande en cours)
* 2 inductance 3,9nH 0603 (commande en cours)
* 2 oscillateur quartz 32 MHz

'''Cartes modules Boutons'''
* un sachet de broches mâles (qu'on utilisera également pour les autres cartes, à récupérer/acheté)

Nous avons alors mis-à-jour la liste de composant située plus haut, ainsi que celle de la page IMA4 2017/2018 [https://projets-ima.plil.fr/mediawiki/index.php/Projets_IMA4_SC_%26_SA_2017/2018]

==Semaine 7==

===Programmation: connexion wifi RPi Zero W et Bootloader sur Atmega328p-pu ===

Pendant cette semaine, nous avons continué la programmation et la configuration des Raspberry Pi 3 et Zero W afin de les utiliser en connexion Wifi.

Nous avons également continuer les programmes de récupération de données : état des boutons et du joystick. Ces programmes sont appliqué sur l'atmega328p-pu standalone sur la plaque d'essai en attendant que le PCB soit opérationnel.
Pour pouvoir programmer l'atemega328p-pu comme une arduino UNO, il nous faut suivre plusieurs étapes :

'''1.Flasher le Bootloader'''
Nous avons 2 Atmega328p-pu neufs, ainsi il nous faut flasher le bootloader sur chacun d'eux afin de pouvoir les utiliser et les programmer sur une breadboard dans un montage minimaliste arduino-standalone.
Pour cela, on peut utiliser une carte arduino UNO. On vérifie le port et le type de carte sélectionnés dans le menu >Outils. Sur cette carte on téléverse le fichier arduinoISP.ino qui se trouve dans les exemples en étant en progrmamateur AVr ISP mkll (>outils>programmateur)
Puis on met l'atmega328p-pu qui nous intéresse sur le suppor socket de la carte. On change de nouveau le programmateur pour Arduino as ISP et on fait >tools>burn bootloader, soit >graver la sequence d'initialisation.
Ces étapes faites, on peut retirer notre microcontroleur et le replacer correctement dans le montage.

'''2.Programmation atmega328 sur breadboard'''
Une fois l'atmega328p-pu préparé, on peut le programmer. On peut le faire simplement à l'aide de la carte arduino UNO utilisée précédemment.On branche les Tx et Rx en commun ainsi que le reset, le GND et le VCC.

Nous avons réaliser des codes basiques tels que le clignotement d'une led rouge ou encore l'affichage de "hello world" sur le moniteur série pour vérifier la bonne fonctionnalité du montage. Cela fait nous avons pu écrire sous Arduino IDE le code de lecture des états.

[[Fichier: montage_BB_test.jpg||left|200px|programmation modules arduino sur breadboard]]

===Electronique : soudure carte de test modules ===

Comme nous l'avons déja vu lors de la réalisation des PCB, si l'on souhaite programmer un atmega328p-pu en bootloader, le montage est simple. Il peut être minimaliste en utilisant une arduino UNO, un atmega328, une breadboard et 3 composants: 1 quartz 16MHZ crystal, 1 résistance 10kOhm et 2 capacitors céramiques de 22pF.
Durant la semaine 7, nous avons soudé les composants traversants de la carte électronique correspondant à ce montage ainsi que le PCB du bouton.

==Semaine 8==

===Programmation ===

===Electronique : Correction soudure et soudure CMS===

Durant cette semaine, nous avions souhaité programmer la carte électronique atmega328p-pu. Cependant, nous avons réaliser que nous avions fait une erreur lors de l'envoie du PCB à la production. En effet, celui-ci avait été fait en Top sur le logiciel Fritzing et non en Bottom. Hors nous avions soudé les composants (durant la semaine 7) comme pour un circuit imprimé en bottom, l'atmega328p-pu se retrouve alors inversé par rapport aux pistes.
Comme solution, nous avons choisi de souder un deuxième support pour l'atmega328 de l'autre coté de la carte avant de la refaire au propre. En effet, avant de la refaire il nous faut vérifier si la carte est bien programmable.
Une fois cela fait nous avions pu programmer la carte mais, nous avions également réalisé la pin 2 de l'atmega328 était prise par le bouton poussoir. Or, nous avons besoin des pin 2 et 3 pour le RX et TX permettant la programmation de l'atmega à partir d'une arduino, les pistes branchement RX-TX n'ont également pas été prévus pour le téléversement des programmes sur la carte. Il nous faut alors couper une piste et souder des câbles pour utiliser toutes les pistes souhaitées.

[[Fichier: correction_proto_PCB.jpg||right|300px|PCB arduino correction]]

Durant cette semaine, nous avons également souhaité souder les CMS et le composant bluetooth nrf52810 sur la carte imprimé et reçu lors de la semaine 7. Pour cela, nous avons convenu de travailler dans la C202 durant la séance du mercredi.

[[Fichier: PCB_nrf52810.jpg||left|400px|carte electroniques imprimées]]

====Comment souder des CMS ?====

les CMS sont des composants montés en surface c'est à dire qu'ils sont montés du même côté que les pistes cuivrées (à l'opposé des composants traversants) et sont de petite tailles souvent de l'ordre du millimètre. La taille est déterminée par 4 chiffres : les 2 premiers pour la longueur et les 2 derniers pour la largeur. On a du 1206,0805,0603 ou encore 0402. Il est même possible de trouver plus petit. A l'école nous utilisons souvent du 0603, c'est le cas de nos composants.
Pour souder des CMS 0603, il nous faut utiliser une autre méthode qui n'est pas le fer à souder :
# Préparer la veille la pâte à braser la veille (dans une seringue)
# Gommer la carte pour éviter l'oxydation (attention à ne pas retirer les miettes de gomme en soufflant dessus)
# Appliquer avec la seringue la pâte sur les empreintes et piste souhaitées. Pour les endroits difficile à atteindre ou avec 2 pistes proches les unes des autres, il est possible de mettre la même goutte de pâte sur les 2 pistes. Cela de causera pas de court-circuit par la suite. En effet, la pâte est composée d’alliage qui sous la chaleur va se fluidifier et se coller uniquement aux pistes métallique. Le reste fondera sous la chaleur du four.
# Appliquer les CMS sur la pâte au fur et à mesure (attention ! ne jamais toucher les CMS avec les doigts, tjrs utiliser une pince)
# Mettre au four

====Bilan soudure nrf52810====

Cependant, une fois le matériel nécessaire préparé, et la pâte mise sur les pistes souhaitées, au moment de déposer le composant, nous avons réalisé que celui-ci était beaucoup plus petit que l'empreinte sur le PCB. Il s'agit d'un composant boitier QFN48. Fritzing ne proposant au plus proche des boitiers QFN24 ou LQFP48, celui-ci a basculé automatiquement pour un boitier LQFN48, de dimension plus grande. Face à ce manque de vigilance, nous avions cependant commencer par le nrf52810 (composant concerné) évitant ainsi de gaspiller d'autres CMS.
Nous avons souhaité refaire la carte sous Altium à partir des fichiers fournis par le concepteur (chose que nous avons commencé à faire aux alentours de la semaine 5)
Après la réalisation du schématic, et de la modification des empreintes de capacités, inductances et autres composants de 0402 à 0603. Notre matériel ne permettant que des empreintes 0603.

Lors du routage, une erreur de chevauchement des pistes est notifiée par Altium au niveau du nrf52810. Celles-ci ne présentent pas d'angles et sont déjà de taille 8mil, il nous faut alors passer les pistes en 6mil. Mais 8mil est la taille minimale pour la production à Polytech, nous avons regardé pour envoyer les cartes à faire ailleurs mais le 6mil n'est pas beaucoup conseillé. De plus, il n'est peut-être pas judicieux de continuer avec le composant microcontrôleur-bluetooth Nrf52810 qui prend du temps, donc la carte est difficilement réalisable et peut-être très long à programmer.

Ainsi en cette fin de semaine, nous avons décider face à l'avancer du projet de laisser les nrf52810 de coté et de les remplacer par des modules sans fils plus simples d'utilisation et complets. Ainsi nous aurions plus de chance d'avoir une connexion sans fils entre les modules. Nous pourrions par exemples utiliser des Xbee, des modules Rf...

==Semaine 9==

====Programmation: PS4 et 1er Test SPI sur atmega328p====

'''Raspberry Pi Zero W et PS4'''

'''Modules Atmega328p et SPI'''

Une carte PCB arduino fonctionnant, nous pouvons la programme pour simuler un module. Celle-ci a été designée afin de s'adapter au module que l'on souhaite. Il suffit de brancher le bouton, le joystick ou autre élèment de manette souhaité.
Cette semaine ci, nous avons alors configurer la partie communication SPI pour l'arduino.

'''Que voulons-nous faire avec les atmegas ?'''
Les cartes électroniques atmega328p vont nous permettre de recevoir les requêtes SPI envoyées par la raspberry pi et d'y répondre. La Raspberry enverra un message, par exemple "1", et l'Arduino lira alors l'état du module qui lui est connecté. Une fois l'état récupéré elle le renvoie à la raspberry pi.

Durant cette semaine, nous avons programmé l'atmega afin qu'il soit en esclave, qu'il reçoive un de la RPi "1" et retourne une valeur sauvegardé "int envoi". Nous avons également commencé les tests pour la lecture de l'état d'un bouton (d'après les tests réalisés les semaines précédentes).

'''Code'''
Comme nous l'avons vu précedement lors de nos recherches (semaines 1 à 4) :
La communication SPI nécessite l'utilisation des pins:

MOSI -> GPIO11 //PB3 //master OUT to the slave IN
MISO -> GPIO12 //PB4 //slave OUT to the master IN
SCLK -> GPIO13 //PB5 //serial clock
SS -> GPIO10 //PB2 //slave select

Il faut également paramétrer l'atmega328p en Slave. On note que dans un premier temps, le programme sera codé avec l'arduino IDE (fichiers .ino). Une fois l'ensemble SPI RaspberryPi-Arduino fonctionnant, on remplacera ces codes par du langage C ou C++.

Pour faire la connexion SPI sur l'atmega328p, on utilise la librairie arduino SPI.h, on a alors directement les fonctions nécessaires intervenant sur les registres souhaités : SPCR (spi control register), SPSR (spi status register) et SPDR (spi data register).

#include <SPI.h>

Il est important d'initialise d'abord le setup et on active le port série pour pourvoir utiliser le moniteur série. (Cela servira à verifier la valeur envoyée par la RPi)

void setup (void)
{
Serial.begin (9600);
pinMode(MISO, OUTPUT); //configuration en esclave *master in slave out*
pinMode(buttonPin,INPUT); //config pin bouton
// turn on SPI in slave mode
SPCR |= _BV(SPE);
// preparation interruptions
pos = 0; // buffer empty
process_it = false;
// activation interruptions
SPI.attachInterrupt();
}

On oublie pas de déclarer les interruptions afin de bien lire la requête reçue.

// SPI interrupt routine
ISR (SPI_STC_vect)
{
byte c = SPDR; // grab byte from SPI Data Register
// add to buffer if room
if (pos < sizeof buf)
{
buf [pos++] = c;
// example: newline means time to process buffer
if (c == '\n')
process_it = true;
} // end of room available
} // end of interrupt routine SPI_STC_vect

Dans la loop main, on traite la requête et on utilise '''SPI.transfer(envoi);''' pour transferer à la RPi les données souhaitées.

Durant cette semaine, nous avons également commencé des programmes de test SPI pour la RPi. Il s'agit principalement de programmes de tests tout faits permettant de vérifier la connexion entre cette dernière et l'arduino. Par exemple, la RPI envoie "bonjour" et l'arduino lui retourne ce qu'elle reçoit, soit "bonjour". Sans succés alors.

====Electronique : Fritzing révision====

Lors de la semaine, le modèle PCB de la carte arduino a été réalisé de nouveau sous fritzing avec les broches et connections manquantes. Nous avons également revu la configuration du bouton reset et ajouté une led d'état de l'alimentation. Nous avons ainsi envoyé deux cartes identiques à la réalisation.
La carte déjà soudée lors des derniers jours fonctionnant, elle nous sert de prototype de programmation. Nous pouvons ainsi avancer à la fois sur la programmation des modules mais aussi sur leur réalisation.

==Semaine 10==

====Programmation : PS4 et SPI sur RPi====

'''Raspberry Pi Zero W et PS4'''

'''Modules Raspberry PI et SPI'''

Durant cette semaine, pour la partie Atmega328p-Modules, nous nous sommes concentrés sur la programmation de la communication SPI avec la raspberry pi. Cette semaine a permis une étude plus approfondit sur le fonctionnement pour la RPi.

On rappelle, comme vu des semaines 1 à 4, pour la RPI3 (tout comme la RPi Zero W) utilise les broches : SCLK (23), MISO(21), MOSI (19) et SPI CS0 (24), SPI CS1 (26).
On la programme en Master. A l'aide des fichiers tests d'inspiration, on pourra directement programmer la RPi en C. Lors de la réalisation du code, il y a 3 étapes : l'initialisation/parametrage en SPI pour être maître, l'envoie de la requête puis la réception de données en retour.

Programmant en C, il ne faut pas oublier les librairies suivantes :

#include <stdint.h>
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
#include <getopt.h>
#include <fcntl.h>
#include <sys/ioctl.h>
#include <linux/types.h>
#include <linux/spi/spidev.h> //pour SPI

On va déclarer des variables globales permettant le paramétrage :

static const char *device = "/dev/spidev0.0"; //si on veut CS0 pour atteindre notre SS
static uint8_t mode; //mode est par défaut à 0
static uint8_t bits = 8; //bits par mot échangé
static uint32_t speed = 500000;
static uint16_t delay;

Dans notre main, on ouvre le port (la connexion) au device souhaité, on vérifie les paramètres (registres, connexions...) puis exécute la fonction transfer(fd). transfer(fd) transmet la requête et s'occupe de la réception.

fd = open(device, O_RDWR);
transfer(fd);
close(fd);

==Semaine 11==

====Programmation: PS4, SSH et tests SPI (RPi3&Atemga328p)====

'''Raspberry Pi Zero W et PS4'''

'''Raspberry PI, Atmega328p et SPI'''

Afin de facilité la programmation en utilisant Ethernet, nous avons installer et configuré la RPi pour l'utiliser en SSH depuis les ordinateurs de la E306. En effet, SSH permet de se connecter à distance sur une machine en utilisant un compte utilisateur de la dite machine. En mettant ssh, on pourra directement agir sur les fichiers de la raspberry depuis un terminal de notre PC. Pour cela, on a d'abord vérifier l'adresse IP de notre raspberry pi : 172.26.145.106 avec un écran mais on peut aussi utiliser les commandes ip a et ifconfig. Puis activer le ssh sur la raspberry pi.
On modifie alors le fichier config.txt mais également etc/network/interfaces pour configurer la bonne interface Ethernet sur la raspberry pi.

[[Fichier: configSSH_raspi.png||left|300px|config ssh ethernet]]

Il nous suffit alors de taper la commande : ssh pi@172.26.145.106 pour accéder à notre RPi.

Nous avons continué à réaliser la communication SPI avec des tests entre une arduino UNO et la RPI3. Nous avons commencé par des tests simples inspirés des études de deux semaines précédentes et modulés selon notre utilité.
Nous arrivons alors à lire l'état envoyer "bonjour" et recevoir "ça va" ou encore "1" et recevoir "3". Il faut noter que le SPI échange des trames, la RPI reçoit alors des hexadécimaux.
Nous avons alors continué pour recevoir l'état du bouton ou du joystick lors de l'envoie de "1" sur l'Arduino328p. La semaine prochaine nous testerons ces même codes fonctionnels sur les cartes atmeg327p.

A la fin de cette semaine, nous avons alors des codes Arduino-SPI (.ino) et des codes Raspberry-SPI (.c) permettant l'échange de données. Le but est maintenant de l'adapter aux cartes imprimées et de le rendre pleinement fonctionnel pour plusieurs cartes à la fois, puis ajouter une boucle de vérification en continue jusqu'à une deuxième requête de la RPi.

====Electronique: réalisation au propres des PCB modules====

Suite à une nouvelle erreur de réalisation cartes électronique, nous avons refait et renvoyé à nouveau les cartes imprimées atmega328p.
Nous les souhaitons au propre pour une version finale. Une fois celle-ci imprimées nous pourrons en avoir 3 , un pour chaque module. Les cartes étaient bien imprimées en bottom mais lors du passage des traversants de bottom à top, le logiciel ne les a pas fait miroiter. Par manque d'attention nous avons alors envoyé les fichiers gerber pour des cartes ayant les composants du même coté que la couche de cuivre.
Les cartes électroniques actuelles sont alors correctes et fonctionnelles mais difficile à souder. Pour eviter les erreurs et continuer sur des prototypes de carte nous préférons attendre en nous concentrant sur la programmation PSI de la Raspberry Pi.

==Semaine 12==

====Programmation====

'''Raspberry Pi Zero W et PS4'''

'''Raspberry PI, Atmega328p et SPI'''

- réflexion: penser à faire boucler sur l'arduino une fois la requête reçu, ça veut dire que la manette est ON et donc vérifier continuellement les modules sur chaque atmega.
- SPI raspberry pi - arduino recuperation état du bouton avec les cartes modules (/!\ récuperation à faire dans une variable)

-SSH perso
adresse Rasppi: 192.168.137.10

====Electronique: Finalisation soudure Modules====

Soudure au propre et finale d'une carte atmega328p et donc envoie pour la réalisation de 2 autres cartes similaires et récupération de matériel
Soudure des 2 autres cartes, + tests sur les états = fonctionnelles.
On a donc bien 3 cartes pour les 3 modules de types différents (1 bouton, 1 joystick, 1 gachette)
PCB pour les 2 joysticks (qui serviront de thumbstick et gachette)

==Semaine 13 et plus==

====Programmation====

'''Raspberry Pi Zero W et PS4'''

'''Modules Atmega328p et SPI'''

====Electronique====

=Documents Rendus=

(à mettre rapport + git + drive)

=Datasheets=

IMA4 2017/2018 P35

2018-05-05T18:19:59Z

Tgracias : /* Semaine 2 */

__TOC__
 

=Présentation générale: Manette modulable=

==Description==

Tout le monde joue aux jeux vidéo cependant, les manettes ne sont pas adaptées aux personnes ayant un handicap pouvant toucher les bras ou les mains.
C’est le cas, de plusieurs patients dans les centres de soins et de rééducation.

Pour ce projet IMA4, nous travaillerons avec le centre SSR (soin de suite et de réadaptation) Marc Sautelet de Villeneuve d’Ascq.
Un adolescent, patient de Marc Sautelet, est passionné par les jeux vidéo. En effet, ayant perdu la motricité d’une partie de son corps, il ne peut pas jouer à deux mains. Pour cela, il bloque la manette entre son épaule et son coude, usant de la mâchoire et des doigts pour contrôler les
joysticks et les boutons. Cet exercice peut s’avérer fatiguant et pénible.

Ainsi, nous chercherons à concevoir une manette PS4 adaptée au handicap de l’adolescent.
Cette manette devra aussi être adaptée pour d’autres patients présentant également des handicaps moteurs. Ainsi nous prendrons pour cibles: tous les patients du centre voulant jouer; et non pas que les enfants et adolescents.

 

{| class="wikitable centre" width="80%"
|+
|-
| width="23%" |
Membre du projet
| width="34%" |
Transley Gracias et Camille Saad
|-
| width="23%" |
Cible
| width="34%" |
Patient présentant un handicap moteur
|-
|width="23%" |
Période du projet
| width="34%" |
janvier 2018 - mai 2018
|-
|width="23%" |
Partenaire/Client
| width="34%" |
Centre SSR Marc Sautelet à Villeneuve d'Ascq
|}

==Objectifs==

Ce projet a pour objectif de créer un prototype de manette qui puisse interagir avec la console PS4 et dont le paramétrage se fait à l’aide d’une application mobile et/ou web. Cette manette devra suivre les demandes du patient ainsi que des aides-soignantes du centre, dans la mesure du possible.

Plus précisément, pour le premier prototype, nous mettrons en œuvre l'utilisation de quelques boutons spécifiques:

* Un joystick (type L/R)
* Quelques boutons poussoirs (type Croix/Triangle/Carré/Rond/R1/L1/Start/...)
* Des boutons gâchettes progressives (type L2/R2).

Le but serait donc dans un premier temps de rendre fonctionnel un bouton de chaque type, puis de les multiplier une fois cela fait. Tous ces boutons réunis constituent une manette fonctionnelle.Ainsi, la manette sera ajustable, c’est à dire qu’elle devra s’adapter aux différents handicaps moteurs possibles.

=Analyse du projet=

==Positionnement par rapport à l'existant==

Notre prototype aura une présentation unique par rapport à l’existant. En effet, les concurrents et produits existants ciblent pour la majorité un seul handicap. Cela
engendre une solution fermée à beaucoup de patients. Notre projet propose une mobilité des mouvements et également un choix large dans la composition et le
design de notre manette.
Le patient n’est pas retreint à jouer à une seule main, à utiliser beaucoup de force...Il y a moins de technique dans la manipulation et on ne joue pas avec une
manette adaptée uniquement pour un droitier ou un gaucher. Cependant, cela nous limitera peut-être dans le choix possible des types de jeux. Tout comme les autres
manettes adapté, l’utilisateur nécessitera un peu d’entrainement.

==Analyse du premier concurrent==

Jouer aux jeux vidéo à une main n’est pas une idée d’aujourd’hui. En 1990, Nintendo propose le Power Glove. Mais il tombe très rapidement aux oubliettes suite à des problèmes techniques.

Un autre gant a fait son apparition quelques années plus tard. Celui-ci, plus technique, il faut office de manette Play Station: le Reality Quest Power Glove.Cette idée de manette-gant, permet de jouer à la PS avec une seule main, elle a était conçue et présentée pour les E3, un salon d’exposition de gaming.Le gant est conçu pour contrôler l’équivalent des 14 boutons et 2 joysticks à l’aide d’une seule main. La « manette » est fixée dans la pomme de la main. L’utilisateur contrôle les mouvements verticaux et horizontaux en pivotant le poignet, et utilisent les 4 boutons d’action principaux et L1/R1 avec les doigts. Les autres boutons sont accessibles par un seul bouton rond contrôlé par le pouce.
La manette est adaptée pour beaucoup de jeux vidéo, dont les plus simples sont les jeux de voitures et de combats (arcade).

; Problèmes:
*Besoin de toute la motricité de la main, c’est-à-dire que si le patient à un doigt paralysé ou manquant, il ne pourra pas jouer avec ce gant
*Design obligatoirement droitier
*Les boutons de contrôle sont peu sensibles et peuvent nécessiter de la force
*Design compliqué et nécessitant beaucoup d’entrainement.

;Lien : https://www.youtube.com/watch?v=qV0SxSJDCYg

 
==Analyse du second concurrent==

Ben Heck, de son vrai nom Benjamin J.Heckendorn, est un concepteur de mods de consoles (mods pour modification, soit « manettes modifiées ») et une star
du net grâce à ses vidéos tutoriels.Il propose alors énormément de produits adaptés ou dérivés en guise de manettes.
Parmi les mods qu’il a réalisé, il a modifié une manette de PS4 afin de la rendre accessible à une personne ne pouvant jouer qu’à une main. Pour cela, il a déplacé les boutons en respectant l’ergonomie de la main valide et modifie les connexions. Il peut lui arriver de rajouter des boutons pour en remplacer un autre. Il réalise également le même système avec la Xbox. Sur la photo ci-dessous, il a adapté la manette pour un droitier.

; Problèmes:
*Besoin de toute la motricité de la main, c’est-à-dire que si le patient à un doigt paralysé ou manquant, il ne pourra pas jouer avec cette ma
*Design obligatoirement droitier ou gaucher, une modification = une manette= une personne
*Besoin obligé du pouce et de l’index, même si avantage : 3 doigts nécessaire.

;Lien :: https://www.youtube.com/watch?v=LieHIscadjk

==Scénario d'usage du produit ou du concept envisagé==

La technologie est ,aujourd’hui, omniprésente dans notre vie. Les consoles de jeux ont envahies les maisons avec plus de 7 personnes sur 10 jouant aux jeux vidéos sur consoles en France (chiffre de l’Express). 0,18% des français sont handicapés cela représente 12 millions de français. Dans ce chiffre, 13,4% des personnes ont un handicap moteur. En 2017, les grands groupes comme Sony ou Microsoft avec respectivement PlayStation et Xbox ne permettent pas à tout le monde de jouer avec une manette. Les manettes sont prévues pour des personnes ayant leurs membres valides, plus précisément les mains et les bras.

Après un accident de voiture, un jeune garçon a perdu la motricité d’un côté du corps. Passionné de jeux vidéo, il se retrouve avec des difficultés à jouer sur sa console PS4. Ingénieux, il utilise la manette en la coinçant entre son épaule et le creux du cou. Usant de la mâchoire et de sa main valide pour contrôler les joysticks et les boutons. L'exercice étant inconfortable et fatiguant il eu l’idée de proposer à des futurs ingénieurs de lui proposer une manette adaptée à son handicap.

Les deux pré-ingénieurs ,avec leur tuteur, ont une idée révolutionnaire : La manette modulable ! Elle permettrait au jeune garçon, ainsi que d’autres joueurs, de pouvoir continuer de s’amuser ou même de commencer à jouer au jeux sur console.
Cette manette aidera fortement dans les centre de rééducation pour faire passer le temps et donner du plaisir à des personnes qui ne peuvent plus s’amuser avec leur console traditionnelle. Elle pourra aussi ouvrir de nouvelles possibilités pour certaines personnes qui n’auraient jamais essayé jusqu'à présent.
Comme son nom l'indique, elle sera modulaire et s'adaptera à différents handicaps. Accompagnée de son application d’initialisation, elle sera accessible aussi bien aux enfants, patients, parents et aides soignantes.

Quelques mois plus tard...Le jeune patient fan de Need For Speed, peut maintenant piloter sa voiture comme un vrai professionnel grâce à l'un des joysticks qu'il utilisera avec sa main valide et il pourra accélérer à des vitesses folles à l'aide de boutons poussoirs au niveau de son pied valide et gagner la partie. Son ami venu lui rendre visite, pourra en lieu et place des aides soignantes configurer à l'aide de la tablette (portable) la manette du patient.
Si le patient change de jeu pour Tekken et que la configuration des modules ne lui convient plus, il peut interchanger les éléments de la manette selon son envie et son confort. Ainsi il peut faire sauter son personnage, il utilisera un module bouton supplémentaire, qu'il actionnera avec le poing.

==Fonctionnement==

Suite à une analyse fonctionnelle et à la formulation de notre projet, nous avons pu définir le fonctionnement de notre système. Notre produit, la manette, doit être accessible d’après nos objectifs à différents types de handicaps moteurs. Ainsi, l’idéal serait de concevoir une manette modulable afin qu’elle puisse s’adapter à toutes les situations. Ce n’est plus au patient de s’adapter à la manette mais à la manette de s’adapter au patient.
Cela signifie que la manette sera, dans la limite du possible et de la sensibilité du corps du patient, composée de plusieurs parties dites « modules » comportant un ou plusieurs actionneurs (boutons, joysticks, gâchettes...). Ces modules seront déplaçables afin d’être utilisé avec différents membres du corps : un doigt, une main,
une jambe ou même un pied. Il suffira de les connectés entre eux suivant l’organisation souhaitée, le Gameplay du jeu ou en fonction du handicap. Le tout sera relié à une application.
L’application sera alors mise en place pour connecter les différentes parties du point de vue software pour prérégler la manette en fonction du patient. Il pourra alors choisir les boutons en fonction du jeu, de ses mouvements mais aussi choisir la sensibilité.

L’application et les modules devront être intuitifs et faciles d’utilisation. De cette manière des utilisateurs non avertis dans le domaine informatique ou jeunes pourront eux-mêmes gérer les connexions.

==Réponse à la question difficile==

'''Question : Comment interconnecter les différents modules de la manette ?'''

Il nous faut pour ce projet interconnecter les modules modélisant la manette qui seront connectés à la consoles PS4 via une Raspberry Pi 3.
Le choix de la Raspberry Pi 3 nous permet d'utiliser son module Bluetooth pour communiquer avec la PS4, ce choix est plus adaptée au projet que du filaire.
Concernant l'interconnexion des modules, nous travaillerons en deux étapes "preuves concept" : filaire et sans fils (Bluetooth).

'''Objectif 1 : Preuve concept filaire'''

Dans cette première partie de projet, nous souhaitons avoir une 1ère preuve de prototype rapidement. Nous nous concentrerons alors sur la communication entre la RPi3 et la PS4 ainsi que sur la conception des modules. Pour les modules, nous réaliserons des cartes électronique pour chaque module avec un micro-contrôleur. La communication filaire nous permettra d'interconnecter les modules à la RPi3 avec un bus SPI.

'''Objectif 2: preuve concept sans fils'''

Une deuxième étape du projet est la réalisation de la solution idéale sans fils. Celle-ci pourra commencer à être développée petit à petit en parallèle avec l'objectif 1. Le but ici, est d'interconnecter les modules en Bluetooth. Nous avons choisi le Bluetooth pour garder une connexion commune sur toute la chaîne.
Nous rajouterons alors un module bluetooth à chaque module de la manette.

'''Objectif 3: possibilité d'adapter les boutons (capuchon en 3D)'''

=Préparation du projet=

==Cahier des charges==

''Chef de projet:'' Alexandre Boé 
''Responsables:'' Xavier Redon, Thomas Vantroys 
''Partenariat:'' Marc Sautelet (non etablie) 
''Elèves-ingénieurs:'' Camille Saâd, Transley Gracias 

'''Sujet :''' Manette modulable pour personne à déficience moteur compatible PlayStation 4 

===Objectifs principal (1er POC) : ===
Faire transmettre des informations issus des actionneurs (ex:boutons poussoires) via des arduinos jusqu’à la Raspberry Pi 3 en SPI. 
Envoyer les données reçues vers la PS4 en USB 

===Objectifs secondaire (2e POC):===
Créer des modules avec un microcontrôleur et une puce bluetooth pour permettre une meilleurs flexibilité (c-àd pouvoirs avoir une meilleure ergonomie et une connexion sans fil) 
Connecter la Raspberry Pi 3 en Bluetooth à la PS4 

[[Fichier: beteacorne.jpg||middle|600px|Bete a corne manette]]

==Choix techniques : matériel et logiciel==

===Liste de matériel :===

'''Modules boutons/joysticks/gachettes'''

3 Push buttons : 
- O X Y Carré R3 L3 
- Guide PS 
- start/back 
--> 0,45€/unité TTC [https://www.gotronic.fr/art-bp-miniature-krs1273-16976.htm] 

1 Thumbstick original: 
Joystick analogique 4 directions --> 4,25€/unité TTC [https://www.gotronic.fr/art-joystick-analogique-4-directions-19063.htm] 

1 buttons trigger L1 L2 => 1x Thumbstick original''' 

'''Cartes Atmega328p /connexion spi/'''

3 Arduino UNO 
1 Arduino UNO atmega328p retirable 
4 capacite 22pF traversantes 
2 resistances 10 kOhm traversantes (à récupérer) 
2 oscillateurs quartz 16MHz traversante 
2 atmega328p-pu et support 

'''Cartes module bluetooth nrf52810 '''

6 capacités 100nF 0603 
6 capacités 12pF 0603 
2 capacités 4,7pF 0603 
2 capacités 1µF 0603 
2 capacités 100pF=0,1nF 0603 (à récupérer) 
2 capacités 0,8pF 0603 (a acheter, commande en cours) 
2 inductance 3,9nH 0603 (a acheter, commande en cours) 
2 oscillateur quartz 32 MHz 

''' Connexions et autres '''

1 Led RGB neopixel [https://www.adafruit.com/product/1734] 
1 Raspberry Pi 3 
--> ~36,23€/unité TTC [https://fr.rs-online.com/web/p/processor-microcontroller-development-kits/8968660/?src=raspberrypi] 
1 Raspberry Pi Zero W (commandée) [https://www.raspberrypi.org/products/raspberry-pi-zero-w/] 
6 Alimentations 5V ou 3,3V 
par exemple, 12 piles de type CR2016 3V rechargeables ou 24 piles AAA 1,5 V rechargeables
5 modules Bluetooth nrf de Nordic : nRF52810-QFAA-R 
--> 3,17€/unité + frais expédition [https://www.mouser.fr/productdetail/nordic-semiconductor/nrf52810-qfaa-r?qs=sGAEpiMZZMve4%2FbfQkoj%252bG%2FosjLoe2oghFQwQllMrQ4%3D]
5 Lignes broches mâles 

===Logiciels:===

- IDE arduino
- Altium
- FreeCAD ou Inkscape

==Liste des tâches à effectuer==

'''Etape 1 : Gestion du projet'''

* Définition des cahiers des charges fonctionnel et technique, choix d'orientation...
* Recherche techniques sur les différentes connexions possibles entre les modules, la RPi 3 et la console PS4
#Recherche connexion SPI entre les modules et la RPi3
# Recherche connexion bluetooth entre la RPi3 et la PS4
# Recherche connexion bluetooth pour les modules
# Recherche carte avec montage Atmega328P-PU et anticipation module bluetooth
* Détermination du matériel nécessaire
* Réflexion sur l'application

'''Etape 2: Réalisation du projet'''

'''Partie 1: Preuve concept manette en filaire'''

* Conception de cartes électroniques pour 2 modules (/!\ prévoir modules bluetooth)
* Réalisation connexion SPI avec 2 modules : programmation des Atmega328p en liaison série.
* Si tests concluant, ajouter des modules jusqu'à en avoir 5 (1 pour chaque type de boutons)
* Connexion bluetooth entre la PS4 et la RPi3
* Réalisation du support des modules avec fixations possibles (imprimante 3D)

'''Partie 2: Preuve concept manette en bluetooth'''

* Ajout des modules bluetooth aux cartes électroniques
* Connexion bluetooth entre les modules

'''Partie 3: Application Android : paramétrage de la manette'''

* Créer une application sur tablette ou smartphone (Android) afin de configurer la manette aux besoins (inter-connexion des modules et console)

==Calendrier prévisionnel==

{| class="wikitable centre" width="80%"
|+
|-
| width="23%" |
'''Date'''
| width="34%" |
'''Tache à réaliser''' 
|-
| width="23%" |
17/01/18-24/01/18
| width="34%" |
Faire des recherches sur les différentes interconnexions du système : Bluetooth, RPi-Atmega328 (SPI), RPi-PS4
Continuer liste des taches, matériel, Début recherches + réflexion fixation support des modules
|-
|width="23%" |
31/01/18
| width="34%" |
Recherche technique connexion PS4-RPi3 et connexion SPI RPi3-Module + code
|-
|width="23%" |
31/01/18-07/03/18
| width="34%" |
Réalisation 1er prototype (+ début prototype 2)
|-
|width="23%" |
07/03/18
| width="34%" |
Seance 7 : Test prototype filaire
|-
|width="23%" |
07/03/18-09/05/18
| width="34%" |
Réalisation 2eme prototype + application Android
|-
|width="23%" |
09/05/18
| width="34%" |
Seance 14 : Test prototype Bluetooth
|-
|width="23%" |
14/05/18
| width="34%" |
Video projet
|-
|width="23%" |
15/05/18
| width="34%" |
Finalisation projet et Rapport
|-
|width="23%" |
16/05/18-17/05/18
| width="34%" |
Soutenances Projet
|}

=Réalisation du Projet=

==Feuille d'heures ==

Voici le tableau d'heures du binôme:

{| 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 S11 !! Heures S12 !! Heures S13et+ !! Total
|-
| Analyse du projet
| 10
| 2
| 1
| 1
| 1
|
|
|
|
|
|
|
| 20min
|
| 15h20
|-
| Cherches techniques
|
| 3
| 4
| 4
| 2
| 2
| 1
|
|
|
| 1
| 1
|
|
| 18
|-
| Rédaction du wiki et rapport de projet
|
| 1
| 1
| 1
| 1
| 30min
| 1
|
| 2
| 30min
| 30min
|
| 2
|
| 10h30
|-
| Programmation
|
|
|
|
| 3
| 2
| 3
| 5
| 4
| 7
| 8
| 6
| 5
|
| 43
|-
| Cartes électroniques
|
|
|
|
|
| 6
| 8
| 4
| 6
| 2
| 1
| 2
| 2
|
| 31
|-
| Application
|
|
|
|
|
|
|
|
|
|
|
|
|-
|-
| Total Semaine
| 10
| 6
| 6
| 6
| 7
| 10h30
| 13
| 9
| 12
| 9h30
| 10h30
| 9
| 9h20
|
| '''117h50'''
|}

==Prologue==

Avant la réalisation et conception d'un projet, il est important d'analyser celui-ci. Nous avons allons consacré le prologue à l'analyse fonctionnelle de la manette. Nous avons également eu une réflexion sur l'analyse technique, cela nous a permis de réaliser une liste de matériel. Il est important de définir les objectifs ainsi que les besoins afin de ne rien oublier. (Voir ci-dessus Analyse projet)
Nous avons également organisé notre travail, pour le partage de documents de recherches et la rédaction de compte-rendu final nous avons réalisé un google drive. Par la suite, nous créerons un projet Git.

Durant ce temps, nous avons décidé de réaliser 5 modules. Les modules sont les différents boutons de la manettes qui nous pourrons placer selon nos choix (boutons modulaires) pour notre prototype projet pour chaque type des boutons d'une manette PS4. Ces modules devrons être connectés à la console et interconnectés. Le tout sera lié à une application Android. Suite à quelques recherches et nos analyses, nous avons décidé les points suivants :

- On commencera avec 2 modules et on les multipliera par la suite.
- Les premiers tests sont réalisés avec des boutons petits pour assurer leur caractéristique "modulaires", par la suite nous pourrons ajouter des capuchons de taille plus importante (imprimante 3D ou achat)
- Conception modules : réalisation de carte avec un microcontrôleur atmega328 programmable pour chaque module (anticiper le module Bluetooth)
- Projet en 2 parties : prototype filaire et prototype Bluetooth
# Prototype filaire : connexions entre les modules et la RPi3 en SPI, connexion Rpi3-PS4 en Bluetooth, avec l'application en filaire à la RPi3
# Prototype Bluetooth: connexion Bluetooth entre modules-RPi3-PS4-apllication

[[Fichier: structuremanette.png||center|400px|Concept manette modulable]]

==Semaine 1==

Durant la séance, nous nous sommes concentrés les recherches afin de définir clairement le cahier des charges technique. Il s'agit des réalisations à mettre en œuvre pour les inter-connexions des éléments de la manette.
Ainsi, nous avons fait des recherches sur :

===Connexion SPI entre les modules (Atmega328p) et la RPi3===

SPI: Serial périphérique interface BUS

[[Fichier: yWGmW.png||right|200px|Concept manette modulable]]
Comme indiqué sur l'image ci-dessus, la Raspberry pi 3 peut communiquer en SPI avec ses broches CS0 (24), CS1 (26), SCLK (23), MISO (21), MOSI (19). Celles-ci permettent de communiquer avec un ou plusieurs esclaves (dans notre cas, des Atmega328p) en reliant directement les broches concernées de la RPi3 à celles des composants esclaves.
Chaque broche CS0 (24) ou CS1 (26) ne peut être connectée qu'à l'entrée SS (aussi appelé CS) d'un seul esclave.
C'est a dire que chaque CS est lié à un esclave afin de choisir avec lequel la communication est établie à un moment donné, et les MISO sont reliées entre elles en cascade, de même pour les SCLK et les MOSI. On peut noter que le maître impose la fréquence d’horloge et sélectionne l’esclave auquel les données sont envoyées. 8 MHz est le plus rapide supportable a 3,3V

[[Fichier: fonctionnementSPI.png||right|200px|Connexion SPI multi-esclaves]]

Voici un schéma du fonctionnement souhaité :

Comme nous souhaitons avoir 5 modules environ il nous faudra rajouter un composant en plus afin d'augmenter les possibilités de sélection, par exemple des démultiplexeurs.
Dans un premier temps nous essaierons avec 2 esclaves, puis on augmentera le nombre.

===Connexion Bluetooth PS4-RPi3===

Les recherches portent également sur la connexion entre la manette PS4 et la console. Elles concernent le protocole de communication via Bluetooth

Caracteristique pour la PS4: Bluetooth®v4.0, Qualcomm Atheros AR3002 Buetooth LE: 2,4-2,5 GHz 

Caracteristique de la connexion : 

*Vitesse de transmission >> 3 Mbit/s 8N1
*Relevé tous les 1.3 millisecond (peut-être)
*Chaque manette à une adresse unique BD_ADDR qui correspond à l’adresse MAC de la carte Réseau
*Protocole de détection est le SDP basé sur une emission reception PDU
*L’Attribut ID est representer en TLV Type Length Value
*Communication HCI ACL Data Packet

===Rélisation des cartes électroniques===

matériel nécessaire pour un PCB : 

*breadboard
*câbles
*1 x 10k Ohm résistance
*Quartz 16Mhz clock crystal
*2 x 22 pF capaciteurs
*Atmega328P-PU

Ressources:
[[https://www.arduino.cc/en/Main/Standalone]]
[[http://www.eprojectszone.com/atmega-328-pu-standalone/]]
[[https://www.arduino.cc/en/Tutorial/ArduinoToBreadboard]]

==Semaine 2==

Durant la semaine deux et durant la séance, nous avons continué et approfondie nos recherches sur le projet. Nous avons pu ainsi affiner nos taches de réalisation et donc notre cahier des charges.

===Connexion aux modules: SPI et Bluetooth ===

 CORRIGER

voir https://peip-ima.plil.fr/mediawiki/index.php/BE_2017-2018#Configuration_du_syst.C3.A8me_embarqu.C3.A9

(sudo apt-get install pi-bluetooth)

''connexion sur la raspberry par ssh:''
su
update-rc.d ssh enable
invoke-rc.d ssh start
ssh pi@172.26.79.1XX

''bluetooth''
bluetoothctl
agent on
default-agent
scan on
pair [device Bluetooth address] (exemple: pair XX:XX:XX:XX:XX:XX )

''NOUVELLE REFLEXION : Connexion SPI entre les modules (Atmega328p) et la RPi3 --> MODULES BLUETOOTH''

Si multi-esclaves= plusieurs modules :
Il faut ajouter des sélections pour les SPI → démultiplexeurs OU ne pas utiliser les CS0 et CS1, et plutôt des pins entrée/sortie de la RPi3 lié au SS comme ça on choisit direct le module esclave voulu.

'''IMPORTANT:''' Nous avons étudié à nouveau la datasheet de notre module bluetooth nrf de Nordik. Le module bluetooth comporte déjà un microprocesseur !
Un module plutôt peut donc jouer le rôle de notre atmega328p. Il n'y a alors pas besoin de réaliser des cartes électroniques de type arduino standalone. Nos PCB regrouperont alors uniquement l'alimentation, un actionneur (bouton, joystick), le module bluetooth et les broches de connexion si besoin...

Cette séance nous a alors permise de revoir entièrement le matériel nécessaire. Notre liste de matériel nous semble alors plus réfléchie et limitée au nécessaire.

===Connexion Bluetooth PS4-RPi3===

Suite à nos recherches de la semaine précédente, nous avons sélectionné deux sites bien renseignés :

SITES

Ils nous ont permis de comprendre la communication entre la manette et la console. En effet, ils nous expliquent les échanges de trames Bluetooth.
EXPLICATIONS 1 exemple 

==Semaine 3 : Début premier prototype==

*'''Connexion SPI RPi3-Arduino'''

Comme vu durant les semaines précédentes, nous souhaitons réaliser une connexion Multi-esclaves en SPI entre la Raspberry pi et plusieurs modules.
Cette semaine nous avons vu que la réalisation de notre premier prototype doit aller vite. Il ne nous est pas nécessaire d’attendre les modules bluetooth si il nous faut dans cette partie uniquement utiliser son microprocesseur. Ainsi pour chaque module nous utilisons une arduino UNO. Nous réaliserons les programmes en C afin de pouvoir les réutiliser avec les modules bluetooth par la suite.
Une fois la connexion réalisable nous adapterons les programmes aux modules bluetooth Nordik. En effet, ceux-ci comporte déjà un microprocesseur, le module peut jouer le rôle de notre atmega328p. Il n'y a aurait alors pas besoin de réaliser des cartes électroniques arduino standalone sur PCB, mais directement des cartes électronique avec le module et le module voulu (bouton, joystick...) et l'alimentation.
Durant la séance nous avons alors revu la liste de matériel nécessaire.

[[Fichier: prototype1.jpeg||center|600px|connexion filaire prototype 1 filaire arduino]]

Durant la séance, nous avons recherches des exemples de codes et de librairies pour Arduino SPI et RaspberryPI SPI.

Nous avons également commencé le programme de la connexion SPI pour l'arduino et récupéré les bibliothéques SPI.h avec SPI.c. Nous nous sommes alors concentrer à les comprendre, pour pouvoir l'utiliser.

*'''Réalisation du projet Git'''

Création du projet IMA4_Projet35_ManetteModulable sur Git et partage de celui-ci.
Les premiers dossier crées durant la séance :
-Arduino (connexion SPI arduino) : ProtoSpi.c + dossier librairie SPI + Makefile
-RPI (dossier codes pour Rpi)
-Readme.md

==Semaine 4==

Pour le prototype 1 FILAIRE nous réaliserons les étapes suivantes :

#Réalisation du programme SPI pour arduino
#Réalisation du programme SPI pour la RPi
#Connexion USB avec la PS4 ou ordinateur
#Réalisation de cartes électroniques atmega328p-pu standalone (remplacer les Arduinos)
#Remplacer les "PCB arduino" par le module bluetooth et adapter la connexion
#Conception 3D de la délimitation 1 axe pour le joystick "gâchette"
#Réalisation de l'application Androïde.

Une fois ces étapes réalisées nous auront alors une preuve de concept filaire et nous pourrons alors passer à une connexion bluetooth.
Le passage à la connexion bluetooth sera le deuxième prototype et le cas idéal de la réalisation de la manette modulable.

===Mise à jour Matériel===

- Modéliser les boutons gâchettes L1/2 R1/2 de la manette PS4 (boutons sensibles à la pression) --> un joystick dont nous bloquerons un axe (imprimante 3D)
- Remplacer la RPi 3 par une Rpi zero W qui nous permettrait de réaliser plus facilement une connexion USB tout en gardant l'avantage du bluetooth.
- Choix de l’alimentation pour les 5 modules Bluetooth: nécessitent 3V --> utiliser des piles rechargeables 1,2V AAA plutôt que piles rondes 3V.

Nous avons également besoin du matériel cité en semaine 1 pour réaliser des cartes électroniques atmega328p-pu standalone. ( nous revenons alors sur les décisions de la semaine 3)

===Connexion SPI RPi3-Arduino===

Montage Raspberrypi et 1 arduino en PSI + 1 bouton + 1 led.
Voici le choix des branchements :

MASTER = RPi
SLAVE= Arduino

'''SPI sur Arduino:'''
MOSI -> GPIO11 //PB3 //master OUT to the slave IN
MISO -> GPIO12 //PB4 //slave OUT to the master IN
SCLK -> GPIO13 //PB5 //serial clock
SS -> GPIO10 //PB2 //slave select
'''Led, bouton et autre...'''
LED --> GPIO6 //PD6
GND
+5V (if required)
'''SPI sur la Raspberry Pi'''
SPIO MOSI -> PIN19
SPIO MISO -> PIN21
SCLK -> PIN23
SPIO CS0 -> PIN24

Continuation du code pour faire clignoter Led branchée à une arduino depuis la Rpi, en connexion SPI.

===Connexion USB PS4-RPi3===

Durant la séance, nous avons regardé comment utiliser le port série sur la RPi3, soit utiliser les UART.

Nous avons réaliser qu'il n'était pas aussi simple d'utiliser le port serie USB de la Raspberry Pi 3, en effet le SoC est un BCM2837 .
De plus nous ne pouvons pas utiliser le même port pour l'alimentation et la connexion.

Une des solutions à cette difficulté serait d'utiliser une RPi ZERO W à défaut d'une RPi 3. On pourrait alors avoir un port d'alimentation avec connexion USB mais également retrouver la connexion bluetooth dont nous avons besoin.

==Semaine 5==

===Programmation: Réflexion définitives prototypes filaire ===

Durant la semaine 5, nous avons continué la réalisation du prototype filaire par l'avancé du code SPI ainsi que les recherches concernant le protocole PS4.

Pour réaliser la connexion entre la PS4 et les différents modules, nous avons vu la semaine dernière que nous utiliserons une RPi zero W (que nous avons commandé). Celle-ci nous permet d'utiliser le bluetooth mais elle nous permet également de réaliser un réseau local sans fil. Ce qui peut être pratique dans la mesure où notre projet est modulable.
En attendant la réception de la commande, nous nous sommes penché sur les programmes et la configuration nécessaire à l'utilisation de la RPi zero W.

===Electronique===

[[Fichier: bouton_c1.jpg|100px|thumb|left|PCB bouton]]
[[Fichier: arduinobb.jpg|200px|thumb|right|atmega328p-pu branchement test]]

Du coté électronique, nous avons réalisé sur fritzing certaines cartes électroniques. Les Arduino Uno servant actuellement de test, seront remplacées par des PCB atmega328p-pu standalone avec des broches permettant les branchements nécessaires SPI ou encore aux modules "boutons/joystick". Pour les boutons, nous avons également réalisé un pcb afin de faciliter les branchements.

Il nous faut alors également une 3eme carte qui nous sera nécessaire pour la réalisation du prototype sans fil. Dans notre liste de matériel, nous avons des composants nrf52810 bluetooth, ceci doivent être soudé avec les capacités de protection mais également des broches de communication. Nous avons alors commencé cette carte électronique sur Altium avec le fichier projet PCB du distributeur à modifier.

[[Fichier: Arduino_c1.jpg|100px|thumb|center|PCB atmega328p-pu]]

=== Construction 3D ===

Enfin, nous avons commencé à réaliser des boîtiers 3D pour certains modules. Par exemple, comme nous l'avions vu précédemment, un des joysticks servira de bouton-gâchette en utilisant un seul de ses axes. Il nous faut alors réaliser un boitier qui bloque l'un des axes, mais également une tige qui nous permettra de pousser le joystick de manière simplifiée.

==Semaine 6==

===Programmation: configuration RPi Zero W ===

Ayant reçu la Raspberry Pi zero W en début de semaine, nous nous sommes concentrés sur la programmation et la configuration de celle-ci.

===Electronique: PCB nrf52810===

Les cartes réalisées en semaine 5 sont validées et en attente de réalisation.

Cette semaine a permis la réalisation et la finalisation de la carte électronique nrf52810. Il nous a fallu recommencé cette carte deux fois. En effet, une fois finie sur Altium nous avons réalisé que les empreintes des CMS sur PCB fourni par le constructeur ne correspondent pas au matériel CMS de l'école. Face à cette inattention de notre part, nous avons décidé de refaire entièrement la carte électronique sur fritzing. Ayant la datasheet et des plans d'inspiration PCB, nous avons pu refaire la carte entièrement.
Sur celle-ci nous avons ajouté des broches de connexion au besoin, un branchement Jtag et ICSP pour la programmation et la connexion SPI.
La carte est en attente de validation, puis validation.

[[Fichier: nrf52810_circuit2.jpg||center|400px|PCB carte nrf52810]]

===Révision matériel ===

Pour la réalisation de nos composants électroniques, il nous a fallu faire une révision des composants disponibles à l'école:
(les quantités indiquées ci-dessous pourront être augmentée si nécessaire,pour avoir dans l'idéal un module de chaque type de la manette, ici on se concentre sur BOUTON et JOYSTICK)

'''Cartes Arduino:'''
* 4 capacite 22pF traversantes
* 2 resistances 10 kOhm traversantes (à récupérer)
* 2 oscillateurs quartz 16MHz traversante
* 2 atmega328p-pu et support

'''Cartes nrf52810'''
* 6 capacités 100nF 0603
* 6 capacités 12pF 0603
* 2 capacités 4,7pF 0603
* 2 capacités 1µF 0603
* 2 capacités 100pF=0,1nF 0603 (à récupérer)
* 2 capacités 0,8pF 0603 (commande en cours)
* 2 inductance 3,9nH 0603 (commande en cours)
* 2 oscillateur quartz 32 MHz

'''Cartes modules Boutons'''
* un sachet de broches mâles (qu'on utilisera également pour les autres cartes, à récupérer/acheté)

Nous avons alors mis-à-jour la liste de composant située plus haut, ainsi que celle de la page IMA4 2017/2018 [https://projets-ima.plil.fr/mediawiki/index.php/Projets_IMA4_SC_%26_SA_2017/2018]

==Semaine 7==

===Programmation: connexion wifi RPi Zero W et Bootloader sur Atmega328p-pu ===

Pendant cette semaine, nous avons continué la programmation et la configuration des Raspberry Pi 3 et Zero W afin de les utiliser en connexion Wifi.

Nous avons également continuer les programmes de récupération de données : état des boutons et du joystick. Ces programmes sont appliqué sur l'atmega328p-pu standalone sur la plaque d'essai en attendant que le PCB soit opérationnel.
Pour pouvoir programmer l'atemega328p-pu comme une arduino UNO, il nous faut suivre plusieurs étapes :

'''1.Flasher le Bootloader'''
Nous avons 2 Atmega328p-pu neufs, ainsi il nous faut flasher le bootloader sur chacun d'eux afin de pouvoir les utiliser et les programmer sur une breadboard dans un montage minimaliste arduino-standalone.
Pour cela, on peut utiliser une carte arduino UNO. On vérifie le port et le type de carte sélectionnés dans le menu >Outils. Sur cette carte on téléverse le fichier arduinoISP.ino qui se trouve dans les exemples en étant en progrmamateur AVr ISP mkll (>outils>programmateur)
Puis on met l'atmega328p-pu qui nous intéresse sur le suppor socket de la carte. On change de nouveau le programmateur pour Arduino as ISP et on fait >tools>burn bootloader, soit >graver la sequence d'initialisation.
Ces étapes faites, on peut retirer notre microcontroleur et le replacer correctement dans le montage.

'''2.Programmation atmega328 sur breadboard'''
Une fois l'atmega328p-pu préparé, on peut le programmer. On peut le faire simplement à l'aide de la carte arduino UNO utilisée précédemment.On branche les Tx et Rx en commun ainsi que le reset, le GND et le VCC.

Nous avons réaliser des codes basiques tels que le clignotement d'une led rouge ou encore l'affichage de "hello world" sur le moniteur série pour vérifier la bonne fonctionnalité du montage. Cela fait nous avons pu écrire sous Arduino IDE le code de lecture des états.

[[Fichier: montage_BB_test.jpg||left|200px|programmation modules arduino sur breadboard]]

===Electronique : soudure carte de test modules ===

Comme nous l'avons déja vu lors de la réalisation des PCB, si l'on souhaite programmer un atmega328p-pu en bootloader, le montage est simple. Il peut être minimaliste en utilisant une arduino UNO, un atmega328, une breadboard et 3 composants: 1 quartz 16MHZ crystal, 1 résistance 10kOhm et 2 capacitors céramiques de 22pF.
Durant la semaine 7, nous avons soudé les composants traversants de la carte électronique correspondant à ce montage ainsi que le PCB du bouton.

==Semaine 8==

===Programmation ===

===Electronique : Correction soudure et soudure CMS===

Durant cette semaine, nous avions souhaité programmer la carte électronique atmega328p-pu. Cependant, nous avons réaliser que nous avions fait une erreur lors de l'envoie du PCB à la production. En effet, celui-ci avait été fait en Top sur le logiciel Fritzing et non en Bottom. Hors nous avions soudé les composants (durant la semaine 7) comme pour un circuit imprimé en bottom, l'atmega328p-pu se retrouve alors inversé par rapport aux pistes.
Comme solution, nous avons choisi de souder un deuxième support pour l'atmega328 de l'autre coté de la carte avant de la refaire au propre. En effet, avant de la refaire il nous faut vérifier si la carte est bien programmable.
Une fois cela fait nous avions pu programmer la carte mais, nous avions également réalisé la pin 2 de l'atmega328 était prise par le bouton poussoir. Or, nous avons besoin des pin 2 et 3 pour le RX et TX permettant la programmation de l'atmega à partir d'une arduino, les pistes branchement RX-TX n'ont également pas été prévus pour le téléversement des programmes sur la carte. Il nous faut alors couper une piste et souder des câbles pour utiliser toutes les pistes souhaitées.

[[Fichier: correction_proto_PCB.jpg||right|300px|PCB arduino correction]]

Durant cette semaine, nous avons également souhaité souder les CMS et le composant bluetooth nrf52810 sur la carte imprimé et reçu lors de la semaine 7. Pour cela, nous avons convenu de travailler dans la C202 durant la séance du mercredi.

[[Fichier: PCB_nrf52810.jpg||left|400px|carte electroniques imprimées]]

====Comment souder des CMS ?====

les CMS sont des composants montés en surface c'est à dire qu'ils sont montés du même côté que les pistes cuivrées (à l'opposé des composants traversants) et sont de petite tailles souvent de l'ordre du millimètre. La taille est déterminée par 4 chiffres : les 2 premiers pour la longueur et les 2 derniers pour la largeur. On a du 1206,0805,0603 ou encore 0402. Il est même possible de trouver plus petit. A l'école nous utilisons souvent du 0603, c'est le cas de nos composants.
Pour souder des CMS 0603, il nous faut utiliser une autre méthode qui n'est pas le fer à souder :
# Préparer la veille la pâte à braser la veille (dans une seringue)
# Gommer la carte pour éviter l'oxydation (attention à ne pas retirer les miettes de gomme en soufflant dessus)
# Appliquer avec la seringue la pâte sur les empreintes et piste souhaitées. Pour les endroits difficile à atteindre ou avec 2 pistes proches les unes des autres, il est possible de mettre la même goutte de pâte sur les 2 pistes. Cela de causera pas de court-circuit par la suite. En effet, la pâte est composée d’alliage qui sous la chaleur va se fluidifier et se coller uniquement aux pistes métallique. Le reste fondera sous la chaleur du four.
# Appliquer les CMS sur la pâte au fur et à mesure (attention ! ne jamais toucher les CMS avec les doigts, tjrs utiliser une pince)
# Mettre au four

====Bilan soudure nrf52810====

Cependant, une fois le matériel nécessaire préparé, et la pâte mise sur les pistes souhaitées, au moment de déposer le composant, nous avons réalisé que celui-ci était beaucoup plus petit que l'empreinte sur le PCB. Il s'agit d'un composant boitier QFN48. Fritzing ne proposant au plus proche des boitiers QFN24 ou LQFP48, celui-ci a basculé automatiquement pour un boitier LQFN48, de dimension plus grande. Face à ce manque de vigilance, nous avions cependant commencer par le nrf52810 (composant concerné) évitant ainsi de gaspiller d'autres CMS.
Nous avons souhaité refaire la carte sous Altium à partir des fichiers fournis par le concepteur (chose que nous avons commencé à faire aux alentours de la semaine 5)
Après la réalisation du schématic, et de la modification des empreintes de capacités, inductances et autres composants de 0402 à 0603. Notre matériel ne permettant que des empreintes 0603.

Lors du routage, une erreur de chevauchement des pistes est notifiée par Altium au niveau du nrf52810. Celles-ci ne présentent pas d'angles et sont déjà de taille 8mil, il nous faut alors passer les pistes en 6mil. Mais 8mil est la taille minimale pour la production à Polytech, nous avons regardé pour envoyer les cartes à faire ailleurs mais le 6mil n'est pas beaucoup conseillé. De plus, il n'est peut-être pas judicieux de continuer avec le composant microcontrôleur-bluetooth Nrf52810 qui prend du temps, donc la carte est difficilement réalisable et peut-être très long à programmer.

Ainsi en cette fin de semaine, nous avons décider face à l'avancer du projet de laisser les nrf52810 de coté et de les remplacer par des modules sans fils plus simples d'utilisation et complets. Ainsi nous aurions plus de chance d'avoir une connexion sans fils entre les modules. Nous pourrions par exemples utiliser des Xbee, des modules Rf...

==Semaine 9==

====Programmation: PS4 et 1er Test SPI sur atmega328p====

'''Raspberry Pi Zero W et PS4'''

'''Modules Atmega328p et SPI'''

Une carte PCB arduino fonctionnant, nous pouvons la programme pour simuler un module. Celle-ci a été designée afin de s'adapter au module que l'on souhaite. Il suffit de brancher le bouton, le joystick ou autre élèment de manette souhaité.
Cette semaine ci, nous avons alors configurer la partie communication SPI pour l'arduino.

'''Que voulons-nous faire avec les atmegas ?'''
Les cartes électroniques atmega328p vont nous permettre de recevoir les requêtes SPI envoyées par la raspberry pi et d'y répondre. La Raspberry enverra un message, par exemple "1", et l'Arduino lira alors l'état du module qui lui est connecté. Une fois l'état récupéré elle le renvoie à la raspberry pi.

Durant cette semaine, nous avons programmé l'atmega afin qu'il soit en esclave, qu'il reçoive un de la RPi "1" et retourne une valeur sauvegardé "int envoi". Nous avons également commencé les tests pour la lecture de l'état d'un bouton (d'après les tests réalisés les semaines précédentes).

'''Code'''
Comme nous l'avons vu précedement lors de nos recherches (semaines 1 à 4) :
La communication SPI nécessite l'utilisation des pins:

MOSI -> GPIO11 //PB3 //master OUT to the slave IN
MISO -> GPIO12 //PB4 //slave OUT to the master IN
SCLK -> GPIO13 //PB5 //serial clock
SS -> GPIO10 //PB2 //slave select

Il faut également paramétrer l'atmega328p en Slave. On note que dans un premier temps, le programme sera codé avec l'arduino IDE (fichiers .ino). Une fois l'ensemble SPI RaspberryPi-Arduino fonctionnant, on remplacera ces codes par du langage C ou C++.

Pour faire la connexion SPI sur l'atmega328p, on utilise la librairie arduino SPI.h, on a alors directement les fonctions nécessaires intervenant sur les registres souhaités : SPCR (spi control register), SPSR (spi status register) et SPDR (spi data register).

#include <SPI.h>

Il est important d'initialise d'abord le setup et on active le port série pour pourvoir utiliser le moniteur série. (Cela servira à verifier la valeur envoyée par la RPi)

void setup (void)
{
Serial.begin (9600);
pinMode(MISO, OUTPUT); //configuration en esclave *master in slave out*
pinMode(buttonPin,INPUT); //config pin bouton
// turn on SPI in slave mode
SPCR |= _BV(SPE);
// preparation interruptions
pos = 0; // buffer empty
process_it = false;
// activation interruptions
SPI.attachInterrupt();
}

On oublie pas de déclarer les interruptions afin de bien lire la requête reçue.

// SPI interrupt routine
ISR (SPI_STC_vect)
{
byte c = SPDR; // grab byte from SPI Data Register
// add to buffer if room
if (pos < sizeof buf)
{
buf [pos++] = c;
// example: newline means time to process buffer
if (c == '\n')
process_it = true;
} // end of room available
} // end of interrupt routine SPI_STC_vect

Dans la loop main, on traite la requête et on utilise '''SPI.transfer(envoi);''' pour transferer à la RPi les données souhaitées.

Durant cette semaine, nous avons également commencé des programmes de test SPI pour la RPi. Il s'agit principalement de programmes de tests tout faits permettant de vérifier la connexion entre cette dernière et l'arduino. Par exemple, la RPI envoie "bonjour" et l'arduino lui retourne ce qu'elle reçoit, soit "bonjour". Sans succés alors.

====Electronique : Fritzing révision====

Lors de la semaine, le modèle PCB de la carte arduino a été réalisé de nouveau sous fritzing avec les broches et connections manquantes. Nous avons également revu la configuration du bouton reset et ajouté une led d'état de l'alimentation. Nous avons ainsi envoyé deux cartes identiques à la réalisation.
La carte déjà soudée lors des derniers jours fonctionnant, elle nous sert de prototype de programmation. Nous pouvons ainsi avancer à la fois sur la programmation des modules mais aussi sur leur réalisation.

==Semaine 10==

====Programmation : PS4 et SPI sur RPi====

'''Raspberry Pi Zero W et PS4'''

'''Modules Raspberry PI et SPI'''

Durant cette semaine, pour la partie Atmega328p-Modules, nous nous sommes concentrés sur la programmation de la communication SPI avec la raspberry pi. Cette semaine a permis une étude plus approfondit sur le fonctionnement pour la RPi.

On rappelle, comme vu des semaines 1 à 4, pour la RPI3 (tout comme la RPi Zero W) utilise les broches : SCLK (23), MISO(21), MOSI (19) et SPI CS0 (24), SPI CS1 (26).
On la programme en Master. A l'aide des fichiers tests d'inspiration, on pourra directement programmer la RPi en C. Lors de la réalisation du code, il y a 3 étapes : l'initialisation/parametrage en SPI pour être maître, l'envoie de la requête puis la réception de données en retour.

Programmant en C, il ne faut pas oublier les librairies suivantes :

#include <stdint.h>
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
#include <getopt.h>
#include <fcntl.h>
#include <sys/ioctl.h>
#include <linux/types.h>
#include <linux/spi/spidev.h> //pour SPI

On va déclarer des variables globales permettant le paramétrage :

static const char *device = "/dev/spidev0.0"; //si on veut CS0 pour atteindre notre SS
static uint8_t mode; //mode est par défaut à 0
static uint8_t bits = 8; //bits par mot échangé
static uint32_t speed = 500000;
static uint16_t delay;

Dans notre main, on ouvre le port (la connexion) au device souhaité, on vérifie les paramètres (registres, connexions...) puis exécute la fonction transfer(fd). transfer(fd) transmet la requête et s'occupe de la réception.

fd = open(device, O_RDWR);
transfer(fd);
close(fd);

==Semaine 11==

====Programmation: PS4, SSH et tests SPI (RPi3&Atemga328p)====

'''Raspberry Pi Zero W et PS4'''

'''Raspberry PI, Atmega328p et SPI'''

Afin de facilité la programmation en utilisant Ethernet, nous avons installer et configuré la RPi pour l'utiliser en SSH depuis les ordinateurs de la E306. En effet, SSH permet de se connecter à distance sur une machine en utilisant un compte utilisateur de la dite machine. En mettant ssh, on pourra directement agir sur les fichiers de la raspberry depuis un terminal de notre PC. Pour cela, on a d'abord vérifier l'adresse IP de notre raspberry pi : 172.26.145.106 avec un écran mais on peut aussi utiliser les commandes ip a et ifconfig. Puis activer le ssh sur la raspberry pi.
On modifie alors le fichier config.txt mais également etc/network/interfaces pour configurer la bonne interface Ethernet sur la raspberry pi.

[[Fichier: configSSH_raspi.png||left|300px|config ssh ethernet]]

Il nous suffit alors de taper la commande : ssh pi@172.26.145.106 pour accéder à notre RPi.

Nous avons continué à réaliser la communication SPI avec des tests entre une arduino UNO et la RPI3. Nous avons commencé par des tests simples inspirés des études de deux semaines précédentes et modulés selon notre utilité.
Nous arrivons alors à lire l'état envoyer "bonjour" et recevoir "ça va" ou encore "1" et recevoir "3". Il faut noter que le SPI échange des trames, la RPI reçoit alors des hexadécimaux.
Nous avons alors continué pour recevoir l'état du bouton ou du joystick lors de l'envoie de "1" sur l'Arduino328p. La semaine prochaine nous testerons ces même codes fonctionnels sur les cartes atmeg327p.

A la fin de cette semaine, nous avons alors des codes Arduino-SPI (.ino) et des codes Raspberry-SPI (.c) permettant l'échange de données. Le but est maintenant de l'adapter aux cartes imprimées et de le rendre pleinement fonctionnel pour plusieurs cartes à la fois, puis ajouter une boucle de vérification en continue jusqu'à une deuxième requête de la RPi.

====Electronique: réalisation au propres des PCB modules====

Suite à une nouvelle erreur de réalisation cartes électronique, nous avons refait et renvoyé à nouveau les cartes imprimées atmega328p.
Nous les souhaitons au propre pour une version finale. Une fois celle-ci imprimées nous pourrons en avoir 3 , un pour chaque module. Les cartes étaient bien imprimées en bottom mais lors du passage des traversants de bottom à top, le logiciel ne les a pas fait miroiter. Par manque d'attention nous avons alors envoyé les fichiers gerber pour des cartes ayant les composants du même coté que la couche de cuivre.
Les cartes électroniques actuelles sont alors correctes et fonctionnelles mais difficile à souder. Pour eviter les erreurs et continuer sur des prototypes de carte nous préférons attendre en nous concentrant sur la programmation PSI de la Raspberry Pi.

==Semaine 12==

====Programmation====

'''Raspberry Pi Zero W et PS4'''

'''Raspberry PI, Atmega328p et SPI'''

- réflexion: penser à faire boucler sur l'arduino une fois la requête reçu, ça veut dire que la manette est ON et donc vérifier continuellement les modules sur chaque atmega.
- SPI raspberry pi - arduino recuperation état du bouton avec les cartes modules (/!\ récuperation à faire dans une variable)

-SSH perso
adresse Rasppi: 192.168.137.10

====Electronique: Finalisation soudure Modules====

Soudure au propre et finale d'une carte atmega328p et donc envoie pour la réalisation de 2 autres cartes similaires et récupération de matériel
Soudure des 2 autres cartes, + tests sur les états = fonctionnelles.
On a donc bien 3 cartes pour les 3 modules de types différents (1 bouton, 1 joystick, 1 gachette)
PCB pour les 2 joysticks (qui serviront de thumbstick et gachette)

==Semaine 13 et plus==

====Programmation====

'''Raspberry Pi Zero W et PS4'''

'''Modules Atmega328p et SPI'''

====Electronique====

=Documents Rendus=

(à mettre rapport + git + drive)

=Datasheets=

IMA4 2017/2018 P35

2018-05-05T18:11:13Z

Tgracias : /* Semaine 1 */

__TOC__
 

=Présentation générale: Manette modulable=

==Description==

Tout le monde joue aux jeux vidéo cependant, les manettes ne sont pas adaptées aux personnes ayant un handicap pouvant toucher les bras ou les mains.
C’est le cas, de plusieurs patients dans les centres de soins et de rééducation.

Pour ce projet IMA4, nous travaillerons avec le centre SSR (soin de suite et de réadaptation) Marc Sautelet de Villeneuve d’Ascq.
Un adolescent, patient de Marc Sautelet, est passionné par les jeux vidéo. En effet, ayant perdu la motricité d’une partie de son corps, il ne peut pas jouer à deux mains. Pour cela, il bloque la manette entre son épaule et son coude, usant de la mâchoire et des doigts pour contrôler les
joysticks et les boutons. Cet exercice peut s’avérer fatiguant et pénible.

Ainsi, nous chercherons à concevoir une manette PS4 adaptée au handicap de l’adolescent.
Cette manette devra aussi être adaptée pour d’autres patients présentant également des handicaps moteurs. Ainsi nous prendrons pour cibles: tous les patients du centre voulant jouer; et non pas que les enfants et adolescents.

 

{| class="wikitable centre" width="80%"
|+
|-
| width="23%" |
Membre du projet
| width="34%" |
Transley Gracias et Camille Saad
|-
| width="23%" |
Cible
| width="34%" |
Patient présentant un handicap moteur
|-
|width="23%" |
Période du projet
| width="34%" |
janvier 2018 - mai 2018
|-
|width="23%" |
Partenaire/Client
| width="34%" |
Centre SSR Marc Sautelet à Villeneuve d'Ascq
|}

==Objectifs==

Ce projet a pour objectif de créer un prototype de manette qui puisse interagir avec la console PS4 et dont le paramétrage se fait à l’aide d’une application mobile et/ou web. Cette manette devra suivre les demandes du patient ainsi que des aides-soignantes du centre, dans la mesure du possible.

Plus précisément, pour le premier prototype, nous mettrons en œuvre l'utilisation de quelques boutons spécifiques:

* Un joystick (type L/R)
* Quelques boutons poussoirs (type Croix/Triangle/Carré/Rond/R1/L1/Start/...)
* Des boutons gâchettes progressives (type L2/R2).

Le but serait donc dans un premier temps de rendre fonctionnel un bouton de chaque type, puis de les multiplier une fois cela fait. Tous ces boutons réunis constituent une manette fonctionnelle.Ainsi, la manette sera ajustable, c’est à dire qu’elle devra s’adapter aux différents handicaps moteurs possibles.

=Analyse du projet=

==Positionnement par rapport à l'existant==

Notre prototype aura une présentation unique par rapport à l’existant. En effet, les concurrents et produits existants ciblent pour la majorité un seul handicap. Cela
engendre une solution fermée à beaucoup de patients. Notre projet propose une mobilité des mouvements et également un choix large dans la composition et le
design de notre manette.
Le patient n’est pas retreint à jouer à une seule main, à utiliser beaucoup de force...Il y a moins de technique dans la manipulation et on ne joue pas avec une
manette adaptée uniquement pour un droitier ou un gaucher. Cependant, cela nous limitera peut-être dans le choix possible des types de jeux. Tout comme les autres
manettes adapté, l’utilisateur nécessitera un peu d’entrainement.

==Analyse du premier concurrent==

Jouer aux jeux vidéo à une main n’est pas une idée d’aujourd’hui. En 1990, Nintendo propose le Power Glove. Mais il tombe très rapidement aux oubliettes suite à des problèmes techniques.

Un autre gant a fait son apparition quelques années plus tard. Celui-ci, plus technique, il faut office de manette Play Station: le Reality Quest Power Glove.Cette idée de manette-gant, permet de jouer à la PS avec une seule main, elle a était conçue et présentée pour les E3, un salon d’exposition de gaming.Le gant est conçu pour contrôler l’équivalent des 14 boutons et 2 joysticks à l’aide d’une seule main. La « manette » est fixée dans la pomme de la main. L’utilisateur contrôle les mouvements verticaux et horizontaux en pivotant le poignet, et utilisent les 4 boutons d’action principaux et L1/R1 avec les doigts. Les autres boutons sont accessibles par un seul bouton rond contrôlé par le pouce.
La manette est adaptée pour beaucoup de jeux vidéo, dont les plus simples sont les jeux de voitures et de combats (arcade).

; Problèmes:
*Besoin de toute la motricité de la main, c’est-à-dire que si le patient à un doigt paralysé ou manquant, il ne pourra pas jouer avec ce gant
*Design obligatoirement droitier
*Les boutons de contrôle sont peu sensibles et peuvent nécessiter de la force
*Design compliqué et nécessitant beaucoup d’entrainement.

;Lien : https://www.youtube.com/watch?v=qV0SxSJDCYg

 
==Analyse du second concurrent==

Ben Heck, de son vrai nom Benjamin J.Heckendorn, est un concepteur de mods de consoles (mods pour modification, soit « manettes modifiées ») et une star
du net grâce à ses vidéos tutoriels.Il propose alors énormément de produits adaptés ou dérivés en guise de manettes.
Parmi les mods qu’il a réalisé, il a modifié une manette de PS4 afin de la rendre accessible à une personne ne pouvant jouer qu’à une main. Pour cela, il a déplacé les boutons en respectant l’ergonomie de la main valide et modifie les connexions. Il peut lui arriver de rajouter des boutons pour en remplacer un autre. Il réalise également le même système avec la Xbox. Sur la photo ci-dessous, il a adapté la manette pour un droitier.

; Problèmes:
*Besoin de toute la motricité de la main, c’est-à-dire que si le patient à un doigt paralysé ou manquant, il ne pourra pas jouer avec cette ma
*Design obligatoirement droitier ou gaucher, une modification = une manette= une personne
*Besoin obligé du pouce et de l’index, même si avantage : 3 doigts nécessaire.

;Lien :: https://www.youtube.com/watch?v=LieHIscadjk

==Scénario d'usage du produit ou du concept envisagé==

La technologie est ,aujourd’hui, omniprésente dans notre vie. Les consoles de jeux ont envahies les maisons avec plus de 7 personnes sur 10 jouant aux jeux vidéos sur consoles en France (chiffre de l’Express). 0,18% des français sont handicapés cela représente 12 millions de français. Dans ce chiffre, 13,4% des personnes ont un handicap moteur. En 2017, les grands groupes comme Sony ou Microsoft avec respectivement PlayStation et Xbox ne permettent pas à tout le monde de jouer avec une manette. Les manettes sont prévues pour des personnes ayant leurs membres valides, plus précisément les mains et les bras.

Après un accident de voiture, un jeune garçon a perdu la motricité d’un côté du corps. Passionné de jeux vidéo, il se retrouve avec des difficultés à jouer sur sa console PS4. Ingénieux, il utilise la manette en la coinçant entre son épaule et le creux du cou. Usant de la mâchoire et de sa main valide pour contrôler les joysticks et les boutons. L'exercice étant inconfortable et fatiguant il eu l’idée de proposer à des futurs ingénieurs de lui proposer une manette adaptée à son handicap.

Les deux pré-ingénieurs ,avec leur tuteur, ont une idée révolutionnaire : La manette modulable ! Elle permettrait au jeune garçon, ainsi que d’autres joueurs, de pouvoir continuer de s’amuser ou même de commencer à jouer au jeux sur console.
Cette manette aidera fortement dans les centre de rééducation pour faire passer le temps et donner du plaisir à des personnes qui ne peuvent plus s’amuser avec leur console traditionnelle. Elle pourra aussi ouvrir de nouvelles possibilités pour certaines personnes qui n’auraient jamais essayé jusqu'à présent.
Comme son nom l'indique, elle sera modulaire et s'adaptera à différents handicaps. Accompagnée de son application d’initialisation, elle sera accessible aussi bien aux enfants, patients, parents et aides soignantes.

Quelques mois plus tard...Le jeune patient fan de Need For Speed, peut maintenant piloter sa voiture comme un vrai professionnel grâce à l'un des joysticks qu'il utilisera avec sa main valide et il pourra accélérer à des vitesses folles à l'aide de boutons poussoirs au niveau de son pied valide et gagner la partie. Son ami venu lui rendre visite, pourra en lieu et place des aides soignantes configurer à l'aide de la tablette (portable) la manette du patient.
Si le patient change de jeu pour Tekken et que la configuration des modules ne lui convient plus, il peut interchanger les éléments de la manette selon son envie et son confort. Ainsi il peut faire sauter son personnage, il utilisera un module bouton supplémentaire, qu'il actionnera avec le poing.

==Fonctionnement==

Suite à une analyse fonctionnelle et à la formulation de notre projet, nous avons pu définir le fonctionnement de notre système. Notre produit, la manette, doit être accessible d’après nos objectifs à différents types de handicaps moteurs. Ainsi, l’idéal serait de concevoir une manette modulable afin qu’elle puisse s’adapter à toutes les situations. Ce n’est plus au patient de s’adapter à la manette mais à la manette de s’adapter au patient.
Cela signifie que la manette sera, dans la limite du possible et de la sensibilité du corps du patient, composée de plusieurs parties dites « modules » comportant un ou plusieurs actionneurs (boutons, joysticks, gâchettes...). Ces modules seront déplaçables afin d’être utilisé avec différents membres du corps : un doigt, une main,
une jambe ou même un pied. Il suffira de les connectés entre eux suivant l’organisation souhaitée, le Gameplay du jeu ou en fonction du handicap. Le tout sera relié à une application.
L’application sera alors mise en place pour connecter les différentes parties du point de vue software pour prérégler la manette en fonction du patient. Il pourra alors choisir les boutons en fonction du jeu, de ses mouvements mais aussi choisir la sensibilité.

L’application et les modules devront être intuitifs et faciles d’utilisation. De cette manière des utilisateurs non avertis dans le domaine informatique ou jeunes pourront eux-mêmes gérer les connexions.

==Réponse à la question difficile==

'''Question : Comment interconnecter les différents modules de la manette ?'''

Il nous faut pour ce projet interconnecter les modules modélisant la manette qui seront connectés à la consoles PS4 via une Raspberry Pi 3.
Le choix de la Raspberry Pi 3 nous permet d'utiliser son module Bluetooth pour communiquer avec la PS4, ce choix est plus adaptée au projet que du filaire.
Concernant l'interconnexion des modules, nous travaillerons en deux étapes "preuves concept" : filaire et sans fils (Bluetooth).

'''Objectif 1 : Preuve concept filaire'''

Dans cette première partie de projet, nous souhaitons avoir une 1ère preuve de prototype rapidement. Nous nous concentrerons alors sur la communication entre la RPi3 et la PS4 ainsi que sur la conception des modules. Pour les modules, nous réaliserons des cartes électronique pour chaque module avec un micro-contrôleur. La communication filaire nous permettra d'interconnecter les modules à la RPi3 avec un bus SPI.

'''Objectif 2: preuve concept sans fils'''

Une deuxième étape du projet est la réalisation de la solution idéale sans fils. Celle-ci pourra commencer à être développée petit à petit en parallèle avec l'objectif 1. Le but ici, est d'interconnecter les modules en Bluetooth. Nous avons choisi le Bluetooth pour garder une connexion commune sur toute la chaîne.
Nous rajouterons alors un module bluetooth à chaque module de la manette.

'''Objectif 3: possibilité d'adapter les boutons (capuchon en 3D)'''

=Préparation du projet=

==Cahier des charges==

''Chef de projet:'' Alexandre Boé 
''Responsables:'' Xavier Redon, Thomas Vantroys 
''Partenariat:'' Marc Sautelet (non etablie) 
''Elèves-ingénieurs:'' Camille Saâd, Transley Gracias 

'''Sujet :''' Manette modulable pour personne à déficience moteur compatible PlayStation 4 

===Objectifs principal (1er POC) : ===
Faire transmettre des informations issus des actionneurs (ex:boutons poussoires) via des arduinos jusqu’à la Raspberry Pi 3 en SPI. 
Envoyer les données reçues vers la PS4 en USB 

===Objectifs secondaire (2e POC):===
Créer des modules avec un microcontrôleur et une puce bluetooth pour permettre une meilleurs flexibilité (c-àd pouvoirs avoir une meilleure ergonomie et une connexion sans fil) 
Connecter la Raspberry Pi 3 en Bluetooth à la PS4 

[[Fichier: beteacorne.jpg||middle|600px|Bete a corne manette]]

==Choix techniques : matériel et logiciel==

===Liste de matériel :===

'''Modules boutons/joysticks/gachettes'''

3 Push buttons : 
- O X Y Carré R3 L3 
- Guide PS 
- start/back 
--> 0,45€/unité TTC [https://www.gotronic.fr/art-bp-miniature-krs1273-16976.htm] 

1 Thumbstick original: 
Joystick analogique 4 directions --> 4,25€/unité TTC [https://www.gotronic.fr/art-joystick-analogique-4-directions-19063.htm] 

1 buttons trigger L1 L2 => 1x Thumbstick original''' 

'''Cartes Atmega328p /connexion spi/'''

3 Arduino UNO 
1 Arduino UNO atmega328p retirable 
4 capacite 22pF traversantes 
2 resistances 10 kOhm traversantes (à récupérer) 
2 oscillateurs quartz 16MHz traversante 
2 atmega328p-pu et support 

'''Cartes module bluetooth nrf52810 '''

6 capacités 100nF 0603 
6 capacités 12pF 0603 
2 capacités 4,7pF 0603 
2 capacités 1µF 0603 
2 capacités 100pF=0,1nF 0603 (à récupérer) 
2 capacités 0,8pF 0603 (a acheter, commande en cours) 
2 inductance 3,9nH 0603 (a acheter, commande en cours) 
2 oscillateur quartz 32 MHz 

''' Connexions et autres '''

1 Led RGB neopixel [https://www.adafruit.com/product/1734] 
1 Raspberry Pi 3 
--> ~36,23€/unité TTC [https://fr.rs-online.com/web/p/processor-microcontroller-development-kits/8968660/?src=raspberrypi] 
1 Raspberry Pi Zero W (commandée) [https://www.raspberrypi.org/products/raspberry-pi-zero-w/] 
6 Alimentations 5V ou 3,3V 
par exemple, 12 piles de type CR2016 3V rechargeables ou 24 piles AAA 1,5 V rechargeables
5 modules Bluetooth nrf de Nordic : nRF52810-QFAA-R 
--> 3,17€/unité + frais expédition [https://www.mouser.fr/productdetail/nordic-semiconductor/nrf52810-qfaa-r?qs=sGAEpiMZZMve4%2FbfQkoj%252bG%2FosjLoe2oghFQwQllMrQ4%3D]
5 Lignes broches mâles 

===Logiciels:===

- IDE arduino
- Altium
- FreeCAD ou Inkscape

==Liste des tâches à effectuer==

'''Etape 1 : Gestion du projet'''

* Définition des cahiers des charges fonctionnel et technique, choix d'orientation...
* Recherche techniques sur les différentes connexions possibles entre les modules, la RPi 3 et la console PS4
#Recherche connexion SPI entre les modules et la RPi3
# Recherche connexion bluetooth entre la RPi3 et la PS4
# Recherche connexion bluetooth pour les modules
# Recherche carte avec montage Atmega328P-PU et anticipation module bluetooth
* Détermination du matériel nécessaire
* Réflexion sur l'application

'''Etape 2: Réalisation du projet'''

'''Partie 1: Preuve concept manette en filaire'''

* Conception de cartes électroniques pour 2 modules (/!\ prévoir modules bluetooth)
* Réalisation connexion SPI avec 2 modules : programmation des Atmega328p en liaison série.
* Si tests concluant, ajouter des modules jusqu'à en avoir 5 (1 pour chaque type de boutons)
* Connexion bluetooth entre la PS4 et la RPi3
* Réalisation du support des modules avec fixations possibles (imprimante 3D)

'''Partie 2: Preuve concept manette en bluetooth'''

* Ajout des modules bluetooth aux cartes électroniques
* Connexion bluetooth entre les modules

'''Partie 3: Application Android : paramétrage de la manette'''

* Créer une application sur tablette ou smartphone (Android) afin de configurer la manette aux besoins (inter-connexion des modules et console)

==Calendrier prévisionnel==

{| class="wikitable centre" width="80%"
|+
|-
| width="23%" |
'''Date'''
| width="34%" |
'''Tache à réaliser''' 
|-
| width="23%" |
17/01/18-24/01/18
| width="34%" |
Faire des recherches sur les différentes interconnexions du système : Bluetooth, RPi-Atmega328 (SPI), RPi-PS4
Continuer liste des taches, matériel, Début recherches + réflexion fixation support des modules
|-
|width="23%" |
31/01/18
| width="34%" |
Recherche technique connexion PS4-RPi3 et connexion SPI RPi3-Module + code
|-
|width="23%" |
31/01/18-07/03/18
| width="34%" |
Réalisation 1er prototype (+ début prototype 2)
|-
|width="23%" |
07/03/18
| width="34%" |
Seance 7 : Test prototype filaire
|-
|width="23%" |
07/03/18-09/05/18
| width="34%" |
Réalisation 2eme prototype + application Android
|-
|width="23%" |
09/05/18
| width="34%" |
Seance 14 : Test prototype Bluetooth
|-
|width="23%" |
14/05/18
| width="34%" |
Video projet
|-
|width="23%" |
15/05/18
| width="34%" |
Finalisation projet et Rapport
|-
|width="23%" |
16/05/18-17/05/18
| width="34%" |
Soutenances Projet
|}

=Réalisation du Projet=

==Feuille d'heures ==

Voici le tableau d'heures du binôme:

{| 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 S11 !! Heures S12 !! Heures S13et+ !! Total
|-
| Analyse du projet
| 10
| 2
| 1
| 1
| 1
|
|
|
|
|
|
|
| 20min
|
| 15h20
|-
| Cherches techniques
|
| 3
| 4
| 4
| 2
| 2
| 1
|
|
|
| 1
| 1
|
|
| 18
|-
| Rédaction du wiki et rapport de projet
|
| 1
| 1
| 1
| 1
| 30min
| 1
|
| 2
| 30min
| 30min
|
| 2
|
| 10h30
|-
| Programmation
|
|
|
|
| 3
| 2
| 3
| 5
| 4
| 7
| 8
| 6
| 5
|
| 43
|-
| Cartes électroniques
|
|
|
|
|
| 6
| 8
| 4
| 6
| 2
| 1
| 2
| 2
|
| 31
|-
| Application
|
|
|
|
|
|
|
|
|
|
|
|
|-
|-
| Total Semaine
| 10
| 6
| 6
| 6
| 7
| 10h30
| 13
| 9
| 12
| 9h30
| 10h30
| 9
| 9h20
|
| '''117h50'''
|}

==Prologue==

Avant la réalisation et conception d'un projet, il est important d'analyser celui-ci. Nous avons allons consacré le prologue à l'analyse fonctionnelle de la manette. Nous avons également eu une réflexion sur l'analyse technique, cela nous a permis de réaliser une liste de matériel. Il est important de définir les objectifs ainsi que les besoins afin de ne rien oublier. (Voir ci-dessus Analyse projet)
Nous avons également organisé notre travail, pour le partage de documents de recherches et la rédaction de compte-rendu final nous avons réalisé un google drive. Par la suite, nous créerons un projet Git.

Durant ce temps, nous avons décidé de réaliser 5 modules. Les modules sont les différents boutons de la manettes qui nous pourrons placer selon nos choix (boutons modulaires) pour notre prototype projet pour chaque type des boutons d'une manette PS4. Ces modules devrons être connectés à la console et interconnectés. Le tout sera lié à une application Android. Suite à quelques recherches et nos analyses, nous avons décidé les points suivants :

- On commencera avec 2 modules et on les multipliera par la suite.
- Les premiers tests sont réalisés avec des boutons petits pour assurer leur caractéristique "modulaires", par la suite nous pourrons ajouter des capuchons de taille plus importante (imprimante 3D ou achat)
- Conception modules : réalisation de carte avec un microcontrôleur atmega328 programmable pour chaque module (anticiper le module Bluetooth)
- Projet en 2 parties : prototype filaire et prototype Bluetooth
# Prototype filaire : connexions entre les modules et la RPi3 en SPI, connexion Rpi3-PS4 en Bluetooth, avec l'application en filaire à la RPi3
# Prototype Bluetooth: connexion Bluetooth entre modules-RPi3-PS4-apllication

[[Fichier: structuremanette.png||center|400px|Concept manette modulable]]

==Semaine 1==

Durant la séance, nous nous sommes concentrés les recherches afin de définir clairement le cahier des charges technique. Il s'agit des réalisations à mettre en œuvre pour les inter-connexions des éléments de la manette.
Ainsi, nous avons fait des recherches sur :

===Connexion SPI entre les modules (Atmega328p) et la RPi3===

SPI: Serial périphérique interface BUS

[[Fichier: yWGmW.png||right|200px|Concept manette modulable]]
Comme indiqué sur l'image ci-dessus, la Raspberry pi 3 peut communiquer en SPI avec ses broches CS0 (24), CS1 (26), SCLK (23), MISO (21), MOSI (19). Celles-ci permettent de communiquer avec un ou plusieurs esclaves (dans notre cas, des Atmega328p) en reliant directement les broches concernées de la RPi3 à celles des composants esclaves.
Chaque broche CS0 (24) ou CS1 (26) ne peut être connectée qu'à l'entrée SS (aussi appelé CS) d'un seul esclave.
C'est a dire que chaque CS est lié à un esclave afin de choisir avec lequel la communication est établie à un moment donné, et les MISO sont reliées entre elles en cascade, de même pour les SCLK et les MOSI. On peut noter que le maître impose la fréquence d’horloge et sélectionne l’esclave auquel les données sont envoyées. 8 MHz est le plus rapide supportable a 3,3V

[[Fichier: fonctionnementSPI.png||right|200px|Connexion SPI multi-esclaves]]

Voici un schéma du fonctionnement souhaité :

Comme nous souhaitons avoir 5 modules environ il nous faudra rajouter un composant en plus afin d'augmenter les possibilités de sélection, par exemple des démultiplexeurs.
Dans un premier temps nous essaierons avec 2 esclaves, puis on augmentera le nombre.

===Connexion Bluetooth PS4-RPi3===

Les recherches portent également sur la connexion entre la manette PS4 et la console. Elles concernent le protocole de communication via Bluetooth

Caracteristique pour la PS4: Bluetooth®v4.0, Qualcomm Atheros AR3002 Buetooth LE: 2,4-2,5 GHz 

Caracteristique de la connexion : 

*Vitesse de transmission >> 3 Mbit/s 8N1
*Relevé tous les 1.3 millisecond (peut-être)
*Chaque manette à une adresse unique BD_ADDR qui correspond à l’adresse MAC de la carte Réseau
*Protocole de détection est le SDP basé sur une emission reception PDU
*L’Attribut ID est representer en TLV Type Length Value
*Communication HCI ACL Data Packet

===Rélisation des cartes électroniques===

matériel nécessaire pour un PCB : 

*breadboard
*câbles
*1 x 10k Ohm résistance
*Quartz 16Mhz clock crystal
*2 x 22 pF capaciteurs
*Atmega328P-PU

Ressources:
[[https://www.arduino.cc/en/Main/Standalone]]
[[http://www.eprojectszone.com/atmega-328-pu-standalone/]]
[[https://www.arduino.cc/en/Tutorial/ArduinoToBreadboard]]

==Semaine 2==

Durant la semaine deux et durant la séance, nous avons continué et approfondie nos recherches sur le projet. Nous avons pu ainsi affiner nos taches de réalisation et donc notre cahier des charges.

===Bluetooth sur la Raspberry Pi 3===

voir https://peip-ima.plil.fr/mediawiki/index.php/BE_2017-2018#Configuration_du_syst.C3.A8me_embarqu.C3.A9

(sudo apt-get install pi-bluetooth)

''connexion sur la raspberry par ssh:''
su
update-rc.d ssh enable
invoke-rc.d ssh start
ssh pi@172.26.79.1XX

''bluetooth''
bluetoothctl
agent on
default-agent
scan on
pair [device Bluetooth address] (exemple: pair XX:XX:XX:XX:XX:XX )

===Modules SPI et Bluetooth===
''NOUVELLE REFLEXION : Connexion SPI entre les modules (Atmega328p) et la RPi3 --> MODULES BLUETOOTH''

Si multi-esclaves= plusieurs modules :
Il faut ajouter des sélections pour les SPI → démultiplexeurs OU ne pas utiliser les CS0 et CS1, et plutôt des pins entrée/sortie de la RPi3 lié au SS comme ça on choisit direct le module esclave voulu.

'''IMPORTANT:''' Nous avons étudié à nouveau la datasheet de notre module bluetooth nrf de Nordik. Le module bluetooth comporte déjà un microprocesseur !
Un module plutôt peut donc jouer le rôle de notre atmega328p. Il n'y a alors pas besoin de réaliser des cartes électroniques de type arduino standalone. Nos PCB regrouperont alors uniquement l'alimentation, un actionneur (bouton, joystick), le module bluetooth et les broches de connexion si besoin...

Cette séance nous a alors permise de revoir entièrement le matériel nécessaire. Notre liste de matériel nous semble alors plus réfléchie et limitée au nécessaire.

===Connexion Bluetooth PS4-RPi3===

Le site qui détaille le protocole Bluetooth PS4 n'est pas complet et de plus n'ayant pas accès à une PS4 (pour le moment) nous avons décidé de commencer par une connexion USB (pour laquelle on dispose de toutes les informations) et qu'on pourra tester plus facilement.

==Semaine 3 : Début premier prototype==

*'''Connexion SPI RPi3-Arduino'''

Comme vu durant les semaines précédentes, nous souhaitons réaliser une connexion Multi-esclaves en SPI entre la Raspberry pi et plusieurs modules.
Cette semaine nous avons vu que la réalisation de notre premier prototype doit aller vite. Il ne nous est pas nécessaire d’attendre les modules bluetooth si il nous faut dans cette partie uniquement utiliser son microprocesseur. Ainsi pour chaque module nous utilisons une arduino UNO. Nous réaliserons les programmes en C afin de pouvoir les réutiliser avec les modules bluetooth par la suite.
Une fois la connexion réalisable nous adapterons les programmes aux modules bluetooth Nordik. En effet, ceux-ci comporte déjà un microprocesseur, le module peut jouer le rôle de notre atmega328p. Il n'y a aurait alors pas besoin de réaliser des cartes électroniques arduino standalone sur PCB, mais directement des cartes électronique avec le module et le module voulu (bouton, joystick...) et l'alimentation.
Durant la séance nous avons alors revu la liste de matériel nécessaire.

[[Fichier: prototype1.jpeg||center|600px|connexion filaire prototype 1 filaire arduino]]

Durant la séance, nous avons recherches des exemples de codes et de librairies pour Arduino SPI et RaspberryPI SPI.

Nous avons également commencé le programme de la connexion SPI pour l'arduino et récupéré les bibliothéques SPI.h avec SPI.c. Nous nous sommes alors concentrer à les comprendre, pour pouvoir l'utiliser.

*'''Réalisation du projet Git'''

Création du projet IMA4_Projet35_ManetteModulable sur Git et partage de celui-ci.
Les premiers dossier crées durant la séance :
-Arduino (connexion SPI arduino) : ProtoSpi.c + dossier librairie SPI + Makefile
-RPI (dossier codes pour Rpi)
-Readme.md

==Semaine 4==

Pour le prototype 1 FILAIRE nous réaliserons les étapes suivantes :

#Réalisation du programme SPI pour arduino
#Réalisation du programme SPI pour la RPi
#Connexion USB avec la PS4 ou ordinateur
#Réalisation de cartes électroniques atmega328p-pu standalone (remplacer les Arduinos)
#Remplacer les "PCB arduino" par le module bluetooth et adapter la connexion
#Conception 3D de la délimitation 1 axe pour le joystick "gâchette"
#Réalisation de l'application Androïde.

Une fois ces étapes réalisées nous auront alors une preuve de concept filaire et nous pourrons alors passer à une connexion bluetooth.
Le passage à la connexion bluetooth sera le deuxième prototype et le cas idéal de la réalisation de la manette modulable.

===Mise à jour Matériel===

- Modéliser les boutons gâchettes L1/2 R1/2 de la manette PS4 (boutons sensibles à la pression) --> un joystick dont nous bloquerons un axe (imprimante 3D)
- Remplacer la RPi 3 par une Rpi zero W qui nous permettrait de réaliser plus facilement une connexion USB tout en gardant l'avantage du bluetooth.
- Choix de l’alimentation pour les 5 modules Bluetooth: nécessitent 3V --> utiliser des piles rechargeables 1,2V AAA plutôt que piles rondes 3V.

Nous avons également besoin du matériel cité en semaine 1 pour réaliser des cartes électroniques atmega328p-pu standalone. ( nous revenons alors sur les décisions de la semaine 3)

===Connexion SPI RPi3-Arduino===

Montage Raspberrypi et 1 arduino en PSI + 1 bouton + 1 led.
Voici le choix des branchements :

MASTER = RPi
SLAVE= Arduino

'''SPI sur Arduino:'''
MOSI -> GPIO11 //PB3 //master OUT to the slave IN
MISO -> GPIO12 //PB4 //slave OUT to the master IN
SCLK -> GPIO13 //PB5 //serial clock
SS -> GPIO10 //PB2 //slave select
'''Led, bouton et autre...'''
LED --> GPIO6 //PD6
GND
+5V (if required)
'''SPI sur la Raspberry Pi'''
SPIO MOSI -> PIN19
SPIO MISO -> PIN21
SCLK -> PIN23
SPIO CS0 -> PIN24

Continuation du code pour faire clignoter Led branchée à une arduino depuis la Rpi, en connexion SPI.

===Connexion USB PS4-RPi3===

Durant la séance, nous avons regardé comment utiliser le port série sur la RPi3, soit utiliser les UART.

Nous avons réaliser qu'il n'était pas aussi simple d'utiliser le port serie USB de la Raspberry Pi 3, en effet le SoC est un BCM2837 .
De plus nous ne pouvons pas utiliser le même port pour l'alimentation et la connexion.

Une des solutions à cette difficulté serait d'utiliser une RPi ZERO W à défaut d'une RPi 3. On pourrait alors avoir un port d'alimentation avec connexion USB mais également retrouver la connexion bluetooth dont nous avons besoin.

==Semaine 5==

===Programmation: Réflexion définitives prototypes filaire ===

Durant la semaine 5, nous avons continué la réalisation du prototype filaire par l'avancé du code SPI ainsi que les recherches concernant le protocole PS4.

Pour réaliser la connexion entre la PS4 et les différents modules, nous avons vu la semaine dernière que nous utiliserons une RPi zero W (que nous avons commandé). Celle-ci nous permet d'utiliser le bluetooth mais elle nous permet également de réaliser un réseau local sans fil. Ce qui peut être pratique dans la mesure où notre projet est modulable.
En attendant la réception de la commande, nous nous sommes penché sur les programmes et la configuration nécessaire à l'utilisation de la RPi zero W.

===Electronique===

[[Fichier: bouton_c1.jpg|100px|thumb|left|PCB bouton]]
[[Fichier: arduinobb.jpg|200px|thumb|right|atmega328p-pu branchement test]]

Du coté électronique, nous avons réalisé sur fritzing certaines cartes électroniques. Les Arduino Uno servant actuellement de test, seront remplacées par des PCB atmega328p-pu standalone avec des broches permettant les branchements nécessaires SPI ou encore aux modules "boutons/joystick". Pour les boutons, nous avons également réalisé un pcb afin de faciliter les branchements.

Il nous faut alors également une 3eme carte qui nous sera nécessaire pour la réalisation du prototype sans fil. Dans notre liste de matériel, nous avons des composants nrf52810 bluetooth, ceci doivent être soudé avec les capacités de protection mais également des broches de communication. Nous avons alors commencé cette carte électronique sur Altium avec le fichier projet PCB du distributeur à modifier.

[[Fichier: Arduino_c1.jpg|100px|thumb|center|PCB atmega328p-pu]]

=== Construction 3D ===

Enfin, nous avons commencé à réaliser des boîtiers 3D pour certains modules. Par exemple, comme nous l'avions vu précédemment, un des joysticks servira de bouton-gâchette en utilisant un seul de ses axes. Il nous faut alors réaliser un boitier qui bloque l'un des axes, mais également une tige qui nous permettra de pousser le joystick de manière simplifiée.

==Semaine 6==

===Programmation: configuration RPi Zero W ===

Ayant reçu la Raspberry Pi zero W en début de semaine, nous nous sommes concentrés sur la programmation et la configuration de celle-ci.

===Electronique: PCB nrf52810===

Les cartes réalisées en semaine 5 sont validées et en attente de réalisation.

Cette semaine a permis la réalisation et la finalisation de la carte électronique nrf52810. Il nous a fallu recommencé cette carte deux fois. En effet, une fois finie sur Altium nous avons réalisé que les empreintes des CMS sur PCB fourni par le constructeur ne correspondent pas au matériel CMS de l'école. Face à cette inattention de notre part, nous avons décidé de refaire entièrement la carte électronique sur fritzing. Ayant la datasheet et des plans d'inspiration PCB, nous avons pu refaire la carte entièrement.
Sur celle-ci nous avons ajouté des broches de connexion au besoin, un branchement Jtag et ICSP pour la programmation et la connexion SPI.
La carte est en attente de validation, puis validation.

[[Fichier: nrf52810_circuit2.jpg||center|400px|PCB carte nrf52810]]

===Révision matériel ===

Pour la réalisation de nos composants électroniques, il nous a fallu faire une révision des composants disponibles à l'école:
(les quantités indiquées ci-dessous pourront être augmentée si nécessaire,pour avoir dans l'idéal un module de chaque type de la manette, ici on se concentre sur BOUTON et JOYSTICK)

'''Cartes Arduino:'''
* 4 capacite 22pF traversantes
* 2 resistances 10 kOhm traversantes (à récupérer)
* 2 oscillateurs quartz 16MHz traversante
* 2 atmega328p-pu et support

'''Cartes nrf52810'''
* 6 capacités 100nF 0603
* 6 capacités 12pF 0603
* 2 capacités 4,7pF 0603
* 2 capacités 1µF 0603
* 2 capacités 100pF=0,1nF 0603 (à récupérer)
* 2 capacités 0,8pF 0603 (commande en cours)
* 2 inductance 3,9nH 0603 (commande en cours)
* 2 oscillateur quartz 32 MHz

'''Cartes modules Boutons'''
* un sachet de broches mâles (qu'on utilisera également pour les autres cartes, à récupérer/acheté)

Nous avons alors mis-à-jour la liste de composant située plus haut, ainsi que celle de la page IMA4 2017/2018 [https://projets-ima.plil.fr/mediawiki/index.php/Projets_IMA4_SC_%26_SA_2017/2018]

==Semaine 7==

===Programmation: connexion wifi RPi Zero W et Bootloader sur Atmega328p-pu ===

Pendant cette semaine, nous avons continué la programmation et la configuration des Raspberry Pi 3 et Zero W afin de les utiliser en connexion Wifi.

Nous avons également continuer les programmes de récupération de données : état des boutons et du joystick. Ces programmes sont appliqué sur l'atmega328p-pu standalone sur la plaque d'essai en attendant que le PCB soit opérationnel.
Pour pouvoir programmer l'atemega328p-pu comme une arduino UNO, il nous faut suivre plusieurs étapes :

'''1.Flasher le Bootloader'''
Nous avons 2 Atmega328p-pu neufs, ainsi il nous faut flasher le bootloader sur chacun d'eux afin de pouvoir les utiliser et les programmer sur une breadboard dans un montage minimaliste arduino-standalone.
Pour cela, on peut utiliser une carte arduino UNO. On vérifie le port et le type de carte sélectionnés dans le menu >Outils. Sur cette carte on téléverse le fichier arduinoISP.ino qui se trouve dans les exemples en étant en progrmamateur AVr ISP mkll (>outils>programmateur)
Puis on met l'atmega328p-pu qui nous intéresse sur le suppor socket de la carte. On change de nouveau le programmateur pour Arduino as ISP et on fait >tools>burn bootloader, soit >graver la sequence d'initialisation.
Ces étapes faites, on peut retirer notre microcontroleur et le replacer correctement dans le montage.

'''2.Programmation atmega328 sur breadboard'''
Une fois l'atmega328p-pu préparé, on peut le programmer. On peut le faire simplement à l'aide de la carte arduino UNO utilisée précédemment.On branche les Tx et Rx en commun ainsi que le reset, le GND et le VCC.

Nous avons réaliser des codes basiques tels que le clignotement d'une led rouge ou encore l'affichage de "hello world" sur le moniteur série pour vérifier la bonne fonctionnalité du montage. Cela fait nous avons pu écrire sous Arduino IDE le code de lecture des états.

[[Fichier: montage_BB_test.jpg||left|200px|programmation modules arduino sur breadboard]]

===Electronique : soudure carte de test modules ===

Comme nous l'avons déja vu lors de la réalisation des PCB, si l'on souhaite programmer un atmega328p-pu en bootloader, le montage est simple. Il peut être minimaliste en utilisant une arduino UNO, un atmega328, une breadboard et 3 composants: 1 quartz 16MHZ crystal, 1 résistance 10kOhm et 2 capacitors céramiques de 22pF.
Durant la semaine 7, nous avons soudé les composants traversants de la carte électronique correspondant à ce montage ainsi que le PCB du bouton.

==Semaine 8==

===Programmation ===

===Electronique : Correction soudure et soudure CMS===

Durant cette semaine, nous avions souhaité programmer la carte électronique atmega328p-pu. Cependant, nous avons réaliser que nous avions fait une erreur lors de l'envoie du PCB à la production. En effet, celui-ci avait été fait en Top sur le logiciel Fritzing et non en Bottom. Hors nous avions soudé les composants (durant la semaine 7) comme pour un circuit imprimé en bottom, l'atmega328p-pu se retrouve alors inversé par rapport aux pistes.
Comme solution, nous avons choisi de souder un deuxième support pour l'atmega328 de l'autre coté de la carte avant de la refaire au propre. En effet, avant de la refaire il nous faut vérifier si la carte est bien programmable.
Une fois cela fait nous avions pu programmer la carte mais, nous avions également réalisé la pin 2 de l'atmega328 était prise par le bouton poussoir. Or, nous avons besoin des pin 2 et 3 pour le RX et TX permettant la programmation de l'atmega à partir d'une arduino, les pistes branchement RX-TX n'ont également pas été prévus pour le téléversement des programmes sur la carte. Il nous faut alors couper une piste et souder des câbles pour utiliser toutes les pistes souhaitées.

[[Fichier: correction_proto_PCB.jpg||right|300px|PCB arduino correction]]

Durant cette semaine, nous avons également souhaité souder les CMS et le composant bluetooth nrf52810 sur la carte imprimé et reçu lors de la semaine 7. Pour cela, nous avons convenu de travailler dans la C202 durant la séance du mercredi.

[[Fichier: PCB_nrf52810.jpg||left|400px|carte electroniques imprimées]]

====Comment souder des CMS ?====

les CMS sont des composants montés en surface c'est à dire qu'ils sont montés du même côté que les pistes cuivrées (à l'opposé des composants traversants) et sont de petite tailles souvent de l'ordre du millimètre. La taille est déterminée par 4 chiffres : les 2 premiers pour la longueur et les 2 derniers pour la largeur. On a du 1206,0805,0603 ou encore 0402. Il est même possible de trouver plus petit. A l'école nous utilisons souvent du 0603, c'est le cas de nos composants.
Pour souder des CMS 0603, il nous faut utiliser une autre méthode qui n'est pas le fer à souder :
# Préparer la veille la pâte à braser la veille (dans une seringue)
# Gommer la carte pour éviter l'oxydation (attention à ne pas retirer les miettes de gomme en soufflant dessus)
# Appliquer avec la seringue la pâte sur les empreintes et piste souhaitées. Pour les endroits difficile à atteindre ou avec 2 pistes proches les unes des autres, il est possible de mettre la même goutte de pâte sur les 2 pistes. Cela de causera pas de court-circuit par la suite. En effet, la pâte est composée d’alliage qui sous la chaleur va se fluidifier et se coller uniquement aux pistes métallique. Le reste fondera sous la chaleur du four.
# Appliquer les CMS sur la pâte au fur et à mesure (attention ! ne jamais toucher les CMS avec les doigts, tjrs utiliser une pince)
# Mettre au four

====Bilan soudure nrf52810====

Cependant, une fois le matériel nécessaire préparé, et la pâte mise sur les pistes souhaitées, au moment de déposer le composant, nous avons réalisé que celui-ci était beaucoup plus petit que l'empreinte sur le PCB. Il s'agit d'un composant boitier QFN48. Fritzing ne proposant au plus proche des boitiers QFN24 ou LQFP48, celui-ci a basculé automatiquement pour un boitier LQFN48, de dimension plus grande. Face à ce manque de vigilance, nous avions cependant commencer par le nrf52810 (composant concerné) évitant ainsi de gaspiller d'autres CMS.
Nous avons souhaité refaire la carte sous Altium à partir des fichiers fournis par le concepteur (chose que nous avons commencé à faire aux alentours de la semaine 5)
Après la réalisation du schématic, et de la modification des empreintes de capacités, inductances et autres composants de 0402 à 0603. Notre matériel ne permettant que des empreintes 0603.

Lors du routage, une erreur de chevauchement des pistes est notifiée par Altium au niveau du nrf52810. Celles-ci ne présentent pas d'angles et sont déjà de taille 8mil, il nous faut alors passer les pistes en 6mil. Mais 8mil est la taille minimale pour la production à Polytech, nous avons regardé pour envoyer les cartes à faire ailleurs mais le 6mil n'est pas beaucoup conseillé. De plus, il n'est peut-être pas judicieux de continuer avec le composant microcontrôleur-bluetooth Nrf52810 qui prend du temps, donc la carte est difficilement réalisable et peut-être très long à programmer.

Ainsi en cette fin de semaine, nous avons décider face à l'avancer du projet de laisser les nrf52810 de coté et de les remplacer par des modules sans fils plus simples d'utilisation et complets. Ainsi nous aurions plus de chance d'avoir une connexion sans fils entre les modules. Nous pourrions par exemples utiliser des Xbee, des modules Rf...

==Semaine 9==

====Programmation: PS4 et 1er Test SPI sur atmega328p====

'''Raspberry Pi Zero W et PS4'''

'''Modules Atmega328p et SPI'''

Une carte PCB arduino fonctionnant, nous pouvons la programme pour simuler un module. Celle-ci a été designée afin de s'adapter au module que l'on souhaite. Il suffit de brancher le bouton, le joystick ou autre élèment de manette souhaité.
Cette semaine ci, nous avons alors configurer la partie communication SPI pour l'arduino.

'''Que voulons-nous faire avec les atmegas ?'''
Les cartes électroniques atmega328p vont nous permettre de recevoir les requêtes SPI envoyées par la raspberry pi et d'y répondre. La Raspberry enverra un message, par exemple "1", et l'Arduino lira alors l'état du module qui lui est connecté. Une fois l'état récupéré elle le renvoie à la raspberry pi.

Durant cette semaine, nous avons programmé l'atmega afin qu'il soit en esclave, qu'il reçoive un de la RPi "1" et retourne une valeur sauvegardé "int envoi". Nous avons également commencé les tests pour la lecture de l'état d'un bouton (d'après les tests réalisés les semaines précédentes).

'''Code'''
Comme nous l'avons vu précedement lors de nos recherches (semaines 1 à 4) :
La communication SPI nécessite l'utilisation des pins:

MOSI -> GPIO11 //PB3 //master OUT to the slave IN
MISO -> GPIO12 //PB4 //slave OUT to the master IN
SCLK -> GPIO13 //PB5 //serial clock
SS -> GPIO10 //PB2 //slave select

Il faut également paramétrer l'atmega328p en Slave. On note que dans un premier temps, le programme sera codé avec l'arduino IDE (fichiers .ino). Une fois l'ensemble SPI RaspberryPi-Arduino fonctionnant, on remplacera ces codes par du langage C ou C++.

Pour faire la connexion SPI sur l'atmega328p, on utilise la librairie arduino SPI.h, on a alors directement les fonctions nécessaires intervenant sur les registres souhaités : SPCR (spi control register), SPSR (spi status register) et SPDR (spi data register).

#include <SPI.h>

Il est important d'initialise d'abord le setup et on active le port série pour pourvoir utiliser le moniteur série. (Cela servira à verifier la valeur envoyée par la RPi)

void setup (void)
{
Serial.begin (9600);
pinMode(MISO, OUTPUT); //configuration en esclave *master in slave out*
pinMode(buttonPin,INPUT); //config pin bouton
// turn on SPI in slave mode
SPCR |= _BV(SPE);
// preparation interruptions
pos = 0; // buffer empty
process_it = false;
// activation interruptions
SPI.attachInterrupt();
}

On oublie pas de déclarer les interruptions afin de bien lire la requête reçue.

// SPI interrupt routine
ISR (SPI_STC_vect)
{
byte c = SPDR; // grab byte from SPI Data Register
// add to buffer if room
if (pos < sizeof buf)
{
buf [pos++] = c;
// example: newline means time to process buffer
if (c == '\n')
process_it = true;
} // end of room available
} // end of interrupt routine SPI_STC_vect

Dans la loop main, on traite la requête et on utilise '''SPI.transfer(envoi);''' pour transferer à la RPi les données souhaitées.

Durant cette semaine, nous avons également commencé des programmes de test SPI pour la RPi. Il s'agit principalement de programmes de tests tout faits permettant de vérifier la connexion entre cette dernière et l'arduino. Par exemple, la RPI envoie "bonjour" et l'arduino lui retourne ce qu'elle reçoit, soit "bonjour". Sans succés alors.

====Electronique : Fritzing révision====

Lors de la semaine, le modèle PCB de la carte arduino a été réalisé de nouveau sous fritzing avec les broches et connections manquantes. Nous avons également revu la configuration du bouton reset et ajouté une led d'état de l'alimentation. Nous avons ainsi envoyé deux cartes identiques à la réalisation.
La carte déjà soudée lors des derniers jours fonctionnant, elle nous sert de prototype de programmation. Nous pouvons ainsi avancer à la fois sur la programmation des modules mais aussi sur leur réalisation.

==Semaine 10==

====Programmation : PS4 et SPI sur RPi====

'''Raspberry Pi Zero W et PS4'''

'''Modules Raspberry PI et SPI'''

Durant cette semaine, pour la partie Atmega328p-Modules, nous nous sommes concentrés sur la programmation de la communication SPI avec la raspberry pi. Cette semaine a permis une étude plus approfondit sur le fonctionnement pour la RPi.

On rappelle, comme vu des semaines 1 à 4, pour la RPI3 (tout comme la RPi Zero W) utilise les broches : SCLK (23), MISO(21), MOSI (19) et SPI CS0 (24), SPI CS1 (26).
On la programme en Master. A l'aide des fichiers tests d'inspiration, on pourra directement programmer la RPi en C. Lors de la réalisation du code, il y a 3 étapes : l'initialisation/parametrage en SPI pour être maître, l'envoie de la requête puis la réception de données en retour.

Programmant en C, il ne faut pas oublier les librairies suivantes :

#include <stdint.h>
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
#include <getopt.h>
#include <fcntl.h>
#include <sys/ioctl.h>
#include <linux/types.h>
#include <linux/spi/spidev.h> //pour SPI

On va déclarer des variables globales permettant le paramétrage :

static const char *device = "/dev/spidev0.0"; //si on veut CS0 pour atteindre notre SS
static uint8_t mode; //mode est par défaut à 0
static uint8_t bits = 8; //bits par mot échangé
static uint32_t speed = 500000;
static uint16_t delay;

Dans notre main, on ouvre le port (la connexion) au device souhaité, on vérifie les paramètres (registres, connexions...) puis exécute la fonction transfer(fd). transfer(fd) transmet la requête et s'occupe de la réception.

fd = open(device, O_RDWR);
transfer(fd);
close(fd);

==Semaine 11==

====Programmation: PS4, SSH et tests SPI (RPi3&Atemga328p)====

'''Raspberry Pi Zero W et PS4'''

'''Raspberry PI, Atmega328p et SPI'''

Afin de facilité la programmation en utilisant Ethernet, nous avons installer et configuré la RPi pour l'utiliser en SSH depuis les ordinateurs de la E306. En effet, SSH permet de se connecter à distance sur une machine en utilisant un compte utilisateur de la dite machine. En mettant ssh, on pourra directement agir sur les fichiers de la raspberry depuis un terminal de notre PC. Pour cela, on a d'abord vérifier l'adresse IP de notre raspberry pi : 172.26.145.106 avec un écran mais on peut aussi utiliser les commandes ip a et ifconfig. Puis activer le ssh sur la raspberry pi.
On modifie alors le fichier config.txt mais également etc/network/interfaces pour configurer la bonne interface Ethernet sur la raspberry pi.

[[Fichier: configSSH_raspi.png||left|300px|config ssh ethernet]]

Il nous suffit alors de taper la commande : ssh pi@172.26.145.106 pour accéder à notre RPi.

Nous avons continué à réaliser la communication SPI avec des tests entre une arduino UNO et la RPI3. Nous avons commencé par des tests simples inspirés des études de deux semaines précédentes et modulés selon notre utilité.
Nous arrivons alors à lire l'état envoyer "bonjour" et recevoir "ça va" ou encore "1" et recevoir "3". Il faut noter que le SPI échange des trames, la RPI reçoit alors des hexadécimaux.
Nous avons alors continué pour recevoir l'état du bouton ou du joystick lors de l'envoie de "1" sur l'Arduino328p. La semaine prochaine nous testerons ces même codes fonctionnels sur les cartes atmeg327p.

A la fin de cette semaine, nous avons alors des codes Arduino-SPI (.ino) et des codes Raspberry-SPI (.c) permettant l'échange de données. Le but est maintenant de l'adapter aux cartes imprimées et de le rendre pleinement fonctionnel pour plusieurs cartes à la fois, puis ajouter une boucle de vérification en continue jusqu'à une deuxième requête de la RPi.

====Electronique: réalisation au propres des PCB modules====

Suite à une nouvelle erreur de réalisation cartes électronique, nous avons refait et renvoyé à nouveau les cartes imprimées atmega328p.
Nous les souhaitons au propre pour une version finale. Une fois celle-ci imprimées nous pourrons en avoir 3 , un pour chaque module. Les cartes étaient bien imprimées en bottom mais lors du passage des traversants de bottom à top, le logiciel ne les a pas fait miroiter. Par manque d'attention nous avons alors envoyé les fichiers gerber pour des cartes ayant les composants du même coté que la couche de cuivre.
Les cartes électroniques actuelles sont alors correctes et fonctionnelles mais difficile à souder. Pour eviter les erreurs et continuer sur des prototypes de carte nous préférons attendre en nous concentrant sur la programmation PSI de la Raspberry Pi.

==Semaine 12==

====Programmation====

'''Raspberry Pi Zero W et PS4'''

'''Raspberry PI, Atmega328p et SPI'''

- réflexion: penser à faire boucler sur l'arduino une fois la requête reçu, ça veut dire que la manette est ON et donc vérifier continuellement les modules sur chaque atmega.
- SPI raspberry pi - arduino recuperation état du bouton avec les cartes modules (/!\ récuperation à faire dans une variable)

-SSH perso
adresse Rasppi: 192.168.137.10

====Electronique: Finalisation soudure Modules====

Soudure au propre et finale d'une carte atmega328p et donc envoie pour la réalisation de 2 autres cartes similaires et récupération de matériel
Soudure des 2 autres cartes, + tests sur les états = fonctionnelles.
On a donc bien 3 cartes pour les 3 modules de types différents (1 bouton, 1 joystick, 1 gachette)
PCB pour les 2 joysticks (qui serviront de thumbstick et gachette)

==Semaine 13 et plus==

====Programmation====

'''Raspberry Pi Zero W et PS4'''

'''Modules Atmega328p et SPI'''

====Electronique====

=Documents Rendus=

(à mettre rapport + git + drive)

=Datasheets=

Projets IMA4 SC & SA 2017/2018

2018-02-09T16:37:53Z

Tgracias : /* Matériel à acquérir */

Merci de référencer vos pages de projets ici. Merci aussi d'uniformiser vos formats que ce soit en regardant la présentation des projets déjà créés ou en demandant une modification du format des précédents si votre façon de faire vous semble la meilleure. Dans tous les cas un minimum de communication entre les binômes est conseillée.

Toutes les sources doivent être déposées sur notre archive GIT. Le service est disponible à l'URL [https://archives.plil.fr archives.plil.fr]. Connectez-vous avec vos identifiants Polytech'Lille. Sauf indication contraire de vos encadrants, rendez le projet public et mettez le lien sur votre Wiki. Vous pouvez trouver de la documentation sur ce système d'archives sur ce [https://git-scm.com/book/fr/v1 site].

== Répartition des binômes ==

{| class="wikitable"
! Projet !! Encadrants école !! Elèves
|-
| P0 [[IMA4 2017/2018 P0|Modèle]]
|
|
|-
| P1 [[IMA4 2017/2018 P1|Automatisation de la production de bière]]
| Rémy Bernard / Alexandre Boé / Thomas Vantroys
| Henri Carlier / Quentin Boëns
|-
| P3 [[IMA4 2017/2018 P3|Sécurisation de l'Internet des Objets par surveillance globale]]
| Alexandre Boé / Xavier Redon / Thomas Vantroys
| Ji Yang
|-
| P4 [[IMA4 2017/2018 P4|Développement d'un module d'énergie pour Internet des Objets]]
| Alexandre Boé / Xavier Redon / Thomas Vantroys
| Abass Ayoub / Alexis Viscogliosi
|-
| P5 [[IMA4 2017/2018 P5|Réseau de capteurs de pollution]]
| Thomas Vantroys / Alexandre Boé / Xavier Redon
| Paul Ribeiro / Naif Mehanna
|-
| P6 [[IMA4 2017/2018 P6|Réseau LoRaWAN]]
| Alexandre Boé / Xavier Redon / Thomas Vantroys
| Antoine Gosse
|-
| P7 [[IMA4 2017/2018 P7|Brique pour apprentissage informatique]]
| Alexandre Boé / Emmanuelle Pichonnat / Thomas Vantroys
| Maéva Delaporte / Simon Blas
|-
| P10 [[IMA4 2017/2018 P10|Portage de RIOT-OS sur MSP430 pour IOT]]
| Thomas Vantroys / Alexandre Boé / Xavier Redon
| Baptiste Cartier
|-
| P12 [[IMA4 2017/2018 P12|Système d'ostéophonie pour magicien]]
| Alexandre Boé / Xavier Redon / Thomas Vantroys
| Amine El Messaoudi / Simon Feutrier
|-
| P14 [[IMA4 2017/2018 P14|Ecran géant modulaire]]
| Alexandre Boé / Xavier Redon / Thomas Vantroys
| Jade Dupont
|-
| P15 [[IMA4 2017/2018 P15|Balle vibrante connectée pour enfants sourd]]
| Rodolphe Astori / Alexandre Boé / Thomas Vantroys
| Thibault Cattelain / Thomas Cunin
|-
| P16 [[IMA4 2017/2018 P16|Sous-chaussure chauffante pour docker]]
| Remy Bernard / Alexandre Boé / Thomas Vantroys
| Rémi Mairesse / Gustave Roux
|-
| P17 [[IMA4 2017/2018 P17|Safe Watch]]
| Xavier Redon
| Oumaima Naanaa
|-
| P18 [[IMA4 2017/2018 P18|Mandala électronique]]
| Xavier Redon / Alexandre Boé
| Lirui Zhang / Lihe Zhang
|-
| P19 [[IMA4 2017/2018 P19|Bijou électronique]]
| Xavier Redon / Alexandre Boé
| Keren Qiang / Lijie Yao
|-
| P20 [[IMA4 2017/2018 P20|Solution de messagerie à base de conteneurs]]
| Xavier Redon / Thomas Vantroys
| Maxime Creteur / Fan Gao
|-
| P22 [[IMA4 2017/2018 P22|Horloge numérique DCF77, serveur de temps et ludique]]
| Xavier Redon / Alexandre Boé / Thomas Vantroys
| Amaury Knockaert / Fabrice Taingland
|-
| P23 [[IMA4 2017/2018 P23|Table de bar connectée]]
| Thomas Vantroys / Alexandre Boé
| Matthieu Delobelle
|-
| P25 [[IMA4 2017/2018 P25|Essaim de robots]]
| Xavier Redon / Alexandre Boé
| Ganix Etcheguibel / Benjamin Canu
|-
| P30 [[IMA4 2017/2018 P30|Contrôle d'une caméra WiFi.]]
| Nathan Martin / Xavier Redon
| Thomas Hubert / Taky Djeraba
|-
| P32 [[IMA4 2017/2018 P32|Tribute to Peter Vogel]]
| Thomas Vantroys / Alexandre Boé / Xavier Redon
| Antoine Untereiner / Jean-Baptiste Watine
|-
| P35 [[IMA4 2017/2018 P35|Manette de jeu vidéo pour personne en situation de handicap]]
| Alexandre Boé / Xavier Redon / Thomas Vantroys
| Camille Saad / Transley Gracias
|-
| P39 [[IMA4 2017/2018 P39|Musique des plantes]]
| Emmanuelle Pichonat / Alexandre Boé
| Rodolphe Toin / Xavier Chenot
|-
| P40 [[IMA4 2017/2018 P40|Exploration du réseau d'anonymisation Tor]]
| Xavier Redon / Thomas Vantroys
| Anthony Durot / Antoine Duquenoy
|-
| P42 [[IMA4 2017/2018 P42|Automatisation de l'assemblage de LEGO]]
| Xavier Redon / Alexandre Boé / Thomas Vantroys
| Justine Senellart / Eloi Zalczer
|-
| P44 [[IMA4 2017/2018 P44|Reconnaissance d’objets via Traitement d’Image]]
| Thomas Danel / Vincent Coelen
| Zoé Briois / Damien Narbais
|-
| P49 [[IMA4 2017/2018 P49|Suivi de la qualité de l’air]]
| Romain Rouvoy / Rédha Kassi
| Nicolas Havard / Hugo Delbroucq
|-
| P50 [[IMA4 2017/2018 P50|Etage commande de Centaure]]
| Xavier Redon / Alexandre Boé / Thomas Vantroys
| Haroun Abdelali
|-
| P60 [[IMA4 2017/2018 P60|Commande de niveaux d’eau]]
| Midzodzi Pekpe
| Claire Vandamme / Alexendra Villa
|-
| P64 [[IMA4 2017/2018 P64|Simulation Labview et mise en réseau Modbus d’un ascenseur]]
| Midzodzi Pekpe / Blaise Conrard
| François-Xavier Cockenpot
|-
| P65 [[IMA4 2017/2018 P65|Exosquelette pour apprentissage]]
| Alexandre Boé / Xavier Redon / Thomas Vantroys
| Florian Le Foll
|-
| P66 [[IMA4 2017/2018 P66|Coupe de France de robotique]]
| Alexandre Boé / Xavier Redon / Thomas Vantroys
| Geoffrey Preud'homme / Amaury Carval
|-
| P67 [[IMA4 2017/2018 P67|Scanner 3D DIY]]
| Xavier Redon / Alexandre Boé / Thomas Vantroys
| Erwan Dufresne
|-
| P68 [[IMA4 2017/2018 P68|Générateur de chronogrammes d'ordonnancement]]
| Xavier Redon / Thomas Vantroys
| Samy Belhouachi
|-
| PP1 [[IMA4 2017/2018 Pré-projet 1|Robot hexapode pour escalier]]
| Alexandre Boé / Xavier Redon / Thomas Vantroys
| Eduardo Gomez-Riaza
|}

== Matériel à acquérir ==

{| class="wikitable"
! Projet !! Matériel
|-
| P1 [[IMA4 2017/2018 P1|Automatisation de la production de bière]]
|
*Capteur de température DS18B20 [https://www.gotronic.fr/art-sonde-etanche-ds18b20-19339.htm]
*Raccord tuyau en Y [https://fr.rs-online.com/web/p/coupleurs-de-tuyaux-flexibles/4197259/] 
*2 Pompes péristaltique dc 12V [https://www.mouser.fr/ProductDetail/Adafruit/1150?qs=sGAEpiMZZMsMyYRRhGMFNp8jyMJFi5X9NqTp2aghyow%3d]
*Tube en silicone [https://fr.rs-online.com/web/p/tubes-flexibles/9124751/]
*Tube en cuivre [https://fr.rs-online.com/web/p/tubes-en-cuivre/0846503/]
*2 résistances 1kOhms
*2 transistors bc547
*2 diodes
*14 cables M/M
*Alimentation DC 12V 
|-
| P3 [[IMA4 2017/2018 P3|Sécurisation de l'Internet des Objets par surveillance globale]]
|
*Xbee USB Adapter * 1 [https://www.amazon.fr/dp/B017KGBP6Y/ref=asc_df_B017KGBP6Y48622783/?tag=googshopfr-21&creative=22722&creativeASIN=B017KGBP6Y&linkCode=df0&hvdev=c&hvnetw=g&hvqmt=]
*XDigiKey Xbee module 2.4Hz * 4 [https://www.digikey.com/catalog/en/partgroup/xbee-and-xbee-pro-zb-zigbee/12201] ReX : imprécis, cherchez chez gotronic
*l'antenne pour Xbee * 4 [https://www.matlog.fr/fr/61-antennes-24-ghz.html]
*Arduino uno * 4 [https://store.arduino.cc/usa/arduino-uno-rev3]
*Xbee Shields pour Arduino * 4 [https://store.arduino.cc/arduino-wirelss-sd-shield]
*Câble USB pour Arduino * 4 [https://fr.aliexpress.com/item/usb-cable-for-arduino-with-UNO-R3-ATMEGA328P-PU-ATMEGA8U2-and-Mega-2560-R3-Mega2560-REV3/32624000858.html?src=google&albslr=221466033&isdl=y&aff_short_key=UneMJZVf&source=%7Bifdyn:dyn%7D%7Bifpla:pla%7D%7Bifdbm:DBM&albch=DID%7D&src=google&albch=shopping&acnt=494-037-6276&isdl=y&albcp=653151748&albag=36672819047&slnk=&trgt=61865531738&plac=&crea=fr32624000858&netw=g&device=c&mtctp=&gclid=Cj0KCQiAv_HSBRCkARIsAGaSsrC92WYZ2oroveXJLqUQCBfRBuRMa8VoShOZWNBitPIvrry8V1HpMmkaAg-QEALw_wcB] 
*Batterie externe(qui a 2 ports à recharger) * 4 [https://www.amazon.fr/EC-Technology-22400mAh-Batterie-capacit%C3%A9/dp/B00F5Q4F0U/ref=sr_1_1_sspa?ie=UTF8&qid=1513804729&sr=8-1-spons&keywords=batteries+externe&psc=1]
*USB À UART TTL Câble * 1 [https://fr.aliexpress.com/item/USB-To-RS232-TTL-USB-To-COM-Serial-Adapter-Cable-Module-PL2303HX-Converter/1859099599.html?src=google&albslr=201492522&isdl=y&aff_short_key=UneMJZVf&source=%7Bifdyn:dyn%7D%7Bifpla:pla%7D%7Bifdbm:DBM&albch=DID%7D&src=google&albch=shopping&acnt=494-037-6276&isdl=y&albcp=653151748&albag=36672819047&slnk=&trgt=61865531738&plac=&crea=fr1859099599&netw=g&device=c&mtctp=&gclid=CjwKCAiAsejRBRB3EiwAZft7sENdHUiXBHo-JhKGxsmwfnaRATNn_OPdCl9y-WVMwi8elX5S6QCMnhoCNm8QAvD_BwE]
*Breadboard de prototypage * 3 [https://www.amazon.fr/Breadboard-Carte-dexp%C3%A9rimentation-Soudure-Solderless/dp/B06XWFG9DT/ref=sr_1_2_sspa?ie=UTF8&qid=1516049551&sr=8-2-spons&keywords=breadboard+arduino&psc=1]
*USB câble pour xbee USB Adapter [https://www.amazon.fr/dp/B003OSS4SA/ref=asc_df_B003OSS4SA49349077/?tag=googshopfr-21&creative=22698&creativeASIN=B003OSS4SA&linkCode=df0&hvdev=c&hvnetw=g&hvqmt=]
|-
| P4 [[IMA4 2017/2018 P4|Développement d'un module d'énergie pour Internet des Objets]]
|
* 1xModule solaire [[https://www.mouser.fr/ProductDetail/MikroElektronika/MIKROE-651?qs=sGAEpiMZZMvxW%252bY8mn0Q9U%252b%2fhOkIvSmCqkyN6XrqZsI%3d]]
* 1xBatterie [[http://fr.farnell.com/varta/55608303059/batterie-nimh-3-6v/dp/279341]]
* 1xConvertisseur Boost [[https://fr.rs-online.com/web/p/convertisseurs-boost/8123659/]]
* 2xDiode de Schottky de redressement [[https://fr.rs-online.com/web/p/diodes-de-redressement-et-schottky/7390436/]]
* 1xConvertisseur Buck-Boost (sortie) [[https://fr.rs-online.com/web/p/regulateurs-a-decoupage-buck-boost/6989091/]]
* 2xSupercondensateur 2,7V - 50F [[https://www.mouser.fr/ProductDetail/Maxwell-Technologies/BCAP0050-P270-T01/?qs=sGAEpiMZZMsCu9HefNWqpt2sk1W1BTZ59akVpHhf5KE=]]
* 10 jumpers [[https://fr.rs-online.com/web/p/cavaliers-et-shunts/6742397/]]
* Module MPPT [[https://www.mouser.fr/ProductDetail/STMicroelectronics/SPV1050TTR?qs=sGAEpiMZZMsMLZWdhVL71%2fkXzzgq0Ptzmbr9rWlHkic%3d]]
* 20 pin connection mâle [[https://fr.rs-online.com/web/p/barrettes-pour-ci/8967620/]]
* 10 transistor npn commandé en tension [[https://fr.rs-online.com/web/p/transistors-bipolaires/7390381/]]
|-
| P5 [[IMA4 2017/2018 P5|Réseau de capteurs de pollution]]
|
* ESP32 [[https://www.gotronic.fr/art-carte-esp32-dev-13907-25510.htm]]
* Module GPS [[https://www.gotronic.fr/art-module-gps-tel0094-25732.htm]]
* Batterie Lithium Ion [[https://fr.rs-online.com/web/p/batteries-externes/8755758/]] ou [[https://fr.rs-online.com/web/p/batteries-externes/1366470/]] suivant le prix
* Adaptateur micro USB
* Breadboard
* Un smartphone sous Android (Version Lollipop minimale - optionnel)
* HPMA115S0-XXX (Capteur déjà acheté normalement)
* 2 connecteurs micro-USB [[https://www.gotronic.fr/art-embase-micro-usb-b-cms-18339.htm]]
|-
| P6 [[IMA4 2017/2018 P6|Réseau LoRaWAN]]
|
* 1 * iC880A-SPI , 
* 1 * Raspberry , 
* 2 * Nucleo-F4 , 
* 2 * Shield STM32 LoRa, 
|-
| P7 [[IMA4 2017/2018 P7|Brique pour apprentissage informatique]]
|
*1xCapteur ultrason [https://www.gotronic.fr/art-module-de-detection-us-hc-sr04-20912.htm]
*2xafficheurs-7segments [http://fr.farnell.com/broadcom-limited/hdsp-7801/afficheur-a-leds-7-62mm-vert/dp/1003275]
*4xboutons poussoirs [https://www.gotronic.fr/art-module-bouton-poussoir-st043-26115.htm]
*4xleds [https://www.gotronic.fr/art-led-5-mm-led5bt-21009.htm]
*2xpotentiomètres [https://www.gotronic.fr/art-potentiometre-lineaire-47k-8486-11110.htm]
*2xcâble [https://www.gotronic.fr/art-cordon-alimentation-pile-9v-19414.htm] + pile [https://www.gotronic.fr/art-pile-9v-au-lithium-uv9l-5575.htm] pour alimenter l'Arduino
*2xArduino Uno [https://store.arduino.cc/arduino-uno-rev3]
*2xModule bluetooth pour arduino (BTM-01)[https://www.mouser.fr/ProductDetail/OSEPP-Electronics/BTM-01/?qs=YCa%2fAAYMW020ADfc44%2fjCA%3d%3d]
*10xMicrocontrôleur Atmega328p [http://fr.farnell.com/microchip/atmega328p-pu/micro-8-bits-avr-32k-flash-28pdip/dp/1715487]
*2xKit roue + moteur [https://www.gotronic.fr/art-kit-roue-moteur-23569.htm]
*1xRoue folle [https://www.robotshop.com/eu/fr/roulette-bille-pololu-0375-po-metal.html]
*1xContrôleur de moteur [https://www.gotronic.fr/art-commande-de-2-moteurs-tb6612fng-2x1a-21716.htm]
*50xpicots mâle [https://fr.rs-online.com/web/p/barrettes-pour-ci/8967620/]
*5xpicots femelle [https://fr.rs-online.com/web/p/barrettes-pour-ci/2677400/]
*4x10 ressorts [https://fr.rs-online.com/web/p/ressorts-de-compression/0821245/]
*1xplaque de contreplaqué [https://www.leroymerlin.fr/v3/p/produits/predecoupe-medium-mdf-naturel-ep-10-mm-l-120-x-l-60-cm-e105237#&xtmc=predecoupe&xtcr=1]
|-
| P10 [[IMA4 2017/2018 P10|Portage de RIOT-OS sur MSP430 pour IOT]]
|
* 2xCC430 [https://www.mouser.fr/ProductDetail/Texas-Instruments/CC430F5137IRGZT/?qs=%2fqzd9s%252bcLd7GiX35ln9VRA==] (fourni par les tuteurs de projet) 3 reçus
* 1xMSP430-CCRF [https://www.olimex.com/Products/MSP430/Starter/MSP430-CCRF/] (fourni par les tuteurs de projet)
* 1xMSP-EXP430G2 [https://www.mouser.fr/productdetail/texas-instruments/msp-exp430g2?qs=sGAEpiMZZMv1ORdfpzTN%252bMwZ3%252b5KGk2B] (fourni par les tuteurs de projet)
|-
| P12 [[IMA4 2017/2018 P12|Système d'ostéophonie pour magicien]]
|
* Raspberry Pi 3, 
* Microcontroleur STM32L433CCT6 [https://www.mouser.fr/ProductDetail/STMicroelectronics/STM32L433CCT6?qs=sGAEpiMZZMuoKKEcg8mMKFZaGHZhaFFC5XHr6X%2fBPloj9WsFWEQ6BA%3d%3d],
* Mémoire Flash IS25WP064A-RMLE [https://www.mouser.fr/productdetail/issi/is25wp064a-rmle?qs=sGAEpiMZZMtI%252bQ06EiAoG5kNS0TozX6Gt0%2FX%2Fi6ExQk%3D], 
* DAC MCP4725A0T-E/CH [https://www.mouser.fr/productdetail/microchip-technology/mcp4725a0t-e-ch?qs=sGAEpiMZZMvfFCidbTccA97L6UsE6%2Fky], 
* Batterie 3.6V [https://www.gotronic.fr/art-accu-nimh-3-6v-300mah-290.htm], 
* Module Bluetooth 4.1 BM20SPKS1NBC-0001AA [https://www.mouser.fr/ProductDetail/Microchip-Technology/BM20SPKS1NBC-0001AA?qs=sGAEpiMZZMsGelYiB%252bjhZv%252biZoDZL1ptX5ao52HhnlyFQbPW6KaEbg%3d%3d],
* Adafruit Bone Conductor Transduce [https://www.mouser.fr/ProductDetail/Adafruit/1674/?qs=sGAEpiMZZMsqIr59i2oRcvz%252byDSTdozphj%2f1Oxe6%252bAQ=], 
* Transducteur Piézo diaphragme :
** fréquence de résonance 2.9KHz (gotronic) [https://www.gotronic.fr/art-disque-piezoelectrique-dp035-3843.htm],
** fréquence de résonance 4.6KHz (gotronic) [https://www.gotronic.fr/art-disque-piezoelectrique-dp027-3842.htm],
** fréquence de résonance 6.6KHz (gotronic) [https://www.gotronic.fr/art-disque-piezoelectrique-dp024-3841.htm],
** Afréquence 8KHz 10KHz (RS) [https://fr.rs-online.com/web/p/buzzers-piezo/7214947/],
* Moteur Électrique CC RS Pro, 3 → 7,2 V c.c., 19,68 W, 19000 tr/min, 4,41 A [https://fr.rs-online.com/web/p/moteurs-v-cc/2389721/].
|-
| P14 [[IMA4 2017/2018 P14|Ecran géant modulaire]]
|
|-
| P15 [[IMA4 2017/2018 P15|Balle vibrante connectée pour enfants sourd]]
|
* 8 vibreurs : [https://www.mouser.fr/productdetail/adafruit/1201?qs=sGAEpiMZZMsMyYRRhGMFNstIkcYqaSq8%2fLLE3lYp32I=]
* Module Bluetooth 4.0 Low Energy : [https://www.mouser.fr/ProductDetail/Adafruit/2479?qs=sGAEpiMZZMsMyYRRhGMFNjWi9ZmxEfRwbLHKJ6JemUg%3d]
* Bobine de recharge à induction (norme Qi) : [https://www.mouser.fr/productdetail/adafruit/1901?qs=sGAEpiMZZMsMyYRRhGMFNkyDC95Rd%252blHW46I1pJekjA%3D]
* Atmega 328p CMS : [https://www.mouser.fr/ProductDetail/Microchip-Technology-Atmel/ATMEGA328PB-AU?qs=sGAEpiMZZMvc81WFyF5EdrSRAEYMYvHlMc95YQj%2fArE%3d]
* 1 Batterie rechargeable 5.2Ah : [https://www.gotronic.fr/art-accu-li-ion-mgl9033-26425.htm#complte_desc]
* 2 controleurs pour moteur :[https://www.mouser.fr/ProductDetail/STMicroelectronics/L293DD?qs=sGAEpiMZZMukgiigmf73gOko5bw7EE67]
*2 condensateurs 14pF :[https://www.mouser.fr/ProductDetail/Murata-Electronics/GCQ1555C1H140FB01D?qs=sGAEpiMZZMs0AnBnWHyRQN7%2fAA2D2lPPLNRvFwtPLQHRWxf2q9etuA==]
*1 crystal quartz 16MHz :[https://www.mouser.fr/ProductDetail/ECS/ECS-160-12-33Q-JES-TR?qs=sGAEpiMZZMuMAfj%252bWfX4nLed60zyr3PUv7Kre5ygQ%252bs%3d]
* 1 résistances CMS 10khoms 0603 :[http://fr.farnell.com/multicomp/mcre000164/res-couche-epaisse-10k-1-0-05w/dp/1711641]
* 7 résistances CMS 1kohms 0603 :[http://fr.farnell.com/multicomp/mcre000140/res-couche-epaisse-1k-1-0-05w/dp/1711615?st=MULTICOMP%201K%200603]
* 1 résistances CMS 470ohms 0603:[https://www.mouser.fr/ProductDetail/TDK/MMZ1608Y471BTA00?qs=sGAEpiMZZMu0dYp3dYbBlQn%252beM9UWul2G3hJ%2f7TLqL0%3d]
* 2 résistances CMS 2kOhms 0603 :[https://www.mouser.fr/ProductDetail/Panasonic-Industrial-Devices/ERJ-3EKF2001V?qs=sGAEpiMZZMu61qfTUdNhGzRxdwze5h8ZMDWmuHH2qQY%3d]
* 2 resistances CMS 340kOhms 0603 :[https://www.mouser.fr/ProductDetail/Vishay/CRCW0603340KFKEA?qs=sGAEpiMZZMukHu%252bjC5l7YRSQiDx9P4ktLgBETRAdfqw%3d]
* 1 resistances CMS 1.87MOhms 0603 :[https://www.mouser.fr/ProductDetail/Yageo/RC0603FR-071M87L?qs=sGAEpiMZZMu61qfTUdNhG6gKAQVNBKOo2zO%2fNI9xQvs%3d]
*2 resistances CMS 100kOhms 0603 :[https://www.mouser.fr/ProductDetail/Vishay-Draloric/RCG0603100KFKEA?qs=sGAEpiMZZMsa677hLZe2Z63dGP%2fTFOZQ]
* 4 condensateur 10uF 0603 :[https://www.mouser.fr/ProductDetail/Taiyo-Yuden/LMK107BC6106MA-T?qs=sGAEpiMZZMukHu%252bjC5l7Yd8IIWTQlTYBUiPYtsE4Bzg%3d]
*1 condensateur 0.1uF 0603 :[https://www.mouser.fr/ProductDetail/Taiyo-Yuden/GMK107BJ104KAHT?qs=sGAEpiMZZMs0AnBnWHyRQNbg85K4ab%2f3WB4TApadaC0%3d]
*1 condensateur 2.2uF 0603 :[https://www.mouser.fr/ProductDetail/Taiyo-Yuden/JMK107B7225KAHTR?qs=sGAEpiMZZMs0AnBnWHyRQPSjYu%2fkbgu8y0KcZVF30DNOIVNQnIIJ3Q%3d%3d]
*1 condensateur 22uF 0603 :[https://www.mouser.fr/ProductDetail/Taiyo-Yuden/LMK107BBJ226MA-T?qs=sGAEpiMZZMs0AnBnWHyRQPSjYu%2fkbgu8OPGniOr6zLcT6eSTCbA%252bCQ%3d%3d]
*2 condensateur 1uF 0603 :[https://www.mouser.fr/ProductDetail/Taiyo-Yuden/GMK107BJ105KA-T?qs=sGAEpiMZZMs0AnBnWHyRQAEIN6r3SS%2fOBpoA9Mx5a9I%3d]
*1 condensateur 1210 100uF 1210 :[https://www.mouser.fr/ProductDetail/Murata-Electronics/GRM32ER61A107ME20L?qs=sGAEpiMZZMukHu%252bjC5l7Ya6pfwBk8EBeq55B9L%252bMJQA%3d]
*2 led verte CMS 1206 :[https://www.mouser.fr/ProductDetail/Kingbright/APTD3216LCGCK?qs=sGAEpiMZZMuCm2JlHBGefutc4sI%252bRg9%2fbKLcTuDCbMNnKZ3XxcbEWg%3d%3d]
*1 led orange 1206 CMS :[https://www.mouser.fr/ProductDetail/Lite-On/LTST-C150KAKT?qs=sGAEpiMZZMseGfSY3csMkTlTHQ2beMlrmGllatFacok%3d]
*2 led rouge 1206 CMS :[https://www.mouser.fr/ProductDetail/Kingbright/APTD3216LSURCK?qs=sGAEpiMZZMuCm2JlHBGefutc4sI%252bRg9%2fEbFuu2HcaZsnh6Yj8wyZLQ%3d%3d]
*1 led bleue CMS 1206 :[https://www.mouser.fr/ProductDetail/Kingbright/APTD3216LQBC-D?qs=sGAEpiMZZMseGfSY3csMkdgyOOAg6kv2SoHfbZ6fYRJR%252bPUfy4LTDQ%3d%3d]
* 1 module Bluetooth 802.15 :[https://www.mouser.fr/productdetail/seeed-studio/317030027?qs=wU1J8Md1npz%2F8UksA%252bh%252byw%3D%3D]
*1 Regulateur de tension LDO :[https://www.mouser.fr/ProductDetail/Microchip-Technology-Micrel/MIC5225YM5-TR?qs=sGAEpiMZZMsGz1a6aV8DcNranXV84HMLR75Z9P39yqc%3d]
*1 Transistor PNP prépolarisé 100mA:[https://www.mouser.fr/ProductDetail/ON-Semiconductor/MMUN2133LT1G/?qs=ZpPixqFcBtysLCI/2LOB%252bQ==]
*1 Régulateur de tension de commutation:[https://www.mouser.fr/ProductDetail/Texas-Instruments/TPS61090RSAR?qs=sGAEpiMZZMuo%252bmZx5g6tFAsofpr73Rbu]
*1 chargeur de batterie pour une cellule Li-on:[http://fr.farnell.com/microchip/mcp73831t-2aci-ot/controleur-de-charge-li-ion-li/dp/1332158]
*3 Diodes :[https://www.mouser.fr/ProductDetail/Diodes-Incorporated/1N4148WQ-7-F?qs=sGAEpiMZZMtzpSA5GSDwayHNFYvfz9yMGFXnI15cqbU%3d]
*1 diodes et redresseurs:[https://www.mouser.fr/ProductDetail/ON-Semiconductor/MBR120ESFT1G?qs=sGAEpiMZZMtQ8nqTKtFS%2fCKUxMvjsmGzPwX1d8aVcbo%3d]
*1 inductance 6.8uH:[http://fr.farnell.com/bourns/srn6045ta-6r8m/inductance-aec-q200-6-8uh-3-6a/dp/2616892]
*Quartz 32Mhz:[https://www.mouser.fr/ProductDetail/?qs=2xLVn2jvFusfExB%252byZEnpA%3D%3D]
|-
| P16 [[IMA4 2017/2018 P16|Sous-chaussure chauffante pour docker]]
|
*2xArduino Pro Mini [https://www.mouser.fr/ProductDetail/Adafruit/2377?qs=sGAEpiMZZMsMyYRRhGMFNrePrikk4IpJQBQo3elmwiI%3d]
*1xbouclier USB vers UART pour mini Arduino [https://www.mouser.fr/ProductDetail/Digilent/410-212?qs=sGAEpiMZZMsF1ODjcwEocFxZWH6k8YAWBC6KMJ05oOA%3d] 
*4xcapteurs de température et humidité DHT22 [https://www.gotronic.fr/art-capteur-de-t-et-d-humidite-dht22-20719.htm]
*2xMOSFET [https://fr.rs-online.com/web/p/transistors-mosfet/5431184/]
*1xbatterie [https://fr.rs-online.com/web/p/batteries-externes/7757508/?searchTerm=pb+A5200&relevancy-data=636F3D3126696E3D4931384E4C446573635461786F6E6F6D794272616E645365617263685465726D325F74656D70266C753D6672266D6D3D6D617463687061727469616C6D617826706D3D5E5B5C707B4C7D5C707B4E647D3F5C707B5A737D2D2C2F255C2E5D2B2426706F3D31313326736E3D592673743D4B4559574F52445F4D554C54495F414C5048415F414E445F4D554C54495F414C5048415F4E554D455249432673633D592677633D4E4F4E45267573743D7062204135323030267374613D706220413532303026]
*1xfilm de tranfert thermique [https://fr.rs-online.com/web/p/tampons-decart-thermiques/5075605/] Référence SILPAD400AC 
*1xBobine fil résisitif [https://fr.rs-online.com/web/p/cable-industriel-multiconducteur/7496344/]
*1xpaire de chaussure de sécurité (utilisation de nos chaussure)
*1xplaque de caoutchouc antidérapant antivibration [https://www.leroymerlin.fr/v3/p/produits/dalle-antiderapante-noir-gpi-e128988] (achetez, remboursement par la suite)
*1xRouleau de scratch [https://www.leroymerlin.fr/v3/p/produits/ruban-adhesif-mini-ruban-scratch-auto-agrippant-scratch-grip-l-2000-x-l-10-mm-e1400146133] (achetez, remboursement par la suite)

|-
| P17 [[IMA4 2017/2018 P17|Safe Watch]]
|
* Arduino ,
* Bouclier Arduino LCD ,
* Bouclier GPS Arduino ,
* Bouclier GSM Arduino ,
* Plaque d'essai, câbles, 3 boutons ,
* Adafruit FONA 808 Cellular + GPS Breakout [https://eu.mouser.com/ProductDetail/Adafruit/2691?qs=sGAEpiMZZMuC4zZxLL0ZTS5y3%2fvN2YqqC7jd%252b8Ewo0tvrzwH6EzcUw%3d%3d],
* OLED Display de MicroView [https://www.mouser.fr/ProductDetail/SparkFun-Electronics/DEV-12923/?qs=%2fha2pyFaduhq0%2f0L4ziGOlrL8k9CznZ%2fHCwmtADFcmfM%252bNj6xnUOTR2J1R9vVHxC],
* Antenne GPS [https://fr.rs-online.com/web/p/antennes-gps/6534111/] ,
*mini JST 2-pin pour la batterie [https://www.mouser.fr/ProductDetail/Adafruit/261?qs=sGAEpiMZZMsMyYRRhGMFNu1QGkj38%2fjpots4OzXyI0g%3d],
* batterie:1200mAh sized Lithium ion/polymer battery [https://www.mouser.fr/ProductDetail/Adafruit/258?qs=%2fha2pyFadui%252bGfcAGyN46wlBHAaZlEsaG2TnF48kfbRBKCZP7yH6DDXLDCpScZ1uLz%2f7LJyXDtVbPM%252b2aEQ0roW2VWPjGRnj],
* headphone jack : [https://www.mouser.fr/ProductDetail/Adafruit/1699?qs=sGAEpiMZZMsMyYRRhGMFNsUVB%252bwflvtuRD2AT1i4W%2fI%3d],
* Antenne GSM [https://fr.rs-online.com/web/p/antennes-gsm-et-gprs/8968291/] ,
* Arduino micro [https://www.mouser.fr/ProductDetail/Arduino/A000053?qs=sGAEpiMZZMvq007EO%252bXAYZAVvNFL4IMQ],
* microUSB cable ,
* usb programmer [https://www.mouser.fr/ProductDetail/SparkFun/DEV-12924?qs=%2fha2pyFadujajXN5UxBZ39QNIwYchoft2tr4SjuyzPeTBIS0mD6hlArvMlp2O59kyDG2ZmVILu%252bM2KFfVewETA%3d%3d].

|-
| P18 [[IMA4 2017/2018 P18|Mandala électronique]]
|
*TCL5947*3 [http://fr.farnell.com/texas-instruments/tlc5947dap/ic-led-driver-linear-32-tssop/dp/1755259]
*Arduino Atmega328p [http://fr.farnell.com/microchip/atmega328p-aur/mcu-8-bits-atmega-20mhz-tqfp-32/dp/2425124?st=atmega328p]
*LEDs rougesx40 [http://fr.farnell.com/kingbright/kpl-3015ec/led-12mcd-rouge-617nm/dp/2426224]
*LEDs jaunesx70 [http://fr.farnell.com/kingbright/kpl-3015syck/led-350mcd-jaune-590nm/dp/2426230]
*LEDs bleuesx55 [http://fr.farnell.com/kingbright/kpl-3015qbc-d/led-200mcd-bleu-465nm/dp/2426226]
*LEDs orangesx55 [http://fr.farnell.com/kingbright/kpl-3015seck/led-350mcd-orange-601nm/dp/2426227]
*Transistorsx30 [http://fr.farnell.com/on-semiconductor/mmbt3904/transistor-npn-sot-23/dp/9846727]
*Bois [https://www.leroymerlin.fr/v3/p/produits/predecoupe-contreplaque-okoume-exterieur-ep-5-mm-l-80-x-l-60-cm-e1401453577]
*Source alimentationx2 [https://www.gotronic.fr/art-4-accus-nimh-r6-varta-1-2v-2-1ah-19151.htm]
*Coupleur de pilesx2 [https://www.gotronic.fr/art-coupleur-4-piles-lr6-em4p-5709.htm]
*Gouache [https://www.amazon.fr/Mallette-dartiste-bois-35-pi%C3%A8ces/dp/B00GIONTS2/ref=sr_1_2?ie=UTF8&qid=1516056582&sr=8-2&keywords=gouache]
*Stylo [https://www.amazon.fr/Papermate-S0916420-PM-300-Pointe-Moyenne/dp/B005HI33KO/ref=sr_1_3?ie=UTF8&qid=1516201326&sr=8-3&keywords=crayon+dore]
*ZX Distance et Gesture Sensor [https://www.mouser.fr/productdetail/sparkfun/sen-13162?qs=sGAEpiMZZMsEbyLvxciIbARXbzpjz%2fFllERyJO140AQcgPpUTdWOKA==]
|
|-
| P19 [[IMA4 2017/2018 P19|Bijou électronique]]
|
*50xLED CMS orange [http://fr.farnell.com/broadcom-limited/hsmd-c170/led-cms-orange/dp/5790864?MER=bn_para_1TP_LastViewed_1]
*50xLED CMS bleu [http://fr.farnell.com/broadcom-limited/hsmr-c170/led-bleu/dp/8554749]
*50xLED CMS vert [http://fr.farnell.com/broadcom-limited/hsmg-c170/led-verte/dp/5790852]
*50xLED CMS jaune [http://fr.farnell.com/broadcom-limited/hsmy-c170/led-jaune/dp/5790876]
*50xLED CMS rouge [http://fr.farnell.com/broadcom-limited/hsms-c170/led-rouge-he/dp/5790839]
*1xArduino UNO & 1xAtmega328p [http://fr.farnell.com/arduino-org/a000066/arduino-uno-carte-d-eval/dp/2075382]
*1xDS18B20 [http://fr.farnell.com/maxim-integrated-products/ds18b20u-t-r/capteur-de-temperature-0-5deg/dp/2515607]
*1xBreadboard [http://fr.farnell.com/mcm/21-18936/half-size-breadboard-with-300/dp/2799991]
*1xPulsesensor [https://www.mouser.fr/ProductDetail/SparkFun/SEN-11574?qs=%2fha2pyFadui%2fRsn4onUiCn%2f5VOJEA9t%252bK%252brmkRQhmlsCSXQ%252bUAWWwg%3d%3d]
*5xpiles de boutons de 3V [http://fr.farnell.com/varta/6032101501/pile-lithium-bouton/dp/300445]
*1xfil de fer [https://www.gotronic.fr/art-soudure-esp006-50-25658.htm]
*1xruban isolant [https://www.gotronic.fr/art-ruban-isolant-temflex-7682.htm]
*50xrésistances 68ohm [https://fr.rs-online.com/web/p/resistances-traversantes/1650741/]
*1xrésistances 8.2 Mohm [https://fr.rs-online.com/web/p/resistances-traversantes/6834102/]
*50xrésistances 56ohm [https://fr.rs-online.com/web/p/resistances-traversantes/1650735/]
*1xinterrupteur bascule [https://www.mouser.fr/ProductDetail/NKK-Switches/B12JJVC?qs=sGAEpiMZZMumOpTNq3bZXvRXehMYP%252byokBQhv3MozMw%3d]
*1xtoile [https://www.amazon.fr/Zedtom-Rouleau-D%C3%A9coration-Artisanat-Bricolage/dp/B01KJXOLZM/ref=sr_1_3?s=hi&ie=UTF8&qid=1516198372&sr=1-3&keywords=toile]
|-
| P20 [[IMA4 2017/2018 P20|Solution de messagerie à base de conteneurs]]
|
* 1 Raspberry Pi
|-
| P22 [[IMA4 2017/2018 P22|Horloge numérique DCF77, serveur de temps et ludique]]
|
* Pack de batterie NiMh 510mAh [http://fr.farnell.com/varta/55750404014/pack-de-batterie-nimh-510mah-4/dp/1903286]
* Contrôleur de batterie [https://fr.rs-online.com/web/p/controleurs-de-charge-de-batterie/5456852/] 
|-
| P23 [[IMA4 2017/2018 P23|Table de bar connectée]]
|
* Regulateur 5V->3.3V 800mA [http://fr.farnell.com/stmicroelectronics/ld1117v33/regulateur-ldo-3-3v-1117-to-220/dp/9755837?CMP=KNC-GFR-FFR-GEN-KWL-G50-STMICROELECTRONICS&mckv=s2ZjbOaj_dc|pcrid|79679603942|&gclid=EAIaIQobChMIhe6d84CU2QIVShbTCh2pTggwEAAYAyAAEgKdUvD_BwE] ,
* 4 * Modules Xbee [http://fr.farnell.com/digi-international/xb24-awi-001/module-zigbee-xbee-1mw-antenne/dp/1337912] ,
* 2 * Capteur de temperature [https://www.mouser.fr/ProductDetail/Analog-Devices/AD22103KTZ?qs=sGAEpiMZZMucenltShoSnoiUfjKGVRv2VdPSgYmyZyM%3d] ,
* 2 * Photoresistance [https://www.gotronic.fr/art-photoresistance-ldr04-2150.htm] ,
* 3 * Microcontroleurs Atmega328P [https://fr.rs-online.com/web/p/microcontroleurs/9214545/] ,
* 3 * Régulateur 9V->5V, 100mA [http://fr.farnell.com/texas-instruments/lm78l05acz-nopb/regulateur-lineaire-5-2v/dp/1469108],
* X * Piles 9V [https://fr.rs-online.com/web/p/piles-9-volts/7951545/] ,
* 3 * Quartz 16M [http://fr.farnell.com/raltron/as-16-000-18/quartz-16mhz-18pf-hc-49s/dp/1611761?MER=bn_para_1TP_LastViewed_3] ,
* 6 * Condensateur 18pF [http://fr.farnell.com/vishay/k180j15c0gf5tl2/ceramic-capacitor-18pf-50v-c0g/dp/4986210] ,
* 1 * Panneau LED[https://www.gotronic.fr/art-panneau-a-leds-rgb-64x32-dfr0460-26065.htm],
* ATMEGA16u2-AU ,
* Connectique USB A male à souder,
* Planche à Pain,
* Autres composants electroniques...
* <del>2</del> 3 Modules Xbee S1,
* <del>2</del> 3 Shield Arduino pou Xbee,
* <del>2</del> 3 Cable USB A - USB mini,
* 1 Xbee - Usb Adaptateur (pour le parametrage),
* 1 Led Rouge + Resistance 330Ohm,
* 3 Resistance 10K Ohm ,
* Planche à pain ,
* 3 Boutons .
|-
| P25 [[IMA4 2017/2018 P25|Essaim de robots]]
|
* 2 x Microcontrôleur Atmega [https://www.mouser.fr/ProductDetail/Microchip-Technology-Atmel/ATMEGA328P-MU?qs=sGAEpiMZZMvqv2n3s2xjscfa4zIkTHJIR0ZBr3z9ETo%3d] ,
* 22 x Condensateur 100nF [http://fr.farnell.com/kemet/c0201c104k9pactu/condensateur-mlcc-x5r-100nf-6/dp/1907036?st=Condensateur%20100nF] ,
* 4 x Condensateur 10uF [http://fr.farnell.com/wurth-elektronik/885012106006/condesateur-mlcc-x5r-10uf-6-3v/dp/2495147] ,
* 4 x Condensateur 22pF [http://www.mouser.fr/ProductDetail/AVX/06036A220KAT2A/?qs=sGAEpiMZZMs0AnBnWHyRQKdiqyDPVQdATEC6RfUr2zQ%3d] ,
* 2 x Rectifier Diode [http://www.mouser.fr/ProductDetail/Vishay-Semiconductors/GL34G-E3-83/?qs=sGAEpiMZZMutXGli8Ay4kH9ZXA1Qtv9UOwbhSBXDb18%3d] ,
* 4 x Servo moteur [https://www.gotronic.fr/art-servomoteur-fs90r-25838.htm] ,
* 6 x LED Infrarouge [http://fr.farnell.com/optek-technology/op290a/led-t-1-3-4/dp/1497872] ,
* 6 x Récepteur Infrarouge [http://www.mouser.fr/ProductDetail/Vishay-Semiconductors/TSOP38238/?qs=sGAEpiMZZMvAL21a%2fDhxMtgKho2n4%2fgBkajAZHPY5lE%3d] ,
* 2 x Quartz [http://www.mouser.fr/ProductDetail/ECS/ECS-160-20-3X-TR/?qs=sGAEpiMZZMvAbnEMxb34PZ9bYWrwSXiB] ,
* 2 x Switch [http://www.mouser.fr/ProductDetail/ALPS/SKQGADE010/?qs=sGAEpiMZZMsqIr59i2oRcrO5GDYRXDIX6cdtN26xmPE%3d] ,
* 2 x USB Chip [http://www.mouser.fr/ProductDetail/FTDI/FT232RL-REEL/?qs=sGAEpiMZZMs5ceO8zL%252bTxyQLQIH6hE7q] ,
* 2 x USB-C Connector [https://www.mouser.fr/ProductDetail/Molex/105450-0101?qs=sGAEpiMZZMulM8LPOQ%252byk43rDx%252b4l5FzJ4YNghWv4pnX6X7mot%2f43w%3d%3d] ,
* 2 x Batteries 9V [http://www.mouser.fr/ProductDetail/Panasonic-Battery/6LF22XWA-B12/?qs=sGAEpiMZZMsra%2fh506hF%252bITISQoCasqh1k2eJLis9sg%3d] ,
* 2 x Régulateur 5v [https://www.mouser.fr/ProductDetail/Texas-Instruments/LM1117IMPX-50-NOPB/?qs=X1J7HmVL2ZGGwLlD0uGqKQ%3D%3D] ,
* 2 x Roue de balance [https://fr.rs-online.com/web/p/billes-porteuses/0687770/] ,
* 2 x Emetteur/Récepteur Ultrason 40kHz [https://www.robotshop.com/ca/fr/module-sonar-hc-sr04-ultra01.html] .
|
|-
| P30 [[IMA4 2017/2018 P30|Contrôle d'une caméra WiFi.]]
|
Sont fournis par Ürbik :
* 2 x Cartes Micro-SD 
*2 x Support Micro-SD vers SD 
*1 * Banana Pi Pro 
*1 * Antenne Wifi pour Banana Pi Pro 
*1 * Module RTC compatible Banana Pro 
*1 * Shield de dévloppement GPIO Banana Pro
*1 * Bloc d'alimentation 230v~5v micro USB 
*1 * Banana Pi D1
*1 * Adaptateur ethernet USB type A
*1 * Cable MicroUSB mâle vers USB type A femelle
*1 * Cable USB type A mâle vers Micro USB mâle et USB type A femelle
Sont demandés à Polytech :
* 2 x Servomoteurs 
* 2 x Câbles ethernet 
* 1 x BananaPi D1 en remplacement [https://e.banana-pi.fr/cameras-banana-pi/35-bpi-d1-camera-ip.html] 
|-
| P32 [[IMA4 2017/2018 P32|Tribute to Peter Vogel]]
|
* 15 x Photorésistances LDR04 [https://www.gotronic.fr/art-photoresistance-ldr04-2150.htm#complte_desc]
* 20 x Amplificateur opérationnel LM358N [https://fr.rs-online.com/web/p/amplificateurs-operationnels/8431578]
* 15 x Résistances 68Kohm [https://fr.rs-online.com/web/p/resistances-traversantes/0386048]
* 15 x Résistances 4,7Kohm [https://fr.rs-online.com/web/p/resistances-traversantes/7077726]
* 25 x Résistances 1Kohm [https://fr.rs-online.com/web/p/resistances-traversantes/2671777]
* 25 x Transistors NPN 2N3904 [https://fr.rs-online.com/web/p/transistors-bipolaires/7390442]
* 12 x Potentiomètres linéaires 100k [https://fr.rs-online.com/web/p/potentiometres/2633006/]
* 10 x Potentiomètres linéaires 10k [https://www.mouser.fr/productdetail/welwyn-components-tt-electronics/p160kn-0qc17b10k?qs=sGAEpiMZZMtC25l1F4XBU1WvpdUcjC%2F6L3FhnOV516EmtF%252b%252b7aZUUw%3D%3D]
* 10 x Condensateurs 10µF [https://www.gotronic.fr/art-condensateur-radial-10uf-50v-3360.htm]
* 10 x Résistances 100Kohm [https://www.gotronic.fr/art-10-resistances-1-4w-100k-8486-20.htm]
* 70 x Leds rouges [https://www.gotronic.fr/art-leds-rouges-led5rl-356.htm]
* 1 x Condensateur 100nF [https://www.gotronic.fr/art-condensateur-ceramique-100-nf-3215.htm]
* 2 x Petits moteurs [https://www.gotronic.fr/art-moteur-miniature-sr30-787.htm]
* 1 x Atmega 328p [https://www.gotronic.fr/art-atmega328p-pu-16820.htm]
* 1 x Led verte [https://www.gotronic.fr/art-leds-vertes-led3gl-2057.htm]
* 1 x Résistance 330ohms 1/6th Watt Pth[https://eu.mouser.com/ProductDetail/SparkFun/COM-08377/?qs=sGAEpiMZZMuM1nRwI3zz2UpCr55iWBr5d51zFU1jOr2Myatejq0Ujw==]
* 1 x bouton poussoir [https://www.gotronic.fr/art-bp-subminiature-krs32n-4271.htm?qs=sGAEpiMZZMs%2FSh%2Fkjph1tvt1%2FmEPT%2FXoz55nayTMEJw%3D]
* 2 x Condensateurs découplages 10µF [https://www.gotronic.fr/art-condensateur-faible-esr-10uf-50v-11308.htm]
* 2 x Condensateurs céramiques 22pF [https://www.gotronic.fr/art-condensateur-ceramique-22-pf-3178.htm]
* 1 x Régulateur de tension [https://www.gotronic.fr/art-l7805cv-1578.htm]
* 1 x Cristal 16Mhz [https://www.gotronic.fr/art-quartz-16-000-mhz-55.htm]
* 3 x Female headers [https://www.mouser.fr/productdetail/harwin/m50-3030842?qs=sGAEpiMZZMve4%2FbfQkoj%252bNAvEyry7AuOrgimgco8uSU%3D]
* 2 x Haut-parleur 2W [https://www.mouser.fr/ProductDetail/CUI/CDS-27208?qs=sGAEpiMZZMuTkJYgZlQcSew3leo0OO6IWAIjM88CpYEXXyeONvvJNg==]
|-
| P35 [[IMA4 2017/2018 P35|Manette de jeu vidéo pour personne en situation de handicap]]
|
* 3 x Push buttons [https://www.gotronic.fr/art-bp-miniature-krs1273-16976.htm] ,
* 2 x Thumbstick (joystick analogique 4 directions) [https://www.gotronic.fr/art-joystick-analogique-4-directions-19063.htm] ,
* 1 x Led RGB [https://www.gotronic.fr/art-led-rgb-5-mm-led5rvb-2103.htm],
* 1 x Raspberry Pi 3 + son câble + carte SD+ alim [https://fr.rs-online.com/web/p/processor-microcontroller-development-kits/8968660/?src=raspberrypi],
* 3 x Arduino UNO ,
* 5 x Alimentation 3V: 10*piles AAA 1,2V rechargeables [https://www.mouser.fr/ProductDetail/Panasonic-Battery/HHR-60AAAHB2?qs=sGAEpiMZZMuXcNZ31nzYhUR9TS3h0B6UyKPniAa4akA%3d],
* 5 x modules bluetooth Nordi nrf nRF52810-QFAA-R [https://www.mouser.fr/productdetail/nordic-semiconductor/nrf52810-qfaa-r?qs=sGAEpiMZZMve4%2FbfQkoj%252bG%2FosjLoe2oghFQwQllMrQ4%3D] ,
* 1 x barette connecteur mâle traversant [https://www.gotronic.fr/art-connecteur-he14-mh200-4459.htm] ,
* 1 x barette connecteur femelle traversant [https://fr.rs-online.com/web/p/barrettes-pour-ci/2677416/] ,
* 1 x breadboard .
* 1 x Raspberry pi zero [https://www.mouser.fr/ProductDetail/SparkFun/DEV-14277?qs=sGAEpiMZZMve4%2fbfQkoj%252bFrmy5Au2u3K1KAGntXrVH8%3d] .
*5 * microcontroleur Atmega328P-PU .
*10 * capacitors 22pF [https://fr.rs-online.com/web/p/condensateurs-ceramique-simple-couche/7215101/] .
*1* bouton poussoir (RESET) .
*5* résistances 10 kOhms .
*5* oscillateur quartz 16Mhz [https://fr.rs-online.com/web/p/quartz/5476294/] .
|-
| P39 [[IMA4 2017/2018 P39|Musique des plantes]]
|
* 1 x Plante ,
* 1 x Cordon pour électrodes [https://www.mouser.fr/ProductDetail/SparkFun-Electronics/CAB-12970/?qs=%2fha2pyFaduj1O95kixslzNrly0UKgNYdQ2TazqXF05PpguJVsXXh3Q%3d%3d],
* 1 x Electrodes [https://www.gotronic.fr/art-pads-a-electrodes-sen-12969-26244.htm],
* 2 x (précédemment 1) Amplificateur d'instrumentation INA125[http://fr.farnell.com/texas-instruments/ina125p/amp-inst-precision-pdip16-125/dp/1459461],
* 1 x Amplificateur d'instrumentation OPA320[http://fr.farnell.com/texas-instruments/opa320aidbvr/ampli-op-20mhz-10v-us-sot-23-5/dp/2542658?st=OPA320],
* 1 x Amplificateur d'instrumentation OPA2320[http://fr.farnell.com/texas-instruments/opa2320aidgkt/op-amp-gp-r-r-cmos-20mhz-8msop/dp/1864818?st=OPA2320],
* 1 x Amplificateur d'instrumentation INA132 [http://fr.farnell.com/texas-instruments/ina132ua-2k5/ampli-diff-300khz-0-1v-us-soic/dp/2782755RL?st=INA132],
* 1 x Arduino Mega [https://fr.rs-online.com/web/p/kits-de-developpement-pour-processeurs-et-microcontroleurs/7154084/],
* 1 x module bluetooth [https://www.gotronic.fr/art-module-bluetooth-hc05-ef03079-05-25579.htm#complte_desc],
* 1 x Cable d'alimentation [https://www.gotronic.fr/art-cordon-alimentation-pile-9v-19414.htm],
* 1 x Batterie [http://fr.farnell.com/duracell/accu-9v1/accumulateur-9v-pq1/dp/4140308],
* 2 x Connecteur Jack [https://fr.rs-online.com/web/p/connecteurs-jack-trs/5051485/],
* 1 x Connecteur MIDI [https://fr.rs-online.com/web/p/connecteurs-din/0491087/],
* 1 x AOP LM324 [http://fr.farnell.com/texas-instruments/lm324n/ic-op-amp-quadruple/dp/1564884?st=LM324N],
* 3 x Interrupteurs [http://fr.farnell.com/multicomp/1ms1t1b5m1qe/interrupteur-spdt/dp/9473378?st=commutateur%20%C3%A0%20levier%20on%20on],
* 1 x Potentiomètre [https://www.gotronic.fr/art-ajustable-vertical-2-2k-8486-11159.htm#complte_desc],
* 2 x LED RGB [https://www.gotronic.fr/art-led-rgb-5-mm-led5rvb-2103.htm],
* 1 x Haut-Parleur [http://fr.farnell.com/kingstate/kdmg28008/loudspeaker-micro/dp/1502732?MER=bn_level5_5NP_EngagementRecSingleItem_3],
* 1 x CAN [http://fr.farnell.com/microchip/mcp2551-i-sn/hi-speed-transceiver-can-2551/dp/9758569],
* 1 x CAN [http://fr.farnell.com/microchip/mcp2551-e-sn/ic-transceiver-can-smd-8soic/dp/1467746],
* 1 x Headers 2*23 [https://www.mouser.fr/ProductDetail/SparkFun/PRT-12790?qs=sGAEpiMZZMuWWq7rhECaKTxAh05%2fvU1hSqT3VTr1yQo%3d],
* 5 x Headers 1*8 [https://www.mouser.fr/ProductDetail/SparkFun/PRT-09279?qs=sGAEpiMZZMuWWq7rhECaKVf6TnXuSdhbVm54%252ba39HDI%3d],
* 1 x Headers 1*10 [https://www.mouser.fr/ProductDetail/SparkFun/PRT-11376?qs=sGAEpiMZZMuWWq7rhECaKW7JSoPFJbh65nnJcQqXBPM%3d],
|-
| P40 [[IMA4 2017/2018 P40|Exploration du réseau d'anonymisation Tor]]
|
*Réseau d'ordinateurs de l'école, implantés avec des VM,
*Un commutateur,
*La ligne SDSL,
*Et un marteau :).
|-
| P42 [[IMA4 2017/2018 P42|Automatisation de l'assemblage de LEGO]]
|
*1 x Arduino Mega
*1 x ESP8266
*1 x Raspberry Pi 3
*1 x imprimante 3D
*1 x plaque de polystyrène
*1 x plaque de plexiglas (3mm)
*1 x plaque Lego [https://shop.lego.com/fr-FR/La-plaque-de-base-verte-10700]
*15 x brique 1x1 noir [https://www.briquestore.fr/1x1/1233-lego-302426-plate-1x1-noir.html]
*15 x brique 1x1 blanc [https://www.briquestore.fr/1x1/1236-lego-302401-plate-1x1-blanc.html]
*15 x brique 1x1 bleu [https://www.briquestore.fr/1x1/1238-lego-302423-plate-1x1-bleu.html]
*15 x brique 1x1 rouge [https://www.briquestore.fr/1x1/1237-lego-302421-plate-1x1-rouge.html]
*15 x brique 1x1 jaune [https://www.briquestore.fr/1x1/1239-lego-302424-plate-1x1-jaune.html]
*15 x brique 1x1 vert [https://www.briquestore.fr/1x1/1241-lego-302428-plate-1x1-dark-green.html]
|
|-
| P44 [[IMA4 2017/2018 P44|Reconnaissance d’objets via Traitement d’Image]]
|
|-
| P49 [[IMA4 2017/2018 P49|Suivi de la qualité de l’air]]
|
Matériel fournit par l'INRIA :
* 1 x Raspberry Pi 3
* 1 x Arduino Méga
* 1 x détecteur de mouvement PIR (HC-SR01)
* 1 x détecteur de bruit
* 1 x capteur de température et d'humidité (DHT22)
* 1 x capteur de pression
* 1 x capteur de luminosité
* 1 x capteur de Composé Organique Volatil COV 
* 4 x capteurs de monoxyde de carbone CO (Alphasense) 
* 2 x capteurs de dioxyde de carbone CO2
* 1 x E/R XBee
* 1 x clavier alphanumérique usb
|-
| P50 [[IMA4 2017/2018 P50|Etage commande de Centaure]]
|
Matériels existants:
*2 x Batteries 12V 22Ah (dont une hs)
*1 x Chargeur de batterie 12V 
*1 x Contacteur 24Vcc 18A ref: TeSys LC1D18BD 
*2 x Variateurs de vitesse ref: Alpes Ital 8CH2QM.2
*1 x Arduino MEGA ADK avec son bouclier de capteurs 
*1 x Carte keyes funduino à 4 relais
*1 x DC/DC convertisseur 24V => 12V & 5V ref: Tracopower TEN 40-4811 
*1 x Porte fusibles à 5 ports 
Matériels manquants:
* 1* Batterie 12V 55Ah; trouvée chez le fournisseur mouser.fr [https://www.mouser.fr/productdetail/power-sonic/ps-12550?qs=sGAEpiMZZMso%252bSMtTqBO32B9ZZCkCjmed3agP8D7TIo%3D]
* 1* Chargeur 24V; chez le même fournisseur [https://www.mouser.fr/productdetail/ault-sl-power/bvl240600003n?qs=sGAEpiMZZMsYfYypWaYaEeWCnBdw823Sg9r4NP%2FMM%252bU%3D] 
|-
| P60 [[IMA4 2017/2018 P60|Commande de niveaux d’eau]]
|
|-
| P64 [[IMA4 2017/2018 P64|Simulation Labview et mise en réseau Modbus d’un ascenseur]]
|
|-
| P65 [[IMA4 2017/2018 P65|Exosquelette pour apprentissage]]
|
*1 x Motoréducteur MFA 919D1001 [https://www.gotronic.fr/art-motoreducteur-mfa-919d1001-11742.htm]
*1 x Amplificateur de courant mesurée MAX4378 [https://www.mouser.fr/ProductDetail/Maxim-Integrated/MAX4378FAUD%2b?qs=sGAEpiMZZMvEn2pkGav3bMGiddAnKBJhMUlghJlr6fA%3d]
|-
| P66 [[IMA4 2017/2018 P66|Coupe de France de robotique]]
|
Fourni par Robotech :
*1 × Batterie Lipo 4S
*1 × Carte de puissance
*1 × Support mécanique & Roues
*2 × Faulhaber MOTOR 3557K024CS
*1 × Contrôleur moteur
*2 × HEDM-550X
*1 × Capteur MinIMU-9 v3
*X × Capteurs ultrasons / infrarouges
*1 × MicroNova Mercury FPGA Development Board
*1 × Arduino MEGA 2560
*1 × Raspberry Pi 3
*1 × Écran LCD SPI
*X × Boutons
|-
| P67 [[IMA4 2017/2018 P67|Scanner 3D DIY]]
|
*2x Moteur NEMA 17
*2x contrôleur moteur
*bouton poussoir de fin de parcours de courroie
*courroie et engrenage pour Nema 17
*Alim 12V
*bobine de PLA pour impression 3D (dispo au Fabricarium)
*Carte arduino Méga
*Caméra Kinect pour 360 ou Kinect microsoft
*Câble / résistances / capa
*module de sauvegarde pour carte SD ou carte micro SD (j'en possède déjà un)
*capteur de mesure de distance [http://fr.farnell.com/sharp/gp2y0a21yk0f/capteur-de-distance/dp/1243869]
*bois
|-
| P68 [[IMA4 2017/2018 P68|Générateur de chronogrammes d'ordonnancement]]
|
|-
| PP1 [[IMA4 2017/2018 Pré-projet 1|Robot hexapode pour escalier]]
|
* Arduino Mega / câble
* 12 servos moteurs SG90 
* une structure robot 4 pattes 
* Plaque d'essai, câbles 
|-
|}

Projets IMA4 SC & SA 2017/2018

2018-02-09T16:31:24Z

Tgracias : /* Matériel à acquérir */

Merci de référencer vos pages de projets ici. Merci aussi d'uniformiser vos formats que ce soit en regardant la présentation des projets déjà créés ou en demandant une modification du format des précédents si votre façon de faire vous semble la meilleure. Dans tous les cas un minimum de communication entre les binômes est conseillée.

Toutes les sources doivent être déposées sur notre archive GIT. Le service est disponible à l'URL [https://archives.plil.fr archives.plil.fr]. Connectez-vous avec vos identifiants Polytech'Lille. Sauf indication contraire de vos encadrants, rendez le projet public et mettez le lien sur votre Wiki. Vous pouvez trouver de la documentation sur ce système d'archives sur ce [https://git-scm.com/book/fr/v1 site].

== Répartition des binômes ==

{| class="wikitable"
! Projet !! Encadrants école !! Elèves
|-
| P0 [[IMA4 2017/2018 P0|Modèle]]
|
|
|-
| P1 [[IMA4 2017/2018 P1|Automatisation de la production de bière]]
| Rémy Bernard / Alexandre Boé / Thomas Vantroys
| Henri Carlier / Quentin Boëns
|-
| P3 [[IMA4 2017/2018 P3|Sécurisation de l'Internet des Objets par surveillance globale]]
| Alexandre Boé / Xavier Redon / Thomas Vantroys
| Ji Yang
|-
| P4 [[IMA4 2017/2018 P4|Développement d'un module d'énergie pour Internet des Objets]]
| Alexandre Boé / Xavier Redon / Thomas Vantroys
| Abass Ayoub / Alexis Viscogliosi
|-
| P5 [[IMA4 2017/2018 P5|Réseau de capteurs de pollution]]
| Thomas Vantroys / Alexandre Boé / Xavier Redon
| Paul Ribeiro / Naif Mehanna
|-
| P6 [[IMA4 2017/2018 P6|Réseau LoRaWAN]]
| Alexandre Boé / Xavier Redon / Thomas Vantroys
| Antoine Gosse
|-
| P7 [[IMA4 2017/2018 P7|Brique pour apprentissage informatique]]
| Alexandre Boé / Emmanuelle Pichonnat / Thomas Vantroys
| Maéva Delaporte / Simon Blas
|-
| P10 [[IMA4 2017/2018 P10|Portage de RIOT-OS sur MSP430 pour IOT]]
| Thomas Vantroys / Alexandre Boé / Xavier Redon
| Baptiste Cartier
|-
| P12 [[IMA4 2017/2018 P12|Système d'ostéophonie pour magicien]]
| Alexandre Boé / Xavier Redon / Thomas Vantroys
| Amine El Messaoudi / Simon Feutrier
|-
| P14 [[IMA4 2017/2018 P14|Ecran géant modulaire]]
| Alexandre Boé / Xavier Redon / Thomas Vantroys
| Jade Dupont
|-
| P15 [[IMA4 2017/2018 P15|Balle vibrante connectée pour enfants sourd]]
| Rodolphe Astori / Alexandre Boé / Thomas Vantroys
| Thibault Cattelain / Thomas Cunin
|-
| P16 [[IMA4 2017/2018 P16|Sous-chaussure chauffante pour docker]]
| Remy Bernard / Alexandre Boé / Thomas Vantroys
| Rémi Mairesse / Gustave Roux
|-
| P17 [[IMA4 2017/2018 P17|Safe Watch]]
| Xavier Redon
| Oumaima Naanaa
|-
| P18 [[IMA4 2017/2018 P18|Mandala électronique]]
| Xavier Redon / Alexandre Boé
| Lirui Zhang / Lihe Zhang
|-
| P19 [[IMA4 2017/2018 P19|Bijou électronique]]
| Xavier Redon / Alexandre Boé
| Keren Qiang / Lijie Yao
|-
| P20 [[IMA4 2017/2018 P20|Solution de messagerie à base de conteneurs]]
| Xavier Redon / Thomas Vantroys
| Maxime Creteur / Fan Gao
|-
| P22 [[IMA4 2017/2018 P22|Horloge numérique DCF77, serveur de temps et ludique]]
| Xavier Redon / Alexandre Boé / Thomas Vantroys
| Amaury Knockaert / Fabrice Taingland
|-
| P23 [[IMA4 2017/2018 P23|Table de bar connectée]]
| Thomas Vantroys / Alexandre Boé
| Matthieu Delobelle
|-
| P25 [[IMA4 2017/2018 P25|Essaim de robots]]
| Xavier Redon / Alexandre Boé
| Ganix Etcheguibel / Benjamin Canu
|-
| P30 [[IMA4 2017/2018 P30|Contrôle d'une caméra WiFi.]]
| Nathan Martin / Xavier Redon
| Thomas Hubert / Taky Djeraba
|-
| P32 [[IMA4 2017/2018 P32|Tribute to Peter Vogel]]
| Thomas Vantroys / Alexandre Boé / Xavier Redon
| Antoine Untereiner / Jean-Baptiste Watine
|-
| P35 [[IMA4 2017/2018 P35|Manette de jeu vidéo pour personne en situation de handicap]]
| Alexandre Boé / Xavier Redon / Thomas Vantroys
| Camille Saad / Transley Gracias
|-
| P39 [[IMA4 2017/2018 P39|Musique des plantes]]
| Emmanuelle Pichonat / Alexandre Boé
| Rodolphe Toin / Xavier Chenot
|-
| P40 [[IMA4 2017/2018 P40|Exploration du réseau d'anonymisation Tor]]
| Xavier Redon / Thomas Vantroys
| Anthony Durot / Antoine Duquenoy
|-
| P42 [[IMA4 2017/2018 P42|Automatisation de l'assemblage de LEGO]]
| Xavier Redon / Alexandre Boé / Thomas Vantroys
| Justine Senellart / Eloi Zalczer
|-
| P44 [[IMA4 2017/2018 P44|Reconnaissance d’objets via Traitement d’Image]]
| Thomas Danel / Vincent Coelen
| Zoé Briois / Damien Narbais
|-
| P49 [[IMA4 2017/2018 P49|Suivi de la qualité de l’air]]
| Romain Rouvoy / Rédha Kassi
| Nicolas Havard / Hugo Delbroucq
|-
| P50 [[IMA4 2017/2018 P50|Etage commande de Centaure]]
| Xavier Redon / Alexandre Boé / Thomas Vantroys
| Haroun Abdelali
|-
| P60 [[IMA4 2017/2018 P60|Commande de niveaux d’eau]]
| Midzodzi Pekpe
| Claire Vandamme / Alexendra Villa
|-
| P64 [[IMA4 2017/2018 P64|Simulation Labview et mise en réseau Modbus d’un ascenseur]]
| Midzodzi Pekpe / Blaise Conrard
| François-Xavier Cockenpot
|-
| P65 [[IMA4 2017/2018 P65|Exosquelette pour apprentissage]]
| Alexandre Boé / Xavier Redon / Thomas Vantroys
| Florian Le Foll
|-
| P66 [[IMA4 2017/2018 P66|Coupe de France de robotique]]
| Alexandre Boé / Xavier Redon / Thomas Vantroys
| Geoffrey Preud'homme / Amaury Carval
|-
| P67 [[IMA4 2017/2018 P67|Scanner 3D DIY]]
| Xavier Redon / Alexandre Boé / Thomas Vantroys
| Erwan Dufresne
|-
| P68 [[IMA4 2017/2018 P68|Générateur de chronogrammes d'ordonnancement]]
| Xavier Redon / Thomas Vantroys
| Samy Belhouachi
|-
| PP1 [[IMA4 2017/2018 Pré-projet 1|Robot hexapode pour escalier]]
| Alexandre Boé / Xavier Redon / Thomas Vantroys
| Eduardo Gomez-Riaza
|}

== Matériel à acquérir ==

{| class="wikitable"
! Projet !! Matériel
|-
| P1 [[IMA4 2017/2018 P1|Automatisation de la production de bière]]
|
*Capteur de température DS18B20 [https://www.gotronic.fr/art-sonde-etanche-ds18b20-19339.htm]
*Raccord tuyau en Y [https://fr.rs-online.com/web/p/coupleurs-de-tuyaux-flexibles/4197259/] 
*2 Pompes péristaltique dc 12V [https://www.mouser.fr/ProductDetail/Adafruit/1150?qs=sGAEpiMZZMsMyYRRhGMFNp8jyMJFi5X9NqTp2aghyow%3d]
*Tube en silicone [https://fr.rs-online.com/web/p/tubes-flexibles/9124751/]
*Tube en cuivre [https://fr.rs-online.com/web/p/tubes-en-cuivre/0846503/]
*2 résistances 1kOhms
*2 transistors bc547
*2 diodes
*14 cables M/M
*Alimentation DC 12V 
|-
| P3 [[IMA4 2017/2018 P3|Sécurisation de l'Internet des Objets par surveillance globale]]
|
*Xbee USB Adapter * 1 [https://www.amazon.fr/dp/B017KGBP6Y/ref=asc_df_B017KGBP6Y48622783/?tag=googshopfr-21&creative=22722&creativeASIN=B017KGBP6Y&linkCode=df0&hvdev=c&hvnetw=g&hvqmt=]
*XDigiKey Xbee module 2.4Hz * 4 [https://www.digikey.com/catalog/en/partgroup/xbee-and-xbee-pro-zb-zigbee/12201] ReX : imprécis, cherchez chez gotronic
*l'antenne pour Xbee * 4 [https://www.matlog.fr/fr/61-antennes-24-ghz.html]
*Arduino uno * 4 [https://store.arduino.cc/usa/arduino-uno-rev3]
*Xbee Shields pour Arduino * 4 [https://store.arduino.cc/arduino-wirelss-sd-shield]
*Câble USB pour Arduino * 4 [https://fr.aliexpress.com/item/usb-cable-for-arduino-with-UNO-R3-ATMEGA328P-PU-ATMEGA8U2-and-Mega-2560-R3-Mega2560-REV3/32624000858.html?src=google&albslr=221466033&isdl=y&aff_short_key=UneMJZVf&source=%7Bifdyn:dyn%7D%7Bifpla:pla%7D%7Bifdbm:DBM&albch=DID%7D&src=google&albch=shopping&acnt=494-037-6276&isdl=y&albcp=653151748&albag=36672819047&slnk=&trgt=61865531738&plac=&crea=fr32624000858&netw=g&device=c&mtctp=&gclid=Cj0KCQiAv_HSBRCkARIsAGaSsrC92WYZ2oroveXJLqUQCBfRBuRMa8VoShOZWNBitPIvrry8V1HpMmkaAg-QEALw_wcB] 
*Batterie externe(qui a 2 ports à recharger) * 4 [https://www.amazon.fr/EC-Technology-22400mAh-Batterie-capacit%C3%A9/dp/B00F5Q4F0U/ref=sr_1_1_sspa?ie=UTF8&qid=1513804729&sr=8-1-spons&keywords=batteries+externe&psc=1]
*USB À UART TTL Câble * 1 [https://fr.aliexpress.com/item/USB-To-RS232-TTL-USB-To-COM-Serial-Adapter-Cable-Module-PL2303HX-Converter/1859099599.html?src=google&albslr=201492522&isdl=y&aff_short_key=UneMJZVf&source=%7Bifdyn:dyn%7D%7Bifpla:pla%7D%7Bifdbm:DBM&albch=DID%7D&src=google&albch=shopping&acnt=494-037-6276&isdl=y&albcp=653151748&albag=36672819047&slnk=&trgt=61865531738&plac=&crea=fr1859099599&netw=g&device=c&mtctp=&gclid=CjwKCAiAsejRBRB3EiwAZft7sENdHUiXBHo-JhKGxsmwfnaRATNn_OPdCl9y-WVMwi8elX5S6QCMnhoCNm8QAvD_BwE]
*Breadboard de prototypage * 3 [https://www.amazon.fr/Breadboard-Carte-dexp%C3%A9rimentation-Soudure-Solderless/dp/B06XWFG9DT/ref=sr_1_2_sspa?ie=UTF8&qid=1516049551&sr=8-2-spons&keywords=breadboard+arduino&psc=1]
*USB câble pour xbee USB Adapter [https://www.amazon.fr/dp/B003OSS4SA/ref=asc_df_B003OSS4SA49349077/?tag=googshopfr-21&creative=22698&creativeASIN=B003OSS4SA&linkCode=df0&hvdev=c&hvnetw=g&hvqmt=]
|-
| P4 [[IMA4 2017/2018 P4|Développement d'un module d'énergie pour Internet des Objets]]
|
* 1xModule solaire [[https://www.mouser.fr/ProductDetail/MikroElektronika/MIKROE-651?qs=sGAEpiMZZMvxW%252bY8mn0Q9U%252b%2fhOkIvSmCqkyN6XrqZsI%3d]]
* 1xBatterie [[http://fr.farnell.com/varta/55608303059/batterie-nimh-3-6v/dp/279341]]
* 1xConvertisseur Boost [[https://fr.rs-online.com/web/p/convertisseurs-boost/8123659/]]
* 2xDiode de Schottky de redressement [[https://fr.rs-online.com/web/p/diodes-de-redressement-et-schottky/7390436/]]
* 1xConvertisseur Buck-Boost (sortie) [[https://fr.rs-online.com/web/p/regulateurs-a-decoupage-buck-boost/6989091/]]
* 2xSupercondensateur 2,7V - 50F [[https://www.mouser.fr/ProductDetail/Maxwell-Technologies/BCAP0050-P270-T01/?qs=sGAEpiMZZMsCu9HefNWqpt2sk1W1BTZ59akVpHhf5KE=]]
* 10 jumpers [[https://fr.rs-online.com/web/p/cavaliers-et-shunts/6742397/]]
* Module MPPT [[https://www.mouser.fr/ProductDetail/STMicroelectronics/SPV1050TTR?qs=sGAEpiMZZMsMLZWdhVL71%2fkXzzgq0Ptzmbr9rWlHkic%3d]]
* 20 pin connection mâle [[https://fr.rs-online.com/web/p/barrettes-pour-ci/8967620/]]
* 10 transistor npn commandé en tension [[https://fr.rs-online.com/web/p/transistors-bipolaires/7390381/]]
|-
| P5 [[IMA4 2017/2018 P5|Réseau de capteurs de pollution]]
|
* ESP32 [[https://www.gotronic.fr/art-carte-esp32-dev-13907-25510.htm]]
* Module GPS [[https://www.gotronic.fr/art-module-gps-tel0094-25732.htm]]
* Batterie Lithium Ion [[https://fr.rs-online.com/web/p/batteries-externes/8755758/]] ou [[https://fr.rs-online.com/web/p/batteries-externes/1366470/]] suivant le prix
* Adaptateur micro USB
* Breadboard
* Un smartphone sous Android (Version Lollipop minimale - optionnel)
* HPMA115S0-XXX (Capteur déjà acheté normalement)
* 2 connecteurs micro-USB [[https://www.gotronic.fr/art-embase-micro-usb-b-cms-18339.htm]]
|-
| P6 [[IMA4 2017/2018 P6|Réseau LoRaWAN]]
|
* 1 * iC880A-SPI , 
* 1 * Raspberry , 
* 2 * Nucleo-F4 , 
* 2 * Shield STM32 LoRa, 
|-
| P7 [[IMA4 2017/2018 P7|Brique pour apprentissage informatique]]
|
*1xCapteur ultrason [https://www.gotronic.fr/art-module-de-detection-us-hc-sr04-20912.htm]
*2xafficheurs-7segments [http://fr.farnell.com/broadcom-limited/hdsp-7801/afficheur-a-leds-7-62mm-vert/dp/1003275]
*4xboutons poussoirs [https://www.gotronic.fr/art-module-bouton-poussoir-st043-26115.htm]
*4xleds [https://www.gotronic.fr/art-led-5-mm-led5bt-21009.htm]
*2xpotentiomètres [https://www.gotronic.fr/art-potentiometre-lineaire-47k-8486-11110.htm]
*2xcâble [https://www.gotronic.fr/art-cordon-alimentation-pile-9v-19414.htm] + pile [https://www.gotronic.fr/art-pile-9v-au-lithium-uv9l-5575.htm] pour alimenter l'Arduino
*2xArduino Uno [https://store.arduino.cc/arduino-uno-rev3]
*2xModule bluetooth pour arduino (BTM-01)[https://www.mouser.fr/ProductDetail/OSEPP-Electronics/BTM-01/?qs=YCa%2fAAYMW020ADfc44%2fjCA%3d%3d]
*10xMicrocontrôleur Atmega328p [http://fr.farnell.com/microchip/atmega328p-pu/micro-8-bits-avr-32k-flash-28pdip/dp/1715487]
*2xKit roue + moteur [https://www.gotronic.fr/art-kit-roue-moteur-23569.htm]
*1xRoue folle [https://www.robotshop.com/eu/fr/roulette-bille-pololu-0375-po-metal.html]
*1xContrôleur de moteur [https://www.gotronic.fr/art-commande-de-2-moteurs-tb6612fng-2x1a-21716.htm]
*50xpicots mâle [https://fr.rs-online.com/web/p/barrettes-pour-ci/8967620/]
*5xpicots femelle [https://fr.rs-online.com/web/p/barrettes-pour-ci/2677400/]
*4x10 ressorts [https://fr.rs-online.com/web/p/ressorts-de-compression/0821245/]
*1xplaque de contreplaqué [https://www.leroymerlin.fr/v3/p/produits/predecoupe-medium-mdf-naturel-ep-10-mm-l-120-x-l-60-cm-e105237#&xtmc=predecoupe&xtcr=1]
|-
| P10 [[IMA4 2017/2018 P10|Portage de RIOT-OS sur MSP430 pour IOT]]
|
* 2xCC430 [https://www.mouser.fr/ProductDetail/Texas-Instruments/CC430F5137IRGZT/?qs=%2fqzd9s%252bcLd7GiX35ln9VRA==] (fourni par les tuteurs de projet) 3 reçus
* 1xMSP430-CCRF [https://www.olimex.com/Products/MSP430/Starter/MSP430-CCRF/] (fourni par les tuteurs de projet)
* 1xMSP-EXP430G2 [https://www.mouser.fr/productdetail/texas-instruments/msp-exp430g2?qs=sGAEpiMZZMv1ORdfpzTN%252bMwZ3%252b5KGk2B] (fourni par les tuteurs de projet)
|-
| P12 [[IMA4 2017/2018 P12|Système d'ostéophonie pour magicien]]
|
* Raspberry Pi 3, 
* Microcontroleur STM32L433CCT6 [https://www.mouser.fr/ProductDetail/STMicroelectronics/STM32L433CCT6?qs=sGAEpiMZZMuoKKEcg8mMKFZaGHZhaFFC5XHr6X%2fBPloj9WsFWEQ6BA%3d%3d],
* Mémoire Flash IS25WP064A-RMLE [https://www.mouser.fr/productdetail/issi/is25wp064a-rmle?qs=sGAEpiMZZMtI%252bQ06EiAoG5kNS0TozX6Gt0%2FX%2Fi6ExQk%3D], 
* DAC MCP4725A0T-E/CH [https://www.mouser.fr/productdetail/microchip-technology/mcp4725a0t-e-ch?qs=sGAEpiMZZMvfFCidbTccA97L6UsE6%2Fky], 
* Batterie 3.6V [https://www.gotronic.fr/art-accu-nimh-3-6v-300mah-290.htm], 
* Module Bluetooth 4.1 BM20SPKS1NBC-0001AA [https://www.mouser.fr/ProductDetail/Microchip-Technology/BM20SPKS1NBC-0001AA?qs=sGAEpiMZZMsGelYiB%252bjhZv%252biZoDZL1ptX5ao52HhnlyFQbPW6KaEbg%3d%3d],
* Adafruit Bone Conductor Transduce [https://www.mouser.fr/ProductDetail/Adafruit/1674/?qs=sGAEpiMZZMsqIr59i2oRcvz%252byDSTdozphj%2f1Oxe6%252bAQ=], 
* Transducteur Piézo diaphragme :
** fréquence de résonance 2.9KHz (gotronic) [https://www.gotronic.fr/art-disque-piezoelectrique-dp035-3843.htm],
** fréquence de résonance 4.6KHz (gotronic) [https://www.gotronic.fr/art-disque-piezoelectrique-dp027-3842.htm],
** fréquence de résonance 6.6KHz (gotronic) [https://www.gotronic.fr/art-disque-piezoelectrique-dp024-3841.htm],
** Afréquence 8KHz 10KHz (RS) [https://fr.rs-online.com/web/p/buzzers-piezo/7214947/],
* Moteur Électrique CC RS Pro, 3 → 7,2 V c.c., 19,68 W, 19000 tr/min, 4,41 A [https://fr.rs-online.com/web/p/moteurs-v-cc/2389721/].
|-
| P14 [[IMA4 2017/2018 P14|Ecran géant modulaire]]
|
|-
| P15 [[IMA4 2017/2018 P15|Balle vibrante connectée pour enfants sourd]]
|
* 8 vibreurs : [https://www.mouser.fr/productdetail/adafruit/1201?qs=sGAEpiMZZMsMyYRRhGMFNstIkcYqaSq8%2fLLE3lYp32I=]
* Module Bluetooth 4.0 Low Energy : [https://www.mouser.fr/ProductDetail/Adafruit/2479?qs=sGAEpiMZZMsMyYRRhGMFNjWi9ZmxEfRwbLHKJ6JemUg%3d]
* Bobine de recharge à induction (norme Qi) : [https://www.mouser.fr/productdetail/adafruit/1901?qs=sGAEpiMZZMsMyYRRhGMFNkyDC95Rd%252blHW46I1pJekjA%3D]
* Atmega 328p CMS : [https://www.mouser.fr/ProductDetail/Microchip-Technology-Atmel/ATMEGA328PB-AU?qs=sGAEpiMZZMvc81WFyF5EdrSRAEYMYvHlMc95YQj%2fArE%3d]
* 1 Batterie rechargeable 5.2Ah : [https://www.gotronic.fr/art-accu-li-ion-mgl9033-26425.htm#complte_desc]
* 2 controleurs pour moteur :[https://www.mouser.fr/ProductDetail/STMicroelectronics/L293DD?qs=sGAEpiMZZMukgiigmf73gOko5bw7EE67]
*2 condensateurs 14pF :[https://www.mouser.fr/ProductDetail/Murata-Electronics/GCQ1555C1H140FB01D?qs=sGAEpiMZZMs0AnBnWHyRQN7%2fAA2D2lPPLNRvFwtPLQHRWxf2q9etuA==]
*1 crystal quartz 16MHz :[https://www.mouser.fr/ProductDetail/ECS/ECS-160-12-33Q-JES-TR?qs=sGAEpiMZZMuMAfj%252bWfX4nLed60zyr3PUv7Kre5ygQ%252bs%3d]
* 1 résistances CMS 10khoms 0603 :[http://fr.farnell.com/multicomp/mcre000164/res-couche-epaisse-10k-1-0-05w/dp/1711641]
* 7 résistances CMS 1kohms 0603 :[http://fr.farnell.com/multicomp/mcre000140/res-couche-epaisse-1k-1-0-05w/dp/1711615?st=MULTICOMP%201K%200603]
* 1 résistances CMS 470ohms 0603:[https://www.mouser.fr/ProductDetail/TDK/MMZ1608Y471BTA00?qs=sGAEpiMZZMu0dYp3dYbBlQn%252beM9UWul2G3hJ%2f7TLqL0%3d]
* 2 résistances CMS 2kOhms 0603 :[https://www.mouser.fr/ProductDetail/Panasonic-Industrial-Devices/ERJ-3EKF2001V?qs=sGAEpiMZZMu61qfTUdNhGzRxdwze5h8ZMDWmuHH2qQY%3d]
* 2 resistances CMS 340kOhms 0603 :[https://www.mouser.fr/ProductDetail/Vishay/CRCW0603340KFKEA?qs=sGAEpiMZZMukHu%252bjC5l7YRSQiDx9P4ktLgBETRAdfqw%3d]
* 1 resistances CMS 1.87MOhms 0603 :[https://www.mouser.fr/ProductDetail/Yageo/RC0603FR-071M87L?qs=sGAEpiMZZMu61qfTUdNhG6gKAQVNBKOo2zO%2fNI9xQvs%3d]
*2 resistances CMS 100kOhms 0603 :[https://www.mouser.fr/ProductDetail/Vishay-Draloric/RCG0603100KFKEA?qs=sGAEpiMZZMsa677hLZe2Z63dGP%2fTFOZQ]
* 4 condensateur 10uF 0603 :[https://www.mouser.fr/ProductDetail/Taiyo-Yuden/LMK107BC6106MA-T?qs=sGAEpiMZZMukHu%252bjC5l7Yd8IIWTQlTYBUiPYtsE4Bzg%3d]
*1 condensateur 0.1uF 0603 :[https://www.mouser.fr/ProductDetail/Taiyo-Yuden/GMK107BJ104KAHT?qs=sGAEpiMZZMs0AnBnWHyRQNbg85K4ab%2f3WB4TApadaC0%3d]
*1 condensateur 2.2uF 0603 :[https://www.mouser.fr/ProductDetail/Taiyo-Yuden/JMK107B7225KAHTR?qs=sGAEpiMZZMs0AnBnWHyRQPSjYu%2fkbgu8y0KcZVF30DNOIVNQnIIJ3Q%3d%3d]
*1 condensateur 22uF 0603 :[https://www.mouser.fr/ProductDetail/Taiyo-Yuden/LMK107BBJ226MA-T?qs=sGAEpiMZZMs0AnBnWHyRQPSjYu%2fkbgu8OPGniOr6zLcT6eSTCbA%252bCQ%3d%3d]
*2 condensateur 1uF 0603 :[https://www.mouser.fr/ProductDetail/Taiyo-Yuden/GMK107BJ105KA-T?qs=sGAEpiMZZMs0AnBnWHyRQAEIN6r3SS%2fOBpoA9Mx5a9I%3d]
*1 condensateur 1210 100uF 1210 :[https://www.mouser.fr/ProductDetail/Murata-Electronics/GRM32ER61A107ME20L?qs=sGAEpiMZZMukHu%252bjC5l7Ya6pfwBk8EBeq55B9L%252bMJQA%3d]
*2 led verte CMS 1206 :[https://www.mouser.fr/ProductDetail/Kingbright/APTD3216LCGCK?qs=sGAEpiMZZMuCm2JlHBGefutc4sI%252bRg9%2fbKLcTuDCbMNnKZ3XxcbEWg%3d%3d]
*1 led orange 1206 CMS :[https://www.mouser.fr/ProductDetail/Lite-On/LTST-C150KAKT?qs=sGAEpiMZZMseGfSY3csMkTlTHQ2beMlrmGllatFacok%3d]
*2 led rouge 1206 CMS :[https://www.mouser.fr/ProductDetail/Kingbright/APTD3216LSURCK?qs=sGAEpiMZZMuCm2JlHBGefutc4sI%252bRg9%2fEbFuu2HcaZsnh6Yj8wyZLQ%3d%3d]
*1 led bleue CMS 1206 :[https://www.mouser.fr/ProductDetail/Kingbright/APTD3216LQBC-D?qs=sGAEpiMZZMseGfSY3csMkdgyOOAg6kv2SoHfbZ6fYRJR%252bPUfy4LTDQ%3d%3d]
* 1 module Bluetooth 802.15 :[https://www.mouser.fr/productdetail/seeed-studio/317030027?qs=wU1J8Md1npz%2F8UksA%252bh%252byw%3D%3D]
*1 Regulateur de tension LDO :[https://www.mouser.fr/ProductDetail/Microchip-Technology-Micrel/MIC5225YM5-TR?qs=sGAEpiMZZMsGz1a6aV8DcNranXV84HMLR75Z9P39yqc%3d]
*1 Transistor PNP prépolarisé 100mA:[https://www.mouser.fr/ProductDetail/ON-Semiconductor/MMUN2133LT1G/?qs=ZpPixqFcBtysLCI/2LOB%252bQ==]
*1 Régulateur de tension de commutation:[https://www.mouser.fr/ProductDetail/Texas-Instruments/TPS61090RSAR?qs=sGAEpiMZZMuo%252bmZx5g6tFAsofpr73Rbu]
*1 chargeur de batterie pour une cellule Li-on:[http://fr.farnell.com/microchip/mcp73831t-2aci-ot/controleur-de-charge-li-ion-li/dp/1332158]
*3 Diodes :[https://www.mouser.fr/ProductDetail/Diodes-Incorporated/1N4148WQ-7-F?qs=sGAEpiMZZMtzpSA5GSDwayHNFYvfz9yMGFXnI15cqbU%3d]
*1 diodes et redresseurs:[https://www.mouser.fr/ProductDetail/ON-Semiconductor/MBR120ESFT1G?qs=sGAEpiMZZMtQ8nqTKtFS%2fCKUxMvjsmGzPwX1d8aVcbo%3d]
*1 inductance 6.8uH:[http://fr.farnell.com/bourns/srn6045ta-6r8m/inductance-aec-q200-6-8uh-3-6a/dp/2616892]
*Quartz 32Mhz:[https://www.mouser.fr/ProductDetail/?qs=2xLVn2jvFusfExB%252byZEnpA%3D%3D]
|-
| P16 [[IMA4 2017/2018 P16|Sous-chaussure chauffante pour docker]]
|
*2xArduino Pro Mini [https://www.mouser.fr/ProductDetail/Adafruit/2377?qs=sGAEpiMZZMsMyYRRhGMFNrePrikk4IpJQBQo3elmwiI%3d]
*1xbouclier USB vers UART pour mini Arduino [https://www.mouser.fr/ProductDetail/Digilent/410-212?qs=sGAEpiMZZMsF1ODjcwEocFxZWH6k8YAWBC6KMJ05oOA%3d] 
*4xcapteurs de température et humidité DHT22 [https://www.gotronic.fr/art-capteur-de-t-et-d-humidite-dht22-20719.htm]
*2xMOSFET [https://fr.rs-online.com/web/p/transistors-mosfet/5431184/]
*1xbatterie [https://fr.rs-online.com/web/p/batteries-externes/7757508/?searchTerm=pb+A5200&relevancy-data=636F3D3126696E3D4931384E4C446573635461786F6E6F6D794272616E645365617263685465726D325F74656D70266C753D6672266D6D3D6D617463687061727469616C6D617826706D3D5E5B5C707B4C7D5C707B4E647D3F5C707B5A737D2D2C2F255C2E5D2B2426706F3D31313326736E3D592673743D4B4559574F52445F4D554C54495F414C5048415F414E445F4D554C54495F414C5048415F4E554D455249432673633D592677633D4E4F4E45267573743D7062204135323030267374613D706220413532303026]
*1xfilm de tranfert thermique [https://fr.rs-online.com/web/p/tampons-decart-thermiques/5075605/] Référence SILPAD400AC 
*1xBobine fil résisitif [https://fr.rs-online.com/web/p/cable-industriel-multiconducteur/7496344/]
*1xpaire de chaussure de sécurité (utilisation de nos chaussure)
*1xplaque de caoutchouc antidérapant antivibration [https://www.leroymerlin.fr/v3/p/produits/dalle-antiderapante-noir-gpi-e128988] (achetez, remboursement par la suite)
*1xRouleau de scratch [https://www.leroymerlin.fr/v3/p/produits/ruban-adhesif-mini-ruban-scratch-auto-agrippant-scratch-grip-l-2000-x-l-10-mm-e1400146133] (achetez, remboursement par la suite)

|-
| P17 [[IMA4 2017/2018 P17|Safe Watch]]
|
* Arduino ,
* Bouclier Arduino LCD ,
* Bouclier GPS Arduino ,
* Bouclier GSM Arduino ,
* Plaque d'essai, câbles, 3 boutons ,
* Adafruit FONA 808 Cellular + GPS Breakout [https://eu.mouser.com/ProductDetail/Adafruit/2691?qs=sGAEpiMZZMuC4zZxLL0ZTS5y3%2fvN2YqqC7jd%252b8Ewo0tvrzwH6EzcUw%3d%3d],
* OLED Display de MicroView [https://www.mouser.fr/ProductDetail/SparkFun-Electronics/DEV-12923/?qs=%2fha2pyFaduhq0%2f0L4ziGOlrL8k9CznZ%2fHCwmtADFcmfM%252bNj6xnUOTR2J1R9vVHxC],
* Antenne GPS [https://fr.rs-online.com/web/p/antennes-gps/6534111/] ,
*mini JST 2-pin pour la batterie [https://www.mouser.fr/ProductDetail/Adafruit/261?qs=sGAEpiMZZMsMyYRRhGMFNu1QGkj38%2fjpots4OzXyI0g%3d],
* batterie:1200mAh sized Lithium ion/polymer battery [https://www.mouser.fr/ProductDetail/Adafruit/258?qs=%2fha2pyFadui%252bGfcAGyN46wlBHAaZlEsaG2TnF48kfbRBKCZP7yH6DDXLDCpScZ1uLz%2f7LJyXDtVbPM%252b2aEQ0roW2VWPjGRnj],
* headphone jack : [https://www.mouser.fr/ProductDetail/Adafruit/1699?qs=sGAEpiMZZMsMyYRRhGMFNsUVB%252bwflvtuRD2AT1i4W%2fI%3d],
* Antenne GSM [https://fr.rs-online.com/web/p/antennes-gsm-et-gprs/8968291/] ,
* Arduino micro [https://www.mouser.fr/ProductDetail/Arduino/A000053?qs=sGAEpiMZZMvq007EO%252bXAYZAVvNFL4IMQ],
* microUSB cable ,
* usb programmer [https://www.mouser.fr/ProductDetail/SparkFun/DEV-12924?qs=%2fha2pyFadujajXN5UxBZ39QNIwYchoft2tr4SjuyzPeTBIS0mD6hlArvMlp2O59kyDG2ZmVILu%252bM2KFfVewETA%3d%3d].

|-
| P18 [[IMA4 2017/2018 P18|Mandala électronique]]
|
*TCL5947*3 [http://fr.farnell.com/texas-instruments/tlc5947dap/ic-led-driver-linear-32-tssop/dp/1755259]
*Arduino Atmega328p [http://fr.farnell.com/microchip/atmega328p-aur/mcu-8-bits-atmega-20mhz-tqfp-32/dp/2425124?st=atmega328p]
*LEDs rougesx40 [http://fr.farnell.com/kingbright/kpl-3015ec/led-12mcd-rouge-617nm/dp/2426224]
*LEDs jaunesx70 [http://fr.farnell.com/kingbright/kpl-3015syck/led-350mcd-jaune-590nm/dp/2426230]
*LEDs bleuesx55 [http://fr.farnell.com/kingbright/kpl-3015qbc-d/led-200mcd-bleu-465nm/dp/2426226]
*LEDs orangesx55 [http://fr.farnell.com/kingbright/kpl-3015seck/led-350mcd-orange-601nm/dp/2426227]
*Transistorsx30 [http://fr.farnell.com/on-semiconductor/mmbt3904/transistor-npn-sot-23/dp/9846727]
*Bois [https://www.leroymerlin.fr/v3/p/produits/predecoupe-contreplaque-okoume-exterieur-ep-5-mm-l-80-x-l-60-cm-e1401453577]
*Source alimentationx2 [https://www.gotronic.fr/art-4-accus-nimh-r6-varta-1-2v-2-1ah-19151.htm]
*Coupleur de pilesx2 [https://www.gotronic.fr/art-coupleur-4-piles-lr6-em4p-5709.htm]
*Gouache [https://www.amazon.fr/Mallette-dartiste-bois-35-pi%C3%A8ces/dp/B00GIONTS2/ref=sr_1_2?ie=UTF8&qid=1516056582&sr=8-2&keywords=gouache]
*Stylo [https://www.amazon.fr/Papermate-S0916420-PM-300-Pointe-Moyenne/dp/B005HI33KO/ref=sr_1_3?ie=UTF8&qid=1516201326&sr=8-3&keywords=crayon+dore]
*ZX Distance et Gesture Sensor [https://www.mouser.fr/productdetail/sparkfun/sen-13162?qs=sGAEpiMZZMsEbyLvxciIbARXbzpjz%2fFllERyJO140AQcgPpUTdWOKA==]
|
|-
| P19 [[IMA4 2017/2018 P19|Bijou électronique]]
|
*50xLED CMS orange [http://fr.farnell.com/broadcom-limited/hsmd-c170/led-cms-orange/dp/5790864?MER=bn_para_1TP_LastViewed_1]
*50xLED CMS bleu [http://fr.farnell.com/broadcom-limited/hsmr-c170/led-bleu/dp/8554749]
*50xLED CMS vert [http://fr.farnell.com/broadcom-limited/hsmg-c170/led-verte/dp/5790852]
*50xLED CMS jaune [http://fr.farnell.com/broadcom-limited/hsmy-c170/led-jaune/dp/5790876]
*50xLED CMS rouge [http://fr.farnell.com/broadcom-limited/hsms-c170/led-rouge-he/dp/5790839]
*1xArduino UNO & 1xAtmega328p [http://fr.farnell.com/arduino-org/a000066/arduino-uno-carte-d-eval/dp/2075382]
*1xDS18B20 [http://fr.farnell.com/maxim-integrated-products/ds18b20u-t-r/capteur-de-temperature-0-5deg/dp/2515607]
*1xBreadboard [http://fr.farnell.com/mcm/21-18936/half-size-breadboard-with-300/dp/2799991]
*1xPulsesensor [https://www.mouser.fr/ProductDetail/SparkFun/SEN-11574?qs=%2fha2pyFadui%2fRsn4onUiCn%2f5VOJEA9t%252bK%252brmkRQhmlsCSXQ%252bUAWWwg%3d%3d]
*5xpiles de boutons de 3V [http://fr.farnell.com/varta/6032101501/pile-lithium-bouton/dp/300445]
*1xfil de fer [https://www.gotronic.fr/art-soudure-esp006-50-25658.htm]
*1xruban isolant [https://www.gotronic.fr/art-ruban-isolant-temflex-7682.htm]
*50xrésistances 68ohm [https://fr.rs-online.com/web/p/resistances-traversantes/1650741/]
*1xrésistances 8.2 Mohm [https://fr.rs-online.com/web/p/resistances-traversantes/6834102/]
*50xrésistances 56ohm [https://fr.rs-online.com/web/p/resistances-traversantes/1650735/]
*1xinterrupteur bascule [https://www.mouser.fr/ProductDetail/NKK-Switches/B12JJVC?qs=sGAEpiMZZMumOpTNq3bZXvRXehMYP%252byokBQhv3MozMw%3d]
*1xtoile [https://www.amazon.fr/Zedtom-Rouleau-D%C3%A9coration-Artisanat-Bricolage/dp/B01KJXOLZM/ref=sr_1_3?s=hi&ie=UTF8&qid=1516198372&sr=1-3&keywords=toile]
|-
| P20 [[IMA4 2017/2018 P20|Solution de messagerie à base de conteneurs]]
|
* 1 Raspberry Pi
|-
| P22 [[IMA4 2017/2018 P22|Horloge numérique DCF77, serveur de temps et ludique]]
|
* Pack de batterie NiMh 510mAh [http://fr.farnell.com/varta/55750404014/pack-de-batterie-nimh-510mah-4/dp/1903286]
* Contrôleur de batterie [https://fr.rs-online.com/web/p/controleurs-de-charge-de-batterie/5456852/] 
|-
| P23 [[IMA4 2017/2018 P23|Table de bar connectée]]
|
* Regulateur 5V->3.3V 800mA [http://fr.farnell.com/stmicroelectronics/ld1117v33/regulateur-ldo-3-3v-1117-to-220/dp/9755837?CMP=KNC-GFR-FFR-GEN-KWL-G50-STMICROELECTRONICS&mckv=s2ZjbOaj_dc|pcrid|79679603942|&gclid=EAIaIQobChMIhe6d84CU2QIVShbTCh2pTggwEAAYAyAAEgKdUvD_BwE] ,
* 4 * Modules Xbee [http://fr.farnell.com/digi-international/xb24-awi-001/module-zigbee-xbee-1mw-antenne/dp/1337912] ,
* 2 * Capteur de temperature [https://www.mouser.fr/ProductDetail/Analog-Devices/AD22103KTZ?qs=sGAEpiMZZMucenltShoSnoiUfjKGVRv2VdPSgYmyZyM%3d] ,
* 2 * Photoresistance [https://www.gotronic.fr/art-photoresistance-ldr04-2150.htm] ,
* 3 * Microcontroleurs Atmega328P [https://fr.rs-online.com/web/p/microcontroleurs/9214545/] ,
* 3 * Régulateur 9V->5V, 100mA [http://fr.farnell.com/texas-instruments/lm78l05acz-nopb/regulateur-lineaire-5-2v/dp/1469108],
* X * Piles 9V [https://fr.rs-online.com/web/p/piles-9-volts/7951545/] ,
* 3 * Quartz 16M [http://fr.farnell.com/raltron/as-16-000-18/quartz-16mhz-18pf-hc-49s/dp/1611761?MER=bn_para_1TP_LastViewed_3] ,
* 6 * Condensateur 18pF [http://fr.farnell.com/vishay/k180j15c0gf5tl2/ceramic-capacitor-18pf-50v-c0g/dp/4986210] ,
* 1 * Panneau LED[https://www.gotronic.fr/art-panneau-a-leds-rgb-64x32-dfr0460-26065.htm],
* ATMEGA16u2-AU ,
* Connectique USB A male à souder,
* Planche à Pain,
* Autres composants electroniques...
* <del>2</del> 3 Modules Xbee S1,
* <del>2</del> 3 Shield Arduino pou Xbee,
* <del>2</del> 3 Cable USB A - USB mini,
* 1 Xbee - Usb Adaptateur (pour le parametrage),
* 1 Led Rouge + Resistance 330Ohm,
* 3 Resistance 10K Ohm ,
* Planche à pain ,
* 3 Boutons .
|-
| P25 [[IMA4 2017/2018 P25|Essaim de robots]]
|
* 2 x Microcontrôleur Atmega [https://www.mouser.fr/ProductDetail/Microchip-Technology-Atmel/ATMEGA328P-MU?qs=sGAEpiMZZMvqv2n3s2xjscfa4zIkTHJIR0ZBr3z9ETo%3d] ,
* 22 x Condensateur 100nF [http://fr.farnell.com/kemet/c0201c104k9pactu/condensateur-mlcc-x5r-100nf-6/dp/1907036?st=Condensateur%20100nF] ,
* 4 x Condensateur 10uF [http://fr.farnell.com/wurth-elektronik/885012106006/condesateur-mlcc-x5r-10uf-6-3v/dp/2495147] ,
* 4 x Condensateur 22pF [http://www.mouser.fr/ProductDetail/AVX/06036A220KAT2A/?qs=sGAEpiMZZMs0AnBnWHyRQKdiqyDPVQdATEC6RfUr2zQ%3d] ,
* 2 x Rectifier Diode [http://www.mouser.fr/ProductDetail/Vishay-Semiconductors/GL34G-E3-83/?qs=sGAEpiMZZMutXGli8Ay4kH9ZXA1Qtv9UOwbhSBXDb18%3d] ,
* 4 x Servo moteur [https://www.gotronic.fr/art-servomoteur-fs90r-25838.htm] ,
* 6 x LED Infrarouge [http://fr.farnell.com/optek-technology/op290a/led-t-1-3-4/dp/1497872] ,
* 6 x Récepteur Infrarouge [http://www.mouser.fr/ProductDetail/Vishay-Semiconductors/TSOP38238/?qs=sGAEpiMZZMvAL21a%2fDhxMtgKho2n4%2fgBkajAZHPY5lE%3d] ,
* 2 x Quartz [http://www.mouser.fr/ProductDetail/ECS/ECS-160-20-3X-TR/?qs=sGAEpiMZZMvAbnEMxb34PZ9bYWrwSXiB] ,
* 2 x Switch [http://www.mouser.fr/ProductDetail/ALPS/SKQGADE010/?qs=sGAEpiMZZMsqIr59i2oRcrO5GDYRXDIX6cdtN26xmPE%3d] ,
* 2 x USB Chip [http://www.mouser.fr/ProductDetail/FTDI/FT232RL-REEL/?qs=sGAEpiMZZMs5ceO8zL%252bTxyQLQIH6hE7q] ,
* 2 x USB-C Connector [https://www.mouser.fr/ProductDetail/Molex/105450-0101?qs=sGAEpiMZZMulM8LPOQ%252byk43rDx%252b4l5FzJ4YNghWv4pnX6X7mot%2f43w%3d%3d] ,
* 2 x Batteries 9V [http://www.mouser.fr/ProductDetail/Panasonic-Battery/6LF22XWA-B12/?qs=sGAEpiMZZMsra%2fh506hF%252bITISQoCasqh1k2eJLis9sg%3d] ,
* 2 x Régulateur 5v [https://www.mouser.fr/ProductDetail/Texas-Instruments/LM1117IMPX-50-NOPB/?qs=X1J7HmVL2ZGGwLlD0uGqKQ%3D%3D] ,
* 2 x Roue de balance [https://fr.rs-online.com/web/p/billes-porteuses/0687770/] ,
* 2 x Emetteur/Récepteur Ultrason 40kHz [https://www.robotshop.com/ca/fr/module-sonar-hc-sr04-ultra01.html] .
|
|-
| P30 [[IMA4 2017/2018 P30|Contrôle d'une caméra WiFi.]]
|
Sont fournis par Ürbik :
* 2 x Cartes Micro-SD 
*2 x Support Micro-SD vers SD 
*1 * Banana Pi Pro 
*1 * Antenne Wifi pour Banana Pi Pro 
*1 * Module RTC compatible Banana Pro 
*1 * Shield de dévloppement GPIO Banana Pro
*1 * Bloc d'alimentation 230v~5v micro USB 
*1 * Banana Pi D1
*1 * Adaptateur ethernet USB type A
*1 * Cable MicroUSB mâle vers USB type A femelle
*1 * Cable USB type A mâle vers Micro USB mâle et USB type A femelle
Sont demandés à Polytech :
* 2 x Servomoteurs 
* 2 x Câbles ethernet 
* 1 x BananaPi D1 en remplacement [https://e.banana-pi.fr/cameras-banana-pi/35-bpi-d1-camera-ip.html] 
|-
| P32 [[IMA4 2017/2018 P32|Tribute to Peter Vogel]]
|
* 15 x Photorésistances LDR04 [https://www.gotronic.fr/art-photoresistance-ldr04-2150.htm#complte_desc]
* 20 x Amplificateur opérationnel LM358N [https://fr.rs-online.com/web/p/amplificateurs-operationnels/8431578]
* 15 x Résistances 68Kohm [https://fr.rs-online.com/web/p/resistances-traversantes/0386048]
* 15 x Résistances 4,7Kohm [https://fr.rs-online.com/web/p/resistances-traversantes/7077726]
* 25 x Résistances 1Kohm [https://fr.rs-online.com/web/p/resistances-traversantes/2671777]
* 25 x Transistors NPN 2N3904 [https://fr.rs-online.com/web/p/transistors-bipolaires/7390442]
* 12 x Potentiomètres linéaires 100k [https://fr.rs-online.com/web/p/potentiometres/2633006/]
* 10 x Potentiomètres linéaires 10k [https://www.mouser.fr/productdetail/welwyn-components-tt-electronics/p160kn-0qc17b10k?qs=sGAEpiMZZMtC25l1F4XBU1WvpdUcjC%2F6L3FhnOV516EmtF%252b%252b7aZUUw%3D%3D]
* 10 x Condensateurs 10µF [https://www.gotronic.fr/art-condensateur-radial-10uf-50v-3360.htm]
* 10 x Résistances 100Kohm [https://www.gotronic.fr/art-10-resistances-1-4w-100k-8486-20.htm]
* 70 x Leds rouges [https://www.gotronic.fr/art-leds-rouges-led5rl-356.htm]
* 1 x Condensateur 100nF [https://www.gotronic.fr/art-condensateur-ceramique-100-nf-3215.htm]
* 2 x Petits moteurs [https://www.gotronic.fr/art-moteur-miniature-sr30-787.htm]
* 1 x Atmega 328p [https://www.gotronic.fr/art-atmega328p-pu-16820.htm]
* 1 x Led verte [https://www.gotronic.fr/art-leds-vertes-led3gl-2057.htm]
* 1 x Résistance 330ohms 1/6th Watt Pth[https://eu.mouser.com/ProductDetail/SparkFun/COM-08377/?qs=sGAEpiMZZMuM1nRwI3zz2UpCr55iWBr5d51zFU1jOr2Myatejq0Ujw==]
* 1 x bouton poussoir [https://www.gotronic.fr/art-bp-subminiature-krs32n-4271.htm?qs=sGAEpiMZZMs%2FSh%2Fkjph1tvt1%2FmEPT%2FXoz55nayTMEJw%3D]
* 2 x Condensateurs découplages 10µF [https://www.gotronic.fr/art-condensateur-faible-esr-10uf-50v-11308.htm]
* 2 x Condensateurs céramiques 22pF [https://www.gotronic.fr/art-condensateur-ceramique-22-pf-3178.htm]
* 1 x Régulateur de tension [https://www.gotronic.fr/art-l7805cv-1578.htm]
* 1 x Cristal 16Mhz [https://www.gotronic.fr/art-quartz-16-000-mhz-55.htm]
* 3 x Female headers [https://www.mouser.fr/productdetail/harwin/m50-3030842?qs=sGAEpiMZZMve4%2FbfQkoj%252bNAvEyry7AuOrgimgco8uSU%3D]
* 2 x Haut-parleur 2W [https://www.mouser.fr/ProductDetail/CUI/CDS-27208?qs=sGAEpiMZZMuTkJYgZlQcSew3leo0OO6IWAIjM88CpYEXXyeONvvJNg==]
|-
| P35 [[IMA4 2017/2018 P35|Manette de jeu vidéo pour personne en situation de handicap]]
|
* 3 x Push buttons [https://www.gotronic.fr/art-bp-miniature-krs1273-16976.htm] ,
* 2 x Thumbstick (joystick analogique 4 directions) [https://www.gotronic.fr/art-joystick-analogique-4-directions-19063.htm] ,
* 1 x Led RGB [https://www.gotronic.fr/art-led-rgb-5-mm-led5rvb-2103.htm],
* 1 x Raspberry Pi 3 + son câble + carte SD+ alim [https://fr.rs-online.com/web/p/processor-microcontroller-development-kits/8968660/?src=raspberrypi],
* 3 x Arduino UNO ,
* 5 x Alimentation 3V: 10*piles AAA 1,2V rechargeables [https://www.mouser.fr/ProductDetail/Panasonic-Battery/HHR-60AAAHB2?qs=sGAEpiMZZMuXcNZ31nzYhUR9TS3h0B6UyKPniAa4akA%3d],
* 5 x modules bluetooth Nordi nrf nRF52810-QFAA-R [https://www.mouser.fr/productdetail/nordic-semiconductor/nrf52810-qfaa-r?qs=sGAEpiMZZMve4%2FbfQkoj%252bG%2FosjLoe2oghFQwQllMrQ4%3D] ,
* 1 x barette connecteur mâle traversant [https://www.gotronic.fr/art-connecteur-he14-mh200-4459.htm] ,
* 1 x barette connecteur femelle traversant [https://fr.rs-online.com/web/p/barrettes-pour-ci/2677416/] ,
* 1 x breadboard .
* 1 x Raspberry pi zero .
*5 * microcontroleur Atmega328P-PU .
*10 * capacitors 22pF [https://fr.rs-online.com/web/p/condensateurs-ceramique-simple-couche/7215101/] .
*1* bouton poussoir (RESET) .
*5* résistances 10 kOhms .
*5* oscillateur quartz 16Mhz [https://fr.rs-online.com/web/p/quartz/5476294/] .
|-
| P39 [[IMA4 2017/2018 P39|Musique des plantes]]
|
* 1 x Plante ,
* 1 x Cordon pour électrodes [https://www.mouser.fr/ProductDetail/SparkFun-Electronics/CAB-12970/?qs=%2fha2pyFaduj1O95kixslzNrly0UKgNYdQ2TazqXF05PpguJVsXXh3Q%3d%3d],
* 1 x Electrodes [https://www.gotronic.fr/art-pads-a-electrodes-sen-12969-26244.htm],
* 2 x (précédemment 1) Amplificateur d'instrumentation INA125[http://fr.farnell.com/texas-instruments/ina125p/amp-inst-precision-pdip16-125/dp/1459461],
* 1 x Amplificateur d'instrumentation OPA320[http://fr.farnell.com/texas-instruments/opa320aidbvr/ampli-op-20mhz-10v-us-sot-23-5/dp/2542658?st=OPA320],
* 1 x Amplificateur d'instrumentation OPA2320[http://fr.farnell.com/texas-instruments/opa2320aidgkt/op-amp-gp-r-r-cmos-20mhz-8msop/dp/1864818?st=OPA2320],
* 1 x Amplificateur d'instrumentation INA132 [http://fr.farnell.com/texas-instruments/ina132ua-2k5/ampli-diff-300khz-0-1v-us-soic/dp/2782755RL?st=INA132],
* 1 x Arduino Mega [https://fr.rs-online.com/web/p/kits-de-developpement-pour-processeurs-et-microcontroleurs/7154084/],
* 1 x module bluetooth [https://www.gotronic.fr/art-module-bluetooth-hc05-ef03079-05-25579.htm#complte_desc],
* 1 x Cable d'alimentation [https://www.gotronic.fr/art-cordon-alimentation-pile-9v-19414.htm],
* 1 x Batterie [http://fr.farnell.com/duracell/accu-9v1/accumulateur-9v-pq1/dp/4140308],
* 2 x Connecteur Jack [https://fr.rs-online.com/web/p/connecteurs-jack-trs/5051485/],
* 1 x Connecteur MIDI [https://fr.rs-online.com/web/p/connecteurs-din/0491087/],
* 1 x AOP LM324 [http://fr.farnell.com/texas-instruments/lm324n/ic-op-amp-quadruple/dp/1564884?st=LM324N],
* 3 x Interrupteurs [http://fr.farnell.com/multicomp/1ms1t1b5m1qe/interrupteur-spdt/dp/9473378?st=commutateur%20%C3%A0%20levier%20on%20on],
* 1 x Potentiomètre [https://www.gotronic.fr/art-ajustable-vertical-2-2k-8486-11159.htm#complte_desc],
* 2 x LED RGB [https://www.gotronic.fr/art-led-rgb-5-mm-led5rvb-2103.htm],
* 1 x Haut-Parleur [http://fr.farnell.com/kingstate/kdmg28008/loudspeaker-micro/dp/1502732?MER=bn_level5_5NP_EngagementRecSingleItem_3],
* 1 x CAN [http://fr.farnell.com/microchip/mcp2551-i-sn/hi-speed-transceiver-can-2551/dp/9758569],
* 1 x CAN [http://fr.farnell.com/microchip/mcp2551-e-sn/ic-transceiver-can-smd-8soic/dp/1467746],
* 1 x Headers 2*23 [https://www.mouser.fr/ProductDetail/SparkFun/PRT-12790?qs=sGAEpiMZZMuWWq7rhECaKTxAh05%2fvU1hSqT3VTr1yQo%3d],
* 5 x Headers 1*8 [https://www.mouser.fr/ProductDetail/SparkFun/PRT-09279?qs=sGAEpiMZZMuWWq7rhECaKVf6TnXuSdhbVm54%252ba39HDI%3d],
* 1 x Headers 1*10 [https://www.mouser.fr/ProductDetail/SparkFun/PRT-11376?qs=sGAEpiMZZMuWWq7rhECaKW7JSoPFJbh65nnJcQqXBPM%3d],
|-
| P40 [[IMA4 2017/2018 P40|Exploration du réseau d'anonymisation Tor]]
|
*Réseau d'ordinateurs de l'école, implantés avec des VM,
*Un commutateur,
*La ligne SDSL,
*Et un marteau :).
|-
| P42 [[IMA4 2017/2018 P42|Automatisation de l'assemblage de LEGO]]
|
*1 x Arduino Mega
*1 x ESP8266
*1 x Raspberry Pi 3
*1 x imprimante 3D
*1 x plaque de polystyrène
*1 x plaque de plexiglas (3mm)
*1 x plaque Lego [https://shop.lego.com/fr-FR/La-plaque-de-base-verte-10700]
*15 x brique 1x1 noir [https://www.briquestore.fr/1x1/1233-lego-302426-plate-1x1-noir.html]
*15 x brique 1x1 blanc [https://www.briquestore.fr/1x1/1236-lego-302401-plate-1x1-blanc.html]
*15 x brique 1x1 bleu [https://www.briquestore.fr/1x1/1238-lego-302423-plate-1x1-bleu.html]
*15 x brique 1x1 rouge [https://www.briquestore.fr/1x1/1237-lego-302421-plate-1x1-rouge.html]
*15 x brique 1x1 jaune [https://www.briquestore.fr/1x1/1239-lego-302424-plate-1x1-jaune.html]
*15 x brique 1x1 vert [https://www.briquestore.fr/1x1/1241-lego-302428-plate-1x1-dark-green.html]
|
|-
| P44 [[IMA4 2017/2018 P44|Reconnaissance d’objets via Traitement d’Image]]
|
|-
| P49 [[IMA4 2017/2018 P49|Suivi de la qualité de l’air]]
|
Matériel fournit par l'INRIA :
* 1 x Raspberry Pi 3
* 1 x Arduino Méga
* 1 x détecteur de mouvement PIR (HC-SR01)
* 1 x détecteur de bruit
* 1 x capteur de température et d'humidité (DHT22)
* 1 x capteur de pression
* 1 x capteur de luminosité
* 1 x capteur de Composé Organique Volatil COV 
* 4 x capteurs de monoxyde de carbone CO (Alphasense) 
* 2 x capteurs de dioxyde de carbone CO2
* 1 x E/R XBee
* 1 x clavier alphanumérique usb
|-
| P50 [[IMA4 2017/2018 P50|Etage commande de Centaure]]
|
Matériels existants:
*2 x Batteries 12V 22Ah (dont une hs)
*1 x Chargeur de batterie 12V 
*1 x Contacteur 24Vcc 18A ref: TeSys LC1D18BD 
*2 x Variateurs de vitesse ref: Alpes Ital 8CH2QM.2
*1 x Arduino MEGA ADK avec son bouclier de capteurs 
*1 x Carte keyes funduino à 4 relais
*1 x DC/DC convertisseur 24V => 12V & 5V ref: Tracopower TEN 40-4811 
*1 x Porte fusibles à 5 ports 
Matériels manquants:
* 1* Batterie 12V 55Ah; trouvée chez le fournisseur mouser.fr [https://www.mouser.fr/productdetail/power-sonic/ps-12550?qs=sGAEpiMZZMso%252bSMtTqBO32B9ZZCkCjmed3agP8D7TIo%3D]
* 1* Chargeur 24V; chez le même fournisseur [https://www.mouser.fr/productdetail/ault-sl-power/bvl240600003n?qs=sGAEpiMZZMsYfYypWaYaEeWCnBdw823Sg9r4NP%2FMM%252bU%3D] 
|-
| P60 [[IMA4 2017/2018 P60|Commande de niveaux d’eau]]
|
|-
| P64 [[IMA4 2017/2018 P64|Simulation Labview et mise en réseau Modbus d’un ascenseur]]
|
|-
| P65 [[IMA4 2017/2018 P65|Exosquelette pour apprentissage]]
|
*1 x Motoréducteur MFA 919D1001 [https://www.gotronic.fr/art-motoreducteur-mfa-919d1001-11742.htm]
*1 x Amplificateur de courant mesurée MAX4378 [https://www.mouser.fr/ProductDetail/Maxim-Integrated/MAX4378FAUD%2b?qs=sGAEpiMZZMvEn2pkGav3bMGiddAnKBJhMUlghJlr6fA%3d]
|-
| P66 [[IMA4 2017/2018 P66|Coupe de France de robotique]]
|
Fourni par Robotech :
*1 × Batterie Lipo 4S
*1 × Carte de puissance
*1 × Support mécanique & Roues
*2 × Faulhaber MOTOR 3557K024CS
*1 × Contrôleur moteur
*2 × HEDM-550X
*1 × Capteur MinIMU-9 v3
*X × Capteurs ultrasons / infrarouges
*1 × MicroNova Mercury FPGA Development Board
*1 × Arduino MEGA 2560
*1 × Raspberry Pi 3
*1 × Écran LCD SPI
*X × Boutons
|-
| P67 [[IMA4 2017/2018 P67|Scanner 3D DIY]]
|
*2x Moteur NEMA 17
*2x contrôleur moteur
*bouton poussoir de fin de parcours de courroie
*courroie et engrenage pour Nema 17
*Alim 12V
*bobine de PLA pour impression 3D (dispo au Fabricarium)
*Carte arduino Méga
*Caméra Kinect pour 360 ou Kinect microsoft
*Câble / résistances / capa
*module de sauvegarde pour carte SD ou carte micro SD (j'en possède déjà un)
*capteur de mesure de distance [http://fr.farnell.com/sharp/gp2y0a21yk0f/capteur-de-distance/dp/1243869]
*bois
|-
| P68 [[IMA4 2017/2018 P68|Générateur de chronogrammes d'ordonnancement]]
|
|-
| PP1 [[IMA4 2017/2018 Pré-projet 1|Robot hexapode pour escalier]]
|
* Arduino Mega / câble
* 12 servos moteurs SG90 
* une structure robot 4 pattes 
* Plaque d'essai, câbles 
|-
|}

Projets IMA4 SC & SA 2017/2018

2018-02-07T18:05:36Z

Tgracias : /* Matériel à acquérir */

Merci de référencer vos pages de projets ici. Merci aussi d'uniformiser vos formats que ce soit en regardant la présentation des projets déjà créés ou en demandant une modification du format des précédents si votre façon de faire vous semble la meilleure. Dans tous les cas un minimum de communication entre les binômes est conseillée.

Toutes les sources doivent être déposées sur notre archive GIT. Le service est disponible à l'URL [https://archives.plil.fr archives.plil.fr]. Connectez-vous avec vos identifiants Polytech'Lille. Sauf indication contraire de vos encadrants, rendez le projet public et mettez le lien sur votre Wiki. Vous pouvez trouver de la documentation sur ce système d'archives sur ce [https://git-scm.com/book/fr/v1 site].

== Répartition des binômes ==

{| class="wikitable"
! Projet !! Encadrants école !! Elèves
|-
| P0 [[IMA4 2017/2018 P0|Modèle]]
|
|
|-
| P1 [[IMA4 2017/2018 P1|Automatisation de la production de bière]]
| Rémy Bernard / Alexandre Boé / Thomas Vantroys
| Henri Carlier / Quentin Boëns
|-
| P3 [[IMA4 2017/2018 P3|Sécurisation de l'Internet des Objets par surveillance globale]]
| Alexandre Boé / Xavier Redon / Thomas Vantroys
| Ji Yang
|-
| P4 [[IMA4 2017/2018 P4|Développement d'un module d'énergie pour Internet des Objets]]
| Alexandre Boé / Xavier Redon / Thomas Vantroys
| Abass Ayoub / Alexis Viscogliosi
|-
| P5 [[IMA4 2017/2018 P5|Réseau de capteurs de pollution]]
| Thomas Vantroys / Alexandre Boé / Xavier Redon
| Paul Ribeiro / Naif Mehanna
|-
| P6 [[IMA4 2017/2018 P6|Réseau LoRaWAN]]
| Alexandre Boé / Xavier Redon / Thomas Vantroys
| Antoine Gosse
|-
| P7 [[IMA4 2017/2018 P7|Brique pour apprentissage informatique]]
| Alexandre Boé / Emmanuelle Pichonnat / Thomas Vantroys
| Maéva Delaporte / Simon Blas
|-
| P10 [[IMA4 2017/2018 P10|Portage de RIOT-OS sur MSP430 pour IOT]]
| Thomas Vantroys / Alexandre Boé / Xavier Redon
| Baptiste Cartier
|-
| P12 [[IMA4 2017/2018 P12|Système d'ostéophonie pour magicien]]
| Alexandre Boé / Xavier Redon / Thomas Vantroys
| Amine El Messaoudi / Simon Feutrier
|-
| P14 [[IMA4 2017/2018 P14|Ecran géant modulaire]]
| Alexandre Boé / Xavier Redon / Thomas Vantroys
| Jade Dupont
|-
| P15 [[IMA4 2017/2018 P15|Balle vibrante connectée pour enfants sourd]]
| Rodolphe Astori / Alexandre Boé / Thomas Vantroys
| Thibault Cattelain / Thomas Cunin
|-
| P16 [[IMA4 2017/2018 P16|Sous-chaussure chauffante pour docker]]
| Remy Bernard / Alexandre Boé / Thomas Vantroys
| Rémi Mairesse / Gustave Roux
|-
| P17 [[IMA4 2017/2018 P17|Safe Watch]]
| Xavier Redon
| Oumaima Naanaa
|-
| P18 [[IMA4 2017/2018 P18|Mandala électronique]]
| Xavier Redon / Alexandre Boé
| Lirui Zhang / Lihe Zhang
|-
| P19 [[IMA4 2017/2018 P19|Bijou électronique]]
| Xavier Redon / Alexandre Boé
| Keren Qiang / Lijie Yao
|-
| P20 [[IMA4 2017/2018 P20|Solution de messagerie à base de conteneurs]]
| Xavier Redon / Thomas Vantroys
| Maxime Creteur / Fan Gao
|-
| P22 [[IMA4 2017/2018 P22|Horloge numérique DCF77, serveur de temps et ludique]]
| Xavier Redon / Alexandre Boé / Thomas Vantroys
| Amaury Knockaert / Fabrice Taingland
|-
| P23 [[IMA4 2017/2018 P23|Table de bar connectée]]
| Thomas Vantroys / Alexandre Boé
| Matthieu Delobelle
|-
| P25 [[IMA4 2017/2018 P25|Essaim de robots]]
| Xavier Redon / Alexandre Boé
| Ganix Etcheguibel / Benjamin Canu
|-
| P30 [[IMA4 2017/2018 P30|Contrôle d'une caméra WiFi.]]
| Nathan Martin / Xavier Redon
| Thomas Hubert / Taky Djeraba
|-
| P32 [[IMA4 2017/2018 P32|Tribute to Peter Vogel]]
| Thomas Vantroys / Alexandre Boé / Xavier Redon
| Antoine Untereiner / Jean-Baptiste Watine
|-
| P35 [[IMA4 2017/2018 P35|Manette de jeu vidéo pour personne en situation de handicap]]
| Alexandre Boé / Xavier Redon / Thomas Vantroys
| Camille Saad / Transley Gracias
|-
| P39 [[IMA4 2017/2018 P39|Musique des plantes]]
| Emmanuelle Pichonat / Alexandre Boé
| Rodolphe Toin / Xavier Chenot
|-
| P40 [[IMA4 2017/2018 P40|Exploration du réseau d'anonymisation Tor]]
| Xavier Redon / Thomas Vantroys
| Anthony Durot / Antoine Duquenoy
|-
| P42 [[IMA4 2017/2018 P42|Automatisation de l'assemblage de LEGO]]
| Xavier Redon / Alexandre Boé / Thomas Vantroys
| Justine Senellart / Eloi Zalczer
|-
| P44 [[IMA4 2017/2018 P44|Reconnaissance d’objets via Traitement d’Image]]
| Thomas Danel / Vincent Coelen
| Zoé Briois / Damien Narbais
|-
| P49 [[IMA4 2017/2018 P49|Suivi de la qualité de l’air]]
| Romain Rouvoy / Rédha Kassi
| Nicolas Havard / Hugo Delbroucq
|-
| P50 [[IMA4 2017/2018 P50|Etage commande de Centaure]]
| Xavier Redon / Alexandre Boé / Thomas Vantroys
| Haroun Abdelali
|-
| P60 [[IMA4 2017/2018 P60|Commande de niveaux d’eau]]
| Midzodzi Pekpe
| Claire Vandamme / Alexendra Villa
|-
| P64 [[IMA4 2017/2018 P64|Simulation Labview et mise en réseau Modbus d’un ascenseur]]
| Midzodzi Pekpe / Blaise Conrard
| François-Xavier Cockenpot
|-
| P65 [[IMA4 2017/2018 P65|Exosquelette pour apprentissage]]
| Alexandre Boé / Xavier Redon / Thomas Vantroys
| Florian Le Foll
|-
| P66 [[IMA4 2017/2018 P66|Coupe de France de robotique]]
| Alexandre Boé / Xavier Redon / Thomas Vantroys
| Geoffrey Preud'homme / Amaury Carval
|-
| P67 [[IMA4 2017/2018 P67|Scanner 3D DIY]]
| Xavier Redon / Alexandre Boé / Thomas Vantroys
| Erwan Dufresne
|-
| P68 [[IMA4 2017/2018 P68|Générateur de chronogrammes d'ordonnancement]]
| Xavier Redon / Thomas Vantroys
| Samy Belhouachi
|-
| PP1 [[IMA4 2017/2018 Pré-projet 1|Robot hexapode pour escalier]]
| Alexandre Boé / Xavier Redon / Thomas Vantroys
| Eduardo Gomez-Riaza
|}

== Matériel à acquérir ==

{| class="wikitable"
! Projet !! Matériel
|-
| P1 [[IMA4 2017/2018 P1|Automatisation de la production de bière]]
|
*Capteur de température DS18B20 [https://www.gotronic.fr/art-sonde-etanche-ds18b20-19339.htm]
*Raccord tuyau en Y [https://fr.rs-online.com/web/p/coupleurs-de-tuyaux-flexibles/4197259/] 
*2 Pompes péristaltique dc 12V [https://www.mouser.fr/ProductDetail/Adafruit/1150?qs=sGAEpiMZZMsMyYRRhGMFNp8jyMJFi5X9NqTp2aghyow%3d]
*Tube en silicone [https://fr.rs-online.com/web/p/tubes-flexibles/9124751/]
*Tube en cuivre [https://fr.rs-online.com/web/p/tubes-en-cuivre/0846503/]
*2 résistances 1kOhms
*2 transistors bc547
*2 diodes
*14 cables M/M
*Alimentation DC 12V 

|-
| P3 [[IMA4 2017/2018 P3|Sécurisation de l'Internet des Objets par surveillance globale]]
|
*Xbee USB Adapter * 1 [https://www.amazon.fr/dp/B017KGBP6Y/ref=asc_df_B017KGBP6Y48622783/?tag=googshopfr-21&creative=22722&creativeASIN=B017KGBP6Y&linkCode=df0&hvdev=c&hvnetw=g&hvqmt=]
*XDigiKey Xbee module 2.4Hz * 4 [https://www.digikey.com/catalog/en/partgroup/xbee-and-xbee-pro-zb-zigbee/12201] ReX : imprécis, cherchez chez gotronic
*l'antenne pour Xbee * 4 [https://www.matlog.fr/fr/61-antennes-24-ghz.html]
*Arduino uno * 4 [https://store.arduino.cc/usa/arduino-uno-rev3]
*Xbee Shields pour Arduino * 4 [https://store.arduino.cc/arduino-wirelss-sd-shield]
*Câble USB pour Arduino * 4 [https://fr.aliexpress.com/item/usb-cable-for-arduino-with-UNO-R3-ATMEGA328P-PU-ATMEGA8U2-and-Mega-2560-R3-Mega2560-REV3/32624000858.html?src=google&albslr=221466033&isdl=y&aff_short_key=UneMJZVf&source=%7Bifdyn:dyn%7D%7Bifpla:pla%7D%7Bifdbm:DBM&albch=DID%7D&src=google&albch=shopping&acnt=494-037-6276&isdl=y&albcp=653151748&albag=36672819047&slnk=&trgt=61865531738&plac=&crea=fr32624000858&netw=g&device=c&mtctp=&gclid=Cj0KCQiAv_HSBRCkARIsAGaSsrC92WYZ2oroveXJLqUQCBfRBuRMa8VoShOZWNBitPIvrry8V1HpMmkaAg-QEALw_wcB] 
*Batterie externe(qui a 2 ports à recharger) * 4 [https://www.amazon.fr/EC-Technology-22400mAh-Batterie-capacit%C3%A9/dp/B00F5Q4F0U/ref=sr_1_1_sspa?ie=UTF8&qid=1513804729&sr=8-1-spons&keywords=batteries+externe&psc=1]
*USB À UART TTL Câble * 1 [https://fr.aliexpress.com/item/USB-To-RS232-TTL-USB-To-COM-Serial-Adapter-Cable-Module-PL2303HX-Converter/1859099599.html?src=google&albslr=201492522&isdl=y&aff_short_key=UneMJZVf&source=%7Bifdyn:dyn%7D%7Bifpla:pla%7D%7Bifdbm:DBM&albch=DID%7D&src=google&albch=shopping&acnt=494-037-6276&isdl=y&albcp=653151748&albag=36672819047&slnk=&trgt=61865531738&plac=&crea=fr1859099599&netw=g&device=c&mtctp=&gclid=CjwKCAiAsejRBRB3EiwAZft7sENdHUiXBHo-JhKGxsmwfnaRATNn_OPdCl9y-WVMwi8elX5S6QCMnhoCNm8QAvD_BwE]
*Breadboard de prototypage * 3 [https://www.amazon.fr/Breadboard-Carte-dexp%C3%A9rimentation-Soudure-Solderless/dp/B06XWFG9DT/ref=sr_1_2_sspa?ie=UTF8&qid=1516049551&sr=8-2-spons&keywords=breadboard+arduino&psc=1]
*USB câble pour xbee USB Adapter [https://www.amazon.fr/dp/B003OSS4SA/ref=asc_df_B003OSS4SA49349077/?tag=googshopfr-21&creative=22698&creativeASIN=B003OSS4SA&linkCode=df0&hvdev=c&hvnetw=g&hvqmt=]
|-
| P4 [[IMA4 2017/2018 P4|Développement d'un module d'énergie pour Internet des Objets]]
|
* 1xModule solaire [[https://www.mouser.fr/ProductDetail/MikroElektronika/MIKROE-651?qs=sGAEpiMZZMvxW%252bY8mn0Q9U%252b%2fhOkIvSmCqkyN6XrqZsI%3d]]
* 1xBatterie [[http://fr.farnell.com/varta/55608303059/batterie-nimh-3-6v/dp/279341]]
* 1xConvertisseur Boost [[https://fr.rs-online.com/web/p/convertisseurs-boost/8123659/]]
* 2xDiode de Schottky de redressement [[https://fr.rs-online.com/web/p/diodes-de-redressement-et-schottky/7390436/]]
* 1xConvertisseur Buck-Boost (sortie) [[https://fr.rs-online.com/web/p/regulateurs-a-decoupage-buck-boost/6989091/]]
* 2xSupercondensateur 2,7V - 50F [[https://www.mouser.fr/ProductDetail/Maxwell-Technologies/BCAP0050-P270-T01/?qs=sGAEpiMZZMsCu9HefNWqpt2sk1W1BTZ59akVpHhf5KE=]]
* 10 jumpers [[https://fr.rs-online.com/web/p/cavaliers-et-shunts/6742397/]]
* Module MPPT [[https://www.mouser.fr/ProductDetail/STMicroelectronics/SPV1050TTR?qs=sGAEpiMZZMsMLZWdhVL71%2fkXzzgq0Ptzmbr9rWlHkic%3d]]
* 20 pin connection mâle [[https://fr.rs-online.com/web/p/barrettes-pour-ci/8967620/]]

|-
| P5 [[IMA4 2017/2018 P5|Réseau de capteurs de pollution]]
|
* ESP32 [[https://www.gotronic.fr/art-carte-esp32-dev-13907-25510.htm]]
* Module GPS [[https://www.gotronic.fr/art-module-gps-tel0094-25732.htm]]
* Batterie Lithium Ion [[https://fr.rs-online.com/web/p/batteries-externes/8755758/]] ou [[https://fr.rs-online.com/web/p/batteries-externes/1366470/]] suivant le prix
* Adaptateur micro USB
* Breadboard
* Un smartphone sous Android (Version Lollipop minimale - optionnel)
* HPMA115S0-XXX (Capteur déjà acheté normalement)
* 2 connecteurs micro-USB [[https://www.gotronic.fr/art-embase-micro-usb-b-cms-18339.htm]]
|-
| P6 [[IMA4 2017/2018 P6|Réseau LoRaWAN]]
|
* 1 * iC880A-SPI , 
* 1 * Raspberry , 
* 2 * Nucleo-F4 , 
* 2 * Shield STM32 LoRa, 
|-
| P7 [[IMA4 2017/2018 P7|Brique pour apprentissage informatique]]
|
*1xCapteur ultrason [https://www.gotronic.fr/art-module-de-detection-us-hc-sr04-20912.htm]
*2xafficheurs-7segments [http://fr.farnell.com/broadcom-limited/hdsp-7801/afficheur-a-leds-7-62mm-vert/dp/1003275]
*4xboutons poussoirs [https://www.gotronic.fr/art-module-bouton-poussoir-st043-26115.htm]
*4xleds [https://www.gotronic.fr/art-led-5-mm-led5bt-21009.htm]
*2xpotentiomètres [https://www.gotronic.fr/art-potentiometre-lineaire-47k-8486-11110.htm]
*2xcâble [https://www.gotronic.fr/art-cordon-alimentation-pile-9v-19414.htm] + pile [https://www.gotronic.fr/art-pile-9v-au-lithium-uv9l-5575.htm] pour alimenter l'Arduino
*2xArduino Uno [https://store.arduino.cc/arduino-uno-rev3]
*2xModule bluetooth pour arduino (BTM-01)[https://www.mouser.fr/ProductDetail/OSEPP-Electronics/BTM-01/?qs=YCa%2fAAYMW020ADfc44%2fjCA%3d%3d]
*10xMicrocontrôleur Atmega328p [http://fr.farnell.com/microchip/atmega328p-pu/micro-8-bits-avr-32k-flash-28pdip/dp/1715487]
*2xKit roue + moteur [https://www.gotronic.fr/art-kit-roue-moteur-23569.htm]
*1xRoue folle [https://www.robotshop.com/eu/fr/roulette-bille-pololu-0375-po-metal.html]
*1xContrôleur de moteur [https://www.gotronic.fr/art-commande-de-2-moteurs-tb6612fng-2x1a-21716.htm]
*50xpicots mâle [https://fr.rs-online.com/web/p/barrettes-pour-ci/8967620/]
*5xpicots femelle [https://fr.rs-online.com/web/p/barrettes-pour-ci/2677400/]
*4x10 ressorts [https://fr.rs-online.com/web/p/ressorts-de-compression/0821245/]
*1xplaque de contreplaqué [https://www.leroymerlin.fr/v3/p/produits/predecoupe-medium-mdf-naturel-ep-10-mm-l-120-x-l-60-cm-e105237#&xtmc=predecoupe&xtcr=1]
|-
| P10 [[IMA4 2017/2018 P10|Portage de RIOT-OS sur MSP430 pour IOT]]
|
* 2xCC430 [https://www.mouser.fr/ProductDetail/Texas-Instruments/CC430F5137IRGZT/?qs=%2fqzd9s%252bcLd7GiX35ln9VRA==] (fourni par les tuteurs de projet) 3 reçus
* 1xMSP430-CCRF [https://www.olimex.com/Products/MSP430/Starter/MSP430-CCRF/] (fourni par les tuteurs de projet)
* 1xMSP-EXP430G2 [https://www.mouser.fr/productdetail/texas-instruments/msp-exp430g2?qs=sGAEpiMZZMv1ORdfpzTN%252bMwZ3%252b5KGk2B] (fourni par les tuteurs de projet)
|-
| P12 [[IMA4 2017/2018 P12|Système d'ostéophonie pour magicien]]
|
* Raspberry Pi 3, 
* Microcontroleur STM32L433CCT6 [https://www.mouser.fr/ProductDetail/STMicroelectronics/STM32L433CCT6?qs=sGAEpiMZZMuoKKEcg8mMKFZaGHZhaFFC5XHr6X%2fBPloj9WsFWEQ6BA%3d%3d],
* Mémoire Flash IS25WP064A-RMLE [https://www.mouser.fr/productdetail/issi/is25wp064a-rmle?qs=sGAEpiMZZMtI%252bQ06EiAoG5kNS0TozX6Gt0%2FX%2Fi6ExQk%3D], 
* DAC MCP4725A0T-E/CH [https://www.mouser.fr/productdetail/microchip-technology/mcp4725a0t-e-ch?qs=sGAEpiMZZMvfFCidbTccA97L6UsE6%2Fky], 
* Batterie 3.6V [https://www.gotronic.fr/art-accu-nimh-3-6v-300mah-290.htm], 
* Module Bluetooth 4.1 BM20SPKS1NBC-0001AA [https://www.mouser.fr/ProductDetail/Microchip-Technology/BM20SPKS1NBC-0001AA?qs=sGAEpiMZZMsGelYiB%252bjhZv%252biZoDZL1ptX5ao52HhnlyFQbPW6KaEbg%3d%3d],
* Adafruit Bone Conductor Transduce [https://www.mouser.fr/ProductDetail/Adafruit/1674/?qs=sGAEpiMZZMsqIr59i2oRcvz%252byDSTdozphj%2f1Oxe6%252bAQ=], 
* Transducteur Piézo diaphragme :
** fréquence de résonance 2.9KHz (gotronic) [https://www.gotronic.fr/art-disque-piezoelectrique-dp035-3843.htm],
** fréquence de résonance 4.6KHz (gotronic) [https://www.gotronic.fr/art-disque-piezoelectrique-dp027-3842.htm],
** fréquence de résonance 6.6KHz (gotronic) [https://www.gotronic.fr/art-disque-piezoelectrique-dp024-3841.htm],
** Afréquence 8KHz 10KHz (RS) [https://fr.rs-online.com/web/p/buzzers-piezo/7214947/],
* Moteur Électrique CC RS Pro, 3 → 7,2 V c.c., 19,68 W, 19000 tr/min, 4,41 A [https://fr.rs-online.com/web/p/moteurs-v-cc/2389721/].
|-
| P14 [[IMA4 2017/2018 P14|Ecran géant modulaire]]
|
|-
| P15 [[IMA4 2017/2018 P15|Balle vibrante connectée pour enfants sourd]]
|
* 8 vibreurs : [https://www.mouser.fr/productdetail/adafruit/1201?qs=sGAEpiMZZMsMyYRRhGMFNstIkcYqaSq8%2fLLE3lYp32I=]
* Module Bluetooth 4.0 Low Energy : [https://www.mouser.fr/ProductDetail/Adafruit/2479?qs=sGAEpiMZZMsMyYRRhGMFNjWi9ZmxEfRwbLHKJ6JemUg%3d]
* Bobine de recharge à induction (norme Qi) : [https://www.mouser.fr/productdetail/adafruit/1901?qs=sGAEpiMZZMsMyYRRhGMFNkyDC95Rd%252blHW46I1pJekjA%3D]
* <del> Batterie rechargeable 5Ah </del> à retirer de la commande car changement de batterie !! : [https://www.gotronic.fr/art-accu-li-ion-26650-26312.htm]
* 1 Batterie rechargeable 5.2Ah : [https://www.gotronic.fr/art-accu-li-ion-mgl9033-26425.htm#complte_desc]
* 2 controleurs pour moteur :[https://www.mouser.fr/ProductDetail/STMicroelectronics/L293DD?qs=sGAEpiMZZMukgiigmf73gOko5bw7EE67]
*2 condensateurs 14pF :[https://www.mouser.fr/ProductDetail/Murata-Electronics/GCQ1555C1H140FB01D?qs=sGAEpiMZZMs0AnBnWHyRQN7%2fAA2D2lPPLNRvFwtPLQHRWxf2q9etuA==]
*1 crystal quartz 16MHz :[https://www.mouser.fr/ProductDetail/ECS/ECS-160-12-33Q-JES-TR?qs=sGAEpiMZZMuMAfj%252bWfX4nLed60zyr3PUv7Kre5ygQ%252bs%3d]
* 1 résistances CMS 10khoms 0603 :[http://fr.farnell.com/multicomp/mcre000164/res-couche-epaisse-10k-1-0-05w/dp/1711641]

* 7 résistances CMS 1kohms 0603 :[http://fr.farnell.com/multicomp/mcre000140/res-couche-epaisse-1k-1-0-05w/dp/1711615?st=MULTICOMP%201K%200603]

* 1 résistances CMS 470ohms 0603:[https://www.mouser.fr/ProductDetail/TDK/MMZ1608Y471BTA00?qs=sGAEpiMZZMu0dYp3dYbBlQn%252beM9UWul2G3hJ%2f7TLqL0%3d]

* 2 résistances CMS 2kOhms 0603 :[https://www.mouser.fr/ProductDetail/Panasonic-Industrial-Devices/ERJ-3EKF2001V?qs=sGAEpiMZZMu61qfTUdNhGzRxdwze5h8ZMDWmuHH2qQY%3d]

* 2 resistances CMS 340kOhms 0603 :[https://www.mouser.fr/ProductDetail/Vishay/CRCW0603340KFKEA?qs=sGAEpiMZZMukHu%252bjC5l7YRSQiDx9P4ktLgBETRAdfqw%3d]

* 1 resistances CMS 1.87MOhms 0603 :[https://www.mouser.fr/ProductDetail/Yageo/RC0603FR-071M87L?qs=sGAEpiMZZMu61qfTUdNhG6gKAQVNBKOo2zO%2fNI9xQvs%3d]

*2 resistances CMS 100kOhms 0603 :[https://www.mouser.fr/ProductDetail/Vishay-Draloric/RCG0603100KFKEA?qs=sGAEpiMZZMsa677hLZe2Z63dGP%2fTFOZQ]

* 4 condensateur 10uF 0603 :[https://www.mouser.fr/ProductDetail/Taiyo-Yuden/LMK107BC6106MA-T?qs=sGAEpiMZZMukHu%252bjC5l7Yd8IIWTQlTYBUiPYtsE4Bzg%3d]

*1 condensateur 0.1uF 0603 :[https://www.mouser.fr/ProductDetail/Taiyo-Yuden/GMK107BJ104KAHT?qs=sGAEpiMZZMs0AnBnWHyRQNbg85K4ab%2f3WB4TApadaC0%3d]

*1 condenateur 2.2uF 0603 :[https://www.mouser.fr/ProductDetail/Taiyo-Yuden/JMK107B7225KAHTR?qs=sGAEpiMZZMs0AnBnWHyRQPSjYu%2fkbgu8y0KcZVF30DNOIVNQnIIJ3Q%3d%3d]

*1 condensateur 22uF 0603 :[https://www.mouser.fr/ProductDetail/Taiyo-Yuden/LMK107BBJ226MA-T?qs=sGAEpiMZZMs0AnBnWHyRQPSjYu%2fkbgu8OPGniOr6zLcT6eSTCbA%252bCQ%3d%3d]

*2 condensateur 1uF 0603 :[https://www.mouser.fr/ProductDetail/Taiyo-Yuden/GMK107BJ105KA-T?qs=sGAEpiMZZMs0AnBnWHyRQAEIN6r3SS%2fOBpoA9Mx5a9I%3d]

*1 condensateur 1210 100uF 1210 :[https://www.mouser.fr/ProductDetail/Murata-Electronics/GRM32ER61A107ME20L?qs=sGAEpiMZZMukHu%252bjC5l7Ya6pfwBk8EBeq55B9L%252bMJQA%3d]

*2 led verte CMS 1206 :[https://www.mouser.fr/ProductDetail/Kingbright/APTD3216LCGCK?qs=sGAEpiMZZMuCm2JlHBGefutc4sI%252bRg9%2fbKLcTuDCbMNnKZ3XxcbEWg%3d%3d]

*1 led orange 1206 CMS :[https://www.mouser.fr/ProductDetail/Lite-On/LTST-C150KAKT?qs=sGAEpiMZZMseGfSY3csMkTlTHQ2beMlrmGllatFacok%3d]

*2 led rouge 1206 CMS :[https://www.mouser.fr/ProductDetail/Kingbright/APTD3216LSURCK?qs=sGAEpiMZZMuCm2JlHBGefutc4sI%252bRg9%2fEbFuu2HcaZsnh6Yj8wyZLQ%3d%3d]

*1 led bleue CMS 1206 :[https://www.mouser.fr/ProductDetail/Kingbright/APTD3216LQBC-D?qs=sGAEpiMZZMseGfSY3csMkdgyOOAg6kv2SoHfbZ6fYRJR%252bPUfy4LTDQ%3d%3d]

* 1 module Bluetooth 802.15 :[https://www.mouser.fr/productdetail/seeed-studio/317030027?qs=wU1J8Md1npz%2F8UksA%252bh%252byw%3D%3D]

*1 Regulateur de tension LDO :[https://www.mouser.fr/ProductDetail/Microchip-Technology-Micrel/MIC5225YM5-TR?qs=sGAEpiMZZMsGz1a6aV8DcNranXV84HMLR75Z9P39yqc%3d]

*1 Transistor PNP prépolarisé 100mA:[https://www.mouser.fr/ProductDetail/ON-Semiconductor/MMUN2133LT1G/?qs=ZpPixqFcBtysLCI/2LOB%252bQ==]

*1 Régulateur de tension de commutation:[https://www.mouser.fr/ProductDetail/Texas-Instruments/TPS61090RSAR?qs=sGAEpiMZZMuo%252bmZx5g6tFAsofpr73Rbu]

*1 chargeur de batterie pour une cellule Li-on:[http://fr.farnell.com/microchip/mcp73831t-2aci-ot/controleur-de-charge-li-ion-li/dp/1332158]

*3 Diodes :[https://www.mouser.fr/ProductDetail/Diodes-Incorporated/1N4148WQ-7-F?qs=sGAEpiMZZMtzpSA5GSDwayHNFYvfz9yMGFXnI15cqbU%3d]

*1 diodes et redresseurs:[https://www.mouser.fr/ProductDetail/ON-Semiconductor/MBR120ESFT1G?qs=sGAEpiMZZMtQ8nqTKtFS%2fCKUxMvjsmGzPwX1d8aVcbo%3d]

*1 inductance 6.8uH:[http://fr.farnell.com/bourns/srn6045ta-6r8m/inductance-aec-q200-6-8uh-3-6a/dp/2616892]

*Quartz 32Mhz:[https://www.mouser.fr/ProductDetail/?qs=2xLVn2jvFusfExB%252byZEnpA%3D%3D]
|-
| P16 [[IMA4 2017/2018 P16|Sous-chaussure chauffante pour docker]]
|
*2xArduino Pro Mini [https://www.mouser.fr/ProductDetail/Adafruit/2377?qs=sGAEpiMZZMsMyYRRhGMFNrePrikk4IpJQBQo3elmwiI%3d]
*1xbouclier USB vers UART pour mini Arduino [https://www.mouser.fr/ProductDetail/Digilent/410-212?qs=sGAEpiMZZMsF1ODjcwEocFxZWH6k8YAWBC6KMJ05oOA%3d] 
*4xcapteurs de température et humidité DHT22 [https://www.gotronic.fr/art-capteur-de-t-et-d-humidite-dht22-20719.htm]
*2xMOSFET [https://fr.rs-online.com/web/p/transistors-mosfet/5431184/]
*1xbatterie [https://fr.rs-online.com/web/p/batteries-externes/7757508/?searchTerm=pb+A5200&relevancy-data=636F3D3126696E3D4931384E4C446573635461786F6E6F6D794272616E645365617263685465726D325F74656D70266C753D6672266D6D3D6D617463687061727469616C6D617826706D3D5E5B5C707B4C7D5C707B4E647D3F5C707B5A737D2D2C2F255C2E5D2B2426706F3D31313326736E3D592673743D4B4559574F52445F4D554C54495F414C5048415F414E445F4D554C54495F414C5048415F4E554D455249432673633D592677633D4E4F4E45267573743D7062204135323030267374613D706220413532303026]
*1xfilm de tranfert thermique [https://fr.rs-online.com/web/p/tampons-decart-thermiques/5075605/] Référence SILPAD400AC 
*1xBobine fil résisitif [https://fr.rs-online.com/web/p/cable-industriel-multiconducteur/7496344/]
*1xpaire de chaussure de sécurité (utilisation de nos chaussure)
*1xplaque de caoutchouc antidérapant antivibration [https://www.leroymerlin.fr/v3/p/produits/dalle-antiderapante-noir-gpi-e128988]
*1xRouleau de scratch [https://www.leroymerlin.fr/v3/p/produits/ruban-adhesif-mini-ruban-scratch-auto-agrippant-scratch-grip-l-2000-x-l-10-mm-e1400146133]

|-
| P17 [[IMA4 2017/2018 P17|Safe Watch]]
|
* Arduino ,
* Bouclier Arduino LCD ,
* Bouclier GPS Arduino ,
* Bouclier GSM Arduino ,
* Plaque d'essai, câbles, 3 boutons .
|-
| P18 [[IMA4 2017/2018 P18|Mandala électronique]]
|
*TCL5947*3 [http://fr.farnell.com/texas-instruments/tlc5947dap/ic-led-driver-linear-32-tssop/dp/1755259]
*Arduino Atmega328p [http://fr.farnell.com/microchip/atmega328p-aur/mcu-8-bits-atmega-20mhz-tqfp-32/dp/2425124?st=atmega328p]
*LEDs rougesx40 [http://fr.farnell.com/kingbright/kpl-3015ec/led-12mcd-rouge-617nm/dp/2426224]
*LEDs jaunesx70 [http://fr.farnell.com/kingbright/kpl-3015syck/led-350mcd-jaune-590nm/dp/2426230]
*LEDs bleuesx55 [http://fr.farnell.com/kingbright/kpl-3015qbc-d/led-200mcd-bleu-465nm/dp/2426226]
*LEDs orangesx55 [http://fr.farnell.com/kingbright/kpl-3015seck/led-350mcd-orange-601nm/dp/2426227]
*Transistorsx30 [http://fr.farnell.com/on-semiconductor/mmbt3904/transistor-npn-sot-23/dp/9846727]
*Bois [https://www.leroymerlin.fr/v3/p/produits/predecoupe-contreplaque-okoume-exterieur-ep-5-mm-l-80-x-l-60-cm-e1401453577]
*Source alimentationx2 [https://www.gotronic.fr/art-4-accus-nimh-r6-varta-1-2v-2-1ah-19151.htm]
*Coupleur de pilesx2 [https://www.gotronic.fr/art-coupleur-4-piles-lr6-em4p-5709.htm]
*Gouache [https://www.amazon.fr/Mallette-dartiste-bois-35-pi%C3%A8ces/dp/B00GIONTS2/ref=sr_1_2?ie=UTF8&qid=1516056582&sr=8-2&keywords=gouache]
*Stylo [https://www.amazon.fr/Papermate-S0916420-PM-300-Pointe-Moyenne/dp/B005HI33KO/ref=sr_1_3?ie=UTF8&qid=1516201326&sr=8-3&keywords=crayon+dore]
*ZX Distance et Gesture Sensor [https://www.mouser.fr/productdetail/sparkfun/sen-13162?qs=sGAEpiMZZMsEbyLvxciIbARXbzpjz%2fFllERyJO140AQcgPpUTdWOKA==]
|
|-
| P19 [[IMA4 2017/2018 P19|Bijou électronique]]
|
*50xLED CMS orange [http://fr.farnell.com/broadcom-limited/hsmd-c170/led-cms-orange/dp/5790864?MER=bn_para_1TP_LastViewed_1]
*50xLED CMS bleu [http://fr.farnell.com/broadcom-limited/hsmr-c170/led-bleu/dp/8554749]
*50xLED CMS vert [http://fr.farnell.com/broadcom-limited/hsmg-c170/led-verte/dp/5790852]
*50xLED CMS jaune [http://fr.farnell.com/broadcom-limited/hsmy-c170/led-jaune/dp/5790876]
*50xLED CMS rouge [http://fr.farnell.com/broadcom-limited/hsms-c170/led-rouge-he/dp/5790839]
*1xArduino UNO & 1xAtmega328p [http://fr.farnell.com/arduino-org/a000066/arduino-uno-carte-d-eval/dp/2075382]
*1xDS18B20 [http://fr.farnell.com/maxim-integrated-products/ds18b20u-t-r/capteur-de-temperature-0-5deg/dp/2515607]
*1xBreadboard [http://fr.farnell.com/mcm/21-18936/half-size-breadboard-with-300/dp/2799991]
*1xPulsesensor [https://www.mouser.fr/ProductDetail/SparkFun/SEN-11574?qs=%2fha2pyFadui%2fRsn4onUiCn%2f5VOJEA9t%252bK%252brmkRQhmlsCSXQ%252bUAWWwg%3d%3d]
*5xpiles de boutons de 3V [http://fr.farnell.com/varta/6032101501/pile-lithium-bouton/dp/300445]
*1xfil de fer [https://www.gotronic.fr/art-soudure-esp006-50-25658.htm]
*1xruban isolant [https://www.gotronic.fr/art-ruban-isolant-temflex-7682.htm]
*50xrésistances 68ohm [https://fr.rs-online.com/web/p/resistances-traversantes/1650741/]
*1xrésistances 8.2 Mohm [https://fr.rs-online.com/web/p/resistances-traversantes/6834102/]
*50xrésistances 56ohm [https://fr.rs-online.com/web/p/resistances-traversantes/1650735/]
*1xinterrupteur bascule [https://www.mouser.fr/ProductDetail/NKK-Switches/B12JJVC?qs=sGAEpiMZZMumOpTNq3bZXvRXehMYP%252byokBQhv3MozMw%3d]
*1xtoile [https://www.amazon.fr/Zedtom-Rouleau-D%C3%A9coration-Artisanat-Bricolage/dp/B01KJXOLZM/ref=sr_1_3?s=hi&ie=UTF8&qid=1516198372&sr=1-3&keywords=toile]
|-
| P20 [[IMA4 2017/2018 P20|Solution de messagerie à base de conteneurs]]
|
* 1 Raspberry Pi
|-
| P22 [[IMA4 2017/2018 P22|Horloge numérique DCF77, serveur de temps et ludique]]
|
* Pack de batterie NiMh 510mAh [http://fr.farnell.com/varta/55750404014/pack-de-batterie-nimh-510mah-4/dp/1903286]
* Contrôleur de batterie [https://fr.rs-online.com/web/p/controleurs-de-charge-de-batterie/5456852/] 
|-
| P23 [[IMA4 2017/2018 P23|Table de bar connectée]]
|
*'''NEW''' Regulateur 5V->3.3V 800mA [http://fr.farnell.com/stmicroelectronics/ld1117v33/regulateur-ldo-3-3v-1117-to-220/dp/9755837?CMP=KNC-GFR-FFR-GEN-KWL-G50-STMICROELECTRONICS&mckv=s2ZjbOaj_dc|pcrid|79679603942|&gclid=EAIaIQobChMIhe6d84CU2QIVShbTCh2pTggwEAAYAyAAEgKdUvD_BwE] ,
* <del>1 * Adaptateur Xbee<->USB </del> Plus nécessaire, on créera le notre avec un ATMega16U2,
* 4 * Modules Xbee [http://fr.farnell.com/digi-international/xb24-awi-001/module-zigbee-xbee-1mw-antenne/dp/1337912] ,
* 2 * Capteur de temperature [https://www.mouser.fr/ProductDetail/Analog-Devices/AD22103KTZ?qs=sGAEpiMZZMucenltShoSnoiUfjKGVRv2VdPSgYmyZyM%3d] ,
* 2 * Photoresistance [https://www.gotronic.fr/art-photoresistance-ldr04-2150.htm] ,
* 3 * Microcontroleurs Atmega328P [https://fr.rs-online.com/web/p/microcontroleurs/9214545/] ,
* 3 * Régulateur 9V->5V, 100mA [http://fr.farnell.com/texas-instruments/lm78l05acz-nopb/regulateur-lineaire-5-2v/dp/1469108],
* X * Piles 9V [https://fr.rs-online.com/web/p/piles-9-volts/7951545/] ,
* 3 * Quartz 16M [http://fr.farnell.com/raltron/as-16-000-18/quartz-16mhz-18pf-hc-49s/dp/1611761?MER=bn_para_1TP_LastViewed_3] ,
* 6 * Condensateur 18pF [http://fr.farnell.com/vishay/k180j15c0gf5tl2/ceramic-capacitor-18pf-50v-c0g/dp/4986210] ,
* 1 * Panneau LED[https://www.gotronic.fr/art-panneau-a-leds-rgb-64x32-dfr0460-26065.htm],
* ATMEGA16u2-AU ,
* Connectique USB A male à souder,
* Planche à Pain,
* Autres composants electroniques...
* <del>2</del> 3 Modules Xbee S1,
* <del>2</del> 3 Shield Arduino pou Xbee,
* <del>2</del> 3 Cable USB A - USB mini,
* 1 Xbee - Usb Adaptateur (pour le parametrage),
* 1 Led Rouge + Resistance 330Ohm,
* 3 Resistance 10K Ohm ,
* Planche à pain ,
* 3 Boutons .
|-
| P25 [[IMA4 2017/2018 P25|Essaim de robots]]
|
* 2 x Microcontrôleur Atmega [https://www.mouser.fr/ProductDetail/Microchip-Technology-Atmel/ATMEGA328P-MU?qs=sGAEpiMZZMvqv2n3s2xjscfa4zIkTHJIR0ZBr3z9ETo%3d] ,
* 22 x Condensateur 100nF [http://fr.farnell.com/kemet/c0201c104k9pactu/condensateur-mlcc-x5r-100nf-6/dp/1907036?st=Condensateur%20100nF] ,
* 4 x Condensateur 10uF [http://fr.farnell.com/wurth-elektronik/885012106006/condesateur-mlcc-x5r-10uf-6-3v/dp/2495147] ,
* 4 x Condensateur 22pF [http://www.mouser.fr/ProductDetail/AVX/06036A220KAT2A/?qs=sGAEpiMZZMs0AnBnWHyRQKdiqyDPVQdATEC6RfUr2zQ%3d] ,
* 2 x Rectifier Diode [http://www.mouser.fr/ProductDetail/Vishay-Semiconductors/GL34G-E3-83/?qs=sGAEpiMZZMutXGli8Ay4kH9ZXA1Qtv9UOwbhSBXDb18%3d] ,
* 4 x Servo moteur [https://www.mouser.fr/ProductDetail/Olimex-Ltd/MS-R-6-40?qs=sGAEpiMZZMvuFyKEiodORqSYMvGj9ACrspkI9Ywy%252bNs%3d] ,
* 6 x LED Infrarouge [http://fr.farnell.com/optek-technology/op290a/led-t-1-3-4/dp/1497872] ,
* 6 x Récepteur Infrarouge [http://www.mouser.fr/ProductDetail/Vishay-Semiconductors/TSOP38238/?qs=sGAEpiMZZMvAL21a%2fDhxMtgKho2n4%2fgBkajAZHPY5lE%3d] ,
* 2 x Quartz [http://www.mouser.fr/ProductDetail/ECS/ECS-160-20-3X-TR/?qs=sGAEpiMZZMvAbnEMxb34PZ9bYWrwSXiB] ,
* 2 x Switch [http://www.mouser.fr/ProductDetail/ALPS/SKQGADE010/?qs=sGAEpiMZZMsqIr59i2oRcrO5GDYRXDIX6cdtN26xmPE%3d] ,
* 2 x USB Chip [http://www.mouser.fr/ProductDetail/FTDI/FT232RL-REEL/?qs=sGAEpiMZZMs5ceO8zL%252bTxyQLQIH6hE7q] ,
* 2 x USB-C Connector [https://www.mouser.fr/ProductDetail/Molex/105450-0101?qs=sGAEpiMZZMulM8LPOQ%252byk43rDx%252b4l5FzJ4YNghWv4pnX6X7mot%2f43w%3d%3d] ,
* 2 x Batteries 9V [http://www.mouser.fr/ProductDetail/Panasonic-Battery/6LF22XWA-B12/?qs=sGAEpiMZZMsra%2fh506hF%252bITISQoCasqh1k2eJLis9sg%3d] ,
* 2 x Régulateur 5v [https://www.mouser.fr/ProductDetail/Texas-Instruments/LM1117IMPX-50-NOPB/?qs=X1J7HmVL2ZGGwLlD0uGqKQ%3D%3D] ,
* 2 x Roue de balance [https://fr.rs-online.com/web/p/billes-porteuses/0687770/] ,
* 2 x Emetteur/Récepteur Ultrason 40kHz [https://www.robotshop.com/ca/fr/module-sonar-hc-sr04-ultra01.html] .
|
|-
| P30 [[IMA4 2017/2018 P30|Contrôle d'une caméra WiFi.]]
|
Sont fournis par Ürbik :
* 2 x Cartes Micro-SD 
*2 x Support Micro-SD vers SD 
*1 * Banana Pi Pro 
*1 * Antenne Wifi pour Banana Pi Pro 
*1 * Module RTC compatible Banana Pro 
*1 * Shield de dévloppement GPIO Banana Pro
*1 * Bloc d'alimentation 230v~5v micro USB 
*1 * Banana Pi D1
*1 * Adaptateur ethernet USB type A
*1 * Cable MicroUSB mâle vers USB type A femelle
*1 * Cable USB type A mâle vers Micro USB mâle et USB type A femelle
Sont demandés à Polytech :
* 2 x Servomoteurs 
* 2 x Câbles ethernet 
* 1 x BananaPi D1 en remplacement [https://e.banana-pi.fr/cameras-banana-pi/35-bpi-d1-camera-ip.html] 
|-
| P32 [[IMA4 2017/2018 P32|Tribute to Peter Vogel]]
|
* 15 x Photorésistances LDR04 [https://www.gotronic.fr/art-photoresistance-ldr04-2150.htm#complte_desc]
* 20 x Amplificateur opérationnel LM358N [https://fr.rs-online.com/web/p/amplificateurs-operationnels/8431578]
* 15 x Résistances 68Kohm [https://fr.rs-online.com/web/p/resistances-traversantes/0386048]
* 15 x Résistances 4,7Kohm [https://fr.rs-online.com/web/p/resistances-traversantes/7077726]
* 25 x Résistances 1Kohm [https://fr.rs-online.com/web/p/resistances-traversantes/2671777]
* 25 x Transistors NPN 2N3904 [https://fr.rs-online.com/web/p/transistors-bipolaires/7390442]
* 12 x Potentiomètres linéaires 100k [https://fr.rs-online.com/web/p/potentiometres/2633006/]
* 10 x Potentiomètres linéaires 10k [https://www.mouser.fr/productdetail/welwyn-components-tt-electronics/p160kn-0qc17b10k?qs=sGAEpiMZZMtC25l1F4XBU1WvpdUcjC%2F6L3FhnOV516EmtF%252b%252b7aZUUw%3D%3D]
* 10 x Condensateurs 10µF [https://www.gotronic.fr/art-condensateur-radial-10uf-50v-3360.htm]
* 10 x Résistances 100Kohm [https://www.gotronic.fr/art-10-resistances-1-4w-100k-8486-20.htm]
* 70 x Leds rouges [https://www.gotronic.fr/art-leds-rouges-led5rl-356.htm]
* 1 x Condensateur 100nF [https://www.gotronic.fr/art-condensateur-ceramique-100-nf-3215.htm]
* 2 x Petits moteurs [https://www.gotronic.fr/art-moteur-miniature-sr30-787.htm]
* 1 x Atmega 328p [https://www.gotronic.fr/art-atmega328p-pu-16820.htm]
* 1 x Led verte [https://www.gotronic.fr/art-leds-vertes-led3gl-2057.htm]
* 1 x Résistance 330ohms 1/6th Watt Pth[https://eu.mouser.com/ProductDetail/SparkFun/COM-08377/?qs=sGAEpiMZZMuM1nRwI3zz2UpCr55iWBr5d51zFU1jOr2Myatejq0Ujw==]
* 1 x bouton poussoir [https://www.gotronic.fr/art-bp-subminiature-krs32n-4271.htm?qs=sGAEpiMZZMs%2FSh%2Fkjph1tvt1%2FmEPT%2FXoz55nayTMEJw%3D]
* 2 x Condensateurs découplages 10µF [https://www.gotronic.fr/art-condensateur-faible-esr-10uf-50v-11308.htm]
* 2 x Condensateurs céramiques 22pF [https://www.gotronic.fr/art-condensateur-ceramique-22-pf-3178.htm]
* 1 x Régulateur de tension [https://www.gotronic.fr/art-l7805cv-1578.htm]
* 1 x Cristal 16Mhz [https://www.gotronic.fr/art-quartz-16-000-mhz-55.htm]
* 3 x Female headers [https://www.mouser.fr/productdetail/harwin/m50-3030842?qs=sGAEpiMZZMve4%2FbfQkoj%252bNAvEyry7AuOrgimgco8uSU%3D]
* 2 x Haut-parleur 2W [https://www.mouser.fr/ProductDetail/CUI/CDS-27208?qs=sGAEpiMZZMuTkJYgZlQcSew3leo0OO6IWAIjM88CpYEXXyeONvvJNg==]
|-
| P35 [[IMA4 2017/2018 P35|Manette de jeu vidéo pour personne en situation de handicap]]
|
* 3 x Push buttons [https://www.gotronic.fr/art-bp-miniature-krs1273-16976.htm] ,
* 2 x Thumbstick (joystick analogique 4 directions) [https://www.gotronic.fr/art-joystick-analogique-4-directions-19063.htm] ,
* 1 x Led RGB [https://www.gotronic.fr/art-led-rgb-5-mm-led5rvb-2103.htm],
* 1 x Raspberry Pi 3 + son câble + carte SD+ alim [https://fr.rs-online.com/web/p/processor-microcontroller-development-kits/8968660/?src=raspberrypi],
* 3 x Arduino UNO ,
* 5 x Alimentation 3V: 10*piles AAA 1,2V rechargeables [https://www.mouser.fr/ProductDetail/Panasonic-Battery/HHR-60AAAHB2?qs=sGAEpiMZZMuXcNZ31nzYhUR9TS3h0B6UyKPniAa4akA%3d],
* 5 x modules bluetooth Nordi nrf nRF52810-QFAA-R [https://www.mouser.fr/productdetail/nordic-semiconductor/nrf52810-qfaa-r?qs=sGAEpiMZZMve4%2FbfQkoj%252bG%2FosjLoe2oghFQwQllMrQ4%3D] ,
* 1 x barette connecteur mâle traversant [https://www.gotronic.fr/art-connecteur-he14-mh200-4459.htm] ,
* 1 x barette connecteur femelle traversant [https://fr.rs-online.com/web/p/barrettes-pour-ci/2677416/] ,
* 1 x breadboard .
* 1 x Raspberry pi zero.
|-
| P39 [[IMA4 2017/2018 P39|Musique des plantes]]
|
* 1 x Plante ,
* 1 x Cordon pour électrodes [https://www.mouser.fr/ProductDetail/SparkFun-Electronics/CAB-12970/?qs=%2fha2pyFaduj1O95kixslzNrly0UKgNYdQ2TazqXF05PpguJVsXXh3Q%3d%3d],
* 1 x Electrodes [https://www.gotronic.fr/art-pads-a-electrodes-sen-12969-26244.htm],
* 2 x (précédemment 1) Amplificateur d'instrumentation [http://fr.farnell.com/texas-instruments/ina125p/amp-inst-precision-pdip16-125/dp/1459461],
* 1 x Arduino Mega [https://fr.rs-online.com/web/p/kits-de-developpement-pour-processeurs-et-microcontroleurs/7154084/],
* 1 x Cable d'alimentation [https://www.gotronic.fr/art-cordon-alimentation-pile-9v-19414.htm],
* 1 x Batterie [http://fr.farnell.com/duracell/accu-9v1/accumulateur-9v-pq1/dp/4140308],
* 2 x Connecteur Jack [https://fr.rs-online.com/web/p/connecteurs-jack-trs/5051485/],
* 1 x Connecteur MIDI [https://fr.rs-online.com/web/p/connecteurs-din/0491087/],
* 1 x AOP LM324 [http://fr.farnell.com/texas-instruments/lm324n/ic-op-amp-quadruple/dp/1564884?st=LM324N],
* 3 x Interrupteurs [http://fr.farnell.com/multicomp/1ms1t1b5m1qe/interrupteur-spdt/dp/9473378?st=commutateur%20%C3%A0%20levier%20on%20on],
* 1 x Potentiomètre [https://www.gotronic.fr/art-ajustable-vertical-2-2k-8486-11159.htm#complte_desc],
* 2 x LED RGB [https://www.gotronic.fr/art-led-rgb-5-mm-led5rvb-2103.htm],
* 1 x Haut-Parleur [http://fr.farnell.com/kingstate/kdmg28008/loudspeaker-micro/dp/1502732?MER=bn_level5_5NP_EngagementRecSingleItem_3],
|-
| P40 [[IMA4 2017/2018 P40|Exploration du réseau d'anonymisation Tor]]
|
*Réseau d'ordinateurs de l'école, implantés avec des VM,
*Un commutateur,
*La ligne SDSL,
*Et un marteau :).
|-
| P42 [[IMA4 2017/2018 P42|Automatisation de l'assemblage de LEGO]]
|
*1 x Arduino Mega
*1 x ESP8266
*1 x Raspberry Pi 3
*1 x imprimante 3D
*1 x plaque de polystyrène
*1 x plaque de plexiglas (3mm)
*1 x plaque Lego [https://shop.lego.com/fr-FR/La-plaque-de-base-verte-10700]
*15 x brique 1x1 noir [https://www.briquestore.fr/1x1/1233-lego-302426-plate-1x1-noir.html]
*15 x brique 1x1 blanc [https://www.briquestore.fr/1x1/1236-lego-302401-plate-1x1-blanc.html]
*15 x brique 1x1 bleu [https://www.briquestore.fr/1x1/1238-lego-302423-plate-1x1-bleu.html]
*15 x brique 1x1 rouge [https://www.briquestore.fr/1x1/1237-lego-302421-plate-1x1-rouge.html]
*15 x brique 1x1 jaune [https://www.briquestore.fr/1x1/1239-lego-302424-plate-1x1-jaune.html]
*15 x brique 1x1 vert [https://www.briquestore.fr/1x1/1241-lego-302428-plate-1x1-dark-green.html]
|
|-
| P44 [[IMA4 2017/2018 P44|Reconnaissance d’objets via Traitement d’Image]]
|
|-
| P49 [[IMA4 2017/2018 P49|Suivi de la qualité de l’air]]
|
Matériel fournit par l'INRIA :
* 1 x Raspberry Pi 3
* 1 x Arduino Méga
* 1 x détecteur de mouvement PIR (HC-SR01)
* 1 x détecteur de bruit
* 1 x capteur de température et d'humidité (DHT22)
* 1 x capteur de pression
* 1 x capteur de luminosité
* 1 x capteur de Composé Organique Volatil COV 
* 4 x capteurs de monoxyde de carbone CO (Alphasense) 
* 2 x capteurs de dioxyde de carbone CO2
* 1 x E/R XBee
* 1 x clavier alphanumérique usb
|-
| P50 [[IMA4 2017/2018 P50|Etage commande de Centaure]]
|
Matériels existants:
*2 x Batteries 12V 22Ah (dont une hs)
*1 x Chargeur de batterie 12V 
*1 x Contacteur 24Vcc 18A ref: TeSys LC1D18BD 
*2 x Variateurs de vitesse ref: Alpes Ital 8CH2QM.2
*1 x Arduino MEGA ADK avec son bouclier de capteurs 
*1 x Carte keyes funduino à 4 relais
*1 x DC/DC convertisseur 24V => 12V & 5V ref: Tracopower TEN 40-4811 
*1 x Porte fusibles à 5 ports 
Matériels manquants:
* 1* Batterie 12V 55Ah; trouvée chez le fournisseur mouser.fr [https://www.mouser.fr/productdetail/power-sonic/ps-12550?qs=sGAEpiMZZMso%252bSMtTqBO32B9ZZCkCjmed3agP8D7TIo%3D]
* 1* Chargeur 24V; chez le même fournisseur [https://www.mouser.fr/productdetail/ault-sl-power/bvl240600003n?qs=sGAEpiMZZMsYfYypWaYaEeWCnBdw823Sg9r4NP%2FMM%252bU%3D] 
|-
| P60 [[IMA4 2017/2018 P60|Commande de niveaux d’eau]]
|
|-
| P64 [[IMA4 2017/2018 P64|Simulation Labview et mise en réseau Modbus d’un ascenseur]]
|
|-
| P65 [[IMA4 2017/2018 P65|Exosquelette pour apprentissage]]
|
|-
| P66 [[IMA4 2017/2018 P66|Coupe de France de robotique]]
|
Fourni par Robotech :
*1 × Batterie Lipo 4S
*1 × Carte de puissance
*1 × Support mécanique & Roues
*2 × Faulhaber MOTOR 3557K024CS
*1 × Contrôleur moteur
*2 × HEDM-550X
*1 × Capteur MinIMU-9 v3
*X × Capteurs ultrasons / infrarouges
*1 × MicroNova Mercury FPGA Development Board
*1 × Arduino MEGA 2560
*1 × Raspberry Pi 3
*1 × Écran LCD SPI
*X × Boutons
|-
| P67 [[IMA4 2017/2018 P67|Scanner 3D DIY]]
|
*2x Moteur NEMA 17
*2x contrôleur moteur
*bouton poussoir de fin de parcours de courroie
*courroie et engrenage pour Nema 17
*Alim 12V
*bobine de PLA pour impression 3D (dispo au Fabricarium)
*Carte arduino Méga
*Caméra Kinect pour 360 ou Kinect microsoft
*Câble / résistances / capa
*module de sauvegarde pour carte SD ou carte micro SD (j'en possède déjà un)
*capteur de mesure de distance [http://fr.farnell.com/sharp/gp2y0a21yk0f/capteur-de-distance/dp/1243869]
*bois
|-
| P68 [[IMA4 2017/2018 P68|Générateur de chronogrammes d'ordonnancement]]
|
|-
| PP1 [[IMA4 2017/2018 Pré-projet 1|Robot hexapode pour escalier]]
|
* Arduino Mega / câble
* 12 servos moteurs SG90 
* une structure robot 4 pattes 
* Plaque d'essai, câbles 
|-
|}

Discussion:Projets IMA4 SC & SA 2017/2018

2018-02-07T13:46:37Z

Tgracias : /* Fiche de présence */

== Notes sur les projets ==

{| class="wikitable"
| Projet || Analyse du projet || Retour sur l'analyse || Matériel || Mi-parcours || Wiki terminé || Rapport || Vidéo
|-
| P1 [[IMA4 2017/2018 P1|Automatisation de la production de bière]]
| Présentation sans supports, bonne analyse de la concurrence. Par contre le scénario d'usage est à revoir en précisant l'usage pour le particulier.
| Le scénario est précisé mais aucune réponse aux questions difficiles "gestion des températures et procédure d'entretien".
| Rien.
|
|
|
|
|-
| P3 [[IMA4 2017/2018 P3|Sécurisation de l'Internet des Objets par surveillance globale]]
| Présentation focalisée sur les réseaux de neurones. Exercice mal compris (pas d'introduction du contexte, pas de scénario d'usage).
| Toujours pas d'analyse de la concurrence, ni de scénario d'usage. Pas de réponse aux questions difficiles "quel est le matériel ? quel est le protocole ? quelles sont les entrées du réseau de neurones ?".
| Une liste mais il manque des références vers les fournisseurs agréés (voir page de l'an dernier).
|
|
|
|
|-
| P4 [[IMA4 2017/2018 P4|Développement d'un module d'énergie pour Internet des Objets]]
| Exercice correctement réalisé.
| Pas de réponse aux questions difficiles "Architecture de la source d'énergie (nombre de chemins d'énergie ?)".
| Rien.
|
|
|
|-
| P5 [[IMA4 2017/2018 P5|Réseau de capteurs de pollution]]
| Présentation focalisée sur la création du site Web. Effort fait pour rédiger un scénario d'usage.
| Réponses aux questions mais l'analyse de la consommation est imprécise. 
| Du matériel listé dans la page Wiki mais à reporter en bas de la page des projets de cette année avec des références valides.
|
|
|
|
|-
| P6 [[IMA4 2017/2018 P6|Réseau LoRaWAN]]
| Exercice correctement réalisé. Scénario d'usage à préciser sur la partie réseau de capteurs.
| Scénario d'usage non précisé. Pas de réponse à la question difficile.
| Du matériel listé mais sans référence, êtes-vous sur que le matériel n'a pas besoin d'être acheté ?
|
|
|
|
|-
| P7 [[IMA4 2017/2018 P7|Brique pour apprentissage informatique]]
| Pas de support. Exercice très bien réalisé.
| Pas de réponse aux questions difficiles "quelle alimentation ? comment faire pour différencier les briques ? comment les briques vont-elles communiquer ? quelle sécurité vis-à-vis des enfants ?"
| Pas de liste de matériel.
|
|
|
|
|-
| P10 [[IMA4 2017/2018 P10|Portage de RIOT-OS sur MSP430 pour IOT]]
| Rien à signaler (juste une confusion entre le MSP430 et le CC430).
| Questions difficiles évacuées. 
| Du matériel listé mais sans référence.
|
|
|
|
|-
| P12 [[IMA4 2017/2018 P12|Système d'ostéophonie pour magicien]]
| Un peu rapide, exercice réalisé. 
| Pas d'analyse de la concurrence. Peu d'effort de rédaction. Des coquilles. Une réponse rapide à la question difficile.
| Du matériel listé mais pas forcément exhaustif et sans référence valide.
|
|
|
|
|-
| P14 [[IMA4 2017/2018 P14|Ecran géant modulaire]]
| Doublant
| Doublant
| Page Wiki vide, pas de liste de matériel.
|
|
|
|
|-
| P15 [[IMA4 2017/2018 P15|Balle vibrante connectée pour enfants sourd]]
| Présentation acceptable mais avec des supports non soignés. Pas d'analyse de la concurrence, pas de scénario d'usage.
| L'analyse de la concurrence et le scénario d'usage ont été ajoutés. Par contre pas de réponse aux questions difficiles "quelle sera l'autonomie de la balle et quel sera le système de rechargement ?".
| Pas de liste de matériel.
|
|
|
|
|-
| P16 [[IMA4 2017/2018 P16|Sous-chaussure chauffante pour docker]]
| Présentation acceptable mais avec des supports non soignés. Trouver des concurrents indirects. Une histoire mais pas de scénario d'usage.
| Page Wiki modifiée après la présentation. Une réponse incomplète à la question difficile. Trop de coquilles pour ce niveau d'études.
| Pas de liste de matériel.
|
|
|
|
|-
| P17 [[IMA4 2017/2018 P17|Safe Watch]]
| Doublant
| Doublant
| Aucune modification de la page Wiki depuis début octobre.
|
|
|-
| P18 [[IMA4 2017/2018 P18|Mandala électronique]]
| Supports très textuels, pas de scénario d'usage mais une rédaction sur l'intérêt psychologique, pas vraiment de partie "concurrents".
| Un effort pour trouver des "concurrents", pas de réponses aux questions difficiles "combien de LEDs ? quelle alimentation pour quelle autonomie".
| Pas de liste de matériel.
|
|
|
|
|-
| P19 [[IMA4 2017/2018 P19|Bijou électronique]]
| Bonne présentation orale. Utilisation du bluetooth peu convainquant. Pas de scénario d'usage. Un "concurrent" trouvé.
| Concept de scénario d'usage non compris. Une réponse à la question difficile très rapide et non convaincante.
| Une liste de matériel dans la page Wiki mais à insérer dans le tableau en bas de la page principale. Pas de référence (voir sur la page de l'an passé).
|
|
|
|
|-
| P20 [[IMA4 2017/2018 P20|Solution de messagerie à base de conteneurs]]
| Support assez corrects, sujet non entièrement compris, scénario d'usage minimal.
| Un problème dans le scénario d'usage : les conteneurs doivent être lancés sur un serveur. Une réponse acceptable à la question difficile.
| Pas de matériel particulier.
|
|
|
|
|-
| P22 [[IMA4 2017/2018 P22|Horloge numérique DCF77, serveur de temps et ludique]]
| Analyse très correcte.
| Réponse à la question difficile.
| Aucune liste de matériel.
|
|
|
|
|-
| P23 [[IMA4 2017/2018 P23|Table de bar connectée]]
| Présentation trop impécise, pas vraiment de scénario d'usage. Par contre des concurrents ont été présentés.
| Un scénario d'usage éloigné de la future utilisation. Trop de coquilles dans ce scénario. Réponse à la question difficile.
| Une liste du matériel mais pas dans la page principale. Pas de référence (voir page de l'an passé).
|
|
|
|
|-
| P25 [[IMA4 2017/2018 P25|Essaim de robots]]
| Analyse très correcte. Un concurrent assez peu en rapport avec les essaims de robots mais dans la ligne des dispositifs de déminage.
| Pas de question difficile.
| Liste du matériel. Préciser pour le chassis.
|
|
|
|
|-
| P30 [[IMA4 2017/2018 P30|Contrôle d'une caméra WiFi.]]
| Objectif mal expliqué. Exercice réalisé.
| Mieux définir l'objectif suite à la visite en entreprise. Pas de réponse à la question difficile.
| Aucune liste de matériel.
|
|
|
|
|-
| P32 [[IMA4 2017/2018 P32|Tribute to Peter Vogel]]
| Excellente présentation et excellent travail préparatoire, Scénario d'usage à préciser, trouver des concurrents.
| Réponse à la question difficile.
| Aucune liste de matériel.
|
|
|
|
|-
| P35 [[IMA4 2017/2018 P35|Manette de jeu vidéo pour personne en situation de handicap]]
| Exercice réussi. Cependant précisez les acteurs dans le scénario d'usage.
| Pas de modification du scénario. Pas de réponse à la question difficile.
| Rien à redire sur la liste de matériel.
|
|
|
|
|-
| P39 [[IMA4 2017/2018 P39|Musique des plantes]]
| Analyse très correcte.
| Réponses aux questions difficiles.
| Aucune liste de matériel.
|
|
|
|
|-
| P40 [[IMA4 2017/2018 P40|Exploration du réseau d'anonymisation Tor]]
| Sujet se prêtant peu à l'exercice mais très bonne présentation. Sujet travaillé.
| Pas vraiment de question, la suggestion est noté dans la page Wiki.
| Pas de matériel à commander.
|
|
|
|
|-
| P42 [[IMA4 2017/2018 P42|Automatisation de l'assemblage de LEGO]]
| Analyse très correcte.
| Pas de réponse aux questions difficiles "Comment démarrer l'imprimante à distance ? Comment sera calibrée la plaque d’impression ?
Comment la plaque va se fixer sur le sol ? 
| Aucune liste de matériel.
|
|
|
|
|-
| P44 [[IMA4 2017/2018 P44|Reconnaissance d’objets via Traitement d’image]]
| Le projet ne semble pas encore avoir été sérieusement étudié.
| Net effort de documentation de la page Wiki. Pas de réponse directe à la question difficile sur la Kinect mais une discussion sur le problème posé.
| Aucune liste de matériel.
|
|
|
|
|-
| P49 [[IMA4 2017/2018 P49|Suivi de la qualité de l’air]]
| Contexte mal présenté, sujet flou. Scénario d'usage à préciser. Pas de contact avec les encadrants avant la présentation.
| Page de Wiki vide.
| Aucune liste de matériel.
|
|
|
|
|-
| P50 [[IMA4 2017/2018 P50|Etage commande de Centaure]]
| Doublant
| Page de Wiki assez vide.
| Aucune liste de matériel.
|
|
|
|
|-
| P60 [[IMA4 2017/2018 P60|Commande de niveaux d’eau]]
| Présentation très correcte.
| Pas de réponse à la question difficile. Page Wiki un peu vide.
| Pas de matériel à commander.
|
|
|
|
|-
| P64 [[IMA4 2017/2018 P64|Simulation Labview et mise en réseau Modbus d’un ascenseur]]
| Doublant
| Wiki avec quelques informations sur le travail accompli depuis fin novembre : étude sur modbus et labview. Quelques coquilles.
| Aucune liste de matériel.
|
|
|
|
|-
| P65 [[IMA4 2017/2018 P65|Exosquelette pour apprentissage]]
| Présentation sans support. Trouver des concurrents indirects. Pas de scénario d'usage.
| Page Wiki vide.
| Aucune liste de matériel.
|
|
|
|
|-
| P66 [[IMA4 2017/2018 P66|Coupe de France de robotique]]
| Analyse très correcte.
| Page Wiki bien tenue. Ajoutez des illustrations.
| Quelques éléments sur le matériel dans la page Wiki mais aucune liste avec références.
|
|
|
|
|-
| P67 [[IMA4 2017/2018 P67|Scanner 3D DIY]]
| Exercice bien réalisé.
| Page Wiki très complète. Ajoutez des illustrations.
| Une liste probablement pas exhaustive.
|
|
|
|
|-
| P68 [[IMA4 2017/2018 P68|Générateur de chronogrammes d'ordonnancement]]
| Doublant
| Page Wiki vide.
| Pas de matériel à commander.
|
|
|
|
|-
| PP1 [[IMA4 2017/2018 Pré-projet 1|Robot hexapode pour escalier]]
| Erasmus
|
|
|
|
|-
|}

== Fiche de présence ==

{| class="wikitable"
! Projet !! Elèves !! Séance 1 (17/01) !! Séance 2 (24/01) !! Séance 3 (31/01) !! Séance 4 (7/02) !! Séance 5 (14/02) !! Séance 6 (21/02) !! Séance 7 (7/03) !! Séance 8 (14/03) !! Séance 9 (21/03) !! Séance 10 (28/03) !! Séance 11 (4/04) !! Séance 12 (11/04) !! Séance 13 (18/04)
|-
| P1 [[IMA4 2017/2018 P1|Automatisation de la production de bière]]
|Quentin Boëns / Henri Carlier
|E304
|E304/305
|E304

|-
| P3 [[IMA4 2017/2018 P3|Sécurisation de l'Internet des Objets par surveillance globale]]
|Ji Yang
|E306
|E303
| Pas de salle 
|-
| P4 [[IMA4 2017/2018 P4|Développement d'un module d'énergie pour Internet des Objets]]
| Alexis Viscogliosi / Abass Ayoub
|C008
|C008
|E304 Alexis Viscogliosi Absent excusé pour entretien stage
|-
| P5 [[IMA4 2017/2018 P5|Réseau de capteurs de pollution]]
| Paul Ribeiro / Mehanna Naïf
|E303
|E301
|A204 Absents 
|-
| P6 [[IMA4 2017/2018 P6|Réseau LoRaWAN]]
| Antoine Gosse
| E306
| E306
| E306
|-
| P7 [[IMA4 2017/2018 P7|Brique pour apprentissage informatique]]
| Maëva Delaporte / Simon Blas
| E304 
| E304 
| E304 
|-
| P10 [[IMA4 2017/2018 P10|Portage de RIOT-OS sur MSP430 pour IOT]]
| Baptiste Cartier
| E306
| E301
| E306
|-
| P12 [[IMA4 2017/2018 P12|Système d'ostéophonie pour magicien]]
| Amine El Messaoudi / Simon Feutrier
| E301
| C201
| Pas de salle 
|-
| P14 [[IMA4 2017/2018 P14|Ecran géant modulaire]]
| Jade Dupont
|E304
|E304
|E304
|-
| P15 [[IMA4 2017/2018 P15|Balle vibrante connectée pour enfants sourd]]
| Thomas Cunin / Thibault Cattelain
| E304
| B306/E304
| Pas de salle 
|-
| P16 [[IMA4 2017/2018 P16|Sous-chaussure chauffante pour docker]]
| Rémi Mairesse / Gustave Roux
| E304
| E301
| Pas de salle 
|-
| P17 [[IMA4 2017/2018 P17|Safe Watch]]
| Oumaima Naanaa
|E302
|E304
|E304
|-
| P18 [[IMA4 2017/2018 P18|Mandala électronique]]
| Lirui Zhang / Lihe Zhang
| E304
| E304
| E304
 Pas de salle 
|-
| P19 [[IMA4 2017/2018 P19|Bijou électronique]]
| Lijie Yao / Keren Qiang
| E303
| E304
| E304
|-
| P20 [[IMA4 2017/2018 P20|Solution de messagerie à base de conteneurs]]
| Maxime Creteur / Gao Fan
|E303
|E301
|A204 Absents 
|-
| P22 [[IMA4 2017/2018 P22|Horloge numérique DCF77, serveur de temps et ludique]]
| Amaury Knockaert / Fabrice Taingland
| E304
| E304
| E304/E302
|-
| P23 [[IMA4 2017/2018 P23|Table de bar connectée]]
| Matthieu Delobelle
| E306
| E306
| E303 - C201
|-
| P25 [[IMA4 2017/2018 P25|Essaim de robots]]
| Benjamin Canu / Ganix Etcheguibel
| E306
| E306
| E306
|-
| P30 [[IMA4 2017/2018 P30|Contrôle d'une caméra WiFi.]]
| Taky Djeraba / Thomas Hubert
| E306
| E306
| Pas de salle 
|-
| P32 [[IMA4 2017/2018 P32|Tribute to Peter Vogel]]
| Jean-Baptiste Watine / Antoine Untereiner
| E306/C201
| E301
| Pas de salle (C201) 
|-
| P35 [[IMA4 2017/2018 P35|Manette de jeu vidéo pour personne en situation de handicap]]
| Transley Gracias / Camille Saad
| E306
| E306
| E305
| E306
|-
| P39 [[IMA4 2017/2018 P39|Musique des plantes]]
| Xavier Chenot / Rodolphe Toin
| E306
| E306
| E306
|-
| P40 [[IMA4 2017/2018 P40|Exploration du réseau d'anonymisation Tor]]
| Antoine Duquenoy / Anthony Durot
| E306
| E306
| E306
|-
| P42 [[IMA4 2017/2018 P42|Automatisation de l'assemblage de LEGO]]
| Eloi Zalczer / Justine Senellart
|E302/E306
|E302/E306
|E304/E302
|-
|-
| P44 [[IMA4 2017/2018 P44|Reconnaissance d’objets via Traitement d’image]]
| Damien Narbais / Zoé Briois
| E306
| E301
| Pas de salle 
|-
| P49 [[IMA4 2017/2018 P49|Suivi de la qualité de l’air]]
| Hugo Delbroucq / Nicolas Havard
| E301
| INRIA
| Pas de salle 
|-
| P50 [[IMA4 2017/2018 P50|Etage commande de Centaure]]
|-
| P60 [[IMA4 2017/2018 P60|Commande de niveaux d’eau]]
| Claire Vandamme / Alexandra Villa
|C008
|C008
|Hors Polytech/B106 Pas de salle Absentes 
|-
| P64 [[IMA4 2017/2018 P64|Simulation Labview et mise en réseau Modbus d’un ascenseur]]
|-
| P65 [[IMA4 2017/2018 P65|Exosquelette pour apprentissage]]
| Florian Le Foll
| E301
| E301
| Pas de salle 
|-
| P66 [[IMA4 2017/2018 P66|Coupe de France de robotique]]
| Carval Amaury
| fabricarium
| fabricarium puis Hors Polytech
| E304
|-
| P67 [[IMA4 2017/2018 P67|Scanner 3D DIY]]
| Erwan Dufresne
| E302/E306
| E301
| E304
|-
| P68 [[IMA4 2017/2018 P68|Générateur de chronogrammes d'ordonnancement]]
|}

IMA4 2017/2018 P35

2018-01-31T16:46:13Z

Tgracias : /* Semaine 2 */

IMA4 2017/2018 P35

2018-01-31T16:39:52Z

Tgracias : /* Semaine 1 */

IMA4 2017/2018 P35

2018-01-31T16:38:22Z

Tgracias : /* Semaine 1 */

Discussion:Projets IMA4 SC & SA 2017/2018

2018-01-31T16:35:42Z

Tgracias : /* Fiche de présence */

== Notes sur les projets ==

{| class="wikitable"
| Projet || Analyse du projet || Retour sur l'analyse || Matériel || Mi-parcours || Wiki terminé || Rapport || Vidéo
|-
| P1 [[IMA4 2017/2018 P1|Automatisation de la production de bière]]
| Présentation sans supports, bonne analyse de la concurrence. Par contre le scénario d'usage est à revoir en précisant l'usage pour le particulier.
| Le scénario est précisé mais aucune réponse aux questions difficiles "gestion des températures et procédure d'entretien".
| Rien.
|
|
|
|
|-
| P3 [[IMA4 2017/2018 P3|Sécurisation de l'Internet des Objets par surveillance globale]]
| Présentation focalisée sur les réseaux de neurones. Exercice mal compris (pas d'introduction du contexte, pas de scénario d'usage).
| Toujours pas d'analyse de la concurrence, ni de scénario d'usage. Pas de réponse aux questions difficiles "quel est le matériel ? quel est le protocole ? quelles sont les entrées du réseau de neurones ?".
| Une liste mais il manque des références vers les fournisseurs agréés (voir page de l'an dernier).
|
|
|
|
|-
| P4 [[IMA4 2017/2018 P4|Développement d'un module d'énergie pour Internet des Objets]]
| Exercice correctement réalisé.
| Pas de réponse aux questions difficiles "Architecture de la source d'énergie (nombre de chemins d'énergie ?)".
| Rien.
|
|
|
|-
| P5 [[IMA4 2017/2018 P5|Réseau de capteurs de pollution]]
| Présentation focalisée sur la création du site Web. Effort fait pour rédiger un scénario d'usage.
| Réponses aux questions mais l'analyse de la consommation est imprécise. 
| Du matériel listé dans la page Wiki mais à reporter en bas de la page des projets de cette année avec des références valides.
|
|
|
|
|-
| P6 [[IMA4 2017/2018 P6|Réseau LoRaWAN]]
| Exercice correctement réalisé. Scénario d'usage à préciser sur la partie réseau de capteurs.
| Scénario d'usage non précisé. Pas de réponse à la question difficile.
| Du matériel listé mais sans référence, êtes-vous sur que le matériel n'a pas besoin d'être acheté ?
|
|
|
|
|-
| P7 [[IMA4 2017/2018 P7|Brique pour apprentissage informatique]]
| Pas de support. Exercice très bien réalisé.
| Pas de réponse aux questions difficiles "quelle alimentation ? comment faire pour différencier les briques ? comment les briques vont-elles communiquer ? quelle sécurité vis-à-vis des enfants ?"
| Pas de liste de matériel.
|
|
|
|
|-
| P10 [[IMA4 2017/2018 P10|Portage de RIOT-OS sur MSP430 pour IOT]]
| Rien à signaler (juste une confusion entre le MSP430 et le CC430).
| Questions difficiles évacuées. 
| Du matériel listé mais sans référence.
|
|
|
|
|-
| P12 [[IMA4 2017/2018 P12|Système d'ostéophonie pour magicien]]
| Un peu rapide, exercice réalisé. 
| Pas d'analyse de la concurrence. Peu d'effort de rédaction. Des coquilles. Une réponse rapide à la question difficile.
| Du matériel listé mais pas forcément exhaustif et sans référence valide.
|
|
|
|
|-
| P14 [[IMA4 2017/2018 P14|Ecran géant modulaire]]
| Doublant
| Doublant
| Page Wiki vide, pas de liste de matériel.
|
|
|
|
|-
| P15 [[IMA4 2017/2018 P15|Balle vibrante connectée pour enfants sourd]]
| Présentation acceptable mais avec des supports non soignés. Pas d'analyse de la concurrence, pas de scénario d'usage.
| L'analyse de la concurrence et le scénario d'usage ont été ajoutés. Par contre pas de réponse aux questions difficiles "quelle sera l'autonomie de la balle et quel sera le système de rechargement ?".
| Pas de liste de matériel.
|
|
|
|
|-
| P16 [[IMA4 2017/2018 P16|Sous-chaussure chauffante pour docker]]
| Présentation acceptable mais avec des supports non soignés. Trouver des concurrents indirects. Une histoire mais pas de scénario d'usage.
| Page Wiki modifiée après la présentation. Une réponse incomplète à la question difficile. Trop de coquilles pour ce niveau d'études.
| Pas de liste de matériel.
|
|
|
|
|-
| P17 [[IMA4 2017/2018 P17|Safe Watch]]
| Doublant
| Doublant
| Aucune modification de la page Wiki depuis début octobre.
|
|
|-
| P18 [[IMA4 2017/2018 P18|Mandala électronique]]
| Supports très textuels, pas de scénario d'usage mais une rédaction sur l'intérêt psychologique, pas vraiment de partie "concurrents".
| Un effort pour trouver des "concurrents", pas de réponses aux questions difficiles "combien de LEDs ? quelle alimentation pour quelle autonomie".
| Pas de liste de matériel.
|
|
|
|
|-
| P19 [[IMA4 2017/2018 P19|Bijou électronique]]
| Bonne présentation orale. Utilisation du bluetooth peu convainquant. Pas de scénario d'usage. Un "concurrent" trouvé.
| Concept de scénario d'usage non compris. Une réponse à la question difficile très rapide et non convaincante.
| Une liste de matériel dans la page Wiki mais à insérer dans le tableau en bas de la page principale. Pas de référence (voir sur la page de l'an passé).
|
|
|
|
|-
| P20 [[IMA4 2017/2018 P20|Solution de messagerie à base de conteneurs]]
| Support assez corrects, sujet non entièrement compris, scénario d'usage minimal.
| Un problème dans le scénario d'usage : les conteneurs doivent être lancés sur un serveur. Une réponse acceptable à la question difficile.
| Pas de matériel particulier.
|
|
|
|
|-
| P22 [[IMA4 2017/2018 P22|Horloge numérique DCF77, serveur de temps et ludique]]
| Analyse très correcte.
| Réponse à la question difficile.
| Aucune liste de matériel.
|
|
|
|
|-
| P23 [[IMA4 2017/2018 P23|Table de bar connectée]]
| Présentation trop impécise, pas vraiment de scénario d'usage. Par contre des concurrents ont été présentés.
| Un scénario d'usage éloigné de la future utilisation. Trop de coquilles dans ce scénario. Réponse à la question difficile.
| Une liste du matériel mais pas dans la page principale. Pas de référence (voir page de l'an passé).
|
|
|
|
|-
| P25 [[IMA4 2017/2018 P25|Essaim de robots]]
| Analyse très correcte. Un concurrent assez peu en rapport avec les essaims de robots mais dans la ligne des dispositifs de déminage.
| Pas de question difficile.
| Liste du matériel. Préciser pour le chassis.
|
|
|
|
|-
| P30 [[IMA4 2017/2018 P30|Contrôle d'une caméra WiFi.]]
| Objectif mal expliqué. Exercice réalisé.
| Mieux définir l'objectif suite à la visite en entreprise. Pas de réponse à la question difficile.
| Aucune liste de matériel.
|
|
|
|
|-
| P32 [[IMA4 2017/2018 P32|Tribute to Peter Vogel]]
| Excellente présentation et excellent travail préparatoire, Scénario d'usage à préciser, trouver des concurrents.
| Réponse à la question difficile.
| Aucune liste de matériel.
|
|
|
|
|-
| P35 [[IMA4 2017/2018 P35|Manette de jeu vidéo pour personne en situation de handicap]]
| Exercice réussi. Cependant précisez les acteurs dans le scénario d'usage.
| Pas de modification du scénario. Pas de réponse à la question difficile.
| Rien à redire sur la liste de matériel.
|
|
|
|
|-
| P39 [[IMA4 2017/2018 P39|Musique des plantes]]
| Analyse très correcte.
| Réponses aux questions difficiles.
| Aucune liste de matériel.
|
|
|
|
|-
| P40 [[IMA4 2017/2018 P40|Exploration du réseau d'anonymisation Tor]]
| Sujet se prêtant peu à l'exercice mais très bonne présentation. Sujet travaillé.
| Pas vraiment de question, la suggestion est noté dans la page Wiki.
| Pas de matériel à commander.
|
|
|
|
|-
| P42 [[IMA4 2017/2018 P42|Automatisation de l'assemblage de LEGO]]
| Analyse très correcte.
| Pas de réponse aux questions difficiles "Comment démarrer l'imprimante à distance ? Comment sera calibrée la plaque d’impression ?
Comment la plaque va se fixer sur le sol ? 
| Aucune liste de matériel.
|
|
|
|
|-
| P44 [[IMA4 2017/2018 P44|Reconnaissance d’objets via Traitement d’image]]
| Le projet ne semble pas encore avoir été sérieusement étudié.
| Net effort de documentation de la page Wiki. Pas de réponse directe à la question difficile sur la Kinect mais une discussion sur le problème posé.
| Aucune liste de matériel.
|
|
|
|
|-
| P49 [[IMA4 2017/2018 P49|Suivi de la qualité de l’air]]
| Contexte mal présenté, sujet flou. Scénario d'usage à préciser. Pas de contact avec les encadrants avant la présentation.
| Page de Wiki vide.
| Aucune liste de matériel.
|
|
|
|
|-
| P50 [[IMA4 2017/2018 P50|Etage commande de Centaure]]
| Doublant
| Page de Wiki assez vide.
| Aucune liste de matériel.
|
|
|
|
|-
| P60 [[IMA4 2017/2018 P60|Commande de niveaux d’eau]]
| Présentation très correcte.
| Pas de réponse à la question difficile. Page Wiki un peu vide.
| Pas de matériel à commander.
|
|
|
|
|-
| P64 [[IMA4 2017/2018 P64|Simulation Labview et mise en réseau Modbus d’un ascenseur]]
| Doublant
| Wiki avec quelques informations sur le travail accompli depuis fin novembre : étude sur modbus et labview. Quelques coquilles.
| Aucune liste de matériel.
|
|
|
|
|-
| P65 [[IMA4 2017/2018 P65|Exosquelette pour apprentissage]]
| Présentation sans support. Trouver des concurrents indirects. Pas de scénario d'usage.
| Page Wiki vide.
| Aucune liste de matériel.
|
|
|
|
|-
| P66 [[IMA4 2017/2018 P66|Coupe de France de robotique]]
| Analyse très correcte.
| Page Wiki bien tenue. Ajoutez des illustrations.
| Quelques éléments sur le matériel dans la page Wiki mais aucune liste avec références.
|
|
|
|
|-
| P67 [[IMA4 2017/2018 P67|Scanner 3D DIY]]
| Exercice bien réalisé.
| Page Wiki très complète. Ajoutez des illustrations.
| Une liste probablement pas exhaustive.
|
|
|
|
|-
| P68 [[IMA4 2017/2018 P68|Générateur de chronogrammes d'ordonnancement]]
| Doublant
| Page Wiki vide.
| Pas de matériel à commander.
|
|
|
|
|-
| PP1 [[IMA4 2017/2018 Pré-projet 1|Robot hexapode pour escalier]]
| Erasmus
|
|
|
|
|-
|}

== Fiche de présence ==

{| class="wikitable"
! Projet !! Elèves !! Séance 1 (17/01) !! Séance 2 (24/01) !! Séance 3 (31/01) !! Séance 4 (7/02) !! Séance 5 (14/02) !! Séance 6 (21/02) !! Séance 7 (7/03) !! Séance 8 (14/03) !! Séance 9 (21/03) !! Séance 10 (28/03) !! Séance 11 (4/04) !! Séance 12 (11/04) !! Séance 13 (18/04)
|-
| P1 [[IMA4 2017/2018 P1|Automatisation de la production de bière]]
|Quentin Boëns / Henri Carlier
|E304
|E304/305
|E304

|-
| P3 [[IMA4 2017/2018 P3|Sécurisation de l'Internet des Objets par surveillance globale]]
|Ji Yang
|E306
|E303
|-
| P4 [[IMA4 2017/2018 P4|Développement d'un module d'énergie pour Internet des Objets]]
| Alexis Viscogliosi/ Abass Ayoub
|C008
|C008
|E304
|-
| P5 [[IMA4 2017/2018 P5|Réseau de capteurs de pollution]]
| Paul Ribeiro / Mehanna Naïf
|E303
|E301
|A204
|-
| P6 [[IMA4 2017/2018 P6|Réseau LoRaWAN]]
| Antoine Gosse
| E306
| E306
|-
| P7 [[IMA4 2017/2018 P7|Brique pour apprentissage informatique]]
| Maëva Delaporte / Simon Blas
| E304 
| E304 
| E304 
|-
| P10 [[IMA4 2017/2018 P10|Portage de RIOT-OS sur MSP430 pour IOT]]
| Baptiste Cartier
| E306
| E301
| E306
|-
| P12 [[IMA4 2017/2018 P12|Système d'ostéophonie pour magicien]]
| Amine El Messaoudi / Simon Feutrier
| E301
| C201
|-
| P14 [[IMA4 2017/2018 P14|Ecran géant modulaire]]
| Jade Dupont
|E304
|E304
|E304
|-
| P15 [[IMA4 2017/2018 P15|Balle vibrante connectée pour enfants sourd]]
| Thomas Cunin / Thibault Cattelain
| E304
| B306/E304
|-
| P16 [[IMA4 2017/2018 P16|Sous-chaussure chauffante pour docker]]
| Rémi Mairesse / Gustave Roux
| E304
| E301
|-
| P17 [[IMA4 2017/2018 P17|Safe Watch]]
| Oumaima Naanaa
|E302
|E304
|-
| P18 [[IMA4 2017/2018 P18|Mandala électronique]]
| Lirui Zhang / Lihe Zhang
| E304
| E304
|-
| P19 [[IMA4 2017/2018 P19|Bijou électronique]]
| Lijie Yao / Keren Qiang
| E303
| E304
| E304
|-
| P20 [[IMA4 2017/2018 P20|Solution de messagerie à base de conteneurs]]
| Maxime Creteur / Gao Fan
|E303
|E301
|A204
|-
| P22 [[IMA4 2017/2018 P22|Horloge numérique DCF77, serveur de temps et ludique]]
| Amaury Knockaert / Fabrice Taingland
| E304
| E304
| E304/E302
|-
| P23 [[IMA4 2017/2018 P23|Table de bar connectée]]
| Matthieu Delobelle
| E306
| E306
| E303 - C201
|-
| P25 [[IMA4 2017/2018 P25|Essaim de robots]]
| Benjamin Canu / Ganix Etcheguibel
| E306
| E306
| E306
|-
| P30 [[IMA4 2017/2018 P30|Contrôle d'une caméra WiFi.]]
| Taky Djeraba / Thomas Hubert
| E306
| E306
|-
| P32 [[IMA4 2017/2018 P32|Tribute to Peter Vogel]]
| Jean-Baptiste Watine / Antoine Untereiner
| E306/C201
| E301
|-
| P35 [[IMA4 2017/2018 P35|Manette de jeu vidéo pour personne en situation de handicap]]
| Transley Gracias / Camille Saad
| E306
| E306
| E305
|-
| P39 [[IMA4 2017/2018 P39|Musique des plantes]]
| Xavier Chenot / Rodolphe Toin
| E306
| E306
| E306
|-
| P40 [[IMA4 2017/2018 P40|Exploration du réseau d'anonymisation Tor]]
| Antoine Duquenoy / Anthony Durot
| E306
| E306
|-
| P42 [[IMA4 2017/2018 P42|Automatisation de l'assemblage de LEGO]]
| Eloi Zalczer / Justine Senellart
|E302/E306
|E302/E306
|-
|-
| P44 [[IMA4 2017/2018 P44|Reconnaissance d’objets via Traitement d’image]]
| Damien Narbais / Zoé Briois
| E306
| E301
|-
| P49 [[IMA4 2017/2018 P49|Suivi de la qualité de l’air]]
| Hugo Delbroucq / Nicolas Havard
| E301
| INRIA
|-
| P50 [[IMA4 2017/2018 P50|Etage commande de Centaure]]
|-
| P60 [[IMA4 2017/2018 P60|Commande de niveaux d’eau]]
| Claire Vandamme / Alexandra Villa
|C008
|C008
|-
| P64 [[IMA4 2017/2018 P64|Simulation Labview et mise en réseau Modbus d’un ascenseur]]
|-
| P65 [[IMA4 2017/2018 P65|Exosquelette pour apprentissage]]
| Florian Le Foll
| E301
| E301
|-
| P66 [[IMA4 2017/2018 P66|Coupe de France de robotique]]
| Carval Amaury
| fabricarium
| fabricarium puis Hors Polytech
| E304
|-
| P67 [[IMA4 2017/2018 P67|Scanner 3D DIY]]
| Erwan Dufresne
| E302/E306
| E301
| E304
|-
| P68 [[IMA4 2017/2018 P68|Générateur de chronogrammes d'ordonnancement]]
|}

Fichier:YWGmW.png

2018-01-24T18:15:50Z

Tgracias : Tgracias a téléversé une nouvelle version de Fichier:YWGmW.png

Fichier:FonctionnementSPI.png

2018-01-24T18:14:27Z

Tgracias :

Fichier:YWGmW.png

2018-01-24T18:13:44Z

Tgracias :

IMA4 2017/2018 P35

2018-01-24T18:13:17Z

Tgracias : /* Semaine 1 */

IMA4 2017/2018 P35

2018-01-24T18:11:17Z

Tgracias :

IMA4 2017/2018 P35

2018-01-15T15:23:07Z

Tgracias : /* Réponse à la question difficile */

IMA4 2017/2018 P35

2018-01-15T14:38:01Z

Tgracias : /* Scénario d'usage du produit ou du concept envisagé */

Projet IMA3 P2, 2016/2017, TD2

2017-06-18T13:02:19Z

Tgracias : /* Partie électronique */

= Projet IMA3-SC 2016/2017 : Station Météo =

== Description du système ==

Notre projet est de mettre en place une station météorologique permettant de connaître :
* la température
* la pression
* l'humidité de l'air
* la vitesse du vent
* la luminosité extérieur

Les données de cette station météo seront visible par toute personne se connectant à une application web.

=== Cahier des charges ===
* La station permettra de prendre des mesures chaque heure de manière automatique, mais il devra être possible d'utiliser une interface web afin de prendre des mesures de manière manuelle.
* L'utilisateur pourra accéder à la base de donnée de la station à partir du site web et visualiser les variations des données (température, vitesse du vent, ...) en fonction du temps ou encore d'afficher toutes les données disponibles pour un jour donné.
* La page d'accueil du site doit permettre la visualisation du temps qu'il fait (clair, grisâtre, pluvieux) et de la température actuelle. L'accès aux données enregistrées se fera via un champ de recherche situé plus bas sur la page.

Le capteur température-humidité-pression sera relié à une carte arduino Uno. L'anémomètre ainsi que le capteur de luminosité seront reliés directement à un FPGA.
L'arduino sera elle aussi reliée au FPGA. En effet le capteurs mesurant la température, la pression et l'humidité de l'air communique par protocole SPI avec le microcontrôleur auquel il est relié. C'est pourquoi l'arduino, qui peut communiquer par SPI, fera office d'interface entre le capteur et le FPGA.
La connexion entre le FPGA et la Raspberry Pi se fera par liaison série filaire. Il sera peut-être possible de remplacer, par la suite, la liaison filaire par une liaison sans-fil à l'aide de modules Xbee.

=== Le matériel ===

* 1 Raspberry Pi
* 1 Arduino Uno
* 1 Shield Xbee (pour l'arduino)
* 1 adaptateur Xbee-USB (pour la raspberry)
* 1 XBee T et R
* 1 Capteur température, pression et humidité (BME280)
* 1 Anémomètre fabriqué avec 4 émetteurs/récepteurs ultrason (HC-SR04)
* 1 capteur de luminosité (GA1A1S202WP)

== Git du projet ==
'''L'intégralité du code source du projet se trouve sur l'archive.'''

[https://archives.plil.fr/aknockae/projet_SC_IMA3.git Archive du projet]

L'archive du projet contient tous les codes sources.
Se trouvant dans le dossier /appWeb :
* index.html, page sur laquelle seront affichée les données.
/appWeb/js
* script.js, le script javascript qui gère la communication entre la page et le serveurs.

/prog
* main.c, le script principale C qui gère la communication entre les capteurs et l'application Web.

/code arduino
* serialArduino/, dossier contenant le programme arduino permettant de récupérer les données du capteur BME280, qui les envoient par liaison série à la carte Arduino. Pour l'instant le Xbee n'est pas pris en charge
* Plusieurs dossier contenant la librairie du capteur BME280, les test du port série, de la communication série par Xbee, etc...

== Réalisation ==

=== Partie informatique ===

==== L'application web ====

[[ Image:Capture_web.png | frame | center | 800 | aperçu de l'application web connectée au serveur websockets ]]
L'application web consiste en une page web codé en HTML. La partie dynamique de la page est codée en JavaScript avec l'aide de la bibliothèque Jquery.

La page web contient : 
- Un indicateur permettant d'informer l'utilisateur de l'état de la connexion au serveur websockets 
- Un tableau présentant les relevé météo des capteurs 
- Un bouton permettant de rafraîchir les données 

L'indicateur permet de savoir si l'application est connectée au serveur Websockets, celui-ci se met en rouge si la connexion est absente ou si il y a un problème.
Le tableau affiche des valeurs entières. Ces valeurs n'ont donc qu'un cardinal restreint de 256 valeurs. Ceci constitue une limite principale de notre système, la précision.

Le bouton qui permet de rafraîchir les données est appelle lors du clique, une fonction javascript chargé d'envoyer un signal "GET" au serveur websocket.
Le programme codé en C, envoie alors les données sous forme de 3 octets. Ces 3 octets représentent dans l'ordre, la pression, la température et l’humidité.

Pour gérer les octets de donnée, nous avons utilisé un tableau typé javascript de type Uint8ClampedArray. Toute donnée de ce tableau est de taille 8 bits et sa valeur est un entier non-signé.

Cette structure est très pratique dans notre cas puisque elle permet à la fois de formater la requête "GET" pour l'envoi au serveur websocket mais aussi les donnée reçu du serveur websocket, pour la lecture. La communication entre le site et le serveur se fait par envoi et réception d'une suite d'octets.

Dans le cas de l'émission, chaque lettre du mot "GET" sont converties en un octet. Ces octets sont mis bout à bout en utilisant un tableau typé. Il suffit juste d'envoyer le buffer de données du tableau en argument à la fonction send(), qui envoie les donnée au serveur.

Dans le cas de la réception, le serveur envoie les octets les uns à la suite des autres. L'application web les récupères sous forme d'un buffer. On crée un autre tableau typé à partir de ce buffer, il "découpe" la chaîne d'octet ce qui permet de les différencier et facilite leurs traitement. Enfin on affiche ces octets dans les bonnes cases du tableau.

Étant donné que les valeurs échangée ne vont que de 0 à 255, il a fallut effectuer quelques conversions.
La pression moyenne au niveau de la mer vaut généralement 1013 hPa. Les relevé météo n'ont jamais relevé de pression en dessous de 845 hPa ni au dessus de 1100 hPa. Partant de ce principe, la valeur affichée sur le site ne sortira jamais de cette intervalle de taille 255.

Pour la température, l'intervalle va de -128 à +127 degré.

La mesure de l'humidité ne pose aucun problème puisqu'elle s'effectue en pourcent.

Ces conversions s'effectue avant l'affichage, par le script javascript.

==== Le côté serveur (Raspberry Pi) ====

[[Fichier:Capture_serveur_websockets.png|800px|frame|center|Aperçu de la réponse du serveur websocket quand il a reçu une requête de l'application web]]

=== Partie electronique ===

Le montage électrique final est en 2 partie, la partie Arduino et la partie FPGA.
Le montage Arduino est composé de la partie capteurs et la partie réception constitué d'un module Xbee fixé à un shield, relié à la Raspberry Pi.
Nous utilisons une liaison sans-fil Xbee pour récupérer les données des capteurs. Les Xbee sont des modules échangeant des données par communication série.

Voici la 1ere partie, la partie sensorielle :

[[Fichier:Montage arduino.jpg|800px|frame|center|Partie émetteur du montage Arduino]]

Voici la 2e partie, la réception surla Raspberry Pi

[[Fichier:Receveur_Xbee.jpg‎|800px|frame|center|Partie récepteur du montage Arduino]]

La 2e partie, programmé par FPGA, est l'anémomètre. Ce circuit composé de 2 capteurs ultrasons, permet de détecter la vitesse du vent. Le principe est simple. Le vent est un déplacement de particules qui constituent l'air. Le son est le déplacement d'une onde mécanique dans l'air. Si les particules sont en mouvement pendant le déplacement de l'onde mécanique, alors la vitesse de cette onde est modifiée.
Le premier capteur émet une impulsion, au même moment, on déclenche un chronomètre. Ce chronomètre s'arrête quand le second capteur reçoit l'impulsion.
Il suffit de mesurer la vitesse de l'impulsion. En effectuant sa différence avec la vitesse d'une onde mécanique dans l'air quand les particules sont immobiles, on obtient la vitesse du vent.

[[Fichier:Anemometre.jpg‎|800px|frame|center|Montage de l'anémomètre, ce montage permet de détecter la vitesse du vent dans une direction (au sens vectoriel)]]

== Séance 1 ==

=== Partie électronique ===

Lors de cette première séance, nous avons pu récupérer et nous informer sur les capteurs BME280 et GA1A1S202WP. Après avoir regardé les documentations de ces deux capteurs, nous avons téléchargé la librairie permettant de faire fonctionner le capteur BME280 (https://github.com/adafruit/Adafruit_BME280_Library).

[[Fichier:BME280.jpg|300px|frame|center|Capteur Adafruit BME280. Mesure la pression, la température et l'humiditée]]

Une fois câblé comme il le fallait, nous avons donc d'abord testé le capteur BME280 et écrit un petit script Arduino qui affichait donc la température, la pression et l'humidité. Puis nous avons branché le capteur de luminosité (GA1A1S202WP) seul à l'arduino, et lancé un nouveau script qui affichait alors la luminosité en Lux de l'objet vers lequel on pointait le capteur. On a ainsi pu constaté une grande différence entre un ciel nuageux, le soleil, et la luminosité de la pièce. Ces observation permettront à l'application web de déduire si le temps est clair ou nuageux uniquement grâce aux relevés du luxmètre.

[[Fichier:Luxmetre.jpg‎|300px|frame|center|Capteur Adafruit GA1A12S202, mesure la lumière]]

=== Partie informatique ===

Nous avons effectué les test des capteurs BME280 et luxmètres sur une carte programmable Arduino Uno. Ces test nous ont permis de bien comprendre le fonctionnement de ces 2 capteurs.
Les données du capteur de luminosité se lisent très facilement sur un port analogique.
NOTE:Nous aurions pu le faire fonctionner par FPGA à l'aide d'un convertisseurs analogique numérique.

Le capteur BME280, contrôlé par une puce, communique par protocole I2C ou SPI, nous devons donc utiliser une carte Arduino pour extraire les données du capteurs, du flot d'information envoyé par la puce. De plus, les données des capteurs sont envoyées à la carte arduino, uniquement si une demande de transfert a été envoyé à la puce du capteur. Le programme qui permet de lire les valeurs est donc complexe. Nous utilisons donc les bilbiothèques Adafruit_Sensor.h et Adafruit_BME280.h pour nous faciliter le travail.

== Séance 2 ==

=== Partie électronique ===

Dans le but de faire notre anémomètre, nous avons commencé à faire un montage avec deux capteurs HC-SR04 : nous devons en placer un face à l'autre, le premier captant les ultrasons du second.
En effet, si on sait que v = d/t où v est une vitesse, d une distance et t un temps, le temps mis par les ultrasons pour aller d'un point A vers un point B en étant portés par un vent allant à une vitesse v est : tab = d/(v+c) où c est la vitesse du son. Dans l'autre sens, on obtient tba = d/(c-v) puisque le vent s'oppose à la propagation du son dans ce cas.

[[Fichier:AnémomètreVuArduino.jpg|left|500px|Câblage niveau Arduino]]
[[Fichier:AnémomètreVuUltrasson.jpg|center|500px|Câblage niveau capteur ultrason]] 

=== Partie informatique ===

Initialisation et appairage des 2 modules Xbee. Ces modules servent à rendre sans-fil la connexion entre les capteurs et la Raspberry Pi sur laquelle se trouve le serveur websocket et l'application web. Ce choix est motivé par notre volonté d'avoir une station météo réaliste et portable. Ainsi des mesures peuvent être prise n'importe où.
Des difficultés de configuration ont rendu la réalisation de la tâche, très longue.

Préparation du serveur websocket. Nous utilisons un ordinateur Raspberry Pi comme "cerveau" de notre station météo. Elle se chargera de récupérer les données des capteurs et de les afficher sur l'application web. Nous avons modifié les différents fichiers de configuration. Nous avons notamment modifié les paramètres IP de la carte pour qu'elle soit accessible depuis les ordinateurs de Polytech. L'IP attribuée pour notre carte sera ''172.26.79.15''

== Séance 3 ==

=== Partie électronique ===

Lors de cette séance, on est passé sur Altium pour remplacer l'Arduino est le code par du FPGA.
On a tout d'abord commencer par réduire la vitesse de l'horloge en la divisant successivement après avoir fait le TP de prise en main.
Pour cela, on est passé par différente méthode : via un compteur pour commencer, mais on était obligé de passer par l'ordinateur pour définir la valeur d’arrêt. Puis on a trouvé la méthode des blocs diviseur qui était beaucoup plus simple à mettre en place. Pour visualiser, on utilisait les DEL.

[[Fichier:PremiereVersion.png| 800px| center| Premiers essai ]]

=== Partie informatique ===

Création du squelette HTML du site web et du début du script JavaScript. Nous utilisons uniquement la bibliothèque Jquery pour faciliter la manipulation du code HTML à travers JavaScript. Dans le fichier ''/js/script.js'', nous gérons la communication par le protocole websocket du côté application web. Nous l'initialisons, initialisons la fonction d'envoi et l'algorithme à exécuter quand l'évènement de réception de données est déclenché.
Pour le moment nous ne savons pas comment exactement envoyer les donnée, quel objet transmettre à la méthode ''send()'', pour avoir un bon traitement des données par le serveur.

== Travail complémentaire ==

Cette étape représente une majeure partie de l'avancée du projet.
=== Partie électronique ===

Il est plus ou moins facile de gérer les capteurs ultrason
Il suffit d'envoyer un signal de temps haut 10µs et temps bas supérieurs à 60ms sur la pâte "trig" du capteur et il émet une onde.
Lorsque l'onde est captée le capteur émet sur la pâte "echo" un signal dont le temps haut est proportionnel à la distance. (suite à un problème, on n'a pas pu faire une capture d'écran du schéma définitif)

=== Partie informatique ===

Nous avons décidé du protocole de communication entre application web et capteurs. L'application web doit envoyer le message 'GET' par websocket au serveur. Le programme du serveur envoie la requête 'GET' à l’Arduino, qui envoie un buffer d'octets. Chaque octet représente la valeur d'un capteur. Dans l'ordre d'envoi : la pression, la température, l'humidité, la luminosité. Le programme de la Raspberry Pi a pour rôle de transférer ces données à l'application web, sous le même format et dans le même ordre.
Le script JavaScript décompose le buffer de donnée et affiche le résultat dans les bonnes cases du tableau.

==== Programme serveur ====

Le fichier '''main.c''' contient le code source permettant de faire fonctionner le serveur websocket et la communication série.
La partie série a été relativement facile à mettre en place puisqu'elle est basé sur l'utilisation des fichier en langage C.
En revanche la partie websocket a été la plus compliqué à mettre en place puisqu'il faut suivre un certain protocole pour récupérer les données reçu et envoyer des données.

'''Partie websockets'''

L'étape de réception websocket permet de récupérer le mot 'GET'.
Pour lire des données reçu il faut allouer de la mémoire de la taille du buffer et ajouter la taille des chaînes d'octets enveloppant le buffer. A partir de la on peut stocker dans cette case le contenu ayant pour adresse "'''in'''", étant un argument de la fonction de réception. Dans notre cas, le buffer a pour taille "'''len'''"

requete=malloc(len+LWS_SEND_BUFFER_PRE_PADDING+LWS_SEND_BUFFER_POST_PADDING);
memcpy(requete,in,len);

L'étape d'envoi permet d'envoyer les données des capteurs vers l'application web.
Pour envoyer un message, il faut allouer une case mémoire de taille égale à la taille du buffer à envoyer, plus les octets enveloppant le message.
unsigned char *buf = malloc(LWS_SEND_BUFFER_PRE_PADDING + length + LWS_SEND_BUFFER_POST_PADDING);
Nous avons choisi le type '''char''' (allant de -127 à 127) car il équivaut à une variable de taille 1 octet. Nous l'avons mis unsigned (allant de 0 à 255) uniquement pour pouvoir correctement lire les valeurs des données dans la console. Ceci nous a permis de vérifier que nous recevions les bonnes donnée par le port série. Il faut savoir que le formatage des données n'est utile que si nous voulons afficher les valeurs. Comme nous échangeons 4 octets, nous aurions pu stocker le message entier dans une unique variable de type "'''int'''" puisque ce type de donnée en C est précisément de taille 4 octets.

Ensuite il faut copier le message que l'on souhaite envoyer dans la case mémoire située à l'adresse de la mémoire alloué plus la taille des octets de début :
memcpy (buf + LWS_SEND_BUFFER_PRE_PADDING, reponse, length );
"'''length'''" étant la taille du message sans les octets entourant ce message.

Enfin, on envoie le message avec une fonction fournie par la librairie ''libwebsockets''. Le message se trouve alors à l'adresse buf + LWS_SEND_BUFFER_PRE_PADDING, définie précédemment :
libwebsocket_write(wsi, buf + LWS_SEND_BUFFER_PRE_PADDING, length, LWS_WRITE_BINARY); //LWS_WRITE_TEXT

'''Partie série'''

La fonction '''getDataFromSensors()''' gère la communication série entre la Raspberry Pi et l'arduino/FPGA.

Pour envoyer un octets en série, il faut juste faire un ''write()''. Dans notre cas nous en avons 3, correspondant au message 'GET'. '''sizeOfRequest''' vaut 3.

for(i = 0; i < sizeOfRequest;i++)
{
if(write(sd,(void*)&request[i],sizeof(char))!=1)
{
perror("main.write"); exit(-1);
}
}

Pour recevoir un octet c'est le même principe mais avec la fonction ''read()''. Nous en recevons 4. Ce morceau de code est placé juste après la partie qui envoie un message, car le circuit arduino/FPGA envoie directement les données dès qu'ils reçoivent 'GET' :

for(i=0;i < 4;i++)
{//on lit ce que nous envoie l'arduino à la suite de la requete GET
if(read(sd,(void*)&reponse[i],sizeof(unsigned char))!=1)
{
perror("main.read"); exit(-1);
}
}

== Conclusion ==

Projet IMA3 P2, 2016/2017, TD2

2017-06-18T12:46:23Z

Tgracias : /* Partie électronique */

= Projet IMA3-SC 2016/2017 : Station Météo =

== Description du système ==

Notre projet est de mettre en place une station météorologique permettant de connaître :
* la température
* la pression
* l'humidité de l'air
* la vitesse du vent
* la luminosité extérieur

Les données de cette station météo seront visible par toute personne se connectant à une application web.

=== Cahier des charges ===
* La station permettra de prendre des mesures chaque heure de manière automatique, mais il devra être possible d'utiliser une interface web afin de prendre des mesures de manière manuelle.
* L'utilisateur pourra accéder à la base de donnée de la station à partir du site web et visualiser les variations des données (température, vitesse du vent, ...) en fonction du temps ou encore d'afficher toutes les données disponibles pour un jour donné.
* La page d'accueil du site doit permettre la visualisation du temps qu'il fait (clair, grisâtre, pluvieux) et de la température actuelle. L'accès aux données enregistrées se fera via un champ de recherche situé plus bas sur la page.

Le capteur température-humidité-pression sera relié à une carte arduino Uno. L'anémomètre ainsi que le capteur de luminosité seront reliés directement à un FPGA.
L'arduino sera elle aussi reliée au FPGA. En effet le capteurs mesurant la température, la pression et l'humidité de l'air communique par protocole SPI avec le microcontrôleur auquel il est relié. C'est pourquoi l'arduino, qui peut communiquer par SPI, fera office d'interface entre le capteur et le FPGA.
La connexion entre le FPGA et la Raspberry Pi se fera par liaison série filaire. Il sera peut-être possible de remplacer, par la suite, la liaison filaire par une liaison sans-fil à l'aide de modules Xbee.

=== Le matériel ===

* 1 Raspberry Pi
* 1 Arduino Uno
* 1 Shield Xbee (pour l'arduino)
* 1 adaptateur Xbee-USB (pour la raspberry)
* 1 XBee T et R
* 1 Capteur température, pression et humidité (BME280)
* 1 Anémomètre fabriqué avec 4 émetteurs/récepteurs ultrason (HC-SR04)
* 1 capteur de luminosité (GA1A1S202WP)

== Git du projet ==
'''L'intégralité du code source du projet se trouve sur l'archive.'''

[https://archives.plil.fr/aknockae/projet_SC_IMA3.git Archive du projet]

L'archive du projet contient tous les codes sources.
Se trouvant dans le dossier /appWeb :
* index.html, page sur laquelle seront affichée les données.
/appWeb/js
* script.js, le script javascript qui gère la communication entre la page et le serveurs.

/prog
* main.c, le script principale C qui gère la communication entre les capteurs et l'application Web.

/code arduino
* serialArduino/, dossier contenant le programme arduino permettant de récupérer les données du capteur BME280, qui les envoient par liaison série à la carte Arduino. Pour l'instant le Xbee n'est pas pris en charge
* Plusieurs dossier contenant la librairie du capteur BME280, les test du port série, de la communication série par Xbee, etc...

== Réalisation ==

=== Partie informatique ===

==== L'application web ====

[[ Image:Capture_web.png | frame | center | 800 | aperçu de l'application web connectée au serveur websockets ]]
L'application web consiste en une page web codé en HTML. La partie dynamique de la page est codée en JavaScript avec l'aide de la bibliothèque Jquery.

La page web contient : 
- Un indicateur permettant d'informer l'utilisateur de l'état de la connexion au serveur websockets 
- Un tableau présentant les relevé météo des capteurs 
- Un bouton permettant de rafraîchir les données 

L'indicateur permet de savoir si l'application est connectée au serveur Websockets, celui-ci se met en rouge si la connexion est absente ou si il y a un problème.
Le tableau affiche des valeurs entières. Ces valeurs n'ont donc qu'un cardinal restreint de 256 valeurs. Ceci constitue une limite principale de notre système, la précision.

Le bouton qui permet de rafraîchir les données est appelle lors du clique, une fonction javascript chargé d'envoyer un signal "GET" au serveur websocket.
Le programme codé en C, envoie alors les données sous forme de 3 octets. Ces 3 octets représentent dans l'ordre, la pression, la température et l’humidité.

Pour gérer les octets de donnée, nous avons utilisé un tableau typé javascript de type Uint8ClampedArray. Toute donnée de ce tableau est de taille 8 bits et sa valeur est un entier non-signé.

Cette structure est très pratique dans notre cas puisque elle permet à la fois de formater la requête "GET" pour l'envoi au serveur websocket mais aussi les donnée reçu du serveur websocket, pour la lecture. La communication entre le site et le serveur se fait par envoi et réception d'une suite d'octets.

Dans le cas de l'émission, chaque lettre du mot "GET" sont converties en un octet. Ces octets sont mis bout à bout en utilisant un tableau typé. Il suffit juste d'envoyer le buffer de données du tableau en argument à la fonction send(), qui envoie les donnée au serveur.

Dans le cas de la réception, le serveur envoie les octets les uns à la suite des autres. L'application web les récupères sous forme d'un buffer. On crée un autre tableau typé à partir de ce buffer, il "découpe" la chaîne d'octet ce qui permet de les différencier et facilite leurs traitement. Enfin on affiche ces octets dans les bonnes cases du tableau.

Étant donné que les valeurs échangée ne vont que de 0 à 255, il a fallut effectuer quelques conversions.
La pression moyenne au niveau de la mer vaut généralement 1013 hPa. Les relevé météo n'ont jamais relevé de pression en dessous de 845 hPa ni au dessus de 1100 hPa. Partant de ce principe, la valeur affichée sur le site ne sortira jamais de cette intervalle de taille 255.

Pour la température, l'intervalle va de -128 à +127 degré.

La mesure de l'humidité ne pose aucun problème puisqu'elle s'effectue en pourcent.

Ces conversions s'effectue avant l'affichage, par le script javascript.

==== Le côté serveur (Raspberry Pi) ====

[[Fichier:Capture_serveur_websockets.png|800px|frame|center|Aperçu de la réponse du serveur websocket quand il a reçu une requête de l'application web]]

=== Partie electronique ===

Le montage électrique final est en 2 partie, la partie Arduino et la partie FPGA.
Le montage Arduino est composé de la partie capteurs et la partie réception constitué d'un module Xbee fixé à un shield, relié à la Raspberry Pi.
Nous utilisons une liaison sans-fil Xbee pour récupérer les données des capteurs. Les Xbee sont des modules échangeant des données par communication série.

Voici la 1ere partie, la partie sensorielle :

[[Fichier:Montage arduino.jpg|800px|frame|center|Partie émetteur du montage Arduino]]

Voici la 2e partie, la réception surla Raspberry Pi

[[Fichier:Receveur_Xbee.jpg‎|800px|frame|center|Partie récepteur du montage Arduino]]

La 2e partie, programmé par FPGA, est l'anémomètre. Ce circuit composé de 2 capteurs ultrasons, permet de détecter la vitesse du vent. Le principe est simple. Le vent est un déplacement de particules qui constituent l'air. Le son est le déplacement d'une onde mécanique dans l'air. Si les particules sont en mouvement pendant le déplacement de l'onde mécanique, alors la vitesse de cette onde est modifiée.
Le premier capteur émet une impulsion, au même moment, on déclenche un chronomètre. Ce chronomètre s'arrête quand le second capteur reçoit l'impulsion.
Il suffit de mesurer la vitesse de l'impulsion. En effectuant sa différence avec la vitesse d'une onde mécanique dans l'air quand les particules sont immobiles, on obtient la vitesse du vent.

[[Fichier:Anemometre.jpg‎|800px|frame|center|Montage de l'anémomètre, ce montage permet de détecter la vitesse du vent dans une direction (au sens vectoriel)]]

== Séance 1 ==

=== Partie électronique ===

Lors de cette première séance, nous avons pu récupérer et nous informer sur les capteurs BME280 et GA1A1S202WP. Après avoir regardé les documentations de ces deux capteurs, nous avons téléchargé la librairie permettant de faire fonctionner le capteur BME280 (https://github.com/adafruit/Adafruit_BME280_Library).

[[Fichier:BME280.jpg|300px|frame|center|Capteur Adafruit BME280. Mesure la pression, la température et l'humiditée]]

Une fois câblé comme il le fallait, nous avons donc d'abord testé le capteur BME280 et écrit un petit script Arduino qui affichait donc la température, la pression et l'humidité. Puis nous avons branché le capteur de luminosité (GA1A1S202WP) seul à l'arduino, et lancé un nouveau script qui affichait alors la luminosité en Lux de l'objet vers lequel on pointait le capteur. On a ainsi pu constaté une grande différence entre un ciel nuageux, le soleil, et la luminosité de la pièce. Ces observation permettront à l'application web de déduire si le temps est clair ou nuageux uniquement grâce aux relevés du luxmètre.

[[Fichier:Luxmetre.jpg‎|300px|frame|center|Capteur Adafruit GA1A12S202, mesure la lumière]]

=== Partie informatique ===

Nous avons effectué les test des capteurs BME280 et luxmètres sur une carte programmable Arduino Uno. Ces test nous ont permis de bien comprendre le fonctionnement de ces 2 capteurs.
Les données du capteur de luminosité se lisent très facilement sur un port analogique.
NOTE:Nous aurions pu le faire fonctionner par FPGA à l'aide d'un convertisseurs analogique numérique.

Le capteur BME280, contrôlé par une puce, communique par protocole I2C ou SPI, nous devons donc utiliser une carte Arduino pour extraire les données du capteurs, du flot d'information envoyé par la puce. De plus, les données des capteurs sont envoyées à la carte arduino, uniquement si une demande de transfert a été envoyé à la puce du capteur. Le programme qui permet de lire les valeurs est donc complexe. Nous utilisons donc les bilbiothèques Adafruit_Sensor.h et Adafruit_BME280.h pour nous faciliter le travail.

== Séance 2 ==

=== Partie électronique ===

Dans le but de faire notre anémomètre, nous avons commencé à faire un montage avec deux capteurs HC-SR04 : nous devons en placer un face à l'autre, le premier captant les ultrasons du second.
En effet, si on sait que v = d/t où v est une vitesse, d une distance et t un temps, le temps mis par les ultrasons pour aller d'un point A vers un point B en étant portés par un vent allant à une vitesse v est : tab = d/(v+c) où c est la vitesse du son. Dans l'autre sens, on obtient tba = d/(c-v) puisque le vent s'oppose à la propagation du son dans ce cas.

[[Fichier:AnémomètreVuArduino.jpg|left|500px|Câblage niveau Arduino]]
[[Fichier:AnémomètreVuUltrasson.jpg|center|500px|Câblage niveau capteur ultrason]] 

=== Partie informatique ===

Initialisation et appairage des 2 modules Xbee. Ces modules servent à rendre sans-fil la connexion entre les capteurs et la Raspberry Pi sur laquelle se trouve le serveur websocket et l'application web. Ce choix est motivé par notre volonté d'avoir une station météo réaliste et portable. Ainsi des mesures peuvent être prise n'importe où.
Des difficultés de configuration ont rendu la réalisation de la tâche, très longue.

Préparation du serveur websocket. Nous utilisons un ordinateur Raspberry Pi comme "cerveau" de notre station météo. Elle se chargera de récupérer les données des capteurs et de les afficher sur l'application web. Nous avons modifié les différents fichiers de configuration. Nous avons notamment modifié les paramètres IP de la carte pour qu'elle soit accessible depuis les ordinateurs de Polytech. L'IP attribuée pour notre carte sera ''172.26.79.15''

== Séance 3 ==

=== Partie électronique ===

Lors de cette séance, on est passé sur Altium pour remplacer l'Arduino est le code par du FPGA.
On a tout d'abord commencer par réduire la vitesse de l'horloge en la divisant successivement après avoir fait le TP de prise en main.
Pour cela, on est passé par différente méthode : via un compteur pour commencer, mais on était obligé de passer par l'ordinateur pour définir la valeur d’arrêt. Puis on a trouvé la méthode des blocs diviseur qui était beaucoup plus simple à mettre en place. Pour visualiser, on utilisait les DEL.

[[Fichier:PremiereVersion.png| 800px| center| Premiers essai ]]

=== Partie informatique ===

Création du squelette HTML du site web et du début du script JavaScript. Nous utilisons uniquement la bibliothèque Jquery pour faciliter la manipulation du code HTML à travers JavaScript. Dans le fichier ''/js/script.js'', nous gérons la communication par le protocole websocket du côté application web. Nous l'initialisons, initialisons la fonction d'envoi et l'algorithme à exécuter quand l'évènement de réception de données est déclenché.
Pour le moment nous ne savons pas comment exactement envoyer les donnée, quel objet transmettre à la méthode ''send()'', pour avoir un bon traitement des données par le serveur.

== Travail complémentaire ==

Cette étape représente une majeure partie de l'avancée du projet.
=== Partie électronique ===

=== Partie informatique ===

Nous avons décidé du protocole de communication entre application web et capteurs. L'application web doit envoyer le message 'GET' par websocket au serveur. Le programme du serveur envoie la requête 'GET' à l’Arduino, qui envoie un buffer d'octets. Chaque octet représente la valeur d'un capteur. Dans l'ordre d'envoi : la pression, la température, l'humidité, la luminosité. Le programme de la Raspberry Pi a pour rôle de transférer ces données à l'application web, sous le même format et dans le même ordre.
Le script JavaScript décompose le buffer de donnée et affiche le résultat dans les bonnes cases du tableau.

==== Programme serveur ====

Le fichier '''main.c''' contient le code source permettant de faire fonctionner le serveur websocket et la communication série.
La partie série a été relativement facile à mettre en place puisqu'elle est basé sur l'utilisation des fichier en langage C.
En revanche la partie websocket a été la plus compliqué à mettre en place puisqu'il faut suivre un certain protocole pour récupérer les données reçu et envoyer des données.

'''Partie websockets'''

L'étape de réception websocket permet de récupérer le mot 'GET'.
Pour lire des données reçu il faut allouer de la mémoire de la taille du buffer et ajouter la taille des chaînes d'octets enveloppant le buffer. A partir de la on peut stocker dans cette case le contenu ayant pour adresse "'''in'''", étant un argument de la fonction de réception. Dans notre cas, le buffer a pour taille "'''len'''"

requete=malloc(len+LWS_SEND_BUFFER_PRE_PADDING+LWS_SEND_BUFFER_POST_PADDING);
memcpy(requete,in,len);

L'étape d'envoi permet d'envoyer les données des capteurs vers l'application web.
Pour envoyer un message, il faut allouer une case mémoire de taille égale à la taille du buffer à envoyer, plus les octets enveloppant le message.
unsigned char *buf = malloc(LWS_SEND_BUFFER_PRE_PADDING + length + LWS_SEND_BUFFER_POST_PADDING);
Nous avons choisi le type '''char''' (allant de -127 à 127) car il équivaut à une variable de taille 1 octet. Nous l'avons mis unsigned (allant de 0 à 255) uniquement pour pouvoir correctement lire les valeurs des données dans la console. Ceci nous a permis de vérifier que nous recevions les bonnes donnée par le port série. Il faut savoir que le formatage des données n'est utile que si nous voulons afficher les valeurs. Comme nous échangeons 4 octets, nous aurions pu stocker le message entier dans une unique variable de type "'''int'''" puisque ce type de donnée en C est précisément de taille 4 octets.

Ensuite il faut copier le message que l'on souhaite envoyer dans la case mémoire située à l'adresse de la mémoire alloué plus la taille des octets de début :
memcpy (buf + LWS_SEND_BUFFER_PRE_PADDING, reponse, length );
"'''length'''" étant la taille du message sans les octets entourant ce message.

Enfin, on envoie le message avec une fonction fournie par la librairie ''libwebsockets''. Le message se trouve alors à l'adresse buf + LWS_SEND_BUFFER_PRE_PADDING, définie précédemment :
libwebsocket_write(wsi, buf + LWS_SEND_BUFFER_PRE_PADDING, length, LWS_WRITE_BINARY); //LWS_WRITE_TEXT

'''Partie série'''

La fonction '''getDataFromSensors()''' gère la communication série entre la Raspberry Pi et l'arduino/FPGA.

Pour envoyer un octets en série, il faut juste faire un ''write()''. Dans notre cas nous en avons 3, correspondant au message 'GET'. '''sizeOfRequest''' vaut 3.

for(i = 0; i < sizeOfRequest;i++)
{
if(write(sd,(void*)&request[i],sizeof(char))!=1)
{
perror("main.write"); exit(-1);
}
}

Pour recevoir un octet c'est le même principe mais avec la fonction ''read()''. Nous en recevons 4. Ce morceau de code est placé juste après la partie qui envoie un message, car le circuit arduino/FPGA envoie directement les données dès qu'ils reçoivent 'GET' :

for(i=0;i < 4;i++)
{//on lit ce que nous envoie l'arduino à la suite de la requete GET
if(read(sd,(void*)&reponse[i],sizeof(unsigned char))!=1)
{
perror("main.read"); exit(-1);
}
}

== Conclusion ==

Fichier:PremiereVersion.png

2017-06-18T12:44:11Z

Tgracias :

Projet IMA3 P2, 2016/2017, TD2

2017-06-18T11:05:23Z

Tgracias : /* Séance 2 */

= Projet IMA3-SC 2016/2017 : Station Météo =

== Description du système ==

Notre projet est de mettre en place une station météorologique permettant de connaître :
* la température
* la pression
* l'humidité de l'air
* la vitesse du vent
* la luminosité extérieur

Les données de cette station météo seront visible par toute personne se connectant à une application web.

=== Cahier des charges ===
* La station permettra de prendre des mesures chaque heure de manière automatique, mais il devra être possible d'utiliser une interface web afin de prendre des mesures de manière manuelle.
* L'utilisateur pourra accéder à la base de donnée de la station à partir du site web et visualiser les variations des données (température, vitesse du vent, ...) en fonction du temps ou encore d'afficher toutes les données disponibles pour un jour donné.
* La page d'accueil du site doit permettre la visualisation du temps qu'il fait (clair, grisâtre, pluvieux) et de la température actuelle. L'accès aux données enregistrées se fera via un champ de recherche situé plus bas sur la page.

Le capteur température-humidité-pression sera relié à une carte arduino Uno. L'anémomètre ainsi que le capteur de luminosité seront reliés directement à un FPGA.
L'arduino sera elle aussi reliée au FPGA. En effet le capteurs mesurant la température, la pression et l'humidité de l'air communique par protocole SPI avec le microcontrôleur auquel il est relié. C'est pourquoi l'arduino, qui peut communiquer par SPI, fera office d'interface entre le capteur et le FPGA.
La connexion entre le FPGA et la Raspberry Pi se fera par liaison série filaire. Il sera peut-être possible de remplacer, par la suite, la liaison filaire par une liaison sans-fil à l'aide de modules Xbee.

=== Le matériel ===

* 1 Raspberry Pi
* 1 Arduino Uno
* 1 Shield Xbee (pour l'arduino)
* 1 adaptateur Xbee-USB (pour la raspberry)
* 1 XBee T et R
* 1 Capteur température, pression et humidité (BME280)
* 1 Anémomètre fabriqué avec 4 émetteurs/récepteurs ultrason (HC-SR04)
* 1 capteur de luminosité (GA1A1S202WP)

== Git du projet ==
'''L'intégralité du code source du projet se trouve sur l'archive.'''

[https://archives.plil.fr/aknockae/projet_SC_IMA3.git Archive du projet]

L'archive du projet contient tous les codes sources.
Se trouvant dans le dossier /appWeb :
* index.html, page sur laquelle seront affichée les données.
/appWeb/js
* script.js, le script javascript qui gère la communication entre la page et le serveurs.

/prog
* main.c, le script principale C qui gère la communication entre les capteurs et l'application Web.

/code arduino
* serialArduino/, dossier contenant le programme arduino permettant de récupérer les données du capteur BME280, qui les envoient par liaison série à la carte Arduino. Pour l'instant le Xbee n'est pas pris en charge
* Plusieurs dossier contenant la librairie du capteur BME280, les test du port série, de la communication série par Xbee, etc...

== Réalisation ==

=== Partie informatique ===

==== L'application web ====

[[ Image:Capture_web.png | frame | center | 800 | aperçu de l'application web connectée au serveur websockets ]]
L'application web consiste en une page web codé en HTML. La partie dynamique de la page est codée en JavaScript avec l'aide de la bibliothèque Jquery.

La page web contient : 
- Un indicateur permettant d'informer l'utilisateur de l'état de la connexion au serveur websockets 
- Un tableau présentant les relevé météo des capteurs 
- Un bouton permettant de rafraîchir les données 

L'indicateur permet de savoir si l'application est connectée au serveur Websockets, celui-ci se met en rouge si la connexion est absente ou si il y a un problème.
Le tableau affiche des valeurs entières. Ces valeurs n'ont donc qu'un cardinal restreint de 256 valeurs. Ceci constitue une limite principale de notre système, la précision.

Le bouton qui permet de rafraîchir les données est appelle lors du clique, une fonction javascript chargé d'envoyer un signal "GET" au serveur websocket.
Le programme codé en C, envoie alors les données sous forme de 3 octets. Ces 3 octets représentent dans l'ordre, la pression, la température et l’humidité.

Pour gérer les octets de donnée, nous avons utilisé un tableau typé javascript de type Uint8ClampedArray. Toute donnée de ce tableau est de taille 8 bits et sa valeur est un entier non-signé.

Cette structure est très pratique dans notre cas puisque elle permet à la fois de formater la requête "GET" pour l'envoi au serveur websocket mais aussi les donnée reçu du serveur websocket, pour la lecture. La communication entre le site et le serveur se fait par envoi et réception d'une suite d'octets.

Dans le cas de l'émission, chaque lettre du mot "GET" sont converties en un octet. Ces octets sont mis bout à bout en utilisant un tableau typé. Il suffit juste d'envoyer le buffer de données du tableau en argument à la fonction send(), qui envoie les donnée au serveur.

Dans le cas de la réception, le serveur envoie les octets les uns à la suite des autres. L'application web les récupères sous forme d'un buffer. On crée un autre tableau typé à partir de ce buffer, il "découpe" la chaîne d'octet ce qui permet de les différencier et facilite leurs traitement. Enfin on affiche ces octets dans les bonnes cases du tableau.

Étant donné que les valeurs échangée ne vont que de 0 à 255, il a fallut effectuer quelques conversions.
La pression moyenne au niveau de la mer vaut généralement 1013 hPa. Les relevé météo n'ont jamais relevé de pression en dessous de 845 hPa ni au dessus de 1100 hPa. Partant de ce principe, la valeur affichée sur le site ne sortira jamais de cette intervalle de taille 255.

Pour la température, l'intervalle va de -128 à +127 degré.

La mesure de l'humidité ne pose aucun problème puisqu'elle s'effectue en pourcent.

Ces conversions s'effectue avant l'affichage, par le script javascript.

==== Le côté serveur (Raspberry Pi) ====

[[Fichier:Capture_serveur_websockets.png|800px|frame|center|Aperçu de la réponse du serveur websocket quand il a reçu une requête de l'application web]]

=== Partie electronique ===

Le montage électrique final est en 2 partie, la partie Arduino et la partie FPGA.
Le montage Arduino est composé de la partie capteurs et la partie réception constitué d'un module Xbee fixé à un shield, relié à la Raspberry Pi.
Nous utilisons une liaison sans-fil Xbee pour récupérer les données des capteurs. Les Xbee sont des modules échangeant des données par communication série.

Voici la 1ere partie, la partie sensorielle :

[[Fichier:Montage arduino.jpg|800px|frame|center|Partie émetteur du montage Arduino]]

Voici la 2e partie, la réception surla Raspberry Pi

[[Fichier:Receveur_Xbee.jpg‎|800px|frame|center|Partie récepteur du montage Arduino]]

La 2e partie, programmé par FPGA, est l'anémomètre. Ce circuit composé de 2 capteurs ultrasons, permet de détecter la vitesse du vent. Le principe est simple. Le vent est un déplacement de particules qui constituent l'air. Le son est le déplacement d'une onde mécanique dans l'air. Si les particules sont en mouvement pendant le déplacement de l'onde mécanique, alors la vitesse de cette onde est modifiée.
Le premier capteur émet une impulsion, au même moment, on déclenche un chronomètre. Ce chronomètre s'arrête quand le second capteur reçoit l'impulsion.
Il suffit de mesurer la vitesse de l'impulsion. En effectuant sa différence avec la vitesse d'une onde mécanique dans l'air quand les particules sont immobiles, on obtient la vitesse du vent.

[[Fichier:Anemometre.jpg‎|800px|frame|center|Montage de l'anémomètre, ce montage permet de détecter la vitesse du vent dans une direction (au sens vectoriel)]]

== Séance 1 ==

=== Partie électronique ===

Lors de cette première séance, nous avons pu récupérer et nous informer sur les capteurs BME280 et GA1A1S202WP. Après avoir regardé les documentations de ces deux capteurs, nous avons téléchargé la librairie permettant de faire fonctionner le capteur BME280 (https://github.com/adafruit/Adafruit_BME280_Library).

[[Fichier:BME280.jpg|300px|frame|center|Capteur Adafruit BME280. Mesure la pression, la température et l'humiditée]]

Une fois câblé comme il le fallait, nous avons donc d'abord testé le capteur BME280 et écrit un petit script Arduino qui affichait donc la température, la pression et l'humidité. Puis nous avons branché le capteur de luminosité (GA1A1S202WP) seul à l'arduino, et lancé un nouveau script qui affichait alors la luminosité en Lux de l'objet vers lequel on pointait le capteur. On a ainsi pu constaté une grande différence entre un ciel nuageux, le soleil, et la luminosité de la pièce. Ces observation permettront à l'application web de déduire si le temps est clair ou nuageux uniquement grâce aux relevés du luxmètre.

[[Fichier:Luxmetre.jpg‎|300px|frame|center|Capteur Adafruit GA1A12S202, mesure la lumière]]

=== Partie informatique ===

Nous avons effectué les test des capteurs BME280 et luxmètres sur une carte programmable Arduino Uno. Ces test nous ont permis de bien comprendre le fonctionnement de ces 2 capteurs.
Les données du capteur de luminosité se lisent très facilement sur un port analogique.
NOTE:Nous aurions pu le faire fonctionner par FPGA à l'aide d'un convertisseurs analogique numérique.

Le capteur BME280, contrôlé par une puce, communique par protocole I2C ou SPI, nous devons donc utiliser une carte Arduino pour extraire les données du capteurs, du flot d'information envoyé par la puce. De plus, les données des capteurs sont envoyées à la carte arduino, uniquement si une demande de transfert a été envoyé à la puce du capteur. Le programme qui permet de lire les valeurs est donc complexe. Nous utilisons donc les bilbiothèques Adafruit_Sensor.h et Adafruit_BME280.h pour nous faciliter le travail.

== Séance 2 ==

=== Partie électronique ===

Dans le but de faire notre anémomètre, nous avons commencé à faire un montage avec deux capteurs HC-SR04 : nous devons en placer un face à l'autre, le premier captant les ultrasons du second.
En effet, si on sait que v = d/t où v est une vitesse, d une distance et t un temps, le temps mis par les ultrasons pour aller d'un point A vers un point B en étant portés par un vent allant à une vitesse v est : tab = d/(v+c) où c est la vitesse du son. Dans l'autre sens, on obtient tba = d/(c-v) puisque le vent s'oppose à la propagation du son dans ce cas.

[[Fichier:AnémomètreVuArduino.jpg|left|500px|Câblage niveau Arduino]]
[[Fichier:AnémomètreVuUltrasson.jpg|center|500px|Câblage niveau capteur ultrason]] 

=== Partie informatique ===

Initialisation et appairage des 2 modules Xbee. Ces modules servent à rendre sans-fil la connexion entre les capteurs et la Raspberry Pi sur laquelle se trouve le serveur websocket et l'application web. Ce choix est motivé par notre volonté d'avoir une station météo réaliste et portable. Ainsi des mesures peuvent être prise n'importe où.
Des difficultés de configuration ont rendu la réalisation de la tâche, très longue.

Préparation du serveur websocket. Nous utilisons un ordinateur Raspberry Pi comme "cerveau" de notre station météo. Elle se chargera de récupérer les données des capteurs et de les afficher sur l'application web. Nous avons modifié les différents fichiers de configuration. Nous avons notamment modifié les paramètres IP de la carte pour qu'elle soit accessible depuis les ordinateurs de Polytech. L'IP attribuée pour notre carte sera ''172.26.79.15''

== Séance 3 ==

=== Partie électronique ===

=== Partie informatique ===

Création du squelette HTML du site web et du début du script JavaScript. Nous utilisons uniquement la bibliothèque Jquery pour faciliter la manipulation du code HTML à travers JavaScript. Dans le fichier ''/js/script.js'', nous gérons la communication par le protocole websocket du côté application web. Nous l'initialisons, initialisons la fonction d'envoi et l'algorithme à exécuter quand l'évènement de réception de données est déclenché.
Pour le moment nous ne savons pas comment exactement envoyer les donnée, quel objet transmettre à la méthode ''send()'', pour avoir un bon traitement des données par le serveur.

== Travail complémentaire ==

Cette étape représente une majeure partie de l'avancée du projet.
=== Partie électronique ===

=== Partie informatique ===

Nous avons décidé du protocole de communication entre application web et capteurs. L'application web doit envoyer le message 'GET' par websocket au serveur. Le programme du serveur envoie la requête 'GET' à l’Arduino, qui envoie un buffer d'octets. Chaque octet représente la valeur d'un capteur. Dans l'ordre d'envoi : la pression, la température, l'humidité, la luminosité. Le programme de la Raspberry Pi a pour rôle de transférer ces données à l'application web, sous le même format et dans le même ordre.
Le script JavaScript décompose le buffer de donnée et affiche le résultat dans les bonnes cases du tableau.

==== Programme serveur ====

Le fichier '''main.c''' contient le code source permettant de faire fonctionner le serveur websocket et la communication série.
La partie série a été relativement facile à mettre en place puisqu'elle est basé sur l'utilisation des fichier en langage C.
En revanche la partie websocket a été la plus compliqué à mettre en place puisqu'il faut suivre un certain protocole pour récupérer les données reçu et envoyer des données.

'''Partie websockets'''

L'étape de réception websocket permet de récupérer le mot 'GET'.
Pour lire des données reçu il faut allouer de la mémoire de la taille du buffer et ajouter la taille des chaînes d'octets enveloppant le buffer. A partir de la on peut stocker dans cette case le contenu ayant pour adresse "'''in'''", étant un argument de la fonction de réception. Dans notre cas, le buffer a pour taille "'''len'''"

requete=malloc(len+LWS_SEND_BUFFER_PRE_PADDING+LWS_SEND_BUFFER_POST_PADDING);
memcpy(requete,in,len);

L'étape d'envoi permet d'envoyer les données des capteurs vers l'application web.
Pour envoyer un message, il faut allouer une case mémoire de taille égale à la taille du buffer à envoyer, plus les octets enveloppant le message.
unsigned char *buf = malloc(LWS_SEND_BUFFER_PRE_PADDING + length + LWS_SEND_BUFFER_POST_PADDING);
Nous avons choisi le type '''char''' (allant de -127 à 127) car il équivaut à une variable de taille 1 octet. Nous l'avons mis unsigned (allant de 0 à 255) uniquement pour pouvoir correctement lire les valeurs des données dans la console. Ceci nous a permis de vérifier que nous recevions les bonnes donnée par le port série. Il faut savoir que le formatage des données n'est utile que si nous voulons afficher les valeurs. Comme nous échangeons 4 octets, nous aurions pu stocker le message entier dans une unique variable de type "'''int'''" puisque ce type de donnée en C est précisément de taille 4 octets.

Ensuite il faut copier le message que l'on souhaite envoyer dans la case mémoire située à l'adresse de la mémoire alloué plus la taille des octets de début :
memcpy (buf + LWS_SEND_BUFFER_PRE_PADDING, reponse, length );
"'''length'''" étant la taille du message sans les octets entourant ce message.

Enfin, on envoie le message avec une fonction fournie par la librairie ''libwebsockets''. Le message se trouve alors à l'adresse buf + LWS_SEND_BUFFER_PRE_PADDING, définie précédemment :
libwebsocket_write(wsi, buf + LWS_SEND_BUFFER_PRE_PADDING, length, LWS_WRITE_BINARY); //LWS_WRITE_TEXT

'''Partie série'''

La fonction '''getDataFromSensors()''' gère la communication série entre la Raspberry Pi et l'arduino/FPGA.

Pour envoyer un octets en série, il faut juste faire un ''write()''. Dans notre cas nous en avons 3, correspondant au message 'GET'. '''sizeOfRequest''' vaut 3.

for(i = 0; i < sizeOfRequest;i++)
{
if(write(sd,(void*)&request[i],sizeof(char))!=1)
{
perror("main.write"); exit(-1);
}
}

Pour recevoir un octet c'est le même principe mais avec la fonction ''read()''. Nous en recevons 4. Ce morceau de code est placé juste après la partie qui envoie un message, car le circuit arduino/FPGA envoie directement les données dès qu'ils reçoivent 'GET' :

for(i=0;i < 4;i++)
{//on lit ce que nous envoie l'arduino à la suite de la requete GET
if(read(sd,(void*)&reponse[i],sizeof(unsigned char))!=1)
{
perror("main.read"); exit(-1);
}
}

== Conclusion ==

Projet IMA3 P2, 2016/2017, TD2

2017-06-18T11:01:15Z

Tgracias : /* Partie électronique */

= Projet IMA3-SC 2016/2017 : Station Météo =

== Description du système ==

Notre projet est de mettre en place une station météorologique permettant de connaître :
* la température
* la pression
* l'humidité de l'air
* la vitesse du vent
* la luminosité extérieur

Les données de cette station météo seront visible par toute personne se connectant à une application web.

=== Cahier des charges ===
* La station permettra de prendre des mesures chaque heure de manière automatique, mais il devra être possible d'utiliser une interface web afin de prendre des mesures de manière manuelle.
* L'utilisateur pourra accéder à la base de donnée de la station à partir du site web et visualiser les variations des données (température, vitesse du vent, ...) en fonction du temps ou encore d'afficher toutes les données disponibles pour un jour donné.
* La page d'accueil du site doit permettre la visualisation du temps qu'il fait (clair, grisâtre, pluvieux) et de la température actuelle. L'accès aux données enregistrées se fera via un champ de recherche situé plus bas sur la page.

Le capteur température-humidité-pression sera relié à une carte arduino Uno. L'anémomètre ainsi que le capteur de luminosité seront reliés directement à un FPGA.
L'arduino sera elle aussi reliée au FPGA. En effet le capteurs mesurant la température, la pression et l'humidité de l'air communique par protocole SPI avec le microcontrôleur auquel il est relié. C'est pourquoi l'arduino, qui peut communiquer par SPI, fera office d'interface entre le capteur et le FPGA.
La connexion entre le FPGA et la Raspberry Pi se fera par liaison série filaire. Il sera peut-être possible de remplacer, par la suite, la liaison filaire par une liaison sans-fil à l'aide de modules Xbee.

=== Le matériel ===

* 1 Raspberry Pi
* 1 Arduino Uno
* 1 Shield Xbee (pour l'arduino)
* 1 adaptateur Xbee-USB (pour la raspberry)
* 1 XBee T et R
* 1 Capteur température, pression et humidité (BME280)
* 1 Anémomètre fabriqué avec 4 émetteurs/récepteurs ultrason (HC-SR04)
* 1 capteur de luminosité (GA1A1S202WP)

== Git du projet ==
'''L'intégralité du code source du projet se trouve sur l'archive.'''

[https://archives.plil.fr/aknockae/projet_SC_IMA3.git Archive du projet]

L'archive du projet contient tous les codes sources.
Se trouvant dans le dossier /appWeb :
* index.html, page sur laquelle seront affichée les données.
/appWeb/js
* script.js, le script javascript qui gère la communication entre la page et le serveurs.

/prog
* main.c, le script principale C qui gère la communication entre les capteurs et l'application Web.

/code arduino
* serialArduino/, dossier contenant le programme arduino permettant de récupérer les données du capteur BME280, qui les envoient par liaison série à la carte Arduino. Pour l'instant le Xbee n'est pas pris en charge
* Plusieurs dossier contenant la librairie du capteur BME280, les test du port série, de la communication série par Xbee, etc...

== Réalisation ==

=== Partie informatique ===

==== L'application web ====

[[ Image:Capture_web.png | frame | center | 800 | aperçu de l'application web connectée au serveur websockets ]]
L'application web consiste en une page web codé en HTML. La partie dynamique de la page est codée en JavaScript avec l'aide de la bibliothèque Jquery.

La page web contient : 
- Un indicateur permettant d'informer l'utilisateur de l'état de la connexion au serveur websockets 
- Un tableau présentant les relevé météo des capteurs 
- Un bouton permettant de rafraîchir les données 

L'indicateur permet de savoir si l'application est connectée au serveur Websockets, celui-ci se met en rouge si la connexion est absente ou si il y a un problème.
Le tableau affiche des valeurs entières. Ces valeurs n'ont donc qu'un cardinal restreint de 256 valeurs. Ceci constitue une limite principale de notre système, la précision.

Le bouton qui permet de rafraîchir les données est appelle lors du clique, une fonction javascript chargé d'envoyer un signal "GET" au serveur websocket.
Le programme codé en C, envoie alors les données sous forme de 3 octets. Ces 3 octets représentent dans l'ordre, la pression, la température et l’humidité.

Pour gérer les octets de donnée, nous avons utilisé un tableau typé javascript de type Uint8ClampedArray. Toute donnée de ce tableau est de taille 8 bits et sa valeur est un entier non-signé.

Cette structure est très pratique dans notre cas puisque elle permet à la fois de formater la requête "GET" pour l'envoi au serveur websocket mais aussi les donnée reçu du serveur websocket, pour la lecture. La communication entre le site et le serveur se fait par envoi et réception d'une suite d'octets.

Dans le cas de l'émission, chaque lettre du mot "GET" sont converties en un octet. Ces octets sont mis bout à bout en utilisant un tableau typé. Il suffit juste d'envoyer le buffer de données du tableau en argument à la fonction send(), qui envoie les donnée au serveur.

Dans le cas de la réception, le serveur envoie les octets les uns à la suite des autres. L'application web les récupères sous forme d'un buffer. On crée un autre tableau typé à partir de ce buffer, il "découpe" la chaîne d'octet ce qui permet de les différencier et facilite leurs traitement. Enfin on affiche ces octets dans les bonnes cases du tableau.

Étant donné que les valeurs échangée ne vont que de 0 à 255, il a fallut effectuer quelques conversions.
La pression moyenne au niveau de la mer vaut généralement 1013 hPa. Les relevé météo n'ont jamais relevé de pression en dessous de 845 hPa ni au dessus de 1100 hPa. Partant de ce principe, la valeur affichée sur le site ne sortira jamais de cette intervalle de taille 255.

Pour la température, l'intervalle va de -128 à +127 degré.

La mesure de l'humidité ne pose aucun problème puisqu'elle s'effectue en pourcent.

Ces conversions s'effectue avant l'affichage, par le script javascript.

==== Le côté serveur (Raspberry Pi) ====

[[Fichier:Capture_serveur_websockets.png|800px|frame|center|Aperçu de la réponse du serveur websocket quand il a reçu une requête de l'application web]]

=== Partie electronique ===

Le montage électrique final est en 2 partie, la partie Arduino et la partie FPGA.
Le montage Arduino est composé de la partie capteurs et la partie réception constitué d'un module Xbee fixé à un shield, relié à la Raspberry Pi.
Nous utilisons une liaison sans-fil Xbee pour récupérer les données des capteurs. Les Xbee sont des modules échangeant des données par communication série.

Voici la 1ere partie, la partie sensorielle :

[[Fichier:Montage arduino.jpg|800px|frame|center|Partie émetteur du montage Arduino]]

Voici la 2e partie, la réception surla Raspberry Pi

[[Fichier:Receveur_Xbee.jpg‎|800px|frame|center|Partie récepteur du montage Arduino]]

La 2e partie, programmé par FPGA, est l'anémomètre. Ce circuit composé de 2 capteurs ultrasons, permet de détecter la vitesse du vent. Le principe est simple. Le vent est un déplacement de particules qui constituent l'air. Le son est le déplacement d'une onde mécanique dans l'air. Si les particules sont en mouvement pendant le déplacement de l'onde mécanique, alors la vitesse de cette onde est modifiée.
Le premier capteur émet une impulsion, au même moment, on déclenche un chronomètre. Ce chronomètre s'arrête quand le second capteur reçoit l'impulsion.
Il suffit de mesurer la vitesse de l'impulsion. En effectuant sa différence avec la vitesse d'une onde mécanique dans l'air quand les particules sont immobiles, on obtient la vitesse du vent.

[[Fichier:Anemometre.jpg‎|800px|frame|center|Montage de l'anémomètre, ce montage permet de détecter la vitesse du vent dans une direction (au sens vectoriel)]]

== Séance 1 ==

=== Partie électronique ===

Lors de cette première séance, nous avons pu récupérer et nous informer sur les capteurs BME280 et GA1A1S202WP. Après avoir regardé les documentations de ces deux capteurs, nous avons téléchargé la librairie permettant de faire fonctionner le capteur BME280 (https://github.com/adafruit/Adafruit_BME280_Library).

[[Fichier:BME280.jpg|300px|frame|center|Capteur Adafruit BME280. Mesure la pression, la température et l'humiditée]]

Une fois câblé comme il le fallait, nous avons donc d'abord testé le capteur BME280 et écrit un petit script Arduino qui affichait donc la température, la pression et l'humidité. Puis nous avons branché le capteur de luminosité (GA1A1S202WP) seul à l'arduino, et lancé un nouveau script qui affichait alors la luminosité en Lux de l'objet vers lequel on pointait le capteur. On a ainsi pu constaté une grande différence entre un ciel nuageux, le soleil, et la luminosité de la pièce. Ces observation permettront à l'application web de déduire si le temps est clair ou nuageux uniquement grâce aux relevés du luxmètre.

[[Fichier:Luxmetre.jpg‎|300px|frame|center|Capteur Adafruit GA1A12S202, mesure la lumière]]

=== Partie informatique ===

Nous avons effectué les test des capteurs BME280 et luxmètres sur une carte programmable Arduino Uno. Ces test nous ont permis de bien comprendre le fonctionnement de ces 2 capteurs.
Les données du capteur de luminosité se lisent très facilement sur un port analogique.
NOTE:Nous aurions pu le faire fonctionner par FPGA à l'aide d'un convertisseurs analogique numérique.

Le capteur BME280, contrôlé par une puce, communique par protocole I2C ou SPI, nous devons donc utiliser une carte Arduino pour extraire les données du capteurs, du flot d'information envoyé par la puce. De plus, les données des capteurs sont envoyées à la carte arduino, uniquement si une demande de transfert a été envoyé à la puce du capteur. Le programme qui permet de lire les valeurs est donc complexe. Nous utilisons donc les bilbiothèques Adafruit_Sensor.h et Adafruit_BME280.h pour nous faciliter le travail.

== Séance 2 ==

=== Partie électronique ===

Dans le but de faire notre anémomètre, nous avons commencé à faire un montage avec deux capteurs HC-SR04 : nous devons en placer un face à l'autre, le premier captant les ultrasons du second.
En effet, si on sait que v = d/t où v est une vitesse, d une distance et t un temps, le temps mis par les ultrasons pour aller d'un point A vers un point B en étant portés par un vent allant à une vitesse v est : tab = d/(v+c) où c est la vitesse du son. Dans l'autre sens, on obtient tba = d/(c-v) puisque le vent s'oppose à la propagation du son dans ce cas.

[[Fichier:AnémomètreVuUltrasson.jpg||left|500px|Câblage niveau capteur ultrason]][[Fichier:AnémomètreVuArduino.jpg||right|500px|Câblage niveau Arduino]] 

=== Partie informatique ===

Initialisation et appairage des 2 modules Xbee. Ces modules servent à rendre sans-fil la connexion entre les capteurs et la Raspberry Pi sur laquelle se trouve le serveur websocket et l'application web. Ce choix est motivé par notre volonté d'avoir une station météo réaliste et portable. Ainsi des mesures peuvent être prise n'importe où.
Des difficultés de configuration ont rendu la réalisation de la tâche, très longue.

Préparation du serveur websocket. Nous utilisons un ordinateur Raspberry Pi comme "cerveau" de notre station météo. Elle se chargera de récupérer les données des capteurs et de les afficher sur l'application web. Nous avons modifié les différents fichiers de configuration. Nous avons notamment modifié les paramètres IP de la carte pour qu'elle soit accessible depuis les ordinateurs de Polytech. L'IP attribuée pour notre carte sera ''172.26.79.15''

== Séance 3 ==

=== Partie électronique ===

=== Partie informatique ===

Création du squelette HTML du site web et du début du script JavaScript. Nous utilisons uniquement la bibliothèque Jquery pour faciliter la manipulation du code HTML à travers JavaScript. Dans le fichier ''/js/script.js'', nous gérons la communication par le protocole websocket du côté application web. Nous l'initialisons, initialisons la fonction d'envoi et l'algorithme à exécuter quand l'évènement de réception de données est déclenché.
Pour le moment nous ne savons pas comment exactement envoyer les donnée, quel objet transmettre à la méthode ''send()'', pour avoir un bon traitement des données par le serveur.

== Travail complémentaire ==

Cette étape représente une majeure partie de l'avancée du projet.
=== Partie électronique ===

=== Partie informatique ===

Nous avons décidé du protocole de communication entre application web et capteurs. L'application web doit envoyer le message 'GET' par websocket au serveur. Le programme du serveur envoie la requête 'GET' à l’Arduino, qui envoie un buffer d'octets. Chaque octet représente la valeur d'un capteur. Dans l'ordre d'envoi : la pression, la température, l'humidité, la luminosité. Le programme de la Raspberry Pi a pour rôle de transférer ces données à l'application web, sous le même format et dans le même ordre.
Le script JavaScript décompose le buffer de donnée et affiche le résultat dans les bonnes cases du tableau.

==== Programme serveur ====

Le fichier '''main.c''' contient le code source permettant de faire fonctionner le serveur websocket et la communication série.
La partie série a été relativement facile à mettre en place puisqu'elle est basé sur l'utilisation des fichier en langage C.
En revanche la partie websocket a été la plus compliqué à mettre en place puisqu'il faut suivre un certain protocole pour récupérer les données reçu et envoyer des données.

'''Partie websockets'''

L'étape de réception websocket permet de récupérer le mot 'GET'.
Pour lire des données reçu il faut allouer de la mémoire de la taille du buffer et ajouter la taille des chaînes d'octets enveloppant le buffer. A partir de la on peut stocker dans cette case le contenu ayant pour adresse "'''in'''", étant un argument de la fonction de réception. Dans notre cas, le buffer a pour taille "'''len'''"

requete=malloc(len+LWS_SEND_BUFFER_PRE_PADDING+LWS_SEND_BUFFER_POST_PADDING);
memcpy(requete,in,len);

L'étape d'envoi permet d'envoyer les données des capteurs vers l'application web.
Pour envoyer un message, il faut allouer une case mémoire de taille égale à la taille du buffer à envoyer, plus les octets enveloppant le message.
unsigned char *buf = malloc(LWS_SEND_BUFFER_PRE_PADDING + length + LWS_SEND_BUFFER_POST_PADDING);
Nous avons choisi le type '''char''' (allant de -127 à 127) car il équivaut à une variable de taille 1 octet. Nous l'avons mis unsigned (allant de 0 à 255) uniquement pour pouvoir correctement lire les valeurs des données dans la console. Ceci nous a permis de vérifier que nous recevions les bonnes donnée par le port série. Il faut savoir que le formatage des données n'est utile que si nous voulons afficher les valeurs. Comme nous échangeons 4 octets, nous aurions pu stocker le message entier dans une unique variable de type "'''int'''" puisque ce type de donnée en C est précisément de taille 4 octets.

Ensuite il faut copier le message que l'on souhaite envoyer dans la case mémoire située à l'adresse de la mémoire alloué plus la taille des octets de début :
memcpy (buf + LWS_SEND_BUFFER_PRE_PADDING, reponse, length );
"'''length'''" étant la taille du message sans les octets entourant ce message.

Enfin, on envoie le message avec une fonction fournie par la librairie ''libwebsockets''. Le message se trouve alors à l'adresse buf + LWS_SEND_BUFFER_PRE_PADDING, définie précédemment :
libwebsocket_write(wsi, buf + LWS_SEND_BUFFER_PRE_PADDING, length, LWS_WRITE_BINARY); //LWS_WRITE_TEXT

'''Partie série'''

La fonction '''getDataFromSensors()''' gère la communication série entre la Raspberry Pi et l'arduino/FPGA.

Pour envoyer un octets en série, il faut juste faire un ''write()''. Dans notre cas nous en avons 3, correspondant au message 'GET'. '''sizeOfRequest''' vaut 3.

for(i = 0; i < sizeOfRequest;i++)
{
if(write(sd,(void*)&request[i],sizeof(char))!=1)
{
perror("main.write"); exit(-1);
}
}

Pour recevoir un octet c'est le même principe mais avec la fonction ''read()''. Nous en recevons 4. Ce morceau de code est placé juste après la partie qui envoie un message, car le circuit arduino/FPGA envoie directement les données dès qu'ils reçoivent 'GET' :

for(i=0;i < 4;i++)
{//on lit ce que nous envoie l'arduino à la suite de la requete GET
if(read(sd,(void*)&reponse[i],sizeof(unsigned char))!=1)
{
perror("main.read"); exit(-1);
}
}

== Conclusion ==

Projet IMA3 P2, 2016/2017, TD2

2017-06-18T11:00:43Z

Tgracias : /* Partie électronique */

= Projet IMA3-SC 2016/2017 : Station Météo =

== Description du système ==

Notre projet est de mettre en place une station météorologique permettant de connaître :
* la température
* la pression
* l'humidité de l'air
* la vitesse du vent
* la luminosité extérieur

Les données de cette station météo seront visible par toute personne se connectant à une application web.

=== Cahier des charges ===
* La station permettra de prendre des mesures chaque heure de manière automatique, mais il devra être possible d'utiliser une interface web afin de prendre des mesures de manière manuelle.
* L'utilisateur pourra accéder à la base de donnée de la station à partir du site web et visualiser les variations des données (température, vitesse du vent, ...) en fonction du temps ou encore d'afficher toutes les données disponibles pour un jour donné.
* La page d'accueil du site doit permettre la visualisation du temps qu'il fait (clair, grisâtre, pluvieux) et de la température actuelle. L'accès aux données enregistrées se fera via un champ de recherche situé plus bas sur la page.

Le capteur température-humidité-pression sera relié à une carte arduino Uno. L'anémomètre ainsi que le capteur de luminosité seront reliés directement à un FPGA.
L'arduino sera elle aussi reliée au FPGA. En effet le capteurs mesurant la température, la pression et l'humidité de l'air communique par protocole SPI avec le microcontrôleur auquel il est relié. C'est pourquoi l'arduino, qui peut communiquer par SPI, fera office d'interface entre le capteur et le FPGA.
La connexion entre le FPGA et la Raspberry Pi se fera par liaison série filaire. Il sera peut-être possible de remplacer, par la suite, la liaison filaire par une liaison sans-fil à l'aide de modules Xbee.

=== Le matériel ===

* 1 Raspberry Pi
* 1 Arduino Uno
* 1 Shield Xbee (pour l'arduino)
* 1 adaptateur Xbee-USB (pour la raspberry)
* 1 XBee T et R
* 1 Capteur température, pression et humidité (BME280)
* 1 Anémomètre fabriqué avec 4 émetteurs/récepteurs ultrason (HC-SR04)
* 1 capteur de luminosité (GA1A1S202WP)

== Git du projet ==
'''L'intégralité du code source du projet se trouve sur l'archive.'''

[https://archives.plil.fr/aknockae/projet_SC_IMA3.git Archive du projet]

L'archive du projet contient tous les codes sources.
Se trouvant dans le dossier /appWeb :
* index.html, page sur laquelle seront affichée les données.
/appWeb/js
* script.js, le script javascript qui gère la communication entre la page et le serveurs.

/prog
* main.c, le script principale C qui gère la communication entre les capteurs et l'application Web.

/code arduino
* serialArduino/, dossier contenant le programme arduino permettant de récupérer les données du capteur BME280, qui les envoient par liaison série à la carte Arduino. Pour l'instant le Xbee n'est pas pris en charge
* Plusieurs dossier contenant la librairie du capteur BME280, les test du port série, de la communication série par Xbee, etc...

== Réalisation ==

=== Partie informatique ===

==== L'application web ====

[[ Image:Capture_web.png | frame | center | 800 | aperçu de l'application web connectée au serveur websockets ]]
L'application web consiste en une page web codé en HTML. La partie dynamique de la page est codée en JavaScript avec l'aide de la bibliothèque Jquery.

La page web contient : 
- Un indicateur permettant d'informer l'utilisateur de l'état de la connexion au serveur websockets 
- Un tableau présentant les relevé météo des capteurs 
- Un bouton permettant de rafraîchir les données 

L'indicateur permet de savoir si l'application est connectée au serveur Websockets, celui-ci se met en rouge si la connexion est absente ou si il y a un problème.
Le tableau affiche des valeurs entières. Ces valeurs n'ont donc qu'un cardinal restreint de 256 valeurs. Ceci constitue une limite principale de notre système, la précision.

Le bouton qui permet de rafraîchir les données est appelle lors du clique, une fonction javascript chargé d'envoyer un signal "GET" au serveur websocket.
Le programme codé en C, envoie alors les données sous forme de 3 octets. Ces 3 octets représentent dans l'ordre, la pression, la température et l’humidité.

Pour gérer les octets de donnée, nous avons utilisé un tableau typé javascript de type Uint8ClampedArray. Toute donnée de ce tableau est de taille 8 bits et sa valeur est un entier non-signé.

Cette structure est très pratique dans notre cas puisque elle permet à la fois de formater la requête "GET" pour l'envoi au serveur websocket mais aussi les donnée reçu du serveur websocket, pour la lecture. La communication entre le site et le serveur se fait par envoi et réception d'une suite d'octets.

Dans le cas de l'émission, chaque lettre du mot "GET" sont converties en un octet. Ces octets sont mis bout à bout en utilisant un tableau typé. Il suffit juste d'envoyer le buffer de données du tableau en argument à la fonction send(), qui envoie les donnée au serveur.

Dans le cas de la réception, le serveur envoie les octets les uns à la suite des autres. L'application web les récupères sous forme d'un buffer. On crée un autre tableau typé à partir de ce buffer, il "découpe" la chaîne d'octet ce qui permet de les différencier et facilite leurs traitement. Enfin on affiche ces octets dans les bonnes cases du tableau.

Étant donné que les valeurs échangée ne vont que de 0 à 255, il a fallut effectuer quelques conversions.
La pression moyenne au niveau de la mer vaut généralement 1013 hPa. Les relevé météo n'ont jamais relevé de pression en dessous de 845 hPa ni au dessus de 1100 hPa. Partant de ce principe, la valeur affichée sur le site ne sortira jamais de cette intervalle de taille 255.

Pour la température, l'intervalle va de -128 à +127 degré.

La mesure de l'humidité ne pose aucun problème puisqu'elle s'effectue en pourcent.

Ces conversions s'effectue avant l'affichage, par le script javascript.

==== Le côté serveur (Raspberry Pi) ====

[[Fichier:Capture_serveur_websockets.png|800px|frame|center|Aperçu de la réponse du serveur websocket quand il a reçu une requête de l'application web]]

=== Partie electronique ===

Le montage électrique final est en 2 partie, la partie Arduino et la partie FPGA.
Le montage Arduino est composé de la partie capteurs et la partie réception constitué d'un module Xbee fixé à un shield, relié à la Raspberry Pi.
Nous utilisons une liaison sans-fil Xbee pour récupérer les données des capteurs. Les Xbee sont des modules échangeant des données par communication série.

Voici la 1ere partie, la partie sensorielle :

[[Fichier:Montage arduino.jpg|800px|frame|center|Partie émetteur du montage Arduino]]

Voici la 2e partie, la réception surla Raspberry Pi

[[Fichier:Receveur_Xbee.jpg‎|800px|frame|center|Partie récepteur du montage Arduino]]

La 2e partie, programmé par FPGA, est l'anémomètre. Ce circuit composé de 2 capteurs ultrasons, permet de détecter la vitesse du vent. Le principe est simple. Le vent est un déplacement de particules qui constituent l'air. Le son est le déplacement d'une onde mécanique dans l'air. Si les particules sont en mouvement pendant le déplacement de l'onde mécanique, alors la vitesse de cette onde est modifiée.
Le premier capteur émet une impulsion, au même moment, on déclenche un chronomètre. Ce chronomètre s'arrête quand le second capteur reçoit l'impulsion.
Il suffit de mesurer la vitesse de l'impulsion. En effectuant sa différence avec la vitesse d'une onde mécanique dans l'air quand les particules sont immobiles, on obtient la vitesse du vent.

[[Fichier:Anemometre.jpg‎|800px|frame|center|Montage de l'anémomètre, ce montage permet de détecter la vitesse du vent dans une direction (au sens vectoriel)]]

== Séance 1 ==

=== Partie électronique ===

Lors de cette première séance, nous avons pu récupérer et nous informer sur les capteurs BME280 et GA1A1S202WP. Après avoir regardé les documentations de ces deux capteurs, nous avons téléchargé la librairie permettant de faire fonctionner le capteur BME280 (https://github.com/adafruit/Adafruit_BME280_Library).

[[Fichier:BME280.jpg|300px|frame|center|Capteur Adafruit BME280. Mesure la pression, la température et l'humiditée]]

Une fois câblé comme il le fallait, nous avons donc d'abord testé le capteur BME280 et écrit un petit script Arduino qui affichait donc la température, la pression et l'humidité. Puis nous avons branché le capteur de luminosité (GA1A1S202WP) seul à l'arduino, et lancé un nouveau script qui affichait alors la luminosité en Lux de l'objet vers lequel on pointait le capteur. On a ainsi pu constaté une grande différence entre un ciel nuageux, le soleil, et la luminosité de la pièce. Ces observation permettront à l'application web de déduire si le temps est clair ou nuageux uniquement grâce aux relevés du luxmètre.

[[Fichier:Luxmetre.jpg‎|300px|frame|center|Capteur Adafruit GA1A12S202, mesure la lumière]]

=== Partie informatique ===

Nous avons effectué les test des capteurs BME280 et luxmètres sur une carte programmable Arduino Uno. Ces test nous ont permis de bien comprendre le fonctionnement de ces 2 capteurs.
Les données du capteur de luminosité se lisent très facilement sur un port analogique.
NOTE:Nous aurions pu le faire fonctionner par FPGA à l'aide d'un convertisseurs analogique numérique.

Le capteur BME280, contrôlé par une puce, communique par protocole I2C ou SPI, nous devons donc utiliser une carte Arduino pour extraire les données du capteurs, du flot d'information envoyé par la puce. De plus, les données des capteurs sont envoyées à la carte arduino, uniquement si une demande de transfert a été envoyé à la puce du capteur. Le programme qui permet de lire les valeurs est donc complexe. Nous utilisons donc les bilbiothèques Adafruit_Sensor.h et Adafruit_BME280.h pour nous faciliter le travail.

== Séance 2 ==

=== Partie électronique ===

Dans le but de faire notre anémomètre, nous avons commencé à faire un montage avec deux capteurs HC-SR04 : nous devons en placer un face à l'autre, le premier captant les ultrasons du second.
En effet, si on sait que v = d/t où v est une vitesse, d une distance et t un temps, le temps mis par les ultrasons pour aller d'un point A vers un point B en étant portés par un vent allant à une vitesse v est : tab = d/(v+c) où c est la vitesse du son. Dans l'autre sens, on obtient tba = d/(c-v) puisque le vent s'oppose à la propagation du son dans ce cas.

[[Fichier:AnémomètreVuUltrasson.jpg||left|500px|Câblage niveau capteur ultrason]][[Fichier:AnémomètreVuArduino.jpg||right|500px|Câblage niveau Arduino]]

=== Partie informatique ===

Initialisation et appairage des 2 modules Xbee. Ces modules servent à rendre sans-fil la connexion entre les capteurs et la Raspberry Pi sur laquelle se trouve le serveur websocket et l'application web. Ce choix est motivé par notre volonté d'avoir une station météo réaliste et portable. Ainsi des mesures peuvent être prise n'importe où.
Des difficultés de configuration ont rendu la réalisation de la tâche, très longue.

Préparation du serveur websocket. Nous utilisons un ordinateur Raspberry Pi comme "cerveau" de notre station météo. Elle se chargera de récupérer les données des capteurs et de les afficher sur l'application web. Nous avons modifié les différents fichiers de configuration. Nous avons notamment modifié les paramètres IP de la carte pour qu'elle soit accessible depuis les ordinateurs de Polytech. L'IP attribuée pour notre carte sera ''172.26.79.15''

== Séance 3 ==

=== Partie électronique ===

=== Partie informatique ===

Création du squelette HTML du site web et du début du script JavaScript. Nous utilisons uniquement la bibliothèque Jquery pour faciliter la manipulation du code HTML à travers JavaScript. Dans le fichier ''/js/script.js'', nous gérons la communication par le protocole websocket du côté application web. Nous l'initialisons, initialisons la fonction d'envoi et l'algorithme à exécuter quand l'évènement de réception de données est déclenché.
Pour le moment nous ne savons pas comment exactement envoyer les donnée, quel objet transmettre à la méthode ''send()'', pour avoir un bon traitement des données par le serveur.

== Travail complémentaire ==

Cette étape représente une majeure partie de l'avancée du projet.
=== Partie électronique ===

=== Partie informatique ===

Nous avons décidé du protocole de communication entre application web et capteurs. L'application web doit envoyer le message 'GET' par websocket au serveur. Le programme du serveur envoie la requête 'GET' à l’Arduino, qui envoie un buffer d'octets. Chaque octet représente la valeur d'un capteur. Dans l'ordre d'envoi : la pression, la température, l'humidité, la luminosité. Le programme de la Raspberry Pi a pour rôle de transférer ces données à l'application web, sous le même format et dans le même ordre.
Le script JavaScript décompose le buffer de donnée et affiche le résultat dans les bonnes cases du tableau.

==== Programme serveur ====

Le fichier '''main.c''' contient le code source permettant de faire fonctionner le serveur websocket et la communication série.
La partie série a été relativement facile à mettre en place puisqu'elle est basé sur l'utilisation des fichier en langage C.
En revanche la partie websocket a été la plus compliqué à mettre en place puisqu'il faut suivre un certain protocole pour récupérer les données reçu et envoyer des données.

'''Partie websockets'''

L'étape de réception websocket permet de récupérer le mot 'GET'.
Pour lire des données reçu il faut allouer de la mémoire de la taille du buffer et ajouter la taille des chaînes d'octets enveloppant le buffer. A partir de la on peut stocker dans cette case le contenu ayant pour adresse "'''in'''", étant un argument de la fonction de réception. Dans notre cas, le buffer a pour taille "'''len'''"

requete=malloc(len+LWS_SEND_BUFFER_PRE_PADDING+LWS_SEND_BUFFER_POST_PADDING);
memcpy(requete,in,len);

L'étape d'envoi permet d'envoyer les données des capteurs vers l'application web.
Pour envoyer un message, il faut allouer une case mémoire de taille égale à la taille du buffer à envoyer, plus les octets enveloppant le message.
unsigned char *buf = malloc(LWS_SEND_BUFFER_PRE_PADDING + length + LWS_SEND_BUFFER_POST_PADDING);
Nous avons choisi le type '''char''' (allant de -127 à 127) car il équivaut à une variable de taille 1 octet. Nous l'avons mis unsigned (allant de 0 à 255) uniquement pour pouvoir correctement lire les valeurs des données dans la console. Ceci nous a permis de vérifier que nous recevions les bonnes donnée par le port série. Il faut savoir que le formatage des données n'est utile que si nous voulons afficher les valeurs. Comme nous échangeons 4 octets, nous aurions pu stocker le message entier dans une unique variable de type "'''int'''" puisque ce type de donnée en C est précisément de taille 4 octets.

Ensuite il faut copier le message que l'on souhaite envoyer dans la case mémoire située à l'adresse de la mémoire alloué plus la taille des octets de début :
memcpy (buf + LWS_SEND_BUFFER_PRE_PADDING, reponse, length );
"'''length'''" étant la taille du message sans les octets entourant ce message.

Enfin, on envoie le message avec une fonction fournie par la librairie ''libwebsockets''. Le message se trouve alors à l'adresse buf + LWS_SEND_BUFFER_PRE_PADDING, définie précédemment :
libwebsocket_write(wsi, buf + LWS_SEND_BUFFER_PRE_PADDING, length, LWS_WRITE_BINARY); //LWS_WRITE_TEXT

'''Partie série'''

La fonction '''getDataFromSensors()''' gère la communication série entre la Raspberry Pi et l'arduino/FPGA.

Pour envoyer un octets en série, il faut juste faire un ''write()''. Dans notre cas nous en avons 3, correspondant au message 'GET'. '''sizeOfRequest''' vaut 3.

for(i = 0; i < sizeOfRequest;i++)
{
if(write(sd,(void*)&request[i],sizeof(char))!=1)
{
perror("main.write"); exit(-1);
}
}

Pour recevoir un octet c'est le même principe mais avec la fonction ''read()''. Nous en recevons 4. Ce morceau de code est placé juste après la partie qui envoie un message, car le circuit arduino/FPGA envoie directement les données dès qu'ils reçoivent 'GET' :

for(i=0;i < 4;i++)
{//on lit ce que nous envoie l'arduino à la suite de la requete GET
if(read(sd,(void*)&reponse[i],sizeof(unsigned char))!=1)
{
perror("main.read"); exit(-1);
}
}

== Conclusion ==

Projet IMA3 P2, 2016/2017, TD2

2017-06-18T11:00:04Z

Tgracias : /* Partie électronique */

= Projet IMA3-SC 2016/2017 : Station Météo =

== Description du système ==

Notre projet est de mettre en place une station météorologique permettant de connaître :
* la température
* la pression
* l'humidité de l'air
* la vitesse du vent
* la luminosité extérieur

Les données de cette station météo seront visible par toute personne se connectant à une application web.

=== Cahier des charges ===
* La station permettra de prendre des mesures chaque heure de manière automatique, mais il devra être possible d'utiliser une interface web afin de prendre des mesures de manière manuelle.
* L'utilisateur pourra accéder à la base de donnée de la station à partir du site web et visualiser les variations des données (température, vitesse du vent, ...) en fonction du temps ou encore d'afficher toutes les données disponibles pour un jour donné.
* La page d'accueil du site doit permettre la visualisation du temps qu'il fait (clair, grisâtre, pluvieux) et de la température actuelle. L'accès aux données enregistrées se fera via un champ de recherche situé plus bas sur la page.

Le capteur température-humidité-pression sera relié à une carte arduino Uno. L'anémomètre ainsi que le capteur de luminosité seront reliés directement à un FPGA.
L'arduino sera elle aussi reliée au FPGA. En effet le capteurs mesurant la température, la pression et l'humidité de l'air communique par protocole SPI avec le microcontrôleur auquel il est relié. C'est pourquoi l'arduino, qui peut communiquer par SPI, fera office d'interface entre le capteur et le FPGA.
La connexion entre le FPGA et la Raspberry Pi se fera par liaison série filaire. Il sera peut-être possible de remplacer, par la suite, la liaison filaire par une liaison sans-fil à l'aide de modules Xbee.

=== Le matériel ===

* 1 Raspberry Pi
* 1 Arduino Uno
* 1 Shield Xbee (pour l'arduino)
* 1 adaptateur Xbee-USB (pour la raspberry)
* 1 XBee T et R
* 1 Capteur température, pression et humidité (BME280)
* 1 Anémomètre fabriqué avec 4 émetteurs/récepteurs ultrason (HC-SR04)
* 1 capteur de luminosité (GA1A1S202WP)

== Git du projet ==
'''L'intégralité du code source du projet se trouve sur l'archive.'''

[https://archives.plil.fr/aknockae/projet_SC_IMA3.git Archive du projet]

L'archive du projet contient tous les codes sources.
Se trouvant dans le dossier /appWeb :
* index.html, page sur laquelle seront affichée les données.
/appWeb/js
* script.js, le script javascript qui gère la communication entre la page et le serveurs.

/prog
* main.c, le script principale C qui gère la communication entre les capteurs et l'application Web.

/code arduino
* serialArduino/, dossier contenant le programme arduino permettant de récupérer les données du capteur BME280, qui les envoient par liaison série à la carte Arduino. Pour l'instant le Xbee n'est pas pris en charge
* Plusieurs dossier contenant la librairie du capteur BME280, les test du port série, de la communication série par Xbee, etc...

== Réalisation ==

=== Partie informatique ===

==== L'application web ====

[[ Image:Capture_web.png | frame | center | 800 | aperçu de l'application web connectée au serveur websockets ]]
L'application web consiste en une page web codé en HTML. La partie dynamique de la page est codée en JavaScript avec l'aide de la bibliothèque Jquery.

La page web contient : 
- Un indicateur permettant d'informer l'utilisateur de l'état de la connexion au serveur websockets 
- Un tableau présentant les relevé météo des capteurs 
- Un bouton permettant de rafraîchir les données 

L'indicateur permet de savoir si l'application est connectée au serveur Websockets, celui-ci se met en rouge si la connexion est absente ou si il y a un problème.
Le tableau affiche des valeurs entières. Ces valeurs n'ont donc qu'un cardinal restreint de 256 valeurs. Ceci constitue une limite principale de notre système, la précision.

Le bouton qui permet de rafraîchir les données est appelle lors du clique, une fonction javascript chargé d'envoyer un signal "GET" au serveur websocket.
Le programme codé en C, envoie alors les données sous forme de 3 octets. Ces 3 octets représentent dans l'ordre, la pression, la température et l’humidité.

Pour gérer les octets de donnée, nous avons utilisé un tableau typé javascript de type Uint8ClampedArray. Toute donnée de ce tableau est de taille 8 bits et sa valeur est un entier non-signé.

Cette structure est très pratique dans notre cas puisque elle permet à la fois de formater la requête "GET" pour l'envoi au serveur websocket mais aussi les donnée reçu du serveur websocket, pour la lecture. La communication entre le site et le serveur se fait par envoi et réception d'une suite d'octets.

Dans le cas de l'émission, chaque lettre du mot "GET" sont converties en un octet. Ces octets sont mis bout à bout en utilisant un tableau typé. Il suffit juste d'envoyer le buffer de données du tableau en argument à la fonction send(), qui envoie les donnée au serveur.

Dans le cas de la réception, le serveur envoie les octets les uns à la suite des autres. L'application web les récupères sous forme d'un buffer. On crée un autre tableau typé à partir de ce buffer, il "découpe" la chaîne d'octet ce qui permet de les différencier et facilite leurs traitement. Enfin on affiche ces octets dans les bonnes cases du tableau.

Étant donné que les valeurs échangée ne vont que de 0 à 255, il a fallut effectuer quelques conversions.
La pression moyenne au niveau de la mer vaut généralement 1013 hPa. Les relevé météo n'ont jamais relevé de pression en dessous de 845 hPa ni au dessus de 1100 hPa. Partant de ce principe, la valeur affichée sur le site ne sortira jamais de cette intervalle de taille 255.

Pour la température, l'intervalle va de -128 à +127 degré.

La mesure de l'humidité ne pose aucun problème puisqu'elle s'effectue en pourcent.

Ces conversions s'effectue avant l'affichage, par le script javascript.

==== Le côté serveur (Raspberry Pi) ====

[[Fichier:Capture_serveur_websockets.png|800px|frame|center|Aperçu de la réponse du serveur websocket quand il a reçu une requête de l'application web]]

=== Partie electronique ===

Le montage électrique final est en 2 partie, la partie Arduino et la partie FPGA.
Le montage Arduino est composé de la partie capteurs et la partie réception constitué d'un module Xbee fixé à un shield, relié à la Raspberry Pi.
Nous utilisons une liaison sans-fil Xbee pour récupérer les données des capteurs. Les Xbee sont des modules échangeant des données par communication série.

Voici la 1ere partie, la partie sensorielle :

[[Fichier:Montage arduino.jpg|800px|frame|center|Partie émetteur du montage Arduino]]

Voici la 2e partie, la réception surla Raspberry Pi

[[Fichier:Receveur_Xbee.jpg‎|800px|frame|center|Partie récepteur du montage Arduino]]

La 2e partie, programmé par FPGA, est l'anémomètre. Ce circuit composé de 2 capteurs ultrasons, permet de détecter la vitesse du vent. Le principe est simple. Le vent est un déplacement de particules qui constituent l'air. Le son est le déplacement d'une onde mécanique dans l'air. Si les particules sont en mouvement pendant le déplacement de l'onde mécanique, alors la vitesse de cette onde est modifiée.
Le premier capteur émet une impulsion, au même moment, on déclenche un chronomètre. Ce chronomètre s'arrête quand le second capteur reçoit l'impulsion.
Il suffit de mesurer la vitesse de l'impulsion. En effectuant sa différence avec la vitesse d'une onde mécanique dans l'air quand les particules sont immobiles, on obtient la vitesse du vent.

[[Fichier:Anemometre.jpg‎|800px|frame|center|Montage de l'anémomètre, ce montage permet de détecter la vitesse du vent dans une direction (au sens vectoriel)]]

== Séance 1 ==

=== Partie électronique ===

Lors de cette première séance, nous avons pu récupérer et nous informer sur les capteurs BME280 et GA1A1S202WP. Après avoir regardé les documentations de ces deux capteurs, nous avons téléchargé la librairie permettant de faire fonctionner le capteur BME280 (https://github.com/adafruit/Adafruit_BME280_Library).

[[Fichier:BME280.jpg|300px|frame|center|Capteur Adafruit BME280. Mesure la pression, la température et l'humiditée]]

Une fois câblé comme il le fallait, nous avons donc d'abord testé le capteur BME280 et écrit un petit script Arduino qui affichait donc la température, la pression et l'humidité. Puis nous avons branché le capteur de luminosité (GA1A1S202WP) seul à l'arduino, et lancé un nouveau script qui affichait alors la luminosité en Lux de l'objet vers lequel on pointait le capteur. On a ainsi pu constaté une grande différence entre un ciel nuageux, le soleil, et la luminosité de la pièce. Ces observation permettront à l'application web de déduire si le temps est clair ou nuageux uniquement grâce aux relevés du luxmètre.

[[Fichier:Luxmetre.jpg‎|300px|frame|center|Capteur Adafruit GA1A12S202, mesure la lumière]]

=== Partie informatique ===

Nous avons effectué les test des capteurs BME280 et luxmètres sur une carte programmable Arduino Uno. Ces test nous ont permis de bien comprendre le fonctionnement de ces 2 capteurs.
Les données du capteur de luminosité se lisent très facilement sur un port analogique.
NOTE:Nous aurions pu le faire fonctionner par FPGA à l'aide d'un convertisseurs analogique numérique.

Le capteur BME280, contrôlé par une puce, communique par protocole I2C ou SPI, nous devons donc utiliser une carte Arduino pour extraire les données du capteurs, du flot d'information envoyé par la puce. De plus, les données des capteurs sont envoyées à la carte arduino, uniquement si une demande de transfert a été envoyé à la puce du capteur. Le programme qui permet de lire les valeurs est donc complexe. Nous utilisons donc les bilbiothèques Adafruit_Sensor.h et Adafruit_BME280.h pour nous faciliter le travail.

== Séance 2 ==

=== Partie électronique ===

Dans le but de faire notre anémomètre, nous avons commencé à faire un montage avec deux capteurs HC-SR04 : nous devons en placer un face à l'autre, le premier captant les ultrasons du second.
En effet, si on sait que v = d/t où v est une vitesse, d une distance et t un temps, le temps mis par les ultrasons pour aller d'un point A vers un point B en étant portés par un vent allant à une vitesse v est : tab = d/(v+c) où c est la vitesse du son. Dans l'autre sens, on obtient tba = d/(c-v) puisque le vent s'oppose à la propagation du son dans ce cas.

[[Fichier:AnémomètreVuUltrasson.jpg||left|400px|Câblage niveau capteur ultrason]][[Fichier:AnémomètreVuArduino.jpg||right|400px|Câblage niveau Arduino]]

=== Partie informatique ===

Initialisation et appairage des 2 modules Xbee. Ces modules servent à rendre sans-fil la connexion entre les capteurs et la Raspberry Pi sur laquelle se trouve le serveur websocket et l'application web. Ce choix est motivé par notre volonté d'avoir une station météo réaliste et portable. Ainsi des mesures peuvent être prise n'importe où.
Des difficultés de configuration ont rendu la réalisation de la tâche, très longue.

Préparation du serveur websocket. Nous utilisons un ordinateur Raspberry Pi comme "cerveau" de notre station météo. Elle se chargera de récupérer les données des capteurs et de les afficher sur l'application web. Nous avons modifié les différents fichiers de configuration. Nous avons notamment modifié les paramètres IP de la carte pour qu'elle soit accessible depuis les ordinateurs de Polytech. L'IP attribuée pour notre carte sera ''172.26.79.15''

== Séance 3 ==

=== Partie électronique ===

=== Partie informatique ===

Création du squelette HTML du site web et du début du script JavaScript. Nous utilisons uniquement la bibliothèque Jquery pour faciliter la manipulation du code HTML à travers JavaScript. Dans le fichier ''/js/script.js'', nous gérons la communication par le protocole websocket du côté application web. Nous l'initialisons, initialisons la fonction d'envoi et l'algorithme à exécuter quand l'évènement de réception de données est déclenché.
Pour le moment nous ne savons pas comment exactement envoyer les donnée, quel objet transmettre à la méthode ''send()'', pour avoir un bon traitement des données par le serveur.

== Travail complémentaire ==

Cette étape représente une majeure partie de l'avancée du projet.
=== Partie électronique ===

=== Partie informatique ===

Nous avons décidé du protocole de communication entre application web et capteurs. L'application web doit envoyer le message 'GET' par websocket au serveur. Le programme du serveur envoie la requête 'GET' à l’Arduino, qui envoie un buffer d'octets. Chaque octet représente la valeur d'un capteur. Dans l'ordre d'envoi : la pression, la température, l'humidité, la luminosité. Le programme de la Raspberry Pi a pour rôle de transférer ces données à l'application web, sous le même format et dans le même ordre.
Le script JavaScript décompose le buffer de donnée et affiche le résultat dans les bonnes cases du tableau.

==== Programme serveur ====

Le fichier '''main.c''' contient le code source permettant de faire fonctionner le serveur websocket et la communication série.
La partie série a été relativement facile à mettre en place puisqu'elle est basé sur l'utilisation des fichier en langage C.
En revanche la partie websocket a été la plus compliqué à mettre en place puisqu'il faut suivre un certain protocole pour récupérer les données reçu et envoyer des données.

'''Partie websockets'''

L'étape de réception websocket permet de récupérer le mot 'GET'.
Pour lire des données reçu il faut allouer de la mémoire de la taille du buffer et ajouter la taille des chaînes d'octets enveloppant le buffer. A partir de la on peut stocker dans cette case le contenu ayant pour adresse "'''in'''", étant un argument de la fonction de réception. Dans notre cas, le buffer a pour taille "'''len'''"

requete=malloc(len+LWS_SEND_BUFFER_PRE_PADDING+LWS_SEND_BUFFER_POST_PADDING);
memcpy(requete,in,len);

L'étape d'envoi permet d'envoyer les données des capteurs vers l'application web.
Pour envoyer un message, il faut allouer une case mémoire de taille égale à la taille du buffer à envoyer, plus les octets enveloppant le message.
unsigned char *buf = malloc(LWS_SEND_BUFFER_PRE_PADDING + length + LWS_SEND_BUFFER_POST_PADDING);
Nous avons choisi le type '''char''' (allant de -127 à 127) car il équivaut à une variable de taille 1 octet. Nous l'avons mis unsigned (allant de 0 à 255) uniquement pour pouvoir correctement lire les valeurs des données dans la console. Ceci nous a permis de vérifier que nous recevions les bonnes donnée par le port série. Il faut savoir que le formatage des données n'est utile que si nous voulons afficher les valeurs. Comme nous échangeons 4 octets, nous aurions pu stocker le message entier dans une unique variable de type "'''int'''" puisque ce type de donnée en C est précisément de taille 4 octets.

Ensuite il faut copier le message que l'on souhaite envoyer dans la case mémoire située à l'adresse de la mémoire alloué plus la taille des octets de début :
memcpy (buf + LWS_SEND_BUFFER_PRE_PADDING, reponse, length );
"'''length'''" étant la taille du message sans les octets entourant ce message.

Enfin, on envoie le message avec une fonction fournie par la librairie ''libwebsockets''. Le message se trouve alors à l'adresse buf + LWS_SEND_BUFFER_PRE_PADDING, définie précédemment :
libwebsocket_write(wsi, buf + LWS_SEND_BUFFER_PRE_PADDING, length, LWS_WRITE_BINARY); //LWS_WRITE_TEXT

'''Partie série'''

La fonction '''getDataFromSensors()''' gère la communication série entre la Raspberry Pi et l'arduino/FPGA.

Pour envoyer un octets en série, il faut juste faire un ''write()''. Dans notre cas nous en avons 3, correspondant au message 'GET'. '''sizeOfRequest''' vaut 3.

for(i = 0; i < sizeOfRequest;i++)
{
if(write(sd,(void*)&request[i],sizeof(char))!=1)
{
perror("main.write"); exit(-1);
}
}

Pour recevoir un octet c'est le même principe mais avec la fonction ''read()''. Nous en recevons 4. Ce morceau de code est placé juste après la partie qui envoie un message, car le circuit arduino/FPGA envoie directement les données dès qu'ils reçoivent 'GET' :

for(i=0;i < 4;i++)
{//on lit ce que nous envoie l'arduino à la suite de la requete GET
if(read(sd,(void*)&reponse[i],sizeof(unsigned char))!=1)
{
perror("main.read"); exit(-1);
}
}

== Conclusion ==

Projet IMA3 P2, 2016/2017, TD2

2017-06-18T10:59:11Z

Tgracias : /* Partie électronique */

= Projet IMA3-SC 2016/2017 : Station Météo =

== Description du système ==

Notre projet est de mettre en place une station météorologique permettant de connaître :
* la température
* la pression
* l'humidité de l'air
* la vitesse du vent
* la luminosité extérieur

Les données de cette station météo seront visible par toute personne se connectant à une application web.

=== Cahier des charges ===
* La station permettra de prendre des mesures chaque heure de manière automatique, mais il devra être possible d'utiliser une interface web afin de prendre des mesures de manière manuelle.
* L'utilisateur pourra accéder à la base de donnée de la station à partir du site web et visualiser les variations des données (température, vitesse du vent, ...) en fonction du temps ou encore d'afficher toutes les données disponibles pour un jour donné.
* La page d'accueil du site doit permettre la visualisation du temps qu'il fait (clair, grisâtre, pluvieux) et de la température actuelle. L'accès aux données enregistrées se fera via un champ de recherche situé plus bas sur la page.

Le capteur température-humidité-pression sera relié à une carte arduino Uno. L'anémomètre ainsi que le capteur de luminosité seront reliés directement à un FPGA.
L'arduino sera elle aussi reliée au FPGA. En effet le capteurs mesurant la température, la pression et l'humidité de l'air communique par protocole SPI avec le microcontrôleur auquel il est relié. C'est pourquoi l'arduino, qui peut communiquer par SPI, fera office d'interface entre le capteur et le FPGA.
La connexion entre le FPGA et la Raspberry Pi se fera par liaison série filaire. Il sera peut-être possible de remplacer, par la suite, la liaison filaire par une liaison sans-fil à l'aide de modules Xbee.

=== Le matériel ===

* 1 Raspberry Pi
* 1 Arduino Uno
* 1 Shield Xbee (pour l'arduino)
* 1 adaptateur Xbee-USB (pour la raspberry)
* 1 XBee T et R
* 1 Capteur température, pression et humidité (BME280)
* 1 Anémomètre fabriqué avec 4 émetteurs/récepteurs ultrason (HC-SR04)
* 1 capteur de luminosité (GA1A1S202WP)

== Git du projet ==
'''L'intégralité du code source du projet se trouve sur l'archive.'''

[https://archives.plil.fr/aknockae/projet_SC_IMA3.git Archive du projet]

L'archive du projet contient tous les codes sources.
Se trouvant dans le dossier /appWeb :
* index.html, page sur laquelle seront affichée les données.
/appWeb/js
* script.js, le script javascript qui gère la communication entre la page et le serveurs.

/prog
* main.c, le script principale C qui gère la communication entre les capteurs et l'application Web.

/code arduino
* serialArduino/, dossier contenant le programme arduino permettant de récupérer les données du capteur BME280, qui les envoient par liaison série à la carte Arduino. Pour l'instant le Xbee n'est pas pris en charge
* Plusieurs dossier contenant la librairie du capteur BME280, les test du port série, de la communication série par Xbee, etc...

== Réalisation ==

=== Partie informatique ===

==== L'application web ====

[[ Image:Capture_web.png | frame | center | 800 | aperçu de l'application web connectée au serveur websockets ]]
L'application web consiste en une page web codé en HTML. La partie dynamique de la page est codée en JavaScript avec l'aide de la bibliothèque Jquery.

La page web contient : 
- Un indicateur permettant d'informer l'utilisateur de l'état de la connexion au serveur websockets 
- Un tableau présentant les relevé météo des capteurs 
- Un bouton permettant de rafraîchir les données 

L'indicateur permet de savoir si l'application est connectée au serveur Websockets, celui-ci se met en rouge si la connexion est absente ou si il y a un problème.
Le tableau affiche des valeurs entières. Ces valeurs n'ont donc qu'un cardinal restreint de 256 valeurs. Ceci constitue une limite principale de notre système, la précision.

Le bouton qui permet de rafraîchir les données est appelle lors du clique, une fonction javascript chargé d'envoyer un signal "GET" au serveur websocket.
Le programme codé en C, envoie alors les données sous forme de 3 octets. Ces 3 octets représentent dans l'ordre, la pression, la température et l’humidité.

Pour gérer les octets de donnée, nous avons utilisé un tableau typé javascript de type Uint8ClampedArray. Toute donnée de ce tableau est de taille 8 bits et sa valeur est un entier non-signé.

Cette structure est très pratique dans notre cas puisque elle permet à la fois de formater la requête "GET" pour l'envoi au serveur websocket mais aussi les donnée reçu du serveur websocket, pour la lecture. La communication entre le site et le serveur se fait par envoi et réception d'une suite d'octets.

Dans le cas de l'émission, chaque lettre du mot "GET" sont converties en un octet. Ces octets sont mis bout à bout en utilisant un tableau typé. Il suffit juste d'envoyer le buffer de données du tableau en argument à la fonction send(), qui envoie les donnée au serveur.

Dans le cas de la réception, le serveur envoie les octets les uns à la suite des autres. L'application web les récupères sous forme d'un buffer. On crée un autre tableau typé à partir de ce buffer, il "découpe" la chaîne d'octet ce qui permet de les différencier et facilite leurs traitement. Enfin on affiche ces octets dans les bonnes cases du tableau.

Étant donné que les valeurs échangée ne vont que de 0 à 255, il a fallut effectuer quelques conversions.
La pression moyenne au niveau de la mer vaut généralement 1013 hPa. Les relevé météo n'ont jamais relevé de pression en dessous de 845 hPa ni au dessus de 1100 hPa. Partant de ce principe, la valeur affichée sur le site ne sortira jamais de cette intervalle de taille 255.

Pour la température, l'intervalle va de -128 à +127 degré.

La mesure de l'humidité ne pose aucun problème puisqu'elle s'effectue en pourcent.

Ces conversions s'effectue avant l'affichage, par le script javascript.

==== Le côté serveur (Raspberry Pi) ====

[[Fichier:Capture_serveur_websockets.png|800px|frame|center|Aperçu de la réponse du serveur websocket quand il a reçu une requête de l'application web]]

=== Partie electronique ===

Le montage électrique final est en 2 partie, la partie Arduino et la partie FPGA.
Le montage Arduino est composé de la partie capteurs et la partie réception constitué d'un module Xbee fixé à un shield, relié à la Raspberry Pi.
Nous utilisons une liaison sans-fil Xbee pour récupérer les données des capteurs. Les Xbee sont des modules échangeant des données par communication série.

Voici la 1ere partie, la partie sensorielle :

[[Fichier:Montage arduino.jpg|800px|frame|center|Partie émetteur du montage Arduino]]

Voici la 2e partie, la réception surla Raspberry Pi

[[Fichier:Receveur_Xbee.jpg‎|800px|frame|center|Partie récepteur du montage Arduino]]

La 2e partie, programmé par FPGA, est l'anémomètre. Ce circuit composé de 2 capteurs ultrasons, permet de détecter la vitesse du vent. Le principe est simple. Le vent est un déplacement de particules qui constituent l'air. Le son est le déplacement d'une onde mécanique dans l'air. Si les particules sont en mouvement pendant le déplacement de l'onde mécanique, alors la vitesse de cette onde est modifiée.
Le premier capteur émet une impulsion, au même moment, on déclenche un chronomètre. Ce chronomètre s'arrête quand le second capteur reçoit l'impulsion.
Il suffit de mesurer la vitesse de l'impulsion. En effectuant sa différence avec la vitesse d'une onde mécanique dans l'air quand les particules sont immobiles, on obtient la vitesse du vent.

[[Fichier:Anemometre.jpg‎|800px|frame|center|Montage de l'anémomètre, ce montage permet de détecter la vitesse du vent dans une direction (au sens vectoriel)]]

== Séance 1 ==

=== Partie électronique ===

Lors de cette première séance, nous avons pu récupérer et nous informer sur les capteurs BME280 et GA1A1S202WP. Après avoir regardé les documentations de ces deux capteurs, nous avons téléchargé la librairie permettant de faire fonctionner le capteur BME280 (https://github.com/adafruit/Adafruit_BME280_Library).

[[Fichier:BME280.jpg|300px|frame|center|Capteur Adafruit BME280. Mesure la pression, la température et l'humiditée]]

Une fois câblé comme il le fallait, nous avons donc d'abord testé le capteur BME280 et écrit un petit script Arduino qui affichait donc la température, la pression et l'humidité. Puis nous avons branché le capteur de luminosité (GA1A1S202WP) seul à l'arduino, et lancé un nouveau script qui affichait alors la luminosité en Lux de l'objet vers lequel on pointait le capteur. On a ainsi pu constaté une grande différence entre un ciel nuageux, le soleil, et la luminosité de la pièce. Ces observation permettront à l'application web de déduire si le temps est clair ou nuageux uniquement grâce aux relevés du luxmètre.

[[Fichier:Luxmetre.jpg‎|300px|frame|center|Capteur Adafruit GA1A12S202, mesure la lumière]]

=== Partie informatique ===

Nous avons effectué les test des capteurs BME280 et luxmètres sur une carte programmable Arduino Uno. Ces test nous ont permis de bien comprendre le fonctionnement de ces 2 capteurs.
Les données du capteur de luminosité se lisent très facilement sur un port analogique.
NOTE:Nous aurions pu le faire fonctionner par FPGA à l'aide d'un convertisseurs analogique numérique.

Le capteur BME280, contrôlé par une puce, communique par protocole I2C ou SPI, nous devons donc utiliser une carte Arduino pour extraire les données du capteurs, du flot d'information envoyé par la puce. De plus, les données des capteurs sont envoyées à la carte arduino, uniquement si une demande de transfert a été envoyé à la puce du capteur. Le programme qui permet de lire les valeurs est donc complexe. Nous utilisons donc les bilbiothèques Adafruit_Sensor.h et Adafruit_BME280.h pour nous faciliter le travail.

== Séance 2 ==

=== Partie électronique ===

Dans le but de faire notre anémomètre, nous avons commencé à faire un montage avec deux capteurs HC-SR04 : nous devons en placer un face à l'autre, le premier captant les ultrasons du second.
En effet, si on sait que v = d/t où v est une vitesse, d une distance et t un temps, le temps mis par les ultrasons pour aller d'un point A vers un point B en étant portés par un vent allant à une vitesse v est : tab = d/(v+c) où c est la vitesse du son. Dans l'autre sens, on obtient tba = d/(c-v) puisque le vent s'oppose à la propagation du son dans ce cas.
[[Fichier:AnémomètreVuUltrasson.jpg||left|400px|Câblage niveau capteur ultrason]][[Fichier:AnémomètreVuArduino.jpg||right|400px|Câblage niveau Arduino]]

=== Partie informatique ===

Initialisation et appairage des 2 modules Xbee. Ces modules servent à rendre sans-fil la connexion entre les capteurs et la Raspberry Pi sur laquelle se trouve le serveur websocket et l'application web. Ce choix est motivé par notre volonté d'avoir une station météo réaliste et portable. Ainsi des mesures peuvent être prise n'importe où.
Des difficultés de configuration ont rendu la réalisation de la tâche, très longue.

Préparation du serveur websocket. Nous utilisons un ordinateur Raspberry Pi comme "cerveau" de notre station météo. Elle se chargera de récupérer les données des capteurs et de les afficher sur l'application web. Nous avons modifié les différents fichiers de configuration. Nous avons notamment modifié les paramètres IP de la carte pour qu'elle soit accessible depuis les ordinateurs de Polytech. L'IP attribuée pour notre carte sera ''172.26.79.15''

== Séance 3 ==

=== Partie électronique ===

=== Partie informatique ===

Création du squelette HTML du site web et du début du script JavaScript. Nous utilisons uniquement la bibliothèque Jquery pour faciliter la manipulation du code HTML à travers JavaScript. Dans le fichier ''/js/script.js'', nous gérons la communication par le protocole websocket du côté application web. Nous l'initialisons, initialisons la fonction d'envoi et l'algorithme à exécuter quand l'évènement de réception de données est déclenché.
Pour le moment nous ne savons pas comment exactement envoyer les donnée, quel objet transmettre à la méthode ''send()'', pour avoir un bon traitement des données par le serveur.

== Travail complémentaire ==

Cette étape représente une majeure partie de l'avancée du projet.
=== Partie électronique ===

=== Partie informatique ===

Nous avons décidé du protocole de communication entre application web et capteurs. L'application web doit envoyer le message 'GET' par websocket au serveur. Le programme du serveur envoie la requête 'GET' à l’Arduino, qui envoie un buffer d'octets. Chaque octet représente la valeur d'un capteur. Dans l'ordre d'envoi : la pression, la température, l'humidité, la luminosité. Le programme de la Raspberry Pi a pour rôle de transférer ces données à l'application web, sous le même format et dans le même ordre.
Le script JavaScript décompose le buffer de donnée et affiche le résultat dans les bonnes cases du tableau.

==== Programme serveur ====

Le fichier '''main.c''' contient le code source permettant de faire fonctionner le serveur websocket et la communication série.
La partie série a été relativement facile à mettre en place puisqu'elle est basé sur l'utilisation des fichier en langage C.
En revanche la partie websocket a été la plus compliqué à mettre en place puisqu'il faut suivre un certain protocole pour récupérer les données reçu et envoyer des données.

'''Partie websockets'''

L'étape de réception websocket permet de récupérer le mot 'GET'.
Pour lire des données reçu il faut allouer de la mémoire de la taille du buffer et ajouter la taille des chaînes d'octets enveloppant le buffer. A partir de la on peut stocker dans cette case le contenu ayant pour adresse "'''in'''", étant un argument de la fonction de réception. Dans notre cas, le buffer a pour taille "'''len'''"

requete=malloc(len+LWS_SEND_BUFFER_PRE_PADDING+LWS_SEND_BUFFER_POST_PADDING);
memcpy(requete,in,len);

L'étape d'envoi permet d'envoyer les données des capteurs vers l'application web.
Pour envoyer un message, il faut allouer une case mémoire de taille égale à la taille du buffer à envoyer, plus les octets enveloppant le message.
unsigned char *buf = malloc(LWS_SEND_BUFFER_PRE_PADDING + length + LWS_SEND_BUFFER_POST_PADDING);
Nous avons choisi le type '''char''' (allant de -127 à 127) car il équivaut à une variable de taille 1 octet. Nous l'avons mis unsigned (allant de 0 à 255) uniquement pour pouvoir correctement lire les valeurs des données dans la console. Ceci nous a permis de vérifier que nous recevions les bonnes donnée par le port série. Il faut savoir que le formatage des données n'est utile que si nous voulons afficher les valeurs. Comme nous échangeons 4 octets, nous aurions pu stocker le message entier dans une unique variable de type "'''int'''" puisque ce type de donnée en C est précisément de taille 4 octets.

Ensuite il faut copier le message que l'on souhaite envoyer dans la case mémoire située à l'adresse de la mémoire alloué plus la taille des octets de début :
memcpy (buf + LWS_SEND_BUFFER_PRE_PADDING, reponse, length );
"'''length'''" étant la taille du message sans les octets entourant ce message.

Enfin, on envoie le message avec une fonction fournie par la librairie ''libwebsockets''. Le message se trouve alors à l'adresse buf + LWS_SEND_BUFFER_PRE_PADDING, définie précédemment :
libwebsocket_write(wsi, buf + LWS_SEND_BUFFER_PRE_PADDING, length, LWS_WRITE_BINARY); //LWS_WRITE_TEXT

'''Partie série'''

La fonction '''getDataFromSensors()''' gère la communication série entre la Raspberry Pi et l'arduino/FPGA.

Pour envoyer un octets en série, il faut juste faire un ''write()''. Dans notre cas nous en avons 3, correspondant au message 'GET'. '''sizeOfRequest''' vaut 3.

for(i = 0; i < sizeOfRequest;i++)
{
if(write(sd,(void*)&request[i],sizeof(char))!=1)
{
perror("main.write"); exit(-1);
}
}

Pour recevoir un octet c'est le même principe mais avec la fonction ''read()''. Nous en recevons 4. Ce morceau de code est placé juste après la partie qui envoie un message, car le circuit arduino/FPGA envoie directement les données dès qu'ils reçoivent 'GET' :

for(i=0;i < 4;i++)
{//on lit ce que nous envoie l'arduino à la suite de la requete GET
if(read(sd,(void*)&reponse[i],sizeof(unsigned char))!=1)
{
perror("main.read"); exit(-1);
}
}

== Conclusion ==

Fichier:AnémomètreVuArduino.jpg

2017-06-18T10:13:18Z

Tgracias : On peut voir ici le câblage de l’Arduino on à utilisé une breadboard supplémentaire pour pouvoir jouer sur la distance.

On peut voir ici le câblage de l’Arduino on à utilisé une breadboard supplémentaire pour pouvoir jouer sur la distance.

Fichier:AnémomètreVuUltrasson.jpg

2017-06-18T10:11:08Z

Tgracias : On peut voir le câblage qui est le même des deux cotés

On peut voir le câblage qui est le même des deux cotés