• Aucun résultat trouvé

À la nécessité d’un environnement de simulation

1.6 Cadre de l’étude

1.6.4 À la nécessité d’un environnement de simulation

Pour étudier les méthodes de détection, de suivi et de commande, il est nécessaire d’em- ployer un simulateur représentatif du comportement de l’avion et capable de générer des images réalistes qui seront utilisées par les méthodes de vision. Ainsi on pourra faire varier différents paramètres de la simulation pour évaluer leurs effets sur nos méthodes et on pourra étudier la chaîne complète de traitements sans recourir à de coûteux, et complexes à mettre en œuvre, essais en vol.

Commande

Détection* Suivi* Calcul des primitives

Avion Ddl caméra Porte-avions Damocles* TACAN, IMU Capteurs Système Exécutable plugin X-Plane config.xml Compilation .lib .exe

* seulement pour plugin X-Plane

Conception Utilisations Gestion étude systématique configXP.xml Entrées- sorties

Figure 1.28 – Conception et utilisation

1.6.4.1 Modèle avion

Le modèle avion a été fourni par Dassault Aviation, sous la forme d’une librairie C++ issue de la conversion d’un code Simulink. Il prend en entrées :

– Les commandes de l’avion : l’accélération normale commandée azc en m/s

2, le taux de roulis commandé pc en deg/s et la position de la manette des gaz entre 0 et 1. Le dérapage est régulé à zéro.

– Le vecteur de vitesse de translation du vent dans le repère FN ED. – Le facteur de turbulence entre 0 et 1.

En sortie, ce modèle fournit un vecteur d’état des variables de vol.

Ce modèle est représentatif d’un avion de combat en phase d’atterrissage et les gouvernes sont trimées pour le point d’équilibre défini par une vitesse de 67m/s à une hauteur de 450 mètres avec une pente de vol nulle et sans vent. Le modèle de l’avion est exécuté à une fréquence de 80 Hz tandis que la boucle de vision et de commande l’est à 20 Hz.

1.6.4.2 Générateur d’images synthétiques

Pour les simulations prenant en compte la vision, il est nécessaire de générer des images représentatives de la réalité. Un grand nombre de logiciels conviennent à cette utilisation [Craighead 2007]. Parmi ces derniers, nous avons retenu ceux étant le plus représentatif gra- phiquement : FlightGear6, OKTAL-SE et X-Plane7. FlightGear est un simulateur de vol

6. http://www.flightgear.org/

open-source déjà employé dans le cadre du projet européen Pégase [Dassault Aviation 2009] dédié à l’étude de l’atterrissage par la vision. OKTAL-SE est un logiciel de génération d’images par calcul physique dans les domaines visible, infrarouge et radar [OKTAL-SE 2012]. X-Plane 9 est un simulateur de vol reconnu comme très réaliste et qui est très utilisé par la recherche scientifique [Ertem 2005, Hing 2009, Garcia 2010, Ribeiro 2010]. Pour notre application, ce dernier a été sélectionné comme générateur d’images car il offre un bon compromis entre représentativité, facilité d’accès et d’utilisation. Ce simulateur de vol n’est pas open-source mais possède un plugin pour interfacer un code externe aux variables internes. La version 10, sortie en début d’année 2012, a un rendu graphique encore amélioré mais nécessite beaucoup plus de puissance pour en profiter, qui est incompatible avec un pc portable datant de 2009. C’est pourquoi la version 9 a été employée et répond de manière satisfaisante à l’exigence de représentativité visuelle.

Le modèle 3D du porte-avions des simulations est le bâtiment américain Nimitz, présent dans X-Plane. Il offre un niveau de détail compatible avec notre application, et qui est su- périeur à ceux des autres modèles de porte-avions (dont un modèle du Charles de Gaulle). Une mire d’appontage a été ajoutée pour correspondre à l’usage des porte-avions français et faciliter le suivi lors des dernières secondes de vol. Enfin, le modèle 3D de l’avion utilisé pour la visualisation est celui d’un Rafale B, le modèle marine n’étant pas disponible8.

D’un point de vue développement, le code C++ emploie les librairies de vision et d’as- servissement visuel OpenCV9 et ViSP10. Cette dernière librairie est développée au sein de

l’équipe Lagadic de l’Inria [Marchand 2005]. Ce code est compilé sous la forme d’une librairie, ou plugin, et est exécuté par X-Plane, comme illustré Fig.1.28. Le plugin transmet les posi- tions de l’avion, du porte-avions et de la caméra. De même, l’horaire, la visibilité, les nuages et l’état de la mer font partie des paramètres modifiables. Enfin ce plugin récupère des images de taille 1024 par 768 pixels, générées par X-Plane, et les fournit aux algorithmes de détection et de suivi.

1.6.4.3 Modèle de capteur et turbulence atmosphérique

Le simulateur de vol X-Plane est utilisé en tant que générateur d’images réalistes. En effet, le rendu de l’image pour des caméras pourvues de champs de vue de l’ordre de 60 à 90 degrés est très satisfaisant. Pour les caméras de notre application, pourvues d’un champ de vue nettement plus étroit, le rendu de l’image peut être amélioré afin d’apparaitre "moins" synthétique. Pour étudier la robustesse des algorithmes de vision sur des images, il est aussi intéressant de considérer des modèles de turbulence atmosphérique et de capteur, ici décrits respectivement par leurs fonctions de transfert F T Matm et F T Mcapt.

Le modèle des perturbations atmosphériques est décrit de manière plus complète dans [Accetta 1993]. Il consiste tout d’abord à calculer le paramètre de Fried r0 :

r0= 2.1[1.46sec(φ)k2 Z L

0

Cn2(η)dη] (1.1)

8. Dans une perspective d’utilisation d’un système d’appontage automatique par vision, on pourrait cepen- dant indiquer que le modèle 3D employé est celui du feu Rafale N. Ce projet était un Rafale marine biplace dépourvu de canon qui fut un temps envisagé, avant de passer sous les fourches caudines de considérations budgétaires.

9. http://opencv.willowgarage.com/wiki/

1.7 Conclusion 41