GoPro + RTK + IMU

Je vais essayer de vous faire une synthèse de mes travaux en relation avec le titre de ce sujet.

Donc, à l’origine, il y avait OpenStreetMap, auquel je contribue depuis 2009. J’avais commencé à archiver des données GPS pour ça depuis 2002… :grinning_face_with_smiling_eyes:

Ensuite est venu Mapillary. J’ai commencé à contribuer en 2017, avec l’application Android de Mapillary.

En 2020, après la sortie de la puce u-blox F9P, c’est l’arrivée du RTK à tarif grand public avec la promesse du positionnement centimétrique pour tous. Avec l’aide de StephaneP, je me monte mon premier rover. Par la suite, j’utiliserai aussi l’aide de Manu pour l’améliorer (design PCB). En 2021, SparkFun me prête son RTK Express pour test (test toujours en cours :sweat_smile:). C’est aussi la période de démarrage de Centipede. À l’été 2021, une première base est installée vers chez moi.

Les rovers permettent, d’une part, d’enregistrer la trace, pour utilisation directe dans OSM, par exemple. D’autre part, ils peuvent aussi transmettre, via un client installé sur un téléphone, les coordonnées courantes à d’autres applications du téléphone. J’utilise ça avec l’application Mapillary. C’est le bonheur de voir la trace des photos nerveusement scotchées sur la chaussée même si le positionnement le long de la trace ne paraît pas parfait.

Avant:

Après:

Face à ces résultats, on oublie les précédents relevés Mapillary et on recommence tout avec ce meilleur positionnement :sweat_smile:. Le petit truc qui me chiffonne aussi, c’est qu’on ne peut pas indiquer dans Mapillary qu’on a des photos localisées par RTK plutôt que GPS classique.

En parallèle, à l’été 2022, je trouve en solde la carte SparkFun supportant la puce ublox F9R. Cette puce est en fait une puce F9P à laquelle a été ajoutée une centrale à inertie (IMU). La combinaison des deux doit permettre de continuer à avoir une position précise même quand on perd la réception GNSS. Ça ne fonctionne que pour certains types de déplacement (voiture, scooter et tondeuse à gazon). Je construis un nouveau rover avec cette carte. Ça va être un peu long pour bien comprendre comme ça marche et le configurer correctement. Ce n’est que depuis début 2024 que ça va. Pour les relevés en voiture, j’utilise ce rover systématiquement.

Résultat sur un petit tunnel:

J’ai quand même des problèmes en tunnel car l’appli Mapillary s’arrête de faire des relevés quand l’incertitude annoncée est supérieure à 50 m, ce qui arrive sur les longs tunnels (>1 km). Les raccords en sortie de tunnel ne sont pas top non plus.

Exemple de mauvais raccord en sortie de tunnel:

Pendant ce temps là, suite au rachat de Mapillary par Meta, Panoramax est porté sur les fonds baptismaux. À l’été 2023, je commence à faire une copie systématique de mes contributions à Mapillary pour les verser plus tard à Panoramax (versement fait depuis). Au passage, on oublie les précédents relevés Mapillary et on recommence tout pour faire un relevé systématique sous Panoramax. Déjà vu? :sweat_smile:

Au printemps 2024, Mapillary, à travers OSM Belgium, me prête une caméra GoPro Max pour faire des relevés plus mieux. C’est le début de nouvelles aventures.

À suivre.

5 Likes

La GoPro Max est une caméra d’action (pour se filmer en action :rofl:) qui permet de réaliser des prises de vue sphériques, qu’on va appeler 360° par la suite. On peut aussi faire de l’acquisition avec un seul côté, vers l’avant ou vers l’arrière. En plus de la vidéo, on peut prendre des photos à intervalle régulier. La qualité d’image étant meilleure que si on extrait des photos de la vidéo, c’est le mode qu’utilise la majorité des contributeurs.

En 360°, l’intervalle minimal entre deux photos successives est de 2 s. C’est assez long. Par exemple, sur autoroute, ma vitesse nominale est de 30 m/s, ça fait une photo tous les 60 m. Même quand on va moins vite, ça fait encore pas mal de distance entre les photos. Inversement, quand on ne fait des photos que d’un seul côté, l’intervalle peut descendre à 0,5 s. Ça fait quatre fois plus de photos. Mon idée initiale était, lors du premier passage sur une route, de prendre des photos 360°. Si je repassais, de faire devant/derrière à 0,5 s. On note aussi que la GoPro Max possède un GPS interne. Néanmoins, quand on a le RTK à côté, on aimerait bien s’en servir à la place du GPS interne. Si on ne peut pas le faire en temps réel, on peut le faire après coup avec JOSM. On charge les photos et la trace GPS/RTK puis on demande à corréler les deux. On peut ajuster un décalage de temps entre les deux, ainsi que le positionnement relatif de l’antenne GPS/RTK et de la caméra.

En mai 2024, je commence mes essais sur le terrain. C’est l’objet de ma virée au Lautaret. Je vous passe les détails et je vais directement aux conclusions:

  • l’heure est enregistrée sous différents champs dans les photos, principalement DateTimeOriginal et GPSDateTime;
  • les heures sont enregistrées à la seconde près;
  • les heures Original et GPS ne sont pas synchronisées;
  • l’heure Original dérive significativement dans le temps, plusieurs secondes par jour;
  • l’heure Original est normalement recalée quand on déclenche l’acquisition avec l’application Android. Recalée sur quoi? Sur l’heure du téléphone?
  • les photos ne sont pas tout à fait prise avec l’intervalle prévu, que l’on compare au temps Original qu’au temps GPS, surtout pour les séquences à 0,5 s. Limite de traitement de la caméra?
  • les coordonnées GPS sont prises à la fin du traitement de la photo. Pour les 360°, c’est d’environ 1,25 s, soit 40 m sur autoroute.

Les premières conclusions étaient, avec l’arrondi à la seconde et la dérive, qu’il était pratiquement impossible de gérer les acquisitions à 0,5 s. J’ai décidé de faire les acquisitions devant/derrière à 1 s. J’ai aussi choisi de ne pas envoyer les séquences sur Panoramax en attendant d’avoir un traitement satisfaisant. J’ai ensuite vu que même à 1 s, il y avait des irrégularités. Enfin, fin juillet 2024, je suis tombé sur des cas où même le 360°/2 s avait des irrégularités. J’ai aussi arrêté l’envoi à Mapillary.

Je me suis mis à cogiter. :sweat_smile: Pendant ce temps là, le stock de photos montait. :face_with_spiral_eyes:

À suivre.

1 Like

Après un hiver à cogiter, je me suis dit qu’il fallait y aller. Dans un premier temps, je regardé de nouveau le temps GPS mais avec, au mieux, un saut d’une seconde sur deux heures d’acquisition, ça paraissait difficile de faire une évaluation précise de la dérive. Peut-être analysant ensemble plusieurs séquences et en supposant une dérive constante, supposition à priori douteuse, tenter un calcul global. Puis, plutôt que prendre le temps GPS, pourquoi ne pas prendre la position GPS? Certes, il y a le décalage temporel de la prise de coordonnées mais le décalage semble bien stable (Gopro : décalage longitudinal et comment recaler avec JOSM). On pourrait corréler les coordonnées GPS de la GoPro avec les coordonnées calculées avec la trace RTK. Si on suppose que la GoPro prend les photos à intervalle régulier, il faut alors ajuster l’heure de la première photo et l’intervalle entre deux photos. Bon, ben, c’est parti. :sweat_smile: Un petit moindre carré visant à minimiser la somme des carrés des distances entre point GoPro et point RTK, en optimisant l’heure initiale et l’intervalle. Quelques essais laborieux au début mais ça finit par marcher. Une fois qu’on a les paramètres, on réinjecte l’heure précise à la milliseconde dans les EXIFS des photos. Ensuite, direction JOSM pour géoréférncer les photos sur la trace RTK, avec ajustement précis du décalage temporel, orientation des photos et tout.

Exemple de résultat dans les plaines de l’ouest de la France (Angoulême, N141(2x2), Chasseneuil-sur-Bonnieure, D951 (double-sens), Bellac, N145 (double-sens), croisement A20). 3000 photos (1h40 d’acquisition) :

On a :

  • Date et heure de la première photo.
  • Intervalle.
  • Erreur moyenne.
  • Erreur Max.

L’erreur moyenne, typiquement vers 1,70 m dans ces cas (route dégagée), montre que le GPS de la GoPro n’est pas mauvais en terrain dégagé. L’erreur max de 5 m montre qu’il n’y a pas de point aberrant, sachant que j’ai éliminé en amont les points latéralement trop loin (5 m) de la trace RTK. Ça peut être pire. Sur Grenoble-Lyon (périphérique nord en souterrain)-début A89, la moyenne reste à 1,81 m mais l’erreur max monte à 24 m.

Graphique des erreurs au cours de la séquence :

Il n’y a pas de tendance globale qui indiquerait que le modèle utilisé est incorrect.

L’intervalle semble proche de 2 s mais pas tout à fait. Là, on a une dérive de 0,22 par heure. À 30 m/s, ça fait 6,6 m par heure. Les valeurs d’intervalle changent un peu et sont typiquement dans la tranche 1,99980 et 1,99990. Je pense que c’est la température qui fait changer l’intervalle, plus petit quand il fait frais, plus grand quand il fait chaud. Pour le moment, je n’ai que des valeurs sur une traversée aller-retour de la France en plein été.

Ensuite, sous JOSM, j’essaie d’ajuster le décalage temporel résiduel à différents points d’une séquence. Ça se joue à quelques centièmes de seconde. J’estime que l’ajustement longitudinal est précis à moins d’un mètre (0,03 s est équivalent à 1 m à pleine vitesse).

Vous pouvez voir la séquence est question ici:

À suivre.