15 réponses à ce sujet

[hmnrobots]

Voilà le problème concernant encore et toujours le robot tondeuse :
-Chaque roue dispose d'un capteur opto qui génère 24 impulsions par tour ce qui est peu!
-ces impulsions sont récupérées par interruption et incrémente un compteur
-chaque roue dispose donc de son propre moto-réducteur indépendant
-Actuellement pour rouler droit, je compare la valeur des 2 compteurs d'impulsion de roue et envoie l'erreur via un PID dans le circuit de commande des moteurs; Le résultat est satisfaisant mais pourrait être amélioré car cette fonction n'est valide que lorsque la vitesse requise est atteinte mais pas pendant la phase d'accélération (sur le coup je n'avais pas réussi à le mettre en place.)

Je me rends bien compte que ce code n'est pas parfait et donc j'en appelle au soutien de la communauté (c'est pas bien dit ?).

Les objectifs :
-être capable d'avancer droit pendant accélération (jusqu'à vitesse de consigne) et décélération.
-gérer les virages par cette même fonction
L'analyse du moment :
Si ma vitesse requise est de (par ex) 50 RPM atteinte en 3s soit sensiblement 17 d'accélération/s. j'envisage alors de générer un compteur de référence qui sera comparé avec les compteurs de roue selon une loi de mouvement uniformément accéléré jusqu'à atteindre la vitesse requise. L'erreur entre ce compteur de référence et le compteur de roue génère individuellement la commande.

Quelqu'un a t il déjà réfléchi et résolu le problème?
Bonne journée

[Black Templar]

Salut hmnrobots !

Normalement, chaque roue possède un asservissement en vitesse. Ainsi, tu es sur que chaque roue tourne bien à la vitesse de consigne.
C'est l'asservissement de base.

Par dessus ça, tu peux asservir ton robot en angle. A l'aide des codeuses, tu peux obtenir la position du robot et son orientation.
Tu calcules donc l'orientation et tu asservie par rapport à une consigne. Le résultat de cette asservissement sera les vitesses de tes roues (qui elle-même sont soumises à l'asservissement en vitesse)

Ainsi, ton robot rectifiera sa trajectoire pour aller toujours tout droit.


++
Black Templar

[hmnrobots]

Salut Black Templar, j'espérais bien ta réponse éclairée !

Normalement, chaque roue possède un asservissement en vitesse.

Au démarrage la vitesse est nulle,il y a accélération,mon problème est que je ne dispose que des impulsions sur les roues (24 par tour) ce qui est je pense trop peu et je ne pense pas pouvoir augmenter beaucoup car elles sont sur le PCF8574. Si je veux asservir toutes les 100ms, mon calcul de vitesse de roue sera trop imprécis.De plus même si le PCF est géré sous interruption, l'acquisition se fait quand même par I2C. Je crains donc que la mesure d'une largeur d'impulsion ne soit pas fiable mais c'est peut être une piste...
Je paye ma volonté d'être resté avec le même PIC et l'absence de capteur sur l'axe du moteur au lieu de la sortie du réducteur.
C'est vrai que ça fonctionne pas trop mal mais je crois que j'aurais pas mal à gagner en re-codant cette partie

Merci pour la contribution

[Black Templar]

Au démarrage la vitesse est nulle,il y a accélération,mon problème est que je ne dispose que des impulsions sur les roues (24 par tour) ce qui est je pense trop peu et je ne pense pas pouvoir augmenter beaucoup car elles sont sur le PCF8574. Si je veux asservir toutes les 100ms, mon calcul de vitesse de roue sera trop imprécis.

Oui, le problème viens du fait que tu as ta codeuse sur la roue et non sur l'arbre moteur.
Asservir tous les 100ms, c'est pas très rapide, mais ce n'est pas déconnant non plus. Surtout qu'avec 24imp/tour, tu ne peux de toute façon pas asservir rapidement. (il vaut mieux asservir tous les 500ms pour avoir environ 12 impultions par boucle d'asservissement que tous les 50ms et n'avoir qu'une seule impulsion, par fois deux)

Perso, j'ai l'habitude d'asservir mes moteurs de robots à 50hz, quand la codeuse est sur l'arbre moteur. Je ne constate pas de gain à le faire plus vite.
Alors dans ton cas, asservir tous les 200ms à 500ms en vitesse devrait être suffisant. Tu ne seras certes pas très précis, mais c'est à cause de la codeuse sur la roue. Et puis une tondeuse doit-elle être précis au cm ?

Par contre, oui, je maintient qu'un asservissement supplémentaire en angle pourrait t'assurer d'aller tout droit. ça rectifierai au moins les erreurs du à l'accélération de tes moteurs (qui n'accélèrent peut être pas de la même manière)

[hmnrobots]

Réflexion utile et nécessaire, je vais creuser et préparer un essai dés mon retour dans l'atelier.
Merci

[hmnrobots]

Comme promis de retour pour donner des résultats qui sont après les premiers essais très positifs; La galère sur laquelle j'ai perdu beaucoup de temps était due au calcul avec des float et int signés! c'était à n'y rien comprendre.
Bref principe retenu : Chaque roue dispose d'un compteur d'impulsions (24/tours).
La consigne de vitesse est fixée à 40 RPM; le contrôle de trajectoire est effectué dans la tâche 200ms.Je génère donc une consigne de totalisateur roue théorique y compris pendant accélération (3RPM/s) ou décélération.C'est ce totalisateur qui est comparé avec chaque compteur de roue. Cette erreur (signée) est traitée en PI avec KP=2 et KI=1 (pour l'erreur cumulée). A l'ensemble j'ajoute la valeur grossière nécessaire (c'est là que je ne comprends pas tout Help BT). Mais le résultat est correct. Par radio, je reçois les valeurs et je constate que l'erreur est très faible(qq unités).
Il était intéressant de constater l'apport de l'action intégrale.
Donc Merci encore pour les conseils.
Pour info j'ai aussi constaté que les calculs en float étaient très gourmands: je suis à 90% de mes 4K, j'ai donc commander des 16f767 compatibles PIN à PIN mais disposant de 8k

[Black Templar]

Cette erreur (signée) est traitée en PI avec KP=2 et KI=1 (pour l'erreur cumulée).

Hum... à première vue, si tu ne travailles qu'avec des entiers, 2 pour Kp et 1 pour Ki ne ssemble pas très précis. Quel a été ta démarche pour les déterminer ?
(Pourquoi ne pas utiliser les float (même si ça consomme plus de CPU)

A l'ensemble j'ajoute la valeur grossière nécessaire (c'est là que je ne comprends pas tout Help BT). Mais le résultat est correct.

/> c'est à dire ?
Tu fais un truc du genre
commande = Kp*erreur + Ki*somme_erreur + constante ?

Dans ce cas, c'est que tes coef sont mal réglés car la constante est inutiles.

[hmnrobots]

Hum... à première vue, si tu ne travailles qu'avec des entiers, 2 pour Kp et 1 pour Ki ne ssemble pas très précis. Quel a été ta démarche pour les déterminer ?
(Pourquoi ne pas utiliser les float (même si ça consomme plus de CPU)

D'abord plus de place en mémoire, j'ai fait le ménage et utilisé des variables locales.J'attends de recevoir le nouveau proc pour ré-écrire qu'avec des floats. Je me suis donc rabattu sur les integers en procédant par essais multiples (beaucoup). Mais honnêtement le résultat est pas mauvais; l'erreur est maintenue à moins de 3 impulsions.

/>/> c'est à dire ?
Tu fais un truc du genre
commande = Kp*erreur + Ki*somme_erreur + constante ?
Dans ce cas, c'est que tes coef sont mal réglés car la constante est inutiles.

La "constante" n'est pas une constante mais la consigne de vitesse (croissante pendant l'accélération) c'est vrai que ça parait bizarre ...

[Black Templar]

Je me suis donc rabattu sur les integers en procédant par essais multiples (beaucoup). Mais honnêtement le résultat est pas mauvais; l'erreur est maintenue à moins de 3 impulsions.

Si le résultat final est bon, tant mieux.
Sinon, tu peux mettre l'intégrateur à 0 et régler le proportionnel afin d'avoir une erreur statique environ égal à 5% de la consigne.
Une fois le kp déterminé, tu règles le ki pour annuler l'erreur statique en un temps raisonnable.

La "constante" n'est pas une constante mais la consigne de vitesse (croissante pendant l'accélération) c'est vrai que ça parait bizarre ...

Hum... Normalement, tu n'as bas besoin d'ajouté cette consigne car elle apparait implicitement dans le calcul de l'erreur.

erreur = consigne - mesure
somme_erreur += erreur

[hmnrobots]

Si le résultat final est bon, tant mieux.
Sinon, tu peux mettre l'intégrateur à 0 et régler le proportionnel afin d'avoir une erreur statique environ égal à 5% de la consigne.
Une fois le kp déterminé, tu règles le ki pour annuler l'erreur statique en un temps raisonnable.

C'est comme ça que j'ai procédé, par la suite l'ajout de la correction intégrale a quasiment annulé l'erreur.
le fait est que la consigne de départ est assez rapidement évolutive pour le peu d'impulsions.En régime établi, quand la vitesse de croisière est atteinte, l'erreur devient quasiment nulle mais il reste malgré tout une certaine oscillation lente (plusieurs secondes 3 à 5).
Peut être devrais je passer à 100ms ?

Hum... Normalement, tu n'as bas besoin d'ajouté cette consigne car elle apparait implicitement dans le calcul de l'erreur.

erreur = consigne - mesure
somme_erreur += erreur

Bon on va dire que c'est une nouvelle façon de faire que je viens d'inventer : une révolution!

[Black Templar]

En régime établi, quand la vitesse de croisière est atteinte, l'erreur devient quasiment nulle mais il reste malgré tout une certaine oscillation lente (plusieurs secondes 3 à 5).
Peut être devrais je passer à 100ms ?

Je ne pense pas non. Passer à 100ms, pour 40RPM et 24ipt, ça te fais du 16 imp/s et donc entre 1 et 2 impulsions toutes les 100ms, ce qui est trop peu pour avoir un truc propre.
Pour le moment, avec 200ms, tu dois avoir environ 3 imp par boucle, ce qui n'est pas beaucoup, mais déjà un peu mieux.

Je te conseillerai de faire un test à 500ms pour voir (8imps). (attention, changer la fréquence d'asservissement implique de changer aussi le coefficient intégrateur ! (si tu double la fréquence, tu divise par 2 ton ki)

Bon on va dire que c'est une nouvelle façon de faire que je viens d'inventer : une révolution!

Certes, mais j'ai du mal à interpréter mathématiquement ce que tu as fais.
En gros, tu as : commande = kp.e + ki.somme(e) + consigne
commande = kp.(consigne-mesure) + ki.somme(consigne-mesure) + consigne
commande = kp.(consigne.(1+1/kp)-mesure) + ki.somme(e)

Ce qui veut dire que pour le proportionnelle, tu considères que ta consigne est plus grande que celle définie (dans ton cas 50% plus grande !).
Tu asservis donc non pas par rapport à la consigne, mais par rapport à consigne.(1+1/kp)
Donc, si on fait abstraction de l'intégrateur, si ta commande est à peu près bonne par rapport à la consigne, c'est que le kp est trop faible par rapport à consigne.(1+1/kp)
Ensuite, en rajoutant l'intégrateur, tu vas corriger l'erreur restante non pas par rapport à consigne.(1+1/kp), mais bien par rapport à la consigne.

Donc oui, ça marche, mais ça ne sert à rien.
Autant utiliser la vraie formule du PI : commande = kp.(consigne-mesure) + ki.somme(consigne-mesure)
Et de bien régler le kp du premier coup (dans ton cas, si tu n'ajoute pas le terme constant, ton coef kp devra être plus grand qu'à présent)

(pour t'en convaincre, essayer de faire un dessin en traçant le comportement de ta commande juste avec le terme proportionnel)

[hmnrobots]

Je ne pense pas non. Passer à 100ms, pour 40RPM et 24ipt, ça te fais du 16 imp/s et donc entre 1 et 2 impulsions toutes les 100ms, ce qui est trop peu pour avoir un truc propre.
Pour le moment, avec 200ms, tu dois avoir environ 3 imp par boucle, ce qui n'est pas beaucoup, mais déjà un peu mieux.

Je te conseillerai de faire un test à 500ms pour voir (8imps). (attention, changer la fréquence d'asservissement implique de changer aussi le coefficient intégrateur ! (si tu double la fréquence, tu divise par 2 ton ki)



Certes, mais j'ai du mal à interpréter mathématiquement ce que tu as fais.
En gros, tu as : commande = kp.e + ki.somme(e) + consigne
commande = kp.(consigne-mesure) + ki.somme(consigne-mesure) + consigne
commande = kp.(consigne.(1+1/kp)-mesure) + ki.somme(e)

Ce qui veut dire que pour le proportionnelle, tu considères que ta consigne est plus grande que celle définie (dans ton cas 50% plus grande !).
Tu asservis donc non pas par rapport à la consigne, mais par rapport à consigne.(1+1/kp)
Donc, si on fait abstraction de l'intégrateur, si ta commande est à peu près bonne par rapport à la consigne, c'est que le kp est trop faible par rapport à consigne.(1+1/kp)
Ensuite, en rajoutant l'intégrateur, tu vas corriger l'erreur restante non pas par rapport à consigne.(1+1/kp), mais bien par rapport à la consigne.

Donc oui, ça marche, mais ça ne sert à rien.
Autant utiliser la vraie formule du PI : commande = kp.(consigne-mesure) + ki.somme(consigne-mesure)
Et de bien régler le kp du premier coup (dans ton cas, si tu n'ajoute pas le terme constant, ton coef kp devra être plus grand qu'à présent)

(pour t'en convaincre, essayer de faire un dessin en traçant le comportement de ta commande juste avec le terme proportionnel)

Super, j'aime cette démonstration!
il faut garder en tête que en fait je calcule une vitesse théorique (évolutive pendant l'accélération) et que de là je calcule un nombre total d'impulsion requise et que c'est lui que je compare avec le compteur d'impulsion de roue; cette différence fournit l'erreur.

La consigne de vitesse sert à calculer une consigne de compteur totalisateur (c'est pas déjà une intégration ça?). pour un vrai calcul de vitesse des roues, je pense que j'ai trop peu d'impulsions par tour et que l'acquisition se faisant sur le PCF bien que sous interruption n'est pas instantanée.l'objectif étant d'aller globalement droit, il m'importe que les compteurs roues soit maintenues identiques. Dans la version 5, c'est ce que je faisais.

Il est marrant de noter (et on dirait que la démonstration le confirme) que pour un ordre de 40 RPM la commande envoyée au sabertooth (le module pilote des moteurs) est d'un peu plus de 60.
Quand j'aurai le nouveau proc avec plus de rom je ferai de nouveaux essais

[hmnrobots]

Test dans la rosée matinale qui permet de visualiser la trajectoire. Compte tenu des irrégularités du terrain je trouve ce résultat satisfaisant .
 V6 003.jpg   1,2 Mo   31 téléchargement(s)

[geek maxou]

Test dans la rosée matinale qui permet de visualiser la trajectoire. Compte tenu des irrégularités du terrain je trouve ce résultat satisfaisant .
 V6 003.jpg   1,2 Mo   31 téléchargement(s)

Bravo !
Je te suis sur ton blog

Bon courage pour la suite,
GeekMaxou

[Black Templar]

Jolie

[hmnrobots]

Merci à vous;
Une fois lâchée je l'ai laissé et elle a bossé pendant 1h10 totalement autonome avec sa nouvelle batterie LIFEPO4 (J'en parlerai dans le sujet énergie).