Dans un précédent article, je testais le fonctionnement d’une boussole électronique avec un Arduino.
Si elle marchait très bien dans des conditions optimales, il était apparu que la proximité d’un champ magnétique suffisamment puissant la rendait complètement inopérationnelle. On observe ce phénomène lorsqu’on approche un aimant d’une boussole : l’aiguille perd le nord, le champ magnétique de l’aimant prenant le dessus sur le champ magnétique terrestre.
Dans le cas d’un robot, c’est problématique parce que les moteurs et haut-parleurs contiennent de puissants aimants. J’avais constaté qu’à partir d’une distance de 15 cm environ, mes moteurs ne gênaient plus trop la boussole, mais ça reste assez contraignant.
Il existent des matériaux qui permettent de dévier les champs magnétiques, notamment le Mu-Metal. Il est essentiellement constitué de fer et de nickel et a subit des traitements spécifiques qui lui confèrent une forte perméabilité magnétique. Le Mu-Metal est très utilisé pour le blindage magnétique (câbles, disques durs…).
C’est plus compliqué à se procurer que la plupart des autres composants d’un robot, mais on en trouve sous forme de ruban adhésif ou de plaque. J’ai commandé une petite plaque autocollante de 10cmx10cm (0.01mm d’épaisseur) pour une quinzaine d’euros sur ebay (on doit pouvoir trouver moins cher, mais en petite quantité, c’est plus difficile).
Pour aller droit au but, ça marche vraiment très bien ! La preuve en vidéo :
Encore un sujet qui m’a posé quelques problèmes, finalement liés à une télécommande un peu particulière.
Je ne suis pas encore sûr à 100% d’intégrer un récepteur et un émetteur infrarouge dans mon robot. Mais il peut-être intéressant de permettre à un robot de piloter les équipements de la maison.
Une LED infrarouge (cadre bleu sur la photo) permettra d’envoyer des signaux à ces équipements. Il faut utiliser des LED IR avec une longueur d’onde de 940nm (celles que j’utilise : 1.1-1.4V, 100 mw, 50 mA).
Pour piloter la LED avec l’Arduino Nano, j’ai utilisé un transistor NPN (BCX38C). Sachant que les sorties du Nano sont limitées à 40mA au grand maximum, je ne voulais pas prendre de risque et j’ai préféré prendre le courant directement sur l’alim. Avec une résistance de 82 Ohms (R = (5 – 1.3)/0.05 = 74 Ohms). Je mesure avec l’ampèremètre une trentaine de mA. Le transistor est donc facultatif.
Un récepteur IR (cadre jaune sur la photo, un TSOP38238) permettra de capturer les signaux d’une télécommande pour pouvoir les restituer plus tard avec notre LED (lorsqu’on appuiera sur un bouton).
J’ai utilisé la librairie IRremote de Kim Shirriff, qui a réglé toutes mes difficultés. Elle gère un large panel de type de signaux. L’exemple IRrecord est le programme que j’ai utilisé pour mes tests (il permet d’apprendre un signal et de le restituer lorsqu’un bouton est appuyé). Un tutorial disponible ici.
En faisant le tour des différents périphériques i2c que je compte utiliser pour mon robot, j’ai eu la mauvaise surprise de voir que la boussole et l’écran OLED partageaient la même adresse sur le bus i2c (x3C). Aucun des 2 modules ne permet de modifier l’adresse comme c’est le cas pour certains périphériques.
J’ai donc commandé le même écran OLED, dont je suis très satisfait, mais dans sa déclinaison SPI afin d’éviter les conflits sur le bus i2c. Ca a été plus compliqué que prévu, d’où ce court article.
La première difficulté concerne le raccordement de l’écran à l’Arduino. Certains connecteurs sont nommés de manière peu éloquente : Gnd, Vcc (jusque là, ça va), D0, D1, RES, DC, CS.
Voici les bonnes correspondances, écran –> Arduino :
GND –> GND (masse)
VCC –> 3.3V à 5V (alimentation)
D0 –> SCK
D1 –> MOSI
RES –> un pin digital (c’est pour le reset)
DC –> un pin digital (data/command)
CS –> SS
Second problème, logiciel pour changer. J’utilise toujours la librairie U8glib dont je suis très content. Par contre, les constructeurs proposés dans les différents exemples de code ne fonctionnent pas : il faut passer au constructeur le numéro du pin RESET !J’ai utilisé le constructeur suivant dans mes tests (avec un Arduino Nano) :
U8GLIB_SSD1306_128X64 u8g(13, 11, 10, 9, 4);
// SW SPI Com: SCK = 13 (D0 sur oled), MOSI = 11 (D1 sur oled), CS = 10 (CS sur oled), A0 = 9 (DC sur OLED), !!RESET = 4 (RES)!!
J’adore les Arduino Nano, ils ne coûtent rien, prennent très peu de place, sont très faciles à intégrer dans des petits projets et offrent toutes les fonctionnalités de leur grand frère le Uno.
L’Arduino MEGA est particulièrement intéressant pour les plus gros projets. Ils offrent bien sûr beaucoup plus d’entrées/sorties analogiques et digitales, mais c’est au niveau de la mémoire qu’ils se démarquent :
EEPROM : 4 Ko contre 1 Ko pour le Nano/Uno
SRAM : 8 Ko contre 2 Ko pour le Nano/Uno
Flash : 256 Ko contre 32 Ko pour le Nano/Uno
L’Arduino MEGA permet donc de s’affranchir d’un certain niveau de contraintes vis-à-vis de la mémoire, qui peut rapidement venir à manquer. Mais au contraire du Nano, il est énorme ! C’est vraiment une carte de prototypage, assez difficile à intégrer dans des projets finaux.
Le meilleur de ces 2 mondes existe ! 🙂
Ce n’est pas une carte qui existe officiellement chez Arduino, mais en cherchant un peu, on la trouve : la Meduino Mega2560 Pro Mini. Je l’ai commandée sur ebay, expédiée depuis la Chine (aucun vendeur européen). Elle est totalement compatible avec le Arduino Mega2560, simplement beaucoup plus compacte.
J’avais besoin de la quantité de mémoire de la MEGA, mais ça taille était vraiment un problème (sans parler de la fiabilité des connecteurs pour un produit fini).
Après avoir soudé les pins (y en a quand même autour de 80), j’ai lancé un petit test avec un écran OLED. Ça a fonctionné parfaitement du premier coup, la carte est vraiment vue comme un Arduino Mega2560 ! 🙂
Pour gérer les déplacements et la localisation d’un robot, il faut connaître ses coordonnées et son orientation (la direction dans laquelle il regarde). Une boussole lui fournira un référentiel pour lui permettre de définir son orientation.
J’ai commandé les 2 modules suivants pour faire mes tests : le HMC5883 et le HMC5983 (on les trouve facilement pour 3€ sur ebay, banggood et autres vendeurs) :
En fait, j’avais déjà un HMC5883, j’ai commandé un HMC5983 qui est son successeur et qui apporte quelques améliorations mineures (SPI, compensation de la température…).
C’est là que mes mésaventures ont commencé : le module HMC5983 peut s’alimenter en 5V (le 5983 tournant à 3.3V), donc je l’ai bêtement connecté à mon Arduino. Mais il marchait très mal (quelques secondes au mieux). J’ai contacté le vendeur (bsfrance sur ebay) qui m’a répondu très rapidement : le module peut s’alimenter en 5V, mais le niveau logique pour les pins i2c est lui toujours à 3.3V ! Bref, il me faut un convertisseur de niveaux pour l’utiliser correctement. C’est commandé, en espérant que le 5983 n’est pas été abîmé par mes tests à 5V.
En attendant, je suis passé sur mon HMC5883, qui lui a été beaucoup plus tolérant : le niveau logique à 5V ne pose pas de problème.
Voici le montage de test :
Un Arduino Nano (non visible), le module HMC5883 (à gauche) et un servomoteur. Le but est que lorsque l’on fait tourner la boussole électronique (le 5883), l’axe du servomoteur se déplace du même angle (par rapport au nord). On voit sur la photos que le HMC5883, la boussole manuelle et l’axe du servomoteur sont tous orientés au nord.
La librairie de Adafruit fonctionne très bien, c’est celle que j’utilise pour le moment.
C’est un bon début. Je m’inquiétais aussi des effets que pouvaient avoir les éléments magnétiques du robot sur la boussole. Les moteurs ainsi que le haut-parleur contiennent des aimants assez puissants. Et je n’avais pas tord de m’en inquiéter, la preuve un images :
Comme on peut le voir, les moteurs comme le HP rendent la boussole totalement inutilisable. C’est facheux, mais on ne va pas se laisser abattre :
il existe peut-être des moyens de calibrer la boussole pour compenser les interférences environnantes fixes (qui ne varient pas), à creuser
Quand je recevrai le convertisseur de niveaux, je testerai le HMC5983, il sera peut-être moins sensible aux interférences
A partir d’une quinzaine de centimètres, les interférences deviennent négligeables, je pourrai ajuster le design du robot pour éloigner au maximum la boussole des moteurs et du HP (voir même le surélever sur une petite tourelle).
Edit du 21/11/2015 :
J’ai reçu les convertisseurs de niveau et j’ai retesté le HMC5983 et ce n’est pas mieux (même avec un autre HMC5983, c’est pareil).
J’ai mis la main sur une librairie spécifique au 5983 (dispo ici, qui fonctionne très bien avec le 5883 aussi). Et je vois qu’il y a beaucoup de lectures en erreur (50%). Au moins, avec cette librairie, j’arrive facilement à écarter les erreurs et obtenir des données utilisables. Par contre, si je lis trop rapidement le capteur, les données ne sont plus exploitables… (en gros, jusqu’à une lecture toutes les 100ms, ça va).
Bref, j’ai perdu bien assez de temps avec ce capteur. J’ai trouvé très peu de cas d’utilisation avec un Arduino, ça n’aide pas. J’aurais aimé comprendre ce qui ne tourne pas rond mais tant pis, j’utiliserai le HMC5883 qui lui ne pose aucun problème.
Dernier point concernant les interférences, j’ai commandé une feuille de Mu-metal, qui est un matériau qui à la faculté de bloquer/dévier les champs magnétiques. Il me permettra d’isoler un peu les moteurs et le HP pour limiter les interférences sur la boussole.
La Pixy MCUcam est une caméra intelligente, elle est capable de reconnaître et suivre des objets grâce à leur couleur. Elle peut apprendre jusqu’à 7 signatures et est très performante (50 analyses d’image par seconde). Elle propose un large panel d’interfaces (i2c, série, SPI, USB…). La page du produit est ici (projet financé via Kickstarter).
Elle est dispo chez Lextronic (entre autres) à 69€. Ça peut sembler cher, mais vu ce qu’elle propose, ça me paraît très raisonnable.
Sur PC, on peut la connecter via USB et utiliser un logiciel pour la tester et la configurer. Sur la vidéo suivante, elle traque 2 objets (précédemment appris).
Comme on peut le voir, la camera sait identifier sur l’image la présence de certains objets. A chaque analyse elle renvoie les coordonnées et les tailles des objets identifiés.
Les performances sont vraiment impressionnantes. Il y a par contre des conditions à respecter : le capteur est basé sur un algorithme de filtrage des couleurs (il analyse la teinte et la saturation de chaque pixel). Les conditions d’éclairage peuvent avoir un impact sur l’efficacité du capteur, ça reste à tester plus en profondeur. De nombreuses options sont disponibles pour ajuster les conditions de reconnaissance. C’est avec des couleurs vives que le capteur marche le mieux.
Si l’application PC est pratique pour les tests et la configuration, c’est avec un Arduino que je l’interfacerai. La camera dispose d’un port pour une nappe de 10 fils. Le câble livré avec n’en contient que 6 et est prévu pour une connexion via SPI. Je compte l’utiliser en i2c, il faudra donc prévoir un nouveau câble. Voici le détail des connexions sur le port de la Pixy CMUcam5 :
Ci-dessous, l’ordre des pins pour les connecteurs mâles et femelles des nappes :
Je ferai un câble spécifique pour la connexion i2c, en attendant j’utilise simplement des câbles de prototypage.
Et voici la démo (fournie en exemple avec la librairie Arduino) en i2c :
A chaque analyse, le capteur renvoie la liste des signatures détectées (sig), les coordonnées (x,y) et la taille en pixel (width/height):
On voit qu’il y a un peu de bruit, il faudra trouver le moyen de filtrer tout ça. Mais les possibilités de ce capteur sont immenses.
Le code source est ici (et provient des exemples de la librairie fournie pour Arduino, je n’ai rien inventé).
Je compte notamment l’utiliser pour mettre en place des algos de SLAM (Simultaneous Localization And Mapping, soit en français: cartographie et localisation simultanées).
L’idée est d’apprendre au capteur un certain nombre d’objets qui serviront de balises de repérage. Quand le capteur identifiera un marqueur, le robot pourra en déduire la pièce dans laquelle il se trouve. Encore mieux, grâce à la taille retournée par le capteur, il pourra estimer la distance qui le sépare de ce marqueur. Le robot saura que sa position est un point sur un cercle de rayon X autour du capteur. Enfin, grâce à une boussole, il saura identifier précisément ce point !
Ça c’est la théorie, on verra la pratique plus tard 🙂
Aujourd’hui, on va regarder ce qui permettra de faire le « cou » de mon robot : une tourelle articulée qui permettra au robot de bouger sa tête de droite à gauche et de haut en bas.
L’ensemble est constitué :
d’une tourelle SPT200 de chez Servocity dans sa déclinaison pour servomoteurs Hitec (commandée chez Robotshop pour 53€, ce qui est très cher pour ce que c’est)
de 2 servomoteurs Hitec HS-645MG
Le tout sera piloté par un contrôleur de servomoteurs de chez Adafruit (i2c), capable de gérer 16 servomoteurs. Pour le moment on en utilisera que 2, mais j’en utiliserai davantage pour les bras.
J’ai réfléchis à différents systèmes que j’aurais pu fabriquer moi-même (j’avais pensé à des systèmes d’axes entraînés par des poulies/courroies etc.). Finalement, je n’aurai pas mieux fait que le SPT200, nous verrons pourquoi.
Il arrive en pièces détachées (le montage était déjà commencé sur cette photo) :
Alors honnêtement, la notice n’est pas des plus claire concernant les vis à utiliser. Toutes les dénominations de vis sont en anglais et en pouces, ça n’aide pas à s’y retrouver. Au final, en faisant preuve de logique et en lisant la notice entièrement avant de commencer, on s’en sort. Les vis noires (à part la très longue) servent à visser dans le plastique de la structure (celles à tête plate servent pour le plateau).
Attention également lors du montage des servomoteurs à s’assurer du bon positionnement de leurs axes avant de les fixer ! J’ai identifié la position correspondant au milieu de course de chaque axe pour l’orienter de la bonne façon.
Malgré son prix, que je trouve très élevé quand on voit la liste éléments qui compose ce kit, il est très bien pensé. La plupart des systèmes de tourelles que l’on trouve sur le marché à des prix raisonnables sont faits pour supporter des charges très faibles car ce sont les axes des moteurs qui supportent tous les efforts. Avec le SPT200, l’effort est porté sur les des roulements à billes intégrés à la structure et les moteurs ne font qu’entraîner les axes, sans subir de contraintes susceptibles d’abîmer les moteurs. Sur les photos précédentes, et les 2 suivantes, on voit où et comment sont placés ces roulements à billes.
Côté électronique, je ne souhaitais pas piloter directement les servos avec l’Arduino (qui aura déjà beaucoup d’autres choses à gérer), j’ai donc opté pour une carte contrôleur de chez Adafruit qui se connecte sur le bus i2c. Un tutorial est disponible ici et la librairie pour Arduino ici.
J’ai écris un programme de test, il est disponible ici et s’inspire des exemples livrés avec la librairie.
Une fois encore, attention ! Les positions MAX et MIN des servos correspondent à mon montage. Exécuter un programme dont les limites des servos n’ont pas été vérifiées avant peut provoquer de la casse : le servo utilisera tout son couple (et donc beaucoup de courant) pour atteindre la position qui lui a été assignée. Si celle-ci dépasse les limites physiques de déplacement (parce que le plateau est en butée sur la structure de la tourelle par exemple), alors les engrenages dans le servos pourraient casser, si ce n’est pas la structure ou même l’alimentation qui ne tient pas la forte demande en courant. Pour ce faire, il faut y aller pas à pas, en assignant une valeur fixe au servo pour déterminer son MAX et son MIN (350 correspond à peu près au milieu chez moi, c’est une valeur sûre je pense : pwm.setPWM(0, 0, 376)).
Cela étant dit, voici une démo :
Bon, là c’est facile, la charge ne pèse rien. Mais mon robot aura une tête bien remplie, probablement autour de 400g d’après mes estimations. On va donc lui coller une charge de 450g et voir ce que ça donne.
Nouvelle démo, plus chargée. Et ça marche très bien ! 🙂
Rien de bien fou dans cet article, on va utiliser un Arduino pour piloter :
Un bargraphe de 5 LEDs, qui sera parfait pour mimer l’animation de la bouche quand le robot parlera
Un Led blanche puissante, j’en utiliserai 2 pour les phares
Un buzzer, qui permettra à la partie électronique d’émettre des sons facilement, sans remonter par le « cerveau »
Des interrupteurs, qui permettront d’intéragir de façon basique avec le robot (activation d’un mode spécifique, répondre à des questions, mise en veille… à voir)
J’ai trouvé le bargraphe sur ebay, il n’est pas cher et conviendra parfaitement pour ce que je compte en faire. Ceux que j’avais testés précédemment étaient constitués de 10 LEDs disposées verticalement. Celui-ci n’en contient que 5 et sont disposées horizontalement. Les specs indiquent un courant direct de 20mA, et une chute de tension de 2.4V pour les LEDs jaune. Chaque LED du bargraphe est connectée à une sortie digitiale de l’Arduino, suivi d’une résistance (130 Ohms environ).
Les LEDs utilisées pour les phares sont des LEDs blanches assez puissantes (dispos ici) (3.5V, 20 mA). Elles ne tirent pas trop de courant, les 20mA correspondent à ce que peut délivrer sans problème une sortie digitale d’Arduino, je ferai donc l’impasse sur le transistor pour piloter ces LEDs de « puissance ». Ici on prévoira une résistance de 100 Ohms environ (je mesure une intensité de 12 mA, très bien). Par défaut les pins digitaux d’un Arduino sont configurés en INPUT, il faut bien penser à les déclarer en OUTPUT, sinon le comportement ne sera pas celui attendu (lumière très faible lors de mes tests).
Le buzzer vient de chez Banggood également. Il se connecte sur une sortie digitale. J’ai ajouté une petite résistance par sécurité (environ 30 Ohms) pour ne pas dépasser les 20 mA préconisés pour le Arduino (je mesure une intensité max de 10 mA). Côté code, je n’ai rien inventé et j’ai utilisé ce qui est décrit dans cet instructable. Cette approche n’utilise pas la fonction tone() disponible sur la plateforme Arduino, qui impose quelques contraintes (utilisable sur une seule sortie en même temps et interfère avec les sorties PWM de l’Arduino).
Enfin, la connexion d’un interrupteur sur une entrée digitale de l’Arduino est très basique, à une subtilité près : quand l’interrupteur est ouvert, on ne peut pas laisser l’entrée digitale flottante (l’état serait instable, oscillant aléatoirement entre HIGH et LOW). On doit donc ajouter une résistance de rappel ou tirage (pull up/down resistor) qui permettra de stabiliser l’état lorsque que le bouton n’est pas pressé. Ce qu’il faut savoir, c’est que toutes les e/s digitales d’un Arduino disposent d’une résistance de tirage (pull up) interne (20 à 50 KOhms). Pour simplifier le montage, on activera donc la résistance interne de tirage pour chaque entrée digitale connectée à un bouton, et l’autre extrêmité du bouton sera liée à la masse. Quand le bouton sera pressé, l’état lu sur le pin sera donc LOW.
Pour activer la résistance de pull up :
pinMode(buttonPin, INPUT);
digitalWrite(buttonPin, HIGH); // active la resistance de tirage interne
ou directement :
pinMode(buttonPin, INPUT_PULLUP);
L’instructable disponible ici, apporte beaucoup d’informations concernant l’utilisation des boutons. Car si le câblage est simple, utiliser correctement un bouton peut nécessiter quelques ruses (debouncing, appui prolongé…).
Démonstration en vidéo (le « phare » clignote en permanence, quand on appuie sur le premier bouton, une animation sur le bargraphe est déclenchée, quand on clique sur le second bouton, le buzzer joue le French Cancan 😉 ) :
J’ai prévu d’utiliser un Arduino Mega pour jouer le rôle de « moelle épinière » de mon prochain robot. C’est cette partie qui permettra l’acheminement des différents messages entre le cerveau (un mini-PC) et le corps (châssis, moteurs, capteurs) du robot.
Cette partie sera donc le carrefour de nombreux échanges entre différents types de périphériques, avec leurs contraintes (protocoles différents, performances, utilisation d’interrupts externes etc.).
Le but de ce PoC (Proof of Concept) est de démontrer que le Arduino Mega est bien capable d’assurer ce rôle. Plus précisément, il doit être capable de gérer en parallèle :
des périphériques sur bus SPI
des périphériques sur bus i2c
la communication série avec un PC
la communication avec un autre Arduino (Nano) sur le bus i2c
le pilotage de pins digitaux
la lecture de pins analogiques
des encodeurs très rapides avec des interrupts externes
Et tout ça pour une emprunte mémoire supportable.
Pour ce faire, j’ai fait un petit montage composé d’un Arduino Mega, d’une matrice de LEDs (SPI), d’un moteur CC et son encodeur (les 2 pins étant attachés à des interrupts externes), un tableau de 10 LEDs (je n’en utiliserai que 8, pilotés directement par des sorties digitales + une résistance de 150 Ohms), une photorésistance (sur pin analogique), un écran OLED (i2c), un capteur thermique IR de 8 cellules (i2c), un Arduino Nano (i2c) avec 2 capteurs ultrasons.
Le schéma suivant sera plus parlant :
L’écran permettra d’afficher un certain nombre d’informations (température la plus élevée sur le capteur thermique, ticks moteurs, les distances relevées par les capteurs ultrasons), le tableau de 8 LEDs affichera la cellule la plus chaude détectée par le capteur thermique) et la matrice de LEDs dessinera une ampoule si une forte lumière est détectée ou un smiley si la température la plus élevée relevée par le capteur est inférieure ou égale à 50°C et un cœur si elle les dépasse.
Pour mesurer l’intensité lumineuse, on utilisera une photorésistance (1-10 KOhms) : sa résistance varie en fonction du niveau lumineux. Un simple pont diviseur de tension (avec une résistance de 10 KOhms) nous permettra d’obtenir des variations de tension sur le port analogique que l’on pourra alors facilement mesurer. Un tuto ici.
L’Arduino Mega est le maître du bus i2c. Pour pouvoir communiquer avec un autre Arduino (Nano ici), ce dernier doit être utilisé en tant qu’esclave sur le bus i2c. Tout ce qu’il faut savoir est ici.
Les détails concernant le moteur (et son encodeur) utilisé est disponible ici. Et voici le détail des connexions :
Côté Arduino Mega, on est confortable, le programme occupe 7% du stockage et utilise 11% de la mémoire. Pour le Nano, la question ne se pose même pas : il ne fera que relever les mesures de capteurs ultrasons.
Lors des premiers essais, des problèmes de performances sont apparus et on pouvait observer une légère latence du système, de l’ordre des 200ms à vue de nez. En pratique, si j’allume la lumière sur la photorésistance, la matrice de LEDs affiche l’ampoule 200ms plus tard. Ce n’est pas énorme, mais ça se sent et ça pourrait poser des problèmes, pour la gestion des obstacles par exemple.
Je me suis vite aperçu que cela venait du rafraîchissement de l’écran OLED : à chaque tour de la boucle principale du programme, l’écran était entièrement redessiné. Je n’ai pas besoin de le mettre à jour si souvent, il suffirait de le faire une fois toutes les 200ms pour avoir un affichage assez fluide (sachant que pour mon utilisation, je pourrais même le rafraîchir toutes les secondes seulement).
Et c’est très facile à faire, grâce à la fonction millis(). Elle renvoie le nombre de millisecondes écoulées depuis que le Arduino est sous tension (le compteur revient à 0 après environ 50 jours de fonctionnement). A partir de là, il suffit de vérifier à chaque tour de la boucle principale qu’au moins 200ms se sont écoulées depuis le dernier rafraîchissement de l’écran. Si ce n’est pas le cas, on ne le redessine.
Cette petite astuce a réglé les problèmes de latence, l’Arduino Mega pilote le tout à merveille, la démo en vidéo :
