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.
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 :
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à).
Les pré-requis étant validés, on va pouvoir s’attaquer à l’installation du système sur l’écran. Pour commencer, j’ai dessiné un boitier qui se fixera derrière l’écran (sur les fixations VESA standards disponibles sur la plupart des écrans) et qui contiendra tout l’électronique :
Le couvercle se clipsera simplement sur le boitier. L’imprimante 3D va pouvoir reprendre du service. Quelques heures plus tard :
Vue de l’intérieur, on peut voir des espaces prévus pour y faire glisser les écrous qui permettront de fixer la carte électronique.
Après installation de l’électronique :
Un connecteur de façade est prévu pour l’alimentation :
Le boitier fermé, et en fonctionnement, tout est prêt pour l’installation sur l’écran.
On installe les rubans de LEDs (autocollants) en faisait bien attention au sens et on fixe le boitier.
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 :
Après une petite trêve, il est temps de se remettre au boulot : réalisation d’un système Ambilight maison. Philips intègre cette technologie à certains de ses écrans depuis plusieurs années. Le principe est de diffuser un halo lumineux autour de la télé, en fonction des couleurs affichées sur les bords, pour une meilleure immersion.
Je voudrais intégrer un système similaire, mais pour mon PC et aller plus loin : en profiter pour les films, mais aussi les jeux, la musique, pouvoir définir des ambiances, gérer des notifications etc.
Il y a une ou deux semaines, j’ai trouvé ça dans ma boite aux lettres :
C’est l’élément clé : il s’agit d’un ruban de LEDs adressables. Comparés aux rubans de LEDs classique, l’avantage énorme de ces rubans, est qu’ils ne nécessitent que 3 ou 4 fils pour être contrôlés, grâce à des petits contrôleurs embarqués (chaque LEDs ayant une adresse). Il en existe différents types, j’ai opté (peut-être un peu rapidement) pour un modèle basé sur chipset SPI : WS2801. Ce n’est pas trop cher (15€ le mètre) et ça devrait faire l’affaire.
Le chipset de LEDs qui a le vent en poupe en ce moment semble être le WS2811 (ou 2812 / 2812B / Neopixel). Il s’agit d’un chipset 3 câbles, contrairement au SPI.
La chose importante à s’assurer lors du choix du chipset, est qu’il soit géré par la librairie FastLED pour Arduino. La liste des chispsets supportés est disponible sur le Wiki du projet.
Mon ruban sera donc piloté par un Arduino Nano. Parce que j’en avais un qui traînait, que ça ne coûte pas cher (2-3€) et que ça ne prend pas trop de place 🙂
Pour le WS2801, nous aurons besoin de 4 cables : +5V (IN/OUT), 0V (GND), SPI Clock (CK) et SPI Data (SD).
Remarque importante, qui m’a fait perdre un peu de temps : les rubans ne sont utilisables que dans un seul sens. Sur certains modèles, une flèche indique le sens. Ce n’était pas le cas sur le mien. J’aurais dû m’apercevoir plus tôt que d’un côté il était marqué « IN 5V » et de l’autre « OUT 5V » pour déterminer le sens.
La connexion sur le Arduino est très simple, il suffit d’utiliser les pins SPI CLOCK et SPI MOSI (pin digitaux 13 et 11 sur le Nano).
Après un premier loupé, j’ai fini par souder un connecteur sur mon ruban de LEDs pour avoir quelque chose de propre, solide et facilement raccordable à la platine de tests.
Pour mes premiers tests, j’ai travaillé avec un ruban de 6 LEDs. Ce n’est pas obligatoire, mais pratique pour la phase de calibrage. De plus, cela évite les problèmes liés à une alimentation insuffisante.
Après cette première partie concernant le matériel utilisé, passons au logiciel et au calibrage. Tout d’abord, il faudra se procurer la libraire FastLED (hyper optimisée et très complète).
Je copie/coller une remarque importante issue du site de FastLED :
IMPORTANT NOTE: If you are building for AVR based systems, please do not use any version of the arduino IDE 1.5.7 or later yet. It messes with some of the asm output which will cause you problems.
En clair, pour Arduino, s’assurer de ne pas avoir une version trop récente de l’IDE (j’utilise la 1.0.5-r2).
Une fois FastLED installé dans les librairies de l’IDE Arduino, nous pouvons ouvrir l’exemple « RGBCalibrate ».
Indiquer le nombre de LEDs utilisées : #define NUM_LEDS 6
Ajouter les LEDS qui correspondent au chipset utilisé (WS2801 dans mon cas) : FastLED.addLeds<WS2801, DATA_PIN, CLOCK_PIN, RGB>(leds, NUM_LEDS);
Le code est prêt à être chargé, et testé ! Normalement, les LEDs devraient s’allumer. Si on constate de que la première LED est rouge, les 2 suivantes vertes et les 3 dernières bleues, alors tout est bon, les couleurs sont envoyées dans le bon ordre : Rouge, Vert, Bleu. Si ce n’est pas le cas, il faudra modifier la ligne d’ajout des LEDs pour identifier l’ordre des couleurs à utiliser pour votre ruban. Dans mon cas, RGB ne correspondait pas, je suis passé en BGR, en modifiant la ligne (ne pas hésiter à tester toutes les combinaisons jusqu’à tomber sur la bonne) : FastLED.addLeds<WS2801, DATA_PIN, CLOCK_PIN, BGR>(leds, NUM_LEDS);
L’étape suivante a consisté à tester la communication entre le PC et la carte Arduino pour piloter le ruban. J’ai écrit 2 petits programmes:
un pour le Arduino Nano, qui écoute les ordres du PC et contrôle les LEDs en fonctions des messages reçus
un pour le PC (en .NET C#), qui permet d’envoyer des ordres au Arduino pour piloter les LEDs.
Le programme pour le Arduino Nano est dispo ici. Le principe est très simple : on écoute sur le port série. Si des données arrivent, on lit le premier octet, qui contiendra un caractère. Si ce caractère est un A, alors on lit les octets qui suivent (3 octets pour chaque led, correspondant au code couleur RGB). Si le premier octet est un B, C ou D, on passe en mode « amibiance » (le Arduino génère en boucle une animation pour les leds).
Côté PC, il s’agit d’un petit programme écrit en C# (application WPF). Les sources sont dispos ici. Attention, c’est pas un chef d’oeuvre, juste une bricole de test, pas de MVVM etc. Mais ça reste simple.
Rien de particulier à ajouter, si ce n’est que la communication avec le Arduino se fait grâce à la classe System.IO.Ports.SerialPort du Framework .NET et le composant graphique ColorPicker provient du Extended WPF Toolkit.
Toutes les actions depuis cette fenêtre, à part les « Ambiances », envoient explicitement à l’Arduino l’état RGB de chaque LED. L’Arduino ne servant qu’à les faire suivre aux LEDs. Ainsi, les scénarios sont intégralement pilotés par le PC, contrairement aux ambiances qui sont calculées par l’Arduino.
Voici une vidéo qui illustre le fonctionnement de l’ensemble :
Il y a un ou deux ans, j’avais fabriqué une tête de lit sur mesures et j’en avais profité pour y intégrer un home cinema: ampli et haut-parleurs, pico-projecteur et un Raspberry Pi pour alimenter tout ça (qui tourne sous OpenElec). Avec bien sûr la terrible contrainte du facteur WAF 🙂
Ça marchait bien mais, pas assez pratique : XBMC sur Raspberry Pi n’est pas un foudre de guerre, il faut réindexer fréquemment le NAS pour voir les derniers films et séries apparaître, et le pilotage de XBMC nécessite de passer par un téléphone ou une tablette.
Bref, changement de plan : intégration d’une tablette 8″ Windows 8.1 dans la tête de lit ! Plusieurs avantages :
La tête de lit est complètement autonome
XBMC est beaucoup plus véloce
Accès direct au NAS via le système de fichiers
Accès à la télé
Accès à VLC
Accès aux replay des différentes chaînes
etc.
Le besoin était de disposer d’un support pour la tablette, qui se cale bien et cache les différents câbles (hdmi, usb, jack audio). Ma surface d’impression étant limitée à 20cm x 20cm, il a été nécessaire de l’imprimer en 2 morceaux.
Ci-dessous, le support assemblé.
Vue de derrière : des profilés alu ont été utilisés pour assembler les 2 moitiés du support :
Des cache-fils ont été imprimés séparément puis fixés sur le support :
Ci-dessous une petite cale qui garantit le blocage de la tablette :
Et voici le tout assemblé. Des espaces ont été prévus pour accéder facilement aux boutons de contrôle du son et de mise sous tension.
Et maintenant la bête en situation :
Vue d’ensemble :
La tête de lit intègre également 2 haut-parleurs, 2 spots et 4 prises secteur.
Pour finir, quelques photos de l’ensemble en fonctionnement…
J’ai acheté un chargeur sans-fil pour mon téléphone (une dizaine d’euros chez Amazon). Cette fonctionnalité est très pratique, mais le chargeur l’est un peu moins :
Cette base circulaire oblige à bien positionner le téléphone pour enclencher la charge. De plus, le téléphone n’est pas du tout calé et l’ensemble prend beaucoup de place sur le bureau.
Le but du jeu à donc consisté à concevoir un support qui pourrait accueillir le téléphone en position verticale et bien sûr, intégrer le chargeur sans fil. Une ouverture à été prévue pour le passage du câble USB du chargeur.
Pas d’articles depuis un moment, mais je n’ai pas chômé pour autant !
Après avoir imprimé un peu tout et n’importe quoi, il était temps d’utiliser la bête pour imprimer un châssis de robot. C’était quand même le but initial 🙂
J’ai fait joujou avec des microcontrôleurs Picaxe, je voulais passer sur du Arduino (hardware Open Source), techno beaucoup plus répandue et avec une très grosse communauté.
Pour découvrir l’Arduino, un objectif simple : fabriquer un petit robot roulant, capable de se déplacer de façon autonome mais également d’être contrôlé à distance via un périphérique mobile (téléphone Lumia 920 sous Windows Phone 8 dans mon cas). Il utilise un télémètre à ultra-sons pour détecter les obstacles et une photorésistance pour détecter les variations de lumières.
Finalement, la prise en main de l’Arduino est un jeu d’enfant. On n’est pas dépaysé après avoir utilisé du Picaxe (qui au passage restent des petits microcontrôleurs super, je n’ai pas vraiment de reproche à leur faire !).
Le prototypage de la partie électronique a été très rapide.
Voici à quoi le robot devrait ressembler (modélisation Sketchup).
Ci-dessous, la vue « explosée » du robot où l’on voit bien les différentes pièces imprimées qui le composent.
Quelques heures plus tard, tout est imprimé 🙂
J’en profite pour préciser quelques astuces. J’ai remarqué que les pièces imprimées, bien que très solides, présentent une faiblesse entre les couches. Quand une pièce « casse », ce n’est jamais une vraie cassure, mais un décollage de 2 couches superposées. Par exemple, quand les parois d’une boîte sont fines, elles se décollent du socle assez facilement.
Pour pallier ce problème, j’ai pris l’habitude de systématiquement consolider les jonctions de plans avec une petite « pente ».
Quelques bandes en relief (3 mm d’épaisseur) sur le fond renforcent aussi la structure. Des emplacements sont prévus pour glisser des écrous. Cela permettra d’assembler les différentes parties avec des vis. Nophead utilise cette astuce pour les pièces de la Mendel90. C’est parfait pour avoir un beau rendu, une bonne solidité et un assemblage facilité.
Même principe de renforcement pour le pare-chocs. Ici, on voit bien que les contraintes appliquées sur les zones où la paroi est la plus fine, sont fortement absorbées par la « pente ».
Un traitement d’enduit en bombe, suivi d’un léger ponçage et d’une couche de peinture en bombe permet de lisser convenablement les pièces et d’avoir un rendu plus « pro ».
Avant/Après lissage, ponçage et peinture.
Fixation de la roulette sur son support imprimé, toujours avec le système des écrous glissés dans la pièce.
Pour que l’électronique soit bien fixée à l’intérieur, j’ai réalisé un petit socle aux dimensions intérieures du robot. 3 écrous viennent assurer que le tout sera bien bloqué grâce à des vis sur la paroi extérieure du robot.
L’ensemble de l’électronique sur son support.
1er étage : la carte Arduino
2ème étage : carte de contrôle des moteurs
3ème étage : carte custom pour connecter avec un minimum de fils l’électronique au reste du robot (piles, LEDs, module Bluetooth, moteurs, etc.)
Toutes les pièces sont peintes, une couche de vernis en bombe a été appliquée pour protéger la peinture.
On peut passer à l’assemblage !
Supports des moteurs et des piles.
Tout est maintenant raccordé ! Les écrous sont en place dans les 4 coins… on peut refermer le petit gars 🙂
Tadaaaammm !
Des ouvertures ont été prévues pour le port USB et l’extrémité du module Bluetooth, histoire de ne pas affaiblir le signal. Des aérations permettent d’évacuer la chaleur (en particulier celle venant de la carte des moteurs).
Sous tous les angles :
A côté de ça j’ai développé une appli Windows Phone 8 pour contrôler le robot. Depuis cette version, Microsoft a laissé un peu plus de liberté aux développeurs pour manipuler le Bluetooth du téléphone. Voici donc la réplique d’une magnifique manette de Nintendo 😀 Le pavé directionnel dérive d’une librairie Open Source.
Fonction de chaque bouton :
Start : connexion au robot
Select : bascule du mode autonome au mode piloté via Bluetooth
Pour le moment, j’arrive à me débrouiller avec Sketchup, qui est assez facile à utiliser.
Mais il est parfois capricieux et les STL générés posent des problèmes d’étanchéité par forcément facile à détecter. J’utilise donc plusieurs outils pour me faciliter la vie :
Tout d’abord, indispensable : le plug-in d’export au format STL, disponible ici.
Plug-in Clean : il permet de nettoyer le modèle de tout ce qui est inutile ou pourrait causer des problèmes.
Plug-in Curviloft : permet de créer facilement des formes complexes à réaliser sans ce plugin.
Enfin, un outil en ligne très pratique : Netfabb en ligne. Il permet de réparer les STL. Il règle notamment les problème d’étanchéité. De ce que j’ai pu tester jusqu’ici, il est plutôt efficace. A essayer si vous n’arrivez pas à corriger un fichier STL.
Je l’ai commandé chez RobotShop, mais il est aussi disponible chez Gotronic.
