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

Projets IMA5 2015/2016

2016-02-23T12:02:50Z

Mzeggai :

Merci de référencer vos pages de projets ici. Merci aussi d'uniformiser vos formats que ce soit en regardant la présentation des projets déjà créés ou en allant modifier le format des précédents si votre façon de faire vous semble la meilleure. Dans tous les cas un minimum de communication entre les binômes est conseillée.

Toutes les sources doivent être déposées sur notre archive GIT. Le service est disponible à l'URL [https://archives.plil.fr archives.plil.fr]. Connectez-vous avec vos identifiants Polytech'Lille. Sauf indication contraire de vos encadrants, rendez le projet public et mettez le lien sur votre Wiki. Vous pouvez trouver de la documentation sur ce système d'archives sur ce [https://git-scm.com/book/fr/v1 site].

== Répartition des binômes ==

<table border="1">
<tr>
<th>Projet</th>
<th>Elèves</th>
<th>Encadrant Ecole</th>
<th>Rapport décembre</th>
<th>Rapports finaux</th>
<th>Vidéo</th>
</tr>
<tr>
<td>[[P1 Convertisseur DC/DC pour réseau MTDC]]</td>
<td> Mehmet Ilter </td>
<td> Philippe DELARUE </td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P2 Data Logger]]</td>
<td> Hidéo VINOT</td>
<td> Alexandre Boé / Thomas Vantroys </td>
<td> 15/12/2015 12;00</td>
<td> [[Fichier: Dossier_soutenance_P2_Data_Logger_Hideo_VINOT_IMA5SC_2015.pdf]]</td>
<td> mercredi 24 février à 10h avec L. Engels</td>
</tr>
<tr>
<td>[[P4 Jukebox multi-pièces]]</td>
<td> Alexandre Jouy / Julien hérin </td>
<td> Rodolphe Astori / Xavier Redon / Alexandre Boé / Thomas Vantroys </td>
<td> [[Fichier:Pre_soutenance_PFE_Jouy_herin.pdf]] </td>
<td> [[Fichier:Rapport PFE P4 Julien HERIN.pdf]] [[Fichier:Rapport_PFE_Jouy.zip]]</td>
<td> RDV pris le 23/02 avec L. Engels</td>
</tr>
<tr>
<td>[[P9 Système d'hébergement domestique]]</td>
<td> Romain Libaert / Timothée Teneur </td>
<td> Xavier Redon / Alexandre Boé / Thomas Vantroys </td>
<td> 15/12/2015, 10:21, [[Fichier:P9_LIBAERT_TENEUR_DEC15.pdf]]</td>
<td> [[Fichier:PFE_Final_TENEUR_LIBAERT.pdf]]</td>
<td> Tournée le 22/02 par M. Engels</td>
</tr>
<tr>
<td>[[P10 LILLIAD: Connected Learning Center | P10 LILLIAD: learning center connecté]]</td>
<td> Mageshwaran Sekar </td>
<td> Alexandre Boé / Thomas Vantroys </td>
<td> 15/12/2015,07:48, [[Fichier:P10_FYP_December_Report_M_SEKAR.pdf]]</td>
<td> [[Fichier:FYP-P10-Lilliad-MSEKAR.pdf]]</td>
<td> </td>
</tr>
<tr>
<td>[[P11 Spectateur augmenté]]</td>
<td> Teresa Tumbragel </td>
<td> Alexandre Boé / Thomas Vantroys </td>
<td> </td>
<td> [[Fichier:Teresa Tumbragel-Rapport Spectateur Augmente.pdf]] </td>
<td> NA </td>
</tr>
<tr>
<td>[[P12 Capteurs enfouis pour vieillissement du béton]]</td>
<td> JULITA Alex </td>
<td> Alexandre Boé / Thomas Vantroys </td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P14 Localisation dans le corps humain]]</td>
<td> Matthieu Marcadet </td>
<td> Alexandre Boé / Thomas Vantroys </td>
<td> 15/12/2015, 10:52, [[Fichier:Rapport_intermediaire_PFE_Marcadet.pdf]]</td>
<td> [[Fichier:Rapport_PFE_P14_Matthieu_Marcadet.pdf]]</td>
<td> </td>
</tr>
<tr>
<td>[[P18 Meuble intelligent]]</td>
<td> Kevin Colautti / Benjamin Lefort </td>
<td> Rémy Bernard / Alexandre Boé / Xavier Redon / Thomas Vantroys </td>
<td> 14/12/2015, 14:44, [[Fichier:P18_pre_soutenance.pdf]]</td>
<td> [[Fichier:Rapport_P18_COLAUTTI_LEFORT.pdf]]</td>
<td> Tournée le 22/02 par M. Engels</td>
</tr>
<tr>
<td>[[Automatic Soldering System Project|P20 Placeur de composants sur PCB]]</td>
<td> Jean Wasilewski & Pierre Letousey </td>
<td> Xavier Redon / Thomas Vantroys / Alexandre Boé </td>
<td> [[Fichier:P20_ASSP.pdf]]</td>
<td> [[Fichier:IMA5-ASSP-JWPL.pdf]]</td>
<td> Rendez-vous pris avec M. Engels le vendredi 25 Février à 10h </td>
</tr>
<tr>
<td>[[P24 Nuage pour sites Web]]</td>
<td> Jeremie Denechaud / Thibaut Scholaert </td>
<td> Xavier Redon / Thomas Vantroys </td>
<td> 15/12/2015, 12:02, [[Fichier:P24_Denechaud_Scholaert.pdf| Rapport intermédiaire de projet]]</td>
<td> </td>
<td> Fait Maison</td>
</tr>
<tr>
<td>[[P25 Architecture ROS pour des véhicules autonomes intelligents]]</td>
<td> Jean-Michel Tournier / Cyril Smagghe </td>
<td> Vincent Coelen et Rochdi Merzouki </td>
<td> 15/12/2015,09:04, [[Fichier:P25-2015_Smagghe_Tournier_decembre.pdf]]</td>
<td> [[Fichier:Rapport_final_P25_Smagghe_Tournier.pdf]]</td>
<td>RDV mercredi 24 15h </td>
</tr>
<tr>
<td>[[P26 Robot de forgeage et d’usinage]]</td>
<td> Bertrand Yvernault / Louis Thebault </td>
<td> Rochdi Merzouki </td>
<td> 14/12/2015, 17:51</td>
<td> </td>
<td>Tournée le 22/02 par M. Engels </td>
</tr>
<tr>
<td>[[P27 Robot de fraiseuse]]</td>
<td> Flavien Royer / Maxime Morisse </td>
<td> Rochdi Merzouki </td>
<td> 14/12/2015, 19:06, [[Fichier:Rapport_Royer_Morisse.pdf]]</td>
<td>[[Fichier:RapportPFE_ROYER_MORISSE.pdf]] </td>
<td> mardi 23 février à 11h15 avec Laurent Engels</td>
</tr>

<tr>
<td>[[P30 Thermostat connecté et intelligent]]</td>
<td> TISSOT Elise / TIRABY Céline </td>
<td> Guillaume Renault / Alexandre Boé / Xavier Redon </td>
<td>15/12/2015, 00:35, [[Fichier:Rapport_PFE_TISSOT_TIRABY.pdf‎ ]] </td>
<td> [[Fichier:Rapport_final_PFE_TISSOT_TIRABY.pdf]] </td>
<td> Tournée le 19/02 par L. Engels </td>
</tr>
<tr>
<td>[[P32 Récupération d'énergie pour balise BLE]]</td>
<td> Quentin Sultana </td>
<td> Frédéric Giraud / Alexandre Boé / Thomas Vantroys </td>
<td> 13/12/2015, 19:31, [[Fichier:CR Miprojet_Sultana.pdf]]</td>
<td> [[Fichier:Rapport_P32_Sultana.pdf]]</td>
<td> RDV L. Engels le 24/02 </td>
</tr>
<tr>
<td>[[P33 Réalisations en faveur de l'accessibilité de jeux vidéos]]</td>
<td> Jérôme Bailet / Mehdi Zeggaï </td>
<td> GAPAS / Laurent Grisoni / Thomas Vantroys </td>
<td> 14/12/2015, 10:54, [[Fichier:PFE_IMA5_Rapport_intermediaire_Bailet_Zeggai.pdf]]</td>
<td> [[Fichier:PFE_IMA5_P33_Rapport_final_Bailet_Zeggai.pdf]]</td>
<td> RDV L. Engels le 25/02 </td>
</tr>
<tr>
<td>[[P35 Robot de test pour le sport de Golf]]</td>
<td> Deborah Saunders </td>
<td> Rochdi Merzouki </td>
<td> 15/12/2015, 12:07</td>
<td> </td>
<td> </td>
</tr>

<tr>
<td>[[P34 Optimisation de trajectoire pour un robot de curiethérapie]]</td>
<td> Sandra HAGE CHEHADE / Thomas DANEL </td>
<td> Vincent COELEN / Rochdi MERZOUKI </td>
<td> 15/12/2015, 12:02</td>
<td> </td>
<td> </td>
</tr>

<tr>
<td>[[P40 Maquette mécatronique durcie d'ascenseur 5 étages]]</td>
<td> Louis CHAUCHARD / Romain IMBERT </td>
<td> Blaise CONRARD </td>
<td> 14/12/2015, 19:21</td>
<td> [[Fichier:IMA5_P40_Chauchard_Imbert_RapportFinal.pdf‎]] </td>
<td> RDV L. Engels le 23/02 </td>
</tr>
<tr>
<td>[[P13 Plateforme expérimentation IOT]]</td>
<td> ROCHE François </td>
<td> Alexandre Boé / Thomas Vantroys </td>
<td> 14/12/2015, 19:37, [[Fichier:PFE_P13_Plateforme_expérimentation_IOT.pdf]] </td>
<td> [[Fichier:PFE_P13-Plateforme_expérimentation.pdf]]</td>
<td> Tournée le 22/02 par M. Engels </td>
</tr>
<tr>
<td>[[Implantation d'un filtre FIR-FX-LMS sur FPGA pour l'annulation de Bruit Acoustique]]</td>
<td> Bown Alexander / Piat Valentin </td>
<td> Alexandre Boé / Thomas Vantroys </td>
<td> NA </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[Pilulier automatique]]</td>
<td> Manouk Simon / Corentin Duplouy </td>
<td> Alexandre Boé / Thomas Vantroys </td>
<td> NA </td>
<td> [[Fichier:Rapport Duplouy Simon.pdf]] </td>
<td> RDV L. Engels le 23/02 </td>
</tr>
</table>

Fichier:PFE IMA5 P33 Rapport final Bailet Zeggai.pdf

2016-02-22T23:46:22Z

Mzeggai : a téléversé une nouvelle version de « Fichier:PFE IMA5 P33 Rapport final Bailet Zeggai.pdf »

Fichier:PFE IMA5 P33 Rapport final Bailet Zeggai.pdf

2016-02-22T23:44:31Z

Mzeggai : a téléversé une nouvelle version de « Fichier:PFE IMA5 P33 Rapport final Bailet Zeggai.pdf »

P33 Réalisations en faveur de l'accessibilité de jeux vidéos

2016-02-22T23:34:08Z

P33 Réalisations en faveur de l'accessibilité de jeux vidéos

2016-02-22T22:51:50Z

Mzeggai : /* Semaine 19 (du 15/02/2016 au 21/02/2016) */

__TOC__
 
==Cahier des charges==
===Présentation générale du projet===

====Contexte====

[[Fichier:logo_la_gerlotte.jpg|thumb|left|La Gerlotte de l'association La vie,autrement ...]]

Les jeux vidéos se sont largement répandus dans le monde aujourd'hui et sont présents sur toutes les plates-formes : téléphones portables, consoles, ordinateur, tablettes. Ils offrent une expérience ludique et divertissante aux utilisateurs au nombre grandissant. Cependant jouer à un jeux vidéos demande de la pratique : il faut manipuler la souris ou le joystick avec brio tandis que la seconde main parcourt le clavier, les manettes de jeux de plus en plus complexes où nos doigts virevoltent en même temps sur les milliers de boutons. Tout cela requiert une grande concentration et des heures d'apprentissage non négligeables.

le sujet est d'autant plus difficile pour les personnes handicapées qui souhaitent s’amuser sur un jeu vidéo actuel. Quels sont les moyens qu’un accidenté lourd ou un individu handicapé depuis sa naissance, pourrait utiliser pour se détendre sur un jeu ?
En fonction de la nature du handicap, des solutions diverses et variées existent.

La Gerlotte, est une maison d’accueil spécialisée de l'association La vie, autrement ..., qui accueille des adultes polyhandicapés dépendants dans tous les actes de la vie quotidienne, à l’exclusion des personnes présentant un gros trouble du comportement ou de la personne.

Nous avons pour projet de permettre l'accessibilité de jeux vidéos aux personnes handicapées de l'établissement et de leur apporter ainsi ce moyen de divertissement.

====Objectif du projet====

Permettre à des personnes handicapées l'accès aux jeux vidéos.

====Description du projet====

Afin de rendre accessible des activités ludiques deux approches sont possibles, une adaptation ou une création des périphériques de jeux (manettes, ...) ou une modification de système existants en les rendant plus interactifs. Les enfants et adultes en situation de polyhandicap sont dans l'incapacité physique de manipuler les télécommandes et joysticks prévus avec les consoles de jeux vidéos classiques (wii, nintendo,..). Le projet est de pouvoir leur rendre accessibles ces moyens de se divertir en trouvant des adaptations (type contacteur) correspondant à leurs capacités. Quelques pistes envisagées (non exclusives) : une commande simple BCI (Brain Computer Interface) compatible avec les logiciels existants fonctionnant en mode défilement, ou encore un contacteur au clignement intentionnel de paupière enregistré par webcam...
Ce projet sera effectué à destination des habitants de la maison d'accueil spécialisée de La Gerlotte de Marcq-en-Barœul. Cette résidence accueille des personnes adultes polyhandicapées dépendantes.

===Étapes du projet===
* Rencontre avec le personnel de la Gerlotte et établissement du cahier des charges et des attentes
* "Clôture" du cahier des charges et début de l'élaboration des adaptations convenues
* Tests des adaptations établies avec les résidents de la Gerlotte, et prise en compte des retours

===Choix techniques : matériel et logiciel===
* Arduino Leonardo [fourni le 13/10/2015]
* Sparkfun Analog Joystick [fourni le 21/10/2015]
* 2 boutons poussoirs [fourni le 21/10/2015]

==Avancement du Projet==

===Semaine 1 (du 28/09/2015 au 04/10/2015)===
Rendez-vous à la Gerlotte du mercredi 30/09/2015 :
* Rencontre avec l'animateur Xavier Hantson et visite de l'établissement la Gerlotte
* Rencontre avec les résidents, présentation des infrastructures en place (adaptations, appareillages), et aperçu des différents handicaps pris en charge
* Réunion avec le directeur David Desmulier, l'ergothérapeute Thierry Danigo et M. Hantson. Brainstorming sur les différents moyens pour l'accessibilité aux jeux vidéos : adaptation, modification de manettes, OneSwitch, support handsfree, reconnaissance oculaire (Eye Tracking Tobii avec le SDK, tools et hardware pour 99 euros), le choix de l'eye track inclurait la création d'un jeux vidéo adapté.
* Accord pour le prochain rendez-vous au 14/10/2015, où un premier choix d'adaptation devra être fait afin de commencer les premiers travaux

Après discussions avec M. Vantroys et M. Grisoni, la reconnaissance oculaire n'est pas un choix que nous conseillent nos professeurs et la création de jeux vidéos serait un travail beaucoup trop laborieux. À ce jour, nous restons dans l'idée de modification de manettes, périphériques pour pouvoir jouer à des jeux déjà existant. Nous poursuivons nos recherches pour approfondir le sujet ou pour trouver d'autres possibilités.

===Semaine 2 (du 05/10/2015 au 11/10/2015)===
Recherche bibliographique sur les solutions et logiciels existants permettant l’accessibilité aux jeux vidéos pour les personnes handicapées (cf [http://www.capgame.fr CapGame]) :
* GlovePie : commande des jeux par la voix
* AltController : des boites virtuels simulent des touches du clavier lors du passage ou clic de la souris
* Kinesic Mouse : contrôle des jeux par mouvements de la tête, sourcils, lèvres, etc
* UnoJoy : librairie Arduino permettant à partir d'une manette existante ou crée, de la rendre compatible sur Windows/Mac/PS3
* Emulation d'un clavier/souris sur Windows à l'aide d'une plate-forme de développement SMT32F4 ou d'un Arduino Leonardo. Création d'une manette de jeux avec des boutons/joysticks de bornes d'arcades.

===Semaine 3 (du 12/10/2015 au 18/10/2015)===
Réunion à la Gerlotte du mercredi 14/10/2015 en présence de M. Xavier Hantson, Thierry Danigo, Martin Nicolas, Laurent Grisoni.

Proposition et Brainstorming sur les différentes solutions envisagés :
* adaptation d'une manette Wii à partir d'un projet déjà commencé l'an dernier ([https://projets-ima.polytech-lille.net:40079/mediawiki/index.php?title=P35_Hack-a-Wii_:_Emulation_de_wiimote_pour_rendre_la_Wii_accessibles_aux_personnes_handicap%C3%A9es lien]), solution orientée pour la console Nintendo Wii
* création d'une manette adaptable à partir d'un microcontrôleur de type Arduino par exemple, orientée plutôt pour les jeux PC.
* intégration de jeux vidéos devenus libres, jeux rétros de l'époque Atari, sur les systèmes Rapsberry Pi ou Banana Pi

Prochaine réunion fixée au mercredi 4/11/2015 à 14h30 à La Gerlotte. Pour cette date, il a été convenu de créer un Google Docs ouvert à tous les encadrants du projet permettant de répertorier tous les liens des pistes de recherches abordées et des solutions déjà existantes en France ou à l'étranger. Lors de ce rendez-vous il est prévu d'observer l'utilisation d'un PC par certains résidents.

===Semaine 4 (du 19/10/2015 au 25/10/2015)===
Durant cette semaine, nous avons discuté avec M. Vantroys sur la manière dont nous pourrions présenter un prototype du système imaginé. Il se présenterait sous la forme d'une simple manette constituée d'un joystick et de quelques boutons poussoirs, le tout contrôlé par un Arduino Leonardo. Ainsi, on pourrait présenter au personnel de la Gerlotte une simple manette permettant de jouer à des jeux émulés simples, manette qui serait algorithmiquement facile à paramétrer, et donc faire une démonstration de son fonctionnement.

L'objectif pour les prochains jours sera de mettre en place et de tester cette manette.

===Semaine 5 Vacances de la Toussaint (du 26/10/2015 au 01/11/2015)===
Création d'une manette de jeux simple à l'aide d'un Arduino Leonardo.

Le Leonardo a l'avantage d'être reconnu directement sur l'ordinateur comme un clavier/souris. Les classes Keyboard et Mouse permettent d'émuler ces périphériques d'entrées.

Cependant pour pouvoir être reconnu en tant que manette de jeux il faut modifier la librairie standard USB et le descripteur HID.

Ce prototype dispose d'un joystick analogique 2 axes et de 6 boutons poussoirs (1 bouton est inclus avec le joystick). Il est optimisé pour jouer à des jeux de GameBoy Advance ou rétros (SuperNES, Master System, Gameboy ...) dont les manettes ne disposent pas énormément de touches.

[[Fichier:kirby-nightmare-in-dream-land-gba-1.jpg|left|thumb|250px|Test de Kirby Nightmare in Dreamland sur GBA fonctionnel]]

[[Fichier:joystickLeonardo.jpg|thumb|center|300px|Arduino Leonardo comme manette de jeux]] 

===Semaine 6 (du 02/11/2015 au 08/11/2015)===
Réunion à la Gerlotte du mercredi 04/11/2015 en présence de M. Martin Nicolas:
* découverte de divers logiciels et matériels à disposition des résidents de La Gerlotte : émulateur de souris avec contacteurs (Mouse Mover), système joystick/clic gauche, logiciel de gestion de la souris à partir des mouvements du visage par webcam.
* observation de l'utilisation d'un ordinateur par un résident (Bertrand), notamment sur un jeu de fléchettes à partir d'un joystick et d'un bouton-clic. Bertrand comprend et agit normalement sur le jeu cependant il lui est difficile de coordonner plusieurs paramètres en même temps tels que la gestion de force et la précision du tir.
* présentation du premier prototype développé : la manette de jeux Arduino Leonardo. Démonstration sur un jeux de Game Boy Advance (Super Mario World) à partir du système d'émulation RomStation.
* discussion sur les diverses améliorations que l'on pourrait apporter sur le prototype : création d'une interface graphique permettant la gestion des fonctions implémentées dans la carte Arduino (gestion des touches et des options), automatisation des touches de manière physique ou algorithmique, éclatement des directions du joystick sur plusieurs contacteurs, adaptation jack-pin arduino afin d'utiliser les boutons switch de type Orby.

Prochaine réunion fixée pour le mercredi 25/11/2015 à 14h30 à La Gerlotte. Pour cette date, nous poursuivrons nos recherches afin d'apporter des améliorations du prototype.

===Semaine 7 (du 09/11/2015 au 15/11/2015)===
Rendez-vous au centre au centre CRNT de l'association APF (Association des Paralysés de France) avec M. Danigo. Nous avons récupéré quelques contacteurs, le standard de la connectique dans le domaine du handicap est le jack (principalement 3.5mm mono). Pour pouvoir les utiliser sur notre dispositif il faut utiliser des jacks femelles 3.5mm mono. Après présentation du prototype nous avons discuté de l'ergonomie du système. Il serait judicieux de construire un boitier où l'on brancherait les contacteurs dans les jacks femelles. Réaliser un PCB et ajouter des mousses à l'intérieur pour que le système soit plus solide.

[[Fichier:button.png|center|thumb|180px|Contacteur Jelly Bean Twist]]

===Semaine 8 (du 16/11/2015 au 22/11/2015)===

Amélioration du prototype par les jacks femelles 3.5mm mono pour pouvoir utiliser les contacteurs, et ajout d'interrupteurs à levier pour automatiser une touche.

===Semaine 9 (du 22/11/2015 au 29/11/2015)===

Réunion à la Gerlotte du mercredi 25/11/2015 en présence de M. Martin Nicolas, M.Xavier Hantson et M.Thierry Danigo:
* Présentation du prototype et des améliorations qui ont été apportées
* Discussion sur les prochaines modifications:
** Éclater le joystick sur plusieurs contacteurs tout en conservant le joystick (dans le but de rendre le système le plus accessible possible). Si le joystick est éclaté sous la forme de 4 boutons directionnels, il faudra penser à annuler la commande lorsque 2 directions contraires sont pressées (haut-bas et droite-gauche).
** Gérer l'automatisation d'une touche de façon périodique et non tout-ou-rien, fréquence qui devra être ajustable par potentiomètre par exemple.

La prochaine réunion est fixée au mercredi 06/01/2016 à 14h30. Pour cette date, nous travaillerons et progresserons sur les axes d'amélioration qui nous ont été proposés, et nous ferons le point sur la soutenance de mi-parcours.

Réunion à l'IRCICA du jeudi 26/11/2015 en présence de M. Laurent Grisoni, M.Samuel Desgrande et Mme.Patricia Plenacoste:
* Présentation du projet à l'Institut Médico-Éducatif Les Papillons Blancs. Nous avons observé une séquence vidéo dans laquelle un enfant handicapé mental et moteur joue à un jeu vidéo de tir sur une cible à partir d'une Kinect. La Kinect va détecter une accélération dans une zone globale et la difficulté consiste à séparer les mouvements parasites involontaires de l'enfant au geste décisif et intentionnel du lancer.
* Présentation de notre projet à La Gerlotte et du prototype de manette de jeux. L'idée d'une interface graphique permettant un mapping des commandes de la manette Arduino est envisageable. L'on pourrait configurer les touches afin qu'elles émulent l'appui de 2 touches successives (ex: saut + avancé).
* Le but de cette réunion serait d'envisager la fusion des 2 projets (Papillons Blancs et Gerlotte) ou l'échange des systèmes afin que dans chaque établissement puisse profiter des réalisations.
* Proposer à La Gerlotte de tester et s'approprier le prototype pendant 2-3 semaines afin d'avoir un feedback utilisateur.

===Semaine 10 (du 30/11/2015 au 06/12/2015)===
Test du joystick HKD-FW22 pour fauteuil roulant switch 4 axes à connectique serre-fils (screw terminal). Un des interrupteurs est usé et réagit d'une mauvaise façon.

[[Fichier:joystickScrew.jpg|center|thumb|180px|Joystick 4 Axis Screw Terminal]]

Amélioration du prototype: automatisation de touches et réglage de la fréquence par des potentiomètres. Chaque potentiomètre est relié à un port analogique et va délivrer une tension. En fonction de la valeur de cette dernière, la période entre 2 appuis successifs sera défini. Par simplicité la fonction de calcul de la période est f(x) = 2 * x. La période maximale est de 2s, et la période minimale de 0s ce qui correspond à un appui constant.

===Semaine 11 (du 07/12/2015 au 13/12/2015)===
Étude des logiciels JoyMouse et JoyToKey avec une manette de jeux.
JoyMouse se concentre sur l'émulation d'une souris avec une manette. L'accélération, la sensibilité, la vitesse ainsi que les clics sont interfaçables facilement.
JoyToKey permet égalemment d'émuler les fonctions de la souris à partir d'une manette mais également simuler des touches claviers. L'interface est beaucoup plus complexes, avec des profils utilisateurs et il est possible d'automatiser une action.

Implémentation Joystick-pad avec boutons. Fonctionne en parallèle du joystick analogique.

Avancement du rapport.

===Semaine 12 (du 14/12/2015 au 20/12/2015)===

Finalisation du rapport et préparation de la soutenance mi-parcours.

===Semaine 13 (du 04/01/2016 au 10/01/2016)===

Réunion à la Gerlotte du mercredi 06/01/2016 en présence de M. Martin Nicolas, Maxime (jeune en situation de handicap suivi par le SAVS Liévin) et M. Benoît Barbet:
* Maxime nous a fait part de son vécu et de ses attentes concernant son utilisation des jeux-vidéo. Nous avons ainsi pu lui présenter le fonctionnement de notre projet.
* Pour l'utilisation de son ordinateur, Maxime utilise un trackball qu'il commande au pied. Nous allons donc réfléchir à la possibilité d'intégrer un trackball à notre système par USB. Notre prototype va intégrer un port USB qui permettra d'utiliser tout types de périphériques de commandes tels qu'un trackball, une souris, un joystick USB, une clé Bluetooth.
* Nous avons aussi discuté de l'interface graphique qui permettrait de gérer les différentes combinaisons de commandes possibles. Nous travaillerons sur ce point dans les jours à venir et nous analyserons si une interface fonctionnelle est envisageable.

La prochaine réunion est fixée au mercredi 20/01/2016 à 14h30. Pour cette date, nous poursuivrons les recherches sur les points évoqués ci-dessus, et nous rendrons notre prototype utilisable afin qu'il puisse être testé par quelques résidents et par Maxime.

Finalisation des fonctionnalités du prototype et de son boitier. Le prototype sera mis à disposition de La Gerlotte le 20/01/2016.

===Semaine 14 (du 11/01/2016 au 17/01/2016)===

Dans le but d'intégrer un port USB à notre prototype, nous utilisons un Raspbery Pi 2. Elle comprend 4 port USB, la distribution Linux que l'on utilise est Raspbian et nous connectons la Raspberry à l'Arduino Leonardo au travers du port série. L'on branche une souris sur l'un des ports USB et un script C va récupérer les événements de la souris (les coordonnées x et y) dans le dossier /dev/input/mice. Les données sont alors envoyés via le port série vers le Leonardo qui va les traduire en coordonnées du joystick. À l'aide de ce système il est alors possible de contrôler les déplacements de son personnage dans un jeux vidéos avec une souris ou un trackball.

===Semaine 15 (du 18/01/2016 au 24/01/2016)===

Sixième réunion à La Gerlotte le mercredi 20/01/2016 en présence de MM. Martin Nicolas, Thierry Danigo.

Nous avons présenté notre prototype prêt à être testé. Il a notamment été essayé par deux résidents de la Gerlotte, et par Maxime du SAVS Liévin, que nous avions rencontré lors de la réunion précédente.

Nous avons connecté 4 contacteurs sur le prototype (2 touches de direction droite/gauche et 2 touches d'action), et les testeurs ont essayé le prototype sur un jeu simple : Tetris. Le test a été plutôt concluant, les utilisateurs arrivaient à utiliser les différents contacteurs avec plus ou moins de facilité. Aussi, nous avons essayé d'intégrer le trackball de Maxime dans notre système, et en retouchant la sensibilité du trackball, nous nous sommes aperçu que le trackball était parfaitement intégrable dans la manette.

Nous avons laissé le prototype à La Gerlotte, afin qu'il puisse être testé "dans le quotidien" des résidents, et avoir un retour sur une telle utilisation.

La prochaine réunion est fixée au 03/02/2016 à 14h30. Pour cette date, nous poursuivrons notre travail sur l'interface graphique de gestion de commandes, et nous réfléchirons sur le design final du système (style du coffret), et sur la conception de plaques électroniques pour le système final.

[[Fichier:protoManetteTupe.jpg|thumb|center|300px|Prototype de manette de jeux prêt à l'emploi]] 

===Semaine 16 (du 25/01/2016 au 31/01/2016)===

Cette semaine nous avons continué l'interface graphique de gestion de commandes. Nous utilisons Processing qui est un environnement de développement libre, multi-plateforme, il permet de programmer en Java et de faire du prototypage rapide.

L'interface graphique réalisé à l'aide de la librairie G4P, est un interface basique qui va permettre d'automatiser chaque bouton du joystick à l'aide de potentiomètres virtuels, mais également de pouvoir effectuer des combinaisons de touches. Des voyants indiquent l'appuie des boutons du joystick sur l'interface.

Concernant la communication de Processing à Arduino nous restons sur le classique envoie-réception série de mots-clés qui vont permettent de modifier le comportement de l'Arduino et ainsi pouvoir remapper les commandes ou les automatiser.

===Semaine 17 (du 01/02/2016 au 07/02/2016)===

Compte-rendu de la réunion du mercredi 03/02/2016 à La Gerlotte :

*Retours sur l'utilisation du proto de manette de jeux que nous avons mis à disposition de La Gerlotte durant 2 semaines. Retours positifs et encourageant, utilisation sur des jeux simples tels que Tetris. Utilisation de 3 contacteurs pour les commandes Gauche, Droite et Rotation du bloc. Manipulation autonome des résidents ou aide d'un ergo pour jouer au jeu (au cas par cas des résidents).
*Partage des commandes entre 2 utilisateurs, permet d'apporter au système une dimension sociale et conviviale. Vincent notamment maitrise parfaitement les commandes de Tetris et a pu jouer pendant plus de 1h sur le jeu de façon autonome.
*Les jeux nécessitent d'être basiques et d'avoir un arrière plan fixe (tetris, pac-man, casse-brique, jeux de combats en 2D par exemple) car la plupart des résidents sont épileptiques. Si l'on prend un jeu de course simple (par ex mario kart) le 1er plan (voiture et perso, route) et l'arrière plan (décor, paysage) changent en permanence, ce qui peut engendrer une sensation de vertige à un épileptique et causer une crise. Notre système offre beaucoup de possibilités d'adaptation pour les résidents.
*Une salle multimédia musique et vidéo va être aménagée à La Gerlotte, la manette de jeux sera mise à disposition dans cette salle et des activités de jeux vidéos seront prévues telles que des tournois entre résidents, jeux en coopération, et permettra aux résidents de s'épanouir tout en améliorant autant leurs capacités motrices, leurs réflexes et ainsi les soigner.

Nous avons décrit également l'avancement sur l'interface graphique pour paramétrer l'automatisation des touches et des combinaisons de touches. Cette interface apporterait plus de possibilités d'adaptation au système. Quelques soucis avec la communication de l'interface avec l'Arduino et quelques soucis à intégrer les fonctions de communication sans modifier toute l'architecture et le code en place sur l'Arduino.
Nous nous sommes mis d'accord sur le fait que 2 boitiers seront réalisés à l'aide de l'imprimante 3D : un boitier pour le système central (Arduino et RaspberryPi) et un boitier pour le joystick et les commandes de direction. Les PCB seront mis en place, le tout pour avoir un produit fini et stable. Ce dernier sera mis à disposition de La Gerlotte.

2 autres manettes supplémentaires seront réalisé, pour Maxime de Liévin et peut-être Le Hameau ?

La prochaine réunion est fixée le mercredi 17/02/2016 14h30 où il sera prévu de tester le produit final, et égalemment de prendre une vidéo d'utilisation de la manette par un/des résident(s).

===Semaine 18 (du 08/02/2016 au 14/02/2016)===

=====PCB shield arduino=====

=====Boîtiers de la manette=====
Nous abandonnons l'idée d'utiliser l'imprimante 3D pour réaliser les boîtiers. En effet l'impression aurait été trop longue (>15h) pour un résultat qui n'aurait pas forcément été solide et optimale.

Nous nous sommes alors tourné pour la découpe laser disponible au Fabricarium et de réaliser des boîtiers en bois. Le processus est rapide (moins de 10 min) et le rendu est assez esthétique. On crée la boite à partir d'un site de [http://carrefour-numerique.cite-sciences.fr/fablab/wiki/doku.php?id=projets:generateur_de_boites génération de boîtes]. Cela va générer un fichier SVG et à l'aide du logiciel Inkscape on ajoute les différents éléments à intégrer: trous, gravures. Plus d'information concernant concernant la découpe laser au Fabricarium disponible [http://www.fabricarium.fr/mediawiki-1.23.5/index.php?title=Speedy_400 ici].

[[Fichier:decoupeJoystick.png|left|thumb|200px|SVG du boîtier du joystick]]

[[Fichier:decoupeArduinoRasp.png|center|thumb|200px|SVG du boîtier du système central (Arduino & Raspberry Pi 2)]] 

=====Interface graphique de la manette=====
Nous avons finalisé l'interface graphique de la manette qui permet de remapper les commandes et de réaliser des combinaisons de touches.

En cliquant sur le bouton "Config" cela ouvre une fenêtre qui va permettre de remapper les boutons de la manette.
Il est possible d'affecter 2 boutons par jack, avec un intervalle de temps les séparant et également configurable.
B1 correspond au 1er bouton du jack, et B2 le 2ème si affecté.
Le bouton "Défaut" dans la fenêtre de configuration remet le jack a l'état initial.

L'interface communique avec l'Arduino via le port série pour envoyer des données. Lors de l'appuie sur le bouton "Config" d'un jack, une fenêtre s'ouvre et la manette est désactivée tant que la configuration n'est pas terminée (afin d'éviter d'éventuels bugs). Les données envoyés à l'Arduino sous forme de chaîne de caractère sont :
* ID du jack à configurer
* Numéro du 1er bouton à affecter
et si combinaison de touches, seront envoyés en plus :
* Numéro du 2ème bouton
* Intervalle de temps (en ms) séparant le 1er et 2ème bouton
En cliquant sur "Ok" la nouvelle configuration du jack est envoyée et la manette est re-activée.

[[Fichier:mappingBoutonsGUI.png|left|thumb|200px|Interface graphique de la manette]]

[[Fichier:configWindowGUI.png|center|thumb|200px|Fenêtre de configuration des jacks]] 

=====Partie Arduino=====
Du côté de l'Arduino, nous avons adapté le code pour pouvoir gérer des combinaisons de touches. On définit une matrice 8x2 de boutons (8 jacks et 2 boutons potentiels affectés par jack). Lors d'un appuie sur un contacteur, si le 2ème bouton n'est pas affecté (initialement à la valeur 13) la manette enverra que la 1ère commande. Si la valeur est différente, la manette enverra le 1er et le 2eme bouton avec un intervalle de temps configurable sur l'interface graphique.

Une fonction va scruter le port série USB de l'Arduino pour voir si des données sont disponibles. Sur ce port l'on ne reçoit que des données de configuration. On adapte alors la matrice de boutons en fonction des données reçues et on ré-active la manette à la fin de chaque configuration.

===Semaine 19 (du 15/02/2016 au 21/02/2016)===

*Montage du système sur le boitier.

*Soudage des composants sur le PCB (broches pour Arduino, prises jack, potentiomètres, données directionnelles)

*Avancement du rapport

*Réunion à La Gerlotte du 17/02/2016 :

Nous avons présenté la version quasi finalisée de la manette, qui est maintenant constituée de deux boîtiers : un boitier directionnel (joystick et contacteurs directionnel), et un boitier central (Raspberry Pi, Arduino et contacteurs d'action). Deux résidents ont testé la manette, et les tests on été plutôt positifs : l'utilisation de la manette a été plutôt bien assimilée. Nous avons pu les filmer pendant qu'ils jouaient.

Nous avons aussi présenté une interface graphique fonctionnelle. Celle-ci permet la combinaison de 2 touches d'action sur un contacteur (exemple : tirer + sauter).

Notre prochain objectif est de finaliser complètement le système, et si possible produire une deuxième manette...

== Fichiers Rendus ==
Dépôt Github du projet

Rapport intermédiaire du projet : [[Fichier:PFE_IMA5_Rapport_intermediaire_Bailet_Zeggai.pdf]]

P33 Réalisations en faveur de l'accessibilité de jeux vidéos

2016-02-11T15:56:14Z

Mzeggai : /* Semaine 17 */

__TOC__
 
==Cahier des charges==
===Présentation générale du projet===

====Contexte====

[[Fichier:logo_la_gerlotte.jpg|thumb|left|La Gerlotte de l'association La vie,autrement ...]]

Les jeux vidéos se sont largement répandus dans le monde aujourd'hui et sont présents sur toutes les plates-formes : téléphones portables, consoles, ordinateur, tablettes. Ils offrent une expérience ludique et divertissante aux utilisateurs au nombre grandissant. Cependant jouer à un jeux vidéos demande de la pratique : il faut manipuler la souris ou le joystick avec brio tandis que la seconde main parcourt le clavier, les manettes de jeux de plus en plus complexes où nos doigts virevoltent en même temps sur les milliers de boutons. Tout cela requiert une grande concentration et des heures d'apprentissage non négligeables.

le sujet est d'autant plus difficile pour les personnes handicapées qui souhaitent s’amuser sur un jeu vidéo actuel. Quels sont les moyens qu’un accidenté lourd ou un individu handicapé depuis sa naissance, pourrait utiliser pour se détendre sur un jeu ?
En fonction de la nature du handicap, des solutions diverses et variées existent.

La Gerlotte, est une maison d’accueil spécialisée de l'association La vie, autrement ..., qui accueille des adultes polyhandicapés dépendants dans tous les actes de la vie quotidienne, à l’exclusion des personnes présentant un gros trouble du comportement ou de la personne.

Nous avons pour projet de permettre l'accessibilité de jeux vidéos aux personnes handicapées de l'établissement et de leur apporter ainsi ce moyen de divertissement.

====Objectif du projet====

Permettre à des personnes handicapées l'accès aux jeux vidéos.

====Description du projet====

Afin de rendre accessible des activités ludiques deux approches sont possibles, une adaptation ou une création des périphériques de jeux (manettes, ...) ou une modification de système existants en les rendant plus interactifs. Les enfants et adultes en situation de polyhandicap sont dans l'incapacité physique de manipuler les télécommandes et joysticks prévus avec les consoles de jeux vidéos classiques (wii, nintendo,..). Le projet est de pouvoir leur rendre accessibles ces moyens de se divertir en trouvant des adaptations (type contacteur) correspondant à leurs capacités. Quelques pistes envisagées (non exclusives) : une commande simple BCI (Brain Computer Interface) compatible avec les logiciels existants fonctionnant en mode défilement, ou encore un contacteur au clignement intentionnel de paupière enregistré par webcam...
Ce projet sera effectué à destination des habitants de la maison d'accueil spécialisée de La Gerlotte de Marcq-en-Barœul. Cette résidence accueille des personnes adultes polyhandicapées dépendantes.

===Étapes du projet===
* Rencontre avec le personnel de la Gerlotte et établissement du cahier des charges et des attentes
* "Clôture" du cahier des charges et début de l'élaboration des adaptations convenues
* Tests des adaptations établies avec les résidents de la Gerlotte, et prise en compte des retours

===Choix techniques : matériel et logiciel===
* Arduino Leonardo [fourni le 13/10/2015]
* Sparkfun Analog Joystick [fourni le 21/10/2015]
* 2 boutons poussoirs [fourni le 21/10/2015]

==Avancement du Projet==

===Semaine 1 (du 28/09/2015 au 04/10/2015)===
Rendez-vous à la Gerlotte du mercredi 30/09/2015 :
* Rencontre avec l'animateur Xavier Hantson et visite de l'établissement la Gerlotte
* Rencontre avec les résidents, présentation des infrastructures en place (adaptations, appareillages), et aperçu des différents handicaps pris en charge
* Réunion avec le directeur David Desmulier, l'ergothérapeute Thierry Danigo et M. Hantson. Brainstorming sur les différents moyens pour l'accessibilité aux jeux vidéos : adaptation, modification de manettes, OneSwitch, support handsfree, reconnaissance oculaire (Eye Tracking Tobii avec le SDK, tools et hardware pour 99 euros), le choix de l'eye track inclurait la création d'un jeux vidéo adapté.
* Accord pour le prochain rendez-vous au 14/10/2015, où un premier choix d'adaptation devra être fait afin de commencer les premiers travaux

Après discussions avec M. Vantroys et M. Grisoni, la reconnaissance oculaire n'est pas un choix que nous conseillent nos professeurs et la création de jeux vidéos serait un travail beaucoup trop laborieux. À ce jour, nous restons dans l'idée de modification de manettes, périphériques pour pouvoir jouer à des jeux déjà existant. Nous poursuivons nos recherches pour approfondir le sujet ou pour trouver d'autres possibilités.

===Semaine 2 (du 05/10/2015 au 11/10/2015)===
Recherche bibliographique sur les solutions et logiciels existants permettant l’accessibilité aux jeux vidéos pour les personnes handicapées (cf [http://www.capgame.fr CapGame]) :
* GlovePie : commande des jeux par la voix
* AltController : des boites virtuels simulent des touches du clavier lors du passage ou clic de la souris
* Kinesic Mouse : contrôle des jeux par mouvements de la tête, sourcils, lèvres, etc
* UnoJoy : librairie Arduino permettant à partir d'une manette existante ou crée, de la rendre compatible sur Windows/Mac/PS3
* Emulation d'un clavier/souris sur Windows à l'aide d'une plate-forme de développement SMT32F4 ou d'un Arduino Leonardo. Création d'une manette de jeux avec des boutons/joysticks de bornes d'arcades.

===Semaine 3 (du 12/10/2015 au 18/10/2015)===
Réunion à la Gerlotte du mercredi 14/10/2015 en présence de M. Xavier Hantson, Thierry Danigo, Martin Nicolas, Laurent Grisoni.

Proposition et Brainstorming sur les différentes solutions envisagés :
* adaptation d'une manette Wii à partir d'un projet déjà commencé l'an dernier ([https://projets-ima.polytech-lille.net:40079/mediawiki/index.php?title=P35_Hack-a-Wii_:_Emulation_de_wiimote_pour_rendre_la_Wii_accessibles_aux_personnes_handicap%C3%A9es lien]), solution orientée pour la console Nintendo Wii
* création d'une manette adaptable à partir d'un microcontrôleur de type Arduino par exemple, orientée plutôt pour les jeux PC.
* intégration de jeux vidéos devenus libres, jeux rétros de l'époque Atari, sur les systèmes Rapsberry Pi ou Banana Pi

Prochaine réunion fixée au mercredi 4/11/2015 à 14h30 à La Gerlotte. Pour cette date, il a été convenu de créer un Google Docs ouvert à tous les encadrants du projet permettant de répertorier tous les liens des pistes de recherches abordées et des solutions déjà existantes en France ou à l'étranger. Lors de ce rendez-vous il est prévu d'observer l'utilisation d'un PC par certains résidents.

===Semaine 4 (du 19/10/2015 au 25/10/2015)===
Durant cette semaine, nous avons discuté avec M. Vantroys sur la manière dont nous pourrions présenter un prototype du système imaginé. Il se présenterait sous la forme d'une simple manette constituée d'un joystick et de quelques boutons poussoirs, le tout contrôlé par un Arduino Leonardo. Ainsi, on pourrait présenter au personnel de la Gerlotte une simple manette permettant de jouer à des jeux émulés simples, manette qui serait algorithmiquement facile à paramétrer, et donc faire une démonstration de son fonctionnement.

L'objectif pour les prochains jours sera de mettre en place et de tester cette manette.

===Semaine 5 Vacances de la Toussaint (du 26/10/2015 au 01/11/2015)===
Création d'une manette de jeux simple à l'aide d'un Arduino Leonardo.

Le Leonardo a l'avantage d'être reconnu directement sur l'ordinateur comme un clavier/souris. Les classes Keyboard et Mouse permettent d'émuler ces périphériques d'entrées.

Cependant pour pouvoir être reconnu en tant que manette de jeux il faut modifier la librairie standard USB et le descripteur HID.

Plus d'informations sur notre dépôt Github pour l'Arduino Leonardo reconnu en tant que manette de jeux : [https://github.com/LuomuJie/JoystickLeonardo JoystickLeonardo]

Ce prototype dispose d'un joystick analogique 2 axes et de 6 boutons poussoirs (1 bouton est inclus avec le joystick). Il est optimisé pour jouer à des jeux de GameBoy Advance ou rétros (SuperNES, Master System, Gameboy ...) dont les manettes ne disposent pas énormément de touches.

[[Fichier:kirby-nightmare-in-dream-land-gba-1.jpg|left|thumb|250px|Test de Kirby Nightmare in Dreamland sur GBA fonctionnel]]

[[Fichier:joystickLeonardo.jpg|thumb|center|300px|Arduino Leonardo comme manette de jeux]] 

===Semaine 6 (du 02/11/2015 au 08/11/2015)===
Réunion à la Gerlotte du mercredi 04/11/2015 en présence de M. Martin Nicolas:
* découverte de divers logiciels et matériels à disposition des résidents de La Gerlotte : émulateur de souris avec contacteurs (Mouse Mover), système joystick/clic gauche, logiciel de gestion de la souris à partir des mouvements du visage par webcam.
* observation de l'utilisation d'un ordinateur par un résident (Bertrand), notamment sur un jeu de fléchettes à partir d'un joystick et d'un bouton-clic. Bertrand comprend et agit normalement sur le jeu cependant il lui est difficile de coordonner plusieurs paramètres en même temps tels que la gestion de force et la précision du tir.
* présentation du premier prototype développé : la manette de jeux Arduino Leonardo. Démonstration sur un jeux de Game Boy Advance (Super Mario World) à partir du système d'émulation RomStation.
* discussion sur les diverses améliorations que l'on pourrait apporter sur le prototype : création d'une interface graphique permettant la gestion des fonctions implémentées dans la carte Arduino (gestion des touches et des options), automatisation des touches de manière physique ou algorithmique, éclatement des directions du joystick sur plusieurs contacteurs, adaptation jack-pin arduino afin d'utiliser les boutons switch de type Orby.

Prochaine réunion fixée pour le mercredi 25/11/2015 à 14h30 à La Gerlotte. Pour cette date, nous poursuivrons nos recherches afin d'apporter des améliorations du prototype.

===Semaine 7 (du 09/11/2015 au 15/11/2015)===
Rendez-vous au centre au centre CRNT de l'association APF (Association des Paralysés de France) avec M. Danigo. Nous avons récupéré quelques contacteurs, le standard de la connectique dans le domaine du handicap est le jack (principalement 3.5mm mono). Pour pouvoir les utiliser sur notre dispositif il faut utiliser des jacks femelles 3.5mm mono. Après présentation du prototype nous avons discuté de l'ergonomie du système. Il serait judicieux de construire un boitier où l'on brancherait les contacteurs dans les jacks femelles. Réaliser un PCB et ajouter des mousses à l'intérieur pour que le système soit plus solide.

[[Fichier:button.png|center|thumb|180px|Contacteur Jelly Bean Twist]]

===Semaine 8 (du 16/11/2015 au 22/11/2015)===

Amélioration du prototype par les jacks femelles 3.5mm mono pour pouvoir utiliser les contacteurs, et ajout d'interrupteurs à levier pour automatiser une touche.

===Semaine 9 (du 22/11/2015 au 29/11/2015)===

Réunion à la Gerlotte du mercredi 25/11/2015 en présence de M. Martin Nicolas, M.Xavier Hantson et M.Thierry Danigo:
* Présentation du prototype et des améliorations qui ont été apportées
* Discussion sur les prochaines modifications:
** Éclater le joystick sur plusieurs contacteurs tout en conservant le joystick (dans le but de rendre le système le plus accessible possible). Si le joystick est éclaté sous la forme de 4 boutons directionnels, il faudra penser à annuler la commande lorsque 2 directions contraires sont pressées (haut-bas et droite-gauche).
** Gérer l'automatisation d'une touche de façon périodique et non tout-ou-rien, fréquence qui devra être ajustable par potentiomètre par exemple.

La prochaine réunion est fixée au mercredi 06/01/2016 à 14h30. Pour cette date, nous travaillerons et progresserons sur les axes d'amélioration qui nous ont été proposés, et nous ferons le point sur la soutenance de mi-parcours.

Réunion à l'IRCICA du jeudi 26/11/2015 en présence de M. Laurent Grisoni, M.Samuel Desgrande et Mme.Patricia Plenacoste:
* Présentation du projet à l'Institut Médico-Éducatif Les Papillons Blancs. Nous avons observé une séquence vidéo dans laquelle un enfant handicapé mental et moteur joue à un jeu vidéo de tir sur une cible à partir d'une Kinect. La Kinect va détecter une accélération dans une zone globale et la difficulté consiste à séparer les mouvements parasites involontaires de l'enfant au geste décisif et intentionnel du lancer.
* Présentation de notre projet à La Gerlotte et du prototype de manette de jeux. L'idée d'une interface graphique permettant un mapping des commandes de la manette Arduino est envisageable. L'on pourrait configurer les touches afin qu'elles émulent l'appui de 2 touches successives (ex: saut + avancé).
* Le but de cette réunion serait d'envisager la fusion des 2 projets (Papillons Blancs et Gerlotte) ou l'échange des systèmes afin que dans chaque établissement puisse profiter des réalisations.
* Proposer à La Gerlotte de tester et s'approprier le prototype pendant 2-3 semaines afin d'avoir un feedback utilisateur.

===Semaine 10 (du 30/11/2015 au 06/12/2015)===
Test du joystick HKD-FW22 pour fauteuil roulant switch 4 axes à connectique serre-fils (screw terminal). Un des interrupteurs est usé et réagit d'une mauvaise façon.

[[Fichier:joystickScrew.jpg|center|thumb|180px|Joystick 4 Axis Screw Terminal]]

Amélioration du prototype: automatisation de touches et réglage de la fréquence par des potentiomètres. Chaque potentiomètre est relié à un port analogique et va délivrer une tension. En fonction de la valeur de cette dernière, la période entre 2 appuis successifs sera défini. Par simplicité la fonction de calcul de la période est f(x) = 2 * x. La période maximale est de 2s, et la période minimale de 0s ce qui correspond à un appui constant.

===Semaine 11 (du 07/12/2015 au 13/12/2015)===
Étude des logiciels JoyMouse et JoyToKey avec une manette de jeux.
JoyMouse se concentre sur l'émulation d'une souris avec une manette. L'accélération, la sensibilité, la vitesse ainsi que les clics sont interfaçables facilement.
JoyToKey permet égalemment d'émuler les fonctions de la souris à partir d'une manette mais également simuler des touches claviers. L'interface est beaucoup plus complexes, avec des profils utilisateurs et il est possible d'automatiser une action.

Implémentation Joystick-pad avec boutons. Fonctionne en parallèle du joystick analogique.

Avancement du rapport.

===Semaine 12 (du 14/12/2015 au 20/12/2015)===

Finalisation du rapport et préparation de la soutenance mi-parcours.

===Semaine 13 (du 04/01/2016 au 10/01/2016)===

Réunion à la Gerlotte du mercredi 06/01/2016 en présence de M. Martin Nicolas, Maxime (jeune en situation de handicap suivi par le SAVS Liévin) et M. Benoît Barbet:
* Maxime nous a fait part de son vécu et de ses attentes concernant son utilisation des jeux-vidéo. Nous avons ainsi pu lui présenter le fonctionnement de notre projet.
* Pour l'utilisation de son ordinateur, Maxime utilise un trackball qu'il commande au pied. Nous allons donc réfléchir à la possibilité d'intégrer un trackball à notre système par USB. Notre prototype va intégrer un port USB qui permettra d'utiliser tout types de périphériques de commandes tels qu'un trackball, une souris, un joystick USB, une clé Bluetooth.
* Nous avons aussi discuté de l'interface graphique qui permettrait de gérer les différentes combinaisons de commandes possibles. Nous travaillerons sur ce point dans les jours à venir et nous analyserons si une interface fonctionnelle est envisageable.

La prochaine réunion est fixée au mercredi 20/01/2016 à 14h30. Pour cette date, nous poursuivrons les recherches sur les points évoqués ci-dessus, et nous rendrons notre prototype utilisable afin qu'il puisse être testé par quelques résidents et par Maxime.

Finalisation des fonctionnalités du prototype et de son boitier. Le prototype sera mis à disposition de La Gerlotte le 20/01/2016.

===Semaine 14 (du 11/01/2016 au 17/01/2016)===

Dans le but d'intégrer un port USB à notre prototype, nous utilisons un Raspbery Pi 2. Elle comprend 4 port USB, la distribution Linux que l'on utilise est Raspbian et nous connectons la Raspberry à l'Arduino Leonardo au travers du port série. L'on branche une souris sur l'un des ports USB et un script C va récupérer les événements de la souris (les coordonnées x et y) dans le dossier /dev/input/mice. Les données sont alors envoyés via le port série vers le Leonardo qui va les traduire en coordonnées du joystick. À l'aide de ce système il est alors possible de contrôler les déplacements de son personnage dans un jeux vidéos avec une souris ou un trackball.

===Semaine 15 (du 18/01/2016 au 24/01/2016)===

Sixième réunion à La Gerlotte le mercredi 20/01/2016 en présence de MM. Martin Nicolas, Thierry Danigo.

Nous avons présenté notre prototype prêt à être testé. Il a notamment été essayé par deux résidents de la Gerlotte, et par Maxime du SAVS Liévin, que nous avions rencontré lors de la réunion précédente.

Nous avons connecté 4 contacteurs sur le prototype (2 touches de direction droite/gauche et 2 touches d'action), et les testeurs ont essayé le prototype sur un jeu simple : Tetris. Le test a été plutôt concluant, les utilisateurs arrivaient à utiliser les différents contacteurs avec plus ou moins de facilité. Aussi, nous avons essayé d'intégrer le trackball de Maxime dans notre système, et en retouchant la sensibilité du trackball, nous nous sommes aperçu que le trackball était parfaitement intégrable dans la manette.

Nous avons laissé le prototype à La Gerlotte, afin qu'il puisse être testé "dans le quotidien" des résidents, et avoir un retour sur une telle utilisation.

La prochaine réunion est fixée au 03/02/2016 à 14h30. Pour cette date, nous poursuivrons notre travail sur l'interface graphique de gestion de commandes, et nous réfléchirons sur le design final du système (style du coffret), et sur la conception de plaques électroniques pour le système final.

[[Fichier:protoManetteTupe.jpg|thumb|center|300px|Prototype de manette de jeux prêt à l'emploi]] 

===Semaine 16 (du 25/01/2016 au 31/01/2016)===

Cette semaine nous avons continué l'interface graphique de gestion de commandes. Nous utilisons Processing qui est un environnement de développement libre, multi-plateforme, il permet de programmer en Java et de faire du prototypage rapide.

L'interface graphique réalisé à l'aide de la librairie G4P, est un interface basique qui va permettre d'automatiser chaque bouton du joystick à l'aide de potentiomètres virtuels, mais également de pouvoir effectuer des combinaisons de touches. Des voyants indiquent l'appuie des boutons du joystick sur l'interface.

Concernant la communication de Processing à Arduino nous restons sur le classique envoie-réception série de mots-clés qui vont permettent de modifier le comportement de l'Arduino et ainsi pouvoir remapper les commandes ou les automatiser.

===Semaine 17 (du 01/02/2016 au 07/02/2016)===

Compte-rendu de la réunion du mercredi 03/02/2016 à La Gerlotte :

*Retours sur l'utilisation du proto de manette de jeux que nous avons mis à disposition de La Gerlotte durant 2 semaines. Retours positifs et encourageant, utilisation sur des jeux simples tels que Tetris. Utilisation de 3 contacteurs pour les commandes Gauche, Droite et Rotation du bloc. Manipulation autonome des résidents ou aide d'un ergo pour jouer au jeu (au cas par cas des résidents).
*Partage des commandes entre 2 utilisateurs, permet d'apporter au système une dimension sociale et conviviale. Vincent notamment maitrise parfaitement les commandes de Tetris et a pu jouer pendant plus de 1h sur le jeu de façon autonome.
*Les jeux nécessitent d'être basiques et d'avoir un arrière plan fixe (tetris, pac-man, casse-brique, jeux de combats en 2D par exemple) car la plupart des résidents sont épileptiques. Si l'on prend un jeu de course simple (par ex mario kart) le 1er plan (voiture et perso, route) et l'arrière plan (décor, paysage) changent en permanence, ce qui peut engendrer une sensation de vertige à un épileptique et causer une crise. Notre système offre beaucoup de possibilités d'adaptation pour les résidents.
*Une salle multimédia musique et vidéo va être aménagée à La Gerlotte, la manette de jeux sera mise à disposition dans cette salle et des activités de jeux vidéos seront prévues telles que des tournois entre résidents, jeux en coopération, et permettra aux résidents de s'épanouir tout en améliorant autant leurs capacités motrices, leurs réflexes et ainsi les soigner.

Nous avons décrit également l'avancement sur l'interface graphique pour paramétrer l'automatisation des touches et des combinaisons de touches. Cette interface apporterait plus de possibilités d'adaptation au système. Quelques soucis avec la communication de l'interface avec l'Arduino et quelques soucis à intégrer les fonctions de communication sans modifier toute l'architecture et le code en place sur l'Arduino.
Nous nous sommes mis d'accord sur le fait que 2 boitiers seront réalisés à l'aide de l'imprimante 3D : un boitier pour le système central (Arduino et RaspberryPi) et un boitier pour le joystick et les commandes de direction. Les PCB seront mis en place, le tout pour avoir un produit fini et stable. Ce dernier sera mis à disposition de La Gerlotte.

2 autres manettes supplémentaires seront réalisé, pour Maxime de Liévin et peut-être Le Hameau ?

La prochaine réunion est fixée le mercredi 17/02/2016 14h30 où il sera prévu de tester le produit final, et égalemment de prendre une vidéo d'utilisation de la manette par un/des résident(s).

== Fichiers Rendus ==
Dépôt Github du projet : [https://github.com/LuomuJie/JoystickLeonardo JoystickLeonardo]

Rapport intermédiaire du projet : [[Fichier:PFE_IMA5_Rapport_intermediaire_Bailet_Zeggai.pdf]]

Station météo connectée

2016-01-20T22:32:53Z

Mzeggai : /* Envoie de données */

==Cahier des charges==

====Présentation générale du projet====

Notre projet consiste en la création d'une station météo nous donnant la température, éventuellement l'humidité et la luminosité. 
Nous devons avoir un système basse consommation, c'est pourquoi nous devons utiliser un système de mise en veille.

=====Objectif du projet=====

L'objectif sera de pouvoir offrir la possibilité à un utilisateur d'obtenir un certain nombre de données météorologiques en temps réel via une page web.

=====Description du projet=====

Nous devons avoir un système embarqué qui récupérera des informations météorologiques telles que la température, la pression, l'humidité, la luminosité. 
Ces données seront envoyées en wifi à un serveur web qui affichera les informations météorologiques en temps réel. 
Nous nous intéresserons donc au côté Gestion d'énergie avec un mode veille/éveil de notre système embarqué, également au stockage des données, sûrement dans une base de données et leur affichage sur une page web.
 (Nous pourrons utiliser le serveur web créé en Projet de PRA).

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

*Nous utiliserons une carte équipée d'un microcontrôleur et d'un module Wifi à savoir : HUZZAH ESP8266 proposé par Adafruit Industries : 
https://www.adafruit.com/products/2471
*Nous coderons le tout via l'IDE Arduino. 
*Nous utiliserons notre machine virtuelle pour stocker les données et les publier sur le site créé en Projet PRA. 
*Nous n'avons pas encore réfléchi au sujet de l'alimentation (batterie, pile...)

==Étapes du projet==

Partie 1 : Récupérer une donnée (température dans un premier temps) et la stocker sur notre machine virtuelle

Partie 2 : Interface web et affichage des données

Partie 3 : Mode veille et activation du réveil

Partie 4 : Essais en extérieur

==Suivi de l'avancement du Projet==

=====Mise en jambe=====
Nous nous sommes intéressés au choix du matériel et à la prise en main de celui-ci. 
Nous avons donc travaillé avec l'ESP8266 d'Adafruit Industries via l'IDE Arduino. 

=====Accès à une page web avec l'ESP8266=====

Nous avons dans un premier temps cherché à savoir comment utiliser le module wifi et récupérer par exemple une page web.
Nous avons utilisé un exemple contenu dans la bibliothèque Adafruit, permettant de réaliser une requête HTTP en se connectant à un réseau Wifi.
Le module se connecte donc à notre smartphone en Wifi et effectue une requête HTTP basique vers un site quelconque, puis nous renvoie le code html de la page.

=====Envoi de données=====

Avant de s'intéresser aux capteurs que nous intégrerons par la suite, nous avons regardé comment envoyer une donnée (rentrée en statique dans le code Arduino) et l'afficher sur une page web. Pour ce, nous avons simplement fait une requête http sur une page php comportant un script. Nous avons mis un script basique qui crée un fichier et écrit dedans la valeur de la donnée. Nous affichons le contenu du fichier sur notre page web d'application.
Cette page php sera donc uniquement appelée par notre ESP8266 et les valeurs seront affichées sur une page web. Les données sont contenues dans l'url et récupérées par le script php.

=====Stockage des données=====

Pour le stockage des données, nous avions dans un premier temps pensé à une base de données mais nous nous sommes plutôt tourné vers un stockage dans un fichier json pour l'affichage de celui-ci dynamiquement en javascript.

=====Interface Web=====

Nous avons pensé à une interface user-friendly dynamique grâce à AngularJS. Nous allons d'ailleurs y afficher, en plus des données météorologiques envoyées par notre station météo, les détails de notre système : Les technologies, le code, un lien vers le wiki...
Les données sont injectées dans la page web dynamiquement à partir du fichier json contenant les valeurs grâce à angular.
Le tableau de données pourra être trié par date, heure, température, humidité.
http://iot.thibautscholaert.com/

=====Application Android=====

L'application Android affichera les données dans une ListView, du relevé le plus récent au plus ancien. Une requête vers le fichier JSON correspondant est exécutée, et chaque relevé (date-heure-température-humidité) est enregistré dans une base de données SQLite dans le téléphone. La liste est constituée à partir de cette base de données. Pour un relevé, la date, l'heure, la température et l'humidité sont affichés dans un même item. La liste sera actualisable via un bouton spécialement affecté. L'idée de l'application nous étant venue assez tard, l'affichage de cette liste reste (pour l'instant ?) basique, sans mise en forme particulière.

=====Mode Veille=====

Nous avons également pensé comme prévu à un mode veille question d'économie d'énergie. L'objet connecté sera en mode veille presque tout le temps et se réveillera toutes les 30 minutes pour envoyer les données instantanées : température, humidité, date et heure. Cette tâche prend très peu de temps, de l'ordre de quelques secondes, ce temps dépend beaucoup du temps de connection à la borne Wifi (notre téléphone). Nous avons donc un système basse consommation grâce à ce mode veille/réveil.
Aussi, le système embarquera une batterie d'une tension de 3V qui est capable d'alimenter le module ESP8266.

Station météo connectée

2016-01-20T22:28:50Z

Mzeggai :

==Cahier des charges==

====Présentation générale du projet====

Notre projet consiste en la création d'une station météo nous donnant la température, éventuellement l'humidité et la luminosité. 
Nous devons avoir un système basse consommation, c'est pourquoi nous devons utiliser un système de mise en veille.

=====Objectif du projet=====

L'objectif sera de pouvoir offrir la possibilité à un utilisateur d'obtenir un certain nombre de données météorologiques en temps réel via une page web.

=====Description du projet=====

Nous devons avoir un système embarqué qui récupérera des informations météorologiques telles que la température, la pression, l'humidité, la luminosité. 
Ces données seront envoyées en wifi à un serveur web qui affichera les informations météorologiques en temps réel. 
Nous nous intéresserons donc au côté Gestion d'énergie avec un mode veille/éveil de notre système embarqué, également au stockage des données, sûrement dans une base de données et leur affichage sur une page web.
 (Nous pourrons utiliser le serveur web créé en Projet de PRA).

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

*Nous utiliserons une carte équipée d'un microcontrôleur et d'un module Wifi à savoir : HUZZAH ESP8266 proposé par Adafruit Industries : 
https://www.adafruit.com/products/2471
*Nous coderons le tout via l'IDE Arduino. 
*Nous utiliserons notre machine virtuelle pour stocker les données et les publier sur le site créé en Projet PRA. 
*Nous n'avons pas encore réfléchi au sujet de l'alimentation (batterie, pile...)

==Étapes du projet==

Partie 1 : Récupérer une donnée (température dans un premier temps) et la stocker sur notre machine virtuelle

Partie 2 : Interface web et affichage des données

Partie 3 : Mode veille et activation du réveil

Partie 4 : Essais en extérieur

==Suivi de l'avancement du Projet==

=====Mise en jambe=====
Nous nous sommes intéressés au choix du matériel et à la prise en main de celui-ci. 
Nous avons donc travaillé avec l'ESP8266 d'Adafruit Industries via l'IDE Arduino. 

=====Accès à une page web avec l'ESP8266=====

Nous avons dans un premier temps cherché à savoir comment utiliser le module wifi et récupérer par exemple une page web.
Nous avons utilisé un exemple contenu dans la bibliothèque Adafruit, permettant de réaliser une requête HTTP en se connectant à un réseau Wifi.
Le module se connecte donc à notre smartphone en Wifi et effectue une requête HTTP basique vers un site quelconque, puis nous renvoie le code html de la page.

=====Envoie de données=====

Avant de s'intéresser aux capteurs que nous intégrerons par la suite, nous avons regardé comment envoyer une donnée (rentrée en statique dans le code Arduino) et l'afficher sur une page web. Pour ce, nous avons simplement fait une requête http sur une page php comportant un script. Nous avons mis un script basique qui crée un fichier et écrit dedans la valeur de la donnée. Nous affichons le contenu du fichier sur notre page web d'application.
Cette page php sera donc uniquement appelée par notre ESP8266 et les valeurs seront affichées sur une page web. Les données sont contenues dans l'url et récupérées par le script php.

=====Stockage des données=====

Pour le stockage des données, nous avions dans un premier temps pensé à une base de données mais nous nous sommes plutôt tourné vers un stockage dans un fichier json pour l'affichage de celui-ci dynamiquement en javascript.

=====Interface Web=====

Nous avons pensé à une interface user-friendly dynamique grâce à AngularJS. Nous allons d'ailleurs y afficher, en plus des données météorologiques envoyées par notre station météo, les détails de notre système : Les technologies, le code, un lien vers le wiki...
Les données sont injectées dans la page web dynamiquement à partir du fichier json contenant les valeurs grâce à angular.
Le tableau de données pourra être trié par date, heure, température, humidité.
http://iot.thibautscholaert.com/

=====Application Android=====

L'application Android affichera les données dans une ListView, du relevé le plus récent au plus ancien. Une requête vers le fichier JSON correspondant est exécutée, et chaque relevé (date-heure-température-humidité) est enregistré dans une base de données SQLite dans le téléphone. La liste est constituée à partir de cette base de données. Pour un relevé, la date, l'heure, la température et l'humidité sont affichés dans un même item. La liste sera actualisable via un bouton spécialement affecté. L'idée de l'application nous étant venue assez tard, l'affichage de cette liste reste (pour l'instant ?) basique, sans mise en forme particulière.

=====Mode Veille=====

Nous avons également pensé comme prévu à un mode veille question d'économie d'énergie. L'objet connecté sera en mode veille presque tout le temps et se réveillera toutes les 30 minutes pour envoyer les données instantanées : température, humidité, date et heure. Cette tâche prend très peu de temps, de l'ordre de quelques secondes, ce temps dépend beaucoup du temps de connection à la borne Wifi (notre téléphone). Nous avons donc un système basse consommation grâce à ce mode veille/réveil.
Aussi, le système embarquera une batterie d'une tension de 3V qui est capable d'alimenter le module ESP8266.

Cahier groupe n°4

2016-01-14T13:37:07Z

Mzeggai : /* PCBX */

== Cahier des charges de la tâche particulière ==
=== Présentation de la tâche particulière ===
La tâche particulière que nous devons effectuer est de configurer le commutateur Cisco 6009 présent en salle E304. Nous devons dans un premier temps de les mettre à jour de CatOS vers IOS, pour pouvoir dans un second temps mettre en place les différents VLAN. Cette tâche particulière est effectuée avec le groupe n°3 qui s'occupera du commutateur présent dans la salle voisine E306.

[[Fichier:Network architecture.PNG |thumb|center| 600px|<center>Architecture Réseau</center>]]

=== Matériel utilisé pour la tâche particulière ===
* Commutateur Cisco 6009
* Un ordinateur muni d'un port série pour la configuration
* Un câble reliant le commutateur à ce port série

== Suivi de l'avancement du TP ==
===Partie commutateur===
===== Semaine 1 (01/10/2015) =====

* Découverte des commutateurs Cisco 6009 présents en E304 et E306

** Le commutateur possède deux modules constitués d'une carte mère appelée carte superviseur et une carte fille qui est la carte routeur.
** Ces cartes possèdent toutes les deux leurs propres mémoires flash à savoir sup-bootflash pour le superviseur et bootflash pour la carte fille.
** On peut également insérer une carte flash de 20Mo dans le module

Initialement, ces modules fonctionnent sous CatOS pour la plupart d'entre eux.
L'idée est de migrer tout les modules vers des systèmes d'exploitation de type IOS (le seul système utilisé aujourd'hui par Cisco).

* Echange d'un superviseur entre les deux commutateurs afin d'avoir sur chacun d'entre eux un superviseur sous IOS et un autre sous CatOS

* Un des superviseurs en E304 censé fonctionner sous CatOS ne démarre pas correctement

* On décide donc d'utiliser une carte flash formatée sous CatOS grâce à l'autre commutateur présent dans la salle voisine. On y copie également un système CatOS pour le superviseur et un boostrap CatOS

Pour la prochaine séance, l'objectif est d'utiliser cette carte pour booter le 2e module en CatOS.

===== Semaine 2 (08/10/2015) =====

* Le premier module fonctionne correctement sous IOS

* Problème de la semaine précédente : le 2e module refuse de booter, même sous le CatOS initialement présent.

* Les données de la carte ont été supprimées, on ne peut les récupérer car tous les autres modules tournent actuellement sou IOS.

* Il faut trouver une solution pour booter le commutateur sous CatOS d'une autre façon

===== Semaine 3 (15/10/2015) =====

* On cherche une solution pour copier un fichier sur la bootfalsh du module qui ne fonctionne pas :
** xmodem, ymodem, zmodem3
** CuteCom

*Un CatOS, puis un IOS a pu être installé sur le superviseur défectueux depuis une carte mémoire flash. On veut que le système démarre sur une image de IOS. On modifie alors le "boot system" par la commande ''configure terminal'' :
Router#config terminal
Router(config)#boot system flash sup-bootflash:c6sup11-js-mz.121-27b.E1.bin
//On quitte le mode configuration et on sauvegarde les modifications
Router#write

*On se connecte sur le rommon et on modifie le mode de démarrage lors de la mise sous-tension par la commande ''confreg''. Ainsi, le système ne bootera plus sur le ROM Monitor mais sur l'image de l'OS configurée précédemment.

*Pour la prochaine fois, il suffira de brancher les deux superviseurs, de formater en IOS le bootflash et sup-bootflash du superviseur qui était défectueux (slave), et d'y copier les fichiers binaires correspondants depuis l'autre superviseur (master).

La configuration réseau du commutateur se déroule en 3 étapes.

Dans un premier temps, on configure les liaisons trunk. Il s'agit ici de la liaison qui relie le commutateur au routeur en E304, sur l'interface 4/1, et la liaison câble qui relie le commutateur au routeur en E306 sur l'interface 2/2. On entre donc les commandes ci-dessous :

conf t
int Gi4/1
switchport
switchport mode trunk
switchport trunk allowed vlan 1,11-20,110,130
no shut
exit

int Gi2/2
switchport
switchport trunk encapsulation dot1q
switchport mode trunk
switchport trunk allowed vlan 11-20,110,130
no shut
exit

interface GigabitEthernet4/10
switchport
switchport mode trunk
switchport trunk allowed vlan 11-20,110,130
exit

Nous avons ensuite créé les VLAN 11-20, 110 et 130 de cette façon :

conf t
vlan 11
name vlan11
exit

On leur attribue ensuite un port physique du commutateur :

int Gi4/11
switchport
switchport access vlan 11
no shut
exit

On obtient donc le schéma physique suivant :

*VLAN11 : Gigabit 4/11
*VLAN12 : Gigabit 4/12
*VLAN13 : Gigabit 4/13
*VLAN14 : Gigabit 4/14
*VLAN15 : Gigabit 4/15
*VLAN16 : Gigabit 4/16
*VLAN17 : Gigabit 4/17
*VLAN18 : Gigabit 4/18
*VLAN19 : Gigabit 4/19
*VLAN20 : Gigabit 4/20
*VLAN 110 : Gigabit 5/1

===== Semaine 9 (26/11/2015) =====

Pour pouvoir ajouter la borne wifi au commutateur, on rajoute le vlan 1 dans l'interface 4/10 :

interface GigabitEthernet4/10
switchport
switchport mode trunk
switchport trunk allowed vlan 1, 11-20,110,130
exit

En mode trunk pour que la borne ait accès à tous les vlan.
Le vlan est configuré de cette facon :
Internet address is 10.10.10.1/24
Broadcast address is 255.255.255.255

=== VM xen ===
====Création de la machine====

===== Semaine 3 (15/10/2015) =====
En parallèle, on crée notre machine virtuelle Xen sur Cordouan :
On achète un nom de domaine sur Gandi : '''zegbicho.lol'''

* On se connecte en ssh sur cordouan :

ssh root@cordouan.insecserv.deule.net

xen-create-image --hostname=KARMELIET --dist=jessie --dir=/usr/local/xen --gateway=193.48.57.174 --ip=193.48.57.164

* On regarde l'était d'avancement de la création et on récupère notre mot de passe root dans le fichier : KARMELIET.log

tail -f /var/log/xen-tools/KARMELIET.log

* On modifie le fichier de conf KARMELIET.cfg :
** bridge=IMA5sc
** on retire l'IP
** mémoire à 512M

===== Semaine 4 (22/10/2015) =====
*On lance la VM xen:
xl create /etc/xen/KARMELIET.cfg

*On se connecte sur la VM xen :
xl console KARMELIET

*Activation l'IPv4 packet forwarding en de-commentant la ligne appropriée dans le fichier /etc/sysctl.conf

*On vérifie le fichier /etc/network/interfaces

*Mises à jour :
apt-get update
apt-get upgrade

On ajoute le serveur apache, le serveur DNS et SSH:
apt-get install openssh
apt-get install bind9

On active la possibilité de se connecter en SSH en tant que root en modifiant le fichier de config /etc/ssh/sshd_config :
PermitRootLogin yes

==== Configuration du serveur apache et installation du certificat SSL ====
Pour activer le certificat SSL, nous devons à la fois manipuler sur notre machine Xen et sur le site gandi. Nous nous sommes d'ailleurs aidés des tutoriels gandi pour réaliser cette tâche. Nous certifions les domaines ''www.zegbicho.lol'' et ''zegbicho.lol''. Nous avons tout d'abord besoin de clés, on génère donc le premier fichier .csr à fournir à gandi avec la commande :

openssl req -nodes -newkey rsa:2048 -sha256 -keyout zegbicho.lol.key -out zegbicho.lol.csr

Cette commande nous a donc généré deux fichier : un fichier .key qui correspond à notre clé privée et un .csr ( clé publique) que nous devons fournir à gandi. Ce dernier nous retourne alors un .crt, nous supprimons aors la .crs dont nous n'avons plus besoin. Nous décidons de les ranger dans des dossier situés dans le dossier /etc/ssl/ de notre machine xen :
*Le fichier .crt dans /etc/ssl/certs/
*le fichier .key dans /etc/ssl/private/

Nous allons à présent suivre le tutoriel gandi : https://wiki.gandi.net/fr/hosting/using-linux/tutorials/ubuntu/ssl

On active le module ssl d'apache :
a2enmod ssl

Puis on fait en sorte qu'apache écoute sur le port 443, on édite donc le fichier de configuration /etc/apache2/ports.conf et on ajoute:
<IfModule mod_ssl.c>
Listen 443
NameVirtualHost 193.48.57.164:443
</IfModule>

Maintenant nous pouvons obtenir le certificat intermédiare de gandi.
Nous récupérons le fichier GandiStandardSSLCA2.pem qui nous plaçons dans le répertoire /etc/ssl/certs/
On effectue le rehash de la structure ssl:
c_rehash /etc/ssl/certs

Pour ajouter un domaine sur notre apache sécurisé, on crée le site dédié www.zegbicho.lol.
Enfin, on ajoute un VirtualHost servant le contenu du dossier /var/www/www.zegbicho.lol/ sur le port 443, dans /etc/apache2/sites-available/000-zegbicho.lol-ssl.conf :

NameVirtualHost *:443
<VirtualHost *:443>

ServerName www.zegbicho.lol
ServerAlias zegbicho.lol
DocumentRoot /var/www/www.zegbicho.lol/
CustomLog /var/log/apache2/secure_access.log combined

SSLEngine on
SSLCertificateFile /etc/ssl/certs/zegbicho.lol.crt
SSLCertificateKeyFile /etc/ssl/private/zegbicho.lol.key
SSLCertificateChainFile /etc/ssl/certs/GandiStandardSSLCA2.pem
SSLVerifyClient None

</VirtualHost>

Nous vérifions la chaine SSl crée avec la commande :
openssl s_client -connect 193.48.57.164:443
Notre chaine est validée, on passe donc à la configuration du serveur DNS

==== Serveur DNS et DNSSEC avec Bind ====

Nous nous aidons ici aussi des tutos gandi

Il s'agira tout d'abord de s'occuper du changement de DNS sur le site gandi.
Nous devons au prélable gérer les glue records : https://wiki.gandi.net/fr/domains/management/change-glue
On va alors créer un enregistrement Glue :
*Nom du serveur : ns.zegbicho.lol
*Adresse IP : 193.48.57.164

On peut alors modifier les serveurs de nom sur gandi.net : https://wiki.gandi.net/fr/dns/change
*DNS1 : ns.zegbicho.lol
*DNS2 : ns6.gandi.net
On utilise un serveur DNS secondaire appartenant à gandi.

On attends la propagation DNS et on s'attaque à la configuration de BIND : https://wiki.gandi.net/fr/hosting/using-linux/tutorials/ubuntu/bind

Toute cette configuration s'effectue dans le dossier /etc/bind/

On commence par créer un dossier zones dans lequel on créer un fichier de zone /etc/bind/zones/db.zegbicho.lol :
$TTL 604800

@ IN SOA ns.zegbicho.lol. root.zegbicho.lol. (
2015102001 ; Serial
86400 ; Refresh
3600 ; Retry
2419200 ; Expire
86400 ) ; Negative Cache TTL

$include /etc/bind/zegbicho.lol.dnssec/zegbicho.lol-ksk.key
$include /etc/bind/zegbicho.lol.dnssec/zegbicho.lol-zsk.key

@ IN NS ns.zegbicho.lol.
@ IN NS ns6.gandi.net.
ns IN A 193.48.57.164
www IN A 193.48.57.164
michel IN A 193.48.57.164
ns IN AAAA 2001:660:4401:60bb:216:3eff:fef6:5366
www IN AAAA 2001:660:4401:60bb:216:3eff:fef6:5366
michel IN AAAA 2001:660:4401:60bb:216:3eff:fef6:5366
@ IN A 193.48.57.164
@ IN AAAA 2001:660:4401:60bb:216:3eff:fef6:5366

Puis on créer le fichier définissant la zone inverse pour la résolution des adresses IP, 57.48.193.in-addr.arpa :

$TTL 604800

@ IN SOA ns.zegbicho.lol. root.zegbicho.lol. (
2015102001 ;serial
14400 ;refresh
3600 ;retry
604800 ;expire
10800 ;minimum
)

57.48.193.in-addr.arpa. IN NS ns.zegbicho.lol.
57.48.193.in-addr.arpa. IN NS ns6.gandi.net.

164 IN PTR zegbicho.lol.

On modifie ensuite le fichier de configuration /etc/bind/named.conf.local, dans lequel on ajoute les zones :

zone "zegbicho.lol" {
type master;
file "/etc/bind/zones/db.zegbicho.lol.signed";
allow-transfer { 217.70.177.40; };
notify yes;
};

zone "57.48.193.in-addr.arpa" IN {
type master;
file "/etc/bind/zones/57.48.193.in-addr.arpa";
allow-transfer { 217.70.177.40; };
};

On finit avec la sécurisation DNS avec DNSSEC: On remarque que le fichier référencé dans /etc/bind/named.conf.local est
/etc/bind/zones/db.zegbicho.lol.signed
Ce fichier est créé après la signature de la zone, mais nous devons tout d'abord réaliser quelques manipulations.

DNSSEC est un protocole de sécurisation du protocole DNS. Celui-ci a pour but de signer les informations publiées grâce à un jeu de clés chiffrées.
On crée donc 2 clés : une Key Signing Key (KSK) et une Zone Signing Key (ZSK). Pour accélérer la génération nous utilisons l'option -r /dev/urandom qui permet d'utiliser une génération pseudo-aléatoire au lieu d'une génération /dev/random par défaut.

Génération de la KSK :
dnssec-keygen -a RSASHA1 -b 2048 -r /dev/urandom -f KSK -n ZONE zegbicho.lol
Génération de la ZSK :
dnssec-keygen -a RSASHA1 -b 1024 -r /dev/urandom -n ZONE zegbicho.lol

On obtient donc 4 clés. En effet, à chaque génération de clé, on obtient une clé publique et une clé privée. Pour s'y retrouver, on renomme ces clés et on les place dans un dossier qu'on créer : /etc/bind/zegbicho.lol.dnssec
Ces clés (les deux clés publiques) sont référées dans le fichier de zone db.zegbicho.lol :
$include /etc/bind/zegbicho.lol.dnssec/zegbicho.lol-ksk.key
$include /etc/bind/zegbicho.lol.dnssec/zegbicho.lol-zsk.key

On va ensuite sur gandi.net dans la rubrique "gérer DNSSEC" et on leur fourni les deux clés publiques KSK et ZSK. Il peut alors les propager.

Finalement, on signe la zone avec la commande suivante :
dnssec-signzone -o zegbicho.lol -k zegbicho.lol.dnssec/zegbicho.lol-ksk zones/db.zegbicho.lol zegbicho.lol.dnssec/zegbicho.lol-zsk

Cette commande va créer le fichier /etc/bind/zones/db.zegbicho.lol.signed qu'on réfère dans le fichier de configuration /etc/bind/named.conf.local

On finit alors par créer et éditer le fichier de cofiguration des options : /etc/bind/named.conf.options :
options {
dnssec enable yes;
dnssec-validation yes;
dnssec-lookaside auto;
listen-on-v6 {any;};
};

==== Vérification de la fonctionnalité de notre site ====

On entre l'URL zegbicho.lol, qui est automatiquement redirigée vers https://zegbicho.lol
On remarque que le certificat est valide. 
La page est uniquement accessible en https car nous avons modifié le fichier de confguration etc/apache2/sites-available/000-default.conf:

<VirtualHost *:80>
.....
Redirect permanent / https://zegbicho.lol
....
</VirtualHost>

On test également notre configuration avec l'outil DNSSEC de l'outil https://www.zonemaster.fr/ et on remarque que le DNSSEC est validé/actif.

Le site web réalisé est donc sécurisé !

===Wifi===
====Tests d'intrusion par cassage de clé WEP====

Pour ce faire, on passe l'interface Wifi en mode monitor :
airmon-ng start wlan0

On affiche ensuite le trafic Wifi visible à l'aide de la commande :
airodump-ng mon0

Une fois notre point d'accès repéré, on procède à un échange de données avec le point d'accès qui nous intéresse (cracotte04) :
airodump-ng --essid cracotte04 --ch 7 --write out mon0

En parallèle de ce processus, on peut lancer le cassage de la clé WEP avec la commande :
aircrack-ng out-01.cap

Après quelques minutes d'attente (soit env. 66249 IVs), on obtient enfin notre clé :
KEY FOUND! [ 55:55:55:55:55:55:55:55:55:55:55:11:11 ]

====Wifi : Cassage de clé WPA-PSK par force brute====

Pour craquer ce type de clé, il faut trouver un moyen un peu plus complexe car aircrack n'est pas capable de trouver la clé par ses propres moyens. Il est nécessaire de lui fournir un dictionnaire contenant la clé de réseau pour espérer pouvoir s'y connecter. Nous avons donc commencé par générer un dictionnaire comprenant cent millions de clés (tous les nombres à 8 chiffres : 00000000 à 99999999). Nous avons pour cela créé un petit code C :

#include <stdio.h>
#include <stdlib.h>
int main(){
int i=0;
FILE* dico = fopen("dictionnaire.txt","w+");
for(i=0;i<=99999999;i++){
fprintf(dico, "%08d\n", i);
}
fclose(dico);
return 0;
}

On passe l'interface Wifi en mode monitor :
airmon-ng start wlan0

On affiche ensuite le trafic Wifi visible à l'aide de la commande :
airodump-ng mon0

Une fois notre point d'accès repéré, on procède à un échange de données avec le point d'accès qui nous intéresse (cracotte04) :
airodump-ng --essid cracotte04 --ch 12 --write crackage_wpa-psk.txt mon0

On peut ensuite lancer le cassage de la clé WPA-PSK en référant notre dictionnaire créé précédemment avec la commande :
aircrack-ng -w dictionnaire.txt crackage_wpa-psk.txt-02.cap

Le test des clés se fait à une vitesse moyenne de 3700 clés par seconde. 
Après quelques minutes d'attente , on obtient enfin notre clé :

[[Fichier:Craquage_WPA_PSK.png |thumb|center| 600px|<center>Craquage WPA-PSK</center>]]

===Sécurisation des données===

*On crée les trois partitions LVM de 1Go :

lvcreate -L 1G -n /dev/virtual/ima5-karmeliet-raid1 -v
lvcreate -L 1G -n /dev/virtual/ima5-karmeliet-raid2 -v
lvcreate -L 1G -n /dev/virtual/ima5-karmeliet-raid3 -v

*On ajoute les partitions dans le fichier de configuration :

disk = [
'file:/usr/local/xen/domains/levrette/disk.img,xvda2,w',
'file:/usr/local/xen/domains/levrette/swap.img,xvda1,w',
'phy:/dev/virtual/ima5-karmeliet-home,xvdc,w',
'phy:/dev/virtual/ima5-karmeliet-var,xvdb,w',
'phy:/dev/virtual/ima5-karmeliet-raid1,xvdd,w',
'phy:/dev/virtual/ima5-karmeliet-raid2,xvde,w',
'phy:/dev/virtual/ima5-karmeliet-raid3,xvdf,w',
]

*Puis, on crée le RAID5 logiciel à l'aide de la commande:

mdadm --create /dev/md0 --level=5 --assume-clean --raid-devices=3 /dev/xvdd /dev/xvde /dev/xvdf

*Pour vérifier que notre md0 a été correctement créé, on exécute la commande:
cat /proc/mdstat

On obtient :

Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdf[2] xvde[1] xvdd[0]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]

unused devices: <none>

*Et pour vérifier notre RAID5 logiciel avec les trois partitions :
mdadm --detail /dev/md/KARMELIET\:0
Ce qui donne :
Version : 1.2
Creation Time : Thu Nov 26 13:40:21 2015
Raid Level : raid5
Array Size : 2095104 (2046.34 MiB 2145.39 MB)
Used Dev Size : 1047552 (1023.17 MiB 1072.69 MB)
Raid Devices : 3
Total Devices : 3
Persistence : Superblock is persistent

Update Time : Thu Nov 26 13:49:20 2015
State : clean
Active Devices : 3
Working Devices : 3
Failed Devices : 0
Spare Devices : 0

Layout : left-symmetric
Chunk Size : 512K

Name : KARMELIET:0 (local to host KARMELIET)
UUID : 4bb46fbe:6292cc6b:5fdccfcc:a4a94ae3
Events : 2

Number Major Minor RaidDevice State
0 202 48 0 active sync /dev/xvdd
1 202 64 1 active sync /dev/xvde
2 202 80 2 active sync /dev/xvdf

Après avoir redémarré la VM, on remarque que le volume nouvellement créé nommé md0 a été remplacé par md127.

Après avoir supprimé une partition, on refait la commande :
mdadm --detail /dev/md127

Et on obtient :
Version : 1.2
Raid Level : raid0
Total Devices : 2
Persistence : Superblock is persistent

State : inactive

Name : KARMELIET:0 (local to host KARMELIET)
UUID : 4bb46fbe:6292cc6b:5fdccfcc:a4a94ae3
Events : 2

Number Major Minor RaidDevice

- 202 48 - /dev/xvdd
- 202 64 - /dev/xvde
On vérifie le volume md127 :
cat /proc/mdstat
On a :
Personalities :
md127 : inactive xvde[1](S) xvdd[0](S)
2095104 blocks super 1.2
unused devices: <none>

===Cryptage des données===

A l'aide de la commande suivante, on formate la carte SD de telle sorte qu'elle n'ait plus qu'une seule partition :
fdisk /dev/sdb

On crée maintenant la partition cryptée protégée par un mot de passe avec la commande :
cryptsetup luksFormat -c aes -h sha256 /dev/sdb1

Avec la commande suivante, on affiche l'état du disque crypté :
cryptsetup luksDump /dev/sdb1

On y ajoute ensuite un système de fichiers (ici au format ext3) :
cryptsetup luksOpen /dev/sdb1 karmeliet
mkfs.ext3 /dev/mapper/karmeliet

Pour monter la partition :
mount -t ext3 /dev/mapper/<nom_du_disque> /mnt/

On peut ainsi lire et écrire des fichiers sur la carte SD en travaillant dans le dossier /mnt/. Après avoir fini, on démonte la carte SD avec les commandes :
umount /mnt/
cryptsetup luksClose karmeliet

Lors de l'échange de cartes SD, en exécutant la commande d'ouverture du système de cryptage ('luksOpen'), un mot de passe est nécessaire pour le montage et l'utilisation de la carte. Le cryptage fonctionne !

===Authentification et serveur RADIUS===

====FreeRadius====

Nous commençons par la configuration d'un serveur FreeRadius sur notre VM pour sécuriser le WiFi par WPA2-EAP. On travaille dans le dossier :
apt-get install freeradius
cd /etc/freeradius
Il nous faut rajouter un nouvel utilisateur qui nous servira pour authentification sur le réseau WiFi. Pour cela, on rajoute une ligne dans le fichier users :
zegbicho Cleartext-password := "ima15"
On édite ensuite le fichier client.conf et on y ajoute :
client E304 {
ipaddr = 10.10.10.1
netmask = 32
secret = password
}
client E306 {
ipaddr = 10.10.10.2
netmask = 32
secret = password
}

client VLAN14 {
ipaddr = 172.20.14.0
netmask = 24
secret = password
}

On configure aussi le fichier eap.conf pour utiliser le PEAP-MSCHAPv2. On édite donc ce fichier et on change le type de méthode :
*default_eap_type = peap
*Dans peap : default_eap_type = mschapv2

eap {
default_eap_type = peap
peap {
default_eap_type = mschapv2
}
}

====Sécurisation WiFi WPA2-EAP====
=====Configuration de la borne=====

Une fois notre configuration sur la machine xen réalisée, on configure la borne WiFi. Le but est de faire en sorte que l'accès à la borne soit controlé par WPA2-EAP. On ajoute à la configuration du point d'accès Wifi un SSID protégé par la méthode WPA2-EAP. On se connecte en telnet à la borne WiFi en 10.10.10.1 avec les identifiants Cisco/Cisco :

apt-get install telnet
telnet 10.10.10.1

conf t

aaa new-model
aaa authentication login eap_karmeliet group radius_karmeliet
radius-server host 193.48.57.164 auth-port 1812 acct-port 1813 key password
aaa group server radius radius_karmeliet
server 193.48.57.164 auth-port 1812 acct-port 1813
!

exit

dot11 ssid SSID_KARMELIET
vlan 14
authentication open eap eap_karmeliet
authentication network-eap eap_karmeliet
authentication key-management wpa
mbssid guest-mode
!

exit

interface Dot11Radio0
encryption vlan 14 mode ciphers aes-ccm tkip
ssid SSID_KARMELIET

exit

interface Dot11Radio0.14
encapsulation dot1Q 14
no ip route-cache
bridge-group 14
bridge-group 14 subscriber-loop-control
bridge-group 14 spanning-disabled
bridge-group 14 block-unknown-source
no bridge-group 14 source-learning
no bridge-group 14 unicast-flooding

exit

interface GigabitEthernet0.14
encapsulation dot1Q 14
bridge-group 14

exit

On réitère l'opération sur la borne située en E306 à l'adresse 10.10.10.2

=====Test sur l'eepc=====
Configuration de l'eepc /etc/network/interfaces :
auto wlan0
iface wlan0 inet static
address 172.20.14.12
netmask 255.255.255.0
gateway 172.20.14.254
wpa-ssid SSID_KARMELIET
wpa-key-mgmt WPA-EAP
wpa-identity zegbicho
wpa-password ima15

On regarde sur notre VM si cela fonctionne : en mode debug sur le RADIUS :
service freeradius stop
/usr/sbin/freeradius -X

Validé !
===PCBX===
Après avoir installé 'asterisk' à l'aide de ''apt-get'', on configure le fichier ''/etc/asterisk/sip.conf'' en y ajoutant cela :
[general]
hasvoicemail = yes
hassip = yes
hasiax = yes
callwaiting = yes
threewaycalling = yes
callwaitingcallerid = yes
transfer = yes
canpark = yes
cancallforward = yes
callreturn = yes
callgroup = 1
pickupgroup = 1
nat = yes

[1001]
type=peer
host=dynamic
dtmfmode=rfc2833
disallow=all
allow=ulaw
fullname = zegboy
username = zegboy
secret = coucou1
context = work

[1002]
type=peer
host=dynamic
dtmfmode=rfc2833
disallow=all
allow=ulaw
fullname = tibeechaw
username = tibeechaw
secret = coucou2
context = work

Ensuite, on ajoute dans le fichier ''/etc/asterisk/extensions.conf'' :
[work]
exten => _1XXX,1,Dial(SIP/${EXTEN},20)
exten => _1XXX,2,Hangup()

Après avoir connecté nos téléphones (Android) au spot Wi-Fi SSID_KARMELIET, on utilise l'application CSipSimple et on y ajoute un compte sur chaque téléphone sur le modèle suivant (exemple pour l'utilisateur 1001) :
Nom du compte : zegboy
Utilisateur : 1001
Serveur : 172.20.14.6 //Adresse IP de l'EeePC sur lequel est installé Asterisk
Mot de passe : coucou1

Ainsi, on obtient un résultat correct puisqu'on a bien sur nos deux téléphones une communication par voie IP.

Station météo connectée

2016-01-06T09:58:14Z

Mzeggai : Page créée avec « ==Cahier des charges== ===Présentation générale du projet=== ====Contexte==== ====Objectif du projet==== ====Description du projet==== ====Choix techniques : matérie... »

==Cahier des charges==
===Présentation générale du projet===

====Contexte====

====Objectif du projet====

====Description du projet====

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

==Étapes du projet==

Partie 1 : 

Partie 2 : 

Partie 3 : 

==Suivi de l'avancement du Projet==

===Séance 1 ===
===Séance 2 ===
===Séance 3 ===
===Séance 4 ===
===Séance 5 ===

Option Internet des objets 2015/2016

2016-01-06T09:56:23Z

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

== Projets ==

Les différents projets proposés ont pour but de réaliser un objet connecté de A à Z. Les objets seront dans la mesure du possible interopérables, soit directement, soit par l'intermédiaire d'un "point d'accès". Différentes problématiques relatives à l'Internet des Objets sont listées ci-dessous. Chaque projet devra intégrer une réflexion sur - au minimum - deux points de cette liste ; tous les points devront être abordés au travers de l'ensemble des projets.

Problématiques (techniques) principales rencontrées dans l'Internet des Objets et les réseaux de capteurs :

* Gestion d'énergie (mode veille et réveil des objets),
* Routage orienté économie d'énergie,
* Lien entre les objets connectés et l'Internet,
* Apport de la localisation,
* Stockage des données et leur représentation,
* Sécurité,
* Mise à jour du code embarqué,
* Distribution du traitement de l'information (object, fog, cloud).

Quelques idées d'objets connectés pouvant être réalisés ; d'autres projets peuvent être proposés (cf. liste matériel disponible) :
* Timer Connecté pour gérer les temps de paroles lors des soutenances (projets, stage, ...)
* Compteur de tour de piste. Lors d'un entrainement sur une piste d'athlétisme il est parfois difficile de compter le nombre de tour de piste effectué tout en réalisant les entraînements. L'idée est donc d'avoir un artefact attaché à la main, muni de boutons poussoir et d'un afficheur. A chaque bouton poussoir est attaché une fonction logiciel (ajouter un tour, remettre à zero, ...)
* Lampe de chevet connectée
* Visualisation de la qualité de l'air avec des artefacts interactifs
* Lampes connectées permettant de réfleter l'état du public dans un amphi lors d'un cours ou d'une soutenance
* Tee shirt augmenté
* "Caillou" connecté
* Boules décoratives connectées : en fonction de la distance entre les différentes boules, leur couleur change
* Sac à dos pour cycliste avec indicateurs de direction
* Réseau de capteurs pour suivi de l'environnement des salles de projets
* Sous-bock connecté
* ...

== Répartition des binômes ==

Ecrivez vos noms sous le format exact "Prénom Nom", séparez vos noms par des virgules.

{| class="wikitable"
! Projet !! Elèves
|-
| [[Sous bock connecté]] || Benjamin LEFORT, Kevin COLAUTTI, Jean-Michel TOURNIER
|-
| [[Réseau de capteurs]] || Alexandre Jouy, Romain Libaert
|-
| [[Thermomètre connecté]] || Flavien Royer, Maxime Morisse
|-
| [[Réseau de lampes]] || Sandra HAGE, Julien HERIN
|-
| [[Brosse à dents intelligente]] || Elise TSSOT Celine TIRABY
|-
| [[Enceintes Bluetooth connectées]] || Mehdi BAKALI, Antonin BRONNER, Jérôme SONTAG
|-
| [[Compteur de tour de piste]] || Jérôme Bailet, Mageshwaran Sekar
|-
| [[Lampe connectée]] || Mourad EL GHISSASSI, Yacine RACHIDI, Rudy ZANOTTI
|-
| [[Station météo connectée]] || Thibaut SCHOLAERT, Mehdi ZEGGAÏ
|}

P33 Réalisations en faveur de l'accessibilité de jeux vidéos

2015-12-14T10:05:39Z

Mzeggai : /* Fichiers Rendus */

Fichier:PFE IMA5 Rapport intermediaire Bailet Zeggai.pdf

== Cahier des charges de la tâche particulière ==
=== Présentation de la tâche particulière ===
La tâche particulière que nous devons effectuer est de configurer le commutateur présent en salle E304 afin de pouvoir les mettre à jour de CatOS vers IOS, afin de pouvoir mettre en place les différents VLAN. Cette tâche particulière est effectuée avec le groupe n°4.

=== Matériel utilisé pour la tâche particulière ===
- Commutateur Cisco 6009

== Suivi de l'avancement du TP ==
=== Séance 1 (01/10/2015) ===

- Découverte des commutateurs Cisco 6009 présents en E304 et E306

- Echange d'un superviseur entre les deux commutateurs afin d'avoir sur chacun d'entre eux un superviseur sous IOS et un autre sous CatOS

- Un des superviseurs en E304 censé fonctionner sous CatOS ne démarre pas correctement

Pour la prochaine séance, l'objectif est de pouvoir résoudre ce dernier problème

TP sysres IMA5sc 2015/2016

2015-10-08T10:11:28Z

Mzeggai :

Merci de référencer votre cahier de travaux pratiques ici.

== Répartition des binômes ==

<table border="1">
<tr>
<th>Cahier</th>
<th>Elèves</th>
<th>Tâche particulière</th>
</tr>
<tr>
<td>[[G1 : Advanced_Networking_Protocol_Workshop | Cahier groupe n°1]]</td>
<td> Mageshwaran Sekar & Hidéo Vinot </td>
<td> Routage + Redondance niveau 3 </td>
</tr>
<tr>
<td>[[Cahier groupe n°2]]</td>
<td> Sandra Hage Chehadé & Elise Tissot </td>
<td> Routage </td>
</tr>
<tr>
<td>[[Cahier groupe n°4]]</td>
<td> Thibaut Schoalert & Mehdi Zeggaï </td>
<td> Configuration des commutateurs </td>
</tr>
<tr>
<td>[[Cahier groupe n°5]]</td>
<td> Jérémie Denéchaud & Gabriel Pagola Nielsen </td>
<td> Wifi - Filtrage par adresse mac </td>
</tr>
<tr>
<td>[[Cahier groupe n°6]]</td>
<td> Jérome Bailet & Matthieu Marcadet </td>
<td> Wifi - Filtrage par adresse mac </td>
</tr>
<tr>
<td>[[PRA 2015 - Câblage d'un réseau redondant|Cahier groupe n°7]]</td>
<td> Jean Wasilewski & Flavien Royer </td>
<td> Câblage d'un réseau redondant </td>
</tr>
<tr>
<td>[[Cahier groupe n°8]]</td>
<td> Cyril Smagghe & Jean-Michel Tournier </td>
<td> Bridge </td>
</tr>
<tr>
<td>[[Cahier groupe n°9]]</td>
<td> Kevin Colautti & Benjamin Lefort </td>
<td> DLNA </td>
</tr>
<tr>
<td>[[Cahier groupe n°10]]</td>
<td> Alexandre Jouy & Julien Hérin </td>
<td> Wifi crack </td>
</tr>
</table>

[[Fichier:résumé répartition.jpg]]

P33 Réalisations en faveur de l'accessibilité de jeux vidéos

2015-10-04T22:58:02Z

Mzeggai : /* Description du projet */

__TOC__
 
==Cahier des charges==
===Présentation générale du projet===

====Contexte====

====Objectif du projet====

Permettre à des personnes handicapées l'accès à des activités ludiques.

====Description du projet====

Afin de rendre accessible des activités ludiques deux approches sont possibles, une adaptation ou une création des périphériques de jeux (manettes, ...) ou une modification de système existants en les rendant plus interactifs. Les enfants et adultes en situation de polyhandicap sont dans l'incapacité physique de manipuler les télécommandes et joysticks prévus avec les consoles de jeux vidéos classiques (wii, nintendo,..). Le projet est de pouvoir leur rendre accessibles ces moyens de se divertir en trouvant des adaptations (type contacteur) correspondant à leurs capacités. Quelques pistes envisagées (non exclusives) : une commande simple BCI (Brain Computer Interface) compatible avec les logiciels existants fonctionnant en mode défilement, ou encore un contacteur au clignement intentionnel de paupière enregistré par webcam...
Ce projet sera effectué à destination des habitants de la maison d'accueil spécialisée de La Gerlotte de Marcq-en-Barœul. Cette résidence accueille des personnes adultes polyhandicapées dépendantes.

===Étapes du projet===
* Rencontre avec le personnel de la Gerlotte et établissement du cahier des charges et des attentes
* "Clôture" du cahier des charges et début de l'élaboration des adaptations convenues
* Tests des adaptations établies avec les résidents de la Gerlotte, et prise en compte des retours

==Avancement du Projet==

===Semaine 1 (du 28/09/2015 au 04/10/2015)===
Rendez-vous à la Gerlotte du mercredi 30/09/2015 :
* Rencontre avec l'animateur Xavier Hantson et visite de l'établissement la Gerlotte
* Rencontre avec les résidents, présentation des infrastructures en place (adaptations, appareillages), et aperçu des différents handicaps pris en charge
* Réunion avec le directeur David Desmulier, l'ergothérapeute Thierry Danigo et M. Hantson. Brainstorming sur les différents moyens pour l'accessibilité aux jeux vidéos : adaptation, modification de manettes, OneSwitch, support handsfree, reconnaissance oculaire (Eye Tracking Tobii avec le SDK, tools et hardware pour 99 euros), le choix de l'eye track inclurait la création d'un jeux vidéo adapté.
* Accord pour le prochain rendez-vous au 14/10/2015, où un premier choix d'adaptation devra être fait afin de commencer les premiers travaux

Après discussions avec M. Vantroys et M. Grisoni, la reconnaissance oculaire n'est pas un choix que nous conseillent nos professeurs et la création de jeux vidéos serait un travail beaucoup trop laborieux. À ce jour, nous restons dans l'idée de modification de manettes, périphériques pour pouvoir jouer à des jeux déjà existant. Nous poursuivons nos recherches pour approfondir le sujet ou pour trouver d'autres possibilités.

===Semaine 2 ===

===Semaine 3 ===

===Semaine 4 ===

===Semaine 5 ===

===Semaine 6 ===

===Semaine 7 ===

===Semaine 8 ===

===Semaine 9 ===

===Semaine 10 ===

===Semaine 11 ===

===Semaine 12 ===

===Semaine 13 ===

===Semaine 14 ===

===Semaine 15 ===

===Semaine 16 ===

===Semaine 17 ===

== Fichiers Rendus ==

P33 Réalisations en faveur de l'accessibilité de jeux vidéos

2015-10-04T22:55:18Z

Mzeggai : /* Semaine 1 */

__TOC__
 
==Cahier des charges==
===Présentation générale du projet===

====Contexte====

====Objectif du projet====

Permettre à des personnes handicapées l'accès à des activités ludiques.

====Description du projet====

Afin de rendre accessible des activités ludiques deux approches sont possibles, une adaptation ou une création des périphériques de jeux (manettes, ...) ou une modification de système existants en les rendant plus interactifs. Les enfants et adultes en situation de polyhandicap sont dans l'incapacité physique de manipuler les télécommandes et joysticks prévus avec les consoles de jeux vidéos classiques (wii, nintendo,..). Le projet est de pouvoir leur rendre accessibles ces moyens de se divertir en trouvant des adaptations (type contacteur) correspondant à leurs capacités. Quelques pistes envisagées (non exclusives) : une commande simple BCI (Brain Computer Interface) compatible avec les logiciels existants fonctionnant en mode défilement, ou encore un contacteur au clignement intentionnel de paupière enregistré par webcam...

===Étapes du projet===
* Rencontre avec le personnel de la Gerlotte et établissement du cahier des charges et des attentes
* "Clôture" du cahier des charges et début de l'élaboration des adaptations convenues
* Tests des adaptations établies avec les résidents de la Gerlotte, et prise en compte des retours

==Avancement du Projet==

===Semaine 1 (du 28/09/2015 au 04/10/2015)===
Rendez-vous à la Gerlotte du mercredi 30/09/2015 :
* Rencontre avec l'animateur Xavier Hantson et visite de l'établissement la Gerlotte
* Rencontre avec les résidents, présentation des infrastructures en place (adaptations, appareillages), et aperçu des différents handicaps pris en charge
* Réunion avec le directeur David Desmulier, l'ergothérapeute Thierry Danigo et M. Hantson. Brainstorming sur les différents moyens pour l'accessibilité aux jeux vidéos : adaptation, modification de manettes, OneSwitch, support handsfree, reconnaissance oculaire (Eye Tracking Tobii avec le SDK, tools et hardware pour 99 euros), le choix de l'eye track inclurait la création d'un jeux vidéo adapté.
* Accord pour le prochain rendez-vous au 14/10/2015, où un premier choix d'adaptation devra être fait afin de commencer les premiers travaux

Après discussions avec M. Vantroys et M. Grisoni, la reconnaissance oculaire n'est pas un choix que nous conseillent nos professeurs et la création de jeux vidéos serait un travail beaucoup trop laborieux. À ce jour, nous restons dans l'idée de modification de manettes, périphériques pour pouvoir jouer à des jeux déjà existant. Nous poursuivons nos recherches pour approfondir le sujet ou pour trouver d'autres possibilités.

===Semaine 2 ===

===Semaine 3 ===

===Semaine 4 ===

===Semaine 5 ===

===Semaine 6 ===

===Semaine 7 ===

===Semaine 8 ===

===Semaine 9 ===

===Semaine 10 ===

===Semaine 11 ===

===Semaine 12 ===

===Semaine 13 ===

===Semaine 14 ===

===Semaine 15 ===

===Semaine 16 ===

===Semaine 17 ===

== Fichiers Rendus ==

2015-05-03T19:08:43Z

Mzeggai :

= Cahier des charges =
== Présentation du projet ==
=== Contexte ===
Dans une époque où la technologie concerne le mode de vie de presque tout le monde, la plupart des gens ont tendance à se tourner vers les nouvelles technologies (smartphone, ordinateur) pour se divertir, et ainsi délaisser les anciens jeux de société. Afin de faire revivre ce genre de jeu, nous avons décidé de revisiter un pilier du jeu de société : le dé à jouer.

=== Objectif du Projet ===
L'objectif de ce projet est de réaliser un dé à jouer programmable du même type que les [http://www.futurocube.com/ futurocubes].

=== Idées de fonctionnalités ===
Voici quelques idées d'applications qu'on pourrait mettre en place :
* Dé à jouer classique : chiffre aléatoire de 1 à 6
* Jeu du morpion (Tic Tac Toe)
* SNAKE fonctionnant avec l'accéléromètre
* Eclairage "d'ambiance" avec variation aléatoire des couleurs
* Modélisation d'un Rubik's Cube 3x3
* Jeu de mémoire couleur/son (comme le jeu Simon)

=== Choix techniques : matériel - utilité ===
Nous allons nous baser sur :
* un microcontrôleur de type MBED (ARM Cortex M3) [fourni le 2/2/2015] : Cerveau du dé - Sons/bruitages

La documentation est disponible [http://developer.mbed.org/platforms/mbed-LPC1768/#schematics-and-data-sheets ici].
Les programmes implémentés seront codés en C/C++.

Ensuite, les composants suivants doivent être intégrés :
* LED RGB (54 LEDs) : Elles seront multiplexés à l'aide de transistors. [9 LED Rouges/Jaunes fournies le 4/2/2015] 54 x [http://fr.farnell.com/avago-technologies/asmb-mtb1-0a3a2/led-rgb-plcc4-surface-noire/dp/2401106 LED] [100 LEDs RGB commandées chez Farnell le 18/2/2015]

* 18 transistors NPN [3 fournis le 4/2/2015]

* 18 x [http://fr.farnell.com/on-semiconductor/bc548brl1g/transistor-npn-30v-100ma-to-92/dp/2317545 Transistor] [20 BC548BRL1G commandées chez Farnell fournies le 11/3/2015]
* 18 x [http://fr.farnell.com/diodes-inc/bc848b-7-f/transistor-npn-sot23/dp/1773620 Transistor CMS] [100 BC848B-7-F commandées chez Farnell le 18/2/2015]

* Résistances : à voir avec les encadrants et en fonction des tests (Savoir si on doit en placer une à l'anode ou une à chaque cathode)
* Accéléromètre : Orientation dans l'espace et réveil de l'appareil après la détection d'un mouvement. [ fourni le 11/2/2015]
* Alimentation : Rechargeable via usb.
* 6 faces "tactiles" via le centre de chaque face : Possible par résistances capacitives, touches tactiles (SparkFun Touch Shield), boutons poussoirs (Tests à réaliser pour déterminer la meilleure méthode).

== Étapes du projet ==
=== Étape 1 ===
* Choix des jeux et fonctionnalités à intégrer au dé en tenant compte des contraintes matérielles
* Aperçu du matériel disponible et nécessaire, puis choix des composants
* Élaboration du schéma électronique à adopter
* Découverte de la plateforme MBED

=== Étape 2 ===
Cette étape occupera la plus grande partie de la durée du projet.
* Réalisation du code des fonctionnalités à intégrer sur la plateforme MBED
* Réalisation des circuits électroniques nécessaires via Altium Designer
* Début du montage du cube

=== Étape 3 ===
* Montage final du cube
* Réalisation de programmes optionnels s'il reste du temps (fonctionnalités compliquées à implémenter ou pensées plus tard dans le projet)
* Tests des fonctionnalités sur le matériel

= Avancée du projet =
== Semaine 1 (du 26/01/2015 au 01/02/2015) ==
[[Fichier:Contrôle_DIODES.jpg|130px|thumb|Schéma multiplexage LED]]
Nous avons surtout porté nos recherches sur du matériel électronique spécifique, notamment pour l'aspect "tactile" de notre cube. En effet, il est possible d'utiliser les techniques suivantes :
* Résistance et capacité : On utilise une simple résistance et un métal conducteur. En touchant celui-ci avec notre doigt, on le transforme en capacité. On peut voir le principe [https://skyduino.wordpress.com/2012/06/02/arduino-faire-une-touche-tactile-avec-une-simple-resistance/ ici].
* Résistance capteur de pression : Prête à être utilisée mais assez chère. Il y a bien d'autres alternatives.
* [https://www.sparkfun.com/products/12013 Touch Shield] : A voir avec l'intégration des LED.
* Boutons réalisés sur le principe du [https://www.sparkfun.com/products/7835 Button Pad] à raison d'un par face : Dans le pire des cas ...

Puis nous nous sommes intéressés à la connexion des LEDs. Elles seront au nombre de 54, soit 9 par face, et en plus, ce sera des LED RGB.
Nous avons trouvé pour cela une solution de multiplexage à l'aide de transistors NPN.
Voici un petit schéma du branchement possible sur une face avec 9 LEDs RGB :
Il sera possible de le porter à plus grande échelle par la suite.

L'objectif pour la semaine prochaine sera de tester les solutions du "tactile" et le branchement des LEDs.

Nous avons également discuté avec nos encadrants sur le matériel et ses limites, c'est-à-dire le tactile, la connexion des LEDs, l’accéléromètre (disponible à Polytech), le MBED, les sons (réalisables avec le MBED) et le côté alimentation.

== Semaine 2 (du 02/02/2015 au 08/02/2015) ==
Lors de cette semaine, nous avons surtout porté nos recherches sur la méthode de multiplexage des LEDs. Faute d'avoir des LEDs RGB, nous avons testé le multiplexage selon le schéma précédent avec 3 LEDs simples, soit une LED RGB. Nous avons réalisé le test d'allumer 1 seule des LEDs (pour avoir une couleur) puis 2 (mélange de couleurs).

[[Fichier:Test3LED1.JPG|130px|thumb|left|Test 1 multiplexage d'une LED RGB (avec 3 LEDs)]]

[[Fichier:Test3LED2.JPG|130px|thumb|centre|Test 2 multiplexage d'une LED RGB (avec 3 LEDs)]]

Nous avons ensuite réalisé le branchement afin d'obtenir une ligne de LEDs RGB selon le schéma précédant, soient 3 fois 3 LEDs simples. On peut voir ci-dessous le branchement et le résultat du test :

[[Fichier:TestMUX1.JPG|130px|thumb|left|Branchement d'une ligne de 3 LEDs RGB (9 LEDs basiques)]]

[[Fichier:TestMUX2.PNG|130px|thumb|centre|Résultat du multiplexage d'une ligne de LEDs]]

L'objectif pour la semaine prochaine sera de tester le multiplexage des LEDs sur une face, et d'aborder le côté "tactile" du projet.

== Semaine 3 (du 09/02/2015 au 15/02/2015) ==

Suite aux résultats du multiplexage des LEDs, nous avons commencé la réalisation du codage de l'allumage de celles-ci selon le schéma complet suivant :

Parallèlement, nous avons porté nos recherches sur l'accéléromètre ADXL335. Nous avons effectué quelques tests pour déterminer le fonctionnement exact.
Nous avons récupéré les valeurs de celui-ci sur les broches analogiques du MBED et à l'aide de la fonction read() qui renvoie logiquement une valeur entre 0.0 et 1.0.
Nous avons codé le petit programme de test suivant pour tester selon l'axe Y:
[[Fichier:54MUX.JPG|160px|thumb|left|Schéma complet du multiplexage]]
''
DigitalOut myled1(LED1);
DigitalOut myled2(LED2);
DigitalOut myled3(LED3);
DigitalOut myled4(LED4);
DigitalOut verif (p5);
DigitalOut verif2 (p30);
AnalogIn x(p15); // 0.4<X<0.6
AnalogIn y(p16); // 0.4<Y<0.6
AnalogIn z(p17); // 0.4<Z<0.6
int main() {
while(1) {
wait(0.2);
float m1 = x.read();
float m2 = y.read();
float m3 = z.read();

if (m2>0.5) myled1=1; else myled1=0;
if (m2>0.52) myled2=1; else myled2=0;
if (m2>0.54) myled3=1; else myled3=0;
if (m2>0.56) myled4=1; else myled4=0;
if (m2>0.58) verif=1; else verif=0;
if (m2>0.6) verif2=1; else verif2=0;}}
''

On peut voir le résultat ici :

[[Fichier:Testaccel.avi]]

== Semaine 4 (du 16/02/2015 au 22/02/2015) ==
Durant cette semaine, nous avons observé le comportement de l'accéléromètre via l'utilitaire Minicom et la liaison série entre le microcontrôleur et le PC. Nous avons ainsi vérifié le fonctionnement de l'accéléromètre selon chaque axe, et ainsi confirmer les pistes observées la semaine dernière. Nous avons ainsi pu réfléchir à une solution tactile pour notre dé.

Après nos recherches sur internet, nous avons pu voir que peu de solutions sont disponibles pour notre MBED.

L'objectif pour la semaine prochaine sera ainsi d'approfondir nos recherches sur cette solution tactile.

== Semaine 5 (du 23/02/2015 au 01/03/2015) ==
Pendant cette semaine, nous avons poursuivi nos recherches sur la partie tactile de notre cube. Nous avons notamment réfléchi à 2 solutions :
* L'utilisation du [https://www.sparkfun.com/products/12013 SparkFun Touch Shield], que nous avons pu nous procurer. Néanmoins, ce pad est spécialement conçu pour être connecté sur Arduino Uno. Il n'est donc pas évident de l'adapter à notre MBED.
* La fabrication de touches tactiles "Do It Yourself" sur [https://skyduino.wordpress.com/2012/06/02/arduino-faire-une-touche-tactile-avec-une-simple-resistance/ ce modèle]. Néanmoins, le code de cette solution est fait pour fonctionner sous Arduino, il faudrait donc réfléchir à l'adapter à notre MBED.

C'est pourquoi nous avons décidé d'emprunter une carte Arduino Uno, afin de tester ces deux solutions, et envisager de les porter sur notre MBED.

L'objectif pour la prochaine séance sera de se décider sur la solution tactile de notre cube, ou sur une alternative à adopter.

== Semaine 6 (du 09/03/2015 au 15/03/2015) ==
Lors de cette sixième semaine, nous avons continué à travailler sur la solution tactile à adopter, et nous avons spécialement étudié la manipulation des ports du microprocesseur du MBED, afin de pouvoir étudier l'utilisation de touches tactiles "Do It Yourself". Après quelques essais infructueux, nous étions prêts à nous orienter vers une solution alternative. Nous avons aussi rendu la carte Arduino Uno qui nous avait été fournie.

Aussi, notre commande de transistors BC548 est arrivée cette semaine, nous avons pu nous les procurer, en vue de l'élaboration de nos PCB.

L'objectif pour la semaine prochaine sera de trouver la solution alternative à adopter pour l'interaction entre l'utilisateur et le dé.

== Semaine 7 (du 16/03/2015 au 22/03/2015) ==
Pendant cette semaine, une solution concernant l'interaction Utilisateur-Dé nous est arrivée : nous avons pu nous procurer un [https://learn.adafruit.com/adafruit-mpr121-12-key-capacitive-touch-sensor-breakout-tutorial/overview Adafruit MPR121 Breakout Board à 12 touches], et un autre à 8 touches. Pour sa simplicité de branchement, nous avons décidé d'utiliser celui à 12 touches. Il nous permettra de créer 6 touches tactiles, une pour chaque face. Nous connecterons cette board via les ports I²C du microcontrôleur.

De plus, M. Boé nous a suggéré d'utiliser un accéléromètre permettant d'influer sur la consommation énergétique du microprocesseur. Il nous a ainsi fourni l'accéléromètre ADXL345, pouvant communiquer avec le microprocesseur via deux protocoles : SPI ou I²C. Nous avons tout d'abord décidé d'utiliser le protocole I²C, mais le programme-test ne fonctionnait pas comme on le voulait. L'impression des valeurs de l'accéléromètre devait se faire via une liaison série vers le PC, mais rien ne se passait à l'écran.

L'objectif pour la semaine prochaine sera de terminer la configuration de l'accéléromètre, et de configurer la board tactile.

== Semaine 8 (du 23/03/2015 au 29/03/2015) ==
Nous avons continué la configuration de l'accéléromètre, en utilisant des bibliothèques obtenues sur le site de développement MBED. N'ayant pas réussi à résoudre le problème de la communication I²C, nous avons décidé d'utiliser les ports SPI pour obtenir les valeurs, avec une bibliothèque paramétrant l'utilisation des ports SPI pour l'accéléromètre. Le code suivant nous a permis d'afficher les valeurs reçues sur les ports SPI via la liaison série :

''
#include "ADXL345.h"
ADXL345 accelerometer(p5, p6, p7, p8);
Serial pc(USBTX, USBRX);
int main() {
int readings[3] = {0, 0, 0};
pc.printf("Starting ADXL345 test...\n");
pc.printf("Device ID is: 0x%02x\n", accelerometer.getDevId());
//Go into standby mode to configure the device.
accelerometer.setPowerControl(0x00);
//Full resolution, +/-16g, 4mg/LSB.
accelerometer.setDataFormatControl(0x0B);
//3.2kHz data rate.
accelerometer.setDataRate(ADXL345_3200HZ);
//Measurement mode.
accelerometer.setPowerControl(0x08);
while (1) {
wait(0.1);
accelerometer.getOutput(readings);
//13-bit, sign extended values.
pc.printf("%i, %i, %i\n", (int16_t)readings[0], (int16_t)readings[1], (int16_t)readings[2]);
}
}
''

Nous avons aussi configuré la board tactile. Elle communique avec le microcontrôleur par les ports I²C. Avec une bibliothèque obtenue sur le site de développement MBED, nous avons réalisé un programme-test qui permet d'allumer les LEDs du microcontrôleur en fonction des touches actives ou non. Voici l'algorithme général de ce programme, exécuté en boucle :

''
//led1, led2, led3 et led4 initialement à 0
Si (touche1 == 1) alors led4=1;
Si (touche2 == 1) alors led3=1;
Si (touche3 == 1) alors {led3=1; led4=1;}
Si (touche4 == 1) alors led2=1;
Si (touche5 == 1) alors {led2=1; led4=1;}
Si (touche6 == 1) alors {led2=1; led3=1;}
Si (touche7 == 1) alors {led2=1; led3=1; led4=1;}
Si (touche8 == 1) alors led1=1;
Si (touche9 == 1) alors {led1=1; led4=1;}
Si (touche10 == 1) alors {led1=1; led3=1;}
Si (touche11 == 1) alors {led1=1; led3=1; led4=1;}
Si (touche12 == 1) alors {led1=1; led2=1;}
''

L'objectif pour la semaine prochaine sera de commencer l'élaboration des cartes PCB, et de paramétrer l'utilisation d'un élément piézoélectrique pour l'émission de sons.

== Semaine 9 (du 30/03/2015 au 05/04/2015) ==
Lors de cette semaine, nous avons commencé à créer une carte PCB avec le logiciel Altium Designer. Nous avons tout d'abord créé la carte permettant le multiplexage des LEDs. Nous avons placé sur cette carte 18 transistors BC548, 18 résistances, ainsi qu'un décodeur 3 vers 8 74LS138, permettant d'avoir une sortie à l'état bas et les 7 autres à l'état haut, selon [http://ecee.colorado.edu/~mcclurel/sn74ls138rev5.pdf cette datasheet]. Les pistes se feront des 2 côtés de la carte. A l'issue de cette semaine, nous avons pu envoyer notre modèle au service électronique pour élaboration.

/* Images (Altium) à venir */

Parallèlement, nous avons travaillé sur l'émission d'une gamme de sons par une pièce piézoélectrique. Sur le site de développement MBED, nous avons pu trouver une bibliothèque permettant l'élaboration d'une note et de sa durée, et par extension l'élaboration d'une mélodie.

''
#include "mbed.h"
#include <Sound.h>
Sound sound(p21, p10);
const Sound::sound_t WESTMINSTER[] = {
// hanon siji 0:b(flat) 1:tujo 2:#(sharp)
// | C1 - B9 kan deno onkai(Gx ha 9x ni okikae te siji) 0xFF=end data
// | | time (1/1[ms]/count)
// | | | envelope(yoin) (1/1 [ms]/count)
// | | | |
{1,0xC5,300,500},
{1,0xD5,300,500},
{1,0xE5,300,500},
{1,0xF5,300,500},
{1,0x85,300,500},
{1,0x95,300,500},
{1,0xA5,300,500},
{1,0xB5,300,500},
{1,0x75,300,500},
{1,0x65,300,500},
{1,0x55,300,500},
{1,0xFF,1000,0}, // end
};
int main() {
//---------------------
// enso data no settei
//---------------------
// sound.sound_enso("/local/enso.txt"); // mbed local file data "enso.txt" load (sita ni data no rei wo oite oku)
sound.sound_enso((Sound::sound_t*)WESTMINSTER);
//---------------------------------------------------
// output tone
//---------------------------------------------------
// tone1
Sound::sound_t oto = {1,0x95,200,100};
sound.sound_sound(oto);
while(sound.sound_sound() == true){}
// tone2
oto.hanon = 1; oto.onkai = 0xA5; oto.time = 2000; oto.envelope = 1000;
sound.sound_sound(oto);
while(sound.sound_sound() == true){}
//---------------
// output melody
//--------------
sound.sound_enso(true);
while(1) {
}
}
''

Nous travaillerons ultérieurement sur la sélection de notes à adopter.

L'objectif pour la semaine prochaine sera de continuer l'élaboration des cartes électroniques, ainsi de commencer le développement des programmes finaux.

== Semaine 10 (du 06/04/2015 au 12/04/2015) ==
Lors de cette semaine, nous avons continué l'élaboration des circuits électroniques. Nous avons commencé à concevoir les faces, soit les cartes contenant 9 LEDs RGB. Nous avons eu des LEDs CMS, nous avons donc dû créer ces composants sur Altium Designer.

Parallèlement nous avons commencé à travailler sur les programmes finaux. Nous avons développé un programme permettant d'allumer une LED une par une, selon la couleur voulue, et selon le schéma suivant :

/* Image à venir */

''
#include "mbed.h"
#include "Random.h"
BusOut myled(LED4,LED3,LED2,LED1);
DigitalOut anode[9]={p12,p13,p14,p15,p16,p17,p18,p19,p20};
BusOut base_couleur(p30,p29,p28);
BusOut collecteur(p24,p23,p22);
void allume_LED(int led, int face, char couleur){
for (int i=0;i<9;i++) anode[i]=0;
// sélection anode ("face")
if ((led == 1)||(led == 4)||(led == 7)){
if ((face == 1) || (face == 2)) anode[0]=1;
else if ((face == 3) || (face == 4)) anode[3] = 1;
else if ((face == 5) || (face == 6)) anode[6] = 1;
}
else if ((led == 2)||(led == 5)||(led == 8)){
if ((face == 1) || (face == 2)) anode[1] = 1;
else if ((face == 3) || (face == 4)) anode[4] = 1;
else if ((face == 5) || (face == 6)) anode[7] = 1;
}
else if ((led == 3)||(led == 6)||(led == 9)){
if ((face == 1) || (face == 2)) anode[2] = 1;
else if ((face == 3) || (face == 4)) anode[5] = 1;
else if ((face == 5) || (face == 6)) anode[8] = 1;
}
// sélection collecteur ("ligne" de LEDs)
if ((face == 1)||(face == 3)||(face == 5)){
if ((led > 0) && (led < 4)) collecteur.write(0);
else if ((led > 3) && (led < 7)) collecteur.write(1);
else if ((led > 6) && (led < 10)) collecteur.write(2);
}
else if ((face == 2)||(face == 4)||(face == 6)){
if ((led > 0) && (led < 4)) collecteur.write(3);
else if ((led > 3) && (led < 7)) collecteur.write(4);
else if ((led > 6) && (led < 10)) collecteur.write(5);
}
//sélection couleur (base)
if (couleur == 'r') base_couleur.write(4);
else if (couleur == 'g') base_couleur.write(2);
else if (couleur == 'b') base_couleur.write(1);
}
''

A partir de ce programme, nous avons conçu une fonction affichant sur une face un chiffre selon le principe d'un dé. Chaque LED sera allumée une par une, mais avec la fréquence de travail très élevée du microprocesseur (environ 100 MHz), notre œil aura l'impression qu'elles sont allumées en même temps. La fonction prend comme paramètre le chiffre affiché, ainsi que le temps d'affichage en secondes :

''
void affiche_de(int chiffre, float time){
Timer t;
t.start();
while (t.read() <= time){
if (chiffre == 1) allume_LED(5,1,'r');
else if (chiffre == 2) {
allume_LED(1,1,'r');
allume_LED(9,1,'r');
}
else if (chiffre == 3) {
allume_LED(1,1,'b');
allume_LED(5,1,'b');
allume_LED(9,1,'b');
}
else if (chiffre == 4) {
allume_LED(1,1,'b');
allume_LED(3,1,'b');
allume_LED(7,1,'b');
allume_LED(9,1,'b');
}
else if (chiffre == 5) {
allume_LED(1,1,'g');
allume_LED(3,1,'g');
allume_LED(5,1,'g');
allume_LED(7,1,'g');
allume_LED(9,1,'g');
}
else if (chiffre == 6) {
allume_LED(1,1,'g');
allume_LED(3,1,'g');
allume_LED(4,1,'g');
allume_LED(6,1,'g');
allume_LED(7,1,'g');
allume_LED(9,1,'g');
}
}
t.stop();
}
''

Nous avons aussi paramétré un générateur d'entiers aléatoires compris entre 1 et 6. A partir d'une bibliothèque obtenue sur le site de développement MBED, nous utilisons une classe "Random" permettant de générer ce chiffre. Ici, un exemple d'affichage d'un chiffre aléatoire :

''
int main() {
Random r;
int i;
r.init();
//génération d'un entier aléatoire entre 1 et 6
uint8_t chiffre = r.getByte();
chiffre = (chiffre % 6)+1;
//petite simulation
for(i=1;i<10;i++) {
if (i<4) allume_LED(i,1,'r');
else if ((i>3) && (i<7)) allume_LED(i,1,'b');
else if (i>6) allume_LED(i,1,'g');
wait_ms(200);
}
//affichage du chiffre aléatoire
if ((chiffre > 0) && (chiffre < 7)) affiche_de(chiffre,15);
}
''

Enfin, nous avons pu récupérer la carte électronique de multiplexage élaborée précédemment. Sur cette carte, les pistes ont été dessinées des deux côtés. Nous avons aussi obtenu un boitier de piles fonctionnant via USB que nous utiliserons comme batterie, ainsi qu'une breadboard de petite taille permettant de fixer le microcontrôleur, l'accéléromètre et la board tactile dessus.

[[Fichier:MUXcotecompo_recto.jpg|200px|thumb|left|Carte électronique du multiplexage des LEDs, côté composants (recto)]]
[[Fichier:MUX_verso.jpg|200px|thumb|centre|Carte électronique du multiplexage des LEDs (verso)]]

L'objectif pour la semaine prochaine sera de continuer, voire de terminer l'élaboration des circuits électroniques des faces, de travailler sur la carte de multiplexage, ainsi que de continuer le développement des programmes finaux.

== Semaine 11 (du 13/04/2015 au 19/04/2015) ==
Lors de cette semaine, nous avons pu avoir une discussion avec M. Boé, afin de faire le point sur notre projet. Il nous a ainsi suggéré de revoir la taille de notre cube, afin de diminuer la taille des faces. La carte de multiplexage réalisée étant trop grande, nous avons décidé d'envisager une nouvelle carte de multiplexage plus petite, pour ainsi obtenir des faces de dimension 6x6 cm environ. Nous avons aussi décidé de créer un PCB spécialement pour des piles de type CR2032, et qu'un autre pour le MBED, l'accéléromètre et la board tactile, et ainsi abandonner l'idée de la breadboard. Nous avons ainsi revu l'élaboration de la face comportant nos LEDs RGB CMS.

Côté informatique, nous avons avancé dans notre code en créant une fonction réalisant une petite animation des LEDs, pour l'instant sur une seule face :

''
//une animation "d'ambiance", pour l'instant sur une seule face
void animations(float duree_anim){
char couleurs[7] = {'w','j','r','p','b','g','t'};
int coul_suiv,led_suiv,j;
Timer t;
//toutes les LEDs de la même couleur
for(j=0;j<7;j++){
t.start();
while (t.read() <= (duree_anim/7)){
for(int i=1;i<10;i++) allume_LED(i,1,couleurs[j]);
}
t.stop();
t.reset();
//changement de couleur progressif, une LED à la fois
if (j==6) coul_suiv=0;
else coul_suiv=j+1;
led_suiv=1;
t.start();
while (led_suiv < 10){
while (t.read() <= (1.5/9)){
for(int k=1;k<=led_suiv;k++) allume_LED(k,1,couleurs[coul_suiv]);
for(int i=led_suiv+1;i<10;i++) allume_LED(i,1,couleurs[j]);
}
led_suiv++;
}
t.stop();
t.reset();
}
anim=true;
}
''

L'objectif pour la prochaine séance sera de créer une fonction de morpion, ainsi que de tester la carte de multiplexage sur une face.

== Semaine 12 (du 20/04/2015 au 26/04/2015) ==
Durant cette semaine, nous avons continué notre code en commençant la programmation d'une fonction "morpion". Cette fonction est assez longue à concevoir, et sera complétée d'une autre fonction vérifiant la victoire au morpion. Voici la fonction "morpion" (la fonction "win" sera élaborée plus tard) :

''
void morpion(){
led_eteinte();
int grille[9]={0,0,0,0,0,0,0,0,0};
int tour=0;
char coul;
bool ligne1=false, ligne2=false, ligne3=false, c1=false, c2=false, c3=false, d1=false, d2=false, gagne=false;
//déroulement de la partie
while ((!gagne)||(tour<9)){
tour++;
//"sélection" joueur : rouge pour joueur 1, vert pour joueur 2
if ((tour%2)==1) coul='r';
else coul='g';
//sélection case via touches
//milieu
if (touche2==1) {
if (grille[4]==0){
allume_LED(5,2,coul);
grille[4]=abs((tour%2)-2); //1 pour joueur 2, 2 pour joueur 1
}
}
else if (touche1==1) {
wait(1);
//haut gauche
if (touche5==1) {
if (grille[0]==0){
allume_LED(1,2,coul);
grille[0]=abs((tour%2)-2);
}
}
//bas gauche
else if (touche6==1){
if (grille[6]==0){
allume_LED(7,2,coul);
grille[6]=abs((tour%2)-2);
}
}
//gauche
else {
if (grille[3]==0){
allume_LED(4,2,coul);
grille[3]=abs((tour%2)-2);
}
}
}
else if (touche5==1) {
wait(1);
//haut gauche
if (touche1==1) {
if (grille[0]==0){
allume_LED(1,2,coul);
grille[0]=abs((tour%2)-2);
}
}
//haut droite
else if (touche3==1){
if (grille[2]==0){
allume_LED(3,2,coul);
grille[2]=abs((tour%2)-2);
}
}
//haut
else {
if (grille[1]==0){
allume_LED(2,2,coul);
grille[1]=abs((tour%2)-2);
}
}
}
else if (touche3==1) {
wait(1);
//bas droite
if (touche6==1) {
if (grille[8]==0){
allume_LED(9,2,coul);
grille[8]=abs((tour%2)-2);
}
}
//haut droite
else if (touche5==1) {
if (grille[2]==0){
allume_LED(3,2,coul);
grille[2]=abs((tour%2)-2);
}
}
//droite
else {
if (grille[5]==0){
allume_LED(6,2,coul);
grille[5]=abs((tour%2)-2);
}
}
}
else if (touche6==1) {
wait(1);
//bas gauche
if (touche1==1) {
if (grille[6]==0){
allume_LED(7,2,coul);
grille[6]=abs((tour%2)-2);
}
}
//bas droite
else if (touche3==1){
if (grille[8]==0){
allume_LED(9,2,coul);
grille[8]=abs((tour%2)-2);
}
}
//bas
else {
if (grille[7]==0){
allume_LED(8,2,coul);
grille[7]=abs((tour%2)-2);
}
}
}
//allumage du reste de la grille
for(int k=0;k<9;k++){
if (grille[k]==1) allume_LED(k+1,2,'r');
else if (grille[k]==2) allume_LED(k+1,2,'g');
}
//vérif ligne complétée
gagne=win(grille,ligne1,ligne2,ligne3,c1,c2,c3,d1,d2);
}
Timer t;
//vérif victoire joueur 1
if(((tour%2)==1)&&(gagne)){
t.start();
while(t.read()<=5){
for(int i=0;i<9;i++){
allume_LED(i,2,'r');
}
}
t.stop();
}
//vérif victoire joueur 2
else if (((tour%2)==0)&&(gagne)){
t.start();
while(t.read()<=5){
for(int i=0;i<9;i++){
allume_LED(i,2,'g');
}
}
t.stop();
}
//vérif match nul
else if ((tour==9)&&(!gagne)){
t.start();
while(t.read()<=5){
for(int i=0;i<9;i++){
allume_LED(i,2,'b');
}
}
t.stop();
}
morp=true;
}
''

A noter qu'ici, nous avons modélisé notre grille à l'aide d'un tableau à une dimension. Nous aurions très bien pu le faire aussi sous la forme d'une matrice à deux dimensions.

Côté électronique, nous avons récupéré le PCB d'une face. Nous avons alors procédé au soudage des 9 LEDs CMS composant notre face, et nous avons procédé aux tests d'allumage et de multiplexage. Les LEDs s'allument comme nous le désirons.

/* Image à venir*/

L'objectif pour les 2 semaines restantes sera de pouvoir présenter au moins un prototype de notre cube montrant son fonctionnement global.

== Semaine 13 (du 27/04/2015 au 03/05/2015) ==
Côté informatique, nous avons continué notre code en intégrant à notre programme final les différentes bibliothèques nécessaires : l'accéléromètre (ADXL345.h), la board tactile (MPR121.h), ainsi que pour le son de notre pièce piézoélectrique (Sound.h). Pour l'émission de ce son, nous avons repris la fonction d'émission d'une mélodie détaillée plus haut, et nous l'avons adaptée pour n'émettre qu'une seule note. Nous avons aussi créé la fonction de vérification de victoire au morpion :

''
//vérification victoire
bool win(int grille[],bool ligne1, bool ligne2, bool ligne3, bool c1, bool c2, bool c3, bool d1, bool d2){
bool v1=false, v2=false;
//verif lignes
if (!((grille[0]==0)&&(grille[1]==0)&&(grille[2]==0))){
v1=grille[0]==grille[1];
v2=grille[1]==grille[2];
ligne1=v1&&v2;
}
if (!((grille[3]==0)&&(grille[4]==0)&&(grille[5]==0))){
v1=grille[3]==grille[4];
v2=grille[4]==grille[5];
ligne2=v1&&v2;
}
if (!((grille[6]==0)&&(grille[7]==0)&&(grille[8]==0))){
v1=grille[6]==grille[7];
v2=grille[7]==grille[8];
ligne3=v1&&v2;
}
//verif colonnes
if (!((grille[0]==0)&&(grille[3]==0)&&(grille[6]==0))){
v1=grille[0]==grille[3];
v2=grille[3]==grille[6];
c1=v1&&v2;
}
if (!((grille[1]==0)&&(grille[4]==0)&&(grille[7]==0))){
v1=grille[1]==grille[4];
v2=grille[4]==grille[7];
c2=v1&&v2;
}
if (!((grille[2]==0)&&(grille[5]==0)&&(grille[8]==0))){
v1=grille[2]==grille[5];
v2=grille[5]==grille[8];
c3=v1&&v2;
}
//verif diagonales
if (!((grille[0]==0)&&(grille[4]==0)&&(grille[8]==0))){
v1=grille[0]==grille[4];
v2=grille[4]==grille[8];
d1=v1&&v2;
}
if (!((grille[2]==0)&&(grille[4]==0)&&(grille[6]==0))){
v1=grille[2]==grille[4];
v2=grille[4]==grille[6];
d2=v1&&v2;
}
bool win=ligne1||ligne2;
win=win||ligne3;
win=win||c1;
win=win||c2;
win=win||c3;
win=win||d1;
win=win||d2;
return win;
}
''

Côté électronique, nous avons en notre possession les PCB des 6 faces du cube.

= Fichiers Rendus =

Fichier:MUXcotecompo recto.jpg

2015-05-03T18:56:03Z

Mzeggai : PCB multiplexage côté composants (sans les composants, recto)

PCB multiplexage côté composants (sans les composants, recto)