DC-Motoren stören MPU 6050

[HaWe]

Gyro Drift hat der MPU6050 (anfangs ein paar Grad pro Minute, die sich aber auch stabilisiert mit der Zeit), das stimmt, aber ich bezweifle, dass dieser digitale IMU mit onboard-dmp samt Sensor-Fusion von Motoren beeinflusst werden soll.
Bei raw Werten und analogen Gyros ist das sicher ein echtes Problem, aber wohl eher nicht hier.
Und bei IMUs mit zusätzlichem Kompass/Magnetometer (MPU9150, CMPS11, CMPS12) habe ich in der Nähe von Motoren dagegen deutlich mehr Probleme als ohne das.
Lasst doch mal den OP erst mal das example mit der neuen dmp6-lib zum Laufen kriegen und dann berichten.

[Che Guevara]

Definitiv wird das von Motoren beeinflusst, je nachdem, wie gut oder schlecht das entkoppelt ist auch mehr oder weniger.
Dabei spielt nicht nur der Drift eine Rolle, sondern auch Dinge wie Quantisierungsfehler, Abtastrate, etc...
Wenn man nur mit einem Gyro einen stabilen Yaw-Wert hinkriegen könnte, glaubst du nicht, große Firmen hätten das schon lange implementiert und würden auf den Kompass verzichten?
Es gibt auf YT ein interessantes Video von TED über Positionsbestimmung mittels ACC-Integration, ist zwar nicht das gleiche, aber die Fehler (und deren Summe über Zeit) werden schön dargestellt und daraus ist auch ersichtlich, dass sowas ohne Absolutwertgeber nie 100% funktionieren wird (zumindest momentan mit verfügbarer Soft / Hardware).

[Moppi]

Wo vorher z.B. noch 180 Grad war, ist wenig später
200 Grad. Der Yaw-Wert variiert.
Dies geschieht wenn ich die Motoren arbeiten lasse.

Nur mal so Interesse halber, was ich hier noch nicht gelesen habe - vielleicht habe ich es übersehen: wann tritt das Problem genau auf? Nur beim Anlauf der Motoren oder auch wenn sie kontinuierlich vor sich hin drehen? Sind die Werte bei einer längeren Geradeausfahrt mit gleichbleibender Leistung der Motoren stabil oder schwanken die dann auch und nur nicht, wenn die Motoren aus sind?

MfG

[HaWe]

Definitiv wird das von Motoren beeinflusst, je nachdem, wie gut oder schlecht das entkoppelt ist auch mehr oder weniger.
Dabei spielt nicht nur der Drift eine Rolle, sondern auch Dinge wie Quantisierungsfehler, Abtastrate, etc...
Wenn man nur mit einem Gyro einen stabilen Yaw-Wert hinkriegen könnte, glaubst du nicht, große Firmen hätten das schon lange implementiert und würden auf den Kompass verzichten?
Es gibt auf YT ein interessantes Video von TED über Positionsbestimmung mittels ACC-Integration, ist zwar nicht das gleiche, aber die Fehler (und deren Summe über Zeit) werden schön dargestellt und daraus ist auch ersichtlich, dass sowas ohne Absolutwertgeber nie 100% funktionieren wird (zumindest momentan mit verfügbarer Soft / Hardware).

ich kann das für meine Modelle bisher nicht bestätigen, im Gegenteil: Magnetometer machen alles in Motornähe oder bei Annäherung an externe Magnetquellen nur schlimmer - teilweise dreht sich das heading (yaw) um 180°. Der MPU6050 mit dmp6 lib bleibt dagegen deutlich stabiler. Alles aber eine Frage ntl, wie der eigene Aufbau ist und das betr. Environment.
Auch das Problem des OP kann ich bisher nicht bestätigen, dass der MPU6050 mit dmp6 lib bei Motorbetrieb über H-Brücken am Arduino schlechtere Werte liefert als ohne Motoren; das heißt ntl auch nicht, dass diese Beobachtung überall im Universum gültig ist.
Auch kenne ich bisher keine bessere MPU6050 lib als die genannte dmp6.

Also lassen wir doch den OP erst mal seinen persönlichen Aufbau mit der dmp6 Lib testen.

[eniddelemaj]

Wow danke für die ganzen Antworte, das weiss ich echt zu schätzen!

Neue Bibliothek:
Habe ich zum Laufen bekommen. Lag übrigens tatsächlich daran, dass ich i2cdev in libraries aktualisieren musste, danke dafür!
Leider hat sich hierbei nichts verändert.

Mechanische Entkopplung:
Ich kann den MPU nicht auf ein Pad kleben, da ich das Breadboard zur Fixierung des MPUs brauche.
Ich habe stattdessen das Breadboard auf Pattafix "Stelzen" geklebt. Das Breadboard steht auf 4 Pattafixe (Mehrzahl?)
auf dem Roboter. Ich denke, dass das eine Art mechanische Entkopplung darstellt. Davon abgesehen, glaube ich nicht,
dass Vibration oder ähnliches der Grund für mein Problem ist. Wenn ich den Yaw Wert messe und mit dem Finger auf den
Roboter klopfe, verändert sich der Wert nicht großartig (Nur im Nachkommabereich etwas).

Motorkabel verdrillen:
Habe ich getan. Leider auch keine Verbesserung meines Problems. Ich hatte auch allerdings nicht
viel Spiel, die Kabel zu verdrillen, da sie zu kurz sind. Reicht das so?



Magnetometer:
Ich bin im Bezug auf Magnetometer der gleichen Meinung wie HaWe. Ich habe schon vorher
etliche Versuche unternommen einen Magnetometer für mein Problem zu nutzen. Das war allerdings
viel schlechter, da ich den Magnetometer nicht anständig kalibrieren kann. Ich habe bestenfalls eine
Abweichung von 5° hinbekommen, was noch zu viel ist. Wie HaWe schon sagt, ist dieser viel anfälliger
gegenüber den Motoren. Die Kombi aus Gyro und Accel scheint dagegen gegen Magnetfelder immun zu sein.
(Kein Veränderung wenn ich mein Handy bspweise in Nähe halte, ganz im Gegensatz zum Magnetometer).

Ich habe jetzt auch nochmal genauer untersucht, wann das Problem auftretet:
Ich habe ein Script geschrieben, das den Roboter in Endlosschleife eine Gerade hin und zurückfährt.
Fahre gerade, drehe um 180°, fahre gerade, drehe um 180°, usw.
Daran konnte ich sehen, wann der Roboter seinen Kurs plötzlich ändert, bzw. wann die 180° sich verschieben.

Ich muss den Roboter am USB Kabel angeschlossen haben, da die Batterien scheinbar zur Neige gehen.

Wenn der Roboter auf dem Boden fährt und das Kabel (was leider etwas kurz ist) den Roboter nicht behindert,
tretet das Problem nicht auf. Halte ich den Roboter in der Luft und drehe ihn von Hand, tretet das Problem auch nicht auf,
also der Winkel verschiebt sich nicht.
Wenn der Roboter allerdings auf dem Boden fährt und das Kabel ihn aufgrund der Länge behindert (Die Räder drehen durch) tretet das Problem auf.
Auch wenn ich den Roboter in der Luft halte und dabei die Räder mit Hand etwas blockiere, tretet das Problem auf.
Hierbei erschließe ich mir, dass durch das blockieren der Räder, die Spannungsversorgung des MPUs geschwächt bzw. verändert wird,
da die Motoren mehr Spannung für sich beanspruchen. Ich kenne die genaue Funktionsweise des MPU 6050 nicht, aber es erscheint mir logisch,dass die Werte sich bei veränderter Spannungsversorgung mitändern.
Ein weiteres Argument für meine These ist, dass Arduino bzw. MPU und Motoren sich eine Stromquelle teilen.
In Anbetracht dieser Aspekte fällt mir noch der Kondensator ein, oder 2 seperate Stromquellen für den Arduino
und den Motor Controller. Vlt wirken sich Spannungsveränderungen dann nicht auf das MPU aus. Der Arduino
ist lediglich über Signalkabel mit dem Motorcontroller verbunden.

Die Kondensatoren habe ich eh schon bestellt und ich werde sie ausprobieren sobald sie da sind. Was haltet ihr von
meinem Lösungsansatz?

[Moppi]

Habe ich getan. Leider auch keine Verbesserung meines Problems. Ich hatte auch allerdings nicht
viel Spiel, die Kabel zu verdrillen, da sie zu kurz sind. Reicht das so?

Alufolie sollte auch möglich sein: um die Drähte gesamt eine Schicht wickeln und einen Draht abisolieren, etwas drumwickeln und mit GND verbinden.

Ich hatte bereits die Vermutung, dass was mit der Spannungsversorgung nicht so ganz ok ist, wenn die Motoren mehr Strom ziehen. Ich glaube, Du verwendest Mignonzellen?
Ich weiß, dass viele der Meinung sind, das reicht aus - hat die letzten 50 Jahre ja auch funktioniert. Aber um Probleme von vorn herein in dieser Richtung auszuschließen würde ich einen LiPo-Akku kaufen und ein Ladegerät dazu. LiPos liefern viel mehr Strom und gehen nicht in die Knie, wenn da etwas mehr Strom gezogen wird. Sie lassen sich außerdem jederzeit aufladen - schnell aufladen (ein 2400mAh-LiPo ist vielleicht in ca. 40min wieder geladen), einen Memory-Effekt gibts dort meines Wissens gar nicht. Nur tief entladen darf man sie nicht. Zum Ausprobieren würde ich hier mal so was hernehmen, was anständig Power liefern kann. Später kann man dann ja Mignons einsetzen, wenn es Spaß macht und sein muss. Die einzelnen Geräte kann man mit einem Festspannungsregler versorgen. Sowohl einen ATmega328, als auch die einzelnen Sensormodule, meist genügen 5V oder 3.3V (LM 2936 Z5,0 für 5V, LP2950-3.3 = LP2950CZ/ACZ für 3.3V - beide sind bis 100mA belastbar und benötigen selber nicht viel Strom und sind einfach mit 2 Kondensatoren zu beschalten). Da kann auch jedes Gerät seinen eigenen Spannungsregler haben (so viel ziehen diese Sensor-Platinen nicht), Hauptsache GND ist miteinander verbunden.

Und noch mal zum Lösungsansatz: https://github.com/Ardumower/ardumow...EV20150531.pdf
Das Dokument auf github, ich denke, damit bekommt man die Motoren auch entstört. Ich würde von der Vorgehnsweise, wie sie in dem Dokument beschrieben ist, gar nicht abweichen.


MfG

[HaWe]

ich bezweifle nach wie vor, dass es sich mit Motor-Entstörungen beseitigen lässt.
Dass es sich ursächlcih um starke Spannungsschwankunken handelt, kann ich mir schon eher vorstellen.
Ich habe bei mir 9.6V oder 12V NiMH Akkus zu mindestens 5000mAh.

Daran einen stabilisierten 9-12V/5V 2A Stepdownregler mit USB Anschluss für meinen MCU (oder Raspi), alternativ ein 7V Stepdownregler zum Anschluss an die Arduino-DC-Buchse.

Die NiMH speisen direkt die H-Brücken.
Alle Sensoren werden vom Onboard-Vc-Pin des Arduinos/Raspis gespeist, so sind sie quasi doppelt stabilisiert.

[Moppi]

Sollte sich eine Störung (durch Funkenbildung z.B.), leistungsmäßig im Ampere-Bereich nicht stärker auswirken, als die gleiche Störung im µA-Bereich? Dann: etwas mehr Leistungsaufnahme = stärkere Störung. Die Spannung könnte auch stabil bleiben, solang die AKkus das hergeben. Wissen wir alles nicht, weil nicht gemessen. Die Motoren sollten wohl auf jeden Fall halbwegs entstört werden. - Genug orakelt.