PoC correction horizon avec IMU Witmotion

Bonjour,

Afin de trouver enfin une solution aux problèmes d’horizon rencontrés lors de relevés, notamment sur les casques vélo, j’ai investi dans un WT9011DCL :
:backhand_index_pointing_right: Fiche produit

Ce capteur enregistre le pitch, roll et yaw via une connexion BLE au téléphone.

Sa compacité et son autonomie me semblent idéales pour accompagner une GoPro Max dans ce type de relevés.


Fréquence des relevés

Alors que les relevés de la GoPro sont limités à 0,5 Hz (soit une image toutes les 2 secondes), le capteur peut monter jusqu’à 200 Hz (valeur configurable).

Pour synchroniser la GoPro avec les mesures, je prends en photo l’écran du téléphone affichant les données en temps réel avec la GoPro tout en tournant le casque, de manière à faire varier progressivement le yaw.

Reste à retrouver ensuite les valeurs prises en photo pour les aligner avec une photo GoPro.

À 10 Hz (soit 10 mesures par seconde), il suffit de conserver 1 mesure toutes les 20 pour correspondre au rythme de 0,5 Hz de la GoPro en partant de la ligne repère.
On obtient alors les valeurs de pitch et roll correspondantes à chaque photo, ce qui permet de corriger l’orientation.

Pour cela, des outils comme img360 peuvent être utilisés.

L’application fournie ne permet malheureusement pas d’enregistrer les données pitch, roll, yaw du téléphone lui-même.
Cela pourrait pourtant être utile, notamment pour utiliser le yaw du téléphone comme référence de direction, et en déduire un delta avec le casque.

Je vais tester une petite appli maison avec Kodular, sauf si vous connaissez déjà une alternative simple.

Les premiers tests réalisés en intérieur sont encourageants.
Je prévois une session en extérieur plus représentative pour publier un exemple concret.

7 Likes

Pour info, il existe des IMU dans certains récepteurs GNSS.

Quel que soit la source, une procédure simple d’alignement me semble possible :

  • fixer le récepteur IMU et la caméra de manière solidaire (sur la même perche, le même véhicule, la même structure indéformable…)
  • dans un endroit plat, la “perche” de la caméra étant à la verticale, mesurer les valeurs initiales du capteur.
  • démarrer les prises de vues.

Tous les angles seront calculés à partir de cette configuration de base (caméra à la verticale, regardant vers l’avant).

Aurais-je oublié quelque chose ?

Effectivement si on peut récupérer les mesures d’angle via un IMU déjà présent dans un device GNSS, c’est tout aussi efficace. A condition qu’il puisse s’intégrer au point de fixation de la camera (donc poids, taille compatible : plutôt limités quand c’est sur un casque)

Je rajouterais que sur les relevés sur casque c’est bien d’avoir deux points de mesures pour le yaw : un sur le casque et un sur le vehicule (cadre du velo) afin d’annuler les mouvements de la tête qui regarde à droite ou à gauche.
Pour permettre ça (+enregistrer les mesures: sur les smartphones Android les applis qui font les relevés en arrière plan sont killées arbitrairement …), j’ai commandé un stick M5 (M5StickC PLUS ESP32-PICO Mini IoT Development Kit | m5stack-store) + une sonde (BMM150).
Je detaillerais le montage une fois le PoC réalisé

1 Like

Du nouveau sur le sujet !

Pour l’enregistrement des données j’ai delaissé le téléphone pour partir sur un petit module ESP32, le m5stickc plus2 qui vient donc compléter le sensor witmotion.

Le résultat est plutôt pas mal
Une photo au bout de 15min d’enregistrement (avec un synchro basée sur un relevé fait en début de série)

Photo brute :

Photo corrigée

Les datas remontées et retrouvées via le script :

Le M5Stick enregistre les données du Sensor Witmotion
Il rajoute pour chaque enregistrement un ID qu’il peut afficher en gros pour pouvoir le prendre en photo via la GoPro qui permet de lier une photo et une ligne de relevé, et un timestamp qui permet de synchroniser ensuite (par intervalle de 2sec) l’ensemble des photos avec le jeu de données.

J’ai mis le détail et les scripts/firmware sur le repos git du projet GitHub - qhess34/pan360-helmetfix

Quelques améliorations à prévoir :

  • Tester l’IMU du M5Stick pour les relevés plutot que passer par le witmotion (il est plus gros et il faut pouvoir prendre la photo de l’id d’enregistrement avec la GoPro
  • Voir si possibilité de régler aussi le problème de yaw (avec un autre capteur fixé sur le cadre du velo comme référentiel)
  • Améliorer la partie algo du script de post traitement.
3 Likes

Bravo. Je n’avais pas pensé à ce point.

On pourrait avoir le smarphone fixé solidement au cadre du vélo, et ton petit IMU fixé sur la caméra (à moins qu’un jour on arrive à récupérer facilement ces données dans les photos, je parle de la GoPro Max).

Dans le cas de d’une perche fixée sur le cadre d’un vélo ou le toit d’une voiture, on pourrait se contenter du seul smartphone fixé correctement sur le tout ?

Comment les photos sont-elles corrigées ?
En lisant ton code bien documenté, tu utilises img360_transformer. Mais modifie-t-il la photo en faisant une reprojection ou est-ce qu’il ajoute des métadonnées ?

  • Dans le premier cas la qualité de la photo peut-être dégradée, ou en tout cas ça prend du temps et des ressources processeur.
  • Dans le second cas c’est très rapide et c’est donc la visionneuse 360° qui fait le travail mais sans coût supplémentaire (elle corrige les angles avant de faire sa reprojection).
1 Like

Oui effectivement un smartphone sur la perche pourrait faire le job à condition de trouver un moyen de faire une synchro avec la sequence photo (prendre en photo avec la gopro l’heure à la seconde avant de le fixer). Attention au poids et à l’emprise au niveau du nadir (pour la prise au vent, et éviter qu’il soit visible sur les photos de la gopro).

Concernant la correction j’utilise img360_transformer, mais il est tout à fait possible d’utiliser d’autres moyens. J’ai implémenté également la génération d’un csv qui liste les corrections à faire par photo. A voir ce que ça donne avec l’ajout des metadonnées. Je n’ai pas encore testé cette option, mais effectivement concernant la qualité+rapidité ça peut être clairement mieux.

À ce propos, est-ce que panoramax utilise des données exifs de pitch et roll lors de l’affichage ? Si ce n’est pas le cas, il vaut peut-être mieux utiliser img360_transformer afin de redresser les images.

Je me répond après avoir passé 2s à chercher : oui

https://gitlab.com/panoramax/server/geo-picture-tag-reader/-/tree/develop/docs?ref_type=heads

D’ailleurs je viens de publier une mise à jour du script (ajout de –update_images) pour choisir le type de mise à jour de la sequence d’image (aucune : on genere juste le CSV, metadatas : mise à jour des metadonnées, jpeg : utilisation de img360-transformer pour mettere à jour le jpeg)

Y a surement des améliorations à faire sur les metadonnées (heading à étudier par exemple)

Je viens de tester, c’est top ! Il suffit maintenant que monte l’IMU dans le bon sens…Concernant le heading, ne serait-il pas possible d’utiliser l’IMU du M5Stick en le fixant sur le cadre. Si les deux IMU donnent une accélération autour de Z trop différente, alors interpoler le yaw entre la photo avant et après.

Oui il faut bien fixer l’IMU. Concernant le sens, on peut le mettre à la verticale ou à l’horizontale (l’appli officielle permet de le configurer pour ajuster les resultats selon ça).

Pour le yaw, je ne pense pas que l’acceleration soit une base solide pour comparer le m5stick et l’IMU.
Je pensais plus me baser sur un module boussole à ajouter au M5stick ( Module boussole Grove V2 101020492 - Gotronic ) qui permettrait de faire des comparaisons (sur la TODO).

Je viens de publier des séquences brutes après juste une correction auto, le résultat est plutôt pas mal (quand je regarde les photos avec Pannelum).
C’est à mon sens un bon outil du coup pour corriger de manière au moins grossière les mouvements de tête pitch/roll lors de la prise de photos.

Le bug Photo Sphere Viewer (Difference in yaw/roll/pitch correction · Issue #1686 · mistic100/Photo-Sphere-Viewer · GitHub) étant toujours présent, le pitch est inversé coté Panoramax, il faudra attendre que ça soit fixé pour en profiter.

Au passage j’ai publié un outil pour corriger de manière réactive (rapide, intuitive et à la chaine) les exifs sur pitch/roll/yaw

Sur les 2 séquences que tu as mis dans le précédent commentaire. il n’y a pas de correction ? on est d’accord ?

Si elles les sont (on peut retrouver les corrections dans les infos exif), mais le viewer panoramax a un bug dont la correction n’est pas encore déployée.

Il inverse le correction du pitch du coup l’affichage est erroné.

1 Like

Exemple sur une des images :

Panellum :

Lien

Panoramax

1 Like

Merci beaucoup pour le script, @qhess34 . I understood from a message here from 1/Sep that there is a “-metadata” option in the script for only updating the tags, but not transforming the images. Am I right? Because I had a look at the Python code and I did not find that option.

I understand that it is better to edit the tags than transforming the images. I guess that after uploading images, the “set orientation” option in “My Pictures” menu does exactly that, setting the Xmp.GPano.PoseHeadingDegrees tag (or perhaps Xmp.Camera.Yaw). As indicated in the following webpage (thanks @Mattam for the link in your message from 31/Aug):

Unfortunately, I think Panoramax currently does not recognize these angular tags.

Therefore, does it make sense to add another option in the same Panoramax page for the pitch angle (I mean, at the same level as “set orientation”). Just for editing theXmp.GPano.PosePitchDegrees tag (or perhaps Xmp.Camera.Pitch). Editing the pitch angle tag, as it is done today with the yaw angle (“set orientation”), would be useful for sequences with a small pitch angle misalignment (as it could happen when riding a bicycle with a GoPro Max in the helmet…). Could this feature be implemented in Panoramax?

Hello,

The option is –update_images metadatas listed on line 143.

It updates tags -XMP-GPano:PosePitchDegrees and -XMP-GPano:PoseRollDegrees.

It is better to edit the tags than modify the images as it rebuild a jpeg file with a loss of quality due to the compression.

Panoramax viewer uses Photo Sphere Viewer library, the recognized tags are based on it as well.

Concerning the pitch and roll correction, I’ve made a WYSIWYG tool for fixing them based on the tags updates. GitHub - qhess34/pan360-fixexif

But for now, you can only use it before uploading the picture sequences to Panoramax.

When it will be possible to update metadatas on already uploaded pictures on Panoramax (with the API), I’ll deliver a patch to updates them.