Asservissement des moteurs (alpha / theta)

J'avais promis de faire une petite brève sur l'asservissement en alpha-théta, qui est expliqué à l'adresse suivante :

http://microb.technology.free.fr/fr/asservissement2005/index.html


Voici plusieurs extraits intéressants :

Sur le fait de devoir avoir 2 types de roues :

"En effet, les roues motorisées, pour être efficaces, doivent être plutôt larges et molles. Cela est malheureusement incompatible avec une mesure fiable de la position (diamètre de la roue et distance entre les 2 roues imprécis). De plus, ce roues peuvent avoir tendance à patiner lors de blocage contre un obstacle ou d'une forte accélération.

C'est pourquoi plusieurs équipes (dont Eirbot à partir de 2003) utilisent des roues folles non motorisées, et placées sur le même axe que les roues motorisées. Elles sont à l'inverse fines et dures, montées sur suspensions, et ne glissent quasiment pas. Pour avoir vu fonctionner des robots avec ce système (Minitech, Eirbot, Ville d'Avray 2005), je peux affirmer que la précision est redoutable, même en cas de choc."

Sur l'alpha theta en lui-même :

Elle consiste à ne pas asservir, comme habituellement sur les robots de la coupe, chacune des roues avec un PID, mais plutôt d'utiliser un PID pour asservir la différence des positions de roues (l'angle Alpha), et un autre PID pour asservir la distance parcourue (Theta)

Commentaires :

J'avais déjà eu cette idée et je l'avais intégré dans l'asservissement du robot 2006, mais sous une forme très basique et uniquement proportionnel :
En réalité, je calculais la différence entre la position des 2 roues puis je donnais un coup de pouce à celle qui était en retard. Il n'y avait aucun terme dérivé ni intégral

Mais là, en réalité, ils vont plus loin, ce n'est pas simplement une correction entre les deux roues qui est appliquée, c'est clairement un calcul de la distance parcourue par le robot et non plus par chaque roue (classiquement sous forme de trapère (accélération, vitesse constante, décéleration)). En réalité, on calcule la distance que doit parcourir le robot (qui peut être de 0 si le robot tourne sur lui-même), et la différence que doivent avoir les roues. On ne se souci plus vraiment de savoir si une roue atteint une valeur précise, parce qu'on tient compte des deux valeurs des roues en même temps pour calculer le PID pour la partie déplacement, et de la différence des deux roues pour calculer en fait l'angle de la trajectoire.

Cet asservissement a un intérêt évident, c'est qu'il rend indissociable les deux roues et prend en compte davantage la trajectoire du robot et non plus la trajectoire d'une roue ou de l'autre, avec des corrections qui sont difficiles à trouver.

Par contre, cet asservissement doit être codé manuellement et ne marche pas sur les LM629. A priori, cela donne d'excellents résultats, car on a bien vu la fluidité du robot de Ville d'Avray !!!

A suivre ...

Sur la partie asservissement de cette année, je pense vraiment avoir trouver la cause des problèmes : les calculs se font en 16 bits, et ne me permettent pas de régler correctement le PID (Ex: je n'avais le choix qu'entre la valeur 2 ou 3 pour la valeur de P alors qu'il aurait fallu avoir une valeur intermédiaire). Je vais pour cela utiliser une librairie de math en 32 bits pour le Javelin qui va me permettre de faire le travail. Reste à savoir si cela ne sera pas trop lent. A voir ...