Robot Pepper – Hackathon ENSIBS 2020

Envoyé par a18allem le 7 Fév 2020 dans À la une, Portfolio, Projets | 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 Portfolio, Projets, À la une, TAF COUAD | 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 COUAD | 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 COUAD | 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…)

STiL – Solution Technique

Envoyé par Clément Rubin le 20 Déc 2019 dans Portfolio, Projets, À la une, TAF COUAD | 0 commentaire

Introduction

 

L’idée de travailler sur le trafic routier nous est venue suite à de simples observations de l’état actuel du trafic dans la ville de Brest. En effet, Brest présente plusieurs points d’engorgement notamment à proximité des ponts permettant de passer de la rive gauche à la rive droite de la ville. Nous avons aussi constaté que ces conditions de circulation difficiles avaient de nombreuses conséquences notamment psychologiques (état d’énervement et de stress) … Il nous a donc semblé pertinent d’essayer de trouver des solutions pour fluidifier le trafic urbain. Nous allons dans cet article vous exposer notre solution, justifier nos choix techniques et les perspectives du projet.

 

Le projet STiL (Smart Traffic Light) consiste à la fluidification du trafic routier par la mise en réseau des feux de circulation. 

Les feux tricolores sont source d’embouteillages et de ralentissements inutiles souvent parce qu’ils se basent sur un plan de feux établi à l’avance fixe qui ne s’adapte pas aux conditions de circulation en temps réel. Notre solution STiL devrait permettre de connecter ces feux entre eux et de les rendre “intelligents” afin de trouver une configuration plus efficace et ainsi réduire les embouteillages dans une agglomération donnée. 

STiL devrait implémenter deux modèles d’intelligence :

• Une intelligence locale. Celle-ci se base sur l’état de l’intersection à un instant donné et fait passer le feu de l’axe vide au rouge afin de faire passer le plus de véhicules possibles. Ainsi, la situation où un conducteur attend à un feu alors que personne ne passe sur l’axe perpendiculaire n’existera plus.
• Une intelligence globale. L’objectif est ici de trouver la meilleure configuration des feux au niveau d’un quartier, d’une ville … Ceci peut être fait par l’utilisation d’une intelligence artificielle qui compile toutes les données de tous les feux afin de déterminer la configuration qui permettra de réduire les embouteillages au maximum sur la zone choisie.

Ces deux modèles d’intelligence ne se basent pas sur l’expérience des régisseurs de feux qui est pourtant primordiale dans ce contexte. C’est pour cela que STiL devrait permettre à la régie d’intervenir sur le fonctionnement de l’algorithme en configurant certains paramètres manuellement afin d’assurer un contrôle humain du dispositif. Les différents paramètres pouvant être configurés incluent notamment :

• Un temps d’attente minimal pour un véhicule motorisé à une intersection. Cela permet de ne pas faire attendre un automobiliste indéfiniment devant un feu si l’axe perpendiculaire est saturé.
• Une durée maximale de feu rouge. Le système STiL ne permet pas la détection des petits véhicules (comme les vélos) cependant, ceux-ci doivent quand même pouvoir traverser l’intersection. Ceci peut se faire en imposant une durée maximale de feu rouge. Quand ce temps sera écoulé, le feu passera au vert et le cycliste pourra traverser.

D’un point de vue technologique, STiL se base sur un système de réseaux de capteurs, une unité centrale et une interface utilisateur. Le réseau de capteurs devrait se déployer sur des feux de circulation déjà installés et consisterait en un petit boitier et un capteur de présence de véhicule. Ces boitiers communiquent en LoRa avec l’unité centrale qui traite les données de tous ces capteurs et leur renvoie le plan de feux à appliquer. L’unité centrale est aussi en charge du traitement des données pour que celles-ci soient visualisables sur l’interface utilisateur. Cette interface prend la forme d’un client local à installer sur un ordinateur quelconque qui permet à la fois de visualiser l’état du trafic et des feux sur chaque intersection mais aussi d’interagir avec l’unité centrale pour lui envoyer les nouveaux paramètres de configuration (temps d’attente minimal …) à utiliser.

 

En quelques mots, on peut dire qu’avec STiL, les feux rouge ne vont plus faire long feu.

Présentation de la solution technique

Photos globales de la maquette

Définition des différents cas d’étude et visualisation du résultat sur la maquette

 

Pour tester le bon fonctionnement de la maquette, nous avons défini dix cas d’usage à valider physiquement. 

 

1. Fonctionnement classique d’un feu tricolore 

 

Le feu reste X secondes au vert puis passe au rouge pendant X secondes.

Cette situation se produit lorsqu’il n’y a pas de voiture détectée aux l’intersection pendant les X secondes.

 

1. Voiture sur axe principal et personne sur axe secondaire 

 

Lorsqu’une voiture arrive sur l’axe principal et qu’il n’y a aucun véhicule sur l’axe secondaire, le feu tricolore de l’axe principal passe au vert. 

 

1. Voiture sur axe secondaire et personne sur axe principal 

 

Lorsqu’une voiture arrive sur l’axe secondaire et qu’il n’y a aucun véhicule sur l’axe principal, le feu tricolore de l’axe secondaire passe au vert. 

 

1.  Voiture sur axe principal détecté par le capteur lointain et voiture sur axe secondaire détecté pendant la traversée de la voiture de l’axe principal. 

 

Si une voiture A est détectée sur l’axe principal par le capteur lointain et qu’une voiture B est détectée ensuite par le capteur de l’axe secondaire, il faut laisser le temps à la voiture A de franchir le feu. Puis le feu secondaire passe au vert pour laisser passer la voiture B.

 

1.  Voiture sur axe secondaire détecté par le capteur de proximité et voiture sur axe principal détecté pendant la traversé de la voiture secondaire. 

 

Si une voiture A est détectée sur l’axe secondaire et qu’une voiture B est détectée ensuite par un capteur de l’axe principal, il faut laisser le temps à la voiture A de franchir le feu. Puis le feu principal passe au vert pour laisser passer la voiture B.

 

1. Embouteillage sur axe principal et une voiture détectée sur axe secondaire.

 

On est dans le cas d’un fonctionnement normal, les voitures de l’axe principal passent pendant Y secondes puis la voiture de l’axe secondaire passe (feu vert sur l’axe secondaire). Il n’y a ensuite plus de voiture sur l’axe secondaire donc l’axe principal doit repasser au vert (voiture détectée sur l’axe principal). 

 

1. Embouteillage sur axe secondaire et une voiture détectée sur axe principal. 

 

On est dans le cas d’un fonctionnement normal, les voitures de l’axe secondaire passent pendant Y secondes puis la voiture de l’axe principal passe (feu vert sur l’axe principal). Il n’y a ensuite plus de voiture sur l’axe principal donc l’axe secondaire doit repasser au vert. 

 

1. Embouteillage sur l’axe principal et sur l’axe secondaire 

 

On est dans le cas d’un fonctionnement normal, les feux changent d’état toutes les Y secondes. 

 

1. Une voiture est captée sur l’intersection principale et le feu passe au vert sur la maquette physique (led verte) et sur l’interface utilisateur.

Ce test nous permet de vérifier le bon fonctionnement de la connexion entre la maquette physique et l’interface utilisateur.

1. Une voiture est captée sur l’intersection principale n°1 et une autre est captée sur l’intersection principale n°2, les différents feux doivent passer au vert ou au rouge sur la maquette et sur l’interface utilisateur.

Ce test nous permet de vérifier que l’interface utilisateur prend bien en compte simultanément des changements d’état de plusieurs feux sur différentes intersections. 

 

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

 

Architecture matérielle

 

Architecture logicielle

Lien Github : https://github.com/yohanpeuziat/STiL-project

Matériel utilisé et montage électronique 

Technologies utilisées : justification

Comme nous l’avons vu dans la partie précédente, plusieurs technologies ont été utilisées (standard de communication, langages de programmation, technologie de captation …). Nous allons dans cette partie justifier ces différents choix techniques. 

Standard de communication et cartes programmables

Nous avons décidé d’utiliser la technologie LoRa pour les communications entre les différentes cartes programmables. LoRa possède de nombreux avantages qui nous ont poussé à faire ce choix technique :

• Utilisation des bandes libres ISM ;
• Faible consommation d’énergie ;
• Communication possible sur de longues distances. Ce point est crucial pour notre système de feux qui devrait couvrir une ville entière ;
• Possibilité de faire un réseau maillé. L’intérêt est que si le serveur n’est – malgré la très longue distance de propagation – pas joignable par un feu, alors un autre feu peut servir de passerelle vers le serveur. Il suffit pour cela de programmer une table de routage sur les cartes électroniques ;
• Facilité d’utilisation et disponibilité du matériel. Au contraire de Sigfox (qui possède des caractéristiques techniques similaires), du matériel était disponible au téléfab.

 

Les modules LoRa présents au Fablab étaient des modules Grove LoRa. Ceux-ci fonctionnent aisément sur les cartes Seeeduino à condition de télécharger la librairie adaptée disponible ici : lien vers la librairie LoRa pour Seeeduino.

C’est pour cela que nous avons choisi d’utiliser des cartes Seeeduino et non des cartes Arduino “classiques”.

Technologie de captation

Le choix de la technologie des capteurs s’est porté sur un capteur infrarouge puisque ceux-ci étaient particulièrement bien adaptés à notre besoin pour la maquette – captation précise des distances (nécessaire pour déterminer si une voiture se trouve du bon côté de la chaussée) et champ angulaire correct – et que le fablab présentait un grand nombre de ces capteurs. 

 

Quant à la configuration du système de captation (autrement dit, la disposition des capteurs dans l’espace), plusieurs solutions étaient possibles. Celles-ci sont résumées dans le tableau suivant :

 

Configuration de la captation	Avantages	Inconvénients
Uniquement en amont de l’intersection	Les données peuvent être traitées avant que le véhicule n’atteigne l’intersection.	On ne sait pas si le véhicule a franchi l’intersection ou non impliquant des prises de décision inefficaces.
Uniquement au niveau du feu	On sait que le véhicule attend à l’intersection.	Le véhicule doit attendre avant que les données soient traitées.
En amont de l’intersection et au niveau du feu	On peut traiter les données avant que le véhicule n’arrive à l’intersection et l’on sait s’il l’a passée ou non.	Il faut deux capteurs. L’algorithme est plus complexe.

 

Finalement, nous avons opté pour la solution comprenant deux capteurs par voie. En effet, elle seule permet d’assurer le passage de chaque voiture avec un temps d’arrêt minimum. De plus, nous avons également constaté la difficulté qu’il existe à n’avoir qu’un seul capteur pour une voie. En effet, la très forte directivité de ces capteurs ne permet ni une captation sur la diagonale ni dans l’axe en surélevant les capteurs. La figure suivante donne un aperçu du problème pour un capteur surélevé. 

 

Cependant, un système de captation infrarouge n’est pas implémentable en situation réelle puisque ces capteurs sont très dépendants de la luminosité ambiante. De plus, plusieurs intersections implémentent déjà un système de captation par boucle magnétique qui pourrait être réutilisable pour notre projet.

Langages de programmation

Langage Arduino sur les cartes programmables

Nous avons préféré directement coder en C dans l’IDE Arduino que d’utiliser CodeBlocks puisque nous maîtrisons tous ce langage et que nous n’étions pas habitués à utiliser le codage par bloc.  

Python

Nous avons utilisé le langage Python comme interface entre la carte Arduino en réception et l’unité centrale. Avoir une telle interface était nécessaire sachant qu’il est impossible d’écrire dans des fichiers à partir de l’IDE Arduino. Python s’est vite imposé comme le langage à utiliser. En effet, c’est un langage simple et connu de tous les membres du groupe. C’est aussi un langage assez haut niveau pour cacher les spécificités des OS et des drivers utilisés par celui-ci dans la lecture des ports USB (ce que ne fait pas le langage C par exemple). Enfin, Python est un langage où la gestion locale des fichiers est très simple.

HTML/CSS

Les langages HTML et CSS sont connus pour leur utilisation dans les sites web. Ces deux langages sont complémentaires, l’un gère le fond tandis que l’autre s’occupe de la forme. Nous avons décidé de les utiliser pour créer l’interface utilisateur en raison de leur simplicité.

Javascript

Nous avons utilisé le langage JavaScript pour dynamiser l’interface utilisateur. Ce langage a permis de répondre à deux besoins majeurs :

• rendre l’interface utilisateur interactive
• récupérer les données de la base de données afin de les restituer sur l’interface utilisateur, à travers l’appel à un script PHP

Ce langage a l’avantage de s’interfacer très facilement avec les langages HTML, CSS et PHP.

PHP

Le langage PHP est principalement orienté serveur. Il est très utile pour la gestion des bases de données ainsi que le transfert d’informations. C’est pourquoi ce langage a pour rôle, dans notre projet, de lire le fichier de données afin de les envoyer à l’interface utilisateur.

L’appel à un script PHP nécessite la mise en place d’un serveur local sur l’unité centrale (ordinateur dans notre cas).

 

Emulation d’une base de données par un fichier txt

Dans un premier temps, nous avions pensé développer une base de données complète en MySQL accessible via un script PHP qui serait appelé par le Javascript. Finalement, après avoir implémenté une première version de la solution se basant sur un fichier txt ouvert par le script Python et par le PHP, nous avons choisi de garder cette solution pour plusieurs raisons :

• La simplicité. Nul besoin de développer une base de données à partir du moment où l’on standardise les informations écrites dans le fichier txt et que l’on code “en dur” l’interprétation qu’il faut faire de celle-ci.
• La non-prolifération de scripts et de documents. Il était nécessaire de passer par un fichier txt. En effet, le script Python ne peut pas à lui seul écrire dans la base de données. Une solution évidente aurait donc été de faire un script PHP complet qui lit le fichier txt puis écrit dans la base de données les informations contenues. Cette solution aurait été beaucoup plus lourde à implémenter (seule la partie lecture du document txt a dû être développée) et n’aurait pas supprimer la présence d’un fichier txt
• Apport en termes d’expérience utilisateur. Nous avons pensé qu’ajouter une US technique implémentant une base de données n’aurait pas apporté assez de valeur à l’utilisateur pour que celle-ci soit prioritaire.

 

Malgré tout, nous sommes conscients que cette solution n’est pas viable sur le long terme et que si notre projet devait être repris et développé à plus grande échelle alors le passage par une véritable BDD serait nécessaire.

 

Conclusion et perspectives

A ce stade, notre maquette présente les caractéristiques nécessaires afin de démontrer la pertinence de notre solution. Néanmoins avec plus de temps, nous pourrions améliorer cette maquette. Voici quelques pistes d’amélioration :

• Avoir un algorithme de gestion globale des deux intersections.
  Un autre point que nous avions abordé lors de l’étude de notre solution était la possibilité d’avoir un algorithme de zone et non juste local comme c’est le cas actuellement. En d’autres termes, la seconde intersection devrait notamment pouvoir se synchroniser avec la première. Ceci rendrait l’algorithme beaucoup plus complexe (possible inclusion d’IA) et nous n’avons pas souhaité essayer de le réaliser.
• Avoir un système reposant sur une Base de Données et non plus un fichier txt.
  Comme expliqué plus haut, nous avons basé nos échanges sur un fichier txt. Pour des raisons de passage à l’échelle (agrandissement de notre système), il serait préférable de disposer d’une base de données regroupant toutes les informations.
• Avoir une version plus complète de l’interface graphique.
  • Avoir une véritable page de login.
    Actuellement une page de login existe mais celle-ci ne vérifie pas la concordance login / mot de passe.
  • Disposer d’une page de visualisation des données avec graphique et tableau.
    L’emplacement de la page est prévu mais pas son contenu.
  • Intégrer une véritable carte routière avec la possibilité de zoomer sur celle-ci. Nous avons intégré le schéma d’une route dans notre application afin de visualiser les feux.
  • Pouvoir changer le comportement de la maquette en envoyant une commande depuis l’interface graphique aux feux telle que “passe au rouge” ou “reste au vert pendant X secondes” … Cette fonctionnalité est importante, mais malheureusement nous n’avons pas eu le temps de la développer. Le plus gros point de blocage de cette fonctionnalité est l’envoi d’une commande de l’interface vers la maquette. Actuellement seul l’envoi dans le sens opposé est réalisé.
  • Pouvoir modifier le temps maximum d’attente à un feu depuis l’interface graphique. De même que précédemment, la “pièce” manquant à cette fonctionnalité est l’envoi de données de l’interface vers la maquette.

Mettre des feux sur tous les axes.
La maquette actuelle comporte 8 axes mais seulement 4 axes sont équipés de feux connectés. Cela aurait rendu la maquette plus réaliste mais n’apporte pas de changements majeurs quant à son fonctionnement.

SmartSéc – Synthèse du projet

Envoyé par Rodrigo Santana Aguiar le 18 Déc 2019 dans TAF COUAD, Portfolio, Projets, À la une | 0 commentaire

I – CONTEXTE :

Les élèves de la Thématique d’Approfondissement « Conception des Objets Communicants » d’IMT Atlantique étaient censés développer un projet pour résoudre une problématique de la société dans n’importe quel domaine. C’était alors dans ce cadre, et étant donné que l’agriculture familiale est responsable de 80% de la production alimentaire mondiale, que nous avons décidé d’aider les agriculteurs familiaux à augmenter leurs profits et la qualité de leurs produits tout en utilisant des technologies simples et peu coûteuses. Ainsi, nous avons convenu de focaliser sur le séchage solaire, étant donné qu’il s’agit d’une technique « verte » permettant de prolonger la durée des aliments et, par conséquentet, réduire les pertes après la récolte.

Nous avons donc réalisé un prototype d’un séchoir solaire intelligent équipé des capteurs de température et d’humidité de l’air et des systèmes de ventilation et de transfert de données par Bluetooth intégré à une plaque Arduino. En plus, on a développé une application Android afin de recevoir les données mesurées et de contrôler le séchoir. Pour ce faire, l’utilisateur lance l’application et sélectionne le produit qu’il veut sécher ; il est donc informé des limites de température et du temps de séchage optimaux. Lorsqu’il démarre le processus de séchage depuis l’application, les données des capteurs sont affichées en temps réel sur l’écran. Parallèlement, le système de ventilation, nécessaire pour garantir la circulation de l’air et améliorer le taux de transfert de masse, empêche que la température dans le séchoir monte au-dessus de celle recommandée.

Figure 1. SmartSéc : le séchoir solaire intelligent.

 

II – RÉALISATION :

Maquette :

• Deux plaques de contreplaqué 13.2×13.2×0.6 cm        (I)
• Une plaque de contreplaqué 13.2×12.6×0.6 cm           (II)
• Trois plaques de contreplaqué 27.2×13.2×0.6 cm        (III)
• Une plaque de contreplaqué 13.2×11.2×0.6 cm           (IV)
• Une plaque de contreplaqué 17.2x12x0.6 cm               (V)
• Une plaque de verre synthétique 16.6×13.2×0.6          (VI)

Pour savoir comment faire l’assemblage des plaques de la maquette, cliquez ici.

Les encoches et les trous des plaques ont été réalisés à l’aide du logiciel Inkscape avec l’extension Tabbed Box (cliquez ici pour voir les sketchs) et d’une découpe laser. Les encoches font 1 cm de largeur et 0.6 cm de hauteur.

On a utilisé des plaques de contreplaqué de 0.6 cm d’épaisseur pour rendre la maquette plus résistante et la plaque de verre transparente a été employée puisqu’il est nécessaire le rayonnement des rayons solaires dans le séchoir pour que le séchage se produise. De plus, on a ajouté des trous sur les plaques (I)* et (III)* afin de favoriser le passage de l’air dans le séchoir.

En outre, pour cacher les câbles et améliorer l’esthétique de la maquette, nous avons convenu de créer trois compartiments : les plus petits pour les composants électroniques et le plus grand pour déposer le matériel à sécher.

Système électronique :

• Un module Bluetooth HC-05
• Un câble USB / Micro USB
• Un smartphone Android
• Une carte Seeeduino Lotus V1.1
• Un capteur d’humidité et de température DHT22
• Un mini ventilateur DC 5v
• Une mini breadboard 170 pins
• une batterie lithium-polymère TURNIGY 1000mAh trois cellules de 11.1 v
• Des fils

 

III – COMPOSANTS ÉLECTRONIQUES

Module Bluetooth HC-05

En utilisant ce module, nous pouvons établir une communication sans fils bidirectionnelle (duplex intégral) entre deux appareils ou microcontrôleurs. Ce module est assez approprié pour transférer les données, pourtant il ne permet pas le transfert de messages multimédia. Puisque nous n’avions pas besoin d’une portée importante pour la démonstration du produit, nous avons décidé d’utiliser ce module pour transmettre les données de température et d’humidité vers notre application Android. Pour ce faire, nous avons connecté le pin RXD du module au pin TXD de la carte et le pin TXD du HC-05 au pin RXD de la Seeeduino.

Figure 2. Module Bluetooth HC-05 (GoTronic, 2019).

 

Seeeduino Lotus 1.1 :

Cette carte est basée sur un ATMega328P compatible avec Arduino et est équipée de 12 connecteurs Grove : 6 digitaux, 3 analogiques, 2 I2C et 1 Uart. Elle est fabriquée à partir de la carte Arduino UNO, ce qui la rend compatible avec la plupart des programmes, des shields ou de l’IDE Arduino. Elle présente aussi l’avantage de s’utiliser directement avec les capteurs de la série Grove, ce qui permet de réaliser des prototypes sans soudure très rapidement. Les connecteurs situés sur les bords extérieurs permettent d’enficher une série de modules complémentaires.

Figure 3. Carte Seeeduino Lotus 1.1 (GoTronic, 2019).

 

Capteur d’humidité et de température DHT-22 :

Ce capteur est un modèle basique et économique. Il a été placé à l’intérieur du séchoir afin de mesurer la température et l’humidité lors du processus de séchage et puis envoyer ces données à la carte Seeeduino, qui va les traiter et les transmettre à l’application. Pour que le capteur puisse envoyer les données à la carte, nous avons connecté son pin 2 (Data) au pin 7 de la Seeeduino.

Figure 4. Capteur de température et d’humidité DHT-22 (GoTronic, 2019).

 

Mini ventilateur DC 5V :

Pour que le processus de séchage se produise, en outre le rayonnement solaire il faut avoir la circulation de l’air dans le séchoir, afin de permettre le transfert de masse. Dans ce cadre, nous avons placé un mini ventilateur à l’intérieur du séchoir pour simuler un vrai processus de séchage ; pour le séchoir en taille réelle, afin d’avoir le même résultat, il faut utiliser un ventilateur plus puissant, ce qui augmentera la consommation d’énergie. Nous avons connecté le ventilateur au pin 7 de la Seeeduino. Nous pouvons démarrer ou arrêter le ventilateur en utilisant l’application et le contrôler automatiquement en concevant le code du microcontrôleur.

Figure 5. Mini ventilateur DC 5V.

 

Schéma de branchements

La Figure 6 présente le schéma de branchement des composants électroniques de notre projet.

Figure 6. Schéma de branchement des composants électroniques.

 

IV – PROTOCOLE DE COMMUNICATION

Dans le cadre de notre projet, nous avons  choisi la technologie Bluetooth comme un standard de communication  pour plusieurs raisons. Tout d’abord, cette technologie de communication sans fil est peu coûteuse par rapport à d’autres technologies et facile à mettre en œuvre. Aussi, lorsque la carte électronique et le smartphone contenant l’application sont synchronisés, la communication est réalisée automatiquement. En outre, le fait que le module Bluetooth consomme peu d’énergie facilite sa mise en place, vu que le séchage solaire peut durer plusieurs heures. Enfin, puisque les informations transférées entre la carte et l’application ne sont pas de grande taille, le bluetooth peut garantit un bon temps de réponse.

 

V – INTERFACE ANDROID

Afin de contrôler le séchoir et suivre les valeurs de température et d’humidité, nous avons créé une application Android communicant avec le séchoir via Bluetooth, avec MIT App Inventor 2. En fait, nous avons choisi d’utiliser cette plateforme parce que nous avons eu des problèmes pour implémenter la fonctionnalité de transfert de données via Bluetooth et pour gérer la base de données sur Android Studio.

En fonction du produit choisi par l’utilisateur, l’application avertit la carte Arduino de la température et du temps de séchage optimaux de séchage. Ensuite, la carte Arduino recevant et traitant les données mesurées par les capteurs, elle les envoie au smartphone. Si jamais la température monte au-delà de celle informée par l’application, la carte Arduino augmente la vitesse du ventilateur de mode à éviter que l’aliment soit endommagé thermiquement.

Puisque nous utilisons le Bluetooth pour transmettre des données, il faut que l’utilisateur l’active et fasse l’appairage entre le module Bluetooth du séchoir et le smartphone. Lors de la première connexion, un pin sera sollicité ; dans notre cas, le pin (1234) était écrit sur un papier collé sur le module.

Une fois fait l’appairage entre les dispositifs, l’utilisateur peut lancer l’application. Sur la page d’accueil, illustré par la Figure 7, pour permettre que l’application reçoive les données, il faut cliquer sur le bouton « Connecter » et choisir le module Bluetooth qui vient d’être associé, dans notre cas, 20:16:02:30:35:20 PINSON.

Figure 7. Page d’accueil de l’application.

Puis, après avoir saisi le nom du produit à sécher, l’utilisateur verra des récommandations de séchage spécifiques. En cliquant sur « commencer », les données de température et d’humidité seront affichées sur la page d’accueil, comme illustré par la Figure 8. Lorsque l’utilisateur veut arrêter le séchage, il peut cliquer sur « Arrêter » et le ventilateur s’arrêtera et les données ne seront plus affichées.

Figure 8. Processus de séchage.

 

VI – CODE

Nous avons choisi d’utiliser le logiciel MIT App Inventor 2 pour coder l’application, car nous trouvons plus facile de comprendre la programmation en blocs. Nous avons donc commencé par la partie graphique et, puisque nos utilisateurs sont des agriculteurs n’ayant pas forcément d’aisance avec des portables, notre objectif était de concevoir une interface la plus ergonomique possible. Ensuite, nous avons créé les fonctionnalités del’application tout en ajoutant et reliant des blocs de programmation.

Pour la carte Seeeduino, nous avons développé un programme en language C afin de contrôler la vitesse du ventilateur en fonction de la limite de température informée par l’application ainsi que d’envoyer les données reçues par le capteur vers le smartphone. Le code du programme de la carte et les captures d’écrans concernant la structure en blocs de l’application sont déposés sur GitHub, et pour y accéder, cliquez ici. Afin de réutiliser l’application que nous avons faite, il faut simplement télécharger l’archive .aia, aller sur MIT App Inventor 2 et le transférer dans un nouveau projet.

 

VII – PERSPECTIVES

Étant donné que le projet avait une durée courte, nous avons décidé de nous focaliser sur les fonctionnalités les plus importantes et qui apporteraient le plus de valeur aux utilisateurs. Ainsi, nous avons dû laisser à côté quelques fonctionnalités que nous aurions aimé mettre en place lors du développement du projet.

Alors, en vue d’orienter des futures recherches et études, nous décrivons ci-dessous les prochaines étapes que nous aurions suivies si nous avons eu plus de temps :

• Mettre en œuvre un serveur pour traiter les données envoyées par les capteurs, afin de permettre le suivi du processus de séchage à distance.
• Mettre en place d’autres protocoles de communication réseau pour le transfert des données, en fonction de la portée et de la consommation énergétique envisagées (ZigBee, Internet ou LoRa, par exemple).
• Créer une version de l’application mobile comportant d’autres langues, notamment le portugais, l’espagnole et l’anglais.
• Rajouter des informations de séchage d’autres aliments sur la base de données, pour la rendre plus complète.
• Tester la sensibilité d’autres capteurs, afin de choisir celui qui présente la meilleure réponse à la variation de la température.
• Ajouter sur l’application la fonctionnalité de recherche vocale des aliments.
• Mener des études de viabilité économique concernant la mise en œuvre des panneaux solaires, de mode à rendre le séchoir complétement autonome en énergie.
• Développer une plateforme collaborative afin que les gens, notamment les chercheurs, puissent y ajouter des recommandations de séchage concernant plusieurs régions.
• Améliorer l’application afin qu’elle soit capable de se connecter à plusieurs séchoirs et de les contrôler au même temps.

 

Auteurs :

SANTANA Rodrigo

FERJANI Wadia

YIN Tan

WinSumption- Présentation des persona

Envoyé par Eric Tobitt le 25 Nov 2019 dans TAF COUAD | 0 commentaire

Présentation et explication des personas

 

Cet article présente les différents personas impliqués dans l’utilisation de notre produit. A chaque persona est associé une explication en lien avec les recherches terrains que nous avons réalisées.

Article rédigé par : Anass BENFATHALLAH, Jean GUILLAUME, Emile LALO, et Eric TOBITT

 

Suite aux différentes données recueillies lors de la recherche terrain et l’état de l’art, des profils “types” d’utilisateurs ont pu être dégagés. Il est intéressant de réaliser ces personas dans l’optique d’identifier les fonctionnalités primordiales à l’utilisateur type.

 

Persona n°1:  Le directeur de résidence, utilisateur de notre solution

Explications : 

 

Les différents entretiens passés avec le directeur de la Maisel, nous ont permis d’établir le persona de Didier, quadragénaire et Directeur de résidence étudiante. Didier n’est pas décisionnaire dans l’implémentation de notre solution dans sa résidence, mais il reste le principal utilisateur. Il est donc important que l’utilisation de notre solution correspondent aux critères de Didier.

Didier travaille au contact d’étudiants et essaie d’être à jour sur les nouvelles technologies. Cela nous donne la possibilité de développer une IHM (Interface Homme-Machine) via une application, car Didier est familier de ce genre de technologie. Didier va être amené à utiliser notre application quotidiennement, il est donc nécessaire que notre interface soit ergonomique pour lui permettre d’accéder rapidement aux informations recherchées. Lors de notre premier entretien avec le responsable de notre résidence étudiante, nous avons  remarqué que celui-ci était déjà assez informé sur les solutions connectées existantes et qu’il a même choisi des systèmes de régulation associés aux radiateurs des espaces communs de certains bâtiments.

 

Didier est actif et social. Il n’a pas volonté de punir les étudiants qui surconsomment mais simplement de les informer. Il sera donc intéressant de proposer une fonctionnalité d’envoi automatisé d’alertes aux étudiants qui consomment trop d’énergie.

 

Didier, comme beaucoup de directeurs(trices) de résidence a deux enfants : il souhaite laisser à ses enfants une planète en bon état. Ainsi il porte de plus en plus d’attention à sa consommation d’énergie, et limite son usage de la voiture.

De plus cela ne lui laisse qu’un temps limité à investir dans son travail. La solution devra donc être facile d’utilisation, avec une prise en main rapide.

Suite à notre deuxième entretien avec le directeur notre résidence étudiante, nous avons ressenti sa forte volonté de sensibiliser les résidents aux bonnes pratiques de l’économie d’énergie. Ne pouvant implémenter des solutions trop coûteuses, il cherche donc un moyen efficace pour sensibiliser les étudiants compatible avec son budget restreint. Ainsi, Didier travaille au fur et à mesure avec ses délégués résidents (ie des élèves responsables de la communication entre les résidents et la Maisel) afin de les rendre conscients des problèmes de surconsommation d’énergie.

 

Persona n°2 : Le résident de logement, qui est affecté par les changements amenés par notre solution

Explications:

 

Le questionnaire envoyé aux résidants nous a permis d’établir ce persona. Pour rappel, voici les points importants que nous avons pu identifier grâce à ce questionnaire :

• Une grande majorité des étudiants sont sensibles à l’écologie et pensent que des efforts en terme de consommation énergétique sont à faire à la Maisel
• Seule une minorité des étudiants sont prêt à payer plus pour réduire leur impact environnemental
• Une majorité n’est pas favorable à payer directement ce qu’ils consomment. On peut penser que les résidents non favorables pensent consommer en excès ce qui explique qu’ils préfèrent payer un forfait.
• La majorité des élèves estime à plus de 20 °C la température idéale du logement.

 

Grâce à ces éléments nous avons pu réaliser le persona d’Émile, 23 ans et résident en résidence étudiante. Émile représente les étudiants sceptiques à notre solution.

Émile n’est pas très impliqué dans l’écologie bien qu’il se sente concerné par les problèmes environnementaux (comme une majorité des étudiants selon le questionnaire que nous avons envoyé). Il n’est pas informé sur sa consommation et, par peur de trop consommer, préfère une facturation commune des charges. Cette facturation commune le pousse par moment, à consommer en excès sans se soucier de l’impact environnemental que cela peut avoir. Il va donc être important d’envisager une solution permettant de sensibiliser, d’informer et de motiver les résidents à faire attention à la surconsommation énergétique.

Les motivations et attentes d’Emile (travailler au calme, se coucher tranquillement, inviter ses amis de temps en temps) correspondent à celles de l’étudiant insouciant qui vit dans le présent, l’esprit occupé par ses nombreuses activités extrascolaires. Ce type d’étudiant ne met pas (en général) les enjeux environnementaux parmi ses priorités.

Dépendant encore de ses parents financièrement, Émile n’est pas prêt à payer pour réduire son impact environnemental. Il faut donc que la solution choisie n’implique pas des coûts trop importants pouvant être traduits par une augmentation  des loyers.

 

Persona 3 : Le décisionnaire, un directeur de conseil d’administration d’école, qui décide d’implémenter notre solution

Lors d’un de nos entretiens, le directeur de la Maisel nous a informé que les projets de rénovation de la résidence étaient votés par un Conseil d’Administration. Le CA de l’IMT a récemment approuvé  un projet de rénovation de certains bâtiments les rendants plus écologiques et un projet de construction de deux nouveaux bâtiments éco-responsables.

 

Christophe est pragmatique et a conscience qu’une gestion manquant d’éco-responsabilité peut nuire à l’image de son école. Son objectif est donc d’investir intelligemment dans des solutions lui permettant d’améliorer la responsabilité sociétale de l’école.

Christophe, en tant que décisionnaire, est donc prêt à investir sur des solutions écologiques, dans l’optique d’augmenter l’attractivité  de la résidence étudiante.

Il est très impliqué dans son travail et ne néglige aucune suggestion d’amélioration ou de progrès.

Ayant fait des études poussées, et étant régulièrement confrontés aux enjeux de transition digitale, il est ouvert aux solutions technologiques.

En tant qu’homme d’affaire et Directeur Financier, la valorisation de l’implémentation de la solution doit être rapide. Il sera donc  favorable à des solutions peu coûteuses et ayant un fort impact.

 

Persona 4 : Le résident très sensibilisé, et acteur du Développement Durable, qui accueillera favorablement notre solution dans son logement

Philippe représente les étudiants très favorables à notre solution.

Philippe est sensible à l’environnement et acteur du Développement Durable. Il a conscience des enjeux écologiques importants, et il est prêt à sacrifier un peu de confort pour réduire son impact environnemental.

Philippe est également actif dans une association environnementale. Il souhaite sensibiliser un maximum de personnes aux efforts environnementaux nécessaires. Notre solution permet aux résidents de recevoir des retours sur leurs consommations d’énergie. Philippe compte bien profiter de cela pour alimenter sa campagne de sensibilisation.

Philippe étant social, il sera amené à vanter les bienfaits de notre solution aux autres résidents permettant un accueil favorable de la part des étudiants plus réticents.

 

 

SmartSéc – Expression de besoin

Envoyé par Rodrigo Santana Aguiar le 25 Nov 2019 dans TAF COUAD | 0 commentaire

Dans cet article, nous exprimerons le besoin de nos utilisateurs à travers la présentation des backlogs et des user’s stories. Cependant, avant, nous ferons un bref rappel du contexte et de la problématique sur lesquels repose notre projet, ainsi que de la solution que nous proposons.

Contexte et problème

Selon l’ONU, l’agriculture familiale est responsable d’environ 70% de la production agricole mondiale. De plus, les statistiques montrent que l’activité est l’un de principaux piliers économiques dans les pays en développement, une fois qu’elle assure la subsistance de 2,5 milliards de personnes (FAO, 2003 ; XIE, AWOKUSE, 2014).

Les agriculteurs familiaux, malgré leur importance pour l’approvisionnement alimentaire mondiale, sont constamment menacés par le manque de ressources technologiques, de connaissances techniques et d’infrastructure de base. D’abord, l’analphabétisme touchant environ 50% de la population rurale, allié au manque de connaissances techniques, fait que leur productivité soit 3 fois plus faible que celle de grands agriculteurs (ALOJEDE, 2013). 

En outre, on voit, par exemple, que l’électricité n’était présent qu’en 38% d’établissements d’agriculture familiale en 2010. Cela signifie donc que la mise en place de certains types de technologies était, et l’est toujours, irréalisable (MEIRELLES, FILHO, 2015).

Compte tenu de ce contexte et de cette problématique, nous nous demandions “Comment pouvons-nous aider les agriculteurs familiaux à augmenter leurs profits ?”

On a trouvé que, la conservation des aliments présentant un vrai défi pour les agriculteurs familiaux, le séchage solaire traditionnel est la méthode la plus utilisée, surtout dans les pays en développement. Cependant, le problème qui se pose est que les techniques utilisées restent rudimentaires et aboutissent généralement à des productions de qualité médiocre, à cause de la mauvaise gestion du processus de séchage (ÇENGEL, 2012).

Solution

Ainsi, nous proposons un séchoir solaire photovoltaïque équipé par des systèmes de ventilation et de contrôle de température et d’humidité.

Les systèmes de contrôle sont composés par des capteurs et des ventilateurs, liés à une carte électronique qui enverra les données à une application mobile. Cette application va recevoir et afficher les mesures de température et d’humidité en temps réel ainsi que permettre au utilisateur d’accéder à des informations pertinentes (telles que les limites de température et d’humidité) sur divers produits. Une autre fonctionnalité de notre application est l’envoi de notifications pour avertir l’utilisateur si la température à l’intérieur du séchoir dépasse celle qui est recommandée pour le produit.

Étant donné que l’accès à l’électricité peut présenter un problème dans certaines zones, on utilise des panneaux solaires pour alimenter la carte et les ventilateurs.

Selon les données recueillies lors de l’étude de terrain, la plupart de nos utilisateurs ont peu de connaissances techniques et sont peu familiarisés avec l’utilisation des smartphones. Ainsi, dans un premier temps, nous visons à développer une application simple et facile à utiliser ; cependant, au fur et à mesure que le processus de prototypage agile avance, nous apporterons les modifications nécessaires afin que notre produit réponde aux besoins des utilisateurs.

Backlog

Dans un premier temps, nous présentons la première version de notre backlog, Figure 1 (cliquez pour visualiser) réalisé le 6 novembre.

On y trouve les trois principales users’ stories de notre projet :

• Suivi en temps réel des valeurs de température et d’humidité: il permet à l’utilisateur de visualiser automatiquement les variables du processus de séchage. Les données sont transmises de la carte électronique à l’application via un système sans fil (pour le prototype qui sera présenté à la fin du semestre, nous utiliserons Bluetooth ; pour les autres cas, une étude sur les canaux de communication sans fil les plus appropriés est nécessaire).

• Contrôle des ventilateurs: si la température dépasse la limite recommandée par l’application, l’utilisateur pourra mettre en marche les ventilateurs afin de disperser la chaleur et procéder au séchage.

• Accès à des recommandations de séchage: comme nos utilisateurs ont peu de connaissances techniques, notre application leur permet d’accéder à une base de données contenant des informations sur la plage optimale de température et d’humidité pour le traitement des produits.

Pour la dernière version de notre backlog, Figure 2 (cliquez pour visualiser), nous avons ajouté trois autres user’s stories :

• Notification de température: si la température dépasse la limite, l’utilisateur doit être averti par une notification push, afin de faciliter la gestion du processus de séchage et d’éviter d’endommager la structure physico-chimique du matériau final.

• Notification d’humidité: si l’humidité de l’aliment atteint la valeur préréglée par l’application, l’utilisateur doit recevoir une notification push, afin qu’il puisse stopper le processus de séchage.

• Obtention du matériel (capteurs, modules de transmission sans fil, entre autres): dans ce cas, il s’agit d’une  » histoire de développeur « , car c’est une des conditions Les matériaux nécessaires doivent être répertoriés et nous nous rendrons ensuite au FabLab pour vérifier leur disponibilité.

Nous avons fait cette dernière version du backlog parce que nous avons réalisé l’importance d’ajouter des notifications pour alerter l’utilisateur au cas où l’une des variables du processus atteindrait des valeurs critiques. En effet, un séchage prolongé dans de telles situations pourrait endommager le produit et entraîner une perte de qualité et de rendement.

Auteurs:

SANTANA Rodrigo

YIN Tan

FERJANI Wadia

 

References

Food and Agriculture Organization of the United Nations, « Statistics », Food and Agriculture Organization of the United Nations. [En ligne]. Disponible sur: http://www.fao.org/statistics/en/. [Consulté le: 14-oct-2019].

O. Awokuse et R. Xie, « Does Agriculture Really Matter for Economic Growth in Developing Countries? », Canadian Journal of Agricultural Economics/Revue canadienne d’agroeconomie, vol. 63, no 1, p. 77‑99, 2015.

M. de S. Filho, A. M. Buainain, C. Guanziroli, et Batalha, « Agricultura familiar – Vol. II », Issuu. [En ligne]. Disponible sur: https://issuu.com/editoraunicamp/docs/528. [Consulté le: 27-oct-2019].

Olojede, « Analysis of rural literacy as a panacea for socio-economy development of Nigeria », Int. J. Sociol. Anthropol., vol. 5, no 9, p. 381‑390, déc. 2013.

ÇENGEL, Yunus A.; GHAJAR, Afshin J. Transferência de calor e massa: Uma Abordagem Prática. 4. ed. Porto Alegre: AMGH EDITORA LTDA, 2012. 904 p.