R'Montagne

Présentation du projet

É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 : Lien Waffle.io

Journal

Date	Hugo AMODRU-FAVIN	Antoine DELISE	Gwenaël MOREAU
SPRINT 1
Lundi 29/01/18	efoed	sidfjeso	zdokz

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.

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

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