Catégorie : Electronique

Articles liés à l’électronique de l’imprimante 3D

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

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

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