Aller au contenu


Photo
- - - - -

Robot-chat & synchronisation coude+épaule


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

#1 titusIII

titusIII

    Membre

  • Membres
  • 16 messages

Posté 28 mars 2016 - 02:14

Bonjour,

 

Nous sommes en Master en electronique et dans le cadre de notre projet scolaire nous réalisons un robot chat à échelle 1.

 

Je suis en charge de la programmation.

L'idée est de reproduire fidèlement les mouvements d'un vrai matou.

 

Pour l'instant je bosse sur une patte accrochée à une épaule.

Nous utilisons des moteurs brushless et je programme sur des Psoc (les micro de chez Cypress).

 

Je bosse sur une des pattes avant.

Pour l'instant je ne m'occupe que de deux moteurs : celui qui controle l'épaule et celui du coude.

J'ai fait des algo math pour déterminer les angles que je dois avoir sur mes deux axes.

J'ai eu le temps de bricoler un soft sur mon ordi pour piloter la carte en USB.

 

Le contrôle des moteurs marche très bien et je suis capable de commander mes deux moteurs en même temps pour leur demander d'aller à une position précise.

 

Je sèche pour faire des mouvements fluides...

Avez vous des idées de comment faire pour réaliser un mouvement fluide en faisant bouger les deux moteurs en même temps?

En fait, je cherche une sorte d'algo d'asservissement numérique qui commanderai directement mes moteurs de telle sorte qu'ils suivent une consigne que je bouge en temps réel.

 

J'avais pensé à un correcteur PID mais le soucis c'est que je commande mes moteurs en vitesse et non en position. Même en dérivant la sortie du correcteur je n'ai pas eu de résultats convainquant.

Je pense qu'il faut que je continue de bosser sur le PID.

 

Pour asservir la vitesse, j'ai un retour tacho de chaque moteur.

 

Si vous avez des idées, merci de me les faire parvenir! Ce serait super!

 

Titus



#2 Leon

Leon

    Membre passionné

  • Membres
  • PipPipPipPipPip
  • 1 289 messages
  • Gender:Male

Posté 28 mars 2016 - 03:20

Quand tu dis "J'ai fait des algo math pour déterminer les angles que je dois avoir sur mes deux axes.", ça signifie, je suppose que tu as une cinématique inverse.

 

Voici ma méthode pour avoir des mouvements fluides. C'est la méthode standard, utilisée dans les robots industriels. C'est diablement efficace!

 

* d'abord tu décomposes en temps réel (une centaine de fois par seconde par ex) ton mouvement en X-Y-Z, pour déterminer la position que tu souhaites obtenir à un instant T. C'est le calcul de la trajectoire à suivre. Ce calcul de trajectoire sera volontairement limité en vitesse, et si besoin en accélération. C'est LA condition qui va permettre d'avoir des mouvements fluides. La limitation en accélération va engendrer des profils de vitesse dit "trapezoidaux", qui va donner des mouvements étonnamment fluides. C'est un peu chiant à calculer quand on travaille en 3D, mais ça donne des résultats magiques. Avec juste une limitation en vitesse, ça donne des mouvements saccadés.

 

* puis tu appliques toujours en temps réel (une centaine de fois par seconde) ta cinématique inverse, ce qui te permet d'en déduire les angles de consigne des moteurs.

 

* enfin, tu appliques ton asservissement. Un PID bien réglé. Cet asservissement doit impérativement être en position (angle des moteurs), surtout pas en vitesse. Donc en entrée, il prend la consigne de position angulaire issu de la cinématique inverse. L'asservissement doit être robuste et très réactif pour suivre exactement la trajectoire de consigne. Et les moteurs doivent être suffisamment puissants pour suivre la consigne exactement, et ne JAMAIS s'en écarter, sinon les mouvements ne seront plus fluides du tout.

 

Et vidéo d'un robot "industriel amateur", avec limitation en vitesse et accélération. Les mouvements sont fluides, bien que pas naturels du tout. Mais avec un réglage, il serait possible de faire des mouvements plus naturels.

 

Leon.


BOB4, mon drone hélicoptère autonome d'intérieur http://heli.bot.free.fr/
BOB3, mon robot autonome d'intérieur avec WiFi + Foxboard Linux http://ze.bot.free.fr/
BOB5, robot bipède simulé, puis tentative de réalisation (fail)


#3 titusIII

titusIII

    Membre

  • Membres
  • 16 messages

Posté 28 mars 2016 - 03:47

Justement je bosse pas en 3D, 2D uniquement pour commencer.

Mon algo il fait ça :

160328045436515858.jpg

En entrée j'ai C et H

En sortie il me donne les angles epaule et coude.

Je pense que c'est ce que tu appelles la cinématique inverse?

 

Je comprend pas trop ta première étape.

Elle est hors ligne (elle s’exécute avant le mouvement?)

 

Titus



#4 titusIII

titusIII

    Membre

  • Membres
  • 16 messages

Posté 28 mars 2016 - 04:02

J'ai pas le choix de commander mes moteurs en vitesse.

Le driver attend un signal PWM qui fait varier la vitesse du moteur.

 

Cependant, je peux faire en sorte que le PID fasse de la position si je lui donne l'erreur de position et que je dérive sa sortie pour avoir la vitesse des moteurs.

C'est possible ça?

 

Je résume si j'ai bien compris :

 

Un mouvement se déroule en 3 étapes.

1* Je regarde l'angle actuel, je connais déjà l'angle final.

Je fais la soustraction pour avoir la distance angulaire à parcourir.

Je fais un traitement en temps réel pour sortir un grand tableau avec les données vitesse dedans. (Pour mes 2 axes en mème temps?)

J'ai pris le soin de limiter la vitesse : donc si je veux faire des mouvements plus rapide je dois pousser cette limite.

 

2* Là j'ai loupé quelque chose!

Je convertis les données "vitesse" précédentes en commande pour mon moteur?

 

3* Là je fais bouger mes moteurs en lui donnant à manger les valeurs de mon tableau avec le meme delay que pour les traitements précédents. (avec un PID)

 

J'ai bon?

Si oui, en particulier pour le grand tableau, ma puce va cruellement manquer de RAM. Je vais investir dans une EEPROM ou quelque chose comme ça



#5 Leon

Leon

    Membre passionné

  • Membres
  • PipPipPipPipPip
  • 1 289 messages
  • Gender:Male

Posté 28 mars 2016 - 04:37

Je comprend pas trop ta première étape.

Elle est hors ligne (elle s’exécute avant le mouvement?)

Le "hors ligne" ou pas, c'est à toi de choisir selon tes besoins. Il y a plein d'alternatives possibles:

* si tu as beaucoup de mémoire (un PC, une Raspberry-Pi), alors tu peux calculer les consignes 2D (X, Y) ou même angulaires en hors ligne, puis les exécuter. C'est une possibilité, pas une obligation. C'est ce qui est fait dans la 2ieme vidéo.

* si tu n'as qu'un microcontrôleur avec très peu de RAM/ROM/Flash (dizaines de ko), et aucun moyen de stockage de données, alors tu ne pourras pas stocker des consignes que tu aurais calculées "hors ligne", ça prend trop de place (100 consignes par seconde, fois 2x4 octets). Dans ce cas, tu devras sans doute tout calculer en "temps réel", à chaque instant.

* si tu dois mettre à jour en temps réel la consigne à cause d'une interaction (réaction à un événement extérieur), alors je te conseille de travailler tout en temps réel. Ca ne demande pas une puissance de calcul si phénoménale que ça.

 

Je pense que c'est ce que tu appelles la cinématique inverse?

Google est ton ami (je sais, faut le dire vite). Cherche "cinématique inverse". (oui, ce que tu as dessiné c'est le principe de la cinématique inverse)

 

J'ai pas le choix de commander mes moteurs en vitesse.

Le driver attend un signal PWM qui fait varier la vitesse du moteur.

 

Cependant, je peux faire en sorte que le PID fasse de la position si je lui donne l'erreur de position et que je dérive sa sortie pour avoir la vitesse des moteurs.

C'est possible ça?

 

Je t'invite à (re)lire/suivre sérieusement, dans le détail, un cours sur l'asservissement PID, car je crois que tu n'as pas tout compris.

 

Pour ton asservissement, le PID doit impérativement avoir :

* la consigne (=l'entrée) doit être la position angulaire impérativement

* la commande (=la sortie) sera le PWM, c'est totalement classique.

 

De plus, quand tu dis que le PWM correspond à la vitesse, c'est totalement faux. A vide, sans couple résistant, c'est un peu vrai, mais c'est tout.

Le PWM correspond au courant, à la puissance que tu vas injecter dans ton moteur, mais là encore, ça n'est pas totalement vrai.

Quoi qu'il en soit, il ne sert à rien de te préoccuper d'à quoi correspond ta commande dans le détail. Crois-moi, un asservissement de position (=avec une consigne de position), en PID, qui sort un PWM vers un moteur, c'est l'asservissement le plus classique qui existe! C'est archi standard, ça fonctionne très bien.

Et ça se règle de manière empirique, il y a des méthodes pour ça, je t'invite à fouiller sur le web.

 

Ne surtout pas dériver quoi que ce soit en sortie!

 

Leon.


BOB4, mon drone hélicoptère autonome d'intérieur http://heli.bot.free.fr/
BOB3, mon robot autonome d'intérieur avec WiFi + Foxboard Linux http://ze.bot.free.fr/
BOB5, robot bipède simulé, puis tentative de réalisation (fail)


#6 Leon

Leon

    Membre passionné

  • Membres
  • PipPipPipPipPip
  • 1 289 messages
  • Gender:Male

Posté 28 mars 2016 - 04:59

Un mouvement se déroule en 3 étapes.

1* Je regarde l'angle actuel, je connais déjà l'angle final.

Je fais la soustraction pour avoir la distance angulaire à parcourir.

Je fais un traitement en temps réel pour sortir un grand tableau avec les données vitesse dedans. (Pour mes 2 axes en mème temps?)

J'ai pris le soin de limiter la vitesse : donc si je veux faire des mouvements plus rapide je dois pousser cette limite.

Déjà, je n'ai pas parlé de mouvement. Les étapes 1 à 3, c'est un algorithme. Dans l'idéal, tout tourne en même temps, plusieurs dizaines/centaines de fois par seconde. La partie 1 de l'algo donne des données mises à jour à la partie 2, et ainsi de suite.

 

Pour l'étape 1, tu n'as pas compris. L'étape 1 sort des positions 2D ou 3D, en X-Y. Donc pas d'angle, pas de vitesse. Je n'ai jamais parlé de CALCULER une vitesse, juste de LIMITER en vitesse et/ou en accélération les mouvements dans ce repère X-Y.

 

J'ai bon?

Si oui, en particulier pour le grand tableau, ma puce va cruellement manquer de RAM. Je vais investir dans une EEPROM ou quelque chose comme ça

Pour l'EEPROM, c'est loin d'être indispensable, voir l'explication juste au dessus.

 

Leon.


BOB4, mon drone hélicoptère autonome d'intérieur http://heli.bot.free.fr/
BOB3, mon robot autonome d'intérieur avec WiFi + Foxboard Linux http://ze.bot.free.fr/
BOB5, robot bipède simulé, puis tentative de réalisation (fail)


#7 titusIII

titusIII

    Membre

  • Membres
  • 16 messages

Posté 28 mars 2016 - 05:36

Donc le plan en X,Y c'est le mien en H,C !

Si oui,

J'ai bien compris la première méthode de stockage hors ligne.

 

Mais vais devoir tout faire en temps réel, ça économisera une EEPROM!

J'ai relu quelques cours sur le PID, j'avais un peu oublié. J'ai eu des cours dessus, c'est revenu vite.

 

C'est donc dans le plan X,Y que je limite la vitesse que va prendre mon point (bout de la patte)!

Je comprend bien le phénomène de trapèze que va créer la limitation en accélération, reste à la mettre en œuvre...

 

Si j'ai bien compris, tout ça repose sur le correcteur PID qui se charge de linéariser les saccades provenant du changement de la consigne?

 

Autre chose, quand tu dis : "la consigne (=l'entrée) doit être la position angulaire impérativement"

Tu parles bien de l'erreur angulaire?

Soit : consigne - valeur_actuelle

Parce si je lui donne la consigne (la valeur demandée qui sort de mes calculs pseudo-hors-ligne), le correcteur ne sauras jamais où il en est en temps réel, donc ne sera pas asservit du tout?

 

Titus.



#8 titusIII

titusIII

    Membre

  • Membres
  • 16 messages

Posté 28 mars 2016 - 06:19

Question idiote!
Bien sur que oui, je regardais un schéma boucle ouverte du PID...

 

Moi et la théorie c'est pas trop ça!

 

Je commence à coder suivant ta méthode, merci encore!

Je tien le forum au courant pour la suite



#9 Leon

Leon

    Membre passionné

  • Membres
  • PipPipPipPipPip
  • 1 289 messages
  • Gender:Male

Posté 28 mars 2016 - 06:25

Si j'ai bien compris, tout ça repose sur le correcteur PID qui se charge de linéariser les saccades provenant du changement de la consigne?

 

Non, ce qui va permettre d'avoir des mouvements fluides, c'est la combinaison du "lissage de consigne" à l'étape 1, et du PID. Surtout l'étape 1 en fait.

Et pour régler la fluidité des mouvements, il faut régler les limites de vitesse et d'accélération à l'étape 1.

 

Au final, si tout est bien réglé côté PID, le mouvement réalisé suivra très précisément les coordonnées X-Y (ou H-C si tu veux) calculées à l'étape 1.

 

Tiens-nous au courant pour la suite!

 

Leon.


BOB4, mon drone hélicoptère autonome d'intérieur http://heli.bot.free.fr/
BOB3, mon robot autonome d'intérieur avec WiFi + Foxboard Linux http://ze.bot.free.fr/
BOB5, robot bipède simulé, puis tentative de réalisation (fail)


#10 titusIII

titusIII

    Membre

  • Membres
  • 16 messages

Posté 28 mars 2016 - 06:28

Encore une petite chose :

 

Je fixe le sens du moteur avant de le faire bouger pour l'instant.

Je reste sur cette méthode?

Je détermine la direction en fonction de l'angle actuel et de l'angle final.

Ça te semble être une bonne méthode?

 

Romain.



#11 Leon

Leon

    Membre passionné

  • Membres
  • PipPipPipPipPip
  • 1 289 messages
  • Gender:Male

Posté 28 mars 2016 - 06:35

Si par "sens du moteur" du entends le sens du courant qui doit passer dans ton moteur en sortie du pont en H, alors il faut qu'il soit déduit du signe de la commande (la sortie de l'asservissement PID).

Commande positive, courant dans 1 sens

Commande négative, courant dans l'autre sens.

 

Il faut que ça soit mis à jour en temps réel impérativement. La commande oscille énormément entre positif et négatif, et c'est parfaitement normal. Pour tenir une position fixe, on a souvent des micro-oscillation autour de la position de consigne. Donc le PID ordonne au moteur d'aller dans 1 sens, et 10ms plus tard dans l'autre sens, et ainsi de suite.

 

Le PWM, quant à lui, est la valeur absolue de la commande. C'est une première approche, on pourra affiner plus tard si tu veux, mais chaque chose en son temps.

 

Leon.


BOB4, mon drone hélicoptère autonome d'intérieur http://heli.bot.free.fr/
BOB3, mon robot autonome d'intérieur avec WiFi + Foxboard Linux http://ze.bot.free.fr/
BOB5, robot bipède simulé, puis tentative de réalisation (fail)


#12 titusIII

titusIII

    Membre

  • Membres
  • 16 messages

Posté 28 mars 2016 - 06:39

C'est pas du moteur courant continu!

 

J'ai des moteurs brushless, je passe par des puces drivers dont la commande du sens se fait uniquement par SPI.

J'ai aussi quelques trucs sympa comme BREAK et des milliers de registres (que j'ai déjà configuré)

 

Donc je change le sens suivant le signe de ma commande, OK !

 

Si tu es curieux, il s'agit de l'A4960 de chez Allegro



#13 titusIII

titusIII

    Membre

  • Membres
  • 16 messages

Posté 29 mars 2016 - 09:25

Bonjour!

 

Alors oui, c'est tout de suite mieux avec les PID !

 

Pour l'instant je joue avec Kp uniquement, mes coeffs sont 4.5 pour l'épaule et 3 pour le coude. Ce ne veut pas dire grande chose sans avoir le système sous les yeux alors voila la bête :

 

 

Y'a un genre d'accroche sur les changements de direction, on voit que ça casse la fluidité, le coude arrive pas à suivre et ça donne un genre de cercle avec le bout de la patte au lieu d'une ligne parallèle au sol.

J'ai pas vraiment d'idée pour corriger ça. Je me demande si c'est pas dû aux moteurs qui ont la particularité de ne pas avoir de couple au démarrage...

 

Si oui, pas facile de régler ça!

 

Avec un coeff plus petit que 4.5 pour l'épaule, le moteur grogne et part de temps en temps.

Si il est plus grand il fait n'importe quoi.

J'étais en train de réfléchir à un moyen de régler finement les coeffs mais avec l'inertie, regarder le potar... Et puis les micros oscillations c'est pas possible avec mes moteurs!

 

Peut être à vide? Mais ça changerai mon système et ça marcherai plus si je le remonte!

 

Une idée?

 

Titus.



#14 ashira

ashira

    Pilier du forum

  • Modérateur
  • PipPipPipPipPip
  • 1 333 messages
  • Gender:Male

Posté 29 mars 2016 - 10:32

Ca joue sûrement, ton moteur décroche souvent. C'est l'effet cogging que les voitures de modélisme ont souvent. C'est pour ça qu'il y a des brushless avec des capteurs: Le contrôleur tient compte de la position de l'arbre du moteur, ca lui donne plus de couple au démarrage.

Tu peux essayer de régler le problème en diminuant ton accélération au début de chaque mouvement (peut etre en fin de mouvement aussi..)

#15 titusIII

titusIII

    Membre

  • Membres
  • 16 messages

Posté 29 mars 2016 - 10:38

En effet, j'ai pas limité l'accélération. Seulement la vitesse pour l'instant.

 

Je bossai dessus justement, merci!

 

En parlant de position de l'arbre d'ailleurs, j'utilise les A4960 pour controller mes brushless.

 

Et la puce se charge de détecter le "point zero" du moteur avant de le démarrer.

J'ai du régler cette étape comme un monstre pour que mon moteur démarre, c'est peut être le moment de revérifier les réglages...



#16 ashira

ashira

    Pilier du forum

  • Modérateur
  • PipPipPipPipPip
  • 1 333 messages
  • Gender:Male

Posté 29 mars 2016 - 11:07

Apparemment tu peux ajuster la courbe d’accélération dans ton contrôleur(?) Le "point zero" c'est peut être pour le timing, c'est le décalage entre l'arbre et l'alimentation des bobines. Si tu as un réglage timing dans ton contrôleur tu peux essayer de le baisser.  



#17 titusIII

titusIII

    Membre

  • Membres
  • 16 messages

Posté 29 mars 2016 - 11:13

Je peux régler la phase, c'est ce dont tu parles?



#18 titusIII

titusIII

    Membre

  • Membres
  • 16 messages

Posté 29 mars 2016 - 11:54

C'est un peu mieux avec quelques réglages du driver. Notamment de la phase et du système qui permet de "synchroniser" le moteur pour le ramener à une position connue.

 

Vue de dessus où on voit assez bien les tremblements :

 

Vue classique, c'est un peu plus fluide :



#19 ashira

ashira

    Pilier du forum

  • Modérateur
  • PipPipPipPipPip
  • 1 333 messages
  • Gender:Male

Posté 29 mars 2016 - 12:01

Je ne sais pas ce que tu appelles la phase, mais sur ce site http://www.allegromicro.com/en/Products/Motor-Driver-And-Interface-ICs/Brushless-DC-Motor-Drivers/A4960.aspx il y a marqué que tu peux ajuster le démarrage du moteur suivant sa charge. Donc peut être que tu peux adoucir la courbe de démarrage quelque part dans les paramètres.  



#20 titusIII

titusIII

    Membre

  • Membres
  • 16 messages

Posté 29 mars 2016 - 12:06

Ah oui, c'est la rampe de démarrage ça !






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

0 members, 0 guests, 0 anonymous users