|
PROJETS GPS |
|
Simulation du design original avec 24 satellites GPS (4 satellites dans 6 orbites), montrant leur évolution à partir d'un point fixe (45ºN) avec les lignes de visibilité. La terre est supposée parfaitement ronde à rayon de 6300 km
(Matlab+Adobe) Situation du 9.12.2007 image du domaine public
| |
 |
Sur
l'image de gauche, l'opératrice tient un récepteur GPS-RTK utilisé pour
les travaux usuels d'arpentage. Cet appareil est bi-fréquence et multi
constellations capable d'une précision centimétrique en temps
réel. Dans ce cas ci, l'ensemble est un TRIMBLE R8
GNSS avec controlleur TSC2. L'objectif de ce projet est de démontrer les résultats obtenables à
partir de modules GPS coutant beaucoup moins cher que l'appareil du
haut
La différence principale entre ces produits est la ''robustesse''
entendue dans le sens technologique: l'appareil du haut fonctionne
toujours et dans presque toutes les situations tandis que les capteurs
monofréquence du bas sont sensibles à la géométrie des constellations,
à la météo et surtout aux obstacles inévitables obstruant le ciel.
Cependant si l'opérateur tient compte de ces limitations et adapte sa
procédures en conséquence, ils sont parfaitement capable de précision
quasi identique au GPS haut de gamme.
|
Système de Positionnement Géodésique
Des modules GPS
monofréquence L1 capables d'émettre des
données brutes ('raw data') sont utilisés couplés à des antennes
TALLYSMAN . Ces récepteurs sont généralement employés pour des applications de navigation automobile ou de drone.
|
|
le récepteur U-BLOX NEO 6P monofréquence GPS seulement
capable de précision centimétrique en mode statique |
l'antenne Tallysman TW3400 |
|
NVS NV08C-CSM GPS-Glonass-Galileo
U-BLOX NEO-M8N GPS-Glonass GPS-Beidou |
 |
|
| Lancé en 2016 le UBLOX NEO M8T GPS/QZSS, GLONASS, BeiDou et Galileo |
 |
Le traitement de données
se fait par le logiciel open-source RTKLIB
sous windows qui permet d'obtenir une
solution centimétrique
par diverses méthodes soit:
a) méthode par post
traitement différentiel de phase
b) méthode Statique Rapide qui nécessite un moyen de communication entre les récepteur
c) méthode Cinématique qui est légèrement moins précise selon nos essais (résultat plus bas).
|
|
La station 'MOBILE' a la même configuration sauf qu'une pôle télescopique est utilisée. Au besoin, la pôle peut être supportée par un trépied modifié à cet effet. Une tablette ultra portable avec téléhone complète l'ensemble. Les récepteurs doivent être configurés via des lignes de commande lancées au démarrage pour une sortie UBX ('raw data').
|
A) solution Statique par Post Traitement
Cette solution a l'avantage de ne pas nécessiter de lien de communication entre la base et le mobile.
Le système est donc opérationnel dans les endroits ou il n'y a pas d'accès internet. L'inconvenient est que nous savons seulement
au moment du traitement si le captage s'est correctement effectué.
Procédure terrain:
1) de la mission dans le but d'effectuer les observations à un moment de la journée ou le nombre de satellites visibles
est maximum et la dilution de la précision (DOP) est minimale. On peut utiliser à cet effet l'application en ligne de Trimble
2) Installation de la base sur un point géodésique du MERN ou un point dont les coordonnées sont connues. La ligne de base doit
être inférieure à 10 km pour conserver une précision acceptable.
3) Observations simultannées des points a relever avec la station mobile.
4) Les données brutes des sites 'base' et 'mobile'
observées simultanément sont enregistrées en format natif *.ubx sur les
portables
avec l'option de traitement 'simple'.
Prévoir un temps de saisie de 15 minutes. On peut alternativement utiliser des téléphone android
avec l'application RTKGPS+ (2.4.3b22). Attention, les fonctionalités cinématique et statique ne fonctionnent pas avec cette version.
Procédure avec RTKLIB:
1) conversion des données *.ubx (natives brutes u-blox) base et mobile en format RINEX
avec l'application RTKCONV
2) post-traitement avec RTKPOST (entrée des coordonnées réelles de la base à l'onglet 'options': lattitude, longitude, hauteur ellipsoidale)
3) visualisation de la solution avec RTKPLOT en activant uniquement les données qualifiées 'fixed' (Q=1)
TEST DU SYSTÈME (capteur NEO 6P // 19 au 23 .08.2013)
B) solution Statique Rapide (28.10.2018)
Cette solution est avantageuse car elle élimine l'étape post-traitement nous donnant une solution fixe après 5-10 minutes de
captage. Cela nous permet de savoir sur le terrain si l'opération a réussi .
La procédure proposée ici consiste à faire le traitement par rtknavi roulant sur un ordinateur windows externe exposé a internet.
ARCHITECTURE DU SYSTÈME
 |
La configuration logicielle est la suivante
Du
coté BASE: RTKGPS+ single Input serie Output LOG STREAM: TCP client (server_name/port 5000)
Du coté du MOBILE: Input serie Output LOG STREAM: TCP client (server_name/port 5001) Pour RTKNAVI sur le serveur intermédiaire: Input base: TCP server (port 5000) Input mobile: TCP server (port 5001) Output NMEA: TCP server (port 5002) Documenter
les coordonnées de la base:
lattitude, longitude, hauteur ellipsoidale à l'onglet Options/Position. |
|
Le processus est démarré, le système produit rapidement une solution 'flottante' et ensuite, on a les solutions fixes (5-10 min.).
Interface RTKNAVI (RTKLIB) sous Windows (solution fixe)
|
|
 |  |
le système est fonctionnel en autant que la longueur de la ligne de base demeure dans l'intervalle recommandé. |
environnement boisé | environnement
urbain non dense |
C) Solution Cinématique
Comparaison d'une solution Statique Rapide
vs Cinématique
|
|
Nous avons un point référence dont les coordonnées sont connus ayant été calculés par post-traitement. Ce même point est ensuite observé et traité par méthode Statique Rapide et ensuite Cinématique. Le résultat superposé est illustré dans l'image de gauche.
La précision de la solution Statique Rapide s'approche beaucoup de celle obtenue par post-traitement i.e. 1-2 cm. La solution Cinématique occupe un carré de 3cm x 4cm ce qui révèle que celle-ci est moins appropriée (ou limite) pour une application de précision.
La question est de savoir si les algorithmes de l'application Cinématique du logiciel manquent de robustesse ou bien les récepteurs ne sont pas suffisamment précis (horloge interne ?).
|
|
En fait, l'imprécision provient des récepteurs qui n'utilisent que la fréquence L1. Des travaux de l'Université Corpus Christi (2012) le confirment: les coordonnés horizontales obtenues par levé Cinématique GPS L1 d'un point fixe se situent dans un carré de 4cm x 4cm, ce qui est dans le même ordre de grandeur que nos résultats.
La qualité des récepteurs n'est donc pas en cause et cette imprécision (relative) est intrinsèque au système mono-fréquence.
|
 |
E) Capteur NV08C Bluetooth
02.02.2016
