Proj-2014-2015-iRock - Revision history

Donsez at 07:45, 9 October 2015

2015-10-09T07:45:24Z

← Older revision		Revision as of 07:45, 9 October 2015
Line 1:		Line 1:
			[[Image:IRock-Prototype-01.jpg\|200px\|right\|thumb\|Prototype de caillou intelligent iRock]]
			[[Image:IRock-Prototype-02.jpg\|200px\|right\|thumb\|Prototype de caillou intelligent iRock]]

	= Introduction =		= Introduction =

RICM4-prj14-grp9: /* Problèmes rencontrés */

2015-03-31T11:42:39Z

Problèmes rencontrés

← Older revision		Revision as of 11:42, 31 March 2015
Line 42:		Line 42:
	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). 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==		==Relais==

RICM4-prj14-grp9: /* Problèmes rencontrés */

2015-03-31T11:40:27Z

Problèmes rencontrés

← Older revision		Revision as of 11:40, 31 March 2015
Line 67:		Line 67:
	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 initiales 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 au niveau de l'économie d'énergie et du respect des normes européennes.

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

RICM4-prj14-grp9: /* Problèmes rencontrés */

2015-03-31T11:39:07Z

Problèmes rencontrés

← Older revision		Revision as of 11:39, 31 March 2015
Line 50:		Line 50:
	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 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.		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==		==Serveur==
	===Objectif:===		===Objectif:===

RICM4-prj14-grp9: /* Objectif: */

2015-03-31T11:29:14Z

Objectif:

← Older revision		Revision as of 11:29, 31 March 2015
Line 53:		Line 53:
	==Serveur==		==Serveur==
	===Objectif:===		===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		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===		===Technologie utilisée===
	Python,InfluxDB,Grafana,Excel,nginx,Mosquitto		Python,InfluxDB,Grafana,Excel,nginx,Mosquitto

RICM4-prj14-grp9: /* Problèmes rencontrés */

2015-03-31T11:28:30Z

Problèmes rencontrés

← Older revision		Revision as of 11:28, 31 March 2015
Line 42:		Line 42:
	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:===

RICM4-prj14-grp9: /* Objectif: */

2015-03-31T11:27:53Z

Objectif:

← Older revision		Revision as of 11:27, 31 March 2015
Line 33:		Line 33:
	==IRock==		==IRock==
	===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 é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)		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		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.		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		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===		===Technologie utilisée===

RICM4-prj14-grp9: /* Partie capteur et acquisition de données */

2015-03-31T11:26:37Z

Partie capteur et acquisition de données

← Older revision		Revision as of 11:26, 31 March 2015
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é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==		==Partie visualisation / stockage des données==

RICM4-prj14-grp9 at 20:45, 30 March 2015

2015-03-30T20:45:54Z

← Older revision		Revision as of 20:45, 30 March 2015
Line 15:		Line 15:
	*''' Répertoire Github''': https://github.com/fpeyre/IRock_2015		*''' 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		*'''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		*'''Scrum''': http://air.imag.fr/index.php/Proj-2014-2015-iRock/Scrum

	= Objectifs=		= Objectifs=
Line 26:		Line 26:

	==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 ê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		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=		=Architecture générale=
Line 32:		Line 32:
	==IRock==		==IRock==
	===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 ~~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)		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		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.		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.
Line 44:		Line 44:
	==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 coût, sa compatibilité avec mbed et la présence d'headers arduino permettant de brancher des ~~extensions~~ arduino		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 ~~utiliseé~~===		===Technologie utilisée===
	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 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.		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==		==Serveur==
	===Objectif:===		===Objectif:===
Line 55:		Line 55:
	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 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 "		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==		==Triangulation==
Line 69:		Line 69:
	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.		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		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.

	= 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

RICM4-prj14-grp9: /* Introduction */

2015-03-30T20:38:51Z

Introduction

← Older revision		Revision as of 20:38, 30 March 2015
Line 1:		Line 1:
	= Introduction =		= 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.		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 =		= Team =