Club robotique de Sophia-Antipolis

Accueil > Essais produits > Robots et kits > GoPiGo3

GoPiGo3

lundi 9 juillet 2018, par Eric P.

Cet article présente un banc d’essai du GoPiGo3, kit développé par Dexter Industries, permettant de monter un robot éducatif contrôlé par une Raspberry Pi.

JPEG - 783.8 ko

Ce kit nous a été généreusement offert par Génération Robots, avec qui nous avons développé depuis plusieurs années une relation de collaboration suivie. Je leur dois d’ailleurs mes plus plates excuses, car cet article aurait dû être rédigé bien plus tôt, sa réception remontant à l’été... 2017. La préparation des divers événements et manifestations publics, à laquelle s’est ajoutée une forte charge de travail au niveau professionnel n’ont pas laissé suffisamment de temps libre pour faire les choses correctement à cette époque.

Un bien pour un mal cependant, car le retard a du coup permis d’utiliser la toute dernière version de la distribution adaptée fournie par Dexter, le fabricant du GoPiGo. Si je dis que c’est un bien, c’est parce que les quelques essais rapides que j’avais faits de la version disponible à l’automne 2017 (j’avais quand même commencé à travaillé sur cet article) ont été tout sauf convaincants. Disons que ça laissait une désagréable impression de produit pas totalement fini.

Et pourtant le site Dexter affiche haut et fort la formule suivante sur la page de présentation du GoPiGo :

One of the best robotics kits you can buy, especially for teachers. [1]

Excusez du peu :) Voyons ce qu’il en est réellement et si le tir a été corrigé depuis la première prise de contact de l’an dernier...

 Le kit

Il s’agit du premier kit de la gamme, dénommé "Base Kit". Il existe des kits plus fournis, incluant entre autres un capteur de distance et son servo d’orientation, ainsi que la carte SD préchargée avec la distribution DexterOS (dont nous parlerons un peu plus loin), ainsi qu’un bloc secteur et d’autres accessoires. A noter que le dongle Wifi proposé n’est plus vraiment utile avec la Raspberry3, puisqu’elle intègre la connectivité Wifi et Bluetooth en standard.

JPEG - 1.1 Mo

Qu’avons-nous dedans ?

  • deux plaques de châssis en acrylique transparent, protégées par un papier adhésif brun qu’il est préférable de retirer avant l’assemblage,
  • deux moteurs avec réducteurs,
  • deux roues et leurs pneus,
  • un ball caster,
  • un boîtier de piles et une sangle Velcro pour le fixer,
  • une carte électronique à connecteur sur la RaspberryPi, incluant entre autres les drivers moteurs et la gestion de leurs encodeurs,
  • de la visserie et des pièces mécaniques pour la fixation des moteurs et l’assemblage du châssis.

Comme indiqué sur la boîte, il ne contient pas la RaspberryPi (ni les piles ou batteries).

Dexter ajouté au kit un petit tournevis. C’est gentil, mais très sincèrement, gardez-le comme souvenir et utilisez quelque chose de meilleure qualité, le mien ayant et tendance à s’émousser très vite à l’usage [2].

Pensez à vous munir d’une pince très fine ou d’une pince à épiler pour accéder à la carte SD une fois le robot assemblé, car les câbles de moteurs viendront vous empêcher d’y accéder facilement avec les doigts.

Les moteurs sont équipés d’encodeurs, ce qui est rare dans ce genre de kit et mérite d’être souligné. C’est bon présage quant au contrôle des mouvements qu’on peut en attendre, et on pourra donc faire autre chose que du suivi de ligne ou du sumo.

JPEG - 524.6 ko

Le capteur est constitué d’un aimant fixé en sortie de moteur et de deux capteurs à effet Hall. Nous passerons sur l’immobilisation de ces derniers à grands renforts de colle thermo-fusible. Ca fait un peu sourire, mais ne soyons pas trop difficiles pour ce genre de kit. Le point positif à en retenir est que le montage de l’encodeur au niveau du moteur, et non des roues comme sur un grand nombre de kits offrant un feedback de la propulsion, fournit une précision de mesure bien supérieure, et donc des déplacements bien plus précis.

Le prix

En date de rédaction, ce kit est vendu 109 Euros par Génération Robots (cf descriptif). Si on y ajoute :

  • la RaspberryPi (environ 40 Euros),
  • sa carte SD (environ 14 Euros pour une 16G [3] en grande surface)
  • 4 batteries rechargeables au format AA (environ 14 Euros en grande surface pour des modèles de qualité correcte offrant une capacité confortable) nous arrivons à un budget total de quasiment 180 Euros. Assez rapidement vous y ajouterez quelques capteurs (suivi de ligne, mesure de distance,...) pour réaliser des choses un peu plus intéressantes que des figures géométriques par déplacement programmés), comptez sur une enveloppe dans les 250 Euros.

 Montage

Il est assez facile, et très bien détaillé dans la notice de montage en ligne. D’accord, elle est en Anglais, mais le nombre de photos permet de s’en sortir même sans lire le texte. Petit avertissement cependant : le montage demande néanmoins une certaine habileté manuelle, et il n’est pas à la portée d’un jeune enfant sans l’aide d’un adulte (sauf génie de la mécanique précoce).

La procédure de montage décrite comporte cependant quelques erreurs, laissant supposer qu’elle ne reflète pas un montage réel, mais des prises de vues destinées à illustrer une notice "théorique".

Fixation des supports des moteurs

La première erreur porte sur la fixation des équerres de montage des moteurs sur le châssis. Si vous procédez comme expliqué et illustré, vous aurez de fortes chances de ne pas pouvoir monter les moteurs ensuite. En effet, la notice indique d’engager les vis du côté de la plaque acrylique, et donc de placer les écrous du côté de l’équerre, c’est à dire du côté où sera le moteur ensuite :

JPEG - 37.4 ko

Le problème est qu’en fonction de la tolérance de longueur des vis fournies, celles-ci peuvent s’avérer trop longues et venir buter sur le moteur, empêchant ensuite sa fixation. C’était en tout cas mon cas.

Il est donc préférable de monter ces vis dans l’autre sens, c’est à dire la tête du côté de l’équerre, et l’écrou du côté de la plaque acrylique, comme le montre la photo ci-dessous :

JPEG - 705.5 ko

A noter que Dexter a dû rencontrer le même problème que moi et procéder comme je le conseille, car une des photos présente dans une étape suivante les montre montées comme suggéré :

JPEG - 46.6 ko

Dommage qu’ils n’aient pas corrigé cette étape de l’assemblage dans la notice de montage :/

Fixation des moteurs sur leurs supports

Ici encore l’erreur trahit le fait que les explications ne sont pas directement issues d’un montage réel. En effet, la notice indique d’introduire les vis de fixation du moteur sur son support par le côté moteur :

JPEG - 81.1 ko

Si on suit ces indications, on se rendra compte au moment de fixer le second moteur en place qu’il est impossible de serrer la vis la plus proche du châssis, du fait de l’angle que fait le tournevis avec sa tête.

Il faut donc engager la vis du côté de l’équerre, et placer l’écrou du côté moteur. Aucun problème pour le serrage, puisque la tête de vis se trouve alors librement accessible sur le côté extérieur du robot :

JPEG - 533.9 ko

La suite

Le reste du montage n’appelle pas de remarque particulière et on parvient au résultat final sans encombre :

JPEG - 534.2 ko

Ne vous inquiétez pas si le connecteur femelle de la carte GoPiGo3 ne vient pas en butée du connecteur mâle de la RaspberryPi, le contact est suffisant quand même :

JPEG - 846.1 ko

  Premières impressions concernant le matériel

Le résultat est un châssis plutôt robuste et stable.Il offre de plus pas mal d’espace pour y fixer diverses extensions (capteurs, mécanismes,...). A ce sujet il y a d’ailleurs une bonne surprise... et une mauvaise.

La bonne surprise est que les perforations présentes en grand nombre sont au format LEGO.

JPEG - 790.4 ko

Il est donc facile d’étendre la structure avec des assemblages LEGO, ce qui ouvre un champ de possibilités immense. Etant un fan des LEGOs par ailleurs, c’est donc un très bon point.

La mauvaise surprise est que Dexter a un peu oublié de prévoir des trous de fixation simples d’emploi pour d’autres accessoires.

J’ai par exemple fait l’emplette de divers capteurs de la gamme, y compris des supports de montage en acrylique pour les installer sur le GoPiGo. La seule option est d’utiliser les minuscules vis D2 et les fentes de largeur correspondante dans les plaques du châssis. D’une part ces vis sont infernales à manipuler même en tant qu’adulte rompu aux travaux de précision, alors imaginez le problème pour un enfant de 10 ans. Sans compter qu’elles vont très rapidement être perdues dans les salles de classe.

OK, on peut toujours recourir à la "solution" à base de Patafix comme ici pour installer rapidement un détecteur d’obstacle :

JPEG - 559.1 ko

Reconnaissez que ce n’est pas du tout idéal. D’autant plus qu’il n’y a pas non plus de support adapté pour ce détecteur, les montures acryliques étant prévues pour des accessoires de la série Grove.

On peut y arriver en trichant, c’est à dire en utilisant les trous prévus pour fixer le capteur pour y insérer une vis de fixation au châssis, et la fente allongée de l’autre branche de l’équerre pour exploiter les trous présents sur le capteur :

JPEG - 589.1 ko

Là encore, allez faire faire ce type de gymnastique à tout un groupe de jeunes.

Le plus fort est illustré par la documentation de l’installation du servo destiné au capteur de distance à ultra-sons :

JPEG - 71.1 ko

Ils ont utilisé une vis auto-foreuse qui passe au travers d’une fente de la plaque acrylique et vient se serrer dans le trou d’extrémité du palonnier du servo. Je ne donne pas 5 minutes de durée de vie à un tel bricolage, sachant que ce robot est destiné à être mis entre le mains de très jeunes puisque Dexter cible le marché de l’éducation.

Si on veut équiper le GoPiGo de certains des accessoires proposés, il faudra inévitablement retoucher les plaques du châssis et probablement les montures de ces accessoires pour pouvoir disposer de possibilités décentes au niveau de leur fixation. Certes la diffusion croissante d’imprimantes 3D, y compris dans les établissements scolaires, permettra de réaliser assez facilement du sur-mesure, mais pour ce qui est du kit prêt à l’emploi, il faut reconnaître que ce n’est pas idéal.

Dans la même série, les accessoires de montage du capteur de suivi de ligne demandent à être adaptés avant utilisation. Deux rondelles en acrylique sont fournies pour sans doute éviter que le serrage des colonnettes métalliques n’abîme le circuit imprimé, ou bien pour placer le capteur à la bonne distance du sol. Toujours est-il que ceux qui en ont décidé du diamètre ont oublié de vérifier ce qu’il y avait sur le PCB à cet emplacement. Manque de chance, dans les deux cas se trouvent des composants CMS et des soudures de connecteurs :

JPEG - 705.2 ko
JPEG - 694.2 ko

Le rondelles ne tombent du coup pas à plat, ce qui a deux conséquences gênantes :

  • elles empêchent les colonnettes d’être perpendiculaires au PCB
  • en cas de serrage abusif des vis, elles risquent d’endommager les composants pincés par les pièces.

Il faut donc les retoucher pour en adapter la forme afin de de venir écraser personne :

JPEG - 1 Mo
JPEG - 575.6 ko

Le problème : qui va faire cela dans le cadre de l’utilisation nominale du kit ? Probablement personne, ce qui va inévitablement conduire à des dégâts à plus ou moins long terme.

Tout cela finit par devenir agaçant, car si on veut faire les choses proprement, il faut passer du temps à rectifier les conséquences d’un manque de soin apporté à la conception des produits. Si encore il s’agissait d’articles à 2 ou 3 Euros port inclus en provenance de Chine, passons. Mais là on parle de capteurs à 25 Euros dans le cas du suiveur de ligne. A ce prix-là on est en droit d’attendre une qualité un cran au-dessus.

Pour conclure ce premier volet de la prise en main, je dirais : "peut mieux faire". La qualité est dans l’ensemble bonne, mais cette impression est gâchée par le sentiment d’un produit dont la conception n’a pas été suffisamment soignée dans les détails.

Voyons maintenant ce qu’il en est de la partie logicielle.

 Le logiciel

Nous allons nous intéresser ici de l’option DexterOS, qui est celle proposée en standard dans les versions plus fournies du kit.

Il s’agit d’une distribution Raspbian adaptée par Dexter pour y inclure le support de la carte de contrôle du robot et fournir out-of-the-box plusieurs outils de programmation adaptés aux publics ciblés. La version utilisée est la 2.1.0-final, dernière en date au moment de la rédaction de cet article. Ma station de travail tourne sous Linux Mint 17.3 64 bits.

Plutôt que de recopier ici les descriptions de DexterOS, je vous engage à visiter le site web qui documente le GoPiGo3, en descendant à la section DexterOS.

Ce qu’on peut en retenir :

  • rien à installer sur les ordinateurs des utilisateurs, car tout se passe via le navigateur Web, le GoPiGo embarquant un serveur HTTP et les applications Web des différents outils proposés,
  • aucun problème d’intégration du GoPiGo dans le réseau local, car il crée lui-même son propre point d’accès Wifi,
  • une commande à distance rudimentaire est proposée parmi les outils, permettant d’actionner les moteurs (c’est plus un outil de vérification de bon fonctionnement du robot et de la connexion que quelque chose de réellement utile au-delà de cette fonction)
  • une collection de leçons,
  • plusieurs outils d’initiation à la programmation,
  • application francisée, y compris au niveau des blocs de programmation.

Au chapitre de l’initiation à la programmation, deux outils sont accessibles directement par un menu de la page principale de l’application Web servie par le GoPiGo :

  • Bloxter, outil de programmation graphique basé sur Blockly,
  • un IDE de programmation textuelle en Python basé sur Jupyter.

Tout cela est fort séduisant et augure d’un environnement plaisant. Voyons cela en détail.

  Bloxter : la programmation graphique

Deux niveaux de Bloxter sont proposés : ("Bloxter" et "Bloxter avancé"), la différence étant le nombre de rubriques et de blocs disponibles dans la toolbox.

Même si intégralement graphique, Bloxter permet également l’apprentissage de Python, car l’espace de travail peut afficher en marge droite le programme équivalent à l’assemblage de blocs.

PNG - 100.6 ko

C’est une très bonne approche pour s’initier en douceur. Et ce n’est pas votre serviteur qui va trouver quelque chose à redire au fait d’utiliser Python pour faire découvrir la programmation. C’est quand même moins ingrat que le C/C++ Arduino :)

On arrive rapidement à coder un super-Blink, qui fait passer par toutes les couleurs les yeux du petit robot dessiné sur la carte du GoPiGo. C’est très ludique et assez addictif, d’autant que la réactivité de l’environnement est bonne, ainsi que les temps de transferts. Pas besoin d’attendre une compilation assortie 9 fois sur 10 de messages d’erreur cabalistiques occasionnés par un pauvre point-virgule oublié. On se retrouve globalement dans un cycle très semblable à celui de l’environnement Graphique du LEGO Mindstorms par exemple.

C’est donc très bien adapté à l’initiation des plus jeunes.

Il y a cependant une différence assez importante avec des outils graphiques comme Scratch ou Thymio VPL au niveau de la structure des programmes. Alors que ces derniers sont basés sur un paradigme événementiel, et qu’on code sous forme graphique les réponses du robot aux divers événements qui peuvent survenir (via des règles dans le cas de Thymio VPL, ou de blocs indépendants déclenchés sur un événement spécifique dans le cas de Scratch), ici nous sommes ici plutôt dans l’approche de la représentation graphique de la boucle principale du programme. Autrement dit, on se retrouve à faire plus ou moins le duo setup/loop de l’Arduino. Dès que la logique va se complexifier ça va vite ressembler à un puzzle 5000 pièces, même si la présence de blocs permettant de créer des fonctions [4] permet d’organiser cela. Par ailleurs, la gestion d’actions en parallèle (typiquement, suivre une ligne tout en surveillant qu’un obstacle n’est pas détecté) devient complexe à implémenter pour les plus jeunes (et même les moins jeunes s’ils débutent) alors que c’est intuitif avec les autres outils cités. Tant qu’à générer du code Python, la représentation graphique aurait pu fournir des possibilités équivalentes à celles de ces outils.

L’autre regret est l’absence dans la toolbox de blocs de contrôle fin des moteurs. On dispose en effet de blocs de contrôle des mouvements du robot (en avant, en arrière, tourner à droite et à gauche), mais impossible de pivoter sur place (les rotations se font obligatoirement avec une roue à l’arrêt) ou de contrôler le rayon de giration par réglage direct et indépendant des vitesses des moteurs. Cela laisse donc peu de place pour l’optimisation d’un suivi de ligne.

Chassez le naturel, et il revient au galop...

Ceci étant, on a la déception là encore d’une réalisation non aboutie à 100%, qui gâche un peu (voire beaucoup parfois) toutes les bonnes intentions présentes dans le produit.

Vous savez tous que Python utilise une syntaxe dans laquelle l’indentation définit les blocs. [5]. La moindre des choses pour un afficheur de code, et surtout si s’il a une vocation pédagogique, est de le faire proprement. Or vous constatez sur le screenshot plus haut l’utilisation d’un afficheur qui replie les lignes sans indications visuelle quand c’est le cas, et qui a de plus une largeur réduite (et non modifiable). On finit rapidement par ne plus rien comprendre au code affiché. Il ne retrouve une certaine clarté que si on dispose d’un écran assez large et qu’on agrandit la fenêtre du navigateur.

Il y a deux solutions pour remédier au problème :

  • utiliser un afficheur sans repli des lignes et avec barre de défilement horizontal, ou un afficheur syntaxique avec coloration et mise en évidence correcte des replis de ligne,
  • ajouter la possibilité de redimensionner l’afficheur de code.

Une suggestion est donc faite en ce sens aux équipes de développement de Dexter. Faites en sorte de tester le produit en vous mettant en situation et à la place de vos utilisateurs cible (aussi bien les enseignants que les élèves), car en négligeant certains points de la réalisation, vous ruinez passablement les très bonnes intentions de départ.

Et ça ne s’arrange pas

Malheureusement, on retrouve ce type de défaut ailleurs, avec par exemple le module de suivi de ligne.

Il s’agit d’un module d’extension doté de 5 capteurs à réflexion infra-rouge et qui retourne directement :

  • la vision noir/blanc de chacun d’entre eux sous forme d’une chaîne de 5 caractères ’B’ ou ’W’
  • la position de la ligne (centrée, à droite, à gauche, tout blanc, tout noir).

Très bonne idée, car cela permet de se passer dans un premier temps de l’analyse "si tel capteur voit ceci, et que tel autre voit cela, mais que tel autre voit cela". La rédaction d’un programme de suivi basique devient de ce fait très simple et logique, en se résumant à une suite de tests telle que :

si la ligne est au milieu, avancer,
sinon si elle est à droite, tourner à droite,
...

PNG - 29.7 ko

Difficile de faire plus simple et surtout plus intuitif pour les jeunes roboticien(ne)s en herbe.

Le seul problème est que ce module fonctionne à l’envers de la logique théorique. Bien que le capteur soit monté dans le bon sens, respectant les indications "front, "left" et "right" inscrites dessus, la chaîne des détections noir/blanc est inversée, comme illustré par les images ci-après :

JPEG - 575.6 ko
PNG - 16.6 ko

Vous constatez que le ’B" (black) est à droite, alors que la ligne est à gauche du capteur (la photo est prise face au robot).

Du coup, le programme devient faux, et pour que le robot suive la ligne, il faut en fait coder :


si la ligne est à droite, tourner à gauche

La seule solution pour ne pas mettre à l’envers la tête des enfants et de monter le dispositif... à l’envers. Le problème est que les capteurs sont alors plus exposés, la pièce acrylique du dessous ne faisant plus office de pare-choc en cas de heurt avec une bordure ou toute autre obstacle.

Avouez que c’est un peu grotesque et pas sérieux. Un simple test du logiciel aurait mis en évidence ce bug de manière flagrante. Cette phase du développement serait-elle facultative chez Dexter ? A moins qu’ils ne la jouent à la Microsoft, en la confiant au client...

Petit complément d’analyse (13/08/2018) :

Ayant vu qu’une nouvelle version de DexterOS était sortie depuis le début de l’été, je l’ai testée pour voir si les points évoqués avaient évolué

Par curiosité j’ai utilisé le bloc de programmation "follow the line while/until" tout seul dans un programme en le configurant avec la clause while True. Eh bien ça marche comme attendu, et le robot suit bien la ligne. Et pourtant, la lecture directe du capteur montre toujours l’inversion de côté dans la chaîne des B/W représentant ce que "voit" chaque capteur du suiveur de ligne.

Par quel miracle alors ? La réponse se trouve dans le code Python généré :

import easygopigo3 as easy
import time
sensor_readings = None
gpg = easy.EasyGoPiGo3()
try:
    my_linefollower = gpg.init_line_follower()
    time.sleep(0.1)
except:
    print('Line Follower not responding')
    time.sleep(0.2)
    exit()
my_linefollower.read_position()
my_linefollower.read_position()
# start
gpg.forward()
while True:
    if my_linefollower.read_position() == 'center':
        gpg.forward()
    if my_linefollower.read_position() == 'left':
        gpg.right()
    if my_linefollower.read_position() == 'right':
        gpg.left()
gpg.stop()

Notez bien la logique du suivi : la fonction read_position semble retourner en fait la position du robot par rapport à la ligne, et non celle de la ligne par rapport au robot comme on pouvait le supposer intuitivement. De plus, cette fonction doit effectuer le miroir de la chaine de "w/b" décrivant ce que voit le capteur avant de l’interpréter. Ca pourrait se tenir, même si un peu tiré par les cheveux, sauf que la documentation de l’API nous dit ceci à propos de la méthode read_position() :


read_position()[source]

Returns a string telling to which side the black line that we’re following is located.
Returns : String that’s indicating the location of the black line.

En bon français, cela se traduit par :


Retourne une chaîne de caractères indiquant de que côté se trouve la ligne que nous sommes en train de suivre.

Malgré toutes mes tentatives à essayer de trouver des explications et des justifications à l’incohérence du résultat observé, il faut se rendre à l’évidence : il s’agit bien d’un bug, plus ou moins contourné dans Bloxter pour le dissimuler, car la documentation fournie par Dexter eux-mêmes confirme l’hypothèse de départ quant à la signification des valeurs retournées.

  Programmation en Python

Ah, nous allons passer aux choses sérieuses maintenant ;)

Sélectionnons "Python" dans le menu "Code". On voit alors apparaître un mini IDE, qui n’est autre que Jupyter [6] comme déjà mentionné dans la présentation initiale. Très bonne idée, car ça offre un environnement interactif très souple et productif pour essayer en live des bouts de code, mais également pour produire des "notebooks", mémorisant des séquences interactives. Idéal pour constituer des supports de formation et d’ateliers. A noter que Jupyter fournit quelques widgets simples, accessibles depuis le code Python, permettant de créer des IHM graphiques simples qui viennent prendre place dans le notebook. On ne vas pas décrire Jupyter ici plus en détail car il y en aurait pour des pages. Le plus simple étant est d’aller sur son site dédié. Il y a aussi un certain nombre de notebooks et de projets exemples fournis qui permettent d’explorer l’outil.

L’environnement offre également :

  • un terminal Python interactif
  • une console pour accès direct au shell

Ca marche très bien et ce n’est que du bonheur au premier contact.

Mais là encore, le deuxième contact est plus rugueux du fait de quelques bizarreries qui sont au rendez-vous :(

Les LEDS des yeux semblent inversées

Anecdotique mais à signaler car perturbant pour les expérimentations. Le petit bonhomme robot dessiné sur la carte de contrôle a deux yeux figurés par deux LEDS RGB :

JPEG - 88.9 ko

On peut les animer individuellement grâce aux méthodes set_left_eye_color et set_right_eye_color. Parfait. Sauf que set_left_eye_color modifie la couleur de l’oeil de droite, et réciproquement.

Ma première réaction a été de pourrir les développeurs de chez Dexter en les soupçonnant de ne pas avoir testé correctement leur soft, car inverser la droite et la gauche est un peu fort. Comme ça m’a semblé vraiment trop gros, j’ai fini par trouver une logique : en fait l’oeil de droite (pour l’observateur) est en fait l’oeil gauche du petit personnage,, étant donné qu’il nous fait face. CQFD.

Ca se tient, mais avouez que c’est un peu perturbant. La preuve. Très sincèrement, je pense qu’il aurait mieux valu conserver une logique droite-gauche par rapport à l’observateur, car je ne suis pas persuadé qu’un jeune expérimentateur de 10 ans va intuitivement faire la nuance.

Les blinkers (LEDs situées au niveau des coins avant de la carte, en-dessous) sont par contre correctement positionnés.

Le capteur de suivi de ligne ne fonctionne pas

Grosse déception, car j’étais parti pour refaire le suivi de ligne en PID, maintenant qu’on a accès au contrôle total de la vitesse de chaque moteur. Le seul problème est que l’initialisation du capteur se solde invariablement par le message "ImportError : Line Follower library not found".

A noter que pour encore mieux tromper l’ennemi, si on lance le script depuis le terminal que Jupyter met à disposition, on obtient un autre message, indiquant lui que le capteur n’a pas pu s’initialiser (j’ai donc au départ cru à un problème hardware ou de communication). Ayant réussi à identifier le code source concerné, cette mystification est le fruit d’une idée "géniale" de son auteur, qui dans le gestionnaire de l’exception produite par l’erreur de chargement de la librairie émet une autre exception faisant elle référence à un problème d’initialisation. Ben voyons, brouillons les pistes pour que les utilisateurs s’y retrouvent plus facilement.

Ce qui est très surprenant, c’est que le code Python initialement testé n’est autre que le copier/coller de celui affiché par Bloxter. Toute se passe comme si les deux modes d’exécution (i.e. Bloxter et Python natif) ne faisaient pas appel aux mêmes librairies d’interfaçage avec le matériel, ou aux mêmes réglages de l’environnement (PYTHONPATH et consorts). Incompréhensible... sauf si on considère un scénario assez probable (et déjà rencontré avec d’autres produits), dans lequel des outils d’origines distinctes et ayant suivi des processus de conception et de développement indépendants, ont été ensuite regroupé au sein d’un unique produit. Il s’agit ici d’un problème d’intégration, auquel un soin suffisant n’a pas été apporté.

[EDIT 13/08/2018]
La version 2.1.2-Final semble avoir corrigé ce problème. Il en persiste cependant un autre lorsqu’on essaye d’utiliser les fonctions de calibration au sein d’un notebook. Si my_linefollower.get_white_calibration() ne génère pas d’erreur (encore qu’on se demande à quoi correspondent les valeurs 0 retournées pour cahcun des 5 capteurs), my_linefollower.get_black_calibration() nous gratifie de :

Line Follower: failed getting black line values!
[Errno 13] Permission denied: '/home/pi/Dexter/black_line.txt'

Le fichier en question est celui où sont stockées les valeurs de calibration. Il est en principe censé être accessible par l’utilisateur jupyter sous lequel tourne le notebook. On peut confirmer ce point en exécutant le code suivant dans une cellule :

import os
os.getuid()

La valeur retournée est 1001, qui est l’uid de jupyter, celui de pi étant 1000.

Or si on se connecte directement sur le GoPiGo en ssh (voir plus loin comment y parvenir), on constate que les fichiers white_line.txt et black_line.txt ont pour propriétaire le user pi et ne sont accessibles que par lui. Il est d’ailleurs curieux que le test de la méthode get_white_calibration() n’ait pas eu le même comportement que son homologue. A croire qu’elle ne met pas à jour ces valeurs.

Au passage : bien que portant l’extension ".txt", ces deux fichiers sont en réalité des fichiers binaires. Encore un signe d’un certain manque de soin apporté à la réalisation [7].

 Essayons d’identifier la source des problèmes et d’y remédier

N’acceptant pas facilement de me faire dicter la loi par un tas d’octets, et étant persuadé que la correction de la plupart de ces défauts ne devrait pas présenter une difficulté insurmontable, j’ai tenté de passer derrière le décor. Comme j’ai pu le faire pour d’autres produits, j’étais parti avec l’intention de communiquer mes modifications au constructeur afin de contribuer à l’amélioration du produit. Tout cela en passe par l’exploration du code des applications via le terminal shell, afin de voir si quelques corrections évidentes ne permettraient pas d’avancer un peu.

Mais il ne faut pas y compter : le code des librairies et applications semble être dans le home dir du user pi, qui est inaccessible au user jupyter sous lequel on est identifié dans le shell proposé au travers de l’onglet terminal [8]. Dexter a de plus modifié le mot de passe de l’utilisateur "pi" [9] et ne diffuse pas le nouveau. Impossible donc de s’y connecter, voire d’utiliser la commande sudo pour passer root ou changer d’identité. Le pompon c’est qu’à toutes les questions qu’on trouve sur ce sujet dans les forums, ils font invariablement la même réponse :

With DexterOS, you won’t be able to log in with SSH because this isn’t the way it was intended to be used.

Autrement dit en bon Français : "avec DexterOS, vous ne pourrez pas vous connecter avec ssh parce que ce n’est la manière dont on est supposé s’en servir". Et si je veux accéder en ssh quand même, pourquoi n’en aurais-je pas le droit ? On se croirait sous Windows, enfermé dans la prison binaire que ses concepteurs ont imaginée bonne pour moi. Messieurs de chez Dexter, n’oubliez pas que vous évoluez dans le monde Linux, qui est aux antipodes de ce genre de pratique.

Du coup, impossible de mettre en application mon projet de correction et de contribution au produit.

Rien que par principe, je suis à deux doigts d’arrêter les frais et de cesser de perdre mon temps avec ce produit. Ainsi à terme qu’avec tous ceux de chez Dexter, les tests effectués jusqu’à présent s’étant révélés plutôt décevants (cf le test du BrickPi d’il y a quelques années)

Dernières tentatives

Puisque c’est comme ça, on va tenter la manière forte, à savoir booter le système en mode single user et modifier le mot de passe de "pi" histoire de retrouver notre pleine liberté d’action.

Arrêt du GoPiGo, extraction de la carte SD (pinces à épiler obligatoires comme indiqué en début d’article, car son accès est un peu entravé par les câbles de moteurs), insertion dans le lecteur de ma machine pour modification du fichier cmdline.txt de la partition boot. Il suffit en effet d’ajouter init=/bin/sh à la fin de l’unique ligne contenue dans ce fichier pour lancer le shell sous l’identité root au lieu du système et de ses services normaux.

Problème : le boot me gratifie systématiquement du message :

sh: can't access tty; job control turned off

et bloque ensuite. Seule issue : couper l’alimentation (pas glop :().

L’approche de la dernière chance : monter la carte SD sur ma machine pour en explorer le rootfs.

Problème : impossible de monter la partition concernée, et ce malgré moult reflashage de l’image et fsck divers. Je n’ai jamais rencontré ce problème avec aucune des distros et RasPi que j’ai utilisées depuis toutes ces années.

Ne m’avouant pas vaincu, j’ai refait la tentative sur une autre machine, tournant sous une version plus récente de Mint (18.3 en l’occurrence). Cette fois-ci la partition rootfs s’est montée normalement [10]. Du coup, on s’empresse d’éditer le fichier /etc/shadow pour y modifier le mot de passe de l’utilisateur pi par quelque chose de connu, en l’encryptant bien entendu à l’aide de la commande mkpasswd [11] :

$ mkpasswd -m sha-512 raspberry
$6$CBy1SgcFgNb7KC$L.jRkdRH/9T//99dkzW6OVIlQAtS87mg3RjcskWXcWDO69/Nn0sAWgQSr5efe9nYsC4hsT9ZWIoaZHIgZpoQG0

Utilisez bien entendu autre chose que le mot de passe trivial habituel (utilisé ici à titre d’exemple), surtout si vous laissez le serveur ssh actif (il l’est par défaut, et c’est tellement pratique).

Et voilà, au prochain reboot vous pourrez à nouveau utiliser librement le user pi, qui a heureusement conservé son statut de sudoer.

Au passage, si au lieu de ssh vous préférez la connexion directe avec clavier USB et moniteur HDMI, pensez à éditer le fichier /etc/default/keyboard pour y remplacer "gb" par "fr" pour la valeur de XKBLAYOUT. Ca vous évitera de pester contre le mot de passe que ne veut pas être accepté.

Modifiez également /etc/resolv.conf en commentant la ligne nameserver = 127.0.0.1 et en ajoutant :

nameserver = 8.8.8.8
nameserver = 4.4.4.4

Faute de quoi vos tentatives d’apt update et apt install vous reverront à la face des messages assez peu intuitifs, dont l’origine est en fait un problème de résolution de nom de serveur.

Maintenant que nous avons repris le contrôle de notre bestiole, il va être possible de rechercher la cause du problème de notre capteur de suivi de ligne et d’y remédier. A suivre...

  Conclusion

Ce produit a failli avoir eu raison de ma patience dans son état actuel :-( Reconnaissez qu’il a fallu se battre.

Et c’est bien dommage car il y a de très bonnes idées, mais un certain manque de rigueur dans la réalisation, aggravé par les obstacles rencontrés pour tenter de contribuer à remédier aux défauts peuvent décourager.

Personnellement je vais le mettre de côté en attendant que Dexter revoie sa copie et corrige les défauts détectés, car les patchs que je pourrais apporter à ma version hackée ont de fortes chances d’être écrasés par la prochaine mise à jour. Je vais néanmoins leur faire part de mes remarques et propositions de correction, à toutes fins utiles.

Que faire ?

Pas simple....

Il y a du potentiel dans le produit, et si vous êtes prêt à vous battre un peu, corriger les défauts signalés ici ne devrait pas être insurmontable. Mais dans ce cas, c’est plus le challenge qui vous intéresse que le fait de disposer d’un produit prêt à l’emploi et sans prise de tête. Si vous optez pour cette stratégie, pensez à suivre les mises à jour de la distribution DexterOS en espérant qu’elles corrigent ces erreurs de jeunesses. Ceci étant, ne perdez pas de vue qu’elle est dans sa version 2.X. Si de tels ajustements pouvaient être compréhensibles dans une version 0.x, ou même 1.x, ça commence à devenir préoccupant s’ils persistent dans une version censée être finalisée.

Si vous recherchez des options pour l’initiation des plus jeunes avec un petit robot mobile et sans histoire, le plus simple et efficace parmi ceux que j’ai pu tester est encore le Thymio. Je n’ai aucune action chez ses concepteurs et personne ne m’en a jamais offert un [12], mais ça fait maintenant plusieurs années que je l’utilise avec une totale satisfaction pour animer des ateliers d’initiation pour les jeunes et les ados. Et quand on voit le niveau de certains projets que les étudiants de l’EPFL ont réalisés avec (comme celui-ci), ça en dit long sur ses possibilités.

Une autre voie à considérer, et moins onéreuse de surcroït : une carte Micro-bit associée à une extension comme la Motor Driver Board, permettant de piloter deux moteurs et de dialoguer avec quelques périphériques, et à un châssis basique. Divers environnements d’initiation à la programmation sont fournis pour elle, aussi bien graphiques que textuels. Elle est par ailleurs très simple à gérer, car dépourvue d’OS : elle se programme nativement en micro-Python bare metal.

Mon avis : c’est vous qui voyez. Quand je pense que le slogan de leur site prétendait que c’était le meilleur kit robotique... Je vous laisse en juger par vous-mêmes...


[1un des meilleurs kits robotiques que vous pouvez acheter, en particulier pour les enseignants

[2et pourtant je suis tout sauf un bourrin pour ce genre d’activité

[3on ne trouve plus guère de cartes de 8G actuellement

[4en mode "Advanced Bloxter"

[5et si vous ne le saviez pas, maintenant c’est chose faite

[6anciennement connu sous le nom de iPython Notebook

[7pour ne pas dire "amateurisme"

[8normal, nous sommes sous Linux et pas question d’aller voir chez le voisin aussi facilement

[9robots1234 dans les anciennes versions de DexterOS

[10je suis preneur de toute explication relative au problème de montage en 17.3 et du succès en 18.x

[11fournie par le package Debian whois

[12celui que j’utilise est un exemplaire mis un à disposition gracieuse par l’INRIA Sophia pour évaluation

Un message, un commentaire ?

modération a priori

Attention, votre message n’apparaîtra qu’après avoir été relu et approuvé.

Qui êtes-vous ?

Pour afficher votre trombine avec votre message, enregistrez-la d’abord sur gravatar.com (gratuit et indolore) et n’oubliez pas d’indiquer votre adresse e-mail ici.

Ajoutez votre commentaire ici
  • Ce formulaire accepte les raccourcis SPIP [->url] {{gras}} {italique} <quote> <code> et le code HTML <q> <del> <ins>. Pour créer des paragraphes, laissez simplement des lignes vides.