Everyone knows the InvenSense MPU6050 sensor, but do they really? Sorry for the silly introduction, it is widely known that the MPU6050 has many undocumented registers, that directly affect readings and control undocumented (mostly dmp) features. I have begun reverse engineering some of them, but this is a long a complicated process. Has anyone else tried to do something similar? Post your results below if you have a greater understanding, than what is documented.
I'll start by sharing my findings on the FINE_GAIN registers, which are (from I2Cdev library):
#define MPU6050_RA_X_FINE_GAIN 0x03 //[7:0] X_FINE_GAIN
#define MPU6050_RA_Y_FINE_GAIN 0x04 //[7:0] Y_FINE_GAIN
#define MPU6050_RA_Z_FINE_GAIN 0x05 //[7:0] Z_FINE_GAIN
Sensors usually have to be calibrated by the following equation:
real value = (reading_from_sensor - offset) * scaling_factor
The offset registers are known and often used, but I have never seen anyone using the registers for the scaling factor. After long nights of frustration I came to the following conclusion:
Bits 0-3 affect the gyro values
Bits 4-7 affect the accelerometer values
These registers do have factory calibration values, but like the accelerometer offsets, they are often way off. I have not done anything to gyro scaling, as I have no means to verify rotational speeds. However since we know gravity we can easily verify accelerometer readings.
First step is to calibrate the accelerometer offsets (values are in +-16g mode). If you have done a good job, accelerometer readings will be exactly the same if you flip it over up side down, except for the sign of course.
After this set the gain register to 0 and take a new reading, with the positive axis facing up. The new correct offsets (4 bits) can be calculated with the following formula.
scaling_factor = (2048 - accel_reading) / 29
To find the divisor I just plotted the accelerometer readings and changed the fine gain value. With each step (there are 16 steps) the readings approximately change by 29 in average (somewhere in the range of 28-30). This is a floating calculation and when converting to integers you have to round up or down.
Of course this has to be done for each axis, carefully placing the sensor to get the highest readings possible when not moving.
Someone should tell you that you are wasting your time. That someone might just as well be me: You are wasting your time.
The I2Cdev lib started when the 'dmp' was still undisclosed. I assume that not all known information is in the I2Cdev lib.
Sometimes a manufacturer uses registers to check the fabrication process or for calibrating. They are often not of interest for the end-user.
The MPU-6050 is outdated and noisy. What good will more information of the registers do ?
Do you use a Arduino Uno ? That is a 5V board and the MPU-6050 is a 3.3V sensor.
Have you read the hidden data of the fabrication process of your ATmega328P 
Koepel:
Someone should tell you that you are wasting your time. That someone might just as well be me: You are wasting your time.The I2Cdev lib started when the 'dmp' was still undisclosed. I assume that not all known information is in the I2Cdev lib.
Sometimes a manufacturer uses registers to check the fabrication process or for calibrating. They are often not of interest for the end-user.The MPU-6050 is outdated and noisy. What good will more information of the registers do ?
Do you use a Arduino Uno ? That is a 5V board and the MPU-6050 is a 3.3V sensor.
Have you read the hidden data of the fabrication process of your ATmega328P
I am using this sensor in a project with a custom PCB and just realized how little is documented about it by the manufacturer. That's my reason for starting this topic. I actually only needed this register and thought I would share my findings.
The MPU6050s noise and performance is good enough for my application, but the feature set is essential. Do you know of any other sensor, that can directly output quaternions? Please let me know if something more modern is available. Power consumption and being able to solder it at home are also a concern.
You don't have to quote my post. What I wrote is already there
The information that was first released for the MPU-6050 was just a subset. Later the 'dmp' code was released. I don't know if also more information was released about the registers.
A custom PCB ? How about the voltages on the I2C bus ? When the processor is running at 5V and the sensor at 3.3V, then there is voltage mismatch.
Bosch puts a M0 ARM processor in the sensor: Adafruit 9-DOF Absolute Orientation IMU Fusion Breakout - BNO055 : ID 2472 : $34.95 : Adafruit Industries, Unique & fun DIY electronics and kits.
Also BNO085 which has the same hardware as the BNO055 but running improved fusion firmware.
Please let me know if something more modern is available.
The MPU6050 is old and noisy, and was discontinued some time ago.
There are several modern 6 and 9 DOF sensors that vastly outperform it. The LSM9DS1 is the best I've encountered to date, and it is straightforward to calculate the quaternion representing the 3D orientation.
Be sure to calibrate the sensor, and that is best done in place, after installation.
I can vouch for the quality of the BNO085; it can be a bit complicated to interface with but it does a lot. I haven't used it in a project first but from my testing results are promising. The UART-RVC mode is super simple to work with and provides some very solid heading readings.
If you want quaternions, there are a multitude of fusion products available for a variety of uses. I'm uncertain about the power requirements in a real world situation but it's worth buying a breakout to evaluate.
Feel free to @/DM me with any questions and I'll do my best to reply with useful information 
Personally I applaud your efforts to learn more about the capabilities of a sensor. Certainly there are newer better IMUs available, however that doesn't mean your efforts are a waste of time. At the very least you're exercising your RE muscles and have been kind enough to share your results with your fellow sensor nerds.
Should you decide you're done with the MPU-6050, as others have mentioned there are newer more accurate and precise IMUs available including the ICM-20948 which is a current-ish relative of the MPU-6050 which has a sensor fusion co-processor as well. The firmware of said motion processor could certainly do with some time under the metaphoric microscope from some enterprising reverse engineer.
It sounds like a difficult and frustrating thing to do. Different chip revisions will likely be different too, just to make the job harder!
This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.