Robotique – Le Labo : drones FPV, impression 3D, robotique et autres projets DIY (Arduino…)

BB-8 DIY (contrôlé par la Force ;)

Après quelques mois passés à bosser sur un gros projet, je m’offre une petite pause de fun pour un petit BB-8 fait maison, parce qu’il est vraiment trop mignon 😉 (vidéo disponible à la fin de l’article).

A la base, je voulais juste faire une une figurine et puis je me suis dit que ça serait sympa de l’animer un peu. Alors il ne se déplace pas, mais il tourne la tête, émet des sons et détecte les obstacles devant lui : un simple passage de la main devant lui déclenchera différentes animations.

Ci-dessous, l’ensemble des éléments utilisés (électronique, pièces imprimées, capteur ultrasons, servomoteur…). Le modèle 3D n’est pas de moi, il vient d’ici. J’ai fait des trous dans le corps pour pouvoir passer l’axe de la tête et imprimé des joints pour assembler le tout (+ le support).

Après ponçage, enduit, peinture et vernis, il ne reste plus qu’à assembler le tout.

L’image suivante représente le « cerveau » de BB-8 : un simple Arduino Nano, un buzzer et 3 borniers à visser (alimentation et capteur ultrasons).

Le code est disponible ici. C’est pas super propre mais bon, ça fait l’affaire. J’ai eu de petits soucis d’incompatibilité entre différentes librairies car elles utilisaient les mêmes interrupts : Servo, NewPing, Tone (ou même NewTone pour éviter le conflit avec NewPing). Au final, je n’utilise aucune librairie pour piloter le buzzer).

Vue du boitier une fois tous les composants en place :

Le servomoteur est fixé au centre du boitier :

Pour prolonger l’axe du servomoteur, j’ai utilisé un tube (qui remontera jusqu’à la tête) et imprimé 2 joints qui s’emboîtent dans le tube de PVC : le premier a un emplacement prévu pour intégrer le connecteur à la tête du servomoteur (en noir, que j’ai découpé d’un support vendu avec le servo) et le second qui permet de faire la jonction avec la tête).

Au passage, le socle au dessus du servo est constitué de 2 pièces : la première permet de surélever le support au dessus des vis du servo et le second est un cône qui donnera l’illusion d’une dune (le sable a été saupoudré sur une couche de colle à bois) parce qu’on rencontre BB-8 dans le désert ;).

Aperçu du système de rotation de la tête :

A l’arrière : un interrupteur et un connecteur USB (le robot peut fonctionner sur USB ou sur pile, au choix) :

Et voilà !

Pour finir, une démonstration de notre petit BB-8 en vidéo 🙂

Tous les fichiers sont disponibles ici (modèles Sketchup, fichiers STL et code pour le Arduino Nano). Les fichiers STL du robot en lui-même sont à récupérer sur Thingiverse comme indiqué plus haut.

Projet R.I.P.E.R. (Robotic Intelligent Platform for Entertainment and Research)

Désolé, ça commence par beaucoup d’explications textuelles, mais des schémas plus éloquents sont à la fin 🙂

J’ai passé ces deux derniers mois à tester pas mal de choses : moteurs, capteurs, amplis audio, écrans, microcontrôleurs, matériaux, montages, mini-PC… C’était intéressant, mais le but est bien évidemment d’utiliser tout ça pour créer un robot 🙂

Dans ce billet, je vais essayer de formaliser toutes les idées qui me trottent dans la tête depuis quelques temps et décrire où je veux aller.

Jusqu’ici j’ai fabriqué quelques robots assez simples, avec des comportements limités à des tâches précises (et avec un petit microcontrôleur en guise de cerveau). Une fois le robot terminé, il l’était vraiment et je passais à autre chose. Cette fois, je veux réaliser une véritable plateforme robotique, très polyvalente pour explorer différents domaines de la robotique :

Le SLAM pour Simultaneous Localization And Mapping (ou cartographie et localisation simultanées). C’est un ensemble de techniques qui permettent à un robot de connaître sa position et de découvrir son environnement.
La synthèse vocale (TTS : Text To Speech), pour lui permettre de communiquer avec des êtres humains par la voix.
La reconnaissance vocale (SR : Speech Recognition ou STT)
Langage, conversation avec un humain
Intelligence artificielle et apprentissage
Utilisation d’internet (accès à des services, bases de connaissances…)
Vision : reconnaissance de formes et de visages, tracking
Algorithmes d’évitement d’obstacles (Virtual Force Field algorithm)
Pilote de la domotique
Télé-présence et surveillance
« Humanisation » : permettre au robot d’exprimer des émotions (mouvements, yeux…), lui donner un comportement moins prévisible avec des micro gestes aléatoires (clignement des yeux…), des tics de langages etc.
Extensibilités : possibilité de lui ajouter des modules pour lui donner de nouvelles capacités (module pour analyser la qualité de l’air, piloter la domotique, changer la fonction de ses bras/mains : poignée, pince, lasers…)
Personnalité, comportements, humeurs, humour…
…

La plateforme devra être suffisamment évoluée pour approfondir tous ces sujets sans devoir refaire un nouveau robot à chaque fois. En gros, il ne sera jamais vraiment terminé 🙂

Les applications qui en découlent sont illimitées :

Accompagnement, stimulation et surveillance/assistance des personnes âgées ou en difficulté
Télé-présence : pouvoir prendre le contrôle du robot à distance et se déplacer / communiquer grâce à lui, comme si on y était
« Chef d’orchestre » domotique et sécurité (détection et signalisation d’intrus, pilote du chauffage, de la télé, de la musique, de l’humidité, simulation de présence…)
Jukebox à la demande
Occuper le chat (en le faisant jouer avec un laser etc.)
Assistant personnel à domicile (domotique, lecture des e-mails et autres notifications, actualités, météo, discussions, gestion de l’agenda et rappel de rendez-vous, mémos, réveil…)
Coach personnel
Station d’analyse de l’air, détection de produits dangereux/toxiques
Exploration de zones dangereuses/inaccessibles pour l’homme
Conquérir le monde…

Pour créer cette plateforme voici les composants que je compte utiliser (dont la plupart ont été testés dans les articles précédents) :

Le cerveau supérieur : un mini-PC sous forme de clé HDMI avec un processeur Intel Atom CherryTrail (4 coeurs), 4Go de RAM, 32 Go de mémoire eMMC. Ces « PC » consomment peu, sont très légers et compacts, offrent des possibilités intéressantes en terme d’IA, sans compter l’accès au Bluetooth et au Wifi (et donc à Internet). Pour une centaine d’euros !
La moelle épinière : un Arduino MEGA (Pro Mini), qui aura la charge de transmettre les messages entre le cerveau (mini-PC) et le reste du corps du robot (capteurs, actuateurs : moteurs, écrans, HP…).
Un anneau de sonars : 12 capteurs ultrasoniques SRF05 pilotés par un Arduino Nano, lui-même connecté à la moelle épinière par le bus I2C. Les capteurs détecteront les obstacles tout autour du robot.
Capteurs d’environnements : boussole (référentiel directionnel), détecteur de luminosité (LDR), détecteur de distance IR (pour éviter les chutes)
La tête : webcam USB avec microphone pour récupérer l’image et le son (et la voix) (Logitech c920), matrice de capteurs thermiques pour identifier les sources de chaleur (humains, animaux, feu…) (TPA81), Pixy CMUCam5 pour reconnaître et traquer des objets, 2 matrices de 8×8 LEDs pour émuler les yeux, un bargraphe de 5 LEDs pour animer la bouche, émetteur/récepteur IR pour piloter certains appareils, des LEDs puissantes pour éclairer dans l’obscurité. Le tout sera piloté par un autre Arduino Nano, lui-même connecté à la moelle épinière par le bus I2C.
Le cou : une tourelle « pan-tilt » constituée de 2 servomoteurs pour bouger la tête de haut en bas et de gauche à droite.
Un ampli et un haut-parleur pour émettre la voix du robot, de la musique ou des sons. Connecté sur la sortie son du mini-PC.
Quelques périphériques pour interagir « manuellement » avec le robot (écran OLED, boutons, buzzer).
HUB USB : pour connecter le mini-PC, la webcam, l’Arduino MEGA (+ de nouveaux périphériques)
Bras : 3-4 servomoteurs et la possibilité d’y attacher un module (pince, laser…)
Des cartes de contrôle des moteurs et servomoteurs (raccordés à la moelle épinière)
Moteurs CC avec encodeurs et un châssis. J’ai opté pour un châssis à chenilles, type tank : facile à diriger et une meilleure adaptation au terrain que les roues.
Alimentation : une première batterie Ni-MH de 7.2V / 5000mA pour les moteurs CC et servomoteurs (bras et cou). Une seconde batterie identique pour tout l’électronique (bas niveau, hub et PC). J’ai opté pour du Ni-Mh pour des raisons de sécurité (je veux pouvoir le laisser allumé même si personne n’est à la maison). La moelle épinière (MEGA) surveillera l’état des batteries. Le robot pourra aussi fonctionner sur une alimentation externe (12 V).

Pour concrétiser tout ça, voici une « maquette » de R.I.P.E.R., ce n’est pas très joli, mais ça a le mérite de clarifier un peu la cible 😉

Le schéma suivant décrit l’architecture du robot et recense toutes les interfaces nécessaires. Le détail de chaque carte n’est pas représenté pour faciliter la lecture. Cliquer sur le schéma pour le voir en taille réelle :

Et voilà, il y a plus qu’à…;)

Boussole électronique : HMC5883 / HMC5983

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.

Voici la démo en vidéo :

Le code source est disponible ici.

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.

Pixy CMUcam5 : un capteur de vision intelligent

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 🙂

Tourelle Pan Tilt (SPT200) et contrôleur de servos Adafruit i2c

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 ! 🙂

PoC de l’étage électronique : Arduino Mega + 10 périphériques

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 :

PoC_mega

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 :

Les librairies utilisées sont les suivantes :

U8glib (pour l’écran OLED)
Encoder (pour l’encodeur)
LedControl (pour la matrice de LEDs)
Wire (pour l’i2c)
NewPing (pour les sonars connectées au Nano)

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 :

Code source pour l’Arduino MEGA
Code source pour l’Arduino Nano

Pilotage d’un module MAX7219 par Arduino (yeux)

Les yeux servent à voir, mais aussi à communiquer une humeur ou des émotions. Le premier aspect sera traité plus tard avec des caméras et différents capteurs. Le second est celui qui nous intéresse aujourd’hui.

Je viens de recevoir quelques modules composés d’un MAX7219 qui pilote une matrice de 8×8 LEDs. Ces modules se pilotent en SPI et peuvent être chaînés. J’en alignerai donc 2, un pour chaque œil.

Pour les connexions MAX7219 –> Arduino :

DIN –> MISO
CLK –> MOSI
CS –> SS

Ces modules valent 2€ l’unité et sont très faciles à contrôler.

Il y a un vaste choix de librairies, je n’en ai testé qu’une : LedControl. Elle fait très bien le boulot et son utilisation est enfantine. Le principe est le suivant : pour stocker un état de la matrice, on utilise un tableau de 8 octets. Chaque octet représente une ligne de la matrice, et chaque bit de cet octet représente l’état d’une LED de la ligne de la matrice (1 = LED allumée, 0 = LED éteinte).

Voici le résultat des premiers essais :

Le code correspondant est disponible ici.

Un autre exemple sympa ici. Ou encore ici.

Utilisation d’un écran OLED avec un Arduino

Même si mon robot disposera de la parole pour communiquer avec un humain, il est toujours pratique d’avoir un écran pour afficher des informations utiles. De plus, l’électronique de bas niveau (Arduino) n’aura pas accès à la synthèse vocale directement, il sera dépendant du « cerveau ». Pour débugger et afficher des messages directement depuis l’Arduino, un écran sera donc bien utile.

J’avais d’abord regardé du côté des écrans LCD classiques, comme celui-ci :

Finalement, ils sont lourds et plus grands que je ne l’imaginais. Je suis alors tombé sur des écrans OLEDs (SSD1306), et ils ont tout pour eux ! Ils sont compacts, légers, offrent une belle qualité d’affichage et ils ne coûtent rien 🙂 (environ 5€).

J’avais commandé ce modèle, mais il n’est plus disponible, celui-ci semble identique. Il se décline en nombreuses versions (taille, connexion : SPI, I2C, Série). J’ai opté pour une version I2C. Il faut savoir qu’il s’agit d’un clone chinois-pas cher. « L’original » étant disponible chez Adafruit (pour plus cher bien sûr). Adafruit a mis à disposition une librairie pour piloter ces écrans avec un Ardino, elle est disponible ici.

Je me suis empressé de raccorder mon écran OLED à un Arduino pour faire tourner la démo :

Ca marche très bien ! 🙂 Attention, dans le cas des clones (en 128×64), l’adresse du module i2c est 0x3C (au lieu de 0x3D comme indiqué dans le code de démo de Adafruit).

Donc, ça marche bien oui, mais cet exemple, avec toute la librairie prend énormément de place sur un pauvre petit Arduino (63% de l’espace de stockage et 76% de la mémoire dynamique) ! Ce qui ne laisse plus beaucoup pour faire autre chose.

Sachant que je n’ai pas besoin de tout ce qui est graphique, j’ai trouvé une librairie basique qui ne gère que le texte. C’est evilOLED par evilNick et elle est disponible ici.

Et c’est tout de suite beaucoup mieux : la démo ci-dessous n’occupe de 12% de stockage sur l’Arduino et 3% de sa mémoire dynamique.

L’essentiel est démontré (l’écran répond à mes attentes). Il faudra cependant tuner un peu cette librairie (ce n’est pas trop compliqué) car elle a ses limites (seuls les chiffres, les lettres majuscules et quelques caractères sont gérés en l’état). Il doit être possible de réutiliser la table de caractères d’Adafruit pour disposer d’un maximum de caractères.

EDIT 06/11/2015 : je viens de m’apercevoir que cette librairie (evilOLED) est très particulière ! En fait, elle intègre sa propre implémentation du protocole i2c pour pouvoir utiliser l’écran sur n’importe quel pin digital du Arduino (ce qui peut être pratique). Donc si on l’utilise sur les pins dédiés à l’i2c, avec d’autres périphériques i2c pilotés par la librairie classique (Wire), il y aura des conflits sur le bus i2c et il deviendra inutilisable.

Je me suis donc rabattu sur la librairie u8glib, qui est très performante, facile à utiliser (sans les limitations de caractères vues précédemment), propose de jolies polices et a une emprunte mémoire acceptable (35% de stockage et 12% de mémoire). Sur un Arduino Mega ça le sera encore plus.

Voici une démo avec la librairie u8glib (j’affiche la plus haute température relevée par un TPA81, les ticks comptés par un encodeur placé sur un axe de moteur et les distances relevées par 2 sonars (HY-SRF05).

Enfin, il y a d’autres librairies qui semblent très intéressantes :

Montage du chassis Iron Man-4 de Keenlon

Je viens de recevoir ma première commande passée chez Robotshop, et en particulier le châssis tank Iron Man 4 de Keenlon (ou Keenon, je ne sais toujours pas).

La fiche technique du châssis est disponible sur le site de Robotshop, ici.

Roues en aluminium et chenilles en nylon
2 puissants moteurs à engrenages métalliques, avec de l’espace pour 2 encodeurs
Deux roulements dans chaque roue
Capacité de transport jusqu’à 4,5 kg (10 livres)
Moteurs de 3 à 9V (courant de bloquage : 4 A par moteur, courant hors charge : 300 mA par moteur)
Dimensions : 168 × 226 × 90 mm
Poids : 1,1 kg

Revue du montage et premières impressions.

Contenu du colis : on retrouve tout le nécessaire, 3 clés pour le vissage et une documentation.

Montage des roulements (chaque bloc de roulement est déjà pré-assemblé).

Le montage des moteurs est aussi très facile.

Ajout des engrenages et de l’étage supérieur. A noter que contrairement à ce que décrit la notice, les 2 blocs d’engrenages sont déjà pré-assemblés. J’ai dû limer légèrement les barres des moteurs pour réussir à fixer les engrenages. Pour la fixation de la partie supérieure, il n’y a pas d’écrou, le pas-de-vis est directement intégré au châssis.

Une tige fine en acier permet de refermer les chenilles. Pour le moment je ne les ai pas enfoncées à 100% (j’aurai sans doute besoin de re-démonter le châssis).

Montage terminé avec l’ajout de la façade avant (à noter : des écrous différents de ceux de la notice).

Le châssis semble de bonne qualité et solide. Quelques imperfections sont présentes mais faciles à corriger. J’ai un doute sur le matériau utilisés pour les 2 engrenages, je ne sais pas dire si c’est de l’alu ou du plastic, on verra à l’usage. Concernant les chenilles, la fixation avec la tige de fer est efficace, mais une fois les chenilles installées, je ne suis pas sur qu’on puisse les démonter de nouveau (l’extrémité de la tige est rugueuse, une fois insérée à fond, ces aspérités se bloquent dans les chenilles).

Pour finir, une courte vidéo d’un moteur en action :

Robot à base d’Arduino, Bluetooth et pilotable avec un téléphone (WP8)

Pas d’articles depuis un moment, mais je n’ai pas chômé pour autant !

Après avoir imprimé un peu tout et n’importe quoi, il était temps d’utiliser la bête pour imprimer un châssis de robot. C’était quand même le but initial 🙂

J’ai fait joujou avec des microcontrôleurs Picaxe, je voulais passer sur du Arduino (hardware Open Source), techno beaucoup plus répandue et avec une très grosse communauté.

Pour découvrir l’Arduino, un objectif simple : fabriquer un petit robot roulant, capable de se déplacer de façon autonome mais également d’être contrôlé à distance via un périphérique mobile (téléphone Lumia 920 sous Windows Phone 8 dans mon cas). Il utilise un télémètre à ultra-sons pour détecter les obstacles et une photorésistance pour détecter les variations de lumières.

Finalement, la prise en main de l’Arduino est un jeu d’enfant. On n’est pas dépaysé après avoir utilisé du Picaxe (qui au passage restent des petits microcontrôleurs super, je n’ai pas vraiment de reproche à leur faire !).

Le prototypage de la partie électronique a été très rapide.

Voici à quoi le robot devrait ressembler (modélisation Sketchup).

Ci-dessous, la vue « explosée » du robot où l’on voit bien les différentes pièces imprimées qui le composent.

Quelques heures plus tard, tout est imprimé 🙂

J’en profite pour préciser quelques astuces. J’ai remarqué que les pièces imprimées, bien que très solides, présentent une faiblesse entre les couches. Quand une pièce « casse », ce n’est jamais une vraie cassure, mais un décollage de 2 couches superposées. Par exemple, quand les parois d’une boîte sont fines, elles se décollent du socle assez facilement.

Pour pallier ce problème, j’ai pris l’habitude de systématiquement consolider les jonctions de plans avec une petite « pente ».

Quelques bandes en relief (3 mm d’épaisseur) sur le fond renforcent aussi la structure. Des emplacements sont prévus pour glisser des écrous. Cela permettra d’assembler les différentes parties avec des vis. Nophead utilise cette astuce pour les pièces de la Mendel90. C’est parfait pour avoir un beau rendu, une bonne solidité et un assemblage facilité.

Même principe de renforcement pour le pare-chocs. Ici, on voit bien que les contraintes appliquées sur les zones où la paroi est la plus fine, sont fortement absorbées par la « pente ».

Un traitement d’enduit en bombe, suivi d’un léger ponçage et d’une couche de peinture en bombe permet de lisser convenablement les pièces et d’avoir un rendu plus « pro ».

Avant/Après lissage, ponçage et peinture.

Fixation de la roulette sur son support imprimé, toujours avec le système des écrous glissés dans la pièce.

Pour que l’électronique soit bien fixée à l’intérieur, j’ai réalisé un petit socle aux dimensions intérieures du robot. 3 écrous viennent assurer que le tout sera bien bloqué grâce à des vis sur la paroi extérieure du robot.

L’ensemble de l’électronique sur son support.

1er étage : la carte Arduino
2ème étage : carte de contrôle des moteurs
3ème étage : carte custom pour connecter avec un minimum de fils l’électronique au reste du robot (piles, LEDs, module Bluetooth, moteurs, etc.)

Toutes les pièces sont peintes, une couche de vernis en bombe a été appliquée pour protéger la peinture.

On peut passer à l’assemblage !

Supports des moteurs et des piles.

Tout est maintenant raccordé ! Les écrous sont en place dans les 4 coins… on peut refermer le petit gars 🙂

Tadaaaammm !

Des ouvertures ont été prévues pour le port USB et l’extrémité du module Bluetooth, histoire de ne pas affaiblir le signal. Des aérations permettent d’évacuer la chaleur (en particulier celle venant de la carte des moteurs).

Sous tous les angles :

A côté de ça j’ai développé une appli Windows Phone 8 pour contrôler le robot. Depuis cette version, Microsoft a laissé un peu plus de liberté aux développeurs pour manipuler le Bluetooth du téléphone. Voici donc la réplique d’une magnifique manette de Nintendo 😀 Le pavé directionnel dérive d’une librairie Open Source.

Fonction de chaque bouton :

Start : connexion au robot
Select : bascule du mode autonome au mode piloté via Bluetooth
A : Allume/éteint les feux
B : Klaxon

Pour finir, voici la bête en action !