la reconnaissance faciale

Envoyé par t21archa le 4 Juil 2022 dans Blog | 0 commentaire

1. Contexte

La reconnaissance faciale a pris une place importante au sein de notre société notamment dans le domaine de la surveillance mais la compréhension de son fonctionnement reste néanmoins complexe et n’est pas accessible à tous. Le but de ce projet était donc d’appréhender une technique de reconnaissance faciale afin de la rendre accessible et compréhensible par des élèves de première année d’école d’ingénieur à IMT Atlantique.

L’école IMT Atlantique veut implémenter, dans le programme de la première année (1A), une nouvelle UE consacrée à l’Internet des Objets et au machine learning. Pour cela, l’école dispose d’un kit de développement et une caméra IA (Intelligence Artificielle). Le matériel à disposition comprend plus précisément : une caméra IA M5Stack, une deuxième caméra ESP-EYE DevKit et un kit de développement M5Stack.

L’objectif du projet est donc de développer un système de reconnaissance faciale détectant la présence d’un masque sur l’utilisateur, tout cela grâce au machine learning. Le projet avait comme contrainte une liste de matériel fournie par le Client. La documentation de l’avancement du projet, de nos difficultés et de la prise en main du matériel doit permettre à l’école d’ajuster son UE.

L’équipe sur le projet est composée de 4 étudiants de FISE A1 : Ella FERNANDEZ, Eliott GODEFROY, Ralph AYOUB et Thaïs ARCHAUD. Celle-ci a été guidée et encadrée par Sylvie Kerouedan.

1. Matériel

• M5stack

Le kit de développement M5Stack est basé sur un afficheur couleur 2″ IPS associé à un ESP32 avec interface Bluetooth et WiFi.  Il comporte une mémoire FLASH de 16 MB accessible en SPI, un mini haut-parleur, 3 boutons-poussoirs.​ Il inclut également une batterie LiPo rechargeable via le port USB Type C (cordon inclus). L’arrière du boîtier comporte 4 aimants permettant le placement du module M5 sur n’importe quelle surface métallique.

• UnitV

La caméra IA UnitV K210 de M5Stack est alimentée par Kendryte K210, un système sur puce (SoC) edge computing avec processeur RISC-V 64 bits double cœur et processeur de réseau neuronal avancé. La caméra IA UnitV prend en charge diverses capacités d’identification par vision (par exemple, acquisition en temps réel de la taille, du type et des coordonnées de la cible détectée).

Elle prend en charge MicroPython, ce qui rend le code des utilisateurs plus concis lors de l’utilisation du UnitV pour la programmation.

• ESP-EYE DevKit

La caméra ESP-EYE DevKit est un module IoT ESP32-CAM d’AI Thinker basé sur un ESP32 proposant une interface WiFi associée à une caméra miniature. L’ESP32 permet d’accéder au flux vidéo de la caméra via un réseau WiFi local ou internet et est programmable grâce à l’IDE Arduino. Un convertisseur USB-série est nécessaire pour la programmation. Le module est accompagné par des connecteurs mâles soudés permettant d’enficher la carte dans une plaque de montage rapide.

1. Réalisation

• Code

Pour construire notre algorithme, nous devons nous baser sur un modèle. Ce modèle sera basé sur un “Convolutional Neural Network”. Un CNN est un réseau de neurones : un algorithme utilisé pour reconnaître des modèles dans les données. Les réseaux de neurones, en général, sont composés d’un ensemble de neurones organisés en calques, chacun ayant ses propres poids et biais apprenables. Cet objet se rapproche de l’unité d’enseignement Pyrat vu en première année, qui utilisait des poids dans ses graphs.

Nous avions besoin d’un dataset afin d’adapter les données dans un modèle de réseau de neurones.

Dans le dataset, nous avons utilisé 200 éléments dans test, et à peu près 1200 éléments pour entraîner le système. Pour avoir encore plus d’images à traiter, nous utilisons une méthode qui va effectuer un nombre de transformations sur les images existantes pour augmenter la taille du dataset. 

Pour tester le modèle, il suffit d’avoir la caméra d’un ordinateur.

Nous lisons la vidéo en temps réel. On effectue plusieurs opérations sur l’image en en temps réel pour pouvoir l’analyser. Tout d’abord, nous détectons les visages présents sur la vidéo, puis pour chaque visage présent, nous testons le modèle entraîné. Par souci esthétique, nous créons un rectangle qui s’affiche autour du visage, rouge si la personne n’a pas de masque, vert sinon. On affiche aussi l’intervalle de confiance si un masque est reconnu. 

• Validation

En reprenant les fonctionnalités et contraintes à satisfaire présentées dans le cahier des charges, nous remplissons pour le moment partiellement la demande. En effet, la partie technique visant à créer un algorithme de détection du masque est réalisée, nous savons également comment améliorer cet algorithme. Cependant, nous sommes encore en cours de réalisation pour la partie contrainte matérielle. Nous pourrons aussi faire part au client de la possibilité de travailler sur le projet sans le matériel.

1. Protocole d’utilisation

• Installation des librairies

La majorité des  librairies peuvent être installées en utilisant la commande pip install [nom de la librairie] sauf pour tensorflow.

Pour installer tensorflow sur jupyter il faut :

• aller dans le navigateur Anaconda (après avoir installé anaconda sur son ordinateur)
• aller dans les environnements
• mettre à jour les indexes
• chercher tensorflow dans la barre de recherche
• cliquer sur tensorflow et keras puis sur appliquer (cela peut prendre du temps)

En allant ensuite sur Jupyter Notebook, l’import de tensorflow et des modules associés n’affiche plus d’erreur et l’utilisation est alors possible.

• UnitV

Pour l’UnitV, il est utilisable seulement sur windows. Tout d’abord, il faut connecter la caméra à l’un des COM USB. Ensuite, on doit lancer l’IDE et connecter l’UnitV. Ne pas oublier de burn la caméra à chaque utilisation avec Easy Loader, disponible sur les docs de m5. Ensuite, on téléverse le modèle, construit précédemment dans la section 5.2.1.1, grâce à kflash_gui. Il faut bien sélectionner le Board M5StickV dans le Board Setting. De même, il faut vérifier que le baudrate est bien réglé (en général la valeur par défaut est la bonne).  Le port COM peut éventuellement changer suivant le branchement opéré. Le fichier du modèle doit être au format .kfpkg.

Ensuite, on implémente le code destiné à mettre en place le modèle de traitement d’image. Les librairies python utilisées sont les suivantes :

• yolo : méthode de détection d’objet,
• sensor, image et KPU : fonctions interne à UnitV, dont KPU qui fait référence au neural network hardware accelerator KPU.

Dès lors, la caméra va afficher l’image et encadrer les visages en indiquant la présence d’un masque ou non.

• Utilisation de l’ESP-EYE

La carte est déjà équipée d’un logiciel de reconnaissance faciale intégrée. Ainsi, pour prendre en main l’outil, on peut commencer par utiliser ce logiciel. Il est utilisable sur n’importe quel système d’exploitation.

Tout d’abord, il faut télécharger le logiciel  Arduino, si on ne l’a pas déjà. Ensuite, il faut régler l’onglet Outils comme sur la figure 1. Pour obtenir la carte “WEMOS LOLIN 32”, il suffit d’aller dans l’onglet “Boards manager…” puis de télécharger le kit lié à l’ESP-32.

Ensuite, il faut ouvrir un terminal dans Arduino, tout en connectant la carte au bon port USB. Pour vérifier quel port USB est utilisé par la carte, on peut utiliser des commandes dans le terminal de l’ordinateur pour le mac, de même pour les autres systèmes d’exploitation.

Normalement, en cliquant sur le bouton BOOT présent sur la carte, le terminal affiche ce message:

[0;32mI (10527) esp-eye: Please say ‘Hi LeXin’ to the board[0m

[0;32mI (10527) esp-eye: Version 1.0.0[0m

Ainsi, il faut dire “hi lexin” (en prononçant le x  comme en chinois, donc “ch”) pour que la carte se lance. Le LED va donc normalement commencer à clignoter en rouge et le terminal va afficher:

 hilexin DETECTED.

La carte va lancer son propre stream wifi, ainsi il faut s’y connecter dans ses paramètres wifi. Pour y avoir accès, il faut se connecter à ce lien: 

http:/192.168.4.1/face_stream

Pour enregistrer un visage, on peut s’appuyer sur la notice d’utilisation dans la boîte. Il faut appuyer sur un bouton sur le coté gauche de la carte.

Quand un visage a été enregistré, son numéro s’affiche en plus d’un “Hello ID”. Si un visage n’est pas reconnu, un “WHO ?” s’affiche en rouge.

1. Perspectives et pistes d’amélioration

Le programme n’est pas très fonctionnel lorsque la personne n’est pas bien éclairée, ou si la personne n’a pas la peau claire. Ainsi, ce problème peut facilement être résolu en ajoutant plus de personnes différentes dans le dataset lors de l’entraînement du modèle. De plus, le modèle n’ayant été entraîné qu’avec des images de masque bleu, il ne marche ainsi qu’avec ceux-ci. On peut aussi résoudre ce problème en travaillant en profondeur sur le dataset.

De plus, nous n’avons que deux classes: avec et sans masque. Cependant, un masque peut être mis d’une mauvaise façon: avec le nez ou le menton qui dépasse par exemple. Ceci peut-être facilement réglé en créant de nouvelles classes et en téléchargeant de nouvelles photos.

Avec cette première mise en place du logiciel, la modification du code est ensuite très facile et peut facilement être adaptée à d’autres projets (reconnaissance des humeurs par exemple).

Le projet pourra donc servir à créer une UE de premiers pas dans le machine learning. A l’aide des documents techniques que nous avons et allons réaliser dans le cadre du projet, les étudiants pourront apprendre les différents moyens de faire des algorithmes de reconnaissance faciale et les adapter à un problème donné (et non pas seulement la détection du masque).

Création d’un capteur de Co2 personnalisé

Envoyé par r21gaude le 27 Juin 2022 dans À la une, Blog, Portfolio, Projets | 0 commentaire

Depuis l’arrivée du COVID-19, la préoccupation à propos du taux de CO2 dans l’air a augmenté. En particulier pour les espaces clos où l’air est moins souvent renouvelé. 

En effet, si celui-ci ne l’est pas, cela signifie que des particules potentiellement infectées restent plus longtemps en suspension dans l’air et que leur transmission est favorisée. Une concentration élevée en CO2 dans une pièce est caractéristique d’un air qui est peu renouvelé : lorsqu’elle est supérieure à 1000 ppm, elle est uniquement produite par la respiration des personnes qui s’y trouvent. D’où le rapport entre concentration en CO2 et transmission du COVID-19. Ainsi, pour limiter la propagation de la pandémie, de plus en plus d’écoles, d’universités et de collectivités se munissent de capteurs de CO2 qui leur permettent de détecter un taux de CO2 trop élevé dans une pièce et de savoir quand l’aérer.

I – Réalisation du capteur de Co2

Matériel nécessaire

• Batterie 9V
• Interrupteur (Optionnel)
• Carte Arduino UNO
• Capteur de Co2
• Breadboard
• 3 Leds (RGB)
• Module de carte SD
• Fils

Étape 1 : Câblage

Voici ci-dessus un schéma du câblage dans son ensemble.

Si vous décidez d’utiliser un interrupteur, voici à quoi devrait ressembler votre montage après soudure.

Étape 2 : Programmation

Il vous faudra importer la bibliothèque du capteur SCD30 dans Arduino.

Puis réaliser un code proche de celui présent sur ce lien gitlab : https://gitlab.imt-atlantique.fr/clanglai/codev-co2-2022 sous le nom SCD-30-6-JUIN-2.

En adaptant les broches à votre branchement.

Étape 3 : Boîtier en 3D

Désormais, il faut créer le boîtier contenant notre capteur ! Voici en photo les différentes pièces à réaliser pour avoir un résultat final proche de celui dans l’introduction.

On laisse un espace dans la base de l’objet pour y glisser l’interrupteur. De plus, le capteur doit pouvoir “respirer”, c’est-à-dire qu’il doit être en contact avec l’air libre. Donc on a intégré une aération, pour faire circuler l’air grâce à 3 bandes horizontales en haut de la base. Les éléments dans la base doivent être fixes et ne pas se déplacer quand on transporte le capteur. C’est pourquoi nous avons fait un support pour la pile et la carte Arduino.

Dans la mine, nous intégrons les LEDs. Elles affichent les couleurs transmises par le capteur. Elles doivent être visibles par l’utilisateur à une distance d’au moins 3 mètres. C’est pourquoi nous voulons que cette partie soit transparente.

Tests et résultats

Voici quelques résultats de notre capteur en fonctionnement !

EcoCard– Etude terrain et personas

Envoyé par m20czern le 6 Jan 2022 dans TAF CoOC | 0 commentaire

Dans le cadre de notre projet, nous avons décidé de nous concentrer sur la problématique de surconsommation d’énergie en entreprise. Nous présentons dans ce document le déroulement de notre étude de terrain ainsi que les informations recueillies lors de chaque entretien. 

Suite à notre état de l’art, nous avons pu formuler différentes hypothèses quant au projet et nous avons donc ciblé plusieurs profils intéressants à rencontrer pour confirmer nos hypothèses. Nous avons tout d’abord rencontré un élève ayant réalisé un stage visant à réduire la consommation d’énergie en entreprise. Nous avons également rencontré deux patrons : le premier était PDG d’une start-up. Le second était un notaire co-président de Planet’RSE, il était donc parfaitement concerné par notre problématique. Finalement, nous avons rencontré M. Jean, un employé chez Orange. 

Partie 1 : Synthèse de l’enquête terrain 

• Entretien avec M. élève : un stagiaire en RSE

La première Rencontre était avec M. Élève, élève à IMT Atlantique, qui avait effectué un stage de première année en RSE et dont le but était de trouver une solution à la surconsommation d’énergie au niveau des postes de travail. Cette rencontre nous a permis de cibler le problème. 

En effet, lors de cette discussion, nous nous sommes rendus compte que la surconsommation d’énergie des ménages n’est jamais fixe : ce problème existe chez certains ménages mais pas chez tous. A l’inverse, M. Élève nous a expliqué que la surconsommation d’énergie au sein des entreprises, notamment la surconsommation des appareils en veille, était un problème qui existait dans une entreprise dès lors que chaque salarié avait son poste de travail.

Lors de son stage, il a pu noter que les salariés n’avaient plus le réflexe d’éteindre leurs ordinateurs et encore plus leurs écrans lorsque ceux-ci ne sont pas utilisés. De plus, M. Élève nous a expliqué que, dans une entreprise, les frais d’énergie sont à la charge de l’entreprise. 

Par conséquent, nous avons choisi de cibler le problème de la surconsommation d’énergie sur celle des entreprises, et spécialement sur la consommation d’énergie des postes de travail lorsque ceux-ci ne sont pas utilisés.

Nous avons également pu échanger sur les solutions possibles pour résoudre le problème posé. M. Élève, lors de son stage, avait imaginé une solution avec des multiprises maître-esclave : lorsque l’alimentation est coupée sur une prise dite « maître », cela coupe l’alimentation sur toutes les autres prises. En termes de coûts, M. Élève nous a expliqué que cela forçait à avoir une multiprise par poste, ce qui n’était pas forcément le cas pour tous. Cela présente donc une potentielle contrainte à prendre en compte. 

• Entretien avec M. Jean : un employé dans une grande entreprise

M.Jean est employé chez Orange.

Dans son entreprise, selon M.Jean, chaque salarié possède à son poste de travail au minimum un PC, deux écrans et une lampe. Il y a également une imprimante par dizaine de postes de travail.

De manière générale, il a confirmé que les systèmes mécaniques sont utiles pour éteindre des appareils comme des écrans mais le fait de couper l’alimentation peut endommager à terme les tours des PC ou les imprimantes.

Nous avons, une fois de plus, eu la chance d’échanger avec l’interviewé sur les solutions qui peuvent être envisagées pour notre problème. M. Jean nous a mentionné un système de prises intelligentes qui sont alimentées à des heures prévues. Même si elles peuvent également être alimentées manuellement, le fait d’instaurer des horaires fixes n’est pas pratique car certains salariés peuvent vouloir revenir à des horaires tardifs…

Il nous a également expliqué que les multiprises ou prises peuvent être reliées par des bridges (ou ponts) via Ethernet en utilisant des scripts Python. Chaque prise a son propre Id. Ce système marche par détection de voltage et peut par exemple attendre que l’écran se mette en veille pour couper complètement l’alimentation.

• Entretien avec M. Notaire : un patron d’entreprise de taille moyenne 

Nous avons interrogé un notaire associé de l’étude Strateia, co-président de Planet’RSE. Ce notaire était le patron d’une société d’une cinquantaine de personnes.

Planet’ RSE est une association dont le but est de promouvoir la responsabilité sociétale des entreprises en élaborant des critères de notation en matière de RSE. C’est pourquoi nous attendions de cette rencontre qu’elle nous éclaire sur l’engagement sociétal des entreprises, quelles entreprises étaient concernées par cet engagement et de quelle manière les entreprises étaient accompagnées. Nous voulions bien sûr savoir également si la problématique de surconsommation d’énergie était une problématique rencontrées par ces entreprises. 

De plus, Planet’RSE analyse les engagements de nombreuses entreprises, par conséquent, nous voulons en apprendre plus sur les différentes choses mises en place par celles-ci afin de réduire la consommation d’énergie

Ce notaire rencontrait également une problématique de quantités de données de plus en plus importantes à gérer avec la numérisation des actes notariés.

Dans un premier temps, nous avons interrogé M. Notaire sur les raisons de son implication chez Planet’RSE. Il a expliqué que, comme la plupart des entreprises au sein de cette association, le but était de s’interroger, de se sensibiliser à la problématique de la responsabilité sociétale et de progresser. L’objectif était d’obtenir des résultats en essayant d’éduquer, d’impliquer l’ensemble des collaborateurs concernés et d’y trouver un intérêt pour l’entreprise comme pour l’environnement. 

Une information très intéressante est que, selon M. Notaire, le plus important est que l’entreprise soit en bonne santé économique, car l’intégration d’argent est alors possible dans des projets dédiés à l’environnement. Peu d’entreprises seraient prêtes à investir du temps et de l’argent s’ils pensent que cela peut les mettre en péril, même pour une cause environnementale. La taille de l’entreprise en revanche ne semble pas avoir un réel impact sur la transition écologique qui s’effectue en son sein selon notre interviewé. 

M.Notaire nous a également confirmé que la problématique de surconsommation d’énergie concernait beaucoup d’entreprises. Il a expliqué que chez Planet’RSE, il n’y avait pas de petite économie, mais qu’il était important que la solution a un problème environnemental n’entraîne pas de trop grosse perte financière pour l’entreprise concernée. La question de coûts de l’objet connecté créé est donc une problématique importante à prendre en compte. Il est aussi intéressant de noter que l’une des premières questions posées lors de l’évocation de notre sujet était le potentiel danger que l’extinction d’un poste de travail pouvait représenter pour les serveurs. C’est donc un point important à prendre en compte lors de la réalisation de notre objet connecté. 

Nous avons également questionné l’interviewé sur l’organisation des postes de travail au sein de son entreprise. Il nous a expliqué qu’ en moyenne, il y avait 2 écrans, une centrale et parfois une imprimante par poste, ce qui revenait à environ 200 objets électroniques dans son entreprise. De plus, des postes fixes et des postes de co-working étaient présents dans l’entreprise. 

Finalement, nous avons évoqué le télétravail au sein de l’entreprise. Les employés ont 2 jours de télétravail par semaine. De plus, le télétravail a un gros impact sur la consommation d’énergie car lorsque les employés travaillaient en télétravail, le système de sécurité de l’entreprise imposait qu’un écran reste allumé au sein de l’entreprise. Ceci multiplie donc le nombre d’appareils électroniques allumés. C’est une hypothèse que nous n’avions pas considéré. 

Pour conclure sur cet entretien, M. Notaire était assez convaincu par notre objet connecté et nous a dit qu’il était possible de revenir vers lui une fois l’objet finalisé. Il semble donc que nos hypothèses soient correctes dans l’ensemble et que notre cible soit cohérente.

• Entretien avec Mme. Claire : une patronne d’une petite entreprise

Nous avons rencontré la patronne d’une start-up d’une dizaine d’employés. Nous avons pu l’interroger sur les économies d’énergie dans les locaux de son entreprise.

Tout d’abord l’entreprise qu’elle dirige est une entreprise spécialisée dans le numérique, elle permet de centraliser les actions lors de la construction des bâtiments. Le but est de minimiser les ressources mis en œuvre pour la communication entre tous les acteurs, ceci permettant de gagner du temps et de l’énergie. De leur point de vue, la RSE fait partie de leur projet et c’est donc un facteur qui leur tient à cœur.  

Sachant qu’elle dirige une start-up, elle nous explique qu’elle ne peut pas vraiment parler de transition écologique au sein de l’entreprise et elle affirme que la taille de l’entreprise joue dans l’impact de la transition écologique. La transition écologique dans une firme multinationale et dans une start up est différente et les résultats aussi. 

Elle considère que ce sont les serveurs qui représentent la plus grande source de consommation d’énergie mais elle explique que cette source ne peut pas être classée comme une source d’énergie inutilement utilisée. De par la petite taille de son entreprise, elle explique que les gestes tels que éteindre son ordinateur en partant, éteindre les écrans, le chauffage, la lumière sont des gestes faciles à appliquer et que par conscience écologique ils étaient déjà mis en place dans l’entreprise. 

Dans l’entreprise, chaque collaborateur a son poste de travail avec une tour et deux écrans. Certains développeurs ont également leur ordinateur portable. Ces postes sont alimentés par une multiprise unique qui alimente aussi éventuellement un téléphone ou le pc portable. La consommation des équipements est de la responsabilité de tous les collaborateurs. Sachant qu’il n’y a pas de télétravail au sein de l’entreprise, les questions sur la surconsommation qu’implique le télétravail n’ont pas pu être réellement traité mais elle explique qu’elle imagine que l’impact énergétique grandit avec le télétravail car plus de données doivent être échangé.

Si jamais elle pouvait trouver une solution à notre problème, elle imaginerait un bouton permettant de fermer toutes les prises simultanément. Elle a donc été naturellement enthousiaste lorsqu’on lui a décrit ce que l’on imaginait pour notre solution. Cependant, elle précise qu’au niveau de sa start-up cette solution représente plus un gain de temps à l’arrivée et au départ de l’employé. En effet, au vue des mesures déjà en place au sein de l’entreprise, elle ne voit pas de réel ajout de la part de notre solution d’un point de vue écologique.

Lorsqu’on analyse cette interview par rapport aux autres, on remarque une divergence d’opinion sur la transition écologique par rapport à la taille de l’entreprise. En effet M.Notaire considère que la taille de l’entreprise ne joue pas sur la transition écologique tandis que Mme.Claire considère que les multinationales ont une plus grande responsabilité en terme écologique car leur impact, qu’il soit positif ou négatif, est toujours plus grand que celui au sein d’une start-up par exemple. Notre solution fonctionne cependant dans les deux cas. En effet, dans le cas d’une start-up, notre impact serait faible mais elle permettrait d’accompagner et de faciliter la transition écologique lorsque l’entreprise grandit. Ensuite, notre solution permet de faire changer efficacement les habitudes des employés d’une grande entreprise.

Partie 2 : Personas

• Patron d’une entreprise

Le premier profil d’utilisateur de notre système est Jean-Pierre, le patron d’une entreprise. Nous avons également décidé de nous concentrer sur un patron ayant une conscience écologique éveillée, rendant la problématique de l’économie d’énergie plus importante pour son entreprise. 

Selon lui, la taille de l’entreprise ne joue en rien sur la présence d’une conscience écologique dans les entreprises mais il est conscient que l’ampleur des impacts diffère avec la taille de l’entreprise. La taille de son entreprise a été choisie au hasard sans être dans les extrêmes car on considère que toute les entreprise pourrait utiliser notre solution.

De plus, il est assez évident que si Jean-Pierre agit par conscience écologique, il est au courant que la transition énergétique reste bénéfique à la vision que son entreprise renvoie, d’où son côté stratège. 

Nous trouvons également intéressant et assez vraisemblable que ce patron ai suivi des études d’ingénieurs, le rendant plus apte à comprendre la solution qui peut être trouvée pour régler son problème et à s’y intéresser. 

• Ingénieur logiciel d’une entreprise

Le deuxième profil d’utilisateur de notre système est Pierre. Il est développeur logiciel au sein d’une entreprise. Nous avons estimé qu’un tel profil était intéressant car Pierre passe par conséquent la plus grande partie de son temps sur un ordinateur et est donc directement concerné par le problème de la surconsommation d’énergie des outils numériques. Nous avons légèrement caricaturé le personnage, en le décrivant comme un loup solitaire.

Pierre est depuis 3 ans dans l’entreprise. Cela signifie qu’il est déjà bien installé et qu’ au vue de son jeune âge, c’est sûrement la première fois qu’il est aussi longtemps au sein de la même entreprise.  Ceci permet de justifier le caractère peu flexible du jeune développeur logiciel : il a pris ses marques dans la boite et refuse que celles-ci soient bousculées. 

Il aimerait en revanche gagner en efficacité. Le fait que Pierre présente ces deux traits de caractère (peu flexible et en recherche d’efficacité) permet d’imposer les contraintes suivantes au système proposé : le système ne doit pas compromettre l’efficacité des employés et ne doit pas (ou quasiment pas) déranger leurs habitudes. 

De plus, le télétravail qui doit pouvoir continuer pour Pierre est une contrainte supplémentaire : le système conçu ne doit pas imposer nécessairement du présentiel. C’est, comme nous l’avons vu précédemment dans l’étude de terrain, une contrainte importante à prendre en compte : le système devra être adapté au télétravail qui peut entraîner une augmentation de la surconsommation d’énergie.  

A cela, nous avons ajouté la conscience écologique de Pierre peu développée, qui rajoute une difficulté à l’instauration d’une solution dans son entreprise. 

Finalement, le profil du développeur logiciel peut être vu comme le “pire cas possible rencontré”, permettant de soulever toutes les contraintes potentiellement rencontrées lors de l’élaboration de notre produit.

CONCLUSION

Finalement, l’étude de terrain a permis de confirmer de nombreuses hypothèses formulées précédemment. Tout d’abord, la problématique de surconsommation d’énergie en entreprise est une problématique avérée, et intéresse particulièrement les entreprises en pleine transition énergétique. De plus, des solutions ont déjà commencé à être imaginées pour pallier au problème. 

Nous avons également écarté certaines hypothèses : nous pensions que nous concentrer sur une entreprise centrée numérique était un critère pour la cible de notre projet. Nous avons en fait réalisé que le problème de la surconsommation d’énergie se posait dans toutes les entreprises en transition énergétique et utilisant des outils numériques. 

Nous avons également pu obtenir, par ces entretiens, quelques directions possibles de solutions. 

LEGOLIRE : Solution Technique

Envoyé par w21mhimd le 21 Déc 2021 dans TAF CoOC | 0 commentaire

Auteur

Koffi Judicaël AMANI, Rose LAPREVOTE, Wael MHIMDI et Souleymane OUEDRAOGO

Contexte

Dans le contexte de la thématique d’approfondissement  CoOC ( Conception d’Objets Communicants), notre équipe s’est intéressée au problème de l’apprentissage de la lecture en CP. Nous nous sommes intéressés aux enfants ayant de grosses difficultés à apprendre à lire, et qui peu à peu perdent leur motivation suite à leurs échecs. La méthode d’enseignement ne leur correspondant manifestement pas, nous avons cherché un nouvel exercice, pouvant être réalisé en autonomie (lorsque le reste de la classe réalise des exercices standards), adapté et adaptable pour l’enfant ciblé. Cet exercice  devait en outre respecter la méthode syllabique aujourd’hui utilisée en France. Le processus de lecture a deux phases majeures : le décodage (des phonèmes, i.e. trouver chaque son à chaque lettre ou association de lettres) et la compréhension (comprendre le mot décodé) .Nous avons donc eu l’idée de “LEGOLIRE”, partant du principe qu’on pouvait associer la lecture à un jeu de construction, et inversant les deux phases. En effet, d’abord l’élève voit une image du mot qu’il devra “lire”, commence par trouver le mot correspondant, puis le “construit” à l’aide de cubes sur lesquels s’affichent différentes syllabes, dont celles du mot recherché.

L’article suivant a pour but d’expliquer comment pouvoir recréer cet objet étape par étape.

Réalisation :

Liste de matériel pour 2 cubes et une base :

contreplaqué (3mm d’épaisseur)

4 afficheurs RB-TFT1.8 (https://www.gotronic.fr/art-ecran-1-8-rb-tft1-8-26567.htm)

module Bluetooth (hc-05)

2 Arduinos Nano

1 ESP32 (Espressif Wroom 32)

4 tags RFID

2 lecteurs RFID

plaques d’essais et câbles

20 résistances 1kohm (5 par afficheur)

1 bouton push

3 batteries 9V 500mA ?

2 interrupteurs

Plans cubes contreplaqué et plans base :

Les images au format PNG du plan de la base et des cubes sont ci-dessous. Attention, il faut modifier les tailles du bouton et des interrupteurs selon votre matériel. Les emplacements sur les plans sont indiqués par des flèches vertes.

Vous pouvez récupérer ici les fichiers au format SVG

Le matériau utilisé est du contreplaqué de 3 mm d’épaisseur.

Une fois les pièces des cubes et de la base prêtes, vous pouvez directement coller 3/4 faces par cubes ensembles, puis laisser les autres de côté pour pouvoir faire rentrer les composant électroniques et les tags RFID dans les cubes.

De même pour la base, vous pouvez commencer par coller toutes les pièces de la boîte sauf le fond. Les 5 dernières petites pièces sont des bordures à emboîter dans les petites encoches sur le haut de la base. Elles servent à délimiter les emplacements des cubes.

Plan de la base :

Plan pour un cube :

Code arduino :

Les codes à téléverser dans l’ESP32 de la base et les Arduino nano des cubes sont ici .

Le code de la base se nomme “BASE.ino”, et celui d’un cube “CUBE.ino”.

Vous aurez donc besoin de l’IDE Arduino, dont le guide d’installation est sur le lien suivant : https://www.arduino.cc/en/Guide

Les bibliothèques à installer sont les suivantes :

• TFT & SPI pour l’afiichage
• BluetoothSerial pour la communication bluetooth
• MFRC522 pour les lecteurs RFID

Pour installer une bibliothèque sur l’IDE Arduino, c’est toujours le même processus : il faut aller dans “Croquis —> Inclure une bibliothèque —> Gérer les bibliothèques”, le gestionnaire de bibliothèques va s’ouvrir, puis il faut taper le nom de la bibliothèque dans la barre de recherche, et enfin installer (ou non si elle l’est déjà) la bibliothèque voulue, comme par exemple pour la bibliothèque TFT :

Pour téléverser le code sur l’ESP32 (la base), il faut d’abord aller dans Outils —> type de carte —>ESP32 Arduino —> ESP32 Dev Module puis dans Outils —> port —> sélectionner le bon port (le seul affiché si vous n’avez que l’ESP32 de branché)

Attention dans le code de la base, il y a des modifications à faire, car il faut retrouver les identifiants des ‘ tags RFID utilisés, puis les mettre à cet endroit du code :

Pour récupérer les identifiants des tags RFID que vous utilisez, une manière de faire est : d’exécuter uniquement la fonction readd() dans la fonction void loop()

Pour téléverser le code sur un Arduino Nano (un cube), il faut d’abord aller dans Outils —> type de carte —>Arduino AVR boards —> Arduino nano, puis dans Outils —> port —> sélectionner le bon port (le seul affiché si vous n’avez que l’Arduino nano de branché)

Electronique :

Dans un cube il y a les composants électroniques suivants :

• un Arduino Nano (qui va récupérer les informations envoyées par la base via Bluetooth, les traiter, et envoyer aux afficheurs les informations d’affichage en terme de syllabes et couleurs)
• 2 afficheurs (un qui affichera une syllabe correcte, l’autre une syllabe fausse)
• 10 résistances (5 par afficheur)
• 1 module Bluetooth (qui permet d’établir la connexion Bluetooth et donc de recevoir les informations transmises par la base)
• 1 interrupteur
• 1 batterie

Les branchements sont donc les suivants :

Attention, si vous décidez de téléverser les codes sur les Arduino Nano après avoir effectué les branchements, il faut débrancher les sorties “TX” et “RX” du module Bluetooth.

Dans une base il y a :

• 2 lecteurs RFID
• 1 ESP32
• 1 bouton push

Les branchements sont donc les suivants :

Intégration de l’électronique dans les cubes et dans la base :

Maintenant que les branchements sont faits et les codes téléversés, il faut associer les tags RFID aux afficheurs avant de les coller dans les cubes. Pour cela on lance un premier exercice, avec plusieurs mots, on pose 2 tags sur les lecteurs RFID, on appuie sur le bouton de validation, on voit sur le moniteur série de la base (sur l’IDE Arduino, le bouton tout en haut à droite en forme de loupe) quelles syllabes étaient associées aux tags, et on les associe aux écrans correspondant, puisqu’ils affichent chacun une syllabe. Puis on recommence, jusqu’à ce que chaque tag RFID soit associé à un afficheur. Puis on peut commencer à remplir les cubes.

Nous concernant, puisque notre objet n’est qu’un prototype, nous n’avons rien soudé, et pris des petites plaques d’essai qui rentraient dans les cubes. Nous avons commencé par fixer les interrupteurs avec de la colle (mais pas beaucoup, attention), et les afficheurs avec du scotch double face posé autour du trou laissé pour l’écran, volontairement un peu plus petits. Ensuite, nous avons fixé les tags RFID sur les faces opposées à leur afficheur associé avec du scotch. Puis nous avons fait rentrer le reste, en calant tout dans le cube (dans l’ordre suivant : module Bluetooth, plaque d’essai, batterie). Lors de cette opération, attention aux branchements !

Pour la base, c’était beaucoup plus simple, nous avons simplement fixé les lecteurs RFID aux bons emplacements avec du scotch, et laissé l’ESP32 au fond.

résultats

Cet article a montré comment fabriquer deux cubes et une base et comment les connecter ensembles pour afficher des syllabes. La vidéo montre comment les cubes et la base fonctionnent.

Mais pour l’exercice imaginé par LEGOLIRE, l’enfant commence par voir des images. Aussi, les images des mots que l’élève devra légolire sont à votre charge. Concernant la liste des mots, vous pouvez la changer (un mot ou plusieurs, ou en ajouter) dans le code à cet endroit en séparant les syllabes par une espace :

Vous trouver ci-dessous une vidéo démonstrative de LÉGOLIRE

Perspectives d’amélioration :

Beaucoup de points sont améliorables dans notre objet. Premièrement, il faudrait que nous finissions le logiciel permettant d’interagir avec une interface graphique plus simple et agréable d’utilisation que le moniteur série de l’IDE Arduino. Ce qui permettrait alors d’intégrer une batterie et un interrupteur (comme prévu sur les patrons du contreplaqué), et de ne plus avoir la base constamment reliée à un ordinateur par un câble, et aussi de ne plus avoir des images à préparer pour faire un exercice, puisque celle-ci seraient sur le logiciel, et défileraient automatiquement lorsqu’un mot est trouvé.

Une perspective d’amélioration intéressante serait d’avoir plus de cubes pour pouvoir faire des mots de plus de deux syllabes (3 cubes intéressants), impliquant une base plus grande et un léger changement des plans pour la base.

Et enfin, nous aimerions pouvoir rendre la difficulté d’un exercice adaptable : arrêter de donner les erreurs mais donner d’autres indications, comme par exemple allumer dans une autre couleur le premier cube ou donner le mot recherché à l’oral.

Transcripen – Présentation de la Solution Technique

Envoyé par l18badou le 21 Déc 2021 dans TAF CoOC | 0 commentaire

I/ Contexte

Dans le cadre de notre spécialisation en conception d’objets communicants (TAF CooC) dans notre formation à l’IMT Atlantique, nous avions pour objectif de créer de la valeur par les besoins actuels des entreprises et de l’industrie à l’aide d’objets communicants. En d’autres termes, nous devions réaliser un objet communicant qui réponde à un besoin utilisateur. 

Chacun des membres du groupe étant en lien quotidien avec des étudiants et / ou journalistes, nous avons relevé, lors de notre étude terrain, un problème récurrent chez ces deux types d’individus, qui sont confrontés au quotidien à de nombreuses conférences et de nombreux échanges oraux longs, voire fastidieux, et pendant lesquels les personnes en question ne peuvent pas être passives (nécessité de réflexion / compréhension / rebondir sur des questions, …) et prendre l’intégralité de l’oral en note. Nous avons donc décidé de répondre à la problématique suivante pendant ce projet : Comment permettre aux interlocuteurs d’un échange, à l’aide d’un objet connecté, de récupérer l’ensemble des informations véhiculées pendant ce-dernier ?

Après nos études terrains, nous avons imaginé, puis prototypé un stylo / micro connecté qui enregistre un oral lorsque l’utilisateur le décide (à l’aide d’un bouton) et envoie sur l’ordinateur de l’utilisateur, via une application, les audios enregistrés sur le stylo / micro sous format texte (transcrits). Grâce à cet objet, l’utilisateur peut totalement se concentrer pendant l’oral et n’a plus à prendre en note les informations véhiculées. Cette phase de prototypage de ce stylo / micro connecté s’est effectuée à l’aide d’une méthode agile (SCRUM) sur 3 semaines.

Dans cet article, nous allons aborder les détails de la phase de prototypage, afin de vous fournir une explication la plus précise possible de notre prototype (choix du matériel, schéma du montage, l’enregistrement audio, l’interface utilisateur, la transmission du fichier audio de la raspberry à l’interface, l’algorithme de transcription utilisé ainsi les résultats obtenus. Nous aborderons ensuite le résultat obtenu à la fin de ces 3 semaines. Enfin, nous aborderons les perspectives d’évolution de notre projet.

Le code (commenté précisément) pour l’ensemble du prototype est disponible sur le lien Github suivant : https://github.com/camillebrl/Transcripen. Vous trouverez également, dans ce Github, une documentation détaillée de l’ensemble des éléments à installer sur la raspberry, ses configurations, …

II/ Réalisation

A. Choix du matériel détaillés et schéma du montage final

• Le choix de la Raspberry pi vs Arduino : Alors qu’Arduino est un microcontrôleur qui ne peut exécuter que du code compilé, la Raspberry pi fonctionne aussi comme système autonome : si l’Arduino est la plus adaptée pour faire de la gestion de LEDs, de capteurs simples (température, luminosité, distance…), elle ne l’est pas pour la gestion de multimédias tels que les audios notamment. La Raspberry Pi est plus adaptée pour cela. C’est pourquoi nous avons, pour ce projet qui consiste en un enregistrement et une gestion de fichiers audios, opté pour une Raspberry Pi.
• Choix du type de Raspberry Pi : la Raspberry Pi Zero est la plus petite sur le marché aujourd’hui (à l’exception de la Raspberry Pi Pico qui n’a pas d’entrée de carte mémoire intégré, ni de port usb, donc trop pas adaptée à notre projet). Puisque nous avions des contraintes de taille du matériel, afin d’intégrer ce-dernier dans un stylo, nous avons opté pour la carte la plus petite possible, d’où notre choix de la Raspberry Pi Zero. Par ailleurs, il existe 2 types de Raspberry Pi Zero : la W et la simple. Puisque nous avions besoin de Wifi pour notre projet (envoie des fichiers audio à l’application), nous avons opté pour la Raspberry Pi Zero W qui est dotée de la wifi, contrairement à la Raspberry Pi Zero.

• La carte SD: nous avons opté pour une carte SD de 32Gb pour la Raspberry. Effectivement, celle-ci est indispensable à la Raspberry: non seulement elle nous permet de stocker les fichiers audios des enregistrements, mais elle est surtout indispensable à la Raspberry (c’est sur cette-dernière que se trouve l’OS de la Raspberry et l’ensemble de ses configurations)
• Breadboard + fils + bouton poussoir + résistance

• Le microphone utilisé est un Microphone Jack 3,5mm nous y avons intégré un convertisseur analogique numérique a la suite de la prise jack, en effet le microphone produit un signal analogique, hors la carte Raspberry ne traite que les signaux numériques. L’ensemble des composants est détaillé ci dessous :
• Microphone Jack, 3,5 cm. 3 Poles. 

• Convertisseur analogique / numérique : 15 cm de câble. Fait la conversion analogique / numérique, intégré une carte son 

• Adaptateur câble micro USB / USB mâle: 

Entrée: 5V | Sortie: 5 V, câble de 12cm.

Le schéma électronique final de notre objet connecté est présenté ci-dessous:

Par ailleurs, nous avons intégré ces composants dans notre objet final, qui prenait la forme d’un stylo. Ci-dessous les images de notre objet final:

Pour le construire, nous avons créé un prototype sur Tinkercad présenté ci-dessous:

B. L’enregistrement audio sur la raspberry

1. Le montage du dispositif d’enregistrement

Pour enregistrer des audios à l’aide de notre micro branché en micro-usb à notre Raspberry Pi Zero W, nous avons utilisé 2 bibliothèques python, indispensables à cet égard: Pyaudio et Pydub. PyAudio fournit des liaisons Python pour PortAudio, la bibliothèque de référence qui gère les entrée/sortie usb d’audio sur toutes les plateformes (dont la Raspberry). Quant à Pydub, elle permet de manipuler un fichier audio simplement (ouverture de l’audio, augmentation / diminution du volume de l’audio, segmentation de l’audio, calcul de la durée de l’audio, et toute autre manipulation possible sur un audio. La librairie est en open-source sur https://github.com/jiaaro/pydub). Pour utiliser pydub, il faut installer ffmpeg/avlib.

Pour effectuer l’enregistrement de l’audio, il est important de prendre en compte plusieurs éléments :

• La détection du port sur lequel est branché le micro à la Raspberry : Afin d’identifier ce port, nous avons utilisé la librairie Pyaudio, qui nous a permis, grâce à sa fonction get_device_info_by_index, de trouver le port correspondant au micro.
• Le nombre d’images collectées par seconde par défaut par le micro : Une fois que nous avons identifié l’indice du port correspondant au micro, nous avons pu afficher son “defaultSampleRate”, qui était, dans notre cas, de 48000Hz. 
• Le fait que Pyaudio découpe les données en CHUNKS (trames), au lieu d’avoir une quantité continue d’audio, afin de limiter la puissance de traitement requise (RAM), puisque la Raspberry a une RAM assez faible (512M pour notre Raspberry Pi Zero W). Dès lors, nous devions définir le nombre de CHUNKS (trames) dans lesquelles nos signaux seront divisés (il s’agit d’une puissance de 2). 
• Une fois que nous avons identifié ces paramètres, nous avons pu instancier un stream (ligne 28 de final_algo.py du Github) qui nous permet ensuite, lorsqu’on appelle la fonction stream.read, d’enregistrer l’audio (ligne 52 du Github).

2. Le montage du dispositif du bouton pour lancer l’enregistrement

L’objectif du bouton est de permettre à l’utilisateur de choisir quand il veut enregistrer et quand il veut d’arrêter d’enregistrer. Un bouton se connecte à une Raspberry Pi à l’aide de ses ports GPIO. Les ports GPIO sont des ports physiques se présentant généralement sous forme de picots métalliques carrés qui permettent de transmettre un signal électrique. Un port GPIO transmet un signal relativement binaire (pas de courant ou du courant). Dans le cas de notre Raspberry Pi Zero W, les ports GPIO travaillent en 3.3V et environ 20 mA. En d’autres termes, les ports GPIO du Raspberry PI permettent d’envoyer du courant (et donc, des informations) à nos composants (les sorties, ici, la Led (que l’on verra ci-dessous)) et récupérer du courant (et des informations) de ceux-ci (les entrées, ici le bouton poussoir). Les ports GPIO de la Raspberry se présentent comme ci contre.

Ils sont numérotés de 1 à 40, en partant du haut à gauche quand vous tenez la Raspberry pi ports GPIO à droite. Cette numérotation de 1 à 40 est le mode de numérotation dit « Board ». Un autre mode de numérotation existe, qui repose sur l’adressage processeur, appelé mode « BCM » (on prend en compte les chiffres après “GPIO” comme “GPIO 25”. On remarque qu’il existe des ports de différents types : des ports de puissance (5v et 3.3v), des ports généraux (GPIO), des ports PCM (Pulse-code Modulation) permettant une représentation numérique de l’analogique échantillonné (forme de sortie audio numérique), des ports UART (prend des octets de données et transmet les bits individuels de manière séquentielle), des ports I2C1 (permettent une communication bifilaire avec une variété de capteurs et de dispositifs externes), et des ports SPI (relient plusieurs dispositifs compatibles à un seul ensemble de broches en leur attribuant des broches de sélection de puce différentes). Nous avons décidé d’utiliser les ports généraux de la Raspberry pour notre montage (soit les ports GPIO), ainsi que le port 3.3v pour le bouton poussoir, par simplicité. 

Pour utiliser les ports GPIO de la raspberry, il faut utiliser une librarie python. Il en existe plusieurs, mais la plus connue (celle pour laquelle il y a le plus d’exemple sur internet) est Rpi.GPIO. Ainsi, nous avons utilisé la librairie RPi.GPIO pour interagir avec notre montage via notre code Python. Nous devions ainsi indiquer au programme quel était le port de récupération du courant (input) et le port de sortie (envoi du courant). Pour se faire, nous avons utilisé la fonction setup, avec comme attributs GPIO.IN et GPIO.OUT pour indiquer respectivement le port d’entrée et de sortie de courant. 

Ici, nous devions prendre en compte le fait qu’une entrée GPIO flotte entre 0 et 1 (fonction input). Par défaut dans la librairie, elle ne peut prendre que 1 ou 0 comme valeurs (True ou False). Aussi, lorsque l’utilisateur appuie sur le bouton, il y a plusieurs entrées qui arrivent dans la seconde qui suit (entre 0 et 1), qui sont arrondies à 1. Afin de ne pas confondre une entrée à 1 correspondant à l’appui sur le bouton par l’utilisateur et une entrée à 1 correspondant à un courant suivant l’appui sur le bouton, nous avons décidé qu’on considérait que l’entrée ne correspondait à un appui sur le bouton que s’il n’y avait pas d’autre courant reçu dans les 2 secondes précédant la réception du courant. Ainsi, si l’utilisateur appuie sur le bouton 2x en 2 secondes, voire plus, on ne considère pas que ce-dernier a appuyé.

Dès lors, il était important, particulièrement suite à ce que nous venons d’expliquer ci-dessus, de prévenir l’utilisateur lorsqu’il enregistre et lorsqu’il a fini d’enregistrer, c’est-à-dire si son appui sur le bouton a bien été pris en compte ou non. C’est pourquoi nous avons mis en place une Led, qui s’allume lorsque l’utilisateur appuie sur le bouton, et s’éteint lorsque l’on considère que l’utilisateur a rappuyé dessus. En d’autres termes, la Led prévient l’utilisateur quand l’enregistrement débute (quand on le lance) et quand l’enregistrement se termine (quand on l’arrête). 

3. Le montage du dispositif de la led pour indiquer à l’utilisateur quand l’enregistrement est lancé

De la même manière que le bouton, la Led est branchée aux ports GPIO de la Raspberry Pi Zero W. Cependant, contrairement au bouton poussoir décrit ci-dessus, nous ne récupérons pas le courant (l’information) de la Led, mais on lui envoie du courant (de l’information) pour l’allumer ou l’éteindre. Alors que l’on utilisait la fonction input pour récupérer les informations issues du bouton poussoir ci-dessus, nous voulons envoyer des informations à la Led. Pour ce faire, nous utilisons la fonction output. Il suffit ensuite de mettre le pin en question (celui qui est lié à la Led) à True lorsqu’on veut l’allumer, et à False lorsqu’on veut l’éteindre. Ainsi, on allume ce-dernier lorsque l’on considère que le bouton poussoir a été appuyé, et on l’éteint lorsqu’on considère qu’il a été de nouveau allumé (à l’aide d’une variable isPressed que l’on a défini en amont, à qui l’on attribue l’opposé (not isPressed) dès lors que l’on considère que le bouton a été appuyé.

4. Explication détaillée du fonctionnement du montage final

Les parties 1, 2 et 3 ont ensuite été liées. En d’autres termes, lorsque l’utilisateur appuie sur le bouton, non seulement la Led s’allume, mais également l’enregistrement se lance. Lorsqu’il rappuie sur le bouton, la Led s’éteint et l’enregistrement s’arrête. Si la Led est allumé, c’est que l’enregistrement est nécessairement en route. Si cette-dernière n’est pas allumée, c’est que l’enregistrement ne l’est pas. 

C. L’application

Pour l’application, le code est disponible sur le dépôt suivant: https://github.com/yac-ai/django_transcripen.git .Pour un développement rapide, le framework Django est utilisé, basé sur le langage de programmation Python. La raison de ce choix est dû au fait que nous avions déjà de l’expérience dessus. Et, vu qu’il fallait aller très vite, ce choix était plus sûr. Pour ce projet, on a créé un environnement virtuel; son avantage d’un environnement virtuel est l’isolation des environnements de développement avec des librairies installées différentes pour chaque projet. Ainsi, nous pouvons installer une certaine version de Python, différente de celle installée dans l’ordinateur et pour nos potentiels autres objets, et les librairies souhaitées. La création et l’activation se font par les commandes suivantes:

python -m venv /home/yacine/.virtualens/djangodev

#yacine étant le nom de votre utilisateur #cmd de création 

source ~ /.virtualenvs/djangodev/bin/activate #cmd d’activation

 Le framework possède un serveur Apache intégré, en phase de développement. Et l’avantage du serveur Apache est la possibilité de visualiser le fonctionnement du site web. Aussi, à la récupération du dépôt git, il faudra se positionner dans le répertoire transcripen_project et lancez la commande suivante qui va activer le serveur apache:

python manage.py runserver

Sommairement, le projet comprend ainsi, dans le dossier transcripen_project/transcripen, les vues qui permettent de traiter les données de chaque page( dans le fichier views.py), les urls qui sont reliés à ces vues (dans le fichier urls.py) et les templates des pages qui contiennent le code html de ces pages(dans le dossier templates).

Pour avoir plus d’informations sur le framework et son fonctionnement, vous pouvez voir référer au lien suivant: https://docs.djangoproject.com/fr/4.0/ . La documentation est très bien faite et facile à comprendre.

D. La transmission des fichiers audio de la raspberry à l’application

Notre projet Transcripen consiste en un stylo enregistreur qui communique avec une application sur l’ordinateur pour que cette dernière transcrive l’échange. Le stylo est un objet connecté qui doit par conséquent s’appuyer sur une transmission sans fil dont notre choix s’est porté sur le Wi-Fi. Il existe différents modes de mise en réseau en Wi-Fi. Pour Transcripen, nous avons opté pour le mode d’infrastructure. Ainsi, l’ordinateur sur lequel tourne l’application et le raspberry contenu dans le stylo sont connectés entre eux dans un réseau local via un point d’accès ou un routeur. Ainsi, nous avons nos deux équipements qui sont dans le même sous-réseau et qui peuvent communiquer facilement. 

La norme 802.11 utilise des ondes électromagnétiques pour une liaison sans fil avec la couche physique qui définit la modulation des ondes radioélectriques et les caractéristiques de la signalisation pour la transmission de données, et la couche liaison de données qui définit l’interface entre le bus de la machine et la couche physique. La troisième couche, celle qui est responsable du transport des messages complets de bout en bout (soit de processus à processus) au travers du réseau est assurée ici par le protocole TCP.

Pour permettre cette transmission, nous avons utilisé les sockets TCP. Concrètement, un socket représente l’association entre IP et Port. L’IP identifie la machine et le port une application. Dans notre projet, le serveur tourne dans le stylo et le client est intégré dans l’application. Ainsi, le serveur est activé à intervalle de temps régulier dans la raspberry pour permettre, dès qu’elle détecte le client de lancer la transmission.  Dans notre cas, le serveur se charge d’envoyer l’audio et le client reçoit le fichier en plusieurs paquets de 1024 octets. 

Ce choix est dû principalement à la facilité d’intégration et au fait que c’était une des compétences déjà acquises dans l’équipe.

 E. Algorithme de transcription d’un fichier audio en fichier texte

L’algorithme est disponible sur le Github du projet, dans la rubrique: https://github.com/camillebrl/Transcripen/blob/main/application/transcription_text/algo_speech_recognition.py.

Nous avons créé  une classe qui a pour attributs le chemin d’un fichier audio .wav ainsi que sa langue et qui renvoie le texte correspondant à la transcription du fichier audio en question. Cette classe effectue un « préprocessing » de l’audio d’entrée (calcul de la durée de l’audio, découpage en sous-audios de 10s), et applique à l’audio préprocessé l’algorithme de Speech Recognition développé par Google et accessible simplement via une API (incluse dans la librarie speech_recognition disponible sur Github https://github.com/Uberi/speech_recognition).

Nous utilisons pour cela plusieurs libraires, notamment Pydub, qui est une librairie permettant de manipuler un fichier audio simplement (ouverture de l’audio, augmentation / diminuaiton du volume de l’audio, segmentation de l’audio, calcul de la durée de l’audio, et toute autre manipulation possible sur un audio. La librairie est en open-source sur https://github.com/jiaaro/pydub). Pour utiliser pydub, il faut installer ffmpeg/avlib. nous utilisons aussi la librairie speech_recognition (https://github.com/Uberi/speech_recognition) qui effectue de la reconnaissance vocale via diverses APIs, en ligne et hors ligne, notamment CMU Sphinx, Google Cloud Speech, WIT.ai, Microsoft Azure Speech, Houndify, IBM Speech to Text, ou encore Snowboy Hotword Detection. Les différents réseaux ont été entraîné sur des audios dont la taille de dépasse pas les 50 secondes. Dès lors, nous avons découpé le fichier audio en sous-audios de 10s. 

1. Le découpage de l’audio

Pour découper l’audio en slots de 10s, on a tout d’abord récupéré la durée de l’audio à l’aide de la fonction duraction_seconds de Pydub. On divise ensuite la durée totale en n sous ensembles de 10 secondes. Pour ce faire, nous utilisons la fonction range de python (range(0, nombre total de secondes de l’audio, 10). On itère (for i) sur toutes les valeurs de cette liste, c’est-à-dire sur les secondes de l’audio. On coupe ensuite l’audio entre la seconde i et la seconde i + 10. Afin d’éviter qu’il y ait des coupures de mots qui gêneraient la transcription de chaque slot d’audio, on prend 1 seconde avant et 1 seconde après de l’audio (plus de détails dans la documentation de l’algorithme sur https://github.com/camillebrl/Transcripen/blob/main/application/transcription_text/algo_speech_recognition.py en lignes 49 à 55). Une fois le slot d’audio récupéré, on l’exporte.

2. L’application de l’algorithme sur les slots de 10 (exactement 11 à 12s d’audio)

Sur ce slot d’audio, on applique la fonction recognize_google (appel de l’API Google qui n’a pas de limite d’appel) sur le slot d’audio, et en définissant la langue. On a en retour un string correspondant à la transcription de l’audio du slot.

3. La concaténation finale du résultat

L’algorithme est donc appliqué sur chaque slot d’audio (on supprime le .wav du slot à chaque fois que l’on a obtenu la transcription de l’audio). On ajoute les transcriptions de chaque slot dans un string général (variable de la classe final_result). On obtient ensuite la transcription de l’audio tout entier.

III/ Résultats

La démonstration présente des résultats concluants sur de nombreux point : 

• Bien qu’étant de volume conséquent, l’objet présenté est bien portable, auto-alimenté et communique sans fil.
• L’enregistrement de l’audio se déroule sans réels problèmes, la qualité de l’enregistrement est très satisfaisante pour une distance à l’objet d’environ 50 cm. Cela est tout à fait cohérent avec le contexte d’un échange entre 2 personnes.  
• L’application reçoit bien le fichier audio, le transcrit et l’affiche sur l’application Web. La transcription est assez satisfaisante, bien que tous les mots ne soient pas réellement transcrits parfaitement. L’esprit et la forme globale de l’échange est bien retranscrit par la solution est ceci était l’objectif principal

IV/ Perspectives

• Automatisation du lancement de nos algorithmes lorsque la Raspberry boote: Nous n’avons pas configuré une exécution du script de manière automatique par manque de temps. Si nous avions eu une semaine supplémentaire (soit un sprint de plus), nous aurions pu mettre cela en place. Dès lors, nous étions obligé de lancer les commandes “python3 final_algo.py” en se connectant en SSH à la Raspberry afin de le faire tourner. Nous aurions pu effectuer une configuration du démarrage de la Raspberry afin que celle-ci lance automatiquement notre algorithme. Pour ce faire, nous aurions pu définir un contrab qui permet, après chaque démarrage, d’exécuter automatiquement un script, à l’aide de la ligne “@reboot  /home/user/final_algo.sh”.
• Miniaturisation: La principale amélioration possible serait de réduire considérablement la taille de nos composants. Dans un premier temps la carte Raspberry Pi Zero pourrait être remplacée au profit d’une carte plus petite intégrant uniquement les ports (seulement 4 port de donné, un port d’alimentation) dont nous avons besoins et un circuit imprimé ne contenant uniquement nos algorithmes utilisé pour le service rendu. Du côté de la batterie sa taille pourrait être diminuée également en réduisant sa capacité. Des tests devront être effectués sur les performances énergétiques des différents composants afin de calculer précisément la capacité nécessaire de notre batterie, pour information la Raspberry Pi Zero W requiert  5V pour environ 300 mA. En conclusion, plus la taille des composants se réduit, plus leur prix de production et de développement augmente.
• Ajout d’un bouton pour surligner les moments importants de l’audio: En plus de transcrire l’audio en texte, nous aurions pu
  • 2 algorithmes tournent : un qui transcrit le tout, un autre juste le moment indiqué, et on fait une recherche dans le document de là où se situe le paragraphe en question, et on y met un effet dessus
• Ajout d’un algorithme de différenciation des interlocuteurs : il existe un ensemble d’algorithmes disponibles (notamment de Google) qui permettent d’effectuer une différenciation d’interlocuteurs d’un audio. Nous aurions pu l’ajouter à notre projet si nous avions eu davantage de temps. Cependant, puisque nous travaillons sur des slots d’audios et puisque les algorithmes sont entraînés sur des audios de courte durée, nous ne savons pas comment nous aurions pu traiter cela. De nombreuses recherches ont été effectuées sur le sujet (sur de longs audios) que nous aurions pu étudier, si nous avions eu davantage de temps.
• Possibilité de configurer le cloud: le choix du wifi reste un bon choix. Mais on pourrait considérer le Cloud qui permettrait de stocker les audios et de récupérer tous les audios enregistrés dans l’application web. 

EcoCard – Solution technique

Envoyé par v20blond le 20 Déc 2021 dans Projets, TAF CoOC | 0 commentaire

Auteurs : M. BARATON, V. BLONDEL, M. CZERNICHOW, L. REYNAUD

I. Contexte 

Nous sommes un groupe de 4 étudiants à IMT Atlantique et devions réaliser un projet dans le cadre de notre thématique d’approfondissement de Conception d’Objet Connecté (CoOC). C’est pourquoi, au fil des dernières semaines, nous avons cherché à répondre à la problématique suivante : comment éviter la surconsommation d’énergie dans les entreprises ? Nous allons vous présenter notre solution, EcoCard.

II. Présentation de la solution technique

   1. Présentation du système et de son fonctionnement 

EcoCard est un système qui permet d’éteindre ou d’allumer un ordinateur depuis un appareil extérieur afin qu’un ordinateur ne reste pas allumer indéfiniment en l’absence de son utilisateur par exemple. Notre solution se présente sous la forme d’un boitier contenant une carte Raspberry PI et un lecteur RFID connectés. La carte Raspberry PI reçoit des informations du lecteur RFID et donne ensuite des consignes à l’ordinateur cible. La connexion entre l’ordinateur cible et la carte Raspberry se fait via un câble Ethernet. Pour entamer le processus, l’utilisateur doit introduire un badge RFID dans une fente du boîtier prévu à cet effet. Le lecteur RFID présent dans le boîtier pourra alors récupérer les informations du badge et les transmettre à la carte Raspberry PI.

Voici un schéma explicatif dans le cas où l’on cherche à utiliser EcoCard dans le cas où l’ordinateur cible est allumé et l’objectif est de l’éteindre :

Schéma explicatif EcoCard

Si le badge a bien les autorisations nécessaires, un message s’affichera sur l’écran de l’ordinateur cible (« Vous allez être déconnecté, arrêt en cours… ») puis l’ordinateur s’éteindra au bout de quelques secondes.

Attention, notre solution fonctionne uniquement sur des appareils OS Windows et non sur des appareils Mac OS ou Linux. Il est possible d’adapter EcoCard à ce type d’appareil en changeant notamment le code présent sur la carte Raspberry PI.

2. Architecture boitier

Pour des raisons fonctionnelles, ergonomiques et esthétiques, l’équipe a opté pour la conception d’un boîtier afin que les fils, la carte Raspberry PI ou le capteur RFID n’encombrent pas l’utilisateur.

La conception s’est faite en deux temps. Tout d’abord la partie principale du boîtier a été modélisée en 3D sur SolidWorks. Cette partie sert à fixer les différents éléments du montage comme le capteur RFID et la carte Raspberry Pi. Elle permet également de créer la fente dans laquelle la carte doit être glissée. Cette partie a été imprimée en 3D. Suite à des complications la partie fixation de la carte Raspberry Pi a été enlevée. Ensuite, il a fallu concevoir le toit et la partie arrière du boîtier. Ces deux parties ont été découpées dans du bois au laser. La partie supérieure a été collé au pistolet à colle car elle a besoin d’être fixée. La partie arrière est vissée à la partie imprimée en 3D de sorte que l’on puisse sortir et rentrer les éléments pour la maintenance éventuelle.

Schéma du boîtier sur SolidWorks sans le toit ni la plaque arrière

Pour concevoir notre système, il faut dans un premier temps connecter la carte Raspberry PI au lecteur RFID. Puis à l’aide de deux vis il faut fixer le lecteur RFID à l’intérieur du boîtier, on le fixe à la partie supérieure, celle accolée à la fente prévue pour les badges RFID. Ensuite on fixe la carte Raspberry PI sur la paroi droite du boitier à l’intérieur afin d’éviter d’avoir à faire les connexions dans l’espace restreint du boitier. Il reste à brancher le câble d’alimentation de la carte grâce à un trou dans la paroi droite du boitier et le câble Ethernet via un trou dans la paroi de derrière. Enfin on referme le boîtier à l’aide des 4 vis prévues à cet effet.

3. Montage électronique et matériel utilisé.

Liste du matériel utilisé :

• Raspberry Pi 3B+
• Module RFID-RC522
• Un câble Ethernet
• Un câble d’alimentation 5V 3000mA Micro USB
• Des câbles et des vis

Présentation du circuit électronique [2]

  Pour des raisons de priorisation des fonctionnalités, nous avons par la suite retiré les LEDs du circuit.

      a. La Raspberry Pi 3B+

L’action d’éteindre ou d’allumer un ordinateur à distance doit se faire à partir d’un autre ordinateur. Dans ce projet, la Raspberry Pi 3B+ fait office d’ordinateur monocarte et fonctionne sous Raspbian 11.

Ce modèle est basée sur un processeur ARM Cortex-A53 64 bits quatre coeurs à 1,4 GHz, il dispose de 1GB de mémoire RAM, une interface Wi-Fi, une interface Bluetooth, 4 ports USB, un port Ethernet, un port HDMI, un port micro-SD et un connecteur GPIO avec 40 broches d’E/S.

Carte Raspberry Pi 3B+

Le fait de disposer à la fois d’une interface Wifi et d’un port Ethernet permet d’utiliser selon la situation un de ces deux protocoles de communication avec l’ordinateur cible. C’est également grâce à cette interface Wifi qu’il est possible d’utiliser l’interface graphique de la Raspberry Pi via VNC sur un ordinateur portable.

Nous avons décidé pour ce projet d’utiliser un système d’exploitation (Raspbian) sous Linux plutôt que sous Windows car la création de l’interface était plus simple avec Raspbian. De plus, les versions des systèmes d’exploitation windows sur Raspberry Pi sont très lourdes et demandent plus de performances et de ressources, ce qui était peu adapté au projet.

      b. Le module RFID-RC522

Module RFID-RC522

Nous avions également besoin d’un module permettant de détecter la présence d’une carte et de lire son UID afin de vérifier que l’utilisateur a le droit d’avoir les accès sur l’ordinateur : nous avons choisi le lecteur RFID-RC522.

Ce module est utilisé pour lire et écrire sur des cartes ou badges RFID de type Mifare. Il fonctionne en transmettant, à travers des ondes radio, de l’énergie au tag RFID. La carte microprocesseur (Arduino, Raspberry ou compatible) et le module RFID communiquent via le bus SPI permettant de laisser libres les autres ports de la carte pour d’autres applications.

Connexion des ports du RC522 aux ports de la Raspberry Pi

4. Pré-configuration de l’ordinateur cible

a. Généralités

L’utilisation du Shutdown, du Wake on Lan et de la mise en veille à distance requiert qu’un certain nombre de paramètres de l’ordinateur cible soit modifiés. Il s’agit en fait d’autoriser sa communication avec les ordinateurs distants. L’ordinateur cible doit être autorisé dans les paramètres à pouvoir:

• Se réveiller grâce à un paquet magique (activation dans le Bios)
• Pouvoir partager et recevoir des fichiers de la part d’un ordinateur distant.
• Pouvoir recevoir un paquet magique de la part d’un ordinateur distant.
• Accéder à distance à un ordinateur distant
• Etre forcé de s’arrêter à partir d’un ordinateur distant.

Tous ces paramètres à activer réduisent la sécurité de l’ordinateur à éteindre vis à vis des ordinateurs distants. De plus, le nom d’utilisateur et le mot de passe d’une session administrateur doivent être inclus dans le code, ce qui pose un problème de sécurité pour cette session. La Pré-configuration est détaillée dans le fichier Read du Git.

b. Le Wake on Lan

Attention, malheureusement seuls certains appareils sont compatibles avec le Wake on Lan. Pour déterminer si votre appareil possède cette fonctionnalité, il faut se rendre dans le BIOS de votre ordinateur, aller dans les options avancées, puis dans gestion de l’alimentation avancée, il faut ensuite activer le démarrage du système par périphériques PCI-E, si l’option n’est pas disponible votre appareil n’est pas compatible.

Dans le cas où votre appareil est compatible, il faut se rendre dans le gestionnaire de périphériques de Windows, ouvrir la carte réseau puis ouvrir la carte Ethernet. Il faut ensuite aller dans l’onglet avancé, cliquer sur Wake On Magic Packet, il faut l’activer. Dans l’onglet Gestion de l’alimentation, tous les éléments doivent être cochés, c’est à dire :

• « Autoriser ce périphérique à sortir l’ordinateur du mode veille »
• « Autoriser uniquement un paquet magique à sortir l’ordinateur du mode veille »

Il faut également récupérer l’adresse MAC de l’ordinateur à allumer via la commande ipconfig /all

Votre appareil est alors configuré pour le Wake On Lane. Cela vous permettra de démarrer à distance votre ordinateur complètement éteint.

La commande à entrer sur la carte Raspberry PI utilise la librairie etherwake, elle contient une unique ligne contentant en particulier l’adresse MAC de l’ordinateur cible. Cette commande permet d’envoyer un paquet magique à l’ordinateur à allumer.

   5. Explication et lien vers le code 

Comme le projet est divisé en différentes fonctionnalités, nous avons décidé d’écrire des scripts shell différents pour chacune de ces fonctionnalités (Shutdown, Wake on Lan…). Cela permet de tester ces scripts shell indépendamment avant de les inclure dans le code.

Un code python va permettre d’appeler les scripts shell à exécuter selon le badge RFID lu. Ce code va être exécuté grâce à un autre script shell appelé lancement.sh qui permet d’exécuter le code python main directement au démarrage de la Raspberry Pi. En effet, on utilise le crontab qui est un programme qui permet aux utilisateurs de Linux d’exécuter automatiquement des scripts à une date ou à une heure spécifiée. Ici, on a spécifié que le script devait être exécuté à chaque lancement grâce à la commande @reboot. L’ensemble du code est disponible ici.

   6. Protocole de Communication

Nous avons choisi, dans le cadre de notre projet, d’utiliser la technologie de transmission Ethernet. Pour l’IEEE (institut des ingénieurs et électriciens), Ethernet est en fait le protocole 802.3. C’est le type de réseau local le plus utilisé aujourd’hui.

Un réseau local (LAN) est un réseau d’ordinateurs connectés dans une zone restreinte. C’est la connexion utilisée dans la grande majorité des bureaux. L’Ethernet est un réseau local nécessitant un câblage.

Le choix de transmission qui s’est présenté à nous était le suivant : Wi-Fi ou Ethernet.

Le Wi-Fi (réseau local) était une solution possible pour réaliser notre système, car l’ordinateur et le boîtier restent très proches l’un de l’autre et peuvent être connectés en LAN (local area network).  Cependant, une telle technologie de transmission implique deux choses : un réseau local fonctionnel à disposition et une connexion permanente de la raspberry pi à ce réseau ainsi que de l’ordinateur. En effet, le réseau local doit être bien choisi : par exemple, le wifi de l’école ne fonctionnait pas. De plus, la connexion permanente des deux outils numériques est une contrainte. Nous avons également constaté lors des recherches réalisées pour coder le Wake on Lan que ce processus se faisait en Ethernet dans la majorité des cas (bien que le Wi-Fi reste une possibilité de transmission).

Nous avons donc opté pour la connexion Ethernet. Cette connexion possède un avantage important : elle permet une connexion beaucoup plus stable. En effet, il n’y a pas de problème d’interférence avec un réseau Ethernet câblé. Or les interférences dans un bureau sont communes, pouvant être créées par le partage de connexion, les connexions bluetooth, etc. En s’affranchissant de toutes ces interférences, via le câble Ethernet, la connexion connaît moins de ralentissements, de déconnexions ou de problèmes de connexions.

De plus, la technologie Ethernet assure une connexion complètement sécurisée. En effet, avec une connexion physique, nous pouvons garder le contrôle sur ce qui est connecté sur notre réseau local. Un réseau Wi-Fi aurait pu s’étendre au-delà des murs de l’entreprise, les impacts du système aussi.

III. Résultats

Notre système de réduction de la consommation d’énergie pour un poste de travail s’est soldé par la mise en place d’un système permettant d’éteindre un ordinateur grâce à un badge RFID. Pour terminer le système, il suffit d’acheter une multiprise maître-esclave et de brancher l’ordinateur sur la prise dite « maître ».

Nous avons donc mis en place et testé trois fonctionnalités du système : le boîtier, le shutdown d’un PC distant par introduction du badge RFID ainsi que l’automatisation du système au démarrage de celui-ci. Ces tests sont présentés dans la vidéo suivante.

IV. Perspectives 

   1. prise de recul sur les points délicats du système

Un des points délicat que nous avons constaté lors de la réalisation de notre projet est l’importance du choix dans le matériel utilisé. En effet, nous avons très rapidement opté pour une carte arduino pour finalement réaliser qu’une carte Raspberry Pi était plus adaptée au projet. De plus, nous avons été confrontés à des problèmes, assez attendus, de cyber sécurité.

Exemple concret :  mon ordinateur se déverrouille grâce à mon empreinte digitale, je dois entrer un code à 4 chiffres si l’ordinateur ne reconnaît pas l’empreinte, mais ce code n’est pas considéré comme le moyen principal de déverrouillage de mon ordinateur. Ainsi dans le script du shutdown lorsque j’indique mon code à 4 chiffres comme mot de passe associé à mon login, cela ne fonctionne pas. Il faut que je désactive l’empreinte digitale et que je mette un mot de passe sous forme d’une chaine de caractère pour que le script du shutdown fonctionne correctement. C’est une des limites de samba-common.

La réalisation du système demandant de nombreuses recherches qui menaient toujours à plus de découverte et de tâches à réaliser, nous avons donc dû prioriser certaines fonctionnalités. C’est pourquoi lors de chaque nouveau sprint, de nouvelles User story ont été ajoutées.

   2. prise de recul sur les forces du système 

La détection RFID est une force du système car c’est un système très fiable qui permet de sécuriser le système en autorisant uniquement une seule carte à déclencher l’arrêt.

Une autre force du système est qu’il est possible de le mettre hors tension puis de le rebrancher sans qu’il y ait d’impact sur son utilisation, ce qui donne des possibilités d’améliorations en terme de consommation pour la Raspberry Pi même si cette consommation est assez minime

   3. descriptions des actions à réaliser pour compléter le système actuel 

Pour compléter le système, il faudrait finaliser le Wake on Lan, en trouvant un ordinateur supportant le Wake on Lan et adapté au code pour ensuite affiner notre code.

Il faudrait également créer une interface pour que le système s’adapte facilement à tous type d’ordinateur et soit facilement configurable, notamment en ce qui concerne l’adresse IP, l’adresse Mac, le nom d’utilisateur et le mot de passe de l’ordinateur distant. Une idée que nous avions était de créer une interface digitale directement sur le boîtier pour avoir un système plus ludique. La fonctionnalité de mise en veille doit également être ajoutée.

Finalement, la dernière tâche à réaliser pour obtenir un système répondant à la problématique initiale, à savoir la réduction de la consommation d’énergie au sein d’une entreprise, est simplement de réaliser le branchement adapté à l’aide d’une prise maître esclave. L’ordinateur serait en fait branché en tant que maître, et lors de son extinction, l’ensemble des autres objets numériques branchés en temps qu’esclaves s’éteindront.

   4. suggestion de pistes concrètes pour l’ajout de nouvelles fonctionnalités 

Il pourrait être ajouté à l’interface un calcul de l’énergie économisée depuis l’utilisation de EcoCard. Une utilisation par défaut est à définir et pourrait être changée.

Après avoir connecté toutes les Raspberry Pi à des postes de travail, on peut créer une carte virtuelle avec leurs positions géographiques reportées sur cette carte. Suite à cela, si jamais plusieurs boitiers EcoCard proches détectent des ordinateurs éteints, la lumière, le chauffage et toutes autres consommations d’énergie inutiles seraient arrêtées.

PILOTIS – Solution technique

Envoyé par n20aidou le 20 Déc 2021 dans TAF CoOC, Projets | 0 commentaire

Equipe

AÏDOUNE Nicolas

BAUVOIS Nicolas

ELIAYAN Matys

BELLERY Marianne

I – Contexte

Dans le cadre du projet fil rouge de la TAF CoOC nous réaliserons le pré-prototype d’un objet communicant. Nous avons choisi de nous intéresser au problème des sinistres provoqués par les dégâts des eaux. En 2015, plus d’un million de dégâts des eaux ont été recensés dans des maisons particulières en France, occasionnant des dégâts estimés à 2,5 milliards d’euros. En effet, en moyenne, le coût lié à un dégât des eaux est autour des 1500€. Pourtant, pour éviter tous les dégâts, il suffit d’agir dans les 30 premières minutes qui suivent l’apparition de l’eau. Et pour éviter des dégâts majeurs, les compagnies d’assurances conseillent d’agir avant que le niveau de l’eau n’atteigne les 15 cm. En plus de cela, le chiffre le plus marquant à ce sujet est que 93% de ces sinistres sont liés à des fuites domestiques qui auraient donc pu facilement être évités. Dans le cadre de notre projet nous nous sommes non seulement intéressés à ces sinistres évitables, mais également aux 7% restants, c’est-à-dire aux inondations occasionnées par les crues, les tempêtes, ou encore les submersions marines.

La problématique soulevée par l’équipe est celle de la prévention des différents types de dégâts des eaux qui sont la cause n°1 des sinistres habitation en France. En effet, nous avons constaté qu’en plus de représenter un coût relativement élevé, cela concerne tous les ans de nombreux foyers dont le nombre risque d’augmenter avec le dérèglement climatique. Ainsi, nous cherchons à  trouver un moyen de limiter les dommages matériels causés par ce type d’événements. Ceci nécessite donc de détecter rapidement le début d’un sinistre et d’en informer le sinistré.

II – Réalisation

Le matériel que nous avons utilisé : 

• Une carte Arduino Uno
• Un module wifi NodeMCU ESP8266
• Une électrovanne normalement ouverte
• Deux modules grove LoRa Radio x2
• Un capteur de niveau d’eau Grove 101020635
• Une résistance de 22kΩ
• Un smartphone android
• Plusieurs câbles
• Un boîtier “Gateway” réalisé à partir d’une impression 3D
• Un boîtier “Détecteur” réalisé à partir d’une impression 3D
• Une alimentation stabilisée
• Un bîtier pour piles 9V et sa pile
• Un module Grove base shield 103030000
• Un relais 5V
• Une alimentation MicroUSB
  

1 ) Prototype

L’architecture de notre prototype suit un schéma classique en IoT, il est composé de deux parties : un nœud et une gateway. Le nœud représente la partie détecteur du prototype qui relève les différentes informations avec ses capteurs. La gateway reçoit les différentes données du nœud et réalise différentes actions en réponse à ces informations.

a . Gateway

La gateway du prototype représente la partie liée au circuit d’eau du domicile. Son rôle est de recevoir les informations qui proviennent du nœud et de les traiter pour agir en conséquence. Ainsi, en recevant une alerte de détection d’eau, la gateway s’occupe de couper l’eau du domicile et déclenche une notification sur le smartphone de l’utilisateur pour lui signaler. De plus, en cas de nouveau message de la part du nœud indiquant une évolution de la situation, le module déclenche une nouvelle notification afin d’informer l’utilisateur en temps réel. 

Le boîtier de la gateway a été réalisé par impression 3D. Une boîte en PLA de dimensions 120mmx100mmx65mm permet de contenir le NodeMCU ESP8266, le relais et le module Grove LoRa radio. Le modèle de ce boîtier a été réalisé à l’aide de Solidworks. Un trou sur le côté permet de faire passer les fils de l’électrovanne qui se situe à l’extérieur du boîtier mais aussi le câble d’alimentation secteur pour le NodeMCU.

Pour éviter de conserver une breadboard dans le boîtier afin d’avoir un montage plus propre et gagner de la place, nous avons soudé tout le circuit. 

b . Noeud

Le rôle de la partie nœud est de détecter l’eau et d’envoyer les informations récoltées à la gateway. Ainsi, le module doit être capable de détecter un simple filet d’eau comme une hauteur d’eau de plusieurs centimètres. Dans un premier temps, la détection d’eau est signalée à la gateway, puis, si la hauteur d’eau est amenée à changer, elle est également communiquée. Enfin, le module est capable de détecter la stabilisation du niveau d’eau et de le signaler à la gateway, qui préviendra à son tour l’utilisateur..

Afin de pouvoir mesurer une hauteur d’eau, il était nécessaire de concevoir un boîtier haut de plusieurs centimètres qui permet également d’éviter que le système prenne l’eau. Il contient la carte arduino UNO, le module Grove LoRa, le capteur de niveau d’eau Grove et le système de détection de filet d’eau. Le boîtier a été réalisé en PLA par impression 3D. 

2 ) Electronique

A. Partie noeud

a . Carte Arduino Uno

Afin de piloter la partie nœud de notre objet, nous avons utilisé une carte de développement  Arduino UNO, qui dispose du microcontrôleur ATmega328P. Pour programmer son fonctionnement, il suffit d’écrire un programme sur l’IDE Arduino puis de téléverser ce code sur la carte via son port USB. Cette carte communique avec les différents composants du nœud et les alimente en énergie électrique. Elle est elle-même alimentée par une pile 9V via sa prise jack.

b . Capteur de niveau d’eau Grove 101020635

Afin de mesurer précisément la hauteur d’eau en temps réel au cours d’un sinistre, nous avons décidé d’utiliser ce détecteur de niveau d’eau capacitif compatible de Seeedstudio. Une fois plongé dans l’eau, ce capteur mesure la hauteur d’eau avec 5 mm de précision à l’aide de ses cellules conductrices, et communique cette information à la carte Arduino via son bus I2C(ports SDA et SCL). Ce capteur est alimenté en 5V via le port 5V de la carte Arduino.

c . Montage de détection de filet d’eau

Le capteur de niveau d’eau présenté dans la partie précédente est très efficace lorsque la hauteur d’eau dépasse 5 mm, cependant il est incapable de détecter un filet d’eau. En réalité, la grande majorité des capteurs de niveau disponibles sur le marché sont faits pour mesurer des niveaux d’eau dans des réservoirs, et sont donc incapables de mesurer une très faible couche d’eau. Nous avons donc décidé de concevoir notre propre circuit de détection, en optant pour un montage très simple.

En effet, nous avons simplement réalisé un circuit représenté ci-dessus reliant l’alimentation 5V de l’Arduino à une résistance de 22K ohm reliée à la masse. On mesure la tension de cette résistance en la reliant à une broche numérique de la carte Arduino. En cas de présence d’un filet d’eau, le circuit est fermé, et la carte Arduino mesure une tension positive aux bornes de la résistance. Ce montage nous permet donc de détecter un potentiel dégâts des eaux dès l’instant où un filet d’eau atteint la partie nœud de notre objet.

d . Module Grove LoRa Radio

Afin d’assurer la communication sans fil longue portée entre les parties nœud et gateway de notre objet,  nous utilisons deux modules LoRa Radio Grove, l’un placé dans le boîtier de détection, l’autre dans le boîtier de transmission. Ces deux modules communiquent selon le protocole LoRa à une fréquence de 868 MHz. Chaque module peut jouer le rôle d’émetteur ou de récepteur, cependant nous utilisons le module du nœud comme émetteur et le module de la gateway comme récepteur. Nous avons choisi ce module LoRa car il permet une communication de bonne qualité même lorsque que l’émetteur et le récepteur sont situés à deux étages différents d’un domicile. Ce critère est crucial car l’utilisateur de Pilotis placera logiquement la partie nœud de l’objet dans une pièce de son domicile particulièrement vulnérable aux dégâts des eaux, or il s’agit souvent du sous-sol. Au contraire, la gateway est située au niveau de l’arrivée d’eau, donc au rez de chaussée.

e . Schéma de l’architecture

B. Partie gateway

a . Module Wifi NodeMCU ESP 3266

Afin de connecter la gateway à internet, nous avons utilisé un Module Node MCU ESP8266. Ce module contient un module ESP8266, il s’agit d’un circuit intégré  à microcontrôleur avec connexion Wi-Fi développé par le fabricant chinois Espressif. Ce module de quelques centimètres permet de connecter un microcontrôleur à un réseau Wi-Fi et d’établir des connexions TCP/IP avec des commandes Hayes. Ainsi, ce module wifi permet de contrôler les composants de la partie gateway(comme une carte Arduino), mais aussi d’envoyer des requêtes URL à l’API  qui s’occupe de l’envoi de notification au smartphone de l’utilisateur(cf. partie 4). 

b . Electrovanne et relais

Afin que notre objet communiquant soit capable de couper le circuit d’eau domestique au cas de détection d’eau, nous l’avons doté d’une électrovanne. Il s’agit d’une vanne commandée électriquement permettant d’agir sur le débit d’eau d’un circuit.. Nous avons choisi une vanne dite tout ou rien, c’est-à-dire étant soit ouverte soit fermée. Son état change suivant qu’elle soit alimentée électriquement ou non, et elle est dite “normalement ouverte” car elle est ouverte en l’absence d’alimentation électrique, et se ferme lorsqu’elle est mise sous tension. L’électrovanne est alimentée en 12V par une alimentation stabilisée reliée au secteur.

Pour piloter cette électrovanne, nous utilisons un relais électromécanique. Il s’agit d’un organe électrique permettant de distribuer la puissance à partir d’un ordre émis par la partie commande. Ainsi, un relais permet l’ouverture et la fermeture d’un circuit électrique de puissance à partir d’une information logique. Dans le cas de Pilotis, la commande logique d’ouverture ou fermeture provient d’une sortie numérique du module NodeMCU, et le circuit électrique concerné est le circuit d’alimentation de l’électrovanne. Dès lors, en cas de détection d’eau sur le sol, le programme téléversé dans le module NodeMCU ordonne l’envoi d’une commande logique entraînant la fermeture du relais, donc la mise sous tension de l’électrovanne et la coupure du circuit d’eau. Cela permet de stopper une éventuelle fuite provenant du circuit domestique.

c . Schéma de l’architecture

3 ) Code Arduino

Les programmes pilotant le fonctionnement des parties nœud et gateway de l’objet sont dans un répertoire Github disponible via ce lien : https://github.com/NicoAdn/pilotis/tree/main.

4 ) API PushingBox / Application PushingBullet

Afin de pouvoir recevoir des notifications, il était nécessaire d’avoir une interface utilisable sur smartphone. Dans un souci de temps, nous avons décidé de ne pas développer cette partie nous même et de nous reposer sur une API existante, simple à mettre en place et à utiliser pour se concentrer sur la réalisation du prototype physique. 

Ainsi, nous avons couplé l’utilisation de l’API PushingBox, qui permet d’envoyer des notifications, et de l’application PushBullet, qui permet de les recevoir sur son téléphone.

Configuration des notifications sur le téléphone

• Dans un premier temps, il faut télécharger l’application PushBullet (disponible uniquement sur Android) et copier le lien qui est dans “Access Tokens.

• Il faut ensuite créer un compte sur PushingBox et ajouter un nouveau service en copiant le lien “Access Tokens”. 

• Après cela, il faut créer un nouveau scénario dans lequel on ajoute une nouvelle action.

• Enfin, il faut copier le Device Id et l’insérer dans le Code(voir Github).

Configuration des notifications sur un nouveau téléphone à partir d’un compte Google :

• Tout d’abord, il faut télécharger l’application PushBullet. 
• Puis se connecter via le compte Google Pilotis.

III – Résultats et perspective

Le projet PILOTIS, visant à créer un objet connecté permettant de prévenir les dégâts des eaux, s’est conclu sur la mise en place d’un prototype fonctionnel sous la forme de deux parties : une gateway et un nœud. Ces deux parties possèdent leur boîtier imprimé en 3D et le système complet permet de recevoir des notifications sur son téléphone qui s’adaptent à la situation.

Cependant, il y a quelques améliorations possibles au système. Dans un premier temps, l’ajout de boutons permettant de réinitialiser les différentes parties du prototype permettrait d’éviter d’avoir à mettre celui-ci hors tension puis sous tension pour le rendre à nouveau fonctionnel après un cycle d’utilisation. Ensuite, nous avons constaté qu’après l’allumage il est parfois difficile de savoir si le programme est opérationnel. En effet, il est nécessaire que le programme se connecte en wifi pour être fonctionnel et cette étape prend un temps qui peut varier en fonction des situations. Il serait donc intéressant d’ajouter des LEDs ou des composants produisant du son afin de permettre à l’utilisateur d’avoir des informations sur l’état du système(en démarrage, en cours de connexion, prêt à l’emploi…).

De plus, l’ajout d’un système d’alerte lumineuse et sonore se déclenchant en cas de détection d’eau et évoluant selon l’état de la situation serait souhaitable. En effet, les  fuites et les inondations arrivent aussi la nuit, dès lors une notification ne suffit pas forcément à prévenir l’utilisateur, qui peut avoir mis son téléphone en mode avion ou l’avoir éteint.  Enfin, le développement d’une application PILOTIS  améliorant l’interface utilisateur et permettant de nouvelles fonctionnalités (réinitialisation du système à distance, configuration de la connexion wifi sans avoir à modifier le code etc…) apporterait une réelle valeur ajoutée au produit.

IV – Vidéo de démonstration

LEGOLIRE – Etude terrain et personas

Envoyé par k20amani le 22 Nov 2021 dans Projets, TAF CoOC | 0 commentaire

Auteur

Koffi Judicaël AMANI, Rose LAPREVOTE, Wael MHIMDI et Souleymane OUEDRAOGO

Ce document présente le déroulement de la recherche sur le terrain, la rencontre avec les parties-prenantes du projet Legolire et les personas inspirés de l’étude terrain.

Sommaire

Partie 1 – Synthèse de l’enquête terrain

• Entretien avec les deux enseignantes.
• Observation terrain : immersion dans la classe de Mme Brassor

Partie 2 – Persona

• L’enseignante de CP, Julie
• L’élève de CP, Simon

Nous avons débuté notre enquête terrain par la prise de contact avec différentes écoles primaires proches de l’école, c’est-à-dire qu’on a appelé plusieurs écoles en se présentant, en présentant le projet de manière très succincte, et en demandant si on pouvait organiser un entretien avec une professeure en CP intéressée par le projet. Une seule école a répondu favorablement, et nous avons mené l’entretien avec Mme Brassor début octobre.
Chaque école nous a redirigé vers une adresse mail. Nous avons envoyé le même mail à pratiquement chaque école. Pour l’école favorable à une rencontre, l’adresse mail donnée était celle de l’enseignante en CP directement, à la différence des autres, qui était l’adresse mail de la direction, qui se chargeait (ou non) de retransmettre notre mail aux enseignantes potentiellement intéressées. Nous pensons que ce qui nous a bloqué pour les autres écoles, c’est ce second intermédiaire qui rend la communication plus lente et plus difficile.
En parallèle nous avons contacté une professeure de l’école qui enseigne le français aux étudiants internationaux, nous avons fait un entretien avec elle et elle nous a redirigé vers une ex-professeure des écoles qui a enseigné pratiquement 30 ans en CP, avec qui nous avons également pu mener un premier entretien quelques jours avant de rencontrer Mme Brassor.
Nous allons dans ce compte-rendu d’enquête détailler le premier entretien avec Mme Armel, avec Mme Brassor, et notre immersion de 2 heures en fin de matinée dans la classe de madame Brassor. Cette immersion fut d’ailleurs l’occasion d’une deuxième discussion qui a en grande partie confirmé nos observations, ce sur quoi nous allons nous concentrer.

Partie 1 – Synthèse de l’enquête terrain

• Entretien avec les deux enseignantes

Mme Brassor et Mme Armel

Nous allons traiter les deux entretiens en parallèle afin de mieux voir les similitudes et les divergences des enseignantes. Les deux professeures ont choisi le CP mais pour des raisons différentes : Mme Armel par goût du défit et Mme Brassor pour la routine quotidienne. Les deux enseignantes apprécient la perspective d’amélioration de leur méthode d’année en année, raison pour laquelle elles restent en CP.
Les deux ont eu des classes d’environ 20 élèves. Mme Armel avait en fait une classe de CP/CE1 et Mme Brassor une classe de CP, ce qui modifie la dynamique des classes : la première travaille plus en autonomie que la seconde, et permet aussi l’accompagnement personnalisé plus que la seconde.
Auparavant, il n’y avait aucun prérequis pour rentrer en CP, c’est-à-dire que certains élèves ne connaissaient pas leur alphabet, alors que maintenant chaque élève arrive avec une base obligatoire. Bien entendu, certains élèves en savent plus que d’autres, certains savent d’ailleurs déjà lire.
Nous avons interrogé les deux enseignantes quant au rôle des parents dans l’apprentissage précoce de la lecture. Les deux ont eu la même réponse (et différentes explications) : les parents n’ont pas tant d’influence que ça. Ils fournissent bien sûr un environnement favorable, i.e. l’enfant a des livres à la maison. Mais certains enfants apprennent entièrement seuls à lire. Les deux enseignantes ont mis en avant la motivation, la détermination personnelle de l’enfant.
Et dans le cas contraire, à savoir un enfant qui a des difficultés à apprendre à lire, plusieurs éléments extérieurs à l’école jouent un rôle aux yeux de nos enseignantes : les parents (parfois peu réceptifs aux suggestions des enseignantes, même vexés), la maison (la présence de livres ou non, ainsi que le temps d’écran), la santé.
En effet, lorsqu’un enfant a des difficultés pour apprendre à lire, l’enseignante en parle aux parents, et propose alors systématiquement de consulter un médecin généraliste, ou un ophtalmologue, ou un orthophoniste, ou encore un autre spécialiste. Les deux enseignantes n’ont aucun droit de diagnostic, elles ne peuvent qu’avoir une intuition, et la communication avec les parents est parfois épineuse. Dans le cas de Mme Armel, elle a travaillé en parallèle avec des orthophonistes pour s’adapter au maximum à l’enfant. Mme Brassor quand à elle sépare santé et école.

Maintenant que le cadre est présenté, intéressons-nous à ce qui se passe à l’école. Mme Brassor sait qu’un élève a du mal à apprendre à lire lorsqu’elle observe que certaines notions vues il y a plusieurs semaines ne sont toujours pas acquises par l’enfant. Il peut aussi passer plus de temps que nécessaire sur ses devoirs (30 minutes au lieu de 10 à 15 minutes).
Les deux enseignantes soutiennent qu’elles ont (eu) un ou plusieurs élèves en difficulté chaque année, 1 ou 2 pour Mme Brassor, et jusqu’à 3 pour Mme Armel.
Mme Brassor suit la méthode semi-syllabique imposée, elle change tout de même des choses chaque année, par exemple de manuel. Mme Armel a joui quand à elle d’une liberté totale dans l’enseignement de la lecture. La méthode qu’elle a retenu de part son expérience (c’est-à-dire la méthode qui marchait pour elle) est une méthode semi-globale : elle partait de mots pour en apprendre de nouveaux qui avaient des sons en commun, afin de ne pas se heurter aux limites de la méthode globale : l’absence de déchiffrement (i.e. de décodage).
Pour Mme Brassor, la lecture c’est du décodage et de la compréhension, accompagnés d’automatismes et de vocabulaire. Pour Mme Armel, les clés de la lecture sont la mémoire et la concentration.
Pour nos deux enseignantes, le pire des cas pour un enfant qui a du mal à apprendre à lire, la chose à éviter, c’est la démotivation de l’élève.

• Observation terrain : immersion dans la classe de Mme Brassor

Immersion dans la classe de Mme Brassor

C’est d’ailleurs l’élément le plus marquant de notre immersion réalisée fin octobre : les deux enfants en difficulté identifiés par Mme Brassor se sont montrés totalement inactifs et désintéressés pour certaines activités de groupe (par exemple lire tous ensemble des syllabes affichées au tableau) : ils ne regardaient pas, se contentaient de répéter ce que leurs camarades disaient sans essayer.
On notera que ces deux enfants en difficulté étaient placés derrière un enfant avec une AVS (auxiliaire de vie scolaire). Elle les a parfois aidés à se concentrer. Ils étaient côte à côte pour que Mme Brassor n’explique pas les activités adaptées deux fois et aussi pour qu’ils s’entraident.
Lors de notre immersion nous avons constaté que Mme Brassor mêle écriture et lecture sur deux heures chaque matin à la même heure (la fameuse routine). Les exercices de lectures sont parfois individuels et parfois collectifs. Leur difficulté est croissante : syllabe, mot, phrase, petit texte. Ils apprennent un nouveau son à chaque séance (pour la nôtre c’était “è”, “ê”), et ils apprennent en plus des mots outils. Avant de commencer à lire une phrase, l’enseignante entoure avec les élèves les mots outils qu’ils connaissent déjà, pour qu’ils n’aient à décoder que les mots restants. La difficulté des élèves est pour la majeure partie dans la compréhension : on les a entendus lire des phrases parfaitement, puis Mme Brassor leur a demandé “Est-ce que tu as compris ce que tu as lu ?” et la réponse a toujours été négative. Après quoi elle leur explique.
On a compté 10 activités différentes en 2 heures de temps, ce qui donne 12 minutes par activité en moyenne (ce chiffre est à relativiser, certaines étaient évidemment plus longues que d’autres) : ça va vite, parce que les enfants au bout d’un moment se désintéressent si l’activité dure trop longtemps ou si la difficulté est trop grande pendant trop longtemps. Et alors ils commencent à discuter entre eux et se déconcentrent. Ils ont d’ailleurs eu 2 activités en autonomie totale (pendant lesquelles Mme Brassor commence par aller voir les élèves en difficulté, et leur a parfois adapté les fiches et les exercices et leur réexplique le ou les exercices), dont une à la fin des deux heures donc après c’était l’heure du déjeuner et le problème de brouhaha des élèves ayant fini l’activité ne s’est pas posé. Mais, pour la première activité en autonomie, les élèves qui ont fini avaient des jeux en autonomie à faire en attendant les autres. De même, ils parlent entre eux, ils discutent pour savoir qui jouera à quoi et comment on joue, ce qui fait beaucoup de bruit et lorsque les autres ont fini, l’enseignante passe du temps à calmer les enfants et à recommencer à travailler : on observe le manque d’autonomie dont elle nous a parlé en entretien.
Une fois les élèves partis on a pu voir sa réaction face aux exercices des élèves en difficulté pour apprendre à lire (et aussi pour apprendre à écrire dans notre cas). Même si elle a adapté les exercices pour ces deux élèves, pour les cibler au maximum et enlever les difficultés secondaires (par exemple donner des étiquettes à coller au lieu d’avoir à écrire), certains exercices n’ont pas été réussi, d’autres oui. Elle s’intéresse aux mécaniques comprises pour pouvoir continuer à travailler avec.
On a surtout retenu qu’il fallait que les élèves en difficulté soient impliqués physiquement dans les exercices, qu’ils aient quelque chose à faire de manière individuelle, sinon ils laissent le travail aux autres et se démotivent presque immédiatement.

Partie 2 – Persona

Les personas présentés se rapprochent plus de nos principales cibles (enseignante de CP et élève de CP). Concernant le persona enfantin, nous n’avons pas fait d’interview d’enfant. Aussi le profil imaginé provient des dires des enseignantes interviewées, de nos interprétations de l’immersion dans la classe et de nos représentations personnelles. Le persona de professeure des écoles est selon nous assez représentatif de Mme Brassor.

L’enseignante de CP, Julie

L’élève de CP, Simon

Pilotis – Recherche et état de l’art du problème choisi

Envoyé par m20czern le 22 Nov 2021 dans Projets, TAF CoOC | 0 commentaire

Introduction

Après plusieurs rencontres sur le terrain dans le cadre d’un autre projet qui n’ont donc pas donné suite, nous avons choisi de nous concentrer sur la surconsommation d’énergie. Ce problème très large existe dans tous les domaines de la société. 

Partie 1 : Synthèse de l’enquête terrain 

I. Etude du problème

1. Réduction du Problème

La première Rencontre était avec M. Élève, élève à IMT Atlantique, qui avait effectué un stage de première année en RSE et dont le but était de trouver une solution à la surconsommation d’énergie au niveau des postes de travail. Cette rencontre nous a permis de cibler le problème. 

En effet, lors de cette discussion, nous nous sommes rendus compte que la surconsommation d’énergie des ménages n’est jamais fixe : ce problème existe chez certains ménages mais pas chez tous. A l’inverse, M. Élève nous a expliqué que la surconsommation d’énergie au sein des entreprises, notamment la surconsommation des appareils en veille, était un problème qui existait dans une entreprise dès lors que chaque salarié à son poste de travail.

Lors de son stage, il a pu noter que les salariés n’avaient plus le réflexe d’éteindre leurs ordinateurs et encore plus leurs écrans lorsque ceux-ci ne sont pas utilisés. Aussi, M. Élève nous a expliqué que, dans une entreprise, les frais d’énergie sont à la charge de l’entreprise. 

Par conséquent, nous avons choisi de cibler le problème de la surconsommation d’énergie sur celle des entreprises, et spécialement sur la consommation d’énergie des postes de travail lorsque ceux-ci ne sont pas utilisés.

         2. Engagement sociétal ou réduction des coûts ?

Afin de pouvoir répondre au problème de la meilleure manière, il fallait pouvoir répondre à la question précédente. En effet, la solution doit-elle desservir une cause environnementale ou bien financière?

Lorsque nous avons posé cette question à M. Élève, il a tout de suite répondu que  l’entreprise lui avait d’abord présenté le but du projet comme étant de réduire les coûts en matière d’énergie. M. Élève a tout de même mentionné le fait que l’engagement sociétal importait beaucoup à l’entreprise.

Quant à lui, M. Jean nous a répondu que la réduction des coûts et l’engagement sociétal importaient tous les deux autant à orange. Au cours de l’interview après cette question, nous avons tout de même remarqué qu’il a beaucoup plus mentionné la réduction des coûts que l’engagement sociétal.

Par conséquent, nous avons l’impression que la réduction des coûts importe plus aux entreprises et nous allons essayer de confirmer cela avec les deux prochaines interviews.

II. Les différentes solutions

Élève et M. Jean, lors des rencontres, nous ont ensuite parlé des solutions qui avaient été mises en place au sein de leur entreprise. Dans ces deux entreprises chaque salarié possède à son poste de travail au minimum un PC, deux écrans et une lampe avec souvent un troisième écran et une imprimante qui peuvent s’ajouter.

1. Les systèmes mécaniques

Élève lors de son stage avait imaginé une solution avec des multiprises maître-esclave, c’est-à-dire que lorsque l’alimentation est coupée sur une prise dite « maître », cela coupe l’alimentation sur toutes les autres prises. En termes de coûts, M. Élève nous a expliqué que cela forçait à avoir une multiprise par poste, ce qui n’était pas forcément le cas pour tous.

Chez Orange, M. Jean nous a mentionné un système de prises intelligentes qui sont alimentées à des heures prévues. Même si elles peuvent également être alimentées manuellement, le fait d’instaurer des horaires fixes n’est pas pratique car certains salariés peuvent vouloir revenir à des horaires tardifs…

De manière générale, M. Jean a confirmé que les systèmes mécaniques sont utiles pour éteindre des appareils comme des écrans mais le fait de couper l’alimentation peut endommager à terme les tours des PC ou les imprimantes.

          2. Utilisation de scripts

Jean nous a expliqué que les multiprises ou prises peuvent être reliées par des bridges (ou ponts) via Ethernet en utilisant des scripts Python. Chaque prise a son propre Id. Ce système marche par détection de voltage et peut par exemple attendre que l’écran se mette en veille pour couper complètement l’alimentation.

III. Futures Rencontres

Les deux rencontres que nous avons pu avoir pour l’instant dans le cadre de cette enquête terrain étaient assez similaires : ils avaient travaillé ou travaillent en tant que salariés dans une branche RSE. Ainsi, nous considérons qu’il nous manque les points de vue de personnes qui occupent d’autres postes.

1. Rencontre avec un PDG de start-up

Nous souhaitions rencontrer le patron d’une entreprise orientée numérique pour vérifier que les hypothèses que nous avions formulées, à savoir qu’une entreprise pourrait être intéressée par une solution à la surconsommation en termes d’énergie. 

Pour un PDG, la question de la priorité entre engagement sociétale et réduction des coûts est primordiale et nous souhaitons par conséquent en discuter avec lui.

Aussi, est-ce que l’entreprise a déjà entrepris des missions visant à réduire cette consommation en énergie et si oui, quelles sont-elles ?

          2. Rencontre avec un notaire et Co-dirigeant de Planet’RSE

Planet’ RSE est une association dont le but est de promouvoir la responsabilité sociétale des entreprises en élaborant des critères de notation en matière de RSE.

Cette rencontre a pour but de nous donner des indications sur le nombre d’entreprises pour qui l’engagement sociétal est important. Nous cherchons à valider l’hypothèse que des entreprises cherchent à réduire la surconsommation en termes d’énergie car celles-ci sont préoccupées par leur engagement sociétal et non pas uniquement par la réduction de leurs coûts.

Planet’ RSE analyse les engagements de nombreuses entreprises, par conséquent, nous voulons en apprendre plus sur les différentes choses mises en place par celles-ci afin de réduire la consommation d’énergie

          3. Liste des questions à poser lors des entretiens

• Comment s’organise l’approvisionnement en énergie des postes de travail (ex : une multiprise par poste ou une pour plusieurs/ lumières individuelles ou pas)?
• Quels appareils sont contenus dans un poste de travail ?
• Les employés ont-ils un ordinateur portable ou un ordinateur fixe? (ou bien les deux)
• Est ce que vous vous sentez concerné par le problème de la surconsommation d’énergie au sein des entreprises?
• Il y a-t-il des initiatives prises au sein de votre entreprise pour réduire la consommation d’énergie?
• Votre entreprise est-elle concernée par le télétravail? Si oui, quels outils numériques sont utilisés? 
• Connaissez vous la part des salariés qui éteignent entièrement tous leurs appareils avant de quitter leur poste de travail (lors d’une pause prise par l’employé ou lors de la fin de leur journée de travail) ?
• A votre avis, la volonté de réduire la consommation d’énergie est-elle davantage due à une volonté de réduire les coûts ou d’avantage à de l’engagement sociétal ?
• Pensez-vous à des solutions visant à réduire la consommation d’énergie d’un poste de travail ?

Partie 2 : Personas

I. Patron d’une entreprise

1. personna
2. Justification

Le premier profil d’utilisateur de notre système est Jean-Pierre, le patron d’une entreprise. Nous avons décidé de nous concentrer sur une entreprise ciblée numérique, car l’utilisation du numérique est très forte dans ces entreprises. L’ensemble des outils numériques utilisés présentent dès lors des sources de gaspillage d’énergie. 

Nous avons également décidé de nous concentrer sur un patron ayant une conscience écologique éveillée, rendant la problématique de l’économie d’énergie plus importante pour son entreprise. 

De plus, comme expliqué précédemment, nous ne voulions pas nous cibler sur une entreprise trop grande, une trentaine d’employés nous semblait idéal. 

De plus, il est assez évident que si Jean-Pierre agit par conscience écologique, il est au courant que la transition énergétique reste bénéfique à la vision que son entreprise renvoie, d’où son côté stratège. 

Nous trouvons également intéressant et assez vraisemblable que ce patron ai suivi des études d’ingénieurs, le rendant plus apte à comprendre la solution qui peut être trouvée pour régler son problème et à s’y intéresser. 

II. Patron d’une entreprise

1. personna

1. Justification

Le deuxième profil d’utilisateur de notre système est Pierre. Il est développeur logiciel au sein d’une entreprise. Nous avons estimé qu’un tel profil était intéressant car Pierre passe par conséquent la plus grande partie de son temps sur un ordinateur et est donc directement concerné par le problème de la surconsommation d’énergie des outils numériques. Nous avons légèrement caricaturé le personnage, en le décrivant comme un loup solitaire.

Pierre est depuis 3 ans dans l’entreprise. Cela signifie qu’il est déjà bien installé et qu’ au vue de son jeune âge, c’est sûrement la première fois qu’il est aussi longtemps au sein de la même entreprise.  Ceci permet de justifier le caractère peu flexible du jeune développeur logiciel : il a pris ses marques dans la boite et refuse que celles-ci soient bousculées. 

Il aimerait en revanche gagner en efficacité. Le fait que Pierre présente ces deux traits de caractère (peu flexible et en recherche d’efficacité) permet d’imposer les contraintes suivantes au système proposé : le système ne doit pas compromettre l’efficacité des employés et ne doit pas (ou au minimum) déranger leurs habitudes. 

De plus, le télétravail qui doit pouvoir continuer pour Pierre est une contrainte supplémentaire : le système conçu ne doit pas imposer nécessairement du présentiel. 

A cela, nous avons ajouté la conscience écologique de Pierre peu développée, qui rajoute une difficulté à l’instauration d’une solution dans son entreprise. 

Finalement, le profil du développeur logiciel peut être vu comme le “pire cas possible rencontré”, permettant de soulever toutes les contraintes potentiellement rencontrées lors de l’élaboration de notre produit.

Pilotis – Personas

Envoyé par n20bauvo le 16 Nov 2021 dans Projets, Blog, TAF CoOC | 0 commentaire

Dans notre projet, nous nous intéressons à la prévention et la détection des dégâts des eaux chez les particuliers. L’objectif est de pouvoir prévenir le plus tôt possible les utilisateurs afin qu’ils puissent agir en conséquence et éviter l’ampleur du sinistre et donc l’ampleur des coûts liés à celui-ci. Nous avons donc réalisé trois personas : un utilisateur plutôt classique, un autre utilisateur dans un autre cas un petit peu plus particulier et un assureur.

Utilisateur 1

Benoït est père de famille, il possède un  emploie stable et un logement. Il aime passer du temps avec sa famille, c’est pourquoi il souhaite pouvoir passer un maximum de son temps avec ses enfants et sa femme le soir et en week-end. Par exemple, il ne supporte pas devoir s’occuper de la paperasse administrative qu’il considère comme une perte de temps. Il sait que les dégâts des eaux sont des incidents fréquents dans les logements et que la détection rapide de ceux-ci permettrait de résoudre rapidement les problèmes, sans dommages majeurs, et sans longue perte de temps au téléphone avec l’assurance.

Il a donc besoin d’un système lui permettant cette détection rapide afin de gagner du temps, de l’argent et donc de la sérénité.

Utilisateur 2

Philippe est un ingénieur père de famille qui tend à s’approcher de l’âge de la retraite. Il possède une résidence secondaire à la campagne qu’il a hérité de sa famille et qui compte beaucoup pour lui. Depuis quelques années, il passe certains week-end à la rénover pour la remettre au goût du jour ce qui lui coûte une certaine somme qu’il voit comme un investissement pour lui, ses enfants et ses futurs petits enfants. Cependant, il passe parfois de longues périodes sans y aller ce qui peut mener à des surprises à l’arrivée sur les lieux. Ainsi, un dégâts des eaux pourrait perdurer dans le temps pendant plusieurs jours voire plusieurs semaines sans que personnes ne puissent agir pour pallier au problème. Cela pourrait entraîner de lourds dégâts et retarder les rénovations de Philippe voir détruire le travail réalisé jusqu’ici. S’en suivent une perte de temps et d’argent en rénovation et réparation.

Il a donc besoin d’un système permettant la détection de dégâts des eaux qui pourrait le prévenir depuis Paris afin d’être sûr d’agir à temps. Cela lui permettrait aussi d’avoir un sentiment de sécurité.

Assureur

Martine est agent général dans une compagnie d’assurance. Elle aime beaucoup son travail et est très investie dans l’entreprise qui l’embauche. Cependant, il existe de nombreuses compagnies d’assurance et la concurrence entre elles est dure. De plus, la guerre des prix est limitée par le besoin de l’assurance à posséder les fonds nécessaires pour rembourser les clients victimes de sinistres. Elle sait également que les dégâts des eaux présentent une problématique en termes de volume car bien que peu chère au cas par cas, leur nombre conséquent lui est une menace. 

Ainsi, Martine a besoin de pouvoir réduire le nombre de dégâts des eaux afin de pouvoir diminuer les coûts pour l’entreprise mais aussi diminuer le prix de son offre pour attirer plus de clients.