Difference between revisions of "Proj-2014-2015-iRock"
| 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 |
+ | 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 |
+ | 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 |
+ | 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 |
+ | 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 |
+ | 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 |
+ | 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 |
+ | 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 |
+ | 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 |
+ | 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 |
+ | 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 |
+ | 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 10: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
- 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é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