Proj-2014-2015-iRock
Introduction
Ce projet consiste à développer une application permettant de gérer un réseau de capteurs visant à prévenir des glissements de terrain dans les zones sensibles. Son déroulement comprend toute les étapes, de la conception à la réalisation, en terminant par le test de notre application dans des conditions réelle et la visualisation des données collectées. Ce projet va donc à la fois demander des compétences géotechniques et informatiques, notamment en visualisation de données.
Team
Au cours de ce projet, nous sommes accompagnés par 3 enseignants de la filière géotechnique (Denis Jongmans, Laurent Baillet, Bievre Grégory), 1 enseignant en visualisation de la filière RICM (Georges-Pierre Bonneau), ainsi qu'un enseignant de l'iut de Valence qui fabrique les cartes nécessaires aux "cailloux", et enfin notre encadrant : Donsez Didier. Notre équipe est constituée de 5 étudiants : 2 dans la spécialité multimédia de RICM5 (Peyre Flavien et Ginoux Pierre-Henri), 2 dans la spécialité réseau (Boey Lionel et Guo Tianmming) et un élève de Master I en informatique (Nizamouddine Ganjat). Le coordinateur pour ce projet sera Peyre Flavien.
Département : RICM 5, Polytech Grenoble
Links
- Notre SRS : http://air.imag.fr/index.php/Proj-2014-2015-iRock/SRS
- Répertoire Github: https://github.com/fpeyre/IRock_2015
- Diagrammes UML: http://air.imag.fr/index.php/Proj-2014-2015-SmartCampus2015#G.C3.A9nie_Logiciel
- Scrum: http://air.imag.fr/index.php/Proj-2014-2015-iRock/Scrum
Objectifs
Partie capteur et acquisition de données
Cette partie consiste à prendre en main la technologie LoRA et à l'utiliser combinée à d'autres cartes embarquées bardées de capteurs (F3 /F4 discovery) pour remonter leurs données. Nous avons également besoin de relais fixe pour la triangulation. Ces relais font office de stations météo via des cartes weather shield de sparkfun. Le protocole LoRA utilisant des bandes de fréquence radio publique, il est également important que nos communications soient cryptées et respectent les normes européennes (notamment au niveau du duty cycle). De plus nous avons plusieurs conditions pour ces IRock et relais. Nous devons avoir une très faible consommation électrique (un IRock doit pouvoir fonctionner 3 ans sans changer sa batterie). Notre objectif est aussi de minimiser le coût de fabrication des IRock. Nous devons également réaliser la boite embarquant les cartes sur le terrain.
Partie visualisation / stockage des données
Cette partie est le coté applicatif de IRock.Nous utilisons des scripts Python pour stocker les données dans une base de données InfluxDB combinée à Grafana pour la visualisation. De plus un système d'export en fichier Excel à été mis en place ,pour avoir accès simplement aux données brutes via des logiciels comme Matlab (utilisé notamment par les géotechniciens)
Partie triangulation / localisation des IRock
La donnée la plus importante pour les géotechnicien est la position exacte de l'IRock. Cette localisation doit être réaliser au millimètre (un mouvement de terrain est annoncé notamment par des pré-glissements dont la taille ne fait que quelques centimètres). Nous souhaitons ne pas utiliser de GPS pour des questions de coût et d'économie énergétique
Architecture générale
IRock
Objectif:
Cette partie est la base de notre projet. Nous savions au départ que nous devions utiliser la technologie LoRA pour les communications. Mais plusieurs cartes embarquées pouvaient permettre d'utiliser cette technologie. Un autre objectif était d'utiliser une station kerlink pour la réception des données et leur envoie sur le serveur. La première carte utilisée fut une waspmote Libelium. Ces cartes peuvent embarquer plusieurs capteurs comme des accéléromètres ou des gps et contienent plusieurs exemple pré-compilé dont un tilt (la carte envoie un message dés qu'elle est en mouvement). Cette carte semblait nous convenir, mais son coût et le fait que des libeliums ne communiquent qu'avec d'autres libelium étaient rédhibitoire en début de projet (pas de communication avec la kerlink de possible) Nous avons ensuite utilisé les cartes LoRA Fabian. Mais la librairie permettant leur programmation étant inaccessible (la page du github menait vers un 404:not found), nous ne pouvions pas les utiliser Enfin nous avons utilisé les cartes mbed LoRA de semtech,qui nous semble le meilleur choix pour ce projet. Il faut cependant porter les weather shield initialement conçuent pour Arduino sur STM32. Une fois le choix de la carte pour LoRA effectué, il nous faut choisir nos cartes de capteurs. Nous avons opté pour des STM32 discovery F3/F4 embarquant un processeur STM32 et des capteurs (magnétomètre ou accéléromètre). Enfin nous avons réalisé à la fablab un moule pour le coffrage en béton contenant nos futures cartes
Technologie utilisée
mbed LoRA, stm32 F3 discovery, stm32 F4 discovery, mbed/Keil pour la programmation/flashage des cartes, inkscape et la découpeuse laser pour le moule du coffrage en béton de la boite
Problèmes rencontrés
Le principal problème rencontré est la compatibilité entre les cartes Discovery et la LoRA mbed. En effet , les discovery ne se flashent que via l'ide Keil. Or les cartes mbed LoRA utilisent la bibliothèque mbed.h propre à l'ide mbed. Cette bibliothèque n'existe donc que pour des cartes de type sm32 nucleo ou étant mbed enabled. De plus, après présentations du projet final aux professeurs de géotechnique, une réserve à était émise sur la résistance des capteurs aux conditions de température que peut rencontrer le cailloux (plus de 40° à l'intérieur de la boite en béton si celle ci est dehors exposée au soleil en plein été ne parait pas impossible). Les fonctions de cryptage ont été mise en place mais un problème persiste. Un message cryptée sur une carte A est bien décrypté sur cette même carte A. Par contre si il est envoyé sur une carte B pour y être décrypté, cela ne marche pas malgré que le message reçu sur la carte B soit identique au message envoyé par la carte A.
Relais
Objectif:
La principale fonction du relais est de récupérer le signal envoyé par les IRock, de mesurer sa force et de l'envoyer ensuite à la station réceptrice.Sa position étant fixe, cette donnée nous est utile pour la triangulation. Ces relais peuvent également faire office de station météo avec l'utilisation de sparkfun weather shield , permettant de mesurer la température, l'humidité, le vent et pluviométrie. La carte embarquant le processeur est une stm32 nucléo . Nous avons choisi cette carte pour son coût, sa compatibilité avec mbed et la présence d'headers arduino permettant de brancher des cartes d'extension arduino.
Technologie utilisée
stm32 nucleo L152RE,sparkfun weather shield, mbed LoRA,mbed
Problèmes rencontrés
Le principale problème rencontré est le portage de la weather shield d'arduino à mbed. Nous avons un code de base arduino fourni par le constructeur utilisant tout les capteurs, calculant toutes les données et les affichant via le port serial. Comme toute les librairies propres à chaque capteurs de la carte existent sous mbed,le travail à effectuer nous paraissait simple. Une fois le code crée, la carte nous donne des données étrange (une température de 11 degrés Fahrenheit, une humidité constante de 5% ,...).Dés que nous branchions la mbed LoRA en plus, la carte refusait tout simplement de se flasher ou de s'allumer , malgré le remappage des pins communes aux deux cartes. Il s’avère que vers la fin du projet, nous avons réussi à utiliser les deux cartes en même temps, mais en utilisant que 2 capteurs de la weather qui nous donne des valeurs encore plus aberrante (taux d'humidité négatif par exemple). Une librairie mbed vérifiant l'état des cartes d'extensions stm32 nous donne une erreur au niveau de l'I2C ,utilisé pour communiquer entre la weather et la nucleo.
Serveur
Objectif:
Installer InfluxDB,un serveur web nginx,grafana,mosquitto ,et écriture des scrypts python pour transmettre les données de la mbed de réception au pc de réception (par le port serial), du pc récepteur au serveur (via MQTT) et pour enregistrer les données dans InfluxDB et créer un fichier Excel par carte. L'installation du serveur est sur une machine Amazon.
Technologie utilisée
Python,InfluxDB,Grafana,Excel,nginx,Mosquitto
Problèmes rencontrés
Pas de problèmes rencontrés dans cette partie. On utilise un système de requête html pour envoyer les donnés au serveur InfluxDB. Il faut donc faire attention au moment de l'écriture des objets JSON à envoyer au serveur (notamment le fait que les string doivent être entouré de " )
Triangulation
Objectif:
Réussir via triangulation à localiser chaque IRock. La précision doit être de l'ordre du cm voir du mm. Nous nous sommes basé sur le papier suivant : http://www.ece.umd.edu/~cpap/published/cpap-franco-rt-08.pdf
Technologie utilisé
Python
Problèmes rencontrés
Comme l'annonce le papier, nous pouvons espérer au maximum 7% de précision de la distance entre le IRock et le relais, ce qui est insuffisant. (sur nos test théorique en X/Y, un point avec x=300 est localisé en X=326). Une amélioration implique un étalonnage basé sur de nombreux échanges (plusieurs centaines) entre les IRock et les relais sur des canaux différent. Cela implique également des messages envoyé depuis le serveur aux relais/IRock pour leur dire de changer de canal.Cela nous semble contradictoire avec les conditions initiales du projet au niveau de l'économie d'énergie et du respect des normes européennes.
Conclusion générale/ Perspective d'évolution
Pour nous, vu que les positions semblent être les données les plus importantes (comparé aux accéléromètres et magnétomètre), la solution serait d'utiliser des gps pour chacun des IRock crée et de renvoyer leur position. En effet on peut estimer que entre l'atténuation entre un IRock et un satellite, et un relais et un satellite est quasiment identique si le relais et le cailloux sont assez proche. Comme le relais est fixe, nous pouvons calculer cette erreur entre la position réelle et la position retournée par le gps et l'appliquer aux données envoyé par le gps de l'IRock.
Une amélioration du projet serait d'automatiser les alertes via l'envoi d'un mail/message quand un IRock bouge, ainsi que de réussir à utiliser une technique de cryptage/décryptage des données envoyés pour etre en accord avec les normes européennes sur l'utilisation des fréquence radios publique.