Drifting or inaccurate Yaw output

[spargopolis]

Hi Kris,

Thanks for the excellent resources you have made available for the MPU9250.

I'm trying get the MPU9250 to work on a custom board running FreeRTOS with a STM32F7x. The driver I'm using in heavily based on your code. More specifically I began by porting
MPU9250BasicAHRS_t3.ino to C and to run on FreeRTOS but later ported key code from (dual) MPU9250.cpp since it appears the most up to date. I am receiving data from accel, gyro and magnetometer sensors. I can provide this code if it would be helpful.

Here are the calibration values I am using:

Communicating with MPU9250 MPU ID : 71 Mag Raw Sens 174 176 164 Starting initAK8963() initAK8963:: Configured AK8963 to map it's output to the EXT_SENS_DATA registers Communicating with AK8963 MPU-mag ID: 48 Accel bias x -0.068603, y -0.990112, z -0.919555 mg Gyro bias x -0.916029, y 1.961832, z 0.862595 Mag Sens 1.179687 1.187500 1.140625 Mag Bias: 54.83300 215.4429 -242.8540 Mag Scale: 1.141000 1.250000 0.754999 Acc Res 0.000061, Gyro Res 0.007629, Mag Res 1.499389 Perhaps something here jumps out to you as being out-of-range? When I run 20 iterations of the MadgwickQuaternionUpdate function I see is the Yaw/Pitch/Roll do not correspond to the orientation of the board. These values slowly drift either downward or upwards. The direction of drift depends on the orientation of the board; (0.017 deg/s for Yaw when the board is horz, faster when vertical). For the components of the quaternion, q[0] drifts quickly and q[3] drifts slowly, whereas as q[1] and q[2] converge (if this helps). When the board is horizontal I see: North Accel x=836, y=-5560, Z=-13020 Temp=32.10 Gyro x=203, y=219, Z=116 Mag x=41, y=55, Z=-587 West Accel x=96, y=-4844, Z=-15368 Temp=32.49 Gyro x=-102, y=237, Z=97 Mag x=204, y=150, Z=-482 East Accel x=-316, y=-4460, Z=-15512 Temp=32.33 Gyro x=-127, y=281, Z=99 Mag x=51, y=-25, Z=-493 South Accel x=-804, y=-1476, Z=-15964 Temp=32.51 Gyro x=-111, y=240, Z=108 Mag x=155, y=85, Z=-401 When I run 100 iterations of the quaternion computation the Yaw value does converge. What I see is when the board is vertical for Yaw is: North 94-95 degs West 93-94 degs East 65-66 degs South 67-68 degs When the board is horizontal I see at Yaw of: North 281-282 degs West 265-266 degs East 302-303 degs South 278-279 degs In this case I notice the 4 components of the quaternion seem to be alternating signs. As an aside question: I understand accel/gyro and magnetometer are oriented on different axis inside the MPU9250, as per the product specification, and this difference is taken into account based on the order and sign of parameters passed into the quaternion computation routine. But does the orientation of the MPU9250 on the board relative to the nominal orientation of the vehicle which contains it (in this case a drone-like device) matter? In other words is there need to transpose the X/Y/Z axis to the NED nominal orientation of the aircraft?

[kriswiner]

I suspect you have not calibrated the sensors properly. How do you calibrate the magnetometer? How do you check that it is calibrated?

On Mon, Dec 31, 2018 at 1:29 PM spargopolis notifications@github.com wrote:

Hi Kris,

Thanks for the excellent resources you have made available for the MPU9250.

I'm trying get the MPU9250 to work on a custom board running FreeRTOS with a STM32F7x. The driver I'm using in heavily based on your code. More specifically I began by porting MPU9250BasicAHRS_t3.ino to C and to run on FreeRTOS but later ported key code from (dual) MPU9250.cpp since it appears the most up to date. I am receiving data from accel, gyro and magnetometer sensors. I can provide this code if it would be helpful.

Here are the calibration values I am using:

MPU:250 Communicating with MPU9250 MPU:250 MPU ID : 71 MPU:286 Mag Raw Sens 174 176 164 MPU:286 Starting initAK8963() MPU:304 initAK8963:: Configured AK8963 to map it's output to the EXT_SENS_DATA registers MPU:318 Communicating with AK8963 MPU:318 MPU-mag ID: 48 MPU:318 Accel bias x -0.068603, y -0.990112, z -0.919555 mg MPU:318 Gyro bias x -0.916029, y 1.961832, z 0.862595 MPU:318 Mag Sens 1.179687 1.187500 1.140625 MPU:318 Mag Bias: 54.83300 215.4429 -242.8540 MPU:318 Mag Scale: 1.141000 1.250000 0.754999 MPU:318 Acc Res 0.000061, Gyro Res 0.007629, Mag Res 1.499389

Perhaps something here jumps out to you as being out-of-range?

When I run 20 iterations of the MadgwickQuaternionUpdate function I see is the Yaw/Pitch/Roll do not correspond to the orientation of the board. These values slowly drift either downward or upwards. The direction of drift depends on the orientation of the board; (0.017 deg/s for Yaw when the board is horz, faster when vertical). For the components of the quaternion, q[0] drifts quickly and q[3] drifts slowly, whereas as q[1] and q[2] converge (if this helps).

When the board is horizontal I see: North MPU:1276626 Accel x=836, y=-5560, Z=-13020 Temp=32.10 MPU:1276626 Gyro x=203, y=219, Z=116 MPU:1276626 Mag x=41, y=55, Z=-587

West MPU:1578428 Accel x=96, y=-4844, Z=-15368 Temp=32.49 MPU:1578428 Gyro x=-102, y=237, Z=97 MPU:1578428 Mag x=204, y=150, Z=-482

East MPU:1460027 Accel x=-316, y=-4460, Z=-15512 Temp=32.33 MPU:1460027 Gyro x=-127, y=281, Z=99 MPU:1460027 Mag x=51, y=-25, Z=-493

South MPU:1684029 Accel x=-804, y=-1476, Z=-15964 Temp=32.51 MPU:1684029 Gyro x=-111, y=240, Z=108 MPU:1684029 Mag x=155, y=85, Z=-401

When I run 100 iterations of the quaternion computation the Yaw value does converge. What I see is when the board is vertical for Yaw is: North 94-95 degs West 93-94 degs East 65-66 degs South 67-68 degs

When the board is horizontal I see at Yaw of: North 281-282 degs West 265-266 degs East 302-303 degs South 278-279 degs

In this case I notice the 4 components of the quaternion seem to be alternating signs.

As an aside question: I understand accel/gyro and magnetometer are oriented on different axis inside the MPU9250, as per the product specification, and this difference is taken into account based on the order and sign of parameters passed into the quaternion computation routine. But does the orientation of the MPU9250 on the board relative to the nominal orientation of the vehicle which contains it (in this case a drone-like device) matter? In other words is there need to transpose the X/Y/Z axis to the NED nominal orientation of the aircraft?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU9250/issues/333, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qvGY7sXdyqaytbr84oBKQ8KNH0-Uks5u-oGogaJpZM4ZlqsU .

[spargopolis]

Hi Kris, Happy new year! For the magnetic calibration I used the ported MPU9250::magcalMPU9250 () algorithm, but perhaps there is an issue with the port. I hadn't really checked if the calibration made sense until today. Today I plotted the XY,XZ,YZ magnetic values over approx. 1000 points in Excel, similar to your descriptions. Here is the raw "before" data: Applying the newly captured mag calibration I plotted the following "after" data in Excel: ...but based on your "after" picture here https://github.com/kriswiner/MPU6050/wiki/Simple-and-Effective-Magnetometer-Calibration it appears that my calibration data is not creating an acceptable response... would you agree? Does it seem most likely that the issue is the magnetic calibration (and not accel or gyro)? Just thinking that I could perform the calibration directly in Excel now that I have the raw data there? Thanks!

[kriswiner]

Yes, the calibration doesn;t look to good. Are you moving the sensor in all directions during the calibration?

On Tue, Jan 1, 2019 at 2:13 PM spargopolis notifications@github.com wrote:

Hi Kris, Happy new year! For the magnetic calibration I used the ported MPU9250::magcalMPU9250 () algorithm, but perhaps there is an issue with the port. I hadn't really checked if the calibration made sense until today. Today I plotted the XY,XZ,YZ magnetic values over approx. 1000 points in Excel, similar to your descriptions. Here is the raw "before" data: [image: image] https://user-images.githubusercontent.com/16444814/50576763-e0670d80-0de6-11e9-8a4e-ff93f4b11fbc.png Applying the newly captured mag calibration I plotted the following "after" data in Excel: [image: image] https://user-images.githubusercontent.com/16444814/50576775-22904f00-0de7-11e9-9990-8d3be295fdf9.png ...but based on your "after" picture here

https://github.com/kriswiner/MPU6050/wiki/Simple-and-Effective-Magnetometer-Calibration http://url it appears that my calibration data is not creating an acceptable response... would you agree? Does it seem most likely that the issue is the magnetic calibration (and not accel or gyro)? Just thinking that I could perform the calibration directly in Excel now that I have the raw data there? Thanks!

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU9250/issues/333#issuecomment-450760811, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qqU7BHesfRM6fNbYfUzhbyG3P-Jgks5u-92GgaJpZM4ZlqsU .

[spargopolis]

Using the 1000 points I had in Excel I computed the mag bias and mag scale in Excel as: Mag Bias: 92.86251, 73.89176, -294.1613 Mag Scale: 1.051568, 1.058319, 0.905677 Several of these values where quite different from my earlier calibration data (but note that the earlier calibration was done on a different data set (so I suspect I didn't move the board around enough during cal). So with this I got the following in Excel: This looks like a better response, not perfect but I assume good enough. However even with this calibration data I still have the same issue (i.e.the Yaw doesn't correspond to the orientation of the board), despite the fact that the mx/my/mz does vary when the sensor is pointed N-E-W-S (see original post for details). So I'm thinking it is related to two issues: 1) the accel/gyro calibration is incorrect and throwing off the Quaternion computation, or 2) the Quaternion filter is not converging for some reason (possibly because my integration time is only 9-12uS, which is then converted to seconds).

[kriswiner]

Yes, the accel and gyro have to have the offset biases removed as well.

If your integration time is ~10 us then the fusion rate should be ~100 kHz which seems reallly too high to be true.

These filters are best run on fast processors like STM32L4 or F4.

On Tue, Jan 1, 2019 at 8:48 PM spargopolis notifications@github.com wrote:

Using the 1000 points I had in Excel I computed the mag bias and mag scale in Excel as: Mag Bias: 92.86251, 73.89176, -294.1613 Mag Scale: 1.051568, 1.058319, 0.905677 Several of these values where quite different from my earlier calibration data (but note that the earlier calibration was done on a different data set (so I suspect I didn't move the board around enough during cal). So with this I got the following in Excel: [image: image] https://user-images.githubusercontent.com/16444814/50580520-7b7ada00-0e1d-11e9-904b-f8c9dbadae93.png This looks like a better response, not perfect but I assume good enough. However even with this calibration data I still have the same issue (i.e.the Yaw doesn't correspond to the orientation of the board), despite the fact that the mx/my/mz does vary when the sensor is pointed N-E-W-S (see original post for details). So I'm thinking it is related to two issues: 1) the accel/gyro calibration is incorrect and throwing off the Quaternion computation, or 2) the Quaternion filter is not converging for some reason (possibly because my integration time is only 9-12uS, which is then converted to seconds).

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU9250/issues/333#issuecomment-450786757, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qtBokjuc8f_7vFopN5e5G8_KwSpRks5u_DoLgaJpZM4ZlqsU .

[spargopolis]

Interesting you were correct the 10us was not right. Is the timing I am reading from the final iteration of the loop running the Quaternion filter. i.e. ` uint32_t IntegrateTimeDeltaUs; .. for (uint8_t i = 0; i < 50; i++) { TimeNowUs = micros();

    IntegrateTimeDeltaUs = TimeNowUs - PrevTimeNowUs;
    PrevTimeNowUs = TimeNowUs;

    //Update the interrupt time delta between readings.
    updateTimeDelta (IntegrateTimeDeltaUs);

    MadgwickQuaternionUpdate(-ax, ay, az, 
                             gx* M_PI /180.0f, -gy* M_PI /180.0f, -gz* M_PI /180.0f,  
                             my, -mx, mz, q);
}

DEBUG_LOG_MPU ("Final time delta %ul", IntegrateTimeDeltaUs);

` Now shows between 91-101 us. Previously I had been using "%d" in the log format, which shows 9-12us. This isn't supposed to matter for non-negative numbers, but appears it does in this implementation.

Note I'm using a STM32F7 processor which has a faster clock rate than an F4. https://en.wikipedia.org/wiki/STM32#STM32_F7

Since the magnetic calibration looks reasonable, I suppose I should focus on the accel and gyro bias next. The other possibility for the issue is the value of "beta". Any other suggestions? Thanks

[spargopolis]

Having looked at the accel and gyro calibration procedure in detail I did find two things. The first was that the procedure assumes that the board is sitting flat during calibration since it removes gravity from the Z-axis. i.e. if(accel_bias[2] > 0L) {accel_bias[2] -= (int32_t) accelsensitivity;} // Remove gravity from the z-axis accelerometer bias calculation else {accel_bias[2] += (int32_t) accelsensitivity;} the other is that the gyro bias is getting written to the hardware registers, so that the CPU doesn't need to take this into account, but the accel bias is not written to hardware, with comment "Apparently this is not working for the acceleration biases..." so the CPU does have to take accel bias into account.

I now make sure I perform accel/gyro calibration when horizontal, and also removed the code where the CPU was subtracting gyro bias. I have recomputed the gyro and accel and these seem to reasonable values. Is there a way to verify this calibration?

Unfortunately I'm left with what appears to be the same issue; the Y/P/R values do not correspond to the orientation of the device, and the slow increase or decrease in a linear fashion.

I may be able to try different hardware tomorrow, but other than this I'm running low on ideas. :)

[kriswiner]

When calibrated, accel should show 0, 0 1 g and gyro 0, 0, 0 dps.

Other than proper calibration of the sensors, and correct ordering in the fusion filter, there is nothing else.

On Wed, Jan 2, 2019 at 1:51 PM spargopolis notifications@github.com wrote:

Having looked at the accel and gyro calibration procedure in detail I did find two things. The first was that the procedure assumes that the board is sitting flat during calibration since it removes gravity from the Z-axis. i.e. if(accel_bias[2] > 0L) {accel_bias[2] -= (int32_t) accelsensitivity;} // Remove gravity from the z-axis accelerometer bias calculation else {accel_bias[2] += (int32_t) accelsensitivity;} the other is that the gyro bias is getting written to the hardware registers, so that the CPU doesn't need to take this into account, but the accel bias is not written to hardware, with comment "Apparently this is not working for the acceleration biases..." so the CPU does have to take accel bias into account.

I now make sure I perform accel/gyro calibration when horizontal, and also removed the code where the CPU was subtracting gyro bias. I have recomputed the gyro and accel and these seem to reasonable values. Is there a way to verify this calibration?

Unfortunately I'm left with what appears to be the same issue; the Y/P/R values do not correspond to the orientation of the device, and the slow increase or decrease in a linear fashion.

I may be able to try different hardware tomorrow, but other than this I'm running low on ideas. :)

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU9250/issues/333#issuecomment-450996282, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qsywZ_nBo0aWua8VuJpigt1fRycWks5u_SnFgaJpZM4ZlqsU .

[spargopolis]

Thanks for your comments. That makes sense re. the expected accel and gyro values after calibration. I will check that out. I will also check the filter code. Cheers

On Wed, Jan 2, 2019, 5:08 PM Kris Winer <notifications@github.com wrote:

When calibrated, accel should show 0, 0 1 g and gyro 0, 0, 0 dps.

Other than proper calibration of the sensors, and correct ordering in the fusion filter, there is nothing else.

On Wed, Jan 2, 2019 at 1:51 PM spargopolis notifications@github.com wrote:

Having looked at the accel and gyro calibration procedure in detail I did find two things. The first was that the procedure assumes that the board is sitting flat during calibration since it removes gravity from the Z-axis. i.e. if(accel_bias[2] > 0L) {accel_bias[2] -= (int32_t) accelsensitivity;} // Remove gravity from the z-axis accelerometer bias calculation else {accel_bias[2] += (int32_t) accelsensitivity;} the other is that the gyro bias is getting written to the hardware registers, so that the CPU doesn't need to take this into account, but the accel bias is not written to hardware, with comment "Apparently this is not working for the acceleration biases..." so the CPU does have to take accel bias into account.

I now make sure I perform accel/gyro calibration when horizontal, and also removed the code where the CPU was subtracting gyro bias. I have recomputed the gyro and accel and these seem to reasonable values. Is there a way to verify this calibration?

Unfortunately I'm left with what appears to be the same issue; the Y/P/R values do not correspond to the orientation of the device, and the slow increase or decrease in a linear fashion.

I may be able to try different hardware tomorrow, but other than this I'm running low on ideas. :)

— You are receiving this because you commented. Reply to this email directly, view it on GitHub <https://github.com/kriswiner/MPU9250/issues/333#issuecomment-450996282 , or mute the thread < https://github.com/notifications/unsubscribe-auth/AGY1qsywZ_nBo0aWua8VuJpigt1fRycWks5u_SnFgaJpZM4ZlqsU

.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU9250/issues/333#issuecomment-451000588, or mute the thread https://github.com/notifications/unsubscribe-auth/APrtjpqRn1-ReY_B5mH_V6OTsPIpUAXUks5u_S3UgaJpZM4ZlqsU .

[spargopolis]

I found a couple of things which have made an improvement: 1) Fixed an issue on my side with the time delta which was causing the quaternion calculation to be really slow to converge, since every 20 iterations the time delta was incorrect. 2) The writing of the gyro offset registers was not working in my case, possibly because I am accessing the device via SPI. So I switched to having the CPU subtract the bias. Now I'm getting a much faster response from the algorithm.

Question re. the direction/sign of acceleration due to gravity. The PS document shows the +Z accel pointing upwards from the top of the MPU9250. Based on this I would assume that if the device was mounted face-up on a PC board, and the board was sitting horizontally on a table, the acceleration due to gravity would be negative (i.e. downwards into the table). However what I see in testing is the acceleration due to gravity is actually positive (e.g. 16479) in this case. I am misinterpreting the documentation? Would the difference in sign also affect the sign of Z gyro?

Similarly for the magnetometer, again if the device was mounted face-up on the PC board, with pin 1 in the lower right-hand side, and the top of the PC board pointing towards magnetic north, which axis and sign should have the largest reading? Based on the documentation I would think it would be negative X? Thanks for you help!

[kriswiner]

when up the Az should be +1 g by convention.

Mz should be ~400 mGauus, by far the largest component if in California. Check the local field from the USGS or equivalent for your area.

On Fri, Jan 4, 2019 at 2:33 PM spargopolis notifications@github.com wrote:

I found a couple of things which have made an improvement:

1. Fixed an issue on my side with the time delta which was causing the quaternion calculation to be really slow to converge, since every 20 iterations the time delta was incorrect.
2. The writing of the gyro offset registers was not working in my case, possibly because I am accessing the device via SPI. So I switched to having the CPU subtract the bias. Now I'm getting a much faster response from the algorithm.

Question re. the direction/sign of acceleration due to gravity. The PS document shows the +Z accel pointing upwards from the top of the MPU9250. Based on this I would assume that if the device was mounted face-up on a PC board, and the board was sitting horizontally on a table, the acceleration due to gravity would be negative (i.e. downwards into the table). However what I see in testing is the acceleration due to gravity is actually positive (e.g. 16479) in this case. I am misinterpreting the documentation? Would the difference in sign also affect the sign of Z gyro?

Similarly for the magnetometer, again if the device was mounted face-up on the PC board, with pin 1 in the lower right-hand side, and the top of the PC board pointing towards magnetic north, which axis and sign should have the largest reading? Based on the documentation I would think it would be negative X? Thanks for you help!

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU9250/issues/333#issuecomment-451588840, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qrzTgqmJhzzgiM8v6hi_rfY4-E9iks5u_9bNgaJpZM4ZlqsU .

[spargopolis]

Thanks yes I see Az = +1 g in the scenario above. I also see Mz as the largest component (~= -450 mG after calibration). I'm located in Ottawa, Canada.

But based on the MPU-9250 PS documentation (version 1.1 section 9.1) shouldn't Az be negative, and the largest magnetic component be -Mx? It's hard to believe the document could be wrong...

[kriswiner]

Az should be +1 g by convention

Why Mx? Usually the normal component is largest.

On Fri, Jan 4, 2019 at 3:19 PM spargopolis notifications@github.com wrote:

Thanks yes I see Az = +1 g in the scenario above. I also see Mz as the largest component (= -450 mG after calibration). I'm located in Ottawa, Canada.

But based on the MPU-9250 PS documentation (version 1.1 section 9.1) shouldn't Az be negative, and the largest magnetic component be -Mx? It's hard to believe the document could be wrong...

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU9250/issues/333#issuecomment-451598038, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qv74WGxy-3O2AZaCfEhexnughfUuks5u_-GSgaJpZM4ZlqsU .

[spargopolis]

Sorry but it's hard to understand if you mean that because Mz is normal to (i.e. at right angles to) Mx, it becomes the largest component in this scenario? If so would this also not apply equally to My, since it is also at right angles to Mx? Thanks.

[kriswiner]

Normal to earth surface. Look at a geophysics textbook if you don;t undertsnad this.

On Fri, Jan 4, 2019 at 3:44 PM spargopolis notifications@github.com wrote:

Sorry but it's hard to understand if you mean that because Mz is normal to (i.e. at right angles to) Mx, it becomes the largest component in this scenario? If so would this also not apply equally to My, since it is also at right angles to Mx? Thanks.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU9250/issues/333#issuecomment-451602328, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qhDSXSuVWpvAygVBIIuLhbOmSivOks5u_-dngaJpZM4ZlqsU .

[spargopolis]

If you are referring to magnetic inclination there would be some vertical (i.e. normal) component at middle latitudes (entirely so at the poles), but mostly the magnetic field would be horizontal. Perhaps the MEMS devices don't respond in the same direction as a compass needle would point.

[kriswiner]

Not inclination, check the USGS or Canadian GS website for an explanation.

On Fri, Jan 4, 2019 at 4:15 PM spargopolis notifications@github.com wrote:

If you are referring to magnetic inclination there would be some vertical (i.e. normal) component at middle latitudes (entirely so at the poles), but mostly the magnetic field would be horizontal. Perhaps the MEMS devices don't respond in the same direction as a compass needle would point.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU9250/issues/333#issuecomment-451607001, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qk6tcZWr9h3BEvk4lJeoYBok1Bv3ks5u_-6EgaJpZM4ZlqsU .

[spargopolis]

OK thanks I will check it out.

Hopefully last questions related to the orientation of the MPU9250. For the following code: MadgwickQuaternionUpdate1(-ax, +ay, +az, gx*pi/180.0f, -gy*pi/180.0f, -gz*pi/180.0f, my, -mx, mz); a) what's the assumed normal/nominal orientation of the chip relative to an aircraft flying straight and level? i.e. is the MPU9250 on the top of the board, with pin1 in the lower right corner, as described above? b) whatever is the orientation for "a", if the same board was normally mounted on the aircraft upside down (i.e. with the MPU-9250 now on the underside of the board), how would this affect the sign and order of the parameters above? If you know of a reference that describes these transformations that would be even better! ...sorry a bit lengthy - I'm just trying to be as clear as possible. Let me know if I can clarify further..

[kriswiner]

This is up to you.

Choose which board orientation will correspond to true North. Which accel axis is pointing in the North direction? East, Down? Then repeat for G and M. Enter the sensor data into the Madgiwck function accordingly, i.e., ANED, GNED, MNED. The when the board is pointed to True North, the quaternions will read 1 0 0 0.

On Sun, Jan 6, 2019 at 8:48 AM spargopolis notifications@github.com wrote:

OK thanks I will check it out.

Hopefully last questions related to the orientation of the MPU9250. For the following code: MadgwickQuaternionUpdate1(-ax, +ay, +az, gxpi/180.0f, -gypi/180.0f, -gz*pi/180.0f, my, -mx, mz); a) what's the assumed normal/nominal orientation of the chip relative to an aircraft flying straight and level? i.e. is the MPU9250 on the top of the board, with pin1 in the lower right corner, as described above? b) whatever is the orientation for "a", if the same board was normally mounted on the aircraft upside down (i.e. with the MPU-9250 now on the underside of the board), how would this affect the sign and order of the parameters above? If you know of a reference that describes these transformations that would be even better! ...sorry a bit lengthy - I'm just trying to be as clear as possible. Let me know if I can clarify further..

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU9250/issues/333#issuecomment-451756091, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qk-KjtkdDWf6DtyD48pEKLKVyidwks5vAijNgaJpZM4ZlqsU .