La base
Le robot utilisé dans la version actuelle de TaxiBot est construit sur la base du mBot de MakeBlock (version 1, à base d’Arduino). Nous n’avons strictement aucun lien avec ce fabricant et l’avons payé "plein pot".
Il se trouve que le produit est de bonne qualité, solide et dispose d’une gamme d’accessoires assez étendue. Il est par ailleurs le point d’entrée d’une gamme proposant des kits compatibles entre eux, incluant dans le haut de la gamme des moteurs asservis et pièces mécaniques diverses pour réalisation de systèmes complexes.
Les robots de la gamme sont contrôlés par des cartes de type Arduino, ce qui rend leur programmation accessible à tous, y compris les débutants via leur environnement graphique. Ce dernier n’est malheureusement pas disponible à ce jour sous Linux, et est donc non compatible avec des postes de travail open tels que les Raspberry Pi dont nous sommes équipés. Shame on you 😡
[EDIT 04/10/2021] la version 2 du mBot vient d’être mise sur le marché, et elle s’inscrit en rupture avec ce qui précède. Beaucoup plus puissante et dotée en fonctionnalités, mais aussi notablement plus chère (un bon 50% en plus). Difficile de savoir pour le moment quel type de processeur la propulse, mais ça ne semble plus du tout être de l’Arduino ou semblable. Jusqu’à nouvel ordre la seule manière de programmer cette version est avec leur environnement graphique Win-Mac. Shame on you again 😡
Le mBo étant largement diffusé au sein de l’Education Nationale, de nombreux établissements scolaires en sont déjà équipés. Ils ne devraient donc avoir aucun mal à reproduire TaxiBot.
Les adaptations
Il y en a deux :
- un détecteur de ligne supplémentaire
- un transmetteur radio XBee
Le détecteur de ligne
Il ne s’agit pas du même modèle que celui livré avec le robot mais d’une version avec 6 capteurs. Ses dimensions font qu’une fois fixé à l’aide des trous situés à l’arrière du châssis, les capteurs tombent quasiment pile au niveau de l’axe des roues motrices. Coup de chance ou design délibéré de la part de MakeBlock ? Probablement la première option, car cette caractéristique n’est mentionnée nulle part dans le descriptif, or elle le serait si elle était le résultat d’un choix délibéré.
Il sert à la détection de la ligne transversale au niveau des croisements en testant l’ensemble des valeurs qu’il fournit : lorsque les 6 capteurs "voient" une ligne, c’est qu’on est exactement au niveau du croisement. Cela nous permet donc d’immobiliser le robot au niveau du croisement de manière précise, afin de pouvoir effectuer un pivotement correct pour emprunter ensuite une nouvelle direction.
Rien de particulier à en dire... si ce n’est qu’il n’est plus distribué 🙁
Le produit le plus proche actuellement disponible est le RGB Line Follower équipé de 4 capteurs :
Les dimensions et l’emplacement des trous de fixation permettent un positionnement au voisinage de l’axe des roues (environ 1cm en arrière). Ca peut quand même convenir, car les capteurs vont détecter le bord de la ligne, et par conséquent l’axe des roues ne devrait pas être très loin de celui de la ligne si on s’arrête assez vite. Le code devra de plus être adapté car le capteur retour le bit pattern du statut ligne/pas ligne des 4 capteurs (et non plus de 6).
Point important : Contraitement à ce que le nom pourrait laisser supposer, ce ne sont pas les capteurs qui sont RGB mais uniquement l’éclairage associé. Les capteurs ne sont eux que de simple capteurs d’intensité lumineuse. Aucune information de couleur n’est donc retournée directement par ce capteur, mais uniquement la détection binaire de ligne, comme pour le suiveur livré en standard ou l’ancien modèle à 6 capteurs.
Par ailleurs, la seule documentation explicite quant à la gestion de la couleur ne décrit que la procédure de calibration (ou apprentissage) permettant de sélectionner celle avec laquelle le terrain est éclairé, pour ensuite mémoriser les niveaux lumineux au-dessus du fond et au-dessus de la ligne en vue de déterminer le statut binaire de détection de ligne. La justification de cet éclairage coloré est de pouvoir fonctionner sur des terrains autres qu’avec une ligne noire sur un fond blanc.
Ceci étant, l’étude du source C++ du driver du capteur révèle des fonctions retournant la valeur brute produite par l’ADC associé à chaque capteur de luminosité. Un registre documenté sommairement permet aussi de contrôler la couleur de l’éclairage (via un code de sélection d’un des 3 couleurs de base, et non pas via les composantes RGB). En théorie on devrait donc pouvoir obtenir une information de couleur par la même méthode que celle utilisée... dans notre robot Coupe de France 2006 🙂
Au passage : la documentation des sources fournis est loin d’être au standard professionnel : la description des fonctions se résume la plupart du temps à... leur nom 😕 En tant que professionel de la chose, ça pique un peu les yeux. MakeBlock, il faudrait faire un petit effort sur le volet logiciel de vos produits, car il n’est pas vraiment à la hauteur du matériel 😉
Le transmetteur XBee
Pourquoi diable cela sachant que le mBot est communiquant par nature ?
C’est simple : il y a (pardon : il y avait) deux versions du mBot :
- équipé d’un module Bluetooth
- équipé d’un module série 2.4GHz
Petit aparté pour dissiper un fréquent malentendu : le module 2.4GHz n’est en rien un module Wifi comme lu dans moult blogs [1] ou entendu parfois (également pour d’autres robots comme le Thymio d’ailleurs). La meilleure démonstration en est qu’à aucun moment on ne vous demande l’ESSID du réseau sur lequel se connecter et son mot de passe. C’est la différence en mathématiques entre relation d’équivalence et implication simple : le Wifi opère dans la bande de fréquence 2.4GHz (et maintenant 5GHz éqalement) mais tout ce qui opère en 2.4GHz n’est pas du Wifi. Ca peut être du Bluetooth par exemple ou de la simple liaison série non-filaire (dite "dématérialisée"). Ce qui fait la différence est le protocole de communication qui va définir la structure des paquets de données échangés sur la liaison radio et l’adressage des protagonistes de ces échanges. Pour en savoir plus, se reporter aux articles d’introduction aux couches OSI. Le module série 2.4GHz du mBot entre dans la catégorie des liaisons série sur support radio.
Dans notre cas de figure nous avons besoin d’une simple liaison série, beaucoup plus simple à mettre en oeuvre car aucun appariement n’est nécessaire comme dans le cas du Bluetooth. Il suffit de le configurer une fois pour toutes et le tour est joué.
Petit souci : impossible de trouver un distributeur capable de le fournir, seule la version Bluetooth étant disponible. L’explication probable est qu’à l’heure actuelle on a tendance à considérer qu’on fait tout avec des smartphones ou des tablettes. Ben voyons 😕
OK, mais pourquoi ne pas utiliser le Bluetooth puisque la Rapsberry en est équipée de base ? Il suffit d’apparier les deux zozos et le tour est joué. La réponse : ça marcherait probablement chez les Bizounours, mais dans le vrai monde où les licornes n’existent pas c’est une autre histoire.
Mes diverses tentatives se sont en effet soldées par :
- une connexion laborieuse à établir
- une connexion très instable
Si on ajoute cela au fait que le Bluetooth est un réseau basse énergie à très courte portée pour des raisons de consommation, on image les risques pris dans le cas de son utilisation dans un milieu fortement pollué sur le plan électromagnétique comme une Fête de la Science ou autre manifestation publique d’envergure.
Exit donc l’option Bluetooth.
Il existe pléthore de modules radio divers et variés, certains arrivant de Chine pour 2 Euros port compris. Ce n’est même pas le prix des composants électroniques, sachant que ce tarif inclut la marge des différents acteurs qui interviennent jusqu’à votre boîte aux lettres. Mais quand ce n’est pas cher, c’est la plupart du temps trop cher. Traduction : ça ne vaut pas grand-chose dans les faits et en général vous en achetez 5 pour en avoir 2 qui fonctionnent au déballage, dont un va lâcher au bout de quelques jours. Je n’invente rien, c’est du vécu.
Ici nous avons besoin de quelque chose de fiable, avec une portée correcte de manière à avoir suffisamment de marge. Il se trouve que j’ai utilisé les XBee de manière assez poussée à titre professionnel, et je les connais donc bien. Ils coûtent certes un peu (beaucoup) plus que les 2 Euros des produits made in China, mais on en a pour son argent et j’ai pu en mesurer les performances y compris en milieu hostile. Et comme j’en avais récupéré un stock devenu inutile lors de l’arrêt des activités de recherche pour lesquelles ils étaient employés, autant les recycler pour une bonne cause.
Le modèle sélectionné ici est la version 802.15.4, dite "Série 1". 802.15.4 n’est autre que la première couche de protocole de communication défini par l’IEEE sur laquelle plusieurs autres protocoles utilisés sur la bande 2.4GHz sont basés (comme ZigBee ou 6LoWPAN par exemple). Pas besoin de prendre un modèle "pro" qui se différencie par la puissance radio. Le modèle standard est largement suffisant, mais je conseille cependant la version avec la petite antenne filaire incorporée (i.e. pas la version avec l’antenne céramique intégrée au circuit imprimée) car le châssis du mBot étant métallique et ses moteurs étant proches, ce n’est pas ce qu’on fait de mieux pour des communications radio.
Remarque : le modèle "Série 1" n’est plus distribué et il semble avoir été remplacé par la version "S2C" qui supporte également le ZigBee. Si j’ai bien compris les documentations, ce support est obtenu par mise à jour du firmware et il semblerait que sans cela le modèle S2C fonctionne en liaison point à point comme utilisé ici. C’est sous toute réserve, n’en ayant jamais eu entre les mains.
Au niveau connexion, il fournissent une simple liaison série et ça tombe bien car c’est exactement ce que font les modules radio proposés pour le mBot. La greffe est donc simple car il suffit de tirer 4 fils (VCC, GND, Rx et Tx) entre le connecteur prévu sur la carte du mBot et notre XBee.
Attention : les signaux présents sur ce connecteur sont en 5V (comme tout le reste sur la carte du mBot) or le XBee fonctionne en 3V3 et n’est pas "5V tolerant". Ce qui veut dire que si on connecte les choses sans plus de précaution, on en sera quitte pour racheter un XBee dans la seconde qui suit.
Il existe heureusement de nombreux adaptateurs qui se chargent de cette... adaptation. Ils prennent également en charge l’adaptation mécanique, car les broches des XBee sont au pas de 2mm et non pas de 2.54mm comme les connecteurs en barrette courants. Les modèles de chez Sparkfun sont de très bonne qualité.
Voici ce que donne cette greffe sur notre mBot :
On y voit le XBee installé sur son adaptateur (PCB rouge) lui même collé sur une petite plaquette en polycarbonate transparent fixée avec de l’adhésif double face au châssis du mBot. Les 4 fils entrent dans le boitier électronique par la découpe bien pratique déjà présente permettant l’accès à l’alimentation 6V. Celle-ci n’est pas utilisée ici, notre modèle étant équipé d’un accu LiPo [2].
Du côté de la Raspberry Pi les choses sont beaucoup plus simples car celle-ci fonctionne avec des niveaux logiques TTL 3V3. On pourra donc relier directement ses broches RXD0 et TXD0 à leurs homologues du XBee.
L’adaptateur utilisé ici est un simple PCB équipé de barrettes au pas de 2mm. On peut voir la liaison au connecteur de la RPi, seuls 4 des fils de la nappe étant utilisés.
Attention : pensez à désactiver la console série dans les options de boot, car sinon tous les messages de progression seront envoyés au XBee qui ne va pas y comprendre grand-chose et risque de se mettre en colère. Ou bien le mBot va se mettre à avancer de manière incontrollée si des caractères correspondant à ses ordres de route font partie des messages affichés. On trouve pas mal d’instructions sur le Net pour cela, sachant qu’il semble que les choses soient différentes entre la Pi3 et la Pi4.
Remarque complémentaire
Il n’y a aucune obligation à utiliser des XBee. N’importe quel transmetteur (le vrai nom étant "modem radio") peut convenir du moment qu’il fonctionne avec une liaison série et qu’on est capable de rendre ses niveaux électriques compatibles avec le TTL 5V si nécessaire.
Cela exclut à priori les produits de la gamme NRF qui eux utilisent un bus SPI. Rien n’interdirait cependant leur utilisation dans l’absolu, mais il faudrait alors modifier le code aussi bien du côté Raspberry que mBot.