aircockpit.com

ah je viens de comprendre . . .
sgdg-> abréviation . . . . sans garantie du gouvernement,


j'ai fait boulette

Bonjour,

quelques nouvelles du front !

D'abord, une fois n'est pas coutume, un coup de gueule : 4 membres du forum, je tairai les noms, m'ont demandé les plans du throttle : pas de problème avec le premier d'entre eux, honorable membre bien connu ici ; en revanche, les 3 autres, des membres peu à pas actifs sur le forum, pour lesquels j'ai du faire quelques manip supplémentaires pour les satisfaire, ont fini par obtenir leur plan, mais après, plus rien, pas l'ombre d'un merçi ... je ne m'étends pas, ça m'est déjà arrivé sur un autre forum avec les plans de ma cnc et de mon tour, à l'avenir je ne partagerai qu'avec les ceuces que je connais, na !

Sinon, en plein dans le programmation de la motorisation du trim, je me suis fixé un cahier des charges un peu sévère, mais j'ai du mal :
- d'abord, au plan de la pure programmation, je voulais réaliser la chose à base de LUA coté FSUIPC/FMGS, et C++ et Arduino pour le pilotage du moteur - et en particulier, je voulais une bonne programmation objet sur l'Arduino, de façon à pouvoir facilement partager et ré-utiliser : il s'avère qu'intégrer proprement les timers en prog objet sur l'Arduino est particulièrement ardu, donc au final, j'ai un bout du truc en objet, mais qui n'intègre pas l'horloge, qu'il faut piloter en prog traditionnelle ; je n'abandonne pas pour autant, mais il faudra que je me perfectionne coté C++.

- et puis, au plan des principes, voilà ce sur quoi je suis parti : le trim est actionné par un moteur pas-à-pas ; la position physique du trim est capté par un potentiomètre (le classique 10K piste cermet qu'on doit tous utiliser à profusion) ;
cette formule permet une intégration mécanique simple et très compacte.
l'algo est le suivant :
au démarrage, lecture de la position physique, traduction en nombre de pas nécessaires pour rejoindre la position 0, et envoi au moteur du nombre de pulses correspondant.
en l'air, à chaque changement de la valeur FMGS du trim, lecture de la position physique, traduction en nombre de pas nécessaire pour rejoindre la bonne position à partir de la position courante, et envoi au moteur du nombre de pulses correspondant.
si un nouveau changement intervient alors que le trim est en mouvement, pas de pb, il suffit de rectifier à la volée le nombre de pulses et la direction.

Donc en fait fonctionnement en boucle ouverte, un moteur pas à pas ne perd pas de pas s'il est correctement mis en œuvre ; je n'ai pas voulu faire d'asservissement pour éviter les phénomènes de pompage ...

Mais il y a un hic ! le potentiomètre de 10K n'est pas très précis, mais il est surtout horriblement pas linéaire, je ne l'avais jamais vraiment mis en évidence ; du coup, le nombre de pas calculé est vraiment mauvais, avec une erreur dans un sens ou dans l'autre selon la position du potentiomètre, ce qui fait que le pompage dont je ne voulais pas est bien là à chaque changement de valeur FMGS ...

Donc 2 solutions :

soit je conserve le potentiomètre, j'accepte le pompage (le phénomène est heureusement bien convergeant) lors du positionnement du trim à 0 au démarrage, et ensuite, je ne consulte plus la position physique du trim à chaque changement de valeur FMGS, et ne travaille qu'en nb de pulses relatifs (ce qui est parfaitement correct, toutes les cnc amateur fonctionnent comme ça).

soit je change mon fusil d'épaule, je vire le potentiomètre et mets 2 fins de course sur les 2 positions extrêmes du trim, afin de pouvoir retrouver le 0 physique du trim à chaque démarrage, et je pilote le moteur en relatif

Je pense que je vais opter pour la première solution, ce qui m'imposera de rajouter un dispositif d'étalonnage de la position 0, mais ça, avec l'arduino, il suffira de rajouter un petit potentiomètre.

Cela étant, les principes généraux sont quand même validés

Voilà, tout ça n'est pas très visuel, mais après la mécanique, il faut quand même s'occuper un peu du cerveau de la chose !

A+, Michel

nb : et au fait, en passant, développer en LUA sous FSUIPC, c'est vraiment extrêmement inconfortable, vraiment l'âge de pierre !

Idée bête: pourquoi pas une fourche optique type souris pour le capteur de position? Une fois que tu as remis le trim à zéro, il est facile de compter le nombre de pas? Il doit sûrement exister des modèles pour Arduino, avantage c’est inusable et indéréglable.
Fab devrait pouvoir élaborer plus avant

Jacques

Toutes les idées sont là et sont bonnes, pour éviter le pompage, inévitable je pense (jeux et autres imprécisions), tu intègres une zone de neutre, qui donnera une marge d'erreur dans laquelle il ne se passera rien.

As-tu essayé en 1/2 pas à l'approche de la consigne ?

Il est certain que je ne conçois la bonne utilisation d'un moteur pas à pas qu'avec une position zéro et comptage de pas, je n'en n'ai jamais mis en oeuvre avec un potentiomètre, j'utilise plutôt des moteurs DC qui par le fait qu'ils n'ont pas de "pas" sont plus simple à utiliser, comme ici avec un capteur magnétique :

https://youtu.be/C4zL3Z2wHo8?t=389

Oui, Jacques, la fourchette optique comme fin de course, mais j'aimerai rester dans la simplicité du schema moteur + pot !

Oui Fabien, j'ai déjà joué avec ça, mais c'est parfaitement inefficace : imagines, je mesure la position, 1000, je donne l,ordre d'aller à 1000 mais j'arrive à 1100 ! Je remesure car désormais il faut aller à 1200 mais j'arrive à 1150 !!! La précision du pot est 10%, on peut faire avec, mais c'est très irrégulier, en positif comme en négatif ... c'est la non linéarité qui sème le bazar !

La solution de facilité aurait été d'utiliser un moteur cc, encore que ...

Michel

Moi je ferai :
-1 - Mesure de la position
-2 - comparaison à la consigne
-3 - choix d'un pas en avant ou en arrière
-4 - Mesure de la position
-5 - si consigne non atteinte aller à -2-

Et les 1/2 pas à l'approche de la consigne, tu as essayé ?

Avec le moteur CC, tu as une autre joyeuseté : L'intégration d'un PID dans ton algorithme ...

Oui Fabien,

J'ai en effet l'intention d'essayer cet algo, mais je crains de saturer l'arduino, car pour fluidifier le mouvement j'ai duz poussé au max le nombre de microsteps (32) ... la parade pourrait être de diminuer ça, mais de gérer l'accélération ; la bestiole n'est pas vraiment rapide !
Quand au pid, c'est précisément ce que je que je voulais éviter, car gourmand en temps de calcul ; un peu les limites d'arduino

Michel

Je suis étonné: Un arduino a normalement la puissance de calcul pour gérer un PID? J’ai fait un petit robot de suivi de ligne et distancemetre ultrasons qui utilise l’algo PID sur Arduino, et qui fonctionne sans saturation.
D’autant que dans ton cas, a priori tu n’utiliserais que la partie PI(power et Intégrative) , pas la D(erivative)?
Il ne s’agit que de piloter une roue en asservissement!
Sinon l’algo utilisé pour le déplacement doux des aiguilles en Lua, qui gère l’acceleration, devrait pouvoir être utile? Je vais regarder. Tout le soucis si j’ai bien compris c’est que la position donnée par le polar n’est linéaire?


Jacques

Je pense à autre chose:
Un tableau de positions créé lors de l’etalonnage, qui stocke des couples (position physique de la roue/résistance du pot)
Un peu chiant a établir, mais une fois fait, le fait que le potard ne soit pas linéaire n’est plus un problème?

Bonjour Jacques,

en fait, je n'ai pas essayé le PID, je n'ai fait que supposer que ça allait être un peu juste, mas peut-être me trompe-je !

mais, comme je le disais plus haut, le moteur pap me plait bien pour des raisons de simplicité de design : le moteur est bien intégré dans le corps du throttle, le potentiomètre et son engrenage viennent se glisser dans un petit coin sous un autre engrenage, c'est vraiment sympa comme implantation, et puis en jouant sur l'enable du driver, aucun pb d'embrayage ...

Alors oui, le pb c'est la non linéarité du potentiomètre, et le fait que 2 mesures successives de sa résistance ne coincident pas complètement, oh pas grand chose, mais comme le moteur est réglé à 32 micro-step (donc 6400 pulses par tour de moteur), une toute petite variation de résistance ça fait des micro-steps ! (il faut tout de même que je vérifie un truc : j'ai branché le potentiomètre sur la sortie 5v de l'arduino, qui est tout de même assez sollicité - mon noyau de pilotage moteur fonctionne sous interruption, avec gestion de l'accélération, plus un affichage sur écran LCD, que je virerai une fois tout ça au point, bref je ne suis pas sur que le 5v soit vraiment nickel ... à l'oscillo j'ai vu des petits pulses, donc peut-être qu'en alimentant le potentiomètre séparément par une tension bien stable ??).

Alors oui, il y a toujours la solution du tableau, dès lors que les mesures du potentiomètre sont bien stables ; mais en fait, je n'ai vraiment besoin que de recaler précisément le trim à 0 au démarrage, après je fonctionnerai exactement comme avec une cnc, tout en relatif par rapport au 0 : je n'ai jamais perdu de pas sur ma cnc, ni sur mon tour, donc ça va le faire.

On pourrait objecter que j'aurais pu mettre 2 fins de course plutôt qu'un potentiomètre, c'est vrai, encore une fois c'est vraiment pour des raisons de design mécanique que j'ai choisi le potentiomètre !

Bon, tout ça me prend un peu la tête : c'est du temps réel, et le simple fait de devoir faire des impressions sur le terminal série pour débugguer modifie complètement le comportement du bidule, bref, du classique Arduino et son manque d'outil de debug.

A+, Michel