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 !
Dansons la lumière !
Ce projet a été réalisé durant la semaine d’intersemestre 2013 « Fablab & Design », en coopération avec les étudiants de l’ESAB.
Ont participé à ce projet Alice Dejoux et Morgane Joly, de l’EESAB BREST, et Victor Dubois, de Télécom Bretagne.
Concept :
» Dansons la lumière » est une installation retranscrivant un lien, une connexion entre un mouvement et la lumière. Nous nous sommes concentrés ici sur le mouvement de la main, mais nous imaginons ce projet à l’échelle du corps pour que la danse devienne lumière. La lumière serait écho du danseur ou son partenaire.
D’un coté, des capteurs de lumière reprennent le mouvement effectué par la main et de l’autre un cube à LEDs retranscrit ce mouvement en points lumineux. La lumière devient empreinte du mouvement.
Matériel :
- 1 Arduino Mega 2560
- 2 ou 3 télémètre à ultrason (par exemple : un clone du PING de Parallax, ou un SRF05)
- un cube à LED
- des fils, une breadboard, de la patience !
Nous avons réutilisé le cube à LED réalisé lors du projet « Cube à LED Météo« , dont nous avons modifié le code.
Fonctionnement :
Le cube à LED est placé devant soi, avec un télémètre de part et d’autre. Les télémètres sont dirigés vers le haut. On place alors ses mains au dessus des télémètres, et en fonction de la distance des mains par rapport aux télémètres, l’image du cube change.
Le principe des télémètres à ultrasons est qu’ils émettent une onde ultrason, et attendent la réponse. Ils mesurent alors le temps que met le son à faire l’aller-retour entre l’émetteur et le premier obstacle rencontré. C’est cette information qui est fournie à Arduino. Nous avons utilisé deux types d’ultrason : un clone du PING de Parallax, et un SRF05.
Améliorations :
Si nous avions eu le temps, nous aurions essentiellement travaillé deux points :
Tout d’abord, ajouter un troisième ultrason. Cela permettrait de faire des visualisation plus intéressantes encore. La principale difficulté réside dans les interférences entre ultrasons : comme nous n’utilisons que des capteurs classiques, ils sont tous à la même fréquence standard : 40kHz. Si une onde émise par un capteur parvient à un autre, par exemple en rebondissant sur la main du manipulateur, alors les mesures sont faussées et la visualisation n’est pas celle attendue. Il faut donc prendre des précautions et bien séparer les capteurs.
Ensuite, nous nous serions penché sur le problème du clignotement du cube. En effet, le principe du cube à LED est d’allumer rangée par rangée. Elles clignotent alors très vite, donnant l’illusion d’être allumée en permanence. Le problème est que les télémètres mobilisent l’Arduino, l’empêchant pendant un court instant de changer l’état des LEDs. Pour palier ce problèmes, nous avons quelques pistes, mais la seule qui nous parait réellement fiable est d’utiliser deux Arduinos : l’un dédié au cube à LEDs, qui ne s’arrête jamais d’allumer et d’éteindre les LEDs ; et un autre, dédié aux capteurs. Celui-ci peut être mobilisé sans risque sur l’affichage. On utiliserait alors une liaison I2C entre les deux Arduinos, en ne transmettant que les valeurs des capteurs. Nous n’avons malheureusement pas eu le temps d’implémenter cette solution.
Pour finir, voici quelques vues du cube en fonctionnement :
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.
PARKUINO
PARKUINO ? Par qui ? Pour qui ?
PARKUINO est un projet développé durant la première semaine d’inter-semestre 2013 par le trio d’élèves FARHANE Karim, ELIDRISSI Yassir, HADFAT Ayoub.
Il est destiné à venir en aide au stationnement des voitures dans les parkings ou les garages.
Le fruit de ce projet se présente sous forme de deux boîtiers :
- L’un posé sur l’obstacle devant lequel la voiture veut se garer ; il permet l’allumage de feux de signalisation (verts/jaunes/rouges) au fur et à mesure que la voiture s’approche de l’obstacle et finalement la sonnerie d’alarme d’un buzzer lorsque celle-ci est trop proche.
- L’autre situé à l’intérieur de la voiture ; il permet d’afficher la distance de la voiture à l’obstacle.
La réalisation de ce projet a nécessité le recours au matériel suivant :
- 2 Arduino UNO.
- 2 Shields Xbee.
- 2 LED rouges, 2 LED jaunes, 2 LED vertes.
- 1 Buzzer.
- 1 Télémètre SRF.
- 1 Afficheur LCD, 1 potentiomètre.
Schéma du montage et principe de fonctionnement :
Montage émetteur
Code Emetteur :
const int Spin = 8; // pin du télémètre
const int led[] = {9,2,3,4,5,6}; // leds indicatrices
const int hp = 7; // haut-parleur
const int borne[] = {5, 15, 30, 60, 90, 120}; // on définit les distances d’activation des leds
const byte borneLim=240;//Limite au-delà de laquelle on éteint l’afficheur du montage récépteur
void setup() {
for(int i=0; i<6; i++){
pinMode(led[i], OUTPUT);
}
pinMode(hp, OUTPUT);
Serial.begin(9600); // démarrage port série
}
void loop() {
byte distance=calculDistance();
if (distance < borne[0] ) {
for(int i =0; i<6;i++){
digitalWrite(led[i], HIGH);
}
digitalWrite(hp, HIGH);
}
if (distance > borne[0] and distance <= borne[1] ) {
for(int i =0; i < 5;i++){
digitalWrite(led[i], HIGH);
}
digitalWrite(led[5], LOW);
digitalWrite(hp, LOW);
}
if (distance > borne[1] and distance <= borne[2]) {
for(int i =0; i < 4;i++){
digitalWrite(led[i], HIGH);
}
for(int i =4; i < 6;i++){
digitalWrite(led[i], LOW);
}
digitalWrite(hp, LOW);
}
if (distance > borne[2] and distance <= borne[3]) {
for(int i =0; i < 3;i++){
digitalWrite(led[i], HIGH);
}
for(int i =3; i < 6;i++){
digitalWrite(led[i], LOW);
}
digitalWrite(hp, LOW);
}
if (distance > borne[3] and distance <= borne[4]) {
for(int i =0; i < 2;i++){
digitalWrite(led[i], HIGH);
}
for(int i =2; i < 6;i++){
digitalWrite(led[i], LOW);
}
digitalWrite(hp, LOW);
}
if (distance > borne[4] and distance < borne[5]) {
for(int i =0; i < 1;i++){
digitalWrite(led[i], HIGH);
}
for(int i =1; i < 6;i++){
digitalWrite(led[i], LOW);
}
digitalWrite(hp, LOW);
}
if (distance >= borne[5] and distance <= borneLim) {
for(int i =0; i < 6;i++){
digitalWrite(led[i], LOW);
}
digitalWrite(led[0], LOW);
digitalWrite(hp, LOW);
}
if(distance > borneLim) distance =borneLim+1;
Serial.write(distance);
delay(100);
}
byte calculDistance() { //Fonction pour calculer la distance
byte distance = 0;
int duration;
pinMode(Spin, OUTPUT);
digitalWrite(Spin, LOW);
delayMicroseconds(2);
digitalWrite(Spin, HIGH);
delayMicroseconds(10);
digitalWrite(Spin, LOW);
pinMode(Spin, INPUT);
duration = pulseIn(Spin, HIGH);
distance = duration / 58;
return(distance);
}
Montage récepteur
Code Récepteur:
#include <LiquidCrystal.h>
LiquidCrystal lcd(12, 11, 5, 4, 3, 2);
byte incomingByte;
const byte borneLim=241;
void setup() {
Serial.begin(9600);
lcd.begin(16,2);
}
void loop() {
if (Serial.available() > 0) {
incomingByte = Serial.read();
Serial.println(incomingByte);
}
if(!(incomingByte==borneLim)) {
lcd.setCursor(0, 0);
lcd.print(« DISTANCE: « );
lcd.print(incomingByte);
lcd.print( » cm »);
lcd.setCursor(0,1);
if(incomingByte < 10) lcd.print(« ATTENTION ! »);
if(incomingByte >= 10 and incomingByte < 30) lcd.print(« DOUCEMENT »);
if(incomingByte >= 30) lcd.print(« CONTINUEZ »);
lcd.setCursor(16,1);
}
else {
}
delay(100);
lcd.clear();
}
Le télémètre SRF mesure constamment la distance de la voiture à l’obstacle.
Au fur et à mesure que celle-ci descend au dessus des bornes prédéfinies, une LED de plus s’allume suivant cet ordre :
1 LED verte → 2 LEDs vertes → 2 LEDs vertes + 1 LED jaune → 2 LEDs vertes + 2 LEDs jaunes →
2 LEDs vertes + 2 LEDs jaunes + 1 LED rouges → 2 LEDs vertes + 2 LEDs jaunes + 2 LEDs rouges
Lorsque toutes les LEDs sont allumées, la sonnerie d’alarme du buzzer se déclenche en plus, signalant que la voiture a atteint une position critique.
En même temps, le Xbee monté sur l’Arduino émetteur se charge d’envoyer la distance (en centimètres) captée par le télémètre à l’autre Xbee monté sur l’Arduino récepteur.
Cette distance est alors affichée sur l’afficheur LCD (en centimètres) et accompagnée d’une commande qui en dépend :
-
« Continuez » tant qu’aucune LED jaune n’est allumée.
-
« Doucement » tant qu’aucune LED rouge n’est allumée.
-
« Attention ! » lorsque toutes les LEDs sont allumées et que la sonnerie du buzzer est déclenchée.
Remarques :
-
Le potentiomètre qu’on peut voir sur le montage sert à régler la luminosité de l’afficheur LCD.
-
Pour des raisons de codage sur 1 byte, la distance maximale à partir de laquelle le capteur télémètre devient sensible est 255 cm.
Version 2.0 ?
Comme les stationneurs deviennent de plus en plus paresseux, nous sommes conscients que la version actuelle du projet ne peut pas les satisfaire entièrement.
Une perspective d’amélioration serait donc d’intégrer au système un moyen de reconnaissance vocale permettant de lire via un haut parleur la distance affichée sur l’écran LCD.
Encore mieux : ajouter au système une caméra permettant au chauffeur de voir en temps réel l’évolution de son espace de stationnement.
Le Téléfab en ébullition
Du 21 janvier au 25 janvier, puis du 28 janvier au 1er février, l’activité a été intense au Téléfab…
Les intersemestres ont permis à une trentaine d’étudiants de Télécom Bretagne et à une quinzaine d’étudiants de L’ESAB de Brest, de prendre en main les technologies disponibles au fablab, d’imaginer, créer et mettre au point des projets variés.
Apprendre par soi même et à l’aide des autres, expérimenter, confronter ses idées, des semaines riches en apprentissage.
Visitez le portfolio pour avoir une idée de la diversité des projets :
- des « cubes à leds » : cubes à leds météo, Led’s zeppelin, leds et mouvement
- des jeux : la bataille navale en solo, télé-nunchuck et arduino, maison piégée, tourelle
- des applications connectées au web : gmail notifier
- du dessin smartphone-afficheur à leds : led’s draw,
- de l’interactivité : une poignée émotive okaeri, Touch my Yoda
- de la musique : Theremin, escalier musical
- des effets lumineux : jouer avec la persistance rétinienne
Projet de tourelle d’Airsoft
Dans le cadre de l’inter-semestre «Fablab ou comment concevoir à peu près tout…» j’ai souhaité réaliser un projet sur un sujet qui me passionne: l’ Airsoft. Tout d’abord, l’ Airsoft est un jeu de rôle mêlant stratégie et tactique qui ressemble au Paintball, et dans lequel les joueurs utilisent des répliques d’armes à feu qui tirent des billes en plastique de 6mm de diamètre. Je me suis donc penché sur l’élaboration d’une tourelle d’ Airsoft, un genre de drone fixe. Durant la semaine d’intersemestre, j’ai réalisé une commande d’un moteur à courant continue à distance grâce à des Arduino. Ce moteur devait servir à assurer la rotation autour de l’axe vertical.
Matériel Nécéssaire:
- 2 Arduinos UNO
- 2 shield XBee
- 1 joystick
- 1 breadboard
- 1 pont en H LMD18200
- 1 moteur à courant continue
- 1 batterie 9V
Montage Électronique:
- La manette:
- Le contrôleur
Le pont en H:
Le fonctionnement:
La manette capte la position des deux axes du joystick et du bouton intégré. Il envoie ensuite ces informations via le module XBee. Par contre il n’est possible de n’envoyer que des variable au format d’un CHAR id est sur un octet. Il faut donc adapter l’information au préalable. La manette envoie aussi un symbole ( 255) entre chaque cycle afin d’assurer la synchronisation. Il faut bien sûr s’assurer que ce symbole n’est jamais utilisé à d’autres fins.
Le contrôleur met le pin correspondant à l’entrée direction du pont en H au niveau haut ou bas en fonction de l’information reçue. Ensuite il applique une tension analogique sur l’entrée » PWB input » qui est fonction de la position du joystick. (J’ai eu quelques bug que je n’ai pas eu le temps de corriger sur ce montage, il est possible qu’il faille envoyer un signal créneau en faisant varier le rapport cyclique en fonction de la position du joystick pour que ça marche mieux.)
La partie Mécanique:
Ce projet contient aussi une partie mécanique. La propulsion des billes devait se faire à l’aide de pièces récupérée sur une vielle réplique électrique. J’ai réalisé la structure de la tourelle en bois.
J’ai aussi commencé à réaliser des modèles 3D sous Solidworks pour assurer la mobilité autour de l’axe vertical. Il s’agit d’un rail qui va guider des roue et d’une crémaillère. Ces pièces sont destinées à être imprimées par l’imprimante 3D du Téléfab.
Suite du projet:
L’objectif final du projet est de réaliser une tourelle autonome qui pourra être guidée à distance via un smartphone. Disposant d’un Raspberry Pi, je compte refaire la partie logicielle en Python en utilisant les connecteurs GPIO du Raspberry. Il me faudra ensuite réaliser l’interface Android pour guider la tourelle. Je compte aussi mettre une webcam afin de renvoyer la vidéo sur le smartphone. Il faut aussi que je finalise les différentes pièces sous Solidworks, que je les imprimes et que je monte le tout. Enfin il me restera encore beaucoup de boulot pour automatiser le tout. Donc si ça vous intéresse de contribuer au projet, n’hésitez pas! 😉
LED’s draw !
Quand un Smartphone et un Arduino dessinent ensemble
« LED’s draw ! » est un projet mené durant la première semaine d’intersemestres « FabLab » (du 21 janvier au 1er février 2013), en collaboration avec l’intersemestre « Bootcamp ». Le projet a été mené par Gaëtan FAYON et Etienne LOUBOUTIN pour la partie « matérielle » du projet, et par Victor DUBOIS et François GUÉGAN pour la partie logicielle (application Smartphone).
« LED’s draw ! » permet de dessiner une image sur son Smartphone (Android) et de l’envoyer sur une matrice à LED 32×16. La matrice reproduit alors l’image à l’identique.
Pour réaliser ce projet, le matériel suivant a dû être utilisé :
- un Arduino UNO ;
- un Arduino MEGA ADK ;
- une matrice à LED (32×16) ;
- un Smartphone (Android) ;
- un environnement de développement JAVA-Android.
Veuillez également vous rendre à cette page (http://developer.android.com/tools/adk/adk.html) pour bien configurer les deux parties du montage (la partie Arduino et la partie Android) pour pouvoir les faire communiquer de la meilleure des manières possibles.
Schéma du montage électronique
Pour développer ce projet, nous avons tout d’abord songer à utiliser une liaison Bluetooth entre le Smartphone et un Arduino BT-V06. Seulement, nous n’avons absolument pas réussi à faire fonctionner ce dernier (de nombreux mystères semblent être à résoudre de ce côté-là : faire fonctionner ce composant se révèle être issu d’un facteur chance assez incroyable). Nous avons alors essayer de faire fonctionner un autre module Bluetooth, le RFM70, sans toutefois plus de succès. Il y a donc moyen d’améliorer le système mis au point en essayant de faire fonctionner ces différents modules de manière convenable.
Au final, le montage réalisé correspond à celui-ci :
A la vue de ce schéma, une question simple doit se poser : pourquoi avoir utiliser deux Arduino (un UNO et un MEGA ADK, soit un pour gérer l’affichage des donnée sur la matrice et un autre pour gérer le flux de donner arrivant du portable) alors que l’Arduino MEGA ADK possède à priori assez de pins pour gérer cela tout seul. Cependant, celui utilisé semblait avoir un problème pour alimenter correctement la matrice à LED en 5V. Nous sommes donc passer par un Arduino UNO pour le faire. Pour faire la liaison entre les deux Arduino, nous avons réalisé un pont I2C, en reliant la pin COM/SDA20 (respectivement COM/SCL21) de l’Arduino MEGA ADK à la pin ANALOG/A4 (respectivement ANALOG/A5) de l’Arduino UNO.
Principe du codage (côté Arduino)
Voici le principe général du projet, informatiquement parlant :
Pour faire simple, l’Arduino MEGA ADK doit gérer ce qui vient du port USB hôte (relié au Smartphone de l’utilisateur). Il reçoit trois données principales : la couleur de la LED à allumer, ses coordonnées et l’intensité de la LED. La couleur est codée sur un octet : 00000000 pour aucune couleur, 00000001 pour la couleur verte, 00000010 pour la couleur rouge et 00000011 pour la couleur orange. On utilise un octet et non deux bits pour la simplicité du protocole, sachant que l’on reçoit les données du Smartphone par octets obligatoirement via le protocole USB, il faudrait sinon dépaqueter chacun des octets. Pour les coordonnées, on sépare l’axe X et l’axe Y : chacun est codé sur un octet et varie soit entre 0 et 15 soit entre 0 et 31 (on utilise une matrice à LED 32×16). L’intensité est également codé sur un octet et varie entre 0 et 15.
L’Arduino MEGA ADK transmet ensuite ces informations à l’Arduino UNO via I2C, et l’Arduino UNO réoriente ces données vers la matrice à LED, en branchant tout ces composants comme il l’est indiqué sur le schéma de montage précédent. Il faut prêter attention à bien connecter les pins de la matrice à LED de manière convenable avec les pins de l’Arduino UNO. Le meilleur moyen de ne pas se tromper et d’utiliser un branchement à base de détrompeur, que vous pouvez créer vous-même si vous avez les composants nécéssaires. Dans tous les cas, si vous respecter les branchements donnés sur le schéma, il n’y aura aucun soucis (d’autant plus que le nom des pins est donné au dos de la matrice à LED).
Au niveau codage, il n’y a rien de bien compliqué, une fois les bonnes librairies téléchargées. Vous pouvez télécharger librement les codes :
- Codes pour l’Arduino MEGA ADK ;
- Codes pour l’Arduino UNO ;
- Librairies pour les compilations des codes (à insérer dans votre répertoire principale de codage) : pour la matrice, pour l’Arduino MEGA ADK et pour la liaison USB.
Principe du codage (côté Android)
Le codage de la partie Android du projet nécessite quant à elle d’être plutôt à l’aise avec la programmation JAVA et des bases solides au niveau de la programmation Android. Pour vous former, n’hésitez pas à consulter les nombreux tutoriels existant sur Internet : à chaque problème existe une recherche Google adéquate !
Pour débuter, je vous propose de commencer par l’excellent tutoriel disponible à cette adresse : http://nbenbourahla.developpez.com/tutoriels/android/introduction-programmation-android/.
Pour en revenir à notre application en elle-même, cette application permet :
- d’enregistrer ou charger (via un mot clé et une commande vocale) une configuration de la grille ;
- d’allumer/éteindre une LED, ou une ligne/colonne entière ;
- d’établir le choix de la couleur pour chaque LED ;
- mélanger la grille en secouant le Smartphone.
Pour approfondir sur le thème de la commande vocale, il suffira par exemple que l’utilisateur dise le mot « maison », pour qu’un dessin de maison s’affiche à la fois sur le Smartphone et sur la matrice à LED. On peut également sélectionner la couleur par commande vocale.
Au niveau de l’interface proposé, voilà ce que nous avons réussi à avoir pour le moment :
Le code de cette application Android contient de nombreuses classes, pour télécharger les codes sources, cliquez sur les liens suivants :
Pour télécharger directement l’application, il est nécessaire de se rendre sur ce site : http://codecamp2013.pbworks.com/w/page/62944320/applis2013.
Perspectives d’amélioration
Actuellement, la connexion entre le Smartphone et la matrice à LED se fait via une connexion filaire USB. Le premier objectif est donc de passer en sans-fil (Bluetooth ou Wi-Fi). Afin de donner tout son sens au projet. Les nombreux problèmes que nous avons eu pour gérer les différents modules Bluetooth nous ont conduit à utiliser une connexion filaire. Cependant, si vous arrivez à dompter l’Arduino BT-V06, vous pourrez supprimer l’Arduino MEGA ADK de la chaîne de transmission (ce qui réduira par la même occasion l’encombrement du système). En effet, vous pourrez dès lors uploader votre code sur l’Arduino BT-V06 via votre ordinateur (si ce dernier est équipé d’un module Bluetooth) et en même temps utilisé cet Arduino comme récepteur des informations envoyés par le Smartphone. Pour les plus curieux d’entre vous, un tutoriel pour s’initier à la manipulation de cet Arduino ce trouve ici : http://www.pobot.org/Arduino-BT.html. Il faudra également mettre à jour le code Android pour que les données qui sont envoyées à l’Arduino le soient par Bluetooth et non par USB.
Une autre amélioration possible est d’ajouter du côté de la matrice à LED un capteur de luminosité pour ajuster automatiquement l’intensité des couleurs en fonction de la luminosité ambiante (il faudra alors s’équiper d’une photorésistance et suivre notamment le tutoriel disponible ici à la cinquième étape).
Documentation complémentaire
- Documentation interne pour la création de l’environnement de liaison entre l’Arduino MEGA ACK et le Smartphone : [COMING SOON]
- Documentation relative à la prise en main de l’Arduino BT-V06 : http://arduino.cc/en/Guide/ArduinoBT ;
- Documentation pour la réalisation d’une liaison Bluetooth entre un microcontrôleur et un Smartphone sous Android : http://nononux.free.fr/index.php?page=elec-brico-bluetooth-android-microcontroleur ;
- Documentation relative à la connexion I2C : http://arduino.cc/forum/index.php/topic,32645.0.html et http://www.arduino.cc/en/Reference/Wire.
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.
