194 réponses à ce sujet

[Oracid]

J'en déduis que l'erreur d'estimation de la trajectoires réelle doit etre de l'ordre de 3mm maximum.

Oui, mais elle n'est pas très grande, ta patte.

[Thot]

Ca fait beaucoup de PID à la suite pour le contrôle.

Je voulais savoir, tous les PID, tu les règles ? Quand on a deux gains intégrale qui se suivent, il y a des risques d'échanges et de pompage entre les termes intégrales.

Les gains dérivés sont souvent fait naturellement par le train de réduction.

 

A titre d'exemple, pour le carte tinymovr, il y a un asservissement en courant équivalent en lien direct avec les bobines, c'est la partie la plus complexe.

Sur cet asservissement, il y a un asservissement proportionnel en vitesse avec un gain en Ampère/(rad/s). A partir de l'erreur de vitesse, on a un courant de consigne.

Enfin, sur cet asservissement, il y a un asservissement proportionnel en position avec un gain en (rad/s)/rad.

 

Ca simule bien un ressort.

 

Le concepteur du tinymovr va bientôt mettre un gain intégral sur l'asservissement de vitesse uniquement.

 

Pas de gain dérivé mais quand on ajoute une charge avec legers frottements (réducteur), ça fait office de terme dérivé naturel.

[pat92fr]

J'ai beaucoup utilisé mon banc de test, https://www.robot-ma...e-et-extension/, pour tester un mouvement ou un mécanisme. A chaque fois, même sans charge, le dessin était différent de la consigne.  De plus, avec ce banc de test, je ne pouvais pas tester avec une charge. 

Alors, j'avais imaginé, mais pas réalisé, un banc de test qui prenait en compte la charge. Pour cela, une patte suspendue à une potence devait faire avancer un tapis roulant, puis j'ai eu l'idée de supprimer le tapis roulant et de mettre une roulette à l'extrémité de la patte. Pour la charge, il suffit de placer un poids sur la potence qui peut monter et descendre librement sur un rail.

Arrivé là, on a toujours pas le capteur du mouvement réel de l'extrémité de la patte. Alors, j'avais imaginé mettre un point rouge ou blanc sur cette extrémité. Puis je filmais avec une caméra quelconque. Avec un logiciel de montage vidéo, je jouais avec l'intensité des couleurs pour ne voir que ce point rouge ou blanc. En accélérant la vidéo, on devait voir apparaitre la forme du mouvement. Puis je prenais une photo de mon écran.

A mon avis, il est impératif d'avoir une vision réelle du mouvement.

 

La fabrication d'un tel banc est dans ma liste. J'ai reçu des profilés et des guides linéaires. Je dois faire la conception et l'assemblage. Bientôt.

 

Bien, tu m'as convaincu pour la trajectoire réelle. A la TRR2019; j'avais passé un peu de temps à bricoler avec OpenCV et Keras pour faire en sorte que Neunoeil suive la ligne blanche à l'épreuve des roulants. Ci-joint un premier résultat avec un script trouvé sur Internet, à peine retouché pour mon besoin. Il me reste à ajouter un repère à l'échelle et un moyen de comparaison avec la trajectoire théorique. A venir...

 

 

C'est un peu décourageant de voir un résultat aussi mauvais dans la vidéo ! 

La dernière séquence correspond à une trajectoire inadaptée par rapport à la taille de la micro jambe. Ca simule une avancée à 0.4m/s. Pour cette vidéo, j'ai ralenti l'exécution de la démarche. 

 

A suivre...

Fichier(s) joint(s)

•  MyCameraTracker.zip   1,27 Ko   97 téléchargement(s)

[pat92fr]

Ca fait beaucoup de PID à la suite pour le contrôle.

Je voulais savoir, tous les PID, tu les règles ? Quand on a deux gains intégrale qui se suivent, il y a des risques d'échanges et de pompage entre les termes intégrales.

Les gains dérivés sont souvent fait naturellement par le train de réduction.

 

A titre d'exemple, pour le carte tinymovr, il y a un asservissement en courant équivalent en lien direct avec les bobines, c'est la partie la plus complexe.

Sur cet asservissement, il y a un asservissement proportionnel en vitesse avec un gain en Ampère/(rad/s). A partir de l'erreur de vitesse, on a un courant de consigne.

Enfin, sur cet asservissement, il y a un asservissement proportionnel en position avec un gain en (rad/s)/rad.

 

Ca simule bien un ressort.

 

Le concepteur du tinymovr va bientôt mettre un gain intégral sur l'asservissement de vitesse uniquement.

 

Pas de gain dérivé mais quand on ajoute une charge avec legers frottements (réducteur), ça fait office de terme dérivé naturel.

 

Tous les coefficients PID et les valeurs limites de sortie des PID, sont exposés dans des registres (EEPROM). En revanche, je peux mettre 0 dans certains coefficients. 

Mon schéma n'est plus tout à fait vrai, car je suis en train de fusionner les PID position et vitesse. En effet, avec un servo du commerce, je ne peux pas régler le PID vitesse individuellement. La plage de rotation est trop faible à cause des butées à 90 ou 180°. En outre, j'ai ajouté les termes de Feed Forward en vitesse, accélération, et courant. Il y a d'autres paramètres que j'ai fixé dans le code, comme la fréquence de coupure des filtres (dérivées). Pour les intégrales, j'ai volontairement implémenté la sommation sur une fenêtre glissante de 50ms et mes coefficients sont relativement faibles.

 

Actuellement, ma configuration est la suivante :

- PI position,  donne vitesse

- P vitesse, donne courant

- feed forward vitesse donne courant

- feed forward accéleration donne courant

- PI courant avec feed forward en courant donne PWM

 

 

Qu'est ce que tu entends par "Les gains dérivés sont souvent fait naturellement par le train de réduction" ?

 

Bizarre, j'ai refait un réglage en prenant les PID hip et knee indépendamment, et ca marche plutot bien. Et lorsque j'exécute la démarche, ca "pompe'... à mort. Bizarre...

 

Sur la vidéo, c'est le servo de genou (en haut à droite) qui semble osciller le plus. Celui de la hanche semble avoir une trajectoire plus régulière.

 

Patrick.

[Oracid]

Bravo ! Elle est génial ta vidéo ! C'est sûr, qu'avec du talent, une idée prend plus vite, corps.

 

Bon, c'est vrai que là, il n'y a pas de charge, mais quand même, ne sois pas déçu, c'est pas si mal.

Merci pour le code.

[pat92fr]

Bonsoir,

 

Il y a du mieux ! Je suis reparti de zéro pour le réglage des PID et j'ai réglé avec une trajectoire circulaire proposée par Thot.

Franchement, certains coefficients n'ont aucun impact visible sur l'asservissement.

Alors, je ne suis pas très satisfait du résultat, mais l'amélioration est perceptible sur la trajectoire de la jambe.

 

 

L'idéal serait que je raccorde au M5Stack, deux servos non modifiés, avec une seconde patte identique, pour comparer !

Par contre, mon implémentation sur M5Stack a un problème. La démarche est à 25% de la vitesse cible. Si j'augmente, la jambe fait n'importe quoi (genre elle pédale dans le mauvais sens!). Bug... 

A chaque jour suffit sa peine.

 

A suivre.

[Oracid]

Et si, tu mettais un papier millimétré, avec les axes X/Y, en fond de ton banc de test ?

Avec to M5 Stack, ton servo est alimenté en quelle tension ?

[pat92fr]

Bonsoir,

 

Bonne idée pour le papier millimétré. Je voulais automatiser dans le script Python, l'acquisition visuelle d'un repère, pour ensuite estimer la position du pied en (x,z) mm de manière automatique, et produire un tableur avec les coordonnées mesurées. Mais en attendant, le papier ira très bien.

 

Au sujet du module servo pour M5Stack, la tension appliquée sur le connecteur XT30 alimente directement les servos.

 

 

La boutique M5 indique "DC power input: 5-7V". Quand on regarde le schéma de la carte, le seul composant exposé au Vcc est le régulateur de tension LM2596SX-5.0/NOPB qui tient 45V (attention à la dissipation quand même). Donc, tu peux sans problème brancher un Lipo 2S sur le module pour alimenter les servos en HV et le core M5Stack. J'ai testé brièvement, ca fonctionne.

 

 

Je suis en train de reprendre le logiciel de ma petite carte. En retouchant la gestion du moteur, je découvre que l'asservissement fonctionne mieux en mode BRAKE qu'en mode COAST. Je recode pour gérer l'alternance BRAKE-FORWARD ou BRAKE-REVERSE. 

 

 

Du coup, avec un simple asservissement P en position, j'ai un résultat plus satisfaisant que la chaine complète initiale, à basse vitesse.

 

 

A suivre.

[Oracid]

Bonne idée pour le papier millimétré. 

Centimètré, ce serait bien aussi.

 

J'avais bien compris que l'on pouvait alimenter le module avec une 2S, mais ce qui m'intéresse c'est, quelle est la tension aux bornes du servo. 

[pat92fr]

8.4V (2S)

[Oracid]

8.4V (2S)

Il m'intéresse ce M5 Stack. Je le mettrais bien sur mon futur bipède.

Je ne veux pas pourrir ton fil. Tu ne voudrais pas faire un fil spécifique au M5 Stack ? Ici, Carte programmables et ordinateurs - Robot Maker (robot-maker.com)

[pat92fr]

Ok pour le fil M5Stack/Stick. Cela permettra de voir s'il y a d'autres utilisateurs dans ce forum.

 

D'abord, les bonnes nouvelles !

 

1) Driver moteur : L'usage du mode BRAKE, en remplacement du mode COAST, entre deux impulsions PWM moteur, a radicalement changé le comportement de l'asservissement. Le couple est plus fort. Le courant est plus élevé. Le moteur entraine la rotation du palonnier à plus faible rapport cyclique PWM moteur (avant 40% PWM, maintenant moins de 10% PWM). A 50% PWM, le courant monte à plus de 500mA. Avant, il fallait pratiquement 100%. Je ne l'explique pas vraiment. La vitesse de rotation du servo n'est pas dégradée contrairement à ce que je j'imaginais avec ce mode. C'est peut etre même le contraire.

 

 

2) Correction PID : mon implémentation de PID qui ne fonctionnait pas bien (surtout la partie intégrale). J'ai donc recoder tous les PID, en incorporant un filtre passe bas pour la dérivée, et un anti-windup clamp pour l'intégrale. Ci-joint une vieille publication de référence (pdf) que j'ai souvent utilisée. Au passage, j'ai trouvé la suite de vidéos MATLAB particulièrement didactique : 

https://youtu.be/wkfEZmsQqiA

 

3) Simplification asservissement : la petite carte accepte maintenant plusieurs modes de contrôle. L'asservissement initial en Position/Vitesse/Courant est complété par un asservissement en Position, et un asservissement en position et courant :

 

 

Je passe l'asservissement en position seule, car il est dangereux. Le courant n'étant plus limité, le servo peut chauffer très vite en charge et il n'y a aucune protection. Il y a bien un seuil de courant implémenté au niveau matériel sur la petite carte, mais ca coupe à 1A, c'est trop fort pour un MG90s.

 

Maintenant, la micro patte tourne en rond correctement. La démarche est aussi correcte, bien que cela ne semblait pas évident au premier coup d'œil ! A environ 0.2m/s, j'obtiens le résultat suivant 

 

 

Et si je compare avec la trajectoire estimée à partir du feedback, c'est identique (faut flipper horizontalement, ma patte est construite dans le sens opposé) : 

 

 

Si on jette un coup d'œil aux différentes courbes de feedback, on ne voit rien de très préoccupant :

 

 

Il y a un léger décalage dans le temps entre la consigne et le réel. L'enchainement de PIDs et de filtrages doit y etre pour quelque chose.

 

On commence à mesurer le problème en sortant la courbe des vitesses :

 

 

On constate que le servo du genou (knee) monte à 1000°/s, sachant qu'il est vendu pour 0.1s/60°, soit 600°/s, à 6V, à vide certainement. Le fait de l'alimenter en 8.4V, lui donne un peu plus de pèche, mais il y a une limite physique qu'on constate sur cette courbe. L'inertie de la patte est faible à vide, mais elle n'est pas négligeable. Donc la déformation de la trajectoire est simplement due au fait que le genou ne suit pas !

 

Alors on pourrait peut etre pousser un peu le courant en réglant les PIDs de manière plus agressive. Il y a de la marge :

 

 

 

Avec ce montage des servos sur un même coté, les palonnier sont décalés. Lorsque la jambe revient vers l'avant, ramenée par le servo de la hanche, la géométrie fait que le pied s'abaisse naturellement. Le servo de genou doit lever le pied, mais aussi lutter contre la descente du pied provoquée par cette géométrie. En fait, les servos de genou et de hanche se trouvent en opposition pendant la phase de swing. C'est très mauvais si l'objectif est d'avancer vite. Je comprends mieux pourquoi il faut absolument un montage coaxiale des servo dans cette configuration de patte. Soit en mettant les servo l'un en face de l'autre, comme sur pupper, soit en faisant un double renvoi pour le genou comme sur mini pupper.

 

Je venais justement d'imprimer une seconde jambe, pour comparer entre deux MG90s hackés et deux MG90s stock.... pas de bol. Faut revoir la mécanique... et du coup toutes les formules FK/IK... c'est pas fini cette histoire ! Finalement, quand je vois les courbes en courant et vitesse, je me dis que j'ai fait un pas en avant, et je pense avoir corrigé, au moins en partie, les erreurs détectées le week-end dernier.

 

A suivre...

Fichier(s) joint(s)

•  IntegralAnti-WindupforPIControllers.pdf   879,95 Ko   1522 téléchargement(s)

[Oracid]

Je venais justement d'imprimer une seconde jambe, pour comparer entre deux MG90s hackés et deux MG90s stock.... pas de bol. Faut revoir la mécanique... et du coup toutes les formules FK/IF... c'est pas fini cette histoire ! 

Que veux-tu dire ? Les 2 servos sont très différents ?

 

Merci pour le sujet, https://www.robot-ma...stack/?p=112300

[pat92fr]

Justement, ils sont identiques. L'idée initiale était de comparer l'asservissement d'origine avec celui que je développe, à mécanique équivalente. Je pourrai le faire en laissant la mécanique comme cela...

 

Je réfléchis à faire un renvoi entre le servo de genou et le genou en utilisant l'axe de rotation du servo de hanche, pour conserver les deux servo du même coté.

[Oracid]

Justement, ils sont identiques.

Oui, ils sont mécaniquement identiques, mais le résultat, est-il bien, différent ?

 

 

Je réfléchis à faire un renvoi entre le servo de genou et le genou en utilisant l'axe de rotation du servo de hanche, pour conserver les deux servo du même coté.

Avec mon 4 barres, l'axe de rotation est unique, et les servos peuvent se situer n'importe où. C'est le but !  Et c'est comme cela que fonctionnent les Cheetah.

En t'inspirant de cela, tu pourrais actionner le fémur avec le servo gauche et le tibia, avec le servo droite.

[pat92fr]

Effectivement, le montage à 4 barres a de nombreux avantages. Comme je voulais faire un minimum de mécanique, j'ai juste refait mon support servo, et voici une nouvelle mécanique avec un montage coaxial, façon pupper.

 

 

J'ai amélioré le code python de telle sorte qu'il fait l'acquisition visuelle de la position du pied avec une précision de l'ordre du mm une fois bien calibré. L'export se fait en CSV.

 

x,z
0.006,-0.098
0.006,-0.098
0.006,-0.098
0.006,-0.098
0.006,-0.098
0.006,-0.098
0.006,-0.098
0.006,-0.098
0.005,-0.098 

Trace visuelle de la trajectoire :

Capture du mouvement dans un fichier (et affichage dans Excel)

Superposition pour vérification :

 

Bien, il me reste à reprendre mes fonctions mathématiques pour la cinématique directe et inverse.

 

A suivre.

[Oracid]

Effectivement, le montage à 4 barres a de nombreux avantages. 

Ah, mais, je ne proposais pas de faire un 4 barres ! Je te conseillais juste de t'inspirer de la jonction servo/fémur ou  servo/tibia. Mais peut importe, ce que tu as fait est très bien !

 

Ton calque millimétré est parfait !

Si je comprends bien la dernière image, le feedback et non pas la consigne, c'est la trace bleu, et le résultat, la trace rouge. Et bien, c'est pas mal ! Cela se superpose bien !

Par contre, les valeurs sur le calque semblent être en millimètre, alors que la réalité, si je me fis à l'échelle de la taille de la patte, serait plutôt en centimètre.

Pour chaque test, ne pourrais tu pas donner la consigne (le mouvement souhaité), le feedback du servo (en bleu), et le résultat physique(en rouge).

Il va falloir que je m'intéresse à OpenCV, de plus près. Je ne sais plus où donner de la tête . . .

[pat92fr]

Oui, je ne suis pas allé jusqu'au bout de l'exercice. J'aurais du superposer la trajectoire déduite du feedback avec celles obtenues visuellement. J'allais le faire jusqu'à ce que les deux MG90s ont lâché pratiquement en même temps. Leur potard est mort. Il se mettaient à vibrer à certaines positions... et effectivement la tension au niveau du curseur variait de manière disproportionnée par rapport aux variations d'angle du palonnier. Ca ne vaut pas un encodeur magnétique.. la durée de vie du potard est faible avec nos applications.

 

Du coup, j'en ai profité pour utiliser ces deux servo en fin de vie, pour régler la mesure de courant et l'asservissement en courant (PI + feed forward courant donne PWM). Je fais le réglage de base moteur bloqué, puis j'affine avec de grandes rotations entre 20 et 160°. Je règle de manière la plus agressive possible sans entrainer d'oscillations parasites.

 

Deux bonnes nouvelles, toujours liées au fait d'utiliser le mode BRAKE plutôt que le mode COAST du driver moteur, entre deux impulsions PWM moteur. Les calculs théoriques du courant dans la résistance de shunt (cf. page 4 : https://www.robot-ma...attes/?p=111766). J'avais estimé à (a,b ) à (1872, 1276). Apres calibration dans ce nouveau mode, je suis à (1950,1204).

 

En outre, la forme du courant à l'oscillo est bien plus normale, à 100mA :

 

A 200mA :

 

A 500mA :

 

J'obtiens les réglages pour le PI courant qui sort le rapport cycle du PWM en % :

• Kp = 1.1 à 2.5%/mA
• Ki = 0.03 à 0.05%/mA (avec une cadence de 1kHz)
• Kfeed-forward = 0.1%/mA

Le Feed Forward joue un rôle majeur : à 500mA de consigne, il donne 50% de PWM. Le Kp et le Ki servent à corriger l'erreur résiduelle entre consigne et mesure courant.

 

J'ai l'impression d'avoir exorcisé une partie de ma petite carte ! Cette partie là semble fonctionner conformément à la théorie.

 

Avec la nouvelle mécanique coaxiale, je parviens à un domaine accessible par le pied, nettement plus symétrique. La différence en X vient du fait que le tibia est rectiligne et plus long que le femur.

 

 

A suivre...

[pat92fr]

La fin de l'année 2020 approche, et voici un ultime réglage à la pleine vitesse.

 

 

La trajectoire est correcte, bien que légèrement inclinée, à cause d'un mauvais réglage de neutre sur l'un des servos.

 

 

Une légère déviation pendant le swing :

 

 

Si on compare le feedback avec la télémétrie OpencCV, on retrouve la forme. Dommage pour le décalage de la caméra et le mauvais réglage du neutre d'un servo, on voit une translation et une rotation... J'étais pressé aussi, c'est bientôt le réveillon de nouvel an !

 

 

Si on jette un œil aux autres paramètres, le fait d'avoir un chaine de PID plus courte, et plus simple a permis de réduire la latence. La changement de mécanique et l'amélioration du driver moteur font le reste.

 

 

Je pense que la micro patte pourrait aller plus vite. Là, c'est une vitesse de l'ordre 30cm/s si mes calculs sont bons.

 

Voici le montage actuel. La nouvelle carte en version micro devrait arriver (20x20mm, pas possible de faire plus petit pour l'instant) 

 

 

 

Merci pour votre support pour cette réalisation. Allez ! Bonne année 2021 à tous ! 

 

Patrick.

[Oracid]

Une excellente base de projet pour la nouvelle année.

Bravo pour ton travail.