IMA4 2017/2018 P35 : Différence entre versions

De Wiki de Projets IMA
(Programmation)
(Feuille d'heures)
 
(42 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.
  
<br><br>
 
  
 
{| 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 technique dans la manipulation et on ne joue pas avec une
+
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 adapté, l’utilisateur nécessitera un peu d’entrainement.
+
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 faut office de manette Play Station: le Reality Quest Power Glove.Cette idée de manette-gant, permet de jouer à la PS avec une seule main, elle a était conçue et présentée pour les E3, un salon d’exposition de gaming.Le gant est conçu pour contrôler l’équivalent des 14 boutons et 2 joysticks à l’aide d’une seule main. La « manette » est fixée dans la pomme de la main. L’utilisateur contrôle les mouvements verticaux et horizontaux en pivotant le poignet, et utilisent les 4 boutons d’action principaux et L1/R1 avec les doigts. Les autres boutons sont accessibles par un seul bouton rond contrôlé par le pouce.
+
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 à un doigt paralysé ou manquant, il ne pourra pas jouer avec ce gant
+
*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
  
<br>
+
 
 
==<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. Sur la photo ci-dessous, il a adapté la manette pour un droitier.
 
  
 
; Problèmes:  
 
; Problèmes:  
*Besoin de toute la motricité de la main, c’est-à-dire que si le patient à un doigt paralysé ou manquant, il ne pourra pas jouer avec cette ma
+
*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 envahies les maisons avec plus de 7 personnes sur 10 jouant aux jeux vidéos sur consoles en France (chiffre de l’Express). 0,18% des français sont handicapés cela représente 12 millions de français. Dans ce chiffre, 13,4% des personnes ont un handicap moteur. En 2017, les grands groupes comme Sony ou Microsoft avec respectivement PlayStation et Xbox ne permettent pas à tout le monde de jouer avec une manette. Les manettes sont prévues pour des personnes ayant leurs membres valides, plus précisément les mains et les bras.
+
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 centre de rééducation pour faire passer le temps et donner du plaisir à des personnes qui ne peuvent plus s’amuser avec leur console traditionnelle. Elle pourra aussi ouvrir de nouvelles possibilités pour certaines personnes qui n’auraient jamais essayé jusqu'à présent.   
+
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 utilisé avec différents membres du corps : un doigt, une main,
+
 
une jambe ou même un pied. Il suffira de les connectés entre eux suivant l’organisation souhaitée, le Gameplay du jeu ou en fonction du handicap. Le tout sera relié à une application.
+
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>==
  
'''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.
+
;'''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 électroniques pour chaque module avec un micro-contrôleur. La communication filaire nous permettra d'interconnecter les modules à la RPi3 avec un bus SPI.
  
Dans cette première partie de projet, nous souhaitons avoir une 1ère preuve de prototype rapidement. Nous nous concentrerons alors sur la communication entre la RPi3 et la PS4 ainsi que sur la conception des modules. Pour les modules, nous réaliserons des cartes électronique pour chaque module avec un micro-contrôleur. La communication filaire nous permettra d'interconnecter les modules à la RPi3 avec un bus SPI.
+
;'''Objectif 2: preuve concept sans fils'''
  
'''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)'''
  
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>
+
;Sujet : Manette modulable pour personne à déficience moteur compatible PlayStation 4 <br>
  
===Objectifs principal (1er POC) : ===
+
'''Objectif principal (1er POC) :'''
Faire transmettre des informations issus des actionneurs (ex:boutons poussoires) via des arduinos jusqu’à la Raspberry Pi 3 en SPI.<br>
 
Envoyer les données reçues vers la PS4 en USB  <br>
 
  
===Objectifs secondaire (2e 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 meilleurs flexibilité (c-àd pouvoirs avoir une meilleure ergonomie et une connexion sans fil) <br>
+
Envoyer les données reçues vers la PS4 en USB.
Connecter la Raspberry Pi 3 en Bluetooth à la PS4 <br>
+
 
 +
'''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 182 : Ligne 194 :
 
2  oscillateurs quartz 16MHz traversante <br>
 
2  oscillateurs quartz 16MHz traversante <br>
 
2  atmega328p-pu et support <br>
 
2  atmega328p-pu et support <br>
 
  
 
'''Cartes module bluetooth nrf52810 '''
 
'''Cartes module bluetooth nrf52810 '''
Ligne 209 : Ligne 220 :
 
===Logiciels:===
 
===Logiciels:===
  
- IDE arduino
+
* IDE arduino
- Altium
+
Altium
- FreeCAD ou Inkscape
+
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...
* Recherche techniques sur les différentes connexions possibles entre les modules, la RPi 3 et la console PS4
+
* 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 concluant, ajouter des modules jusqu'à en avoir 5 (1 pour chaque type de boutons)  
+
** 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 321 : Ligne 332 :
 
|
 
|
 
|
 
|
|
+
|  
 
|
 
|
 
|
 
|
 
| 20min
 
| 20min
|
+
| 2
| 15h20
+
| 17h20
 
|-
 
|-
 
| Cherches techniques  
 
| Cherches techniques  
Ligne 340 : Ligne 351 :
 
|  
 
|  
 
| 1
 
| 1
 +
|
 
| 1
 
| 1
|
+
| 5
|
+
| 23
| 18
 
 
|-
 
|-
 
| Rédaction du wiki et rapport de projet
 
| Rédaction du wiki et rapport de projet
Ligne 359 : Ligne 370 :
 
|  
 
|  
 
| 2
 
| 2
|
+
| 17
| 10h30
+
| 27h30
 
|-
 
|-
| Programmation
+
| Programmation des communications des modules vers RPi et RPi vers Console
 
|  
 
|  
 
|  
 
|  
Ligne 376 : Ligne 387 :
 
| 6
 
| 6
 
| 5
 
| 5
|  
+
| 46
| 43
+
| 89
 
|-
 
|-
| Cartes électroniques
+
| Conception des modules: cartes électroniques
 
|  
 
|  
 
|  
 
|  
Ligne 393 : Ligne 404 :
 
| 2
 
| 2
 
| 2
 
| 2
|  
+
| 1
| 31
+
| 32
 
|-
 
|-
| Application
+
| Application Androïd
 
|  
 
|  
 
|  
 
|  
Ligne 407 : Ligne 418 :
 
|
 
|
 
|
 
|
 +
| 1
 
|
 
|
|
+
| 4
 +
| 12
 +
| 17
 
|-
 
|-
 
|-
 
|-
Ligne 424 : Ligne 438 :
 
| 10h30
 
| 10h30
 
| 9
 
| 9
| 9h20
+
| 13h20
|  
+
| 83
| '''117h50'''
+
| '''205h50'''
 
|}
 
|}
  
Ligne 436 : 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.  
+
* 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)
+
* 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)  
+
* 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
+
* 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 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.
+
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 455 : Ligne 470 :
  
 
[[Fichier: yWGmW.png||right|200px|Concept manette modulable]]
 
[[Fichier: yWGmW.png||right|200px|Concept manette modulable]]
Comme indiqué sur l'image ci-dessus, la Raspberry pi 3  peut communiquer en SPI avec ses broches CS0 (24), CS1 (26), SCLK (23), MISO (21), MOSI (19). Celles-ci permettent de communiquer avec un ou plusieurs esclaves (dans notre cas, des Atmega328p) en reliant directement les broches concernées de la RPi3 à celles des composants esclaves.
+
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 463 : 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 essaierons avec 2 esclaves, puis on augmentera le nombre.  
+
Dans un premier temps, nous essaierons avec 2 esclaves, puis on augmentera le nombre.  
 
 
  
 
===Connexion Bluetooth PS4-RPi3===
 
===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
+
Les recherches portent également sur la connexion entre la manette PS4 et la console. Elles concernent le protocole de communication via Bluetooth.
  
Caracteristique pour la PS4:  Bluetooth®v4.0, Qualcomm Atheros AR3002 Buetooth LE: 2,4-2,5 GHz  <br/>
+
Caracteristiques pour la PS4:  Bluetooth®v4.0, Qualcomm Atheros AR3002 Buetooth LE: 2,4-2,5 GHz  <br/>
  
Caracteristique de la connexion : <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/>
+
Matériel nécessaire pour un PCB : <br/>
  
 
*breadboard
 
*breadboard
Ligne 500 : 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 approfondie nos recherches sur le projet. Nous avons pu ainsi affiner nos taches de réalisation et donc notre cahier des charges.
+
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.
  
===Connexion aux modules: SPI et Bluetooth ===
+
===Communication modules-RPi: SPI et Bluetooth ===
  
<span style="color: Green"> CORRIGER</span>
+
'''Recherches :'''
 
 
voir https://peip-ima.plil.fr/mediawiki/index.php/BE_2017-2018#Configuration_du_syst.C3.A8me_embarqu.C3.A9
 
  
 
(sudo apt-get install pi-bluetooth)
 
(sudo apt-get install pi-bluetooth)
  
''connexion sur la raspberry par ssh:''
+
;connexion sur la raspberry par ssh:
 
  su
 
  su
 
  update-rc.d ssh enable
 
  update-rc.d ssh enable
Ligne 517 : Ligne 530 :
  
  
''bluetooth''
+
;Bluetooth:
 
  bluetoothctl
 
  bluetoothctl
 
  agent on
 
  agent on
Ligne 523 : Ligne 536 :
 
  scan on
 
  scan on
 
  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 529 : 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 !
+
;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 536 : 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 :
+
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: Red">SITES</span>
 
 
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: Red">EXPLICATIONS 1 exemple </span>
 
  
 
==<span style="color: Black">Semaine 3 : Début premier prototype</span>==
 
==<span style="color: Black">Semaine 3 : Début premier prototype</span>==
Ligne 556 : 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 l'utiliser.  
+
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===
 
===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 dossier crées cette la séance :
+
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)  
Ligne 570 : Ligne 581 :
  
 
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.  
 
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.  
<span style="color: Red"> Déveloper</span>
 
  
 
On a décidé de commencer par une connexion USB (pour laquelle on dispose de toutes les informations) celle-ci étant plus complète.
 
On a décidé de commencer par une connexion USB (pour laquelle on dispose de toutes les informations) celle-ci étant plus complète.
 +
  
 
==<span style="color: Black">Semaine 4</span>==
 
==<span style="color: Black">Semaine 4</span>==
Ligne 584 : 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 Androïde.
+
#Réalisation de l'application Androïd.
  
Une fois ces étapes réalisées nous auront alors une preuve de concept filaire et nous pourrons alors passer à une connexion bluetooth.  
+
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)
+
*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.  
+
*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.
+
*Choix de l’alimentation pour les 5 modules Bluetooth: nécessitent 3V -->  utiliser des piles rechargeables 1,2V AAA plutôt que piles rondes 3V.
  
Nous avons également besoin du matériel cité en semaine 1 pour réaliser des cartes électroniques atmega328p-pu standalone. ( nous revenons alors sur les décisions de la semaine 3)
+
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 623 : 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 module.  
+
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 UART.  
+
Il est alors important de savoir comment utiliser le port série sur la RPi3, soit utiliser les UARTs.  
  
Nous avons réaliser qu'il n'était pas aussi simple d'utiliser le port serie USB de la Raspberry Pi 3, en effet le SoC est un BCM2837 .  
+
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.
 
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>==
Ligne 636 : Ligne 648 :
 
===Programmation: Réflexion définitives prototypes filaire ===
 
===Programmation: Réflexion définitives prototypes filaire ===
  
La semaine dernière, nous avons rencontré une difficulté liée aux ports séries UART.  
+
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.
+
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.  
 
Ensuite, nous avons continué la réalisation du prototype filaire par l'avancé du code SPI ainsi que les recherches concernant le protocole PS4.  
  
La Raspberry Pi zero W peut également être utile pour la connexion entre la PS4 et les différents modules en jouant le rôle d'intermédiaire. Nous avons alors commandé une Rpi zero W pour notre projet.  
+
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é sur les recherches pour les programmes et la configuration nécessaire à l'utilisation de la RPi zero W.
+
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===
Ligne 649 : Ligne 661 :
 
[[Fichier: arduinobb.jpg|200px|thumb|right|atmega328p-pu branchement test]]
 
[[Fichier: arduinobb.jpg|200px|thumb|right|atmega328p-pu branchement test]]
  
Du coté électronique, nous avons réalisé sur fritzing certaines cartes électroniques. Les Arduino Uno servant actuellement de test, seront remplacées par des PCB atmega328p-pu standalone avec des broches permettant les branchements nécessaires SPI ou encore aux modules "boutons/joystick". Pour les boutons, nous avons également réalisé un pcb afin de faciliter les branchements.   
+
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 3eme carte qui nous sera nécessaire pour la réalisation du prototype sans fil. Dans notre liste de matériel, nous avons des composants nrf52810 bluetooth, ceci doivent être soudé avec les capacités de protection mais également des broches de communication. Nous avons alors commencé cette carte électronique sur Altium avec le fichier projet PCB du distributeur à modifier.
+
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|center|PCB atmega328p-pu]]
Ligne 658 : Ligne 670 :
  
 
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.
 
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.
 +
  
 
==<span style="color: Black">Semaine 6</span>==
 
==<span style="color: Black">Semaine 6</span>==
Ligne 672 : 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 validation.
+
La carte est en attente de validation, puis réalisation.
  
 
[[Fichier: nrf52810_circuit2.jpg||center|400px|PCB carte nrf52810]]
 
[[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 augmentée si nécessaire,pour avoir dans l'idéal un module de chaque type de la manette, ici on se concentre sur BOUTON et JOYSTICK)
+
(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 702 : 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: connexion wifi RPi Zero W et Bootloader sur Atmega328p-pu ===
+
===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.
 
Pendant cette semaine, nous avons continué la programmation et la configuration des Raspberry Pi 3 et Zero W. Concernant la configuration ssh, nous avons utilisé un téléphone en guise de point d’accès à la RPi Zero W en wifi.
Nous avons aussi directement configurer l'OS Jessie, utilisé pour la RPi Zero. On a modifié le fichier cmd.txt et ...pour pouvoir programmer un USB gadget sur le port OTG.
+
Nous avons aussi directement configuré l'OS Jessie, utilisé pour la RPi Zero. On a modifié le fichier cmd.txt.  
<span style="color: Red">Ci-dessus expliquer fichiers</span> 
+
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 continuer les programmes de récupération de données : état des boutons et du joystick. Ces programmes sont appliqué sur l'atmega328p-pu standalone sur la plaque d'essai en attendant que le PCB soit opérationnel.
+
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'''
 
'''1.Flasher le Bootloader'''
Nous avons 2 Atmega328p-pu neufs, ainsi il nous faut flasher le bootloader sur chacun d'eux afin de pouvoir les utiliser et les programmer sur une breadboard dans un montage minimaliste arduino-standalone.  
+
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és dans le menu >Outils. Sur cette carte on téléverse le fichier arduinoISP.ino qui se trouve dans les exemples en étant en progrmamateur AVr ISP mkll (>outils>programmateur)  
+
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 suppor socket de la carte. On change de nouveau le programmateur pour Arduino as ISP et on fait >tools>burn bootloader, soit >graver la sequence d'initialisation.
+
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 microcontroleur et le replacer correctement dans le montage.  
+
Ces étapes faites, on peut retirer notre microcontrôleur et le replacer correctement dans le montage.  
  
 
'''2.Programmation atmega328 sur breadboard'''
 
'''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 réaliser des codes basiques tels que le clignotement d'une led rouge ou encore l'affichage de "hello world" sur le moniteur série pour vérifier la bonne fonctionnalité du montage. Cela fait nous avons pu écrire sous Arduino IDE le code de lecture des états.
+
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.
  
 
[[Fichier: montage_BB_test.jpg||left|200px|programmation modules arduino sur breadboard]]
 
[[Fichier: montage_BB_test.jpg||left|200px|programmation modules arduino sur breadboard]]
  
===Electronique : soudure carte de test modules ===
+
===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 correspondant à ce montage ainsi que le PCB du bouton.
+
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>==
  
 
===Programmation ===
 
===Programmation ===
Après moult recherche sur les différents site web bien fournis pour le coups on as pu trouvé une amorce à la programmation de l'OTG via un script qui agit au niveau du kernel dans le sous dossier usg_gadget. Ce script donne les informations nécessaires pour pouvoirs échangé les données.
+
 
Avec le script trouvé et les informations des sites web décryptant les trames de la manette, on a toujours pas réussit à faire passer notre RPi Zero W pour une manette de PS4. Néanmoins il nous manque la trame HID complète de la manette pour avoir un test effectif.
+
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===
 
===Electronique : Correction soudure et soudure CMS===
  
Durant cette semaine, nous avions souhaité programmer la carte électronique atmega328p-pu. Cependant, nous avons réaliser que nous avions fait une erreur lors de l'envoie du PCB à la production. En effet, celui-ci avait été fait en Top sur le logiciel Fritzing et non en Bottom. Hors nous avions soudé les composants (durant la semaine 7) comme pour un circuit imprimé en bottom, l'atmega328p-pu se retrouve alors inversé par rapport aux pistes.  
+
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 pin 2 et 3 pour le RX et TX permettant la programmation de l'atmega à partir d'une arduino, les pistes branchement RX-TX n'ont également pas été prévus pour le téléversement des programmes sur la carte. Il nous faut alors couper une piste et souder des câbles pour utiliser toutes les pistes souhaitées.  
+
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|300px|PCB arduino correction]]
+
[[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.  
 
[[Fichier: PCB_nrf52810.jpg||left|400px|carte electroniques imprimées]]
 
  
 
====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.
+
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, tjrs utiliser une pince)
+
# 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 commencer par le nrf52810 (composant concerné) évitant ainsi de gaspiller d'autres CMS.  
+
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 schématic, et de la modification des empreintes de capacités, inductances et autres composants de 0402 à 0603. Notre matériel ne permettant que des empreintes 0603.
+
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 8mil, il nous faut alors passer les pistes en 6mil. Mais 8mil est la taille minimale pour la production à Polytech, nous avons regardé pour envoyer les cartes à faire ailleurs mais le 6mil n'est pas beaucoup conseillé. De plus, il n'est peut-être pas judicieux de continuer avec le composant microcontrôleur-bluetooth Nrf52810 qui prend du temps, donc la carte est difficilement réalisable et peut-être très long à programmer.  
+
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>==
 
==<span style="color: Black">Semaine 9</span>==
  
====Programmation: PS4 et 1er Test SPI sur atmega328p====
+
===Programmation: reconnaissance en tant que manette PS4===
  
'''Raspberry Pi Zero W et 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.  
 
 
Les premiers tests sur Windows ne nous donner pas satisfaction. En effet, l'ordinateur détectait bien le nouvel appareil avec son nom mais l'origine rester inconnue.  
 
  
 
Lors des tests sur Linux on a pu voir des erreurs via la commande 'dmesg' :
 
Lors des tests sur Linux on a pu voir des erreurs via la commande 'dmesg' :
Ligne 798 : Ligne 811 :
 
  [193413.177227] usb 4-1.1: device descriptor read/64, error -110
 
  [193413.177227] usb 4-1.1: device descriptor read/64, error -110
  
 +
===Programmation: Premiers tests SPI sur la carte Atmega328p====
  
'''Modules Atmega328p et SPI'''
+
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.
Une carte PCB arduino fonctionnant, nous pouvons la programme pour simuler un module. Celle-ci a été designée afin de s'adapter au module que l'on souhaite. Il suffit de brancher le bouton, le joystick ou autre élèment de manette souhaité.
 
Cette semaine ci, nous avons alors configurer la partie communication SPI pour l'arduino.
 
  
 
'''Que voulons-nous faire avec les atmegas ?'''  
 
'''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.
+
Les cartes électroniques atmega328p vont nous permettre de recevoir les requêtes SPI envoyées par la raspberry pi et d'y répondre. La Raspberry enverra un message, par exemple "1", et l'Arduino lira alors l'état du module qui lui est connecté. Une fois l'état récupéré, elle le renvoie à la Raspberry Pi.
  
Durant cette semaine, nous avons programmé l'atmega afin qu'il soit en esclave, qu'il reçoive un de la RPi "1" et retourne une valeur sauvegardé "int envoi". Nous avons également commencé les tests pour la lecture de l'état d'un bouton (d'après les tests réalisés les semaines précédentes).
+
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'''
 
'''Code'''
Ligne 818 : Ligne 830 :
 
SS -> GPIO10  //PB2  //slave select
 
SS -> GPIO10  //PB2  //slave select
  
Il faut également paramétrer l'atmega328p en Slave. On note que dans un premier temps, le programme sera codé avec l'arduino IDE (fichiers .ino). Une fois l'ensemble SPI RaspberryPi-Arduino fonctionnant, on remplacera ces codes par du langage C ou C++.
+
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).  
 
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).  
Ligne 824 : Ligne 836 :
 
   #include <SPI.h>
 
   #include <SPI.h>
  
Il est important d'initialise d'abord le setup et on active le port série pour pourvoir utiliser le moniteur série. (Cela servira à verifier la valeur envoyée par la RPi)  
+
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)
 
  void setup (void)
Ligne 858 : Ligne 870 :
 
Dans la loop main, on traite la requête et on utilise '''SPI.transfer(envoi);''' pour transferer à la RPi les données souhaitées.  
 
Dans la loop main, on traite la requête et on utilise '''SPI.transfer(envoi);''' pour transferer à la RPi les données souhaitées.  
  
Durant cette semaine, nous avons également commencé des programmes de test SPI pour la RPi. Il s'agit principalement de programmes de tests tout faits permettant de vérifier la connexion entre cette dernière et l'arduino. Par exemple, la RPI envoie "bonjour" et l'arduino lui retourne ce qu'elle reçoit, soit "bonjour". Sans succés alors.
+
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====
 
====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.
 
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.  
+
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>==
 
==<span style="color: Black">Semaine 10</span>==
  
====Programmation : PS4 et SPI sur RPi====
+
===Programmation: Raspberry Pi implémentation périphérique USB en tant qu e manette PS4===
  
'''Raspberry Pi Zero W et 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]]
  
Cette semaine, pour tester la prise OTG nous avons décider de lancer un script qui est habituellement utilisé. Nous avons choisi le script Serial Adapter qui est censé permettre de se connecter à la RPi Zero W en SSH via ce port.  
+
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 quelque modifications et plusieurs petits bugs, nous avons réussir à faire fonctionner le ssh via le port OTG. Donc le problème était le même, notre script mélangé avec les informations sur la PS4 n'était toujours pas fonctionnel.
+
Après quelques modifications et plusieurs petits bugs, nous avons réussi à faire fonctionner le ssh via le port OTG.  
  
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.  
+
Cependant, notre problème reste le même, notre script mélangé avec les informations sur la PS4 n'est toujours pas fonctionnel.
  
'''Modules Raspberry PI et SPI'''
+
===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 avec la raspberry pi. Cette semaine a permis une étude plus approfondit sur le fonctionnement pour la RPi.  
+
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 rappelle, comme vu des semaines 1 à 4, pour la RPI3 (tout comme la RPi Zero W) utilise les broches : SCLK (23), MISO(21), MOSI (19) et SPI CS0 (24), SPI CS1 (26).  
On la programme en Master. A l'aide des fichiers tests d'inspiration, on pourra directement programmer la RPi en C. Lors de la réalisation du code, il y a 3 étapes : l'initialisation/parametrage en SPI pour être maître, l'envoie de la requête puis la réception de données en retour.  
+
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.  
  
Programmant en C, il ne faut pas oublier les librairies suivantes :
+
Deux bibliothèques sont importantes :
 
+
  #include <sys/ioctl.h>         //Pour la transmission
#include <stdint.h>
+
  #include <linux/spi/spidev.h>  //Pour SPI
#include <unistd.h>
 
#include <stdio.h>
 
#include <stdlib.h>
 
#include <getopt.h>
 
#include <fcntl.h>
 
  #include <sys/ioctl.h>
 
#include <linux/types.h>
 
  #include <linux/spi/spidev.h>  //pour SPI
 
 
 
On va déclarer des variables globales permettant le paramétrage :
 
  
 +
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 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 mode;      //mode est par défaut à 0
Ligne 904 : Ligne 916 :
 
  static uint16_t delay;
 
  static uint16_t delay;
  
Dans notre main, on ouvre le port (la connexion) au device souhaité,  on vérifie les paramètres (registres, connexions...) puis exécute la fonction transfer(fd). transfer(fd) transmet la requête et s'occupe de la réception.  
+
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);
 
  fd = open(device, O_RDWR);
 
  transfer(fd);
 
  transfer(fd);
 
  close(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>==
 
==<span style="color: Black">Semaine 11</span>==
  
====Programmation: PS4, SSH et tests SPI (RPi3&Atemga328p)====
+
===Programmation: PS4, SSH et tests SPI (RPi3&Atemga328p)===
  
 
'''Raspberry Pi Zero W et PS4'''
 
'''Raspberry Pi Zero W et PS4'''
Lors de recherche supplémentaire, nous avons essayer de voir s'il un pilote de gestion du périphérique serait nécessaire à la connexion de notre pseudo manette.  
+
 
 +
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'''
 
'''Raspberry PI, Atmega328p et SPI'''
  
Afin de facilité la programmation en utilisant Ethernet, nous avons installer et configuré la RPi pour l'utiliser en SSH depuis les ordinateurs de la E306. En effet, SSH permet de se connecter à distance sur une machine en utilisant un compte utilisateur de la dite machine. En mettant ssh, on pourra directement agir sur les fichiers de la raspberry depuis un terminal de notre PC. Pour cela, on a d'abord vérifier l'adresse IP de notre raspberry pi : 172.26.145.106 avec un écran mais on peut aussi utiliser les commandes ip a et ifconfig. Puis activer le ssh sur la raspberry pi.  
+
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.
 
On modifie alors le fichier config.txt mais également etc/network/interfaces pour configurer la bonne interface Ethernet sur la raspberry pi.
 
[[Fichier: configSSH_raspi.png||left|300px|config ssh ethernet]]
 
 
 
Il nous suffit alors de taper la commande : ssh pi@172.26.145.106  pour accéder à notre RPi.  
 
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 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 arrivons alors à lire l'état envoyer "bonjour" et recevoir "ça va" ou encore "1" et recevoir "3". Il faut noter que le SPI échange des trames, la RPI reçoit alors des hexadécimaux.  
Nous avons alors continué pour recevoir l'état du bouton ou du joystick lors de l'envoie de "1" sur l'Arduino328p. La semaine prochaine nous testerons ces même codes fonctionnels sur les cartes atmeg327p.  
+
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).
  
A la fin de cette semaine, nous avons alors des codes Arduino-SPI (.ino) et des codes Raspberry-SPI (.c) permettant l'échange de données. Le but est maintenant de l'adapter aux cartes imprimées et de le rendre pleinement fonctionnel pour plusieurs cartes à la fois, puis ajouter une boucle de vérification en continue jusqu'à une deuxième requête de la RPi.
+
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====
+
===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.
+
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.  
 
Nous les souhaitons au propre pour une version finale. Une fois celle-ci imprimées nous pourrons en avoir 3 , un pour chaque module. Les cartes étaient bien imprimées en bottom mais lors du passage des traversants de bottom à top, le logiciel ne les a pas fait miroiter. Par manque d'attention nous avons alors envoyé les fichiers gerber pour des cartes ayant les composants du même coté que la couche de cuivre.  
Les cartes électroniques actuelles sont alors correctes et fonctionnelles mais difficile à souder. Pour eviter les erreurs et continuer sur des prototypes de carte nous préférons attendre en nous concentrant sur la programmation PSI de la Raspberry Pi.  
+
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>==
 
==<span style="color: Black">Semaine 12</span>==
  
====Programmation====
+
===Programmation===
  
 
'''Raspberry Pi Zero W et PS4'''
 
'''Raspberry Pi Zero W et PS4'''
  
Cette semaine nous avons décidé de prendre un cap temporaire. On a utiliser un script pour faire un pseudo clavier/souris pour essayer d'envoyer nos données puis modifier petit à petit jusqu'a avoir un script/programme compatible PC. Il devra ce faire passer pour un Joystick donc une manette classique.   
+
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'''
 
'''Raspberry PI, Atmega328p et SPI'''
  
- réflexion: penser à faire boucler sur l'arduino une fois la requête reçu, ça veut dire que la manette est ON et donc vérifier continuellement les modules sur chaque atmega.
+
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.
- SPI raspberry pi - arduino recuperation état du bouton avec les cartes modules  (/!\ récuperation à faire dans une variable)
+
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  
 
-SSH perso  
 
adresse Rasppi: 192.168.137.10
 
adresse Rasppi: 192.168.137.10
  
====Electronique: Finalisation soudure Modules====
+
===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 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
Ligne 961 : Ligne 991 :
 
On a donc bien 3 cartes pour les 3 modules de types différents (1 bouton, 1 joystick, 1 gachette)
 
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)
 
PCB pour les 2 joysticks (qui serviront de thumbstick et gachette)
 +
  
 
==<span style="color: Black">Semaine 13 et plus</span>==
 
==<span style="color: Black">Semaine 13 et plus</span>==
  
====Programmation====
+
===Programmation: Finalisation implémentation reconnaissance RPi en manette et transfert vers la console ===
  
'''Raspberry Pi Zero W et PS4'''
+
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.
  
'''Modules Atmega328p et SPI'''
+
[[Fichier: applicationManette.png||center|400px|présentation de l'application, positionnement boutons]]
  
====Electronique====
 
  
 +
==Prototype en fin de parcours==
  
 +
[[Fichier: Manodulable.png||center|700px|prototype filaire en fin de parcours ]]
  
 
=Documents Rendus=
 
=Documents Rendus=
  
(à mettre rapport + git + drive)
+
[[Media: P35_ManetteModulable.pdf]]
  
=Datasheets=
+
[https://archives.plil.fr/tgracias/IMA4_Projet35_ManetteModulable.git Lien vers le Git]

Version actuelle datée du 20 janvier 2019 à 17:50


Vidéo HD

Sommaire


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.
Lien 
https://www.youtube.com/watch?v=qV0SxSJDCYg


Analyse du second concurrent

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

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.
Lien 
: https://www.youtube.com/watch?v=LieHIscadjk


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

La technologie est, aujourd’hui, omniprésente dans notre vie. Les consoles de jeux ont 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.

Bete a corne manette

Choix techniques : matériel et logiciel

Liste de matériel :

Modules boutons/joysticks/gachettes

3 Push buttons :
- O X Y Carré R3 L3
- Guide PS
- start/back
--> 0,45€/unité TTC [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
  1. Recherche connexion SPI entre les modules et la RPi3
  2. Recherche connexion bluetooth entre la RPi3 et la PS4
  3. Recherche connexion bluetooth pour les modules
  4. 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
    1. Prototype filaire : connexions entre les modules et la RPi3 en SPI, connexion Rpi3-PS4 en Bluetooth, avec l'application en filaire à la RPi3
    2. Prototype Bluetooth: connexion Bluetooth entre modules-RPi3-PS4-apllication
Concept manette modulable


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

Concept manette modulable

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

Connexion SPI multi-esclaves

Voici un schéma du fonctionnement souhaité :

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

Connexion Bluetooth PS4-RPi3

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

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

Ressources: [[7]] [[8]] [[9]]

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.

connexion filaire prototype 1 filaire arduino

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

Nous avons également commencé le programme de la connexion SPI pour l'arduino et récupéré les bibliothéques SPI.h avec SPI.c. Nous nous sommes alors concentrer à les comprendre, pour pouvoir 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 :

  1. Réalisation du programme SPI pour arduino
  2. Réalisation du programme SPI pour la RPi
  3. Connexion USB avec la PS4 ou ordinateur
  4. Réalisation de cartes électroniques atmega328p-pu standalone (remplacer les Arduinos)
  5. Remplacer les "PCB arduino" par le module bluetooth et adapter la connexion
  6. Conception 3D de la délimitation 1 axe pour le joystick "gâchette"
  7. 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

PCB bouton
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.

PCB atmega328p-pu

Construction 3D

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


Semaine 6

Programmation: configuration RPi Zero W

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

Electronique: PCB nrf52810

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

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

PCB carte nrf52810

Révision matériel

Pour la réalisation de nos composants électroniques, il nous a fallu faire une révision des composants disponibles à l'école: (les quantités indiquées ci-dessous pourront être augmenté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.

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. 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.

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.

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 :

  1. Préparer la veille la pâte à braser la veille (dans une seringue)
  2. Gommer la carte pour éviter l'oxydation (attention à ne pas retirer les miettes de gomme en soufflant dessus)
  3. 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.
  4. Appliquer les CMS sur la pâte au fur et à mesure (attention ! ne jamais toucher les CMS avec les doigts, toujours utiliser une pince)
  5. Mettre au four
carte electroniques imprimées

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.

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.


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.

Code Arduino-SPI
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.

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 :

  1. La RPi envoie en SPI un tableau avec la valeur 0x0A soit "\n" en première position et que des 0x00 par la suite.
  2. L'arduino reçoit 0x0A, elle va lire l'état du bouton ou de la variable voulue du joystick (par exemple l'axe X)
  3. 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 :

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:

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.

présentation de l'application, positionnement boutons


Prototype en fin de parcours

prototype filaire en fin de parcours

Documents Rendus

Media: P35_ManetteModulable.pdf

Lien vers le Git