RTK moving base

J'ai craqué pour un GPS RTK...

RTK est l'acronyme de Real Time Kinematic. C'est une technique qui permet d'améliorer la précision d'un GPS (appelé Rover), grâce à un deuxième GPS (généralement fixe et appelé Base) à proximité.

L'amélioration de la précision en temps réel est permise grâce à l'envoi de correction de la Base vers le Rover.

Jusqu'à présent c'était une technologie assez couteuse, mais la miniaturisation permet aujourd'hui d'y accéder... pour les bourses bien remplies...

J'ai commandé un GPS "base" et un "rover" chez Drotek (en fait ça fait déjà 2ans, mais ils étaient restés dans un placard...).

J'ai vu qu'il y avait aussi une alternative (reach-rtk) intéressante chez Emlid.
A noter également que la version tiny RTK n'est pas opensource/hardware, et que d'autres versions sont réputées plus ouvertes comme la version smartnav. Mais la version tiny RTK a l'avantage de tout avoir sur une seule puce.

Une fois la commande reçue, première surprise : les cartes sont vraiment toutes petites, même avec le boitier! De quoi en embarquer une sur un drone, ou un cerf-volant. Le plus lourd étant l'antenne (environ 50g), qui semble cependant nécessaire pour avoir un bon signal.

La documentation est disponible sur le site de Drotek.

Il faut commencer par installer le logiciel u-center de u-blox, l'entreprise qui fait la carte du récepteur GPS (neo-M8P).

Une version récente (18.11) existe, mais elle ne correspond pas à la plupart des tutoriels et je l'ai trouvé moins intuitive. Je suis resté sur la version 8.26 (toujours téléchargeable).

Mauvaise surprise : le logiciel n'est disponible que pour PC (et une version pour android également).

Mon dual boot sur Windows étant cassé, et souhaitant rester sur linux/ubuntu, j'installe le logiciel avec Wine.

Après lancement de u-center, le GPS branché en USB n'est cependant pas visible.
J'ai trouvé la solution sur le wiki de Paparazzi, il faut créer un lien symbolique :

ls /dev

En branchant débranchant

mkdir -p ~/.wine/dosdevices

ln -s /dev/ttyACM0 ~/.wine/dosdevices/com1

On arrive ensuite à se connecter



Cela m'a permis de prendre en main le réglage des (nombreux) paramètres

Mais assez vite je me suis retrouvé face à des difficultés avec des paramètres qui ne pouvaient pas être modifiées (ou plutôt qui revenaient à leurs valeurs initiales). Cela est lié pour une part à la sauvegarde des paramètes dans la mémoire temporaire de la puce, ce qui nécessite de faire "send" (en bas à gauche de la fenêtre) après chaque modification. Avant un redémarrage, il faut également sauver les paramètres dans les mémoires plus durables de la puce.



Une bonne chose est qu'il est possible de retourner à une configuration de base, ce qui après avoir essayé de changer un peu tous les paramètres (et ne plus trop savoir lesquels) est bien utile.



Je n'en suis pas sûr, mais il m'a semblé qu'il était bon de repasser par la configuration de base pour avoir un comportement plus stable, par exemple avant une mise à jour du firmware.



Je me suis retrouvé en difficulté lors de la mise à jour du firmware. En effet, ma version datant un peu, le firmware présent ne permettait pas de faire du RTK en moving base. Il fallait donc faire une mise à jour du firmware, vers la dernière version 3.01 HPG 1.40 mais celle-ci échouait systèmatiquement.



Je pense que cela était en partie liée au fait que la carte rebootait avant la mise à jour, ce qui empêchait le lien symbolique de fonctionner. La fenêtre de mise à jour devient rouge, mais parfois rien n'indique clairement qu'il y a eu un problème. Après de nombreux essais, j'ai donc trouvé un autre PC pour pouvoir utiliser windows et m'affranchir des problèmes qui pourraient être liés à une utilisation avec Linux.

Malheureusement, pas plus de succès avec Windows au début, ni avec les versions plus récentes de U-Center qui présentent un nouvel outil de mise à jour.

D'après certains commentaires sur des forums, le problème vient de l'utilisation du port USB et non du port série (UART), et éventuellement de problème de driver selon la version de Windows (guère mieux que Linux au final!). Mais pourtant certains clamaient avoir réussi la mise à jour de la même carte de Drotek.

En reprenant ces paramètres de base, et à force d'essayer cela a fini par marché dans certains conditions, mais sans que cela soit 100% reproductible.

Cela a marché lorsque je lançais une première fois la mise à jour avec les paramètres suivants :

Au moment du reboot, windows indiquait une erreur de driver (en bas à droite), puis la mise à jour échouait après un timeout. Le gps n'était alors plus reconnu par windows et automatiquement déselectionné de U-Center.
Je débranchais ensuite la prise USB, puis la rebranchais. Le port com réapparaisait et je réselectionnais le GPS. Je relançais une mise à jour, mais cette fois en choisissant de faire la mise à jour par le port USB.




Et là parfois, victoire, une barre de défilement apparait et à la fin l'écran devient vert. Il était enfin temps de passer à l'étape suivante.
 

Par défaut, le récepteur GPS envoie des trames NMEA que l'on peut voir passer dans la "Packet console".



Cette configuration par défaut est adaptée pour le Rover, mais pour la base, il faut enlever ces trames NMEA afin de ne pas gêner les messages RTCM (selon débit de la communication).

Pour cela, le plus rapide est d'aller dans la "Message view". On y voit un arborescence avec les différentes messages existants. Les messages effectivement envoyés sont en noir, ce qui ne sont pas envoyés en gris.



Pour les (nombreux) messages NMEA, il est possible de les déleselectionner directement ici (ce qui est beaucoup moins laborieux que la méthode détaillée plus bas).



Ceci stoppe les messages (et donc la mise à jour des infos dans les fenêtres de droite qui se mettaient à jour si votre antenne était en vu des satellites).

Pour passer en Moving Base, il faut utiliser le réglage suivant :


Puis autoriser les messages RTCM nécessaires :

Extrait du doc du C94-M8P

Dans mon cas, j'ai sélectionné le port USB pour faire mes tests.


J'ai utilisé un script python pour forwarder les correction du GPS Base vers le GPS Rover à travers mon PC

import serial
import time # Optional (if using time.sleep() below)

serBase = serial.Serial(port='COM16', timeout=1)
serRover = serial.Serial(port='COM17', timeout=1)

while (True):
    if (serBase.inWaiting()>0): #if incoming bytes are waiting to be read from the serial input buffer
        data = serBase.read(serBase.inWaiting())
        #data_str = data.decode('ascii') #read the bytes and convert from binary array to ASCII
        print(data) #print the incoming string without putting a new-line ('\n') automatically after every print()
        serRover.write(data)
    if (serRover.inWaiting()>0): #if incoming bytes are waiting to be read from the serial input buffer
        data_str = serRover.read(serRover.inWaiting()).decode('ascii') #read the bytes and convert from binary array to ASCII
        print(data_str)
    time.sleep(0.01) # Optional: sleep 10 ms (0.01 sec) once per loop to let other threads on your PC run during this time. 

Après quelques essais en extérieur, j'ai bien la qualité du signal gps (dans la trame GGA) passer de 1 à 2 ou 5.

Doc récepteurs de la série M8

Doc M8P

Doc de chez sparkfun 

Doc carte d'évaluation

Doc uCenter