Hi,
ich möchte Bewegungsdaten mit dem MPU6050 ermitteln.
I2C läuft. Ich kann Register beschreiben und auch wieder auslesen.
Leider bleiben die Register für die Messdaten noch leer.
In vielen Projekten die im Netz stehen werden folgende Register genutzt.
#define MPU_RA_BANK_SEL 0x6D
#define MPU_RA_MEM_START_ADDR 0x6E
#define MPU_RA_MEM_R_W 0x6F
#define MPU_RA_DMP_CFG_1 0x70
#define MPU_RA_DMP_CFG_2 0x71
Leider werden diese Register im Datenblatt nicht erklärt.
Ich habe: "MPU-6000 and MPU-6050 Register Map and Description Rev
4.0.pdf"
Hat jemand noch ein altes Datenblatt oder kann Auskunft über diese
Register geben??
Eine Init Routine für den MPU6050 habe ich natürlich. Die Datenblätter
habe ich auch. Leider werden in den Datenblättern scheinbar nicht alle
Register erwähnt.
MPU6050 Init von Noah Zerkin und eine andere beschreiben die oben
erwähnen Register.
Ich möchte nur Wissen ob jemand eine Doku zu diesen Registern hat oder
mir sagen kann was diese Register bewirken?????
Oder gibt es sogar eine alte und eine neue Schaltkreis-Version mit
unterschiedlichen Registern?????
Ach ich glaube das ist für den eingebauten DSP. Invensense rückt ja
nicht raus wie man das manuell einspielen kann. Und diese
(undukumentierten) Register werden dann befingert um den Fusion
Algorithmus Dump da wieder einzuspielen (nachdem welche mitgeplottet
haben was die Motion App da macht)
Da gibts dann 8 Banks in die dann 128 oder 256 Bytes eingespielt werden,
welche dann diese UC3-A3 Firmware dort einspielen.
Bisher musste ich die Register nie befingern um die Rohdaten des Sensors
auszulesen.
OK, danke für die Info. Da kann es also nicht an diesen Registen liegen.
ein paar Register sind hier beschrieben:
http://www.i2cdevlib.com/devices/mpu6050#registers
Weiter bin ich trotzdem noch nicht alle Daten Register bleiben leer.
Gibt es noch bestimmte dinge die man beachten sollte beim MPU6050?????
hier meine INIT
CLKSEL = 3 bringt nix
eine Auslese Routine habe ich noch nicht geschrieben, weil ich noch
keine Daten auslesen konnte.
Ich wollte eigentlich den INT-Pin nehmen einen Interupt generieren und
die entsprechenden Register auslesen.
Interrupt kommt nicht
Im Moment lese ich einfach folgende Register aus
leider bleiben alle leer.
1
MPU_RA_INT_STATUS0x3A
2
MPU_RA_ACCEL_XOUT_H0x3B
3
MPU_RA_ACCEL_XOUT_L0x3C
4
MPU_RA_ACCEL_YOUT_H0x3D
5
MPU_RA_ACCEL_YOUT_L0x3E
6
MPU_RA_ACCEL_ZOUT_H0x3F
7
MPU_RA_ACCEL_ZOUT_L0x40
8
MPU_RA_TEMP_OUT_H0x41
9
MPU_RA_TEMP_OUT_L0x42
10
MPU_RA_GYRO_XOUT_H0x43
11
MPU_RA_GYRO_XOUT_L0x44
12
MPU_RA_GYRO_YOUT_H0x45
13
MPU_RA_GYRO_YOUT_L0x46
14
MPU_RA_GYRO_ZOUT_H0x47
15
MPU_RA_GYRO_ZOUT_L0x48
16
17
MPU_RA_FIFO_COUNTH0x72
18
MPU_RA_FIFO_COUNTL0x73
19
MPU_RA_FIFO_R_W0x74
Das Auslesen an sich funzt. Ich kann alle zuvor beschriebenen Werte
wieder zurück lesen.
Mit dem I2C stimmt auf dem Oszi auch alles. (siehe Anhang)
Keine Ursache.
Ich nutze den Fifo nicht. Ich lese die Register alle 10ms "manuell" aus,
so habe ich eine feste Zeitbasis für die Lageberechnung (also unter
anderem die Integration der Winkelgeschwindigkeit) im µC.
> und die Register bleiben nicht mehr leer. Timmo 1000 Dank.>> Nutz du den FIFO oder liest du die Daten direkt von den entsprechenden> Registern aus??
Hallo, ich spiel gerade mit dem selben Chip rum. Bekommst Du vernünftige
Daten? Bei mir kommen zwar Gyro- und ACC-Daten, aber ich kann damit gar
nichts anfangen.
Ich hab bei ruhendem Chip mal den Mittelwert über 256
Beschleunigungsmessungen gebildet und das als Referenz für die aktuelle
Lage genommen. Wenn man von den aktuellen Beschleunigungswerten immer
die Referenz abzieht, sollte eigentlich immer ziemlich null
herauskommen, solange man den Chip nicht bewegt.
Das tut es nun überhaupt nicht.
Rauschen hast du immer drin, auch wenn du immer einen Mittelwert von den
vorherigen Messungen abziehst. Je nach Messbereich und Einstellungen
(Hochpass/Tiefpass-Filter etc) schwanken die Abweichungen.
Aber wenn du die Werte mal in m/s² oder Grad/s umrechnest wirst du sehen
dass das Rauschen auf der ebene gar nicht mehr so schlimm ist.
Aber wenns gut eingestellt ist rauschen bei mir die Rohdaten des
Beschleunigungssensors etwa um +-3 (im 4G Bereich). Der Gyro ist hier
aber schlimmer, aber das wirkt sich eigentlich nur auf den Drift aus,
welchen man ja mit dem Beschleunigungssensor ja wieder kompensiert. Den
Drift um die Z-Achse kompensiere ich mit einem Mag3110 (der Drift ist
auch noch da wenn man ihn vorher mit einer Mittelwertsbildung bestimmt
hat und abzieht)
Timmo H. schrieb:> Rauschen hast du immer drin, auch wenn du immer einen Mittelwert von den> vorherigen Messungen abziehst. Je nach Messbereich und Einstellungen> (Flter etc) schwanken die Abweichungen.> Aber wenn du die Werte mal in m/s² oder Grad/s umrechnest wirst du sehen> dass das Rauschen auf der ebene gar nicht mehr so schlimm ist.>> Aber wenns gut eingestellt ist rauschen bei mir die Rohdaten des> Beschleunigungssensors etwa um +-3 (im 4G Bereich). Der Gyro ist hier> aber schlimmer, aber das wirkt sich eigentlich nur auf den Drift aus,> welchen man ja mit dem Beschleunigungssensor ja wieder kompensiert. Den> Drift um die Z-Achse kompensiere ich mit einem Mag3110
Dann ists bei mir schlecht eingestellt. Hättest Du vielleicht mal eine
Registerbelegung für den Anfang? Ich hab die von hier:
http://www.roboternetz.de/community/threads/61632-MPU6050-mit-Atmega32
genommen. Wenn ich den Chip nicht bewege hab ich bei x,y,z jeweils
Abweichungen von ein paar hundert vom Mittelwert. Außerdem kommen nur ca
3 Messungen pro Sekunde.
>> Meine müsste ich nochmal raussuchen, aber ich glaube die waren recht> ähnlich
Vielen Dank fürs Helfen.
Das mit der langsamen Abtastung lag an völlig falschen Werten fürs TWI.
Beim Mittelwert hab ich das Problem, dass ich es nicht schaffe, die 256
Messwerte vorzeichenbehaftet zu addieren. Das mit dem
add bla_low, trööt_low
adc bla_high, trööt_high
geht jedenfalls nicht.
Naja in der Z-Achse (natürlich je nach Drehrichtung) wo du ja immer 1G
hast, wenn es gerade liegt, ist so ein 16-Bit wert auch schnell
übergelaufen. Da musst du das schon etwas größer dimensionieren und
natürlich auch entsprechend die Division dafür vorsehen.
Gut dass ich mich nicht mehr mit Assembler rumschlage :D
Timmo H. schrieb:> Naja in der Z-Achse (natürlich je nach Drehrichtung) wo du ja immer 1G> hast, wenn es gerade liegt, ist so ein 16-Bit wert auch schnell> übergelaufen. Da musst du das schon etwas größer dimensionieren und> natürlich auch entsprechend die Division dafür vorsehen.> Gut dass ich mich nicht mehr mit Assembler rumschlage :D
ja, ich nehm 24 Bit als Summe. 256 Stück 16 Bit Zahlen gehen genau in
eine 24 Bit Zahl. Zum Schluss schau ich mir nur die oberen 16 Bit an und
schon hab ich dividiert.
Jetzt scheints auch zu gehen. Ich hatte ja eigentlich sowas, wie die
Teapot-Demo vor, nur dass der Chip nicht seine Ausrichtung (theta, psi,
phi) rechnen soll, sondern seine Lage (x,y,z). Unter der Voraussetzung,
dass man ihn nicht zusehr dreht.
Mal sehen, aber ich fürchte, ich hab einen grundlegenden Denkfehler.
Vielleicht als kleine Hilfe für dich/euch, was in Ordnung ist vom
Rauschen her. Der Sensor wird mit 100 Hz ausgelesen, (jedoch nur jeder 5
Wert auf dem Display dargestellt), DLPF_CFG = 0 (keine Filterung), Gyro
@ 2000dps, Acc @ 8G. Ungefilterte und nicht umgerechnete Rohdaten. Nur
der Gyro Offset von X = -50; Y= 19; Z=-3 wurde rausgerechnet:
http://bilder.pcmx.de/MPU6050.mkv
Hallo Zusammen
Ich habe ein ähnlcihes Problem gehabt. Im meinem Fall Arbeitet nur due
MPU 6050 Revsion D mit meinem Programm alle neueren MPUs Revsion E
aufwärts braucht man eine Treiber update...
Hallo zusammen,
experimentiere auch gerade mit diesem Sensor und bin froh, dass ich
endlich ein Forum gefunden habe in dem es um den MPU 6050 geht und in
dem deutsch gepostet wird!
Was möchte ich machen?
Ich will versuchen Modellbaumotoren + Propeller von meinem Kopter zu
wuchten. Dazu messe ich mit dem Sensor die Beschleunigung in einer Achse
und lasse mir mit einer Stroboskop-Schaltung die Position der Unwucht
anzeigen. Dann auf der gegenüberliegenden Seite Ausgleichsmasse
anbringen.
Als Prozessor verwende ich einen Picaxe-Prozessor und arbeite über i2c.
Bisher kann ich den Beschleunigungswert auslesen und den Blitz auslösen
aber die Laufzeiten im Prozessor pendeln immer etwas.
Erste Frage wäre wie kann ich prüfen ob ein neuer Messwert im Sensor
vorliegt?
Um die Laufzeitprobleme zu umgehen gibt es ja die DMP-Funktion.
Stelle mir das so vor:
- Beschleunigungswert für die Achse ins Register schreiben
- Wenn dieser Beschleunigungswert bei einer Messung überschritten wird
dann wird ein Interrupt ausgelöst und dieser Wert in einem Register
abgelegt das ausgelesen werden kann.
Allerdings habe ich keine Ahnung wie ich dazu den Sensor konfigurieren
muss!
Ihr könnt mir da doch sicher einen Tip geben oder?
LG
Wolfgang