Résolution exprimée des encodeurs (pour PID)

Echangez ici sur vos idées ou vos problèmes concernant vos circuits électroniques et électriques.
Discuss here the problems concerning your electronic and electrical circuits.
Post Reply
mightywarrior
Posts: 239
Joined: Sat 28 Oct 2006, 22:44

Résolution exprimée des encodeurs (pour PID)

Post by mightywarrior » Wed 16 Jul 2014, 13:14

Bonjour,

A la recherche d'encodeurs incrémental en quadrature pour réaliser un robot régulé par PID, je rencontre un souci par rapport à la résolution tel qu'elle est exprimée sur les datasheet ou sites de ventes.

En effet le nombre indiqué, par exemple 360 pour cet encodeur dont le datasheet est ici, représente t' il le nombre d'impulsions par révolution pour un canal ou est-ce le total des impulsions des deux canaux (c'est à dire 4 fois le nombre d'impulsions d'un canal) ?

Merci.

mightywarrior
Posts: 239
Joined: Sat 28 Oct 2006, 22:44

Re: Résolution exprimée des encodeurs (pour PID)

Post by mightywarrior » Fri 18 Jul 2014, 13:04

Bonjour,

Je vois que ma question n'inspire pas grand monde :roll: ...

Prenons les choses autrement :
-Si le codeur produit 360 impulsions par canal par révolution, est-ce suffisant pour réaliser un asservissement PID correcte* ?
-Au contraire, si le codeur produit 90 impulsions par canal par révolution, est-ce suffisant pour réaliser un asservissement PID correcte ?
Ça m'aiderais grandement d'avoir des précisions là dessus bien que ça ne réponde pas directement à ma question initiale. :)

* Je ne cherche pas la performance ultime mais quelque chose qui marche bien.

EDIT: J'oubliais de préciser : les codeurs seront couplé à l'axe moteur et pas en sortie du moto-réducteur.

Merci à vous !

Keuronde
PMI
Posts: 500
Joined: Mon 25 Jan 2010, 22:48

Re: Résolution exprimée des encodeurs (pour PID)

Post by Keuronde » Fri 18 Jul 2014, 14:18

De ce que j'en comprends, c'est qu'une impulsion c'est un temps haut suivi d'un temps bas.
Tu aurais 360 impulsions par voie, d'où une capacité de 1440 signaux par tour.

Concernant ton PID, tu as besoin d'un peu plus d'informations pour savoir si le capteur convient.

Je suppose que tu veux un asservissement en vitesse.
Si tu veux un peu de précision, il te faut, à ta vitesse la plus basse commandable, au moins une dizaine impulsions par période d'acquisition. (disons qu'en dessous de 6 impulsions tu as quelque chose de très approximatif !).

Il te faut donc :
  • Le rayon de tes roues
  • Le rapport de réduction de ton réducteur
  • Ta période d'acquisition (1 ms ?)
  • Ta vitesse lente (de 10 à 20 cm/s ?)
Équipe Poivron
Coupe 2014 : Équipe Poivron (67e)
Coupe 2012 : Équipe Poivron (73e)
Coupe 2011 : Équipe Poivron (122e) - Prix des équipes !
Coupe 2010 : Équipe Poivron (78e)


Passez voir le Portail des équipes

mightywarrior
Posts: 239
Joined: Sat 28 Oct 2006, 22:44

Re: Résolution exprimée des encodeurs (pour PID)

Post by mightywarrior » Fri 18 Jul 2014, 18:09

De ce que j'en comprends, c'est qu'une impulsion c'est un temps haut suivi d'un temps bas.
Tu aurais 360 impulsions par voie, d'où une capacité de 1440 signaux par tour.
Oui c'est ce que je me disais aussi mais je tenais à venir demander ici afin d'en être certain. En effet pour la petite histoire, avant d'opter pour ces codeurs, j'avais dans l'idée d'acheter un couple de ces moto-réducteurs emg30 avec encodeurs (+ roues et support moteurs qui vont avec). Sauf que voilà, en cherchant bien j'ai trouvé sur un post d'un autre forum qu'en réalité les 360 impulsions annoncés en sortie de réducteur correspondaient à la somme des deux canaux après réduction:
Sensor halls outputs are quadrature, open collector, 3 pulses each per motor shaft
revolution.

Pour le reste je suis entièrement d'accord avec toi. Effectivement c'est pour un asservissement en vitesse.

Infos supplémentaire:
-Moto-réducteur :950D501 avec une vitesse de sortie de 252tr/min à 12v et un rapport de 50:1
-Roues : 8cm de diamètre
-Période d'acquisition : c-a-d ? Combien de fois par seconde je compte lire les encodeurs ? J'avoue ne pas savoir du tout. Tout ce que je sais c'est que je compte utiliser un PIC18F452 cadencé à 20 ou 40Mhz et entièrement dédié à la régulation PID.
-Vitesse lente : 10cm/s semble pas mal du tout pour le néophyte que je suis en matière de PID.

mightywarrior
Posts: 239
Joined: Sat 28 Oct 2006, 22:44

Re: Résolution exprimée des encodeurs (pour PID)

Post by mightywarrior » Mon 28 Jul 2014, 14:33

Bonjour,

J'ai fini par commander les encodeurs (et tout le nécessaire pour fabriquer un robot de test pour l'asservissement en vitesse) et je confirme qu'ils donnent bien 360 impulsions/tour par canal.

J'ai donc commencé par faire simple en asservissant un seul moteur en vitesse ce qui m'a déjà permis de progresser sur la compréhension du pid en lui même.

J'ai toutefois une question théorique qui me chiffonne et pour laquelle je n'ai pas trouver de réponses sur internet :
Pour un robot différentiel on a 2 moteurs ce qui veux dire qu'il faut donc 2 asservissements pid. Du coup il faut un triplet de coeff Kp, Ki et Kd par pid du coup, si mon raisonnement est juste, on a deux régulations indépendante et de coeff différents, alors comment le robot peut il rouler droit de cette manière ?

Merci!

Keuronde
PMI
Posts: 500
Joined: Mon 25 Jan 2010, 22:48

Re: Résolution exprimée des encodeurs (pour PID)

Post by Keuronde » Mon 28 Jul 2014, 22:15

mightywarrior wrote:Pour un robot différentiel on a 2 moteurs ce qui veux dire qu'il faut donc 2 asservissements pid.
La, je suis d'accord !
mightywarrior wrote:Du coup il faut un triplet de coeff Kp, Ki et Kd par pid du coup, si mon raisonnement est juste, on a deux régulations indépendante et de coeff différents
D'un point de vue asservissement, (peut-être que d'autre me contrediront), je pense que tu peux prendre les mêmes coefficients pour tes deux moteurs, ça devrait être suffisant.
mightywarrior wrote:alors comment le robot peut il rouler droit de cette manière ?
A moins d'utiliser des sciences occultes (ou peut-être un filtre de Kalman), tu ne feras pas rouler un robot droit juste avec une boucle d'asservissement en vitesse.

Grâce à tes codeurs tu sais de combien ont tourné tes roues gauche et droite. Tu peux donc estimer ta position par rapport à ton point de départ, ta position et ton orientation. Tu peux déterminer ton erreur de position et d'orientation et calculer, grâce à une boucle supplémentaire d'asservissement, tes consignes de vitesse de tes moteurs gauche et droite.

Tu as ici mon architecture pour mon robot. Le gyroscope me servait à estimer l'orientation du robot, mais on peut aussi faire ça avec les codeurs.

Image

Tu trouveras des détails sur l'asservissement polaire sur le site de RCVA
Équipe Poivron
Coupe 2014 : Équipe Poivron (67e)
Coupe 2012 : Équipe Poivron (73e)
Coupe 2011 : Équipe Poivron (122e) - Prix des équipes !
Coupe 2010 : Équipe Poivron (78e)


Passez voir le Portail des équipes

mightywarrior
Posts: 239
Joined: Sat 28 Oct 2006, 22:44

Re: Résolution exprimée des encodeurs (pour PID)

Post by mightywarrior » Tue 29 Jul 2014, 11:26

Tout d'abord, merci d'avoir pris du temps pour me répondre.

Vous me dites donc qu'un robot asservi en vitesse ne peut pas rouler droit et que, pour ce faire, je devrais utiliser un asservissement polaire ou au moins, comme le suggère la page de l'équipe RCVA, deux asservissement en position ?

Je prends bonne note de tout ça. Je vais donc recommencer à zéro en tentant d'asservir un seul moteur en position, puis les deux puis modifier le tout en asservissement polaire.

Il me reste une question au sujet de votre schéma: En plus d'une cellule "asservissement polaire" il y a une cellule "asservissement moteur", qu'est-ce donc?

Keuronde
PMI
Posts: 500
Joined: Mon 25 Jan 2010, 22:48

Re: Résolution exprimée des encodeurs (pour PID)

Post by Keuronde » Tue 29 Jul 2014, 15:26

Nul besoin de tout recommencer !!

Tu as besoin d'avoir un asservissement en vitesse pour chaque moteur !

L'asservissement polaire (ou les autres) se situent au dessus : la sortie de l'asservissement polaire ne va pas alimenter directement les moteurs, elle va alimenter les asservissements en vitesse que tu mets au point.

Sur mon robot, j'ai un asservissement polaire (un PI sur la distance, un PI sur l'orientation). Ça me donne une consigne en vitesse pour chaque moteur qui va nourrir l'asservissement en vitesse du moteur.
Équipe Poivron
Coupe 2014 : Équipe Poivron (67e)
Coupe 2012 : Équipe Poivron (73e)
Coupe 2011 : Équipe Poivron (122e) - Prix des équipes !
Coupe 2010 : Équipe Poivron (78e)


Passez voir le Portail des équipes

mightywarrior
Posts: 239
Joined: Sat 28 Oct 2006, 22:44

Re: Résolution exprimée des encodeurs (pour PID)

Post by mightywarrior » Tue 29 Jul 2014, 18:25

D'accord, je vois mieux l'ampleur du travail qui m'attend :)

Merci pour ces précisions.

Dernière question, dans le cas d'un asservissement en vitesse d'un moteur, je donne une vitesse comme consigne mais dans le cas d'un asservissement en position d'un moteur, la consigne c'est quoi exactement ? un nombre de tick ?

Keuronde
PMI
Posts: 500
Joined: Mon 25 Jan 2010, 22:48

Re: Résolution exprimée des encodeurs (pour PID)

Post by Keuronde » Tue 29 Jul 2014, 19:44

Dans un asservissement en vitesse, la consigne est une vitesse,
Dans un asservissement en position, la consigne est une position !

:D Yeah ! :D

Pour l'asservissement polaire, tu as deux consignes, une consigne en distance (la distance en ton robot et ton point consigne), et une orientation (celle nécessaire pour atteindre ton point consigne).

Après, au niveau des unités, tu fais un peu ce que tu veux. Ici, tu n'a qu'un seul type de capteur, tu peux tout exprimer en tick de codeur. C'est plus simple !
Mais ce n'est pas forcément une bonne idée ! Dans certains cas, tu as une roue un peu plus petite que l'autre. Convertir tes Tick en mm, permet notamment de tenir compte du rayon de tes roues.

De mon coté, j'utilisais le mètre (ou le millimètre) comme unité de distance et le radian comme unité d'angle. Avoir des angles en radian permet d'utiliser facilement les fonctions trigonométrique !
Équipe Poivron
Coupe 2014 : Équipe Poivron (67e)
Coupe 2012 : Équipe Poivron (73e)
Coupe 2011 : Équipe Poivron (122e) - Prix des équipes !
Coupe 2010 : Équipe Poivron (78e)


Passez voir le Portail des équipes

mightywarrior
Posts: 239
Joined: Sat 28 Oct 2006, 22:44

Re: Résolution exprimée des encodeurs (pour PID)

Post by mightywarrior » Sun 10 Aug 2014, 21:44

Bonjour,

Après avoir monté le châssis et ma carte d'asservissement me revoilà !
Tu as besoin d'avoir un asservissement en vitesse pour chaque moteur !

L'asservissement polaire (ou les autres) se situent au dessus : la sortie de l'asservissement polaire ne va pas alimenter directement les moteurs, elle va alimenter les asservissements en vitesse que tu mets au point.

Sur mon robot, j'ai un asservissement polaire (un PI sur la distance, un PI sur l'orientation). Ça me donne une consigne en vitesse pour chaque moteur qui va nourrir l'asservissement en vitesse du moteur.
J'ai traduit ta remarque par un schéma (pour être certain que je me plante pas et qu'on est bien sur la même longueur d'onde :) ) donc c'est bien un truc dans ce genre qui serait à programmer ? :
Image

J'ai dû changer de microcontrôleur pour gérer cet ensemble d'asservissements, J'utilise un ATmega328P à 20Mhz. Comme je n'ai pas encore de recul en la matière, j'aimerais savoir si vous pensez qu'il serait en mesure de gérer tout ça ou il faut plutôt se tourner vers une bête de course ?

Merci !

arno
PMI
Posts: 686
Joined: Wed 23 Jun 2004, 21:51
Location: Un peu partout...

Re: Résolution exprimée des encodeurs (pour PID)

Post by arno » Mon 11 Aug 2014, 20:51

mightywarrior wrote: donc c'est bien un truc dans ce genre qui serait à programmer ?
Ca parait pas mal dans le principe. Je suis pas sur à 100% des signes, mais ça me parait bon.

Par contre, je pense qu'il manque un truc sur le retour des codeurs.
En général, l'info retournée par les codeurs passe par un bloc le transformant en position absolue sur la table (donc [CodeuseD, CodeuseG] => [X, Y, Cap]), suivi par un bloc qui calcule la différence entre cette position courante et la position demandée, pour sortir la consigne de distance/cap qui rentre dans les PID.

Tel que je comprends ton schéma (ça fait un moment que j'ai pas utilisé de moteurs courant continu sur des robots, avec les pas à pas on perds l'habitude de la double asserv...), tu obtients la distance parcourue le long de ta trajectoire (la distance curviligne) et un truc proche d'une différence de cap entre arrivée et départ (pas exactement). Hors, la distance curviligne n'est pas ce exactement ce que tu cherches à controller. Toi, ce qui t'intéresse c'est la distance restante a ta cible. Si tu part avec une différence de cap importante avec le point que tu vises, ta trajectoire va être plus proche d'une portion d'ellipse que d'une droite, et donc la distance parcourue sera supérieure à la distance à vol d'oiseau donné comme ordre avant le mouvement.
Dis autrement, il existe une infinité de trajectoires courbes ayant une longueur curviligne donnée et un cap d'arrivé donné. Tu dois donc te ramener à la position réelle sur la table (à travers le calcul de la position [X, Y, Cap] du robot) pour ajuster les consignes en fonction de ta position réelle et de ta cible.

J'attends une confirmation des autres membres, car n'ayant jamais attaqué le problème de cette façon (on a toujours commencer par le calcul de la position absolue avant de regarder comment asservir...) je peux me tromper et rater un truc.


Sinon, il y a aussi en général des blocs de saturation, pour éviter d'envoyer les PID en orbite : que tu sois à 1m ou 3m de ta cible tu ne pourras pas pour autant accelerer 3 fois plus vite, donc ca charge les intégrateurs et ça risque de créer des oscillations pour le décharger, ça crée aussi des dérivées énormes. Brider les entrées des PID permet de limiter ce phénomène (par exemple, quelque soit la distance au point, on bride à 50cm maxi l'erreur donnée en entrée du PID, a toi de voir si c'est nécessaire, et quels limites lui donner). L'idée derrière ça est que tu ne t'attends pas a ce qu'une commande différente soit donné aux roues lors du décollage que le point visé soit moyennement loin ou très loin (tu ne décolle pas plus vite en voiture si tu dois faire 200 bornes que si tu en fait juste 2). Si c'est proche alors c'est normal que ca parte moins vite par contre.
Tu peux aussi faire ce bridage directement au niveau de l'intégrateur du PID, et filtrer les dérivées pour limiter l'influence des transitoires comme le changement de cible. Mais bon, l'impact de ce genre de techniques est surtout présent lorsque tu commenceras à envoyer la purée, sur des réglages doux ça doit marcher sans, même si ça reste une bonne pratique.

J'espère que ce pavé est à peu près compréhensible, sinon n'hésites pas à me demander d'expliciter ce qui n'est pas clair.

Keuronde
PMI
Posts: 500
Joined: Mon 25 Jan 2010, 22:48

Re: Résolution exprimée des encodeurs (pour PID)

Post by Keuronde » Tue 12 Aug 2014, 10:59

Concernant ton schéma d'asservissement
Au niveau de l'asservissement des moteurs, ça me parait bon.
Au niveau de l'asservissement polaire, ça parait presque bon.
Comme le dit arno, je pense qu'il faut que tu rajoutes un étage pour déterminer ta position à partir du retour de tes codeurs.
Un fois que tu as ta position, tu peux calculer ton erreur d'orientation et de distance pour l'envoyer à l'asservissement polaire.
Tu fixes un point but, ton erreur de distance est la distance entre ton robot et ton point but. Ton orientation but est la direction que doit avoir ton robot pour se retrouver face à ton point but.

Concernant la saturation de tes PI
C'est un point souvent négligé, mais vital pour avoir un asservissement qui tient la route.
Légende :
Cmax :commande maximale
C_P : commande proportionnelle
C_I : commande intégrale

Si C_P + C_I > Cmax
=> C_I = Cmax - C_P

Petite amélioration
Tu peux rajouter un code pour brider tes variations de consigne. Je le mets au niveau de l'asservissement polaire et je supprime l'intégrateur de l'asservissement polaire car le couple intégrateur + limitation de variation semble instable. Mais c'est quelque chose à mettre après que tu aies fait fonctionner le reste.
Équipe Poivron
Coupe 2014 : Équipe Poivron (67e)
Coupe 2012 : Équipe Poivron (73e)
Coupe 2011 : Équipe Poivron (122e) - Prix des équipes !
Coupe 2010 : Équipe Poivron (78e)


Passez voir le Portail des équipes

mightywarrior
Posts: 239
Joined: Sat 28 Oct 2006, 22:44

Re: Résolution exprimée des encodeurs (pour PID)

Post by mightywarrior » Wed 13 Aug 2014, 17:42

Merci pour vos réponses !

J'avoue que celle de Arno échappe totalement à ma compréhension :roll:

Sachant que ce qui m'intéresse c'est "simplement" que mon robot roule droit en ligne droite ce système, de mon point de vue de néophyte, semble un poil sur-dimensionné... il n'y a pas plus simple ?

arno
PMI
Posts: 686
Joined: Wed 23 Jun 2004, 21:51
Location: Un peu partout...

Re: Résolution exprimée des encodeurs (pour PID)

Post by arno » Wed 13 Aug 2014, 23:54

mightywarrior wrote:Sachant que ce qui m'intéresse c'est "simplement" que mon robot roule droit en ligne droite ce système, de mon point de vue de néophyte, semble un poil sur-dimensionné... il n'y a pas plus simple ?
Mettre les 2 roues sur le même arbre ? :lol:

L'autre solution reste de partir du principe que si tu régules tes 2 roues à la même vitesse tu iras à peu prêt droit et que c'est suffisant. C'est facile avec des moteurs pas à pas, un peu moins direct avec des moteurs à courant continu.
Tu peux alors découper tes mouvements en deux étapes : tourner sur place vers le point que tu vises (donc les 2 roues à la même vitesse mais de sens inversés), puis avancer tout droit (les 2 roues à la même vitesse et dans le même sens).
Selon ton système, ça sera plus ou moins bon, d'où le besoin rapidement d'ajouter une correction en prenant en compte l'angle réel du robot par rapport à l'angle idéal entre ton point de départ et d'arrivée (donc une constante).
Et le niveau suivant est de corriger non pas avec l'angle idéal de ta trajectoire, mais avec l'angle entre ta position courante (et non plus de départ) et ton point d'arrivée. Ca y est tu as un asservissement polaire !
mightywarrior wrote:J'avoue que celle de Arno échappe totalement à ma compréhension :roll:
Aie... c'est pas evident à expliquer et j'utilise pas toujours les bons mots pour illustrer un schéma que j'ai en tête. Je vais essayer de faire plus simple.

L'idée est que tu as plusieurs repères dans ton système, et qu'il faut que chaque niveau d'asservissement soit fait dans le bon repère, d'où le besoin de certains changement de repères par endroit.

La boucle d'asservissement polaire doit être faite dans le repère associé à la table. Dans ce repère, ton robot à 2 coordonnées correspondant à sa position sur la table, que j'appelle x et y. Par exemple, x peut être la distance entre le bord de la table et le robot suivant la largeur de la table et y la distance entre le bord de la table suivant la longueur de la table.
Et une 3eme coordonnée correspond à l'angle vers lequel pointe l'avant de ton robot dans ce plan, ce que j'appelle le cap. Imagine une carte avec latitude, longitude et le cap donnée par ta boussole.

Pour en revenir à ton asservissement polaire, l'idée est que ta consigne d'angle est la différence entre le cap du robot et le cap qu'il faudrait pour viser ta cible. De même la consigne de distance est la distance entre les coordonnées du robot et les coordonnées de l'arrivée.

Tout ça nécessite de calculer la position de ton robot dans ce repère. Le problème avec ton schéma courant est que tu as pris comme consigne de vitesse/d'angle le retour des codeurs directement.
Il te manque un petit bloc pour faire le changement de repere et avoir la position du robot, pas seulement l'angle des codeurs.

Pour calculer la position du robot à partir des codeurs :
A chaque pas de temps, il te faut regarder combien à parcouru chaque roue. La moyenne des 2 déplacements te donne la distance linéaire parcourue. La différence entre les 2 te donne l'angle parcouru (avec un coeff dépendant de l'entraxe entre les deux roues codeuses).

Si on appelle "delta1" et "delta2" le nombre de pas de codeurs parcourues par les roues gauches et droites pendant un pas de temps, on peux calculer "d" la distance et "alpha" l'angle parcouru pendant ce pas de temps. Ca nous donne à peu près cette formule :
// d est ici en m. Selon comment tu fais tes calculs (entiers/flottants) tu peux ajuster cette unité pour avoir le max de précision (on travaille en nanomètres chez nous...)
d=(delta1+delta2)/2 * COEFF_M_PAR_PAS
// alpha est ici en radians (même remarque que ci-dessus pour l'unité)
alpha=(delta1-delta2) * COEFF_M_PAR_PAS / ENTRAXE_ROUES_CODEUSES_EN_M
Remarque : "delta1" et le nombre de pas comptés pendant un pas de temps de ton échantillonage, donc on repart de 0 à chaque pas de temps. Si tu travailles avec le total des pas, alors c'est la différence entre la position de la roue codeuse actuelle et celle au pas de précédent : delta1=codeur1(t)-codeur1(t-1)

Jusque là, c'est proche de ce que tu as sur ton schéma. Sauf que c'est une approximation valide seulement pendant un pas de temps !
Ensuite, il faut donc que tu ajoutes ce resultat à la position précédente du robot. Le piège c'est que la distance parcourue est ajouté dans la direction donnée par le cap du robot.
x(t) = x(t-1) + d*cos(cap(t))
y(t) = y(t-1) + d*sin(cap(t))
cap(t) = x(t-1) + alpha
Grace à ça tu connais maintenant ta position du robot dans le repère de la table. Ton point d'arrivée (disont "A"), étant aussi exprimé dans ce repère (coordonnées [Ax,Ay]) tu peux facilement retrouver tes distance et angle de consigne (donc la partie "asservissement polaire") :
consigne_distance(t) = racine_carrée( (Ax - x(t) )^2 + (Ay - y(t) )^2 ) // d'après Pythagore
consigne_angle(t) = arctan(Ay - y(t), Ax - x(t))
Je n'ai pas pris le temps de tout poser sur une feuille, c'est juste de tête, donc les signes des angles sont peut être inversés (dans l'arctan, ou les sin/cos du dessus), mais le principe est là. Je peux aussi avoir raté un coeff quelque part. Je pense que le principe énoncé reste juste, n'hésites pas à poser ces formules sur un dessin pour vérifier que ça colle. Et pour les autres, n'hésitez pas non plus à me corriger si vous voyez une boulette (il est tard...).

Ce n'est pas insurmontable à ajouter, et l'avantage c'est que tu peux découper tout ça en plusieurs bloc indépendants, validables séparément :
* L'asservissement de vitesse d'un moteur seul demande simplement une consigne constante et le retour d'une seule roue codeuse. Si tu affiche la vitesse mesurée par la roue codeuse, tu peux vérifier que ça suit bien ta consigne.
* La partie qui te donne la position du robot dans le repere de la table est facile à tester même sans que l'asservissement fonctionne : comme seule l'info des roues codeuses rentre dedans tu peux faire bouger le robot à la main pour vérifier que ça marche (le faire tourner de 90°, faire un ou plusieurs tours complets, avancer en ligne droite de 10 cm, revenir en arrière de 10 cm, faire un carré,...). C'est comme ça qu'on le règle chez nous.
Une fois que cette partie est correcte
* Lorsque tu as un asservissement en vitesse qui marche, et une position correcte, tu peux fermer la boucle entre les deux en ajoutant la partie qui calcule les consignes de vitesse en fonction de ta position.
* Tu pourras alors essayer de regler le système de plus en plus rapide, ce qui fera surement faire apparaitre à un moment le besoin de petits ajustement comme les blocs de saturation des intégrateurs (tu verras des oscillations, voir instabilités sinon)

J'espère que c'est mieux présenté, sinon dis moi où ça bloque, et je tenterais de faire un schéma pour illustrer tout ça.

Post Reply