Pages

Affichage des articles dont le libellé est théorie. Afficher tous les articles
Affichage des articles dont le libellé est théorie. Afficher tous les articles

jeudi 2 février 2012

Nouveau modèle 3D

Tout en travaillant sur l'animation de mon robot, j'essaye d'améliorer le problème conceptuel de la dernière patte. Voici pour l'instant comment je vois la chose :


Concept de robot avec augmentation de la liberté du pied


Ici, le pied peut désormais se tourner vers le centre comme ceci :


En le voyant comme ça, je pense qu'il est peut-être un tout petit peu long...


Mais il peut aussi aller chercher plus loin lorsqu'il avancera grâce à une allonge plus grande.



La patte peut aller chercher plus loin, les mouvements pourrons être plus fluides.


Il ne me reste donc plus qu'à modéliser une vraie patte plutôt qu'un bloc et à le réaliser. Pour cela, j'ai pensé à une impression 3D pour quelque chose de très personnalisé. Reste à voir le prix que cela coûtera.

dimanche 29 janvier 2012

Modélisation 3D de Belma

Généralement, c'est plutôt lors de la conception du produit que le rendu 3D est utile. En ce qui me concerne, je n'aurai pas fait comme tout le monde en modélisant mon robot après l'avoir construit. Voici donc le résultat :

Belma en 3D !

Malgré qu'il manque la carte ArbotiX, les trous des deux plaques du corps, les câbles et les vis, je vais m'arrêter la dans la modélisation car le but est surtout de créer l'animation qui me sera (je l'espère) utile pour réaliser l'animation séquentielle.

Un problème de conception
Je profite d'ailleurs de ce post pour soulever justement un problème de conception qui risque de me poser des soucis même si je n'en suis pas sûr à 100%. En fait, le pied de Belma peut se tourner à l'horizontal voir même complètement vers le haut. D'ailleurs, cela ne me sera sans doute jamais utile de lever le pied plus haut qu'à l'horizontal.

Pied à l'horizontal


Par contre, dans l'autre sens, le pied va bien à la verticale mais pas vraiment beaucoup plus. Alors même si on peut facilement imaginer un mouvement complet du robot en prenant en compte cette contrainte, j'ai bien peur que cela puisse me causer du soucis.

Un degré de liberté handicapant ?

Ceci est donc à méditer. Peut-être qu'il faudrait que je revoie ce point en inversant le sens du servomoteur pour que son pied soit manipulé directement par le moteur et non qu'il fasse partie intégrante du pied comme on peut le voir sur beaucoup de projets de Quadropods et d'Hexapods sur le net.

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 ;)