Exploitation des signaux de référence de navigation par satellite pour un positionnement centimétrique : RTKLIB fait appel à Centipède et l’IGN pour afficher dans QGIS

Nous avons récemment discuté [1] de la mise en œuvre de récepteurs de signaux de navigation par satellite (GNSS) en vue d’un positionnement centimétrique, et en avons profité pour développer un système de communication radiofréquence longue portée s’appuyant sur le protocole LoRa à 868 MHz afin de s’affranchir de restrictions sur les émissions radiofréquences dans les bandes de téléphonie mobile ou celles industrielles, scientifiques et médicales (ISM) autour de 2,45 et 5,8 GHz sur notre site d’étude. Ce faisant, nous avons découvert le projet Centipède qui vise à produire un maillage dense de stations GNSS de référence (dites stations de base) en vue de permettre un positionnement centimétrique de dispositifs mobiles (dits rovers) en s’affranchissant des délais ionosphériques et autres effets corrélés entre station de base et rover. En effet, le délai ionosphérique, variable au cours du temps et de l’activité solaire, est la principale source d’incertitude du temps de vol des ondes électromagnétiques depuis les satellites de navigation en orbite moyenne (20 000 km de la surface de la Terre) vers le récepteur au sol, induisant une incertitude de position de quelques mètres (pour rappel, 1 ns de retard se traduit par 30 cm d’erreur de trilatération du récepteur). En imposant la position d’une station de base supposée connue, un rover suffisamment proche – typiquement dans un rayon d’une trentaine de kilomètres – subira les mêmes délais ionosphériques que la station de base, effet qui pourra donc être corrigé par un logiciel approprié tel que RTKLIB. Centipède dissémine ces informations de stations de base par réseau compatible Internet (IP), accessible en particulier par le réseau de téléphonie mobile, moyennant un abonnement relativement courant actuellement.

Nous allons explorer trois utilisations des connaissances acquises pour le positionnement centimétrique de GNSS exploitant la bibliothèque libre RTKLIB et sa déclinaison pour récepteurs faible coût Demo5 de https://github.com/rinex20/RTKLIB-demo5 : la configuration et l’utilisation de RTKLIB en console, s’affranchissant ainsi des déboires des interfaces graphiques pour rendre l’application compatible avec les systèmes embarqués à faible empreinte mémoire et ressources de calcul, l’utilisation des signaux communiqués par Centipède depuis la station de référence la plus proche du site d’observation et une comparaison avec les résultats issus du post-traitement en exploitant les signaux de référence communiqués par l’Institut Géographique National (IGN), et finalement la cartographie en temps réel des signaux GNSS centimétriques dans l’outil de gestion des informations spatialisées QGIS.

Nous précisons dès le début de cet exposé que l’objectif n’est pas une résolution centimétrique d’un objet en mouvement, mais une géolocalisation avec une telle résolution après observation des constellations de satellites pendant plusieurs minutes, voire dizaines de minutes. La solution convergera petit à petit en passant de Single (mesure simple récepteur) à Float (en cours de recherche de la solution) à Fixed (solution obtenue). Le passage de Float à Fixed peut être long, voire ne jamais arriver tel que nous l’avons constaté sous certains couverts forestiers.

Nous avions dans la description précédente [1] expliqué comment configurer deux U-Blox Zed-9FP montés sur le circuit imprimé commercialisé par MikroE sous la référence 4456 au moyen du logiciel propriétaire U-Center, mais exécutable au moyen de l’émulateur Wine sous GNU/Linux, pour ne transmettre que les messages binaires au format UBX et ne pas émettre les messages NMEA. Ainsi, avec les trames RAWX communiquées en 115 200 bauds 8N1 pour toutes les constellations supportées (GPS, Galileo, Beidou et éventuellement GLONASS, même si ce dernier est plutôt à proscrire compte tenu de sa communication multiplexée en fréquence très différente des autres modes de communication différenciant chaque satellite sur le code), nous avions proposé d’implémenter une station fixe (basestation) communiquant avec une station mobile (rover) dont la position relative est identifiée au centimètre près. Nous allons poursuivre cette étude en nous appuyant cette fois sur des réseaux de basestations de référence aux positions connues avec une exactitude subcentimétrique (un point que nous avions omis d’aborder auparavant) en vue de localiser un rover avec une exactitude centimétrique en s’appuyant sur ce réseau de référence dont les informations sont transmises en temps réel, et accessibles notamment par réseau de téléphonie mobile ou Wi-Fi (Centipède) ou en post-traitement (IGN).

1. RTKLIB en mode console

Moins de trois mois après avoir publié la méthode d’acquisition et de traitement de signaux centimétriques par récepteurs UBlox de la série 9 (Zed-F9P), les outils sont déjà cassés ! L’interface graphique de rtknavi_qt ne compile plus, et nous n’allons évidemment pas utiliser les binaires précompilés pour MS-Windows : afin de nous affranchir des affres de bibliothèques dont l’interface de programmation applicative (API) ne cesse de changer et de nous libérer d’interfaces graphiques illisibles sur un écran illuminé par le soleil, nous allons explorer les interfaces en ligne de commande de RTKLIB, plus stables, compatibles avec les applications embarquées ou avec une automatisation des acquisitions et des traitements.

Les outils en ligne de commande se compilent sans surprise (testé sous Debian GNU/Linux) en exécutant make depuis le répertoire app/consapp de RTKLIB-demo5. Notez que la cross-compilation vers une cible embarquée d’architecture autre que l’hôte, telle que le processeur ARM 64 bits de la Raspberry Pi 4 dont nous supposons l’environnement de développement produit par Buildroot [2] s’obtient simplement en commentant dans le Makefile la ligne export CC = gcc, puis en lançant la compilation par CC=aarch64-linux-gcc make en ayant pris soin d’ajouter à son PATH le répertoire output/host/usr/bin du Buildroot configuré pour la cible (p. ex. make raspberrypi4_64_defconfig && make depuis Buildroot). Les binaires se regroupent dans un unique répertoire, par exemple /tmp/bin prêt à expédier sur la cible, en commentant dans le Makefile la ligne BINDIR = /usr/local/bin, puis en exécutant mkdir -p /tmp/bin && BINDIR=/tmp/bin make install afin de se contenter de copier le contenu de /tmp/bin vers la carte SD de la Raspberry Pi 4. Lors de la connexion du récepteur U-Blox Zed-9FP, nous penserons à charger le pilote du port série virtuel sur bus USB modprobe cdc_acm, puisqu’il n’est pas chargé automatiquement.

Nous apprenons dans la documentation de RTKLIB [3] que la commande rtkrcv -s -o RTKlib_dualZedF9P.conf fait appel au logiciel approprié pour traiter un flux de mesures portant d’une part les informations de la station de référence, et d’autre part les observations du rover, selon un fichier de configuration un peu volumineux et disponible à https://github.com/jmfriedt/RIOT_NyAlesund pour être lancé dès son chargement (option -s), mais dont les principales informations sont :

donc deux flux venant sur les ports série /dev/ttyACM0 (UBlox servant de rover) et /dev/ttyUSB3 (sortie du flux de la station de base communiqué par LoRa), au débit de 115 200 bauds, et au format UBlox binaire (UBX). Les sorties sont d’une part des données issues des traitements en divers formats (latitude/longitude/hauteur ou XYZ dans un repère d’origine le centre de la Terre – on vérifie que la racine de la somme des carrés est bien de l’ordre du rayon terrestre [4] de 40 000/(2π)=6366 km), ainsi que le stockage des mesures brutes acquises par le rover et transmises par la station de base. Le résultat de ces traitements lorsque rover et station de base sont en vue du ciel (Fig 1) est de la forme :

avec dans l’ordre le temps GPS, la position dans un repère centré sur le centre de la Terre ECEF, une qualité de mesure Q, un nombre de satellites visible ns et un écart type sur la mesure (donc une résolution) sdx, sdy et sdz pour les trois directions de l’espace. Nous avons tronqué cet affichage des autres informations redondantes par souci de compacité.

La documentation de RTKLIB à la page 104 de https://www.rtklib.com/prog/manual_2.4.2.pdf nous aide à interpréter le statut de l’analyse en fournissant la nature de la solution dans la colonne Q :

Ainsi, une solution de type 1 est garante de la position avec une résolution subcentimétrique et son obtention sur le terrain permet de s’assurer de la qualité de la mesure en imposant d’observer suffisamment longtemps pour que la solution converge, parfois un peu pénible sous la pluie ou dans la neige.

2. Exploitation des signaux de référence de Centipède

La documentation de Centipède explique fort bien comment utiliser les informations diffusées et fournit à https://docs.centipede.fr/docs/Rover_rtklib_pc/RTKlib_windows.html un fichier d’exemple de configuration. Nous nous inspirons de ce document pour d’une part fournir un flux venant du port série connecté au récepteur Zed-F9P – le même qui a servi de rover auparavant – mais cette fois la station de base n’est pas un flux du port série, mais un flux IP venant de la connexion Wi-Fi de l’ordinateur effectuant les acquisitions et connecté au caster de Centipède diffusant ses informations sur le port 2101. Nous prenons soin de mentionner la station de référence qui nous intéresse, ici ENSMM puisque nous sommes à proximité de cette localisation ; ce fichier de configuration RTKlib_centipede.conf contient donc :

pour être utilisé par rtkrcv au moyen de rtkrcv -s -o RTKlib_centipede.conf.

Le résultat du traitement en temps réel des observations est de la forme :

avec une qualité Q de 1 qui indique une solution fixe et un écart type dans les trois directions inférieur au centimètre.

Nous observons un écart de 5 m entre la station de référence que nous avons fournie initialement et la solution fournie par Centipède. Dans la première solution, la position de la station de référence n’a pas été imposée et a été mesurée par une solution simple (non différentielle) : cette position fluctue, comme toute mesure GNSS sans référence, de +/-7 m et un écart de 5 m n’est pas surprenant. Cette erreur pourrait être corrigée en plaçant notre station de base sur un point de position connue et en s’y référant lors de chaque campagne de mesures. Au contraire, la mise en place de la station de référence Centipède impose une période d’acquisition de sa position et son positionnement relativement au réseau de référence de l’IGN, garantissant la cohérence des positions. C’est justement cette position du réseau RGP (Réseau GNSS Permanent) de l’IGN que nous allons considérer ci-dessous pour du post-traitement.

Notons en cas de difficulté à se connecter une commande très pratique de rtkrcv qu’est stream qui annonce la nature des flux reçus par RTKLIB :

prouve que le port série du récepteur mobile (ttyACM0) a été détecté et le flux en provenant de Centipède (http://caster.centipede.fr) est reçu. En cas d’échec de connexion à Internet, nous aurions un message du type :

Par ailleurs, la commande satellite de rtkrcv permet de voir les constellations de satellites vu leur statut :

et de s’assurer par exemple que l’antenne est bien connectée et alimentée.

3. Exploitation des signaux de référence de l’IGN

Le site de l’IGN qui propose l’accès à leurs observations de référence de signaux de navigation par satellites – https://rgp.ign.fr/DONNEES/diffusion/ – se configure en sélectionnant la station de référence aussi proche que possible du site d’observation, pour nous station BSCN -> flèche+ pour ajouter la station, activer GPS C2 et Galileo, sélectionner la plage horaire autour de l’observation, 1 s de pas d’échantillonnage, et le format Rinex2.11 (Fig. 2). Une fois ces configurations achevées et validées par Valider les filtres, Ajouter au panier et Télécharger. On appréciera la qualité de ces données en sachant qu’une ligne téléphonique dédiée est installée à l’observatoire de Besançon pour collecter et communiquer ces mesures.

Nous apprenons dans la page de manuel de rnx2rtkp https://manpages.debian.org/testing/rtklib/rnx2rtkp.1.en.html qui fait partie de RTKLIB que le post-traitement des fichiers au format d’échange standard RINEX est pris en charge par cet outil qui prend comme argument le nom du fichier d’observations du rover, le nom du fichier d’observations de la station de référence que nous venons d’obtenir auprès de l’IGN (extension ??o avec ?? l’année de la mesure) ainsi que les éphémérides associées au moment de l’observation contenues dans le fichier d’extension ??n. Nous ajoutons comme options le type de solution recherchée – ici un rover statique (-p parmi 0 : single, 1 : dgps, 2 : kinematic, 3 : static, 4 : moving-base, 5 : fixed, 6 : ppp-kinematic, 7 : ppp-static) et un masque d’élévation en dessous duquel les observations sont rejetées (-m). Comme rnx2rtkp n’accepte que des fichiers au format RINEX, nous devons convertir les enregistrements au format UBlox en RINEX au moyen de convbin fourni lui aussi par RTKLIB :

À l’issue de ce traitement, nous avons la satisfaction d’obtenir à nouveau des solutions subcentimétriques, cette fois en excellent accord avec la solution calculée avec la position de la station de référence Centipède :

Certes, la solution est obtenue a posteriori, mais cette approche peut s’avérer fort utile sur des sites où une liaison téléphonique n’est pas disponible pour récupérer en temps réel les informations de référence de Centipède, au détriment de ne pas savoir avant post-traitement si la solution a convergé. On prendra donc soin d’attendre quelques dizaines de minutes sur chaque site de mesure pour enregistrer suffisamment de mesures pour maximiser les chances de convergence de la solution Fixed.

4. Traitement sur téléphone mobile

RTKLIB existe pour Android sous le nom de RTKlibDroid disponible à https://github.com/jancelin/RTKlibDroid ou RtkGps+ à https://github.com/jancelin/RtkGps avec une archive APK disponible dans les releases du dépôt afin qu’il ne soit pas nécessaire de se prostituer auprès de Google pour installer l’application. C’est cette seconde option que nous avons testée en configurant une source de rover venant du Zed-F9P connecté au téléphone mobile par câble USB-OTG – donc avec la broche ID du connecteur USB micro-B connectée à la masse – et la seconde source de station de base venant du caster Centipède, toujours en référant comme point de montage la station de référence la plus proche (dans notre cas ENSMM). Après quelques minutes en espace libre avec une bonne vue du ciel, la solution Fixed est obtenue et l’écart type sur la position chute sous le centimètre (Fig. 3). Dans le cas particulier du téléphone mobile Sony Xperia Z5 Compact utilisé au cours de ces essais, la détection du périphérique connecté au port USB nécessite une recherche explicite dans Settings -> Device connection -> USB Connectivity -> Detect USB Device. Une fois le port série virtuel identifié, RtkGps+ valide la lecture des données en faisant clignoter un des deux indicateurs verts en haut à droite de l’interface graphique signifiant que les trames sont lues et traitées.

Obtenir une solution subcentimétrique sur téléphone mobile est bien, mais les utilisateurs argumenteront qu’ils veulent cette solution dans leur outil favori de gestion d’informations spatialisées, donc QField sous Android – la version embarquée de QGIS. Il faut donc transmettre les informations issues de RTKLIB vers QField en passant outre du récepteur GPS matériel équipant le téléphone mobile. Pour ce faire, nous exploiterons l’option d’injection de position en mode développeur sous Android : RTKLIB produit une information centimétrique au travers de ce protocole qui supplante la position déduite par le récepteur matériel et indique à QField sa position depuis le périphérique externe. Après avoir généré un projet QGIS trivial qui ne contient qu’une couche OpenStreetMaps et l’avoir importé dans QField, nous pourrons valider avec une résolution centimétrique sur plateforme de calcul mobile les informations spatialisées qui nous intéressent (Fig. 4).

L’activation du mode d’injection de trames GNSS dans Android s’obtient en activant le mode développeur et en autorisant RtkGps+ à injecter les trames dans l’onglet Select mock location app (Fig. 4, gauche).

5. Utilisation de téléphones mobiles équipés de récepteurs multibandes

Certains téléphones portables sont équipés de récepteurs GNSS multiconstellations et multibandes tels que décrits à [5] et en particulier lorsqu’ils sont basés sur un chipset Qualcomm Snapdragon. Nous avons ainsi acquis un Xiaomi Mi 10 Lite muni de son Snapdragon 765G et tenté d’estimer la résolution de positionnement en post-traitement s’appuyant sur les données fournies par le récepteur de l’IGN à Nanterre.

Les mesures brutes du téléphone portable Xiaomi Mi 10 Lite sont enregistrées au moyen de l’application Geo++ RINEX Logger. La nature des constellations observées est précisée dans l’entête du fichier RINEX, avec G pour GPS américain, R pour GLONASS russe, E pour Galileo européen, C pour Beidou chinois et J pour QZSS japonais tandis que le type des observations suit avec C pour les pseudoranges (temps de vol du code), L la phase de la porteuse radiofréquence, D le décalage Doppler de la porteuse dû au mouvement du satellite et S la puissance du signal. Nous constatons donc que le Xiaomi Mi 10 Lite observe les quatre grandes constellations en orbite moyenne (G, R, E et C) sur les bandes 1 et 5 de GPS et Galileo en code et en phase :

Le résultat du traitement est quelque peu décevant avec :

un écart type dans les trois directions de l’ordre du mètre. Nous avions bien été prévenus de la qualité médiocre des antennes de réception GNSS équipant les téléphones mobiles et placer le téléphone à quelques dizaines de centimètres du sol sur un banc est loin d’une condition idéale pour éviter les rebonds et interférences des chemins multiples, mais nous sommes loin du centimètre recherché (Fig 5).

6. Injection des signaux GNSS dans QGIS

Maintenant que nous sommes capables de traiter en temps réel des mesures acquises par le récepteur mobile en se référant à une station de base de coordonnées connues, il peut sembler utile de placer sur une carte le fruit de ces traitements. Bien que Google Maps propose un mode de positionnement en temps réel depuis un récepteur GNSS (Tools -> GPS -> Realtime), il s’agit d’un jouet propriétaire qui ne possède pas toutes les couches d’analyse que nous aurions été susceptibles d’obtenir lors de traitements antérieurs à la séance d’observation sur le terrain, et nous allons donc nous efforcer d’interfacer Quantum-Gis (QGIS) avec le flux issu du traitement de RTKLIB. En effet, au moins dans sa version 3.28 utilisée pour cette démonstration, un flux de données GNSS peut être acquis depuis gpsd par QGIS en activant View -> Panels -> GPS Information. La nouvelle fenêtre qui apparaît sous la liste des couches propose de se connecter de diverses façons à une source de données de localisation et en particulier gpsd. Si le démon de gestion des données de positionnement est actif et communique par défaut sur son port 2947, alors QGIS indique une cible au niveau de la position du récepteur. Aucune configuration n’est modifiée dans QGIS puisque gpsd communique par défaut au travers de ce port de localhost.

Cependant, nous ne sommes pas intéressés par la connexion d’un simple GPS à QGIS, mais par l’exploitation du résultat du traitement en temps réel par RTKLIB. Ainsi, il faudra remplacer l’interface physique (Bluetooth, USB ou RS232) par un flux de données, et naturellement un pipe nommé ou FIFO vient à l’esprit. Cependant, avant de se lancer dans le flux continu de données, commençons par essayer de communiquer un fichier au format NMEA issu du traitement par rnx2rtkp à gpsd en vue de le transmettre à QGIS.

Les auteurs de gpsd ont prévu la capacité à tester le démon avec un jeu de données factice et proposent pour cela le script Python gpsfake. Ce programme accepte en argument un fichier contenant des données de positionnement au format NMEA et injecte ces informations à une instance spécifique de gpsd. Afin d’exécuter gpsfake, il faut s’assurer que le port 2947 de localhost est libre et qu’aucune instance de gpsd n’y est associée (sudo lsof -i:2947 -n -P ne doit rien répondre, sinon systemctl stop gpsd et systemctl stop gpsd.socket) avant de lancer gpsfake -S fichier.nmea. Nous avons pris un temps significatif à découvrir que les pseudoterminaux créés par gpsfake sont protégés par un superviseur de sécurité AppArmor dont seule la politesse nous interdit de s’en débarrasser tant ses restrictions sont handicapantes. En effet, les messages de dmesg du type :

indiquent que AppArmor a non seulement interdit l’accès au pseudoterminal /dev/pts/10, mais en plus il interdit à l’administrateur d’en changer les permissions. Pour une fois, nous allons suivre l’approche rationnelle consistant à modifier correctement les fichiers de configuration de AppArmor au lieu de simplement contourner le problème ; ces fichiers dans /etc/apparmor.d/usr.sbin.gpsd contiennent des informations de la forme :

qui autorisent à gpsd d’accéder aux périphériques de communication de récepteurs matériels, que nous complétons de :

pour autoriser l’accès aux pseudoterminaux. À l’issue de cette correction prise en compte par apparmor_parser -r /etc/apparmor.d/usr.sbin.gpsd, l’erreur disparaît au lancement de gpsfake avec l’argument -S pour ralentir le flux de données suivi du nom de l’archive au format NMEA, et en connectant QGIS, nous avons la satisfaction de voir le voyant vert s’allumer et une cible se placer sur la position issue du traitement de RTKLIB (Fig. 6).

Nous pourrons vérifier que gpsd comprend bien les informations fournies au moyen des outils en ligne de commande que sont cgps ou gpsmon pour valider la position proposée dans le fichier NMEA.

Finalement, nous voudrions dynamiquement mettre à jour QGIS avec les mesures issues du flux continu de traitement de RTKLIB et non d’un fichier issu d’un traitement statique. La FIFO vient évidemment à l’esprit pour effectuer ce traitement : un pipe nommé est créé au moyen de mkfifo /tmp/mafifo mais une fois de plus, AppArmor va nous empêcher d’en modifier les permissions et nous prenons soin d’ajouter /tmp/mafifo rw, après les autorisations déjà discutées auparavant de /etc/apparmor.d/usr.sbin.gpsd. Si nous avons pris soin de produire un fichier au format NMEA comme attendu par gpsd, par exemple au moyen de :

(notez que le -e de cette fonction fournie auparavant a été remplacée par -n pour remplacer le format de sortie de XYZ à NMEA), alors lancer gpsd par /usr/sbin/gpsd -N -D 1 /tmp/mafifo suivi de while true; do cat fichier.nmea > /tmp/mafifo ;sleep 1;done va continuellement communiquer par la FIFO le contenu du fichier NMEA. En connectant QGIS à gpsd, nous verrons le curseur se positionner au bon endroit. Nous étant convaincu de la validité de la procédure, nous appliquons le concept à la communication en temps réel en ajoutant dans le fichier de configuration de rtkrcv une nouvelle sortie au format NMEA pointant vers /tmp/mafifo :

puis :

1. Lancer gpsd avec /usr/sbin/gpsd -N -D 1 /tmp/mafifo.
2. Lancer rtkrcv -s -o RTKlib_centipede.conf.
3. Connecter QGIS.

Le résultat est présenté en Fig. 7 avec un référencement sur la station Centipède ENSMM, avec une mesure de la largeur du nuage de points acquis en cinq minutes du centimètre, acquis en temps réel. On notera que comme tout bon pipe nommé, les données ne commencent à circuler que lorsque les deux extrémités du tuyau sont connectées, donc rtkrcv demandera à écraser /tmp/mafifo lors de la première connexion de QGIS qui échouera, et ce n’est que lors de la deuxième connexion que QGIS recevra avec succès les données de position au format NMEA. Parfois, les trames ne commencent pas sur l’information attendue et il faut relancer la tentative de connexion jusqu’à ce que QGIS finisse par comprendre les messages qui lui sont transmis. Les positions sont simultanément sauvées dans un fichier indiquant la position dans un référentiel d’origine le centre de la Terre et indiquant un écart type de la position centimétrique de la forme :

On pourrait s’inquiéter de voir des coordonnées différer de 5 m sur X et d’un mètre sur Y et Z, mais ce système de coordonnées est peu intuitif et l’utilisation du convertisseur de référentiels https://proj.org/ mis en paquet par Debian GNU/Linux sous le nom proj-bin indique que les positions obtenues à partir de Centipède ou IGN ne diffèrent de cette nouvelle position séparée de plusieurs jours de 1,5 m, inacceptable si nous visons un positionnement reproductible centimétrique, avec une altitude qui a même fait un saut de 4 m. En effet, la conversion depuis ECEF vers WGS-UTM31N indique que :

il faut donc prendre soin de vérifier la reproductibilité des mesures à long terme.

Nous répétons cette mesure régulièrement sur plusieurs jours afin d’analyser l’impact de la géométrie de la constellation des satellites de navigation, en nous rappelant qu’un satellite en orbite moyenne met 12 h pour parcourir sa circonférence et que pendant ce temps, la Terre a fait un demi-tour. Ainsi, la constellation aura considérablement changé en quelques heures, permettant de valider l’insensibilité de la mesure à la position des satellites dans le ciel. En effet, nous constatons sur plusieurs jours que l’observation ne varie que de quelques centimètres, en accord avec nos attentes (Fig. 8), avec une fluctuation de la mesure un peu dégradée en Z comme on peut s’y attendre, compte tenu de l’extension de la constellation en latitude et longitude plutôt qu’en altitude. Pourquoi le saut de plusieurs mètres sur l’analyse précédente ? Nous n’avions initialement pris aucune précaution contre les multichemins (multipath) dans lesquels le récepteur ne voit pas le signal provenant directement d’un satellite, mais son rebond sur une surface réfléchissante environnante. Lors des premières mesures, le récepteur était placé sur un tas de mousses isolantes d’environ 1,20 m de hauteur, sans plan de masse métallique sous l’antenne (Fig. 1). Au cours des nouvelles mesures, nous avons pris soin de nous placer au niveau du sol (qui ne peut donc pas agir comme réflecteur de multichemin) et sur un plan de masse conséquent. Ces précautions semblent avoir résolu le problème.

Conclusion

Alors que les vendeurs de babioles ne rêvent que de localiser les clients avec une résolution centimétrique pour leur transmettre la publicité de produits inutiles au bon endroit, l’avènement de récepteurs de localisation par constellations de navigation par satellites propose des perspectives d’applications fascinantes, pour qui prend le temps d’apprendre à s’en servir. Nous avons exploré le positionnement avec une résolution subcentimétrique en exploitant une station de référence supposée soumise aux mêmes sources de biais que le dispositif mobile, avec une exactitude limitée par la localisation de la station de base. Avec une station de base librement positionnée, l’exactitude reste métrique mais avec une résolution subcentimétrique, alors que placer la station de base sur un emplacement connu ou exploiter une station de référence de position connue ramène l’exactitude à la résolution du centimètre. Afin de valider sur le terrain la qualité de la mesure et de l’interpréter dans un contexte géographique, nous avons transmis le fruit de ces calculs à QGIS sous GNU/Linux et QField sous Android, qui par ailleurs affichent les fonds de cartes ou résultats des analyses antérieurs sur le site d’étude.

Nous avons mentionné notre capacité à « cross-compiler » rtkrcv sur Raspberry Pi 4 : étrangement, nous ne sommes jamais arrivés à obtenir une position centimétrique, l’instruction satellite de rtkrcv indiquant tout au plus deux satellites en mode RTK alors que le même fichier de configuration avec l’antenne au même emplacement permet d’obtenir une solution sans problème sur ordinateur portable, et ce même en passant le processeur de la Raspberry Pi 4 en mode performance pour le cadencer à 1500 MHz. Le problème doit être lié à la puissance de calcul pour atteindre la solution RTK, puisqu’en l’absence de connexion à Centipède, la solution Single est atteinte en quelques minutes. Pourtant, [7] annonce faire fonctionner cette combinaison : nous y constatons que seule la porteuse L1 est traitée, et en effet nous convergeons vers une solution de type Single dans cette configuration, avec une exactitude métrique et non centimétrique.

Les fichiers de configuration de RTKLIB utilisés au cours de ces expériences (rover Zed-F9P vs basestation Zed-F9P ou Centipède ou IGN) sont disponibles à https://github.com/jmfriedt/RIOT_NyAlesund.

Remerciements

Au cours de l’Eclipse IoT Day organisé à Grenoble les 19 et 20 janvier 2023 [6], les administrateurs de Centipède nous ont fait remarquer qu’il est possible d’abaisser la bande passante de communication en n’acquérant qu’une mesure toutes les 5 secondes (au lieu de chaque seconde actuellement) et que le taux de rafraîchissement des corrections résultant est suffisant pour la correction RTK, un point intéressant lorsque le débit de communication est limité.

Références

[1] J.-M Friedt, « Communication LoRa au moyen de RIOT-OS pour la mesure centimétrique par GPS différentiel avec RTKLIB », Hackable 45 (nov.-déc. 2022) - https://connect.ed-diamond.com/hackable/hk-045/communication-lora-au-moyen-de-riot-os-pour-la-mesure-centimetrique-par-gps-differentiel-avec-rtklib

[2] G. Goavec-Merou, J.-M Friedt, « On ne compile jamais sur la cible embarquée : Buildroot propose GNU Radio sur Raspberry Pi (et autres) », Hackable 37 (2021) - https://connect.ed-diamond.com/hackable/hk-037/on-ne-compile-jamais-sur-la-cible-embarquee-buildroot-propose-gnu-radio-sur-raspberry-pi-et-autres

[3] RTKLIB Manual : Demo5 version (2021) à
https://github.com/rtklibexplorer/RTKLIB/blob/demo5/doc/manual_demo5.pdf

[4] F. Trystram, Le procès des étoiles, Ed. Seghers (1979) ou J. Verne, Aventures de trois Russes et de trois Anglais dans l’Afrique australe, Ed. Hetzel et Cie (1872) replacé dans un contexte historique à https://lesia.obspm.fr/perso/jacques-crovisier/JV/verne_3R3A.html

[5] S. Barbeau, Crowdsourcing GNSS features of Android devices (2021) à
https://barbeau.medium.com/crowdsourcing-gnss-capabilities-of-android-devices-d4228645cf25

[6] Programme, transparents et vidéos des présentations de Eclipse IoT Day Grenoble 2023 à
https://wiki.eclipse.org/Eclipse_IoT_Day_Grenoble_2023#January_19.2C_2023

[7] T. Everett, Raspberry Pi based PPK and RTK solutions with RTKLIB (11/2022) à
https://rtklibexplorer.wordpress.com/2022/11/10/raspberry-pi-based-ppk-and-rtk-solutions-with-rtklib/