R'Montagne

Présentation du projet

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 n’est pas forcément abordable par la plupart des personnes, surtout celles ne sortant qu’occasionnellement.

Fall Alarm : https://fall-alarm.net/

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é ensembles, et de partager leurs données. En effet, à chaque incident, l’application sera mise à jour de la position et de la date de l’accident, afin de permettre aux prochains utilisateurs d’être prévenus.

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 Batterie rechargeable et interchangeable (port micro-USB, plus courant) Alarme s’enclenche dès que considéré nécessaire Utilisateur a la possibilité d’activer/désactiver l’alarme quand il le souhaite Lorsque l’alarme est activée, 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, à condition que l’alimentation solaire suffise à maintenir l’appareil en marche de manière “illimitée”.

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

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.

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.

Arbre : largeur, remontée d’infos, alertes, canaux -> Protocole Spec tech balise Batteries Taches et homme*mois

Logiciel Gateway : sans (extension envisagée) Antenne relais : mat, paratonnerre, etc. Robustesse : étaller dans le temps, ralentir les transmissions Débit classique 1kbps, utilisation du spectre 1% du temps Si on emet 1s, on peut pas émettre pendant 99s csma : collisions/retransmissions coup

Faire gaffe aux bandes passantes du lora en fonction du pays

Planning

• Semaine 1 : 29/01 -> 02/02 : Prise en main du matériel, 1ers tests

• Semaine 2 : 05/02 -> 09/02 : Prototype logiciel

• Semaine 3 : 12/02 -> 16/02 : Prototype logiciel (fin) + Prototype matériel

• Semaine 4 : 19/02 -> 23/02 : Tests utilisateur prototype + Déploiement serveur

• Semaine 5 : 26/02 -> 02/03 : Maquette application mobile + Prototype

• Semaine 6 : 05/03 -> 09/03 : Prototype application mobile + Rajout Gateway

• Semaine 7 : 12/03 -> 16/03 : Finalisation du projet + Marge retard