Hey Neil, It has been a while since I've looked at this code, and you've just reminded me I never did finish the api, getQuat, getAccel ect where supposed to be there. Can you show me how you are decoding the buffer.

This is the format of the data in the fifo, /* ================================================================================================ *

• ================================================================================================ */ /* debug.printf("AccX: %i-%i, \r ", buffer[34],buffer[35]); debug.printf("AccY: %i-%i,\r ", buffer[38],buffer[39]); debug.printf("AccZ: %i-%i \r ", buffer[42],buffer[43]); debug.printf("GyrX: %i-%i, \r ", buffer[16],buffer[17]); debug.printf("GyrY: %i-%i \r ", buffer[20],buffer[21]); debug.printf("GyrZ: %i-%i \r ", buffer[24],buffer[25]); debug.printf("MagX: %i-%i \r ", buffer[28],buffer[29]); debug.printf("MagY: %i-%i \r ", buffer[30],buffer[31]); debug.printf("MagZ: %i-%i \r\n", buffer[32],buffer[33]);

• / debug.printf("ACC: %d, %d, %d\r\n", (int16_t)(((int16_t)buffer[34] << 8) + (int16_t)buffer[35]), (int16_t)(((int16_t)buffer[38] << 8) + (int16_t)buffer[39]), (int16_t)(((int16_t)buffer[42] << 8) + (int16_t)buffer[43]));

debug.printf("GYRO: %d, %d, %d\r\n", (int16_t)(((int16_t)buffer[16] << 8) + (int16_t)buffer[17]), (int16_t)(((int16_t)buffer[20] << 8) + (int16_t)buffer[21]), (int16_t)(((int16_t)buffer[24] << 8) + (int16_t)buffer[25]));

debug.printf("Magn: %d, %d, %d\r\n", (int16_t)(buffer[28] << 8) + buffer[29], (int16_t)(buffer[30] << 8) + buffer[31], (int16_t)(buffer[32] << 8) + buffer[33]);

I think for Accx,accy I am supposed to get 0 and around 16300 for the z axis, gyro all 0, no idea for the magnetometer. I am going crazy with this Please help :)

I managed to find my mpu9150 after much digging and the code above does work (it looked right but I thought I'd check) how long and secure are your i2c connections, have you left the i2c at 100khz?

yes I have kept it the same as 100khz.

Could you please let me know what are the values u get?

The airplane moves okayish in Processing

If you mbed it doing lots, or trying to send data at a low baud rate it may miss data on the i2c bus, but the fact the first half of the packet (the quaternion) is always valid is odd.

ACC: 21 : 0.01g, 0.03g, 1.02g
GYRO: 21 : -0.06deg/s, 0.00deg/s, -0.06deg/s

ACC: 41, 214, 8382
GYRO: -1, 0, -1
Magn: -9217, -31745, -5633

accelerometer is set to 4g full scale, gyro 2000 deg/s full scale.

Hi Chris, I changed the baud rate to 115200.

I get the below which I think is stil wrong for Acceleration and Magn. Gyro seems right I guess any idea why only the accelerometer is having issues? Even the magnetometer keeps varying. I am using a different board NRF51DK. Do you have code to convert these values to their actual values?

1. QUAT_R: 0.986836 0.032715 0.035414 -0.154373 ACC: -634, 426, 7945 GYRO: 0, -1, 0 Magn: -6913, 28672, 4608
2. QUAT_R: 0.986434 0.033040 0.035943 -0.156730 ACC: -648, 442, 7946 GYRO: -1, -1, 0 Magn: -6913, 29696, 4608
3. QUAT_R: 0.986509 0.033956 0.036442 -0.155943 ACC: -663, 423, 7965 GYRO: 1, -2, 0 Magn: -6913, 28160, 5120
4. QUAT_R: 0.986175 0.033157 0.036380 -0.158228 ACC: -614, 445, 7922 GYRO: 0, 0, 0 Magn: -6913, 29184, 5120
5. QUAT_R: 0.986545 0.034871 0.035305 -0.155780 ACC: -653, 502, 7949 GYRO: -1, -1, -1 Magn: -6401, 29184, 5120
6. QUAT_R: 0.986286 0.036978 0.035423 -0.156901

the data values look correct in the last data you posted? to convert you just scale by (full_range / MAX_INT16). so for the accelerometer its full range is set to 4g

float acc_scale =  4.0/32768.0;
float actual_x = sensor_x * acc_scale;

Hi Chris

Thanks a lot. These are the values I get now .

ACC: 0.108398, -0.158325, 0.912231 GYRO: 0.000000, -0.061035, 0.000000 Magn: -225.036621, 796.875000, 196.875000

1. QUAT_R: 0.991462 -0.079867 -0.065677 0.079447 ACC: 0.109619, -0.157593, 0.912720 GYRO: 0.000000, -0.061035, -0.061035 Magn: -234.411621, 787.500000, 206.250000
2. QUAT_R: 0.991466 -0.079865 -0.065615 0.079441 ACC: 0.114258, -0.157593, 0.912109 GYRO: 0.000000, -0.061035, -0.061035 Magn: -187.536621, 796.875000, 253.125000
3. QUAT_R: 0.991446 -0.079844 -0.065911 0.079467

Does this seem ok at rest? I also wanted to know the following: 1) How do I setup Bias for each of them? 2)Also where should I make the changes if I want to set Acc to 2G and Gyro to 250 . I need to use it for human motion so I think lower resolution values should be good enough?

I am really really really thankful for all the help your giving me :) One more thing, the program at time gives zero values for everything, I need to restart the board and then I get proper values, Any idea about this?

Thanks and Regards, Neil

I wrote this library for personal use and never really got to writing a nice api, there are methods in the MPU9150 class ( setGyroFullScaleRange, setAccelFullScaleRange for changing the resolution of the sensors, but I don't know if that effects the DMP firmware that is uploaded (this is what generates the quaternions), and modifying the frequency of the data is even harder, there's a config array in the dmpdata.h file and the last hex value controls the update frequency. looking at the header file for the library is the best way to see whats available I'm afraid.

also the data looks fine, If the sensor board is perfectly level then there may be an issue with the factory set biasing though. The magnetometer reading is normal but actually getting useful data from it is a bit of hassle.

Oh, Thanks Chris. Btw could you please let me know how you found out that the resolution for acc and gyro is 4 and 2000?

And How do you increase the speed at which the data is acquired and displayed?

because I set them that way ;) 4g is the default and isn't changed, the gyro is set in the initialiseDMP method in the library. As i mentioned a few comments up changing how the actually DMP chip sends data is messy, the last value of the dmpConfig array in dmpdata.h controls it (there is a comment). As far as I could find when i was porting this library there is no documentation for the DMP in these sensors, the firmware uploaded to it is undocumented and no source is available.

But even if I try to change the resolution of the two in the above said method it doesn't change :(

It still stuck at 4g and 2000

And the rate of read is just changd by this right:

if(timer.read_ms() > [1000->this value]){ timer.reset();

that line only effects how often data is sent over serial, not the actual sensor update frequency, (see previous comment) I'l look into the range of the sensors not changing but I'm not sure how the DMP firmware effects this, You may be better off using a library that doesn't use the DMP and calculating sensor fusion on the mbed.

Yes, I actually tried another library but the quaternions generated using madgwick or so are very very different from the quaternions generated by the DMP and do not work with the teapot or any other programs.

Raw Values:

1. ACC: 414 -16 16436
2. GYR: -5 5 -3
3. MAG: -93 39 15

Processed Values:

1. ACC_R: 0.025269 ms2 -0.000977 ms2 1.003174 ms2
2. GYR: -0.038147 0.038147 -0.022888
3. MAG_R: -313.286163 uTe 229.389053 uTe 313.797821 uTe

Quaternions

1. QUAT_R: 0.879949 0.007043 -0.012350 0.474855

These are the values I get with the other api located here: https://developer.mbed.org/users/onehorse/code/MPU9150AHRS/

The accel values seem to be okay but the mag and gyro and quaternions do not.

I am so confused what to do :(

Invensense have released a lot more information and source code since I wrote this library (I will have to update it when I'm not so busy (if that ever happens) so i can see now that the DMP needs 4G, 2000Deg/s to work (also it turns out the DMP doesn't even use the magnetometer). I'm not sure why that other library Isn't working properly, the fusion seems wrong but it could just be calibration.

You mean this:

The embedded Digital Motion Processor (DMP) is located within the MPU-9150 and offloads computation of motion processing algorithms from the host processor. The DMP acquires data from accelerometers, gyroscopes, magnetometers and additional 3rd party sensors such as pressure sensors, and processes the data. The resulting data can be read from the DMP’s registers, or can be buffered in a FIFO. The DMP has access to one of the MPU’s external pins, which can be used for generating interrupts. The purpose of the DMP is to offload both timing requirements and processing power from the host processor. Typically, motion processing algorithms should be run at a high rate, often around 200Hz, in order to provide accurate results with low latency. This is required even if the application updates at a much lower rate; for example, a low power user interface may update as slowly as 5Hz, but the motion processing should still run at 200Hz. The DMP can be used as a tool in order to minimize power, simplify timing, simplify the software architecture, and save valuable MIPS on the host processor for use in the application.

It says here that it generates using all? Could you please let me know which document you are referring to ;)