für Arduino / Due: Empfehlung für IMU / I2C Gyro Sensor

[Sisor]

Beim Lesen dieses Threads habe ich mir mehrfach an den Kopf gefasst.
Daher hier ein weiteres Plädoyer für den MPU6050:

MPU6050 u.ä. scheiden also aus, weil man zum Einen viel zu viel selber rechnen muss um zu verwertbaren Werten zu kommen,

- Falsch! Sehr einfach auszulesen. Siehe MPU6050_raw.ino: 1 Befehl -> 3 Winkel, 3 Beschleunigungen!

zum anderen oft AVR Timer verwendet werden, was die Sache unglaublich verkompliziert und gerade auch für den Due unbrauchbar macht.

- Falsch! Der MPU6050 hat ein Interrupt-Pin. Wenn Daten da sind, meldet er sich -> Kein Timer nötig.

Außerdem hat er offenbar keine eingebauten Kalman-Filter, wie es nötig wäre.

- Stimmt, aber ein LowPassFilter ist integriert, das von 260Hz - 5Hz einstellbar ist.

Ein Magnetometer ist direkt anschließbar.

Das Teil wird nicht ohne Grund in unzähligen Anwendungen verwendet.

PS: Die Daten schon als eine Quaternion vorliegen zu haben, bietet die Möglichkeit, eine Rotation im Raum sehr effizient zu berechnen. Für 3dimensionale Anwendungen ein sehr schönes Feature.

[HaWe]

Sisor, ich kann mir nach deinem Post langsam auch an den Kopf fassen -

welchen Teil von

"ich will keinen MPU verwenden und Suche daher eine Alternative"

hast du nicht verstanden?


Das Gleiche gilt auch für die Quaternionen, und auch für die ganzen libs, die man braucht, um erstmal überhaupt die stabilisierten Quaternionen auslesen zu können, und dann die ganzen Rechenoperationen, um rumrechnen zu müssen, um dann erst die gewünschten durch Sensorfusion und Kalman gefilterten Winkel zu erhalten. Ich will weder #include "I2Cdev.h" noch #include "MPU6050.h" noch #include "MPU6000.h" o.ä. einschließen müssen - wire.h muss ausreichen: Ich kümmere mich selber um meine I2C Steuerung. Im Übrigen war von deinem MPU6050_raw.ino hier noch nie die Rede gewesen, ganz unabhängig von den Monsterlibs, die man auch dafür zusätzlich bräuchte (und einen IRQ-Pin will ich übrigens auch nicht auslesen müssen).


Welchen Teil von

"Ich möchte die 3D Winkel direkt auslesen können ohne zusätzliche Libs und ohne erst rumrechnen zu müssen"

hast du also hier nicht verstanden?


Also verarsch mich du jetzt nicht auch noch, einer reicht.

[Che Guevara]

Also ich wäre ja mal für ne neue Rubrik im Roboternetz:
Petitionen gegen User, die keine Argumente bringen und nur Blödsinn schreiben

Ciao

[HaWe]

oohh jaa - ich auch!

und eine für Petitionen gegen User, die nicht die Fragen in den Topics lesen können und nur Blödsinn schreiben !

[Sisor]

Du hast begründet, warum du den MPU nicht nutzen willst. Ich (und nicht nur ich) wollte dich darauf aufmerksam machen, dass deine Argumente teils haltlos sind. Dies hätte theoretisch dazu führen können, dass du dein kategorisches Ausschließen des MPU noch einmal überdenkst.

'Monsterlibs': Nur weil eine Bibliothek viel Quelltext enthält, heißt das nicht, dass am Ende auch viel Byte-Code auf dem MC landet. Es wird nur übersetzt, was du auch benutzt.

Und nein, mir ist kein Sensor bekannt, der deine Anforderungen hinsichtlich eines Kalman-Filters erfüllt.

[HaWe]

nein, ich will den bescheuerten MPU nicht verwenden,
ich habe davon und von seinen Monsterlibs komplett die Nase voll,
ich Suche eine Alternative, wo ich einfach nur 3 (für 3D) per Sensorfusion gefilterte Winkel oder 3 Winkelgeschwindigkeiten auslesen muss.

Alles was an Mathematik dazu passieren muss, muss bereits in dem Chip passiert sein.

Der MicroInfinity-Gyro für Lego kann das ja immerhin für 1D, ich Suche jetzt aber so etwas für 3D.

[Mxt]

Eingebaute Kalman-Filterung bei solchen Sensoren kenne ich nur von den teueren:
https://www.xsens.com/products/mti-10-series/