Auteur/autrice : LordGG

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

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 :

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

Surveiller la décharge de la batterie

Il est souvent utile de pouvoir surveiller l’état de charge des batteries d’un dispositif électronique (et d’en déduire une estimation de son autonomie restante).

Dans le cas d’un robot, celui-ci pourra signaler que ses batteries ont besoin d’être rechargées, ou même se rendre de lui-même à une station de chargement.

Quand une batterie se décharge, la tension à ses bornes diminue. La solution consiste donc à mesurer cette tension. Et c’est exactement à cela que servent les entrées analogiques des Arduinos. Attention cependant, ces entrées ont leur limite. Pour la plupart des Arduinos, elles mesurent des tensions comprises entre 0 et 5V.

Si la batterie délivre plus de 5V, elle risque de détruire l’entrée, il est donc nécessaire de s’assurer que les 5V ne seront en aucun cas dépassés. Pour ce faire, nous utiliserons un pont diviseur de tension, soit 2 résistances. Cette page explique très bien le principe.

Il s’agit ici de déterminer quelles résistances utiliser. Plus leurs valeurs sont élevées, et moins de courant sera gaspillé dans ce montage. Une résistance totale de 10 à 20 KOhms fera l’affaire.

Avant toute chose, il faut identifier quelle sera la tension maximale de la batterie. Dans mon cas, j’utiliserai une batterie de 7.2V qui prendra le relais de l’alimentation continue en 12V lorsque celle-ci sera coupée. Je prévois une marge de sécurité et je détermine que la tension maximale en entrée ne dépassera en aucun cas 14V. Le but du jeu consiste à ramener cette plage de 0 à 14V sur une plage de 0 à 5V, pour que l’entrée analogique de l’Arduino puisse l’exploiter.

Soit on sort la calculette, soit on passe par un calculateur en ligne :

01_calcul_pont_diviseur

Dans mon cas, pour obtenir une tension de sortie de 5V à partir d’une source de 14V, je peux utiliser un pont diviseur de tension constitué d’une résistance R1 de 15 KOhms et d’une résistance R2 de 8.2 KOhms (d’autres combinaisons sont évidemment possibles).

On peut vérifier pour la forme :
Vout = Vcc x (R2/(R1+R2)) = 14 x (8200/(15000+8200)) = 4.948… V

Comme le montre la formule, la tension de sortie est proportionnelle à la tension d’entrée.

Côté Arduino, la fonction analogRead(pin) permet de lire la tension mesurée sur le pin passé en paramètre. Elle retourne une valeur comprise entre 0 et 1023, qui représente une tension allant de 0 à 5V sur le pin analogique (ou proportionnellement de 0 à 14V aux bornes de la batterie). On divisera la valeur mesurée par 73.07 (car 1023/14 = 73.07…) pour obtenir la tension aux bornes de notre batterie.

Voici le montage, ultra basique :

Et on peut constater que la tension calculée par le Arduino est très proche de la tension mesurée avec un voltmètre 🙂

Code source disponible ici

Ajout d’une alimentation externe à un hub USB non-alimenté

J’aurai bientôt besoin d’un hub USB pour connecter plusieurs périphériques à une clé PC (type Intel Compute Stick). Je ne veux pas que la clé soit responsable d’alimenter le hub et tout ce qui y sera connecté (je ne suis d’ailleurs pas sûr qu’elle en soit capable).

Il me faut donc un hub USB alimenté. Le problème est que ce type de hub est souvent : plus cher, plus encombrant et un peu plus difficile à trouver. L’astuce va donc consister à récupérer un hub USB non-alimenté, compact et léger et de lui ajouter une alimentation.

J’ai commandé celui-ci pour sa taille et son poids minimalistes.

Le principe est tout simple : un câble USB est constitué de 4 fils (+5V, Masse, Data+ et Data-), il suffit d’apporter les 5V d’une autre source que le connecteur hôte.

Attention : il est très important de penser à supprimer la connexion 5V partant vers le périphérique hôte. Sinon, le port USB (du PC par exemple) pourrait griller s’il n’est pas protégé. Les 5V seront apportés au hub par une source externe, tout en conservant la connexion de données.

01_powered_hub_schema

J’ai d’abord démonté le hub pour voir si je pouvais faire la modification à l’intérieur, mais ce n’est pas gérable, tout est beaucoup trop petit et en double couche :

OLYMPUS DIGITAL CAMERA

On va donc s’intercaler avant le hub et le PC :

A noter que mes connexion sont droites entre les 2 connecteurs parce que le connecteur de droite est monté à l’envers. Toujours bien vérifier les standards :

05.USBCe n’est pas la version finale, je compte bien intégrer ça plus proprement. On peut voir dans la vidéo que même lorsque le PC n’est pas connecté, le hub est alimenté, et que le PC reconnaît les périphériques connectés.

 

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 :
01_ecran_lcd_classique

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€).

02_ecran_oled

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 :

Autonomie et alimentation d’un robot

Quand on fabrique un robot, se pose toujours la question de son l’alimentation en énergie : batteries (Ni-Mh, Li-Po, Plomb …?) ou alimentation fixe ? quelle autonomie ? caractéristiques etc.

Mon besoin :

  • Le robot doit pouvoir être opérationnel 24h/24
  • Il doit disposer d’une certaine autonomie : 2h serait un bon début
  • Sécurité : le robot pourra être actif lorsqu’il est seul. Je préférerais qu’il ne brûle pas la maison 🙂

Mon choix actuel va se porter sur des batteries NiMh. Bien que les LiPos présentent beaucoup d’avantages par rapport aux NiMh (poids, solutions de contrôle de charge, capacité…), elles restent réputées bien moins fiables. Une batterie LiPo mal gérée peut exploser, elles sont plus sensibles aux chocs… Les NiMh sont un compromis acceptable étant donnée leur fiabilité éprouvée.

L’option d’une batterie au plomb a été envisagée. Elles ont de nombreux avantages (facilité à charger, puissance, robustesse, prix…), mais elles sont très lourdes ! Pour un robot de taille moyenne, ce n’est pas envisageable.

Le robot devra donc fonctionner en étant branché sur le secteur pour pouvoir être opérationnel 24/24. Il devra aussi disposer de batteries de secours qui prendront le relais en cas de perte de l’alimentation fixe.

Idéalement, le robot pourrait recharger ses batteries en même temps qu’il fonctionne sur secteur. J’ai fait pas mal de recherches concernant le chargement des batteries, et ce n’est pas trivial ! Pour les LiPos, ils existent des contrôleurs de charge qui rendent la chose plus facile. Malheureusement, pour charger des batteries NiMh de façon sécurisée et optimale, cela semble plus délicat. Il faut surveiller la température ou la tension de la batterie pour savoir quand stopper la charge. Si c’est aussi vrai pour les LiPos, beaucoup plus de solutions faciles à intégrées sont disponibles.

Je vais donc faire le choix de la faciliter dans un premier temps : le robot fonctionnera sur secteur (via un adaptateur) lorsqu’il y sera connecté. En cas de perte d’alimentation fixe, ils basculera automatiquement sur ses batteries jusqu’à ce que l’alimentation fixe revienne. Il sera donc toujours nécessaire de charger manuellement ses batteries quand elles seront déchargées, mais le robot pourra être opérationnel en permanence.

Pour réaliser ce comportement, c’est très facile ! Il suffit de 2 diodes (schottky de préférence, pour limiter la chute de tension), et le tour est jouer. Une seule condition à respecter (au delà des caractéristiques adaptées pour la diode) : l’alimentation fixe doit avoir une tension supérieure à la tension de la batterie (d’au moins la valeur la tension de seuil de la diode).

Voici le circuit, ultra basique :

alim_secours
http://www.sonelec-musique.com/electronique_realisations_alim_secours_bat_001.html

Pour des explications plus détaillées, je recommande cet excellent site qui explique absolument tout !

En pratique, on peut voir que lorsque je coupe l’alimentation fixe, la batterie prend automatiquement le relais, et inversement. Le tout sans perturber la carte Arduino qui continue à fonctionner normalement (pas de coupure ou de redémarrage), la bascule se fait donc de manière transparente.

On ne le voit pas bien sur la vidéo, mais j’ai un programme qui tourne en boucle sur le Arduino qui contrôle la LED embarquée. Elle s’allume de plus en plus longtemps au fil du temps. L’exécution du programme n’est pas affectée par le changement de source d’alimentation, la carte de reboot pas.

J’y reviendra plus en détail dans un autre article. J’ai opté pour l’utilisation de 2 batteries NiMh 7.2 V 5000 mAh (l’une pour les moteurs CC et servomoteurs et l’autre pour l’électronique). L’alimentation secteur sera de 9 ou 12V à 5-10A. Des régulateurs de tension remettront tout ça à 5V pour l’électronique. J’utiliserai 2 diodes Schottky SR810 (8A/100V, 0.50€).

Une alternative que je n’ai pas abordée, mais qui peut-être pratique : l’utilisation de batteries externes pour smartphone/tablette. Je crois qu’il s’agit en général de batteries de type Li-Ion. Ces batteries externes se trouvent un peu partout à de très bons prix. Et l’avantage, c’est qu’elles embarquent déjà tout l’électronique pour la gestion de la charge, le tout pour un poids intéressant. Pour des projets pas trop gourmands en courant, ou pour la partie électronique d’un robot, ça peut être une solution. J’envisage cette option en complément si nécessaire.

Et pour finir, depuis quelques années, on trouve des batteries LifePo4, avec des avantages comparables aux LiPo, mais bien plus stables (et donc moins dangereuses), à creuser…

L’ampli audio PAM 8403 en action

Suite au comparatif précédent, j’avais prévu de reposter un aperçu de ce petit ampli audio 5V qui m’avait agréablement surpris, mais cette fois-ci avec un haut-parleur plus adapté (3W, 4 Ohms).

Voici le résultat :

Autant dire que pour moins de 4€ (2€ pour l’ampli, 2€ pour le haut parleur), ça me paraît difficile de faire mieux ! Pour mon robot, je verrai si j’utilise ce HP ou le précédent (beaucoup plus compact). Si je dispose de suffisamment de place et que le poids n’est pas un problème, alors j’opterai pour ce HP.
La consommation est en moyenne entre 100 et 200 mA à vue de nez, avec des pics à 500 mA au maximum.
Petite remarque ici, j’ai fait une sommation passive des voix gauche et droite (stéréo vers mono).  Je ne compte utiliser qu’un seul HP sur mon robot. L’utilisation de 2 HP ne m’apporterait rien et consommerait davantage tout en étant plus lourd et plus volumineux.
La sommation des 2 voix se fait avant l’entrée dans l’ampli, avec une résistance de 1 KOhms pour chaque ligne (je n’utilise donc qu’une seule entrée/sortie de l’ampli). J’ai trouvé quantité de circuits différents, mais celui-ci est le plus simple et fonctionne très bien.
circuit_mixage_stereo_mono
http://techtalk.parts-express.com/showthread.php?241139-Stereo-to-mono-summing-circuit

Comparatif d’amplis audio 5V

Pour donner de la voix à mon projet en cours, il me fallait de quoi restituer le son en sortie d’une prise jack (pour écouteurs) de manière décente.

Je n’ai pas eu besoin de chercher beaucoup avant d’être noyé sous les différentes solutions proposées, du vieux (presque légendaire 😉 ) LM386 aux modèles plus récents. Mais difficile de faire le tri.

J’ai donc commandé 4 modules basés sur différents amplis pour me faire mon idée. Sachant que le but est de pouvoir sortir un son correct d’un haut-parleur de 2-3W, permettant de bien comprendre des voix et pourquoi pas jouer un peu de musique.

Au menu :

  • LM386, ampli mono de classe AB
  • PAM8302, ampli mono de classe D, 2.5W
  • TS2012, ampli stéréo de classe D, 2*2.8W
  • PAM8403, ampli stéréo de classe D, 2*3W

Ci-dessous une vidéo, pour donner un aperçu des performances de chacun. Le PAM8302 n’apparait pas, le volume était vraiment trop faible et le potentiomètre tellement fragile qu’il n’a vécu que quelques minutes. Il faut garder en tête que c’est un test « express » visant à donné un premier aperçu : l’empacement du micro bougeant à chaque prise, le positionnement du HP variant tout autant. De plus ces modules ne sont qu’une implémentation de chaque ampli (d’autres circuits les mettraient peut-être plus en valeur).

Les 2 premiers m’ont un peu déçu : le LM386 a du volume mais la qualité laisse à désirer et le TS2012 propose une meilleure qualité mais un volume trop juste.

Mais le PAM8403 est tout simplement bluffant ! J’ai été très étonné du son qui sortait de mon petit HP de 2W ! De plus, il donnera le meilleur de lui-même avec un HP d’une impédance de 4 Ohms (contre 8 ici), j’ai hâte d’écouter ça, je re posterai certainement un article.

Pour finir, la conso est très raisonnable. Je n’ai pas fait de mesures précises, mais en jetant un coup d’oeil à mon alim, elle semblait comprise entre 100 et 200mA (peut-être même moins).