Pages

lundi 23 janvier 2012

Weekend difficile

Ce weekend, j'ai commencé à étudier les déplacements de Belma. Une étape qui démarrais plutôt bien grâce à NUKE, une librairie utilisant la cinématique inverse. J'ai réussi à faire avancer Belma sans trop de difficultés même si le résultat était assez chaotique (je vais d'ailleurs éviter la performance en vidéo). La où ça commence à coincer c'est lorsqu'il faut pratiquer soit même la théorie. En effet, avant Belma, je n'en avait jamais entendu parler. Or, je ne suis pas du tout satisfait du résultat de NUKE. Je trouve que les mouvements ne sont pas fluides, pas lisses, pas naturels.

Mais revenons à la cinématique inverse. Un mot assez barbare mais qui permet pourtant de prévoir les mouvements d'un membre s'il souhaite atteindre un point. La théorie n'a rien de simple surtout que je n'ai trouvé justement pratiquement que de la théorie sur le net et peu de pratique et que cela ne concernait que de la théorie 2D alors que je travaille en 3D.

Néanmoins, je me suis tout de même arrêté sur un article assez bien rédigé que je vais vous résumer en français (http://freespace.virgin.net/hugo.elias/models/m_ik2.htm).

Prenons l'exemple de ce membre à 2 axes.

Membre à deux axes. Le point rouge, c'est l'objectif.

Le point rouge étant l'objectif, la cinématique inverse doit nous permettre de savoir de combien de degrés doit être a et b pour que le point bleu arrive sur le point rouge.
Alors comment faire ? Il existe deux méthodes, une méthode qui donnera le résultat directement et l'autre qui va s'approcher de l'objectif par étapes successives. Comme nous sommes en robotique et que le mouvement doit être assez lisse, je vais employer la seconde méthode que je vais appeler "la méthode simple".

La méthode simple !
Simple comme boujour (ou pas), voici comment faire.
Prenons ce graphique :
Objectif, toujours le point rouge !
Dans cette position, si on tourne l'axe A un tout petit peu, cela va déplacer le point bleu vers a et si on tourne l'axe B un tout petit peu, cela va déplacer le point vers b. Pour que le point rencontre sa cible, il faut pourtant qu'on aille dans la direction de t. On voit donc bien que tourner B sera inutile vu que le mouvement sera perpendiculaire. Par contre, tourner A va nous approcher de notre objectif.

Second graphique maintenant, plus aléatoire :
Vous ai-je précisé que l'objectif était le point rouge ?
Ici, en regardant les vecteurs a et b, on remarque que les deux nous rapprocherons de la cible mais que b sera plus efficace que a. Il faut donc tourner les deux axes mais B un peu plus que A.

Méthode de programmation
Comment vais-je représenter cela en code ?
Pour l'instant, je n'y ai que peu réfléchis mais je crois que le mieux serait de travailler avec un logiciel de modélisation 3D (il doit bien y avoir les éléments de l'AX-12 modélisés quelque part sur le net) puis de l'animer par cinématique inverse pour en sortir une séquence de 16 ou 32 positions en fonction de la fluidité requise. Chaque séquence représentant une commande (avancer, reculer, tourner, etc.). Reste à voir si j'ai le niveau pour faire de l'animation 3D. C'est pas gagné mais ce sera pourtant la prochaine étape de mon projet ;)

Aucun commentaire:

Enregistrer un commentaire