Proj-2014-2015-iRock: Difference between revisions

From air
Jump to navigation Jump to search
No edit summary
No edit summary
Line 20: Line 20:
==Partie capteur et acquisition de données==
==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ée 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.
Cette partie consiste à prendre en main la technologie LoRA et à l'utiliser combinée à d'autres cartes embarquées bardée 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==
==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)
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==
==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 etre réaliser au millimétre (un mouvement de terrain est annoncé notamment par des pré glissement dont la taille ne fait que quelques centimètre). Nous souhaitons ne pas utiliser de GPS pour des questions de coût et d'économie énergétique
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é glissement dont la taille ne fait que quelques centimètre). Nous souhaitons ne pas utiliser de GPS pour des questions de coût et d'économie énergétique


=Architecture générale=
=Architecture générale=
Line 33: Line 33:
===Objectif:===
===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 été d'utiliser une station kerlink pour la réception des données et leur envoie sur le serveur.
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 été 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 embarqués plusieurs capteurs comme des accélérométres ou des gps et contient plusieurs exemple pré-compilé dont un tilt (la carte envoit 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 etaient rédhibitoire en début de projet (pas de communication avec la kerlink de possible)
La première carte utilisée fut une waspmote Libelium. Ces cartes peuvent embarqués plusieurs capteurs comme des accéléromètres ou des gps et contient plusieurs exemple pré-compilé dont un tilt (la carte envoi 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
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 concue pour Arduino sur STM32.
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 éffectué, il nous faut choisir nos cartes de capteurs. Nous avons optés pour des STM32 discovery F3/F4 embarquant un processeur STM32 et des capteurs (magnétométre ou accélérométre). Enfin nous réalisé à la fablab un moule pour le coffrage en béton contenant nos futures cartes
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 réalisé à la fablab un moule pour le coffrage en béton contenant nos futures cartes


===Technologie utilisé===
===Technologie utilisé===
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
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===
===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)
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)
==Relais==
==Relais==
===Objectif:===
===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 cout, sa compatibilité avec mbed et la présence d'headers arduino permettant de brancher des extensions arduinos
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 extensions arduino
===Technologie utilisé===
===Technologie utilisé===
stm32 nucleo L152RE,sparkfun weather shield, mbed LoRA,mbed
stm32 nucleo L152RE,sparkfun weather shield, mbed LoRA,mbed
===Problémes rencontrés===
===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 fournit 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 % ,...)dés que nous branchions la mbed LoRA en plus, larte 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 aberante (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.
Le principale problème rencontré est le portage de la weather shield d'arduino à mbed. Nous avons un code de base arduino fournit 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 aberante (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==
==Serveur==
===Objectif:===
===Objectif:===
Installer InfluxDB,un serveur web nginx,grafana,mosquitto ,et ecriture des scrypts python pour transmettre les données de la mbed de recption au pc de reception (par le port serial), du pc recepteur 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 achine Amazon
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é===
===Technologie utilisé===
Python,InfluxDB,Grafana,Excel,nginx,Mosquitto
Python,InfluxDB,Grafana,Excel,nginx,Mosquitto
===Problèmes rencontrés===
===Problèmes rencontrés===
Pas de problémes rencontrés dans cette partie. On utilise un systeme de requette 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 etre entourré de "
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 etre entourré de "


==Triangulation==
==Triangulation==
Line 63: Line 63:
Python
Python
===Problèmes rencontrés===
===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 initales du projet:
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:


=Conclusion générale/ Perspective d'évolution=
=Conclusion générale/ Perspective d'évolution=

Revision as of 08:47, 25 March 2015

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 en géotechnique et en informatique, 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

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ée 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é glissement dont la taille ne fait que quelques centimètre). 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 été 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 embarqués plusieurs capteurs comme des accéléromètres ou des gps et contient plusieurs exemple pré-compilé dont un tilt (la carte envoi 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 réalisé à la fablab un moule pour le coffrage en béton contenant nos futures cartes

Technologie utilisé

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)

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 extensions arduino

Technologie utilisé

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 fournit 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 aberante (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é

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 etre entourré 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:

Conclusion générale/ Perspective d'évolution

Progress of the project

The project started January 14th, 2013.

Week 1 (January 26th - Janurary 30th)

  • Project discovery
  • Technologies and sensors discovery
  • Meeting with tutors and tearchers to define the project