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
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.
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...
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.
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.
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.
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.
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?
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.
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.
