Le Thymio II est un robot à destination de l’éducation et de la recherche, conçu par l’EPFL [1] qu’on ne présente plus dans le monde de la robotique de pointe. Il est entièrement open-source et open-hardware.
Ses qualités sont telles qu’il a suscité l’engouement d’une communauté très active, à laquelle contribuent notamment des acteurs de premier plan tels que l’INRIA. C’est d’ailleurs grâce au prêt d’un de leurs exemplaires que j’ai pu explorer rapidement ses possibilités et vous livrer ici ce que j’en ai retenu. Merci à vous Thierry et Martine 😉
Rapide tour d’horizon
Pour citer un extrait du site de présentation :
L’objectif du projet Thymio II est de permettre au grand public d’accéder à la robotique par un robot programmable et riche en possibilités, afin de permettre l’exploration des technologies liées à la robotique.
Le résultat est un robot complet et bien pourvu en fonctionnalités, commercialisé aux environs de 100 Euros. Il laisse sur ce plan largement derrière lui la concurrence actuelle, et pour preuve il suffit de consulter la liste de ses capteurs et actionneurs :
- 5 capteurs de proximité infra-rouge en face avant
- 2 capteurs de proximité infra-rouge en face arrière
- 2 capteurs de proximité infra-rouge sous le châssis, en configuration suivi de ligne
- 1 accéléromètre 3 axes
- 1 microphone
- 1 récepteur de télécommande infra-rouge au protocole RC5
- 1 capteur de température
- 5 touches capacitives sur le dessus
A cela il faut ajouter :
- un haut-parleur
- 39 LEDs adressables, dont plusieurs bicolores et 2 RGB
- un lecteur de carte micro-SD
La connexion avec le PC utilisé pour la programmation est réalisée par câble USB. Ce même câble est utilisé pour recharger sa batterie, soit via le port USB du PC, soit via un chargeur mural standard pour téléphone.
Il est propulsé par deux moto-réducteurs CC commandés en vitesse.
Quelques petits détails sympathiques :
- aussi bien les roues que la carrosserie comportent des points de fixation compatibles avec les briques et axes de LEGO, permettant ainsi d’associer les deux outils pour des réalisations complexes
- il peut communiquer avec ses congénères en utilisant pour cela les capteurs infra-rouge des détecteurs de proximité
Tout cela est illustré par le schéma ci-dessous, emprunté au site Web.
Programmation du Thymio
Le Thymio est animé par un PIC24FJ128 16 bits. En utilisation standard, il ne se programme pas directement, comme par exemple les robots éducatifs à base d’Arduino, mais via un langage spécifique nommé Aseba, qui est compilé en byte code, exécuté par une machine virtuelle légère sur le MCU. Il faut noter qu’Aseba n’est pas propre au Thymio et est également utilisé sur d’autres robots analogues à vocation éducation et recherche : marXbot, hand-bot, e-puck, Elisa-3.
La caractéristique fondamentale d’Aseba est qu’il est réactif, autrement dit basé sur une approche événementielle. Point de duo setup/loop avec une programmation impérative conventionnelle, mais une série de handlers pour les différents événements impliqués. Ceux-ci couvrent un large éventail fonctionnel, dont :
- polling des différents capteurs (proximité, température, accéléromètre,...)
- changement d’état des boutons
- réception RC5
- réception via infra-rouge
- détection de choc (par traitement interne des signaux des accéléromètres)
- polling de la vitesse et du ratio PWM des moteurs
- timers
Cela ne nous intéresse pas ici, mais Aseba peut tirer parti des capacités multi-processeur de la machine hôte. Et dernier point (qui me séduit tout particulièrement ;)) : Aseba s’intègre très bien dans les architectures D-Bus et ROS. C’est y pas merveilleux ça ?
Les outils de programmation
Ils sont gratuits et open-source. Le site en propose deux :
- un environnement graphique (VPL pour Visual Programming Language)
- un IDE pour programmation textuelle en langage Aseba
Le premier est bien entendu destiné aux plus jeunes, et propose de manière très simple de définir l’ensemble de règles événementielles qui vont constituer la programmation du comportement.
Une règle basique est composée de deux pictogrammes, l’un représentant l’événement (ex : tel(s) capteur(s) de proximité a détecté un obstacle), l’autre l’action à déclencher (allumer une LED, modifier les vitesses des moteurs).
Une version avancée de la règle permet d’ajouter une forme de condition au sélecteur d’événement sous forme d’un filtre qui teste un état. La notion d’état est implémentée par un vecteur de 4 booléens, ce qui comme vous l’aurez calculé rapidement donne 16 états possibles. Une des actions possibles est de modifier ce vecteur d’état.
L’environnement VPL génère en réalité le code Aseba correspondant, qu’on peut récupérer dans l’IDE Aseba pour le reprendre et le compléter.
Le langage Aseba
Concernant la programmation Aseba, le plus simple est d’en donner un extrait, tiré du site Web :
onevent buttons
if button.forward==1 then
motor.left.target=200
motor.right.target=200
end
if button.center==1 then
motor.left.target=0
motor.right.target=0
end
if button.backward==1 then
motor.left.target=-200
motor.right.target=-200
end
if button.left==1 then
motor.left.target=-200
motor.right.target=200
end
if button.right==1 then
motor.left.target=200
motor.right.target=-200
end
Cet extrait illustre l’écriture du handler d’un événement (buttons en l’occurrence). La structuration est assez simple : le handler débute par sa clause onevent et se termine à la clause onevent suivante (ou la fin du source).
La commande des moteurs est faite en donnant la vitesse cible via la propriété target. Les différents identificateurs (button.left, motor.right,...) représentant les constituants manipulables du robot sont pré-définis dans la bibliothèque Aseba pour le Thymio, automatiquement et implicitement importée dans le programme.
Un corollaire de l’architecture événementielle du langage est l’absence des attentes synchrones (fonctions sleep ou delay présentes dans la plupart des environnements). La raison est simple : une attente de ce type, c’est le mal absolu dans un environnement de type micro-contrôleur, car point de multi-thread ici pour laisser au processeur la possibilité de faire autre chose pendant la pause (par exemple gérer la communication avec un autre protagoniste).
Comment on s’en sort ? En utilisant les deux timers mis à disposition, et les événements timeout associés. De cette manière, c’est le noyau exécutif qui s’occupe de faire autre chose (gérer les capteurs et les actionneurs par exemple) entre temps. Si on fait le bilan, on se retrouve en définitive avec un contexte multi-tâche de manière transparente. Pas mal pour un micro-contrôleur :)
Je vais arrêter ici de reproduire les informations disponibles sur le site Web, ayant fait le tour de ce qui a le plus retenu mon attention. Il est abondamment documenté et illustré, et je vous engage à aller en étudier le contenu.
Un exemple de code
Pour illustrer tout ceci, vous trouverez ci-après le programme que j’ai écrit pendant mon voyage initiatique avec le Thymio. Il implémente un suiveur de ligne avec détection d’obstacle et auto-calibration au démarrage :
- démarrage et arrêt via utilisation des boutons
- analyse du sol au départ pour définir les seuils blanc/noir utilisés pour la détection de la ligne
- suivi de la ligne avec arrêt si obstacle détecté sur la trajectoire
- attente d’un signal sonore pour repartir
- si obstacle toujours présent, exécution d’un demi-tour et reprise du suivi de ligne
- si voie libre, reprise du suivi de ligne dans la même direction
- si robot décollé du sol et tourné à la verticale, arrêt complet
Le format de fichier Aseba est en réalité un document XML contenant :
- la déclaration des constantes
- le code des handlers d’événements (élément node du document)
Mes impressions
En préambule des propos qui suivent, je tiens à préciser qu’ils n’engagent bien entendu que moi et ne sauraient constituer un quelconque jugement de valeur du produit et des outils qui l’accompagnent. Il est important également de garder à l’esprit que certaines de ces réactions sont influencées par mon bagage et mon expérience en termes de programmation, qui peuvent fausser l’évaluation car n’étant peut-être pas représentatifs de la population cible typique du Thymio et de son éco-système.
Le Thymio
Ce petit robot sympa et coloré m’a conquis. Il cumule les atouts d’être richement doté en équipements, et d’avoir un look simple, mais sypathique. Nul doute qu’il saura conquérir aussi les plus jeunes, grâce à la palette de comportements qu’il propose.
Il suffit d’ailleurs de faire un petit tour de la galerie de projets pour y découvrir des utilisations pour le moins originales, et en tout cas impressionnantes. J’ai par exemple été emballé par le projet Barcode LightPainting, qui ne fait rien de moins que générer des images avec des Tymios utilisant une technique qui m’a rappelé les bons vieux écrans vectoriels Tektronix 4010 qui équipaient les stations CAO dans les années 70-80.
J’ai pu cependant noter un petit défaut de conception, qui a pour effer de rendre le micro [2] utilisable dans peu de situations en définitive. Il faut en tout cas l’oublier dès que le robot est en mouvement. En effet les vibrations des moteurs engendrent un niveau proche de la saturation, et on ne peut donc pas s’en servir pour par exemple arrêter le robot avec un claquement de mains. Par contre ça marche pour le faire démarrer.
Un montage sur amortisseur de vibrations aurait peut-être amélioré les choses, au prix d’une plus grande complexité mécanique et donc d’un prix sans doute moins attractif.
Le paradigme Aseba
En tant que développeur logiciel ayant vu et utilisé pas mal de choses depuis l’année 1976, date de mon premier contact avec un clavier d’ordinateur, je ne peux qu’en apprécier l’orientation. C’est clean par nature, et change des plats de spaghettis qu’on rencontre (trop) souvent avec une approche plus classique (genre setup/loop et consorts).
Quant à savoir maintenant ce qu’il en est en termes de support pédagogique, tout dépend en fait quel est l’objectif recherché :
- initier à la logique roboticienne
- initier à la programmation
Objectif robotique
Dans le premier cas, il est clair que le choix fait par les concepteurs d’Aseba est en ligne. Et pour cause, ce sont des roboticiens de haut vol. Plus sérieusement, la logique réactive est exactement celle d’un robot autonome qui doit réagir à un contexte évolutif.
Il parait donc le plus logique d’exprimer le programme selon le même modèle. Il y a par conséquent une totale adéquation entre les paradigmes, et les électroniciens parleraient d’adaptation d’impédance ;) La difficulté à cependant ne pas sous-estimer est de parvenir à définir des règles ne présentant pas d’incohérences mutuelles.
L’autre aspect roboticien bien mis en lumière par Aseba est la notion d’état, qui fait partie des principes élémentaires utilisés en robotique. On se rend rapidement compte qu’on a besoin de cette approche pour pouvoir définir des réactions différentes à un même événement en fonction du contexte courant du robot. La mise en oeuvre au travers des filtres par état proposés dans le mode avancé de VPL présente cette technique d’une manière assez illustrative.
Objectif programmation
Si on s’intéresse maintenant à l’initiation à la programmation "standard", j’avoue être moins concaincu, surtout avec les plus jeunes. Lorsqu’on élabore la formalisation d’un algorithme (même sans prononcer ce terme), le reflexe prédominant est de raisonner à l’image de notre fonctionnement naturel, c’est à dire selon une succession d’actions élémentaires, succession la plupart du temps unique, l’homme n’étant pas multi-tâche par défaut [3]. Un effort intellectuel est donc nécessaire pour passer du domaine séquentiel au domaine événementiel.
Ce dernier point est d’ailleurs assez bien illustré par le cas de figure des attentes, évoqué plus haut. On constate que la logique séquentielle disparaît, puisqu’éclatée sur au moins deux handlers d’événement (celui qui lance le délai, et celui qui gère son expiration).
Au final, j’ai donc le sentiment que pour une initiation à la programmation en général, une interface graphique orientée time flow (ex : LEGO Mindstorms) est plus accessible car plus intuitive.
Pour conclure
Sur le plan matériel, le Thymio est à mon avis une petite révolution, car il présente un rapport fonctionnalités/prix imbattable et sans commune mesure avec les produits de la même famille, qui sont soit beaucoup moins bien dotés lorsqu’ils sont dans les mêmes prix (ex : le 3pi de Pololu, que j’aime bien par ailleurs), soit deux fois plus chers avec 3 fois moins de possibilités (ex : l’Arduino Robot, qui pour moi est une vraie mauvaise affaire)
Si vous faites la synthèse de mes impressions sur les outils de programmation, vous en retiendrez que selon les attentes les conclusions peuvent diverger, principalement du fait du choix du paradigme sur lequel Aseba est fondé. J’ai par ailleurs été déçu par l’environnement graphique, qui se montre un peu fastidieux à utiliser dès qu’on dépasse le stade des programmes de type "hello world". Son faible taux d’expressivité algorithmique par rapport à la surface graphique occupée et l’absence d’une fonctionnalité permettant de créer l’équivalent de sous-programmes [4] rendent très vite assez fastidieuse l’élaboration d’une logique un tant soit peu évoluée.
Mais alors, que fait-on pour nos jeunes recrues avides de découvrir les joies du logiciel et de ses bugs ?
Et bien on suit de très près la contribution de l’équipe INRIA Bordeaux, et plus précisément de David Sherman, qui a développé un plugin Scratch pour programmer le Thymio. Je ne l’ai pas encore essayé, mais ça fleure plutôt bon comme solution de repli. Cela fera probablement l’objet d’un nouvel article sur le Thymio. Pour ceux qui veulent en savoir plus en attendant, je vous engage déjà à visiter cette page.
A suivre...
Vos commentaires
# Le 27 janvier 2016 à 21:53, par Franck En réponse à : Thymio II
Bonjour, vue l’étude approfondie que vous avez faite sur ce robot je serais très intéressé de connaître votre avis sur la solution proposée par les kits makeblock ?
# Le 29 janvier 2016 à 00:46, par Eric P. En réponse à : Thymio II
Bonsoir,
Impossible d’émettre un avis digne d’intérêt sur ces kits car nous n’en avons jamais eu entre les mains. Si quelqu’un veut nous en donner un à tester, on veut bien 😉
Répondre à ce message
# Le 5 janvier 2016 à 19:03, par dchav En réponse à : Thymio II
Avez-vous testé le robot edison ?
# Le 5 janvier 2016 à 19:11, par Eric P. En réponse à : Thymio II
S’il s’agit de celui-ci, pas pour le moment.
Répondre à ce message
# Le 17 novembre 2015 à 16:34, par Okimi En réponse à : Thymio II
Il existe maintenant un nouvel environnement de programmation pour le robot Thymio appelé Blockly4Thymio. Plus simple, plus visuel, adapté au jeune publique. A retrouver sur www.blockly4thymio.net
# Le 17 novembre 2015 à 20:05, par Eric P. En réponse à : Thymio II
Ah voilà qui relance mon intérêt pour le Thymio :) On va tester cela dès que possible.
Répondre à ce message