aortner Geschrieben January 8, 2018 at 07:02 Geschrieben January 8, 2018 at 07:02 Hallo. Ich möchte dem imu brick 2 benutzen um mein GPS zu korrigieren. Ich brauche es für einen Landwirtschaftlichen Zweck. Dazu brauche ich ein stabiles Heading und Roll um den Hang auszugleichen. Bei unseren Test stellten wir ein relatives großen Drift beim Roll fest. Wir benutzen IMU_V2_CALLBACK_ORIENTATION um die Daten auszulesen. Woran kann das liegen? Zitieren
borg Geschrieben January 8, 2018 at 20:46 Geschrieben January 8, 2018 at 20:46 Ein Drift kommt oft Zustande wenn sich Magnetfelder in der Umgebung ändern. Welchen "Sensor Fusion Mode" verwendet ihr? Gibt es irgendein spezielles Event bei ~1200 Sekunden welches dazu geführt hat das der Wert zurückspringt? Zitieren
aortner Geschrieben January 8, 2018 at 21:14 Autor Geschrieben January 8, 2018 at 21:14 Derzeit sind das nur 3 Vergleichswerte zw. Imu brick , dog2 (analog) und mpu9250 des Emlid reach gps. Sensor Fusion führen wir noch keine durch . Zitieren
borg Geschrieben January 8, 2018 at 21:20 Geschrieben January 8, 2018 at 21:20 Ich meinte die "set_sensor_fusion_mode" Funktion. Damit kann man einen Fusion-Modus ohne Magnetometer auswählen, dann kann es nicht mehr zu Drift auf Grund von Magnetfeldern kommen. Allerdings kann die IMU dann keine absoluten Werte mehr zurück geben sondern nur noch Veränderungen (ob das für eure Anwendung OK ist weiß ich nicht). Dass das drei Vergleichswerte sind hab ich mir schon gedacht. Bei ~1200 Sekunden sieht es so aus als würden die IMU Brick Daten zurückspringen auf die anderen Daten. Die Frage ist warum das passiert dort? Zitieren
aortner Geschrieben January 8, 2018 at 21:25 Autor Geschrieben January 8, 2018 at 21:25 Ok Danke- bin neu bei der Sache. Derzeit ist nur der callback programmiert alles andere Standard. Vermutlich hat sich die imu dort neu kalibriert. Zitieren
raphael_vogel Geschrieben January 8, 2018 at 21:40 Geschrieben January 8, 2018 at 21:40 @aortner, ich kenn deinen Bericht im Emlid Forum über deinen autonom fahrenden Traktor (mit Reach RTK). Ich versuche mich auch seit einiger Zeit an einem autonom fahrenden Rasenmäher Roboter, hab aber die Investition in Reach RS bisher noch gescheut. Was mich interessiert ist, warum und wie du die Tinkerforge IMU in Zusammenhang mit Reach verwenden willst? Für "Heading" würde doch auch ein einfacher Kompass reichen? Zitieren
aortner Geschrieben January 8, 2018 at 21:47 Autor Geschrieben January 8, 2018 at 21:47 Roll brauchen wir für den hangausgleich da das gps recht hoch montiert ist. Mit imu heading versuchen wir heading zu stabilisieren wie es zb Mit 2 gps Antennen gemacht wird. Hilfe und Ideen sind willkommen! Was meinst du mit Kompass? Zitieren
aortner Geschrieben January 10, 2018 at 20:33 Autor Geschrieben January 10, 2018 at 20:33 ok ich werde es mit imu.SetSensorFusionMode(2); probieren. Zitieren
AlexanderS Geschrieben March 20, 2018 at 21:22 Geschrieben March 20, 2018 at 21:22 Hallo ich habe das gleiche Problem: Roll wandert teilweise stark, obwohl sich die Neigung gar nicht ändert. Auch im imu.SetSensorFusionMode(2) ist das noch zu beobachten Man braucht nur die imu auf einen Tisch legen und seitlich verschieben. Dann ändert sich teilweise auch Roll (bis zu 6°), obwohl die Neigung gar nicht geändert wird. Ist das ein Software / Hardware Fehler ? Ist der Sensor so ungenau ? Ich suche nach Antworten, da an sich der Sensor für unsere Anwendungen perfekt wäre. Nur an der Genauigkeit hapert es etwas Zitieren
Tipsy Tinker Geschrieben April 16, 2021 at 14:56 Geschrieben April 16, 2021 at 14:56 (bearbeitet) Hallo Zusammen, Ich hatte für ein studentisches Projekt auch den Versuch unternommen, mittels des IMU Bricks eine Rotationsbewegung aufzuzeichnen und kämpfe scheinbar mit einer Art Sensordrift, den ich aber mit imu.SetSensorFusionMode(2) wie hier vorgeschlagen, nicht wegbekomme. Am orangen Graph der ermittelten Daten erkennt man das recht gut. Die Werte der Drehbewegung laufen nach dem Nulldurchgang wieder ins Positive, was ja bedeuten würde, dass Real eine Art "Wendung" stattfindet. Allerdings ist real der Bewegungsablauf abgeschlossen. Die Beschleunigungswerte (blauer Graph) und die visuelle Beobachtung entsprechen dem. Den Versuchsaufbau habe ich mal vereinfacht dargestellt. Die Bewegung von Pos. 1.) nach Pos. 2.) soll aufgezeichnet werden. Nach dem Ablauf werden aber weiter Werte aufgezeichnet, die gegenläufig sind. Sind das eigentlich die gleichen Werte, die den IMU in der 3D Anzeige des Brickviewers weiter drehen lassen, wenn er nach dem rumspielen wieder ruhig liegt? Und könnte ein Zusammenhang mit der Kalibrierung, bzw. automatischen Dauerkalibrierung bestehen? Vielleicht hat wer einen Tip, was man prüfen könnte? Gruß Tipsy bearbeitet April 20, 2021 at 08:49 von Tipsy Tinker Pic Position Edit Zitieren
borg Geschrieben April 19, 2021 at 08:15 Geschrieben April 19, 2021 at 08:15 Wenn die IMU sich nach einer Zeit im Brick Viewer noch dreht liegt das für gewöhnlich am Magnetometer. Der Fusion-Algorithmus stellt dann fest, dass die absolute Position die durch Beschleunigungssensor/Gyroskop bestimmt wurde bezüglich der Richtung nicht mehr zum Magnetfeld passt und kalibriert sich entsprechend neu. Das kann z.B. gut passieren wenn man die IMU bewegt und sie dabei näher an einen Monitor ranbringt der ein Magnetfeld ausstrahlt. Dies bezieht die IMU dann (fälschlicherweise) mit ein und kalibriert sich darauf. Das gleiche wieder umgekehrt wenn man sie wieder weiter weg bewegt. Bezüglich des Graphen oben: Entweder die IMU hat sich wirklich erst rechtsrum um eine Achse gedreht und beim stoppen gibt es eine leichte Drehung zurück, oder es ist irgendeine Art Überschwingen des Gyroskops was dann wieder zurück schwingt. Zitieren
Tipsy Tinker Geschrieben April 19, 2021 at 19:29 Geschrieben April 19, 2021 at 19:29 Moin, vor 10 Stunden schrieb borg: an einen Monitor ranbringt der ein Magnetfeld ausstrahlt Ja, das konnte ich reproduzieren. Hatte ich in einem anderen Post von Dir schonmal wo gelesen. Mein Problem konnte ich lösen, in dem ich set_sensor_fusion_mode(0) gewählt habe. Hatte zunächst set_sensor_fusion_mode(2) versucht, allerdings hat das ja, wie oben beschrieben keine Abhilfe geschaffen. Hat wohl nicht ausgereicht, das Magnetometer abzuwählen. Die Verwendung von unkalibrierten und unkompensierten Sensorwerten genügt wohl im dargelegten Anwendungsfall. vor 10 Stunden schrieb borg: eine leichte Drehung zurück Im Zeitlupenvideo kann ich diese nicht erkennen. Naja, jetzt passt es ja. :) Trotzdem vielen Dank! Gruß Tipsy Zitieren
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.