IMA4 2017/2018 P49
Sommaire
Présentation générale
- Nom du projet : Station Modul'Air
- Résumé : Développer l'aspect modulaire de la station de suivi de la qualité de l'air conçue par des laboratoires de recherche tout en améliorant le système initial et en permettant une installation rapide des prochains nœuds de contrôle.
- Membres du projet : DELBROUCQ Hugo et HAVARD Nicolas
- Superviseurs du projet : KASSI Redha (IRCICA) et ROUVOY Romain (INRIA)
Description
Lors de précédents projets, une station de contrôle de la qualité de l'air a été conçue afin d'étudier l'air au sein du campus de l'Université de Lille. La station initiale comporte de multiples capteurs : CO, CO2, microparticules, composé organique volatil par exemple pour étudier l'air, mais aussi des capteurs de bruit, de présence, de température ou de pression pour enregistrer les conditions des prises de mesures.
Cependant, réaliser un contrôle de la qualité de l'air en un seul point peut avoir un intérêt limité. Notre projet consiste donc à faciliter la mise en place des futurs systèmes et à permettre à ceux existant d'être mis à jour à distance. Le réseau de nœuds de capteurs devra communiquer avec une application web centralisée à l'INRIA permettant de visionner les différentes données au cours du temps et ce pour chaque nœud. De plus, les capteurs des stations doivent pouvoir être permutés facilement, au gré de l'opérateur, pour modifier la nature des données mesurées sans passer plusieurs heures à reconfigurer le système.
Objectifs
- Faciliter l'installation de nœuds pour que les opérateurs n'aient que quelques lignes de commandes à taper pour rendre le système opérationnel
- Permettre la mise à jour à distances de tous les nœuds simultanément
- Permettre un aspect modulaire de la station, en rendant les capteurs 'plug and play' avec le minimum possible d'activité humaine pour changer les configurations
Analyse du projet
Positionnement par rapport à l'existant
Il existe déjà une version de ce projet existant réalisé par d'autres étudiants. Néanmoins, celui ci n'est pas satisfaisant car il ne fonctionne que sur un seul nœud. De plus les données sont stockées en local et non en ligne ce qui rend difficile la visualisation de ces données par un tiers. C'est pourquoi il va falloir remanier le code afin de permettre cela. De plus, les différents capteurs doivent être modulables. C'est à dire que si l'on modifie leur place sur la maquette, il faut un système permettant la reconnaissance du capteur placé au préalable.
Analyse du premier concurrent
Atmo Hauts-de-France est une association de surveillance de l'air qui mesure le taux de dioxyde de soufre (SO2), dioxyde d'azote (NO2), ozone (O3), les poussières (PM10 et PM25) ou encore la radioactivité de l'air dans le nord de la France et partage les données sur leur site internet en donnant un indice compris entre 1 et 10 pour aider les néophytes à comprendre le niveau de l'air actuel.
Analyse du second concurrent
Notre second courant est Foobot, une entreprise ciblant avec ses produits les ménages. Cette société propose une station de contrôle de la qualité de l'air dont les données sont accessibles depuis une application sur téléphone. Cet outil a pour but de renseigner l'utilisateur sur les problèmes qui apparaissent en cas de mauvaise qualité de l'air, les causes possibles et les démarches à réaliser afin de prévenir d'autres problèmes pouvant apparaître. Pour y parvenir, il mesure différents taux dans l'air tels que les COV (composés organiques volatils), les particules fines, la température et l'humidité et déduit de ces données des comportement à établir grâce à des modèles mathématiques.
Scénario d'usage du produit ou du concept envisagé
Donald veut importer des bananes depuis l'Afrique afin de les vendre plus cher pour devenir millionnaire (et peut être même président ensuite !). Son seul et unique but est donc de se faire le plus de marge possible. Néanmoins, il souhaite que ses clients continuent d'acheter ses bananes, et se soucie donc de la qualité de celles-ci à leur arrivée. Il s'intéresse en particulier à la qualité du transport de ces bananes.
Lorsqu'il demande à ses partenaires de lui fournir des informations en temps réel de la qualité de ses bananes lors de leur transport, ces derniers ne savent pas quoi lui répondre. Malheureusement pour ses partenaires, Abdel et Kader, cette contrainte est très problématique car ils ne connaissent aucun moyen de contrôler la qualité des bananes en temps réel dans le réseau de transport. C'est pourquoi ils demandent à des étudiants de Polytech Lille de résoudre leur problème. Heureusement pour eux, l'INRIA et l'IRCICA possèdent déjà un prototype d'une station de suivi de la qualité de l'air. Ils se mirent donc à travailler dans le but de satisfaire leur demande pour que Donald devienne très riche pour construire un joli mur autour de sa maison.
Réponse à la question difficile
Préparation du projet
Cahier des charges
Choix techniques : matériel et logiciel
- Choix Technique :
- Remplacement des programmes en C++ par du NodeJS : le NodeJS est en effet plus adapté pour notre utilisation avec les échanges entre les noeuds et le serveur puisqu'il fonctionne de manière asynchrone, ainsi que pour afficher en temps réel les données sur l'application web dédiée à la visualisation des données récoltées par les différents noeuds.
- Remplacement des programmes en C++ par du NodeJS : le NodeJS est en effet plus adapté pour notre utilisation avec les échanges entre les noeuds et le serveur puisqu'il fonctionne de manière asynchrone, ainsi que pour afficher en temps réel les données sur l'application web dédiée à la visualisation des données récoltées par les différents noeuds.
- Choix Matériel :
(ce matériel nous a été fourni par l'IRCICA/INRIA soudé à une maquette déjà conçue par de précédents projets)
- 1 * Raspberry Pi 3
- 1 * Arduino Mega
- 1 * Capteur de mouvement PIR
- 1 * Capteur de température, pression et humidité
- 1 * Capteur de bruit
- 1 * Set de capteurs chimiques Alphasense (CO, CO2, microparticules)
- 1 * Raspberry Pi 3
Liste des tâches à effectuer
Dans un premier temps, nous allons nous concentrer sur la partie informatique du projet en récupérant le code existant sur le prototype et en le transférant sur un dépôt Git. Nous aurons ainsi à disposition un dépot Git pour le code et la configuration du Raspberry Pi et un autre pour le programme Arduino.
Ensuite, il est prévu de permettre l'envoi de donnée via différents protocoles comme le WiFi, l'Ethernet, le Bluetooth, le LoRa ou encore le Zigbee afin de permettre plus de libertés à la station et pousser l'idée de la modularité sur l'envoi des données.
Enfin, si nous y arrivons, il serait envisageable de pousser la modularité sur les composants du systèmes en ajoutant la possibilité de retirer la Raspberry Pi ou l'Arduino et de les remplacer par d'autres cartes.
Calendrier prévisionnel
Pour les vacances de Février, nous pensons que nous aurons fini de trier le code existant et que nous aurons ajouté ce code sur les dépôts Git dédiés. Nous projetons de plus avoir bien avancé dans la traduction du code C++ et avoir implanté les quelques fonctionnalités demandées pour le Raspberry comme la possibilité d'éteindre proprement la machine à l'aide d'un bouton entre autre.
Réalisation du Projet
Feuille d'heures
Tâche | Prélude | Heures S1 | Heures S2 | Heures S3 | Heures S4 | Heures S5 | Heures S6 | Vacances Février | Heures S7 | Heures S8 | Heures S9 | Heures S10 | Heures S11 | Heures S12 | Heures S13 | Heures S14 | Heures S15 | Total |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Analyse du projet | 3h30 | 8h30 | 6h | 6h | 3h30 | 6h | 2h |
Prologue
Nous nous sommes rendus à deux reprises dans les laboratoires de l'IRCICA puis de l'INRIA afin d'en apprendre plus sur notre projet et de comprendre ce que nos clients attendaient de nous. Nous avons aussi profité de ces visites pour voir la maquette déjà conçue sur laquelle nous allons travailler, et récupérer les codes de l'Arduino et du Raspberry. De plus, il semblerait que les parties électroniques comprenant arduino et python (nécessaires à l'acquisition des données de certains capteurs) aient été déjà réalisées avant notre arrivée. Notre travail commence donc par réaliser l'architecture logicielle du projet afin de comprendre ce que la personne nous précédant a réalisé ainsi que l'architecture adaptée à plusieurs nœuds que nous avons donc à faire.
Semaine 1
Durant la première semaine, nous avons tout d'abord rattrapé notre retard sur la rédaction du Wiki. Nous avons aussi pu analyser le code du premier nœud de notre système qu'il nous faut encore ajouter au git du projet afin de clarifier son fonctionnement :
--git partie arduino
--git partie rasberry et communication
De plus, nous avons aussi établi le fonctionnement du mode de communication entre les différents nœuds et notre interface. En effet, l'utilisation de telegraf permet de traiter les données de chaque nœud facilement pour ensuite les centraliser sur influxdb qui les stocke dans une base de données pour ensuite envoyer ces données à grafana qui est un logiciel permettant des simulations graphiques et la possibilité d'utiliser un interface agréable.
Collecte :
On peut voir sur la partie Telegraf que l'outil fonctionne par scrutation. Il demande d'abord au nœud à un intervalle de 30s les données qu'il renvoie une donnée correspondant à la moyenne des données prélevées par le nœud lors de ces 30s. Cela permet d'éviter des écarts trop important ne reflétant pas la réalité.
Base de données :
Fonctionement du réseau nœud/interface
Semaine 2
• Nous avons profité de ce début de semaine pour préparer l'installation de Telegraf que nous espérions terminer mercredi. Nous avons donc repérer les fichiers de configuration et ce qu'il nous fallait y mettre dedans, ainsi que la procédure d'installation du paquet sur la Raspberry.
• Le mercredi après-midi, nous avons pu installer Telegraf sur la Raspberry basée à l'INRIA et avons commencé à configurer ce dernier pour qu'il fonctionne avec la base de données en temps réel située sur le serveur de l'INRIA et avons du effectuer différents paramétrages de la Raspberry pour que le système fonctionne correctement.
Semaine 3
Cependant, bien que Telegraf peut recevoir en entrée une impressionnante quantité de base de données pour envoyer le contenu sur influxDB, le choix de SQLite pose problème
Semaine 4
- Nous avons pu récupéré une Raspberry Pi afin d'effectuer des tests en dehors du laboratoire et obtenir ainsi plus d'indépendance. La Raspberry n'ayant aucun rapport avec les projets existant à l'INRIA, et ne connaissant pas les mots de passe de la machine, nous avons du réinstaller le système d'exploitation Raspbian sur la carte avant d'installer les mises à jours pour partir sur une bonne base.
- Recherches de compatibilités entre Telegraf et SQLite - Abandon de la solution Telegraf car inadaptée à notre architecture
Semaine 5
Suite à l'abandon de Telegraf, nous avons choisi de partir sur une solution constituée d'un script C lancé par un Cron de la Raspberry pour lancer de manière asynchrone les données non envoyées par le noeud sur le serveur de l'INRIA.<\ BR>
L'envoi des données sur le serveur se fera via une requête REST (à détailler) à l'aide de cURL. <\ BR>
Dans le but de conserver le choix de nodeJS, le script C sera remplacé par un script Javascript, avec le framework NodeJS. Pour cela, nous nous inspirerons du paquet Node-influx (git du paquet ici)