MPU 6050 Beschleunigungssensor - Programm zu langsam

[Klebwax]

Die übertriebenen Comments sind für mich nur eine Lesehilfe, die kommen beim fertigen Code natürlich raus.

Dem fertigen Code sind sie egal, die ignoriert der Compiler vollständig. Für mich sind sie aber keine Lesehilfe sondern behindern mich beim Lesen. Ebenso die vielen Leerzeilen. Man muß dauernd scrollen, um ein paar Zeilen im Zusammenhang zu sehen. Ich hab mir den Code daher nicht angesehen und kann dir also auch nicht sagen, wo dein Problem liegt.

MfG Klebwax

[Atvilar]

Hallo Klebwax,

Ich spreche nicht vom Compiler, sondern vom Program selbst.
alles was die MPU macht ist: schau dir 0,01 sec die Bewegungen an, addiere sie zusammen, berechne daraus deine aktuelle Position.
Dann geht das Programm anderen Aufgaben nach. Bis sich das Program das nächste mal an der IMU ankommt, werden Bewegungen ignoriert.

LG Atvilar

[HaWe]

hallo,
1., da es ein Arduino-Programm ist, wäre das Arduino-Unterforum der bessere Ort zum Posten.
2., wenn du parallele Ausführung von Sensor-Auslesen + Logging und restlichen Programmfunktionen willst, die sich gegenseitig nicht behindern, empfiehlt sich Multithreading (1 Thread für I2C und den MPU samt Logging, 1 Thread oder mehrere weitere für den Rest). Das funktioniert auf dem Arduino Due und Zero mit der Scheduler Lib und mit dem ESP32 per std::thread - dann wird dabei nichts mehr verpasst!
3., ich würde für den MPU eine Lib verwenden, die den internen motion processor verwendet (z.B. MPU6050_DMP6_using_DMP_V6.12, dabei I2C-Clock auf 400000)

PS:
(https://github.com/jrowberg/i2cdevli...rduino/MPU6050, bin mir nicht sicher, welche du verwendest)

[Rabenauge]

Ich sehe, dass du den Dallas-Temperatursensor benutzt.
Wenn der im Parasit-Modus läuft, ist er sehr langsam! Der braucht dann nämlich eine gewisse Zeit, um sich aufzuladen.
Da die Dinger im normalen Modus (eigene Stromversorgung) auch nicht mehr können, als eben die Temperatur auszugeben, benutz ich die kaum noch...
Weiter sehe ich, dass deine zahlreichen seriellen Ausgaben auch sehr langsam erfolgen- dafür gibts nur selten nen sinnvollen Grund.
Auch das verzögert den Programmablauf deutlich.
Schreiben auf SD-Karte ist ebenfalls nicht eben schnell...

Du kannst ja mal ermitteln, wie lange deine loop() für einen Durchlauf braucht: am Anfang die aktuellen micros() auslesen, am Ende wieder...und dir die Differenz ausgeben lassen.
Mit millis() geht das natürlich auch....micros() hat aber ne höhere Auflösung.

[Atvilar]

Hallo,

@ HaWe
1) Danke, ich war mir nicht sicher ob ich auf Sensor oder Arduino posten sollte.
2) Multithreading, so etwas habe ich mir gedacht. muss mich da aber erst einlesen, wie ich das hinbekomme! (hab Arduino Uno)
3) Lib Möchte ich verhindern, da in einer weiteren Ausbaustufe 2 Libs kollidieren würde (Ich glaube die Beiden verwenden die gleiche Clock oder so)

@ Rabenauge:
Den Dallas Sensor benutze ich, weil ich den gerade zur Hand hatte. Er läuft NICHT im Parasit-Modus
Die Seriellen Ausgaben benutze ich zum Debugging und Kalibrieren, auch die kommen später raus. Trotzdem: Ohne Seriellen Ausgaben + SD Speicherung: 369 952 micros / loop
Schreiben auf die SD ist aber nicht zu vermeiden. wäre eine Lange "Wurst" schneller?
1 Loop mit Seriellen Ausgaben dauert ca. 422 488 micros

Edit:
Ohne die beiden T Berechnungen (Dallas + MPU) komme ich auf 40 056 micros / Loop.
Außerdem habe ich die baudrate auf 230400 erhöht.
Nichtsdestotrotz muss der Loop noch schneller sein.

Danke für die Tipps!

[HaWe]

Mit dem Uno geht MT nicht bzw. nicht vernünftig, da viel zu wenig RAM. Der Arduino Zero/M0 hat aber denselben Formfaktor, hat aber ~15x soviel RAM und ~3x soviel Takt.
Deine Bedenken wegen "Clock" vesretehe ich nicht....
Der Flaschenhals wird aber sicher das schnelle Schreiben auf SD sein.

[Rabenauge]

Du kannst versuchen, die Ausgaben, die auf die Karte geschrieben werden, erst ein paar Datensätze lang zu puffern.
Das erspart zumindest das dauernde öffnen und schliessen der Datei...da musst du halt schauen, wie weit du mit dem Arbeitsspeicher kommst.

Weiters würde ich versuchen, möglichst viele der Fliesskomma-Berechnungen zu umschiffen (je mehr davon verschwindet, umso besser).

[wkrug]

Wie wärs, wenn Du die Gyro Abfragen in einen Timer Interrupt legst, der alle 5 bis 10ms ausgelöst wird.
Dort zyklisch die Gyro Werte addieren und in der Hauptroutine die Position daraus berechnen.
Komplexe Berechnungen sollten da aber dann vermieden werden ( Zeitfaktor ).

Zum anderen würde ich statt der float Variablen lieber int Typen wählen, wo das möglich ist, weil die ein Controller wesentlich schneller verrechnen kann.

[HaWe]

Ist die Frage, was genau gespeichert werden soll: die nackten raw-Werte direkt aus den Registern (6DOF, zusammengesetzt zu 3x integer für Gyro und 3x integer für Accel.) - oder schon fertig ausgerechnete Winkel.
Eulerwinkel (bzw. yaw, pitch, roll) werden aber nur mit floats vernünftig berechnet. Wenn also abspeichern, dann entweder direkt die raw-Werte aus den Registern (ohne weitere Umrechnungen), oder die daraus bereits fertig ausgerechneten geometrischen Winkel und dann erst zu int gerundet:
z.B. die float-Eulerwinkel mit 100 multiplizieren und dann runden (edit: je nachdem, int16_t oder uint16_t). Dann hat man gegenüber float nur die halbe Anzahl an Bytes auf SD zu schreiben und statt 6 Werte für 6DOF nur 3 ausgerechnete Euler-Winkel.