IMA4 2017/2018 P5 : Différence entre versions

De Wiki de Projets IMA
(→‎Semaine 8)
(→‎Feuille d'heures)
Ligne 270 : Ligne 270 :
 
|
 
|
 
| 1H
 
| 1H
 +
| 1H
 +
|
 
|
 
|
 +
|
 +
|
 +
|-
 +
| Informations/Interprétation mesures
 +
|
 +
|
 +
|
 +
|
 +
|
 +
|
 +
|
 +
|
 +
| 1H
 
|  
 
|  
 
|
 
|

Version du 10 mars 2018 à 10:54


Réseau de capteurs de pollution

Présentation générale

Description

Notre projet consiste à réaliser un réseau de capteurs de pollution. Ceux ci permettront, au travers d'une application web et d'une application mobile de visualiser le taux de pollution aux particules fines et polluants chimiques en différents endroits d'une carte. Le capteur devra communiquer en bluetooth avec un téléphone pour envoyer les données récoltées sur le serveur. Nous pourrons ensuite, si le temps nous le permet, ajouter une fonctionnalité permettant d'aider les utilisateurs à trouver les chemins les plus appropriés pour se déplacer en étant le moins exposé possible à la pollution. En effet, l'exposition prolongée à un taux élevé de particules fines réduit l'espérance de vie. Connaitre le taux de pollution est donc un enjeu majeur.

Scénario

Pedro est intolérant aux particules fines et est cependant un grand sportif. Jusqu’à maintenant, il se contentait de courir sur des tapis roulants dans sa salle de sport. Cependant, il se demandait chaque fois quand est-ce qu’il franchirait le pas et irait courir dehors. Cela tombe bien car sa copine vient de lui offrir un capteur de pollution miniature tenant dans sa poche qui lui permet de connaître les endroits non pollués où il peut courir. Des centaines d’utilisateurs l’utilisent en ce moment et leurs données sont renvoyées en temps réel sur la carte de pollution de la ville qui s’affiche sur son smartphone. Il peut également visualiser où se trouvent les personnes disposants du capteur si celles-ci ont décidé de l’autoriser. Dans une prochaine mise à jour, Pedro se réjouit d’avance de pouvoir utiliser son application comme un véritable GPS d’air pur : en rentrant son point de départ et sa destination, il pourra obtenir la meilleure route possible selon ses conditions de tolérance.

Objectifs

  • Élaboration d'un capteur de pollution permettant de détecter différents polluants (particules fines, poussière, résidus de combustion) connecté au réseau LoRaWAN
  • Création d'une application web permettant aux utilisateurs de visualiser les taux de pollution détectés par les capteurs en différents endroits de la ville et de pouvoir déterminer le chemin le plus approprié pour leurs déplacements.
  • Création d'une application mobile avec les mêmes spécificités que le site web
  • Élaboration d'un algorithme de machine learning permettant de déterminer le meilleur chemin selon des anciennes données dans le cas d'une panne des capteurs.

Analyse du projet

Positionnement par rapport à l'existant

Analyse du premier concurrent : Bornes implantées dans la ville

Certaines bornes peuvent permettre d'obtenir la qualité de l'air en dans la ville en temps réel. Cependant, notre projet aura comme avantage de :

  • permettre de connaître précisément le taux de pollution en tous les endroits de la ville et pas seulement en un endroit fixe.
  • D'obtenir le taux de pollution sur son téléphone. Il n'y a donc pas besoin de se déplacer pour le connaître.

Analyse du second concurrent : Applications, sites web indiquant le taux de pollution

D'autres applications et sites web permettent d'obtenir un taux de pollution comme Plume : https://air.plumelabs.com/fr/live/lille Notre projet permettra cependant d'ajouter :

  • La possibilité de connaître la pollution dans des endroits plus précis de la ville contrairement à Plume qui donne une valeur par ville.
  • Permet à l'utilisateur de faire sa propre mesure à l'aide du capteur.

Scénario d'usage du produit ou du concept envisagé

Sur la page d'accueil: les informations générales sur la pollution :

  • La moyenne journalière de pollution sur toute la ville
  • L'évolution de la pollution moyenne sur la semaine, le mois, l'année... (graphique)

Dans les autres onglets :

  • Une carte de la ville de Lille présentant le niveau de pollution en fonction des données relevées sur les capteurs.
  • Une interface permettant à l'utilisateur de rentrer le trajet qu'il souhaite réaliser et qui lui renvoie le meilleur itinéraire

Réponse à la question difficile

Selon certaines documentations, le capteur perd en précision lorsqu'un souffle est appliqué sur le capteur. Il faudrait donc envisager un moyen pour protéger le capteur du vent afin d'obtenir la meilleure précision. Surtout en cas de placement des capteurs sur des véhicules.

Quelle quantité de données sera envoyée par le smartphone et quelle consommation aura le capteur de particule fine ?

  • données doit contenir : la position GPS du capteur, l'heure de la mesure ainsi que la mesure. Cela correspond donc à quelques dizaines d'octets. En fonction du nombre de mesures faites par heure, on peut donc calculer la quantité de données envoyée par heure ou par jour.
  • consommation de la carte :
    • ESP32 : environ 100mA en actif et sinon 4mA en slow speed sleep
    • module GPS : ?????
    • En prenant une batterie de 2000mA pour ne pas qu'elle soit trop encombrante et en prenant en compte une consommation moyenne de 10mA, nous obtenons une autonomie de 140H. Ce qui correspond à 1 semaine d'autonomie.

Préparation du projet

Cahier des charges

Réalisation de la carte du capteur :

Polluants pouvant être analysés :

  • Monoxyde de carbone
  • Dioxyde de carbone
  • Ozone
  • Particules en suspension PM2.5 (particules de diamètre inférieurs à 2,5 micromètres),PM10
  • Dioxyde de souffre

Choix techniques : matériel et logiciel

Capteur :

La raspberry pi peut être remplacée par le module Particle Photon ( Lien [[1]] ) qui comprend un module de données cellulaires qui amortirait le cout d'un dongle. Le kit de développement de Particle comprend une batterie et une carte SIM prépayée ainsi que plusieurs accessoires supplémentaires. Il serait peut être plus raisonnable d'opter pour le kit.

Backend

Application mobile :

  • Java/Kotlin

Application Web :

  • Node/AngularJS : pour améliorer la fluidité du site.
  • Bootstrap/Semantic UI : pour faciliter le développement

Liste des tâches à effectuer

Calendrier prévisionnel

Réalisation du Projet

Feuille d'heures

Tâche Prélude Heures S1 Heures S2 Heures S3 Heures S4 Heures S5 Heures S6 Heures S7 Heures S8 Heures S9 Heures S10 Total
Choix du matériel 2H 1H
Analyse du projet + préparation oral 6H
Création du Back-End de l'application et de l'appli web 2H 5H 6H 5H 3H
Site web 6H 10H 12H 4H
Carte/capteur 3H 2H
Programme ESP32 4H 3H
Documentation (rethinkDB, rabbitMQ) 3H 2H 1H
Documentation (Angular JS, facebook authentification, maps) 1H
Documentation Android 4H 10H 2H
Travail sur l'application Android 6H 2H
Wiki 1H 1H 1H 1H
Informations/Interprétation mesures 1H

Prologue

  • Préparation de l'oral :

Description du projet : quels sont les objectif à remplir, scénario d'usage permettant de se rendre compte de l'utilité du projet et analyse des concurrents pour connaître ce qui existe déjà et savoir ce que nous devons ajouter dans notre projet pour nous démarquer.

  • Choix du matériel et des technologies utilisées
  • Après l'oral : réponse à la question sur l'autonomie de la batterie ainsi que sur la quantité de données envoyées

Semaine 1

  • Vérification du schéma électronique et de la carte permettant d'alimenter et de contrôler notre capteur.

Nous avons finalement changé de batterie. En effet, une batterie de 5V nous paraissait plus adaptée du fait que nous devons alimenter le microcontroleur en 3,7V et le capteur en 5V. Nous obtiendrons un meilleur rendement en réalisant une baisse de tension qu'une augmentation de tension. La batterie sera un peu plus volumineuse mais nous permettra de tenir plus longtemps. Nous avons donc ajouté un connecteur micro-usb que nous souderons sur la carte et qui nous permettra de l'alimenter en 5V.

Semaine 2

  • Documentation sur la base de donnée rethinkDB afin de bien comprendre son fonctionnement ainsi que le gestionnaire de queue de message rabbitMQ.

Ces recherches vont nous permettre d'être plus efficace par la suite et de savoir quel est le meilleur moyen d'utiliser cette base de donnée.

Semaine 3

  • Installation des environnements de travail sur nos ordinateurs ainsi que sur un serveur pour nous permettre de travailler tous les deux sur les mêmes données : tomcat pour le serveur java, rethinkDB pour la base de données.Mais nous avons eu un problème car l'espace disponible sur le serveur que nous possédons n'est pas suffisant.

Début de la programmation du code serveur : Mise en place de l'architecture temps-réel et mise en avant des problèmes à résoudre : documentation sur les queues et les websockets. Problème : réaliser un code en boucle infinie pour pousser les données vers la queue, ou uniquement garder une connection WS active ?


Semaine 4

  • Création de la base de projet web. Nous avons désormais une base de projet tournant avec Node, angular, rethinkdb et avec les fonctionnalités basiques.

Nous avons également étudié la documentation qui va nous permettre d'implémenter une authentification du client via facebook par exemple et d'utiliser l'API de google maps.

  • Durant la séance suivante, nous avons pu utiliser l'api de google maps pour obtenir leur carte sur notre site web. Nous avons pour cela dû nous créer une clé d'identification et insérer leur script dans la page. Puis nous avons ajusté celle ci afin qu'elle prenne l'ensemble de la largeur du site. Enfin, nous avons réussi à manipuler les marqueurs afin de pouvoir indiquer les endroits où des mesures de taux de pollution ont été effectuées. Pour le moment, ces positions ont été fixées manuellement. Mais nous modifierons prochainement le code afin que les données soient récupérées dans la base de données et affichées dynamiquement sur la carte.
  • Réalisation des endpoints REST pour l'utilisateur, mise en place du code associé aux actions sur la base de donnée. Mise en place des moyens de sécurisation (JWT en particulier). Réalisation de testbench pour tester ce qui à été mentionné précédemment.

Début de la réalisation de la partie temps réel.


Semaine 5

  • Ajout de la librairie semantic UI au projet web pour permettre un design plus agréable pour l'utilisateur mais aussi faciliter celui ci. Cependant, nous avons eu quelques problèmes pour faire cohabiter toutes les librairies sur le projet web. Nous avons donc recréé un projet Web fonctionnant avec du javascript classique plutôt que Angular afin d'avoir une interface fonctionnelle le plus rapidement possible. En effet, nous devrons pouvoir faire des tests avec le capteur lorsque nous recevrons les composants. Nous retenterons de faire fonctionner les différents modules tous ensemble sous angular à la fin du projet si le temps nous le permet.
  • Ajout de l'apparition des fenêtres lorsque l'utilisateur clic sur les markers de google maps correspondants aux points de mesure de pollution. Ceux ci indiqueront le taux de pollution calculé pour chaque polluant, la date et l'heure de la mesure ainsi que l'adresse à laquelle elle a été prise. Enfin, nous afficherons le nom et la photo de la personne qui a pris la mesure si celui ci l'accepte.

Nous pourrons également ajouter la météo du moment où la mesure a été prise. En effet, celle ci peut influer sur la précision de la mesure.

  • Nous pourrons également implémenter un système de vérification des mesures prises. Si une données est aberrante par rapport aux données prisent aux alentours par d'autres membres, nous ne la prendrons pas en compte.


Semaine 6

  • Nous avons reçu une partie de notre commande de composants dont l'ESP32. Nous avons donc pu commencer à travailler sur celui ci. Pour le programmer, 3 choix s'offraient à nous :

Nous nous sommes penchés vers cette dernière solution qui étaient celle proposée dans la datasheet de notre composant sur sparkfun. Certaines sources menaient à penser que certaines fonctionnalités n'étaient pas encore implémentées dans le module de développement arduino. Cependant, le projet ayant bien avancé depuis la dernière année, les fonctionnalités dont nous avons besoin (bluetooth) semblent bien présentes. Nous avons donc suivi les quelques étapes décrites sur ce lien pour installer le module supplémentaire sur le logiciel arduino : https://learn.sparkfun.com/tutorials/esp32-thing-hookup-guide?_ga=1.189350435.90086807.1452767181#installing-the-esp32-arduino-core

Nous avons ensuite réalisé le programme permettant d'envoyer les données et de les recevoir via bluetooth sur l'ESP32. Pour cela, nous devons importer les librairies BLE sur arduino. Et au moyen du langage C++ avons défini des fonctions de callback. Celle ci signalent lorsqu'un appareil se connecte ou se déconnecte de l'ESP32. Et signalent également lorsqu'un caractère est reçu. Dans le code principal, nous envoyons un nombre flottant qui s'incrémente toutes les secondes. Et lorsqu'un caractère est reçu, il s'affiche.

Nous avons également commencé l'application android permettant de communiquer avec l'ESP32. Celle ci est pour l'instant minimaliste et ne permet que de se connecter à notre microcontrôleur, d'envoyer des données en appuyant sur un bouton ou d'en recevoir à l'aide d'un autre bouton. Cela nous a donc permis de vérifier que le système de communication bluetooth fonctionne. Pour réaliser notre application et faire fonctionner la librairie BLE bluetooth d'android, il ne faut pas oublier de demander les permissions pour le bluetooth et la localisation qui sont indispensables. Par la suite, nous modifierons l'application android pour n'avoir qu'un seul bouton pour demander une mesure et l'afficher. Le code de l'arduino lui devra se mettre en attente tant qu'un caractère précis n'est pas reçu. Puis, lors de sa réception, communiquera avec notre capteur de pollution pour récupérer les données et les envoyer sur l'application android.

Voici le résultat sur la vidéo suivante, qui démontre que la connexion entre notre microcontroleur et l'appli android fonctionne :

Quant au coté serveur, les appels permettant de récupérer l'ensemble des données de l'air ou plus de détails sur une donnée particulière ont été réalisés. Nous avons également mis en place le serveur websocket. Plus de documentation est nécessaire car nous ne savons toujours pas si l'API websocket gère les threads par elle même. Dans le cas contraire, il sera nécessaire de mettre en place un système de multithreading. Pour le moment, les sockets sont disposés sur deux threads. Un thread principal qui permet de recevoir les données du client (par exemple des données de l'air) et un thread secondaire, connecté aux changefeeds de rethinkdb, qui permettent de pousser tout changement sur la table vers un curseur infini. Lors de chaque changement du changefeed, les données sont envoyées aux clients. Ils sont d'abord traités par un décodeur qui permet de parser le JSON reçu, composé d'un champ old_val et new_val. Afin de simplifier, nous ne renvoyons que le champ non vide. Dans le cas ou les deux sont remplis, nous renvoyons les deux champs afin de comparer l'ancienne et nouvelle valeur.

Semaine 7

screen du site web
  • Le site web récupère désormais les données issues de l'API REST. Nous utilisons pour cela les xhtmlHTTPrequest. Cette connexion est pour l'instant effectuée en localhost en faisant tourner en paralèlle la base de données rethinkDB ainsi que l'API REST. 2 requêtes sont alors nécessaires pour récupérer tous les points de mesure présents dans la base de données :

- La première requête à l'adresse "http://localhost:8080/unwheeze/auth/clientToken" avec le header 'Authorization':'Basic -token-' pour récupérer une API key qui sera utilisée dans la requête suivante. - La deuxième requête à l'adresse "http://localhost:8080/unwheeze/airData/getAirCollection" avec le header 'X-Api-Key': -API key-.

Ces deux requêtes sont effectuées de manières synchrone car nous avons besoin que celles ci soient effectuées afin de pouvoir continuer le reste du processus. Mais nous pourrons l'améliorer en l'utilisant de manière asynchrone. De plus, pour effectuer des requêtes en local, nous avons remarqué que nous devions lancer le navigateur en désactivant les sécurité. Par exemple : chromium-browser --disable-web-security --user-data-dir sur ubuntu avec chromium.

  • Nous utilisons désormais Highchart pour afficher des graphs sur notre site web. Ces graphs afficherons l'évolution de la pollution au cours du temps au niveau du point cliqué par l'utilisateur. Ces graphs devront donc être modifiés pour prendre en compte les différents points de mesure de pollution se trouvant aux alentours du point cliqué durant les dernières 24H par exemple. Ceci fera donc l'objet d'une nouvelle requête à l'API Rest pour récupérer l'ensemble des points de mesures à afficher sur les graphs lors d'un clic.

Le point délicat étant de pouvoir retrouver quel point de mesure a été cliqué par l'utilisateur et pouvoir envoyer une requête appropriée à l'API. Nous voulons également laisser à l'utilisateur le choix de l'étendue des points qu'il souhaite comparer ainsi que la durée temporel sur laquelle il souhaite voir l'évolution de la pollution. L'affichage des graphs nécessite un bon moment de documentation quant a l'utilisation de l'API de Highchart.

  • Nous avons également implémenté une Heatmap sur la carte google map. Celle affichera en rouge les points avec le plus de pollution et en vert les zones les moins polluée et à privilégier par l'utilisateur.

Semaine 8

  • Nous avons reçu notre capteur et avons commencé à l'utiliser grâce à un Arduino pour le tester. Nous avons bien réussi à récupèrer les valeurs et sommes donc passé à l'ESP32. Nous avons alors dû réaliser le programme qui attend de recevoir un caractère par bluetooth depuis le téléphone pour envoyer les valeurs du capteur de pollution sur le téléphone. Nous arrivons alors à nous connecter, et recevoir sur les 3 champs différents les valeurs de PM10 PM2.5 et PM01 comme le montre la vidéo suivante :

/////////////////video////////////////////

Cependant, notre programme devra utiliser le pin SET du capteur de pollution pour le laisser en mode faible consommation d'énergie tant que nous ne l'utilisons pas.

  • Nous avons également apporté des modifications au site web afin de faire des ajustements esthétiques et permettre d'afficher les graphiques selon l'intervalle de temps et la distance choisie par l'utilisateur.
  • Enfin, nous avons pu contacter une personne s'occupant de l'analyse des données de pollution sur Lille qui nous a expliqué comment vérifier les valeurs obtenues sur notre capteur. En effet, 2 stations de mesures sont disponibles sur Lille. Une stations de à proximité du traffic : Boulevard de Leeds 59700 Lille à coté du Crown Plaza et une station bruit de fond à coté de l'école Lakanal à fives (Groupe Lakanal Campau - Rue du long Pot 59800 Lille Fives).

Les valeurs sont prises à hauteur d'homme pour simuler au mieux la pollution à laquelle un être humain peut être exposé en ville.

Nous devrons donc vérifier si notre capteurs ne sous estime pas la pollution en ville ou au contraire ne les surestime pas. En effet, pour l'instant, nous avons seulement pu vérifier superficiellement que les valeurs étaient correctes. Dans notre maison, les valeurs sont entre 0 et 8 pour chaque polluant alors que à coté du pot d'échappement d'une voiture, nous arrivons jusqu'à des valeurs de 127ug/m3. Lorsque notre projet sera plus avancé, nous ferons donc les mesures juste à coté de ces deux stations afin de vérifier la précision de nos mesures et de vérifier que notre capteur est bien précis en comparant les valeurs avec celles disponibles sur le site de l'ATMO : http://www.atmo-hdf.fr/acceder-aux-donnees/mesures-des-stations.html

Documents Rendus

Récupérée de « https://projets-ima.plil.fr/mediawiki/index.php?title=IMA4_2017/2018_P5&oldid=53040 »