Apprentissage et analyse virtuels à peu de frais : l’ESTTMA et le projet Bluejay (La Revue de l'ARC - AUTOMNE 2014 - Volume 3, Numéro 4)

Formats Alternatifs

Table des matières

 

Par le major Eric North, le sous‑lieutenant Ben Frans, le sous‑lieutenant Jolanta Matusewicz, Maria Correa et Colton Harrison‑Steel

Introduction

L’Escadron de soutien technique des télécommunications et des moyens aérospatiaux (ESTTMA) est une organisation du ministère de la Défense nationale (MDN) du Canada. L’ESTTMA fournit aux organisations partenaires du MDN une mine de produits et de services techniques, notamment l’analyse technique, la conception et la production d’équipement aérospatial. Il a fourni son appui lors de l’essai opérationnel et de l’évaluation (EOE) de l’hélicoptère CH146 Griffon, en 2009, et à nouveau en 2010 en partenariat avec le Centre de guerre électronique des Forces canadiennes (CGEFC), l’Installation d’évaluation et d’essais de l’Aviation de l’Armée de terre et le gestionnaire des systèmes d’armes (GSA) du CH146. Des membres de l’ESTTMA ont participé à la conception et à l’installation des montages électriques et mécaniques du système avancé de données télémétriques (Advanced Range Data System, ARDS) du Département de la Défense des États‑Unis, un système qui fournit une localisation temps‑espace ou des données de trajectoire de vol précises pendant les essais opérationnels d’aéronefs. Le personnel des exercices avait besoin de données de trajectoire de vol et de cap de l’aéronef pendant chaque vol, tant pour des motifs de sécurité que du point de vue du contrôle du rayon d’action, sans compter l’évaluation après‑vol des manœuvres de l’appareil.

Bien que les systèmes de navigation de bord aient pourvu les équipages aériens de la connaissance de la situation nécessaire au cours de chaque mission, la fonction d’enregistrement et d’obtention des données de trajectoire de vol n’était pas facile d’accès. Les systèmes d’enregistrement de la trajectoire de vol intégrés à l’ARDS sont coûteux et exigent la prise de dispositions spéciales pour leur utilisation dans des appareils canadiens et pour l’emploi dans une zone géographique limitée. Il fallait d’autre part qu’un certain nombre de stations et de terminaux à terre soient en état de fonctionner et soient parfaitement opérationnels pendant les essais.

À leur retour au Canada, les membres de l’ESTTMA ont eu des échanges avec des collègues du CGEFC pour évaluer la viabilité d’une version plus petite et moins coûteuse de l’ARDS pouvant être installée dans les aéronefs de l’Aviation royale canadienne (ARC) pour les missions dont ils sont chargés dans le cadre d’opérations intérieures et de déploiement[1]. Des parties de cet examen, de même que des échanges entre les membres de l’équipe au sujet de la relecture de la trajectoire de vol, ont mené à l’élaboration d’un système prototype et d’un système de démonstration plus petits et plus légers que nature et d’une suite d’outils logiciels d’emmagasinage et d’affichage de données de trajectoire de vol. Le matériel du système prototype et du système de démonstration était auto‑alimenté, a coûté moins de 5 000 $ et fonctionnait indépendamment des systèmes d’enregistrement des données de vol et des liens de données. Le prototype a été traité comme une trousse « sans modification » de mission d’aéronef pouvant être installée dans un certain nombre de points différents du poste de pilotage de divers aéronefs, tant au Canada qu’à l’étranger. Ce matériel comprenait le MTi-G du fabricant XSens, c’est‑à‑dire une petite centrale d’attitude et de cap (AHRS) munie d’un système mondial de localisation (GPS), employant une technologie de système microélectromécanique capable de prendre en charge des applications de véhicules en mouvement. La suite logicielle consistait en une gamme de programmes commerciaux et de programmes à source ouverte. Le recours à des logiciels à source ouverte a permis aux auteurs de monter une trousse d’outils d’analyse des données de plusieurs trajectoires pour appuyer le projet. Au moyen de la méthodologie présentée plus tôt, ils ont appliqué les résultats d’expériences de GPS réalisées à l’aide de véhicules terrestres à la validation des données de sortie de capteurs d’un GPS/unité de mesure inertielle (UMI) intégré. Cette validation était nécessaire pour garantir la bonne exploitation du GPS/UMI lors des expériences aéroportées subséquentes. La suite logicielle comprenait également un jeu de modifications, élaborées par l’équipe, apportées à un simulateur de vol à source ouverte appelé FlightGear. Les utilisateurs ont pu, au moyen de ce logiciel, emmagasiner des trajectoires, analyser leurs données et afficher les trajectoires de vol résultantes dans un environnement virtuel complet avec cartes personnalisées superposables.

Haut de la page

Les applications créées pour Bluejay comprennent l’analyse après‑mission des trajectoires et des régimes de vol de différents environnements d’apprentissage, comme la formation au pilotage de l’ARC, y compris la phase I (ab initio), la phase II (élémentaire), et la phase III (hélicoptère/multimoteur). Les autres applications possibles comprennent l’EOE avec applications en guerre électronique, la caractérisation des trajectoires de vol que peut utiliser le Directeur – Sécurité des vols (DSV) dans le cadre de ses enquêtes sur des accidents d’aéronef, les essais et évaluations techniques, l’examen et le raffinement des démonstrations de vol acrobatique, la tactique embarquée ainsi que d’autres manœuvres.

Le présent rapport est ainsi structuré : la partie Expériences présente le matériel et les logiciels employés pendant le projet et décrit les expériences réalisées; la partie Résultats et la partie Analyse présentent les constatations issues des expériences; la partie Conclusions récapitule l’analyse et donne les grandes lignes des travaux à venir.

Expériences

Deux variantes matérielles ont été élaborées pour soutenir le projet : (1) un prototype constitué d’une enceinte métallique, de capteurs, d’un processeur et d’autres composants convenant à l’installation dans un aéronef et (2) un système de démonstration constitué de parties des organes internes du système prototype selon une configuration beaucoup plus petite et beaucoup plus légère. Les paragraphes qui suivent donnent le détail du système prototype et du système de démonstration du projet Bluejay.

Système prototype

Le matériel du système prototype Bluejay consistait en des capteurs de position et d’attitude, en une source d’alimentation et en un ordinateur miniature. Un AHRS/GPS MTi-G de XSens a servi de capteur principal de position et d’attitude, tandis qu’un récepteur GPS GlobalSat DG-100 a constitué le capteur secondaire du véhicule, qui a permis de connaître sa position et de valider certains des résultats du MTi-G recueillis pendant les expériences à bord de véhicules terrestres. Cet équipement était logé dans une enceinte convenant à l’utilisation en aviation; il était doté de commutateurs, de disjoncteurs et de barrettes pour l’alimentation interne et externe ainsi que de dispositifs d’accueil d’antennes externes et de moyens de communication avec un ordinateur hôte. Les attaches, les matériaux de construction, le câblage, les commutateurs, les interconnexions et les autres composants ont été choisis selon des critères de disponibilité, de conformité aux normes aérospatiales et de sécurité aérienne. L’enceinte comportait un couvercle amovible et une petite porte facilitant l’accès aux bornes d’emmagasinage de données et aux autres barrettes de l’ordinateur miniature. La polyvalence du concept permet le montage de l’enceinte à différents endroits dans le poste de pilotage de l’aéronef au moyen de sangles d’arrimage ou d’une plaque d’adaptation fixée soit au plancher de la cabine, soit à une autre structure apte à la recevoir. Les figures 1[2] et 2 montrent le système prototype.

Haut de la page

La figure 1 illustre la disposition des rouages fonctionnels du matériel du prototype utilisé dans le cadre du projet Bluejay. La partie gauche de la figure comprend les composants matériels et logiciels embarqués, y compris l’ordinateur Habey BIS 6620, ainsi que les liens entre le Habey et l’alimentation, la mémoire, l’interface de contrôle de l’alimentation et la centrale d’attitude et de cap XSens. Ce système de référence comprend un récepteur GPS relié à une antenne. Une antenne distincte émerge de l’enregistreur chronologique du GPS DG100. La partie plus petite de la figure, à droite, comprend le matériel basé à terre, notamment la connexion selon le protocole Ethernet, le chargeur et la source externe d’alimentation. Ces éléments sont branchés au matériel embarqué par l’entremise du contrôle d’alimentation et de l’interface. Fin de la figure 1.

Figure 1. Diagramme du matériel du prototype du projet Bluejay

 

La figure 2 donne une vue en trois dimensions des parties du prototype ainsi qu’elles se présenteraient si elles étaient retirées de leur enceinte. Le couvercle est soulevé et les organes internes mentionnés à la figure 1 apparaissent dans la partie centrale de la figure. Le bas de l’enceinte loge les commutateurs et entrées de branchement où les composants basés à terre (absents de la figure) se connectent au matériel intérieur en traversant l’étui. Fin de la figure 2.

Figure 2. Vue éclatée de l’enceinte du système prototype.

 

Haut de la page

Système démonstrateur

Un système de démonstration a été élaboré pour répondre au besoin de mener des essais de véhicules aériens au moyen d’un petit avion télécommandé. Si on le compare au système prototype, le système démonstrateur (que montre la figure 3[3]) a recouru à une alimentation électrique nettement moindre et à un ordinateur monocarte plus petit. L’ordinateur monocarte était muni d’une architecture de processeur différente de celle du système prototype, mais compatible avec le système d’exploitation choisi, c’est‑à‑dire un Linux axé sur Debian. Au lieu d’être montées dans une enceinte, les antennes du MTi‑G et du GPS étaient montées à l’extérieur de l’aéronef, sur une plaque d’adaptation conforme à la cambrure supérieure de l’aile. Les autres composants, y compris l’ordinateur monocarte et la source d’alimentation, ont été installés en fonction de l’espace libre dans le fuselage de l’aéronef, à l’arrière du compartiment moteur. Une fois les vols effectués, un câble de transfert de données a été branché à l’ordinateur monocarte pour transférer à l’hôte les données enregistrées.

La figure 3 illustre le matériel du système de démonstration Bluejay. La BeagleBoard (carte électronique de type ordinateur monocarte de faible puissance) en constitue la plus grande partie, car elle comprend l’ordinateur, la mémoire et l’interface, ainsi qu’un branchement Ethernet à terre. L’ordinateur se connecte à une alimentation électrique mobile elle même connectée à une deuxième source d’alimentation en électricité liée à une source d’alimentation externe à terre. L’ordinateur se branche également, grâce à un bus série universel (USB), à une centrale d’attitude et de cap dont fait partie un GPS muni d’une antenne. Fin de la figure 3.

Figure 3. Éléments matériels du système démonstrateur de Bluejay.

  

Hau de la page

Collecte de données

Le volet logiciel de Bluejay se divise en trois catégories : collecte, analyse et affichage des données. Le logiciel de collecte de données se trouvait dans un ordinateur intégré au système prototype et au système de démonstration, fonctionnant au moyen d’un nœud Linux à faible consommation de l’unité centrale de traitement. Il a été conçu de manière à être polyvalent, axé sur les scripts et capable de prendre en charge de multiples capteurs. L’ordinateur intégré peut être configuré de manière à fonctionner en autonomie en plus d’être réseauté avec toute une gamme de fonctions de déparasitage et de transfert des journaux des capteurs. Une fonction de synchronisation dans le temps permet à tous les capteurs et à l’ordinateur de partager une estampille temporelle commune, fondée sur le temps universel (TU), obtenue du GPS du MTi‑G. Les utilisateurs ont le loisir, après le vol, d’extraire des données d’une carte mémoire numérique protégée. Sinon, il leur est possible de procéder à un branchement direct à un hôte, en passant par Ethernet, pour transférer les données consignées. La séquence du flux de données de Bluejay est illustrée à la figure 4[4].

La figure 4 illustre la séquence du flux des données de Bluejay à l’ordinateur hôte. Les données naissent dans Bluejay à partir des données des capteurs d’attitude et de cap. Elles sont liées, par un bus série, au bus série universel du fichier de journalisation. Les données du fichier de journalisation passent ensuite de Bluejay à l’ordinateur hôte par l’entremise d’une connexion Ethernet. La première étape franchie dans l’ordinateur hôte est celle du lissage, du cap et de la correction. Les données passent ensuite à la dernière étape (relecture de la trajectoire de vol) selon un protocole générique. Fin de la figure 4.

Figure 4. Séquence du flux des données de Bluejay.

 

Haut de la page

Outils d’analyse

L’écriture programmatique du logiciel d’analyse, qui a servi à traiter les données obtenues des capteurs, a été faite en SciLab. SciLab étant multiplateforme et à source ouverte, il comporte nombre de fonctions utiles, notamment la corrélation, le débruitage et des dispositions de transformation par un système coordonné en plus du traçage et d’autres outils d’analyse. Les paragraphes qui suivent constituent une description sommaire d’une partie de la trousse d’outils élaborée en SciLab pour appuyer le projet Bluejay.

En l’absence de solution de référence pour l’attitude (tangage, roulis et lacet), les données obtenues du GPS peuvent servir, de manière élémentaire et non officielle, à estimer le cap du véhicule en plus de son tangage[5]. Ce calcul du tangage peut servir à évaluer rapidement le rendement d’un AHRS/GPS comme le MTi‑G; il peut cependant être nécessaire de procéder à un filtrage par passage à basse altitude ou de déterminer la moyenne du mouvement pour atténuer le bruit des capteurs du GPS. Il faut, par surcroît, l’appliquer avec prudence en raison du faible taux de mise à jour du GPS et à cause des hypothèses, y compris l’absence de glissement sur l’aile et d’autres dynamiques des véhicules. Les calculs peuvent servir, dans certaines situations, à corriger le signe et à estimer les valeurs de tangage pour l’évaluation du cap en matière de qualité des capteurs, particulièrement en ce qui a trait au MTi‑G pour la confirmation de l’utilisation d’un scénario approprié de filtrage Kalman étendu. D’autres capteurs recourant à un GPS/UMI intégré avec fusion de données peuvent aussi tirer profit de ce calcul simple (p. ex., en l’absence de solution de référence et quand les paramètres de la fusion de données doivent être accordés, particulièrement lorsque la qualité des données de sortie d’attitude soulèvent des doutes).

Selon la configuration de départ conjuguée au générateur de signaux d’horloge de chaque capteur, il peut arriver que les estampilles temporelles de capteurs multiples ne soient pas bien harmonisées les unes aux autres. Une approche de détermination des différences entre les estampilles temporelles de capteurs multiples consiste à comparer visuellement les sorties de données des capteurs au moyen d’outils de traçage. Il faut faire au moins deux tentatives de mise en correspondance physique de certaines des caractéristiques de ces sorties, en s’intéressant à la distance de chaque caractéristique de la sortie d’un capteur par rapport à la même caractéristique de la sortie de l’autre capteur. Cette méthode sert bien son but quand, par exemple : (1) on ne compare qu’un petit nombre de capteurs; (2) les sorties d’un capteur sont très semblables aux sorties des autres capteurs; (3) les caractéristiques des sorties de chaque capteur sont faciles à reconnaître par des indices visuels comme des transitions abruptes d’un point de données à l’autre; (4) on a la liberté de tolérer l’imprécision de l’harmonisation des estampilles temporelles; (5) la différence entre les estampilles temporelles d’au moins deux capteurs demeure constante dans l’ensemble de données de chaque capteur dans les limites de l’expérience menée[6]. Ayant pris tous ces éléments en considération, les auteurs ont opté, pour la détermination du décalage entre le MTi‑G et le DG‑100 lors des expériences menées au moyen de véhicules terrestres, pour une approche modérément robuste proposée dans la documentation sur le filtrage numérique. Il y aura peut‑être lieu de propager cette approche selon le type de capteurs utilisé dans une application donnée, car elle peut être utile à certains concepts comprenant des réseaux de capteurs. Les sous‑produits de l’approche comprennent la capacité de déterminer la similitude des décalages temporels à l’échelle de toutes les données obtenues de deux capteurs (c’est‑à‑dire la similitude comme mesure de l’étendue de l’écart des décalages temporels pour toutes les valeurs minimales de la moyenne quadratique); le nombre d’occurrences d’un décalage temporel donné; la similitude des données entre deux capteurs (c’est‑à‑dire la grandeur de toutes les valeurs minimales de la moyenne quadratique comme méthode de détermination de la similitude entre les données de deux capteurs).

Haut de la page

Affichage et analyse après action

Le logiciel d’affichage a permis aux utilisateurs de relire leurs données de trajectoire sous la forme d’une simulation tridimensionnelle. Réalisée sur un processeur hôte, cette simulation a été une adaptation d’un simulateur à source ouverte, indépendant de toute plateforme, nommé FlightGear. D’autres types de logiciel ont été évalués en vue de la relecture des données de trajectoire, comme l’outil d’animation à source ouverte nommé Blender, de même que Google Earth, Microsoft Flight Sim X et X‑Plane. FlightGear a finalement été choisi, car il est à source ouverte et compatible avec l’univers de l’aviation grâce à sa vaste bibliothèque de terrains, d’aérodromes et d’aéronefs. Des fonctions supplémentaires, comme le positionnement précis des aérodromes sur le géoïde de référence, la capacité de se brancher à un serveur météo et la possibilité de produire d’autres formes d’élaboration ont fait de FlightGear un bon choix pour Bluejay. Ce logiciel était idéal pour le projet, car des cartes personnalisables superposables ont été créées et superposées sur le terrain existant, produisant une bonne harmonisation des images matricielles et des artéfacts de FlightGear, comme les aérodromes[7]. La saisie des instructions de l’aéronef dans FlightGear est normalement confiée à un opérateur, mais la version utilisée du logiciel prévoyait la relecture des vols, ce qui présentait de l’intérêt pour le projet.

L’interface entre le fichier de journalisation (produit au moyen du matériel de Bluejay) et FlightGear était simple. FlightGear permet la création d’un protocole personnalisé de saisie connu sous le nom de protocole générique. On a rédigé un fichier .XML liant les caps du fichier de journalisation produit en vol aux propriétés associées de FlightGear. Le processus de chargement a débuté avant l’exécution de FlightGear. Des options de blocage du modèle implicite de dynamique de vol ont été transmises à l’interface des lignes de commande. D’autres paramètres ont été précisés, notamment la vitesse de relecture, l’emplacement du fichier de journalisation ainsi que la sélection d’un fichier .XML contenant le protocole générique. Une fois l’initialisation terminée, un aéronef simulé a suivi la trajectoire et observé le cap du vol enregistré dans le temps et dans l’espace. La relecture dans FlightGear a permis à l’utilisateur, entre autres choses, de visionner le vol enregistré depuis différents points de vue en se servant des divers types d’aéronef choisis au début.

Une retouche[8] a été apportée au code source de FlightGear pour permettre le chargement de cartes matricielles personnalisées par opposition au terrain implicite normalement généré par les procédures de FlightGear. Avant le démarrage, les cartes personnalisées ont dû être traduites en un format pris en charge par le logiciel. FlightGear prévoit la prise en charge de fichiers image, nommés pavés, dans un format d’image comprimée .DDS. Ces pavés ne sont pas intrinsèquement géoréférencés, mais leur nom de fichier est un indice de l’emplacement du pavé géoréférencé. Un processus et un script ont été créés pour prélever le géodésique de coin du fichier .tif initial et recadrer, renommer, comprimer et transférer le fichier résultant aux dossiers appropriés dans les répertoires de données de FlightGear. Le processus de conversion de cartes personnalisables superposables en vue de leur utilisation dans FlightGear est illustré à la figure 5[9].

Haut de la page

La figure 5 montre le processus de conversion des cartes personnalisables superposables. Le processus commence par l’utilisation des bibliothèques d’abstraction de données géospatiales. Ce stade compte trois étapes : (1) création des fichiers cartographiques géoréférencés de l’utilisateur, (2) conversion de ces fichiers au format geotiff, (3) transfert des fichiers au script Python, où ils sont renommés. Les fichiers sont comprimés au format .dds au moyen de la trousse d’outils nvidia. Pour finir, les fichiers sont versés au dossier FlightGear pertinent. Fin de la figure 5.

Figure 5. Processus de conversion des couches superposables des cartes personnalisées.

 

Expériences terrestres

Bien que les éléments matériels de Bluejay aient été conçus pour fonctionner en vol, il a fallu procéder à des essais de trajectoire à terre pour évaluer les sorties des capteurs en plus d’élaborer les volets logiciel et matériel. Différentes expériences à bord de véhicules terrestres ont été menées au moyen du GPS GlobalSat (DG‑100) et du GPS/UMI XSens (Mti‑G) dans une configuration semblable à celle de la figure 3. Les capteurs, une fois placés dans le véhicule et leurs antennes GPS dégagées de toute obstruction de la vue du ciel, ont été branchés à un ordinateur portatif pour configuration, saisie des données et traitement après collecte. Les essais sur véhicule terrestre ont l’avantage d’être considérablement moins coûteux que des expériences recourant à un aéronef réel. Plusieurs emplacements voisins de la 8e Escadre Trenton ont été choisis pour les expériences à bord de véhicules terrestres, y compris des routes situées au nord de l’autoroute 401. Un logiciel de détermination en ligne du profil altimétrique nommé VeloRoutes a servi à l’évaluation des trajectoires en vue d’une modification maximum de l’élévation sur de courtes distances pour obtenir des variations raisonnables du tangage du véhicule. Une fois les trajectoires convenables identifiées, des expériences réalisées à l’aide du MTi‑G et du DG‑100 ont été faites le long de trajectoires choisies; les données ont été enregistrées en vue du traitement après action dans SciLab et de l’affichage éventuel dans FlightGear. Les résultats des expériences faites à l’aide de véhicules terrestres sont présentés dans la partie Conclusions du présent rapport.

Expériences aériennes

On a décidé de réaliser les expériences en vol au moyen d’un petit avion télécommandé plutôt que d’un aéronef véritable. Le modeste facteur de forme et le faible poids du système démonstrateur Bluejay ont été très avantageux pour ces expériences. Un club local d’avions miniatures télécommandés a été choisi comme emplacement pour l’exécution des essais; des vols ont été réalisés au fil de plusieurs nuits calmes et dégagées pour garantir qu’il n’y ait que peu d’interférence, voire aucune, résultant du vent et d’autres effets environnementaux. L’avion télécommandé était muni du système démonstrateur Bluejay ainsi que d’une caméra vidéo à haute définition (HD) compatible avec le GPS. La caméra vidéo HD a permis de comparer chacun des segments du vol grâce à la vue depuis le poste de pilotage produite dans FlightGear lors de la relecture. Les figures 6 et 7 illustrent le montage expérimental du système démonstrateur.

Haut de la page

La figure 6 montre le matériel Bluejay en cours d’installation dans un avion miniature télécommandé. Fin de la figure 6.

Figure 6. Matériel du démonstrateur à la phase initiale d’installation.

 

La figure 7 montre l’avion télécommandé au moment où il fait l’objet des derniers ajustements, tout juste avant de décoller. Fin de la figure 7.

Figure 7. Matériel du démonstrateur à la dernière phase de l’installation.

Résultats et analyse

Terre

Les données produites par le MTi‑G et par le DG‑100 utilisés dans le cadre des expériences à terre ont été étudiées selon la méthodologie déjà mentionnée au passage où sont décrits les outils d’analyse. Les données de localisation obtenues du DG‑100 ont été post‑traitées pour produire une maquette‑référence de l’azimut et du tangage, celui‑ci étant calculé au moyen d’une variation de l’équation citée à la note de fin de texte 5. L’harmonisation des données des deux capteurs est présentée à la figure 8. Plusieurs caractéristiques ressortent dans chaque ensemble de données :

  1. il existe un manque notoire dans les données du DG‑100, qui commencent à environ 2 200 secondes dans les deux ensembles de données en raison d’une fonction du DG‑100 qui empêche la consignation des données quand le véhicule demeure immobile pendant plusieurs minutes;
  2. bien que dans sa majeure partie, l’ensemble de données 1 des deux capteurs semble apparié de près, dans plusieurs segments de données de l’ensemble de données 2, particulièrement entre 1 050 secondes et 2 050 secondes, les sorties du MTiG ne s’harmonisent pas au tangage calculé au moyen du DG‑100 en raison, entre autres, d’erreurs dans la modélisation faite au moyen de l’équation mentionnée à la note de fin de texte 5;
  3. il importe de savoir que les auteurs ont été en mesure d’employer une estimation rudimentaire des intervalles de temps et de déterminer un décalage temporel approprié entre les capteurs pour les deux ensembles de données, bien qu’ils aient appliqué une approche simplifiée à la modélisation du tangage recourant aux données du DG‑100.

Haut de la page

La figure 8 comprend deux graphiques qui expriment les données de vol. Dans le graphique de gauche, des lignes distinctes représentent l’azimut des capteurs, en degrés, sur l’axe Y par rapport à la durée en secondes sur l’axe X. Une ligne bleue marque l’azimut calculé et une ligne noire, l’azimut mesuré. Le deuxième graphique, recourant aux mêmes couleurs de ligne, exprime le tangage calculé et le tangage mesuré, en degrés, sur l’axe Y relativement à la durée en secondes représentée sur l’axe X. Fin de la figure 8.

Figure 8. Données des capteurs : (en naut) l’azimut des capteurs; (en bas) le tangage des capteurs, après application de la correction temporelle.

 

Haut de la page

Air

Une fois les vols réalisés avec succès, les données saisies au moyen du système démonstrateur ont été transférées à un hôte par l’entremise d’Ethernet et post‑traitées à l’aide d’un logiciel; ces données post‑traitées ont alors été versées à FlightGear pour analyse visuelle. Les trajectoires de vol simulées dans FlightGear ont été comparées à un programme montrant les vidéos saisies au moyen de la caméra vidéo HD pendant les vols. Les résultats des expériences aériennes montrent la comparaison de la vidéo HD et de la vue simulée depuis le poste de pilotage de FlightGear et sont montrés aux figures 9, 10 et 11.

La figure 9 comprend deux images. L’image de gauche est une vue naturelle, depuis le poste de pilotage, du ciel et de la terre tandis que l’aéronef roule légèrement sur la gauche. À droite, on aperçoit l’image simulée de la même vue. Les nuages et le ciel sont plus définis dans l’image simulée mais la terre n’est pas aussi précise que dans la vue naturelle, car les arbres et les champs sont essentiellement gris et blancs. Fin de la figure 9.

Figure 9. Comparaison du produit de la caméra vidéo HD avec la vue du poste de pilotage de FlightGear. L’aéronef effectue un virage peu marqué vers la gauche et entame un roulement léger sur la gauche.

  

La figure 10 comprend deux images. L’image de gauche est une vue naturelle, depuis le poste de pilotage, du ciel et de la terre tandis que l’aéronef roule très nettement sur la gauche. À droite, on aperçoit l’image simulée depuis le même point de vue. Les nuages et le ciel sont plus définis dans l’image simulée mais la terre n’est pas aussi précise que dans la vue naturelle, car les arbres et les champs sont privés de couleur. Fin de la figure 10.

Figure 10. Comparaison de la vue enregistrée par la caméra vidéo HD et de la vue depuis le poste de pilotage fournie par FlightGear. L’appareil roule sur la gauche.

 

La figure 11 est constituée de deux images. L’image de gauche est une vue naturelle, depuis le poste de pilotage, du ciel et de la terre tandis que l’aéronef roule sur la gauche selon un arc plus large qu’à la figure 10. L’image de droite est l’interprétation simulée de la même vue. Les nuages et le ciel sont plus définis dans la vue simulée, mais la terre est plus vague que dans la vue naturelle, car les arbres et les champs sont incolores. Fin de la figure 11.

Figure 11. Comparaison de l’image obtenue de la caméra vidéo HD et de la vue, depuis le poste de pilotage, produite par FlightGear. L’avion roule sur la gauche selon un arc vaste.

 

Haut de la page

L’image de gauche des figures ci‑dessus est une photographie prise par une caméra vidéo HD pendant l’essai du système démonstrateur embarqué sur l’avion télécommandé. L’image de droite est une capture d’écran de la relecture, dans FlightGear, du même vol. Dans cette image, une carte à plus haute définition est superposée sur la carte topographique personnalisée pour faciliter le référencement des repères terrestres entre les deux images. Les résultats ont été concluants, car le toit bleu d’une grange avoisinante a constitué un bon point de référence entre tous les jeux d’images. Une zone défrichée apparaît aussi distinctement en gris tant sur la vidéo que sur la simulation de la relecture du vol.

En plus de la comparaison de la vue, depuis le poste de pilotage, entre la vidéo enregistrée et la simulation en relecture, les membres du projet ont été en mesure d’exploiter l’analyse après action de FlightGear en faisant des pauses sur image, en fouillant la relecture et en en rembobinant des segments, en plus d’accélérer et de ralentir la relecture. Qui plus est, des angles de prise de vue multiples, différentes perspectives et des points de vue depuis l’intérieur et l’extérieur de l’aéronef ont été possibles, et une vue de type « poursuite » a très nettement illustré les diverses phases de relecture de la simulation des trajectoires de vol. De concert avec les cartes personnalisables superposables, y compris des cartes topographiques et de détail du terrain, toutes ces fonctions ont donné lieu à une capacité impressionnante d’analyse après action.

Conclusions

Le présent rapport présente les travaux réalisés dans le cadre d’un projet nommé Bluejay, qui portait sur un ensemble de matériels et de logiciels utiles à l’analyse après mission des données de trajectoire de vol. Le matériel propre au projet a été conçu de manière à être petit, auto-alimenté, peu coûteux et capable de fonctionner indépendamment des systèmes d’enregistrement des données et des liens de données. Dans tous les cas où cela a été possible, les logiciels d’appui au projet ont été choisis selon des critères d’indépendance de toute plateforme, de faible coût ou, mieux, de leur nature à source ouverte, de leur disponibilité à la distribution commerciale et de leur utilisation répandue. Le présent rapport démontre que le matériel de Bluejay peut être traité comme une trousse de mission d’aviation « sans modification » apte à l’installation dans différents points du poste de pilotage de divers aéronefs tant au Canada qu’à l’étranger. Deux systèmes distincts, soit un système prototype et un système de validation du principe, ont été élaborés au moyen de composants peu coûteux, en plus d’être de taille physique modifiable, pour permettre l’évaluation de capteurs. En recourant à des logiciels à source ouverte, les auteurs ont mis en œuvre une trousse d’outils servant à analyser les données de plusieurs trajectoires d’appui au projet. L’application de la méthodologie présentée au passage où sont abordés les outils d’analyse aux résultats obtenus de GPS dans le cadre d’expériences réalisées à bord de véhicules terrestres a permis aux auteurs de valider les sorties de données des capteurs d’un GPS/UMI intégré. Cette validation était nécessaire pour garantir la bonne exploitation du GPS/UMI lors des expériences aéroportées subséquentes. Les résultats des expériences ont été présentés au moyen de plusieurs programmes à source ouverte, y compris une version modifiée du simulateur de vol FlightGear, pour démontrer les capacités du système. En se fondant sur Bluejay, les auteurs affirment que les pilotes de l’ARC, tout comme les opérateurs d’autres forces militaires et de différentes organisations, sont capables de recourir au système comme capacité d’analyse après action. Les opérateurs pourraient se servir de Bluejay pour consigner leurs vols et, par la suite, pour afficher les trajectoires de vol résultantes dans un environnement virtuel complet doté de cartes personnalisables superposables.

En ce qui a trait à un système autonome d’enregistrement des données, sans égard au fait que le matériel de démonstration ait été plutôt petit et ait pu servir à bord d’un avion miniature télécommandé, il faudra travailler à la détermination de la mesure dans laquelle il peut être miniaturisé davantage et dans laquelle son prix à l’unité peut être réduit. Des analyses de suivi sont nécessaires à la détermination du meilleur point d’installation dans différents aéronefs et à la prise d’une décision sur la possibilité de maintenir le caractère auto‑alimenté du matériel ou de pouvoir le brancher à l’alimentation de l’aéronef. D’autre part, il faut prendre en compte l’installation optimale de matériel de soutien, comme les câbles d’antenne, de transfert de données et autres. Dans certains cas, il pourra être envisagé d’intégrer le matériel Bluejay aux trousses de mission existantes afin de minimiser les répercussions potentielles sur la navigabilité technique et opérationnelle.

Il faudra travailler davantage à déterminer les utilisations potentielles de Bluejay, y compris l’adaptation du logiciel aux organiseurs électroniques de poste de pilotage et aux ardoises électroniques. Compte tenu de la prolifération de ces dispositifs dans les différents marchés de l’aviation, il semble raisonnable d’offrir une solution « à guichet unique » pour la consignation, l’analyse et l’affichage des trajectoires de vol, sur un seul et même dispositif. Plusieurs ardoises accueillent des gyroscopes, accéléromètres, magnétomètres et GPS, ce qui facilite sans aucun doute leur utilisation dans un rôle de consignation de données. Par ailleurs, certaines ardoises sont munies d’un passe‑antenne afin d’améliorer la qualité et la disponibilité des données position‑vitesse‑temps du GPS.

Les futures initiatives axées sur le logiciel Bluejay pourront comprendre la prévision de l’exploitation simultanée sur plusieurs aéronefs pendant la relecture des trajectoires de vol, particulièrement dans le cas d’applications visant le vol en formation serrée. On pourrait s’intéresser à des aides visuelles comme des cases et des plaques d’approche. Il est utile de savoir que FlightGear propose déjà une visualisation de l’alignement de descente pouvant être fort utile à l’analyse après action des approches. Les autres enrichissements potentiels comprennent la représentation d’un poste de pilotage fonctionnel recourant aux données enregistrées communiquées aux instruments pour afficher la position, l’attitude et le cap, ainsi que la fourniture d’une carte mouvante à la relecture.

Haut de la page


Le major Eric North s’est enrôlé dans les Forces armées canadiennes en 1998, comme ingénieur en aérospatiale. Il a obtenu du Collège militaire royal du Canada (CMRC), à Kingston, en Ontario, un baccalauréat en ingénierie (B. Ing.) en mai 2002. En 2007, le major North a entrepris une maîtrise en sciences appliquées (Électrotechnique) au CMRC et a étudié en même temps la robotique à l’université Queen’s. Il a terminé ses études des cycles supérieurs en mai 2009, avec la rédaction d’une thèse en navigation et en instrumentation. Il a par la suite été affecté à l’ESTTMA, à la 8e Escadre Trenton. Le major North est actuellement commandant du 14e Escadron de génie logiciel (14 Esc G Logiciel), à la 14e Escadre Greenwood, en Nouvelle‑Écosse.

Le sous‑lieutenant Ben Frans s’est joint à l’ARC en 2003, comme technicien en avionique. Il a obtenu du CMRC, en 2012, un diplôme en électrotechnique. Il poursuit actuellement sa formation d’officier du génie aérospatial. Il s’intéresse particulièrement au suivi du mouvement dans les environnements synthétiques, à la réalité amplifiée, à la réalité virtuelle, à la téléprésence et au véliplanchisme.

Le sous‑lieutenant Jolanta Matusewicz détient une maîtrise en génie aérospatial (2006) de l’université du Texas à Arlington. Elle s’est jointe à l’ARC en 2012, comme officier du génie aérospatial et a été employée au sein de l’ESTTMA dans le cadre de sa formation professionnelle. Elle suit en ce moment une formation en langue seconde à l’École de langues de la 8e Escadre Trenton, en Ontario.

Maria Correa a obtenu en 1991 un baccalauréat ès sciences (Électrotechnique) de l’Universidad Distrital de Bogotá, en Colombie. Elle a une vaste expérience des divers domaines de l’avionique, c’est‑à‑dire la maintenance, la réparation, la recherche et le développement appliqués aux aéronefs commerciaux et militaires. Mme Correa est depuis 2000 ingénieure‑conceptrice et agente de projet à l’ESTTMA.

Colton Harrison‑Steel est inscrit en génie mécanique et des matériaux à l’université Western Ontario, à London. Il a été employé à l’ESTTMA, à différents titres, pour soutenir l’obtention de son diplôme.

Abréviations

AHRS―centrale d’attitude et de cap

ARC―Aviation royale canadienne

ARDS―système avancé de données télémétriques

CGEFC―Centre de guerre électronique des Forces canadiennes

CMRC―Collège militaire royal du Canada

EOE―essai opérationnel et évaluation

ESTTMA―Escadron de soutien technique des télécommunications et des moyens aérospatiaux

GDAL―bibliothèque d’abstraction des données géospatiales

GPS―système mondial de localisation

HD―haute définition

MDN―ministère de la Défense nationale

UMI―unité de mesure inertielle

USB―bus série universel

Haut de la page

Notes

1. Pour mieux comprendre les techniques d’estimation de la position et de l’orientation de véhicules en mouvement, les auteurs du présent rapport ont étudié différentes initiatives en la matière, notamment les travaux présentés par J. Gregory et coll., « Low-cost Three-dimensional Navigation Solution for RISS/GPS Integration Using Mixture Particle Filter », dans IEEE Transactions on Vehicular Technology, vol. 59, no 2, février 2010, p. 599‑615; U. Iqbal et coll., « Experimental Results on an Integrated GPS and Multisensor System for Land Vehicle Positioning », dans International Journal of Navigation and Observation, vol. 2009; E. North et coll., « Improved Inertial/Odometry/GPS Positioning of Wheeled Robots even in GPS-denied Environments », dans le numéro de février 2012 d’InTech. Ils ont consulté des sources supplémentaires quant aux montages expérimentaux pour la navigation et l’instrumentation de véhicules aérospatiaux, notamment : C. Cutright et M. Braasch, « GPS and INS Flight Test Instrumentation of a Fully Aerobatic Turbojet Aircraft », dans le rapport de conférence IEEE Aerospace Conference Proceedings, vol. 3 (2002); Z. J. Huang et J. C. Fang, « Integration of MEMS Inertial Sensor-based GNC of a UAV », dans International Journal of Information Technology, vol. 11, no 10, 2005; D. H. Hwang et coll., « Design of a Low-cost Attitude Determination GPS/INS Integrated Navigation System », dans GPS Solutions, vol. 9, no 4, 2005, p. 294‑311. La modélisation et la simulation avec applications de modernisation de la capacité ont aussi été envisagées lors de la rédaction du présent rapport, par l’étude des textes suivants : J. Landolt et J. Evans, « R&D Initiatives in Modelling and Simulation for Capability Modernization of the Canadian Air Force », dans Canadian Military Journal, printemps 2001, p. 37‑42, et une appréciation de l’orientation prévue du MDN en matière d’accroissement du recours aux technologies de simulation selon la perspective de J. L. D. Lachance, Projecting Power: Alternative Futures for Canada’s Air Force in 2020, Trenton, Ontario, Centre de guerre aérospatiale des Forces canadiennes, 2010 et K. Truss, « Le Centre de l’environnement synthétique aérien du Canada : dynamiser la transformation de la force », dans La Revue de l’Aviation royale canadienne, vol. 1, no 3, 2012, p. 64‑68. La motivation du présent projet est née en partie de travaux antérieurs exécutés par le major Adam Cybanski, membre du groupe du Directeur – Sécurité des vols, au sujet de l’enregistrement et de la visualisation des trajectoires de vol.  (retourner)

2. Les couleurs utilisées dans la figure 1 représentent les composants physiquement regroupés dans l’assemblage de niveau supérieur suivant.  (retourner)

3. Les couleurs utilisées dans la figure 3 représentent les composants physiquement regroupés dans l’assemblage de niveau supérieur suivant.  (retourner)

4. Les couleurs utilisées dans la figure 4 représentent les composants physiquement regroupés dans l’assemblage de niveau supérieur suivant.  (retourner)

5. Le tangage est ainsi calculé : ρ (k) = tan-1(∆h/∆d) (1) où : ρ (k) représente le tangage à l’échantillon k, ∆h = h (k) − h (k − 1) représente un changement d’altitude entre l’échantillon actuel et l’échantillon précédent et ∆d = d (k) − d (k − 1) représente un changement de distance entre l’échantillon actuel et l’échantillon précédent.  (retourner)

6. On peut préférer d’autres méthodes recourant au filtrage numérique à celles qui précèdent : la documentation publiée comporte de nombreuses mentions de systèmes et de processus d’estimation décalée des signaux, dont C. Y. Wuu et A. Pearson, « On Time Delay Estimation Involving Received Signals », dans IEEE Transactions on Acoustics, Speech, and Signal Processing, vol. 32, no 4, 1984, p. 828‑835.  (retourner)

7. Le code source de plusieurs versions de FlightGear était facile d’accès pour téléchargement, notamment (le 26 septembre 2014) à l’adresse http://www.flightgear.org, ce qui en a fait un outil de travail pratique.  (retourner)

8. Créée par B. Laniel. Vue photographiée de Brest : pièce FlightGear pour superposition aux images matricielles dans les environnements simulés, http://wiki.flightgear.org/photoscenery (consulté le 26 septembre 2014).  (retourner)

9. Les couleurs utilisées dans la figure 5 indiquent les éléments logiciels différents.  (retourner)

Haut de la page

 

Table des matières

Date de modification :