Aller au contenu


Photo

Modification d'un (micro) servo pour robot à pattes


  • Veuillez vous connecter pour répondre
194 réponses à ce sujet

#61 Oracid

Oracid

    Pilier du forum

  • Modérateur
  • PipPipPipPipPip
  • 6 768 messages
  • Gender:Male

Posté 22 novembre 2020 - 12:18

Oui, ça fait rêver !

Mais permets moi d'insister, le pignon de sortie du servo comporte un certain nombre de dents. Quand tu positionnes le palonnier, à une dent près, tu peux avoir un écart important entre la position souhaitée et la position réelle du palonnier. Comment corriger cet écart ?

Par exemple, tu veux positionner ton servo au neutre (90°). Malheureusement, lorsque tu positionnes le palonnier, il faut beaucoup de chance pour qu'il soit vraiment à 90°.

Du coup, on est obligé de corriger cet écart dans son programme, mais cela diminue d'autant le débattement du servo.

Si ton servo à un débattement de 180° et que ta correction est de 5°, alors le débattement possible du servo ne sera plus plus que de 175°.

Bien sûr, on peut donner une valeur négative ou supérieure à 180°, au servo, mais je ne suis pas certain que son électronique apprécie.

Suis-je clair ?



#62 pat92fr

pat92fr

    Membre chevronné

  • Membres
  • PipPipPipPip
  • 673 messages
  • Gender:Male

Posté 22 novembre 2020 - 01:08

C'est très clair !

 

Effectivement, si le servo a un débattement maximum de 180° et si le palonnier est monté avec un angle de 5° par rapport à la position médiane du servo (à cause du faible nombre de dents du pignon de sortie) , tu obtiens une course asymétrique de 85° dans un sens et 95° dans l'autre. Malheureusement, le logiciel et l'asservissement ne peuvent rien contre ces limites physiques. Tu ne peux que compenser les 5° en réglant ton neutre dans le logiciel. Si cela pose un vrai problème, et si tu as besoin de +/-90° de débattement, il faut choisir un servo avec un plus grand débattement (exemple : 270° ou  300°).

 

En revanche, la position du servo peut etre asservie avec une précision qui ne dépend que de la mesure de sa position. Celle-ci dépend, de la qualité du potentiomètre (ou encodeur pour les servo haut de gamme) interne au servo, de la résolution de l'ADC de la carte de contrôle, de la qualité de fabrication de la carte de contrôle (intégrité des signaux faibles), et de la capacité à filtrer le signal (cause parasites venant du moteur). Dans la limite du débattement, la position souhaitée peut toujours être atteinte avec précision qui peut être inférieure à 1°.

 

En outre, il faut éviter les positions extrêmes du palonnier (ex. : +90° ou -90° pour un servo avec un débattement 180°). Si le servo tape sur sa propre butée mécanique, cela peut endommager les pignons de son réducteur. Pour obtenir la flexibilité autour de la consigne de position dont je parlais, il faut avoir de la marge en débattement. Pour un servo avec un débattement de 180°, il doit être possible de limiter la plage de fonctionnement à -60° et +60° en logiciel (par exemple). Ainsi, en cas d'effort sur le palonnier, le servo pourra relâcher légèrement sa position par rapport à la consigne de +/-30° (exemple), sans risquer de taper sur ses butées mécaniques.

 

Tu peux certainement me confirmer que pour un robot marcheur (4 ou 5 barres, ou en série), un débattement de 120°, avec possibilité d'extension jusqu'à 180° ('compliance') permet de couvrir pas mal de cas d'emploi.

 

Patrick.



#63 pat92fr

pat92fr

    Membre chevronné

  • Membres
  • PipPipPipPip
  • 673 messages
  • Gender:Male

Posté 22 novembre 2020 - 01:40

Avant d’attaquer les asservissements, petite synthèse du contrôle du moteur.
 
Contrôle du moteur :
 
La carte électronique met en œuvre un driver moteur Ti DRV8872, qui intègre un pont en H à base de MOSFET.
 
La conception de la carte de contrôle suit le schéma de principe de Ti :
 
CaptureDRV9972-2.PNG
 
Le DRV8872 est directement alimenté (VM) par la batterie Lipo 2S de 8.4V.
Le ‘Controller’ est un STM32G4 (ARM32bits Cortex M4 @ 150MHz).
Un petit régulateur LDO de 100mA sur la carte permet de produire localement le 3v3 à partir de la tension batterie.
 
CaptureDRV9972detail.PNG
 

Le pont en H permet d’entrainer le moteur dans un sens ou dans l’autre, avec une seule tension alimentation.

 

CaptureDRV9972-H.PNG

 

- Pour stopper le moteur, 3v3 sur IN1 et IN2. C’est le pilotage par défaut au démarrage de la carte.

- Pour tourner dans un sens, le STM32G4 pilote en PWM le signal IN1 et laisse à la masse le signal IN2.

- Pour tourner dans l’autre sens, masse sur IN1, PWM sur IN2.

 

J’ai fait le choix d’être en roue libre (‘coast’) entre deux impulsions PWM. J’ai pensé que cela permettrait d’atteindre la vitesse maximale du servo en rotation.

 

Le rapport cyclique du PWM permet de contrôler le courant dans le moteur. Plus le rapport cyclique est élevé et plus le courant moyen dans le moteur sera intense. 

Les signaux PWM sont générés par un TIMER dans le STM32G4.

La fréquence du PWM est de 20KHz pour rendre inaudible le courant passant dans les bobines du moteur.

 

J’ai choisi une résolution de 1% pour le rapport cyclique. Cela peut paraitre faible.

En fait, je constate qu'il faut minimum 25% de rapport cyclique pour que le palonnier du servo commence à tourner à vide.

Je pense que c'est la cadence d'ajustement du PWM plutôt que la précision de chaque impulsion PWM qui fera la différence. A voir.

 

A suivre.

 



#64 Oracid

Oracid

    Pilier du forum

  • Modérateur
  • PipPipPipPipPip
  • 6 768 messages
  • Gender:Male

Posté 22 novembre 2020 - 02:34

Tu as très bien compris ce que je voulais dire et tes explications sont très claires. Il y aurait peut-être une solution mécanique avec un palonnier légèrement orientable après son positionnement, mais cela devrait être couteux en volume.

 

Tu peux certainement me confirmer que pour un robot marcheur (4 ou 5 barres, ou en série), un débattement de 120°, avec possibilité d'extension jusqu'à 180° ('compliance') permet de couvrir pas mal de cas d'emploi.

Dans mes quadrupèdes, les servos sont positionnés avec un débattement  de 0° à 180°, horizontal. Même si depuis quelques temps, mécaniquement, les fémurs peuvent décrire un V, je n'utilise pas cette possibilité.

Pour chaque 4 barres, je filtre, je limite, la course de 0° à 140° pour le servo gauche et de 40° à 180° pour le servo droit.

Je positionne le palonnier pour une erreur positive pour le servo gauche et une erreur négative pour le servo droit. Ainsi, l'erreur s'ajoute dans la zone interdite.



#65 pat92fr

pat92fr

    Membre chevronné

  • Membres
  • PipPipPipPip
  • 673 messages
  • Gender:Male

Posté 22 novembre 2020 - 02:41

Ok, parfait.

 

Une idée : Et si tu collais le palonnier sur la première barre (liftarm) avec un angle pour compenser le faible nombre de dents du pignon de sortie.

 

Ou alors, imprimer en 3D une pièce pour remplacer la première barre, dans laquelle se fixe le palonnier, toujours avec cet angle de compensation.

 

Patrick.



#66 pat92fr

pat92fr

    Membre chevronné

  • Membres
  • PipPipPipPip
  • 673 messages
  • Gender:Male

Posté 22 novembre 2020 - 02:50

Limiteur de courant :
 
Le driver moteur DRV8872 intègre un limiteur de courant.
 
Le courant maximum admissible par ce composant est de 3.6A. Une alarme est déclenchée (Fault : Overcurrent Event) en cas de courant supérieur à cette limite. Cette alarme est capturée par le STM32G4.
 
Il est possible d’abaisser cette limite, en jouant sur la valeur de la résistance de shunt (Rsense) raccordée à la broche ISEN du driver.
Cette résistance se trouve en série avec le moteur. Lorsque que le courant dépasse la limite, le driver fait du ‘chopping’.
C'est  à dire qi'il réduit automatiquement la largeur des impulsions PWM (par hachage) pour stabiliser le courant moteur en dessous de la limite.
 
Tout est expliqué dans le datasheet. J’ai donc utilisé une résistance de 330 mOhms pour limiter le courant à environ 1A dans le moteur du micro-servo.
Pour un servo standard, je devrai certainement prendre une valeur plus petite pour permettre un courant plus fort.
Toutefois, un servo standard à fort couple (>20Kg) peut consommer plus de 5A, il faudra peut etre que je change de driver moteur.
 
Si la limitation de courant offerte par le driver moteur est une fonctionnalité intéressante, qui a l’avantage d’être prise en charge par le matériel (fiable), elle n’est d’aucune aide pour mettre en place l’asservissement en courant recherché !
 
A suivre..


#67 pat92fr

pat92fr

    Membre chevronné

  • Membres
  • PipPipPipPip
  • 673 messages
  • Gender:Male

Posté 22 novembre 2020 - 03:42

Passons aux asservissements et commençons par la fin !
C’est-à-dire l’asservissement en couple par le courant moteur.
On commence par celui-là, parce que c’est le plus simple à tester et il fonctionne de manière autonome ! 
Par exemple, si on fixe une consigne à 100mA dans un sens de rotation, on peut facilement vérifier que le moteur tourne dans le bon sens, et que le courant n’excède par 100mA (mesure ampèremétrique). 
 
Bien sûr, cet asservissement seul, ne permet pas de contrôler la position du servo. A vide, il ira taper dans sa buté mécanique. Mais, il permet déjà de valider le comportement ‘flexible’ du servo. 
Note : A ce sujet, il faut noter que le réducteur d’un micro-servo a un ratio élevé (> 200 voire 300+). La flexibilité de l’articulation avec un tel ratio risque de ne pas être très performante. La souplesse en cas d’impact devrait logiquement être faible, dangereuse pour la pignonnerie du servo, et quel que soit l’efficacité de l’asservissement. On mesurera et on avisera…
 
Comme nous l’avons vu, le driver moteur DRV8872 n’offre pas de régulation de courant, il va falloir l’implémenter de A à Z, avec une partie en matériel et une partie en logiciel.
Pour asservir le courant moteur, il faut commencer par le mesurer avec une précision correcte ! 
 
Première difficulté ! Avec un pilotage en PWM (commutation à 20KHz), le courant moteur change constamment. 
 
CaptureCurrent.PNG
 
Les appels de courant sont trop forts, et la carte trop petite, pour pouvoir lisser le courant suffisamment à l’aide de condensateurs de filtrage (trop encombrent).
Il faut donc accepter l’idée qu’il n’est pas possible de mesurer directement le courant moyen (vert). On devra l’estimer à partir de mesures de courants instantanés (rouge).
 
Puisque j’utilise un STM32G4 à 150MHz, avec un ADC capable de 4Msps (échantillons par seconde), je pourrais certainement calculer le courant moyen, en prenant des très nombreux échantillons en continu, et calculer la moyenne des échantillons à l’aide d’une fenêtre glissante. Ce n’est pas la solution que je recherche car je garde l’objectif de pouvoir éventuellement prendre un microcontrôleur moins puissant, moins consommant et plus économique à la fin du projet.
 
A suivre..
 
 


#68 Thot

Thot

    Membre passionné

  • Membres
  • PipPipPip
  • 327 messages
  • Gender:Male
  • Location:Toulouse

Posté 22 novembre 2020 - 06:47

C'est très intéressant ! Très joli boulot ! Je joue en ce moment avec des brushless qui ont justement un asservissement en courant à la base et en effet, cela résout beaucoup de problèmes. et offre des possibilités à imaginer.

Autant pour un brushless, où la commutation des bobines est faite directement par le contrôleur, il y a une certaine facilité. Pour un moteur à brosse, ça va être une autre histoire à cause des balais. En effet, la réponse en intensité d'un moteur courant continu, sur une fréquence proche de celle de la rotation du moteur, il va y avoir des pics d'appel. Je suis curieux d'en voir la tête si tu as moyen de les visualiser via oscillo. Je me rappelle d'un projet d'électronique où nous devions justement exploiter ces pics d'intensité pour mesurer la vitesse de rotation du moteur et en asservir sa vitesse (pour un train électrique en pente)

Les fréquences pour lesquelles tu vas travailler vont peut-être être éloignées de celle du moteur. J'espère que ces pics ne vont pas influencer l'asservissement en courant.

Après, justement, si tu traces en interne la réponse en courant du moteur, peut-être que tu peux chopper ces pics pour récupérer la vitesse de rotation ? :-)

 

Limiter le courant dans ses petits moteurs permet d'éviter un peu plus de cramage !!


"Il n'y a rien de plus étrange pour l'homme que son image" RUR, Karel Capek
Caliban Midi - Art - Terroir et Robotique


#69 pat92fr

pat92fr

    Membre chevronné

  • Membres
  • PipPipPipPip
  • 673 messages
  • Gender:Male

Posté 22 novembre 2020 - 07:00

Merci Thot. 

 

En bref, oui, je confirme, c'est l'enfer avec un moteur à balais ! Difficile d'avoir des mesures propres à cause de nombreux parasites.

 

A ce stade, je m'en sors plutôt bien sur l'estimation du courant, mais je rencontre beaucoup de difficulté pour estimer la vitesse de rotation (mesure bruitée).

 

Je vais certainement sortir l'oscillo pour mieux comprendre contre quoi je me bats ! Si j'ai des mesures intéressantes, je les posterai.

 

En outre, le moteur est souvent en charge et à faible vitesse, voire à vitesse nulle. C'est quand même une application particulière ces servocommandes !

 

Je termine ce projet et je passe aux actionneurs brushless, soit en direct, soit avec un réducteur de faible ratio (1:3 à 1:9).

 

Disons que ce projet est une bonne entrée en matière !

 

Patrick.



#70 Oracid

Oracid

    Pilier du forum

  • Modérateur
  • PipPipPipPipPip
  • 6 768 messages
  • Gender:Male

Posté 22 novembre 2020 - 07:18

Je reviens sur ce que j'ai dit plus haut. Cette partie du code mériterait d'être revue.

En effet, un débattement de 0° à 120° est suffisant dans la configuration de mon quadrupède. Néanmoins, si je voulais utiliser les positions accessibles grâce au V, alors je devrais utiliser un servo moteur avec une plage d'angle plus important.

 

Une idée : Et si tu collais le palonnier sur la première barre (liftarm) avec un angle pour compenser le faible nombre de dents du pignon de sortie.

Malheureusement, l'erreur est différente d'un servo à l'autre.



#71 pat92fr

pat92fr

    Membre chevronné

  • Membres
  • PipPipPipPip
  • 673 messages
  • Gender:Male

Posté 22 novembre 2020 - 08:08

Mesure de courant moteur instantané :
 
La méthode la plus courante consiste à mesurer la tension aux bornes d’une résistance de shunt placée en série avec le (driver) moteur.
On utilise une résistance de faible valeur pour limiter la chute de tension et sa propre dissipation thermique.
Comme la tension mesurée est faible, on utilise un amplificateur opérationnel. Et puisqu’on cherche à récupérer la mesure dans le logiciel, on passe ensuite dans un convertisseur analogique-numérique.
 
Une telle résistance est déjà en place pour le fonctionnement du limiteur de courant intégré au driver moteur DRV8872.
On va donc la réutiliser pour l’asservissement en courant. Sa valeur est fixée par la limite de courant du driver, on devra faire avec 0.33 Ohms !
 
Voici le schéma électrique simplifié pour la mesure de courant moteur :
CaptureCircuitCurrent-1.PNG
Je me suis inspiré de la note d’application ST : https://www.st.com/r...electronics.pdf

 

Procédons au calcul de la tension U, en fonction du courant passant par le moteur, noté I.
 
R1 est traversée par le courant I venant du moteur.
 
Le réseau de résistances R2, R10, R11, raccordé au 3v3 et à la masse pourrait perturber la mesure.
Le courant généré par le 3v3, passant par R10, R2 puis R1, est en fait négligeable par rapport à I, compte tenu des valeurs élevées des résistances R10 et R2.
Le courant traversant le moteur, puis passant par R2 et R11 jusqu’à la masse est également négligeable par rapport à I, compte tenu des valeurs élevées de R2 et R11 par rapport à celle de R1.
 

Donc, on retiendra que la tension aux bornes de R1 ne dépend que de I. On obtient le schéma équivalent suivant :

CaptureCircuitCurrent-2.PNG

J’ai utilisé une première fois le théorème de Thévenin pour simplifier une première partie du circuit.

CaptureCircuitCurrent-3.PNG CaptureFormule-1.PNG

J’ai utilisé une seconde fois le théorème de Thévenin pour simplifier le reste du circuit.

CaptureCircuitCurrent-4.PNG CaptureFormule-2.PNG

Seule la tension Ue’ nous intéresse dans cette dernière étape, puisque l’entrée de l’amplificateur opérationnel a une impédance très élevée.

La résistance équivalente Re’ n’engendre aucune chute de tension.

 

Inutile de développer tous les calculs. Traçons plutôt le graphe I (A) donne U (V) : 

CaptureCurrentBeforeAPO.PNG

On constate que la tension à l’entrée de l’amplificateur opérationnel du STM32G4 est proportionnelle au courant moteur, dans une plage de 0.05 à 0.35V.

L’AOP intégré au STM32G4 peut etre configuré avec un gain de 8 (montage non inverseur). La niveau de tension ainsi augmenté, permettra une conversion analogique-numérique sur une plage de tension assez large avec une bonne résolution.

 

Avec un ADC sur 12 bits (0 à 3.3V), le courant I (A) donne la valeur ADC (0-4096) suivante :

CaptureCurrentAfterAOP.PNG

 

On en déduit l’application afine suivante, en fonction du courant moteur I (A) :

CaptureFormule-3.PNG

AN : un courant moteur de I = 100mA devrait donner une valeur ADC de 1463.

 

Le calcul de la valeur de ‘a’ permet une première approximation. En pratique, elle pourra être ajustée par calibration manuelle de la carte électronique (mesure ampèremétrique).
Quant à la valeur de ‘b’, elle ne dépend pas du courant moteur. Le logiciel pourra la calibrer automatiquement en faisant une série de mesures, moteur à l’arrêt.
 

A ce stade, nous pouvons estimer le courant moteur à partir de la valeur retournée par l’ADC, dans une plage de courant assez large comprise entre -500mA et +1A.

 

Le courant moteur subit de fortes variations en fonctionnement, à cause notamment du pilotage du pont en H en PWM. Pour rendre inaudible le courant moteur, la fréquence du PWM est supérieure à 20kHz.

 

Le courant est :

  • positif (1) lorsque le moteur est entrainé, dans un sens ou dans l’autre,
  • nul (2) lorsque le frein est activé (brake)
  • négatif (3) lorsque le moteur est en roue libre (coast).

CaptureCurrentPath.PNG

 

La mesure de courant doit donc se faire lorsque le moteur est entrainé (courant positif).

 

A la cadence de 20kHz, il n'est pas souhaitable de déclencher la mesure ADC en logiciel.

 

Le STM32G4 dispose d’un mécanisme de TRIGGER matériel permettant notamment de déclencher l’acquisition d’un ADC par le TIMER en charge de la génération des signaux PWM, sans intervention du logiciel. Pour déclencher l’acquisition de l’ADC au meilleur moment, le TIMER doit être configuré en mode PWM ‘center-aligned’. Ce mode de fonctionnement permet d’ailleurs d’obtenir une période parfaitement constante des signaux PWM. Le TRIGGER s'active lorsque le compteur du TIMER atteint sa limite haute (overflow) et sa limite basse (underflow). 

 

CaptureTRIGGER.PNG

 

La conversion analogique-numérique est ansi déclenchée alternativement en milieu d’impulsion PWM, lorsque le courant moteur est positif, et entre deux impulsions lorsque le courant est nul ou négatif. Il est facile de filtrer les mesures nulles ou négatives, pour ne retenir que les mesures positives, permettant d’obtenir une estimation du courant dans le moteur lorsqu’il est entrainé.

 

Pour estimer le courant moyen dans le moteur sur une période, il faut tenir compte de la largeur d’impulsion Une approximation (trop) simple consiste à multiplier le courant instantané mesuré par le rapport cyclique PWM.

CaptureFormule-4.PNG

 

 

Passons à la réalité !

 

Lorsque le moteur est à l'arrêt, je mesure 'b' = 1205. C'est la valeur ADC lorsque le courant moteur est nul.

La petite déviation par rapport au calcul théorique doit être due à la valeur des résistances (tolérance 1%).

 

Pour mesurer 'a', je teste différentes valeurs de PWM, et pour chaque valeur je mesure le courant débité par mon alimentation de labo et la valeur ADC.

Je mesure 'a' ~ 2433.

C'est une très grosse déviation par rapport à mon calcul théorique. Je pense que ma méthode d'approximation du courant moyen à partir du courant instantané est trop imprécise.

 

Enfin, voici une comparaison entre le courant moyen estimé par ma carte électronique et mon algorithme, en phase DRIVE (jaune) et en phase COAST (bleu), par rapport au courant débité par mon alimentation de labo (auquel j'ai soustrait la consommation statique de ma carte ~30mA).

 

CaptureCurrentCalibration.PNG

 

La marge d'erreur est de 10% en moyenne, avec une erreur maximale de 20% autours de 300mA.

C'est beaucoup, mais probablement pas rédhibitoire pour un asservissement.

 

A suivre...

Patrick.

 

 

 

 

 

 

 



#72 pat92fr

pat92fr

    Membre chevronné

  • Membres
  • PipPipPipPip
  • 673 messages
  • Gender:Male

Posté 23 novembre 2020 - 08:19

Bonsoir,

 

Voici quelques mesures avec un petit oscilloscope numérique. Toutes les mesures sont faites avec le moteur bloqué. Il ne tourne pas.

 

Je mesure la tension à la sortie ISEN du driver, juste avant la résistance de shunt (Rsense) reliée à la masse, pour différentes valeurs de PWM (%).

CaptureDRV9972.PNG

 

Note : je n'ai pas réussi à fixer la masse de l'oscillo au niveau de la résistance. Je me suis branché sur le connecteur du servo. Du coup, les mesures sont peut etre un peu décalées en tension (bias).

 

PWM = 20% :

Le courant estimé est de 15mA. Le courant en roue libre est de -0mA.

Image15.png

 

PWM = 50% :

Le courant estimé est de 74mA. Le courant en roue libre est de -13mA.

Image100.png
 

PWM = 65% :

Le courant estimé est de 229mA. Le courant en roue libre est de -54mA.

Image230.png
 

PWM = 75% :

Le courant estimé est de 455mA. Le courant en roue libre est de -72mA.

Image455.png
 

 

Je suis surpris du profil du courant dans le moteur. Je m'attendais à un profil en "dent de requin".

Lorsque le PWM dépasse 50%, le courant moteur monte très rapidement (pic), puis continue à monter avec une pente douce jusqu'à presque 1A en pointe.

 

Je ne sais pas trop quoi faire de ces mesures. Je vais essayer de corriger ma formule qui estime le courant par rapport à la mesure de courant faite au milieu de l'impulsion PWM. Pas trivial...

 

Je me demande si le profil serait le même avec un moteur en mouvement.

 

A suivre..

Patrick.



#73 Thot

Thot

    Membre passionné

  • Membres
  • PipPipPip
  • 327 messages
  • Gender:Male
  • Location:Toulouse

Posté 23 novembre 2020 - 08:59

C'est en effet étrange comme réponse. Le moteur est bloqué ici donc tu as un modèle avec une résistance en série avec une bobine d'une certaine inductance qui a tendance à "donner de l'inertie" au courant. Mais toujours en montant.

Peut-être que le profil en dent de requin avec la belle montée exponentielle, tu peux l'obtenir en hachant la tension avec une fréquence plus faible.

 

Pour avoir l'inductance, en théorie, en enlevant la tension liée à la résistance interne du moteur, tu l'obtiendrais en divisant la tension par la dérivée de l'intensité.


"Il n'y a rien de plus étrange pour l'homme que son image" RUR, Karel Capek
Caliban Midi - Art - Terroir et Robotique


#74 pat92fr

pat92fr

    Membre chevronné

  • Membres
  • PipPipPipPip
  • 673 messages
  • Gender:Male

Posté 23 novembre 2020 - 11:46

D'accord. Le moteur est tellement petit que son inductance est peut etre très faible. Je vais essayer avec un servo de taille standard.

 

Patrick.



#75 pat92fr

pat92fr

    Membre chevronné

  • Membres
  • PipPipPipPip
  • 673 messages
  • Gender:Male

Posté 08 décembre 2020 - 09:40

Bonsoir,

 

Il y a deux semaines, j'ai avancé sur le pilotage du moteur en PWM, la mesure de courant moteur et la mesure de position (potentiomètre).

 

La semaine dernière, j'ai implémenté l'asservissement suivant en m'inspirant du modèle Dynamixel.

 

CaptureAsservissementScématique5.PNG

 

La consigne de position est d'abord traitée par un bloc 'profil', qui calcule la meilleure trajectoire, entre la position courante et la position demandée. Cette trajectoire est calculée en fonction de la vitesse maximale et de l'accélération maximale (autres consignes). Ainsi, la courbe de vitesse de rotation du servo aura une forme de trapèze : le servo va accélérer, jusqu'à atteindre sa vitesse de croisière, puis décélérer jusqu'à arriver à sa position finale pour finalement s'arrêter. C'est la sortie de ce bloc 'profil' qui va servir de consigne de position pour la suite de l'asservissement.

Ensuite, c'est un enchainement de PID, qui régulent en position, en vitesse, en courant jusqu'au moteur.

 

Voici un premier test avec un élastique en guise de charge. On joue sur le courant (couple) tout en pilotant le servo en position alternativement entre 30° et 150°.

 

 

Ce premier test est assez concluant. La marge de progression est énorme quant au réglage des PID.

 

Le retour d'information fonctionne bien. Le débit de la liaison série half-duplex est un peu limite. Ce n'est pas l'idéal pour débugger (50 à 100 relectures par seconde de tous les registres RAM du servo).

 

A suivre,

Patrick.



#76 Oracid

Oracid

    Pilier du forum

  • Modérateur
  • PipPipPipPipPip
  • 6 768 messages
  • Gender:Male

Posté 09 décembre 2020 - 08:10

As-tu un outil particulier pour régler les PID ?



#77 pat92fr

pat92fr

    Membre chevronné

  • Membres
  • PipPipPipPip
  • 673 messages
  • Gender:Male

Posté 09 décembre 2020 - 09:31

Bonjour,

 

Pour régler les PID, j'utilise un outil de visualisation (consigne, erreur, sortie) et je règle à la main selon ma propre méthode.

Comme j'ai implémenté des PID avec anti-windup, feed-forward et filtrage passe-bas. Cela peut faire beaucoup de paramètres par bloc PID.

 

Dans ce contexte précis, je n'ai pas de méthode scientifique. Les caractéristiques du moteur me sont inconnues, la charge du moteur est variable, etc.

Difficile de dire si le réglage que j'obtiens est optimal ou pas.

 

Enfin, la liaison série qui permet de piloter le servo, donne accès à l'ensemble des registres de configuration.

Il est donc possible d'ajuster les paramètres PID pour une application particulière sans avoir à recompiler le logiciel de la carte de contrôle.

Les paramètres sont stockés en Flash dans le STM32G4.

 

CaptureRegs01.PNG

 

Patrick.



#78 Oracid

Oracid

    Pilier du forum

  • Modérateur
  • PipPipPipPipPip
  • 6 768 messages
  • Gender:Male

Posté 09 décembre 2020 - 11:03

Pour régler les PID, j'utilise un outil de visualisation.

Quel outil ?



#79 pat92fr

pat92fr

    Membre chevronné

  • Membres
  • PipPipPipPip
  • 673 messages
  • Gender:Male

Posté 09 décembre 2020 - 11:17

Il s'agit d'un petit script en Python utilisant la bibliothèque Tkinter et une implémentation personnelle du protocole de communication Dynamixel V2. Cette application permet d'accéder en lecture/écrite à l'ensemble des registres de configuration, de contrôle et de feedback du servo modifié. 

 

CaptureGUI1.PNG



#80 pat92fr

pat92fr

    Membre chevronné

  • Membres
  • PipPipPipPip
  • 673 messages
  • Gender:Male

Posté 09 décembre 2020 - 03:00

Nouveau test en jouant sur la vitesse et l'accélération :

 

 

Dans cette séquence, le servo ne reçoit qu'une consigne par seconde (première partie de video), et quatre consignes par seconde (seconde partie de la vidéo). Le servo se débrouille pour calculer la trajectoire à sa propre vitesse (1000 itération par seconde).

 

La séquence de fin reproduit la sollicitation d'un servo dans un quadripède avec un cycle de marche de 500ms et une oscillation de 90°. On notera que l'accélération minimale est de l'ordre de 6000dps/s minimum pour atteindre la consigne.

 

Est-ce que vous voyez des tests dynamiques à faire ? Je suis çà court d'idée.

 

Patrick.






0 utilisateur(s) li(sen)t ce sujet

0 members, 0 guests, 0 anonymous users