I’ve discovered strange code in MPU6000 module
github.com/diydrones/ardupilot/ … 0.cpp#L377
Strange thing is X and Y values are read in reverse order.
Bytes 0,1 goes to Y accel value
Bytes 2,3 goes to X accel value
Same for gyro values.
According to specification X-axis-bytes comes first.
Is it a hardware-specific hack? Looks like IMU turned in 90 degrees.
I’m porting arducopter on custom hardware with MPU6050 as IMU.
i2c is the only supported bus for MPU6050 so I’m hacking MPU6000 code to support i2c transport.
Could be that we did that because the APM2 has the chip rotated 90degrees, or maybe we have a difference definition of what X vs Y is from the MPU6k datasheet.
You’ll find that SirAlex who I think works on the Crius board and/or MegaPirates has already ported our MPU6k library to work on the 6050. The problem with using that is that it’s much slower than using an SPI connection. about 20x slower I think. 8Mhz vs 400khz.
Thanks for information!
MPU6050 supports i2c only so in my case it is 400kHz VS Zero
Looks like I found the confirmation for the answer (through looking QGroundControl source code)
The strange calculation just ‘fixes’ HW axes to match logical aircraft axes:
X axis goes forward
Y goes to the right
Z goes down.
Could someone confirm my findings?