J’y pensais depuis quelques temps, j’ai franchis le pas et j’ai commandé une petite CNC !
CNC signifie Computer Numerical Control, ce qui, en français, donnerait machine-outil à commande numérique, ou plus littéralement « commande numérique par calculateur ».
Alors qu’une imprimante 3D dépose de la matière en partant du bas de l’objet, la fraiseuse CNC va retirer de la matière en partant du haut de l’objet. Mais si souvent on y fixe une fraise pour faire de l’usinage, on peut aussi y attacher un foret pour réaliser des perçages très précis, ou encore un laser pour « dessiner » sur du bois ou du liège, voir découper certains matériaux.
On peut aussi l’utiliser comme graveuse (sur bois, plexi, alu…). Et l’un des usages qui m’intéresse le plus : la gravure de PCB ! Je ne réalise pas souvent des PCB, mais à chaque fois, avec la gravure chimique, c’est tout un chantier dans la salle de bains, les produits perdent leur efficacité avec le temps, on ne peux pas s’en débarrasser simplement, bref, la gravure m’ira très bien pour mes besoins 🙂
En général, quand on est sur un PC, on a toujours à peu près les mêmes onglets ouverts. Pour gagner du temps, on peut les ouvrir automatiquement quand le navigateur se lance. Après être tombé sur quelques sites ou des gars expliquaient comment ils avaient créé leur page d’accueil personnalisée, ça m’a donné envie d’en faire autant (voici un exemple).
Les intérêts sont multiples :
Productivité : une seule page d’accueil qui donne accès à tout ce dont on a quotidiennement besoin
Accessibilité : il suffit d’un navigateur et d’une connexion internet
Indépendance : on gère soit même ce « portail », on est pas dépendant d’une plateforme spécifique (comme Netvibes) qui peut fermer ou modifier ses conditions d’utilisation
Évolutivité : on y ajoute tout de dont on peut avoir besoin et les possibilités sont vastes (grand choix d’applications Open Source ou gratuites, possibilité d’ajouter ses propres développements…)
Bien sûr, ça demande un peu plus de temps et de travail, mais au quotidien, c’est du bonheur. Une petite remarque aussi concernant la sécurité : comme on peut être amené à installer un grand nombre d’applications de sources diverses, je préfère ne rien stocker de critique sur ce portail et l’accès est très restreint.
Avant de rentrer dans le détail, voici une capture d’écran de l’ensemble de ma page d’accueil, qui finalement est devenue un bureau virtuel (cliquer pour la voir en grand) :
On retrouve les services suivants :
Recherche multi-moteurs (dev perso)
Un accès rapide à mes différentes messageries/Facebook
Une bibliothèque pour accéder à mes PDF, via Encode Explorer
Quelques images en plus :
Tout ça c’est bien, mais je voulais aussi que ça ne soit pas trop moche, sans devoir y passer trop de temps, et c’est là qu’intervient AdminLTE. C’est une interface d’admin de démo basée sur Bootstrap (donc responsive : qui s’adaptera aux écrans de différents préiphériques). Elle contient un maximum de contrôles, et graphiquement, c’est plutôt réussi ! Je l’ai donc utilisée pour construire mon portail, moyennant quelques petites modifications.
Pour terminer, j’ai organisé tout ça dans une petite application PHP, histoire d’avoir un mini Framework MVC (basique), gérer l’authentification, les cookies etc. Il a fallu bidouiller pas mal des applications listées ci-dessus pour contourner leur authentification (et qu’il vérifie la connexion au portail à la place). J’ai parfois du tricher de manière assez moche, mais ça fonctionne 😀
Le tout est hébergé chez OVH, avec un nom de domaine très court. Soit une vingtaine d’euros par an. C’est le prix de l’indépendance 😉
Depuis plus d’un an, le blog n’était plus mis à jour, alors que j’étais sur un projet passionnant (R.I.P.E.R.). J’ai dû mettre ces activités en suspend pour le boulot : j’avais une certif à préparer et ça m’a demandé beaucoup de temps (CEH).
Fraîchement certifié, me revoilà ! Dès le début de mes révisions, j’ai été confronté à un problème : la lecture de centaines de pages de cours sur l’écran, ça fatigue. Et devoir constamment modifier les réglages de luminosité sur l’écran, c’est toujours contraignant, surtout si on doit le faire plusieurs fois dans la journée. A noter que sur un ordinateur portable, cela ne pose pas de problème car Windows permet de modifier directement la luminosité de l’écran. Sur un écran fixe, c’est une toute autre histoire.
J’ai testé différents logiciels, comme f.lux qui semble une référence dans le genre (il permet d’ajuster la luminosité/colorimétrie de l’écran en fonction de l’heure du jour). Mais finalement, pas moyen de trouver un logiciel simple (et pas gavé de spy/ad-wares), qui permet de modifier la luminosité de l’écran à un instant T avec un simple curseur.
Je m’y suis donc collé. C’est très simple, le logiciel se lance et se place dans la barre des tâches. En cliquant sur son icone, un menu s’affiche permettant de modifier la luminosité des écrans connectés au PC. Voilà ce que ça donne :
Je me suis vite aperçu qu’il n’était pas possible de modifier directement la luminosité de Windows quand l’écran est « externe » (et non intégré à un portable). L’astuce consiste tout simplement à ajouter un calque qui se superpose au bureau et reste tout le temps au premier plan sans empêcher la souris d’accéder aux éléments graphiques sous-jacents. Il suffit ensuite de faire varier l’opacité de ce calque pour diminuer la luminosité 🙂
Voici le bout de code magique qui permet de gérer la « transparence pour les clics de souris » :
public static class WindowsServices
{
const int WS_EX_TRANSPARENT = 0x00000020;
const int GWL_EXSTYLE = (-20);
[DllImport("user32.dll")]
static extern int GetWindowLong(IntPtr hwnd, int index);
[DllImport("user32.dll")]
static extern int SetWindowLong(IntPtr hwnd, int index, int newStyle);
public static void SetWindowExTransparent(IntPtr hwnd)
{
var extendedStyle = GetWindowLong(hwnd, GWL_EXSTYLE);
SetWindowLong(hwnd, GWL_EXSTYLE, extendedStyle | WS_EX_TRANSPARENT);
}
}
En faisant le tour des différents périphériques i2c que je compte utiliser pour mon robot, j’ai eu la mauvaise surprise de voir que la boussole et l’écran OLED partageaient la même adresse sur le bus i2c (x3C). Aucun des 2 modules ne permet de modifier l’adresse comme c’est le cas pour certains périphériques.
J’ai donc commandé le même écran OLED, dont je suis très satisfait, mais dans sa déclinaison SPI afin d’éviter les conflits sur le bus i2c. Ca a été plus compliqué que prévu, d’où ce court article.
La première difficulté concerne le raccordement de l’écran à l’Arduino. Certains connecteurs sont nommés de manière peu éloquente : Gnd, Vcc (jusque là, ça va), D0, D1, RES, DC, CS.
Voici les bonnes correspondances, écran –> Arduino :
GND –> GND (masse)
VCC –> 3.3V à 5V (alimentation)
D0 –> SCK
D1 –> MOSI
RES –> un pin digital (c’est pour le reset)
DC –> un pin digital (data/command)
CS –> SS
Second problème, logiciel pour changer. J’utilise toujours la librairie U8glib dont je suis très content. Par contre, les constructeurs proposés dans les différents exemples de code ne fonctionnent pas : il faut passer au constructeur le numéro du pin RESET !J’ai utilisé le constructeur suivant dans mes tests (avec un Arduino Nano) :
U8GLIB_SSD1306_128X64 u8g(13, 11, 10, 9, 4);
// SW SPI Com: SCK = 13 (D0 sur oled), MOSI = 11 (D1 sur oled), CS = 10 (CS sur oled), A0 = 9 (DC sur OLED), !!RESET = 4 (RES)!!
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 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 :
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.
Deux semaines plus tard, me revoilà. J’avais réussi a obtenir des impressions très belles. Mais j’ai très vite déchanté quand il s’est agit d’imprimer des pièces de précision : les objets imprimés n’étaient pas aux bonnes dimensions ! Par exemple, pour une boite de 20 mm x 20 mm x 10 mm, j’obtenais une boite de 21.4 mm x 20.6 mm x 10 mm.
J’ai fait pas mal de tests…
Plusieurs choses à retenir :
lors du calibrage, j’avais beaucoup trop resserré mes courroies
Mes courroies étaient HS. Je ne sais pas s’il s’agissait de courroies de mauvaise qualité, ou si je les ai abîmées en les tendant trop. En tout cas, j’avais un peu de colle a bois qui avaient coulé sur celle de l’axe X et génait un peu les déplacements, et celle de l’axe Y présentait des marques de pliures douteuses. Bref, j’ai remplacé les 2, je ne les ai pas trop tendues et les résultats ont été beaucoup plus précis !
Un pied à coulisse digital est indispensable pour bien étalonner l’imprimante
Une fois la mécanique fiabilisée, il restait quelques écarts, les dimensions n’étaient pas encore tout à fait parfaites. L’étape suivante consiste donc à étalonner l’imprimante en mettant à jour son firmware pour lui dire, pour chaque axe, combien de pas moteur sont nécessaires pour un déplacement réel de 1 mm. J’ai perdu beaucoup de temps à trouver comment se faisait l’étalonnage. J’ai tatônné et obtenu de très bons conseils via le forum francophone RepRap. Aussi je ne détaillerai pas tout le processus ici et me contenterai d’un lien vers un excellent article qui explique tout cela très bien :
Au final, ce qui reste peut-être le plus simple est d’imprimer quelques grandes pièces pour faire des mesures précises et calculer les nouvelles valeurs à entrer dans le firmware de l’imprimante. Voici quelques pièces qui m’ont aidé à étalonner et calibrer ma RepRap.
Pour finir, le soulagement, enfin des dimensions correctes ! Contrairement à la photo, le meilleur endroit pour prendre des bonnes mesures est de se positionner sur les dernières couches imprimées.
Pour imprimer un objet, l’imprimante à besoin d’un fichier qui lui dit exactement quoi faire. Il contient du GCode, c’est ce fichier que nous allons devoir créer.
Pour ce faire, on utilisera Slic3r, intégré à Pronterface (via le menu Settings / Slicing Settings). Ce petit logiciel va recevoir un fichier 3D en entrée, au format .STL. Il va ensuite utiliser tous les paramètres que nous lui aurons fournis pour découper en plein de tranche l’impression 3D et les transformer en lignes de commandes pour l’imprimante.
Au premier démarrage, Slic3r pose un certain nombre de question pour ajuster les paramètres. Pour le moment, je ne rentre pas dans les détails, je travaille encore aux ajustements. Mais il faut au moins répondre aux questions de bases posées par le logiciel.
On charge ensuite un fichier .STL (le Thingiverse est parfait pour cela, choisir un objet relativement plat et en contact au maximum avec le plateau) et on exporte le fichier au format GCode. Pour le nommage du fichier : maximum 8 caractères, une extension « .G » et le tout en majuscules.
De nombreux réglages sont possibles avant de découper le modèle 3D, j’y reviendrai plus tard (j’ai notamment augmenté la température de mon plateau chauffant, les pièces ne tenaient pas assez bien). Pour mon premier essai, j’ai utilisé des couches de 0.3 mm.