Electronique – Page 2 – 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 et interférences électromagnétiques

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 :

Récepteur/émetteur IR : clonage d’une télécommande

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.

Ecran OLED SSD1306 128×64 SPI

Cet article fait suite à celui-ci.

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

Arduino Mega… Mini !

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

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

Bargraphe, Led, buzzer et bouton avec un Arduino

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 😉 ) :

Le code correspondant est disponible ici