Planete Sciences

Bonjour,
éviter, c'est bien, ne pas se prendre de mur, c'est idéal, mais quand ça arrive, on crame un moteur.
Je cherche une méthode propre et si possible simple pour détecter un blocage de roue. J'ai un robot avec de l'odométrie, il a 2 roues, j'ai de manière temporellement locale: position du robot, des roues, leurs vitesses, leurs accélérations, etc.
Détecter une vitesse à 0 alors que la puissance est non nulle ne me semble pas suffisant: déjà parce que s'il n'y a pas assez de puissance, et que le robot est immobile, ça peut-être normal. Ensuite parce que les roues peuvent légèrement et doucement patiner, auquel cas, on ne détecte pas le blocage.
On peut aussi mettre des fins de course partout, mais j'aimerai faire mieux.

Le mieux que j'ai comme idée est de faire un filtre RII passe-bas sur la somme des puissance(positives) envoyée aux moteurs,un filtre passe-bas RII sur l'acceleration des roues, et si le rapport est trop faible, je considère qu'il y a blocage. Mais je ne suis pas convaincu de mon idée.
Est-ce que vous savez s'il y a des documents d'équipes sur le sujet? avez-vous de bonnes idées?
merci

Salut !

H0x7d0 wrote: ↑

Mon 21 Jan 2019, 15:33

J'ai un robot avec de l'odométrie, il a 2 roues, j'ai de manière temporellement locale: position du robot, des roues, leurs vitesses, leurs accélérations, etc.

Juste pour être sur d'avoir bien compris, tu as un odométrie avec roues codeuses indépendantes des moteurs, ou seulement mesure sur les moteurs, ou les deux ?

H0x7d0 wrote: ↑

Mon 21 Jan 2019, 15:33

On peut aussi mettre des fins de course partout, mais j'aimerai faire mieux.

Partout, c'est probablement un peu trop, mais en laisser un bien placé devant voire derrière, c'est pas compliqué et ça peut régler quelques problèmes facilement.

H0x7d0 wrote: ↑

Mon 21 Jan 2019, 15:33

Le mieux que j'ai comme idée est de faire un filtre RII passe-bas sur la somme des puissance(positives) envoyée aux moteurs,un filtre passe-bas RII sur l'acceleration des roues, et si le rapport est trop faible, je considère qu'il y a blocage. Mais je ne suis pas convaincu de mon idée.
Est-ce que vous savez s'il y a des documents d'équipes sur le sujet? avez-vous de bonnes idées?
merci

La question que je me pose est la façon dont tu calcules la consignes à ta moteurs.
Dans le cas où tu planifie une trajectoire, pour faire simple une grande droite de 2 mètres de long, avec vitesse en trapèze, cela veut dire que a tout moment tu sais où doit être ton robot par rapport à cette trajectoire précalculée. Comme la trajectoire a été calculée avec des paramètres physiquement réalisables (vitesses/accélération inférieurs au maxi réalisable par le robot), le robot va pouvoir suivre la trajectoire précisément quand tout va bien, et tout blocage, patinage, déjantage... va avoir un effet sur l'erreur entre la position actuelle du robot et celle qu'il aurait du avoir. Un simple seuil de 5, 10... 20 cm selon la précision de ton contrôle et tu as une détection de défaut couvrant un peu tout ce qui peut se passer.

C'est aussi applicable sur un moteur seul, si tu le regarde en position et pas en vitesse. En position, tu regarde l'intégrale de la vitesse, donc une une erreur faible va s'amplifier au cours du temps, et devenir visible. Dans le cas de l’accélération d'un moteur en rampe, comme tu l'avais mentionné, au début, la puissance n'est pas suffisante pour faire bouger le moteur, et la position (ou l'angle comme tu préfères) théorique continue d'augmenter, puis l'asserv fini par faire décoller le moteur et rattraper la consigne. Si le moteur ne décolle pas, l'angle théorique augmente sans que l'angle réalisé ne bouge, et lorsque tu atteinds le seuil critique, ça part en erreur.

Et tu peux avoir les 2 : seuils "serrés" sur les moteurs, pour être très réactifs sur un blocage ou gros effort sur roue, et seuil plus large sur la position du robot, permettant de détecter patinage et autre collision avec élément de jeu qui fait dévier le robot.


Si en revanche tu ne calcules pas de trajectoire, mais à un simple asserv sur une consigne de cap, ou asserv polaire, c'est plus difficile à mettre en place, mais il est possible de même de faire une notion de "gabarit" au niveau de la vitesse*.


Enfin ce n'est qu'une solution...

Nous on a un asservissement polaire. Le cap et la distance a l'objectif ont chacun une rampe en vitesse accélération, ce qui nous permet de connaître à chaque moment la valeur "attendue" et la valeur réelle de l'erreur de cap et de distance. Quand la différence entre attendu et réel dépasse un certain seuil, on considère qu'on a été bloqué / patiné / poussés. Ca marche assez bien, et il y a un seul paramètre à régler (écart).

On avait aussi prévu pour les autres actionneurs du robot de faire un estimateur qui traque la température du moteur en fonction de sa puissance élec, mais on a jamais pris le temps de l'implémenter.

Merci pour vos réponses rapides et techniques.

Description de mon asservissement:

-chaque roue à une consigne et un asservissement indépendant en vitesse.
-J'ai un asservissement en arc de cercle qui calcul la distance à parcourir, la différence de vitesse entre les roues, et qui donc contrôle la vitesse des roues, pour arriver au bon endroit.
en terme de performance, ça donne ça, pour un trajet direct de 1.5m. A gauche le déplacement n'est pas orthonormé: sur 1.5m, le robot dait un écart de 8mm latéral.

L’échantillonnage du graphique est de 0.04ms, mais le calcul de position et contrôle de vitesse des moteurs est à 0.004ms.
Actuellement, les codeurs sont sur les roues motrices, et je suis en train de faire des emplettes sur aliexpress pour réduire le problème. J'ai d'aussi bon résultats en simulation aussi parce que c'est moins précis qu'avec des codeurs externes. Il est vrai qu'avec des roues externes, on réduit le problème du patinage des roues quand le robot est immobile, mais je ne pense pas que ce soit propre, il suffit que le robot vibre pour quel la vitesse ne soit plus juste nulle.

edit: j'ai dit pas mal de bêtises en terme d'interprétation des résultats, je m'arrète là, et bosse un peu tout ce que vous avez dit.

J'ai fait pas mal de corrections qui n'ont rien à voir, notamment: mon accélération avait un facteur 10 caché ce qui n'était pas le cas de la décélération, et surtout, ma valeur de vitesse était déduite du différentiel de position, via excel (considérant la période parfaitement stable). J'affiche maintenant la vitesse réelle des roues (valeurs de l'asserv'), ce qui est beaucoup plus stable.

Donc le graphique ci-dessous, correspond à 2 A/R du robot, le premier sans soucis, le second en le ralentissant, voir bloquant. Le premier aller retour est jusqu'à 5.4 secondes.


En filtrant pas mal l'erreur, entre la vitesse voule et la vitesse réelle, j'ai quelque chose de beaucoup mieux et d'utilisable:


Merci pour votre aide!

Salut,

H0x7d0 wrote: ↑

Tue 22 Jan 2019, 16:29

Il est vrai qu'avec des roues externes, on réduit le problème du patinage des roues quand le robot est immobile, mais je ne pense pas que ce soit propre,

Les codeur externe sont vivement conseiller.
Ils éliminent tout problème de patinage des roues lors des accélérations.
Ils permettent d'avoir un point d'appui sur la table plus petit et donc plus précis.
Ils permettent de calculé la position du robot via l'odométrie même quand les moteurs sont désactivé (ne régule pas).
Ils permettent de faire une détection de blocage fiable.

H0x7d0 wrote: ↑

Tue 22 Jan 2019, 16:29

il suffit que le robot vibre pour quel la vitesse ne soit plus juste nulle

Je suis pas certain d'avoir bien comprit ce commentaire ?

H0x7d0 wrote: ↑

Tue 22 Jan 2019, 16:29

L’échantillonnage du graphique est de 0.04ms, mais le calcul de position et contrôle de vitesse des moteurs est à 0.004ms.

Est ce que ce serait pas des secondes [s] plutôt que des millisecondes [ms] ?
Sur nos robots, nous faisons le calcule de position et contrôle des moteurs a une fréquence de 10ms (0.01s).
A une fréquence trop élevée, les résultats seront pas bon et une fréquence trop basse aussi... 10ms donne de bon résultat.

PS : tous notre code est sur github si tu veux y jeter un oeil pour t'inspirer

A+
Romain

Merci @romain_cvra
Pour les roues codeuses externes, on est d'accord. Ce que je disais c'est qu'avec des codeurs internes ou externe, le seuil de "on n'avance plus" n'est par forcément juste 0m/s, dès que le robot bouge un peu, même s'il reste sur place, et le seuil de 0m/s est dépassé.

Pour la période, c'est effectivement en ms, donc 4ms pour le positionnement et l'asserv' en vitesse des roues, et 40ms pour le contrôle/asserv général.
Actuellement, l'asserv' marche pas trop mal, et j'avais vraiment le problème précis détection de blocage. Je ne l'ai pas encore implémenté, mais les résultats sur excel me semblent suffisants.
Sur le graphique, de 0 à 5.4s, tu as l'aller retour sur 1.5m, et la suite qui fait n'importe quoi, c'est moi qui ralentie ou bloque et libère le robot. L'asserv' est assez fluide.

prochaines étapes: fabriquer 4 nouvelles roues, dont deux pour des codeurs. Actuellement, j'ai une roue voilée. (Et à un moment, il faudra que je vois comment on peut faire des points cette année)

H0x7d0 wrote: ↑

Tue 29 Jan 2019, 20:18

Merci @romain_cvra
Pour les roues codeuses externes, on est d'accord. Ce que je disais c'est qu'avec des codeurs internes ou externe, le seuil de "on n'avance plus" n'est par forcément juste 0m/s, dès que le robot bouge un peu, même s'il reste sur place, et le seuil de 0m/s est dépassé.

Avec Plaisir!
Oui je vois ce que tu veux dire, a la limite c'est trop grave, temps que l'odométrie en X/Y sur la table le prend en compte. Tes divers régulateur vont compenser.

Il y a quand même des choses assez bizard dans les graphiques...
Sur le graph de la vitesse linéaire du robot, lorsque celui freine, il y a de petit pick ou il accélère a nouveau.
Je connais pas ta mécanique mais vu la masse d'un robot Eurobot "standard". Est ce que dynamiquement c'est possible ?

Pour le graph des accélérations :
Est ce que tu limites les accélération max ? J'ai un peu de la peine a voir sur ton graph a l’œil ca me semble très fort, tu es sur que tu patine pas ?

A+

Merci,
Le robot fait un poids standard léger (tout en plastique, environ 5kg je pense). Les roues sont en alu, pneu en tapis de cuisson de cookie (silicone), les roues font 35mm de large, une des roues est un peu voilée, et les codeurs sont sur ces roues.
Pour la pente de décélération, c'est effectivement un peu moche que le robot donne des petites impulsion, mais c'est "normal": la décélération est assez faible, et l'asservissement global essaie de garder une décélération selon la pente, si le robot décélère trop vite, il va ré-accélérer. on trouve ces mêmes pics sur la stabilité de la vitesse à vitesse constante.
Il manque un petite bout de données: lors de la rotation pour se remettre droit, la rotation n'affiche pas les données.
Les pointes sont sur le graphique de vitesse et non de position: le robot n'alterne pas avant puis reculons juste accélérer et décélérer. Il va a reculons que lorsque la vitesse est négative. Donc c'est physiquement possible.
Il est possible d'atténuer ces pointes avec de meilleurs coefs de PID, et avec une accélération différente. Ici, j'ai ajouté la vidéo, et on entend bien un "clac" à la fin du premier aller, et il se peut effectivement que le robot ai un peu dérapé.
https://youtu.be/RfBkR2xd-Ko

fichier excel ici: https://ufile.io/lz3hq
limitation vitesse: 500mm/s et acceleration 600mm/s/s.

(Sinon, rien à voir, mais c'est cool et un e bonne idée, d'avoir un bootloader pour flasher sur CAN!)

H0x7d0 wrote: ↑

Wed 30 Jan 2019, 17:06

les roues font 35mm de large

Voila entre autre pourquoi les codeurs externes serais un grande avantage.
Actuellement lorsque le robot tourne sur lui même, il n'est pas possible de connaitre précisément la distance entre les deux points de contacte au sol. Car ce point de contact peut être n'importe ou sur toutes la largeur de la roue et en plus varier pendant un tour de roue.

H0x7d0 wrote: ↑

Wed 30 Jan 2019, 17:06

limitation vitesse: 500mm/s et acceleration 600mm/s/s.

Ok j'imagine que ces chiffres sont la vitesse et l'accélération souhaitée, celle que le robot devrait suivre.
Dans le fichier excel, il y a des accélérations à 3.8[m/s^2], c'est assez énorme.

Par exemple, notre robot de 2017 avait une limite théorique maximum a 3.75[m/s^2].
Cet limite est contrainte uniquement par 3 chose :
- La position du centre de gravité par rapport au roue motrice.
- La position des patins par rapport au roue motrice.
- Le coefficient de frottement des roues.

Dans ton cas, le calcule est différent pour l'accélération et pour la décélération par ce qu'il n'y pas de patin a l'arrière.

A+