Asservissement numérique

[invitefb4c2277]

Bonjour à tous,

Je réalise un asservissement de position à l'aide d'un moteur pas à pas piloté par un microcontrôleur.
Je ne suis pas un pro et c'est pour une distraction de retraité.

Comme le moteur est alimenté intelligemment, il ne saute pas de pas et c'est une boucle ouverte.
Actuellement il fonctionne à accélération constante, c'est à dire à vitesse linéaire dans le temps
grâce à une table de montée (et descente) en régime.
Pour satisfaire sans à-coups les petits déplacements, le moteur doit démarrer à vitesse lente et ainsi
il est peu réactif aux grands déplacements.

Je cherche de l'aide pour l'élaboration d'un algorithme permettant un fonctionnement plus souple.

Inutile de me dire que j'aurais du prendre un autre moteur, le matériel existe et fonctionne déjà, je
désire simplement améliorer son fonctionnement.
-----

[PIXEL]

y'a , tout de même, "un truc qui m'interpelle au niveau du vécu" (merci Bretécher)....

l'utilisation d'un PàP est JUSTEMENT faite pour s'abstenir d'un asservissement...
(sauf détection du point de départ)

[iso14000]

+1

il faut juste se démerder pour que le couple reste suffisant et ne pas "riper" des pas ... donc il y a une vitesse limite et une accélération limite aussi..... en général les tables de vitesses répondent à une rampe en trapèze qui permet de rester dans la zone de travail sûre quelque soit la charge

On peut bien sûr ajouter un codeur mézalors un moteur DC ou BLDC aurait suffit....

comprends pas non plus....

[DAUDET78]

le matériel existe et fonctionne déjà,

Tu as le schéma de l'interface de commande du pas à pas ?

[A voir en vidéo sur Futura]

[gienas]

Bonjour H.Cou29 et tout le groupe

Bienvenue sur le forum.

... à vitesse linéaire dans le temps
grâce à une table de montée (et descente) en régime.
Pour satisfaire sans à-coups les petits déplacements, le moteur doit démarrer à vitesse lente ...

Je pense que tu fais allusion à la vitesse start stop, obligatoire pour arrêt précis et démarrage garanti. Si l'accélération et la décélération sont des rampes linéaires, tu peux précalculer (car j'imagine que ton asservissement comporte du calcul simple) la vitesse maximale à atteindre pour pouvoir décélérer et arrêter sans dépassement.

Ceci n'est vrai que pour des "faibles" déplacements.

Au delà de la limite où la pleine vitesse est atteinte, les deux pentes ont une durée maximale, correspondant à un déplacement connu.

C'est un comptage qui peut arrêter le mouvement, mais peut-être aussi une position absolue. Je ne connais pas assez ton hard.

Je me souviens d'avoir déjà fait ça dans ma jeunesse.

[invitefb4c2277]

Merci de vos réponses, voici la suite.

Toutes les 40 ms je reçois une consigne.
La position est donnée par le nombre de pas depuis une origine.

Le moteur est piloté par 2 paramètres binaires: le sens et les impulsions. Il possède dans son alimentation un contrôle de courant qui empêche une perte de pas.

J'ai une table de 500 valeurs pour la montée en régime le numéro 1 correspond à la vitesse la plus faible, le numéro 500 la vitesse la plus grande. Une valeur correspond à un intervalle de temps entre 2 impulsions permettant de passer 1 pas.

A partir de (consigne - position), du numéro et de l'état, le jeu consiste à indiquer si on monte en accélérant, en décélérant, à vitesse constante, la même chose en descendant en sachant qu'il faut 6µs avant de changer le sens à une vitesse minimale.

je reçois la consigne via USB (HID), l'asservissement est réalisé par un pic 18F4550.

Le problème vient du fait que je ne peux changer la valeur de l'accélération qu'à un moment d'arrêt c'est à dire au numéro 0 et qu'elle doit reste constante pendant le cycle montée descente (des numéros).

Mon programme fonctionne mais pour obtenir de la souplesse, il faut qu'à tout instant et pour chaque état, je puisse calculer le delta t suivant cohérent pour le fonctionnement ce qui n'est pas aussi évident qu'en utilisant le numéro.

y-a-t-il encore des amateurs ?

[invitefb4c2277]

Pour préciser la commande d'un pas à pas par un microcontrôleur, tapez sur gogole AVR446, le calcul du délais inter pas est très bien expliqué.
Cependant ce calcul nécessite le numéro n du pas et une accélération constante durant la montée ou la descente.
Un autre calcul permet de s'affranchir du numéro du pas et ainsi de changer d'accélération, c'est cette voie que je voudrais explorer.

[iso14000]

je vois pas où est le problème :
une machine d'état bien écrite permet de résoudre tous les cas....

[luc_1049]

Bonjour

Les moteurs PAP sont utilisées sans asservissement en général en choisissant un moteur puissant qui ne décroche pas soit. Ici le choix est imposé ne revenons pas dessus.
Ce qui m'étonne c'est le système de détection de perte de pas à partir de la donnée courant, ne faudrait il pas en plus une autre info via par exemple un capteur optique qui inclue la mécanique. Autrement dit pour un asservissement précis ne faut il pas un signal qui indique avant le décrochement (trigger sur seuil de consommation du courant) peut être en quelque sorte le glissement du moteur via un capteur optique, pour faire une analogie avec une pll, un signal amont qui averti au plus tôt avec une très bonne sensibilité le glissement du moteur PAP.
Peut être que le contrôle de courant implémenté inclue cette fonctionnalité en récupérant si c'est prècis et faisable une image de la position angulaire du moteur via le courant consommé et la fem induite ?

Qu'en pensez vous ?

cdlt

[invitefb4c2277]

Pour Luc_1049, je me suis vraisemblablement mal exprimé, le moteur est de la marque oriental muni de son alimentation alpha-step dont je ne m'occupe pas si ce n'est le réglage initial du courant (à 50% du max). J'ai une mécanique que j'ai testée et avec laquelle je n'ai pas de perte de pas.
Le problème consiste à lui envoyer une suite d'impulsions pour suivre le mieux possible la consigne en essayant d'avoir un mouvement continu. Si la réponse est trop rapide, une montée à faible pente se retrouve en escalier.

Pour iso_14000, je ne comprend pas ce que tu veux dire qu'est ce qu'une machine d'état.

[iso14000]

à je viens enfin de comprendre....
tu as un ensemble système de commande+PAP et pas un PAP et une carte que tu as fait toi-même...
et tu envois des commandes à ce système qui ne fait pas toujours ce que tu veux...

right?

[invitefb4c2277]

C'est bien cela, il fait exactement ce que lui commande mais ce que je lui commande ne me satisfait pas entièrement.

L'asservissement le plus simple que je réalise est le suivant (au parenthèses près):

est enregistrée une table val[500] calculées pour une accélération donnée

cloc pendant 10µs est la sortie vers l'impulsion
va peut être -1 ou +1 (ou 0 si cloc reste à 0)
pos = pos + va (pos comme position)
ecart = cons - pos (cons comme consigne)

if ( cloc == 0) {if( ecart > 0) {Monte(); numero = 1;}
else {if (ecart < 0) {Descend (); numero = 1;

else { if (va == 1) {if (ecart > num) numero++;
else numero--;}}
else {if ( va == -1) {if (-ecart > num ) numero++;
else numero--;}

if (numero > 499) numero = 499
On charge le timer avec val[numero]
Quand le timer a fini son décompte, une impulsion est lancée et on boucle.

Si la consigne varie doucement et l'accélération importante, la mécanique suit en escalier, et si je réduis trop l'accélération, j'ai du retard pour les grandes variations.

Je cherche une solution pour asservir à accélération variable.

[iso14000]

avant de descendre dans le code... j'aimerais bien avoir les références exactes de ton matériel STP.....

[Qristoff]

On va pas faire un cours, mais..

Je réalise un asservissement de position à l'aide d'un moteur pas à pas piloté par un microcontrôleur.

Si l'accélération et la décélération sont des rampes linéaires

suivant les lois mathématiques, on se retrouve face à deux boucles de régulations imbriquées (sans parler de la boucle vitesse/fréquence de la commande moteur)

Le problème vient du fait que je ne peux changer la valeur de l'accélération qu'à un moment d'arrêt c'est à dire au numéro 0 et qu'elle doit reste constante pendant le cycle montée descente (des numéros).

c'est justement pour éviter de trop compliquer l’imbrication des boucles et rendre le système instable, que l'on fixe une accélération constante..ça devient vite "casse gueule", les boucles "accélération/vitesse".
As-tu une bonne idée des constantes de ton système ?

[invitefb4c2277]

Bonjour,

D'abord le pourquoi du comment:

Je m'autorise à motoriser un simulateur de vol d'hélicoptère,

http://www.webm6.com/op2-sige2.jpg.host

C'est peut être un bien grand mot car dans un premier temps je reproduis uniquement le tangage et le roulis.
On peut assimiler l'ensemble à un pendule de 250Kg suspendu à un fil de 1.5m que l'on fait osciller autour de la verticale.

Détails de la mécanique:

http://www.webm6.com/op2-mecanique2.jpg.host

tout ceci pour voir ça: (c'est la rade de Brest)

http://www.webm6.com/op2-ecrans.jpg.host

Tout fonctionne mais je le trouve trop réactif pour les mouvements lents et il pourrait l'être beaucoup plus pour les mouvements plus rapides.

[Qristoff]

Whaouh ! impressionnant !
Et tu as un calculateur temps réel dédié à la simulation physique ou c'est windows qui gère tout ?

[iso14000]

en effet! , il y a 10 ans je travaillais pour les FTD et on avait aussi 3 écrans pour les IHM c'était tiptop , mais je constate que les amateurs d'aujourd'hui , l'évolution de la technique aidant, sont amenés à faire des réalisations professionnelle.
j'ai la même question que le Qristoff aussi....

et la référence des controleurs pas à pas.??

[invitefb4c2277]

Le logiciel de simulation est FSX mais j'ai vu le même résultat avec X-Plane. En même temps que les images sortent sur l'écran, on peut lui demander toutes les valeurs d'angles, de vitesse et d'accélération.

Pour l'instant je lui demande par USB (HID) le pitch et le roll que je reçois sur un pic 18F4550 avec lequel je fabrique 2 bits:
- sens
- impulsions pour les pas

(plus un troisième: moteur on à la mise en route et qui maintient la position en absence d'impulsions pour les pas).

Windows envoie ses valeurs à peu près toutes les 40 ms, en dessous de cette valeur ça devient aléatoire la charge du processeur se faisant sentir.

Je n'ai pas réussi à faire gérer les 2 moteurs par un seul pic, j'ai donc 1 carte par axe.

l'USB génère une interruption pour la consigne et le timer 0 en génère une autre en priorité pour les impulsions.

J'ai commencé par des essais de de puissance en imposant un mouvement, j'ai de la marge.
j'ai ensuite cherché un Co optimum pour un mouvement sans à-coups et suffisamment réactif.
J'ai remplacé le calcul inter pas par une table qui m'impose de garder la même accélération, un calcul plus complexe nécessiterait sans doute un pic en 16 ou 32 bits.

Je pense qu'on peut faire mieux mais j'arrive un peu à la limite de mes connaissances.
Ce auquel je réfléchi en attendant de trouver une solution parfaitement continue:
- découper les 40 ms en 4 ou 8 parties pour lisser l'arrivée,
- en montant de 1, 2 ou de 4 dans une même table on pourrait avoir des accélérations différentes.
- ....?

[Qristoff]

Merci pour tes réponses complètes (on a trop souvent l'habitude d'avoir des interlocuteurs à qui il faut arracher les vers du nez...)

Windows envoie ses valeurs à peu près toutes les 40 ms

les valeurs de pitch et de roll fournies par l'usb sont en absolues ou incrémentales ? est-ce que tu fonctionnes en boucle ouverte pour la position (c'est ce qu'on fait généralement avec des moteurs PàP) ou as tu un feedback de position pour l'asservissement ? et si tu as un asservissement, de quel type ? PI ?

[invitefb4c2277]

Dans windows la valeur d'un angle est d'abord limitée à 20°:


If realpitch > 40 Then
realpitch = 20
ElseIf realpitch > 15 Then
realpitch = 12 + realpitch / 5
End If

If realpitch < -40 Then
realpitch = -20
ElseIf realpitch < -15 Then
realpitch = -12 + realpitch / 5
End If

puis passée en valeur positive et arrondie:

realpitch = 550*(realpitch + 20)

transformé en 2 octets pour envoi
buffer0 = realpitch
buffer1 = realpitch / 256

Dans le pic on fait l'inverse:

consigne = 11000 - readbuf[1] * 256 - readbuf[0]
on reste en nombre de pas qui varient de -11000 à +11000

la position est issue du décompte des pas sans boucle de retour.

[iso14000]

d'accord je comprends mieux maintenant.

et donc si par exemple ton pitch passe de +10 à -10 (un gros coup de manche) alors que ton moteur allait d'une position de repos à 0 vers +10, il faut qu'il décélère s'arrête puis accélère dans l'autre sens vers -10.... right?

[invitefb4c2277]

Exact avec en plus un temps d'arrêt de 6 µs pour le changement de sens.

[iso14000]

alors si c'est cela ton problème , il n'y a pas grand chose à faire, car si tu veux rester en boucle ouverte (cas d'un usage normal d'un pas à pas) il faut forcément arrêter convenablement le moteur et sa charge .
ensuite si tu veux plus "brutal" il te faut un retour position de ton système ... mais là c'est une autre histoire... et d'autres ennuis / calculs aussi

A++

[Qristoff]

Dans ton µc, il faut implémenter une rampe montante et descendante qui permet de rejoindre la valeur finale de consigne. Cette rampe doit être juste calculée en tenant compte de l'inertie de ton système sans que ton moteur décroche. ça sera beaucoup plus "soft" et réaliste. Faut juste trouver la bonne inclinaison (accélération/décelerration) de rampe ! La rampe peut être aisément réalisée avec un compteur qui cherche à rejoindre la consigne finale en temps donné. Plus besoin de temps mort..

un temps d'arrêt de 6 µs pour le changement de sens

le moteur ne verra rien en 6µs..

[invitefb4c2277]

Le calcul des éléments d'une rampe est trop lourd pour mon µc c'est pourquoi j'en ai une d'enregistrée, il faudrait que je change de µc.
Je vais quand même regarder cette piste.

[Qristoff]

Le calcul des éléments d'une rampe est trop lourd pour mon µc

c'est pas du calcul mais juste un compteur/décompteur qui monte et qui descend la vitesse (toujours à la même cadence d'horloge !) suivant la valeur à atteindre.

[invitefb4c2277]

Peux-tu préciser l'organigramme car avec un pap la vitesse monte et descend selon un train d'impulsions.

[Qristoff]

Peux-tu préciser l'organigramme car avec un pap la vitesse monte et descend selon un train d'impulsions.

C'est pas un train d'impulsions, la vitesse de rotation moteur dépend du temps pour passer à la combinaison de phase suivante. A basse vitesse, ce temps est relativement long et tu le réduis pour augmenter la vitesse. Donc, dans ton µc tu as bien quelque part un registre contenant cette valeur de temps, inversement proportionnelle à la vitesse attendue.
Donc, en partant de la valeur max (qui correspond à la vitesse mini de démarrage), tu peux faire converger cette valeur de temps vers une valeur qui serait l'image de ta vitesse désirée. La vitesse de convergence devient dans ce cas ton accélération qui peut être modifiable en cours de route.
Prenons comme exemple:
- un moteur PàP unipolaire 4 fils avec 4 steps/tour (simplifions au max)
- un registre 8 bits pour la vitesse avec une vitesse max de 4000 tr/min, soit 418 rad/s, soit 3,75ms pour passer d'un step au suivant.
- en prenant ton Lsb registre 3,75ms/2=1,875ms, cela une vitesse de démarrage mini à FF de 255*1,875ms=478ms (*4step=1,9tr/s)

1/ tu parts donc de FF et ta vitesse objectif est de 2000 tr/min, soit 7,5ms entre chaque step.
2/ si tu décrémentes ton compteur d'un Lsb toute les 10ms, tu atteindras la valeur voulue en (478-3,75)/1,875=253*10ms=2530ms (un peu lent !)

• première solution: tu décrémentes ton compteur plus vite (par exemple 1ms), tu atteindras la valeur voulue en (478-3,75)/1,875=253*1ms=253ms. C'est mieux !
• deuxième solution: tu décrémentes à la même vitesse mais de plusieurs lsb (3 par exemple; tu atteindras la valeur voulue en (478-3,75)/5,625=84*10ms=840ms, c'est mieux que les 2,53s de (2)

Tu vois que tu peux jouer sur les deux tableaux !

[Qristoff]

Le problème dans cet algorithme, c'est que l'accélération n'est pas linéaire et que la vitesse augmente trés fort lorsque le compteur atteint des petites valeurs. Il faut pour cela procéder par dichotomie qui améliore un peu le résultat ou utiliser la formule de Torricelli si ton µc a un peu de ressource.

[invitefb4c2277]

Bonjour Qristoff,

J'ai effectivement une table de valeurs mais qui correspond, aux temps inter step (via un timer) pour une mise en rotation à accélération constate. Une augmentation de vitesse se fait par incrémentation.
Je pourrais aussi incrémenter par 2 ou 3 tant que la puissance du moteur est compatible, j'y pense et ce que tu me dis me conforte dans cette voie.