R'Montagne
É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 |
|
|
| |
| Mardi 30/01/18 |
|
|
| |
| Mercredi 31/01/18 |
|
|
| |
| Jeudi 01/02/18 |
|
|
| |
| Vendredi 02/02/18 |
|
|
| |
| Semaine 2 | ||||
| Lundi 05/02/18 |
|
|
| |
| Mardi 06/02/18 |
|
|
| |
| Mercredi 07/02/18 |
|
|
| |
| Jeudi 08/02/18 |
|
|
| |
| Vendredi 09/02/18 |
|
|
| |
| Semaine 3 | ||||
| Lundi 12/02/18 |
|
|
| |
| Mardi 13/02/18 |
|
|
| |
| Mercredi 14/02/18 |
|
|
| |
| Jeudi 15/02/18 |
|
|
| |
| Vendredi 16/02/18 |
|
|
| |
| Interruption de Février |
|
|||
| Semaine 4 | ||||
| Lundi 26/02/18 |
|
|
| |
| Mardi 27/02/18 |
|
|
| |
| Mercredi 28/02/18 |
|
|
| |
| Jeudi 01/03/18 |
|
|
| |
| Vendredi 02/03/18 |
|
|
| |
| Semaine 5 | ||||
| Lundi 05/03/18 |
|
|
| |
| Mardi 06/03/18 |
|
|
| |
| Mercredi 07/03/18 |
|
|
| |
| Jeudi 08/03/18 |
|
|
| |
| Vendredi 09/03/18 |
|
|
| |
| Samedi 10/03/18 |
|
|
| |
| Dimanche 11/03/18 |
|
|
||
| Semaine 6 | ||||
| Lundi 12/03/18 |
|
|
| |
| Mardi 13/03/18 |
|
|
| |
| Mercredi 14/03/18 |
|
|
| |
| Jeudi 15/03/18 |
|
|
| |
| Vendredi 16/03/18 |
|
|
| |
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
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 :
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é.
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).
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.
| 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