Aspects de la programmation de Thymio en classe

Suite à un appel à projets, la délégation académique au numérique éducatif a équipé l’école Camille Hirtz de Strasbourg d’un pack de 6 robots Thymio. Nous les avons expérimentés dans toutes les classes du cycle 3 actuel, soit les CE2, CM1 et CM2.

La technique

Il s’agit de la première génération de robots, qui se branchent sur la prise USB de l’ordinateur. Nous avons mis à jour le firmware et installé le logiciel ASEBA Studio version 1.5.4 sur chaque poste utilisant le robot. Les ordinateurs fonctionnent sous Windows 7.

Nous avons essayé le site Blockly for Thymio mais malheureusement, nous ne sommes pas parvenus à le faire fonctionner sur nos robots. Nous avons donc utilisé uniquement l’interface Aseba Studio, à télécharger sur le site officiel.

Le logiciel Aseba Studio contient le pilote du robot et propose trois interfaces:

  • l’interface texte, qui ressemble au langage BASIC;
  • l’interface VPL, un langage graphique sous forme d’icônes
  • l’interface Blockly, plus récente, que nous avons utilisée avec les élèves.

Blockly est une interface graphique mise au point par Google. Les structures de programmation se présentent sous forme de pièces de puzzle qui s’emboîtent. Les instructions sont très claires. L’utilisation de Blockly ne se limite pas à Thymio: on peut l’utiliser sur de nombreux sites. Citons l’excellent code.org., qui utilise Blockly, mais aussi Scratch, qui utilise un système différent (en Flash) qui ressemble fort à Blockly. Ainsi, en choisissant Blockly nous pouvons diversifier les approches.

Branchements sur USB : attention

Nous avons rapidement rencontré une difficulté : si le câble USB est débranché, ou si on éteint le robot, la fenêtre contenant le programme sous Blockly en cours de développement se ferme, sans autre forme de procès ! Ce fonctionnement est pour le moins gênant; aucun développeur de programmes n’accepterait de travailler dans de telles conditions.

Certes, au départ, cette contrainte n’est pas vraiment gênante, puisque les élèves peuvent faire leurs recherches avec le robot branché. Mais, plus tard, nous prévoyons des difficultés, lorsqu’il faudra tester le robot en autonomie sur un circuit. Dans ce cas, il faut surtout ne pas oublier d’enregistrer le programme avant de débrancher le robot ! On peut ainsi perdre des heures de travail sans le moindre avertissement. Les aller-retour entre l’expérience et la programmation seront hélas bien plus complexes.

Espérons que ce défaut sera corrigé dans de prochaines versions.

Spécificités de la programmation sous Aseba Studio avec Blockly

Les instructions sont non bloquantes

Thymio fait d’abord penser à l’antique tortue Logo, qui officiait dans les écoles dans les années 80. Mais il faut se méfier des analogies, elles sont trompeuses: le robot Thymio est bien plus sophistiqué; il dispose de capteurs permettant de détecter l’environnement, de roues et de LEDS permettant de se déplacer ou de se signaler. Sa programmation aussi est bien différente, du moins avec Aseba Studio.

Dans le modèle algorithmique classique, celui du LOGO, les instructions du programme sont  bloquantes: elles prennent le temps de s’exécuter, et rendent la main au programme uniquement lorsqu’elles sont terminées.

Ainsi, les instructions suivantes tracent un carré:

carre

 

source: code.org

L’instruction « avancer de 100 pixels » ne sera terminée que lorsque la tortue aura avancé. Tant que l’instruction n’est pas terminée, le programme attend. Puis, l’instruction suivante, tourner à droite de 90 °, prend le relai. Là encore, le programme attend qu’elle soit terminée. Le fait de répéter 4 fois la structure permet de tracer un carré.

Ce modèle n’est pas disponible nativement sous ASEBA Studio. En effet, les instructions sous ASEBA ne sont pas bloquantes. D’ailleurs, sous Blockly pour Thymio, il n’y a pas d’instruction « avancer » mais bien « commencer à avancer à la vitesse de … ». Autrement dit, lorsque cette instruction est effectuée, les moteurs sont démarrés avec une énergie correspondant à la vitesse indiquée, puis l’instruction rend la main alors que les moteurs continuent de tourner.

Que vont produire les instructions ci-dessous ?

repetition1Comme les instructions sont non bloquantes, la première instruction sera bien lancée, mais elle sera immédiatement annulée par la seconde, qui porte sur les mêmes moteurs. Notre robot tournera  vers la droite, et comme nous n’arrêtons pas les moteurs, ce mouvement de rotation continuera jusqu’à ce qu’on arrête le programme. Mais nous ne verrons pas avancer le robot en ligne droite, car il n’a pas eu le temps de le faire !

Dans ce cas là, il est inutile de répéter 4 fois le jeu d’instructions: c’est finalement la dernière instruction lancée qui sera réalisée. Plus généralement, nous n’avons jamais utilisé l’instruction « répéter » dans aucun des défis proposés aux élèves. Cette instruction sert surtout à parcourir des tableaux; elle peut aussi servir dans une simulation complexe d’instructions bloquantes réalisées à l’aide de procédures.

Si on veut tracer un segment, ou tourner d’un certain angle, il faut donc interrompre le déplacement au bout d’un certain délai. L’utilisation d’un ou deux minuteurs -fournis- est indispensable. La programmation sous Thymio peut donc devenir complexe très rapidement. Heureusement, la puissance de la programmation événementielle permet tout de même de simuler des comportements complexes avec très peu d’instructions.

La programmation est événementielle

Thymio dispose d’un grand nombre de capteurs. Chacun d’entre eux peut produire un évènement que l’on peut intercepter par programme.

Ce type de programmation est moderne: c’est ainsi que fonctionnent tous les systèmes d’exploitation graphiques actuels.

Les élèves sont donc invités à programmer les réactions du robot pour différents événements:

bouton_centralNous avons été surpris de voir avec quelle facilité il est possible de programmer des comportements complexes, avec peu d’instructions, et sans même utiliser des variables ! Voici par exemple une simulation d’un comportement « explorateur » : le robot doit arriver à se déplacer à l’intérieur d’un couloir en S. Cette programmation utilise l’événement « lorsque le capteur XXX détecte quelque-chose (ou) rien » et l’instruction « commencer à rouler en XXX à la vitesse VVV », qui sont bien entendu utilisées plusieurs fois ! Nous y avons ajouté quelques effets avec les LEDS et des bruitages, mais ça c’est juste pour le plaisir.

Le programme est ici, sans les couleurs et les effets sonores.Avec la gestion de ces 4 évènements, Thymio arrive déjà à se débrouiller sur un parcours continu avec des virages assez larges.

explorateurSimpleDes élèves chercheurs

L’intérêt de l’algorithmique en général, et de la programmation de Thymio en particulier, est que le résultat des programmes peut être évalué immédiatement, par l’observation du comportement du robot. Pas besoin de validation par le maître, les élèves sont confrontés au résultat de leur programme… qu’il corresponde aux attentes… ou non !

Pour favoriser le travail de recherche, nous présentons l’activité sous forme de « défis ». On montre un film, qui tourne en boucle, dans lequel l’acteur principal, le robot, se comporte d’une manière particulière. A côté de ce film, on affiche les structures utiles au programme: événements, actions… bien sûr dans le désordre. Aux différentes équipes de reconstituer le comportement, le plus exactement possible. En présentant les instructions utiles, on limite les risques de se perdre et on favorise le travail d’ordonnancement. La recherche est donc guidée, mais laisse suffisamment de place à l’expérimentation et au tâtonnement.

Ensuite, après quelques défis de ce genre, de difficulté croissante, on peut lancer un « super défi », comme le déplacement sur le parcours de notre vidéo. Là, on montre le comportement du robot, mais on ne donne aucune indication sur les instructions; les élèves doivent se référer au corpus déjà appris.

Nous n’avons pas présenté les  défis comme une course, mais comme une activité à réussir collectivement: le défi est considéré comme réussi lorsque tous les groupes l’ont résolu. Pour atteindre cet objectif, les élèves ont le droit de se déplacer, de communiquer entre les groupes, de s’entraider.  Le rôle de l’enseignant est d’aider les élèves en difficulté à comprendre les phénomènes; mais pas d’aplanir ou de prévenir ces obstacles ! Les élèves qui ont terminé un défi peuvent aider ceux qui ont des difficultés… et ces derniers ont aussi le droit d’aller chercher des explications auprès d’un groupe plus en avance.

Les premiers résultats sont prometteurs; les élèves  effectuent la recherche avec motivation et plaisir. Selon nos observations, les groupes se lancent dans leur travail sans concertation avec les autres groupes. Ceux qui sont en difficulté ne profitent pas spontanément de la liberté de se déplacer et d’aller voir les camarades. A l’enseignant de les y inciter, ou de proposer aux élèves en avance d’aider les autres. Cette activité de recherche offre donc l’occasion de développer d’autres manières d’apprendre -à travers les relations tissées entre les élèves- et de modifier ainsi leur rapport au savoir. Nous allons donc bien au-delà du simple apprentissage d’un langage de programmation.

À télécharger : la présentation Powerpoint (fichier ppsx) contenant les premiers défis (185Mo – le fichier est lourd car il intègre les vidéos.) Pour lire ce fichier, il faut la visionneuse Powerpoint. Si vous constatez qu’il manque des animations dans notre présentation, c’est peut-être parce que votre visionneuse n’est pas à jour.

Vous naviguez dans