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

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.

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.

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

Réalisation du Projet

Feuille d'heures

Voici le tableau d'heures du binôme:

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

Semaine 1

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

Connexion SPI entre les modules (Atmega328p) et la RPi3

SPI: Serial périphérique interface BUS

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

Voici un schéma du fonctionnement souhaité :

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

Connexion Bluetooth PS4-RPi3

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

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

Caracteristiques de la connexion :

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

Rélisation des cartes électroniques

Matériel nécessaire pour un PCB :

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

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.

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.

Révision matériel

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

Cartes Arduino:

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

Cartes nrf52810

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

Cartes modules Boutons

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

Nous avons alors mis-à-jour la liste de composant située plus haut, ainsi que celle de la page IMA4 2017/2018 [10]

Semaine 7

Programmation: Connexion wifi sur RPi Zero W et configuration USB

Pendant cette semaine, nous avons continué la programmation et la configuration des Raspberry Pi 3 et Zero W. Concernant la configuration ssh, nous avons utilisé un téléphone en guise de point d’accès à la RPi Zero W en wifi. Nous avons aussi directement configuré l'OS Jessie, utilisé pour la RPi Zero. On a modifié le fichier cmd.txt. Nous avons étudié comme avoir un périphérique USB gadget sur le port OTG, et pouvoir programmer ce périphérique, on a besoin de ConfigFs. Il s'agit d'un système de fichiers virtuels permettant de créer des périphériques USB.

Programmation: Bootloader sur Atmega328p-pu

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

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

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

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

Electronique : soudure carte de tests pour modules

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

Semaine 8

Programmation

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

Electronique : Correction soudure et soudure CMS

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

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

Comment souder des CMS ?

Les CMS sont des composants montés en surface c'est à dire qu'ils sont montés du même côté que les pistes cuivrées (à l'opposé des composants traversants) et sont de petite tailles souvent de l'ordre du millimètre. La taille est déterminée par 4 chiffres : les 2 premiers pour la longueur et les 2 derniers pour la largeur. On a du 1206,0805,0603 ou encore 0402. Il est même possible de trouver plus petit. A l'école nous utilisons souvent du 0603, c'est le cas de nos composants. Pour souder des CMS 0603, il nous faut utiliser une autre méthode qui n'est pas le fer à souder :

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

Bilan soudure nrf52810

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

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

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

Semaine 9

Programmation: reconnaissance en tant que manette PS4

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

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

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

Programmation: Premiers tests SPI sur la carte Atmega328p=

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

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

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

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

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

Il faut également paramétrer l'atmega328p en Slave. On note que dans un premier temps, le programme sera codé avec l'arduino IDE (fichiers .ino).

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

 #include <SPI.h>

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

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

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

// SPI interrupt routine ISR (SPI_STC_vect) {

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

} // end of interrupt routine SPI_STC_vect

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

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

Electronique : Fritzing révision

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

Semaine 10

Programmation: Raspberry Pi implémentation périphérique USB en tant qu e manette PS4

Nous avons continué le travail effectué pour pouvoir programmer un périphérique USB sur le port OTG. Comme nous l'avions vu, il est nécessaire de faire des configurations préalables avec ConfigFs. Nous avons procédé aux réglage suivants:

• Rajouter dtoverlay=dwc2 dans le fichier boot/config.txt: ce qui permet de charger le driver dwc2 pour la gestion de l’OTG qui se trouve dans le noyau.
• Rajouter dwc2 et libcomposite dans le fichier data/etc/modules pour initialiser configFs.

Ainsi cette semaine, pour tester la prise OTG, nous avons décidé de lancer un script habituellement utilisé. Nous avons choisi le script Serial Adapter qui est censé permettre de se connecter à la RPi Zero W en SSH via ce port. Après quelques modifications et plusieurs petits bugs, nous avons réussi à faire fonctionner le ssh via le port OTG.

Cependant, notre problème reste le même, notre script mélangé avec les informations sur la PS4 n'est toujours pas fonctionnel.

Programmation: Modules, Raspberry Pi et SPI

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

On rappelle, comme vu des semaines 1 à 4, pour la RPI3 (tout comme la RPi Zero W) utilise les broches : SCLK (23), MISO(21), MOSI (19) et SPI CS0 (24), SPI CS1 (26). On la programme en Master. Notre code en C se compose de 3 étapes :

• L'initialisation et la configuration de la communication SPI vue par la RPi (nombre de bits par mots échangés, vitesse, mode, maître ou esclave...).
• L'envoi d'une requête par exemple "0x0A" soit "\n".
• Réception des données octet par octet sur le bus en retour.

Deux bibliothèques sont importantes :

#include <sys/ioctl.h>          //Pour la transmission
#include <linux/spi/spidev.h>   //Pour SPI

On va déclarer des variables globales qu'on utilisera pour la configuration :

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

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

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

Application: début et principe

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

Voici le principe d'application que nous souhaitons développer : Par définition de notre projet, la manette doit être modulaire. De ce fait, les boutons seront amenés à changer. Ainsi, l'utilisateur devra choisir les boutons qu'il veut utiliser et les faire glisser sur la position du bouton de la manette officielle. On réalise la correspondance entre les boutons modulaires et les boutons officiaux. Le joueur n'est pas obligé de respecter les types de boutons prévus de base : par exemple joystick à la place des flèches directionnelle ou bouton carré au lieu de la flèche du haut.

Semaine 11

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

Raspberry Pi Zero W et PS4

Lors de recherches supplémentaires, nous avons essayé de voir s'il un pilote de gestion du périphérique serait nécessaire à la connexion de notre pseudo manette.

Raspberry PI, Atmega328p et SPI

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

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

A la fin de cette semaine, nous avons alors des codes Atmega-SPI (.ino) et des codes Raspberry-SPI (.c) permettant l'échange de données. Le but est maintenant de l'adapter aux cartes imprimées et de le rendre pleinement fonctionnel pour plusieurs cartes à la fois, puis ajouter une boucle de vérification en continue jusqu'à une deuxième requête de la RPi. Pour les modules, le plus important est la déclaration des interruptions "quand envoyer les octets d'états?" puis la boucle d'envoie avec SPI.tranfer() (voir photo gauche).

Quant à la raspberry, le plus important est la fonction transfer(). Elle permet d'envoyer un tableau d'octets par SPI et de retourner le tableau d'octets quelle peut recevoir en retour (voir photo droite).

Electronique: réalisation au propres des PCB modules

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

Semaine 12

Programmation

Raspberry Pi Zero W et PS4

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

Raspberry PI, Atmega328p et SPI

Lors de cette semaine, nous avons entièrement abandonné les arduinos pour garder uniquement nos cartes électroniques Atmega328p-pu enfin imprimés, soudées, alimentées et prêtes à l'emploi. Nous avons alors continué les test SPI pour un seul device sur celles-ci jusqu'à réussir la récupération des valeurs des capteurs (bouton ou joystick) et commencé une ébauche de programmation pour deux devices. Notre programme pour un device fonctionne de la manière suivante :

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 :

Pour finir sur la communication USB, après avoir récupéré les valeurs des boutons et initié la manette en gadget USB, nous avons essayé de mettre en place le transfert des données comme pour un clavier vers la PS4. Mais travaillant toujours dessus, nous avons pour l’instant eu très peu de résultat concluant mais très proche.

Programmation: Finalisation communication SPI

Durant ces dernières semaines, nous nous sommes concentrés sur la réalisation de la communication SPI avec deux devices. Pour cela, on télécharge un programme de récupération d'états (Programme arduino) sur chaque Atmega328p-pu selon le capteur choisi. Pour la raspberry pi, celle ci ouvrira l'accés aux devices à tour de rôle. (/dev/spidev1 puis /dev/spidev2). Lors de cette communication à plusieurs devices, plusieurs problèmes ont été rencontré. Les différenciations des octets reçu et des correspondances octet-device ont été difficile. En effet, dans un premier temps, nous souhaitons stocker les valeurs du devices 1 dans un tableau 1 et les valeurs du device2 dans un tableau 2. Cependant à chaque communication, ces valeur changeait de position. Ce changement de position, rend le traitement des données par la suite impossible. Dans un deuxième temps nous souhaitions également envoyé un caratère 'J' ou 'B' pour faire la différence entre la réception depuis un Bouton ou depuis un joystick. Mais l'ajout de ce caractère rendait la communication encore plus compliquée.

Pour résoudre ce problème, nous avons choisi de modifier directement les octet des états depuis les Atmega328p-pu, soit avant l'envoie par le bus SPI. Nous perdons de l'information mais nous avons directement un identifiant Joystick/sel, Joystick/X, Joystick/Y ou encore Bouton ou pas bouton dans les octets transmis et reçus. Nous avons alors 0b1XXXXXXX pour un Joystick ou 0b0XXXXXXX pour le bouton. Puis au niveau du joystick, nous avons 0b111XXXXX pour le bouton joystick "sel", 0b101XXXXX pour l'axe X et 0b110XXXXX pour l'axe Y. Nous pouvons alors par la suite directement traiter les valeurs, et voir quel état des modules a changé.

Comme nous perdons en précision (décalage de 1 ou 3 bits sur la droite), les valeurs des états du joystick changent. Voici la forme finale de la réception pour les tableaux de stockage r1 (device1 joystick) et r2 (device2 bouton) en décimal:

Application Android suite

Coté Android, il est donc nécessaire de posséder un appareil ayant une communication Bluetooth. Pour la connexion en Bluetooth socket, les deux appareils doivent besoin de connaître leurs AdresseMac. Donc, l’application commence par chercher un l’appareil distant pour se connecter à celui-ci. Dès que la connexion est établie, un thread permet de laisser l’application tournée avec en fond de tâche la connexion active. Pour envoyer et recevoir les données, on a besoin de créer un nouveau thread. Puis, une dernière partie qui implémente l’envoie et la réception des données via ce therad. Coté Raspberry, il faudra donc faire avoir une approche équivalente à celle-ci citée ci-dessus. Il faut tout d’abord, activer l’utilisation du Bluetooth sur la Raspberry Pi Zero W. Puis créer, la socket Bluetooth connectée avec la bonne adresse mac.

Prototype en fin de parcours

Documents Rendus

Media: P35_ManetteModulable.pdf

Lien vers le Git