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

hallo,
wer hier hat eine gute Empfehlung für eine IMU, die man mit einem Arduino Due und einem Breadboard betreiben kann ?

Es sollte ein I2C Gyro Sensor sein, der intern durch eigene Filter (Kalman etc.) stabilisiert ist, evtl. durch Verwendung zusätzlicher weiterer Sensoren (wie z.B. Accelerometer und/oder Kompass).

Der Gyrowert (wenigstens die Winkelgeschwindigkeit - oder möglicherweise auch bereits der Winkel) sollte also stabilisiert und gefiltert ausgegeben werden, indem man einfach I2C Register ausliest (z.B. 3x 16 oder 3x 24 bit für die 3 dim.), ohne dass weitere Berechnungen notwendig sind. Insb. muss der Sensor auch für den Due geeignet sein.

MPU6050 u.ä. scheiden also aus, weil man zum Einen viel zu viel selber rechnen muss um zu verwertbaren Werten zu kommen, zum anderen oft AVR Timer verwendet werden, was die Sache unglaublich verkompliziert und gerade auch für den Due unbrauchbar macht. Außerdem hat er offenbar keine eingebauten Kalman-Filter, wie es nötig wäre. Ein einfaches selbst ausgelöstes I2C -read für devaddr + regaddr muss also reichen.

Eine grundsätzliche Idee wäre z.B. dieser Chip als 1D-Gyro hier, leider ist der aber eben 1D und nicht direkt anschließbar und steuerbar mit Arduinos/Breadboards, außerdem scheint er auch UART/SPI zu haben und kein I2C:
http://www.minfinity.com/eng/page.ph...=1&sub=1&tab=2

Wer kennt was?

Hi,

also der MPUxxxx scheidet eigentlich nicht aus (also nicht wegen dem o.g. Argument). Den gibts in der 6xxx Version mit Gyro + Acc und in der 9xxx Version mit Gyro + Acc + Compass.
Er lässt sich einfach konfigurieren (DLPF, Scaling, etc) und beinhaltet einen DMP, der dir Quaterionen ausgibt.
Musst mal danach googln, einige Projekte verwenden die DMP Daten.

Gruß
Chris

hallo,
das wäre schön, wenn du Recht hast!
Was jetzt Quaternionen sind, weiß ich nicht, bei allem was ich aber gefunden habe, muss man aber selber Kalman-Filter programmieren und Timer-Interrupts für i2c verwenden:
http://playground.arduino.cc/Main/MPU-6050#sketch
https://github.com/jrowberg/i2cdevli...rduino/MPU6050
https://github.com/TKJElectronics/Ka...amples/MPU6050

Ich suche etwas, wo die Winkelgeschwindigkeit oder sogar der Winkel bereits intern durch Kalman berichtigt sind und man nur noch die gefilterten Werte auslesen muss (z.B. als 16- oder 24-bit Werte)

Der Cruizcore-IMU legt sie z.B. als (edit: KALMAN-) gefilterte 16-bit-Werte in insg. 2 Bytes ab und man muss die 2 Bytes nur noch zu ints zusammensetzen (LoByte + 8x HiByte): die muss man dann noch über die Zeit integrieren um den Drehwinkel zu erhalten, das ist ntl. ok.

Ich kenne diesen IMU im Prinzip sogar schon von Lego (als XG1300L): mehr als 2 Register-Bytes auslesen braucht man da also prinzipiell wirklich nicht zu machen, anschließend nur noch eben integrieren. Genau so soll es sein, also keine Riesen-libs etc., wozu auch, wenn die gefilterten Werte schon fertig in den Registern abgelegt sind?

Der MPUxxxx gibt dir Winkelgeschwindigkeit, Beschleunigung und Temperatur aus (alles mit max. 8kHz), der DMP gibt Quaternionen mit 200Hz aus.
Quaternionen findet man mit Google beim ersten Treffer, das ist eine andere Art der Darstellung der Orientierung im Raum, weil Euler zb das Problem mit dem Gimbal Lock hat, sie lassen sich aber relativ einfach in Euler-Winkel überführen.
Winkelgeschwindigkeit, Temperatur und Beschleunigung liegen jeweils als 16Bit vor, ist also auch kein Aufwand das auszulesen! Mit dem DMP kenn ich mich nicht so aus.

für den MPU werden aber irgendwelche seltsamen AVR-I2C-libs mit AVR-IRQs verwendet, die für den Due nicht funktionieren, und ein Kalman ist eben nicht eingebaut, daher sind die abgelegten Werte für Winkelgeschwindigkeit, Temperatur und Beschleunigung höchstens ungefilterte raw-Werte.
Damit ist es aber keine IMU, die selber bereits intern die Werte Kalman-bereinigt anbietet: darum geht es aber.
Aus der bereinigten 3D-Winkelgeschwindigkeiten dann in einen 3D-Vektor zu berechnen, ist dann aber doch absolut kein Problem mehr, wozu brauche ich da Quaternionen?
Andererseits, wenn der Kalman integriert wäre, warum würde sich dann jemand die Mühe machen, ein externes Kalman Programm dafür zu schreiben? ich glaube also kaum, dass der MPUxxxx das bereits integriert hat - darum geht es aber.

(Der XG1300L bzw. R1350 hat den Kalman aber bereits integriert und legt die gefilterten 1D-Werte dann in 2 Registern ab, fertig, und so etwas suche ich - nur eben 3D und per I2C.)

Hm, ich habs mir schonmal gedacht, entweder du liest nicht richtig oder bist beratungsresistent!
Man braucht für den MPU WEDER eine spezielle Library NOCH muss man die Werte (Winkel als Quat.) selbst errechnen, den die WERDEN ausgegeben!!!!!!!

EDIT:
Achja, ob da drinnen ein Kalman am Werkeln ist oder nicht, weiß ich nicht, aber es gibt auch noch andere Filter, die sehr gut arbeiten. Außerdem warum sollte man, nur weil man die Daten schon fusioniert bekommt, nicht mal selbst einen Kalman schreiben? So schwierig ist das nicht und stell dir vor: man lernt dabei sogar noch was :D

dann wahrscheinlich begriffsstutzig.

dann schreib mir bitte mal auf, wie der Sketch lautet, ohne irgendwelch libs verwenden zu müssen:

der Sketch-Code würde wahrscheinlich so ähnlich wie folgt aussehen (Pseudo-Code, Syntax stimmt sicher nicht genau ):

Code:

---

while(1) {
 
  // dt ausrechnen;
  dt=millis()-oldtime;
  oldtime=millis();

  if Wire.available() {
    Wire.beginTransmission(devaddr);
    Wire.write(start_reg); // address MPU-reg.
    Wire.endTransmission();

   
    //...
    Wire.requestFrom(devaddr, 6);
    // das müsste jetzt sicher anders geschrieben werden...
    int xw= (Wire.read(xreg1)+ 8* Wire.read(xreg2))*dt;
    int yw= (Wire.read(yreg1)+ 8* Wire.read(yreg2))*dt;
    int zw= (Wire.read(zreg1)+ 8* Wire.read(zreg2))*dt;
   
  }
  delay(20);
 
  // das wäre der komplette Code für die bereits intern Kalman-bereinigten Cruizcore-Sensoren.
  // so soll es - im Prinzip - funktionieren!
 
}

---

wie sähe das jetzt für den MPU aus (bitte den kompletten Code posten, ich verstehe nämlich nicht, wie das gehen soll)

- - - Aktualisiert - - -

ps, edit,

mit fällt dazu gerade ein: der MPU hat einen Interrupt-Pin, der mit einem AVR-Interrupt getriggert werden msss - genau das geht aber nicht mit dem Due (CMIIW)


edit 2, ich sehe, du hast es ja gerade noch nachgeschoben:
was ich suche ist eine IMU, die den Kalman bereits integriert hat, wie oben im TOP geschrieben, und wie es die betr. Cruizcode Sensoren ja auch haben.

ich suche eine IMU, die bereits Filter-kompensierte Werte ablegt, nichts wo selber noch gerechnet werden muss, wie ich ja ausführlich geschrieben habe.

Also einmal probier ichs noch:
Wenn du den MPU richtig einstellst (was nicht gerade schwierig ist), GIBT ER KOREKTE, DRIFTFREIE WINKEL AUS.
Ob die jetzt mit Kalman oder Tante-Ema-Filter berechnet werden, sollte doch egal sein, solange sie richtig sind?!
Auch den Interrupt musst du nicht benutzen, obwohl ich nicht verstehe, warum das mit deinem µC nicht funktionieren soll...

Mit dem Mega geht es (erster Link), sie sind aber als raw Werte extrem verrauscht, daher ist ein Kalman nötig.
Ich habe es auch mit meinem Due probiert, klappte absolut nicht. Ich habe ihn exakt so verkabelt, wie mit dem mega.
Ich hab von dem Ding mit seinen Monster-Libs auch die Nase voll (ich habe ihn inzwischen verschenkt), daher suche ich eine Alternative mit integriertem Kalman, wie ich es ganz oben bereits beschrieben habe.

Also das ist definitiv meine letzte Antwort hier, komme mir langsam verarscht vor!
HIER: https://www.youtube.com/watch?v=Ge8L9f6rzA0
sieht man EINDEUTIG, dass die ausgegeben Winkel nicht verrauscht sind und alles funktioniert, wie es soll.

er schreibt aber: I've finally figured out exactly what the DMP initialization sequence is doing step by step and will be able to make low-level alterations to enable the 9-axis advanced fusion.


Ich sehe nicht, welchen Code er (für den Due?) verwendet - findest du ihn?
Ist es tatsächlich nur das Auslesen von 6 Registern, so wie ich es schrieb und wie es dem Cruizcore Sensor sntspricht?

Auf der anderen Seite verstehe ich nicht, wieso du dich hier so am MPU festbeißt. Ich schrieb doch glasklar, dass ich eine Alternative mit eingebautem Kalman suche, ähnlich wie der von Cruizcore...?

Das eine Video ist nur ein Beispiel!!!
Hättest du nur 1x 1minute lang gegoogelt ( http://bit.ly/Av9g0u ), wüsstest dus!
Hier ( https://gentlenav.googlecode.com/svn...bUDB/MPU6000.c ) gibts zum beispiel nen code, wie man das macht.
Ich weiß ja nicht, wer du bist, aber irgendwie bezweifel ich die beiden Videos in deiner Signatur, den wer nen Schachroboter programmieren kann, sollte auch in der Lage sein, ein paar Zeilen Code zu schreiben oder mal zu googeln.

EDIT:
Jetzt komm bitte nicht daher, dass der Code nicht für nen Due ist! Du wolltest nen Sensor, der das kann was du geschrieben hast, der MPU ist der einzige den ich kenne, der auch ausgezeichnet funktioniert!
Und die paar Zeilen für die Hardware Initialisation wirst du ja wohl hinbekommen oder nicht???

wer kann jetzt hier nicht lesen?

schrieb ich: ich will den MPU zum Laufen kriegen?
Oder schrieb ich: ich suche eine Alternative mit integriertem Kalman, der auch mit dem Due arbeitet?

Hättest du jemals mit dem MPU und dem Due selber gearbeitet, wüsstest du, warum ich eine Alternative suche.

Also sei jetzt bitte du nicht beratungsresistent, sondern poste einen einfachen Code ohne libs, die den MPU mit Kalman zum Laufen bringt indem einfach nur 6 bytes mit gefilterten Werten ausgelesen werden - oder lass es einfach, hier Besserwissereien zu verbreiten und weiter auf dem MPU rumzureiten, denn danach habe ich nicht gefragt!.

Welchen Prozessor du genau verwendest, spielt doch überhaupt keine Rolle, hauptsache er kann I2C und das kann der Due.
Der MPU hat einen DMP (Digital Motion Processor) integriert, der intern, ohne dass du irgendwas rechnen musst, einen Filter (evtl Kalman, evtl nicht) auf die Rohdaten (Gyro & Acc) anwendet und so die korrekten, driftfreien, voll benutzbaren, tollen, supergeilen fusionierten Winkel ausgibt!!! (ich glaub, das schreib ich dir jetzt zum 10. mal)
In dem Link, den ich vorhin gepostet hatte, sind alle benötigten Funktionen drin, um den DMP zu initialisieren und auszulesen, zudem noch Konversion von Quaternionen in Euler & DCM.
Einziger "Nachteil" du musst mehr als 6Bytes einlesen, um die Winkeldaten zu erhalten, weil Quaternionen nunmal mehr Platz brauchen.
Was willst du mehr oder anders oder ...??

Zitat:

---

Zitat von HaWe

hallo,
wer hier hat eine gute Empfehlung für eine IMU, die man mit einem Arduino Due und einem Breadboard betreiben kann ?

Es sollte ein I2C Gyro Sensor sein, der intern durch eigene Filter (Kalman etc.) stabilisiert ist, evtl. durch Verwendung zusätzlicher weiterer Sensoren (wie z.B. Accelerometer und/oder Kompass).

Der Gyrowert (wenigstens die Winkelgeschwindigkeit - oder möglicherweise auch bereits der Winkel) sollte also stabilisiert und gefiltert ausgegeben werden, indem man einfach I2C Register ausliest (z.B. 3x 16 oder 3x 24 bit für die 3 dim.), ohne dass weitere Berechnungen notwendig sind. Insb. muss der Sensor auch für den Due geeignet sein.

MPU6050 u.ä. scheiden also aus, weil man zum Einen viel zu viel selber rechnen muss um zu verwertbaren Werten zu kommen, zum anderen oft AVR Timer verwendet werden, was die Sache unglaublich verkompliziert und gerade auch für den Due unbrauchbar macht. Außerdem hat er offenbar keine eingebauten Kalman-Filter, wie es nötig wäre. Ein einfaches selbst ausgelöstes I2C -read für devaddr + regaddr muss also reichen.

Eine grundsätzliche Idee wäre z.B. dieser Chip als 1D-Gyro hier, leider ist der aber eben 1D und nicht direkt anschließbar und steuerbar mit Arduinos/Breadboards, außerdem scheint er auch UART/SPI zu haben und kein I2C:
http://www.minfinity.com/eng/page.ph...=1&sub=1&tab=2

Wer kennt was?

---

bitte nur direkt auf diese TOP-Fage antworten. Danke.

ps,

mich interessieren auch keine Quaternionen, alleine bei der Vorstellung, damit rechnen zu müssen, kriege ich Gehirnkrämpfe.
Ich brauche einzig und allein die ganz simplen isolierten Dreh-Bewegungsrichtungen in den 3 Raumrichtungen/Ebenen, vergleichbar mit Kompassgraden, nur eben nicht alleine in der Ebene (wie beim Kompass, d.h. um die Hochachse) sondern auch in den Ebenen um die Quer- und um die Längsachse. Das Bezugssystem ist dabei (wie beim Kompass) das irdische (echte, absolute) Raumkoordinatensystem.

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

Zitat:

---

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!

Zitat:

---

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.

Zitat:

---

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.

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.

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 :D

Ciao

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 !

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.

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.

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

hallo,
ich sehe da zwar jetzt keinen Preis auf den ersten Blick, aber der MicroInfinity (1D mit Kalman) hat auch 85 EUR plus 20 EUR Versand gekostet.
Wenn es also im Verhältnis zur Leistungsfähigkeit steht und am Arduino leicht anzuschließen und per I2C leicht auslesbar ist ...

Ich kenne den aktuellen Preis nicht. Aber da muss man sicher minderstens eine Null anhängen.

I2C kann der nicht. UART könnte gehen. Ich kenne nur die USB-Version von den Dingern und das C++ SDK für Windows.

I2C ist Vorraussetzung, weil alle anderen Ports bereits besetzt sind. Es muss ja auch nicht schnell sein, 50Hz reichen dicke aus.

HaWe: Dein Wunsch ist verständlich und es geht mir Ähnlich. Nur gibt es diesen Sensor mit den von dir gewünschen Funktionen offensichtlich nicht (zumindest nicht bezahlbar)! Die User versuchen dir nun andere Wege aufzuzeigen, die natürlich nicht deiner Wunschvorstellung entsprechen und überleg dir eine alternative Lösung für dein Problem.

Ansonsten können wir den Thread hier gleich zu machen mit dem Kommentar:
"So einen Sensor gibt es nicht bzw. ist sehr teuer. Alternativen sind nicht gewünscht. Thema abgeschlossen!"

ich würde noch etwas abwarten wollen - was spricht dagegen?
Es haben sicher noch nicht alle 64.816 Forumsmitglieder meine Frage gelesen und auch Zeit gehabt, darüber nachzudenken...

ps, edit:
"sehr teuer" ist relativ, da muss man erst mal sehen, was man für welchen Preis bekommt - da bin ich durchaus flexibel.

so - und es gibt ihn doch! :cool:
und billig ist er auch noch! :cool:
und extrem einfach steuern lässt er sich auch ! :cool:
CMPS11,
echter IMU-Sensor (Gyro, Kompass, Acc) mit interner on-board-Kalman-Sensorfusion !
kostet knapp 30 EUR!
Beschreibung siehe hier:
http://www.mindstormsforum.de/viewtopic.php?f=78&t=8642
http://www.mindstormsforum.de/viewto...p=67476#p67401

share and enjoy! \\:D/