Une virée au Lautaret

Je contribue à Mapillary depuis 2017 avec un smartphone. Depuis 2021, j’ai ajouté le RTK pour avoir des positions plus précises. Il reste quand même des problèmes de positionnement le long de trace qui fait qu’on est loin du centimètre en pratique. Depuis bientôt 2 ans, j’essaie aussi d’ajouter une centrale à inertie pour compléter le positionnement dans la réception GNSS est mauvaise. Ça commence à bien marcher depuis l’été 2023. Je stocke mes acquisitions Mapillary depuis cette période pour un futur transfert vers Panoramax en espérant résoudre les problèmes de précision. Au printemps 2024, j’ai reçu en prêt une GoPro Max de Mapillary par l’intermédiaire d’OSM Belgique.

L’objectif du jour est d’aller faire du ski de rando au Col du Lautaret au départ de Grenoble. C’est une occasion inespérée de faire une grosse moisson de photos Mapillary/Panoramax.
Difficulté supplémentaire, il y a des tunnels. Je dispose de :

À noter qu’avec OpenCamera, sur mes deux téléphones, la géolocalisation n’est pas stockée avec assez de digits. C’est arrondi à une trentaine de mètres et il faut que je reprenne la géolocalisation en post-traitement. Et pour Mapillary, comme signalé précédemment, les photos sont mal placées le long de la trace. Dans les deux cas, la géolocalisation n’est pas satisfaisante et je veux l’améliorer avant de passer à Panoramax.

Compte-tenu de tous ces éléments, je veux continuer à prendre des photos en frontal avec un téléphone en plus des photos 360°. D’où le programme :

Aller : prendre uniquement des photos frontale dans la partie de la route avec tunnels, c’est-à-dire en amont du Bourg d’Oisans. Sachant que l’application Mapillary s’arrête de prendre des photos en tunnel quand l’incertitude transmise par le F9R est supérieure à 30 m et que c’est vite le cas, j’opte pour OpenCamera. Donc, on prend la route avec le RTK dès le début sur le téléphone secondaire. Ça va bien. Je déclenche l’acquisition photo au début des gorges de la Romanche. Ça se passe bien sauf que l’espace disponible semble limité. OpenCamera stocke dans la mémoire interne où je n’ai que 3 Go. Je finis au col du Lautaret avec 0,2 Go de libre. Je découvre aussi que je n’ai plus de réseau et donc de correction RTK depuis un certain temps. Je ne m’en étais pas rendu compte en roulant car OpenCamera prend tout l’écran y compris la barre de notification où il y l’icône d’état de Lefebure. (En fait, il n’y a que le dernier kilomètre qui est concerné).

Après le ski, je profite de la pause boisson pour essayer de repasser l’enregistrement d’OpenCamera sur la carte SD (de 128 Go). Je n’y arrive pas alors que ça fonctionnait avant (testé à l’été 2023 mais j’ai réinitialisé le téléphone depuis). Peut-être ce bug:
https://sourceforge.net/p/opencamera/discussion/general/thread/487f7d956b/

Retour : Installation de la GoPro sur le toit de la voiture. J’ai fait des essais la veille mais c’est le première usage réel. Petit stress. Je passe aussi sur le téléphone principal. Je démarre avec OpenCamera… qui plante au bout de 12 photos. Je bascule sur Mapillary. Sauf qu’en l’absence de la localisation fictive, il va arrêter de prendre des photos dans les tunnels. On va faire avec. Je ne vais pas faire poireauter mes coéquipiers plus que ça. En route, je profite d’un arrêt à un feu de chantier pour aller jeter un coup d’œil à la GoPro. Elle a l’air éteinte. Je la rallume et je relance. En fait, non, c’est seulement l’écran qui était éteint. Je n’avais pas repéré la petite LED qui clignotait. J’arrête l’acquisition frontale en cours quand ça tourne légèrement à la pluie. La GoPro continue. De retour à la maison, j’ai bien des photos de toute la route dans la GoPro.

À l’arrivée, il reste 38 % de batterie pour deux heures de route. C’est carrément faible. Pour le stockage, seulement 11 Go occupés sur 120 Go. Il y a plus de marge.

À suivre, le post-traitement.

3 Likes

Post-traitement, je veux :

  • éliminer les photos superposées (arrêt aux feux et autres stationnements)
  • géolocaliser précisément les photos. Au moins trois cas différents : GoPro, OpenCamera et Mapillary. Sur smartphone Android, l’heure courante n’est pas stable. Elle est recalée de manière irrégulière (~1/2h) sur le réseau. Pour Mapillary, il y a sans doute deux sous-cas avec et sans “localisation fictive”. Avec la “localisation fictive”, j’ai les logs des points GPS qui ont été transmis au téléphone et qui ont permis à Mapillary de choisir le moment de déclenchement des photos. Ça doit me permettre de reconstituer de manière plus précise l’heure de déclenchement des photos. J’ai vérifié avec l’acquisition RTK à 1 Hz mais je viens de passer à 4 Hz.
  • incertitude : stocker l’incertitude estimée sur la position. Dans un premier temps, stocker le type de fix (RTK ou pas…). Plus tard, les informations d’incertitude par exemple récupérées dans les sentences NMEA GST.
  • enregistrer le système géodésique. Une précision centimétrique n’a de sens que si on connaît le système géodésique utilisé (RGF93 pour la France). On peut l’indiquer à travers son code EPSG. Néanmoins, le code EPSG n’a de sens que si on est en RTK (fix ou flottant).
  • corriger les traces dans les tunnels en lissant les raccords en sortie de tunnel à l’aide des données de l’IMU.
  • enregistrer la direction de la prise de vue, idéalement d’après les infos de l’IMU que j’enregistre dans plusieurs sentences NMEA et UBX.
2 Likes

Pour le moment, post-traitement basique pour Mapillary.

  • Pour la courte séquence avec Mapillary et la position fictive (du col au Lauzet), pas de post-traitement. Le seul passage critique est la galerie paravalanche de la Marionnaise. Elle fait 400 m de long. L’incertitude de position est montée seulement à 6 m. Mapillary n’a pas arrêté les acquisitions. Les photos sont bien en retard de 2 s sur la position où elles devraient être sur la trace. Toutes les traces pointent à 90°. L’altitude est à priori aussi manquante.
    Mapillary cookie policy use
  • Pour le retour avec Mapillary sans position fictive, pas de prise de vue dans les tunnels. Reprise de position avec la trace RTK dans JOSM. Ajustement au doigt mouillé du décalage entre heure des photos et heure GPS. Les photos semblent mal réparties le long de trace, comme s’il y avait des problèmes sur le timestamp des photos (et décalage temporel qui semble changer d’une photo à l’autre):

    À gauche, avant correction. À droite, après correction.
    Toujours dans JOSM, forçage de l’orientation sur l’axe de progression et ajout du décalage entre antenne et caméra. J’ai aussi une altitude dans les EXIF. Il faudrait quand même vérifier si c’est bien une altitude au-dessus du niveau de la mer comme mis dans les EXIF ou si c’est une hauteur par rapport à l’ellipsoïde. :sweat_smile:
    Mapillary cookie policy use
  • L’aller avec OpenCamera.Un peu pareil que le cas précédent. Utilisation de JOSM. Décalage temporel instable et photos par super régulièrement réparties. Ça semble quand même moins pire qu’avec Mapillary.
    Mapillary cookie policy use
  • GoPro : toujours avec JOSM. Décalage temporel de 200 s ! Il va falloir rerégler l’heure de la GoPro plus souvent. Par contre, avec la vision latérale, il est très facile d’ajuster le décalage temporel au 1/10 s.
    Photo à l’entrée du tunnel:
    Mapillary cookie policy use
    Vue en plan:
3 Likes

Une fois tout ça posé à plat et par rapport à l’objectif de positionner précisément les photos, le mieux est de ne pas faire de capture avec un smartphone et de tout faire avec la caméra. Inconvénient, je ne peux pas faire acquisition à 360° et frontale en même temps. Plus la batterie un peu limitée. Il en faudrait deux et un chargeur USB pour recharger en roulant celle qui ne sert pas.

1 Like

Hier soir, réunion du groupe local avec une présentation de Panoramax par barnes38. On a discuté GoPro Max et RTK. Comme signalé plus haut, la GoPro avait un fort décalage temporel et semble, globalement, avoir une forte dérive, ce qui est dommage pour un appareil équipé d’un GPS. Ça m’a donné l’idée d’aller voir ce qu’il y avait dans les EXIF, en particulier côté GPS:

DateTime        2024:05:08 14:39:24
DateTimeOriginal        2024:05:08 14:39:24
DateTimeDigitized        2024:05:08 14:39:24

GPSTimeStamp        12:36:03

La bonne nouvelle est que l’heure GPS est stockée dans les photos. Et ça confirme que l’horloge de la GoPro n’est pas synchronisée au GPS avec plus de 3 mn de différence!!!

La mauvaise nouvelle (déjà signalée par StephaneP), est que l’heure est stockée à la seconde près, pas de milliseconde. Ça ne va pas être facile de recaler les photos quand on en prend plus de une par seconde.

À noter que l’application de contrôle de la caméra depuis un smartphone recale régulièrement l’heure de la caméra. À voir si c’est un avantage ou un inconvénient pour un calage précis des photos (surtout en voiture).

2 Likes

Merci je n’avais pas attention à ce décalage…
Je vais essayer de corriger mes séquences rtk, dans JOSM, en recalant chacune sur un repaire visuel visible sur une des photos, et aussi dans le fond de photographie aérienne DBOrthoIGN. En utilisant “l’ajustement manuel”, on peut faire glisser toute la séquence de photos sur sa trace rtk et corriger la position des photos assez finement !

Mon mode opératoire est d’ouvrir la photo 360° en dehors de JOSM et de chercher des points de repère visibles sur la photo 360° et l’orthophoto, idéalement, perpendiculairement au déplacement. Sur l’exemple suivant, il y a la rambarde du pont à droite et on est à peu près au milieu du pointillé blanc à gauche.

Et donc, quand on a fait du timelapse à 2 images par seconde avec l’heure notée à la seconde, ça donne ça au moment de géoréférencer:

Les images sont réunies par paquet de 2. :cry:

Aujourd’hui, j’ai comparé dans les décalages temporels entre GPSDateTime et DateTimeOriginal pris dans les EXIF des photos. La situation n’est pas catastrophique comme je le pensais. Les décalages temporels sont assez stables.

Sur le retour du Lautaret, 2 h de route, il y a une différence de 1 s entre le début et la fin.

Un autre jour, 1 heure d’acquisition. Pas de différence entre le début et la fin.

Enfin, dernier jour avec la capture frontale précédente à 2 images/s. Aller-picnic-retour. Le truc marrant, c’est qu’à un moment, les heures s"'incrémentent de manière décalée, une sur une photo, l’autre sur l’autre:

DateTimeOriginal GPSDateTime
2024:05:12 16:01:36	2024:05:12 14:02:15Z
2024:05:12 16:01:36	2024:05:12 14:02:16Z
2024:05:12 16:01:37	2024:05:12 14:02:16Z
2024:05:12 16:01:37	2024:05:12 14:02:17Z

Donc, le matin, le décalage est de 40 s. L’après-midi, en repartant, il est de 39 s puis il se met à osciller entre 39 et 40 s. 5h45 entre le début et la fin. La caméra était en charge pendant la pause. Est-ce que ça peut influencer la stabilité de son horloge?

J’ai oublié de préciser qu’entre la séquence n°2 en fin de journée et la séquence frontale le lendemain matin, le décalage est passé de 43 à 40 s.

Pour l’histoire des demi-secondes, j’ai envoyé à Mapillary sans recaler sur la trace RTK/IMU (faut justifier le prêt de la caméra :sweat_smile:). Forcément, dans les tunnels, ça ne le fait pas:

Sauf que je suis en train de me dire qu’il n’y a qu’à virer une image sur deux pour résoudre le problème d’arrondi (plutôt que refaire la route à 1 image/s).

Photos mal placées de 30 km :

350 m après la sortie d’un tunnel.

J’étais en train de regarder pour ne garder qu’une image sur deux mais je découvre que l’heure enregistrée n’est pas régulière:

À gauche, DateTimeOriginal, à droite GPSDateTime.

Des fois, il y a 3 photos de suite avec la même heure (trait rouge), des fois, une seule (point rouge). L’heure GPS est plus régulière… mais manquante dans les tunnels.

Je continue mes investigations. J’ai tracé la différence de temps entre le temps GPS et l’horloge interne de la GoPro sur une série de 999 photos (à 2 images/s):

On voit clairement une dérive. Avec 7e-4 s par image, ça ferait 125 s par jour. Le temps GPS est stable. C’est le temps local qui a des irrégularités. Sauf que j’ai trouvé une autre série où le temps GPS a aussi des grumeaux:

image

Pas détecté de problème en mode 360° à 2 s.

J’avais écrit des scripts pour interpoler les timestamps avec mes caméras Yi. En résumé, je n’ai pas trouvé de solution qui fonctionne convenablement.
Tu auras peut-être un peu plus de réussite car tu sais que normalement tu as environ 500ms entre chaque photo. Tes “grumeaux”, c’est probablement des moments où le timelapse a été un tout petit peu trop rapide (ou trop lent), et tu te retrouves avec 3 photos la même seconde.

Je pensais tenter de répartir régulièrement dans le temps les photos au sein d’une séquence en utilisant le temps GPS pour la tendance globale. Je vois aussi que les dérives varient dans le temps. Effet de la température sur l’horloge interne? Pour le moment, ce n’est pas dans mes priorités. Je vais déjà aller voir si le problème persiste à 1 image/s.

J’ai géoréférencé à l’arrache mon paquet à 2 image/s. J’ai viré les images superposées avec ton script. J’ai envoyé le résultat à Mapillary. De toute façon, c’est toujours meilleur que si j’avais utilisé l’appli Mapillary sur mon smartphone où les décalages temporels sont supérieurs à la seconde.

Juste par curiosité, as tu aussi testé différentes cartes micro SD et comparé les temps d’écriture des fichiers JPEG et l’influence que peut avoir celui-ci sur une séquence de capture si la carte n’est pas performante …?

Non, c’est la GoPro avec sa carte µSD fournies par OSM_BE. Je n’ai pas fait de tests sur la carte µSD.

On pourrait interpoler les images impaires avec les paires… c’est pas idéal mais en première approximation (je sais, ce mot à ajouter parfois à notre vocabulaire).