Gyro drift beheben/kompensieren

[eniddelemaj]

Was sind Bakensysteme? Ich kenne Baken nur von Schranken.
Was soll ich damit machen?

Naja manuell nachkalibrieren ist ziemlich unschön. Per Hand wieder auf richtigen Kurs setzen meinst du?
Wenn es nicht anders geht, würde ich natürlich Geld dafür investieren, wenn ich damit mein Problem lösen kann.
Also ich könnte mir einen Arduino mit mehr Ram holen, damit ich dieses Kalibrationsscript ausführen kann oder
wie shedepe gesagt hat diesen BNO055 verwenden.

Was wäre also eurer Meinung nach die beste Lösung?

[Moppi]

Was die beste Lösung ist, kommt auf Deine Umgebung an, in der das Teil betrieben werden soll.


Nur mal so eine Idee:
Hast Du schon mal versucht, das Bauteil, dass von Drift betroffen ist, anders zu installieren? Beispielweise seitenverkehrt oder auf dem Kopf, oder beides - um dann zu schauen, wie das mit dem Drift aussieht (also ob der Drift auch gegenläufig ist, wenn das Sensormodul zur jetzigen Position gedreht installiert ist)? Falls es möglich wäre, den Drift in die Gegenrichtung zu bekommen, könnte man zwei dieser Sensoren installieren und den Drift etwas kompensieren (auch wenn er vermtl. nicht ganz beseitigt werden kann). Wenn der Drift mit dem Bauteil nichts zu tun hat, sondern überwiegend von der Erdrotation oder so was abhängt, wird das vermtl. nicht funktionieren.

Wenn Du ein Kompassmodul hast, dass genau ist, außerhalb magnetischer Felder, die es beeinflussen, dann kannst Du doch dein Teil kalibrieren. HaWe hatte aber mit andern Worten schon geschrieben, dass Du nur dann kalibrieren kannst, wenn Du mit dem Modul außerhalb magnetischer Felder bist, also weg von elektrischen Geräten. Also such die Punkte in der Umgebung, wo das Teil fährt, wo ein Kompass ordentliche Werte liefert - zum Kalibrieren fährst Du die dann an.

-----------------------------------------------------------------------------------------------------
Nachtrag:

Noch ein paar Informationen anderer User bezüglich 6050:

Nettes Spielzeug. Ich hab's an einem Raspberry Pi via I2C erprobt, wenn man die Null-Werte gut genug bestimmt, zeigen die Gyro-Achsen eine recht geringe Drift, < 1 Grad/Minute. Auch die Wiederholgenauigkeit ist nicht schlecht. Zu Temperaturstabilität etc. kann ich nichts sagen. Achtung: Den beworbenen "Motion Prozessor" Teil des Sensors kann man vergessen, der Hersteller wirbt zwar damit, es gibt aber keine öffentlich zugängliche Dokumentation dazu. Für den SDK kann man wohl ein paar 1000er abdrücken. Für alles andere kann man Datenblätter im Internet finden.

Soweit ich weis muss man alle Koeffizienten (Nullwerte, Empfindlichkeit, Tempereturkoeffizienten) selbst bestimmen, das kann dauern. Viel weiter bin ich noch nicht gekommen, v.A. um einen anständigen "Künstlichen Horizont" draus zu basteln muss ich meine Mathematikkenntnisse noch ein wenig entrosten.
Alles in allem erstaunlich für den Preis, wie viel besser Sensoren für den 10fachen Preis sind kann ich nicht sagen. Für den Einstieg auf jeden Fall empfehlenswert.

Vom Prinzip her taugt das Modell für den Quadrocopter (egal ob Hexa, Octa), allerdings musst du entsprechende Filter-Algorithmen laufen lassen (Kalman, DCM) um den Drift zumindest von Pitch und Roll einzudämmen. Beim Yaw musst du dir einen weiteren Sensor besorgen (zb. Magnetsensor) um auch da den Drift kompensieren zu können. Wenn es dir nur um das Fliegen mit einer Fernbedienung geht, dann brauchst du den Drift von Yaw nicht unbedingt per Microcontroller zu kompensieren, sondern kannst das ganze auch per Fernbedienung trimmen, dass reicht aus.

Quelle: https://www.amazon.de/Wadoy-MPU-6050...ews-filter-bar

-----------------------------------------------------------------------------------------------------
Nachtrag:
https://www.roboternetz.de/community...hidget-1044%29

-----------------------------------------------------------------------------------------------------
Nachtrag:

Von dieser Seite habe ich so einen Calibration Script heruntergeladen:
https://github.com/kkpoon/CalibrateMPU6050

Das Problem ist leider nur, dass mein Arduino nicht genug Arbeitsspeicher hat.

Vielleicht auf einem nodeMCU versuchen?


MfG

[HaWe]

oft ist es schon so, dass die Nähe zu Motoren Magnetstörfelder verursachen, die sich bei verschieden starkem Betrieb beider Motoren unkalkulierbar verändern. Man müsste den Sensor 1 m über dem Robot montieren, damit sie nicht mehr stören, und später dürfen auch keine extrernen Magnetfelder oder Eisenträger (Stahlbeton) etc. in der Umgebung vorkommen (Bereits ein Notebook, in dessen Nähe ein Kompass-Sensor gerät, dreht dessen Anzeige um bis zu +/- 180° (!):
Praktisch also Mumpitz.

Bakensysteme:
das sind elektonische Leuchttürme, die du anpeilen oder anpingen kannst (per Radiowellen, Licht, Laser oder Infrarot)

Fix- und fertiges Bakensystem: Pozyx https://www.pozyx.io/?gclid=EAIaIQob...SAAEgJWgPD_BwE

[shedepe]

Also ich widerspreche an der Stelle HaWe erneut, dass Motoren unbedingt Probleme machen müssen. Wenn man Industriemotoren verwendet hat man z.B. sehr geringe externe Magnetfelder weil die Dinger korrekt geschirmt sind.

Ihr redet grade davon Drift eines Gyros bzw. Accelerometers zu kalibrieren bzw. eliminieren. Der Drift ist so hochgradig von Temperatur usw. abhängig -> Funktioniert nicht. Dazu gibt es zwei Lösungen 1. Man nimmt einen Lasergyro beginnend bei so 500.000€ oder 2. Man beschäftigt sich mit SLAM und nutzt Gyro und Acellerometer für kurzfristig (Im millisekunden bis einstelligen Sekunden Bereich) genaue Zusatzinformationen. Was aber nicht funktioniert ist der Versuch aus dieser Kombi den zurückgelegten Weg zubestimmen. Die Drehung noch eher. Was man machen kann ist wenn man steht (Und weiß dass man steht) die Sensordaten wieder zu 0 kalibrieren.

[Che Guevara]

Hi,

also nicht umsonst werden Magnetometer relativ häufig verbaut wenn es um die Drehung der Yaw-Achse geht. Dass Motoren und andere eisenhaltige Gegenstände Störungen verursachen, ist auch nichts neues. Trotzdem kann man mit einem Kompass sehr gute Ergebnisse erzielen.
Wurde er einmalig in einer relativ ungestörten Umgebung kalibriert, kann man später jederzeit die aktuelle Vektorlänge des Magnetfeldes ausrechnen und somit erkennen, ob und wie stark die Daten gerade verfälscht sind. Nun kann man einfach seinen Filter so anpassen, dass er nur bei geringer Störung den Kompass mit einbezieht oder je nach Störung mehr oder weniger stark.
Wer gut in Sensorfusion ist, der schafft es auch, einen Kalman oder ähnliche Filter so zu programmieren, dass dieser nur einmalig beim Start (also Motoren aus) den Kompass benötigt und später ohne diesen trotzdem korrekte Headingwerte liefert.

[HaWe]

Extremfall zur Verdeutlichung:

kalibriere ihn mal in einer ungestörten Umgebung,

dann platziere ein paar Dutzend starke Dauermagneten und DC-Elektromagneten zufällig irgendwo im Raum
und verändere ihre Position während des Tests
und dann fahre mit deinem Robi an diesen Magneten mit veränderlicher Position vorbei:

das gibt Murks, das Heading (Yaw) ist nicht zu gebrauchen.

[seite5]

@Che Guevara:
also nicht umsonst werden Magnetometer relativ häufig verbaut wenn es um die Drehung der Yaw-Achse geht.
Das ist wohl richtig, aber wenn Du den zurückgelegten Weg, also quasi Deinen Standort bestimmen willst, summierst
Du auf und damit summierst Du fortlaufend jeden Fehler, also Driften und absolute Fehler. Kann man sich mit einfachen
Zahlenbeispielen klarmachen (Geschwindigkeit = 1. Ableitung des Weges nach der Zeit, Beschleunigung: 2. Ableitung,
Weg aus Beschleunigung bedeutet dann 2x integrieren, also gehen Fehler bei z.B. konstanter Beschleunigung auch
quadratisch ein.) Um so was befriedigend zu realisieren brauchst du, wie shedepe schon erwähnt hat, high-end-sensoren mit
minimalen Fehlern.
mfg
Achim

[HaWe]

Vielleicht noch mal etwas aus dem Netz dazu mit Komplementärfilter:

http://www.pieter-jan.com/node/11

Du verstehst das zu Grunde liegende Problem offensichtlich überhaupt nicht:

yaw-Werte (horizontaler Kurs) basieren auf Drehungen um die senkrechte Achse (die zum Erdmittelpunkt gerichtet ist).
Bei Drehung um die senkrechte Achse ändern Accelerometer aber überhaupt nicht ihre Messwerte!
Bei yaw-Drehung bleiben Accelerometer ständig konstant (der senkechte Vektor auf 9,8m/s², die beiden horizontalen auf 0m/s²), egal wie man dreht!

Das mit den Komplementärfiltern für Gyro-yaw-Werte zusammen mit Accelerometern kann daher mathematisch überhaupt nicht funktionieren, da Accelerometer keine veränderlichen Messwerte und damit auch keinen Filter-Beitrag zu der senkrecht stehenden yaw-Achse liefern können!

Accelerometer können nur Veränderungen messen, die NICHT um die senkrechte Achse drehen.
Accelerometer können daher mathematisch nur roll- und pitch Werte per Filter Fusion stabilisieren!

Probiere es bitte immer erst selber aus, bevor du hier falsche und komplett irreführende Hinweise gibst!

[Moppi]

Bei Drehung um die senkrechte Achse ändern Accelerometer aber überhaupt nicht ihre Messwerte!

Also mit andern Worten: Beschleunigungssensoren messen die Beschleunigung nicht, die aus der Fliehkraft resultiert
Richtig?

MfG

[HaWe]

Also mit andern Worten: Beschleunigungssensoren messen die Beschleunigung nicht, die aus der Fliehkraft resultiert
Richtig?

das ist auch falsch, selbstverständlich messen sie auch Fliehkräfte (Zentrifugalbeschleunigung), aber die sind bei der Messung von yaw Werten irrelevant bzw. für Komplementär- oder Kalmanfilter etc. nicht zielführend.
Und bevor du nun wieder irgendwelche theoretischen Gedankenspiele anfängst: überprüfe sie bitte praktisch, bevor du sie postest, und dann zeige auch bitte den fertigen C(++) Code!