Wieso ruft ihr imu_v2_get_quaternion() auf und formt das in Euler-Winkel um anstatt direkt imu_v2_get_orientation() den Euler-Winkel auszulesen?
Wieso ruft ihr imu_v2_get_quaternion() auf und formt das in Euler-Winkel um anstatt direkt imu_v2_get_orientation() den Euler-Winkel auszulesen?
wenn du mir erklärst was genau die in der doku mit dem gimballock meinen und warum sie dazu raten die quaternioen zu benutzen? wenn ich es recht verstehe, drehst du das ding auf hochkant und bekommst keine ausrichtugn mehr ... über die quaternionen soll dasd wohl nicht passieren, solange man die ausrichtung der achsen berücksichtigt ... meinem verständnis nach muss man das dann selber machen, weswegen ich den obigen ansatz verfolge ...
denke ich habe das WE mal irgendwo zwit dazwischen um mich wieder ran zu setzen
PS: nicht erklären was gimballock ist, sondern im konkreten kontext dieses sensors und warum sie davor warnen wenn nicht gemeint ist was ich gerade als annahme geschrieben habe![]()
Es gibt 10 Sorten von Menschen: Die einen können binär zählen, die anderen
nicht.
Ja, die Quaternion-Darstellung ist ohne Gimbal Lock. Allerdings nur solange wie man bei Quaternionen bleibt, bei der Umrechnung in Euler verliert man deren Vorteile.
Gimbal Lock ist in der Deutschen Wikipedia leider nicht mathematisch erklärt, bei Drehungen kann es zu Singularitäten (Sprünge bei einem Pitch von +90/-90°) kommen, Eine gute Erklärung kriege ich leider nicht hin, deswegen der Verweis auf [1].
Der Punkt ist: Das Problem hat man (soweit ich das verstehe) bei Berechnungen, z.B. Gegeben ist eine Position A. Welche Drehung d muss ich anwenden um zu Position B zu kommen. Beim einfachen auslesen des aktuellen Winkels, um die Drehung im 3D-Raum zu lesen kommt es zu keinem Problem. Die Eulerwinkel des IMU Bricks 2 sind hier nicht besser oder schlechter als die Eulerwinkel anderer IMUs.
[1] https://zfx.info/viewtopic.php?p=35924#p35924
Geändert von Defiant (05.08.2017 um 09:45 Uhr)
Lesezeichen