IMA4 2017/2018 P35 : Différence entre versions
(→Feuille d'heures) |
|||
(81 révisions intermédiaires par 3 utilisateurs non affichées) | |||
Ligne 1 : | Ligne 1 : | ||
+ | <include nopre noesc src="/home/pedago/pimasc/include/video-ManetteModulable-iframe.html" /> | ||
__TOC__ | __TOC__ | ||
<br style="clear: both;"/> | <br style="clear: both;"/> | ||
Ligne 16 : | Ligne 17 : | ||
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. | 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%" | {| class="wikitable centre" width="80%" | ||
Ligne 41 : | Ligne 41 : | ||
Centre SSR Marc Sautelet à Villeneuve d'Ascq | Centre SSR Marc Sautelet à Villeneuve d'Ascq | ||
|} | |} | ||
+ | |||
==<span style="color: Black">Objectifs</span>== | ==<span style="color: Black">Objectifs</span>== | ||
Ligne 52 : | Ligne 53 : | ||
* Des boutons gâchettes progressives (type L2/R2). | * 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. | + | 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. |
+ | |||
+ | |||
=<span style="color: RoyalBlue">Analyse du projet</span>= | =<span style="color: RoyalBlue">Analyse du projet</span>= | ||
+ | |||
==<span style="color: Black">Positionnement par rapport à l'existant</span>== | ==<span style="color: Black">Positionnement par rapport à l'existant</span>== | ||
Ligne 61 : | Ligne 65 : | ||
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 | 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. | design de notre manette. | ||
− | Le patient n’est pas retreint à jouer à une seule main, à utiliser beaucoup de force...Il y a moins de | + | Le patient n’est pas retreint à jouer à une seule main, à utiliser beaucoup de force...Il y a moins de techniques 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 | + | manette adaptée uniquement pour un droitier ou un gaucher. Cependant, cela nous limitera peut-être dans le choix possible des types de jeux. |
− | manettes | + | Tout comme les autres manettes adaptées, l’utilisateur nécessitera un peu d’entrainement. |
− | ==<span style="color: Black">Analyse du premier concurrent</span>== | + | |
+ | ==<span style="color: Black">Analyse du premier concurrent : Manette sous forme de gant</span>== | ||
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. | 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 | + | Un autre gant a fait son apparition quelques années plus tard. Celui-ci, plus technique, il fait 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 utilise les 4 boutons d'action 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). | 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: | ; Problèmes: | ||
− | *Besoin de toute la motricité de la main, c’est-à-dire que si le patient | + | *Besoin de toute la motricité de la main, c’est-à-dire que si le patient a un doigt paralysé ou manquant, il ne pourra pas jouer avec ce gant |
*Design obligatoirement droitier | *Design obligatoirement droitier | ||
*Les boutons de contrôle sont peu sensibles et peuvent nécessiter de la force | *Les boutons de contrôle sont peu sensibles et peuvent nécessiter de la force | ||
Ligne 80 : | Ligne 85 : | ||
;Lien : https://www.youtube.com/watch?v=qV0SxSJDCYg | ;Lien : https://www.youtube.com/watch?v=qV0SxSJDCYg | ||
− | + | ||
==<span style="color: Black">Analyse du second concurrent</span>== | ==<span style="color: Black">Analyse du second concurrent</span>== | ||
− | 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 | + | 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. |
− | 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. |
− | 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 | ||
; Problèmes: | ; Problèmes: | ||
− | *Besoin de toute la motricité de la main, c’est-à-dire que si le patient | + | *Besoin de toute la motricité de la main, c’est-à-dire que si le patient a un doigt paralysé ou manquant, il ne pourra pas jouer avec cette manette |
*Design obligatoirement droitier ou gaucher, une modification = une manette= une personne | *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. | *Besoin obligé du pouce et de l’index, même si avantage : 3 doigts nécessaire. | ||
;Lien :: https://www.youtube.com/watch?v=LieHIscadjk | ;Lien :: https://www.youtube.com/watch?v=LieHIscadjk | ||
+ | |||
==<span style="color: Black">Scénario d'usage du produit ou du concept envisagé</span>== | ==<span style="color: Black">Scénario d'usage du produit ou du concept envisagé</span>== | ||
− | La technologie est ,aujourd’hui, omniprésente dans notre vie. Les consoles de jeux ont | + | La technologie est, aujourd’hui, omniprésente dans notre vie. Les consoles de jeux ont envahi 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. | 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. | 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 | + | Cette manette aidera fortement dans les centres de rééducation pour faire passer le temps et donner du plaisir à des personnes qui ne peuvent plus s’amuser avec leurs consoles traditionnelles. 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. | 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. | 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. | 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. | ||
+ | |||
==<span style="color: Black">Fonctionnement</span>== | ==<span style="color: Black">Fonctionnement</span>== | ||
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. | 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 | + | |
− | une jambe ou même un pied. Il suffira de les | + | 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és avec différents membres du corps : un doigt, une main, |
+ | une jambe ou même un pied. Il suffira de les connecter 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 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é. | ||
Ligne 119 : | Ligne 126 : | ||
==<span style="color: Black">Réponse à la question difficile</span>== | ==<span style="color: Black">Réponse à la question difficile</span>== | ||
− | |||
− | 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. | + | ;'''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. | 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). | + | :Concernant l'interconnexion des modules, nous travaillerons en deux étapes "preuves concept" : filaire et sans fils (Bluetooth). |
− | '''Objectif 1 : Preuve concept filaire''' | + | ;'''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 | + | :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 électroniques 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''' | + | ;'''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)''' | ||
− | |||
− | |||
− | |||
=<span style="color: RoyalBlue">Préparation du projet</span>= | =<span style="color: RoyalBlue">Préparation du projet</span>= | ||
Ligne 145 : | Ligne 155 : | ||
''Elèves-ingénieurs:'' Camille Saâd, Transley Gracias <br> | ''Elèves-ingénieurs:'' Camille Saâd, Transley Gracias <br> | ||
− | + | ;Sujet : Manette modulable pour personne à déficience moteur compatible PlayStation 4 <br> | |
− | + | '''Objectif principal (1er POC) :''' | |
− | |||
− | |||
− | + | Faire transmettre des informations issues des actionneurs (ex:boutons poussoires) via des arduinos jusqu’à la Raspberry Pi 3 en SPI.<br> | |
− | Créer des modules avec un microcontrôleur et une puce bluetooth pour permettre une | + | Envoyer les données reçues vers la PS4 en USB. |
− | + | ||
+ | '''Objectif secondaire (2e POC):''' | ||
+ | |||
+ | Créer des modules avec un microcontrôleur et une puce bluetooth pour permettre une meilleure flexibilité (c-à-d pouvoir avoir une meilleure ergonomie et une connexion sans fil).<br> | ||
+ | Configurer la Raspberry Pi 3 en Bluetooth et transmission à la PS4. | ||
[[Fichier: beteacorne.jpg||middle|600px|Bete a corne manette]] | [[Fichier: beteacorne.jpg||middle|600px|Bete a corne manette]] | ||
Ligne 161 : | Ligne 173 : | ||
===Liste de matériel :=== | ===Liste de matériel :=== | ||
− | + | '''Modules boutons/joysticks/gachettes''' | |
3 Push buttons :<br> | 3 Push buttons :<br> | ||
Ligne 174 : | Ligne 186 : | ||
1 buttons trigger L1 L2 => 1x Thumbstick original''' <br> | 1 buttons trigger L1 L2 => 1x Thumbstick original''' <br> | ||
− | + | '''Cartes Atmega328p /connexion spi/''' | |
3 Arduino UNO <br> | 3 Arduino UNO <br> | ||
Ligne 183 : | Ligne 195 : | ||
2 atmega328p-pu et support <br> | 2 atmega328p-pu et support <br> | ||
− | + | '''Cartes module bluetooth nrf52810 ''' | |
− | |||
6 capacités 100nF 0603 <br> | 6 capacités 100nF 0603 <br> | ||
Ligne 195 : | Ligne 206 : | ||
2 oscillateur quartz 32 MHz <br> | 2 oscillateur quartz 32 MHz <br> | ||
− | + | ''' Connexions et autres ''' | |
1 Led RGB neopixel [https://www.adafruit.com/product/1734] <br> | 1 Led RGB neopixel [https://www.adafruit.com/product/1734] <br> | ||
Ligne 209 : | Ligne 220 : | ||
===Logiciels:=== | ===Logiciels:=== | ||
− | + | * IDE arduino | |
− | + | * Altium | |
− | + | * FreeCAD ou Inkscape | |
==<span style="color: Black">Liste des tâches à effectuer</span>== | ==<span style="color: Black">Liste des tâches à effectuer</span>== | ||
Ligne 218 : | Ligne 229 : | ||
* Définition des cahiers des charges fonctionnel et technique, choix d'orientation... | * Définition des cahiers des charges fonctionnel et technique, choix d'orientation... | ||
− | * | + | * Recherches 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 SPI entre les modules et la RPi3 | ||
# Recherche connexion bluetooth entre la RPi3 et la PS4 | # Recherche connexion bluetooth entre la RPi3 et la PS4 | ||
Ligne 228 : | Ligne 239 : | ||
<u>'''Etape 2: Réalisation du projet'''</u> | <u>'''Etape 2: Réalisation du projet'''</u> | ||
− | '''Partie 1: Preuve concept manette en filaire''' | + | *'''Partie 1: Preuve concept manette en filaire''' |
− | * Conception de cartes électroniques pour 2 modules (/!\ prévoir modules bluetooth) | + | ** 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. | + | **Réalisation connexion SPI avec 2 modules : programmation des Atmega328p en liaison série. |
− | * Si tests | + | ** Si tests concluants, ajouter des modules jusqu'à en avoir 5 (1 pour chaque type de boutons) |
− | * Connexion bluetooth entre la PS4 et la RPi3 | + | ** Connexion bluetooth entre la PS4 et la RPi3 |
− | * Réalisation du support des modules avec fixations possibles (imprimante 3D) | + | ** Réalisation du support des modules avec fixations possibles (imprimante 3D) |
− | '''Partie 2: Preuve concept manette en bluetooth''' | + | *'''Partie 2: Preuve concept manette en bluetooth''' |
− | * Ajout des modules bluetooth aux cartes électroniques | + | ** Ajout des modules bluetooth aux cartes électroniques |
− | * Connexion bluetooth entre les modules | + | ** Connexion bluetooth entre les modules |
− | '''Partie 3: Application Android : paramétrage de la manette''' | + | *'''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) | + | ** Créer une application sur tablette ou smartphone (Android) afin de configurer la manette aux besoins (inter-connexion des modules et console) |
==<span style="color: Black">Calendrier prévisionnel</span>== | ==<span style="color: Black">Calendrier prévisionnel</span>== | ||
Ligne 285 : | Ligne 296 : | ||
| width="34%" | | | width="34%" | | ||
Seance 14 : Test prototype Bluetooth | 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%" | | |width="23%" | | ||
Ligne 294 : | Ligne 315 : | ||
=<span style="color: RoyalBlue">Réalisation du Projet</span>= | =<span style="color: RoyalBlue">Réalisation du Projet</span>= | ||
− | ==<span style="color: Black">Feuille d'heures</span>== | + | ==<span style="color: Black">Feuille d'heures </span>== |
+ | |||
+ | Voici le tableau d'heures du binôme: | ||
{| class="wikitable" | {| class="wikitable" | ||
− | !Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Total | + | !Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Heures S11 !! Heures S12 !! Heures S13et+ !! Total |
|- | |- | ||
| Analyse du projet | | Analyse du projet | ||
Ligne 309 : | Ligne 332 : | ||
| | | | ||
| | | | ||
+ | | | ||
| | | | ||
| | | | ||
− | | | + | | 20min |
+ | | 2 | ||
+ | | 17h20 | ||
|- | |- | ||
| Cherches techniques | | Cherches techniques | ||
Ligne 321 : | Ligne 347 : | ||
| 2 | | 2 | ||
| 1 | | 1 | ||
− | | | + | | |
− | | | + | | |
− | | | + | | |
− | | | + | | 1 |
− | | | + | | |
+ | | 1 | ||
+ | | 5 | ||
+ | | 23 | ||
|- | |- | ||
| Rédaction du wiki et rapport de projet | | Rédaction du wiki et rapport de projet | ||
Ligne 336 : | Ligne 365 : | ||
| 1 | | 1 | ||
| | | | ||
+ | | 2 | ||
+ | | 30min | ||
+ | | 30min | ||
| | | | ||
− | | | + | | 2 |
− | | | + | | 17 |
− | | | + | | 27h30 |
|- | |- | ||
− | | Programmation | + | | Programmation des communications des modules vers RPi et RPi vers Console |
| | | | ||
| | | | ||
Ligne 349 : | Ligne 381 : | ||
| 2 | | 2 | ||
| 3 | | 3 | ||
− | | | + | | 5 |
− | | | + | | 4 |
− | | | + | | 7 |
− | | | + | | 8 |
− | | | + | | 6 |
+ | | 5 | ||
+ | | 46 | ||
+ | | 89 | ||
|- | |- | ||
− | | | + | | Conception des modules: cartes électroniques |
| | | | ||
| | | | ||
Ligne 363 : | Ligne 398 : | ||
| 6 | | 6 | ||
| 8 | | 8 | ||
− | | | + | | 4 |
− | | | + | | 6 |
− | | | + | | 2 |
− | | | + | | 1 |
− | | | + | | 2 |
+ | | 2 | ||
+ | | 1 | ||
+ | | 32 | ||
|- | |- | ||
− | | Application | + | | Application Androïd |
| | | | ||
| | | | ||
Ligne 380 : | Ligne 418 : | ||
| | | | ||
| | | | ||
+ | | 1 | ||
| | | | ||
− | | | + | | 4 |
+ | | 12 | ||
+ | | 17 | ||
|- | |- | ||
|- | |- | ||
Ligne 392 : | Ligne 433 : | ||
| 10h30 | | 10h30 | ||
| 13 | | 13 | ||
− | | | + | | 9 |
− | | | + | | 12 |
− | | | + | | 9h30 |
− | | | + | | 10h30 |
− | | | + | | 9 |
+ | | 13h20 | ||
+ | | 83 | ||
+ | | '''205h50''' | ||
|} | |} | ||
Ligne 406 : | Ligne 450 : | ||
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 : | 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 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 | + | *# Prototype Bluetooth: connexion Bluetooth entre modules-RPi3-PS4-apllication |
[[Fichier: structuremanette.png||center|400px|Concept manette modulable]] | [[Fichier: structuremanette.png||center|400px|Concept manette modulable]] | ||
+ | |||
==<span style="color: Black">Semaine 1</span>== | ==<span style="color: Black">Semaine 1</span>== | ||
− | Durant la séance, nous nous sommes concentrés sur | + | Durant la séance, nous nous sommes concentrés sur 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 : | Ainsi, nous avons fait des recherches sur : | ||
Ligne 425 : | Ligne 470 : | ||
[[Fichier: yWGmW.png||right|200px|Concept manette modulable]] | [[Fichier: yWGmW.png||right|200px|Concept manette modulable]] | ||
− | Comme indiqué sur l'image ci- | + | Comme indiqué sur l'image ci-contre, 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. | 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 | + | 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]] | [[Fichier: fonctionnementSPI.png||right|200px|Connexion SPI multi-esclaves]] | ||
Ligne 433 : | Ligne 479 : | ||
Voici un schéma du fonctionnement souhaité : | 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. | + | 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 | + | 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. | |
− | + | Caracteristiques pour la PS4: Bluetooth®v4.0, Qualcomm Atheros AR3002 Buetooth LE: 2,4-2,5 GHz <br/> | |
− | + | Caracteristiques de la connexion : <br/> | |
− | *Vitesse de transmission >> 3 Mbit/s 8N1 | + | **Vitesse de transmission >> 3 Mbit/s 8N1 |
− | *Relevé tous les 1.3 millisecond (peut-être) | + | **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 | + | **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 | + | **Protocole de détection est le SDP basé sur une emission reception PDU |
− | *L’Attribut ID est representer en TLV Type Length Value | + | **L’Attribut ID est representer en TLV Type Length Value |
− | *Communication HCI ACL Data Packet | + | **Communication HCI ACL Data Packet |
===Rélisation des cartes électroniques=== | ===Rélisation des cartes électroniques=== | ||
− | + | Matériel nécessaire pour un PCB : <br/> | |
*breadboard | *breadboard | ||
Ligne 468 : | Ligne 515 : | ||
==<span style="color: Black">Semaine 2</span>== | ==<span style="color: Black">Semaine 2</span>== | ||
− | Durant la semaine deux et durant la séance, nous avons continué et | + | Durant la semaine deux et durant la séance, nous avons continué et approfondi nos recherches sur le projet. Nous avons pu ainsi affiner nos tâches de réalisation et donc notre cahier des charges. |
− | ===Bluetooth | + | ===Communication modules-RPi: SPI et Bluetooth === |
− | + | '''Recherches :''' | |
(sudo apt-get install pi-bluetooth) | (sudo apt-get install pi-bluetooth) | ||
− | + | ;connexion sur la raspberry par ssh: | |
su | su | ||
update-rc.d ssh enable | update-rc.d ssh enable | ||
Ligne 483 : | Ligne 530 : | ||
− | + | ;Bluetooth: | |
bluetoothctl | bluetoothctl | ||
agent on | agent on | ||
Ligne 490 : | Ligne 537 : | ||
pair [device Bluetooth address] (exemple: pair XX:XX:XX:XX:XX:XX ) | 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'' | ''NOUVELLE REFLEXION : Connexion SPI entre les modules (Atmega328p) et la RPi3 --> MODULES BLUETOOTH'' | ||
Ligne 496 : | Ligne 544 : | ||
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. | 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... | 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... | ||
Ligne 503 : | Ligne 551 : | ||
===Connexion Bluetooth PS4-RPi3=== | ===Connexion Bluetooth PS4-RPi3=== | ||
− | + | Suite à nos recherches de la semaine précédente, nous avons sélectionné deux sites bien renseignés. Ils nous ont permis de comprendre la communication entre la manette et la console. En effet, ils nous expliquent les échanges de trames Bluetooth. | |
+ | |||
==<span style="color: Black">Semaine 3 : Début premier prototype</span>== | ==<span style="color: Black">Semaine 3 : Début premier prototype</span>== | ||
− | + | ===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. | 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. | ||
Ligne 518 : | Ligne 567 : | ||
Durant la séance, nous avons recherches des exemples de codes et de librairies pour Arduino SPI et RaspberryPI SPI. | 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 | + | 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 les utiliser. |
− | + | ===Réalisation du projet Git=== | |
Création du projet IMA4_Projet35_ManetteModulable sur Git et partage de celui-ci. | Création du projet IMA4_Projet35_ManetteModulable sur Git et partage de celui-ci. | ||
− | Les premiers | + | Les premiers dossiers créés durant cette la séance : |
-Arduino (connexion SPI arduino) : ProtoSpi.c + dossier librairie SPI + Makefile | -Arduino (connexion SPI arduino) : ProtoSpi.c + dossier librairie SPI + Makefile | ||
-RPI (dossier codes pour Rpi) | -RPI (dossier codes pour Rpi) | ||
-Readme.md | -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. | ||
+ | |||
+ | On a décidé de commencer par une connexion USB (pour laquelle on dispose de toutes les informations) celle-ci étant plus complète. | ||
Ligne 539 : | Ligne 595 : | ||
#Remplacer les "PCB arduino" par le module bluetooth et adapter la connexion | #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" | #Conception 3D de la délimitation 1 axe pour le joystick "gâchette" | ||
− | #Réalisation de l'application | + | #Réalisation de l'application Androïd. |
− | Une fois ces étapes réalisées nous | + | Une fois ces étapes réalisées, nous aurons 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. | 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=== | ===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 | + | Nous avons également besoin du matériel cité en semaine 1 pour réaliser des circuits électroniques atmega328p-pu standalone. ( Nous revenons alors sur les décisions de la semaine 3) |
===Connexion SPI RPi3-Arduino=== | ===Connexion SPI RPi3-Arduino=== | ||
Ligne 578 : | Ligne 634 : | ||
===Connexion USB PS4-RPi3=== | ===Connexion USB PS4-RPi3=== | ||
+ | Durant cette, nous avons regardé comment faire cohabiter bluetooth, Application Androïd, USB, PS4, SPI et les modules. | ||
− | + | Il est alors important de savoir comment utiliser le port série sur la RPi3, soit utiliser les UARTs. | |
− | Nous avons | + | Nous avons réalisé qu'il n'était pas aussi simple d'utiliser le port série 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. | + | 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. | ||
− | |||
==<span style="color: Black">Semaine 5</span>== | ==<span style="color: Black">Semaine 5</span>== | ||
− | ===Programmation === | + | ===Programmation: Réflexion définitives prototypes filaire === |
+ | |||
+ | La semaine dernière, nous avons rencontré une difficulté liée aux ports séries UARTs. | ||
+ | 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. | |
− | + | Nous avons pu voir que 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 | + | En attendant la réception de la commande, nous nous sommes penchés sur les recherches pour les programmes et la configuration nécessaire à l'utilisation de la RPi zero W. |
===Electronique=== | ===Electronique=== | ||
[[Fichier: bouton_c1.jpg|100px|thumb|left|PCB bouton]] | [[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 circuit électronique afin de faciliter les branchements. | ||
+ | |||
+ | Il nous faut alors également une 3ème 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, ceux-ci doivent être soudés 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]] | |
− | |||
− | [[Fichier: Arduino_c1.jpg|100px|thumb| | ||
− | |||
=== Construction 3D === | === Construction 3D === | ||
Ligne 611 : | Ligne 674 : | ||
==<span style="color: Black">Semaine 6</span>== | ==<span style="color: Black">Semaine 6</span>== | ||
− | ===Programmation === | + | ===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. | + | 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=== | + | ===Electronique: PCB nrf52810=== |
Les cartes réalisées en semaine 5 sont validées et en attente de réalisation. | Les cartes réalisées en semaine 5 sont validées et en attente de réalisation. | ||
Ligne 621 : | Ligne 685 : | ||
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. | 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. | 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 | + | La carte est en attente de validation, puis réalisation. |
− | |||
− | |||
+ | [[Fichier: nrf52810_circuit2.jpg||center|400px|PCB carte nrf52810]] | ||
===Révision matériel === | ===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: | 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 | + | (les quantités indiquées ci-dessous pourront être augmentées 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:''' | '''Cartes Arduino:''' | ||
Ligne 651 : | Ligne 714 : | ||
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] | 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] | ||
+ | |||
==<span style="color: Black">Semaine 7</span>== | ==<span style="color: Black">Semaine 7</span>== | ||
− | ===Programmation === | + | ===Programmation: Connexion wifi sur RPi Zero W et configuration USB=== |
+ | |||
+ | 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 configuré l'OS Jessie, utilisé pour la RPi Zero. On a modifié le fichier cmd.txt. | ||
+ | Nous avons étudié comme avoir un périphérique USB gadget sur le port OTG, et pouvoir programmer ce périphérique, on a besoin de ConfigFs. Il s'agit d'un système de fichiers virtuels permettant de créer des périphériques USB. | ||
− | + | ===Programmation: Bootloader sur Atmega328p-pu === | |
− | Nous avons également | + | Nous avons également continué les programmes de récupération de données : état des boutons et du joystick. Ces programmes sont appliqués 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 : | 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 | + | Nous avons 2 Atmega328p-pu neufs, ainsi il nous faut charger un amorceur 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 | + | Pour cela, on peut utiliser une carte arduino UNO. On vérifie le port et le type de carte sélectionné 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 | + | Puis on met l'atmega328p-pu qui nous intéresse sur le support socket de la carte. On change de nouveau le programmateur pour "Arduino as ISP" et on fait >tools>burn bootloader, soit >graver la séquence d'initialisation. |
− | Ces étapes faites, on peut retirer notre | + | Ces étapes faites, on peut retirer notre microcontrôleur 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. | 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 | + | Nous avons réalisé 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. |
− | ===Electronique === | + | [[Fichier: montage_BB_test.jpg||left|200px|programmation modules arduino sur breadboard]] |
+ | |||
+ | ===Electronique : soudure carte de tests pour 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. | 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 | + | Durant la semaine 7, nous avons soudé les composants traversants de la carte électronique correspondante à ce montage ainsi que le PCB du bouton. |
+ | |||
==<span style="color: Black">Semaine 8</span>== | ==<span style="color: Black">Semaine 8</span>== | ||
Ligne 681 : | Ligne 752 : | ||
===Programmation === | ===Programmation === | ||
− | ===Electronique=== | + | Après moult recherches sur les différents site web bien fournis,on a 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 échanger 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éussi à 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 | + | Durant cette semaine, nous avons souhaité programmer la carte électronique atmega328p-pu. Cependant, nous avons réalisé 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. | 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 | + | 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 pins 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évues pour le téléversement des programmes sur la carte. Il nous faut alors couper une piste et souder des câbles pour avoir toutes les pistes souhaitées. |
+ | |||
+ | [[Fichier: correction_proto_PCB.jpg||right|200px|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. | 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. | ||
+ | |||
====Comment souder des CMS ?==== | ====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 : | 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) | # 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) | # 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 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, | + | # Appliquer les CMS sur la pâte au fur et à mesure (attention ! ne jamais toucher les CMS avec les doigts, toujours utiliser une pince) |
# Mettre au four | # Mettre au four | ||
+ | [[Fichier: PCB_nrf52810.jpg||left|200px|carte electroniques imprimées]] | ||
====Bilan soudure nrf52810==== | ====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 | + | 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 commencé 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) | 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 | + | Après la réalisation du schéma d'implémentation, nous avons modifié les empreintes des capacités, des inductances et autres composants de 0402 à 0603. En effet, notre matériel ne disponible n'était qu'en 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 | + | 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 6mil, il nous faut alors passer les pistes en taille inférieure. 6mil est la taille minimale pour la production à Polytech, mais le 6mil n'est pas conseillée. 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... | 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... | ||
+ | ==<span style="color: Black">Semaine 9</span>== | ||
+ | |||
+ | ===Programmation: reconnaissance en tant que manette PS4=== | ||
+ | |||
+ | Les premiers tests sur Windows ne nous donnent pas satisfaction. En effet, l'ordinateur détectait bien le nouvel appareil avec son nom mais l'origine reste inconnue. | ||
− | ==<span style="color: Black">Semaine | + | 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 | ||
+ | |||
+ | ===Programmation: Premiers tests SPI sur la carte Atmega328p==== | ||
+ | |||
+ | Une carte PCB atmega 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 configuré la partie communication SPI pour l'atmega. | ||
+ | |||
+ | '''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 octet "0x01" de la RPi et retourne une valeur sauvegardé. 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). | ||
+ | |||
+ | 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 pouvoir 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 basiques 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. | ||
+ | |||
+ | |||
+ | ==<span style="color: Black">Semaine 10</span>== | ||
+ | |||
+ | ===Programmation: Raspberry Pi implémentation périphérique USB en tant qu e manette PS4=== | ||
+ | |||
+ | Nous avons continué le travail effectué pour pouvoir programmer un périphérique USB sur le port OTG. | ||
+ | Comme nous l'avions vu, il est nécessaire de faire des configurations préalables avec ConfigFs. Nous avons procédé aux réglage suivants: | ||
+ | *Rajouter dtoverlay=dwc2 dans le fichier boot/config.txt: ce qui permet de charger le driver dwc2 pour la gestion de l’OTG qui se trouve dans le noyau. | ||
+ | *Rajouter dwc2 et libcomposite dans le fichier data/etc/modules pour initialiser configFs. | ||
+ | |||
+ | [[Fichier: identifiManette.png||middle|300px|détection de la manette en périphérique USB]] | ||
+ | |||
+ | Ainsi cette semaine, pour tester la prise OTG, nous avons décidé de lancer un script 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 quelques modifications et plusieurs petits bugs, nous avons réussi à faire fonctionner le ssh via le port OTG. | ||
+ | |||
+ | Cependant, notre problème reste le même, notre script mélangé avec les informations sur la PS4 n'est toujours pas fonctionnel. | ||
+ | |||
+ | ===Programmation: 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 pour le côté de la raspberry pi. Cette semaine a permis une étude plus approfondie 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. | ||
+ | Notre code en C se compose de 3 étapes : | ||
+ | * L'initialisation et la configuration de la communication SPI vue par la RPi (nombre de bits par mots échangés, vitesse, mode, maître ou esclave...). | ||
+ | * L'envoi d'une requête par exemple "0x0A" soit "\n". | ||
+ | * Réception des données octet par octet sur le bus en retour. | ||
+ | |||
+ | Deux bibliothèques sont importantes : | ||
+ | #include <sys/ioctl.h> //Pour la transmission | ||
+ | #include <linux/spi/spidev.h> //Pour SPI | ||
+ | |||
+ | On va déclarer des variables globales qu'on utilisera pour la configuration : | ||
+ | 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 périphérique 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); | ||
+ | |||
+ | ===Application: début et principe=== | ||
+ | |||
+ | 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. | ||
+ | |||
+ | Voici le principe d'application que nous souhaitons développer : | ||
+ | Par définition de notre projet, la manette doit être modulaire. De ce fait, les boutons seront amenés à changer. Ainsi, l'utilisateur devra choisir les boutons qu'il veut utiliser et les faire glisser sur la position du bouton de la manette officielle. On réalise la correspondance entre les boutons modulaires et les boutons officiaux. Le joueur n'est pas obligé de respecter les types de boutons prévus de base : par exemple joystick à la place des flèches directionnelle ou bouton carré au lieu de la flèche du haut. | ||
+ | |||
+ | |||
+ | ==<span style="color: Black">Semaine 11</span>== | ||
+ | |||
+ | ===Programmation: PS4, SSH et tests SPI (RPi3&Atemga328p)=== | ||
+ | |||
+ | '''Raspberry Pi Zero W et PS4''' | ||
+ | |||
+ | Lors de recherches supplémentaires, nous avons essayé 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 installé 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. | ||
+ | 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êmes codes fonctionnels sur les cartes atmega328p définitives. | ||
+ | |||
+ | [[Fichier: ArduinoSPI.png||left|300px|Code Arduino-SPI]] | ||
+ | [[Fichier: fonctiontransfer.png||right|300px|Code Raspberry-SPI]] | ||
+ | A la fin de cette semaine, nous avons alors des codes Atmega-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. | ||
+ | Pour les modules, le plus important est la déclaration des interruptions "quand envoyer les octets d'états?" puis la boucle d'envoie avec SPI.tranfer() (voir photo gauche). | ||
+ | |||
+ | Quant à la raspberry, le plus important est la fonction transfer(). Elle permet d'envoyer un tableau d'octets par SPI et de retourner le tableau d'octets quelle peut recevoir en retour (voir photo droite). | ||
+ | |||
+ | ===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 éviter 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. | ||
+ | |||
+ | ==<span style="color: Black">Semaine 12</span>== | ||
+ | |||
+ | ===Programmation=== | ||
+ | |||
+ | '''Raspberry Pi Zero W et PS4''' | ||
+ | |||
+ | Cette semaine nous avons décidé de prendre un cap temporaire. On a utilisé un script pour faire un pseudo clavier/souris pour essayer d'envoyer nos données. Nous avons modifié petit à petit jusqu’à avoir un script/programme compatible PC. Il devra ce faire passer pour un Joystick donc une manette classique. | ||
+ | |||
+ | '''Raspberry PI, Atmega328p et SPI''' | ||
+ | |||
+ | Lors de cette semaine, nous avons entièrement abandonné les arduinos pour garder uniquement nos cartes électroniques Atmega328p-pu enfin imprimés, soudées, alimentées et prêtes à l'emploi. Nous avons alors continué les test SPI pour un seul device sur celles-ci jusqu'à réussir la récupération des valeurs des capteurs (bouton ou joystick) et commencé une ébauche de programmation pour deux devices. | ||
+ | Notre programme pour un device fonctionne de la manière suivante : | ||
+ | # La RPi envoie en SPI un tableau avec la valeur 0x0A soit "\n" en première position et que des 0x00 par la suite. | ||
+ | # L'arduino reçoit 0x0A, elle va lire l'état du bouton ou de la variable voulue du joystick (par exemple l'axe X) | ||
+ | #L'arduino renvoie cette valeur | ||
+ | Nous avons continué les tests afin d'envoyer plusieurs valeurs en même temps. Ces tests se sont fait sans succés. En effet le SPI envoie octet par octet, ce qui rend la communication plus difficile quand on a plusieurs valeurs à transmettre. | ||
+ | |||
+ | Réflexion:. | ||
+ | * Penser à faire le programme en boucle à chaque réception de 0x0A. | ||
+ | * Faire la récupération de chaque octet reçu et le stocker dans un tableau. | ||
+ | |||
+ | -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) | ||
+ | |||
+ | |||
+ | ==<span style="color: Black">Semaine 13 et plus</span>== | ||
+ | |||
+ | ===Programmation: Finalisation implémentation reconnaissance RPi en manette et transfert vers la console === | ||
+ | |||
+ | L'objectif de cette dernière semaine étant donc de faire une preuve de concept 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). | ||
+ | |||
+ | Durant les semaines restantes, nous avons travaillé sur HID descriptior (description du périphérique) en le codant pour un mélange joystick & PS4. Cela pour faire en sorte que notre manette soit réellement considérée au maximum comme une manette PS4 par le PC. Ci dessous voici le hid descriptor : | ||
+ | [[Fichier: hid_desc.png||center|500px|descriptor hid ]] | ||
+ | |||
+ | Pour finir sur la communication USB, après avoir récupéré les valeurs des boutons et initié la manette en gadget USB, nous avons essayé de mettre en place le transfert des données comme pour un clavier vers la PS4. Mais travaillant toujours dessus, nous avons pour l’instant eu très peu de résultat concluant mais très proche. | ||
+ | |||
+ | ===Programmation: Finalisation communication SPI === | ||
+ | |||
+ | Durant ces dernières semaines, nous nous sommes concentrés sur la réalisation de la communication SPI avec deux devices. | ||
+ | Pour cela, on télécharge un programme de récupération d'états (Programme arduino) sur chaque Atmega328p-pu selon le capteur choisi. Pour la raspberry pi, celle ci ouvrira l'accés aux devices à tour de rôle. (/dev/spidev1 puis /dev/spidev2). | ||
+ | Lors de cette communication à plusieurs devices, plusieurs problèmes ont été rencontré. Les différenciations des octets reçu et des correspondances octet-device ont été difficile. | ||
+ | En effet, dans un premier temps, nous souhaitons stocker les valeurs du devices 1 dans un tableau 1 et les valeurs du device2 dans un tableau 2. Cependant à chaque communication, ces valeur changeait de position. Ce changement de position, rend le traitement des données par la suite impossible. | ||
+ | Dans un deuxième temps nous souhaitions également envoyé un caratère 'J' ou 'B' pour faire la différence entre la réception depuis un Bouton ou depuis un joystick. Mais l'ajout de ce caractère rendait la communication encore plus compliquée. | ||
+ | |||
+ | Pour résoudre ce problème, nous avons choisi de modifier directement les octet des états depuis les Atmega328p-pu, soit avant l'envoie par le bus SPI. Nous perdons de l'information mais nous avons directement un identifiant Joystick/sel, Joystick/X, Joystick/Y ou encore Bouton ou pas bouton dans les octets transmis et reçus. | ||
+ | Nous avons alors 0b1XXXXXXX pour un Joystick ou 0b0XXXXXXX pour le bouton. | ||
+ | Puis au niveau du joystick, nous avons 0b111XXXXX pour le bouton joystick "sel", 0b101XXXXX pour l'axe X et 0b110XXXXX pour l'axe Y. | ||
+ | Nous pouvons alors par la suite directement traiter les valeurs, et voir quel état des modules a changé. | ||
+ | |||
+ | Comme nous perdons en précision (décalage de 1 ou 3 bits sur la droite), les valeurs des états du joystick changent. | ||
+ | Voici la forme finale de la réception pour les tableaux de stockage r1 (device1 joystick) et r2 (device2 bouton) en décimal: | ||
+ | |||
+ | [[Fichier: etatsspi.png||middle|300px|tableau recuperation des etats]] | ||
+ | |||
+ | ===Application Android suite=== | ||
+ | |||
+ | Coté Android, il est donc nécessaire de posséder un appareil ayant une communication Bluetooth. Pour la connexion en Bluetooth socket, les deux appareils doivent besoin de connaître leurs AdresseMac. Donc, l’application commence par chercher un l’appareil distant pour se connecter à celui-ci. Dès que la connexion est établie, un thread permet de laisser l’application tournée avec en fond de tâche la connexion active. Pour envoyer et recevoir les données, on a besoin de créer un nouveau thread. Puis, une dernière partie qui implémente l’envoie et la réception des données via ce therad. | ||
+ | Coté Raspberry, il faudra donc faire avoir une approche équivalente à celle-ci citée ci-dessus. Il faut tout d’abord, activer l’utilisation du Bluetooth sur la Raspberry Pi Zero W. Puis créer, la socket Bluetooth connectée avec la bonne adresse mac. | ||
+ | |||
+ | [[Fichier: applicationManette.png||center|400px|présentation de l'application, positionnement boutons]] | ||
− | |||
− | == | + | ==Prototype en fin de parcours== |
− | + | [[Fichier: Manodulable.png||center|700px|prototype filaire en fin de parcours ]] | |
=Documents Rendus= | =Documents Rendus= | ||
+ | |||
+ | [[Media: P35_ManetteModulable.pdf]] | ||
+ | |||
+ | [https://archives.plil.fr/tgracias/IMA4_Projet35_ManetteModulable.git Lien vers le Git] |
Version actuelle datée du 20 janvier 2019 à 17:50
Sommaire
- 1 Présentation générale: Manette modulable
- 2 Analyse du projet
- 3 Préparation du projet
- 4 Réalisation du Projet
- 5 Documents Rendus
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.
Membre du projet |
Transley Gracias et Camille Saad |
Cible |
Patient présentant un handicap moteur |
Période du projet |
janvier 2018 - mai 2018 |
Partenaire/Client |
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 techniques 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ées, l’utilisateur nécessitera un peu d’entrainement.
Analyse du premier concurrent : Manette sous forme de gant
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 fait 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 utilise les 4 boutons d'action 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 a 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.
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.
- Problèmes
- Besoin de toute la motricité de la main, c’est-à-dire que si le patient a un doigt paralysé ou manquant, il ne pourra pas jouer avec cette manette
- 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.
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 envahi 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 centres de rééducation pour faire passer le temps et donner du plaisir à des personnes qui ne peuvent plus s’amuser avec leurs consoles traditionnelles. 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és avec différents membres du corps : un doigt, une main, une jambe ou même un pied. Il suffira de les connecter 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 électroniques 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
Objectif principal (1er POC) :
Faire transmettre des informations issues 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.
Objectif secondaire (2e POC):
Créer des modules avec un microcontrôleur et une puce bluetooth pour permettre une meilleure flexibilité (c-à-d pouvoir avoir une meilleure ergonomie et une connexion sans fil).
Configurer la Raspberry Pi 3 en Bluetooth et transmission à la PS4.
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 [1]
1 Thumbstick original:
Joystick analogique 4 directions --> 4,25€/unité TTC [2]
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 [3]
1 Raspberry Pi 3
--> ~36,23€/unité TTC [4]
1 Raspberry Pi Zero W (commandée) [5]
6 Alimentations 5V ou 3,3V </u>
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 [6]
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...
- Recherches 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 concluants, 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
Date |
Tache à réaliser |
17/01/18-24/01/18 |
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 |
31/01/18 |
Recherche technique connexion PS4-RPi3 et connexion SPI RPi3-Module + code |
31/01/18-07/03/18 |
Réalisation 1er prototype (+ début prototype 2) |
07/03/18 |
Seance 7 : Test prototype filaire |
07/03/18-09/05/18 |
Réalisation 2eme prototype + application Android |
09/05/18 |
Seance 14 : Test prototype Bluetooth |
14/05/18 |
Video projet |
15/05/18 |
Finalisation projet et Rapport |
16/05/18-17/05/18 |
Soutenances Projet |
Réalisation du Projet
Feuille d'heures
Voici le tableau d'heures du binôme:
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 | 2 | 17h20 | |||||||
Cherches techniques | 3 | 4 | 4 | 2 | 2 | 1 | 1 | 1 | 5 | 23 | |||||
Rédaction du wiki et rapport de projet | 1 | 1 | 1 | 1 | 30min | 1 | 2 | 30min | 30min | 2 | 17 | 27h30 | |||
Programmation des communications des modules vers RPi et RPi vers Console | 3 | 2 | 3 | 5 | 4 | 7 | 8 | 6 | 5 | 46 | 89 | ||||
Conception des modules: cartes électroniques | 6 | 8 | 4 | 6 | 2 | 1 | 2 | 2 | 1 | 32 | |||||
Application Androïd | 1 | 4 | 12 | 17 | |||||||||||
Total Semaine | 10 | 6 | 6 | 6 | 7 | 10h30 | 13 | 9 | 12 | 9h30 | 10h30 | 9 | 13h20 | 83 | 205h50 |
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
Semaine 1
Durant la séance, nous nous sommes concentrés sur 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
Comme indiqué sur l'image ci-contre, 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
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.
Caracteristiques pour la PS4: Bluetooth®v4.0, Qualcomm Atheros AR3002 Buetooth LE: 2,4-2,5 GHz
Caracteristiques 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
Semaine 2
Durant la semaine deux et durant la séance, nous avons continué et approfondi nos recherches sur le projet. Nous avons pu ainsi affiner nos tâches de réalisation et donc notre cahier des charges.
Communication modules-RPi: SPI et Bluetooth
Recherches :
(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. Ils nous ont permis de comprendre la communication entre la manette et la console. En effet, ils nous expliquent les échanges de trames Bluetooth.
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.
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 les utiliser.
Réalisation du projet Git
Création du projet IMA4_Projet35_ManetteModulable sur Git et partage de celui-ci. Les premiers dossiers créés durant 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.
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ïd.
Une fois ces étapes réalisées, nous aurons 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 circuits é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 modules.
Il est alors important de savoir comment utiliser le port série sur la RPi3, soit utiliser les UARTs.
Nous avons réalisé qu'il n'était pas aussi simple d'utiliser le port série 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 UARTs. 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.
Nous avons pu voir que 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és sur les recherches pour les programmes et la configuration nécessaire à l'utilisation de la RPi zero W.
Electronique
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 circuit électronique afin de faciliter les branchements.
Il nous faut alors également une 3ème 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, ceux-ci doivent être soudés 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.
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 réalisation.
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ées 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 [10]
Semaine 7
Programmation: Connexion wifi sur RPi Zero W et configuration USB
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 configuré l'OS Jessie, utilisé pour la RPi Zero. On a modifié le fichier cmd.txt. Nous avons étudié comme avoir un périphérique USB gadget sur le port OTG, et pouvoir programmer ce périphérique, on a besoin de ConfigFs. Il s'agit d'un système de fichiers virtuels permettant de créer des périphériques USB.
Programmation: Bootloader sur Atmega328p-pu
Nous avons également continué les programmes de récupération de données : état des boutons et du joystick. Ces programmes sont appliqués 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 charger un amorceur 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é 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 support socket de la carte. On change de nouveau le programmateur pour "Arduino as ISP" et on fait >tools>burn bootloader, soit >graver la séquence d'initialisation. Ces étapes faites, on peut retirer notre microcontrôleur 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éalisé 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.
Electronique : soudure carte de tests pour 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 correspondante à ce montage ainsi que le PCB du bouton.
Semaine 8
Programmation
Après moult recherches sur les différents site web bien fournis,on a 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 échanger 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éussi à 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 avons souhaité programmer la carte électronique atmega328p-pu. Cependant, nous avons réalisé 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 pins 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évues pour le téléversement des programmes sur la carte. Il nous faut alors couper une piste et souder des câbles pour avoir toutes les pistes souhaitées.
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.
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, toujours 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 commencé 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éma d'implémentation, nous avons modifié les empreintes des capacités, des inductances et autres composants de 0402 à 0603. En effet, notre matériel ne disponible n'était qu'en 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 6mil, il nous faut alors passer les pistes en taille inférieure. 6mil est la taille minimale pour la production à Polytech, mais le 6mil n'est pas conseillée. 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: reconnaissance en tant que manette PS4
Les premiers tests sur Windows ne nous donnent pas satisfaction. En effet, l'ordinateur détectait bien le nouvel appareil avec son nom mais l'origine reste 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
Programmation: Premiers tests SPI sur la carte Atmega328p=
Une carte PCB atmega 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 configuré la partie communication SPI pour l'atmega.
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 octet "0x01" de la RPi et retourne une valeur sauvegardé. 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).
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 pouvoir 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 basiques 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: Raspberry Pi implémentation périphérique USB en tant qu e manette PS4
Nous avons continué le travail effectué pour pouvoir programmer un périphérique USB sur le port OTG. Comme nous l'avions vu, il est nécessaire de faire des configurations préalables avec ConfigFs. Nous avons procédé aux réglage suivants:
- Rajouter dtoverlay=dwc2 dans le fichier boot/config.txt: ce qui permet de charger le driver dwc2 pour la gestion de l’OTG qui se trouve dans le noyau.
- Rajouter dwc2 et libcomposite dans le fichier data/etc/modules pour initialiser configFs.
Ainsi cette semaine, pour tester la prise OTG, nous avons décidé de lancer un script 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 quelques modifications et plusieurs petits bugs, nous avons réussi à faire fonctionner le ssh via le port OTG.
Cependant, notre problème reste le même, notre script mélangé avec les informations sur la PS4 n'est toujours pas fonctionnel.
Programmation: 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 pour le côté de la raspberry pi. Cette semaine a permis une étude plus approfondie 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. Notre code en C se compose de 3 étapes :
- L'initialisation et la configuration de la communication SPI vue par la RPi (nombre de bits par mots échangés, vitesse, mode, maître ou esclave...).
- L'envoi d'une requête par exemple "0x0A" soit "\n".
- Réception des données octet par octet sur le bus en retour.
Deux bibliothèques sont importantes :
#include <sys/ioctl.h> //Pour la transmission #include <linux/spi/spidev.h> //Pour SPI
On va déclarer des variables globales qu'on utilisera pour la configuration :
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 périphérique 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);
Application: début et principe
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.
Voici le principe d'application que nous souhaitons développer : Par définition de notre projet, la manette doit être modulaire. De ce fait, les boutons seront amenés à changer. Ainsi, l'utilisateur devra choisir les boutons qu'il veut utiliser et les faire glisser sur la position du bouton de la manette officielle. On réalise la correspondance entre les boutons modulaires et les boutons officiaux. Le joueur n'est pas obligé de respecter les types de boutons prévus de base : par exemple joystick à la place des flèches directionnelle ou bouton carré au lieu de la flèche du haut.
Semaine 11
Programmation: PS4, SSH et tests SPI (RPi3&Atemga328p)
Raspberry Pi Zero W et PS4
Lors de recherches supplémentaires, nous avons essayé 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 installé 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. 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êmes codes fonctionnels sur les cartes atmega328p définitives.
A la fin de cette semaine, nous avons alors des codes Atmega-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. Pour les modules, le plus important est la déclaration des interruptions "quand envoyer les octets d'états?" puis la boucle d'envoie avec SPI.tranfer() (voir photo gauche).
Quant à la raspberry, le plus important est la fonction transfer(). Elle permet d'envoyer un tableau d'octets par SPI et de retourner le tableau d'octets quelle peut recevoir en retour (voir photo droite).
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 éviter 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 utilisé un script pour faire un pseudo clavier/souris pour essayer d'envoyer nos données. Nous avons modifié petit à petit jusqu’à avoir un script/programme compatible PC. Il devra ce faire passer pour un Joystick donc une manette classique.
Raspberry PI, Atmega328p et SPI
Lors de cette semaine, nous avons entièrement abandonné les arduinos pour garder uniquement nos cartes électroniques Atmega328p-pu enfin imprimés, soudées, alimentées et prêtes à l'emploi. Nous avons alors continué les test SPI pour un seul device sur celles-ci jusqu'à réussir la récupération des valeurs des capteurs (bouton ou joystick) et commencé une ébauche de programmation pour deux devices. Notre programme pour un device fonctionne de la manière suivante :
- La RPi envoie en SPI un tableau avec la valeur 0x0A soit "\n" en première position et que des 0x00 par la suite.
- L'arduino reçoit 0x0A, elle va lire l'état du bouton ou de la variable voulue du joystick (par exemple l'axe X)
- L'arduino renvoie cette valeur
Nous avons continué les tests afin d'envoyer plusieurs valeurs en même temps. Ces tests se sont fait sans succés. En effet le SPI envoie octet par octet, ce qui rend la communication plus difficile quand on a plusieurs valeurs à transmettre.
Réflexion:.
- Penser à faire le programme en boucle à chaque réception de 0x0A.
- Faire la récupération de chaque octet reçu et le stocker dans un tableau.
-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: Finalisation implémentation reconnaissance RPi en manette et transfert vers la console
L'objectif de cette dernière semaine étant donc de faire une preuve de concept 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).
Durant les semaines restantes, nous avons travaillé sur HID descriptior (description du périphérique) en le codant pour un mélange joystick & PS4. Cela pour faire en sorte que notre manette soit réellement considérée au maximum comme une manette PS4 par le PC. Ci dessous voici le hid descriptor :
Pour finir sur la communication USB, après avoir récupéré les valeurs des boutons et initié la manette en gadget USB, nous avons essayé de mettre en place le transfert des données comme pour un clavier vers la PS4. Mais travaillant toujours dessus, nous avons pour l’instant eu très peu de résultat concluant mais très proche.
Programmation: Finalisation communication SPI
Durant ces dernières semaines, nous nous sommes concentrés sur la réalisation de la communication SPI avec deux devices. Pour cela, on télécharge un programme de récupération d'états (Programme arduino) sur chaque Atmega328p-pu selon le capteur choisi. Pour la raspberry pi, celle ci ouvrira l'accés aux devices à tour de rôle. (/dev/spidev1 puis /dev/spidev2). Lors de cette communication à plusieurs devices, plusieurs problèmes ont été rencontré. Les différenciations des octets reçu et des correspondances octet-device ont été difficile. En effet, dans un premier temps, nous souhaitons stocker les valeurs du devices 1 dans un tableau 1 et les valeurs du device2 dans un tableau 2. Cependant à chaque communication, ces valeur changeait de position. Ce changement de position, rend le traitement des données par la suite impossible. Dans un deuxième temps nous souhaitions également envoyé un caratère 'J' ou 'B' pour faire la différence entre la réception depuis un Bouton ou depuis un joystick. Mais l'ajout de ce caractère rendait la communication encore plus compliquée.
Pour résoudre ce problème, nous avons choisi de modifier directement les octet des états depuis les Atmega328p-pu, soit avant l'envoie par le bus SPI. Nous perdons de l'information mais nous avons directement un identifiant Joystick/sel, Joystick/X, Joystick/Y ou encore Bouton ou pas bouton dans les octets transmis et reçus. Nous avons alors 0b1XXXXXXX pour un Joystick ou 0b0XXXXXXX pour le bouton. Puis au niveau du joystick, nous avons 0b111XXXXX pour le bouton joystick "sel", 0b101XXXXX pour l'axe X et 0b110XXXXX pour l'axe Y. Nous pouvons alors par la suite directement traiter les valeurs, et voir quel état des modules a changé.
Comme nous perdons en précision (décalage de 1 ou 3 bits sur la droite), les valeurs des états du joystick changent. Voici la forme finale de la réception pour les tableaux de stockage r1 (device1 joystick) et r2 (device2 bouton) en décimal:
Application Android suite
Coté Android, il est donc nécessaire de posséder un appareil ayant une communication Bluetooth. Pour la connexion en Bluetooth socket, les deux appareils doivent besoin de connaître leurs AdresseMac. Donc, l’application commence par chercher un l’appareil distant pour se connecter à celui-ci. Dès que la connexion est établie, un thread permet de laisser l’application tournée avec en fond de tâche la connexion active. Pour envoyer et recevoir les données, on a besoin de créer un nouveau thread. Puis, une dernière partie qui implémente l’envoie et la réception des données via ce therad. Coté Raspberry, il faudra donc faire avoir une approche équivalente à celle-ci citée ci-dessus. Il faut tout d’abord, activer l’utilisation du Bluetooth sur la Raspberry Pi Zero W. Puis créer, la socket Bluetooth connectée avec la bonne adresse mac.