Difference between revisions of "Projets:Perso:2011:InterfaceJeu"

From Electrolab
Jump to: navigation, search
(→‎Etat d'avancement: actualisation des réalisations récentes + objectifs à court/moyen terme)
(rework important pour actualiser)
Line 3: Line 3:
 
|author= Clément
 
|author= Clément
 
|proposal_date= 25/03/2011
 
|proposal_date= 25/03/2011
−
|abstract1=Ayant bien aimé un petit jeu con, je me suis dit que ce serait nettement mieux avec une interface hw adaptée
+
|abstract1=Abstract à peaufiner pour donner un réel apercu de tous les aspects de ce projet...
−
|abstract2=De là découle l'idée suivante: faire une interface hw à base d'arduino, pour:
+
|abstract2=... qui devient de plus en plus touffu !
−
|abstract3=- que ce soit facilement reproductible, pas trop cher, ...
+
−
|abstract4=- encourager des nouveaux venus à l'électronique à prendre en main cette plateforme
+
−
|abstract5=- faire en sorte que ces utilisateurs puissent par la suite aborder d'autres projets
+
 
|tags=PPC
 
|tags=PPC
 
|where=Anywhere
 
|where=Anywhere
Line 16: Line 13:
 
|estimated_time= few nights of work for the first prototype
 
|estimated_time= few nights of work for the first prototype
 
}}
 
}}
 +
 +
=Etat d'avancement/Historique/News=
 +
* fin 2011: "fin" du projet/atteinte d'un certain niveau de maturité permettant de passer à autre chose/refaire un point sur les objectifs&attendus.
 +
* mois à suivre: (OBJECTIFS)
 +
- mettre en place workshop d'application à l'Electrolab
 +
- développement des fiches d'activité/de support
 +
- développement du jeu d'origine (faisant appel à plus d'éléments que le bras & etch a sketch)
 +
* 1re quinzaine septembre: (OBJECTIFS)
 +
- finaliser les docs de présentation/support pour l'owf: photos, dossier de présentation
 +
- clean-up du code arduino/java + publication pour la version etch a sketch
 +
- fabrication du premier proto pour etch a sketch (à terme, plusieurs exemplaires, pour diffusion de beta lors de/suite à l'owf)
 +
- derniers cadrages pour rework v1=>v2 (ou simplement v1.2) du bras robotique. En particulier, interfacage squeakbot, pour présenter une alternative et montrer la généricité du concept fuku
 +
* fin aout 2011:
 +
- soucis pratique avec la machine de découpe laser: fabrication v0.2 en découpe laser en suspens jusqu'à nouvel ordre
 +
- prototypage d'un spin-off 'etch a sketch': Proof of Concept java/arduino opérationnelle (publication du code à venir, après clean up)
 +
- négociations pour la v2 du spin-off 'bras robotique' faite pour planète science. WE de travail pour passer de v1 (présentée à la Japan Expo) en v2 présentable à l'OWF planifié pour le Groweek (week end de travaux du secteur robotique de planète sciences, ouvert à tous), les 17/18 septembre
 +
* début aout 2011: acceptation présentation OWF ; préparation v0.2 pour cette occasion
 +
* juillet 2011: "livraison" de la v0.1 à un utilisateur pour beta testing ; prise de rendez-vous pour l'OWF fin septembre 2011
 +
* juin 2011: réalisation d'un fork pour l'animation bras robotique de planète science ; réalisation d'une interface en acrylique
 +
* 010 mai 2011: cablage du proto 0.1 & test rapide soft
 +
* 05 mai 2011: session travail sur proto 0: découpe du mdf
 +
* 03 mai 2011: commande de potards (http://fr.mouser.com/ProductDetail/BI-Technologies/P160KN-0QD15B10K/?qs=sGAEpiMZZMtxdMMi52izyq2vfP2RDTRmHzs3%252bIJ%252bhKI%3d
 +
* courant avril 2011: achat de panneau plastique, prototypage soft (cf )[http://wiki.electrolab.fr/Projets:Perso:2011:OpenShima projet Open Shima]
 +
* 07 avril 2011: soirée proto version 0
 +
* 31 mars 2011: soirée b(ière)rainstorming sur le projet
 +
* Mars 2011: début du projet
  
  
 
=Introduction=
 
=Introduction=
 
Donne un appercu des tenants et aboutissants du projet.
 
Donne un appercu des tenants et aboutissants du projet.
 +
 +
==Motivation & Contexte==
 +
Ayant bien aimé un petit jeu con (voir le lien plus bas), je me suis dit que ce serait nettement mieux d'y jouer avec une interface adaptée (un joystick fait sur mesure). Ayant la chance d'avoir toutes les compétences requises pour en faire un, j'ai creusé un peu la question, et je me suis rendu compte:
 +
- que ca pouvait être super fun, à faire et à utiliser, sans être compliqué (pour quelqu'un du métier)
 +
- que ca rejoignait une cause nettement plus "importante", qui personnellement me motive: diffuser et démocratiser certains trucs technologiques.
 +
- que pas mal de gens d'horizons divers accrochaient immédiatement à l'idée
 +
De là est venue une réflexion où la réalisation de ladite interface n'est plus qu'un prétexte pour développer un ensemble de ressources pédagogiques. L'objectif central est donc devenu de constituer un ensemble de ressources fondamentales pour que les utilisateurs s'approprient les savoirs et savoirs faire nécessaires pour réaliser ce "petit projet con", pas si con que ca au final, mais suffisamment léger pour en être intéressant et motivant.
 +
 +
En pratique, j'envisage ce projet comme un démonstrateur, un support pour diffuser (notamment par le biais d'ateliers réguliers au lab et ailleurs) les rudiments de l'électronique & informatique (embarquée), à la fois indispensable pour réaliser bon nombre de projets, et ouvrant un nombre incalculable de possibilités.
 +
Accessoirement, le lab ayant besoin à la fois de nouveaux membres porteurs de projets (qu'ils possèdent initialement les compétences requises... ou pas), et d'entrées d'argent pour financer ses activités, l'idée de préparer des kits ayant un réel intérêt pour les débutants a fait son chemin. Parce que faire clignoter 3 leds, assembler un robot inutile, c'est bien, mais on peut faire plus diversifié et durable.
 +
 +
 
==Objectifs==
 
==Objectifs==
 
Rendre fun un plus ou moins serious game grace à une interface hw, servant de prétexte à:
 
Rendre fun un plus ou moins serious game grace à une interface hw, servant de prétexte à:
−
* une introduction à l'électronique (par le biais d'arduino, de l'interface hw)
+
* une introduction à l'électronique, par l'intermédiaire des capteurs/actionneurs requis par le jeu (et sélectionnés intelligemment)
−
* un support plus ou moins pédagogique sur certains systèmes & mécanismes d'interface (selon le game design)
+
* une introduction à l'informatique embarquée, par l'utilisation d'un microcontroleur accessible facilement (arduino)
−
* Une initiation amusante à un procédé physique / chimique relativement complexe et pouvant être abordé simplement par le jeu
+
* une introduction à l'informatique pas embarquée, par le lien avec un ordinateur & le développement d'une petite application (le jeu à proprement parler)
−
* Eventuellement, servir de support pour des activités pédagogiques/tactical programming (cf JLM stuff)
+
* Eventuellement, en cerise sur le gateau, une initiation amusante à un procédé physique / chimique relativement complexe, abordé simplement/de manière ludique.
  
 
==Principes==
 
==Principes==
−
* Un jeu simple tourne sur un ordinateur personnel ; jeu réalisé... grace à un framework type FANG ? En langage XXX/YYY/ZZZ ?
+
* Un jeu simple tourne sur un ordinateur personnel ; le langage dudit jeu importe peu, mais les mécanismes doivent à terme en être compréhensibles.
−
* La majeure partie des fonctionnalités du jeu sont pilotées par une interface hw basée sur une Arduino, avec des capteurs/indicateurs divers et variés.
+
* La majeure partie des fonctionnalités du jeu sont pilotées par une interface hw basée sur une Arduino, avec des capteurs/actionneurs divers et variés (on construit un "joystick" sur mesure).
−
* Le lien entre le hw et le soft est effectué via l'interface série émulée de l'Arduino
+
* Tous les éléments du système (logiciel sur PC, sur l'Arduino, capteurs/actionneurs, concepts électroniques, informatique, ...) doivent être documentés avec soin, puisque l'ensemble n'est qu'un prétexte à s'approprier les différents éléments technologiques mis en oeuvre.
−
* Moteur de jeu type variables d'état + lois d'évolution, eg simulateur. Certaines de ces variables sont commandables (grace à l'interface), d'autres sont visualisées sur des indicateurs hw
+
* Les possibilités de modification et d'extension doivent être importantes et bien documentées: le projet/jeu/réalisation initiale n'est qu'un exemple, qui n'est pas à consommer en soi, mais doit servir de point de départ vers d'autres projets.
−
* Eventuellement, en complément des actionneurs qui constituent l'interface hw, l'écran de l'ordinateur peut être utilisé pour afficher une vue plus complexe du process et/ou des animations amusantes pour renforcer l'aspect ludique du jeu.
+
−
* L'ensemble hw+sw est pensé pour servir de prétexte à s'approprier les différents éléments technologiques mis en oeuvre:
+
−
** principes électroniques, grâce à l'arduino
+
−
** principes logiciels, grâce à... JLM/FANG ?
+
  
 
==Fonctionnalités==
 
==Fonctionnalités==
  
 
===Partie software===
 
===Partie software===
−
La plate forme software de base doit permettre de simplement lire / écrire sur les différents éléments de l'interface hardware. Tout comme l'on ferait avec un joystick, le logiciel prend en entrée des valeurs en pourcentage (éventuellement codées sur un octet pour simplifier). Pour les mêmes raisons et pour simplifier le développement d'autes interfaces / logiciels, il génère également en sortie des valeurs simples à convertir. Cette fois encore, l'utilisation d'un pourcentage semble être une bonne idée.
+
Il y a deux software: celui sur le PC et celui de l'Arduino. Ils doivent communiquer/échanger des informations ; le soft coté PC se charge en prime de la "game logic" (règles du jeu) et d'affichage complémentaire (et peut être interactions avec clavier, souris, etc), celui coté Arduino doit se charger des capteurs et actionneurs.
 +
 
 +
Le protocole de communication entre le software tournant sur le microcontroleur et celui sur le PC doit se prêter aux extensions. Il est donc préférable qu'il soit simple (à comprendre/prendre en mains) et flexible (extensible/modifiable). Malgré les inconvénients de cette approche, il a été jugé préférable de transmettre les informations "en clair", sous forme de trames intelligibles par un humain (qui sera de toute manière encouragé à aller y fourrer son nez), c'est à dire de chaines de caractères, du type: "xxxx,yyyy,zzzz,tttt;". Il sera envisageable, dans des versions ultérieures/pour novices déjà initiés, d'utiliser des protocoles plus sophistiqués, tels que Firmata. Mais puisqu'on souhaite permettre de s'approprier chaque brique constitutive, ce ne peut pas être le choix fait pour la version initiale.
 +
 
 +
Dans l'absolu, étant donné le hardware utilisé (port série virtuel offert par l'arduino), le langage coté PC n'a pas d'importance. Il sera même intéressant de disposer d'un grand nombre d'alternatives ! En pratique, j'ai plutôt l'habitude (enfin, de vagues restes) de java, et l'environnement de développement/programmation de l'Arduino étant en java (et open source), il semble raisonnable de commencer par ce langage. Cela permet d'envisager à terme d'intégrer des éléments dans une version spécifique de cet environnement, voire de servir d'introduction aux mécanismes dudit environnement ; toujours pour encourager les utilisateurs à s'approprier les concepts, outils, et en faire réellement ce qu'ils souhaitent par la suite.
 +
 
 +
Le logiciel de l'Arduino se doit d'exposer les règles fondamentales & mécanismes habituels de code embarqué sur ce genre de plateforme.  
  
 
===Partie Hardware===
 
===Partie Hardware===
−
Les éléments hard montés sur la carte 'version de base' sont choisis pour fournir un support à une initiation à l'électronique. Il semble intéressant de pouvoir gérer des galvas, interrupteurs, potentiomètres, leds et servos de modélisme. Par ailleurs, une charge quelconque nécessitant un petit transistor NPN ferait un bon support pédagogique ; une ampoule basse tension (type vélo) semble toute indiquée.
+
Les éléments hard montés sur la carte 'version de base' sont choisis pour fournir un support à une initiation à l'électronique. Histoire de permettre par la suite tout un tas de projets, il a été convenu:
 +
- de n'utiliser que des éléments génériques, simples ; permettant de s'approprier les concepts (plutôt que de se plonger dans la doc d'un composant spécifique)
 +
- de ne pas chercher à complexifier le montage, ni à l'optimiser plus que nécessaire (si telle fonction n'est pas possible sans utiliser un capteur complexe & 5 astuces d'interface, on s'en passe)
  
 +
Bref, les fondamentaux, tous les fondamentaux:
 +
- interrupteurs,
 +
- potentiomètres,
 +
- leds
 +
- servos de modélisme
 +
- une charge quelconque nécessitant un petit transistor NPN (ampoule basse tension (type vélo), relai, ventilateur, buzzer, ...)
  
 +
Tout un tas de sophistication seront envisageables/possibles par la suite, mais ce sera aux utilisateurs de les construire sur la base de leurs compétences nouvellement acquises... et de leur propre besoins et envies !
  
−
La conversion entre les différentes tensions mesurées sur les potentiomètres de l'interface est réalisée par l'Arduino de manière à fournir une couche d'abstraction simple du matériel. Le firmware de l'Arduino doit donc se charger de la partie calibration de l'interface.
+
===Partie documentation & support===
 +
Elle est tout aussi importante (voire plus) que la partie software & hardware. Pour l'instant, rien n'est gravé dans le marbre... ni même couché par écrit ! L'objectif principal reste de rendre accessible *tous* les éléments constitutifs de l'ensemble. De la manière dont je l'envisage, elle se découpe de la manière suivante:
 +
- une documentation autosuffisante, précise, sur tous les éléments constitutifs. Servant de référence/dictionnaire/manuel technique en cas de questionnement sur un point précis
 +
- une trame (plusieurs, en fait) permettant de s'approprier petit à petit les concepts sous jacents. Ceci avec différents points de départ (correspondant aux différents publics envisagés) et différents déroulements: auto-apprentissage, support d'atelier (qu'il soit régulier/sur la durée, ou bien dans le cadre d'un événement/d'une intervention quelque part).
 +
Bien que cette documentation se doive d'être complète et suffisante pour la majorité des fonctionnalités présentées, elle doit également faire référence/donner les pistes pertinentes pour toute personne intéressée pour pousser plus avant ses recherches.
  
−
Pour maximiser les différentes possibilités software/hardware, le firmware de l'arduino doit être en mesure de reconfigurer à chaud les différentes I/O disponibles sur la carte en fonction des besoins de la simulation et de l'interface.
 
  
 
==Ressources==
 
==Ressources==
Line 63: Line 112:
  
 
==Questions ouvertes/problèmes==
 
==Questions ouvertes/problèmes==
−
=== quid de la partie soft sur PC? ===
 
−
* Clément: moi je vote pour:
 
−
** faire une API propre, bien documentée, pour les couches basses/abstractant le hw, ceci dans un ou plusieurs langages
 
−
*** permet de se concentrer sur notre "coeur d'activité"
 
−
*** permet d'etre quick win
 
−
*** permet d'impliquer d'autres gens avec expertise complémentaire
 
−
** faire un démonstrateur minimaliste infame coté PC 'couche haute'
 
−
** se rapprocher de JLM/FANG (voir avec mon frère)
 
−
 
 
=== quid de l'aspect DIY&récup vs facilité de faire un kit ===
 
=== quid de l'aspect DIY&récup vs facilité de faire un kit ===
 
* Clément: je vote pour
 
* Clément: je vote pour
 
** faire un peu tout à moyen terme
 
** faire un peu tout à moyen terme
 
** mais à court terme se concentrer sur la version as cheap and easy as possible, cad une sorte de starter kit arduino + nécessaire pour construire une interface avec
 
** mais à court terme se concentrer sur la version as cheap and easy as possible, cad une sorte de starter kit arduino + nécessaire pour construire une interface avec
 +
=> cela n'empêche pas la découpe laser pour "faire bonne impression", sans décourager les reproductions (eg: pas d'assemblage ou de découpe impossible à reproduire avec un outillage simple), ni le sourcing de composants neufs (quoique manifestement trouvables par d'autres biais).
  
 
=== quid des fonctionnalités précises (eg capteurs, actionneurs) présents sur l'interface ===
 
=== quid des fonctionnalités précises (eg capteurs, actionneurs) présents sur l'interface ===
 
* Clément: je vote pour:
 
* Clément: je vote pour:
 
** dans la 1re version, essayer le plus possible d'en avoir pour le moins cher possible, et le moins compliqué: as cheap and easy as possible, toujours
 
** dans la 1re version, essayer le plus possible d'en avoir pour le moins cher possible, et le moins compliqué: as cheap and easy as possible, toujours
−
** réfléchir malgré tout aux notions électroniques possible d'inculquer par ces biais, et vérifier de la faisabilité du jeu prévu avec ce qu'on installera
+
** réfléchir malgré tout aux notions électroniques possible d'inculquer par ces biais, et vérifier de la faisabilité du jeu prévu avec ce qu'on installera (ou, trouver un autre jeu).
 +
=> etch a sketch est parfait en ce sens.
  
 
=== quid des acteurs impliqués (ou devant l'être) dans le projet ===
 
=== quid des acteurs impliqués (ou devant l'être) dans le projet ===
−
* Clément: je vote pour:
+
Eh bien... ca reste à voir. Entre les membres du lab & les utilisateurs/contributeurs potentiels, ca fait du monde ! Mais jusqu'ici, il semblerait que j'aie du pain sur la planche jusqu'au stade beta, ou d'autres pourront s'approprier tel ou tel aspect du projet.
−
** Crafty fait du soft coté PC
+
−
** Yannick fait de l'appro de matos, du proto
+
−
** Clément fait du coté arduino & doc pédagogique + coordination projet
+
−
 
+
  
 
==Macro planning==
 
==Macro planning==
−
* Réaliser un premier prototype hw courant avril pour pouvoir valider certains concepts et travailler sur le logiciel par la suite
+
* Réaliser un premier prototype hw courant avril 2011 pour pouvoir valider certains concepts et travailler sur le logiciel par la suite => fait.
−
* Ebaucher le logiciel courant mai, pour distribution à des testeurs + développeurs complémentaires ; prévoir d'autres interfaces hw pour qu'ils fassent des essais. Faire des démos pour peaufiner le concept
+
* Ebaucher le logiciel courant mai, pour distribution à des testeurs + développeurs complémentaires ; prévoir d'autres interfaces hw pour qu'ils fassent des essais. Faire des démos pour peaufiner le concept => pas vraiment fait à temps, il y a eu de la dispersion ! (tentative d'autonomie de l'Arduino, réalisation de l'animation bras robotique)
−
* Tenter de créer une dynamique autour de ce projet au delà du lab, pour inciter d'autres acteurs à s'approprier l'ensemble
+
* Tenter de créer une dynamique autour de ce projet au delà du lab, pour inciter d'autres acteurs à s'approprier l'ensemble => pas encore tout à fait réussi, même si l'intéret pour le projet et les résultats sont déjà là.
  
−
=Etat d'avancement=
+
==Actions passées/Prochaines actions/en cours==
−
* fin 2011: "fin" du projet/atteinte d'un certain niveau de maturité permettant de passer à autre chose/refaire un point sur les objectifs&attendus.
+
−
* mois à suivre: (OBJECTIFS)
+
−
- mettre en place workshop d'application à l'Electrolab
+
−
- développement des fiches d'activité/de support
+
−
- développement du jeu d'origine (faisant appel à plus d'éléments que le bras & etch a sketch)
+
−
* 1re quinzaine septembre: (OBJECTIFS)
+
−
- finaliser les docs de présentation/support pour l'owf: photos, dossier de présentation
+
−
- clean-up du code arduino/java + publication pour la version etch a sketch
+
−
- fabrication du premier proto pour etch a sketch (à terme, plusieurs exemplaires, pour diffusion de beta lors de/suite à l'owf)
+
−
- derniers cadrages pour rework v1=>v2 (ou simplement v1.2) du bras robotique. En particulier, interfacage squeakbot, pour présenter une alternative et montrer la généricité du concept fuku
+
−
* fin aout 2011:
+
−
- soucis pratique avec la machine de découpe laser: fabrication v0.2 en découpe laser en suspens jusqu'à nouvel ordre
+
−
- prototypage d'un spin-off 'etch a sketch': Proof of Concept java/arduino opérationnelle (publication du code à venir, après clean up)
+
−
- négociations pour la v2 du spin-off 'bras robotique' faite pour planète science. WE de travail pour passer de v1 (présentée à la Japan Expo) en v2 présentable à l'OWF planifié pour le Groweek (week end de travaux du secteur robotique de planète sciences, ouvert à tous), les 17/18 septembre
+
−
* début aout 2011: acceptation présentation OWF ; préparation v0.2 pour cette occasion
+
−
* juillet 2011: "livraison" de la v0.1 à un utilisateur pour beta testing ; prise de rendez-vous pour l'OWF fin septembre 2011
+
−
* juin 2011: réalisation d'un fork pour l'animation bras robotique de planète science ; réalisation d'une interface en acrylique
+
−
* 010 mai 2011: cablage du proto 0.1 & test rapide soft
+
−
* 05 mai 2011: session travail sur proto 0: découpe du mdf
+
−
* 03 mai 2011: commande de potards (http://fr.mouser.com/ProductDetail/BI-Technologies/P160KN-0QD15B10K/?qs=sGAEpiMZZMtxdMMi52izyq2vfP2RDTRmHzs3%252bIJ%252bhKI%3d
+
−
* courant avril 2011: achat de panneau plastique, prototypage soft (cf )[http://wiki.electrolab.fr/Projets:Perso:2011:OpenShima projet Open Shima]
+
−
* 07 avril 2011: soirée proto version 0
+
−
* 31 mars 2011: soirée b(ière)rainstorming sur le projet
+
−
* Mars 2011: début du projet
+
  
−
==Prochaines actions/en cours==
+
===TODO 3 : prototype 0.2===
−
===TODO 0 : brainstorming===
+
Objectifs:
−
* La première application, c'est naturellement celle qui s'inspire du PJC initial. Mais c'est un peu limité, et il doit être possible de trouver d'autres "thèmes" (brainstorm!)
+
L'objectif du prototype 0.2 est de tirer les enseignements de la version précédente pour réaliser un modèle permettant une diffusion plus large. Il est prévu de présenter cette version lors de l'OWF en septembre 2011, et de le confronter à des utilisateurs finaux.
−
** sous marin
+
Vu la simplicité du kit envisagé, il est prévu d'en avoir quelques uns à donner aux personnes les plus motivées pour tester le concept.
−
** usine retraitement des eaux usées
+
A noter que lors de l'OWF, le bras robot plasci sera présenté également. Selon le temps disponible, il sera plus avancé que la version présentée à la Japan Expo...
−
** éolienne
+
−
** barrage hydroélectrique
+
−
** pisciculture
+
−
** lockpicking
+
−
** centrale production bio-carburant
+
−
** Usine de production de parfum (colonne de [http://fr.wikipedia.org/wiki/Vapocraquage vapocraquage] )
+
−
** Machines outil (genre gras 5 axes, etc...)
+
−
** Un pinball (pas très serious game, mais un bon pjc DIY en perspective !)
+
  
−
*At random, quelques design goals, feature requests, ...
+
Features:
−
** que ce soit hautement hackable, pensé non pas comme un jouet mais comme un moyen fun d'introduction à la bidouille, notamment chez les jeunes
+
Améliorations par rapport à la précédente version (0.1):
−
** que ce soit même une incitation par tous les moyens à se faire bidouiller
+
* réalisation physique plus propre (découpe laser & plexi)
 +
* meilleur choix des éléments électroniques montés (exit galva, welcome servos ?)
 +
* réalisation d'un soft coté PC et validation du concept d'interaction
  
 +
Description
 +
Finalement, pour des raisons de simplicité (à tous niveaux), le jeu "centrale nucléaire" est en suspens (quoique des prototypes/travaux aient été réalisés). L'application retenue est etch a sketch, permettant simplement de dessiner à l'écran. C'est assez pauvre coté interactions (surtout coté actionneurs: on a pas trouvé de prétexte crédible pour les servos, npn, ...), mais finalement ce n'est pas forcément un mal, puisque c'est simple tout en étant complet.
 +
Coté réalisation, quelques soucis coté découpe laser (indisponibilité de la machine) risquent de compromettre une réal' ultra propre. Ou, de favoriser une réalisation "à la main" et donc incitant peut être plus facilement la reproduction :)
  
−
=> On va découper les choses de la manière suivante:
+
Reste à faire:
−
* on fait un proto simple (cf proto 0) puis un autre un peu plus évolué (cf proto 1)
+
-tenter tout de même de fabriquer en laser quelques exemplaires. Sinon, les faire "à l'ancienne"
−
* on fait le minimum de code pour que ca tourne, puis on diffuse déjà ca aux personnes intéressées pour contribuer du code, du matériau pédagogique complémentaire/associé.
+
-compléter le dossier pour l'organisation de l'OWF
−
Ensuite, ben on avise selon les retours :)
+
-peaufiner/cleaner le code existant (coté PC surtout, pour release...)
 +
-ébaucher la documentation (les deux aspects sont à considérer: "fiche composant/concept", "trame d'activité/de prise en main")
 +
-concrétiser les pistes existantes pour la constitution d'un kit, vendable par l'Electrolab
 +
 
 +
 
 +
===TODO 2: spin off bras robotique pour planète sciences===
 +
Retour d'expérience à documenter ; en attendant, consulter le wiki (pas forcément à jour non plus) sur le site de plasci:http://www.planete-sciences.org/robot/wiki/doku.php?id=brasrobot
  
 
===TODO 1 : prototype 0.1===
 
===TODO 1 : prototype 0.1===
Line 225: Line 242:
  
  
−
===TODO 2 : prototype 0.2===
 
−
Objectifs:
 
−
L'objectif du prototype 0.2 est de tirer les enseignements de la version précédente pour réaliser un modèle permettant une diffusion plus large. Il est prévu de présenter cette version lors de l'OWF en septembre 2011, et de le confronter à des utilisateurs finaux.
 
  
−
Features:
+
===TODO 0 : brainstorming===
−
Améliorations par rapport à la précédente version:
+
* La première application, c'est naturellement celle qui s'inspire du PJC initial. Mais c'est un peu limité, et il doit être possible de trouver d'autres "thèmes" (brainstorm!)
−
* réalisation physique plus propre (découpe laser & plexi)
+
** sous marin
−
* meilleur choix des éléments électroniques montés (exit galva, welcome servos) & learning curve documentée
+
** usine retraitement des eaux usées
 +
** éolienne
 +
** barrage hydroélectrique
 +
** pisciculture
 +
** lockpicking
 +
** centrale production bio-carburant
 +
** Usine de production de parfum (colonne de [http://fr.wikipedia.org/wiki/Vapocraquage vapocraquage] )
 +
** Machines outil (genre gras 5 axes, etc...)
 +
** Un pinball (pas très serious game, mais un bon pjc DIY en perspective !)
 +
** etch a sketch !!!
  
−
Description
+
*At random, quelques design goals, feature requests, ...
−
Realisation/TODO:
+
** que ce soit hautement hackable, pensé non pas comme un jouet mais comme un moyen fun d'introduction à la bidouille, notamment chez les jeunes
−
* objectifs/description sous forme de doc à peu près présentable
+
** que ce soit même une incitation par tous les moyens à se faire bidouiller
−
* documentation (au moins ébauche de) à peu près utilisable
+
−
* plans dxf des pièces à découper
+
−
* choix d'une application funky, réalisation soft correspondant
+
−
* quelques exemplaires en kit en plus de l'exemplaire de démonstration, pour diffusion & beta testing out in ze ouaillde.
+
  
−
=Résultats=
+
 
−
Permet de capitaliser sur le travail effectué: l'utiliser, le reproduire, l'améliorer, ...
+
=> On va découper les choses de la manière suivante:
−
==Schéma structurel==
+
* on fait un proto simple (cf proto 0) puis un autre un peu plus évolué (cf proto 1)
−
TBC
+
* on fait le minimum de code pour que ca tourne, puis on diffuse déjà ca aux personnes intéressées pour contribuer du code, du matériau pédagogique complémentaire/associé.
−
==Budget==
+
Ensuite, ben on avise selon les retours :)
−
TBC
+
−
==Contacts, fournisseurs==
+
−
TBC
+
−
==Prototype 1==
+
−
TBC
+

Revision as of 00:00, 8 September 2011

Interface de jeu
Auteur Clément
Date de proposition 25/03/2011
Tags du projet PPC
Lieu d'utilisation final Anywhere
Utilisateur final Youngsters
Type de projet

Projet personnel de Clément

Projet Interface de jeu

Abstract à peaufiner pour donner un réel apercu de tous les aspects de ce projet...
... qui devient de plus en plus touffu !



Etat d'avancement/Historique/News

  • fin 2011: "fin" du projet/atteinte d'un certain niveau de maturité permettant de passer à autre chose/refaire un point sur les objectifs&attendus.
  • mois à suivre: (OBJECTIFS)

- mettre en place workshop d'application à l'Electrolab - développement des fiches d'activité/de support - développement du jeu d'origine (faisant appel à plus d'éléments que le bras & etch a sketch)

  • 1re quinzaine septembre: (OBJECTIFS)

- finaliser les docs de présentation/support pour l'owf: photos, dossier de présentation - clean-up du code arduino/java + publication pour la version etch a sketch - fabrication du premier proto pour etch a sketch (à terme, plusieurs exemplaires, pour diffusion de beta lors de/suite à l'owf) - derniers cadrages pour rework v1=>v2 (ou simplement v1.2) du bras robotique. En particulier, interfacage squeakbot, pour présenter une alternative et montrer la généricité du concept fuku

  • fin aout 2011:

- soucis pratique avec la machine de découpe laser: fabrication v0.2 en découpe laser en suspens jusqu'à nouvel ordre - prototypage d'un spin-off 'etch a sketch': Proof of Concept java/arduino opérationnelle (publication du code à venir, après clean up) - négociations pour la v2 du spin-off 'bras robotique' faite pour planète science. WE de travail pour passer de v1 (présentée à la Japan Expo) en v2 présentable à l'OWF planifié pour le Groweek (week end de travaux du secteur robotique de planète sciences, ouvert à tous), les 17/18 septembre

  • début aout 2011: acceptation présentation OWF ; préparation v0.2 pour cette occasion
  • juillet 2011: "livraison" de la v0.1 à un utilisateur pour beta testing ; prise de rendez-vous pour l'OWF fin septembre 2011
  • juin 2011: réalisation d'un fork pour l'animation bras robotique de planète science ; réalisation d'une interface en acrylique
  • 010 mai 2011: cablage du proto 0.1 & test rapide soft
  • 05 mai 2011: session travail sur proto 0: découpe du mdf
  • 03 mai 2011: commande de potards (http://fr.mouser.com/ProductDetail/BI-Technologies/P160KN-0QD15B10K/?qs=sGAEpiMZZMtxdMMi52izyq2vfP2RDTRmHzs3%252bIJ%252bhKI%3d
  • courant avril 2011: achat de panneau plastique, prototypage soft (cf )projet Open Shima
  • 07 avril 2011: soirée proto version 0
  • 31 mars 2011: soirée b(ière)rainstorming sur le projet
  • Mars 2011: début du projet


Introduction

Donne un appercu des tenants et aboutissants du projet.

Motivation & Contexte

Ayant bien aimé un petit jeu con (voir le lien plus bas), je me suis dit que ce serait nettement mieux d'y jouer avec une interface adaptée (un joystick fait sur mesure). Ayant la chance d'avoir toutes les compétences requises pour en faire un, j'ai creusé un peu la question, et je me suis rendu compte: - que ca pouvait être super fun, à faire et à utiliser, sans être compliqué (pour quelqu'un du métier) - que ca rejoignait une cause nettement plus "importante", qui personnellement me motive: diffuser et démocratiser certains trucs technologiques. - que pas mal de gens d'horizons divers accrochaient immédiatement à l'idée De là est venue une réflexion où la réalisation de ladite interface n'est plus qu'un prétexte pour développer un ensemble de ressources pédagogiques. L'objectif central est donc devenu de constituer un ensemble de ressources fondamentales pour que les utilisateurs s'approprient les savoirs et savoirs faire nécessaires pour réaliser ce "petit projet con", pas si con que ca au final, mais suffisamment léger pour en être intéressant et motivant.

En pratique, j'envisage ce projet comme un démonstrateur, un support pour diffuser (notamment par le biais d'ateliers réguliers au lab et ailleurs) les rudiments de l'électronique & informatique (embarquée), à la fois indispensable pour réaliser bon nombre de projets, et ouvrant un nombre incalculable de possibilités. Accessoirement, le lab ayant besoin à la fois de nouveaux membres porteurs de projets (qu'ils possèdent initialement les compétences requises... ou pas), et d'entrées d'argent pour financer ses activités, l'idée de préparer des kits ayant un réel intérêt pour les débutants a fait son chemin. Parce que faire clignoter 3 leds, assembler un robot inutile, c'est bien, mais on peut faire plus diversifié et durable.


Objectifs

Rendre fun un plus ou moins serious game grace à une interface hw, servant de prétexte à:

  • une introduction à l'électronique, par l'intermédiaire des capteurs/actionneurs requis par le jeu (et sélectionnés intelligemment)
  • une introduction à l'informatique embarquée, par l'utilisation d'un microcontroleur accessible facilement (arduino)
  • une introduction à l'informatique pas embarquée, par le lien avec un ordinateur & le développement d'une petite application (le jeu à proprement parler)
  • Eventuellement, en cerise sur le gateau, une initiation amusante à un procédé physique / chimique relativement complexe, abordé simplement/de manière ludique.

Principes

  • Un jeu simple tourne sur un ordinateur personnel ; le langage dudit jeu importe peu, mais les mécanismes doivent à terme en être compréhensibles.
  • La majeure partie des fonctionnalités du jeu sont pilotées par une interface hw basée sur une Arduino, avec des capteurs/actionneurs divers et variés (on construit un "joystick" sur mesure).
  • Tous les éléments du système (logiciel sur PC, sur l'Arduino, capteurs/actionneurs, concepts électroniques, informatique, ...) doivent être documentés avec soin, puisque l'ensemble n'est qu'un prétexte à s'approprier les différents éléments technologiques mis en oeuvre.
  • Les possibilités de modification et d'extension doivent être importantes et bien documentées: le projet/jeu/réalisation initiale n'est qu'un exemple, qui n'est pas à consommer en soi, mais doit servir de point de départ vers d'autres projets.

Fonctionnalités

Partie software

Il y a deux software: celui sur le PC et celui de l'Arduino. Ils doivent communiquer/échanger des informations ; le soft coté PC se charge en prime de la "game logic" (règles du jeu) et d'affichage complémentaire (et peut être interactions avec clavier, souris, etc), celui coté Arduino doit se charger des capteurs et actionneurs.

Le protocole de communication entre le software tournant sur le microcontroleur et celui sur le PC doit se prêter aux extensions. Il est donc préférable qu'il soit simple (à comprendre/prendre en mains) et flexible (extensible/modifiable). Malgré les inconvénients de cette approche, il a été jugé préférable de transmettre les informations "en clair", sous forme de trames intelligibles par un humain (qui sera de toute manière encouragé à aller y fourrer son nez), c'est à dire de chaines de caractères, du type: "xxxx,yyyy,zzzz,tttt;". Il sera envisageable, dans des versions ultérieures/pour novices déjà initiés, d'utiliser des protocoles plus sophistiqués, tels que Firmata. Mais puisqu'on souhaite permettre de s'approprier chaque brique constitutive, ce ne peut pas être le choix fait pour la version initiale.

Dans l'absolu, étant donné le hardware utilisé (port série virtuel offert par l'arduino), le langage coté PC n'a pas d'importance. Il sera même intéressant de disposer d'un grand nombre d'alternatives ! En pratique, j'ai plutôt l'habitude (enfin, de vagues restes) de java, et l'environnement de développement/programmation de l'Arduino étant en java (et open source), il semble raisonnable de commencer par ce langage. Cela permet d'envisager à terme d'intégrer des éléments dans une version spécifique de cet environnement, voire de servir d'introduction aux mécanismes dudit environnement ; toujours pour encourager les utilisateurs à s'approprier les concepts, outils, et en faire réellement ce qu'ils souhaitent par la suite.

Le logiciel de l'Arduino se doit d'exposer les règles fondamentales & mécanismes habituels de code embarqué sur ce genre de plateforme.

Partie Hardware

Les éléments hard montés sur la carte 'version de base' sont choisis pour fournir un support à une initiation à l'électronique. Histoire de permettre par la suite tout un tas de projets, il a été convenu: - de n'utiliser que des éléments génériques, simples ; permettant de s'approprier les concepts (plutôt que de se plonger dans la doc d'un composant spécifique) - de ne pas chercher à complexifier le montage, ni à l'optimiser plus que nécessaire (si telle fonction n'est pas possible sans utiliser un capteur complexe & 5 astuces d'interface, on s'en passe)

Bref, les fondamentaux, tous les fondamentaux: - interrupteurs, - potentiomètres, - leds - servos de modélisme - une charge quelconque nécessitant un petit transistor NPN (ampoule basse tension (type vélo), relai, ventilateur, buzzer, ...)

Tout un tas de sophistication seront envisageables/possibles par la suite, mais ce sera aux utilisateurs de les construire sur la base de leurs compétences nouvellement acquises... et de leur propre besoins et envies !

Partie documentation & support

Elle est tout aussi importante (voire plus) que la partie software & hardware. Pour l'instant, rien n'est gravé dans le marbre... ni même couché par écrit ! L'objectif principal reste de rendre accessible *tous* les éléments constitutifs de l'ensemble. De la manière dont je l'envisage, elle se découpe de la manière suivante: - une documentation autosuffisante, précise, sur tous les éléments constitutifs. Servant de référence/dictionnaire/manuel technique en cas de questionnement sur un point précis - une trame (plusieurs, en fait) permettant de s'approprier petit à petit les concepts sous jacents. Ceci avec différents points de départ (correspondant aux différents publics envisagés) et différents déroulements: auto-apprentissage, support d'atelier (qu'il soit régulier/sur la durée, ou bien dans le cadre d'un événement/d'une intervention quelque part). Bien que cette documentation se doive d'être complète et suffisante pour la majorité des fonctionnalités présentées, elle doit également faire référence/donner les pistes pertinentes pour toute personne intéressée pour pousser plus avant ses recherches.


Ressources

Réalisation

Rassemble un ensemble de ressources décrivant les étapes du projet, et aidant à organiser le travail en cours

Questions ouvertes/problèmes

quid de l'aspect DIY&récup vs facilité de faire un kit

  • Clément: je vote pour
    • faire un peu tout à moyen terme
    • mais à court terme se concentrer sur la version as cheap and easy as possible, cad une sorte de starter kit arduino + nécessaire pour construire une interface avec

=> cela n'empêche pas la découpe laser pour "faire bonne impression", sans décourager les reproductions (eg: pas d'assemblage ou de découpe impossible à reproduire avec un outillage simple), ni le sourcing de composants neufs (quoique manifestement trouvables par d'autres biais).

quid des fonctionnalités précises (eg capteurs, actionneurs) présents sur l'interface

  • Clément: je vote pour:
    • dans la 1re version, essayer le plus possible d'en avoir pour le moins cher possible, et le moins compliqué: as cheap and easy as possible, toujours
    • réfléchir malgré tout aux notions électroniques possible d'inculquer par ces biais, et vérifier de la faisabilité du jeu prévu avec ce qu'on installera (ou, trouver un autre jeu).

=> etch a sketch est parfait en ce sens.

quid des acteurs impliqués (ou devant l'être) dans le projet

Eh bien... ca reste à voir. Entre les membres du lab & les utilisateurs/contributeurs potentiels, ca fait du monde ! Mais jusqu'ici, il semblerait que j'aie du pain sur la planche jusqu'au stade beta, ou d'autres pourront s'approprier tel ou tel aspect du projet.

Macro planning

  • Réaliser un premier prototype hw courant avril 2011 pour pouvoir valider certains concepts et travailler sur le logiciel par la suite => fait.
  • Ebaucher le logiciel courant mai, pour distribution à des testeurs + développeurs complémentaires ; prévoir d'autres interfaces hw pour qu'ils fassent des essais. Faire des démos pour peaufiner le concept => pas vraiment fait à temps, il y a eu de la dispersion ! (tentative d'autonomie de l'Arduino, réalisation de l'animation bras robotique)
  • Tenter de créer une dynamique autour de ce projet au delà du lab, pour inciter d'autres acteurs à s'approprier l'ensemble => pas encore tout à fait réussi, même si l'intéret pour le projet et les résultats sont déjà là.

Actions passées/Prochaines actions/en cours

TODO 3 : prototype 0.2

Objectifs: L'objectif du prototype 0.2 est de tirer les enseignements de la version précédente pour réaliser un modèle permettant une diffusion plus large. Il est prévu de présenter cette version lors de l'OWF en septembre 2011, et de le confronter à des utilisateurs finaux. Vu la simplicité du kit envisagé, il est prévu d'en avoir quelques uns à donner aux personnes les plus motivées pour tester le concept. A noter que lors de l'OWF, le bras robot plasci sera présenté également. Selon le temps disponible, il sera plus avancé que la version présentée à la Japan Expo...

Features: Améliorations par rapport à la précédente version (0.1):

  • réalisation physique plus propre (découpe laser & plexi)
  • meilleur choix des éléments électroniques montés (exit galva, welcome servos ?)
  • réalisation d'un soft coté PC et validation du concept d'interaction

Description Finalement, pour des raisons de simplicité (à tous niveaux), le jeu "centrale nucléaire" est en suspens (quoique des prototypes/travaux aient été réalisés). L'application retenue est etch a sketch, permettant simplement de dessiner à l'écran. C'est assez pauvre coté interactions (surtout coté actionneurs: on a pas trouvé de prétexte crédible pour les servos, npn, ...), mais finalement ce n'est pas forcément un mal, puisque c'est simple tout en étant complet. Coté réalisation, quelques soucis coté découpe laser (indisponibilité de la machine) risquent de compromettre une réal' ultra propre. Ou, de favoriser une réalisation "à la main" et donc incitant peut être plus facilement la reproduction :)

Reste à faire: -tenter tout de même de fabriquer en laser quelques exemplaires. Sinon, les faire "à l'ancienne" -compléter le dossier pour l'organisation de l'OWF -peaufiner/cleaner le code existant (coté PC surtout, pour release...) -ébaucher la documentation (les deux aspects sont à considérer: "fiche composant/concept", "trame d'activité/de prise en main") -concrétiser les pistes existantes pour la constitution d'un kit, vendable par l'Electrolab


TODO 2: spin off bras robotique pour planète sciences

Retour d'expérience à documenter ; en attendant, consulter le wiki (pas forcément à jour non plus) sur le site de plasci:http://www.planete-sciences.org/robot/wiki/doku.php?id=brasrobot

TODO 1 : prototype 0.1

Le but du prototype 0.1 est de fournir une base correcte pour développer un peu de soft et valider le concept. On va donc monter les éléments "en direct", cad avec le minimum de matos & d'électronique: pas de multiplexage, et dans la mesure du possible, des éléments les plus simples possible, bien que variés. Juste pour montrer ce qu'on peut brancher simplement sur une Arduino.


Il doit etre simple à:

  • comprendre
    • => pas de multiplexage des leds par exemple
  • fabriquer
    • => plexi plié/percé pour faire un pupitre, sur lequel est fixée l'arduino, les potards & différents switchs, leds, témoins (galva), ...
  • reproduire
    • => pas d'éléments de récup, juste des choses communes/courantes.


Type d'éléments montés/liste de course:

  • 4 potards (10k, linéaire, 17mm à montage sur panneau ; ref mouser: 858-P170N-QC12BR10K )
  • 3 leds (n'importe lesquelles, 3mm/5mm <20mA)
  • 4 galvanometre/indicateur (TODO: choisir, cf ressources) + élec de pilotage. => en fait, NON
  • 4 on/off switches/momentary (TODO: choisir, cf ressources)
  • 1 servomoteur (juste le connecteur)
  • 1 ampoule basse tension (type vélo ; juste les culots) + NPN + transistor
  • filasse pour relier à l'arduino (Fil, pin, gaine thermo) => sous forme de fil monobrin qui rentre bien dans les supports ; 3 couleurs min (idéalement, plein...)
  • barette sécable 1xPLEIN adaptée à l'arduino
  • support pour l'arduino (hex stand)

Penser également aux à coté (guide de montage/starting ; packaging ; outils nécessaire)

Ports arduino typique:

  • D0, D1: réservés port série
  • D2: (interrupt) => switch (x1)
  • D3, D5, D6, D9, D10, D11: (pwm) servo x1, ampoule1 x1, galva x4
  • D7, D8, D12: switch (x3)
  • D13: (led) led
  • A0, A1, A2, A3: Potards (x4)
  • A4, A5: led (x2)

Livrables:

  • tuto de réalisation
  • liste de course
  • doc néophyte sur le fonctionnement de chaque élément
  • code source exemple prise en main de chaque élément coté arduino
  • code source pour intégration au projet OpenShima coté arduino


Ressources:

  • NPN:
    • BC817 package pas cool (?), 0.5A
    • BC337 package cool, 0.8A
  • push:
    • mouser 104-0012-EVX

=> regarder également eBay/brocantes radio pour des lots à pas cher

TODOs:

  • yannick: contact pour négo appro galva => en fait, non: plutot des servos
  • clément:
    • doc néophyte
    • liste course
    • proto 0.x
    • code
    • check vincent pour contact découpe laser ; voir yannick pour format de fichier pour passage CNC
  • bussiere: cleaner son code & page wiki

Remarques:

  • faire un pdf imprimable pour faire sa propre face avant, voire tout reproduire
  • faire des faces avant interchangeables
  • les galvas, en fait ca sert à rien, il faut mettre des microservos en rab à la place => revoir liste des éléments

Commentaires:

  • Ce proto a été donné pour beta test ; il est utilisé en standalone (donc pas tout à fait comme prévu initialement), et a cette occasion on peut se rendre compte du coté limité des interactions possibles avec la plateforme. On constate aussi la difficulté/l'importance d'avoir un gamedesign pertinent (sinon, c'est assez chiant à jouer, et donc l'effet "plop" reste limité)


TODO 0 : brainstorming

  • La première application, c'est naturellement celle qui s'inspire du PJC initial. Mais c'est un peu limité, et il doit être possible de trouver d'autres "thèmes" (brainstorm!)
    • sous marin
    • usine retraitement des eaux usées
    • éolienne
    • barrage hydroélectrique
    • pisciculture
    • lockpicking
    • centrale production bio-carburant
    • Usine de production de parfum (colonne de vapocraquage )
    • Machines outil (genre gras 5 axes, etc...)
    • Un pinball (pas très serious game, mais un bon pjc DIY en perspective !)
    • etch a sketch !!!
  • At random, quelques design goals, feature requests, ...
    • que ce soit hautement hackable, pensé non pas comme un jouet mais comme un moyen fun d'introduction à la bidouille, notamment chez les jeunes
    • que ce soit même une incitation par tous les moyens à se faire bidouiller


=> On va découper les choses de la manière suivante:

  • on fait un proto simple (cf proto 0) puis un autre un peu plus évolué (cf proto 1)
  • on fait le minimum de code pour que ca tourne, puis on diffuse déjà ca aux personnes intéressées pour contribuer du code, du matériau pédagogique complémentaire/associé.

Ensuite, ben on avise selon les retours :)

Retrieved from "https://wiki.electrolab.fr/index.php?title=Projets:Perso:2011:InterfaceJeu&oldid=1499"