Gimbal Lock

Design Patterns, Erklärungen zu Algorithmen, Optimierung, Softwarearchitektur
Forumsregeln
Wenn das Problem mit einer Programmiersprache direkt zusammenhängt, bitte HIER posten.
meiwen
Beiträge: 14
Registriert: 23.10.2012, 00:01
Benutzertext: Hola

Gimbal Lock

Beitrag von meiwen »

Hi,

ich beschäftige mich gerade mich Eulerwinkeln und dann kommt man ja zwangsläufig auf den Gimbal Lock. In allen Definitionen dazu lese ich immer, dass der Gimbal Lock durch eine Rotation um 90° Grad entsteht, wenn zwei Achsen aufeinander fallen. Was ich dabei nicht verstehe ist, wie die Achsen aufeinander fallen können. In diesem Video dazu
https://www.youtube.com/watch?v=zc8b2Jo7mno
wird von einer Hierarchie der Achsen gesprochen. Dabei ist y in der Hierarchie ganz oben. Dies hat zur Folge dass bei einer Rotation um die Y-Achse sich die X und Z Achse mit drehen. Z steht in der Hierarchie ganz unten. Wird also um die Z Achse gedreht, bleiben die anderen Achsen , X und Y an der gleichen Stelle. Ich verstehe nicht warum die Achsen auf einmal in einer Hierarchie zueinander stehen und woher diese kommt. Bei allen Rotationen die nicht den Gimbal Lock vorführen wollen, wie zum Beispiel hier
http://commons.wikimedia.org/wiki/File:Euler2.gif
drehen sich immer die Achsen mit.
Zumindest für mich ergibt sich hier noch keine Logik. Aber vielleicht weiß ja hier jemand Rat ;)
Benutzeravatar
dot
Establishment
Beiträge: 1734
Registriert: 06.03.2004, 18:10
Echter Name: Michael Kenzel
Kontaktdaten:

Re: Gimbal Lock

Beitrag von dot »

Eben genau weil die Achsen sich mitdrehen. Nehmen wir z.B. die Rotationssequenz xyz. Wir rotieren also erst um x, alles dreht sich mit, dann um y, alles dreht sich mit und dann um z, alles dreht sich mit. Wenn wir in dieser Sequenz nun um irgendeinen Wert um x rotieren und dann um 90° um y, liegt die Achse, um die die darauf folgende Rotation um z erfolgt entlang der Richtung, in die unser x anfangs gezeigt hat. Wann immer in dieser Sequenz um ein ungerades Vielfaches von 90° um y rotiert wird, haben die Rotation um x und die Rotation um z den selben Effekt, da die beiden Achsen zusammenfallen (Gimbal lock); wir haben einen Freiheitsgrad verloren...
Benutzeravatar
Krishty
Establishment
Beiträge: 8238
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Gimbal Lock

Beitrag von Krishty »

Ich glaube, kimmi war es, der den Gimbal Lock mal sehr sehr anschaulich erklärt hat:

In einem Egoshooter kannst du nur furchtbar schwer zielen, wenn das Ziel senkrecht über oder unter dir liegt. Sobald du senkrecht nach unten guckst, und die Maus nach links oder rechts bewegst, drehst du dich nämlich nicht nur um deine globale Y-Achse, sondern auch um deine lokale Z-Achse. Das ist Gimbal Lock.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
meiwen
Beiträge: 14
Registriert: 23.10.2012, 00:01
Benutzertext: Hola

Re: Gimbal Lock

Beitrag von meiwen »

Hi

erst mal danke für die schnellen Antworten. Scheint wohl so als ob ich ein besonders schwerer Fall bin, aber ich verstehe es leider immer noch nicht.
Ich habe mir zum besseren Verständnis mal die Lösung von dot aufgezeichnet.
Dabei entspricht die blaue Achse Z, Y grün und X rot.
Im ersten Bild befindet sich mein Koordinatensystem im ursprünglichen Zustand ( keine Rotation erfolgt).
Danach drehe ich um 90° an der Y-Achse, wie dot beschrieben hat. Die X und Z Achse vollziehen dabei die Rotation mit.
Daraus ergibt sich mein zweites Bild. Die X-Achse liegt wie dot auch beschrieben hat nun an der Stelle an der zuvor meine Z Achse war.
Da sich meine Z Achse aber auch weiter gedreht hat, liegen die Achsen nicht übereinander. Somit beschreiben zumindest in meiner Logik die Drehung um X und Z Achse nicht die gleiche Rotation.
meiwen
Beiträge: 14
Registriert: 23.10.2012, 00:01
Benutzertext: Hola

Re: Gimbal Lock

Beitrag von meiwen »

so diesmal mit Datei in der ich mir das Ganze aufgemalt habe ;)
Dateianhänge
Unbenannt.PNG
Unbenannt.PNG (8.44 KiB) 9974 mal betrachtet
Benutzeravatar
dot
Establishment
Beiträge: 1734
Registriert: 06.03.2004, 18:10
Echter Name: Michael Kenzel
Kontaktdaten:

Re: Gimbal Lock

Beitrag von dot »

meiwen hat geschrieben:Da sich meine Z Achse aber auch weiter gedreht hat, liegen die Achsen nicht übereinander. Somit beschreiben zumindest in meiner Logik die Drehung um X und Z Achse nicht die gleiche Rotation.
Das Problem ist aber, dass die Rotation nicht um die jeweilige mitrotierte lokale Achse erfolgt, denn du hast ja eben nicht einfach nur eine Rotation, sondern eine Sequenz von aufeinanderfolgenden Rotationen. Es reicht also nicht, einfach nur das objektlokale Koordinatensystem aufzuzeichnen, du musst immer auch nach jedem Schritt wieder das "globale" Koordinatensystem einzeichnen. Denn die jeweils nächste Rotation erfolgt um die Achsen dieses Systems. Oder anders ausgedrückt: Die Koordinatenachsen stehen still und dein Objekt rotiert. Und genau da liegt wohl dein Verständnisproblem... ;)
meiwen
Beiträge: 14
Registriert: 23.10.2012, 00:01
Benutzertext: Hola

Re: Gimbal Lock

Beitrag von meiwen »

Ok, nächster Versuch. Meine Achsen bleiben still.
Ich habe mir dazu wieder eine Grafik gemacht. In der Grafik ist ein einfaches Objekt welches um 90° um die Y Achse gedreht wird.
Daraus ergibt sich Bild zwei. Wenn die Achsen also gleich bleiben, wie können sie dann auf einmal übereinander liegen?!?
Dateianhänge
Unbenannt2.PNG
Unbenannt2.PNG (9.58 KiB) 9950 mal betrachtet
Benutzeravatar
dot
Establishment
Beiträge: 1734
Registriert: 06.03.2004, 18:10
Echter Name: Michael Kenzel
Kontaktdaten:

Re: Gimbal Lock

Beitrag von dot »

Naja, da siehst du's jetzt wunderschön: Eine Rotation um x vor der 90° y-Rotation und eine Rotation um z nach der 90° y-Rotation haben nun den gleichen Effekt auf die Ausrichtung des Objektes, weil durch die 90° Rotation dazwischen die lokale x-Achse des Objektes auf die globale z-Achse rotiert wurde. ;)
Benutzeravatar
eXile
Establishment
Beiträge: 1136
Registriert: 28.02.2009, 13:27

Re: Gimbal Lock

Beitrag von eXile »

Mich selber haben diese ganzen Darstellungen und Erklärungen zum Gimbal Lock nie befriedigt. Immer gibt es irgendwelche Stellen, die unexakt, schlecht vorstellbar oder einfach nur falsch sind. Daher eine komplett mathematische Erklärung.

Wir haben eine handelsübliche Euler-Rotationsmatrix in ZXY-Reihenfolge (eine der zwölf gültigen Rotationsreihenfolgen für Euler-Rotationen):\($$\begin{align}
\operatorname{R}(\vartheta, \varphi, \psi) &= \operatorname{R_z}(\vartheta) \cdot \operatorname{R_y}(\varphi) \cdot \operatorname{R_x}(\psi) \\
&=
\left(
\begin{array}{ccc}
1 & 0 & 0 \\
0 & \cos(\vartheta) & -\sin(\vartheta) \\
0 & \sin(\vartheta) & \cos(\vartheta) \\
\end{array}
\right)
\cdot
\left(
\begin{array}{ccc}
\cos(\varphi) & 0 & \sin(\varphi) \\
0 & 1 & 0 \\
-\sin(\varphi) & 0 & \cos(\varphi) \\
\end{array}
\right)
\cdot
\left(
\begin{array}{ccc}
\cos(\psi) & -\sin(\psi) & 0 \\
\sin(\psi) & \cos(\psi) & 0 \\
0 & 0 & 1 \\
\end{array}
\right) \\
&=
\left(
\begin{array}{ccc}
\cos(\vartheta) \cos(\varphi) & \cos(\vartheta) \sin(\varphi) \sin(\psi)-\cos(\psi) \sin(\vartheta) & \cos(\vartheta) \cos(\psi) \sin(\varphi)+\sin(\vartheta) \sin(\psi) \\
\cos(\varphi) \sin(\vartheta) & \cos(\vartheta) \cos(\psi)+\sin(\vartheta) \sin(\varphi) \sin(\psi) & \cos(\psi) \sin(\vartheta) \sin(\varphi)-\cos(\vartheta) \sin(\psi) \\
-\sin(\varphi) & \cos(\varphi) \sin(\psi) & \cos(\varphi) \cos(\psi) \\
\end{array}
\right)
\end{align}$$\)
Wenn wir jetzt mal \($\varphi = -90^\circ$\) setzten, sehen wir:\($$\operatorname{R}(\vartheta, -90^\circ, \psi) = \left(
\begin{array}{ccc}
0 & -\sin(\vartheta +\psi) & -\cos(\vartheta +\psi) \\
0 & \cos(\vartheta +\psi) & -\sin(\vartheta +\psi) \\
1 & 0 & 0 \\
\end{array}
\right)$$\)
D.h. es gilt insbesondere \($\operatorname{R}(x, -90^\circ, 0) = \operatorname{R}(0, -90^\circ, x)$\). Das ist es, was manche mit „die Rotationsachsen fallen zusammen“ meinen – den beiden Rotationsparametern kommt die gleiche Bedeutung zu.
meiwen hat geschrieben:In diesem Video dazu
https://www.youtube.com/watch?v=zc8b2Jo7mno
wird von einer Hierarchie der Achsen gesprochen.
Das Video hatte mich hier schon einmal aufgeregt; ich würde es nicht zum Einarbeiten in die Thematik benutzen. ;)
Krishty hat geschrieben:Ich glaube, kimmi war es, der den Gimbal Lock mal sehr sehr anschaulich erklärt hat:

In einem Egoshooter kannst du nur furchtbar schwer zielen, wenn das Ziel senkrecht über oder unter dir liegt. Sobald du senkrecht nach unten guckst, und die Maus nach links oder rechts bewegst, drehst du dich nämlich nicht nur um deine globale Y-Achse, sondern auch um deine lokale Z-Achse. Das ist Gimbal Lock.
Ich glaube eher, das hat etwas mit der Parametrisierung der Kameraorientierung zu tun: Es sind einfach Kugelkoordinaten (Maus nach links/rechts entspricht \($\varphi$\), Maus nach oben/unten entspricht \($\vartheta$\)). Die Probleme am Nord- und Südpol liegen einfach an den Singularitäten der Parametrisierung.

Dass da kein Gimbal-Lock auftreten kann, sieht man wohl schon daran, dass man im Gegensatz zu Apollo 11 nicht rollen kann (oder zumindest nicht bis zu 90 Grad). Also ist man entweder immer in einem Gimbal Lock, oder nie. Da ich mich mit den meisten First-Person-Kameras gut umschauen kann, tippe ich darauf, dass wir letzteren Fall haben. ;)
Zuletzt geändert von eXile am 27.01.2013, 00:51, insgesamt 1-mal geändert.
Benutzeravatar
dot
Establishment
Beiträge: 1734
Registriert: 06.03.2004, 18:10
Echter Name: Michael Kenzel
Kontaktdaten:

Re: Gimbal Lock

Beitrag von dot »

eXile hat geschrieben:Die Probleme am Nord- und Südpol liegen einfach an den Singularitäten der Parametrisierung.
Genau das ist doch Gimbal Lock!? In 3D sind's eben Singularitäten der Parametrisierung einer Hypersphäre...
Stephan Theisgen
Beiträge: 94
Registriert: 29.07.2003, 11:13

Re: Gimbal Lock

Beitrag von Stephan Theisgen »

Hallo!

@meiwen: Mach Dir mal keine Sorgen, der Gimbal Lock ist wirklich "hart zu knacken".

Ich habe beruflich viel mit Berechnungen von Rotation etc. zu tun (im Bereich Physik) und ich muss sagen, dass ich mit Mathematik eigentlich keine Schwierigkeiten habe und mit Euler-Winkel vertraut bin. Die Formeln von eXile zeigen das Problem mathematisch sauber und auf dieser Ebene verstehe ich das Problem auch und begreife es. Es mir aber bildlich plausibel zu machen fällt mir, genau wie vielen anderen, sehr schwer, deswegen finde ich die Diskussion hier sehr gut. Ich bin immer auf der Suche nach einer anschaulichen / einfach zu begreifenden Erklärung.

Mal eine Frage von mir: In der Physik werden Euler-Winkel als Parametrisierung sehr gerne verwendet, z.B. um die Bewegungsgleichungen eines Kreisels zu lösen etc., da kümmert sich kein Mensch um den Gimbal Lock, obwohl er ja physikalische Realität ist (siehe z.B. Apollo 11). Bis jetzt ist mir noch nicht ganz klar, ob das einfach ignoriert wird oder ob es da grundlegende unterschiede zwischen den Parametrisierungen gibt.

@meiwen: Wie hast Du diese schönen Bildchen gemacht, ich könnte sowas gut berufliche brauchen, zur Visualisierung von Rotation.
meiwen
Beiträge: 14
Registriert: 23.10.2012, 00:01
Benutzertext: Hola

Re: Gimbal Lock

Beitrag von meiwen »

Super. Vielen Dank jetzt hats endlich klick gemacht.
Die Bilder sind mit Word ;)
Stephan Theisgen
Beiträge: 94
Registriert: 29.07.2003, 11:13

Re: Gimbal Lock

Beitrag von Stephan Theisgen »

Die Bilder sind mit Word
Ok, jetzt wo Du es sagst, da hätte ich auch selber drauf kommen können. Sieht doch nach Word aus ;-)
Bis jetzt ist mir noch nicht ganz klar, ob das einfach ignoriert wird oder ob es da grundlegende unterschiede zwischen den Parametrisierungen gibt.
Nein, gibt es nicht. Nur wird die Parametrisierung nicht falsch, sondern nur für diese speziellen Werte unbrauchbar. Ich kann ja trotzdem jede Orientierung erreichen, also ist sie vollständig und bis auf diesen einen Fall auch eindeutig. So jetzt hab ichs mir auch nochmal klar gemacht. Danke dafür!
Benutzeravatar
eXile
Establishment
Beiträge: 1136
Registriert: 28.02.2009, 13:27

Re: Gimbal Lock

Beitrag von eXile »

Erst einmal muss ich etwas Selbstkritik üben: Ich habe im obigen Post die Matrixmultiplikation einfach falsch ausgeführt; die Erkenntnisse werden davon aber glücklicherweise nicht tangiert. Wird Ist nun korrigiert.

Zweitens habe ich mal geschaut, wie überhaupt ein Gimbal-Lock bei Euler-Winkeln auftreten kann. Und mit Euler-Winkeln meine ich hier tatsächlich alle zwölf unterschiedlichen Notationsmöglichkeiten, aufgeteilt in \($2 \cdot 6$\) Gruppen (XYZ, XZY, YXZ, YZX, ZXY, ZYX; und XYX, XZX, YXY, YZY, ZXZ, ZYZ). Erkenntnisse:
  • Ein Gimbal-Lock kann nur bei zwei bestimmten Stellungen des mittleren Winkels auftreten.
  • Erste Gruppe: Gimbal-Lock tritt auf bei
    • \($\operatorname{XYZ}(\vartheta, 90^\circ, \psi), \operatorname{XYZ}(\vartheta, -90^\circ, \psi)$\)
    • \($\operatorname{XZY}(\vartheta, -90^\circ, \psi), \operatorname{XZY}(\vartheta, 90^\circ, \psi)$\)
    • \($\operatorname{YXZ}(\vartheta, -90^\circ, \psi), \operatorname{YXZ}(\vartheta, 90^\circ, \psi)$\)
    • \($\operatorname{YZX}(\vartheta, 90^\circ, \psi), \operatorname{YZX}(\vartheta, -90^\circ, \psi)$\)
    • \($\operatorname{ZXY}(\vartheta, 90^\circ, \psi), \operatorname{ZXY}(\vartheta, -90^\circ, \psi)$\)
    • \($\operatorname{ZYX}(\vartheta, -90^\circ, \psi), \operatorname{ZYX}(\vartheta, 90^\circ, \psi)$\)
  • Zweite Gruppe: Gimbal-Lock tritt auf bei
    • \($\operatorname{XYX}(\vartheta, 0^\circ, \psi), \operatorname{XYX}(\vartheta, 180^\circ, \psi)$\)
    • \($\operatorname{XZX}(\vartheta, 0^\circ, \psi), \operatorname{XZX}(\vartheta, 180^\circ, \psi)$\)
    • \($\operatorname{YXY}(\vartheta, 0^\circ, \psi), \operatorname{XZX}(\vartheta, 180^\circ, \psi)$\)
    • \($\operatorname{YZY}(\vartheta, 0^\circ, \psi), \operatorname{XZX}(\vartheta, 180^\circ, \psi)$\)
    • \($\operatorname{ZXZ}(\vartheta, 0^\circ, \psi), \operatorname{XZX}(\vartheta, 180^\circ, \psi)$\)
    • \($\operatorname{ZYZ}(\vartheta, 0^\circ, \psi), \operatorname{XZX}(\vartheta, 180^\circ, \psi)$\)
  • Es gibt positiven Gimbal-Lock: Beispielsweise \($\operatorname{XYZ}(x, 90^\circ, 0) = \operatorname{XYZ}(0, 90^\circ, x)$\)
  • Und es gibt negativen Gimbal-Lock: Beispielsweise \($\operatorname{XYZ}(x, -90^\circ, 0) = \operatorname{XYZ}(0, -90^\circ, -x)$\)
  • In obiger Liste entspricht der erste gegebene Wert für den mittleren Winkel immer einem positiven Gimbal Lock, der zweite Wert einem negativen Gimbal Lock
Drittens die Antwort auf dots Frage:
dot hat geschrieben:Genau das ist doch Gimbal Lock!? In 3D sind's eben Singularitäten der Parametrisierung einer Hypersphäre...
Hier muss ich leider respektvoll anderer Ansicht sein.

Legen wir uns erst einmal rigoros unsere Definitionen fest. Wir verwenden das Koordinatensystem von Direct3D, und die Rotationsnotation \($\operatorname{XZY}$\). Wir müssen nun zwei Dinge trennen: Die Abbildung von Mauskoordinaten auf Winkel, und die Abbildung von Winkel auf Rotationen. Singularitäten von letzterer Abbildung stellen einen Gimbal-Lock dar, Singularitäten von ersterer nicht.

Angenommen wir haben Mauskoordinaten \($m_x, m_y$\) (das ignoriert jetzt komplett das Clipping der Maus am Bildschirmrand; das kann man aber problemlos ausbügeln). Dann wollen wir daraus eine bestimmte Orientierung berechnen:
\($$\begin{align}
\operatorname{C_{FPS}}: &[0,1]^2 \to [0, 2 \pi]^3, \\
&(m_x, m_y)^{\mathrm T} \mapsto (\pi/2, \quad (2 \pi \cdot m_x + \pi/2) \ \mathrm{mod} \ 2 \pi, \quad -\pi \cdot m_y + \pi/2)^{\mathrm T}
\end{align}$$\)
Damit kriegen wir die Rotationsmatrix \($\mathbf M$\) für eine bestimmte Mausposition einfach mittels:
\($$\mathbf M = \operatorname{XZY}\big(\operatorname{C_{FPS}}(m_x, m_y)\big)$$\)Damit man sieht, dass das funktioniert, habe ich einfach mal folgendes vorbereitet:
  • Wir schauen ziemlich weit nach oben (\($m_y = 0.05$\)), und drehen uns einmal im Kreis (\($m_x \in [0,1]$\))
  • x-Achse rot, y-Achse grün, z-Achse blau (wie gesagt: linkshändisches Koordinatensystem wie in Direct3D)
  • Blickrichtung orange, zwei kleine Orthogonalvektoren grau
Ergebnis:
Bild

Das sieht für mich erst einmal korrekt aus. Dabei stellt man nun drei Sachen fest:
  • Konvertiert man die von \($\operatorname{C_{FPS}}$\) zurückgegebenen Kugelkoordinaten in zweiter und dritter Komponente in euklidische Koordinaten, sehen wir, dass wir bereits zwei Singularitäten haben. Und zwar genau den von mir angesprochenen Nord- und Südpol.
  • Da wir in der Abbildungskette nun bereits zwei Singularitäten haben, kriegen wir die durch spätere Abbildungen in der Kette auch nicht mehr weg. Es könnte aber noch theoretisch der Fall eintreten, dass auch genau an diesen Singularitäten von \($\operatorname{C_{FPS}}$\) ein Gimbal-Lock auftritt.
  • Jedoch ist auch dies nicht der Fall: Wie wir obiger Auflistung der Gimbal-Lock-Winkel für \($\operatorname{XZY}$\) entnehmen können, träte der Gimbal-Lock bei \($\varphi = \mp 90^\circ$\) auf. D.h. in obiger Animation sind wir zweimal durch den Gimbal-Lock gelaufen, und es hat uns nicht gestört! Außerdem ist hier das Eintreten des Gimbal-Locks nicht vom Nord- oder Südpol abhängig, sondern von der Mausbewegung nach links/rechts! Es macht uns aber überhaupt keine Probleme, weil wir nicht Rollen wollen.
Ich muss somit hier zum Schluss kommen, dass es sich nicht um einen Gimbal Lock handelt. Es liegt an der Parametrisierung mit Polarkoordinaten, wie sie in \($\operatorname{C_{FPS}}$\) verwendet wird. ;)
Stephan Theisgen
Beiträge: 94
Registriert: 29.07.2003, 11:13

Re: Gimbal Lock

Beitrag von Stephan Theisgen »

Sehr interessante Ausführungen... Das muss ich mir erstmal zu Gemüte führen...

Genau, ein Problem wird der Gimbal Lock erst, wenn wir Rollen wollen würden. Ich frage mich nur immer, ob das nur daran liegt, dass wir von vornherein rollen wollen. Was ist eigentlich, wenn ich jedesmal meine Koordinatenachsen aktualisiere und dann erst entscheide zu Rollen, dann sollte das ganze kein Problem darstellen oder?
Mathematisch gesagt, global weisen die Eulerwinkel den Gimbal Lock auf, lokal auch? Sprich ist die Darstellung vielleicht lokal nicht singulär? Keine Ahnung, wie ich das besser ausdrücken soll...
Benutzeravatar
dot
Establishment
Beiträge: 1734
Registriert: 06.03.2004, 18:10
Echter Name: Michael Kenzel
Kontaktdaten:

Re: Gimbal Lock

Beitrag von dot »

eXile hat geschrieben:Konvertiert man die von \($\operatorname{C_{FPS}}$\) zurückgegebenen Kugelkoordinaten in zweiter und dritter Komponente in euklidische Koordinaten, sehen wir, dass wir bereits zwei Singularitäten haben. Und zwar genau den von mir angesprochenen Nord- und Südpol.
Genau das meinte ich auch. Wir haben dort einen Gimbal Lock, nämlich eben den Gimbal Lock der Kugelkoordinaten. Die Abbildung der Mauskoordinaten auf Winkel hat dort keine Singularität, sondern die resultierende Rotation, wenn man die abgebildeten Winkel als Kugelkoordinaten interpretiert...

Bei einer Eulersequenz verliert der dritte Winkel bei bestimmten Werten des zweiten Winkels seine Bedeutung \($\Leftrightarrow$\) Gimbal Lock
Bei Kugelkoordinaten (XY Sequenz) verliert der Azimut im Zenit bzw. Nadir (also bei bestimmten Werten des ersten Winkels) seine Bedeutung \($\Leftrightarrow$\) Gimbal Lock


Btw: Mit was hast du das coole .gif gemacht? :)

Edit: Das war völliger Blödsinn
Zuletzt geändert von dot am 27.01.2013, 12:38, insgesamt 4-mal geändert.
Stephan Theisgen
Beiträge: 94
Registriert: 29.07.2003, 11:13

Re: Gimbal Lock

Beitrag von Stephan Theisgen »

Bei einer Eulersequenz verliert der dritte Winkel seine Bedeutung ⇔ Gimbal Lock
Bei Kugelkoordinaten verliert der Azimut im Zenit bzw. Nadir seine Bedeutung ⇔ Gimbal Lock
Sehr interessante Diskussion, ich lerne gerade und lerne und lerne, ganz neben bei, phantastisch...
Benutzeravatar
dot
Establishment
Beiträge: 1734
Registriert: 06.03.2004, 18:10
Echter Name: Michael Kenzel
Kontaktdaten:

Re: Gimbal Lock

Beitrag von dot »

Wobei ich nochmal drüber nachgedacht hab und mich vor eXiles ausführlicher Argumentation respektvoll verneigen muss ;). Die den Kugelkoordinaten entsprechenden kartesischen Koordinaten haben dort eine Singularität, die XY Sequenz aber nicht. Bei dem Beispiel mit der FPS Kamera handelt es sich tatsächlich nicht um Gimbal Lock. Ich hab den selben Fehler gemacht wie die Wikipedia...
Benutzeravatar
dot
Establishment
Beiträge: 1734
Registriert: 06.03.2004, 18:10
Echter Name: Michael Kenzel
Kontaktdaten:

Re: Gimbal Lock

Beitrag von dot »

Ok, nochmal drüber nachgedacht: Die oben verlinkte Erklärung in der Wikipedia ist imo schlüssig und auf unser FPS Kamera Beispiel anwendbar. Ich bin mir noch nicht sicher, wo genau das Problem liegt und hab leider grad nicht genug Zeit mich genauer damit zu befassen. Rein intuitiv würd ich jedenfalls mal vermuten, dass es in die Richtung geht, dass die XY Sequenz zwar stetig und bijektiv ist, der Tangentialraum im Zenit bzw. Nadir aber an Dimension verliert. D.h. man müsste Gimbal Lock als eine Art Singularität der Ableitung und nicht als Singularität der Abbildung selbst definieren!?
Alexander Kornrumpf
Moderator
Beiträge: 2112
Registriert: 25.02.2009, 13:37

Re: Gimbal Lock

Beitrag von Alexander Kornrumpf »

dot hat geschrieben:Wobei ich nochmal drüber nachgedacht hab und mich vor eXiles ausführlicher Argumentation respektvoll verneigen muss ;). Die den Kugelkoordinaten entsprechenden kartesischen Koordinaten haben dort eine Singularität, die XY Sequenz aber nicht. Bei dem Beispiel mit der FPS Kamera handelt es sich tatsächlich nicht um Gimbal Lock. Ich hab den selben Fehler gemacht wie die Wikipedia...
Das Problem bei dem Teleskopbeispiel ist nicht dass die zwei Gimbals parallel ausgerichtet sind. Du verlierst dadurch keinen Freiheitsgrad, weil die Achsen immer noch Orthogonal zueinander sind. Achsparallität ist ein Problem, Ringparalleltät nicht. Das Problem ist dass du um dem Helikopter zu folgen ein drittes Gimbal bräuchtest, also einen Freiheitgrad, der physikalisch in der arretierung des Telekops nie da war. Es ist kein Gimbal Lock sondern einfach ein Problem das auftritt, wenn man im 3D-Raum nur zwei Freiheitsgrade zulässt. Der Wikipedia Artikel ist falsch (Wenn man Gimbal Lock als das Align mehrerer Gimbalachsen definiert).

EDIT: Um Unklarheiten zu vermeiden: Ob das dritte Gimbal helfen würde dem Heli im Beispiel zu folgen hängt wohl tatsächlich von der Rotationsreihenfolge also der Anordnung der Gimbals von außen nach innen ab. Zumindest soweit ich mir das jetzt im Kopf vorstellen konnte.
Benutzeravatar
dot
Establishment
Beiträge: 1734
Registriert: 06.03.2004, 18:10
Echter Name: Michael Kenzel
Kontaktdaten:

Re: Gimbal Lock

Beitrag von dot »

Alexander Kornrumpf hat geschrieben:Der Wikipedia Artikel ist falsch (Wenn man Gimbal Lock als das Align mehrerer Gimbalachsen definiert).
Korrekt, allerdings ist Gimbal Lock eben nicht als das Align mehrer Achsen definiert, sondern als der Verlust eines Freiheitsgrades, der bei Eulerwinkeln allerdings eben genau dann auftritt, wenn Achsen alignen. Beim Teleskopbeispiel geht genauso ein Freiheitsgrad verloren...
Alexander Kornrumpf
Moderator
Beiträge: 2112
Registriert: 25.02.2009, 13:37

Re: Gimbal Lock

Beitrag von Alexander Kornrumpf »

dot hat geschrieben:
Alexander Kornrumpf hat geschrieben:Der Wikipedia Artikel ist falsch (Wenn man Gimbal Lock als das Align mehrerer Gimbalachsen definiert).
Korrekt, allerdings ist Gimbal Lock eben nicht als das Align mehrer Achsen definiert, sondern als der Verlust eines Freiheitsgrades, der bei Eulerwinkeln allerdings eben genau dann auftritt, wenn Achsen alignen. Beim Teleskopbeispiel geht genauso ein Freiheitsgrad verloren...
Nein, ein Teleskop hat qua Konstruktion nur zwei Freiheitsgrade (schwenk und kipp). Und die sind auch dann noch unabhängig wenn du es sekrecht stellst.
Benutzeravatar
dot
Establishment
Beiträge: 1734
Registriert: 06.03.2004, 18:10
Echter Name: Michael Kenzel
Kontaktdaten:

Re: Gimbal Lock

Beitrag von dot »

Im Zenit und Nadir hat das Teleskop aber eben nurmehr einen Freiheitsgrad, oder täusch ich mich da?
Alexander Kornrumpf
Moderator
Beiträge: 2112
Registriert: 25.02.2009, 13:37

Re: Gimbal Lock

Beitrag von Alexander Kornrumpf »

dot hat geschrieben:Im Zenit und Nadar hat das Teleskop aber eben nurmehr einen Freiheitsgrad, oder täusch ich mich da?
Jain. Weil es halt zylindrisch ist täuscht das.

Im Zenit kannst du es um die "eigene Achse" drehen. Das ändert die Orientierung des Dings schon. Aber nicht wo du hinschaust wenn du durchschaust. Bei einem asymmetrischen Gegenstand wäre das aber ein echter Freiheitsgrad. Und darum geht es doch.

Ich denke das passiert auch mit der Kamera, die ja auch nur ein besseres Teleskop ist. Es ist eben was anderes ob du von außen auf das Gibal schaust, oder ob dein "Auge" selbst darin eingebaut ist.
Benutzeravatar
dot
Establishment
Beiträge: 1734
Registriert: 06.03.2004, 18:10
Echter Name: Michael Kenzel
Kontaktdaten:

Re: Gimbal Lock

Beitrag von dot »

Alexander Kornrumpf hat geschrieben:Im Zenit kannst du es um die "eigene Achse" drehen. Das ändert die Orientierung des Dings schon. Aber nicht wo du hinschaust wenn du durchschaust. Bei einem asymmetrischen Gegenstand wäre das aber ein echter Freiheitsgrad. Und darum geht es doch.
Genau diese Tatsache wollte ich mit diesem "steig, bijektiv aber degeneriertem Tangentialraum" Konstrukt berücksichtigen. Nachdem ich nun aber nochmals drüber nachgedacht hab, ist mir sonnenklar, dass die gewünschte Bewegung über eine Orientierung führt, die sich tatsächlich durch keine Trajektorie des Systems erreichen ließe. Das Teleskop verliert natürlich keinen Freiheitsgrad, das Beispiel in der Wikipedia ist Bullshit und eXiles Argumentation steht nach wie vor felsenfest in der Brandung... ;)
Zuletzt geändert von dot am 27.01.2013, 17:54, insgesamt 1-mal geändert.
Alexander Kornrumpf
Moderator
Beiträge: 2112
Registriert: 25.02.2009, 13:37

Re: Gimbal Lock

Beitrag von Alexander Kornrumpf »

Keine Ahnung. Der Begriff kommt ja offensichtlich vom Lock zweier Gimbals. Und das passiert nie wenn du von Anfang an nur zwei Gimbals hast. Übertragener Sinn kann anders sein.

Wieder auf die FPS Kamera angewendet: Wäre die Kamera in zwei Gimbals gelagert, dann müsste das Bild im Zenit "rollen", wenn man "schwenkt". Man kann aber trotzdem noch unabhängig davon kippen (tilt sagt man bei Kameras glaube ich). Man hat halt einen Freiheitsgrad den man will (schwenk) gegen einen eingebüßt der cinematisch gesehen nichts nützt (rollen). Aber es sind physikalisch gesehen noch zwei da. Wenn das nicht klappt liegt es wie Exile sagte an der Abbildung einer 2D Fläche auf Rotationswinkel, nicht am Gimbal Lock. Mit einem echten Gimbal im 3D Raum lockt da nichts.

EDIT: Das beantwortete eine Frage, die dot wegeditiert hat.
Jetzt wo wir uns einig sind: wer repariert Wikipedia?
Benutzeravatar
dot
Establishment
Beiträge: 1734
Registriert: 06.03.2004, 18:10
Echter Name: Michael Kenzel
Kontaktdaten:

Re: Gimbal Lock

Beitrag von dot »

Jap, du warst leider etwas zu schnell... ;)
Benutzeravatar
Jonathan
Establishment
Beiträge: 2367
Registriert: 04.08.2004, 20:06
Kontaktdaten:

Re: Gimbal Lock

Beitrag von Jonathan »

Ihr seid cool Jungs! Wissenschaft live :D
Lieber dumm fragen, als dumm bleiben!
https://jonathank.de/games/
Alexander Kornrumpf
Moderator
Beiträge: 2112
Registriert: 25.02.2009, 13:37

Re: Gimbal Lock

Beitrag von Alexander Kornrumpf »

Jonathan hat geschrieben:Ihr seid cool Jungs! Wissenschaft live :D
Der Respekt gebührt allein eXile. Aber mir wäre wirklich wohler dabei jemand würde Wikipedia fixen. Das macht mich total nervös.
Benutzeravatar
eXile
Establishment
Beiträge: 1136
Registriert: 28.02.2009, 13:27

Re: Gimbal Lock

Beitrag von eXile »

Fixt nicht die Wikipedia. Sowohl Wikipedia wie auch mein letzter Post sind korrekt, und ich erkläre auch wieso.

Das alles lässt sich in ein konsistentes Gesamtbild zusammenfügen:
  • Die Kameraparametrisierung wird in jedem Fall Singularitäten am Nord- und Südpol erzeugen
  • Bei allen für FPS-Kameras verwendbaren Euler-Winkel-Notationen mit Ausnahme einer einzigen wird in diesen Singularitäten kein Gimbal-Lock angenommen
  • Es gibt jedoch genau eine Euler-Winkel-Notation, wo genau am Nord- und Südpol und nur dort ein Gimbal-Lock einsteht:
    • Nämlich bei \($\operatorname{YZX}$\)
    • Immer vorausgesetzt man benutzt ein Direct3D-Koordinatensystem
Wenn wir also \($\operatorname{YZX}$\) verwenden, haben wir am Nord- und Südpol sowohl eine Singularität in der Parametrisierung, als auch einen Gimbal-Lock. In allen anderen Fällen haben wir am Nord- und Südpol jeweils eine Singularität in der Parametrisierung, aber keinen Gimbal-Lock dort. In beiden Fällen haben wir das FPS-typische Kameraverhalten an den Singularitäten, d.h. dieses wird nicht durch den Gimbal-Lock ausgelöst.

Wenn man also annimmt, dass die Euler-Notation \($\operatorname{YZX}$\) bei einem solchen Fernrohr vorliegt, könnte durchaus ein Gimbal-Lock vorliegen. Schließlich wird beim Anvisieren des Helikopters die euklidische Koordinatenposition anvisiert, und wir haben keinen Funker, der uns zwei Kugelwinkel durchgibt. Damit gibt es dort auch keinen Zwischenschritt wie hier mit \($\operatorname{C_{FPS}}$\) und dann erst einer Euler-Rotation.

Wir haben dummerweise nun einmal nur eine zweidimensionale Mausposition als Eingabe; daher müssen wir parametrisieren und erzeugen dabei Singularitäten. Hätten wir ein magisches Eingabegerät, mit der wir einfach sagen können „schau dir mal den Punkt \($(x,y,z)^{\mathrm T}$\) an“, hätten wir keine Probleme.

Man könnte als überraschendes Fazit sagen, dass \($\operatorname{YZX}$\) besonders gut für eine First-Person-Kamera geeignet ist (sofern man überhaupt für die Berechnung dieser Kamera wirklich Euler-Winkel, und nicht gleich Quaternionen verwenden will):
  • Wenn man nicht Rollen will, ist sie so gut wie jede andere Euler-Winkel-Notation
  • Wenn man Rollen will, dann erzeugt der Gimbal-Lock ein "intuitives" Verhalten:
    • Schaut man nicht zum Nord- oder Südpol, rollt man ganz normal
    • Schaut man zum Nord- oder Südpol, kriegt man, wenn man rollt, den gleichen Effekt, als ob man die Maus nach links/rechts bewegen würde :)
Das GIF habe ich übrigens mittels Mathematica ausgegeben lassen. Hier mal der ganze Code, falls der interessant ist:

Code: Alles auswählen

Rx[\[Theta]_] = RotationMatrix[\[Theta], {1, 0, 0}]

Ry[\[Theta]_] = RotationMatrix[\[Theta], {0, 1, 0}]

Rz[\[Theta]_] = RotationMatrix[\[Theta], {0, 0, 1}]

(* Generate all Euler notations *)
R1[\[Theta]_, \[Phi]_, \[Psi]_] = 
  Simplify[Rx[\[Theta]].Ry[\[Phi]].Rz[\[Psi]]];
R2[\[Theta]_, \[Phi]_, \[Psi]_] = 
  Simplify[Rx[\[Theta]].Rz[\[Phi]].Ry[\[Psi]]];
R3[\[Theta]_, \[Phi]_, \[Psi]_] = 
  Simplify[Ry[\[Theta]].Rx[\[Phi]].Rz[\[Psi]]];
R4[\[Theta]_, \[Phi]_, \[Psi]_] = 
  Simplify[Ry[\[Theta]].Rz[\[Phi]].Rx[\[Psi]]];
R5[\[Theta]_, \[Phi]_, \[Psi]_] = 
  Simplify[Rz[\[Theta]].Rx[\[Phi]].Ry[\[Psi]]];
R6[\[Theta]_, \[Phi]_, \[Psi]_] = 
  Simplify[Rz[\[Theta]].Ry[\[Phi]].Rx[\[Psi]]];
R7[\[Theta]_, \[Phi]_, \[Psi]_] = 
  Simplify[Rx[\[Theta]].Ry[\[Phi]].Rx[\[Psi]]];
R8[\[Theta]_, \[Phi]_, \[Psi]_] = 
  Simplify[Rx[\[Theta]].Rz[\[Phi]].Rx[\[Psi]]];
R9[\[Theta]_, \[Phi]_, \[Psi]_] = 
  Simplify[Ry[\[Theta]].Rx[\[Phi]].Ry[\[Psi]]];
R10[\[Theta]_, \[Phi]_, \[Psi]_] = 
  Simplify[Ry[\[Theta]].Rz[\[Phi]].Ry[\[Psi]]];
R11[\[Theta]_, \[Phi]_, \[Psi]_] = 
  Simplify[Rz[\[Theta]].Rx[\[Phi]].Rz[\[Psi]]];
R12[\[Theta]_, \[Phi]_, \[Psi]_] = 
  Simplify[Rz[\[Theta]].Ry[\[Phi]].Rz[\[Psi]]];

(* In these angles we will have a gimbal lock - visible because of \
the addition of angles in the resulting matrix *)
Simplify[R1[\[Theta], 90 Degree, \[Psi]]]
Simplify[R2[\[Theta], -90 Degree, \[Psi]]]
Simplify[R3[\[Theta], -90 Degree, \[Psi]]]
Simplify[R4[\[Theta], 90 Degree, \[Psi]]]
Simplify[R5[\[Theta], 90 Degree, \[Psi]]]
Simplify[R6[\[Theta], -90 Degree, \[Psi]]]
Simplify[R7[\[Theta], 0 Degree, \[Psi]]]
Simplify[R8[\[Theta], 0 Degree, \[Psi]]]
Simplify[R9[\[Theta], 0 Degree, \[Psi]]]
Simplify[R10[\[Theta], 0 Degree, \[Psi]]]
Simplify[R11[\[Theta], 0 Degree, \[Psi]]]
Simplify[R12[\[Theta], 0 Degree, \[Psi]]]

(* We want to use a left-handed coordinate system, like in Direct3D. \
Invert some axis. Here, we invert the z-Axis. *)
InvertZ[x_] := {x[[1]], x[[2]], -x[[3]]};

(* Use a simpe mouse to Euler-angle transformation for R2 *)
MouseToAngle[mx_, my_] = {Pi/2, 
   Mod[2 Pi*mx + Pi/2 , 2 Pi], -Pi*my + Pi/2};

(* Play with R2: Use \[Phi] and \[Psi] *)
Manipulate[Graphics3D[{Thick,
   Red, Line[{{0, 0, 0}, InvertZ [{1, 0, 0}]}],
   Green, Line[{{0, 0, 0}, InvertZ[{0, 1, 0}]}],
   Blue, Line[{{0, 0, 0}, InvertZ[{0, 0, 1}]}],
   Orange, 
   Line[{{0, 0, 0}, InvertZ[R2[\[Theta], \[Phi], \[Psi]].{1, 0, 0}]}],
   Gray, Line[{{0, 0, 0}, 
     InvertZ[R2[\[Theta], \[Phi], \[Psi]].{0, 0.5, 0}]}],
   Gray, Line[{{0, 0, 0}, 
     InvertZ[R2[\[Theta], \[Phi], \[Psi]].{0, 0, 0.5}]}]},
  {PlotRange -> {{-1, 1}, {-1, 1}, {-1, 1}}, 
   ViewVertical -> {0, 1, 0}, ViewPoint -> {1.5, 2, 1}}], {{\[Theta], 
   90 Degree}, 0, 2 Pi}, {\[Phi], 0, 2 Pi}, {{\[Psi], 100 Degree}, 0, 
  2 Pi}]

(* Play with R2: Use mx and my *)
Manipulate[Graphics3D[{Thick,
   Red, Line[{{0, 0, 0}, InvertZ [{1, 0, 0}]}],
   Green, Line[{{0, 0, 0}, InvertZ[{0, 1, 0}]}],
   Blue, Line[{{0, 0, 0}, InvertZ[{0, 0, 1}]}],
   Orange, 
   Line[{{0, 0, 0}, InvertZ[R2 @@ MouseToAngle[mx, my].{1, 0, 0}]}],
   Gray, Line[{{0, 0, 0}, 
     InvertZ[R2 @@ MouseToAngle[mx, my].{0, 0.5, 0}]}],
   Gray, Line[{{0, 0, 0}, 
     InvertZ[R2 @@ MouseToAngle[mx, my].{0, 0, 0.5}]}]},
  {PlotRange -> {{-1, 1}, {-1, 1}, {-1, 1}}, 
   ViewVertical -> {0, 1, 0}, ViewPoint -> {1.5, 2, 1}}],
 {mx, 0, 1}, {my, 0, 1}]

(* Plot the R2 rotation animation *)
rotationAnimation = Table[Graphics3D[{Thick,
     Red, Line[{{0, 0, 0}, InvertZ [{1, 0, 0}]}],
     Green, Line[{{0, 0, 0}, InvertZ[{0, 1, 0}]}],
     Blue, Line[{{0, 0, 0}, InvertZ[{0, 0, 1}]}],
     Orange, 
     Line[{{0, 0, 0}, 
       InvertZ[R2 @@ MouseToAngle[mx, 0.05].{1, 0, 0}]}],
     Gray, 
     Line[{{0, 0, 0}, 
       InvertZ[R2 @@ MouseToAngle[mx, 0.05].{0, 0.5, 0}]}],
     Gray, 
     Line[{{0, 0, 0}, 
       InvertZ[R2 @@ MouseToAngle[mx, 0.05].{0, 0, 0.5}]}]},
    {PlotRange -> {{-1, 1}, {-1, 1}, {-1, 1}}, 
     ViewVertical -> {0, 1, 0}, ViewPoint -> {1.5, 2, 1}}],
   {mx, 0, 1, 0.025}];

(* Safe the animation as a GIF *)
Export["animation.gif", rotationAnimation, "DisplayDurations" -> 0.01]
Und noch ein paar Aufzeichnungen, falls ich sie jemals wieder brauche:

Code: Alles auswählen

Rotation um den Nordpol:

R1: 	theta=0		phi=[0, 2Pi]	psi=90
	-		var		eps		1 Lösung

R2:	theta=90	phi=[0, 2Pi]	psi=90
	-		var		eps		1 Lösung

R3:	theta=[0, 2Pi]	phi=0		psi=90
	var		eps		eps		2 Lösungen

R4:	theta=[0, 2Pi]	phi=90		psi=0		
	var		eps		-		1 Lösung, Gimbal Lock

R5:	theta=90	phi=[0, 2Pi]	psi=0
	-		var		eps		1 Lösung

R6:							Keine einparametrische Lösung
	-		-		var		0 Lösungen



R7:							Keine einparametrische Lösung
	-		-		var		0 Lösungen

R8:							Keine einparametrische Lösung
	-		-		var		0 Lösungen

R9:	theta=[0, 2Pi]	phi=90		psi=90
	var		eps		eps		2 Lösungen

R10:	theta=[0, 2Pi]	phi=90		psi=0
	var		eps		eps		2 Lösungen

R11:	theta=90	phi=[0, 2Pi]	psi=0
	-		var		eps		1 Lösung

R12:	theta=0		phi=[0, 2Pi]	psi=90		
	-		var		eps		1 Lösung



3x 0 Lösungen
6x 1 Lösung (5x ohne, 1x mit Gimbal Lock)
3x 2 Lösungen
Antworten