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 ! 🙂
Rien de bien fou dans cet article, on va utiliser un Arduino pour piloter :
Un bargraphe de 5 LEDs, qui sera parfait pour mimer l’animation de la bouche quand le robot parlera
Un Led blanche puissante, j’en utiliserai 2 pour les phares
Un buzzer, qui permettra à la partie électronique d’émettre des sons facilement, sans remonter par le « cerveau »
Des interrupteurs, qui permettront d’intéragir de façon basique avec le robot (activation d’un mode spécifique, répondre à des questions, mise en veille… à voir)
J’ai trouvé le bargraphe sur ebay, il n’est pas cher et conviendra parfaitement pour ce que je compte en faire. Ceux que j’avais testés précédemment étaient constitués de 10 LEDs disposées verticalement. Celui-ci n’en contient que 5 et sont disposées horizontalement. Les specs indiquent un courant direct de 20mA, et une chute de tension de 2.4V pour les LEDs jaune. Chaque LED du bargraphe est connectée à une sortie digitiale de l’Arduino, suivi d’une résistance (130 Ohms environ).
Les LEDs utilisées pour les phares sont des LEDs blanches assez puissantes (dispos ici) (3.5V, 20 mA). Elles ne tirent pas trop de courant, les 20mA correspondent à ce que peut délivrer sans problème une sortie digitale d’Arduino, je ferai donc l’impasse sur le transistor pour piloter ces LEDs de « puissance ». Ici on prévoira une résistance de 100 Ohms environ (je mesure une intensité de 12 mA, très bien). Par défaut les pins digitaux d’un Arduino sont configurés en INPUT, il faut bien penser à les déclarer en OUTPUT, sinon le comportement ne sera pas celui attendu (lumière très faible lors de mes tests).
Le buzzer vient de chez Banggood également. Il se connecte sur une sortie digitale. J’ai ajouté une petite résistance par sécurité (environ 30 Ohms) pour ne pas dépasser les 20 mA préconisés pour le Arduino (je mesure une intensité max de 10 mA). Côté code, je n’ai rien inventé et j’ai utilisé ce qui est décrit dans cet instructable. Cette approche n’utilise pas la fonction tone() disponible sur la plateforme Arduino, qui impose quelques contraintes (utilisable sur une seule sortie en même temps et interfère avec les sorties PWM de l’Arduino).
Enfin, la connexion d’un interrupteur sur une entrée digitale de l’Arduino est très basique, à une subtilité près : quand l’interrupteur est ouvert, on ne peut pas laisser l’entrée digitale flottante (l’état serait instable, oscillant aléatoirement entre HIGH et LOW). On doit donc ajouter une résistance de rappel ou tirage (pull up/down resistor) qui permettra de stabiliser l’état lorsque que le bouton n’est pas pressé. Ce qu’il faut savoir, c’est que toutes les e/s digitales d’un Arduino disposent d’une résistance de tirage (pull up) interne (20 à 50 KOhms). Pour simplifier le montage, on activera donc la résistance interne de tirage pour chaque entrée digitale connectée à un bouton, et l’autre extrêmité du bouton sera liée à la masse. Quand le bouton sera pressé, l’état lu sur le pin sera donc LOW.
Pour activer la résistance de pull up :
pinMode(buttonPin, INPUT);
digitalWrite(buttonPin, HIGH); // active la resistance de tirage interne
ou directement :
pinMode(buttonPin, INPUT_PULLUP);
L’instructable disponible ici, apporte beaucoup d’informations concernant l’utilisation des boutons. Car si le câblage est simple, utiliser correctement un bouton peut nécessiter quelques ruses (debouncing, appui prolongé…).
Démonstration en vidéo (le « phare » clignote en permanence, quand on appuie sur le premier bouton, une animation sur le bargraphe est déclenchée, quand on clique sur le second bouton, le buzzer joue le French Cancan 😉 ) :
J’ai prévu d’utiliser un Arduino Mega pour jouer le rôle de « moelle épinière » de mon prochain robot. C’est cette partie qui permettra l’acheminement des différents messages entre le cerveau (un mini-PC) et le corps (châssis, moteurs, capteurs) du robot.
Cette partie sera donc le carrefour de nombreux échanges entre différents types de périphériques, avec leurs contraintes (protocoles différents, performances, utilisation d’interrupts externes etc.).
Le but de ce PoC (Proof of Concept) est de démontrer que le Arduino Mega est bien capable d’assurer ce rôle. Plus précisément, il doit être capable de gérer en parallèle :
des périphériques sur bus SPI
des périphériques sur bus i2c
la communication série avec un PC
la communication avec un autre Arduino (Nano) sur le bus i2c
le pilotage de pins digitaux
la lecture de pins analogiques
des encodeurs très rapides avec des interrupts externes
Et tout ça pour une emprunte mémoire supportable.
Pour ce faire, j’ai fait un petit montage composé d’un Arduino Mega, d’une matrice de LEDs (SPI), d’un moteur CC et son encodeur (les 2 pins étant attachés à des interrupts externes), un tableau de 10 LEDs (je n’en utiliserai que 8, pilotés directement par des sorties digitales + une résistance de 150 Ohms), une photorésistance (sur pin analogique), un écran OLED (i2c), un capteur thermique IR de 8 cellules (i2c), un Arduino Nano (i2c) avec 2 capteurs ultrasons.
Le schéma suivant sera plus parlant :
L’écran permettra d’afficher un certain nombre d’informations (température la plus élevée sur le capteur thermique, ticks moteurs, les distances relevées par les capteurs ultrasons), le tableau de 8 LEDs affichera la cellule la plus chaude détectée par le capteur thermique) et la matrice de LEDs dessinera une ampoule si une forte lumière est détectée ou un smiley si la température la plus élevée relevée par le capteur est inférieure ou égale à 50°C et un cœur si elle les dépasse.
Pour mesurer l’intensité lumineuse, on utilisera une photorésistance (1-10 KOhms) : sa résistance varie en fonction du niveau lumineux. Un simple pont diviseur de tension (avec une résistance de 10 KOhms) nous permettra d’obtenir des variations de tension sur le port analogique que l’on pourra alors facilement mesurer. Un tuto ici.
L’Arduino Mega est le maître du bus i2c. Pour pouvoir communiquer avec un autre Arduino (Nano ici), ce dernier doit être utilisé en tant qu’esclave sur le bus i2c. Tout ce qu’il faut savoir est ici.
Les détails concernant le moteur (et son encodeur) utilisé est disponible ici. Et voici le détail des connexions :
Côté Arduino Mega, on est confortable, le programme occupe 7% du stockage et utilise 11% de la mémoire. Pour le Nano, la question ne se pose même pas : il ne fera que relever les mesures de capteurs ultrasons.
Lors des premiers essais, des problèmes de performances sont apparus et on pouvait observer une légère latence du système, de l’ordre des 200ms à vue de nez. En pratique, si j’allume la lumière sur la photorésistance, la matrice de LEDs affiche l’ampoule 200ms plus tard. Ce n’est pas énorme, mais ça se sent et ça pourrait poser des problèmes, pour la gestion des obstacles par exemple.
Je me suis vite aperçu que cela venait du rafraîchissement de l’écran OLED : à chaque tour de la boucle principale du programme, l’écran était entièrement redessiné. Je n’ai pas besoin de le mettre à jour si souvent, il suffirait de le faire une fois toutes les 200ms pour avoir un affichage assez fluide (sachant que pour mon utilisation, je pourrais même le rafraîchir toutes les secondes seulement).
Et c’est très facile à faire, grâce à la fonction millis(). Elle renvoie le nombre de millisecondes écoulées depuis que le Arduino est sous tension (le compteur revient à 0 après environ 50 jours de fonctionnement). A partir de là, il suffit de vérifier à chaque tour de la boucle principale qu’au moins 200ms se sont écoulées depuis le dernier rafraîchissement de l’écran. Si ce n’est pas le cas, on ne le redessine.
Cette petite astuce a réglé les problèmes de latence, l’Arduino Mega pilote le tout à merveille, la démo en vidéo :
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).
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
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.
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.
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.)
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 là).
Après avoir validé la faisabilité de piloter un ruban de 6 LEDs avec le PC depuis une application Windows (C#) en passant par un Arduino Nano, l’étape suivante consiste en un test « grandeur nature ».
Mon système Ambilight contiendra environ 60-70 leds, 2 points essentiels sont à vérifier :
La consommation maximale de courant, pour prévoir une alimentation suffisante
La réactivité de l’ensemble
J’en ai aussi profité pour monter l’ensemble des composants sur une seule plaque électronique pour en faciliter l’intégration :
En plus du câble USB, j’ai ajouté un connecteur pour le ruban de LEDs et un autre pour l’alimentation (dont l’entrée sera fixée sur le boitier) :
De la même façon, un connecteur a été soudé sur le ruban de LEDs :
Et voici le tout en action, ça marche, c’est déjà ça 😉
Première vérification : mesurer l’intensité. J’ai volontairement utilisé l’ensemble du ruban de LEDs (85 Leds) pour ces tests. Il suffit d’intercaler (en série) un multimètre pour faire les mesures.
Les LEDs de type WS2801 sont données pour une puissance de 0.3W, donc, à 5V, à puissance maximale, on ne devrait pas dépasser les 60 mA par LED.
Tout d’abord en utilisation classique (couleurs de l’arc en ciel), on tourne en moyenne à moins de 1.5A. La consommation semble faible, mais comme ici les LEDs ont toutes une couleur, elles ne sont pas à fond.
Pour tester la consommation maximale, il faut les mettre à la puissance maximale, et en blanc. Ici on passe à 2.5A. Ce qui reste très raisonnable comparé aux 5A théoriques auxquels je m’attendais (mais je vérifierai quand même qu’elles sont bien à luminosité maximale).
Dans tous les cas, l’alimentation de 5V/4A que j’ai prévue fera parfaitement l’affaire pour 60-70 LEDs.
Le dernier point concerne la réactivité. Ici, rien à redire, ça dépote ! La démonstration en vidéo :
Toutes mes commandes sont enfin arrivées. En fait, il ne me manque que les planches de MDF, alors que c’est à peu près la seule chose que je n’ai pas commandée en Angleterre ou en Chine 😉
La carte contrôleur permet de piloter l’imprimante. Elle est connectée aux moteurs, plateau chauffant, au chauffage de la buse, aux thermistances, aux interrupteurs de fin de course etc. C’est elle qui est responsable de l’impression.
Bref j’ai reçu la carte électronique de contrôle aujourd’hui, une Melzi. J’ai pas mal hésité entre la config la plus répandue, à savoir un Arduino Mega + shield RAMPS 1.4 et la Melzi.
J’ai opté pour la Melzi essentiellement pour 2 raisons : la première, c’est que c’est la carte que Nophead propose par défaut dans son kit, donc pas besoin de modifier le gabarit de perçage. La seconde, c’est que la Melzi utilise des borniers à vis pour tous les câbles, ça me semble beaucoup plus fiable que les connecteurs habituels qui n’ont pas de réel blocage mécanique.
La Melzi est vraiment un « tout en un », les pilotes des moteurs sont pré-soudés (A4988), les connecteurs sont bien disposés etc. Mais il faut savoir que la solution basée sur un shield RAMPS étant plus répandue représente souvent le standard. Il sera plus facile de la faire évoluer (piloter plusieurs buses, ajouter un écran de contrôle etc.). Des évolutions sont aussi possibles sur la Melzi, mais au prix d’efforts/recherches plus importants.
Cette commande faisait partie des quelques une passées sur Aliexpress, donc j’ai voulu la tester rapidement (et sommairement), c’est à dire charger le Firmware Marlin modifié par Nophead pour m’assurer que cette première phase se passait bien.
Avant toute chose, s’assurer que le cavalier de l’auto-reset est bien inséré (à droite sur l’image ci-dessous), et que le cavalier indiquant le mode d’alimentation de la carte est bien sur USB (pas besoin de s’embêter davantage, il s’agit seulement de charger le firmware) (à gauche sur la photo ci-dessous).
Ensuite, récupérer la version modifiée par Nophead du Firmware Marlin, dispo sur son Github. Le répertoire Melzi est à copier dans le dossier « hardware » du répertoire d’installation de l’IDE Arduino. On ouvre après le fichier principal du projet (Marlin.ino).
Il ne reste plus qu’à connecter la carte Melzi en USB, attendre que le driver s’installe et charger le firmware (s’assurer que le type de carte « Melzi W/ ATmega1284p 16mhz » et le bon port sont bien sélectionnés dans le menu « Outils »).
Le chargement s’est bien passé, ouf 🙂
Carté payée 37€ sur Aliexpress (les 4 drivers A4988 sont intégrés).
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.
