(L’AHRS, page mise à jour par Benjamin le 23/03/2024)
L’AHRS, pour « Attitude and Heading Reference System » est la partie de l’EFIS la plus complexe. Ce n’est pas en raison des composants qui le constituent (notamment les IMUs, cf. infra), car ils sont très répandus, faciles à trouver sur des cartes de prototypage, et bon marché. C’est en fait à cause du logiciel qui fusionne les données brutes des capteurs, et en déduit les angles qui permettent de décrire la position de l’aéronef. Ce logiciel fait appel à des notions mathématiques complexes, rarement maîtrisées par un amateur, même averti.
Le hardware est donc très accessible et c’est pour cela qu’on voit fleurir sur le Web des réalisations qui, pour certaines, peuvent sembler très abouties mais, sans prendre le risque de se tromper, on peut dire que dans leur immense majorité, elles n’ont jamais été testées en vol avec succès.
Le cœur d’un AHRS est constitué d’une centrale inertielle (gyromètre et accéléromètre, chacun sur 3 axes) généralement couplée à un magnétomètre, également triaxial. Trois axes, qui permettent de façon générale de se repérer dans l’espace et qui, pour les avions, ne sont pas choisis au hasard : l’AHRS est « calé » sur les axes de roulis, de tangage et de lacet.
Les technologies actuelles ne font pas appel à des gyroscopes mécaniques, mais à des composants miniaturisés semi-conducteurs, sans pièce en rotation, des MEMS, pour Micro Electro Mechanical Systems. On trouve aisément dans le commerce, pour quelques euros, des centrales à inertie (ou IMU, pour Inertial Measurement Unit) à base de MEMS, associant un accéléromètre triaxial, un gyromètre triaxial, un magnétomètre triaxial et parfois un microcontrôleur 32 bits assurant la « fusion » des données de ces 9 capteurs pour fournir en clair à l’utilisateur une orientation absolue sous la forme des 3 angles bien connus de tous les pilotes : inclinaison, assiette et cap.
Les IMUs de ce type les plus connus sont le BNO055 de Bosch et le MPU9250 d’Invensense. Il en existe bien d’autres, plus récents et plus performants. Ces IMUs à 9 degrés de liberté sont utilisés intensivement comme capteurs d’orientation dans les contrôleurs de vol des drones multirotors, dans les smartphones, dans l’industrie automobile, la robotique…etc. Mais lorsqu’on cherche à les utiliser dans un aéronef à voilure fixe, ils posent tous le même problème rédhibitoire. Et ce problème est intimement lié à la mécanique du vol des aéronefs à voilure fixe, laquelle n’a rien à voir avec celle des drones multi rotors ou des véhicules et applications terrestres, pour lesquels ces IMUs ont été conçus.
Prenons par exemple un BNO055, le plus connu et le plus répandu dans la communauté Arduino, et utilisons-le comme AHRS pour un horizon artificiel. Confortablement assis devant un bureau, tout se passe comme attendu. En statique, l’attitude indiquée sur l’écran est strictement identique à celle que l’on impose manuellement à cet « AHRS », et avec une réactivité très supérieure au besoin. Emportons maintenant ce même système en vol dans un avion (donc à ailes fixes).
En vol rectiligne horizontal stabilisé, l’horizon artificiel reste parfaitement horizontal. Des petits mouvements sur les commandes de vols, vifs et de faible amplitude, avec retour rapide au vol horizontal rectiligne, sont parfaitement reproduits sur l’écran. Maintenant, mettons rapidement l’avion en virage horizontal stabilisé à 30° d’inclinaison. Au début du virage, l’horizon semble suivre correctement le mouvement pendant un bref instant. Mais au bout d’une ou deux secondes, il commence à revenir vers une position suggérant un vol rectiligne horizontal, position qu’il atteint finalement en deux ou trois secondes supplémentaires, pour s’y maintenir indéfiniment, alors que l’avion est toujours en virage à 30° ! Un tel AHRS ne sert bien évidemment à rien !
La raison de ce phénomène est la suivante : le BNO055, comme tous les autres IMUs à 6 ou 9 degrés de liberté, ne peut pas distinguer l’accélération due à la gravité terrestre de celle, centrifuge, liée au virage.
S’il y a une accélération uniquement sur l’axe Z, et aucune sur les axes X et Y (voir la figure 1), et c’est le cas en virage coordonné, le BNO055 et les autres IMUs de cette catégorie en déduisent à tort que l’avion est horizontal dans le repère terrestre. L’accélération résultant de la somme des vecteurs de la pesanteur et de l’accélération centrifuge est interprétée de façon erronée comme étant liée à la seule gravité, puisque le pilote maintient le vecteur de cette accélération résultante dans le plan de symétrie de l’avion… grâce à la bille! En IMC, notre oreille interne est trompée de la même façon.
Il manque donc à ces IMU le moyen d’isoler le vecteur inertiel du vecteur non inertiel, afin de pouvoir calculer de façon fiable la position de l’avion par rapport au repère terrestre galiléen (ou inertiel).
Ceux qui s’intéressent à la mécanique du vol des aéronefs à voilure fixe se souviennent qu’on peut déterminer l’inclinaison d’un avion en virage si on connaît le rayon du virage et la vitesse sur la trajectoire. En vol, il n’est pas facile de mesurer le rayon du virage qu’on est en train d’effectuer (!) mais on peut le déduire de la vitesse et de ce qu’on appelait « autrefois » la cadence, c’est à dire la vitesse angulaire, celle à laquelle « défile » le compas ou le conservateur de cap.
Ces données supplémentaires sont donc indispensables pour réaliser le calcul de l’angle de roulis. Les EFIS du commerce ont deux solutions pour récupérer ces données : soit ils utilisent, en sus des gyromėtres qui sont toujours affectés d’une dérive plus ou moins rapide, un magnétomètre intégré pour aider à calculer la vitesse angulaire, et sont reliés aux circuits de pressions statique ET dynamique pour calculer la vitesse de l’avion, soit ils exploitent les données d’un GPS/GNSS qui fourni (entre autres) la vitesse sol et la route vraie (track). Le plus souvent les deux solutions sont utilisées, pour pouvoir compter sur au moins une source de données en cas de défaillance de l’autre.
Les calculs mathématiques nécessaires à cette fusion de données font appel à des notions particulièrement complexes, hors de la portée d’un non spécialiste. N’ayant pas les compétences requises dans ce domaine, il fallait donc, pour notre EFIS, trouver une solution professionnelle. Elle nous a initialement été apportée par la Société Naveol, qui nous a fourni un prototype intégrant un GNSS Ublox, une centrale inertielle 6 DOF STMicroelectronics (accéléromètre triaxial et gyromètre triaxial) et un microcontrôleur assurant la fusion des données. Ce module était alimenté en 5 volts, comme la carte Teensy (voir ici) utilisée dans l’EFIS. Il communiquait avec cette dernière par la voie série à 115200 bauds. En vol, il fournissait de façon parfaitement exacte et précise les angles de tangage et de roulis, les vitesses angulaires sur les 3 axes, les accélérations sur les 3 axes, la route GPS, et la vitesse verticale (vario).
Malheureusement, ce module n’était ni open source, ni open hardware. De plus, la version commerciale qui aurait pu voir le jour, n’a finalement jamais été développée, peut-être en raison de l’incertitude sur les débouchés commerciaux, peut-être aussi en raison d’éventuels problèmes de responsabilité. Comme nous l’avait précisé NAVEOL, et cela convient bien au monde de l’aviation non certifiée : « Cet AHRS n’est pas certifié, ni conçu pour apporter une quelconque aide aux pilotes. Aucune garantie n’est fournie sur la précision et la fiabilité des données. Ce produit est dérivé de matériel pour modèles réduits ». Ces caractéristiques sont précisément celles que nous recherchions, afin de respecter notre cahier des charge en ce qui concerne la maîtrise des coûts.
Les constructeurs amateurs d’avions sont habitués à ce genre de restriction. Il en est de même de leurs passagers qui, pendant le vol, ont sous les yeux le petit panneau règlementaire qui précise : « ATTENTION : cet aéronef ne répond pas aux conditions de délivrance du certificat de navigabilité… etc . etc. »
Toujours est-il qu’il nous a fallu chercher une autre solution. Elle est venue d’un algorithme de fusion de données de type Extended Kalman Filter (ou EKF) développé par Adhika Lie de l’Université du Minnesota, et disponible en téléchargement dans le domaine public via ce lien. Cet algorithme (UNav INS) a été modifié et adapté au monde Arduino/Teensy par Brian R. Taylor de la société Bolder Flight Systems, et il a fait l’objet d’une discussion technique prolongée sur le forum PJRC. De nombreuses améliorations ont été progressivement apportées, la version la plus récente, celle qui est utilisée dans notre AHRS, est disponible en téléchargement ici (post #759).
La centrale inertielle Invensense 9DOF MPU9250 utilisée dans les exemples fournis avec la bibliothèque UNav INS est obsolète, et de plus en plus difficile à trouver dans le commerce. De plus, les sites de vente en ligne sont inondés de clones de provenance douteuse qui ne fonctionnent pas. Nous avons donc adapté l’algorithme pour utiliser des capteurs STMicroelectronics plus récents et plus performants, très faciles à trouver dans le commerce : le LSM6DSOX (accéléromètre triaxial et gyromètre triaxial) et le LIS3MDL (magnétomètre triaxial). Ces deux capteurs sont associés sur la carte Adafruit 4517.
Notre AHRS (fig. 2) est architecturé autour de ces capteurs et d’un GNSS U-Blox NEOM9N monté sur une carte SparkFun. Le logiciel de fusion des données tourne sur une carte Teensy 4.0. Pour pouvoir le tester rapidement avec l’EFIS déjà installé dans l’avion, lui-même conçu, câblé et programmé pour l’AHRS NAVEOL, la connectique reprend celle du boîtier NAVEOL, avec une sortie UART série (broches Tx et Rx). Mais il existe également une interface CAN Bus (broches CAN H et CAN L) qui doit être utilisée avec la version appropriée du logiciel, voir le fichier README sur le dépot GitHub. L’avantage majeur de l’AHRS AvionicsDuino par rapport au Naveol, c’est qu’il est intégralement open source open hardware, tout peut être modifié et personnalisé.
Installation dans l’aéronef
L’AHRS doit être parfaitement aligné avec les trois axes de roulis, de tangage et de lacet de l’avion en ligne de vol horizontal rectiligne.
L’orientation est la suivante : les cartes Teensy et IMU sont sur le dessus, la carte GNSS est en dessous, et le connecteur de sortie à 6 broches est à l’arrière.
Résultats
Les premiers tests en vol ont été d’emblée très satisfaisants, l’horizon de l’EFIS AvionicsDuino avec l’AHRS AvionicsDuino suit très fidèlement celui de l’EFIS Dynon D10A (vidéo 1), ainsi que l’horizon naturel (vidéo 2).
Les deux programmes EFIS et EMS qu’on voit à l’œuvre dans les vidéos ci-dessus sont des versions anciennes. De nombreuses améliorations et corrections ont depuis été ajoutées. Tous les paramètres affichés par l’EFIS ont été validés rigoureusement, durant de nombreux autres vols d’essai.
Réalisation pratique
Téléchargement du programme AHRS AvionicsDuino approprié depuis GitHub
La version 2.0 ou ultérieure de ce logiciel ne doit être utilisée qu’avec le logiciel de l’EFIS_Remote_Module version 2.0 ou ultérieure et le logiciel EFIS version 3.0 ou ultérieure. Cela est dû aux modifications importantes de la configuration du bus CAN qui ont été réalisées lorsque la ligne de communication série UART qui reliait l’EFIS à l’AHRS a été otée et que l’AHRS a été raccordé au bus CAN.
La version 1.3 doit être utilisée avec le logiciel EFIS_Remote_Module V 1.0, le logiciel EFIS V 2.5 et une ligne de communication série UART entre AHRS et EFIS. Ces versions anciennes ne seront plus mises à jour.
Il faut extraire les bibliothèques Bolder Flight System (dossier 3rdPartyLib) dans le dossier des bibliothèques Arduino.
Télécharger (ici et là) puis installer les bibliothèques Adafruit dans le dossier des bibliothèques Arduino.
Le GNSS U-Blox Neo M9N doit être configuré grâce au logiciel u-Blox u-Center.
Il est possible de le configurer manuellement en activant l’un après l’autre les messages nécessaires sur la sortie UART1, sortie qui doit elle-même être correctement configurée. Cette configuration manuelle constitue un bon exercice pour bien comprendre le fonctionnement et la « philosophie » u-Blox.
On peut également faire cette configuration plus simplement, à l’aide d’un fichier de configuration téléchargeable ci-dessous. Attention, il faut utiliser un fichier de configuration correspondant à la version du firmware du NEO-M9N. Voir sur la page Configuration du GNSS la façon de procéder à la configuration automatisée à l’aide de ce fichier.
La bibliothèque Bolder Flight Systems Ublox décode les données des messages suivants :
- UBX-NAV-DOP
- UBX-NAV-EOE
- UBX-NAV-POSECEF
- UBX-NAV-PVT
- UBX-NAV-VELECEF
- UBX-NAV-TIMEGPS
Tous ces messages doivent donc être activés dans le U-Center sur la sortie UART1 du GNSS. Cette sortie doit être configurée à 921600 bauds. Le paramètre CFG-RATE-MEAS doit être réglé sur 50 ms pour obtenir une fréquence de sortie des messages de 20 Hz.
Téléchargement des fichiers Kicad 6 de l’AHRS AvionicsDuino V1
Pour éviter à l’avenir les difficultés de configuration du NEO-M9N auxquelles Stéphane et d’autres ont été confrontés, j’ai refait la vidéo expliquant la procédure d’ajout des messages UBX-NAV sur la sortie UART1. Je pense que c’est effectivement nettement plus clair ainsi. Voir la page Configuration du GNSS u-blox.
Par ailleurs, après avoir sauvegardé la configuration de mon NEO-M9N, j’ai mis à jour le firmware, passant de la version 4.00 à 4.04. Et comme constaté par d’autres, je n’ai pas pu restaurer la configuration préalablement sauvegardée. J’obtenais un message d’erreur indiquant que la version du fichier de configuration ne correspondait pas au nouveau firmware. J’ai refait la configuration manuellement, et j’ai généré un nouveau fichier de configuration correspondant à la version 4.04 du firmware. Ce nouveau fichier est désormais également disponible en téléchargement dans le bas de la page AHRS.
Benjamin
Bonjour Stéphane,
À la bonne heure ! Bravo !
Merci pour la proposition de refaire les vidéos. En fait, la place n’est pas infinie sur le serveur, ce sont les vidéos qui en prennent le plus, et je ne souhaite pas les héberger sur un serveur tiers, genre YouTube. Je préfère donc faire ce travail. Car effectivement, si on regarde les vidéos sans lire les explications, on peut facilement se faire piéger. Vous êtes le deuxième à qui cela arrive, c’est donc bien qu’il y a un problème que je n’avais pas anticipé. Je vais donc refaire une des vidéos, et je vais mettre des avertissements dans le texte de la page AHRS et dans celui de la page sur la configuration du GNSS.
Désolé pour ce désagrément !
Benjamin
Bonjour Benjamin.
Effectivement quand on active les bons paramètres cela fonctionne bien mieux !!!!
Mon problème a été de m’arrêter aux vidéo d’explication et de faire bêtement ce que je voyais dedans, pensant que les paramètres qui étaient montrés dans ces vidéos étaient les bons ! Or non je te propose donc, pour que les buses comme moi ne se fasse plus coincer et du coup prendre de ton temps, de refaire ces vidéos que je t’enverrais.
Encore une fois un immense merci pour ton temps précieux.
Bonsoir Stéphane,
J’ai bien vus tous les messages que vous avez activés. Mais ce ne sont pas les bons. L’AHRS n’a que faire de trames NMEA. Les mesages à activer sont très clairement indiqués en bas de la page AHRS. Je ne peux que vous recommander de lire cette page attentivement jusqu’à la fin. Tout y est.
Benjamin
Je suis navré de mobiliser autant de ton temps, mon cerveau n’y arrive pas avec les paramètres du NEO…
Voici en pièce jointe des copies d’écran des paramètres que je viens de mettre dans le NEO.
peux tu me les confirmer stp
Bonjour Stéphane,
Pour l’AHRS, ce qui compte, ce sont uniquement les messages émis par le GNSS sur sa sortie UART1 et non sur sa sortie USB. Voir le bas de la page AHRS. Et tous les paramètres doivent être sauvegardés en RAM, BBR et FLASH.
Benjamin
Bonjour Benjamin.
J’ai donc repris un à un les paramètres en suivant tes vidéos point par point. Voici la photo de tous les paramètres changés, de l’état dans lequel il était et de l’état dans lequel ils se trouvent.
Bien a toi
Bonsoir Stéphane,
C’est ce que je pensais, et tout devient plus clair : le message UBX-NAV-PVT n’est pas activé sur la sortie UART1 de votre GNSS.
Les lignes Layers 0, 1 et 2 devraient toutes être à 1. Dans la case Value à droite, il faut saisir 1, puis cliquer sur les 3 boutons Set in RAM, BBR et FLASH, puis sur le bouton Send configuration pour enregistrer. Il faut faire la même chose pour tous les messages indispensables au filtre.
Ma vidéo explicative n’est peut-être pas assez claire, je vais la vérifier une nouvelle fois pour tenter de comprendre où est le piège. Éventuellement je veux bien vos remarques sur cette vidéo pour en améliorer la clarté.
Benjamin
et voici UBX NAV PVT en 1
Bonsoir Benjamin.
Voici la capture demandée.
Bonjour Stéphane,
OK, merci pour ces captures d’écran.
Deux choses sont maintenant claires :
– le port UART1 du NEO-M9N est bien configuré, puisqu’il peut être initialisé avec succès par
Gnss.Begin(921600)– les paramètres
Gnss.num_sv()etGnss.gps_tow_s()ne peuvent pas être lus sur cette sortie UART1 probablement parce que le message UBX-NAV-PVT n’est pas activé sur cette sortie.Pouriez-vous SVP faire une copie d’écran u-center, menu view, option Generation 9 configuration view, Advanced configuration, en développant le mesage CFG-MSGOUT-UBX-NAV-PVT-UART1. Il faut cliquer sur le signe + à gauche du message pour le développer. Bien sûr, le NEO-M9N doit pour cela être connecté en USB.
Benjamin
et voici la dernière capture ecran IDE et U-center
Bonjour Benjamin.
voici le résultat du debug
Bonjour Stéphane,
Bon, 11 satellites comme sur votre capture d’écran, c’est bien suffisant pour l’AHRS. Je ne comprends donc pas bien ce qui se passe.
Pourriez-vous essayer de téléverser ce sketch dans l’AHRS et observer la sortie sur le moniteur série de l’IDE ? C’est en fait le sketch de l’AHRS auquel j’ai juste ajouté quelques lignes
Serial.printde débogage.Par ailleurs, pour partager le code pour un écran en 800×480 (7″ ou 5″), j’ai rajouté l’option .zip pour joindre des fichiers à un commentaire. A faire dans un commentaire séparé sur la page EFIS et non AHRS, merci d’avance.
Benjamin
Bonsoir Benjamin.
Tout d’abord merci pour le temps consacré et l’aide apportée.
j’ai fait capture une capture d’écran. je suis a 12 la ou tu es a 16. j’ai commandé une antenne céramique qui parait il, est plus efficace. Tout le reste fonctionne sans problème il n’y a que l’ AHRS qui coince …..
De quel manière puis je transférer le code pour l’écran de l’EFIS en 7″ pour partager après que tu valides le test…
Bonjour Stéphane,
Merci pour les copies d’écran, cela va permettre d’y voir plus clair.
Votre copie d’écran du u-center permet de voir que le GNSS a fait son fix (fix=3 indique un fix 3D correct, donc au minimum 4 satellites en vue), et que la fréquence des trames UBX-NAV-PVT sur la sortie USB est bien de 20 Hz (iTOW indique le nombre de millisecondes écoulées depuis le début de la semaine en cours, et on a bien 50 ms entre chaque trame). Cette copie d’écran ne présage pas de ce qui est émis sur la sortie UART, mais a priori, si vous avez utilisé le fichier de configuration téléchargé sur le site, votre GNSS doit être bien configuré.
Votre copie d’écran du moniteur série montre effectivement que la communication de la carte Teensy 4.0 avec le GNSS se fait bien, idem pour la carte IMU Adafruit LSM6DS+LIS3MDL.
Et l’écran entièrement bleu de l’EFIS étant imposé par l’AHRS, on peut être certain que la communication série entre l’AHRS et l’EFIS se fait bien.
Cet écran bleu permanent alors que le GNSS a bien fait son fix traduit le fait que la condition « if (Gnss.num_sv() > 5) », au début de loop() n’est jamais vraie. Ce qui peut laisser supposer que votre GNSS ne capte pas le minimum requis de 6 satellites indispensables pour satisfaire cette condition.
Donc ma première question est la suivante : avez-vous une bonne antenne exposée au ciel sans aucun obstacle ?
Deuxième question : pourriez-vous poster une copie d’écran du u-Center, avec affichage des messages UBX-NAV-PVT décodés, dans une fenêtre « Message view » (ouverture par la touche F9), comme la photo jointe : on y voit clairement qu’il y a 16 satellites en vue (flèche rouge).
J’attends votre réponse, et pendant ce temps, je mets au point une version légèrement modifiée du programme de l’AHRS, avec plusieurs affichages de débogage dans le moniteur série, affichages qui nous permettront d’y voir encore plus clair. Je posterai ici cette version.
Benjamin
Voici la réponse de l IDE
Bonjour Benjamin.
J’ai injecter tes paramètres avec U Center.
Ca y est communication avec gnss ok + IMU ok .
pour autant toujours un beau ciel bleu ….
Bonjour Stéphane,
Comme promis, j’ai vérifié toute la page sur la configuration du GNSS, et j’ai à nouveau visualisé les vidéos. Tout me semble clair et correct, je ne vois pas très bien ce que je pourrais ajouter et/ou corriger.
Mais si vous avez des questions particulières ou des doutes concernant la configuration de votre GNSS, n’hésitez pas à poster un commentaire, soit sur cette page de configuration, soit sur la page AHRS.
Dans le doute, j’ai même installé sur mon PC la toute dernière version du u-Center (v23.08) : il n’y a eu aucune modification significative par rapport à la version qui m’avait servi pour faire les vidéos (v21.02). Je n’ai donc pas besoin de refaire ces vidéos.
A l’aide du u-Center, j’ai réalisé une sauvegarde de la configuration de mon GNSS dans un fichier .txt, puis j’ai rétabli sa configuration d’usine par défaut de ce GNSS. Et bien sûr, cela a empêché l’AHRS de démarrer, avec le message « Impossible de communiquer avec le GNSS » dans le moniteur série. J’ai ensuite rétabli la bonne configuration préalablement sauvegardée, et aussitôt, l’AHRS a fonctionné à nouveau normalement.
J’ai ajouté sur la page AHRS un lien de téléchargement vers ce fichier de configuration. Vous pouvez donc l’utiliser pour configurer votre GNSS, ce qui évite d’avoir à le faire manuellement. Comme l’utilisation de ce fichier de configuration n’est pas absolument évidente, j’ai rajouté un paragraphe spécifique sur cette page, pour préciser la marche à suivre.
J’espère que ceci pourra vous aider.
Benjamin
Bonjour Stéphane,
Ah ! Les choses ne s’arrangent pas… Si vous avez maintenant une impossibilité de communiquer avec le GNSS, c’est qu’il y a eu un retour en arrière, puisque le 13 janvier, vous écriviez que la communication avec le GNSS était établie… Ça devient vraiment très très difficile de vous suivre…
Vous devez avoir un problème de configuration de votre GNSS. A mon retour en fin de semaine, je vais revérifier que la page sur la configuration du GNSS, et en particulier les vidéos, sont assez claires, et au besoin, je ferai des correctifs ou des ajouts.
Benjamin
Bonsoir Benjamin.
code original téléversé après ajout des lignes demandées.
Message affiché au moniteur série IDE : impossible de communiquer avec le GNSS.
Quand a l’IMU …..rien de neuf
Bonjour Stéphane,
Avec ces informations partielles, ce n’est vraiment pas simple d’analyser votre (ou vos) problème(s). Par rapport à la dernière fois, (le 14 janvier) avez vous pu régler le problème du LSM6DS ? Si oui, que donne l’affichage dans le moniteur série de l’IDE quand vous rajouter les quelques lignes de code que j’avais écrites dans mon message du 11 janvier ? Si vous acceptiez de répondre de la façon la plus précise possible à ces deux questions simples, nous pourrions probablement avancer. Je pars bien sur de l’hypothèse que votre montage est strictement identique à celui du site, idem pour le software, et que vous n’avez apporté aucune modification.
Depuis notre dernier échange il y a deux semaines, j’ai commandé et reçu une nouvelle carte IMU Adafruit 4517 pour pouvoir refaire des essais au banc, en conditions expérimentales, et tout fonctionne parfaitement de mon côté.
Je vais être absent quelques jours, je prendrai connaissance de vos réponses à mes deux questions dès mon retour en fin de semaine.
Benjamin
Bonsoir Benjamin.
Je te fais un point de tout ce qui a été fait avec AHRS. Changer IMU, breakboard NEO, permuter les teensy, réinjecter le code….. Et rien n’y fait. J’ai recommencé mon faisceau et connecter en j8. J’ai même changé le PCB que j’ai contrôlé avant….. Et pourtant la communication reste impossible. Sur husse center j’ai plein de satellites j’ai refait les paramètres de la carte en suivant bien les vidéos…. J’en perds mon latin
Bonsoir Benjamin.
J’ai tout repris à zéro pour le AHRS. Contrôler le PCB, contrôler connectique, contrôler branchement, contrôler les versions et toujours problème avec le lsm6 DS je pense que mon IMU a un problème…. Je vais la commander et te tiens au courant après montage de la nouvelle. Merci
Bonjour Stephaner,
La ligne 38
/*indique juste un début de commentaire sur plusieurs lignes à partir de la ligne 39, commentaire qui se termine ligne 68 par*/Vous avez sans doute modifié le code quelque part pour que cette ligne 38 produise une erreur de compilation. Si vous remplacez
/*par//, cela n’a plus la même signification…Votre message n’est pas clair, je ne suis pas sûr de bien le comprendre, en particulier les modifications que vous avez réalisées. Que signifie « mon écran EFIS se réinitialise » ?
Quoiqu’il en soit, apparemment, vous avez donc quand même finalement réussi à compiler, et maintenant la communication est établie avec le GNSS : qu’avez-vous modifié ? Mais le programme semble désormais s’arrêter dans la boucle while infinie de la ligne 177 car il n’a pas pu initialiser le LSM6DS. Ce qui est assez incompréhensible, sauf mauvais câblage, détérioration du module IMU Adafruit 4517, ou modification hasardeuse du programme.
Pour en avoir le coeur net, histoire de repartir vraiment de zéro, j’ai téléchargé moi-même le programme de l’AHRS sur le site AvionicsDuino (puis GitHub), et je l’ai compilé : aucune erreur…
Voici ma configuration :
IDE Arduino v 1.8.19 et TeensyDuino v 1.59 beta#4
Toutes mes bibliothèques sont à jour, voici les versions que j’utilise :
Utilisation de la bibliothèque uNavINS-master prise dans le dossier: Documents\Arduino\libraries\uNavINS-master (legacy)
Utilisation de la bibliothèque Eigen-main version 3.0.2 dans le dossier: Documents\Arduino\libraries\Eigen-main
Utilisation de la bibliothèque ublox-main version 6.0.6 dans le dossier: Documents\Arduino\libraries\ublox-main
Utilisation de la bibliothèque Adafruit_LSM6DS-master version 4.7.2 dans le dossier: Documents\Arduino\libraries\Adafruit_LSM6DS-master
Utilisation de la bibliothèque Adafruit_BusIO-master version 1.14.5 dans le dossier: Documents\Arduino\libraries\Adafruit_BusIO-master
Utilisation de la bibliothèque Wire version 1.0 dans le dossier: C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\Wire
Utilisation de la bibliothèque SPI version 1.0 dans le dossier: C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\SPI
Utilisation de la bibliothèque Adafruit_Sensor-master version 1.1.14 dans le dossier: Documents\Arduino\libraries\Adafruit_Sensor-master
Utilisation de la bibliothèque Adafruit_LIS3MDL-master version 1.2.3 dans le dossier: Documents\Arduino\libraries\Adafruit_LIS3MDL-master
Utilisation de la bibliothèque TeensyTimerTool version 1.4.1 dans le dossier: Documents\Arduino\libraries\TeensyTimerTool
Je n’ai pas pu tester le fonctionnement sur un autre AHRS, je n’en ai qu’un exemplaire, et cet exemplaire est dans mon avion mais il fonctionne parfaitement.
Je vous conseille donc de faire comme moi, c’est à dire de repartir d’une version propre, non modifiée, du programme AHRS, fraichement téléchargée sur le site AvionicsDuino (GitHub).
Puis d’utiliser comme moi les toutes dernières versions de l’IDE, de TeensyDuino et des bibliothèques.
Si dans ces conditions le programme compile et se charge normalement sur la carte Teensy 4.0 de votre AHRS, et que l’AHRS ne fonctionne toujours pas, c’est que votre câblage a un défaut ou que le module Adafruit 4517 est endommagé.
Si à l’avenir vous avez à nouveau des soucis, et pour en faciliter la compréhension, il faudrait mettre dans vos posts des extraits de votre code montrant les modifications que vous avez apportées, des extraits des messages d’erreur du compilateur, et des liens vers un emplacement de stockage externe (Imgur ou autre cloud) où l’on pourrait visualiser vos schémas et PCB. Sans ces éléments, il est difficile et chronophage de vous aider efficacement.
Benjamin
la situation a évolué…. en compilant je remarquait une ligne un peu bizarre qui passait.
je l’ai recherché et trouvé : ligne 38 /* error « /* » et modifier en //. et maintenant j’ai :
Communication établie avec le GNSS
Adafruit LSM6DS+LIS3MDL test…..
Failled to find LSM6DS chip
et indice supplémentaire mon écran EFIS se réinitialise au démarrage du AHRS quand il est connecte a celui ci.
Re bonjour Stephaner,
Ah ! Que voilà une info utile !
Je ne sais pas si vous aviez bien examiné le programme de l’AHRS. Le message « Impossible de communiquer avec le GNSS » correspond à ces lignes :
162 if (!Gnss.Begin(921600))
163 {
164 Serial.println("Impossible de communiquer avec le GNSS");
165 while (1) {}
166 }
Donc votre GNSS ne peut pas être initialisé par la fonction begin(), et le programme s’arrête dans la boucle infinie de la ligne 165.
Si on exlut a priori un défaut du PCB ou des soudures, c’est que le GNSS est mal configuré.
Avez-vous bien configuré (comme indiqué en bas de la page AHRS, et en suivant les indications de la page Configuration du GNSS U-Blox) la sortie UART1 sur 921600 bauds ?
Je vous invite en particulier à regarder à nouveau la dernière vidéo.
Benjamin
Bonjour Benjamin.
L’AHRS est déconnecté de tout sauf du PC quand je clique sur l’icône après avoir injecté avec les 4 lignes de print j’ai la réponse suivante : impossible de communiquer avec le GNSS.
Du coup je me suis connecté via U-center grâce auquel j’ai fait les paramètres en suivant les procédures indiquées. J’obtiens en affichant les GPS un peu plus de 14 GPS visible et dans la case fix c’est marqué 3D gmss. Je pense avoir bien contrôlé mes soudures et les pistes les continuités de cartes Teensy a la carte spark fun.
Bonjour Stephaner,
On va essayer de comprendre ce qui ce passe. Tout d’abord en sériant bien les problèmes.
Avant de tester la communication entre AHRS et EFIS, il faut être certain que l’AHRS fonctionne correctement.
Pourriez-vous SVP faire le test simple décrit dans mon post du 11 janvier, avec l’AHRS seul, non relié à l’EFIS, en rajoutant les 4 lignes de code indiquées. Et nous tenir ensuite au courant du résultat.
Si l’AHRS fonctionne bien (PCB bien réalisé et GNSS bien configuré en suivant les indications du site, fix obtenu avec une bonne antenne, si possible en extérieur), on doit pouvoir lire sur le moniteur série le nombre de satellites en vue, et les angles de pitch et roll doivent évoluer conformément à la position de l’AHRS.
Benjamin
Bonsoir Benjamin.
communication impossible avec GNSS. Pourtant j’ai un beau fix. Avec U-Center j’arrive a lire les messages….
et Horizon artificiel avec ou sans AHRS marron et bleu. les écrans ont fonctionner ce soir sans discontinuer pendant 5 H sans soucis.
Bonjour Stephaner,
Comme je l’ai écrit le 3 janvier dans ma réponse à Laurent Lecoutre sur la page AHRS (à bien relire), si le GNSS de l’AHRS reçoit moins de 6 satellites (c’est le cas lorsqu’on vient de mettre l’AHRS sous tension), il envoie un angle de pitch de 90° à l’EFIS, donc ce dernier ne doit alors afficher que du bleu (et pas du marron). Si à la mise sous tension de l’ensemble l’EFIS affiche immédiatement un horizon avec moitié bleu et moitié marron, c’est soit qu’il y a un problème de communication entre l’EFIS et l’AHRS (bien vérifier la connexion Rx-Tx/Tx-Rx, et bien sûr ne pas utiliser pour le moment le CAN bus entre l’AHRS et l’EFIS), soit que l’AHRS ne fonctionne pas, ou pas correctement. Cela ne devrait pas être trop compliqué à déboguer en rajoutant quelques Serial.print dans la fonction loop() de l’AHRS et en obserant le résultat dans le moniteur série de l’IDE.
Je suggère cette insertion de 4 lignes à la fin de loop(). Ainsi placées, ces lignes ne seront exécutées qu’une fois au moins 6 satellites en vue. Et même si l’AHRS n’est pas connecté à l’EFIS. Je n’ai pas testé sur mon AHRS, car il est monté dans mon MCR.
282 secondeGNSS = Gnss.utc_sec();
283 tabTrame[28]=secondeGNSS;
284
285 }
286 Serial.printf("Nombre de satellites : %2.0f %s",nbSat, "\n");
287 Serial.printf("Pitch en degrés : %2.0f %s",pitch * (180 / PI), "\n");
288 Serial.printf("Roll en degrés : %2.0f %s",roll * (180 / PI), "\n");
289 Serial.println("--------------------------------------------------");
290 }
291 }
292 //******************** Fin de la boucle infinie Loop *********************************
Pouvez-vous SVP me tenir au courant du résultat de ce test simple ?
Benjamin
Bonjour Benjamin.
Tout est téléversé dans tout les modules. En relisant les post sur l’AHRS je vois que si il n’y a pas de fix , l’EFIS est par défaut sur un écran marron. Hors le mien est avec la représentation de l’horizon avec ou sans AHRS. L’AHRS connecté il ne se passe pas plus que sans(vague sensation de ne pas avoir de communication).
Bonne journée et merci d’avance.
Du coups je ne vais pas perdre de temps et me lancer sur l’EFIS.
Pour le « fixe » c’est bon j’ai trouvé ce qu’il me faut dans mon stock pour dépanner, il me restera à trouver une antenne digne de ce nom à poser sur la machine.
Re bonjour Laurent,
Non, en dehors de celui de l’EFIS, il n’existe pas de logiciel permettant de tester facilement et immédiatement l’AHRS.
De plus, ce dernier a vraiment besoin d’un fix GPS pour fonctionner correctement, donc une antenne est indispensable.
En l’absence d’un bon fix, l’angle de pitch reste bloqué (volontairement) à 90°, donc l’horizon artificiel est entièrement bleu (c’est un avertissement signifiant que le système ne fonctionne pas encore).
Il faut attendre qu’au moins 6 satellites soient en vue pour que la ligne d’horizon apparaisse, avec la terre marron en bas et le ciel bleu en haut.
Enfin, dans l’état actuel du logiciel, l’AHRS n’envoie spontanément aucune donnée sur la voie série UART (Serial2) qui le connecte à l’EFIS, c’est l’EFIS qui déclenche l’envoi d’un trame de données en envoyant le caractère ‘F’ 20 fois par seconde à l’AHRS sur Serial2.
Ceci étant dit, il existe quand même un moyen assez simple de tester l’AHRS : il suffit de rajouter quelques lignes de Serial.print() dans la boucle loop() avec les angles qu’on veut « visualiser » (en pratique roll et pitch), et si la carte Teensy 4.0 de l’AHRS est reliée par un câble USB à un PC, le terminal série de l’IDE Arduino affichera ces angles sous forme textuelle. En faisant tourner l’AHRS à la main, on doit voir les angles évoluer dans le terminal série.
Mon AHRS est monté dans mon avion, je n’ai pas testé… Mais ça doit fonctionner.
Benjamin
Merci Benjamin pour ton retour.
Mon AHRS est maintenant terminé et j’attaque l’EFIS, en attendant existe il a ta connaissance un logiciel android ou PC compatible permettant de tester son bon fonctionnement ?
Bonjour Laurent,
Passer à TeensyDuino 1.59 Beta #3 (ou même maintenant #4) était effectivement ce qu’il fallait faire. Il y avait une incompatibilité entre TeensyDuino 1.58 et la bibliothèque Eigen.
Dans les commentaires les plus récents de la page en anglais sur l’AHRS, j’ai précisé, concernant l’AHRS, les versions de bibliothèques à utiliser.
Benjamin
Correction de mon commentaire :
au final le problème venait de la version de la bibliothèque TeensyDuino la compilation a fonctionné uniquement avec la version 1.59.3
Il faut que je me trouve un pigtail et une antenne pour le GPS !
Hello,
Merci pour ce super projet, j’ai décidé de me lancer tant il est passionnant et devrait donner un coup de jeune à mon ULM 🙂
J’ai terminé la partie hardware de l’AHRS … me voilà maintenant dans les galères de compilation avec la notamment la librairie Eigen qui me donne du fil à retordre 🙁
La version incluse dans le fichier « AvionicsDuino_AHRS_3rdParty_Libraries » remonte avec des erreurs multiples de type :
In file included from d:\Users\laure\OneDrive\Documents\Arduino\libraries\Eigen-main\src/Eigen/Core:172,
from d:\Users\laure\OneDrive\Documents\Arduino\libraries\Eigen-main\src/Eigen.h:36,
from d:\Users\laure\OneDrive\Documents\Arduino\libraries\uNavINS-master/uNavINS.h:48,
from D:\Users\laure\OneDrive\Documents\Arduino\AHRS_AvionicsDuino_V1.3\AHRS_AvionicsDuino_V1.3.ino:107:
d:\Users\laure\OneDrive\Documents\Arduino\libraries\Eigen-main\src/Eigen/src/Core/GenericPacketMath.h:719:57: note: ‘Eigen::prefetch’ declared here
719 | template EIGEN_DEVICE_FUNC inline void prefetch(const Scalar* addr)
et la version trouvée sur Gitlab indique l’absence du Eigen.h alors qu’il est bien présent.
Vraiment super !!!!
Bonjour,
Il y a si peu de composants sur cet AHRS que la BOM n’avait pas été rédigée!
Mais c’est chose faite, elle est téléchargeable sur la page AHRS.
Benjamin
Bonjour.
as tu le BOM pour le AHRS s’il te plait? …. que je ne face pas de bêtises à la commande
Bonjour Jean Claude,
Si tu n’as pas modifié le PCB qui est sur le site, la carte GNSS est en dessous, la carte IMU Adafruit est vers l’avant, la prise USB de la carte Teensy 4.0 est à gauche, et la prise USB du GNSS à droite.
Amicalement,
Benjamin
Bonjour Benjamin,
Le téléchargement de l’AHRS s’est bien passé, et pour continuer l’Efis, je suis en train de créer un boîtier pour l’AHRS que je vais réaliser avec mon imprimante 3D afin de le rendre moins fragile lors des manipulations pour les tests. Je me pose une question, la partie supérieure de l’AHRS est elle le NEO ou le Teensy et capteurs Adafruit ? Le logiciel laisse supposer que c’est le NEO, car tu inverses les axes Y et Z.
Voilà, je m’apprête à mettre sous tension tout cela et je croise les doigts, je te tiens au courant.
Amicalement
Jean-Claude
Bonsoir Jean Claude,
Tout est en téléchargement sur la page AHRS ! Il y a 3 liens, pour le programme de l’AHRS, pour les bibliothèques nécessaires, et pour les fichiers Kicad. Même pas besoin d’aller chercher sur Internet !
Amicalement,
Benjamin
Bonjour Benjamin,
Je suis sur L’AHRS, la partie matérielle est terminée, il me reste le téléversement dans la Teensy 4.0. A ce sujet, il me manque la bibliothèque ubx.h, une recherche sur internet me donne 2 options, afin de faire une erreur, pourrais tu me donner le lien pour télécharger le bon fichier. Après cela, je fais les essais de l’EFIS complet et je te donne les résultats. Merci d’avance.
Amitiés
JCB
Bonjour Jean Claude,
Au moment où le schéma de l’EFIS a été fait, nous utilisions un prototype d’AHRS fourni par la société Naveol. Cet AHRS comportait un GNSS, mais le système était fermé, tant sur le plan hardware que logiciel. Il n’y avait donc aucun accès direct possible à ce GNSS. L’AHRS Naveol transmettait par voie série des trames comportant un nombre fini de paramètres, sans aucune personnalisation possible. Pour cette raison, un autre GNSS a été inclus dans l’EFIS, de façon à ne pas se priver des nombreuses possibilités d’évolution que cela autorisait (réglage de l’heure, calcul de la vitesse et de la direction du vent… etc.).
Par la suite, nous avons mis au point notre propre AHRS, en utilisant le même GNSS que celui de l’EFIS. Et pour pouvoir le tester rapidement sans modifier l’EFIS, cet AHRS a été conçu « compatible Naveol ». Avec la même sortie série, et les mêmes trames de données. Ce qui a permis de le valider très simplement, en le mettant à la place du Naveol. Mais le nouvel AHRS comporte une possibilité de connexion au CAN Bus, ce qui améliore beaucoup ses capacités de communication avec les autres modules du système, dont l’EFIS. Donc avec un petit développement supplémentaire orienté CAN Bus, un seul GNSS est suffisant. Il peut être situé dans l’AHRS ou dans l’EFIS.
Si je devais modifier l’architecture du système qui est installé dans mon MCR, je conserverais un seul GNSS, dans l’AHRS, et cet AHRS serait relié à l’EFIS par le bus CAN, il lui transmettrait aussi les quelques paramètres dont il a besoin pour régler l’heure, calculer le vent et autres… La liaison série AHRS-EFIS serait supprimée.
Le bus CAN est vraiment la meilleure solution de communication pour mettre en réseau les différents éléments du système avionique.
Amicalement,
Benjamin
Bonjour Benjamin,
Actuellement en cours de commande des éléments AFIS et AHRS, j’ai une question, faut il 2 UBlox NEO M9N, un connecté directement sur la Teensy 4.1 et un dans l’AHRS ?
Merci pour cette belle réalisation..
Jean-Claude
Bonjour Julien,
Merci pour ce commentaire.
Pour l’instant, ce module n’est pas encore commercialisé par Naveol. Il s’agit d’un prototype qui nous a permis de valider le design de l’efis. Il y a déjà presque 10 personnes intéressés, Naveol souhaiterait au moins une vingtaine de client potentiels pour finaliser une version commerciale. J’espère que ce sera dans les mois qui viennent.
Le firmware n’est pas open source, il appartient à Naveol. A ma connaissance, il n’existe pas à l’heure actuelle de soft open source capable d’animer un ahrs utilisable dans un aéronef à voilure fixe…
Salut
Bien interessant comme acticle j’en arrive à la même conclusion
le firmware est open source?
comment on peux ce procurer le module avec le GPS?
Merci