Plan de vol et photogrammétrie avec ANAFI + QGC

Préparer un plan de vol en drone consiste à définir la trajectoire, l’altitude et la vitesse de l’appareil, ainsi que les spécifications de capture d’images, mais c’est aussi prendre en compte toutes les exigences liées à la météo et au terrain (lumière, végétation) afin d’anticiper au mieux les aléas et répondre plus précisément aux objectifs de la mission.

[ exemple de plan de vol avec l’emplacement des prises de vues photographiques ]

Le plan de vol peut être créé soit sur le terrain à l’aide d’une application mobile, soit à partir d’un logiciel de planification, sur ordinateur. Dans le cas présenté ici, nous allons examiner un vol programmé et sa préparation pour une mission de type cartographie / photogrammétrie.

Le site étudié : une fouille archéologique

L’utilisation d’un drone sur un site archéologique est essentiel pour photographier et documenter le site, mais également pour compléter les levés topographiques. Lors d’une fouille, un passage en drone au moment où le décapage s’achève est particulièrement intéressant : cette étape permet d’obtenir un instantané du site, juste avant d’entreprendre la fouille intensive. Les archéologues disposent alors d’une vision globale des vestiges et de leur niveau d’apparition.

[ fouille réalisée sur la commune d’Artzenheim (Haut-Rhin, Alsace) par Éveha / mars – avril 2024 ]

Le site présenté ici se situe à Artzenheim (Haut-Rhin), avec l’intervention de la société Éveha dans le cadre d’un projet de lotissement au Sud de la commune. La fouille a pour objectif la mise en évidence d’un habitat protohistorique (Bronze final), type d’habitat encore mal connu dans la plaine du Rhin supérieur. Une analyse spatiale des unités d’habitation (bâtiments, fosses, puits) est envisagée pour vérifier leur existence et préciser l’étendue de ces ensembles.

Le plan de vol : préparation et conversion

Pour notre plan de vol, la préparation est réalisée sur QGroundControl. La surface à couvrir est de 1.35 hectares, par mesure de précaution le plan de vol a été scindé en 2 parties. Le matériel utilisé est un drone compact : l’Anafi 4K de Parrot. Le capteur photo est un Sony IMX 230 qui permet de prendre 2 types de photos :

  • JPEG RECT : 4:3 – 16MP – 4608 × 3456 – HFOV 75,5°
  • JPEG WIDE : 4:3 – 21MP – 5344 × 4016 – HFOV 84°

QGroundControl permet d’élaborer le plan de vol dans ses moindres détails et il se charge également de prendre le contrôle du drone lors de la mission autonome. La communication avec le drone se fait par le biais du protocole MAVLink. C’est un standard léger qui permet une communication bidirectionnelle entre le drone et la station au sol. Il est donc possible de connaître en temps réel la position du drone, son altitude, sa vitesse, l’état de la batterie ou les commandes en cours d’exécution.

[ schéma représentant les 2 vols programmés effectués sur le site ]

Seulement voilà, l’Anafi utilise sa propre variante de communication MAVLink (cf. Parrot SDK – Messages V1) et il n’est possible d’obtenir que des photos “rectilinéaires” (au format 4608 × 3456) pendant une mission contrôlée par QGroundControl. Les logiciels de photogrammétrie (notamment MicMac) n’apprécient pas vraiment les images corrigées de la distorsion par le firmware du drone, car la distorsion résiduelle ne correspond à aucune réalité physique et à aucun modèle.

Alors que faire ? L’application FreeFlight6 de Parrot permet pourtant d’élaborer des plans de vols et de prendre des photos en “wide” (au format 5344 × 4016) ! En revanche, il n’y a aucune fonction pour préparer un vol de type “Survey” en grille ou double-grille comme avec QGroundControl. Ce dernier produit cependant des plans de vols au format JSON, et FreeFlight6 accepte également des fichiers de ce type mais largement moins complexe dans leur structure.

Voilà un angle d’approche intéressant ! Il nous faut simplement convertir notre plan de vol QGroundControl vers un plan de vol FreeFlight6 au format JSON !

Voici donc un convertisseur de plan QGC vers FF6, développé en Python3. Il traite uniquement les plans QGC de type “Survey” (c’est ce type de plan qui nous intéresse ici), les autres types “Corridor Scan” et “Structure Scan” seront pris en charge dans un développement ultérieur.

Le lien vers le projet : gitlab.com/epysod12/qgc-to-ff6

[ exemple de plan de vol converti depuis QGroundControl vers FreeFlight6 ]

L’exécution du script nécessite un seul argument : le fichier JSON [QGC] :

python3 qgc-to-ff6.py /home/<...>/mon-plan-de-vol.plan

Nous obtenons alors 3 fichiers CSV + 1 fichier JSON [FF6] :

Le script regroupe les fichiers dans un sous-répertoire, nommé d’après le nom du fichier QGC. Voici une liste non-exhaustive (+/- dans l’ordre) de ses fonctionnalités :

  • distinction possible entre les points de Décollage et d’Atterrissage
  • calcul de l’intervalle “timelapse” (déduite de la valeur “trigger distance“)
  • récupération de la valeur du “pitch camera” (entre 0° et -90°)
  • prise en charge de la fonction “TurnAroundDistance” de QGC

Une autre fonction intéressante du script est le calcul des azimuts et des distances entre les WP, en faisant appel à la bibliothèque pyproj, et notamment avec la fonction Geod.inv (transformation inverse). Cette fonction retourne 3 valeurs : azimut avant, azimut arrière, ainsi que la distance entre les WP.

Mise en œuvre et résultats obtenus

Pour ce chantier, les 2 missions QGC ont été converties en missions FF6, puis exécutées successivement. Le pitch camera étant réglé sur -90°, le drone a gardé une orientation fixe durant toute la mission, ce qui fait gagner plusieurs secondes à chaque WP en évitant une rotation de l’appareil. C’est une approche inspirée de cette discussion : Heading fixed flight path for multicopters.

[ trajet en grille effectué lors du premier vol, zone Nord | image extraite de FF6 ]
[ trajet en grille effectué lors du second vol, zone Sud | image extraite de FF6 ]

520 photographies ont été réalisées pendant ces 2 missions, elles ont ensuite été traitées sous WebODM. On obtient alors un modèle 3D du site, mais surtout une orthophotographie d’une résolution de 0.5 cm / pixel.

Le lien vers l’orthophoto : RueDesVosges_ODM_ORTHO_2024-04-12.zip

Cette photo est utilisable dans un SIG. Mais comme elle est volumineuse, il est préférable de créer une pyramide d’orthophotos : la pyramide contient des versions de l’image à des résolutions inférieures qui permettent de visualiser cette image en évitant d’en charger la totalité en mémoire. Le schéma suivant explique ce principe :

[ source : commons.wikimedia.org/wiki/File:Image_pyramid.svg ]

GDAL permet de créer une pyramide d’aperçus avec cette commande :

gdaladdo /home/<...>/mon-image.tif -ro 2 4 8 16

Traduction :
GDAL Add Overview
mon-image.tif [mode Read-Only] [sous-échantillonnage ×2 ×4 ×8 ×16]

Le résultat est un fichier .ovr qui contient les niveaux d’aperçus (c’est-à-dire notre pyramide). Notez qu’il contient seulement les images sous-échantillonnées, il ne faut surtout pas supprimer le fichier .tif d’origine !

Enfin, voici le rendu 3D généré par PotreeConverter :

018135_RueDesVosges_2024-04-12/RueDesVosges.html

Ajouter un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *