Na ja, technisch lösbar wird das sein, aber wie denn jetzt - auch das Kompensieren der Drift?
MfG
:Weihnacht
Druckbare Version
Na ja, technisch lösbar wird das sein, aber wie denn jetzt - auch das Kompensieren der Drift?
MfG
:Weihnacht
Wurde doch schon öfters ausgeführt:
Entweder muss man sich mit dem (kurzfristigen) Driftfehler des MPU6050 (z.B. im dmp mode) abfinden, andernfalls lässt sich (mittel/langfristig) die Geräte-spezifische, über die Zeit schwankende Drift nur durch verlässliche externe Referenzen kompensieren (teilw. Odometrie, in absolut Stör-Magnetfeld-freien Umgebungen auch Kompass (fällt hier weg), sehr grob auch GPS (fällt hier auch weg), ansonsten Peilung von eigenen Referenz-Baken/Markierungen oder Detektion von Boden-Markierungen) .
Vielleicht noch mal etwas aus dem Netz dazu mit Komplementärfilter:
http://www.pieter-jan.com/node/11
MfG
:Weihnacht
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!
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!
Komm mal runter.
Das muss nicht zielführend sein, was ich hier schreibe. Wo steht das?
Es sollte aber eine äußere Form wahren, die ich manchmal in Deinen Beiträgen vermisse. DAS fördert die konstruktive Zusammenarbeit. DAS ist zielführend.
Um die eigentliche Problematik mal auf den Punkt zu bringen, Moppi: Der Komplementärfilter würde eine oder DIE Lösung sein, wenn die Beschleunigungssensoren diese minimalen Bewegungen in x- und y-Richtung vernünftig messen würden. Bei einem Roboter sind die gemessenen Beschleunigungswerte aber so verschwindend gering, dass sie im Rauschen des Sensors untergehen. Man kann damit recht zuverlässig die Neigung eines Gerätes (zum Gravitationsfeld der Erde, also immer nach unten) messen, aber kaum eine Bewegung in x/y-Richtung (eine leichte Drehung, wie hier das Problem, schon gar nicht).
Kurz: wenn der Beschleunigungssensor es könnte, warum bräuchte man dann noch ein Gyroskop?
An "meiner Form" ist nichts auszusetzen, denn sie verweist (in Abgrenzung zu "wilder Spekulation") auf rationale Argumente und praktische Verwertbarkeit.
Dein "komm mal runter" ist aber ein Einwurf, der genau das nicht tut, daher pack dich mal an deine eigene Nase.
Übrigens, auch deintrifft nicht den Punkt, denn wenn es so wäre, dann könnte man ja gewinnbringend statistische oder stochastische Filter für Sensorfusion verwenden - das wäre ja sogar äußerst hilfreich und wünschenswert (s. Komplementärfilter-Link), aber es geht eben nicht für Accelerometer und Gyro-yaw-Werte!Zitat:
Kurz: wenn der Beschleunigungssensor es könnte, warum bräuchte man dann noch ein Gyroskop?