Le Dragonfly
C’est un avion de construction amateur, dérivé du Quickie de Burt Rutan, le génial père des VariEze, Long-EZ, Voyager et bien d’autres (voir Wikipédia pour plus d’informations).
Paul a équipé le sien de deux allumages électroniques, en lieu et place de l’allumage d’origine par magnéto. La magnéto, c’est moins bien sur bien des aspects, mais si on perd la batterie et l’alternateur en vol (c’est une image), le moteur continue à tourner. L’allumage électronique est plus exigeant côté alimentation…
Pourquoi un double allumage ?
Parce que sur un moteur d’avion à essence, l’allumage est généralement doublé pour assurer une redondance : traditionnellement, deux magnétos alimentent deux bougies par cylindre. Dans le cas de ce Dragonfly dont le moteur est dérivé d’un moteur automobile, la magnéto était unique.
L’inconvénient de deux allumages par rapport à un seul, est qu’on a deux fois plus de chances d’avoir une panne d’allumage ! Donc pour que le doublement de l’allumage apporte une sûreté de fonctionnement accrue par rapport à un seul, il faut que la redondance soit complète, de façon à ce que la panne d’un seul allumage n’arrête pas le moteur. C’est bien le cas avec deux magnétos et deux bougies par cylindre, et évidemment pas avec une seule magnéto.
Une méthode classique est d’assurer la redondance par deux technologies différentes, par exemple un allumage par magnéto, et un autre électronique. Ce faisant, on évite qu’un défaut systématique se produise simultanément sur les deux allumages (casse d’une pièce d’usure sur une magnéto, condensateur chimique défaillant au bout de 5000 h dans un montage électronique). Pour la même raison et sans être totalement paranoïaque, on peut sur des solutions informatisées, utiliser non seulement des bases matérielles différentes mais aussi des programmes développés par des équipes indépendantes.
Ceci étant, le pire n’est pas certain, l’utilisation de la même technologie sur les deux parties redondantes ne représente pas un risque grave dès lors que la fiabilité de ladite technologie a été prouvée. C’est bien le cas de l’allumage par deux magnétos identiques, c’est aussi le cas si on utilise un allumage électronique dont la fiabilité est avérée. A cet égard, l’utilisation d’un allumage issu du marché automobile et connu comme fiable est une idée très pertinente. C’est ce qui a conduit Paul à choisir un allumage largement éprouvé sur véhicules Ford (Fiesta, etc.).
On le voit ici, à gauche du rouleau de fil rouge et noir passé « au cas où » en même temps que les autres (il porte la référence ESC 89FB-12A297-BB) :
L’analyse des modes de défaillance d’un système conduit à faire la chasse aux pannes dites de « mode commun », c’est à dire aux pannes pouvant réduire à néant la belle redondance qu’on a cherchée à mettre en place : deux allumages électroniques fiables, deux bougies par cylindre, mais une seule batterie, on voit tout de suite qu’un défaut électrique sur la batterie unique (ou sur l’alternateur qui l’alimente) se traduira par une panne simultanée des deux allumages et donc un arrêt du moteur. Pour cette raison, Paul a prévu d’alimenter un des deux allumages par une batterie de secours se rechargeant en même temps que la principale, mais via une diode anti-retour évitant que toute l’installation électrique de l’avion vienne décharger la batterie de secours en cas de défaillance de la batterie principale. Ainsi on a un allumage sur une batterie et un autre allumage sur une autre batterie, la panne de mode commun est évitée.
Sur cette photo, on voit la batterie de secours (12V – 7,2 Ah), sous la double bobine (de référence 88SF-12029-AA) d’un des deux allumages .
Mais alors où est le problème ?
Fondamentalement, le montage des deux allumages électroniques alimentés chacun par une batterie spécifique est sain, mais la question est de savoir où et comment connecter le compte-tours VDO. Question simple, mais réponse un peu compliquée.
L’allumage utilisé ne possède pas de sortie spécifique pour un compte-tours, mais comme il alimente deux bobines, il possède deux sorties pour ce faire. Chacune de ces sorties équivaut à un rupteur mécanique classique qu’on aurait remplacé par un composant statique. A l’oscilloscope on voit du 12V continu, qui chute à 0 quand le « rupteur » se ferme, et qui réapparait à l’ouverture du rupteur mais surmonté brièvement d’un pic de plusieurs centaines de volts. C’est normal, le but du bidule est de justement générer ce pic au primaire de la bobine pour que le secondaire fournisse aux bougies le pic de plusieurs kilovolts qui va bien. Mais peut-on impunément appliquer ce signal au compte-tours sans le griller, ni écrouler l’énergie fournie à la bobine ?
Le prudence impose d’interposer un petit circuit de mise en forme du signal. Moitié calculé et moitié pifométré, un circuit en « T » avec, horizontalement (l’horizontale du T), deux résistances de 47 kΩ et, verticalement, un condensateur de 10 nF font l’affaire. L’oscilloscope confirme que le signal est correct pour le compte-tours et que le signal appliqué à la bobine n’est pas atténué. Et le compte-tours affiche un régime plausible. Par contre, l’avance à l’allumage n’étant pas encore calée, le régime est instable et l’aiguille peu amortie du compte-tours amplifie la chose.
Un essai du compte-tours sur un générateur de signal rectangulaire 0-12V (facile à réaliser sur un Arduino) montre qu’effectivement le compte-tours n’aime pas les échelons de fréquence du signal. Un essai avec des paliers successifs de deux secondes à 500, puis 1000, puis 2000, puis 3000 tours/minute, met en évidence des oscillations de l’aiguille du compte-tours à chaque changement de palier.
A ce stade, on sait récupérer le signal pour le compte-tours, et on a bien noté qu’il faudrait l’intégrer pour calmer les oscillations du compte-tours (mathématiquement, si on intègre un escalier on obtient une rampe : normal !). Cette intégration est déjà une première complication. La seconde complication est que si l’allumage auquel on a choisi de connecter le compte-tours tombe en panne, on a un problème : le moteur tourne sur l’autre allumage, mais on n’a plus de compte-tours. Donc si on résume, on veut générer un signal pour le compte-tours qui soit toujours prélevé sur l’allumage le plus sain, et qui de plus soit intégré pour limiter les oscillations du compte-tours.
Ce sera déjà une amélioration. Le seconde amélioration bien tentante est de gérer automatiquement le cas simple d’un défaut de batterie. En effet, ce défaut de batterie entraine (en tout cas au bout d’un certain temps) la perte de l’allumage qui y est connecté, ce qui est dommage quand on sait que l’autre batterie, saine, pourrait alimenter les deux et que du coup on conserverait la redondance des allumages. Donc on va ajouter la commutation automatique de l’alimentation des allumages : chaque allumage est alimenté par sa batterie attitrée en temps normal, mais si la tension de ladite batterie est trop basse, il commute sur l’autre ; quitte à revenir ensuite à la configuration initiale si la tension de batterie est remontée à une valeur normale.
La solution retenue : BGA sur base Arduino
Le BGA, c’est le nom que nous avons donné au Boitier de Gestion des Allumages…
Le voici en place derrière le tableau de bord :
Quant à l’Arduino qui constitue le coeur du boîtier, c’est un petit circuit du commerce disponible pour pas cher en France et à vil prix sur le marché asiatique (le nôtre a couté 5 € port compris, mais c’est un clône avec quelques différences par rapport à l’original).
Voici l’intérieur du boitier en cours de câblage :
Pour le raccordement des allumages aux batteries, nous avons utilisé le module de 2 relais (2 € port compris, acheté devinez où) que l’on voit sur la gauche de la photo sous les 4 gros fils rouges. Qu’on se rassure, les fils sont gros à cause de l’isolant silicone, mais il ne passe qu’un ampère par allumage.
A ce propos, on peut s’interroger sur l’utilisation, sur le boîtier, d’un connecteur DB25 qui n’a pas vocation de connecteur d’alimentation : par précaution, toutes les broches des circuits d’alimentation sont doublées. Ce n’est pas près de chauffer autant que les prises micro-USB de nos smartphones bien plus inquiétantes à cet égard.
S’agissant d’un seul exemplaire à réaliser, le plus simple est l’utilisation d’une carte fille « proto shield » surmontant l’Arduino, sur laquelle on peut reporter toute la partie électronique (qui s’est compliquée en cours de route depuis la photo). Pour le rétablissement de la balance commerciale, ce « shield » a été approvisionné en France : circuit nu à plus de 12 €, balance dûment rétablie…
Pour le pilote, l’interface est minimaliste : un interrupteur ON/OFF spécifique à l’allumage, et 4 voyants (LEDs bicolores).
A la mise sous tension, un bref autotest permet de vérifier les voyants.
Puis (voir photo ci-contre) les deux voyants « batteries » s’allument en vert (batteries OK) et les deux voyants « allumages » s’allument en rouge (allumages éteints).
Ensuite, dès que le moteur tourne, les 4 voyants sont verts et si tout va bien ils le resteront pendant toute la durée du vol.
Cette notice d’utilisation en dit un peu plus sur les indications des voyants et sur la logique de fonctionnement du BGA.
Schéma électronique du BGA et programme de l’Arduino
Sauf à vouloir adapter la présente réalisation à une application similaire, l’exposé du détail de l’électronique et du programme Arduino ne présentent pas d’intérêt particulier. Néanmoins, j’ai assez complètement documenté le tout, donc si vous êtes intéressé merci de compléter le formulaire de prise de contact en page d’accueil du présent site, de façon à ce que je vous transmette ce qui peut vous être utile pour votre propre application.
Particularités du programme
Utilisation des interruptions
Le logiciel passe son temps à attendre des évènements « rares ».
L’horloge de l’Arduino a une fréquence de 16 MHz et donc une période de 1/16 = 0,0625 µs. Quand les choses « se précipitent » (moteur à 3000 tours/minute), l’Arduino n’a du travail urgent que toutes les 10 ms, soit tout les 160 000 coups d’horloge. C’est dire qu’il a du temps libre pour mesurer les tensions de batteries, faire divers calculs et commander les voyants.
La solution classique est que le programme principal [qui s’appelle d’ailleurs loop()] boucle sans cesse en regardant s’il y a du nouveau, ce qui fait plein de scrutations de nombreuses variables pour rien, avec le risque qu’une des scrutations tombe sur un cas mal géré et que le programme se plante dans une boucle sans fin. Il est beaucoup plus simple d’utiliser les interruptions (dont celle d’un des timers de l’Arduino) pour cadencer le travail du microprocesseur en lui disant quand une impulsion vient d’être reçue d’un allumage ou quand telle ou telle temporisation est terminée. C’est la solution qui a été retenue.
Intégration du signal envoyé au compte-tours
Le signal envoyé au compte-tours est un signal rectangulaire normalement de même fréquence que celle des impulsions reçues de l’allumage.
Sauf que pour éviter de répercuter les variations rapides de cette fréquence des impulsions, on a vu qu’il faudrait l’intégrer. Donc au lieu de seulement mesurer la durée entre les deux dernières impulsions, on va calculer la moyenne des 25 dernières durées mesurées, dite « moyenne glissante ». On va donc calculer la « somme glissante » qu’on divisera ensuite par 25 pour avoir la moyenne.
Pour réaliser cela, on utilise une structure faite pour ça : un tableau de 25 cases. Trop simple !
Le mécanisme est le suivant : on imagine 25 cases disposées en cercle, et on remplit ces cases, une à une, avec les mesures successives comme on distribuerait des cartes à jouer, chaque case à son tour. A cette différence près avec le jeu de cartes que chaque nouvelle carte dans une case remplace l’ancienne au lieu de se placer au-dessus.
Quand une mesure nouvelle arrive, elle doit aller dans une case contenant déjà une mesure ancienne. Je lis cette mesure ancienne (que je peux maintenant jeter), je la retranche de la somme glissante actuelle et j’y ajoute la valeur de la nouvelle mesure (que je place à son tour dans la case, à la place de l’ancienne, pour la conserver jusqu’au prochain passage). C’est tout ! La prochaine mesure tombera dans la case suivante et ainsi de suite. A chaque nouvelle mesure, la somme glissante est recalculée : en quelque sorte elle oublie la mesure la plus ancienne pour la remplacer par la plus récente, de sorte qu’elle est toujours égale à la somme des 25 dernières mesures.
On pourrait procéder de façon moins astucieuse et calculer benoitement à chaque nouvelle mesure la somme des 25 cases, mais ce serait beaucoup moins rapide, et tellement moins beau…
Juste un conseil : arrêtez les mots croisés et le sudoku, et mettez vous à l’Arduino, c’est bluffant.