Discussion :

[bousky]

Bonjour,

Après avoir consulté tout ce que je pouvais, je n'arrive toujours pas à résoufre mon problème.

Je travaille sur un système à 2 trackers (6 degrés de liberté) et je cherche à afficher les coordonnées de l'un dans le repère de l'autre; Pour l'instant, je récupère:

P1 (x1, y1, z1, A1, E1, R1); Position et angles ABSOLUS d'Euler du capteur 1
P2 (x2 ... R2) idem capteur 2

Je voudrais exprimer x2/1, y2/1 etc... J'essaie de changer de repère à l'aide des quaternions. Les formules de changement de repère sont sur de nombreux site internet mais... ne marchent pas ! En effet, la combinaison des rotations successives a l'air de fausser le calcul... mais je ne sais pas comment faire.
Quelqu'un a-t-il une idée ?

Merci !

[pseudocode]

Pourquoi passer par les quaternions ? L'utilisation standard des matrices de passage pose un problème ?

[bousky]

oui, pour des histoires de Gimbal Lock
je me dois de faire le travail le plus propre possible...

http://www.developpez.net/forums/d14...d-gimbal-lock/

[pseudocode]

oui, pour des histoires de Gimbal Lock
je me dois de faire le travail le plus propre possible...

http://www.developpez.net/forums/d14...d-gimbal-lock/

Quel rapport entre le gimbal lock et le changement de repère ?

Ou alors, c'est plus qu'un simple changement de repère que tu veux faire...

[bousky]

Et ben si je ne m'abuse les quaternions permettent de ne pas se soucier de l'ordre des rotations qui sont effectuées: une seule multiplication par un quaternion contenant l'info des 3 angles d'Euler suffit.
Et en plus il me semble que les ambiguïtés possibles dues à la manipulation de matrices de rotation sont supprimées.
Enfin j'ai lu de nombreuses fois que le calcul est beaucoup plus simple (ce dont je commence à douter ) et moins coûteux.

Mettons que tous ces avantages ne soient pas vérifiés, pour des raisons de compatibilité et de contraintes professionnelles, il est de toute façonplus simple pour moi de manipuler les quaternions.

Voilà... j'espère avoir répondu à tes questions pseudocode

[pseudocode]

Et ben si je ne m'abuse les quaternions permettent de ne pas se soucier de l'ordre des rotations qui sont effectuées: une seule multiplication par un quaternion contenant l'info des 3 angles d'Euler suffit.
Et en plus il me semble que les ambiguïtés possibles dues à la manipulation de matrices de rotation sont supprimées.
Enfin j'ai lu de nombreuses fois que le calcul est beaucoup plus simple (ce dont je commence à douter ) et moins coûteux.

Tout cela est vrai à condition de manipuler tout le temps des quaternions. Si tu fais la navette entre représentation Quaternion et Euler à chaque calcul, tu perds tout ces avantages.

Enfin soit.

Tu peux donner 2 point P1 et P2, ainsi que l'opération qui pose problème ?

[bousky]

ouais, je me doute que la navette quaternion <-> Euler n'est pas idéale...
mais bon, tâchons d'en faire abstraction pour l'istant; voici l'allure de mon algo (désolé c'est un peu long, et il y a d'autres navettes Vecteur <-> Quaternion qui sont superflues mais j'aimerais savoir si ma démarche est fausse)

P = (x2,y2,z2)
Pref =(x1,y1,z1)

O = quaternion obtenu à partir des angles d'Euler du capteur 2
Oref = idem pour le capteur 1

Où, pour des angles (A,E,R) le quaternion d'orientation O est ainsi obtenu (formule directement pompée d'internet)
O (a,b,c,d)
où
a = (cos(R/2) * cos(E/2) * cos(A/2) + sin(R/2) * sin(E/2) * sin(A/2)),
b = (sin(R/2) * cos(E/2) * cos(A/2) - cos(R/2) * sin(E/2) * sin(A/2)),
c = (cos(R/2) * sin(E/2) * cos(A/2) + sin(R/2) * cos(E/2) * sin(A/2)),
d = (cos(R/2) * cos(E/2) * sin(A/2) - sin(R/2) * sin(E/2) * cos(A/2))

Oref_conj= conjugué(Oref);
trans = P-Pref
Qtrans = (0,trans.x, trans.y, trans.z) //quaternion obtenu à partir du veteur trans.
Qtrans = Oref_conjugué * Qtrans * (Oref_conjugué)^-1

//OBTENTION DE LA TRANSLATION
trans = (Qtrans.i, Qtrans.j, Qtrans.k) //vecteur des 3 composantes complexes de Qtrans

//OBTENTION DES ANGLES
O = Oref_inverse*O;
et on extrait les trois angles d'Euler à partir de O

Le pb est que les résultats sont faux: si je fixe les 2 capteurs sur un solide et que je bouge le solide, les coordonnées relatives devraient être fixes (les 2 cpateurs étant fixes l'un par rapport à l'autre), or elles ne le sont pas... ='(


... et merci pour ton aide!

[pseudocode]

Le pb est que les résultats sont faux: si je fixe les 2 capteurs sur un solide et que je bouge le solide, les coordonnées relatives devraient être fixes (les 2 cpateurs étant fixes l'un par rapport à l'autre), or elles ne le sont pas... ='(

Les coordonnées "relatives" devraient être fixes dans la base (1,i,j,k) ?

Heu... non.

[bousky]

Heu... jai pas trop compris ta remarque... mais quelle que soit la positon/orientation du solide sur lequel je fixe les capteurs, les coordonnées du capteur 2 dans le référentiel du capteur 1 devraient être fixe sachant qu'il n'y a aucun mouvement relatif...

... non ?

[pseudocode]

les coordonnées du capteur 2 dans le référentiel du capteur 1 devraient être fixe sachant qu'il n'y a aucun mouvement relatif...

Dans le référentiel du capteur 1 = dans la base cartésienne définie par le capteur 1 : oui.

Mais le repère des quaternions c'est la base (1,i,j,k) et cette base ne "bouge" pas en fonction du capteur 1. C'est comme si tu me disais que les coordonnées du capteur 2 devraient être fixe dans la base (o,x,y,z).

[bousky]

Ah je vois...
Donc si j'ai bien compris la conversion que je fais ne rend pas les coordonnées cartésiennes dans le repère 1 ...? Et dans ce cas, que manque-t-il?

[pseudocode]

Ah je vois...
Donc si j'ai bien compris la conversion que je fais ne rend pas les coordonnées cartésiennes dans le repère 1 ...? Et dans ce cas, que manque-t-il?

Bah, c'est ce que je te disais au début. il te faut la matrice de passage de la base cartésienne 'P1' a la base cartésienne 'P2' (ou l'inverse)

Il n'y a pas de problème de gimbal lock, tu n'as pas besoin des quaternions. C'est juste une matrice de passage entre 2 bases cartésiennes.