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

From Electrolab
Jump to: navigation, search
(Passe la photo de brique au début)
(proof of concept)
Line 112: Line 112:
  
 
==== proof of concept ====
 
==== proof of concept ====
On part sur l'idée de briques. Les caractéristiques/expression du besoin sont les suivantes:
+
Voir la page [[Projets:Perso:2011:TortueSimple:POC1|premier proto de base de controle + briques]]
* 96 emplacements
+
* 80 types de briques
+
* possibilité d'allumer une led (monochrome) par emplacement lorsqu'il est actif
+
 
+
Le principe d'identification des briques est d'intégrer une résistance de valeur donnée, que l'interface de contrôle va mesurer pour retrouver le type de la brique.
+
 
+
On envisage plusieurs solutions techniques:
+
*A: utilisation d'un seul microcontroleur (à définir ; typiquement un 'duino) avec front end constitué de multiplexeurs analogiques pour la mesure, et de registre à décalage pour piloter chacune des leds témoin d'activité
+
*B: utilisation de plusieurs microcontroleurs, chacun avec de quoi mesurer quelques emplacements + piloter leur éclairage ; mise en réseau de ces sous modules/pilotage par un module maitre
+
*C: utilisation de convertisseurs adc externes (type SPI) (+ éventuellement un I/O expander pour piloter les leds) => constitution de modules slave d'I/O, pilotés par un seul microcontroleur central.
+
 
+
Critiques:
+
*B: A priori, il n'y a pas besoin de patate pour le calcul pour un sous ensemble d'emplacements, et avoir à gérer plusieurs microcontroleurs semble overkill.
+
* rien n'empeche dans l'approche A d'etre également modulaire (cad, de mettre les mux sur des petits modules indépendants et avoir une seule carte centrale de pilotage).
+
 
+
La bonne question à poser est donc plutot:
+
* est-ce qu'on fait une carte de controle "monolithique", cad tous les composants sont sur une seule et meme carte, de fait moins extensible, mais plus facile à monter/fabriquer, ou bien est-ce qu'on prévoit d'emblé une carte master, de controle, et un ensemble de cartes slaves interfacant chacune un sous ensemble d'emplacements.
+
* est-ce qu'on utilise les channel d'adc du microcontroleur (et donc des mux analogiques), ou bien des adc externes connectés sur bus de donnée type SPI
+
  
 
==Ressources==
 
==Ressources==

Revision as of 22:25, 4 October 2012

Turzzle
Auteur Clément/Martin
Date de proposition 08/06/2011
Tags du projet PPC
Lieu d'utilisation final Anywhere
Utilisateur final Youngsters
Type de projet

Projet personnel de Clément/Martin

Projet Turzzle

Dédramatiser la programmation grâce à des ptites tortues (à la LOGO) qui courent partout par terre en s'inspirant d'un petit jeu con (http://www.robozzle.com/), mais sans ordinateur visible. Pour cela il faut :
- fabriquer une tortue simple (au sens LOGO),
- fabriquer des dalles adaptées pour qu'elle s'y déplace
- fabriquer une console de commandes et une interface de "programmation"


Actus

Voici un ptit teaser du module pour la tortue: Teaser Robozzle.JPG

Deux micromoteurs Maxon (issus de la commande groupée du lab, de belles bestioles) et un devkit TI (Cortex M3, Ethernet+CAN, double décodeur de quadrature). Yapluka !

Et un ptit teaser d'une brique représentant une instruction de l'interface tangible: Brique.jpg


Introduction

Beaucoup de gens pensent que pour Programmer un Ordinateur (avec les majuscules), il faut être une sorte de magicien moderne, capables d'une sorte de karaté mental à la Matrix pour parvenir à dompter une sorte de Deus Ex Machina grandiosement transandant comparable à HAL dans l'odyssé de l'espace, alors que non, pas du tout. En fait, ca demande bien des contorsions mentales, mais c'est qu'il faut parvenir à simplifier, simplifier et simplifier ses ordres pour les rendre compréhensibles par un vulgaire tas de fil dépourvu de toute jugeotte...

Objectifs

L'objectif de ce projet est de mettre au point des outils permettant de réaliser des animations visant à dédramatiser la programmation en permettant à des débutants complets (jeunes et moins jeunes) de programmer un petit robot inspiré des tortues LOGO dans un environnement un peu ludique.

La ligne éditoriale du projet est de cacher la technologie autant que possible pour éviter d'effrayer les nouveaux venus: pas de tape à l'oeil, on cherche à faire low tech, au moins en apparence. En particulier, il ne faut ni écran ni clavier visible.

L'objectif n'est PAS d'enseigner la programmation à proprement parlé, car cele serait difficile voire impossible d'atteindre cet objectif tout en collant à l'idée de jeu simple ciblant les débutants absolus.

Principes

Comme les tortues LOGO, l'objectif est de permettre aux débutants de comprendre que programmer, c'est donner des ordres très simples à des composants techniques très bêtes. On ajoute des idées venus du jeu robozzle pour ajouter une finalité plus forte aux programmes développés avec le robot. On ne fait plus un programme pour faire un programme, mais on le fait pour résoudre un problème donné (c'est à dire un niveau du jeu).

Le principe du jeu est basé sur un petit robot (donc) qui parcourt un monde simple composé d'une grille de cases. L'objectif du jeu est d'amener le robot à passer sur certaines cases du monde. Pour cela, on donne dispose de 3 ordres possibles: avance, tourne de 90° à gauche et tourne de 90° à droite. C'est tout. Ensuite, on peut écrire jusqu'à 6 fonctions (des suites nommées d'ordres) pour grouper les ordres ensemble, ce qui donne 6 ordres de plus : f1 à f6 pour appeller les fonctions. Enfin, il est possible de donner une couleur à un ordre donné. Par exemple, si on dit "avance rouge", le robot n'avancera que s'il se trouve sur une dalle rouge au moment de l'exécuter. Sinon, l'ordre est simplement ignoré et on passe à l'ordre suivant du programme. Au début du niveau, certaines cases contiennent des étoiles, qui disparaissent dès que le robot passe sur la case en question. Le niveau est gagné dès la disparition de la dernière étoile, même si le programme n'est pas fini (s'il reste des instructions à exécuter). Si le robot "tombe", c'est à dire va dans des cases sans dalle, le niveau est perdu.

L'interface du jeu est donc très simple en apparence. La mécanique du jeu (la motivation des joueurs) vient du fait que les programmes que l'on peut écrire sont de taille bornée. Cela force à factoriser les choses, et constitue un petit casse-tête sympatique. Il est également possible de faire des niveaux beaucoup plus avancés, où une maîtrise avancée de la récursivité (par exemple) est indispensable, mais c'est un peu hors sujet ici.

Fonctionnalités

Caractéristiques générales du jeu

La grille du monde est toujours inférieure à 14x14 dalles. Chaque dalle est soit rouge, soit verte, soit bleue. Certaines dalles portent des étoiles qui s'éteignent quand la tortue passe. La tortue accepte au maximum 6 fonctions de 10 instructions chacunes. En plus de la localisation des dalles et des étoiles, chaque niveau spécifie la quantité d'instructions que la tortue admet. Par exemple, http://www.robozzle.com/js/play.aspx?puzzle=23 restreint à une seule fonction, de seulement 4 instructions au maximum. Certaines choses possibles dans le jeu sur le site ne seront pas possibles à priori. En particulier, on ne prévoit pas d'autoriser à changer la couleur des dalles.

Le nombre de types d'ordres varie selon la variante visée. On peut pas faire moins que 7, la version classique du site robozzle en compte 12 et on peut occuper 20 types d'ordres si on pousse le concept.

  • Indispensable: 3 déplacements relatifs: avance, gauche, droite
  • Entre 4 et 6 pour les appels des différentes fonctions: F1, F2, F3, F4, F5, F6
  • Optionnel: 3 ordres pour changer la couleur de la dalle courante: to_red, to_green, to_blue
  • Encore plus optionnel: on pourrait ajouter 4 déplacements absolus: nord, sud, est, ouest. Dans la même veine, on peut vouloir des déplacements absolus de plus d'une case, comme NN, SS, EE, WW (voire NNN, SSS, EEE, WWW mais faut ptet pas abuser).

De plus, chaque ordre est décliné en 4 versions conditionnelles une version blanche qui s'exécute tout le temps, et trois versions rouge/vert/bleu qui ne s'exécutent que si la dalle courante est de la couleur dite.


Comme l'objectif est d'organiser des stands et autres démonstrations, la bonne dimension du jeu est de l'ordre de quelques mètres de coté. Par exemple, des dalles 25x25 cm donnent un niveau de jeu de l'ordre de 3,5mx3,5m, ce qui semble raisonnable.

Module Tortue

  • Software: juste du soft embarqué a priori, rien de bien sorcier. Il faut juste stocker la pile d'appel des fonctions de façon à pouvoir dépiler en fin de fonction.
  • Hardware:
    • deux servos modifiés pour la rotation continue
    • carte arduino/version customisée
    • capteurs de ligne (par exemple CNY70, ou équivalent en moins cher)
    • de quoi communiquer avec la console de commandes: liaison radio (Xbee ou full custom)?
    • de quoi communiquer avec les dalles: IR?
    • peut etre capteur de couleur (http://www.sparkfun.com/products/10656 par exemple, à tester)
    • logement pour piles AA/9v

Module Dalles

  • Software:
    • il faut détecter quand le niveau est terminé (toutes les étoiles sont éteintes), et prévenir la tortue pour qu'elle s'arrête
    • il faut peut-être prévoir un quelque chose permettant de vérifier que le niveau est soluble et qui lève une alarme si la disposition des dalles rend le niveau impossible. Un copain de Martin a fait un programme qui fait ceci, reste à savoir où on va trouver dans le jeu un processeur assez solide pour l'exécuter. http://www.loria.fr/~bedaride/robozzle.py
  • Hardware:

Tous les éléments structurels seraient à fabriquer en MDF découpés au laser (voir FR4, si c'est possible ???)

Il faut que les dalles puissent porter des gens qui marchent dessus pour leur permettre de suivre la tortue. Interdire de marcher sur les dalles irait contre l'objectif de dédramatisation.

Module interface de commandes

pré-étude

À priori, il n'y a absolument pas de logiciel dans ce module, seulement du matériel. Le gros défi est de faire une interface aussi pratique que possible pour les utilisateurs.

Pour encoder chaque ordre sur le panneau de commandes, on va disposer plusieurs éléments cote à cote sur le panneau de commandes. Il faut 60 tels éléments sur le panneau (10 instructions par fonction). On veut à la fois que ce soit (1) pratique à utiliser (2) petit pour avoir un panneau de taille raisonnable (3) solide car c'est une pièce d'usure (4) bon marché car on en a besoin d'une centaine pour commencer à jouer, probablement.

Par ailleurs, on peut vouloir ajouter 3 emplacements de commande en plus sur le panneau de commande. Cela permetterait de faire un livret où les niveaux sont imprimés. L'utilisateur pourrait alors réfléchir complètement unplug sur son niveau avec le panneau de commandes (non connecté) et le livret, avant de tester sa solution en connectant le panneau. Les trois emplacements de commandes supplémentaires permettant aux machines d'identifier le niveau joué.

  • Approches high-tech: On pourrait utiliser un écran tactile (sur la tortue?), ou une commande par smartphone + site web, mais ca serait en contradiction avec l'objectif annoncé "low tech en apparence pour n'effrayer personne". Donc non.
  • Approche par potentiometres: Chaque ordre est porté par un potar 36 positions (3 ordres+6 fonctions x 4 couleurs), ou bien par un potar 12 positions (6 ordres et 6 fonctions)+ un potard 4 positions pour les couleurs. Une autre variante serait d'avoir un potar pour les ordres/fonctions et une LED indiquant la couleur. Une seule molette peut être utilisée pour changer la LED de toutes les cases. Le problème majeur est que cette approche prend beaucoup de place, et je sais pas si un potard 36 positions est très simple à utiliser en pratique. Le prix reste également à évaluer.
  • Plugs physiques: chaque case de l'interface de commande est une petite prise dans laquelle on peut enficher un objet physique pour spécifier l'ordre. Ca peut être des briques Lego, avec la couleur de la brique indiquant aux humains l'ordre en question, et une petite résistance dedans permettant à la console d'obtenir la même information. Les plugs peuvent être plus petit que les potards vu qu'on a pas à les manipuler finement. En contrepartie, on risque de les perdre (ou de se les faire voler par les participants), ce qui impose de baisser le prix et le temps de fabrication au max des sucettes. Plusieurs approches sont possibles pour connecter les sucettes aux sockets du panneau.
    • Prise jack: on peut utiliser les connecteurs audio classiques. On en trouve par exemple sur mouser. Pour tenir la contrainte d'espace, il semble préférable de prendre des prises mono en 2.5mm. Ca revient grosso modo à 40c pour le male (la sucette) et 50c pour la socket sur le panneau. C'est relativement cher, et on maitrise mal la solidité du truc.
    • Prise RCA: c'est moins cher que des jacks classiques: 18c le male et 30c la femelle (c'est vendu pour 5000 cycles de branchement/débranchement). Mais à ce prix, y'a que le métal du male, pas de plastique du tout. On peut dire que c'est ce qu'on voulais, qu'on va repraper ou mouler le haut des sucettes, mais il ne faut pas perdre de vue que c'est une piece d'usure. En clair, j'ai peur que ce soit fragile.
    • Brique lego: une autre idée est de mettre la connectique (une résistance) dans une sorte de brique lego. Une approche légèrement hardcore est de partir d'une brique existante. Il semble cependant plus raisonnable de fabriquer une boite de la taille d'une pièce lego 4x2 (mais sans ergots) spécifiquement pour l'occasion, et la remplir de connectique ensuite. On peut par exemple mettre des ergots de pile AA dedans (13c la paire). Si la brique a une ptite séparation à 0.1mm du bord, on peut glisser l'ergot de la pièce dedans avant de la souder+coller à chaud. Pour la socket, deux possibilités:
      • On peut soit repraper la plaque qui va porter l'ensemble, et faire un T extrudé sur l'axe Y. Ensuite, on colle le même genre de connecteur que dans la brique, fixé sur le petit coté du T (la jambe du T fait contrefort pour éviter que ca casse). Ca va être pénible à repraper (le panneau risque de faire 25x25, ce qui est trop gros pour les repraps classiques par exemple)
      • On fixe un autre porte-pile sur le PCB (comme celui ci, 24c la paire), et on pose une parrure lasercutée par dessus pour protéger le PCB.
      • autre possibilité : on sépare la brique en deux compartiments, et on bouche chaque compartiment avec deux plots. la brique est posée sur le PCB, sur lequel deux pistes viennent sous les plots. Les briques sont maintenues en position par la planche lasercuttée posée sur le PCB.

Dans la section Actus ci-dessus, on trouve un proto reprapé de brique creuse format lego 4x2. Le rendu est propre, et c'est rapide à imprimer. quelques points de colle pour fixer les languettes sur les cotés + une résistance soudée au fond, et on est bons. On pourrait éventuellement modifier la forme à l'intérieur pour fixer la résistance au fond.


Les plugs ont l'avantage de leur inconvéniant : on risque de les perdre, mais on peut les utiliser un temps tout seul, sans les connecter du tout. Ensuite, on les branche sur une plaque de commande, puis on connecte cette plaque au reste du dispositif pour avoir une correction automatique de la solution. On va tenter cette approche pour voir.

proof of concept

Voir la page premier proto de base de controle + briques

Ressources

  • En plus du jeu dont on s'inspire directement (http://www.robozzle.com/) on peut citer LightBot qui est comparable: LightBot et LightBot 2. La principale différence est que le monde n'est pas plat dans LightBot: certaines cases sont plus hautes que d'autres et il faut sauter pour monter. De plus, éteindre les étoiles demande d'exécuter une instruction spécifique pour cela. Notons que la Java Learning Machine (joujou d'emptty) permet de jouer à LightBot.

Réalisation

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

Questions ouvertes/problèmes

Réponses aux critiques classiques

  • Est-ce qu'il ne serait pas plus approprié de directement faire une "vraie" tortue LOGO, et de voir ce jeu comme un "mode" d'utilisation ?
    • Non, car une véritable tortue logo serait bien plus complexe et chère à réaliser. Ca semble donc un peu over-enginering.
  • Est-ce que tout ceci ne semble pas un peu beaucoup / cher pour simplement dédramatiser l'acte de programmation ?
    • Peut-être que c'est complexe pour un objectif finalement limité, mais on trouve ca fun et on a envie de le faire :) Quant au prix, il est un peu tôt pour en parler, mais il est probable qu'on trouve le soutien de partenaires en temps voulu (comme l'INRIA). De plus, la ligne éditoriale "low tech apparent" devrait aider à mitiger ce problème.
  • Est-ce que ca sera efficace en pratique pour faire passer le message ciblé?
    • Bah on est en phase préliminaire pour l'instant. On va tâcher de faire en sorte que oui, mais on peut pas répondre pour l'instant.


Etat d'avancement

Macro planning

L'une des difficultées de ce projet est qu'il est en fait composé de trois sous-projets relativement complexes chacuns. Pour avancer malgré tout, on va se concentrer pour l'instant sur le panneau de commandes. La tortue avance par ailleurs (par exemple au travers du projet shhhhield), et les dalles, meh on verra après.

On vise donc une v0.5 avec un panneau de commande fonctionnel pour jouer sur l'ordinateur, et ensuite, on réfléchira à une v1 avec les trois modules entièrement IRL (en plus ca laissera le shhhhield avancer).

  • finir d'envisager les éléments du panneau de commande
  • modéliser ce qui doit être reprapé, et fabriquer des protos mécaniques
  • acheter les pièces électroniques
  • faire un proto complet méca+elec
  • faire le soft de commande pour arduino interfaçant le panneau.
  • faire un démonstrateur logiciel qui mocke les deux autres composants

Prochaines actions/en cours

  • On est bloqués tant qu'on a pas les pieces électroniques

Résultats

Permet de capitaliser sur le travail effectué: l'utiliser, le reproduire, l'améliorer, ...