Archives mensuelles : octobre 2015

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

Test du contrôleur de moteurs Sabertooth dual 5A

Pour piloter les moteurs du châssis IronMan-4, j’ai commandé un contrôleur de moteurs de chez Dimension Engineering, le « Sabertooth dual 5A motor driver« .

Je l’ai commandé chez RobotShop, mais il est aussi disponible chez Gotronic.

Il permet de piloter 2 moteurs à courant continu de 6 à 18V et peut délivrer jusqu’à 5A par moteur. Je compte utiliser une batterie type modélisme de 7.2V, les specs sont donc parfaites pour le châssis et la source d’énergie.

Je ne vais pas reprendre la fiche produit ici, mais ce petit module offre quelques fonctions bien sympa, notamment au niveau de la consommation d’énergie (au freinage, à l’inversion du sens, récupération d’énergie cinétique…). Il propose aussi plusieurs modes de fonctionnement. Le mode série standard me permet de contrôler très facilement le moteur avec un seul pin de l’Arduino !

La transition de la vitesse maximale en avant à la vitesse maximale en arrière se fait sans prendre de précaution particulière (pas besoin d’arrêter les moteurs). Le contrôleur peut assurer que la transition soit fluide en toutes circonstances.

Voici le montage pour le test :

Le code pour le test est dispo ici.

Et la démo live (pour info, sans charge et les 2 moteurs à vitesse maximale, le courant mesuré est de 500 mA):

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 :

HALO : démo de mon Ambilight DIY

00_halo_demo

De retour après une longue absence. Mon système Ambilight a bien avancé, bien qu’il ne soit pas terminé, l’essentiel y est pour une première démo ! Je le poste donc tel quel parce que je vais me lancer sur autre chose ! Le détail des étapes précédentes (électronique, impression du boitier, intégration…) est disponibles dans les articles précédents).

Au menu :

  • Un logiciel permettant de piloter l’Arduino  nano, qui lui-même pilote le ruban de LEDs
  • Le logiciel se lance au démarrage de Windows et se charge dans la barre de notifications pour un accès rapide

01_halo_icon

  • Quand on clique sur l’icone, 3 modes sont disponibles :
    • Ambiance, qui permet de définir une couleur fixe ou une animation de couleurs
    • Ecran, pour analyser la couleur aux bords de l’écran et la transmettre aux LEDs associées (3 méthodes d’analyse sont disponibles : GDI, DirectX 9 et DirectX 11, la première étant la plus stable mais la moins performante sur les films par exemples)
    • Son, pour analyser le son de l’ordinateur et animer les LEDs en conséquence (ce mode est pour l’instant très expérimental, il ne se base que sur le niveau sonore). J’ai utilisé la librairie NAudio.

02_halo_menu

  • Le bouton « Configuration » permet d’accéder à de nombreux paramétrages, à commencer par le choix de l’écran équipé du ruban de LEDs, la configuration de la communication avec l’Arduino et le mode de démarrage du logiciel.

03_halo_settings

  • Un écran spécifique est disponible pour permettre un placement facile des LEDs (on peut en ajouter, en supprimer, les déplacer, définir la surface de couverture et d’analyse etc.)

04_halo_settings

  • D’autres options de configuration permettent de calibrer la puissance des LEDs, corriger les couleurs etc.

Et pour illustrer le tout, rien de tel qu’une vidéo :

Quelques remarques :
  • Tout n’est pas terminé :
    • L’analyse de l’écran marche bien, mais dans les films, la moyenne des couleurs tend souvent vers des gris, l’algo d’identification de la couleur dominante d’une zone est à ajuster.
    • La méthode de capture d’écran classique (GDI) induit de micro-ralentissements, presque imperceptibles, mais qui restent présents.
    • L’utilisation de DirectX (9 ou 11) fonctionne très bien pour les vidéos, mais  posent quelques autres problèmes (lorsque de la souris bouge par exemple)
    • La partie analyse du son est une ébauche, il est possible d’aller beaucoup plus loin : analyser séparément les canaux gauche/droite, analyser le spectre (aigus, médiums, graves) au lieu de se baser sur le volume etc.
    • Exposition d’un service pour que des applications tiers puissent piloter les LEDs
    • Ajout de modules de notifications (e-mails, facebook etc.)
  • Mon Arduino Nano vient de Chine et utilise vraisemblablement une puce FTDI « not genuine ».  L’année dernière FTDI a déclenché un petit scandale en publiant un driver qui modifiait le PID des puces contrefaites (le driver a depuis été supprimé de Windows Update). Bref, si vous êtes confrontés à un problème de communication avec votre Arduino, vous pouvez jeter un oeil ici (plus d’infos en vidéo ici, ici ou encore ).