Latest revision as of 10:38, 22 February 2015

Actus

La principale caractéristique de ce ptit projet est d'alterner les longues périodes de mort clinique avec les petits pics d'activités super temporels. Et pourtant, il avance encore (des fois) !

Le prochain item sur la TODO est un proof of concept - sous la forme de shield arduilol quick n dirty - du module de programmation par briques. Stay tuned !

Un ptit teaser d'une brique représentant une instruction de l'interface tangible (pour donner une idée des dimensions qu'on veut manipuler), et la version 1.1 du pré-prototype de shield qui pourra accueillir 6 briques. On va l'utiliser pour affiner notre design de brique et vérifier que c'est pratique sous la main avant de chercher à faire un shield pouvant accueillir la quarantaine de briques nécessaire pour jouer vraiment.

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... On associe également trop souvent "compréhension de la programmation" à "écrire (voire pisser) du code", à tord !

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. En se passant de clavier, de lignes de code, on rend accessible aux personnes ne sachant pas lire (et encore moins lire l'anglais).

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

Enfin, vu la finalité de ce projet, la qualité de la doc (de construction/technique, mais aussi manuel utilisateur, fiches d'activités, etc) est primordiale !

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

Version LOGO

Il s'agit ici de reproduire une tortue LOGO : il s'agit d'un robot doté d'une cinématique type char, auquel on donne des instructions simples de déplacement. Il est par ailleurs capable de dessiner, en laissant une trace de son passage.

Il est tout à fait approprié d'utiliser une surface effacable (type Velleda) pour pouvoir faire plusieurs essais, mais ce n'est pas obligatoire.

L'interface de contrôle de ce robot peut être de plusieurs types:

• pilotage par logiciel sur ordinateur (pas très intéressant...)
• pilotage par pupitre de commande (voir ci après)
• pilotage par lecteur de cartes (voir ci après)

Version Turzzle

Le principe de ce jeu est basé sur un petit robot 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. Dans le jeu d'origine, 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.

Pour pouvoir jouer à ce jeu, il est nécessaire de construire des dalles modulaires, à assembler en fonction des différents niveaux.

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 disparaissent 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 (presque) raisonnable.

Module Tortue

On s'inspire de la tortue LOGO d'il y a quelques dizaines (glups) d'années, dont on réalise une version actualisée.

La tortue est un petit robot doté d'une cinématique de déplacement "type char". Elle est capable d'exécuter des déplacements simples: avancer de x milimètres, tourner (dans un sens ou l'autre) de y°, lever ou baisser le stylo.

Elle dispose par ailleurs de plusieurs interfaces, permettant de l'utiliser dans différents contextes. Elle est autonome en énergie et en contrôle commande : pas de fil à la patte ! Elle est suffisament légère pour être manipulée et transportée, tout en étant assez robuste pour survivre à des sessions de jeu avec des enfants.

Il est envisageable à ce stade d'adapter des modèles de robot du commerce à nos besoins ; de trouver un design OSHW et de le modifier, voire d'en créer un de toutes pièces.

Enfin, son cout de revient reste raisonnable pour être accessible.

Pré-étude

{Elements de décision pour le design}

• 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 ou bien PAP
  • carte arduino/version customisée ou plus patator si nécessaire
  • capteurs de ligne (par exemple CNY70, ou équivalent en moins cher)
  • de quoi communiquer avec la console de commandes: liaison radio (Xbee, wifi, bluetooth, "custom")?
  • de quoi communiquer avec les dalles: IR? RFID?
  • peut etre capteur de couleur (http://www.sparkfun.com/products/10656 par exemple, à tester)
  • logement pour piles AA/9v ou batteries

Coté réalisation, on pourrait patir d'une base existante (à trouver), ou bien faire une conception OSHW simple, utilisant des pièces lasercuttées et d'autres imprimées 3D.

proof of concept

A priori, on va commencer par chercher des projets existants (du commerce, voire mieux, OSHW). Si aucun ne correspond aux critères, il faudra attaquer la conception de cette bestiole nous même.

Module lecteur de cartes

{descriptif de ce module: son role, ses objectifs, ...} Ce module permet de donner une succession d'ordres à la tortue, qu'elle mémorise au fur et à mesure, à l'aide de cartes qu'on manipule directement. Ce mode de fonctionnement est directement inspiré de la tortue LOGO d'époque.

Pré-étude

{Elements de décision pour le design} La tortue d'origine utilise des cartes perforées, avec 6 emplacements. On pourrait utiliser des cartes lasercuttées (ou faites à la main), ou encore, utiliser simplement des cartes imprimées, avec des ronds noirs ou blancs. On peut envisager d'utiliser le format carte de visite, assez simple à faire fabriquer, avec plusieurs modèles pré-établis et des cartes 'vierges'.

Coté électronique, on a simplement besoin de pouvoir lire les N positions, et de transmettre l'information aux autres systèmes (directement la tortue, un ordinateur... selon les cas d'utilisation). Une simple arduino uno customisée (ou un shield) est à même de remplir ce rôle. Coté mécanique, on peut concevoir assez facilement des pièces imprimées/lasercuttées pour faire un lecteur de cartes de ce type.

proof of concept

Quelques crobards ont été réalisés : yapluka en faire des fichiers de design et à fabriquer. Affaire à suivre !

Module Dalles

{descriptif de ce module: son role, ses objectifs, ...} Il s'agit de dalles pour réaliser des niveaux de turzzle. On aimerait avoir une dimension de 25x25cm environ (voire moins, selon la taille de la tortue !) pour obtenir une taille totale raisonnable.

On peut imaginer plusieurs types de dalles:

• des dalles entièrement passives (eg, plaques de couleur qu'on assemble), ce qui implique que toute l'intelligence/gestion du niveau se fait dans la tortue
• des dalles avec information, par exemple tag RFID, permettant au robot de les différencier
• des dalles actives, avec information/communication avec le robot, et feedback (lumineux) pour matérialiser le niveau.

Pré-étude

{Elements de décision pour le design} On a peut être envie de réaliser différents types de dalles:

• purement passif (eg, on imprime dessus mais la tortue doit "tout faire")
• avec identification (type tag RFID intégré: la tortue peut retrouver ses petits en cours de route)
• active, avec microcontrolleur intégré, leds, communications...

• 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:
  • une inspiration du hw du zombie badge du NYC : http://www.buildbrighton.com/images/7/7c/BuildBrighton_badge_instructions-web.pdf
  • mécaniquement, assemblage comme des pièces de puzzle
  • marquage de lignes (croix noires) pour aider au déplacement de la tortue (peinte, "imprimées" au laser, scotch d'électricien, ...)

Tous les éléments structurels seraient à fabriquer en MDF/PMMA 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.

proof of concept

A voir ultérieurement... on va probablement partir du du bête MDF de quelques mm d'épais, découpé... bha, à voir, peut être à la main :)

Module pupitre de commande

Il s'agit ici d'une surface de contrôle, ou l'on peut paramétrer le fonctionnement de la tortue (la programmer, en fait). Plusieurs approches sont envisageables pour concrétiser cela.

pré-étude

Du point de vue de l'utilisateur, 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. A priori: non.

• 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 ; même si elle date un peu, et qu'en fait, pour commencer, on va plutot faire un bête shield arduino avec 6 emplacements (suffisant pour valider le principe).

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 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. De notre expérience personnelle, LOGO est un bon terrain de jeu pour apprendre en faisant les concepts clé de la programmation...

Etat d'avancement

Macro planning

L'une des difficultées de ce projet est qu'il est en fait composé de plusieurs sous-projets relativement complexes chacuns. Pour avancer malgré tout, on va se concentrer pour l'instant sur le pupitre de commande, qui est l'élément central de l'approche. Pupitre de commande:

• finir d'envisager les éléments du panneau de commande, eg la partie purement UX design
• 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

Ensuite, on pourra attaquer le lecteur de cartes:

• modélisation des pièces à lasercutter/repraper
• design électronique
• soft embarqué
• prototypage de cartes de commande
• soft d'interfacage à peu près exploitable/démonstrateur qui mocke le reste du système

Coté robot:

• faire une étude de l'existant, pour voir si on peut acheter/reproduire tout fait, forker de l'existant, ou s'il faut repartir de zéro.

Prochaines actions/en cours

• proto de shield pupitre en cours de réalisation pour valider le principe des briques: connectique, mesure de résistances.
• Prototypage lecteur de cartes
• State of ze art robot tortuesque

Résultats

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