Projet Développement : Robot suiveur d’utilisateur
Equipe :
Paul PAQUIN, étudiant en 1ère année à IMT Atlantique
Grégoire PICHEREAU, étudiant en 1ère année à IMT Atlantique
Baptiste SCHMITT, étudiant en 1ère année à IMT Atlantique
Ruyi ZHENG, étudiant en 1ère année à IMT Atlantique
I – Contexte
Durant le cursus Ingénieur généraliste de l’IMT Atlantique, les élèves doivent réaliser un projet Développement. C’est dans ce cadre que nous avons proposé notre propre projet : Construire un robot capable de suivre de lui même un humain et de porter une charge. L’idée derrière ce projet est de développer une solution pour les personnes à handicap moteur. En effet, ceux ci peuvent se retrouver en difficulté dans beaucoup de situations de la vie courante.
Ainsi, nous avons réalisé un prototype qui grâce à des modules de magnétométrie et de GPS est capable de se localiser. Nous avons ensuite développé une application Android capable de se connecter au robot et de donner sa position. Grâce à ça, le robot peut alors suivre l’utilisateur.
II – Réalisation
– une plaque de contreplaqué de 2 centimètres d’épaisseur pour servir de support
– deux planches de bois 20×5×5 cm
– deux planches de bois 10×5×5 cm
– quatre planches de bois 25×7×1 cm
– deux moteurs de la gamme Maxon Motor A-max Program de 12 V
– deux roues de 10 cm de haut
– une roue non motrice qui se met sous le châssis
– deux adaptateurs moteur-châssis créés à l’aide d’une imprimante 3D
– deux adaptateurs moteur-roue créés à l’aide d’une imprimante 3D
– une batterie lithium-polymère TURNIGY 1000mAh trois cellules de 11.1 v
– une carte Arduino Uno
– une breadboard
– un magnétomètre Adafruit HMC5833l
– un module Parallax PAM-7Q pour le GPS
– un module Bluetooth HC-05
– une carte L298N
– un smartphone Android
– des vis et des câbles
2 ) Plateforme
Nous avons décidé de concevoir un châssis en bois à deux étages. Le premier étage servant au transport du système de positionnement embarqué ainsi qu’à celui des batteries, le second couvrant le premier, ayant lui pour but de servir de support où l’on pourrait déposer la charge.
Pour soutenir le châssis et pour le mettre en mouvement nous avons convenu de fixer sur les côtés avant deux moteurs de la gamme Maxon Motor A-max Program de 12 V chacun reliés à des roues de 10 cm de haut, fixe sur axe ainsi qu’en polypropène et en caoutchouc. Enfin nous avons décidé de placer une dernière roue non motrice, une roulette pivotante en caoutchouc à l’arrière du véhicule.
Pour faciliter la suspension des moteurs au bas du châssis nous avons convenu de modéliser des supports pour moteurs. De même, nous avons choisi de concevoir des adaptateurs entre les moteurs et les roues pour améliorer la transmission. La réalisation de ces parties s’est faite sous SolidWorks. Nous avons aussi pu retravaillé certaines pièces déjà à disposition sur des sites dédiés comme Thingiverse tant les moteurs et les roues que nous avions choisi semblent être des standards dans le milieu de la conception robotique amateur.
Une fois réalisées, les pièces sont alors converties en fichier .stl, format lisible par l’imprimante 3D que nous utilisons, une Ultimaker 2+. Le traitement de ses fichiers s’est fait par le logiciel dédié Ultimaker Cura permettant de visualiser la future impression 3D et ainsi de repositionner la pièce si sa disposition n’est pas optimale, d’ajouter un support pour stabiliser l’impression mais surtout de voir si il est possible ou non de réaliser une impression sans problèmes (les morceaux de la pièce ne pouvant être imprimés s’affichant en rouge dans le logiciel).
On place ensuite les moteurs à courant continus dans les supports en plastique dédiés imprimés par l’imprimante 3D, pour bien fixer les moteurs il est possible de visser les supports pour resserrer le tout. On ajoute alors les adaptateurs entre les moteurs et les roues, eux aussi imprimés en 3D, qu’on visse alors dans les adaptateurs de hub et dans les roues en plastique.
On a alors le premier étage de la maquette qui contiendra tout le matériel nécessaire pour la détection de l’utilisateur et la commande des moteurs. On réalise alors un second étage pour pouvoir disposer la charge. Afin d’observer les composants et de vérifier leur bon fonctionnement durant un essai on opte pour une plaque de plastique en tant que capot pour le premier étage. Une fois installée et vissée on rajoute des plaques de bois tout autour de la plateforme pour servir de rebord de manière à ce que la charge ne puisse pas tomber.
3 ) Code Arduino
Comme le projet contient de nombreuses fonctionnalités, et que beaucoup de composants fonctionnent différemment, nous avons choisi de programmer le code, qui sera téléversé dans le robot, par classe. En effet, cela permet de tester séparément chaque fonctionnalité avant de les mettre ensemble. Ainsi, le code est facilement debuggable et on peut s’y retrouver bien plus facilement.
Pour ce faire, nous avons écrit des classes en langage C++, que l’on a ensuite placées dans le répertoire Librairie du dossier Arduino.
Enfin, un code Arduino va importer les classes nécessaires et va les appeler selon ses besoins.
Le code est présent sur le GitHub ici.
4 ) Electronique
a . Module L298N
Le prototype se déplace à l’aide de 3 roues: 1 roue pivotante et 2 roues motrices. Les moteurs sont alimentés par une batterie lithium-polymère TURNIGY 1000mAh trois cellules de 11.1 v. Etant donné la taille de notre prototype, nous avons décidé d’utiliser un module « Double Pont-H » de type L298N destiné au contrôle des moteurs continus (des Maxon A-motor DC) pour sa facilité d’utilisation et sa compatibilité avec la carte Arduino Uno que nous utilisons.
Cette carte est composée de 3 pins par moteur : 2 pins contrôlent le passage du courant dans les deux fils reliant la carte L298N au moteur et 1 pin PWM qui est utilisée pour contrôler la vitesse du moteur.
Les pins IN1, IN2, ENA sont reliés aux pin de l’arduino 7, 8 et 5; et gèrent le moteur A.
De même, les pins IN3, IN4, ENB sont reliés aux pin de l’arduino 12, 4 et 9; et gèrent le moteur B.
Pour contrôler les moteurs, puis la plateforme, nous avons créé des bibliothèques Arduino spécifique. Nous disposons ainsi d’une classe Moteur qui permet de contrôler facilement les moteurs à partir d’un nouveau sketch Arduino, et d’une classe Plateforme qui permet de contrôler aisément l’interaction entre les deux roues.
A noter que cette Plateforme est la classe mère de PlateformeIntelligente qui permet aussi de rejoindre un point dont on connaît la distance et l’angle entre le vecteur robot-point et la médiatrice du segment joignant les deux roues du robot.
b . Module Adafruit HMC5833l (magnétomètre)
Pour calculer l’angle entre la médiatrice du segment joignant les deux roues arrières du robot et l’utilisateur, nous utilisons un intermédiaire, le pôle nord, dont la mesure est plus précise grâce à l’utilisation du champ magnétique terrestre. Pour ce faire, nous utilisons donc un magnétomètre (module Adafruit HMC5833l).
Ce magnétomètre est posé à l’horizontal au même endroit que l’arduino. Nous avons dû le tester et changer son orientation pour que le magnétomètre donne des mesures cohérentes avec nos calculs. C’est à dire que nous avons placé le magnétomètre de sorte que lorsque le robot soit dirigé vers le pole nord, l’angle mesuré soit égal à 0. Le magnétomètre a ensuite été fixé pour conserver cette cohérence. En effet, toute erreur sur l’orientation de référence de celui-ci entraîne une erreur sur la mesure.
Le magnétomètre est relié aux pins analogiques A4 et A5 de l’arduino par ses pins SCL et SDA. Pour récupérer les mesures du magnétomètre, nous avons créé une classe, MagneticRead, qui renvoie la valeur en degré ou en radian selon la méthode appelée du heading (le heading étant la direction selon laquelle le véhicule est dirigé)
c . Module Parallax PAM-7Q pour le GPS
Le module GPS que nous utilisons pour le projet est le module Parallax PAM-7Q. Il se situe sur la même breadboard que le magnétomètre.
Le gps utilise la pin digital numéro 6 de l’arduino relié à la pin TX du module.
Les mesures du gps sont elles aussi récupérées à l’aide d’une classe que nous avons créée. Au départ, nous comptions utiliser une classe déjà développée pour ces besoins, nommé TinyGPS.
Malheureusement, nous n’avons pas réussi à la faire fonctionner, nous avons donc utilisé la bibliothèque SoftwareSerial pour récupérer les données gps brutes et les traiter dans notre classe GPS (c’est à dire récupérer les informations utiles).
Nous avons aussi testé les conditions de fonctionnement du gps. Nous nous sommes vite rendus compte que le gps ne fonctionne qu’en extérieur. Celui-ci semble de plus continuer de fonctionner en cas de pluie légère et de temps nuageux.
d . Module Bluetooth HC-05
Grâce à la technologie Bluetooth, de nombreuses informations peuvent transiter entre le smartphone de l’utilisateur et le robot.
La pin RX du module est connectée à la pin 11 de l’arduino tandis que la pin TX du module est connectée à la pin 10 de l’arduino.
Une bibliothèque, CommunicationManager, a été développé pour récupérer les informations en provenance du Bluetooth et les interprète selon un protocole de communication.
e . Capteur ultrason HC-Sr04
Nous avons ajouté des capteurs ultrasons HC-Sr04 au robot qui mesurent la distance entre le robot et l’obstacle. Les bornes de « trigger » et d’« écho » sont reliées à la pin digital 13.
Pour contrôler ces capteurs et récupérer les mesures réalisées, nous avons utilisé la classe Capteur présente de base dans la bibliothèque arduino. Les différentes réactions du robot en fonction de la distance avec l’obstacle sont présentes dans la classe plateforme.
Ainsi, toute cette partie n’est pas visible dans le sketch final, mais est présente dans la classe PlateformeIntelligente. C’est d’ailleurs ce fait qui justifie l’écriture de cette classe héritée : le comportement de cette classe, qui arrête le robot dès qu’un obstacle est détecté était nuisible pour notre phase de test. Le robot s’arrête ainsi en cas d’obstacle présent à une distance inférieure à 30 centimètres, fait tourner ses capteurs pour détecter une voie où il n’y a pas d’obstacle et se déplace dans cette direction.
f . Schéma des branchements
5 ) Interface Android
Afin de permettre au robot de suivre automatiquement les mouvements de l’utilisateur, nous avons besoin d’un appareil mobile capable d’envoyer des informations de localisation. Nous avons donc créé une application pour smartphones Android avec Android Studio. Application et robot communiquent via Bluetooth, l’application obtient l’information de la position via GPS, et la direction (heading) de l’utilisateur via la boussole interne du mobile (compass).
Ensuite, l’application envoie les informations au robot via le canal Bluetooth, en même temps le téléphone mobile reçoit également des informations envoyées par le robot. L’application peut analyser le message et afficher la distance et la puissance sur l’interface Androïde. Afin de s’assurer que chaque fonction peut être réalisée, nous allons faire une application distincte pour chaque fonction, y compris la communication Bluetooth, GPS, Boussole.
Ayant rencontré des difficultés pour écrire une application Bluetooth, nous avons décidé de ne pas rechercher la totalité des appareils Bluetooth à proximité. Cependant, la recherche d’autres appareils utilisant Bluetooth effectuée par le téléphone portable permet de trouver le module Bluetooth (HC-05) de la plateforme. Après recherche, nous avons résolu le problème.
Depuis, l’application peut rechercher, se connecter et créer un canal Bluetooth pour échanger des informations.
La plupart des smartphones modernes sont équipés d’un GPS qui fonctionne avec deux modes, le mode réseau et le mode satellite : le mode réseau utilise des méthodes de ciblage et est utilisé en intérieur, car le signal satellite est faible, ce qui impacte la précision de localisation. Or, les méthodes implémentées dans ce mode ont une efficacité indépendante à la qualité de réception. Il est cependant impossible d’obtenir les informations relatives à la direction. Quand il est à l’extérieur, le positionnement par satellite est utilisé. En raison de son positionnement rapide et sa grande précision, des informations importantes telles que la direction et la vitesse peuvent être obtenues.
Comme précédemment mentionné, le GPS ne peut pas obtenir d’informations de direction dans le contexte de positionnement par réseau, d’autres méthodes sont donc nécessaires pour obtenir la direction. Heureusement, la plupart des téléphones mobiles ont une fonction de boussole, et nous pouvons donc obtenir cette information capitale.
Dans le processus de communication Bluetooth, deux canaux (des threads) sont demandés : le premier est utilisé pour envoyer les informations de localisation toutes les trois secondes, le second reçoit les informations envoyées par le robot et affiche l’interface après le traitement. Cela nécessite des capacités de multithreading, malheureusement nous ne disposions pas des connaissances relatives à implémentation de cette technique. Cependant, nous avons trouvé une bibliothèque traitant spécifiquement le multithreading ce qui nous a permis de mettre en place cette fonction.
Afin d’échanger des informations sans problèmes avec le robot, nous avons conçu un protocole de communication pour réguler la structure de l’information.
La plupart de nos fonctions ont été implémentée et deux affichages ont été développés selon que le robot est en mode suivi ou en mode contrôlé par l’utilisateur.
6 ) Protocole de communication
Grâce à la technologie Bluetooth, de nombreuses informations peuvent transiter entre le smartphone de l’utilisateur et le robot. Ces informations ainsi que leurs impacts sur le fonctionnement du robot et de l’application sont très variés. Cela impose que chaque type d’information ait un format reconnaissable parmi les autres.
Cependant, comme les équipes chargées de développer la partie application Android et la partie code Arduino ne sont pas les mêmes, il convient de rédiger un unique protocole de communication respecté par toutes les équipes. Un tel protocole garantit non seulement que les formats d’une information donnée soit les mêmes pour l’émetteur et le récepteur mais il a aussi la capacité d’évoluer si de nouvelles fonctionnalités venaient à être implémentées sur le robot.
La spécification du protocole choisie ne retransmet aucun message perdu ou erroné durant son trajet. En effet, un mécanisme de retransmission pourrait rendre le robot beaucoup moins réactif.
Toutes les informations suivent le format suivant : ‘#’ + type + ’\’ + Données + ‘$’
Les champs ‘type’ et ‘données’ varient selon le type de donnée envoyée tandis que ‘#’ et ‘$’ indiquent respectivement le début et la fin du message. Le récepteur sait alors si le message qu’il a reçu est complet ou non. De plus si le champ ‘données’ contient plus qu’une seul donnée alors celles-ci sont séparées par un symbole ‘\’ pour bien faire la distinction.
Le détail du protocole est présent sur le GitHub ici.
III – Résultats
Notre projet de réalisation d’un robot suiveur d’utilisateur assisté de son application compagnon s’est soldé par la mise en place de systèmes embarqués placés dans une plateforme construite en bois et en plastique et dont les composants sont appairés au smartphone de l’utilisateur.
Un des critères de fonctionnement du robot qui fait défaut au prototype est sa précision, notamment du à l’approximation de l’ordre du mètre des GPS modernes.
En effet la solution technique utilisée semble améliorer la précision de la course du robot cependant on peut rester mitigé sur les déplacements en intérieur tant le GPS voit son efficacité diminuée dans la majorité des bâtiments.
Finalement, il semble que le projet puisse être amélioré en intégrant une alternative au GPS en intérieur et en prenant une Arduino Mega parce qu’elle permet de mettre plus de composants nécessitant des protocoles de communication.
Utilisation du mp3 player shield
La carte en question est le modèle sparkfun.com mp3 Player Shield 4-1-11. Elle permet de lire des fichier audios à partir d’une carte SD et a une prise jack pour un haut parleur classique.
Toutes les infos utiles sont sur ce site, avec un très bon tutoriel : https://learn.sparkfun.com/tutorials/mp3-player-shield-hookup
la carte est assez ancienne, et les librairies actuelles d’utilisation des fichiers lourds sur carte SD (libraries SdFat) n’est plus compatible. Retrouvez les librairies compatibles sur ce github : https://github.com/madsci1016/Sparkfun-MP3-Player-Shield-Arduino-Library/releases/tag/1.02.02 (mettre les dossier des librairies SdFat et SFEMP3Shield dans /home/fablab/sketchbook/librairies/)
(merci à ce forum pour l’aide : https://forum.arduino.cc/index.php?topic=517154.0)
Fête de la science 2017
Bonjour bonjour!
Comme chaque année partout en France du 7 au 15 octobre à lieu la fête de la science!
Comme chaque année Océanopolis coordonne cet événement pour le département du Finistère…
Et depuis 2 ans nous nous organisons avec l’UBO Open Factory et le département informatique de l’UBO pour proposer une animation sous le signe de la découverte de la robotique, de l’informatique et des machines de fabrication numérique :
LE FABULEUX LABORATOIRE!
Du 11 au 15 octobre nous serons donc à Brest, au Quartz (pour accueillir le public et leur présenter plein de petites choses très cool!
Nous accueillerons des scolaires le jeudi 11 et vendredi 12 octobre, de 9h à 16h.
(Environs 3500 enfants sur deux jours)
Le week-end c’est l’ouverture au grand public, de 10h à 18h.
Nous sommes entrain de préciser les choses ensemble mais ce qui est sûr c’est que nous allons avoir besoin de mains, de présences, de coolatitude et de bonne humeur durant l’événement… Alors si tu as l’une de ces qualités ou bien toutes ou bien aucune, mais tu souhaiterais quand même t’investir, tu es le-la bienvenu-e ! Tu n’as qu’à passer au Téléfab faire un petit coucou et nous donner tes disponibilités entre le 11 et 15 octobre.
Woilou!
Bois souple
Voici quelques expérimentations pour rendre le bois souple.
A l’aide de différents motifs découpés à la découpeuse laser, répétés plus ou moins de fois sur une surface, nous pouvons donner une certaine souplesse au bois: c’est ce qu’on appelle la technique du lattice hinge (traduction française: charnière en treillis). Cette technique est inspirée du kerfing (de l’anglais kerf qui signifie entailles/traits de scie).
» Le kerfing est une technique à l’origine pratiquée par les luthiers pour cintrer le bois à froid. Il s’agit de réaliser des rainures dans le sens perpendiculaire au bois, pour l’affiner localement et lui prêter une plus grande souplesse. «
Pour l’instant nous avons réalisé ces essais sur deux types de bois : du medium 3mm et du contreplaqué peuplier 3 mm. Nous nous sommes aperçu que certain motifs fonction mieux sur le medium que sur le contreplaqué, et inversement. Les échantillons sont tous présents au fablab. Nous allons poursuivre les tests sur du pmma et sur d’autres épaisseurs.
Réalisation d’une maison à serrures type Montessori
En surfant sur le net, j’ai trouvé des jouets pour bébés utilisant des vraies serrures qui m’ont semblé bien plus pertinents que les jouets tout en plastique. On les trouve communément sous le terme de maison à serrures Montessori.
J’avais bien envie d’en réaliser une par moi-même. Après avoir parcouru le Web, j’ai décidé de partir sur un format « tableau à serrures » plutôt que maison, et j’ai choisi le thème de la grange pour pouvoir mettre derrière chaque porte une photo d’un animal de la ferme (que j’ai récupéré d’un livre cartonné pour enfant).
J’ai fait un dessin sous inskape et voici ce que cela donne :
Planche 1 : dessin de l’avant
Planche 2 : Arrière
Je l’ai mis aux dimensions de la découpe laser que je vais utiliser à savoir environ 45 cm de haut et 30 cm de large. Je vais utiliser du contreplaqué de peuplier de 5mm d’épaisseur et il y aura une face avant et une face arrière ce qui me permet d’utiliser des vis pour fixer les charnières et les différentes serrures et d’avoir un tableau plus solide.
Premier essai :
Je fais le premier essai avec la planche arrière car c’est le dessin le plus simple. Pour la découpe laser, en noir elle grave et en rouge elle découpe, mais il faut choisir les bons paramètres Puissance vs Vitesse. Je profite des tests faits par ma collègue Solène Geffroy lors de l’élaboration d’un gabarit de découpe.
Pour la coupe, je mets P=90 et V=2
Pour avoir l’effet « grange en bois » je me dis qu’il faut une gravure assez forte et je mets 60 pour la puissance et 20 pour la vitesse sur la couleur noire. Il s’avère que c’était un mauvais choix : la gravure est super longue et trop profonde. J’obtiens quand même une première mouture de mon projet.
Pour l’avant je vais faire autrement :
Couleur noire : P=20 et V=90, c’est un peu léger en gravure mais ça va vite (si je recommence je mettrais plutôt P=40 et V=40 pour avoir un peu plus de profondeur creusée dans le bois)
Quelques images de la découpe laser
J’obtiens 2 parties face avant et arrière, mais pour pouvoir mettre les serrures diverses, il me faut un peu de profondeur, je prends du médium MDF 10mm que je découpe également à la découpe laser (celle à laquelle j’ai accès demande plusieurs passes pour réussir la découpe et avec une petite meuleuse dremel j’enlève les zones très noircies par la laser)
Peinture, fixation arrière + médium + devant puis positionnement charnières et des différentes serrures :
- verrou à poussoir (en bas à droite)
- serrure à clef (en bas à gauche)
- entrebâilleur de porte (au milieu à gauche)
- crochet à levier (au milieu à droite)
- crochet contrevent (en haut)
Après la peinture (indiquée rouge sur le pot) je trouve que c’est un peu trop rose fluo, j’atténue ce fluo en mettant une couleur différente pour chaque porte.
Derrière chacune des portes il y a un animal de la ferme découpé dans un vieux livre pour enfant.
Il ne reste plus qu’à mettre les portes, les serrures (je rajoute un contrefort derrière les portes pour assurer le vissage). Quelques photos des différentes étapes.
Et voici la grange au final
Il ne reste plus qu’à espérer que le petit Maël qui va recevoir cette maison s’amusera beaucoup à découvrir et à s’approprier les différents mécanismes.
Construction d’imprimantes 3D : la carte électronique
Ce mardi, nous avons continué l’atelier de la semaine dernière. Nous n’arrivions pas à contrôler correctement l’imprimante A car certains moteurs fonctionnaient de manière inversée. Nous avons donc décidé de reflasher la carte pour changer les réglages.
La carte minitronics est compatible avec l’IDE Arduino. Le guide de construction indique le lien vers le dépôt Github qui contient le firmware (attention, nous avons la version 2.5 de la Foldarap). Il n’y a presque rien à changer, à part la fréquence de fonctionnement du port série dans un define. Par contre, il faut configurer l’IDE Arduino pour la carte Minitronics, en suivant les explications ici (à faire à la main, il y a un lien vers une version preconfigurée, mais on est forcé de s’inscrire).
Une fois la carte flashée, l’imprimante marche parfaitement. Malheureusement nous avons trop chauffé le filament qui s’est bloqué, il va donc falloir faire un peu de démontage pour nettoyer tout ça.
La suite dans 2 semaines
Exceptionnellement, aucun atelier n’est prévu la semaine prochaine. Le prochain atelier aura lieu mardi 7 février à 18h30. Et on fera marcher au moins une imprimante !
Atelier construction d’imprimantes 3D
Au Téléfab, on a récupéré deux imprimantes 3D Foldarap en cours de construction, venant des Fabriques du Ponant. On en a profité pour faire ce soir un atelier pour essayer de les faire marcher. Voici l’état des lieux
Imprimante A
Une première imprimante 3D est quasiment terminée. Tout est monté et assemblé, mais l’imprimante ne marche pas.
On a trouvé un soucis avec la carte : impossible de communiquer en utilisant Pronterface. Ça vaudrait le coût de tenter de reflasher la carte pour voir si elle peut ressusciter.
Après avoir remplacé la carte, tous les actionneurs semblent marcher. Mais certains axes sont inversés, et on dirait aussi que les end points sont lus à l’envers (activé quand ils le sont pas). Il va donc falloir vérifier les branchements et voir ce qu’on peut corriger en logiciel.
Imprimante B
La deuxième imprimante est bien moins avancée. Elle est en partie montée et des choses sont à démonter car elles ont été faites à l’envers.
On a aussi découvert que le support de la tête d’impression est cassé. On a donc lancé l’impression d’une nouvelle pièce. Ça nous a permis de retrouver les sources des pièces 3D (rechercher github dans le guide d’assemblage).
La suite mardi prochain
On continuera mardi prochain à partir de 18h30. Venez nous aider !
Robot Scribe
Dans le cadre de notre projet développement S2, nous devions concevoir un robot capable d’écrire des caractères avec un stylo, facile à utiliser et à moindre coût.
Nous avons pour cela décidé de construire un robot commandé par une application Android qui envoie par Bluetooth les caractères à écrire.
Notre robot est constitué d’un moteur et un train d’imprimante récupérés sur une vieille imprimante, 3 servomoteurs, une carte Arduino, une carte Ardumoto et des pièces pour relier le tout, imprimées à l’aide d’une imprimante 3D. Les pièces imprimées sont : les broches (qui constituent le bras du robot et qui servent à tenir le stylo) et la plate-forme pour relier le train d’imprimante et le bras. Le train d’imprimante va servir à translater le montage lorsqu’on a fini d’écrire un caractère. Deux des servomoteurs sont utilisés pour contrôler les broches qui tiennent le stylo et le troisième sert à soulever la plate-forme lorsque l’on veut déplacer le crayon sans écrire.
Le principe de notre robot consiste donc à envoyer des caractères en Bluetooth à partir de l’application et d’effectuer un traitement avec un code Arduino en fonction de la lettre reçue. À La réception d’un caractère, nous allons donc baisser le crayon, écrire le lettre reçue, lever le crayon et déplacer le dispositif avec le train d’imprimante pour écrire la prochaine lettre.
Cependant, les lettres écrites avec le robot sont très grandes car les servomoteurs ne sont pas assez précis donc on ne peut pas écrire des lettres de la taille de lettres manuscrites. Pour améliorer notre robot il faudrait donc utiliser des servomoteurs plus précis.
Code Arduino
#include <Servo.h>
#include <string.h>
Servo myservo1; //servo de gauche
Servo myservo2; //servo de droite
Servo myservo3; //servo qui soulève le crayon
#include <SoftwareSerial.h>
double pi = 3.141592654;
int bluetoothTx = 0; // on branche le TX du bluetooth à la broche 0 de l’arduino
int bluetoothRx = 1; // on branche le RX du bluetooth à la broche 1 de l’arduino
double distance = 9;
double angle_depart1 = 180;
double angle_depart2 = 90;
double l1 = 10;
double l2 = 12.5;
SoftwareSerial bluetooth(bluetoothTx, bluetoothRx);
#define CW 0
#define CCW 1
#define MOTOR_A 0
// constantes utilisées par Ardumoto : ne pas les changer!
const byte PWMA = 3; // la broche 3 est utilisée pour la puissance du moteur du train d’imprimante
const byte DIRA = 12; // la broche 12 est utilisée pour la direction
void setup() {
Serial.begin(9600); // Begin the serial monitor at 9600bps
//Setup bluetooth
delay(100); // Short delay, wait for the Mate to send back CMD
bluetooth.begin(9600); // Start bluetooth serial at 9600
//Setup servo
myservo1.attach(5); // attaches the servo on pin 9 to the servo object
myservo2.attach(9);
myservo3.attach(2);
Serial.println(« initialisation »);
myservo1.write(0);
myservo2.write(0);
myservo3.write(0);
//Setup Ardumoto
setupArdumoto();
stopArdumoto();
}
void loop()
{
if (bluetooth.available()) // A la réception d’un caractère
{
char text = (char)bluetooth.read();
Serial.print(« text = « );Serial.println(text);
bluetooth.print(text);
myservo3.write(20);
ecrire(text);
myservo3.write(20);
myservo1.write(0);
myservo2.write(0);
driveArdumoto(CCW, 150); // On translate le moteur
delay(100); // pendant 100 ms
stopArdumoto(); // et on le stoppe
}
}
void ecrire(char lettre)
{
if (lettre == ‘a’){
aller_en(-5.5,7);
myservo3.write(0);
aller_en(0,15.5);
aller_en(5.5,7);
aller_en(2.5,11.5);
aller_en(-2.5,11.5);
}
if (lettre == ‘b’){
aller_en(5,7);
myservo3.write(0);
aller_en(5,17);
aller_en(-5,17);
aller_en(-5,12);
aller_en(5,12);
aller_en(-5,12);
aller_en(-5,7);
}
if (lettre == ‘c’){
aller_en(-5,7);
myservo3.write(0);
aller_en(5,7);
aller_en(5,17);
aller_en(-5,17);
}
if (lettre == ‘d’){
aller_en(5,7);
myservo3.write(0);
aller_en(5,17);
aller_en(-5,17);
aller_en(-5,7);
}
if (lettre == ‘e’) {
aller_en(-5,7);
myservo3.write(0);
aller_en(5,7);
aller_en(5,17);
aller_en(-5,17);
myservo3.write(20);
aller_en(5,12);
myservo3.write(0);
aller_en(-5,12);
}
if (lettre == ‘f’) {
aller_en(5,7);
myservo3.write(0);
aller_en(5,17);
aller_en(-5,17);
myservo3.write(20);
aller_en(5,12);
myservo3.write(0);
aller_en(-5,12);
}
if (lettre == ‘g’) {
aller_en(-5,17);
myservo3.write(0);
aller_en(5,17);
aller_en(5,7);
aller_en(-5,7);
aller_en(-5,12);
aller_en(0,12);
}
if (lettre == ‘h’) {
aller_en(-5,7);
myservo3.write(0);
aller_en(-5,17);
myservo3.write(20);
aller_en(-5,12);
myservo3.write(0);
aller_en(5,12);
myservo3.write(20);
aller_en(5,7);
myservo3.write(0);
}
if (lettre == ‘i’) {
aller_en(0,7);
myservo3.write(0);
aller_en(0,17);
}
if (lettre == ‘j’) {
aller_en(-5,7);
myservo3.write(0);
aller_en(0,7);
aller_en(0,17);
}
if (lettre == ‘k’) {
aller_en(5,7);
myservo3.write(0);
aller_en(5,17);
myservo3.write(20);
aller_en(5,12);
myservo3.write(0);
aller_en(-5,17);
myservo3.write(20);
aller_en(5,12);
myservo3.write(0);
aller_en(-5,7);
}
if (lettre == ‘l’) {
aller_en(-5,7);
myservo3.write(0);
aller_en(5,7);
aller_en(5,17);
}
if (lettre == ‘m’) {
aller_en(-5,7);
myservo3.write(0);
aller_en(-5,17);
aller_en(0,12);
aller_en(5,17);
aller_en(5,7);
}
if (lettre == ‘n’) {
aller_en(5,7);
myservo3.write(0);
aller_en(5,17);
aller_en(-5,7);
aller_en(-5,17);
}
if (lettre == ‘o’) {
aller_en(5,7);
myservo3.write(0);
aller_en(5,17);
aller_en(-5,17);
aller_en(-5,7);
}
if (lettre == ‘p’) {
aller_en(5,7);
myservo3.write(0);
aller_en(5,17);
aller_en(-5,17);
aller_en(-5,12);
aller_en(5,12);
}
if (lettre == ‘q’) {
aller_en(5,7);
myservo3.write(0);
aller_en(5,17);
aller_en(-5,17);
aller_en(-5,7);
myservo3.write(20);
aller_en(0,12);
myservo3.write(0);
aller_en(-10,2);
}
if (lettre == ‘r’) {
aller_en(5,7);
myservo3.write(0);
aller_en(5,17);
aller_en(-5,17);
aller_en(-5,12);
aller_en(5,12);
aller_en(5,7);
}
if (lettre == ‘s’) {
aller_en(5,7);
myservo3.write(0);
aller_en(-5,7);
aller_en(-5,12);
aller_en(5,12);
aller_en(5,17);
aller_en(-5,17);
}
if (lettre == ‘t’) {
aller_en(0,7);
myservo3.write(0);
aller_en(0,17);
myservo3.write(20);
aller_en(5,17);
myservo3.write(0);
aller_en(-5,17);
}
if (lettre == ‘u’) {
aller_en(5,17);
myservo3.write(0);
aller_en(5,7);
aller_en(-5,7);
aller_en(-5,17);
}
if (lettre == ‘v’) {
aller_en(5,17);
myservo3.write(0);
aller_en(0,7);
aller_en(-5,17);
}
if (lettre == ‘w’) {
aller_en(5,17);
myservo3.write(0);
aller_en(2.5,7);
aller_en(0,12);
aller_en(-2.5,7);
aller_en(-5,17);
}
if (lettre == ‘x’) {
aller_en(-5,7);
myservo3.write(0);
aller_en(5,17);
myservo3.write(20);
aller_en(-5,17);
myservo3.write(0);
aller_en(5,7);
}
if (lettre == ‘y’) {
aller_en(0,7);
myservo3.write(0);
aller_en(0,12);
aller_en(-5,17);
myservo3.write(20);
aller_en(0,12);
myservo3.write(0);
aller_en(5,17);
}
if (lettre == ‘z’) {
aller_en(-5,7);
myservo3.write(0);
aller_en(5,7);
aller_en(-5,17);
aller_en(5,17);
}
if (lettre == ‘0’) {
aller_en(5,7);
myservo3.write(0);
aller_en(5,17);
aller_en(-5,17);
aller_en(-5,7);
}
if (lettre == ‘1’) {
aller_en(0,7);
myservo3.write(0);
aller_en(0,17);
aller_en(-5,12);
}
if (lettre == ‘2’) {
aller_en(-5,7);
myservo3.write(0);
aller_en(5,7);
aller_en(-5,12);
aller_en(-5,17);
aller_en(5,17);
aller_en(5,12);
}
if (lettre == ‘3’) {
aller_en(5,7);
myservo3.write(0);
aller_en(-5,7);
aller_en(-5,12);
aller_en(5,12);
myservo3.write(20);
aller_en(-5,12);
myservo3.write(0);
aller_en(-5,17);
aller_en(5,17);
}
if (lettre == ‘4’) {
aller_en(0,7);
myservo3.write(0);
aller_en(0,17);
aller_en(5,12);
aller_en(-5,12);
}
if (lettre == ‘5’) {
aller_en(5,12);
myservo3.write(0);
aller_en(5,7);
aller_en(-5,7);
aller_en(-5,12);
aller_en(5,17);
aller_en(-5,17);
}
if (lettre == ‘6’) {
aller_en(-5,17);
myservo3.write(0);
aller_en(5,17);
aller_en(5,7);
aller_en(-5,7);
aller_en(-5,12);
aller_en(5,12);
}
if (lettre == ‘7’) {
aller_en(5,7);
myservo3.write(0);
aller_en(-5,17);
aller_en(5,17);
}
if (lettre == ‘8’) {
aller_en(-5,7);
myservo3.write(0);
aller_en(5,7);
aller_en(5,12);
aller_en(-5,12);
aller_en(-5,17);
aller_en(5,17);
aller_en(5,12);
aller_en(-5,12);
aller_en(-5,7);
}
if (lettre == ‘9’) {
aller_en(5,7);
myservo3.write(0);
aller_en(-5,7);
aller_en(-5,17);
aller_en(5,17);
aller_en(5,12);
aller_en(-5,12);
}
else{
Serial.println(« mauvais caractère »);
bluetooth.print(« mauvais caractère »);
}
}
double angle1(double alpha){
double resultat = angle_depart1 – alpha;
return resultat;
}
double angle2(double alpha){
double resultat = angle_depart2 – alpha;
return resultat;
}
void aller_en(double x,double y){
double gamma1 = (atan2(y,x+distance/2))*(180/pi);
double c1 = sqrt(y*y + (x+distance/2)*(x+distance/2));
double truc = (l1*l1 + c1*c1 – l2*l2)/(2*l1*c1);
double beta1 = (180/pi)*acos(truc);
double alpha1 = beta1 + gamma1;
double gamma2 = (atan2(y,x-distance/2))*(180/pi);
double c2 = sqrt(y*y + (x-distance/2)*(x-distance/2));
double beta2 = (acos((l1*l1 + c2*c2 – l2*l2)/(2*l1*c2)))*(180/pi);
double alpha2 = gamma2 – beta2;
Serial.print(« le servo de gauche va a « );Serial.print(alpha1);Serial.println( » degrés »);
myservo1.write(angle1(alpha1));
Serial.print(« le servo de droite va a « );Serial.print(alpha2);Serial.println( » degrés »);
myservo2.write(angle2(alpha2));
delay(1000);
}
// driveArdumoto drives ‘motor’ in ‘dir’ direction at ‘spd’ speed
void driveArdumoto(byte dir, byte spd)
{
digitalWrite(DIRA, dir);
analogWrite(PWMA, spd);
}
// stopArdumoto makes a motor stop
void stopArdumoto()
{
driveArdumoto(0, 0);
}
// setupArdumoto initialize all pins
void setupArdumoto()
{
// All pins should be setup as outputs:
pinMode(PWMA, OUTPUT);
pinMode(DIRA, OUTPUT);
// Initialize all pins as low:
digitalWrite(PWMA, LOW);
digitalWrite(DIRA, LOW);
}
Projet développement :Braille pour grimpeur
BEDETTI Corto
BLANCHARD Elisa
MASSOT Guillemette
Le but de notre projet développement est de faciliter la pratique de l’escalade pour les personnes déficientes visuelles. Afin de leur permettre d’avoir une première appréhension des prises pour une voie donnée, nous avons réalisé une maquette 3D représentant leur position et leurs formes.
Dans un premier temps, nous nous sommes intéressés aux moyens à mettre en œuvre pour acquérir les données sur les prises, c’est-à-dire leur position, leur couleur ainsi que leur forme. Nous avons réalisé des traitements sur l’image 2D grâce à un programme Python, afin de ne garder que les prises d’une même couleur.
-
- Mur d’escalade de Télécom Bretagne
-
- Image obtenue après traitement de la voir bleue
Pour que ce traitement soit plus précis, en évitant par exemple les erreurs dues aux traces laissées par d’anciennes prises ; nous avons rajouté une correction manuelle, pour ajouter ou supprimer des prises. Nous avons ainsi obtenu une image contenant uniquement les prises d’une même couleur, c’est-à-dire les prises formant une voie d’escalade.
Image obtenue après traitement de la voir bleue
Suppression manuelle d’une prise parasite
La voie ainsi reconstruite, nous avons converti l’image en un fichier compatible avec l’imprimante 3D, et avons distingué les prises du fond en faisant varier l’épaisseur d’impression.
Maquette 3D de la voie bleue
Enfin nous avons réalisé une interface permettant de reproduire automatiquement le même traitement en se basant sur une photo. Une fois la photo chargée dans l’interface, l’utilisateur sélectionne une prise. L’interface distingue ensuite automatiquement toutes les prises de cette couleur pour reconstituer la voie. L’interface est accompagnée d’une fiche d’explication donnant quelques conseils concernant l’acquisition des données, afin d’avoir un traitement optimal.
L’interface nous permet de récupérer les données RGB (triplet de couleur) d’un point sélectionné sur la prise. On définit ensuite un seuil de tolérance, ainsi on ne conserve que les pixels dont les données RGB appartiennent à l’intervalle [valeur initiale – seuil; valeur initiale + seuil]. On ajoute une bande sur l’image pour que les personnes déficientes visuelles puissent repérer le haut de la maquette.
L’interface manuelle permet d’ajouter ou de supprimer des prises. Le programme rajoute un carré respectivement de la couleur de la voie ou noir à l’endroit où l’on clique.
Lien pour les codes : https://github.com/GuillemetteMassot/Interface
Projet Ligne Bleue
Ce projet a été réalisé dans le cadre du projet développement, qui a eu lieu lors du second semestre.
Descriptif du projet :
En 1680, la ville de Brest a été fortifiée. Les remparts ont été entièrement démolis après-guerre, mais il est possible de deviner leurs formes en observant une carte de la ville. Gwenaëlle Magadur, artiste peintre plasticienne, propose donc à la ville de redessiner leurs formes et en juin 2000, une ligne bleue est tracée à même le sol. Notre projet consiste en la réalisation d’une application Android qui doit permettre à un utilisateur de visualiser du contenu visuel et textuel, une photographie et un poème par exemple. En lançant l’application, l’utilisateur se verra proposer une balade dans le vieux Brest.
Cadre de travail :
Nous avons choisi de travailler sur une carte de la ville de Brest sur laquelle nous avons modélisé la ligne bleue par un trait fin de la même couleur. En raison de l’intégration des services Google, nous avons décidé de travailler avec une carte GoogleMap. Afin de signaler la présence de contenu, des marqueurs interactifs ont été déposés le long de la ligne. Lorsque que l’utilisateur clique sur un marqueur, il sera redirigé vers le contenu correspondant.
Séquence d’utilisation :
Premièrement, l’utilisateur démarre l’application, il accède à la page d’accueil. Lorsqu’il clique sur Accéder à la carte, il arrive sur le layout de la 2ème figure, enfin il sélectionne un marqueur en cliquant dessus et accède au layout de la dernière activité, la SwipeActivity. Cette activité présente une photo statique en haut de l’écran et un texte scrollable en dessous : au glissement de doigt vertical, le texte défile sous l’image sans modifier celle-ci. Lors d’un glissement horizontal, les entités image et texte changent.
Stockage des données :
Nous stockons le contenu multimédia dans un serveur web et identifions les caractéristiques de ce contenu dans une base de données. Lorsque l’application Android souhaite accéder à un certain contenu multimédia, elle transfère donc au serveur web une clé. Cette clé est transmise à la base de données, qui identifie quelle image le serveur web doit envoyer au client Android.
Ce qui reste à améliorer :
Plusieurs évolutions restent envisageables. L’application pourrait guider l’utilisateur jusqu’à la ligne bleue, grâce à un itinéraire fourni par Google. Il serait également possible que les utilisateurs laissent leurs avis sur l’application ou déposent du contenu eux-mêmes, éventuellement validé par l’artiste avant d’être mis à la disposition de tous. Enfin, il pourrait être intéressant de créer une interface d’ajout de contenu pour l’artiste, afin de faciliter l’entrée de données qui se fait actuellement directement dans la base de données.
