Actualités Projets

Étoiles de Noël

Envoyé par Tristan le 7 Déc 2014 dans À la une, Portfolio, Projets | 1 commentaire

C’est bientôt Noël ! Le moment parfait pour réaliser soi-même une guirlande électrique à mettre dans le sapin. Pour changer un peu des guirlandes électriques que l’on trouve dans le commerce, j’ai décidé de faire un guirlande de grands étoiles translucides, contenant chacune une LED multicolore par branche. Voici un aperçu du résultat en vidéo (en vertical désolé, mais sinon on n’aurait pas vu tout le sapin) :

Dans la vidéo, il n’y a qu’onze étoiles dans le sapin. L’objectif final est une guirlande de vingt étoiles mais le rendu est déjà sympa. Différents modes sont proposés : fixe blanc, changement de couleurs, clignotant blanc, fixe multicolore, scintillement blanc, rotation colorée des branches des étoiles, et flammes rouges et jaunes. Ce ne sont que des exemples, je n’ai pas encore eu beaucoup de temps pour programmer les effets.

Voici quelques photos détaillant la guirlande :

Si vous voulez construire une guirlande du même genre pour Noël, ce n’est pas très compliqué. Il suffit d’un peu de matériel, d’une imprimante 3D et de patience. Je détaille dans la suite comment j’ai fait ma guirlande, et ce que je compte améliorer.

Le matériel

Voici le matériel que j’ai utilisé pour construire cette guirlande :

du plastique ABS transparent 1,5 mm (environ 500g) ;
un ruban à LEDs Neopixel d’Adafruit de 2m avec 120 LEDs RGB (multicolores) contrôlables individuellement, PCB blanc ;
5m de câble 3G0,75mm noir pour la base de la guirlande ;
20m de câble RJ11 noir pour les branches vers les étoiles ;
un Arduino Nano pour contrôler les LEDs ;
une alimentation 5V 4A pour alimenter l’Arduino et les LEDs ;
un gros condensateur pour protéger le ruban et l’Arduino.

Au niveau des outils, il faut une imprimante 3D et un poste de soudure.

L’étoile en plastique

L’étoile est entièrement réalisée à l’imprimante 3D. Le modèle a été dessiné sous OpenSCAD. Il est disponible sur Github, avec les fichiers STL exportés pour l’impression. Le fichier est paramétrable. Il est possible de modifier le nombre de branches ou la taille de l’étoile par exemple.

La pièce à imprimer se décompose en 3 parties, dont 2 identiques. Voici à quoi ça ressemble une fois imprimé :

L’étoile est faite de deux moitiés, qui s’emboitent sur un anneau central. Ceci permet de fermer simplement l’étoile en force. Je n’ai pas mis de colle, même s’il pourrait être utile d’en ajouter pour solidifier le tout. Il y a une encoche en bas de chaque demi-étoile pour laisser passer le fil électrique. Il y a aussi un petit trou en haut de chaque demi-étoile pour accrocher du fil de pêche qui servira à accrocher l’étoile au sapin. La partie circulaire au centre de l’étoile servira de support au ruban à LEDs.

J’ai imprimé toutes les pièces avec un remplissage de 100%. Le rendu visuel est différent avec un remplissage de 0%, plus transparent. Vous pouvez faire des tests.

Pour faire une guirlande complète, il faut imprimer 40 demi-étoiles et 20 anneaux, ce qui peut prendre du temps selon la rapidité de votre imprimante 3D…

Les LEDs et le câblage

La partie électronique dans chaque étoile est extrêmement simple et se compose uniquement d’un bout de ruban à LEDs contenant 5 LEDs. Les dimensions de l’étoile sont faites pour que les LEDs s’alignent toutes seules face à chaque branche de l’étoile. Voici à quoi ressemble l’intérieur d’une étoile : La seule chose à faire pour construire l’étoile est de souder sur le ruban le fil qui servira à faire une branche de la guirlande. Ce fil est du fil RJ11. J’ai découpé des morceaux de 70cm pour chaque étoile. L’intérêt du câble RJ11 est qu’il a 4 conducteurs : le noir est la masse, le rouge me sert de 5V, le vert me sert de « data in » et le jaune de « data out ». Le fil de données fait ainsi un aller retour : il arrive par le vert, traverse le ruban, et repart par le jaune. C’est ce qui permettra de contrôler indépendamment toutes les LEDs. Voici le circuit global de la guirlande :

La câble horizontal en bas est le câble 3G0,75mm et les câbles verticaux sont les câbles RJ11. Avec 20 étoiles, il y a 3 mètres de guirlande, avec une branche de 70cm qui part tous les 15 cm. Il est aussi possible d’ajouter 1 mètre de câble en début de guirlande pour éloigner le contrôleur et faciliter la mise en place dans le sapin.

La longueur et la section du câble sont importantes. Plus le câble est long, plus il doit avoir une large section (une faible résistivité) pour que la tension dans l’étoile la plus éloignée reste suffisante. De même, plus il y a d’étoiles, plus l’intensité qui traverse le fil est importante. C’est pourquoi j’utilise des fils très fins pour les branches et un gros câble pour le « tronc » de la guirlande. J’utilise cet outil en ligne pour estimer les sections à utiliser.

Pour souder le câble RJ11 au câble 3G0,75mm tous les 15cm, il suffit de dénuder un petit tronçon (2cm) du cable 3G0,75mm au cutter, puis de dénuder à des endroits différents le fil 5V et le fil de masse. On soude ensuite directement sur les parties dénudées. Il faut ensuite couper le troisième fil (données) et souder le fil vert du câble RJ11 du côté du contrôleur et le fil jaune de l’autre côté. Pour éviter des court-circuits, j’ai mis de la gaine thermo-rétractable sur les fils de données. J’ai ensuite enrobé le tout dans du scotch d’électricien noir pour isoler et cacher les fils.

Une précaution importante à prendre lors de la construction de la guirlande est que l’étoile la plus proche du contrôleur doit être faite d’un bout de ruban pris à un début de ruban. Tous les 50cm sur le ruban, il y a une soudure et une première LED avec une résistance de protection devant le « data in ». C’est une de ces LEDs qui doit être la première connectée au contrôleur.

Le contrôleur

Le contrôleur est simplement un Arduino Nano qui se situe en bout de guirlande (côté « data in »). Il envoie les commandes par le fil bleu vers les LEDs et peut contrôler chaque LED indépendemment.

Le circuit électronique est composé de l’Arduino Nano, d’un condensateur (2 en parallèle en fait) pour protéger l’alimentation, et d’une résistance d’1 MΩ servant de « pull-up » pour un bouton qui fonctionne au toucher. Le bouton sert à changer de mode d’affichage. J’ai soudé les composants sous forme d’un « shield » pour l’Arduino Nano, ce qui m’évite de le souder. Je n’ai pas encore fait de boitier pour le circuit, ni décidé comment je vais faire le bouton, ce qui explique les fils dans le vide :

Le programme est fait sous la forme d’une librairie pour contrôler les étoiles (Stars.h et Stars.cpp) et d’un sketch avec plusieurs modes d’affichage. Il est disponible sur Github et utilise la librairie NeoPixel d’Adafruit (à installer sur votre ordinateur). Les modes actuels sont assez basiques. Je compte les améliorer.

Améliorations

Plusieurs améliorations sont possibles à partir de ce premier jet :

Faire un joli boitier pour le contrôleur.
Coller les étoiles pour qu’elles tiennent mieux, ou concevoir un meilleur système de fixation.
Améliorer les animations de la guirlande. L’Arduino Nano peut être utilisé pour faire des millions d’effets différents. je n’ai pas encore passé assez de temps là-dessus.
Ajouter des capteurs pour faire réagir la guirlande à son environnement : le bruit, la lumière, la date ou l’heure pourraient faire changer les animations. Tout est possible !
Ajouter une LED au centre de l’étoile. Je ne suis pas sûr de vouloir faire ça, mais certaines personnes me l’ont suggéré.

À vous !

Cette guirlande n’est pas très compliquée à construire. Il faut juste un peu de patience. Si vous en manquez, vous pouvez aussi construire une seule étoile, qui illuminera votre sapin. Même sans la partie électronique, l’étoile seule peut faire joli dans le sapin, et vous pouvez mettre n’importe quelle sorte de choses dedans.

Si vous faites évoluer l’idée, tenez-moi au courant !

Inauguration des Fabriques du Ponant

Envoyé par Sylvie le 14 Sep 2014 dans Téléfab, Blog | 0 commentaire

Le 20 septembre, dès 14h, les Fabriques du Ponant ouvrent leurs portes.
C’est l’occasion de venir faire la fête du numérique : des ateliers de découverte, de co-construction d’objets connectés, d’aménagements du lieu vous seront proposés.

Les activités pour les 9-17 « Les Petits Hackers » de la Maison du Libre seront aussi présentées à cette occasion.

N’hésitez pas à venir.

Sonar DIY : Fonctionnement et architecture générale

Envoyé par Pierre-Henri le 1 Sep 2014 dans Projets | 6 commentaires

This entry is part 2 of 2 in the series Sonar DiY

Un sonar, c’est un dispositif qui se base sur la propagation d’une onde acoustique pour détecter et positionner des objets. Le radar est basé sur le même principe, mais utilise des ondes électromagnétiques. C’est un dispositif qui existe dans la nature : beaucoup d’animaux utilisent un sonar pour se repérer, comme par exemple la chauve-souris ou les dauphins. Dans les sonars artificiels, on distingue les sonars passifs (on écoute seulement les bruits ambiants), et les sonars actifs (on émet un son, puis on écoute le retour du son émis).

Le but n’est pas de faire un cours théorique sur le sonar, mais d’en expliquer grossièrement le fonctionnement et les caractéristiques dans notre cas. Je vais donc m’intéresser uniquement au sonar actif (sous-)marin. Le principe d’un sonar actif est simple : on émet une onde à un instant t connu, puis on mesure l’intensité du signal sonore reçu. Chaque matériau a ses propres caractéristiques de diffraction et de réflexion des ondes sonores, et les éléments présents dans le faisceau d’émission de l’onde sonore vont donc chacun renvoyer une portion plus ou moins grande de l’impulsion vers l’antenne du sonar (en gros, un micro). En mesurant cette puissance du signal reçu en fonction du temps, on peut savoir quels éléments sont présents à quelle distance. En traitant un peu le signal reçu, on peut aussi obtenir d’autres informations, comme par exemple la vitesse de l’élément qui renvoie (avec l’effet Doppler). Un dispositif sonar doit donc être capable d’émettre et de recevoir une onde sonore, et de traiter cette onde.

Un sonar est donc constitué de trois éléments principaux :

une antenne, qui peut être soit émettrice (comme un haut parleur), soit réceptrice (un micro), soit les deux ;
un dispositif électronique de réception et d’émission,
un dispositif de traitement des données et d’affichage.

Je passe sur la partie électronique et traitement de données, qui ne présentent que peu de particularités. C’est un élément standard de toute chaine de transmission, et le sonar ne déroge donc pas à cette règle. Ca ne rend pas ces parties faciles à réaliser cependant, comme on le verra lors de la réalisation ! Je vais détailler dans la suite les caractéristiques de l’antenne.

Lorsqu’on émet une impulsion sonore, on va insonifier (c’est à dire « éclairer » mais avec une onde sonore au lieu de lumière) une zone. La zone insonifiée dépend de facteurs géométriques (forme du faisceau sonore émis), du milieu (vitesse de propagation du son, atténuation) et de facteurs temporels (en particulier, la durée de l’impulsion). Commençons par les contraintes : le milieu. L’eau de mer est un milieu hétérogène, mais l’équation de MacKenzie permet d’obtenir une approximation suffisante pour nos besoins. Vous trouverez un calculateur ici : http://resource.npl.co.uk/acoustics/techguides/soundseawater/. Dans les eaux brestoises, au mois de septembre, on peut tabler sur une température de 18°C en surface, et de 14/15°C à 30m de fond. Si on fait une approximation à 16°C, avec une salinité de 35, et une profondeur (très rarement atteinte !) de 50m, on obtient environ 1510m/s. La température est la variable qui influe le plus sur cette vitesse. Concernant l’atténuation de l’onde dans le milieu, on reste dans du classique : plus la fréquence de l’onde est faible, moins il y a d’atténuation. Par contre, d’après les règles de la diffraction, la pouvoir de résolution d’un sonar est de l’ordre de la longueur d’onde utilisée. Ainsi, plus on diminue la fréquence, plus la résolution diminue. Si on cherchait à trouver des poissons solitaires, ou si on travaillait dans la guerre numérique et la chasse aux mines sous-marines, il nous faudrait une résolution très faible, et on chercherait donc à avoir une fréquence élevée. Cependant, ce n’est pas du tout l’objectif. De plus, comme on le verra, la réalisation d’une antenne sonar est relativement complexe sans les moyens adéquats, et notre antenne sera donc forcément un peu limitée. On va donc chercher à minimiser l’atténuation plutot que de travailler sur la résolution. Ceci a également l’avantage de nous faire travailler sur des fréquences faibles (< 100kHz), plus faciles à manipuler en électronique. En l’occurrence, on choisira une fréquence de l’ordre de 25kHz pour des raisons pratiques que je détaillerai dans une partie suivante.

Maintenant qu’on a nos contraintes, voyons sur quoi on peut influer. On se place dans le cas idéal, dans lequel on peut réaliser n’importe quelle antenne. La forme géométrique du faisceau sonore est l’élément crucial lors de la conception de l’antenne. Il existe différentes configurations d’utilisation d’un sonar. Par exemple, un sondeur bathymétrique est en fait un sonar, qui envoie une onde sonore étroite directement vers le fond, et qui compte le temps nécessaire pour le retour, ce qui donne la profondeur. Il faut une onde étroite, afin d’éviter d’avoir trop de reliefs à l’intérieur de la zone insonifiée, mais cette contrainte n’est pas forte. Une faisceau en cône est tout à fait satisfaisant.

Il existe d’autres types de systèmes sonars. Par exemple, on peut positionner plusieurs antennes fixes sur des bouées dans une zone que l’on veut couvrir. Puis, on émet un (ou plusieurs) bruit(s) depuis un endroit connu, et on traite les données reçues sur chacune des antennes pour « cartographier » la zone. Dans ce cas, il n’y a que des antennes de réception, qui peuvent avoir un angle d’ouverture très large. Dans notre cas, un tel système est trop complexe à mettre en œuvre, mais il est pratique pour des systèmes de détection destinés à rester en place. Dans un système plus portable, le problème est de couvrir une large zone. On va donc utiliser un bateau qui déplacera l’antenne. En répétant des mesures le long du déplacement, on pourra également cartographier une zone sans avoir besoin de plusieurs antennes de réception. Dans ce cas, la zone insonifiée doit être la plus grande possible, mais également la plus fine possible. En effet, si le faisceau est trop large, on saura qu’il y a un objet à une distance connue, mais cet objet sera sur un arc de cercle, on ne pourra pas le positionner en deux dimensions. Par contre, il faut balayer une grande largeur autour du sonar. Un faisceau en cône ne convient donc pas, il va falloir une forme de pyramide très large sur le côté perpendiculaire au déplacement (altitude), et très étroit sur l’autre côté (azimut).

Afin de se débarrasser des problèmes liés aux mouvements du bateau et à la thermocline (changement brutal de température, qui réfléchit les ondes sonores), on va utiliser un sonar à balayage latéral (side scan sonar). Un tel sonar utilise un engin tracté (« towfish ») que j’appellerai poisson ou poisson tracté par la suite. L’antenne est installée sur le poisson, qui est tracté sous l’eau par le bateau. Le long du cable de tractage, on fait également passer les données reçues. Il est également possible de refaire ce travail sur un sonar embarqué sur le bateau.

Image issue de Wikipedia

Un schéma d’un sonar à balayage latéral est présenté dans l’image précédente, issue de Wikipedia. L’antenne est sur le poisson. Le faisceau idéal pour un transducteur de ce type est un faisceau rectangulaire. L’angle d’azimuth est très étroit (idéalement, 1° ou moins), et l’angle de l’altitude est large, idéalement 30° de chaque côté dans des eaux peu profondes. On trouve des antennes performantes à un prix abordable chez Garmin ou Humminbird, cependant les spécifications ne sont pas disponibles et ces antennes ne fonctionnent qu’avec l’électronique associée. On va donc construire notre propre antenne (ou transducteur).

Etant donnée la solution adoptée, il y a quatre grosses parties à concevoir et construire pour le sonar :

le transducteur (et son poisson)
la partie électronique de transmission, qui sera principalement analogique
la partie traitement du signal
l’affichage et le stockage des résultats du sonar

Les deux dernières parties seront numériques, il faudra donc aussi réaliser une interface analogique/numérique. Dans le prochain article, je commencerai à présenter la solution utilisée pour l’antenne.

Globe à persistance rétinienne

Envoyé par Tristan le 18 Août 2014 dans Portfolio, Projets, À la une | 3 commentaires

Le globe à persistance rétinienne consiste à donner l’impression d’un globe de LEDs sur lequel on peut afficher des images, en faisant simplement tourner à grande vitesse un demi-cercle sur lequel sont fixées des LEDs RGB. En allumant les LEDs exactement aux bons instants, on peut produire n’importe quelle image. Voici quelques exemples :

Ce globe est le résultat du travail d’une succession de personnes au Téléfab. Un premier projet S2 (CHAIEB Hassen, EL AABOUDI Khalid, RAYNAL Damien et TELLAT Wael, étudiants en première année) a permis de construire la structure du globe ainsi que les premières version des logiciels de contrôle et d’obtenir le premier prototype fonctionnel. Un projet d’intersemestre (Boris Claverie et Rémy Bétus, étudiants en troisième année) a permis de travailler sur la conception du contact électrique entre les parties fixes et tournantes et sur la synchronisation de l’image par rapport à la vitesse du moteur. Enfin, divers intervenants du Téléfab (Benoit Larras, Pierre-Henri Horrein et Tristan Groléat) ont travaillé sur la fiabilisation générale du globe (structure, électronique, logiciel). Cet article mis à jour régulièrement présente le fonctionnement du globe dans son état actuel, ainsi que les leçons apprises des tentatives précédentes.

Voici le globe à l’arrêt :

Il est composé de plusieurs parties importantes :

la partie fixe qui permet la stabilité du système, avec un moteur à courant continu qui fait tourner le globe ;
la partie tournante avec les LEDs contrôlées par un Arduino Mega ;
l’interface entre la partie fixe et tournante, qui permet à la partie tournante de recevoir de l’énergie et des ordres, et de détecter sa vitesse de rotation ;
la carte électronique de contrôle, fixe, qui fournit une alimentation à différents niveaux de tension, contrôle le moteur, et facilite la communication entre les parties fixes et tournantes ;
le logiciel embarqué, qui contrôle le tout ;
les logiciels de support, qui permettent de travailler avec le globe.

Le code et les objets 3D utilisés pour la conception du globe sont disponibles sur Github.

La partie fixe

La partie fixe est composée d’une planche de contreplaqué sur laquelle sont fixés quatre mâts faits de profilés d’acier en cornière. Ces mâts sont rejoints en haut par des profilés plats en acier qui se rejoignent au centre. À cet endroit, un trou est percé. L’axe de la partie tournante est une tige filetée. En haut, une tige lisse graissée est vissée sur la tige fileté. C’est ce qui sert à maintenir la tige.

Le bas de la tige est fixé au moteur à courant continu fixé au centre de la planche de contreplaqué. Il s’agit d’un moteur récupéré qui provient apparemment d’un essuie-glace.

Cette structure remplace la précédente qui était faite en bois, avec un seul mât. Elle est beaucoup plus rigide que la précédente, ce qui permet de parer en partie au balancement dû à un mauvais équilibrage de la partie tournante.

La partie tournante

La structure de la partie tournante est un anneau en plastique. Cette anneau est traversé par une tige filetée servant d’axe. Des trous sont percés sur l’anneau pour laisser passer 39 LEDs RGB réparties uniformément en un demi-cercle. Chaque LED est connectée directement à l’Arduino MEGA accroché sur l’axe au centre de l’anneau. Pour faciliter les connexions, un shield a été créé pour l’Arduino avec une plaque de prototype.

Pour diminuer les connexions, les cathodes des LEDs sont reliées. Ainsi, toutes les cathodes « rouge » sont reliées à un pin de l’Arduino, de même pour les cathodes « vert » et « bleu ». L’anode de chaque LED est connectée à un pin différent de l’Arduino. De cette manière pour contrôler 39 LEDs, il faut 39 + 3 = 42 pins. Cela signifie qu’à un instant donné, toutes les LEDs allumées ont la même couleur. Pour afficher des images, il faut donc allumer très rapidement chaque LED l’une après l’autre.

Cette partie est celle qui a été la moins modifiée depuis le début. La seule nouveauté est le remplacement des serre-joints utilisés pour fixer l’Arduino par des pièces faites à l’imprimante 3D, disponibles sur Github dans le dossier Things (ficher OpenSCAD ou STL arduino_holder).

L’interface fixe/tournant

Contact électrique

L’interface entre les parties fixes et tournantes est une partie cruciale du globe. Elle sert avant tout à alimenter en énergie la partie tournante. Pour cela, deux contacts doivent être faits : la masse, et un 9V qui permet d’alimenter l’Arduino Mega par le pin Vin. Un composant appelé collecteur tournant est disponible dans le commerce pour réaliser des contacts électriques tournants. Mais celui utilisé est fait maison à l’imprimante 3D. Les plans sont sur Github dans le dossier Things. (fichier OpenSCAD connection-base, les fichiers STL sont aussi disponibles).

Le principe est simple : deux larges rondelles sont utilisées comme contacts tournants. Elles sont fixées à la partie tournante par des pièce réalisées à l’imprimante 3D (une base, un séparateur pour éviter le contact entre les deux rondelles, et des petites cales pour tenir le tout fixé). Des fils électriques passent par l’intérieur de la base et sont soudés aux rondelles. Sur la partie fixe, deux petites vis poussées par des ressorts appuient sur les rondelles. Elles sont visibles à gauche sur la photo. Elles sont maintenues par une pièce faite à l’imprimante 3D, et sont chacune soudées à un fil électrique arrivant par derrière.

Ce mécanisme permet d’alimenter l’Arduino MEGA sans avoir de problèmes de fils qui s’emmêlent. Le défaut est que cela crée des frottements et du bruit. Mais le contact est fiable. Pour s’assurer que l’Arduino fonctionne sans problème en rotation, une grosse capacité a été placée sur la partie tournante en parallèle de l’alimentation de l’Arduino. Elle agit comme une mini batterie en cas de coupure de très courte durée.

Ce contact électrique a été une source majeure de difficultés dans la conception de ce globe. Différentes solutions ont été tentées : enrouler du fil de fer sur la partie tournante et tendre un fil entre deux bouts de bois pour appuyer sur la partie tournante, coller du scotch cuivré sur la partie tournante et tendre des bandes de cuivre avec une pièce faite à l’imprimante 3D, utiliser une prise jack en faisant tourner la partie mâle dans la partie femelle. Toutes ces solutions ont marché pendant un temps, mais se sont vite usées et ont cessé de fonctionner. La solution actuelle a duré beaucoup plus longtemps que ces solutions.

Détection de la vitesse de rotation

Une fonction annexe de l’interface fixe/tournant est de permettre à l’Arduino MEGA de détecter un point fixe lors de la rotation, pour avoir une référence et permettre d’afficher une image fixe. Ceci est réalisé grâce à une LED cachée dans le petit cube noir visible à droite sur la photo précédente. La LED est constamment allumée et fixe. Dans la partie tournante, en face de la LED, se trouve une photorésistance (fils violets qui arrivent en haut de la photo). Quand la photorésistance passe devant la LED, elle détecte la lumière. La photorésistance est directement connectée à l’Arduino MEGA, avec un montage pull-down, qui fait que la valeur 0 est lue constamment, sauf quand la photorésistance est devant la LED. Dans ce cas, la valeur 1 est lue par l’Arduino.

Au début, nous utilisions un montage pull-up, la photorésistance lisait un 1 constamment et un 0 en passant devant la LED. Mais nous avons remarqué que ce montage était beaucoup plus sensible au bruit provoqué par l’alimentation instable, provoquant des fausses détections difficiles à ignorer côté logiciel.

La carte électronique de contrôle

Alimentation

L’objectif principal de cette carte est d’alimenter l’Arduino et le moteur. Elle reçoit en entrée du 12V (ou un peu plus) fourni par un vieux transformateur récupéré. Pour alimenter l’Arduino, elle contient un simple régulateur 9V.

L’alimentation du moteur est un peu plus complexe car nous voulons pouvoir contrôler sa vitesse. Cela permet de le ralentir pour montrer aux gens le fonctionnement de la persistance rétinienne. Pour cela, nous utilisons un potentiomètre visible en bas à droite sur la photo. Mais le moteur demande beaucoup de puissance, il n’est donc pas possible de le mettre simplement en série avec le potentiomètre. La meilleure manière de contrôler un moteur à courant continu est d’utiliser des PWM, c’est à dire un signal carré alternant rapidement entre la tension maximale (les 12V reçus en entrée) et 0. Selon le rapport cyclique entre la durée à 12V et la durée à 0v, la vitesse du moteur change. Pour générer ces PWMs à rapport cyclique variable en fonction de la valeur d’un potentiomètre, nous avons utilisé un montage à partir du composant NE 555 trouvé sur instructables. Le montage décrit dans l’article est exactement celui réalisé ici. Les valeurs de résistance sont adaptées pour aller avec la valeur du potentiomètre, selon la formule indiquée dans l’article. Les PWMs générées ne supportent pas assez de puissance pour contrôler le moteur. C’est pourquoi elles sont utilisées comme signal de contrôle pour un transistor MOSFET, qui contrôle le moteur, suivant le montage décrit dans la partie « Simple Power MOSFET Motor Controller » de cet article.

Dans sa première version, le globe n’avait aucune carte de contrôle. Une alimentation réglable à deux sorties était donc nécessaire pour le faire fonctionner, ce qui était encombrant. Dans une version suivante, une alimentation de PC a été récupérée, et la vitesse du moteur était contrôlée par un gros potentiomètre en série avec le moteur. Ce système fonctionnait mais toute la puissance non utilisée par le moteur était dissipée par le potentiomètre, qui chauffait beaucoup et risquait de brûler l’utilisateur. La version actuelle est plus compacte et ne chauffe quasiment pas.

Communication avec la partie tournante

Envoyer des informations à la partie tournante sans l’arrêter permet d’apporter de l’interactivité au globe. Pour ce faire, un bus de communication entre la partie fixe et la partie tournante est nécessaire. Mais nous ne disposons que de deux conducteurs entre la partie fixe et mobile : la masse et le 9V. Pour ne pas compliquer la mécanique, l’alimentation peut être modulée par un Arduino fixe pour envoyer des informations à l’Arduino MEGA tournant. Pour ceci, il modifie la masse en la passant à 5V pendant de très courts instants, ce qui crée des impulsions. Le délai entre les impulsions permet de coder des 1 et des 0, et donc d’envoyer des messages binaires.

Le mécanisme pour créer ces impulsions sur le fil de masse est intégré à la carte. Il est visible sur la partie gauche de la photo et détaillé sur le schéma ci-dessus. La sortie GND_MOD peut être utilisée à la place de la vraie masse pour alimenter la partie tournante. Un condensateur branché en parallèle sur l’alimentation de l’Arduino évite qu’il ne soit perturbé par les impulsions. Ce condensateur est isolé du PIN de lecture (3) par une diode pour rendre les impulsions visibles par le PIN 3. L’entrée CTRL est un signal géré par l’Arduino externe. Quand cette entrée passe à 0, GND_MOD passe à 5V à cause du transistor (un MOSFET N) par l’intermédiaire d’une résistance de pull-up d’1kΩ. Sinon GND_MOD reste à la masse. Si aucun fil n’est connecté à CTRL, GND_MOD reste à la masse grâce à la résistance de pull-up de 10kΩ sur CTRL. L’Arduino de contrôle externe est donc facultatif.

Le circuit qui permet de générer les impulsions a été fait « au feeling », en s’inspirant du système de communication 1-wire. Des retours d’experts pour améliorer le circuit seraient les bienvenus. Mais pour le moment, ce circuit fonctionne bien.

Le logiciel embarqué

Le logiciel embarqué est en une librairie qui gère l’affichage et la communication, et des exemples d’utilisation. Tout le code est sur Github dans le dossier « Globe ».

Librairie : l’affichage

L’affichage est géré par la classe singleton Globe. Cette classe fournit une méthode d’initialisation (begin), à partir de son appel, l’affichage sur le globe est géré par l’Arduino. La classe fournit aussi des méthodes de dessin (setLed, getLed, rotate, setLedRot, getLedRot) qui permettent de modifier l’image affichée sur le globe. Les changements sont visibles dés le prochain rafraichissement de l’image. Enfin, la librairie contient des méthodes de synchronisation (delayRound, passedRound) qui permettent de synchroniser le déroulement du programme par rapport à la vitesse de rotation.

Le fonctionnement de la librairie est entièrement basé sur des interruptions : les interruptions du capteur de tour permettent de mesurer la vitesse de rotation et de commencer l’affichage ; les interruptions d’un timer permettent d’allumer les LEDs les unes après les autres. L’exécution de la librairies est critique et les interruptions ne doivent pas être inhibées. La librairie utilise une part non négligeable du temps du processeur, qui augmente avec la vitesse de rotation.

L’affichage de l’image se fait colonne par colonne et LED par LED. Une seule LED est allumée à un instant donné. Chacune des trois couleurs est gérée en binaire (allumée ou éteinte), ceci à cause du faible nombre de sorties analogiques de l’Arduino. Il serait possible d’afficher les colonnes couleur par couleur (rouge puis vert puis bleu) au lieu de LED par LED pour aller plus vite. Cette alternative a été tentée, mais elle nuit au mélange des couleurs.

Librairie : la communication

La communication entre la partie fixe et tournante ne fonctionne que dans un seul sens : l’Arduino fixe envoie des ordres à l’Arduino MEGA tournant. L’Arduino fixe est donc le maître et l’Arduino tournant est l’esclave. La librairie est donc divisée en deux classes : BusMaster et BusSlave. Elles ont toutes les deux une méthode d’initialisation (begin). Ensuite la classe maître a une méthode send et la classe esclave a des méthodes available, read et readString pour savoir si un message est disponible, lire un octet du message, ou lire une chaine entière.

La communication fonctionne par impulsions. Il y a 3 symboles : 0, 1, et fin qui correspondent à des délais différents entre deux impulsions. Chaque octet est envoyé suivi de 2 bits permettant de numéroter l’octet, d’un bit de parité, et d’un symbole fin. Chaque octet est envoyé à 3 reprises. Cette redondance est ajoutée pour fiabiliser la communication. Deux facteurs rendent la communication complexe : le bruit dû au contact tournant et l’imprécision de mesure due au fait que l’Arduino esclave s’occupe déjà de l’affichage, ce qui l’empêche de mesurer les délais avec précision. Le second facteur est au moins aussi important que le premier.

Du côté maitre, les messages sont envoyés de manière bloquante en utilisant la fonction Arduino delay. Du côté esclave, les mesures sont faites à l’aide d’interruptions et de deux timers. Nous avons essayé d’utiliser un ICP (Input Capture Pin) de l’ATMega pour rendre les mesures plus précises (le timer est déclenché automatiquement par les interruptions) mais les interruptions ICP ont une priorité trop forte qui ne peut pas être réglée, ce qui empêche le fonctionnement de l’affichage du globe.

Les exemples

Différents exemples sont disponibles avec la librairie : une carte du monde qui tourne sur lui-même, un texte qui défile et un bonhomme qui court à contre-sens du globe. Deux exemples interactifs sont aussi disponibles : la possibilité d’afficher le texte qu’on veut en l’envoyant sur le port série de l’Arduino fixe, ainsi qu’un jeu de Snake pouvant se jouer à 2. Pour ce dernier jeu, des joysticks doivent être connectés à l’Arduino fixe.

Les logiciels de support

Certains logiciels ne servent pas directement à faire fonctionner le globe, mais sont utiles pour le programmer. C’est le cas par exemple du programme ImageConverter disponible sur Github. Il a été développé en Java par les premiers étudiants qui ont travaillé sur le globe. Il permet de prendre une image, de diminuer sa résolution, de convertir ses couleurs, et de générer un format qui permet d’intégrer l’image dans du code pour l’afficher le globe. C’est ainsi qu’a été fait le programme avec la carte du monde qui tourne.

Sonar DIY : Introduction

Envoyé par le 10 Août 2014 dans Projets | 1 commentaire

This entry is part 1 of 2 in the series Sonar DiY

Qu’y a-t’il sous la mer ? C’est une question qui intéresse beaucoup de monde, mais dont la réponse peut se révéler assez compliquée. Selon les personnes, l’objectif n’est pas le même : les pêcheurs veulent repérer les poissons, les militaires veulent repérer les dangers potentiels, et d’autres veulent juste savoir ce qu’il y a au fond, par exemple pour préparer une plongée sympa…

Image issue du site Internet du SHOM

L’objectif de ce projet est de s’attarder sur ce troisième cas. Trouver une plongée sympa, comme sur l’image au dessus issue du site du SHOM, si on ne connait pas les coordonnées exactes à 10m près peut s’avérer délicat. En effet, une fois au fond, la visibilité est parfois limitée,et on peut passer à moins de 10 mètres d’une épave sans même se douter qu’elle est là. L’une des solutions est d’utiliser le sondeur d’un bateau pour repérer les changements brutaux de profondeur sous le bateau, mais la zone couverte par un sondeur dépasse rarement le mètre, ce qui est donc insuffisant. De plus, pour trouver une épave, on connait généralement le point de naufrage, mais avec les courants, une épave peut se situer à plusieurs kilomètres de là où elle a coulé !

Il existe donc plusieurs solutions :

avoir beaucoup de patience et de chance, et tenter de trouver au sondeur quand même (par expérience, c’est fastidieux !)
avoir beaucoup de contacts qui vous donnent quelques points précis. Cependant, ces points, c’est un peu comme pour les coins à champignons : c’est personnel !
avoir un beau budget, et s’offrir un sonar tout fait, qui coûtera pour les moins chers un peu plus de 2000$ (montés sur le bateau), et pour les plus chers jusqu’à plusieurs (dizaines de) milliers de dollars.

Aucune de ces solutions ne me satisfaisait vraiment, et j’ai donc décidé de chercher comment faire un sonar maison à prix réduit (attention, on parle quand même de centaines d’euros), avec une qualité correcte, pour explorer les fonds marins.

Un sonar, sur le principe, c’est simple : on envoie une impulsion acoustique dans l’eau (un bip), puis on écoute le retour en chronométrant le temps que ça a mis pour revenir. Comme on connait la vitesse de propagation du son dans l’eau (environ 1500m/s), on peut obtenir la distance parcourue par l’onde et donc la position de l’objet qui a renvoyé.

Ca c’est la théorie extrêmement simplifié. Mais dans la pratique, le problème est un peu plus complexe : comment émettre un son puissant dans l’eau ? Comment le récupérer ? Comment mesurer la distance et en déduire la position ? Comment l’adapter à un bateau ? Plus on rentre dans les détails, plus le problème se complexifie.

En cherchant un peu sur le grand-n-Internet, on trouve quelques références, pas mal de demande (sur les forums Arduino entre autres), mais rien de bien probant. La plupart des solutions proposées s’appuient sur des éléments de sonar ou de « FishFinder », ce qui augmente « un peu » le prix ! Puis, en cherchant un peu plus, on tombe sur une solution extrêmement séduisante : http://www.mbtelectronics.com/side-scan-sonar.php

En feuilletant le document, on se rend compte que le problème est effectivement très complexe, et qu’il implique de faire de l’électronique analogique, un peu de mécanique, et du matériau. Cependant, c’est la seule solution vraiment DIY que j’ai réussi à trouver, et j’ai essayé de m’y intéresser plus en détail.

Le but de cette série d’article est de présenter ma version du Sonar DIY proposé par Mark Thompson (que je remercie d’ailleurs ici, ses conseils lors de nos échanges de mails m’ont permis de me sortir de problèmes qui m’auraient autrement empêché de continuer !). Voici les contraintes que je me suis fixé :

un sonar utilisable par un non électronicien/informaticien/ingénieur. Même si la réalisation n’est clairement pas faisable sans connaissances en électronique, le but est de pouvoir mettre ce sonar « entre toutes les mains »
un sonar à moins de 250€. Le prototype va clairement couter plus cher, mais j’aimerais pouvoir fournir à la fin du projet une liste du matériel, qui permettra de le refaire pour un prix accessible. Bien sûr, je ne compte pas le coût de l’outillage, ou du matériel « classique » (comme par exemple le bout pour le tractage du poisson) qui sera utilisé
un traitement numérique. La solution proposée par Mark Thompson est intégralement analogique, ce qui ne permet pas d’envisager d’évolutions au niveau du traitement des données reçues. Le traitement sera réalisé en numérique dans le sonar proposé, et permettra à terme de faire un sonar de qualité correcte..

Je posterai sur ce projet de manière assez irrégulière, en fonction du temps et des avancées du projet. Le prochain post présentera de manière générale les différents éléments du sonar, et les différentes possibilités retenues.

Contrôle d’une voiture Arduino avec le cerveau

Envoyé par Selsabil le 2 Août 2014 dans Portfolio, Projets, À la une | 1 commentaire

Ce projet a été réalisé dans le cadre du projet S2 développement par 3 élèves de l’école Télécom Bretagne: Selsabil GAIED, Frédéric LECOGUIEC et Samia LAHBABI, et est tutoré par Sylvie KEROUEDAN et Bernard GOURVENNEC.
L’objectif du projet est de pouvoir télécommander un robot de type Arduino en utilisant les possibilités offertes par le casque cérébral Emotiv EPOC. Ce mini-robot possède une interface Bluetooth capable d’échanger avec un ordinateur auquel est connecté le casque et qui est aussi le support de codage pour le développeur. Par l’action de la pensée (penser au fait d’avancer, de s’arrêter) ce casque récupère les signaux cérébraux qui seront transmis à un ordinateur pour ensuite être envoyés, via Bluetooth, après traitement du signal, à notre robot qui se déplacera par la suite selon l’action qui lui aura été ordonnée.

Notre prototype fonctionne selon le principe illustré par le schéma bloc suivant:

Le logiciel Emotiv interprète la pensée et simule l’appui sur une touche du clavier. Le programme Python lit les entrées sur le clavier et envoie une commande par Bluetooth. Cette dernière est reçu par le robot par le biais de son module Bluetooth. La carte Arduino exécute donc la partie du code correspondante à la commande reçue, soit la marche ou l’arrêt des moteurs et par la suite la marche avant ou l’arrêt de la voiture.

Réalisation de la mini voiture Arduino:
La liaison entre le casque et le robot
Le casque Emotiv Epoc vient avec :
– une clef USB dongle qui permet ma liaison sans fil avec l’ordinateur
– un jeu de 16 têtes de capteurs placés dans un étui “humidificateur”
– un bidon de NaCl
– un manuel d’utilisation
– Le pack des logiciels Emotiv pour Windows et leur licence.Pour plus d’informations sur le casque visitez ce lien: http://www.arts-numeriques.info/emotiv-epoc/.

Pour utiliser le casque, nous avons procédé à l’installation des logiciels fournis avec sur un PC Windows équipé d’un module Bluetooth, la pose des capteurs sur le casque, l’humidification des tampons des capteurs avec le NaCl et la connexion de ce dernier via la clef USB.

Afin de réaliser la liaison casque-robot de notre prototype récupérer et pouvoir récupérer et envoyer les commandes du casque, nous avons passé par les étapes suivantes:
- Connecter le casque
- Calibrer le casque en s’entraînant avec le panneau de configuration Emotiv Control Panel
- Allumer le Bluetooth de l’ordinateur
- Allumer le Bluetooth de la voiture
- Appairer le Bluetooth de l’ordinateur et celui de la voiture en liaison série
- Noter l’adresse du port série utilisé pour cette liasion
- Connecter le logiciel Emokey au Control Panel et ajouter les deux règles suivantes:
  – Règle 1 : Simuler l’appui sur la touche 1 du clavier si l’intensité détectée par le casque de l’action « pousser » est supérieure à 80%
  – Règle 2 : Simuler l’appui sur la touche 2 du clavier si l’intensité détectée par le casque de l’action « pousser » est inférieure à 80%
- Exécuter le code Python,disponible sur ce lien https://github.com/sgaied/Robot-command–par-le-cerveau/blob/master/pythonSerialKey.py, dans une fenêtre terminal Windows (Ne pas oublier d’y insérer la bonne adresse du port COM de la liaision Bluetooth) .
- Pointer la sortie du logiciel Emokey vers cette fenêtre.

On observera ainsi notre voiture avancer et s’arrêter selon l’intention de l’utilisateur du casque.

Récepteur universel de télécommande USB

Envoyé par Pierre-Henri le 2 Juil 2014 dans Portfolio, Projets, Blog | 0 commentaire

Quand on monte un lecteur vidéo de salon pour lire ses vidéos, regarder ses images, ou écouter de la musique, l’un des problèmes auquel on se heurte est la télécommande. Plusieurs solutions existent, comme garder un clavier (idéalement sans fil) à proximité, ou utiliser un application smartphone dédié (la télécommande Android pour XBMC est une super application !), mais finalement, rien ne remplace la bonne vieille zappette !

Le problème, c’est que pour utiliser la télécommande sur un PC, il faut un récepteur infrarouge connecté au PC. Il existe quelques designs pour les connecter à un port série, mais les PCs avec port série ne courrent plus vraiment les rues. Dans cet article, je décris donc (très) rapidement un design que j’ai récupéré et adapter pour réaliser un récepteur infrarouge universel (ou presque) compatible USB.

Le design original (ainsi que le code) est disponible ici : http://dicks.home.xs4all.nl/avr/usbtiny/ . Le principe de ce design est le suivant : on utilise un microcontrôleur (ATTiny2313 de Atmel) qui va servir à réaliser un périphérique USB1 et à transmettre les données reçues au PC. Le récepteur infrarouge est un TSOP2438, qui est petit et capable de recevoir même en environnement bruité. Il envoie un 1 quand il reçoit un signal et 0 sinon.

Le code proposé sur la page permet de recevoir les données pour une télécommande de type RC5, ce qui couvre une énorme majorité des télécommandes existantes (la télécommande de la Livebox, des TVs Samsung ou Philips…). Dans le code, on attend des fronts montants ou descendants provenant du TSOP, et on compte le temps entre ces fronts. Chaque touche de la télécommande envoie une séquence de 1 et de 0 avec des temps différents, la lecture des temps permet donc de savoir quelle touche a été utilisée. Le microcontrôleur transmet ensuite via USB la séquence des temps, le PC est en charge de décoder. Le protocole de communication avec le PC est basé sur un design ancien, l’IgorPlugUSB, qui est supporté en particulier par LIRC (sous Linux) et par WinLIRC (sous Windows). Le module devrait donc être reconu immédiatement.

La configuration de LIRC et de WinLIRC se fait ensuite comme avec n’importe quelle télécommande.

Afin de faciliter la réalisation du projet, les fichiers de conception pour Eagle sont disponibles sur le GitHub du Téléfab (https://github.com/telefab/recepteur-inrarouge), ainsi que le code original modifié pour les dernières versions du compilateur. Et voici le résultat !

Système d’affichage de score pour un air-hockey

Envoyé par Abdelhak le 26 Juin 2014 dans Portfolio, Projets, À la une, Blog | 1 commentaire

Ce projet a été réalisé dans le cadre du projet S2 développement par 3 élèves de Télécom Bretagne: Bellamine Abdelhak, Abdelghani Morsi et Yang likuang, tutorés par Sylvie Kérouedan et Benoit Larras.

Contexte

L’objectif de ce projet est de réaliser un système électronique qui permet de calculer et afficher le score au cours d’une partie d’air-hockey. Ce système est installé sur la table d’air hockey du foyer des élèves de Télécom Bretagne.

Matériel utilisé

Carte Arduino uno.
Écran TFT LCD Shield.
Deux capteurs infrarouges SHARP.

L’interaction entre ces différents composants et leurs fonctionnalités peuvent être représentées sur le schéma suivant:

projet

Réalisation du système

Le prototype réalisé est constitué d’une carte arduino uno à laquelle est connecté l’écran LCD TFT Shield et les deux capteurs infrarouges Sharp.

Ce prototype permet d’afficher les scores des deux joueurs, le temps restant de la partie ainsi que l’incrémentation du score de l’un des deux joueurs s’il marque un but. D’autant plus le système réalisé permet de gérer le début et la fin d’une partie.

Vous trouverez ici la documentation sur le capteur Sharp et ici un lien pour télécharger les bibliothèques nécessaires pour programmer l’écran LCD TFT Shield.

La figure suivante représente le prototype réalisé :

Le branchement électrique du système est le suivant :

Le code utilisé pour programmer le système contient les parties suivantes :

Initialisation de l’écran : cela permet d’afficher dans l’écran le temps (90 secondes) et les scores des deux joueurs initialement nuls. Les boutons start et stop qui permettent respectivement de débuter et terminer une partie sont également affichés.

Mise à jour des scores : le score d’un joueur est incrémenté de un lorsque un but est marqué.

Gestion de la fin d’une partie : la partie se termine si le temps est écoulé ou si l’un des deux joueurs atteint un score de 7. A la fin d’une partie on affiche le vainqueur et le bouton start qui permet de commencer une nouvelle partie.

Vous trouverez ici le code utilisé pour programmer le système.

Panneau d’affichage de score sportif

Envoyé par Louis C. le 23 Juin 2014 dans Portfolio, Projets, À la une, Blog | 0 commentaire

Ce projet a été réalisé dans le cadre du projet S2 développement par 3 élèves de Télécom Bretagne: Louis CESBRON LAVAU, Alexandre Ferretti et Florent Perez tutoré par Sylvie Kérouedan.

Contexte

Nous avons été contactés par Olivier Moal afin de fournir un panneau d’affichage des
scores pour un club de football avec quelques contraintes comme le fait que le panneau
se contrôle à distance avec un téléphone, que l’arbitre se situera a environ 70m du
panneau(ce qui conduit à une comparaison des différentes liaisons sans fil possibles), que
celui-ci sera placé en extérieur(donc le panneau devra être étanche).

Nous devions donc réaliser: un panneau d’affichage de score, une application smartphone et la communication entre les deux.

Voici l’architecture de notre projet:

Matériel utilisé

Arduino Mega 2560
Arduino Uno
2 modules Xbee
1 module bluetooth
5 afficheurs 7 segments double
1 plaque de prototypage
de nombreux fils

Partie panneau

La première étape de notre projet consistait à utiliser ou créer le panneau qui servira à
l’affichage des scores. Par souci d’espace et d’argent nous avons choisi de créer une
version miniature d’un panneau d’affichage. Ce panneau sera piloté par carte arduino afin
de contrôler les afficheurs 7 segments que nous avons préférés aux diodes classiques ou
aux écrans à LEDs car plus petits, simples à contrôler(nous n’avons besoin que de
l’affichage de chiffres ou de lettres,pas de symboles), moins chers et disponibles au
FABLAB.
En effet l’afficheur 7 segments utilisé possède 8pins : 7 pour les différents segments et un
pour le point. Nous utiliserons 5*2 afficheurs 7 segments:2*2 pour afficher le temps(heures
et minutes), 2*2 pour afficher le score (limité ainsi à 99) et enfin 1*2 pour afficher la
période de jeu.

Nous avons testé, à l’aide de la carte arduino chaque segment afin de savoir quelle pin
contrôlait quel segment. Le souci quand à l’utilisation de tels afficheurs est le nombre de
fils assez conséquents à utiliser. Pour cela nous avons décidé d’utiliser une technique
« classique » : brancher les segments correspondants des différents afficheurs ensemble
et dans le code arduino de créer une boucle qui allume successivement un afficheur puis
l’autre avec un délai très faible ce qui a pour conséquence d’allumer les différents
afficheurs en reliant moins de fils à la carte arduino.

Vous trouverez le code du panneau ici.

Principe de fonctionnement des pins:

Panneau réalisé:

Partie transmission

Le besoin du client repose sur un contrôle à distance du panneau d’affichage et
cette partie est donc un de points clefs de notre projet. Nous avons donc commencé à
étudier les différentes technologies possibles pour choisir celle qui nous paraissait la
mieux adaptée. Il est nécessaire d’envoyer les informations présentes sur l’application
smartphone (score, chronomètre, période) au panneau d’affichage et ce pour une
actualisation en temps réel.

Nous avions choisi les ondes 433MHz mais faute de matériel nous avons utilisé la technologie Xbee.

Après avoir configuré les deux modules Xbee : un sur chaque arduino, pour qu’ils
communiquent ensemble. Nous avons codé la transmission (voir annexe). Le plus dur
concernant la transmission a été de configurer les deux modules grâce au logiciel X-CTU,
une fois cette opération faîte, le code de l’arduino est très simple, il suffit d’envoyer une
chaîne de caractère à l’autre arduino qui en fonction de cette chaîne de caractère lancera
une fonctionnalité du panneau.
Concernant le bluetooth, cela fonctionne de la même manière : une fois la connexion entre
le smartphone et l’arduino effectuée. La communication peut se faire. A chaque fois que
l’utilisateur effectue une action sur l’application : lancer le chrono, incrémenter le score,…
cela envoie un message bluetooth sous forme de chaîne de caractère à l’arduino qui le
transmet directement à l’autre arduino.
Il reste des améliorations à faire sur la communication : il n’y a pas de contrôle d efiabilité
mis en place. Si un message est perdu, l’arduino ne le sait et c’est donc à l’utilisateur de
se rendre compte que le message est perdu sans savoir où est le problème. On peut
envisager l’ajout de cette fonctionnalité.

Vous trouverez le code de la transmission ici.

Partie application

Pour commander le panneau à distance, il a été décidé d’utiliser une application Android.
L’application doit être sécurisée, pour empêcher que n’importe qui puisse contrôler le
panneau,
elle doit permettre de modifier le score, le nom des équipes, de lancer et de mettre en
pause le chronomètre. Il est également envisageable de mettre en place des pré-réglages
pour différents sports de façon à ce que l’incrémentation de points soit ajuster au
sport( Par exemple possibilité de rajouter 5, 3 ou 2 points d’un coup pour un réglage rugby
alors que pour un réglage foot on rajoute un seul point d’un coup).
L’application doit également être capable d’envoyer les informations de scores sur un
serveur.
En effet, nous développons également une application spectateur qui permet de visualiser
les scores de matchs à distance. D’où la nécessite d’avoir les informations stockées sur
un serveur.
Pour développer cette application, en java, nous avons d’abord du installer le SDK Android
et ajouter l’ADT Android sur Eclipse, ce qui lui permet de reconnaître les fonctionnalités
propres à Android et ses bibliothèques.
Nous avons choisi de développer l’application sur la version 4.0 (Ice Cream Sandwich)
d’Android.
Il a fallu ensuite configurer l’AVD, Android Virtual Device, qui permet de simuler un
terminal Android. Ce n’est cependant pas aussi pratique qu’un vrai terminal et cela ne
permet pas de tester les fonctions qui utilisent des organes de communication tel le GPS
ou le bluetooth, que nous utilisons.
Il est donc préférable d’utiliser directement un smartphone connecté au PC via USB.
Pour cela il faut activer le mode développeur du terminal. La procédure est différente pour
chaque version d’Android. Avec le Nexus 4 que nous utilisons, il faut taper 7 fois sur le
numéro de Build dans les paramètres du téléphone. On a alors accès aux options
développeurs. Il est nécessaire d’activer le débogage USB via ces options. Il faut ensuite
installer les drivers USB présent dans le SDK Android. Eclipse se charge alors tout seul
d’effectuer le transfert du fichier .apk vers le terminal pour effectuer les tests.
Viens ensuite le temps de la programmation pure. Il faut tout d’abord réaliser l’interface
graphique en créant un layout en xml. Eclipse possède également un outils graphique
pour réaliser cela. On ne peut cependant pas se passer d’utiliser le xml directement.

Une fois l’interface créer, il faut programmer son comportement. Lors du lancement de
l’application, il faut charger l’interface (avec la fonction setContentView) puis lire les
actions réalisées sur les différents boutons (avec la fonction setOnClickListener).
Ensuite il suffit de programmer les actions à effectuer lors de l’appui sur un bouton.
Pour cela on différencie les actions à faire grâce à l’ID du bouton enclenché (rôle du
switch). Pour la plupart des actions, il y a une action en interne, c’est à dire au niveau de
graphique de l’application et une action bluetooth, c’est à dire l’envoi de message
bluetooth vers l’arduino. Il faut donc créer des méthodes qui permettent d’utiliser le
bluetooth de l’appareil et de l’appairer avec l’arduino

Vous trouverez le code Java de l’application ici pour le code java et ici pour le code XML

Conclusion et améliorations envisagées

Nous avons ainsi réalisé un panneau d’affichage de scores à petite échelle incluant un
chronomètre, un numéro de période et le score de la partie. Ceci associé à une application
android reliée au panneau grâce à des connexions sans fil Xbee et bluetooth. Nous avons
respecté la plupart des contraintes du client excepté l’étanchéité ( une coque étanche
réalisée avec l’imprimante 3D du fablab devrait suffire).
De plus ce projet peut être repris pour faire un panneau d’affichage des scores plus
complet: affichage du nom des équipes, prise en compte d’encore plus de sports (le volley ou le hockey par exemple) puisque notre méthode de construction du panneau en lui-même permet l’ajout facile d’afficheurs 7 segments supplémentaires et que notre
application android peut être reprise comme base pour un nouveau projet(les fonctions
périodes, chronomètre, scores existent déjà).

Photo du projet complet

IMAG1464

EleFab

Envoyé par Aurelien le 18 Juin 2014 dans Projets, À la une, Applications Android, Portfolio | 0 commentaire

Ce projet a été réalisé dans le cadre du projet S2 développement par 3 élèves de l’école Télécom Bretagne: Pierre-Emmanuel DE SOLAGES,Arthur BOURGEOIS et Aurélien JANVIER est tutoré par Sylvie KEROUEDAN et Pierre-Henri HORREIN.

L’ objectif est d’augmenter la visibilité du Fablab et de permettre aux personnes intéressées d’avoir accès à l’information quant à son état d’ouverture. Pour cela nous avons divisé notre projet en 3 sous-parties : une application Android et deux systèmes composés d’arduino.

Ces trois sous-parties utilisent le site du Téléfab qui gère l’information de l’état d’ouverture du Fablab:

Matériel utilisé :

2 cartes arduino uno
2 shields éthernet
3 résistances de 1500 Ω
1 résistance de 10 kΩ
quelques LED RGB
3 LED rouges et 3LED verte
un bouton poussoir
du bois
des plaques de plexiglas

Partie Affichage RAK :

Pour réaliser ce boîtier, il est tout d’abord nécessaire d’écrire le code que devra exécuter la carte arduino pour effectuer des requêtes GET au site du Téléfab et donc récupérer l’information sur l’état d’ouverture de celui-ci.

voir https://github.com/aurelienjanvier/Ouverture_Telefab/issues/2

Ensuite , une plaque laissant apparaitre le mot « Telefab » a été réaliser à l’imprimante 3D en deux parties (car trop grande).

<<Modèles 3D à venir>>

Enfin, nous avons assemblé une matrice de LED RGB relier ensuite à la carte arduino. La matrice s’allume en vert lorsque l’état est ouvert, en rouge lorsqu’il est fermé et en bleu pendant les temps de chargement.

Une boîte en bois a alors été conçus pour contenir tous les composants. Pour que la lumière des LED se diffuse et que le rendu soit plus esthétique, une plaque de plexiglas est disposée entre la plaque « Telefab » et la matrice.

Partie Système Fablab

La carte arduino de ce boîtier contient un code basé sur le code de l’affichage RAK. En effet, le système récupère toujours la donnée sur l’information de l’état d’ouverture, mais cette fois-ci, il a aussi la possibilité d’envoyer une requête POST pour la modifier une fois le bouton pressé.

voir https://github.com/aurelienjanvier/Ouverture_Telefab/issues/3

Le boîtier est une nouvelle fois en bois mais une plaque de plexiglas laisse apparent la carte arduino et le système électronique.

Partie Application Android

Cette application s’appelle Elefab et a été développé grâce au logiciel eclipse en langage Java.

Elle est composée de 2 interfaces: une interface utilisateur et une interface administratrice.

Ci-dessus, on peut voir l’interface utilisateur dans les deux états possibles : ouvert ou fermé.

L’utilisateur peut alors rafraichir la page ou alors appuyer sur le bouton « Réglage » qui l’emmènera ,si il possède des identifiants corrects, sur la page administratrice où il pourra changer l’information.

Télécharger ici.

« Entrées plus anciennes

Entrées suivantes »