138 réponses à ce sujet

[Astondb8]

Bonjour,

Je viens vers vous aujourd'hui pour une question.

Avant de passer au bras articulé, je souhaiterais régler les odomètres. Mais pour cela, j'ai besoin d'une méthode.
J'ai entendu parler d'une méthode qui consiste à faire faire à mon robot des carrés.

- Tout droit sur une distance x
- Tourner à droite de 90
- Tout droit sur cette même distance X
- Tourner à droite de 90°
- Etc.

Au bout d'un certain nombre de passage, il va forcement y avoir de la dérive. Cette dérive deviendrait une constante prendre en compte dans le calcul de position.

Voilà pour la théorie. Mais qu'en est il de la pratique ,
Comment prendre cette dérive en compte dans le code pour calculer ma position de façon plus précise ?

C'est une méthode, Mais il y en a sans doute d'autres.
Quelle est la méthode que vous utilisez ?

J'ai parcouru un lien sur Pobot je crois qui parlait de ce sujet mais impossible de mettre la main dessus.
Donc soit vous avez le lien, soit vous vavez comment appliquer cette méthode, soit vous utiliser une méthode fiable mais laquelle ?
Et même si je retrouve ce lien, je serais intéresse par d'autres méthodes.

Merci pour vous réponses.

Cdlt
Yves

[Leon]

Si la mécanique est bien réalisée (pas besoin d'être parfaite) c'est à dire si les 2 roues sont parallèles, et qu'elles ont le même diamètre, alors il n'y a pas besoin de s'embêter à faire des carrés. Les carrés peuvent servir de test pour vérifier que tout fonctionne bien, c'est tout.

Il n'y a que 2 paramètres à régler pour faire de l'odométrie: le premier qui est lié à la circonférence des roues, et permet de déterminer l'avancement en fonction de la moyenne des tops lus sur les 2 roues. Le deuxième paramètre est lié à la circonférence et l'écartement des roues; il permet de déterminer l'orientation en fonction de la différence d'avancement des 2 roues.

Pour régler le 2ieme paramètre (qui est de loin le plus essentiel), j'ai une méthode très simple, mais diablement efficace et précise : je fais faire à mon robot 5 ou 10 tours sur lui même. En le pilotant en "manuel", avec une vitesse la plus faible possible. La lecture de l'avancement des 2 roues permet de déterminer le paramètre en question. Et il est nécessaire de re-régler ça si tu touches à la mécanique.

Leon.

[arobose]

Hello Yves et Leon,

Pour compléter la réponse de Leon (que je vais conserver et tester rapidement car elle a l'air simple et efficace), voici un tuto très complet pour réaliser une calibration de l'odomètrie d'un robot mobile (C'est en anglais) : http://www-personal.umich.edu/~johannb/Papers/umbmark.pdf.

Bon WE.

Arobose.

[Astondb8]

Merci à vous pour ces infos,

Mais pour le moment, je rame pas mal avec le code de localisation...

Pas simple cette histoire. Mais une fois fait, cela sera un véritable plaisir.
Et puis, je rame certes, mais chaque ligne de code est une nouvelle satisfaction.
Heureusement que je ne suis pas seul, mais je dois y arriver par moi même.
Donc le jeux est de chercher. Si je suis a coté on m'aide à revenir dans les clous.
Mais pas question que l'on me donne un code tout fait qui ne m'apprendrait rien.

Aller courage Je vais y arriver.....

Cdlt
Yves

[Astondb8]

Bonjour,

Juste un petit message pour vous parler de la technique que j’utilise.

En fait, je n’étais pas tout à fais prêt à faire des calculs de réglages car les constantes de roues et de codeurs n’étaient pas réglées.

En effet, je devais d'abord définir plusieurs choses

- Le périmètre de mes roues
- Le nombre de Tick par tour de codeur
- La distance séparant les deux roues (celles qui entrainent les codeurs pour ceux qui auraient des codeurs indépendants des moteurs)

Les constantes que je dois renseigner correspondent à ces lignes dans le code :

#define TICK_PER_MM_LEFT 90.9456817668 // Périmètre divisé par le nombre de Ticks pour la roue gauche
#define TICK_PER_MM_RIGHT 90.9456817668 // Périmètre divisé par le nombre de Ticks pour la roue droite
#define DIAMETER 164.5 // Distance entre les roues (en millimètre)

#define TWOPI 6.2831853070 // Pi * 2
#define RAD2DEG 57.2958 // conversion de radiants en degrés

Le Périmètre de mes roues est simple à trouver.
Périmètre = Diamètre * Pi
Mes roues font 70mm de diamètre mon périmètre est donc de 219.912mm

Dans mon cas, ça se complique pour le nombre de Tick par tour de codeur.
En effet, normalement, cette information se trouve dans le datasheet des moteurs ou celui des codeurs.
Hors, je n'ai pas trouvé cette information sur aucun des documents concernant mes moteurs ou mes codeurs. Il a donc fallu que je trouve une solution.
Car sans cette constante, impossible de faire le moindre calcul de position.

Dans le code, il y a un compteur qui compte le nombre de tik lors des déplacements du robot. J'ai donc utilisé ce compteur.

Dans le code, la valeur retournée par ces compteurs se trouve dans deux variables (une par codeur)

volatile long left_cnt = 0;
volatile long right_cnt = 0;

Mais comment les compter de façon précise ? Car la moindre erreur nous donnerais invariablement un mauvais calcul.

J'ai donc monte la manipe suivante.

- Débranche mes deux moteurs sans débrancher l'alimentation des codeurs
- Désactive les PWM de mon code et les mettant en commentaire
- Aouté dans le code les lignes suivantes pour monitorer cette variable.
Serial.print("left_cnt : ");
Serial.println(left_cnt);
- Mis un repaire sur une roue et un autre repère juste en face sur le châssis du robot (Voir photo)
- Remis le compteur à zéro
- Positionné les deux repères face à face
- Puis, j'ai fait tourner la roue d'un tour en revenant exactement dans la position ou les deux repères sont face à face
Il ne suffisait donc plus qu'à lire sur le serial monitor la valeur retournée et donc le nombre de Ticks que le codeur comporte.
Pour m’assurer du résultat, j'ai renouvelé l'opération plusieurs fois pour être certain que j'obtenais le même résultat à chaque fois.
J'ai également renouvelé l'opération pour l'autre codeur (en changeant bien sur la ligne de code et monitorer l'autre variable).

Serial monitor avec la variable à 0



Positionnement des repérés



Serial monitor avec le nombre de Tiks pas tour sur mes codeurs



Voilà j'ai le nombre de Ticks il me reste à diviser le périmètre par le nombre obtenu

Pour l’écart entre les deux roues, je dois bien sur sortir mon réglet.

Il me faut encore contrôler la précision de ce montage.
Le 1er test à faire, est de faire deux marques au sol espacées d'une distance fixe. (moi j'ai pris 60 Cm car c'est la taille de ma table.
J'ai donc fait deux marques sur ma table espacées de 60 CM. Il me faut également monitoré la variable pos_X qui contiens le calcul de la distance parcourue et comparé si cette variable me donne bien 60 Cm quand après avoir poussé mon robot d'une marque à l'autre.

Le dernier test à faire, est le contrôle de l'angle (quand le robot tourne et donc connaitre l'ange sur lequel il a tourné). Cette valeur est contenue dans la variable "théta"
J'ai tracé sur ma table deux droites qui se croisant avec un angle de 90°J'ai positionné la roue droite de mon robot sur une des ligne ligne et fait tourner mon robot autour de la roue gauche jusqu'au moment ou la roue droite se positionne sur l'autre marque.
La variable theta doit me retourner 90.

Voila, je suis prêt

[Leon]

Comme je te l'ai conseillé juste avant, il est beaucoup plus judicieux de :
1) travailler avec plus qu'1 seul tour: avec 10 tours de roues par exemple, ta constante sera 10 fois plus précise qu'avec 1 seul tour
2) déterminer la constante d'écart entre les 2 roues en faisant tourner le robot 10 fois sur lui même.

Déterminer la constante d'écart par une simple mesure directe est assez optimiste, je ne pense pas que tu puisse obtenir de résultat satisfaisant ainsi.

Leon.

[Astondb8]

Merci pour ce conseil Léon

En fait, tu me conseil de faire la même chose mais en faisant faire 10 tours puis de diviser mon résultat pas 10.

Oui, en effet, tu as raison. Le résultat sera bien plus précis qu'avec un seul tour.
Bon si je comprends bien, je dois recommencer

Mais si le résultat est plus précis et plus fiable, cela en vaut la peine.
Comme j'ai les résultats pour un tour, nous verrons bien qu'elle est l’écart obtenu entre les deux méthodes.

Merci

Cdlt
Yves

[Astondb8]

Bon voila mon robot est étalonné. .
Merci a Leon et Julien et Eric pour leurs conseils, mais siutout à Jo qui suit mon projet et sans qui mes connaissances ne seraient que théoriques.

Donc revenons à ces tests.
J'ai reussis à obtenir une precision de 3 à 5 dixièmes de millimètres en distance sur un étalon de 60Cm et de 5 à 8 dixièmes de radians pour la direction.

Effectivement, les resultats obtenus aux 1er tes basés sur un seul tour est bien différent de celui que j'obtenais en faisant 10 tours et en divisant par 10. Du reste, ces resultats étaient contraire a toute logique. Car mes réducteur étant de 1:53 je ne pouvais pas avoir 630 Ticks par tour. Par contre, 636 est en resultat parfaitement logique.

Reste la partie la plus complexe pour moi, lui commander des déplacements à distances fixes pour commencer les tests dynamiques.

Je vous tiens bien sur infirmé de l'évolution du projet.

Cdlt
Yves

[Jbot]

J'ai reussis à obtenir une precision de 3 à 5 dixièmes de millimètres en distance sur un étalon de 60Cm et de 5 à 8 dixièmes de radians pour la direction.

Heuu, 5 à 8 dixieme de radian c'est énorme comme erreur, ca représente 45degrés d'erreur la.
Deja 8centieme ca serait limite trop.

Corrige ça avant de passer a la suite, c'est plus prudent.

[Astondb8]

Heuu, 5 à 8 dixieme de radian c'est énorme comme erreur, ca représente 45degrés d'erreur la.
Deja 8centieme ca serait limite trop.

Corrige ça avant de passer a la suite, c'est plus prudent.

Merci Jibot

Mais je pense que c'est dans mon message que je me suis trompé.
En fait ce sont des degrés puisque je passe par cette ligne

#define RAD2DEG 57.2958

Qui vas permettre de transformer les Radiants en degrés..

Sauf erreur de ma part.
Et une erreur de 45° sur une rotation de 90° oui c'est énorme. Mais trop loin pour être réaliste.

dlt
Yves

[Astondb8]

Bon voila ou j'en suis

J'en suis à essayer de lui commander d'aller a un point precis (x, y) et qu'il s'y arrête.

Pas simple car j'ai quelques problemes de réglage du PID.

Il essais d'aller à ce point, mais comme il n'arrive pas à le trouver avec precision, il ce lance dans une danse incessante qui ce traduit par de petits virages à droite suivies de petits virages à gauche et ainsi de suite.

J'espere que ce n'est pas la base elle même qui n'est pas suffisamment precise pour y parvenir.

Je tente donc pas à pas de régler les valeurs du PID ainsi que celles de sa de decceletation et sans doute accélération.
Il arrive à se rendre sans probleme à un point qui ne nécessite pas de virage, mais son arrêt est un peux brutal.

Je ne doute pas d'y parvenir enfin, mais les tâtonnements sont un peux fastidieux.
Apres ça, l'opération suivante sera de lui faire faire une boucle de carrés afin de voir si a chaque carre il repasse bien par les mèmes points.

Ensuite, lui integrer des capteurs d'environnement pour détecter les obstacles et lui indiquer comment il doit réagir.

Ensuite …

Je ne suis pas tres rapide, mais je découvre à chaque pas une difficulté supplémentaire. Mais chaque pas me permet d'apprendre à les résoudre.
Celà dit, je ne suis même pas certain que mon prochain projet se réalisera Plus rapidement, car d'autres difficultés apparaitrons. Difficultés qu'il faudra aussi apprendre à résoudre.

Cdlt
Yves

[Leon]

Pas simple car j'ai quelques problemes de réglage du PID.

Ca, les PID, c'est souvent chiant à régler.
Tu peux nous donner plus de précision, stp, pour qu'on puisse éventuellement t'aider?

Est-ce que tu as programmé ton PID tout seul, ou alors est-ce que tu as repris quelque chose d'existant?

A quelle fréquence tourne ton asservissement?

Qu'est-ce que ton PID asservit? L'avancement de chaque roue? Ou alors l'orientation et l'avancement général du robot (ce que je préconise)?
Est-ce que le robot essaye de suivre une trajectoire pré-définie? Ou alors est-ce qu'il recalcule en permanance l'erreur en fonction de la position actuelle (X-Y) et de la cible (ce que je préconise)?

Pour finir, est-ce que tu as bien mis une partie qui "lisse" les consignes en temps réel, avec des rampes d'accélération et de décélération?

J'espere que ce n'est pas la base elle même qui n'est pas suffisamment precise pour y parvenir.

C'est rarement le cas. Même une base pas terrible peut être asservie. Avoir du jeu et des frottements, ça pénalise l'asservissement, ça le rend moins facile à régler et/ou moins performant. C'est tout.

Leon.

[Astondb8]

Bonjour Léon,

Comment répondre à ces questions ?

En fait, je peux sans problème répondre à la 1ere.
J'utilise un code tout fait. C'est le tuto qu'a fait Jbot sur son Robot Maximus.


Je dois avouer avoir pas mal de difficultés à comprendre l'ensemble des algorithmes qu'il a developpées. Ce que je peux te dire, c'est que Sans son aide je n'en serais pas là.

Je le mets du reste fort à contribution j’essaie donc de comprendre un certain nombre de choses et tacher de me débrouiller seul. De toutes façons, Il me donne des pistes et pas les solutions toutes cuites. (c'est du reste la raison pour laquelle je rame autant).
Bien sur si je ne comprend vraiment pas il ne me laisse pas en carafe, mais il y a certaines choses (notamment pour les réglages) ou il faut voir ce qui se passe pour apporter des changements appropriés. Cela n'est réellement possible qu'en voyant les réactions du robot.


Toutefois, je ne serais pas contre ton avis et tes conseils. (tu es comme quelque un ici d'une aide précieuse).


Sinon, pour la fiabilité de la base, je me suis rendu compte hier que mes roues n’étaient pas exactement parallèles. Il est évident que cela n'aide pas un réglage de PID optimum et facile.

Pour l'opération suivant, (passer à l'étage supérieur) je vais devoir refaire la base entièrement. Elle a pour le moment 27Cm de diamètre et pour mettre mon bras je vais devoir l'agrandir. autre raison qui m'oblige à agrandir le diamètre de la base roulante, c'est que je vais changer mes moteurs et mes codeurs.
En effet, je vais monter des codeurs indépendant pour ne pas être sujet a une perte de précision due aux dérapages.

Par contre, je ne vais faire ces changement qu’après avoir terminé cette base. Cela me permettra de faire directement les bons plans de fabrication aux bonnes mesures sans passer (comme c'est le cas avec celle ci) par tellement de modifications que ce n'est plus une base mais un véritable Gruyère.

Voilà, si tu as des conseils a me donner en plus de ceux de Jo, tu es le bienvenu.

Cdlt
Yves

[Black Templar]

Salut !

Personnellement, je te conseil de ne pas faire un asservissement en position !
Les asservissements en positions ne sont pas très précis. Il vaut mieux faire un asservissement en vitesse qui est beaucoup plus précis.
EDIT : j'ai raconté n'importe quoi, dsl...

Ensuite, pour aller à un point donnée, je te conseil d'utiliser un algorithme de planification de trajectoire qui se chargera de calculer la vitesse de tes roues afin d'arriver à la position voulue.
D'une part, tu pourras ainsi régler toi même la phase de décélération lorsque tu approche de l'obstacle et d'autre part, ça te permettra ensuite de modifier l'algo de planification pour éviter les obstacles par exemple.

Si tu garde un asservissement en position, ton algo de planification de trajectoire devra envoyer à l'asservissement une série de points de passages et non des vitesses. Ce qui est beaucoup plus difficile si tu veux respecter les contraintes cinématiques du robot (accélération max, vitesse max, vitesse angulaire max, etc.)

Pour plus de précisions, en plus de l'asservissement et de la planification de trajectoire, tu peux implémenter un algo de suivi qui se charge de vérifier que l'asservissement suit exactement la trajectoire fournis par l'algo de planification (mais cette pahse de suivi n'est pas obligatoire)


++
Black Templar

[Leon]

Yves, il vaut mieux attendre de l'aide de Jbot, puisque tu as repris sa solution.

Personnellement, je te conseil de ne pas faire un asservissement en position !
Les asservissements en positions ne sont pas très précis. Il vaut mieux faire un asservissement en vitesse qui est beaucoup plus précis.

Désolé, je ne te comprend pas du tout. Si tu fais un PID sur la position, qu'est-ce qui n'est pas précis? Pour information, c'est comme ça que fonctionnent 99% des robots industriels, qui sont monstrueusement précis et rapides.

Ensuite, pour aller à un point donnée, je te conseil d'utiliser un algorithme de planification de trajectoire qui se chargera de calculer la vitesse de tes roues afin d'arriver à la position voulue.
D'une part, tu pourras ainsi régler toi même la phase de décélération lorsque tu approche de l'obstacle et d'autre part, ça te permettra ensuite de modifier l'algo de planification pour éviter les obstacles par exemple.

Je ne comprend toujours pas. Tu peux très bien faire tout ça avec un asservissement en position. Il suffit (comme je l'évoquais dans mon post précédent) de construire des rampes d'accélération et de décélération. D'ailleurs, en Automatique, on apprend à construire une consigne REALISTE en entrée de l'asservissement, c'est indispensable pour faire un asservissement robuste. Ici, réaliste veut dire que la consigne de position évolue à une vitesse réaliste, et à une accélération réaliste, selon les performances atteignables par ton robot.

Si tu garde un asservissement en position, ton algo de planification de trajectoire devra envoyer à l'asservissement une série de points de passages et non des vitesses. Ce qui est beaucoup plus difficile si tu veux respecter les contraintes cinématiques du robot (accélération max, vitesse max, vitesse angulaire max, etc.)

C'est plus simple que tu ne le penses. Tu n'as pas besoin de manipuler des trucs compliqués, pour calculer "à l'avance" ta trajectoire (tes points de passage). A partir de la position et orientation 2D courante de ton robot, tu fais évoluer en temps réel tes consignes de manière crédible pour atteindre ta cible.

Leon.

[Astondb8]

Ca y est, le PID est enfin réglé

Assez propre au démarrage
Un poil brutal au freinage.
Mais cela reste donc perfectible.

Pour la solution utilisée par Jo (et donc celle mise en Place sur SAMU est celle préconisée par Léon.
Ne me demandez pas de commenter ou de rentrer dans ce discourt d'experts, j'en serais bien incapable.


Cdlt
Yves

[Black Templar]

Désolé, je ne te comprend pas du tout. Si tu fais un PID sur la position, qu'est-ce qui n'est pas précis? Pour information, c'est comme ça que fonctionnent 99% des robots industriels, qui sont monstrueusement précis et rapides.

Il m'avait semblé lire ceci il n'y a pas longtemps. J'ai retrouvé l'article qui parlait de ça et en fait, ça n'a rien à voir du tout... En fait, ça parlait du nombre d'intégrateur indispensable pour annuler les erreurs en position, en vitesses ou en accélération... rien à voir...
Info complétement erroné, merci de m'avoir corrigé j'aurais du vérifier mes dires avant de poster :/

Je ne comprend toujours pas. Tu peux très bien faire tout ça avec un asservissement en position. Il suffit (comme je l'évoquais dans mon post précédent) de construire des rampes d'accélération et de décélération. D'ailleurs, en Automatique, on apprend à construire une consigne REALISTE en entrée de l'asservissement, c'est indispensable pour faire un asservissement robuste. Ici, réaliste veut dire que la consigne de position évolue à une vitesse réaliste, et à une accélération réaliste, selon les performances atteignables par ton robot.

Mais alors comment fais-tu pour gérer les vitesses si tu asservis en position ? Tu parles de consigne réaliste, mais si tu ne manipule que des positions, comment peux-tu gérer convenablement la vitesse à laquelle tu dois faire tourner les roues pour que ça soit réaliste ??
J'avoue que je ne comprends pas trop. Tu as une commande qui est une position, une mesure que est aussi une position. L'erreur est donc une erreur de position, tu passes l'erreur dans le PID pour en déduire la commande en vitesse à envoyer aux roues. Où se trouve les rampes d'accélérations et de décélération ici ?

C'est plus simple que tu ne le penses. Tu n'as pas besoin de manipuler des trucs compliqués, pour calculer "à l'avance" ta trajectoire (tes points de passage). A partir de la position et orientation 2D courante de ton robot, tu fais évoluer en temps réel tes consignes de manière crédible pour atteindre ta cible.

Hum... ça me parait tellement compliqué de faire comme ça. Je pense que je vais tester tout ça pour démystifier l'asservissement en position !
Et encore un nouveau projet à réaliser


++
Black Templar

[Astondb8]

Vous vous doutez bien que je ne peux que compter les points...

Il m'est aujourd'hui impossible de vous départager. Cela dit chez moi ca marche. Pourquoi, comment, ne me le demander pas.
Mais ce qui est certain c'est que cette méthode est plutôt fiable.

Peut être que Jbot vous apportera des élément sur sa technique. Ce qui est sur, c'est que j'en apprendrais plus sur le fonctionnement de mon robot

Cdlt
Yves

[Leon]

Mais alors comment fais-tu pour gérer les vitesses si tu asservis en position ? Tu parles de consigne réaliste, mais si tu ne manipule que des positions, comment peux-tu gérer convenablement la vitesse à laquelle tu dois faire tourner les roues pour que ça soit réaliste ??

Même si tu élabore une consigne de position, tu peux (dois) prendre en compte la vitesse maxi souhaitée dans l'élaboration de cette consigne. Pour perfectionner encore plus, tu peux intégrer un critère d'accélération (vitesse trapézoidale). Si tu n'intègres que la vitesse, alors ta consigne à un instant t+1 sera la consigne à l'instant t : vitesse x delta_t.

Il faut bien voir que si tu met un PID qui asservit une position, alors automatiquement le terme dérivé asservit la VITESSE! Tu es obligé de calculer et de prendre en compte l'erreur sur la vitesse.

Il y a des applications où on veut un PID sur la vitesse directement. C'est utilisé quand tu veux asservir la vitesse de rotation d'une machine tournante (machine outil, groupe électrogène), alors que la position n'a pas besoin d'être précise. Dans ce cas, le terme proportionnel est la vitesse, et le terme dérivé est l'accélération. Tout à l'heure, quand tu parlais d'asservissement en vitesse, je pensais que tu parlais de ça, mais ça n'est pas adapté pour un robot qui doit se déplacer précisément.

J'avoue que je ne comprends pas trop. Tu as une commande qui est une position, une mesure que est aussi une position. L'erreur est donc une erreur de position, tu passes l'erreur dans le PID pour en déduire la commande en vitesse à envoyer aux roues. Où se trouve les rampes d'accélérations et de décélération ici ?

Encore une fois, un vrai asservissement n'est pas seulement un PID. Il y a autre chose autour. Il faut en plus injecter EN ENTREE du PID une consigne réaliste. Par exemple, si tu veux que ton robot se déplace 10m plus loin, tu ne vas pas directement envoyer [position_depart + 10m] instantanément comme consigne en entrée de ton PID. Un PID n'est pas fait pour ça, et ne peut que suivre des consignes réalistes. Tu vas créer une consigne réaliste [position départ + V_cible x (t - t0)]. Donc même si tu asservi en position, tu prend en compte la vitesse réaliste (ta vitesse cible).

Voici un graphique d'asservissement en altitude de mon drone. Les trais propre, ce sont les consignes (vitesse et position). J'utilise un PID en position. Le terme proportionnel, c'est la position, le dérivé, c'est la vitesse. Ici, tu as même des rampes "trapézoidales" de vitesse (pas à la décélération), ce qui constitue la consigne de position et de vitesse REALISTE, qui prend en compte les capacités du drone.

Leon.

Image(s) jointe(s)

• 

[Black Templar]

Merci Léon pour ces explications, c'est plus clair pour moi maintenant !

Vous vous doutez bien que je ne peux que compter les points...

Il n'y a pas de match ici