Open RSKothari opened 7 years ago
The datasheet is quite vague about the Digital Motion Processor which should be inside the MPU-6050, or at least the datasheet I have. In 7.9 the datasheet says the following:
The DMP acquires data from accelerometers, gyroscopes, and additional 3rd party sensors such as magnetometers, and processes the data. The resulting data can be read from the DMP’s registers, or can be buffered in a FIFO.
The problem is, is that there's no mention of these DMP registers in the MPU-6050 register map and descriptions. (revision 4.2)
I'd like to see if I can add it, but with documentation this vague I'm afraid I can't help you. So if you can find more information about the DMP, please share it.
It seems that the i2c library built and managed by @jrowberg seems to solve the same. Here is the link: https://github.com/jrowberg/i2cdevlib
I am a newbie when it comes to programming in C but I'll try and look through his library and figure out where he gets it from.
So I looked into the code of i2cdevlib. The registers they use as the DMP config registers are 0x70 and 0x71, which are not in the register map documentation I found.
Also, the code mentions that the DMP methods are not documented...
If you look at the sparkfun libraries, they just let the DMP write to the FIFO, and then just read from the FIFO directly. So I guess one just needs to config the DMP to output values to the FIFO and then simply read the FIFO
I think if this Arduino C library was 'converted' to Python (the important bits, particularly in the .h file), then this Python library could replicate the functionality. The Arduino library is sort of the gold standard library for using the DMP because of the exensive work that's gone into getting it working. I've thought about doing it but found it easier to simply implement on an Arduino and then pass values to the Python script over a serial connection rather than directly handle in Python.
Two quick comments from my end:
I’m pretty sure the DMP uses the FIFO exclusively for its output, since there’s no other logical way to deliver variable-length binary packets (some of which can be very long) generated on a repeating interval. In other words, you can’t read DMP output like raw accel/gyro data.
The v2.0 microcode binary blob in the I2Cdevlib implementation is extremely outdated, but nobody (myself included) has enough time/motivation so far to update it to v5.1 or v6 or whatever is the latest. This would undoubtedly be worthwhile for anyone wishing to obtain the best performance from that device.
Is it possible to modify the library in order to read data directly from the DMP?