R'Montagne

From air
Jump to: navigation, search

Équipe

Étudiant Rôle
Hugo Amodru-Favin Chef de Projet
Antoine Delise Lead Developer
Gwenaël Moreau Kanban Master

Tâches

Répartition générale des tâches

Étudiant Tâche
Hugo Amodru-Favin Application Ionic
Antoine Delise Développement Arduino
Gwenaël Moreau BDD - API

Détail des tâches : Waffle.io

Journal

Date Hugo AMODRU-FAVIN Antoine DELISE Gwenaël MOREAU
Semaine 1
Lundi 29/01/18
  • Ré-assimilation du sujet
  • Ré-assimilation du sujet
  • Ré-assimilation du sujet
  • Mise en place d'un Kanban
Mardi 30/01/18
  • Mise à jour de la page AIR
  • Réflexions sur l'implémentation du LoRa
  • Mise à jour de la page AIR
  • Réflexions sur l'implémentation du LoRa
  • Mise en place du calendrier prévisionnel
  • Définition et répartition des tâches
Mercredi 31/01/18
  • Récupération des cartes Semtech
  • Présentation du Hackathon Vinci Energies
  • Prise en main des cartes LoRa
  • Récupération des cartes Semtech
  • Présentation du Hackathon Vinci Energies
  • Prise en main des cartes LoRa
  • Recherche d'un environnement de programmation gratuit utilisable pour le projet
  • Récupération et prise en main des cartes Semtech LoRaMote
  • Présentation du Hackathon Vinci Energies
Jeudi 01/02/18
  • Choix des fonctionnalités de l'application mobile
  • Prise en main des cartes LoRa
  • Recherche d'un environnement de programmation gratuit utilisable pour le projet
  • Prise en main des cartes LoRa
Vendredi 02/02/18
  • Réflexions sur l'implémentation de l'application
  • Démarrage de l'application mobile
  • Mises à jour d'Ionic, de Android Studio
  • Premières communications fructueuses des cartes Semtech LoRaMote
  • Recherche d'un environnement de programmation gratuit utilisable pour le projet
  • Premières communications fructueuses des cartes Semtech LoRaMote
Semaine 2
Lundi 05/02/18
  • Configuration Login et Mot de Passe, Identification base
  • Prise en main des cartes LoRa, premiers programme Lora
  • Atolic TrueStudio semble correspondre à nos attentes
  • Réflexion et création de la base de données
Mardi 06/02/18
  • Configuration Login, Mot de passe
  • Création d'une structure pour l'application Lora
  • Routage statique In Progress
  • Création de l'API REST EN PHP
Mercredi 07/02/18
  • Réunion avec Rémi CHOLLET et 3 PEIP D
  • Assimilation du fonctionnement de Leaflet
  • Création d'une structure pour l'application Lora
  • écritude d'une librairie de buffer cyclique à taille variable pour manipuler des paquets
  • Réunion avec Rémi CHOLLET et 3 PEIP D
  • Création de l'API REST en PHP
Jeudi 08/02/18
  • Ajout de marqueurs sur Leaflet
  • Création d'une structure pour l'application Lora
  • Routage statique fonctionnel
  • Création de l'API REST EN PHP
Vendredi 09/02/18
  • Hackathon Vinci Energies
  • Hackathon Vinci Energies
  • Hackathon Vinci Energies
Semaine 3
Lundi 12/02/18
  • Préparation Soutenance
  • Mise en place d'un Contiki/Cooja pour faciliter le développement
  • Importation des librairie et début débogage
  • Préparation Soutenance
Mardi 13/02/18
  • Mise à jour de AIR
  • Préparation Soutenance
  • Répétition soutenance
  • Préparation Soutenance
  • Répétition soutenance
  • Mise en place d'un Contiki/Cooja pour faciliter le dévelloppement
  • Fin du débogage de l'importation des librairies
  • Préparation Soutenance
  • Répétition soutenance
Mercredi 14/02/18
  • Soutenance de mi-projet
  • Réunion post-soutenance pour redéfinir certains aspects
  • Soutenance de mi-projet
  • Réunion post-soutenance pour redéfinir certains aspects
  • Soutenance de mi-projet
  • Réunion post-soutenance pour redéfinir certains aspects
Jeudi 15/02/18
  • Prise en main de la LoRaOne
  • Prise en main de la LoRaOne
  • Prise en main de la LoRaOne
Vendredi 16/02/18
  • Prise en main de la LoRaOne
  • Prise en main de la LoRaOne
  • Prise en main de la LoRaOne
Interruption de Février
  • Développement sur Contiki/Cooja afin de réaliser un routage dynamique
Semaine 4
Lundi 26/02/18
  • Réunion post-interruption pédagogique
  • Travail sur l'affichage des éléments sur la carte utilisateur
  • Réunion post-interruption pédagogique
  • Continuation du travail sur Contiki
  • Le routage dynamique fonctionne
  • Il reste des imprécision à corriger pour améliorer la communication
  • Réunion post-interruption pédagogique
  • Corrections de l'API en accord avec l'application mobile
  • Modifications sur la base de données
Mardi 27/02/18
  • Création de la page de création d'un nouvel utilisateur
  • Design de l'application mobile
  • Fin du protocole de routage Contiki, tests virtuels de fonctionnement
  • Le routage dynamique fonctionne sur des réseaux complexes
  • Liaison entre l'application mobile et l'API
Mercredi 28/02/18
  • Fin de la page de création d'un nouvel utilisateur
  • Ajout de l'utilisation des sessions dans l'application
  • Panne ordinateur personnel
  • Perte des données du routage dynamique malgré une tentative de back-up avant la panne
  • Travail sur l'application mobile avec Hugo
  • API : Création d'un utilisateur
  • API : Récupération des informations nécessaires pour la carte
  • API : Ajout de l'utilisation des sessions pour stocker l'utilisateur connecté
Jeudi 01/03/18
  • Affichage des informations sur la Map
  • Affichage des informations sur la Map
  • Tentative de récupération ordinnateur et données (échec)
  • API : Récupération des informations nécessaires pour la carte
Vendredi 02/03/18
  • Listing des futures tâches à implémenter dans l'application
  • Réunion et préparation rendez-vous avec M.Donsez
  • Réunion et préparation rendez-vous avec M.Donsez
  • Réparation d'ordinateur personnel, de nouveau pleinement opérationnel mais toutes les données ont été perdues
  • Réunion et préparation rendez-vous avec M.Donsez
  • Renseignements sur Swagger
Semaine 5
Lundi 05/03/18
  • Restructuration de l'application, amélioration visuelle
  • Logout fonctionnel
  • Finalisation de la carte, et ajout de la gestion des différentes cartes
  • Restructuration de l'application
  • Création d'une page Swagger
  • Corrections de l'API
  • Ajout des cartes dans la base de données
  • Récupération des éléments liés à la carte dans l'API
Mardi 06/03/18
  • Ajout gestion secouriste
  • Développement de la page Account, modification utilisateur
  • Ajout gestion secouriste
  • Création vues côté secouristes
  • Fin du Swagger
  • API : Modifications utilisateur
  • API : Modifications mot de passe
  • Base de données : Ajout affectations secouristes-cartes
  • API : Récupération des cartes pour un secouriste
Mercredi 07/03/18
  • Amélioration et finalisation de la page Account
  • Corrections du menu et de la navigation
  • Programme de récupération des messages à la racine et inscription des données dans la base de données
Jeudi 08/03/18
  • Extraction des dents de sagesse
  • Menu dynamique, permet de gérer plusieurs map
  • Création de la page de compte
  • Modification et débogage du système de navigation
  • Création du programme de communication LoRa et récupération des coordonnées GPS depuis la carte SodaqONE
  • Tests de temps de synchronisation et précision du GPS
Vendredi 09/03/18
  • Réunion et préparation rendez-vous avec M.Donsez
  • Design du LogoV2, Embellie CSS de l'application mobile
  • Réunion avec les PEIP D
  • Réunion et préparation rendez-vous avec M.Donsez
  • Un peu de Sodaq
  • Ajout de filtre
  • Nouveau déploiement sur le PlayStore
  • Réunion et préparation rendez-vous avec M.Donsez
  • Finition du programme de communication LoRa
  • Tests d'envoi de la carte SodaqONE vers la base de données en passant par une racine (carte Arduino LoRa)
Samedi 10/03/18
  • Réflexions et implémentations des Usercases concernant la gestion des licences
  • Ajout de notifications mobiles
  • Ajout d'une page liée à la gestion des Trackers
  • Début du Poster Anniversaire
  • Réflexions et implémentations des Usercases concernant la gestion des licences
  • Ajout de notifications mobiles
  • Tests du programme de communication avec les LoRas
Dimanche 11/03/18
  • Implémentations des usercases liées à la gestion des licences côté application
  • Système de notification automatique (FireBase)
  • Implémentations des usercases liées à la gestion des licences côté api
  • Système de notification automatique (FireBase)
Semaine 6
Lundi 12/03/18
  • Ajouts de fonctionnalités dans l'application
  • Correctifs programme de communication
  • ébauche de l'interface d'administration (édition automatique)
  • Rédaction du dossier Management de Projet Innovant
  • Correctifs programme de communication
Mardi 13/03/18
  • Rédaction du dossier Management de Projet Innovant
  • Finalisation des fonctionnalités de l'application
  • Correctifs des bugs
  • Test Réel à la Bastille
  • Rédaction du dossier Management de Projet Innovant
  • Finalisation des fonctionnalités de l'application
  • Correctifs des bugs
  • Page de création de Map Admin
  • Rédaction du dossier Management de Projet Innovant
  • Préparation des capteurs pour le test réel
  • Test Réel à la Bastille
Mercredi 14/03/18
  • Préparation de la soutenance
  • Remplissage de la BDD
  • Finalisation du Poster
  • Test Réel aux Taillées
  • Préparation de la soutenance
  • Préparation de la démonstration
  • Dernier correctifs de l'application
  • Préparation de la soutenance
  • Finalisation du Poster
  • Test Réel aux Taillées
Jeudi 15/03/18
  • Soutenance de Projet
  • Soutenance de Projet
  • Soutenance de Projet
Vendredi 16/03/18
  • 16 Ans de la filière RICM : Présentation du travail effectué
  • 16 Ans de la filière RICM : Présentation du travail effectué
  • 16 Ans de la filière RICM : Présentation du travail effectué

Métriques Logicielles

Langages :

  • Ionic (TypeScript, HTML, CSS)
  • C++
  • PHP
  • Java

Lignes de code :

  • Application mobile : ~3000
  • API + Swagger : ~2000
  • LoRa : ~150
  • Routage : ~300

Cocomo (complexité P semidetached) :

  • Effort = 3 * 5,1501,12 = 18,8 mois homme
  • TDev = 2,5 * Effort0,35 = 7 mois

Temps ingénieur :

  • 180h par personne
  • 6400€ brut coûtant par personne et par mois
  • Coût du projet : 23500€

Collaboration avec le DUT RT et les PEIPs D

L'objectif de cette collaboration est de familiariser des étudiants en PEIP D avec des projets qu'ils seront amenés à développer dans les prochaines années. Nous avons rencontré Rémi CHOLLET et 3 étudiants Mercredi 7 Février, en voici un résumé écrit par Mr CHOLLET définissant les contours de cette collaboration.


"Un rapide résumé de la rencontre que nous avons eu ce matin avec le projet R’Montagne.

Présents : - RCIM5 Gwenael Moreau, Hugo Amodru-Favin - PEIP-D : Yoann Goma-Missamou, Vincent Cadoux, Philippe Charrat - IUT : Rémy Chollet, tuteur pédagogique des PEIP-D Excusés : Didier Donsez, blessé (aie ! courage …), Antoine Delise en cours de marketing

Contexte : Les PEIP-D participent aux projets RICM5 en prenant une tâche « annexe » (hors chemin critique) en charge. L’objectif est une expérience d’immersion + notation liée au PEIP.

Déroulé : Les étudiant RCIM5 ont présenté le projet dans son principe et état d’avancement. Les échanges se sont portés sur l’idée de mener une étude (simulation et mesure) sur la consommation des balises par les PEIP-D avec pour objectif de dimensionner la réserve d’énergie.

Ceci implique : - coté RCIM5 : mise à disposition d’une carte prototype.

- cote PEIP-D : inventaire des paramètres à prendre en compte :

  • consommation carte (GPS + puce LoRa) = > veille + temps d’activation (recherche à faire sur le temps de synchronisation du GPS)
  • puissance d’émission à calibrer en fonction de la couverture voulue et débit (voir Spread Factor ?)
  • temps d’émission-réception (émission jusqu’à acquittement)

- cote PEIP-D : penser la manip pour valider ce modèle

  • mesure moyenne du courant
  • configuration effective du réseau
  • réserver le matériel (voir Jean-Yves Frau au département R&T ?)

- cote PEIP-D : paramètrer les simulations et mesures en fonction de puissance d’émission (ou autre élément pouvant apparaitre comme pertinent)

D’une manière générale, pour les PEID-D : - penser bibliographie (pour commencer : https://fr.wikipedia.org/wiki/LoRaWAN et aussi https://fr.wikipedia.org/wiki/Format_des_piles_et_accumulateurs_électriques  :-) ) - planifier - communiquer : reporting !!!"

Description du sujet

Randonnée et risques

Ouvert à tous, la randonnée est un sport et un loisir qui prend de plus en plus d’ampleur de nos jours. Ne nécessitant pas de grands prérequis, des milliers de personnes se lancent en montagne chaque jour, malheureusement parfois sans connaître toutes les mesures de sécurité associées.

En effet, de janvier à juin 2016, en randonnée et en alpinisme, l’Association Nationale pour l’Étude de la Neige et des Avalanches (ANENA) a comptabilisé 21 accidents notables, dont 8 accidents mortels, impliquant 15 décès.

Aujourd’hui, les mesures de sécurités préconisent que chaque groupe de randonneur se doivent de se munir d’un téléphone portable afin d’appeler les secours en cas de problème. Malheureusement, la communication mobile dépendant de la couverture réseau, peu présente en montagne, l’impossibilité de joindre les secours reste un problème.

Solutions existantes

La solution la plus répandue, est celle du téléphone à connexion satellite. Ayant une communication vers les satellites, cela permet une couverture réseau beaucoup plus répandue dans les montagnes, partout dans le monde (ou presque). Cependant, les téléphones portables satellitaires coûtent chers, et ne sont pas forcément abordables par la plupart des personnes, surtout celles ne sortant qu’occasionnellement.

Fall Alarm est un système de détection de chute sur chantier utilisant les mêmes technologies dont nous avons besoin pour notre projet.

Quelles zones géographiques ?

Toutes les zones montagneuses peuvent présenter des zones blanches, démunies de connexion quelconque autre que les connexions satellitaires. Certaines chaînes de montagne comme la Cordillaire des Andes ne présentent aucune connexion possible quelconque.

Dans le cadre de notre projet, nous fonctionnerons essentiellement dans la localisation grenobloise avec l'objectif que notre solution soit applicable partout dans le monde. Une contrainte intervient tout de même étant donnée que la fréquence d'utilisation du LoRa en Europe est de 868MHz, 915MHz en Amérique et 433MHz en Asie.

Fonctionnalités

Afin de remplir au mieux ses attentes, le principal objectif de ce dispositif sera premièrement de pouvoir communiquer avec les secours à n’importe quel moment, et surtout n’importe où. De plus, il sera capable de détecter de nombreux cas de détresse de la part de l’usager afin de pouvoir lancer un appel d’urgence sans interaction avec l’usager, au cas où il serait inconscient, ou incapable de lancer un appel manuel.

Grâce aux accéléromètres, le dispositif sera à même de détecter un mouvement brutal du randonneur, ce qui pourrait s’apparenter à une chute. Ils pourront également détecter une position anormale, ou une immobilité prolongée, ce qui déclencherait le dispositif d’urgence automatiquement.

Grâce à des tests réalisés au préalable, le boîtier pourra détecter correctement les chûtes de simples mouvements, afin de ne pas lancer l’appel sans raison valable.

Avant de lancer une alerte automatique, le dispositif émettra un signal auditif et visuel à l’utilisateur quelques secondes auparavant, afin de le prévenir l'émission du signal d’urgence, et de lui proposer de le désactiver sur simple pression d’un bouton, afin d’éviter les communications inutiles.

Également, le randonneur sera à même d'émettre volontairement un appel d’urgence à l’aide du bouton, ce qui permet à tout moment d’appeler de l’aide sans effort. Cela peut permettre également à appeler les secours pour une personne en danger qui ne porterait pas le dispositif.

L’appel au secours se représente par un envoi de coordonnées GPS aux secours, via une communication radio LoRa vers des bornes relais placées au préalables en montagne. Cette communication irait de relai de relai jusqu’au centre de sécurité, d’où le message serait transmis aux secours.

De plus, une application mobile verra le jour afin de connecter tous les utilisateurs du module de sécurité, de les visualiser sur une map, et de partager leurs données. En effet, à chaque incident, l’application mettra à jour la position et de la date de l’accident, afin de permettre aux prochains utilisateurs d’être prévenus. Ils pourraient, s'ils sont à proximité, d'assister la personne en détresse en attendant l'arrivée des secours. Bien évidemment, cette application ne sera accessible uniquement si le smartphone de l'utilisateur est relié à une connexion 4G ou Wi-Fi.

Cette prévention pourrait les sensibiliser aux risques de la montagne, leur permettre d’éviter le secteur mais aussi d’aider les personnes en danger si la distance le permet.

Exigences

Fonctionnelles

  • Batterie garantie fonctionnelle 1 semaine
  • Rechargement possible via le panneau solaire portable
  • Dispositif pouvant être allumé et éteint par l'utilisateur
  • Alarme s’enclenche automatiquement dès qu'elle est considérée nécessaire, signal sonore
  • Utilisateur a la possibilité d’activer/désactiver l’alarme quand il le souhaite
  • Lorsque l’alarme est active, l’appareil ne peut s’éteindre
  • ...

Non-Fonctionnelles

  • Résistance : aux chocs, impacts, waterproof (utilisé en permanence en plein air)
  • Disponibilité : Appareil de secours -> Doit être au plus possible performant
  • Performance : Minimiser les pertes réseaux
  • Accessible : Utilisateur pas forcément familier avec des appareils électroniques (facile d’utilisation)
  • Fiabilité : Précision du GPS (rayon de 10m), données non-éronnées
  • Coût : Le plus faible possible pour vendre le moins cher possible
  • Efficacité : Réduire la consommation, utiliser le moins possible les ressources

Composants

LoRaONE

Pour le coeur du projet, après avoir cherché et comparés plusieurs modules LoRa, GPS ou encore accéléromètres, nous avons finalement opté pour le projet LoRaONE.

LoRaONE est un projet de SODAQ regroupant plusieurs composants dans une seule et même carte, de taille réduite.

https://www.kickstarter.com/projects/sodaq/loraone-the-lora-iot-development-board

“The one IoT development board to rule them all” --SODAQ

Cette carte regroupe plusieurs capteurs afin de respecter aux mieux nos exigences :

Un émetteur/récepteur LoRa afin de pouvoir communiquer au mieux avec les antennes relai à longue distance

Un module + antenne GPS de bonne précision (< 10m) pour connaître en tout temps notre position, et ainsi faciliter l’arrivée des secours, ainsi que la recherche de l’individu en détresse

Un accéléromètre sur 3 axes afin de pouvoir détecter tout mouvement, vitesse ou rotation dans l’espace, ce qui permet la détection de chutes ou d’arrêt de mouvements

3 LED RGB afin de pouvoir signaler à l’utilisateur un manque de batterie, un signal d’urgence ou plus si nécessaire

Un bouton poussoir pour le signal d’alarme

Un connecteur de charge par panneau solaire, afin de faire durer chaque batterie le plus longtemps possible

Un connecteur micro-USB ainsi que des lignes pour se connecter à une base Arduino si besoin

Spécifications carte LoRaOne

De plus, grâce au starter pack, nous pouvons avoir accès à la base ONEBase qui nous permettrait d’étendre plus loin la facilité d’utilisation du produit :

Spécifications base LoRaOneBase

Comme nous pouvons le voir, cette base nous permettra de connecter la batterie ainsi que le panneau solaire qui sont fournis dans le pack.

Nous pourrons également connecter jusqu’à 4 modules supplémentaires.

La batterie fournie aura une capacité de 800 mAh, le panneau solaire fourni pouvant délivrer jusqu’à 500 mW de puissance.

Le total atteint une taille d’environ 10*5 cm, ce qui n’est pas excessif, ce qui le rend aisément portatif sur une jambe ou à la taille.

Coût : 115€

Ce module pourra également servir d’antenne relai, l'alimentation solaire devrait maintenir le dispositif chargé en permanence. Des tests seront effectués pour savoir si un panneau solaire plus puissant est requis.

Boîtier

Le boîtier sécurisé devant respecter plusieurs exigences, nous pouvons le construire en plastique résistant, ce qui le rendrait léger tout en respectant une rigidité suffisante. Les antennes pourront être placées le long du boîtier, à l’intérieur si la connexion est suffisante, ou à l’extérieur. Dans ce dernier cas les trous réalisés sur le boîtier afin de laisser passer les câbles seront colmatés afin de garantir une étanchéité.

Schéma boitier d'alarme

Balises

Afin de remonter les informations transmises par les boitiers, des balises seront mises en places sur la zone à couvrir, leur nombre et leur positions dépendra du terrain (obstacles, dénivelés). On distinguera deux types de balises. Tout d’abord, les balises racines qui permettront une communication GSM afin de faire remonter les données vers le serveur. Viennent ensuite les balises standard qui se contenteront de faire remonter vers leur balise racine associée. L’architecture de liaison des balises est détaillée dans une prochaine partie.

Chaque balise est composée d’une barre de fer pouvant être plantée dans le sol, d’un système de lest afin d’immobiliser la balise, d’un paratonnerre, d’un panneau solaire ainsi que d’un LoraOne et d’une batterie. Les balises racines seront équippée en plus d’un dispositif de communication GSM (téléphone portable, émetteur GSM).

Schéma balises d'alarme

Application mobile

Une application mobile est téléchargeable par les utilisateurs. Ils peuvent voir les autres utilisateurs présents dans leur zone. Lorsqu’un utilisateur est en position de danger, une notification apparaît si les utilisateurs sont proches de la situation de danger.

Cette application n’est pas directement reliée au dispositif. Elle ne fonctionne qu’avec la connexion du mobile, et est destinée à être un niveau de sécurité supérieur. Un randonneur proche d’une zone de danger pourrait arriver sur place plus rapidement que les secours.

Communication

Pour un envoi de position + numéro d’identification (X chiffres) :

  • Temps de communication : < 2 s
  • Communication régulière, intervalle de 15 minutes

On peut donc au maximum avoir 15 * 60 / 2 = 450 individus pouvant communiquer avec la même antenne relai, donc dans le même cercle d’environ 15 km de diamètre.

On communique donc au minimum 2 secondes sur 15 minutes, donc 1/450 << 1%, le temps de communication est respecté.

En cas de problème, nous pouvons envoyer jusqu’à 9x plus avec la borne sans dépasser le temps de communication autorisé (1%). Donc 1 envoi d’appel d’urgence toutes les 2 minutes environ.

La balise racine peut être directement connectée au serveur, dans ce cas, il n’y a pas de communication GSM nécessaire et pas de Gateway. Si la racine n’est pas directement connectée au serveur, elle devra au minimum garantir une communication GSM (ce qu’elle peut faire, il n’y a pas de Gateway nécessaire) pour remonter l’information vers le serveur, et donc la base de données.

GSM : Si Racine connectée à Serveur -> No GSM + Gateway Else : GSM + Gateway : LoRa Racine connectée ordi (RaspberryPI) + ordi connecté GSM

Stabilisation et gestion d’erreurs

Choix du routage

Notre réseau n'est pas un réseau traditionnel. Les seules communications existantes sont soit une remontée d'information vers la racine soit une innondation d'alerte vers les clients. Pour celà nous avons donc décidé d'utiliser un algorithme de routage simplifié basé uniquement sur un arbre en largeur des balises. Nous rajoutons en option la possibilité de créer plusieurs racines et donc plusieurs arbres dont les racines communiquent par gsm. Nous nous basons sur des papiers de recherches afin de déterminer quel algorithme auto-stabilisant est le plus adapté au système LoRa (Tel que le papier "A self-stabilizing algorithm for constructing breadth-first trees" par Shing-Tsaan Huang, Nian-Shing Chen).

Stabilisation

Afin de gérer la communication de chaque message vers le serveur, nous allons prendre un noeud (balise LoRa) dit “racine” connecté directement au serveur, nous ne nous occuperons pas de la communication au serveur dans cet onglet. Chaque message reçu de la part d’un noeud du système doit être relayé jusqu’à la racine du système afin de communiquer avec les secours (ou serveur simplement).

Pour cela, il faudra assurer que chaque balise LoRa soit connecté au réseau, afin d’avoir au départ un graphe de communication connexe. Par dessus ce graphe, nous allons utiliser un processus silencieux auto-stabilisant qui construira un arbre de parcours en largeur, avec pour racine le noeud “racine” décidé ci-dessus.

Au lancement du système, il faut prévoir un léger temps de stabilisation, qui dépendrait de l’algorithme et de la taille du graphe (nombre de balises). Cependant, après cela, l’algorithme assure un arbre en profondeur minimal qui nous permettrai de communiquer avec la racine le plus rapidement possible, et donc une qualité de service maximale.

Gestion d’erreurs

Dans un réseau comme celui-ci, plusieurs types d’erreurs peuvent se produire : Délai de communication trop important vers une balise “Crash” d’une balise de communication Surpopulation d’une balise ou congestion de messages

Afin de palier au premier type d’incident rencontré, il faut nécessairement qu’à chaque emplacement dans la zone couverte, l’utilisateur soit à même de communiquer avec au minimum 2 balises différentes. Ainsi, dans le cas d’une communication trop longue sur une balise, l’autre aurait de grandes chances de délivrer le message plus rapidement.

Au niveau de la défaillance d’une balise, l’algorithme d’arbre en profondeur nous fournit déjà une solution intégrée grâce à son auto-stabilisation. Dans le cas de déconnexion d’une balise, l’algorithme mettrai à jour automatiquement l’arbre de communication, et n’importe quel message d’alerte émis serait délivré dans un délai raisonnable.

Pour le troisième cas d’erreur, il n’y aurait pas de solution réelle, si ce n’est de limiter le nombre de communications données, en ne prenant plus en compte les “ping” de chaque utilisateur mais seulement les messages d’alertes, ce qui permettrai une bien plus grande gestion de la congestion à un endroit donné. Également, une balise en dessous d’un lien congestionné pourrait communiquer avec ses autres voisins (non-fils dans l’arbre) afin de libérer de l’espace dans le lien avec son père dans l’arbre. Également, le système ne pourra accepter que jusqu’à 1000 utilisateurs par noeud, et également 4000 utilisateurs par cluster (dans le cas d’un réseau avec plusieurs clusters donc plusieurs racines cette limite augmente).

Plusieurs types de paquets circulent sur le réseau de balise: Les pings, messages envoyés spontanéments à intervalle régulier par les utilisateur contenant l’id ainsi que les deux coordonées gps (27 bits chacun) Les incidents, identique à un ping mais à priorité haute. Les alertes, messages brodcastés par le serveur afin d’envoyer un message en chaine de caractères courts et compressés.

Coûts matériels

Que ce soit pour le dispositif utilisateur ou la balise (racine ou non), le LoRaOne correspond pour permettre les actions recherchées. Afin de réaliser un prototype pertinent, 6 kits LoRaOne sont requis. Ces kits sont accessibles sur le site de Sodaq au prix de 115€ chacun (prix variable). Disponible ici, voir avant dernier bundle : starter "ONE EU starter" actuellement à 112,10€.

Un buzzer est à ajouter au dispositif utilisateur afin de lui délivrer un signal sonore.

Un shield GSM est requis pour que la balise racine communique avec l'extérieur. Sodaq en propose un designé pour fonctionner sur leurs produits mais est éctuellement en rupture de stock. Un shield GSM arduino convient tout autant et peut être trouvé sur le site arduino ici.

Aucun boitier ne sera commandé car nous avons fait le choix de les manufacturer nous même au fablab. Le besoin d'étanchéité n'est pas primordial pour notre prototype, bien que nous tenterons de l'assurer.

Récapitulatif
Produit Lien Quantité Prix Unitaire
1 LoRaOne EU Starter Achat 6 115€
2 Buzzer Achat 3 5.49€
3 Shield GSM Achat 1 65€

Développement

Nous utiliserons les librairies standards Arduino ainsi que celle de SODAQ/Arduino pour le LoRa.

L'IDE Arduino sera utilisé, plus pratique pour l'utilisation de Git (comparé à Mbed).

Mise sur le marché

Ce dispositif a pour but d’être utilisé en montagne, lors de randonnée. Il n’est pas destiné à un usage quotidien, c’est pourquoi nous considérons qu’il est plus judicieux de louer les dispositifs plutôt que de les vendre, même si l’achat n’est pas à omettre de notre stratégie.

Le dispositif peut être commandé en ligne, puis retourné par la poste après usage. Le client louerait le dispositif pour une certaine durée avec un possible nombre supplémentaire de batterie. Les tarifs varient en fonction de la durée et du nombre de batteries louées. Des offres de groupes pourraient être applicables. A long terme, des boutiques pourraient être disséminées dans des grandes villes proches des zones montagneuses, zones à randonnées (Grenoble, Annecy, etc.).

L’application est téléchargeable gratuitement par quiconque, mais utilisable seulement par les clients. Un code d’accès sera envoyé avec le dispositif expirant après la fin de la location.

Il faudra tenir compte de la bande passante du LoRa, variante en fonction des continents.

Planning prévisonnel

Sprint 1 : 29/01 --> 09/02 : Création du prototype logiciel #1

  • Prise en main du matériel
  • Premiers tests de transmissions LoRa
  • Création du protocole d'architecture des balises
  • Application sur les cartes et tests
  • Tests de performances des cartes (durabilité, chargement, batterie)
  • Tests de maintenabilité de l'algorithme (déconnexions, latences)

Sprint 2 : 12/02 --> 23/02 : Prototype logiciel #2 et prototype matériel

  • Création du programme embarqué (utilisateur)
  • Communication avec la racine et le serveur
  • Création des maquettes boîtier et balise
  • Construction des maquettes
  • Finalisation du premier prototype

Sprint 3 : 26/02 --> 09/03 : Fonctionnalités supplémentaires

  • Ajout de la communication entre le LoRa et le GSM sur la balise racine
  • Création application mobile utilisateur
  • Tests sur l'application
  • Tests sur la transmission totale depuis l'utilisateur vers le serveur via le GSM
  • Finalisation du projet

Sprint 4 : 12/03 --> 16/03 : Fin du projet

  • Création de la documentation finale (à partir de la documentation réalisée en continu)
  • Pause café
  • Temps supplémentaire en cas de problèmes importants
  • Préparation de la soutenance