Hier gab es 2015 auch schon Tipps zu diesem Problem: https://www.roboternetz.de/community...l=1#post612808
MfG
Hier gab es 2015 auch schon Tipps zu diesem Problem: https://www.roboternetz.de/community...l=1#post612808
MfG
Was mir bei deinem ersten Bild noch auffällt: Es sieht so aus als hättest du die Motorleitungen nicht verdrillt. Mach das mal.
Das ersetzt dir zwar die Kondensatoren nicht, gehört aber zu den Entstörmaßnahmen die man immer macht da sie
a) wenig Aufwand erfordern
b) in der Regel hilfreich sind (und wenn nicht, haben sie immerhin keine Nachteile)
Sollte daß noch nichts bringen muß dein Hardwareaufbau nochmal genauer untersucht werden.
Hallo,
in vielen meiner Hubschrauber sitzt auch dieser Gyro drin. Und die sind so empfindlich, dass ich sie per Hand nicht ruhig halten kann.
Okay, Kaffeefetischist..Spass,,,,, die sind wirklich extrem empfindlich....
Daher sind generell unter der Elektronik noch PADs zur mechanischen Entkopplung vorhanden.
Suche mal nach Klebepad für Gyro. Hier gibt es verschiedene Varianten. Oft konnten Vibrationen nur durch tauschen des PADs beseitigt werden.
An elektrische Störung glaube ich nicht unbedingt. Wurde ja schon geschrieben, der Datenverkehr scheint ja zu laufen.
Vorstellbar wären evtl. noch magnetische Störungen von den Motoren, da Du schreibst, dass bei weniger Leistung es besser wird.
Ob das möglich ist, bin ich mir aber nicht sicher.
Oder rechnet Dir da ein externes Magnetometer was mit rein ?
Siro
Geändert von Siro (26.11.2018 um 08:25 Uhr)
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.
Geändert von HaWe (26.11.2018 um 10:56 Uhr)
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).
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
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.Zitat von Che Guevara
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.
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?
Berechtigungen
Zitieren
Lesezeichen