da muss ich passen, wenn du hier nicht weiter kommst, dann stell mal diese Frage bei github in den issues!
- - - Aktualisiert - - -
PS
hast du evtl I2Cdev 2x auf deinem System?
I2Cdev gehört NUR in den libraries Ordner!
Druckbare Version
da muss ich passen, wenn du hier nicht weiter kommst, dann stell mal diese Frage bei github in den issues!
- - - Aktualisiert - - -
PS
hast du evtl I2Cdev 2x auf deinem System?
I2Cdev gehört NUR in den libraries Ordner!
einmal in: sketch\Zitat:
sketch\I2Cdev.cpp.o (symbol from plugin): (.text+0x0): first defined here
libraries\I2Cdev\I2Cdev.cpp.o (symbol from plugin): In function `I2Cdev::I2Cdev()':
und einmal in: libraries\I2Cdev\
PS: unbedingt lesenswert: Dokument auf github
Sollte die Fragen beantworten, was notwendig ist beim Entstören und vor allem, warum.
MfG
Moppi
Hallo,
also m.M.n. hört sich das vielmehr nach Drift an als nach HW-Problemen. Woher ein MEMS Gyroskop Probleme mit HF-Strahlung bekommen sollte, kann ich mir ehrlich gesagt nicht vorstellen und wenn die Strahlung so heftig wäre, dass die Kommunikation gestört wird, würdest du überhaupt keinen Wert mehr auslesen können.
Dass es mit der Handdrehung besser aussieht als wenn die Motoren laufen ist IMHO auch logisch, Motoren bringen oft Vibrationen die du mit deiner Hand nicht erzeugst.
An deiner Stelle würde ich mir einen Kompass (z.b. HMC5883L) besorgen, alles andere wird auf Dauer sowieso nicht funktionieren.
Gruß
Chris
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
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.
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).
Zitat:
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:
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.