Forum: Mikrocontroller und Digitale Elektronik Quaternion IMU Winkelanalyse


von Sven (Gast)


Angehängte Dateien:

Lesenswert?

Hallo zusammen,

ich versuche momentan mit matlab aus Sensordaten den Winkelverlauf für 
die Drehung um die Z-Achse herauszubekommen. Ich habe folgende 
Sensorinformationen:
- Zeit: t
- Beschleunigungsdaten: ax, ay und az
- Drehraten: qw, qx, qy, qz

Mein bisheriges Programm sieht gekürzt folgendermaßen aus:
% Einlesen der Daten
xxx

%% Quaternion bilden
quat = quaternion(qw,qx,qy,qz);
Q = compact(quat);                    % als Nx4 Matrix

%% Drehung um die Z-Achse
drehax  = [0, 0, 1];
vec = quatrotate(quatinv(Q), drehax);
vec = atan2d(vec(:,1), vec(:,2));
plot(t, vec)

Außerdem habe ich eine Simulation erstellt, die die Bewegung sehr gut 
abbildet. (Siehe Anhang) Dabei habe ich nur die Drehraten genutzt.

Jetzt bin ich mir bei der Auswertung der Dateien allerdings nicht mehr 
sicher, ob es der richtige Weg ist, um die Drehung um die Z-Achse 
darzustellen, weil das Ergebnis der Plots nicht dem entspricht was ich 
mir im vorhinein erhofft hatte. Reichen die Quaternionen aus oder 
benötige ich dafür noch die Beschleunigungsdaten und weitere 
Integrationen?

über einen Tipp würde ich mich sehr freuen!

Viele Grüsse

Sven

von Walter T. (nicolas)


Lesenswert?

Wenn Du aus einer Drehrate eine Drehung berechnen willst - egal ob 
Quaternionen, Eulerwinkel oder natürliche Koordinaten ( = direction 
cosinus) - wirst Du in irgendeiner Form integrieren müssen. Dabei 
entsteht auch eine unvermeidbare Drift.

Am einfachsten geht das Integrieren in natürlichen Koordinaten.

Sven schrieb:
> vec = quatrotate(quatinv(Q), drehax);

Damit drehst Du das Koordinatensytem um Körper um die Z-Achse. Damit 
hast Du nicht den Drehwinkel. Du brauchst die Projektion der Drehung auf 
die Z-Achse.

Beim konkreten Matlab-Problem kann ich nichts sagen. Ich habe nie die 
aerospace-Toolbox besessen oder genutzt.

Ich nehme an, dass "quad2angle" oder "quad2dcm" Deine Freunde sind.

: Bearbeitet durch User
von Sven (Gast)


Angehängte Dateien:

Lesenswert?

Danke für die schnelle Antwort.

In der Tat habe ich einen weiteren Kurzcode mit Quat2angle geschrieben, 
der mir für meine Testdaten ganz gute Ergebnisse liefert. Allerdings 
sind die Plots der originalen Ergebnisse durchsäht mit Sprüngen, wie man 
im Anhang sehen kann. Hat dafür jemand eine Erklärung woran das liegen 
könnte?
Eigentlich sind es nahezu die gleichen Bewegung...

von Walter T. (nicolas)


Lesenswert?

Sven schrieb:
> Allerdings
> sind die Plots der originalen Ergebnisse durchsäht mit Sprüngen, wie man
> im Anhang sehen kann. Hat dafür jemand eine Erklärung woran das liegen
> könnte?

Jetzt interessiert mich aber doch, in welchem Schuljahr mit Matlab und 
Quaternionen herumgespielt wird. Und in welchem die Tatsache, dass -180° 
= +180° entspricht, behandelt wird.

: Bearbeitet durch User
von Sven (Gast)


Lesenswert?

Es ist ein Uniprojekt mit Matlabneulingen.
Ja, diese Sprünge sind ja das Problem, aber ich finde leider keine 
Lösung, um das Problem zu umgehen. Eigentlich hatte ich extra auf 
Quaternionen gesetzt, um den Gimbal Lock bei den Euler Winkeln zu 
umgehen.
Gibt es da einen Trick? Einfach alles in Betrag nehmen, würde ja auch 
die Daten verfälschen.

von Walter T. (nicolas)


Lesenswert?

Sprünge in der Winkel-Interpretation der Rotation sind kein Gimbal-Lock. 
Sie sind einfach nur ein Interpretationsfehler.

Welcher Studiengang ist es denn? Momentan gehe ich davon aus, dass die 
korrekte Interpretation der Winkeldaten eine Fingerübung ist, die man 
einfach mal gemacht haben sollte.

: Bearbeitet durch User
von Mirko W. (Gast)


Lesenswert?

Diese Sprünge sind ja nur scheinbar da. Das liegt eben an der Wahl der 
RPY-Koordinaten. Z. B. solltest du sehen, dass die Komponenten der 
Quaternionen nicht springen. Falls doch, dann ist irgendwas faul.

Wenn du dir einen Körper oder eine Rotationsmatrix mit deinen Daten 
visualisierst (also animiert im Zeitablauf), dann solltest du sehen, 
dass die Rotationen nicht springen.

Wie so oft: wenn man etwas nicht gut visualisiert, ist es unfassbar 
schwer, es zu verstehen.

von Sven (Gast)


Lesenswert?

Es ist ein Ingenieurwissenschaftlicher Studiengang und es soll eine 
Bewegung von einem Paddel analysiert werden.
Die Interpretation im Testfile ist kein Problem. Das kann ich 
nachvollziehen, aber mit den Originaldaten zerbreche ich mir den Kopf 
und komme nicht von der Stelle. Hast du ein ähnliches Problem schon mal 
bearbeitet?

von Walter T. (nicolas)


Lesenswert?

Sven schrieb:
> Es ist ein Ingenieurwissenschaftlicher Studiengang und es soll eine
> Bewegung von einem Paddel analysiert werden.

Dann bleibe ich bei der obigen Aussage,

Walter T. schrieb:
> [...], dass die
> korrekte Interpretation der Winkeldaten eine Fingerübung ist, die man
> einfach mal gemacht haben sollte.

Sven schrieb:
> [...] aber mit den Originaldaten zerbreche ich mir den Kopf
> und komme nicht von der Stelle.

Das schöne an Matlab ist: Man kann damit hervorragend seine Daten 
darstellen.  Auch animiert. Deine Freunde sind plot3(), quiver3(), 
patch(). Wenn man nicht weiterkommt, ist das ein sinnvoller 
Zwischenschritt, um Einsicht in die Daten zu bekommen. Wenn man bedenkt, 
dass die Richtungskosinusmatrix ein normalisiertes Dreibein ist, ist 
eine animierte Darstellung der Drehung ein Kinderspiel (wurde ja auch 
schon im Eröffnungsposting gemacht).

Sven schrieb:
> Hast du ein ähnliches Problem schon mal
> bearbeitet?

Kann man so sagen.

: Bearbeitet durch User
von M. Н. (Gast)


Lesenswert?

Hallo,

ohne einen fixen Referenzpunkt, wie z.B. ein Magnetsensor, der das 
Erdmagnetfeld misst, wirst du um den Yaw Winkel (Hochachse) kein genaues 
Ergebnis bekommen, da die Integration deiner Drehrate den Wert driften 
lässt und es keine Gravitationskomponente für den Beschleunigungssensor 
gibt, die das korrigieren könnte. Mit einem gut offset-getrimmten 
Gyroskop (Automtive Grade) komme ich selsbt auf einen drift von einigen 
Grad pro Stunde (Die Drehung der Erdachse ist korrigiert, bevor jemand 
meckert). Aber auch das driftet und wird weglaufen.

Wenn du nach einem guten AHRS Algorithmus suchst, kann ich dir den 
Madgwick-Algorithmus empfehlen: 
https://x-io.co.uk/open-source-imu-and-ahrs-algorithms/

Dieser ist open source und recht gut beschrieben. Ebenso gibt es C Code, 
der auch funktioniert. Du kannst diesen Algorithmus auch mit einem 
Magnetfeldsensor nutzen. Dann bekommt man auch ein gutes Ergebnis in 
allen 3 Eulerwinkeln.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.