Impression 3D et Thingiverse
Si l’impression 3D se démocratise, faire une version électronique de l’objet que l’on souhaite imprimer est souvent difficile. Le scanner 3D sera certainement une solution dans un futur proche à condition de vouloir refaire une pièce existante mais c’est à l’aide d’outils parfois complexes (libres ou payants) comme solidworks, sketchup, freecad, openscad, autocad qu’il faut créer sont objet sur l’ordinateur avant de le voir se matérialiser sur l’imprimante. Sauf si quelqu’un d’autre à fait un objet identique à celui qu’on veut et qu’il en fournit le code !
Heureusement, ceux qui savent faire des objets numériques sont souvent partageurs et il existe des sites qui regorgent d’objets mis à disposition du monde entier par leurs auteurs.
Thingiverse est un de ces sites, on y trouve des milliers d’objets utiles ou pas avec les sources disponibles pour les réimprimer (découper ou fraiser).
Le Téléfab participe à ce site sous une étiquette dédiée http://www.thingiverse.com/Telefab/overview . Pour l’instant nous avons encore peu d’objets mais si vous souhaitez participer en mettant vos créations, n’hésitez pas à me contacter pour que je vous donne la marche à suivre.
Persistance rétinienne et affichage d’image 3D
Ce projet a été réalisé dans le cadre du projet développement du cursus d’ingénieur de Telecom Bretagne en 2013. Ce projet a été réalisé par CHAIEB Hassen, EL AABOUDI Khalid, RAYNAL Damien et TELLAT Wael.
Concept
Le système réalisé est un système très visuel qui permet d’afficher n’importe quelle image sur une sphère en 3D. Grâce à une unique barre de leds (diodes) le système permet, en faisant tourner cette barre à une periode inférieure à la persistance rétinienne (50ms) , d’afficher l’image sur la surface de la sphère.
Matériel
- Carte Arduino Mega
- 40 leds RGB (rouge,vert ,bleu)
- une photodiode
- un moteur electrique
- un support mécanique
Déroulement du projet
Premiers tests:
Pour être sûr que notre approche était la bonne, nous avons d’abord réalisé des tests de notre
code et du circuit avec un nombre réduit de LEDs (3 puis 13). Ceci nous permettait également de
vérifier qu’il n’y avait pas de perte de luminosité ou autre problème engendré par le nombre
important de soudures.
Développement de la solution:
Le développement de notre solution s’est fait en deux principales parties :
La première étant le développement d’une interface graphique en Java :
qui à partir d’une image, nous donne une matrice simplifiée prête à être affichée.
La seconde étant la programmation du circuit, qui à partir de la matrice obtenue, va contrôler l’allumage des diodes.
I. L’interface graphique
- Rôle principal
Prend en entrée une image et renvoie une matrice divisant image en 40 lignes, et autant de colonnes que nécessaire. Cette matrice contient les codes couleurs qui permettront d’afficher l’image. - Le code:
https://github.com/telefab/POV3DLED/tree/master/ImageConverter - Comment ca marche ?
- Ouvrir une image
- Dessiner la matrice
- Exemple
- Fonctionnalités principales
- Simplification de la couleur :
Comme nous utilisons des diodes RGB, nous sommes limités à 6 couleurs : Blanc-Rouge-Vert-Bleu-Cyan-Magenta-Jaune.
Nous allons donc récupérer l’information sur les couleurs de l’image, et décider, selon ces informations, quelle est la couleur « la plus proche » parmi nos 6 couleurs. Ceci est réalisé par les fonctions :- protected int arrondi (int x){ } :
Cette fonction reçoit un entier (couleur) entre 0 et 255 et renvoie 0 ou 1 pour dire que cette couleur existe ou pas.
Ce choix est fait selon une valeur limite d’existence de la couleur qu’on a fixé à 110
Par exemple : Ici, Arrondi(r) renvoie 1 et Arrondi(b)=Arrondi(g)=0.
Donc on décide que c’est la couleur Rouge. - protected int correspondanceNombre (Color c){ }fait la correspondance couleur->nombre
- protected int arrondi (int x){ } :
- Découpage de l’image :
Une fois le nombre de lignes de la matrice résultantes choisi, ici fixé à 40, on calcule le nombre de colonnes (=largeur de l’image/(hauteur de l’image /40)). Puis on découpe notre image en petits carrés. - Moyennage des couleurs des pixels de chaque carré :Une fois l’image découpée en carrés, on parcourt ces carrés en faisant la moyenne des couleurs de chaque carré, 3 moyennes sont calculées : la moyenne Rouge, Bleue et Verte. On peut ensuite déduir la couleur
- Exportation de la matrice en fichier texte
- Simplification de la couleur :
A la fin du traitement un fichier texte est créé, utilisant comme séparateur « ; » pour les lignes et « , » pour les colonnes.
II.La programmation du circuit Arduino
- Rôle principal :
Le circuit Arduino prend en entrée la matrice retournée par l’interface graphique et contrôle l’affichage de chaque diode (couleur et temps d’affichage) - Code
povled.ino - Fonctions principales
- Conversion texte en matrice : (Pas encore implémenté)
- Conversion chiffre en couleur :
C’est ‘opération inverse que ce qui a été fait dans l’interface graphique, mais ici, c’est des courants qu’on contrôle : Pour afficher la diode 5 en rouge://initialisation for (int i=0;i<40;i++) {digitalWrite( leds[i], LOW);}; //Allumage des leds concernees digitalWrite( leds[5], HIGH);} //initialisation des couleurs digitalWrite( r, HIGH); digitalWrite( g, HIGH); digitalWrite( b, HIGH); //Allumage de la couleur digitalWrite( r, LOW); - Allumage colonne/colonne :Grâce à une boucle, les diodes d’une même colonne sont allumées les unes après les autres (la persistance rétinienne permet de voir une colonne allumée).
Une deuxième boucle permet de passer d’une colonne à une autre. - Synchronisation grâce à un capteur d’intensité lumineuse
Grâce à un capteur, le passage de notre système par sa position initiale va être détecté. Tout de suite, l’allumage des colonnes reprend à la première colonne.
D’une photo à un portrait en 3D
À l’occasion de l’OpenBidouilleCamp des 17 et 18 mai 2013, nous avons proposé une petite activité autour de l’imprimante 3D :
- prendre une photo de profil devant un fond vert
- extraire la silhouette de l’image
- la convertir en un objet 3D au format STL : le profil en relief dans un cadre
- l’imprimer avec la Makerbot
Nous avons ainsi distribué de nombreux petits portraits en plastique. Voici un exemple de résultat :
Pour passer de la photo devant un fond vert à l’objet 3D au format STL, j’ai développé un petit programme en Python disponible sur GitHub. J’ai récupéré pour cela un script de formatage en STL proposé par Manfred Moitzi.
Le programme s’occupe d’identifier la couleur dominante de l’image, d’extraire la silhouette (tout ce qui n’est pas de cette couleur), de la redimensionner, et de la transformer en objet 3D sur deux hauteurs. Il peut être utilisé soit en ligne de commande en exécutant ./extruder.py source.jpg resultat.stl, soit par une interface graphique en exécutant ./gui.py. Des paramètres (tolérance d’extraction, définition et taille du résultat…) sont modifiables directement dans le code pour la ligne de commande, ou sur l’interface pour l’interface graphique.
L’extraction de la silhouette est la partie la moins fiable du processus et ne fonctionne que si le fond vert est suffisamment uniforme. Le mieux est de ne pas trop éclairer pour ne pas créer d’ombres. Une image sombre n’est pas un problème : seule la silhouette nous intéresse.
Nous projetons maintenant de passer à une version en relief du visage plutôt qu’un profil plat, à suivre…
How to : connecter un arduino et un téléphone Android
Le concept :
Arduino et Android sont deux technologie très puissantes et ouvertes. Il peut être très intéressant de les connecter.
C’est ce que nous avons fait pour notre projet LED’s draw !
Nous avons un peu peiné à mettre en place un environnement de travail Android – Arduino. Ils existent de nombreux tutoriels sur le sujet, mais nous n’en avons trouvé aucun qui suffise. Je vais donc tenter de les regrouper ici pour faciliter une telle liaison.
Les tutoriels sur lesquels nous allons nous baser :
- la page de la carte Arduino Mega ADK, sur laquelle on peut brancher un téléphone Android :
http://arduino.cc/en/Main/ArduinoBoardADK
Le problème du tutoriel disponible sur le site d’Arduino est qu’il ne marche qu’avec Processing pour programmer l’application. Je déconseille fortement d’utiliser ce logiciel, c’est beaucoup plus dur de programmer pour Android en C/C++ qu’en Java avec Eclipse.
- la page Google pour utiliser des cartes Arduino – like avec Android
http://developer.android.com/tools/adk/adk.html
La page 2011 présente comment faire. La page 2012 est moins bien.
Le problème est qu’ils présentent surtout leur carte à eux.
- Enfin, voici un tutoriel plutôt sympa : http://allaboutee.com/2011/12/31/arduino-adk-board-blink-an-led-with-your-phone-code-and-explanation/
L’environnement Eclipse pour Android
Tout d’abord, installez l’environnement Eclipse pour Android. C’est long à télécharger, donc autant commencer par ça.
Si vous n’avez pas Eclipse
Vous pouvez tout télécharger ici : http://developer.android.com/sdk/index.html
Normalement c’est bien expliqué.
Si vous avez déjà Eclipse
Vous pouvez l’ouvrir, et installer l’environnement Android : Help/Install New Software/Add/
Mettez le nom que vous voulez, et pour location : http://dl-ssl.google.com/android/eclipse/
Plus d’info ici : http://developer.android.com/sdk/installing/installing-adt.html
Il faut ensuite télécharger les sdks android dans Eclipse : Windows/Android SDK Manager
Sélectionner le sdk que vous voulez (normalement ça marche à partir de Android 3.2 (API 13).
Installer « SDK plateform », et « Google APIs ».
Installer Arduino IDE :
Suivre la procédure pour installer l’arduino IDE et l’arduino ADK sur votre ordinateur (sur le site arduino). Si vous êtes sous Windows, ne pas oublier d’installer le driver ! Pour cela, démarrer/panneau de configuration/système et sécurité/Gestionnaire de périphériques
En branchant votre arduino ADK, vous devriez voir apparaître un nouveau périphérique. Une petit bulle-info peut apparaître. Ouvrez-le/la, installer le pilote, et installation manuelle, aller dans votre dossier arduino contenant le dossier drivers. Sélectionnez celui-ci (qui contient un fichier Arduino Mega ADK) pour y trouver le driver.
Dans le gestionnaire des périphériques, on peut vérifier si l’installation s’est bien passée : l’arduino ADK doit apparaître sous ce nom dans le gestionnaire des périphériques. On peut aussi tester grâce au programme Blink Led (dans les exemples de arduino IDE).
Installer les outils Google :
On passe maintenant sur le tutoriel de Google : http://developer.android.com/tools/adk/adk.html
De « Getting Started with the ADK » jusqu’à « Installing the firmware to the ADK board » inclus.
Ne pas télécharger la librairie CapSense, elle n’est plus à jour n’est pas utile. Ne pas faire Running the Demokit Android application (c’est plutôt réservé à la carte de Google).
Vous pouvez lire la suite, mais il est plus simple de passer au tutoriel suivant :
Un exemple pour bien commencer :
On va donc maintenant regarder un tutoriel pour transférer des données du téléphone à la board.
http://allaboutee.com/2011/12/31/arduino-adk-board-blink-an-led-with-your-phone-code-and-explanation/
Vous pouvez le suivre, ou reprendre directement le projet ici :
En important le code dans Eclipse, il est probable que vous ayez des erreurs aux lignes suivantes :
import com.android.future.usb.UsbAccessory ;
import com.android.future.usb.UsbManager ;
Pour régler le problème, il faut régler la « build target » en google api, c’est-à-dire :
Pour le télécharger, sur Eclipse : windows/android sdk manager/
télécharger la google api qui vous convient (la version 3.2 fonctionne, si vous avez besoin d’une version plus récente ça devrait marcher aussi).
projet/properties/Android
Problème classique :
Si vous refaites un projet « from scratch », vous risquez de rencontrer un problème de layout : une erreur avec « android.R.layout ». NE PAS importer R. ça ne fera qu’empirer les choses. Il faut au choix :
- reprendre le projet au dessus ;
- supprimer les dossiers values-v11 et values-v14 situés dans le dossier res ;
- trouver une vraie solution…
Normalement, ça devrait fonctionner !
Réaliser sa propre installation domotique : architecture
La première étape pour réaliser notre installation domotique est de définir l’architecture de notre installation. Cette architecture n’est bien sûr pas figée, et pourrait très bien être modifiée au gré de l’évolution des besoins et des solutions.
Afin de pouvoir traiter les informations et agir en conséquence, il sera nécessaire de disposer d’un serveur allumé en permanence. Cependant, pour limiter les coûts et la consommation électrique, la contrainte est la suivante : le serveur doit pouvoir tourner sans problèmes sans une carte faible puissance, comme par exemple une Raspberry Pi ou une BeagleBoard. Il existe plusieurs solutions domotiques libres, je vous conseille l’excellent article de linuxfr.org qui fait un tour d’horizon intéressant des technologies.
Le choix de la solution conditionne les interfaces utilisées pour communiquer entre les différents éléments. C’est donc un choix primordial. Trois solutions ont retenu mon attention :
- LinuxMCE, qui est une distribution Linux complète basée sur Ubuntu. Elle utilise beaucoup de solutions libres, mais l’utilisation d’une distribution Linux dédiée limite grandement la généricité de la solution.
- OpenRemote, qui est une solution professionnelle basée sur Java. C’est une solution qui a l’air intéressante, qui propose des applications pour la plupart des écrans de la maison, mais le Java s’adapte encore mal à des plateformes faibles puissances.
- Domogik, qui est une solution très jeune, développée par des français. C’est la solution que j’ai adoptée, pour trois raisons principales. Tout d’abord, elle est développée en Python. Ce n’est pas que j’apprécie particulièrement ce langage, mais il est efficace, simple d’accès, et dispose d’une communauté assez active. Ensuite, Domogik intégre déjà beaucoup de protocoles, sous la forme de plugins. Les plugins sont faciles à développer, et permettent de sélectionner quels éléments seront actifs. Ce fonctionnement par plugin signifie aussi qu’on peut limiter facilement le champ d’action de Domogik, et interfacer d’autres logiciels. Finalement, Domogik est basé sur xPL, qui est un protocole de communication simple et efficace, à base de texte. Pas besoin de cablage compliqué, il suffit d’une interface permettant d’envoyer des caractères.
L’architecture de la solution domotique sera donc axée autour du xPL. Tous les éléments devront, à un moment donné, finir par « parler » le xPL. Cependant, il est facile de réaliser celà sans pour autant perdre en généricité, le xPL étant un protocole situé assez haut dans les couches de la pile protocolaire (en fait, normalement, le xPL s’utilise au dessus de l’Ethernet…). Domogik a également le bon goût de permettre d’avoir plusieurs « serveurs », ou plus précisément plusieurs hôtes, qui communiqueront en Ethernet. Ainsi la solution, bien que centralisée (il y a toujours un hôte principal), permet une certaine distribution de l’information, et surtout une réutilisation de l’infrastructure existante.
Installer Domogik est relativement aisé. J’ai installé la version de développement, disponible via Mercurial. Pour contrôler tout ça, j’ai également installé Domoweb, l’interface Web de Domogik, et Domodroid, l’interface Android. Le site de Domogik, bien que très très lent, est complet, et l’information est assez simple à trouver. Le tutorial pour l’installation en particulier est très bien fait.
Une fois que tout est installé, on se retrouve avec un serveur domotiqe, un moyen de le contrôler, mais rien à récupérer ou à contrôler… Nous verrons ça dans la prochaine note !
Réaliser sa propre installation domotique : Introduction
Je me suis lancé depuis début 2013 dans un projet à long terme, visant à mettre au point une installation domotique complète à la maison. De manière simplifiée, je me suis fixé les objectifs suivants pour mon projet :
- la solution ne doit pas être une solution de bricolage. Elle doit pouvoir rivaliser en efficacité avec les solutions disponibles (à prix d’or ! ) dans le commerce. Elle ne doit pas fonctionner que chez moi, mais être transposable sans trop de difficultés dans n’importe quel cas. Le côté esthétique du produit final est également à prendre en compte.
- la solution ne doit pas être trop chère. La notion de chère dépend bien sûr des moyens de chacun, et des éléments dont on parle. Pour chacun des éléments de la solution final, il faudra discuter du prix.
- pour des raisons d’éthique personnelle, la solution devra s’appuyer uniquement sur du logiciel libre et du matériel ouvert. Tout matériel dont l’intégration nécessite du reverse-engineering ne sera pas pris en compte. Le matériel n’a pas besoin d’être libre, mais il doit pouvoir être utilisé sans avoir à réfléchir au moyen de communiquer avec lui (on excluera typiquement de la solution toutes les solutions de transmission sans fil du commerce pour lesquels il n’existe pas de pile libre). Afin de respecter cet esprit d’ouverture, toutes mes contributions seront elles aussi mises à disposition.
- la solution doit être sécurisée. Le principe de ce projet est de centraliser l’intégralité des informations de mon logement. Je ne veux pas que ces informations soient utilisables par n’importe qui, ni que quiconque puisse venir jouer avec mes réglages de chauffage sans que je l’ai autorisé. Plus embêtant encore, si j’ajoute une caméra dans mon appartement, je ne veux pas que n’importe qui puisse utiliser cette caméra pour m’espionner. Même si la notion de sécurité ne sera pas primordiale au début du projet, il faudra la prendre en compte à un moment ou à un autre, en gardant bien à l’esprit qu’il n’existe pas de solutions inviolables.
Ce type de projet au long cours a l’avantage (et l’inconvénient aussi) de fournir un nombre conséquent de mini-projets. J’essaierai de faire des notes assez régulière sur l’avancement du projet, sur le choix des différentes solutions, …. Certaines parties du projet seront probablement l’occasion de proposer des réalisations dans le portfolio. Je suis ouvert à toute discussion pour me proposer des solutions plus efficaces, plus élégantes, ou tout simplement différentes de celles que je proposerai.
Dans la prochaine note, je présenterai un peu quels sont les objectifs pour la première version de mon installation, et quel fonctionnement j’adopterai pour le développement. Je présenterai également succintement l’écosystème de la domotique.
Comment faire un « Makey Makey » avec un Arduino
Vous connaissez le Makey Makey ? Si non, allez vite ici : www.makeymakey.com
Si vous avez envie d’en reproduire le principe, rien de plus simple. Avec un Arduino, il est aussi possible de déclencher des événements en giflant quelqu’un, par exemple. Il suffit d’une entrée ADC sur l’Arduino, et de brancher dessus une résistance d’une dizaine de MΩ en « pull-up » (c’est-à-dire entre l’entrée et la tension d’alim). Ensuite, en connectant quelque chose à l’entrée ainsi modifiée, le signal sera exploitable sur le logiciel. Attention, il faut que ce quelque chose soit relié à la masse via une résistance de quelques dizaines de MΩ au maximum. Si la résistance est trop grande, on peut augmenter la résistance du « pull-up » pour augmenter la plage de détection de l’événement.
Design d’un émetteur infrarouge
Pour concevoir une télécommande à courte portée, le plus simple est d’utiliser la technologie infrarouge. Cependant, si les composants sont faciles à trouver et peu chers, il faut prendre quelques précautions pour les utiliser, notamment pour l’émetteur.
En effet, on ne peut pas envoyer une information numérique telle qu’elle directement à une diode infrarouge. Les ondes infrarouges seraient atténuées trop rapidement et la portée de notre émetteur sera très faible. Il faut donc moduler l’information. C’est pour cela que tous les récepteurs du commerce intègrent un démodulateur et ne détectent l’information que sur une certaine fréquence. Ainsi, même si le récepteur et l’émetteur sont tout près, une information non modulée ne parviendra pas au récepteur.
Il existe pourtant une façon très simple de faire un modulateur pour une diode infrarouge. On va utiliser un NE555, composant de base pour tous les montages nécessitant une horloge ou un élément gérant le temps. Ce composant va nous générer un signal créneau de 38kHz, la fréquence porteuse de la plupart des commandes infrarouges. Il suffit ensuite de brancher la diode infrarouge sur sa sortie, et un transistor 2N2222 entre la diode et la masse pour envoyer l’information à moduler. Voici un schéma du montage :
Ainsi il est possible de communiquer via infrarouge avec la plupart des récepteurs existants.
Bien entendu, il est aussi possible de changer la fréquence du signal généré par le NE555, pour une autre application par exemple. Pour cela il suffit de changer la valeur des résistances du montage en fonction des équations données dans la datasheet du composant.
Multiplexage d’ADC sur Arduino
Les cartes Arduino sont idéales pour s’initier à la programmation, ou bien réaliser simplement de petits projets d’électronique. Elles disposent d’I/O numériques, de sorties numériques PWM ainsi que d’entrées analogiques, les ADCs. Cependant, dans certains cas, la carte étudiée n’a pas un nombre suffisant d’entrées ou de sorties. Au lieu de monter en gamme de matériel ou tout simplement de doubler le microcontrôleur, nous allons voir qu’il est possible de contourner ce problème. Pour le prix d’une sortie numérique du microcontôleur, nous pourrons doubler le nombre d’entrées analogiques.
Par exemple, supposons que nous avons besoin de 32 entrées analogiques alors qu’au maximum, les cartes Arduino n’en proposent que 16. Nous allons utiliser des multiplexeurs externes 1:2 afin de pouvoir connecter 2 informations analogiques sur une seule entrée ADC de l’Arduino. Il faut donc un multiplexeur par ADC dans notre cas. Les entrées de commande des multiplexeurs ont juste besoin d’être reliées ensemble sur une sortie numérique du microcontrôleur. Voici un schéma de la réalisation hardware :
Au niveau software, pour scanner les entrées, on va procéder 16 par 16. On fixe d’abord une valeur pour la commande des multiplexeurs, puis on scanne les 16 entrées qui sont disponibles. Il suffit ensuite de changer la commande des multiplexeurs et de scanner encore les 16 ADCs. On a alors parcouru les 32 entrées. Voici le code correspondant au multiplexage d’une entrée :
int sensorPin = A0; // sélectionne l'ADC
int muxPin = 22; // sélectionne le pin de commande des mux
int sensorValue = 0; // variable pour stocker la valeur de l'ADC
int mux = 0;
void setup() {
pinMode(muxPin, OUTPUT);
}
void loop() {
sensorValue = analogRead(sensorPin); // on lit l'ADC
if(mux==0){
// commandes pour la première entrée
}
else{
// commandes pour la seconde entrée
}
mux = 1 - mux; // on change d'état le pin de commande mux
digitalWrite(muxPin, mux);
delay(10);
}
L’opération est bien entendu 2 fois plus longue que pour 16 entrées, mais ce temps peut être négligeable selon l’application. Il est aussi possible de multiplier les entrées analogiques par 3 ou 4 en utilisant des multiplexeurs 1:3 ou 1:4, mais le temps de scan sera multiplié d’autant.
IPv6 sur Arduino
À Telecom Bretagne, nous aimons l’open source et nous aimons IPv6. C’est pourquoi nous avons décidé d’apporter ce protocole à notre plate-forme de prototypage préférée : Arduino.
Arduino offre la possibilité de créer de nouveaux usages pour les objets qui nous entourent :
- Un campus intelligent qui adapte sa consommation électrique à ses occupants et leurs besoins
- Une cafetière qui twitte lorsqu’un café a été pris
- Une horloge qui indique le nombre de minutes avant qu’un bus arrive à l’arrêt le plus proche
Pour commencer, rendez-vous sur le GitHub de Telecom Bretagne où vous trouverez la documentation ainsi que la librairie sous licence BSD.
Vous pourrez également venir vous former à l’utilisation de cette librairie dès la rentrée au Téléfab à Brest et au LabFab à Rennes !
Pour toute question relative à l’utilisation de cette librairie, merci de prendre contact avec Baptiste Gaultier (baptiste.gaultier@tb, si vous êtes en dehors de Télécom Bretagne, remplacez tb par telecom-bretagne.eu).
