Etat de l’art – projet Blind Climbers

Envoyé par Clément Rubin le 23 Mar 2020 dans Blog, TAF CoOC | 0 commentaire

L’art s’invite au Fablab

Envoyé par g17leroy le 9 Mar 2020 dans Portfolio, Projets, À la une | 0 commentaire

Grâce à la découpeuse LASER du Fablab, j’ai pu réalisé cette superposition de couches, inspirées d’une oeuvre d’art existante. Le modèle d’ours se compose de 6 couches pour donner cette impression de  profondeur.

Les dessins ont été fait sur Corel Draw, couches après couches.

Merci à Mathilde pour son aide.

Trophées de l’Atlanticup 2019

Envoyé par Julien Lantrin le 19 Fév 2020 dans Portfolio, Projets, À la une | 0 commentaire

Le fablab a permis au Bureau des Sports de réaliser les trophées de la première édition de l’Atlanticup.

Nous avons réalisé grâce à la découpeuse laser des trophées en forme du pays de Brest et gravés des sponsors ainsi que le nom de l’évènement.

Les dessins ont été fait sur Corel Draw.

Merci à Cédric Mancec pour le design des trophées en forme « Pays de Brest »

Ukulélé Custom

Envoyé par mmenoret le 17 Fév 2020 dans Portfolio, Projets | 0 commentaire

Petit projet perso…

Ayant reçu un ukulélé à construire pour Noël, nous avons décidé de le customiser, et quoi de mieux que la découpe laser pour faire quelque chose de joli quand on est pas très créatif soi-même!

Étant fans de Calvin et Hobbes, nous avons trouvé des dessins déjà vectorisés sur thingiverse disponibles ICI

Il suffit de les recadrer en fonction des dimensions du corps du ukulél, et c’est parti!

Un petit tour à la découpe laser (Paramètres de gravure: 100% Vitesse, 80% puissance, 500 dpi) et voilà le résultat!

Et une fois le yukulélé vernis et monté:

Plus qu’à apprendre à en jouer!

Robot Pepper – Hackathon ENSIBS 2020

Envoyé par a18allem le 7 Fév 2020 dans Portfolio, Projets, À la une | 0 commentaire

 Contexte

Dans le cadre de notre intersemestre nous avons participé au hackathon 2020 de l’ENSIBS (Ecole Nationale Supérieure d’Ingénieurs de Bretagne-Sud). Ce hackathon a été organisé en collaboration avec la chaire Maintien@Domicile, commune à l’ENSIBS et IMT Atlantique en partenariat avec le centre de rééducation Kerpape. Durant cet évènement (se déroulant sur 2 jours et demis) nous devions travailler sur un projet concret et utile autour d’un challenge handicap et numérique, en formant des équipes mixtes avec des étudiants de l’ENSIBS en mécatronique..

Présentation du projet

Nous avons choisi de travailler sur un projet d’amélioration des fonctionnalités du robot Pepper. 

Pour contextualiser, Pepper est un robot français qui sert principalement à l’assistance et la présentation. Il a été utilisé dans des travaux de développement de comportement sociaux avec des enfants autistes mais aussi dans des scénarios de levée de suspicion d’état anormal (chute, malaise, oubli de soi, etc.).

Ce robot est très facilement programmable grâce à un logiciel de développement appelé “Choregraphe”.  Le logiciel est prévu avec une interface graphique permettant de faire des blocs de programmation et des liaisons entre blocs. Il suffit de glisser-déposer des blocs de fonctionnalités fournis et de les relier entre eux afin de définir un scénario d’utilisation. Si jamais nous cherchons à utiliser une fonctionnalité qui n’est pas déjà disponible, on peut facilement coder son propre bloc en python.

Capture d’écran du logiciel Choregraphe

Présentation de l’équipe

• Étudiants mécatronique de l’ENSIBS : Maxime Dubois, Alexis Eveno, Chloé Humbert, Salomé Leguede, Erwan Le Texier
• Étudiants IMT Atlantique : Théo Fontenit, Arnaud Allemang–Trivalle

Objectifs du projet

Une liste d’objectifs à réaliser nous a été fournis lorsque nous avons commencé le projet. A cause du manque de temps et de soucis techniques, nous n’avons pas pu réaliser tous ces objectifs bien qu’une majorité de ceux-ci ont été atteints.

• Programmer et reprendre en main les programmes de visites Chaire et portes ouvertes ENSIBS
• Programmer le robot afin de redémarrer de façon autonome avec un programme prédéfini
• Ajouter la fonctionnalité de déplacement du robot
• Ajouter la fonctionnalité de mise en relation en visio avec l’extérieur
• Piloter des fonctionnalités par la voix

Scénarios

A partir des différents objectifs nous avons imaginé 2 scénarios d’utilisation à ajouter aux fonctionnalités déjà présentes sur le robot. En effet, ces scénarios servent à permettre une utilisation concrète et réfléchie des différentes fonctionnalités que nous souhaitions développer. 

• Lors des dernières portes ouvertes de l’ENSIBS, Pepper était capable de présenter l’école, la chaire Maintien@Domicile et d’échanger avec les visiteurs sur certains sujets. Le premier scénario consiste à compléter cette visite en permettant au robot de suivre automatiquement son interlocuteur.
• Le second scénario est un scénario d’aide à la personne. L’idée est que Pepper vienne au secours d’une personne lorsqu’elle appelle à l’aide, et qu’il puisse appeler automatiquement les secours. L’appel en question peut être soit un appel téléphonique, un SMS ou une visioconférence. Dans le dernier cas, les secours peuvent déterminer la gravité de la situation et agir en conséquence.

Déroulement du Hackathon

Pour travailler sur ce projet nous avons décidé de diviser notre groupe en 2 sous-groupes, un par scénario. 3 étudiants ont principalement travaillé sur le premier scénario et sur les livrables tandis que le second groupe composé des 4 personnes restantes s’est concentré sur le second scénario.

• Premier Scénario

Comme décrit précédemment, le premier scénario consiste à suivre une personne tout en présentant l’école. Pour commencer, nous sommes partis sur un assemblage bloc tracker, temporisation et fonction move to pour que le robot suive une personne. En réalité, après avoir fait beaucoup d’essais, nous avons découvert qu’il y avait une solution beaucoup plus simple.

En effet, il est possible de programmer le robot avec le bloc de programmation people tracker, qui réalise le repérage des personnes en plus du guidage. Ce bloc est composé de trois modes : face, whole body et move. Pour le premier cas, la tête du robot suit le visage de la personne. Dans le 2ème cas, elle suit le corps d’une personne. Enfin, dans le dernier mode, Pepper va suivre la personne.

Afin d’éviter que Pepper ne percute un obstacle ou une personne lors de son déplacement, nous avons utilisé le bloc Set External Anti-Collision qui permet d’arrêter le robot dès qu’il détecte un obstacle.

Un problème est survenu lors de la détection de la personne à suivre. Dans le cas où, une autre personne passe devant la personne suivie par Pepper, celle-ci se met à suivre la deuxième personne. Pour résoudre ce problème, nous avons ajouté la mémorisation des visages. Cela permet au robot de ne suivre que la personne enregistré au départ de la visite. 

Enfin, nous avons amélioré le suivi de personne en implémentant des mots clés qui permettent de lancer le déplacement du robot: Suis-moi, suivre etc.

• Deuxième Scénario 

Le deuxième scénario est un peu plus complexe. Il consiste à porter secours à une personne en danger. 

Des solutions non abouties

Le sous objectif principal du scénario d’aide à la personne en danger, est notamment de passer un appel en visioconférence. 

Une des solutions trouvées a été de pouvoir créer un serveur web de conférence. Cette solution induit de créer un serveur sur « ngrok ». Cette solution n’a pas abouti car nous avions trouvé le moyen de générer une page web sur Pepper via Choregraphe (cf programme Python ci-dessous). Cela permet de télécharger des applications du site d’Aldebaran Robotics mais il n’est pas possible de télécharger des applications type « google duo » pour réaliser des visioconférences à cause d’un problème de droits. 

Développer une application pour l’appel visio en suivant des instructions sur Microsoft Azure est une autre solution. Il est alors possible de créer une machine virtuelle et de la configurer pour la visio, mais au vu de la complexité, cette solution n’a pas été développée. 

Nous avons décidé de dissocier l’appel téléphonique et la visio. Pour le second cas, il est possible d’utiliser le réseau « WebRTC » avec Pepper en tant que module technique. Cependant, nous n’avons pas poursuivi cette solution et nous nous sommes concentré sur l’appel.

Code python pour ouvrir une page web sur la tablette du robot Pepper

Schémas de contexte du réseau

 

 

 La solution aboutie : démarche et explications

Le robot autorise l’enregistrement de mots prédéfini. Lorsque le robot détecte un de ces mots enregistrés, il déclenche la réponse associée. Suite à un appel de la personne en difficulté (via “à l’aide”, “au secours” ou encore “sos”) le robot va repérer l’origine du son et se diriger vers la source du bruit. Une fois arrivé à destination, le robot va demander si tout va bien, et en fonction de la réponse, peut appeler les secours . Le repérage de l’origine du son est difficile surtout dans des milieux bruyants et restreints. 

Une des solutions trouvées a été de créer un numéro de téléphone virtuel via un ordinateur. Sur ce compte virtuel twilio, un compte « SID » est créé. Via cette plateforme web, on peut envoyer un sms à un téléphone. On a ensuite pris une base de code python, que l’on a adapté pour l’IDE de l’éditeur de code. Sur ce code, notre identifiant SID est modifié ainsi que le numéro de téléphone virtuel. Ces informations permettent de communiquer entre un téléphone et le robot.

Ensuite, le code Python est intégré au logiciel Choregraphe pour ne plus avoir à passer par un ordinateur pour la communication entre le robot et le téléphone. Un début de solution à été de générer un script python et un bloc « get attached ». Le bloc « get attached » permet d’intégrer des libraires python au logiciel choregraphe. Le script python fait le lien entre le robot et le téléphone. Cette solution n’a pas fonctionné, car le logiciel choregraphe ne parvient pas à trouver la librairie importée.

Une autre solution est de charger la librairie au travers du script. Cependant, il y a un problème de format. Le logiciel choregraphe ne supporte que les fichiers « .dll », et pas les « .py ». A moins de trouver un moyen de convertir le format, cette solution reste inutilisable.

Une autre solution serait d’installer la librairie directement sur Pepper. Installer cette librairie revient à créer un comportement supplémentaire. Cependant, lors de l’exécution, il manquait une librairie PYTZ. Cette librairie est récupérable grâce au logiciel « Putty », qui l’installe sur le robot. Après avoir ré-exécuter le comportement, il manquait une autre librairie qui est maintenant installée. La découverte d’un tutoriel en japonais sur l’utilisation de Twilio nous a permis de finaliser la réalisation de l’appel via le robot Pepper.

Un problème que nous avons rencontré au niveau du suivi d’une personne est que le robot peut répondre de manière étrange. Cela est dû à une saturation de mémoire du robot lors d’un chargement de programme. Cette situation peut arriver notamment lors de chargement de programme avec reconnaissance vocale. Pour résoudre ce problème, il faut éteindre complètement le robot et le faire redémarrer.

• Pistes d’amélioration

Un objectif supplémentaire serait de faire en sorte de pouvoir changer de mode de fonctionnement sans avoir à utiliser un ordinateur. Pour faire ça, le plus simple est de réunir l’intégralité des programmes utilisés en un seul, avec pour condition d’activation la reconnaissance d’un mot clé. A l’heure actuelle, cette fonction n’a pas encore été réalisée.

Une piste de modification du programme s’est présentée lors d’une présentation à une promotion d’élèves de l’ENSIBS. En effet, le robot avait pour objectif de suivre un des élèves. La modification est sur la distance d’arrêt entre le robot et la personne ciblée. La proximité entre le robot et la personne peut être gênante, au point de faire peur. Nous avons ici découvert l’importance de réfléchir à la perception du robot par les utilisateurs.

Une autre piste de modification est sur la vitesse de déplacement. Lorsque le robot suit une personne, il faut que la personne marche lentement pour ne pas sortir de la zone de détection. Il est possible que le problème soit d’ordre logiciel, le robot doit recalculer à chaque instant si la personne est situé devant lui, ce qui peut demander des ressources assez importantes.

Démonstrations

Scénario global

Scénario 1 : Fonction de suivi automatique

Bonus 1 : Spectacle d’animations prédéfinies du robot Pepper

Bonus 2 : Reconnaissance automatique de sexe et d’âge

Retours d’expérience

• Théo Fontenit

J’abordais cet intersemestre sans vraiment savoir ce que j’allais réaliser puisque je n’avais jamais réalisé de hackathon et que nous étions les premiers de l’IMT à réaliser celui ci avec l’ENSIBS. Nous sommes arrivé jeudi matin sur les lieux du Hackathon. Après une rapide visite des lieux, nous nous sommes tout de suite mis dans le bain puisque nous avons eu la présentation des sujets et le choix des sujets dès 10h30. Le début de journée était un peu hésitant: je ne connaissais ni les personnes de mon groupe ni l’objet d’étude de notre week end: le robot Pepper. Cependant au fil de la journée, nous avons appris à nous connaître et à apprivoiser le robot. Nous avons découvert l’immense palette de comportements que le robot Pepper pouvait réaliser, avec un peu d’imagination nous pouvions créé un tas de scénarios différents !

Au cours du week end, diverses difficultés nous ont fait face. Par exemple, lorsque j’ai voulu mettre en place le suivi du robot par le son, je me suis rendu compte que la fonction SoundTracker préconfiguré dans le logiciel Chronographe était approximative du fait que les 4 microphones du robot possédaient une zone morte derrière ce dernier et que les échos des sons ne permettaient pas une localisation précise. J’ai donc reprogrammé les blocs en langage Python. Il fallait donc être capable de comprendre les programmes déjà créés en programmation orientée objet et de les modifier afin d’obtenir la fonction désirée. Cela s’est traduit par la création de nouvelles fonctions python et de nouvelles entrées dans les blocks Python du logiciel Chorégraphe.

Le hackathon s’est révélé être un expérience très positive. J’ai eu l’occasion de rencontrer de nombreuses personnes passionnés par des thématiques qui me tiennent à coeur. En effet, les étudiants en mécatronique m’ont permit de découvrir le domaine de la robotique. J’ai toujours été attiré par ce domaine cependant je n’avais jamais eu l’occasion de réaliser des applications concrètes de ce type. La possibilité de programmer le robot Pepper m’a permis d’apprendre de nombreuses compétences tel que la capacité à réaliser la stratégie de commande adaptée à un robot humanoïde, la réflexion sur la perception du robot par l’humain et leurs interactions, ou encore la prise en compte de l’environnement par un robot et ses capteurs. De plus, l’application que nous avons développé sur Pepper possède une vraie utilité et pourrait être améliorée afin d’être réellement mis en place dans la maison de personnes âgées afin de détecter leur chute et afin de leur apporter une aide. Enfin, les profs de l’ENSIBS et les ingénieurs de la chaire Maintien à domicile ont été très disponible et m’ont permit de découvrir la robotique tout en prenant plaisir dans un format qui tranche avec les cours habituels.

• Arnaud Allemang–Trivalle

J’ai déjà eu l’occasion de participer à différents Hackathon et j’étais donc familier au concept et au déroulement général de l’intersemestre. Cependant à la différences de mes autres expériences, cette fois je n’avais aucune compétence directement liée au thème du hackathon et à la robotique. Ainsi au final j’appréhendais un peu cet intersemestre car j’avais peur de ne rien comprendre aux différents projets, de brider mon imagination par manque de connaissance et d’être un poids pour mon équipe.

Finalement, lors de la présentation des différents projets j’ai pu identifier celui autour du robot pepper. Il a su attirer mon attention et ne demandait que des connaissances basiques en programmation. Une fois mon projet choisi j’ai pu rencontrer les autres étudiants intéressés par celui-ci, échanger avec eux et former une équipe. Le contact c’est fait assez facilement et rapidement et nous nous sommes directement mis dans le bain. La première journée nous avons pris en main le robot, exploré l’étendu de ses fonctionnalités et commencé à programmer. Nous avons rapidement réalisé que nous pouvions programmer facilement ce robot afin de mettre en place de nombreux scénarios.

Cependant, la programmation par bloc, qui semblait très simple au premier abord, s’est montré par moment très capricieuse. En effet, il est parfois compliqué de comprendre toutes les subtilités d’un bloc déjà programmé car nous n’avons pas accès au code python qui est concrètement utilisé. Ainsi la démarche est devenue assez expérimentale, et nous avons dû tester chaque paramètre des blocs afin d’identifier quelles étaient leur réelle utilité.

Par exemple pour la fonctionnalité de suivi automatique de l’utilisateur, nous avons passez beaucoup de temps à tester différents blocs pythons et différentes configurations avant de réaliser que ça pouvait être faire en utilisant qu’un seul bloc avec les bons paramètres.

Au final le hackathon s’est révélé être une expérience très enrichissante. Cela m’a permis de prendre en main des technologies que l’on ne rencontre pas tous les jours, et d’échanger avec des étudiants spécialisés dans le domaine de la robotique. Découvrir le robot Pepper m’a fait prendre conscience de toute les possibilités offertes par les robots sociaux. En effet possédant de nombreux capteurs il devient possible de réaliser toutes sortes de scénarios. L’imagination et les capacités des développeurs semblent n’être presque que les seuls limites au développement de nouvelles solutions.

Je tiens à remercier tout particulièrement les professeurs de l’ENSIBS et les ingénieurs de la chaire Maintien@Domicile qui ont été très disponibles et d’un grand soutien pour la réalisation de notre projet. Merci également à toutes les personnes qui ont rendu ce hackathon et cet intersemestre possible. J’espère que l’an prochain d’avantages d’élèves d’IMT Atlantique auront l’opportunité d’y participer.

Ressources

Pour accéder à toutes les ressources (codes, vidéos, photos, manuel d’utilisation) issues de ce Hackathon il suffit de cliquer ici.

Le meuble mobile

Envoyé par w19gong le 3 Fév 2020 dans Portfolio, Projets, À la une | 0 commentaire

** Ce projet a été fait dans le cadre du Hackathon de l’ENSIBS qui s’est déroulé du 30 janvier au 1er février à Lorient. Des étudiants d’IMT Atlantique ont participé dans le cadre de la semaine d’intersemestre **

Introduction

Ce projet a pour objectif d’améliorer un ancien projet traitant d’un meuble mobile destinées aux personnes âgées et à mobilité réduite. Ce dernier a été réalisé par d’autres élèves dans le cadre d’un stage de deuxième année. Notre objectif principal est d’améliorer la structure mécanique du meuble mobile et enfin de vérifier la partie programmation.

Prise en main du projet

Le principal problème mécanique à résoudre était la fixation des roues mecanum : la fixation des axes était réalisée jusqu’à présent par deux liaisons pivot de chez Igus, auto-lubrifiante. Le système, hyperstatique donc, était difficile à monter et engendrait trop d’effort, si bien que les courroies sautaient des roues des moteurs.

Une conception antérieure au Hackathon avait donc mené à choisir deux liaisons linéaires annulaires de chez Igus, de nouveau.

Le projet a tout d’abord été traité de manière séquentielle en s’intéressant en premier lieu aux améliorations à apporter à une seule roue, afin de vérifier le modèle conçue en amont, puis aux roues restante. En second lieu, nous avons apportés les modifications appropriées aux supports de chaque moteur pour les 4 roues. Enfin, nous avons vérifié le bon fonctionnement du meuble en testant quelques fonctions de déplacements.

Montage préliminaire d’une roue

Voici en substance toutes les manipulations réalisées, afin de vérifier que le nouveau système conçu est viable :

• Fixation des nouveaux paliers (liaisons linéaires annulaires) sur les équerres supports d’une roue : perçage à 4,2 mm (pour les vis)
• Remplacement des roulements à brides par un roulement de type linéaire-annulaire.
• Mauvaise fixation des moyeux des roues constatée : les vis n’étaient visées dans rien du tout => 3 tiges filetées de M4 * 75 mm avec rondelles et écrous à frein ont été ajoutées au modèle.
• Agrandissement de l’ouverture dans le châssis pour le passage de la courroie à la scie-sauteuse
• Re-perçage de la base pour fixer la grande équerre support de la roue :

    – marquage en plaçant l’ensemble équerres-roue à la bonne place (approximativement)

    – pointage et perçage à 5mm.

Même s’il restait encore quelques adaptations à faire, le montage avec les rotules a alors été validé par la chaire, et nous avons pu procéder à la réalisation des autres montages.

Montage des 4 roues

Pendant qu’un de nos membres s’occupait de l’usinage des trois autres axes pour les roues, d’autres se sont occupés de la préparation des supports.

Un problème majeur a alors été détecté : les courroies étaient en diagonale, les nouveaux paliers étant plus épais que les précédents. Nous avons donc décidé d’inverser les engrenages sur les axes moteurs, et d’adapter en épaisseur des cales entre les petites équerres des roues et le palier.

De plus, les supports-moteur restaient problématiques : d’une part, un boulon de fixation de l’équerre sur le châssis poussait directement sur le moteur, ce qui décentrait celui-ci, et détendait la courroie. D’autre part, l’écrou à sertir de réception de ce boulon, était situé au milieu de la plaque-support, et non sur un bord, déséquilibrant ainsi la plaque. Nous avons donc ajouté deux autres écrou à sertir supplémentaires, montant ainsi leur nombre à quatre, et situés aux quatres coins de la plaque. Les fentes sur le chassi pour l’adaptation de hauteur des moteurs ont été allongées en conséquence.

Enfin, pour pallier la mauvaise fixation des moteurs sur ces fentes, ce qui posait problème vis-à-vis de la tensions des courroies, l’adjonction de trois rondelles à chaque écrou (dont une à dentures extérieures) s’est révélée suffisante. À noter, aussi, le positionnement de la clavette pour les roues mecanum sur leurs axes, qui reste difficile et qui nous a posé problème.

 

Nous avons alors pu monter séparément les quatres roues avec leurs moteurs, en les alignant deux à deux, à vue (avec une règle), et effectuer les corrections d’alignement, pièce à pièce, car aucun montage n’était identique à un autre : il fallait adapter le modèle à la réalité. Toutes les vis de pression ont également été resserrées avec soin, afin d’éliminer au maximum tous les jeux de mouvement sur les engrenages.

Le résultat “statique” était déjà concluant, puisque désormais les roues tournées à la main entraînent les moteurs pourtant à fort couple, sans que les courroies ne sautent. Mais nous avons pu procéder à des tests dynamiques.

 

Vérifications et modifications apportées

 

Après branchement de la carte de puissance réalisée lors d’un projet précédent, et connexion d’un IDE Arduino à la celle-ci, le premier essai à vide n’a pas été concluant :

• le déplacement avant/arrière était bon,
• la translation gauche/droite n’était pas excellente,
• la rotation du plateau sur lui-même ne fonctionnait pas du tout, les roues essayant de replier le châssis sur lui-même !

Après analyse, il s’est en fait révélé que les roues mecanum étaient montées à l’envers depuis le début de la construction de la base… Ainsi, au lieu de voir les roulettes du dessous des roues disposées en ‘X’, il fallait les avoir en ‘O’.

Conclusion

Majoritairement déroulé dans l’atelier de fabrication, ce projet nous a fait adapter le modèle de conception au réel : chaque pièce étant unique, cela rendait le travail à fournir et les problèmes à résoudre aussi intéressant que totalement différents d’une roue à une autre.

Pour des passionnés de mécanique et de fabrication, ce projet s’est donc révélé très motivant. De plus nous avons pu apprécier la bonne ambiance que l’évènement a installé au sein de l’école, ainsi que l’engagement des encadrants pour nous aider dans nos réalisations.

 

Ressources et liens

Code de test Arduino

Ce fichier peut être trouvé dans le dossier se trouvant à l’adresse suivante:

https://drive.google.com/open?id=1HCUQd-cEFMARB2H0DnM9QcvOWuwK77bm

 

 

 

TP VHDL du dept ELEC : les feux tricolores

Envoyé par JNB le 21 Jan 2020 dans Portfolio, Projets, À la une | 2 commentaires

Le TP VHDL¹ sur la gestion de feux tricolores méritait une mise à jour concernant le matériel, le passage à un FPGA² compatible avec Vivado³, donc au moins de la série 7. C’est chose faite, le nouveau FPGA est un Artix 7 de chez Xilinx, présent sur la carte Nexys 4 de chez Digilent.

Le passage à cette nouvelle carte implique de concevoir et réaliser une nouvelle maquette de feux tricolores. L’ancienne maquette était compatible avec la carte d’évaluation Spartan 3, avec un connecteurs 40 broches mappé sur des GPIO⁴ du FPGA. Sur la Nexys, les connecteurs sont de 12 broches. C’est le moment pour en profiter et utiliser les outils du Telefab pour améliorer l’esthétique de la chose.

Voici un aperçu de l’ancienne maquette :

C’est simple et efficace, fiable et robuste. Cependant ça pourrait être améliorer niveau design. C’est là que le Telefab intervient. Il est facilement possible d’utiliser la découpeuse laser (surtout quand on a les droits pour le faire soi-même…) qui permet d’avoir un rendu très propre. Le principe ici va être de faire une boite en MDF 3mm avec un assemblage à encoches. Tout d’abord j’utilise Inkscape (sur machine GNU/Linux en libre service) avec son génial plugin de génération de boîtes. Pour cela, il faut aller dans le menu «Extension/Plugin» et sélectionner «LaserCut». Ensuite il suffit de renseigner les dimensions, dans mon cas L=l=14cm, H=6cm, boite fermée, sans compartiment, épaisseur du matériaux : 3mm. Voila ce que ça donne :

Une fois le schéma généré et sauvegardé, je passe sous Corel pour le mettre en forme avant de le transférer à la découpeuse laser. Il faut passer les trait de découpe en «traits fin» et en couleur rouge pur (#FF0000). Puis reste à faire le dessin de la route et du chemin, et faire les feux tricolores et passer le tout à la découpe laser. Voici le résultat final :

Les évolutions seront :

• Amélioration du câblage, plus flexible, et connecteur mieux protégé. La gaine thermorétractable est très pratique, mais donne un résultat rigide.
• Facilitation du changement de LED en cas de besoin

Ce n’est pas parfait, mais c’est beaucoup plus joli !

 

MindPeace – Solution Technique

Envoyé par Sanaa Ghandi le 6 Jan 2020 dans À la une, TAF CoOC, Portfolio, Projets | 0 commentaire

Auteurs:  GHANDI Sanaa- LAFEUILLADE Timothée- Ilona MALLEIN-GERIN

 

Plan:

I-Contexte

II-Présentation de la solution technique de manière synthétique

III-Présentation de la solution de manière détaillée

IV-Lien vers le code

V-Protocole de communication

VI-Justification des choix techniques

VII-Perspectives

VIII-Sources

 

 

I-Contexte

 

Dans le cadre de notre projet TAF COOC, nous étions amenés à réaliser un objet permettant d’optimiser l’apprentissage des enfants atteints de troubles d’attention. Ces derniers sont souvent sujets à des crises de panique et ont une faible capacité de concentration, ce qui les freine dans leur éducation. Nous avons ainsi conçu un objet communicant qui a pour fonction de rassurer ces enfants et de raviver ponctuellement leur attention, lorsqu’ils doivent effectuer une tâche par exemple.

Nous avons réalisé un prototype de cet objet qui grâce à une LED et un écran LCD affiche des messages et diffuse des lumières douces. Nous avons aussi développé une application permettant aux parents de choisir les couleurs et les messages à afficher sur l’objet. Grâce à cela, l’objet est personnalisable pour chaque enfant.

 

II-Présentation de la solution technique de manière synthétique

 

1) L’objet

L’objet a la forme d’une boule. D’un côté, l’objet représente une tête d’ours. Du tissu doux est collé sur toute cette moitié de l’objet. De l’autre côté, la place est laissée pour l’écran qui peut afficher des messages. Le chapeau, fait d’un matériau translucide, s’illumine grâce à une LED Neopixel.

Fig1: Face arrière de l’objet: ours (à gauche),  Face devant de l’objet contenant l’écran (à droite)

 Fig2: La face avant de l’objet est personnalisable

 

 

2) L’application

Sur l’écran d’accueil, il faut d’abord se connecter en BlueTooth à l’objet. Le menu propose ensuite deux actions possibles : choisir les couleurs du chapeau et programmer un message.

Pour le chapeau, l’utilisateur choisit 3 couleurs qui vont défiler en continu sur l’objet. Il sélectionne les couleurs sur la roue des couleurs. Pour les messages, seuls les messages de 32 caractères sont compatibles avec l’écran. L’utilisateur rentre le message directement dans le champs de saisie et clique sur valider.

Fig3: L’application: fonctionnalité de changement de couleur

Fig4: Le chapeau s’illumine par les couleurs choisies

Fig5: Fonctionnalité d’envoi de message, affichage du message sur l’écran LCD

Voici une vidéo du fonctionnement (qui est pas mal! )

 

 

III-Présentation de la solution de manière détaillée

 

1)Diagramme d’architecture matérielle/logicielle

 

Fig6: Diagramme d’architecture matérielle et logicielle

 

Liste du matériel

– Une carte Arduino UNO Rev3

– Un afficheur LCD 2×16 I2C

– Une LED Neopixel Unique

– Un mini haut-parleur dynamique 2W

– Un module BlueTooth HC-05

– Des câbles

 

2)Matériel utilisé et montage électronique

 

a-Carte Arduino UNO [4]

Fig7: Carte Arduino Uno

 

b-Afficheur LCD 2×16 I2C [3]

 

Fig8: Afficheur LCD

ll se compose de deux parties: un écran LCD “classique” et au dos un module d’interface I2C.

La communication avec une carte Arduino se fait avec le protocole I2C (voir internet pour plus de détails) sur deux lignes dénommées SCL et SDA. Il faut ajouter les lignes d’alimentation Vcc et GND.

Pour le câblage:

on relie le VCC au 5V et le GND au GND de l’Arduino

le SDA sur A4

le SCL sur A5

Fig9: Cablâge du LCD

Bibliothèques installées: 

LiquidCrystal_I2C

Fonctions utilisées: 

  lcd.init();                      // initialise le lcd

  lcd.backlight();

  lcd.print(« Hello, MindPeace! »);  // Affiche le message sur le LCD.

 

c-LED Neopixel Unique

 

Fig10: Neopixel

 

Pour le câblage:

On relie le 5V au VCC

Le GND au GND 

Et le in au Pin  5

Fig11: Cablâge du Neopixel

 

Bibliothèques installées: 

Adafruit_NeoPixel

Fonctions utilisées: 

  Adafruit_NeoPixel strip = Adafruit_NeoPixel(24, PIN, NEO_GRB + NEO_KHZ800);

// Pour définir qu’on utilise bien l’ordre GRB et non pas RGB, et pour dire qu’on travaille à 800KHz

  strip.begin(); // initialisation des neopixels

  strip.show();  // applique l’effet sur le neopixel ici il va s’éteindre

  strip.setPixelColor(0, strip.Color(0, 0, 255)); // on choisit la couleur qu’on veut afficher ici le     bleu , c’est un code GRB ( green,red, blue)

  strip.show(); // ici le neopixel s’allume en bleu

 

 

d-Mini Haut Parleur dynamique 2W [2]

 

Fig12: Haut-parleur

Pour le câblage:

On relie un pin au VCC et l’autre au pin 8 de l’arduino.

Fig13: Cablâge du Haut-parleur

Fonctions utilisées: 

tone(8, 293, 112.5); 

Ce qui veut dire émettre le son de fréquence 293 Hz pendant 112.5 ms sur le pin 8 

Autres possibilités: 

Programmer des musiques comme en utilisant le format midi puis en le convertissant en un code arduino sous forme de suite de commande tone. [6]

Ou d’utiliser une carte SD qui contient déjà des sons sous format .wav [7]

 

e-Module Bluetooth HC-05 [1]

 

Fig14: Cablâge du module Bluetooth

Le comportement utilisé est « maître/esclave ». Un esclave pourra parler avec un seul maître, mais un maître pourra dialoguer avec plusieurs esclaves. Son utilisation, se passe en plusieurs étapes :

Le maître se met en mode « reconnaissable »

L’esclave trouve le maître et demande à s’y connecter

Le maître accepte la connexion

Les périphériques sont alors appairés (ou associés)

La communication peut commencer [5]

Remarque:

Quand vous appareillez votre module Bluetooth sur votre téléphone le code que vous devez entrer est souvent 1234 

Pour le câblage: [1]

On relie le GND au GND, le 5V au VCC

Et nous avions relié le RX au pin 11 et le TX au pin 12

Bibliothèques installées: 

SoftwareSerial

Fonctions utilisées: 

SoftwareSerial bt(11, 10); // (RX, TX) (pin Tx BT, pin Rx BT) ( nous avons choisi d’appeler notre module bluetooth bt )

Serial.begin(9600); // Sur les PCs du fablab il faut choisir 9600 Bauds afin que les messages que vous imprimer puissent s’afficher 

bt.begin(9600);  // démarrage du bluetooth à 9600 bauds

while(bt.available() > 0) // vérifie qu’il y’a encore des données à lire reçues par bluetooth

l_char = bt.read() // lis le caractère reçu et le stock dans la variable l_char

 

3)Schéma de l’application

 

Fig15: Schéma du fonctionnement de l’application

 

 

IV-Lien vers le code

 

Vous trouverez le code arduino, le code MIT sur Github par ici

https://github.com/Ghandisanaa/MindPeace

 

V-Protocole de communication

 

Nous avions choisi pour l’envoi de nos propres messages une communication unidirectionnelle de l’application vers arduino via bluetooth car nous n’avions pas estimé nécessaire l’envoi d’acquittements ou autres messages de confirmations par le programme implémenté sur l’Arduino.

Nous n’avons pas prévu de correction d’erreurs ni de numérotation de messages pour détecter si un paquet a été perdu.

En effet, l’existence d’une latence due au Bluetooth faisait que le système n’arrivait plus à bien déchiffrer les messages reçus s’il reçoit plusieurs requêtes de suite dans le cas où l’utilisateur manipule trop vite l’application. Ce qui fait qu’il serait peut être intéressant de mettre en place un système d’acquittement et de numérotation des messages envoyés.

Nous avons par contre opté pour une classification des messages par types ( Texte, changement de couleur 1 ou 2 ou 3) afin de faciliter le traitement de ces requêtes par la carte arduino, ce qui fait que pour l’envoi des rappels nous avions mis au début de chaque message une lettre “T” et pour l’envoi du changement de lumière nous avons mis pour la première couleur la lettre “I”, pour la deuxième “J” et “K” pour la dernière. 

Le codage était en utf_8

La taille des différents messages envoyés était limitée:  15 bits pour les couleurs car nous avions utilisé un code RGB,  et 34 bits pour les messages textes (ou rappels) car nous étions limités par la taille de l’écran LCD utilisé qui ne pouvait afficher que 32 caractères.

Afin de pouvoir délimiter les différentes parties de chaque message nous avons opté pour de point-virgules afin de faciliter l’ unpacking du message 

La nature des messages était également toujours  connu au préalable des int ou des char et donc on convertissait les informations extraites si cela est nécessaire.

 

VI-Justification des choix techniques

 

Bluetooth

Nous avons choisi Bluetooth comme technologie de communication car celle-ci est relativement facile d’accès et d’utilisation. En effet, nous avions à disposition des modules Bluetooth compatibles avec Arduino et notre langage de programmation disposait de fonctions prédéfinies permettant la communication via la technologie Bluetooth.

Cependant, cette technologie de communication a une très faible portée qui n’est pas adapté à l’utilisation finale de notre objet. Dans un futur développement de notre objet, il faudrait changer de protocole de communication. Pour notre premier prototype ici présenté, utiliser le Bluetooth suffisait amplement.

 

Arduino uno

Nous avons choisi comme microcontrôleur une carte Arduino UNO car sa programmation est relativement simple et de nombreuses ressources sont présentes sur internet. Elle est de plus compatible avec un grand nombre de composants ce qui nous laissait une large marge de manœuvre dans le choix des autres composants. Enfin, chaque membre de notre équipe avait déjà travaillé avec Arduino, ce qui réduisait notre temps de formation. 

pourquoi uno voir c’est quoi la différence 

 

Afficheur LCD

Nous voulions au départ utiliser un écran LCD graphique couleur afin de pouvoir afficher des photos et des images. Toutefois suite à un problème de matériel, nous n’avons eu à disposition qu’un écran LCD permettant d’afficher du texte uniquement. Suite à un échange avec des clients potentiels nous avons établi que cet afficheur était amplement suffisant pour un premier prototype. De plus, la petite taille du message possible à afficher sur l’écran n’est pas un problème car cela convient mieux aux enfants ciblés, des messages trop grands pouvant les perturber ou les rebuter. 

 

Neopixel unique

Nous avons choisi d’utiliser une LED neopixel car celle-ci peut changer de couleur, ce qui permet d’avoir à la fois des lumières douces et vives afin d’attirer l’attention de l’enfant. De plus, ce composant est facile d’utilisation, possède une forte luminosité (une seule LED est nécessaire) et compatible avec arduino.

 

Imprimer en 3D 

Nous avons décidé d’imprimer l’objet avec une imprimante 3D pour ce premier prototype pour des raisons pratiques. Ce procédé est simple, rapide et disponible directement au fablab de notre école. Il est aussi compatible avec nos besoins puisque nous avons choisi de faire nous même le design.

Le plastique imprimé est assez solide pour protéger tout le matériel électronique, et donc adapté à une utilisation par des enfants.

 

MIT App Inventor

Pour programmer l’application sur smartphone, nous avons utilisé le langage de programmation proposée par le MIT qui s’appelle App Inventor. Ce langage de programmation est assez limité dans ses possibilités, tant techniques qu’esthétiques. Nous avons toutefois choisi d’utiliser cela à cause de contraintes de temps. App Inventor était le seul langage de programmation d’application que les membres de notre groupe connaissaient. Au vu du temps qui était consacré à ce projet, nous n’avions pas le temps de nous former à d’autres langages. Nous nous sommes donc tournés vers App Inventor qui est facile d’utilisation et qui offre des possibilités suffisantes pour les besoins d’un prototype.

 

VII-Perspectives

 

Après la conception de ce premier prototype, notre objet est encore loin d’être terminé, et nous pourrions non seulement améliorer les fonctionnalités déjà existante, mais aussi en développer d’autres.

Afin d’améliorer les fonctionnalités existantes, nous pourrions :

• Intégrer une batterie à l’intérieur de l’objet
• Utiliser une autre technologie réseau, adaptée à la communication longue distance (de l’ordre du kilomètre) 
• Implémenter des fonctionnalités temporelles, qui permettraient aux parents de programmer des rappels à l’avance 
• Utiliser plusieurs neopixels et LED, avec la possibilité de programmer des motifs lumineux

De plus, afin d’améliorer notre objet, nous pourrions développer d’autres fonctionnalités :

• Remplacer l’écran existant avec un écran couleur, qui pourraient afficher des photos et des pictogrammes en plus du texte
• Développer la possibilité d’émettre des musiques, ou bien des messages vocaux pré-enregistrés
• Utiliser un autre langage de programmation, afin d’avoir plus de liberté et de possibilité pour le développement de l’application mobile
• Retravailler le design, avec en particulier la possibilité de faire un objet entièrement translucide
• Faire une base de données permettant aux parents d’utiliser des musiques déjà existantes, ou d’en rajouter
• Développer des fonctionnalités de localisation, comme un suivi GPS ou une aide pour faire des trajets habituels

 

VIII-Sources: 

 

[1]Arduino UNO Home Automation using Bluetooth HC05 module:

https://create.arduino.cc/projecthub/iot-enthusiast/arduino-uno-home-automation-using-bluetooth-hc05-module-12f2aa

consulté le 17/12/2019

 

[2]Brancher un haut-parleur à l’Arduino:

http://electroniqueamateur.blogspot.com/2015/07/brancher-un-haut-parleur-larduino.html

consulté le 17/12/2019

 

[3]Mise en oeuvre I2C vers LCD carte chinoise sur Arduino:

http://blog.f8asb.com/2014/03/01/mise-en-oeuvre-i2c-vers-lcd-carte-chinoise-sur-arduino/

consulté le 17/12/2019

 

[4]Arduino – Apprendre à développer pour créer des objets intelligents:

https://www.editions-eni.fr/open/mediabook.aspx?idR=8457f073dc836b48a324c65a97bdc71b

consulté le 17/12/2019

 

[5]Utiliser un module Bluetooth HC-05 avec Arduino: 

https://eskimon.fr/tuto-arduino-907-utiliser-un-module-bluetooth-hc-05-avec-arduino,

consulté le 17/12/2019

[6]HOW TO CONNECT SPEAKER TO ARDUINO | DIY | ARDUINO LESSONS:

https://www.youtube.com/watch?time_continue=1&v=MWwqIDTJSPY&feature=emb_title

consulté le 17/12/2019

 

[7]Audio Player using ARDUINO [sd card interface]:

https://www.youtube.com/watch?v=uSUZbLlRi1g&t=103s

consulté le 17/12/2019

WinSumption – Solution Technique

Envoyé par Eric Tobitt le 20 Déc 2019 dans Portfolio, Projets, À la une, TAF CoOC | 0 commentaire

Conception d’un système d’économie d’énergie en résidence

 

Ce document a pour but de présenter et documenter la solution technique mise en place afin de répondre au besoin du projet et justifier les choix techniques effectués lors de la conception ainsi que décrire les perspectives dans l’éventualité d’un projet plus long.

Document rédigé par : BENFATTALLAH Annass, GUILLAUME Jean, LALO Emile, TOBITT Eric

 

I) Présentation de l’objet électronique communiquant

 

 

 

• Présentation synthétique :

 

 

La solution mise en oeuvre est basé sur une Arduino UNO. Un capteur relève périodiquement la température et la transmet via le module Bluetooth par la carte Arduino. L’Arduino est alimentée par un bloc de piles rechargeables afin d’assurer la portabilité du prototype.

 

(insérer photos) + mettre le schéma global d’architecture du PPT d’Eric (du thermomètre au gérant qui utilise l’appli)

 

 

• Présentation détaillée :

 

 

1. Structure

 

Le capteur réalisé a été placé dans un boîtier conçu avec deux compartiments communicants. Le premier pour le bloc de piles, lourd, qui est maintenu en place à l’aide des parois et de vis. Le second contient l’Arduino, le module bluetooth branché sur la breadboard ainsi que le capteur de température. Du volume a été laissé pour pouvoir manipuler la configuration et le câblage. Une ouverture entre les deux compartiments est laissée pour passer le fil d’alimentation électrique. L’ensemble des composants électroniques sont fixés aux parois de leur compartiment pour éviter que des mouvements altèrent les branchements quelque peu fragiles. De plus des ouvertures d’aération ont été stratégiquement placées pour éviter que le fonctionnement du capteur influe sur la bonne mesure de la température.

 

 

 

2. Matériel électronique

 

• Carte Arduino UNO

 

Le choix d’une carte arduino s’est fait au vu des tâches simples de transfert d’information à effectuer, ne nécessitant pas de processeur avancé. De plus la grande modularité de l’Arduino, l’existences de nombreux composants compatibles et des bibliothèques associées ainsi que la vaste ressource présente en ligne ont permis un prototypage relativement rapide et modulaire. Ainsi on a pu orienter le choix des modules et le développement du programme embarqué en fonction de contraintes fonctionnelles réelles. De plus, l’Arduino fonctionnant avec peu d’énergie, celle-ci nous a permis de faire un prototype portable utilisant des piles rechargeables, afin d’avoir une solution plus proche de la solution final souhaitée. L’installation de capteurs sans fils présente un réel intérêt pour les clients interrogés, pouvant ainsi se passer du surcoût important que représente le câblage d’un bâtiment entier.

• Capteur de température de d’humidité DHT11

 

Ce capteur de température et d’humidité a été sélectionné pour des raisons techniques mais aussi pratiques. Sa mise en oeuvre est simple, la communication avec l’arduino se fait avec un unique port digital à sens de transmission alterné, sélectionné en début du code Arduino, émettant sur demande de l’Arduino un message contenant la température mesurée au degré près ainsi que l’humidité au pourcentage près. Le prototype réalisé ne nécessitant pas de mesures précises, et ce capteur étant disponible et fonctionnant correctement, il a été jugé satisfaisant pour la présente application. Il utilise une bibliothèque DHT existante.

• Module Bluetooth HC-05

 

Le module HC-05 est le module Bluetooth le plus utilisé sur Arduino. Il se connecte via deux ports séries RX et TX à l’Arduino. Ceux-ci sont configurable sur des ports digitaux (ici respectivement 12 et 13) grâce à la bibliothèque SoftwareSerial afin de garder disponible les ports séries 0 et 1 utilisés par le port USB disponibles. En imprimant (print()) simplement la chaîne de caractères sur le port série TX de l’Arduino (RX du module) celle-ci est transmise via Bluetooth au téléphone connecté. Ici on transmet de cette manière, toutes les secondes, la température et l’humidité relevées.

Le choix de la communication par Bluetooth sur le prototype s’est fait pour l’économie en énergie de cette technologie, ainsi que la compatibilité aisée avec l’Arduino et le smartphone utilisé comme station de base. Une communication Wifi trop énergivore compromettrait la portabilité du prototype et le désir du client d’avoir des capteur sans fils et le Lora n’est pas disponible nativement sur Android donc rallongerait considérablement la phase de prototypage dédiée à son implémentation. Cependant, la portée limitée du Bluetooth et une consommation qui reste trop élevée ne permet probablement pas d’en faire une solution définitive à l’échelle d’un bâtiment, ce que nous détaillerons dans les perspective de développement de la solution.

• Bloc d’alimentation

Nous avons choisi de rendre le capteur autonome en énergie. Cette réalisation est importante avec le besoin de modularité de la solution. Ainsi, suite au choix de technologies économes en énergie, nous avons choisi d’utiliser un bloc de 8 piles rechargeables fournissant 9,8V au total pour une capacité de 2200mAh. Cette alimentation branchée sur le port X1 de l’Arduino (qui prend des tensions de 9V à 12V) alimente correctement la carte ainsi que les modules connectés. On mesure une consommation de 90mA lorsque le module Bluetooth est en recherche, puis une consommation oscillant entre 50mA et 70mA lors des phases de transmission. On calcul une autonomie en fonctionnement d’environ 35h, ce qui n’est pas suffisant pour un capteur réel (voir perspectives) mais largement assez pour le démonstrateur réalisé.

 

 

3. Code Arduino

 

Le code utilisé sur l’Arduino Reprend deux bibliothèques: celle du capteur de température DHT et SoftwareSerial permettant d’utiliser le module bluetooth en parallèle du port sérial natif utilisé pour communiquer en USB.

On initialise donc le port utilisé pour le module DHT ainsi que les ports RX et TX (12 et 13 ici) utilisés pour le module Bluetooth. On démarre donc les ports série natif et Bluetooth avec le bon Baud rate (9600) et la communication en dht. Ensuite la boucle infinie procède à une pause d’une seconde pour limiter la fréquence des transmissions, récupère les données du capteur et les transmet comme chaîne de caractères en utilisant la fonction print() sur le port Bluetooth avec des séparateurs prédéfinis en accord avec l’application Android (ici “x” et “z”). Le port série natif a été utilisé à des fins d’essais.

B) Présentation de l’application Android :

 

• Logiciel utilisé :

 

Deux d’entre nous avaient déjà participé à un projet d’application avec Android Studio. Nous avons aussi envisagé d’utiliser MIT App Inventor pour l’application Android mais il y a plusieurs inconvénients :

– la programmation par blocs met des contraintes.

– faible communauté de développeurs pour résoudre les problèmes/erreurs rencontrés

– nous avions très peu d’expertise avec cette technologie

Nous avons donc choisi le logiciel Android Studio.

 

 

• Stockage des données : (partie que l’on peut raccourcir si besoin)

 

Pour le stockage des données de température nous avons utilisé l’API SharedPreferences.

L’idée de départ était d’utiliser une base de données de type SQLite qui est un type de base de données compatible avec Android Studio. Cependant, le temps que nous avions était restreint et nous avions peu d’information à stocker (un relevé de température par minute maximum). En effet, dialoguer avec une base de données demande d’utiliser un grand nombre de classes (« DAO »), ce qui complexifie grandement la réalisation du prototype.

L’idée suivante fut d’utiliser un fichier «.txt » stocké de préférence en stockage externe (carte SD). Nous avons tenté d’implémenter cette solution mais un problème (nous n’arrivons pas à écrire à nouveau dans un fichier existant) nous a conduits à changer de solution et à utiliser l’API SharedPreferences.

Celle-ci permet de stocker les données dans un fichier xml et fournit des services pour stocker et récupérer des entrées (clé+valeur). De plus le fichier xml correspondant est accessible depuis toutes les activités.

 

 

• Différentes pages et navigation entre les pages :

 

La page de login est le point d’entrée de l’application. C’est de là que l’on accède à la page d’activation de la réception sans fil (bluetooth dans notre cas) d’informations des capteurs.

Le centre de l’application est la page de base d’informations sur les résidents. De là on accède aux données des capteurs correspondant à un résident en particulier. On peut aussi accéder à la page qui liste les alertes de surconsommation.

Pour l’instant, les alertes sont à rentrer manuellement lorsque le gérant remarque des une surconsommation, mais il semble important que la version finale de l’application détecte automatiquement les situations de surconsommation. Cela permet de repérer les résidents peu attentifs à leur consommation énergétique. Pour l’instant, le gérant a tout de même un historique des surconsommations dont il s’est rendu compte.

Nous avons choisi un graphique de type “LineChart” (ligne brisée) réalisé grâce à la bibliothèque “MPAndroidChart”. La page de visualisation récupère la donnée de température récupérée lors de l’activation du Bluetooth à travers l’API “SharedPreferences”.

 

 

• Lien vers le code

https://github.com/Anassbenfathallah/Projet_Fil_Rouge_CoOC

 

C) Perspectives / Prolongation possible du projet :

   

Suite aux tests d’expérience utilisateur que nous avons réalisés, nous avons eu des retours sur de potentielles fonctionnalités à développer en cas de prolongation du projet. Ces différentes perspectives d’amélioration peuvent être séparées en deux catégories : Les améliorations techniques et les amélioration de l’interface.

 

 

• Améliorations Techniques

 

 

Les différentes points d’amélioration techniques sont les suivants :

 

• Compactage de la solution : Notre solution était déjà suffisamment compacte pour un prototype (95 x 80 x 130 mm). Cependant dans l’optique d’améliorer ce prototype pour se diriger vers une commercialisation, il pourrait être intéressant de le rendre encore plus compacte en remplaçant la carte arduino par un circuit imprimé spécialement conçu, intégrant bluetooth et les capteurs souhaités.

 

• Technologie LoRa : Notre solution fait communiquer les capteurs avec l’interface via bluetooth. Bien que cette technologie soit adaptée pour un prototype simple, elle ne peut être envisagée pour une solution réelle. En effet dans l’optique d’installation de la solution en logement, la technologie bluetooth pourrait poser divers problèmes :
  • La portée d’émission du signal est relativement faible pour du bluetooth (environ 20m sans obstacles) tandis que le LoRa permet une portée d’émission de plusieurs kilomètres.
  • Le bluetooth permet simplement de jumeler deux objets entre eux mais n’est pas adapter pour faire communiquer un réseau d’objets entre eux. La technologie LoRa permet la communication entre plusieurs objets.
  • Le Bluetooth consomme plus que le LoRa compliquant donc les solutions d’alimentation en énergie.

 

• Batterie alimentée par panneaux solaires : Notre solution comprend actuellement un bloc de 8 piles AA ce qui est trop gourmand en énergie. Il serait préférable d’intégrer une batterie alimentée par panneaux photovoltaïques. Il faut noter que la consommation énergétique de l’objet est suffisamment faible pour être alimenté par des panneaux photovoltaïques éclairé par la lumière de la chambre.

 

• Ajout de capteurs : Notre solution comprends actuellement un seul capteur de température. Il serait plus intéressant de rajouter de nouveaux capteurs tel que un second capteur de température collé au chauffage afin d’en mesurer la consommation énergétique.

 

 

• Améliorations de l’interface

 

 

Au-delà des améliorations techniques, des améliorations de l’interface pourrait permettre d’améliorer l’expérience utilisateur de notre solution. Voici les améliorations possibles auxquelles nous avons réfléchie :

 

• Implémentation d’une page Web : En plus de l’application Android, il pourrait être intéressant d’accéder à l’interface via une page web afin de visualiser les informations de l’application sur un écran plutôt que sur un téléphone.

 

• Ajout de fonctionnalité de restitution des données : Notre solution comprend actuellement un graphe permettant de restituer la température d’un logement au cours du temps. D’autres moyens de restitutions des données peuvent être envisagés. Un des retours des utilisateurs, était d’envisager d’afficher un plan par étage des bâtiments de la résidence pour y afficher la température par logement. Ceci permettrait à l’utilisateur de visualiser les différences de températures entre tous les logements d’un même étage.

 

• Implémentation d’une page de gestion des alertes : Notre solution contient actuellement une page d’alerte permettant à l’utilisateur de visualiser des alertes de sur-consommation. Cependant toute la partie traitement des données pour automatiser la création d’alerte n’a pas été faite. Il serait intéressant d’implémenter une page permettant de gérer les seuils d’alertes à la guise de l’utilisateur.

 

COOCOPARK – Solution technique

Envoyé par Tristan Boussard le 20 Déc 2019 dans Portfolio, À la une, TAF CoOC | 0 commentaire

Auteurs : BOUSSARD Tristan, LANTRIN Julien, PREVOST Matthias, RUNACHER Oscar

 

Contexte

Dans le cadre de la TAF CoOC, les élèves doivent réaliser un projet fil rouge de développement et de prototypage. C’est dans ce contexte que nous avons proposé notre propre projet : COOCOPARK.

Pour ce projet nous souhaitons proposer une solution sous la forme d’une application qui indique à l’utilisateur une place de stationnement adaptée à ses critères et le plus proche possible de sa destination. L’application présente à l’utilisateur un ensemble de parkings sur une carte et lui fournit un chemin pour accéder à une place actuellement disponible qui correspond à une distance minimale de sa destination et à la taille de son véhicule. La disponibilité des places est actualisée en temps réel.

Ainsi, nous avons réalisé un prototype qui grâce à des capteurs ultrasons connectés à une carte Arduino est capable d’indiquer l’occupation ou non de places de stationnements fictives à une application iOS/Android codée en React Native. L’application utilise aussi des données issues d’une API de Brest Métropole et du site de Brest’Park pour afficher des informations supplémentaires sur les parking brestois à l’utilisateur.

(suite…)