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 (SO₂), dioxyde d'azote (NO₂), ozone (O₃), 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.

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, CO₂, microparticules)

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 l'Arduino et la programmation des capteurs en Python (nécessaires à l'acquisition des données de certains capteurs) aient déjà été réalisées avant notre arrivée. Nous devons donc 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 :

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éré 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

Le lundi nous avons poursuivi notre documentation sur le sujet pour ensuite aller le mercredi à l'INRIA faire fonctionner Télégraf. Nous avons alors eu un problème qui s'est posé, en effet Télégraf n'est pas adapté à une base SQLite comme celle utilisée dans la Rasp Pi. Nous avons donc essayé de faire deux choses :

changer la base SQLite mais nous ne connaissions pas les conséquences sur le reste du programme se servant d'une librairie propre à SQLite et de plus, nous avons eu du mal à trouver un convertisseur valable. L'exportation était simple à réaliser mais il aurait fallu modifier les fichiers en interaction avec la base car ils se servaient de bibliothèques sqlite3.h , cela aurait pu entrer en conflit avec le reste du programme que nous ne maîtrisons malheureusement pas complètement.

   Manipulation pour changer la base SQLite en MySQL : 
         exporter la base en fichier .dump puis utiliser le  script python qui remplace les marqueurs SQLite par des marqueurs MySQL pour enfin réimporter la base au format MySQL.

créer un fichier .conf prenant en charge la base SQLite en input. Mais la aussi nous ne disposions pas des connaissances nécessaires à sa réalisation. En effet, d'après ce que nous avons pu observer, les fichiers d'input disponibles sur le git de telegraf sont uniques et ont peu de points commun entre eux.

Nous avons donc continué de perdre bêtement du temps sur cette idée qui de plus est lourde à supporter pour une Rasp Pi.

Semaine 4

Nous avons pu récupérer 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.
L'envoi des données sur le serveur se fera via une requête REST (à détailler) à l'aide de cURL.

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)

Semaine 6

Nous nous sommes intéressés à deux solutions pour envoyer les données sur influxDB :
• la requête cURL en Bash permettant d'envoyer jusque 5 000 données comprises dans un fichier, par exemple un fichier texte nommé sensors_data.txt sur le port d'écoute de l'application influxDB, à savoir le port 8086 de apolline.lille.inria.fr dans notre cas. Nous aurons donc une commande du type suivant :

curl -i -XPOST 'http://apolline.lille.inria.fr:8086/write?db=airquality' --data-binary @sensors_data.txt

L'intérêt de cette méthode serait d'envoyer les données de la base de données SQLite sur un fichier sql au travers des commandes suivantes :

.output airquality.sql
.dump airquality.sql

avant de passer ce fichier sql à la commande curl pour envoyer les différentes données sur l'application.

• via un script Javascript permettant d'envoyer les données des différentes séries sur l'application.

Dans le but de tester l'efficacité de la commande bash qui semble être la plus simple et la plus efficace, nous avons installé les différentes applications utilisées que sont influxDB et Grafana dans le but de reproduire le système étudié et de pouvoir le manipuler sans aucun risque. De cette manière, nous devrions pouvoir tester l'envoi et la réception de données sur influxDB, et la visualisation de celles-ci sur Grafana.

IMA4 2017/2018 P49

Sommaire