Introduction
Les objets connectés
Omniprésents dans notre quotidien avec une croissance constante, les objets connectés représentaient 11,7 milliards d’appareils à travers le monde à la fin de l’année 2020 pour des usages très divers aussi bien du côté des professionnels et de l'industrie, que chez les particuliers. Dans ce domaine, le marché se segmente en plusieurs catégories d’usages notamment avec la maison intelligente (compteurs connectés, etc.), les systèmes portables (smartphones, montres connectés, etc.), les drones et enfin les équipements de santé (balances connectées, etc.).
Le flux d’échange des données créés par ses appareils fournit une quantité phénoménale d’informations. Ces dernières, après traitement, sont alors présentées dans des IHM permettant de mieux apprécier certaines grandeurs comme la consommation d'énergie ou l’analyse de nos déplacements. C’est sur ce dernier point que nous allons nous intéresser à l’usage des objets connectés pour la géolocalisation au sein d’un bâtiment, ou autrement dit la géolocalisation indoor.
La géolocalisation indoor
Le problème de la géolocalisation ne se pose plus tellement en extérieur notamment grâce au développement des services GPS avec des cartographies comme Google Maps, OpenStreetMap ou Waze. Cependant c’est loin d’être le cas lorsque l’on souhaite offrir ce même type de service dans un bâtiment.
Le principal problème d’un système GPS est la mauvaise pénétration des signaux satellites dans un bâtiment ce qui le rend peu fiable pour ce type de positionnement. C’est pour cette raison que d’autres moyens sont élaborés pour permettre aux visiteurs de se positionner dans un bâtiment.
Plusieurs solutions sont proposées par différents acteurs du marché en exploitant les technologies utilisées dans les objets connectés notamment avec les réseaux maillés. Il n’existe donc pas une technologie ou un protocole standard spécifique à la géolocalisation indoor car aucun constructeur n’a réellement pu imposer ses normes. La géolocalisation indoor nécessite de bien connaître les caractéristiques environnementales du lieu où ce service sera intégré afin de connaître le nombre d’appareils nécessaires et où les placer.
Il est à noter que le sujet de la géolocalisation dans les bâtiments a déjà fait l'objet d'articles sur linuxembedded:
La topologie Mesh
Ce type de réseau a pour particularité d’interconnecter des appareils entre eux (appelés nœuds) de telle sorte que les communications puissent continuer même lorsque un ou plusieurs nœuds ne sont plus dans un état fonctionnel.
Pour connaître le nombre de connexions dans une topologie maillée complète, on peut utiliser la formule suivante :
Nb = (n*(n-1)) / 2
Avec pour résultat :
- Nb : le nombre de connexion dans la topologie maillée
Et pour variables :
- n : le nombre d’appareil à connecter
Dans un réseau maillé partiel (ou hybride) les nœuds d’extrémités se connectent à leur n+1 points de concentration. Ces différentes topologies peuvent être raccordées à une passerelle (gateway), elle même reliée à un service cloud.
Un réseau maillé permet d’étendre la couverture de son réseau afin d’interconnecter des appareils qui ont une courte portée. Cela peut servir notamment pour couvrir un bâtiment entier avec des capteurs. Cependant cela peut représenter un coût important si beaucoup d’appareils doivent être utilisés, de plus, un nœud peut représenter un point de vulnérabilité en cas de cyberattaque. Plus le réseau maillé sera grand et plus nombreux seront les points d’attaques, et il suffirait d’une seule brèche pour accéder à tout le reste. La sécurité étant un point très important mais non traité dans cet article, je vous invite à lire l'article de Mickaël RAMILISON sur l'implémentation de Secure Boot sur iMX8.
Par ailleurs, la consommation d’énergie est plus importante dans ce type de réseau avec un peu plus de latence à cause des différents sauts que les données sont amenées à faire entre chaque nœud.
Enfin, comme expliqué précédemment, aucun standard ne s’est réellement imposé dans le secteur ce qui pousse les différents acteurs à améliorer leurs protocoles pour optimiser l’aspect énergétique ou encore la précision.
Principe de la mesure par la méthode AOA (Angle of Arrival) du Bluetooth 5.1
Le Bluetooth 5.1 est une version basée sur le Bluetooth MESH qui lui même repose sur le BLE (Bluetooth Low Energy). L'intérêt est de pouvoir créer un réseau maillé tout en optimisant la consommation d'énergie.
L'intérêt de la version 5.1 réside dans la fonctionnalité de radiogoniométrie Bluetooth, l'AOA, pour la géolocalisation indoor. En effet, comme précisé précédemment dans la partie "Géolocalisation indoor", il faut un certain nombre d'appareils à placer et à connecter au sein du bâtiment pour avoir un calcul de positionnement fonctionnel et l'AOA pourrait considérablement réduire le nombre d'appareil à placer.
La méthode par AOA ou "Angle Of Arrival" (Angle d'arrivée) consiste à un échange de paquets de données entre un appareil émetteur appelé "beacon" (balise) et un appareil récepteur nommé "locator" (localisateur). Ce dernier appareil possède plusieurs antennes qui sont séparées d’une distance "d" connue.
Lors de la phase d' "advertising", un nouveau signal nommé CTE ou "Continuous Tone Extension" (extension de tonalité continue) est ajouté au paquet de données habituel qui est appelé. Ce signal apporte une tonalité continue sur une fréquence calculée de 250 Hz qui est propre au Bluetooth. Il est indépendant du reste de paquet de données et ne crée donc pas d’interférence. Cela permet ainsi de calculer une position en continue en temps réel.
Pour mieux comprendre le calcul de l’angle, il faut prendre en compte que le récepteur possède plusieurs antennes. Il va donc choisir l’antenne de réception et la changer pour une autre antenne à proximité pour recevoir un nouveau paquet de données. Ces paquets sont envoyés par le beacon par ondes radio à une fréquence de 2,4 GHz via le signal CTE qui forme une onde périodique. Cela permet d'avoir une longueur d’onde constante et de calculer la différence de phase entre ce qui est reçu par les 2 antennes. Il est alors possible de procéder à un calcul trigonométrique permettant de déterminer l’angle où se situe le beacon par rapport au récepteur avec la formule suivante :
θ = arccos((ψλ)/(2πd))
Avec pour résultat :
- θ : L’angle d’arrivée en radian permettant de situer où se trouve le beacon par rapport au récepteur.
Et pour variables :
- ψ : La différence de phase entre les ondes reçues par les 2 antennes du récepteur.
- λ : La longueur d’onde du signal CTE reçu, soit 0,125 m avec la fréquence de 2,4 GHz du Bluetooth.
- d : La distance entre les 2 antennes qui doit prendre en compte la fréquence de Nyquist pour éviter les erreurs d'échantillonnage. La fréquence de Nyquist correspond au double de la fréquence la plus élevée contenue dans le signal. Le Bluetooth fonctionne sur une bande de fréquence de 2,4 Ghz, la fréquence de Nyquist de notre signal est donc de 4,8 GHz. Cette fréquence correspond à une longueur d’onde de 0,0625 m soit 6,25 cm. La distance d ne doit donc pas dépasser la valeur de 6,25 cm dans notre cas.
Cette fonctionnalité a pour particularité de donner un positionnement en trois dimensions avec un angle azimut et un angle en élévation. Cependant on ne peut pas obtenir la distance du beacon. C’est pour cette raison que j’ai décidé de combiner cette méthode avec une détermination de la distance avec le RSSI (Received Signal Strength Information) que je détaillerai plus en détails dans la partie suivante.
Calcul de la distance avec le RSSI
Le RSSI ou Received Signal Strength Indication (Indication de la puissance du signal reçu) est une valeur liée à la distance entre un émetteur et un récepteur ainsi qu’à l’environnement qui entoure ces éléments. L’équation suivante permet de calculer le RSSI à une distance "d" en se basant sur une valeur de RSSI mesurée à une distance "d0" .
RSSI(d) = RSSI(d0) - 10 * n * log(d/d0)
Avec pour résultat :
- RSSI(d) : le RSSI calculé pour la distance d.
Et pour variable :
- RSSI(d0): le RSSI mesuré pour la distance d0.
- n : une constante comprise entre 2 et 4 dont le résultat dépend de l’environnement.
L’équation peut se simplifier en prenant d0 = 1 m et ainsi nous donner le moyen de calculer n et la distance d avec les équations suivantes :
d = 10((RSSI(d0)-RSSI(d)) / (10*n))
n = (RSSI(d0)-RSSI(d))/(10*log(d/d0)
J’ai arbitrairement choisi une valeur de n constante pour mes tests et établir une moyenne basée sur des valeurs empiriques pour la valeur de RSSI(d0).
Caractéristiques et prise en main du matériel
J’ai pu me servir des technologies BLE et Bluetooth MESH grâce à des kits de développement, les nRF52DK de chez NORDIC Semiconductor. Ce kit de développement me permet d’exploiter un SoC ou System on Chip (système sur puce) nRF52832 relié à des broches, des antennes, des boutons et des LEDs.
Cette carte permet également d’émuler d’autres SoC moins performants comme la nRF52810 et se présente sous la forme ci-dessous :
J’ai donc pu créer un réseau maillé où j’ai pu connecter 2 kits avec un smartphone. De cette manière j’ai pu réaliser un usage assez simple comme allumer plusieurs LEDs avec le bouton d’une des cartes ou via un bouton virtuel du smartphone. Pour réaliser ces manipulations, je me suis servi de l'OS Zephyr, un système d’exploitation temps réel que je détaillerai plus tard dans une partie dédiée.
Cependant, le kit de développement nRF52DK qui possède le SoC nRF52832 n’est pas compatible avec la radiogoniométrie Bluetooth. Je suis donc passé sur une autre carte, la nRF52833DK.
Ce kit de développement diffère du précédent par un SoC nRF52833, un nombre de broches supplémentaire et une plus grande taille pour les "buffers" ce qui le rend compatible avec le Bluetooth 5.1 et se présente sous la forme ci-dessous :
Le kit de développement est donc bien compatible avec la radiogoniométrie Bluetooth. Cependant, il faut intégrer à cette carte un système de réception doté d’au moins 2 antennes prenant en compte les caractéristiques citées dans les explications sur l’AOA. À l’origine nous avions prévu d’utiliser notre propre système de réception composé d’un commutateur SP4T adapté au 2,4 GHz, HMC7992 branché avec 2 antennes 2,4 GHz.
Zephyr RTOS
Zephyr est un système d’exploitation temps-réel open source et libre sous licence Apache 2.0 géré par la Linux Foundation. Il est destiné à être utilisé sur des appareils ayant des ressources limitées donc parfaitement adapté pour des systèmes embarqués ou autrement dit les objets connectés. Il est hautement configurable et modulable ce qui permet d’optimiser son intégration dans les appareils et les ressources et mémoires sont allouées de manière statique. À travers son architecture, Zephyr peut gérer nativement le BLE avec notamment la version 5.1, ainsi que d’autres protocoles de communication comme le standard 6LoWPAN, le protocole Thread via sa version open source OpenThread, le réseau Wi-FI ainsi que le protocole MQTT.
Ce RTOS a été choisi dans un premier temps car les développeurs derrière Zephyr travaillent également sur la partie logicielle des nRF52 de NORDIC. J’ai pu poser des questions auprès des membres de la communauté qui m’ont répondu et aidé à avancer dans mon projet. Dans un second temps, j’ai pu constater que Zephyr avait une très grande communauté de développeurs et qu’il y a sans cesse des améliorations ce qui est très bénéfique pour faire des solutions durables. Enfin, par rapport à la solution propriétaire de NORDIC, il est beaucoup plus facile de manipuler et configurer Zephyr car il s’installe et s’intègre très bien dans un environnement Linux.
L'installation de Zephyr se réalise très simplement en suivant le guide des développeurs qui est très bien documenté. On peut alors construire les exemples qui sont fournis dans le SDK et les modifier à notre guise pour en faire nos propres projets. Vous avez par ailleurs ici un exemple ci-dessous de commande permettant de construire un projet sur une nRF52833DK, et dans ce cas précis il s'agit de l'exemple "beacon" présent dans le dossier "bluetooth".
west build -p auto -b nrf52833dk_nrf52833 zephyr/samples/bluetooth/beacon
On peut ensuite utiliser la commande ci-dessous pour flasher la carte de développement correspondante.
west flash
Pour pouvoir assurer la configuration et le paramétrage des fichiers il faut absolument s'informer sur leur documentation et ne pas hésiter à directement leur poser des questions.
Développement de l'IHM avec ArcGIS
ArcGIS est une suite logiciel développée par l’ESRI proposant de nombreuses solutions en termes de cartographie et de géolocalisation. Ces solutions se présentent sous la forme d'API qui nécessitent donc la création d’un compte développeur. Avant de choisir ArcGIS, d’autres solutions de cartographie ont été envisagées. Malheureusement, le constat est général, les autres solutions sont obsolètes ou trop limitées dans leurs offres gratuites. ArcGIS permet sur la plateforme développeurs de déposer en ligne des fichiers pouvant représenter le plan d’un bâtiment.
J’ai donc retracé géométriquement les plans du bâtiment de l’agence en utilisant JOSM, un outil libre écrit en Java permettant d’exporter le tracé géométrique de murs et de pièces dans le format GEOJson. Cependant, en important ce format dans la plateforme développeur, l’aspect n’était plus le même et j’ai donc choisi de refaire uniquement le plan du rez-de-chaussée sous un autre format. Je suis donc passé sur QGIS, un autre logiciel libre permettant d’exporter du format Shapefile, format propriétaire d’ESRI qui a bien fonctionné sur la plateforme.
J’ai ainsi pu afficher le plan du rez-de-chaussée de l’agence de Nantes en me servant de l’API Javascript comme le montre la capture d’écran de la page web ci-dessous :
Cependant, je suis passé sur l'API Python d'ArcGIS en me basant et réutilisant ce que j'ai appris avec l'API ArcGIS. La raison principale est que l'API Python me laisse la possibilité de directement intégrer un programme Python permettant de récupérer et intégrer les positions x et y calculées à partir de l'angle azimut et du RSSI de manière locale.
Architecture du système
L'idée derrière ce schéma est de pouvoir synthétiser l'ensemble des éléments qui ont été détaillés dans cette article. Le beacon active la transmission du signal lors de l’appui sur un des boutons intégrés au nRF52833DK dédié. Le récepteur qui est composé de l’autre nRF52833DK et du dispositif d’antennes patch se charge de transmettre les coordonnées calculées vers le l'ordinateur via une liaison série. Un programme Python ayant intégré l'API d'ArcGIS va alors utiliser ces données pour les afficher sur une carte avec le plan du bâtiment.
Résultats et analyses
Les tests que j’ai effectués ont montré que les valeurs de RSSI étaient tout simplement instables et que cela ne permettait pas un positionnement fiable sur l’interface. En effet, la précision était sur un intervalle allant aléatoirement de 1 à 10 m ce qui n’est pas acceptable et les directions n’étaient pas du tout cohérentes.
J'ai donc envisagé plusieurs hypothèses qui expliqueraient l’instabilité du RSSI. La première est que l’environnement où je travaille crée trop de réflexion d’ondes car une structure métallique englobe l’ensemble du bâtiment. La deuxième est qu’il existe des interférences dues aux autres appareils connectés. La troisième hypothèse est que la méthode de réception de la valeur de RSSI est basée sur un exemple fonctionnant à l’origine sur une seule antenne. Or, dans ce cas précis, j’utilise un système avec plusieurs antennes qui peuvent donc tout à fait calculer une valeur de RSSI différente.
J’ai donc décidé de moyenner ces valeurs de RSSI pour essayer de stabiliser une valeur qui me servira de référence pour le calcul de la distance. De plus, j’ai décidé de calculer la constante d’environnement n afin d’améliorer la précision de la détection. Pour réaliser ce calcul, j’ai mesuré 20 valeurs de RSSI à une distance de 1 m pour en faire une moyenne. Ensuite, j’ai réalisé 20 mesures de RSSI à une distance de 2 m pour aussi en faire une moyenne. De cette manière je peux me servir de l’équation isolant la valeur n à partir des moyennes obtenues.
Cela s’est avéré fructueux, puisque le positionnement du point représentant le beacon est devenu plus cohérent. Pour mieux comprendre les résultats, ils ont été réalisés en plaçant le beacon en direction sud par rapport au système de réception représenté avec le losange orange aux distances de 1, 2 et 3 mètres. L’IHM donne donc les rendus suivant :
Bien que le positionnement ne soit pas bien dimensionné au niveau de la distance, il est encourageant de constater une certaine stabilité et cohérence sur la direction. La dernière correction restante étant liée au dimensionnement de la distance, j’ai optimisé le coefficient lié à l’échelle sur la carte pour me rapprocher le plus possible de la distance réelle. Les nouveaux résultats sont les suivants :
Il est intéressant de constater que même avec des valeurs proches de la réalité, plus on s’éloigne du dispositif de réception et moins on est précis. Néanmoins, la précision reste intéressante à exploiter et on peut déduire que cette précision passera alors au mètre à un certain rayon.
Conclusion et axes d'améliorations sur le système
Les résultats montrent qu'il est bel et bien possible de n'utiliser qu'un seul système de réception pour géolocaliser un appareil ce qui peut représenter un gain conséquent en termes de coût en réduisant le nombre d'appareils nécessaires. Cependant, il faut bien prendre en compte que les tests ont été réalisés dans une configuration avantageuse, c'est à dire sans obstacle entre le récepteur et le beacon. Il serait donc très intéressant de poursuivre le projet pour tester l'AOA dans d'autres configurations et peut être ainsi optimiser son utilisation. Par ailleurs un comparatif au niveau énergétique et de l'autonomie avec d'autres méthodologies de calcul de positionnement serait aussi intéressant à réaliser pour mieux se rendre compte des avantages et inconvénients.
Enfin, il est aussi possible d'améliorer le système pour faciliter l'accès à l'IHM de positionnement. On peut remplacer l'ordinateur par un modem connecté aux réseaux internet mobile qui enverra alors les données vers un "broker" MQTT. De cette manière on pourra se servir d'un service de cloud comme une instance EC2 d'AWS qui s'abonnera à ce "broker" pour récupérer les coordonnées x et y et réaliser la même chose qu'avec l'interface utilisant Python et l'API d'ArcGIS. On peut donc tendre vers un système dont le schéma serait le suivant :
Sources
- https://www.journaldunet.fr/web-tech/dictionnaire-de-l-iot/1498593-marche-de-l-iot-tous-les-chiffres-en-france/
- https://fr.wikipedia.org/wiki/Syst%C3%A8me_de_positionnement_en_int%C3%A9rieur
- https://www.digikey.fr/fr/articles/get-accurate-real-time-asset-tracking-using-bluetooth-direction-finding
- https://www.digikey.fr/fr/articles/use-bluetooth-5-1-enabled-platforms-part-1
- https://zephyrproject.org/wp-content/uploads/sites/38/2020/09/zephyr_overview_091520.pdf
- https://developers.arcgis.com/javascript/latest/
- https://developers.arcgis.com/python/guide/using-the-gis/