A few questions for Understanding

[afnan]

Hi, Thank you for giving us such great code to ease our lives. I have a few questions for MPU9250 i hope you can help me make my concept clear using NodeMCU 160 MHz

1. Why is rate and processor speed critical other than battery usage? and filter update rate?
2. In your code https://github.com/kriswiner/MPU9250/blob/master/MPU9250_MS5637_AHRS_t3.ino how do you calculate values for following and how to use them? `/*#define X_FINE_GAIN 0x03 // [7:0] fine gain

   define Y_FINE_GAIN 0x04

   define Z_FINE_GAIN 0x05

   define XA_OFFSET_H 0x06 // User-defined trim values for accelerometer

   define XA_OFFSET_L_TC 0x07

   define YA_OFFSET_H 0x08

   define YA_OFFSET_L_TC 0x09

   define ZA_OFFSET_H 0x0A

   define ZA_OFFSET_L_TC 0x0B */`

3. I want to implement a button which resets the sensor on which ever angle it is and start from zero. Just like tare button in weighing machines. Would following logic work or is there anything better than this?

GET CURRENT VALUES OF YAW,PITCH,ROLL IF VALUES < 0 ADD TO FUTURE VALUES ELSE SUBTRACT FROM FUTURE VALUES

[kriswiner]

If you are performing fusion on the host, then host processor speed is clearly an issue. You should be working at >1 kHz fusion rates to get anything sensible.

The accel offset hols the offset biases that you calculate during the accel calibration. I don;t use them because of the temperature compensation bit, which has given me unstable results.

I wouldn;t worry about fine gain or anything else.

The yaw, pitch, and roll from a well-calibrated MPU9250 is absolute wrt true North and the floor. You can always add angles to these to get whatever result you want.

On Tue, Aug 22, 2017 at 5:48 PM, afnan notifications@github.com wrote:

Hi, Thank you for giving us such great code to ease our lives. I have a few questions for MPU9250 i hope you can help me make my concept clear using NodeMCU 160 MHz

1. Why is rate and processor speed critical other than battery usage?
2. In your code https://github.com/kriswiner/ MPU9250/blob/master/MPU9250_MS5637_AHRS_t3.ino https://github.com/kriswiner/MPU9250/blob/master/MPU9250_MS5637_AHRS_t3.ino how do you calculate values for following and how to use them? /*#define X_FINE_GAIN 0x03 // [7:0] fine gain #define Y_FINE_GAIN 0x04

   define Z_FINE_GAIN 0x05 #define XA_OFFSET_H 0x06 // User-defined trim

   values for accelerometer #define XA_OFFSET_L_TC 0x07 #define YA_OFFSET_H 0x08 #define YA_OFFSET_L_TC 0x09 #define ZA_OFFSET_H 0x0A #define ZA_OFFSET_L_TC 0x0B */

3. I want to implement a button which resets the sensor on which ever angle it is and start from zero. Just like tare button in weighing machines. Would following logic work or is there anything better than this?

GET CURRENT VALUES OF YAW,PITCH,ROLL IF VALUES < 0 ADD TO FUTURE VALUES ELSE SUBTRACT FROM FUTURE VALUES

— 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/178, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qii644CqnLUKF0yJB8NdpmugrCXxks5sa3bxgaJpZM4O_Wuo .

[TediumRemedy]

Hi Kris, Regarding

If you are performing fusion on the host, then host processor speed is clearly an issue. You should be working at >1 kHz fusion rates to get anything sensible.

Just to add to your answer - I am running at 500 Hz on STM32, and seems like I am getting decent values (provided the mag is calibrated) after a few seconds of MCU start (while the fusion algorithm is settling in), because I am using synchronous I2C reads/writes (not interrupts or DMA) and the loop speed is limited by the I2C bus speed.

I want to implement a button which resets the sensor on which ever angle it is and start from zero. Just like tare button in weighing machines. Would following logic work or is there anything better than this?

You mean you want to reset the Yaw/Pitch and Roll values and have the sensor fusion algorithm start from scratch, or completely reset the MPU9260? If the former, just write initial values (1,0,0,0) into the quaternion? If the latter, send the reset command to the MPU and re-initialize it.

[kriswiner]

I woukd strongly recommend using interrupts for data ready where possible.

I am getting 50 kHz fusion rates using an STM32L4. Are you using an F103 or something? Also, I noticed if one uses pi = 3.14159f instead of the built-in Arduino PI definition the fusion rates speed up by a factor of 10 or so. Still don;t know why!

On Fri, Aug 25, 2017 at 12:53 AM, TediumRemedy notifications@github.com wrote:

Hi Kris, Regarding

If you are performing fusion on the host, then host processor speed is clearly an issue. You should be working at >1 kHz fusion rates to get anything sensible.

Just to add to your answer - I am running at 500 Hz on STM32, and seems like I am getting decent values (provided the mag is calibrated) after a few seconds of MCU start (while the fusion algorithm is settling in), because I am using synchronous I2C reads/writes (not interrupts or DMA) and the loop speed is limited by the I2C bus speed.

I want to implement a button which resets the sensor on which ever angle it is and start from zero. Just like tare button in weighing machines. Would following logic work or is there anything better than this?

You mean you want to reset the Yaw/Pitch and Roll values and have the sensor fusion algorithm start from scratch, or completely reset the MPU9260? If the former, just write initial values (1,0,0,0) into the quaternion? If the latter, send the reset command to the MPU and re-initialize it.

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

[TediumRemedy]

I woukd strongly recommend using interrupts for data ready where possible.

I am getting 50 kHz fusion rates using an STM32L4. Are you using an F103 or something? Also, I noticed if one uses pi = 3.14159f instead of the built-in Arduino PI definition the fusion rates speed up by a factor of 10 or so. Still don;t know why!

@kriswiner Yes, exactly, I am using F103. I moved the I2C operations to interrupts-based, but only managed to get to 1500 iterations per second. In addition, the Madgwick algorithm takes about a minute to "stabilize" its yaw now (but once a minute passes, it's pretty accurate in all three axes). It just slowly "drifts" from 0 so its actual value with every iteration during this minute. The mag is hard-iron calibrated, but perhaps I need to calibrate accelerometer or the gyro, not sure.

F103 has its clock frequency set to 72MHz, and I suspect there are so few iterations (comparing to your STM32L4) because of the slow HAL library I am using (seemingly it adds a lot of overhead, as opposed to if I was working with bare metal registers for I2C). Or it could be due to inefficient floating point operations in the Madgwick filter itself (F103 doesn't have an FPU. But so does the Arduino).

I am getting 50 kHz fusion rates using an STM32L4.

Do you happen to be using HAL for I2c on STM32L4 as well, or some other library?

Also, I noticed if one uses pi = 3.14159f instead of the built-in Arduino PI definition the fusion rates speed up by a factor of 10 or so. Still don;t know why!

So, if you put 3.1415926535897932384626433832795 (this is what PI is defined is in Wiring.h) instead of 3.14159f, it will speed up (or M_PI, which is 3.141592653589793238462643)? Weird

[kriswiner]

I am using a custom Arduino core for the L4 so not ST HAL.

The pi think has to do with some AVR wierdness, don't understand it but it has a dramatic effect on the L4.

If one defines a float as 3.159 but doesn;t put the f at the end the compiler has to do some things to convert it, and I think without the f instruction to the compiler to treat it as a native float there must be some conversion to 32-bit integer and then back to float. Not sure, but it is something like this.

Yes, the F103 is going to be very pokey; 72 MHz isn;t really a fair representation of the actual compute speed. The L4 is orders of magnitude faster.

On Tue, Sep 5, 2017 at 11:27 AM, TediumRemedy notifications@github.com wrote:

I woukd strongly recommend using interrupts for data ready where possible.

I am getting 50 kHz fusion rates using an STM32L4. Are you using an F103 or something? Also, I noticed if one uses pi = 3.14159f instead of the built-in Arduino PI definition the fusion rates speed up by a factor of 10 or so. Still don;t know why!

@kriswiner https://github.com/kriswiner Yes, exactly, I am using F103. I moved the I2C operations to interrupts-based, but only managed to get to 1500 iterations per second. In addition, the Madgwick algorithm takes about a minute to "stabilize" its yaw now (but once a minute passes, it's pretty accurate in all three axes). It just slowly "drifts" from 0 so its actual value with every iteration during this minute. The mag is hard-iron calibrated, but perhaps I need to calibrate accelerometer or the gyro, not sure.

F103 has its clock frequency set to 72MHz, and I suspect there are so few iterations (comparing to your STM32L4) because of the slow HAL library I am using (seemingly it adds a lot of overhead, as opposed to if I was working with bare metal registers for I2C). Or it could be due to inefficient floating point operations in the Madgwick filter itself (F103 doesn't have an FPU. But so does the Arduino).

I am getting 50 kHz fusion rates using an STM32L4.

Do you happen to be using HAL for I2c on STM32L4 as well, or some other library?

Also, I noticed if one uses pi = 3.14159f instead of the built-in Arduino PI definition the fusion rates speed up by a factor of 10 or so. Still don;t know why!

So, if you put 3.1415926535897932384626433832795 (this is what PI is defined is in Wiring.h) instead of 3.14159f, it will speed up (or M_PI, which is 3.141592653589793238462643)? Weird

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU9250/issues/178#issuecomment-327262178, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qm7wq0S2diwBMXThD6JLDtAZGodUks5sfZJ_gaJpZM4O_Wuo .

[TediumRemedy]

I am using a custom Arduino core for the L4 so not ST HAL.

But the original code is supposed to work on a regular Arduino as well? Or just Teensy v3 (which as I understand have the same characteristics as my F103)? If yes, how much time does Madgwick algorithm take to converge?

Update: I multiplied beta parameter by 4, and now Madgwick filter converges in about 10 seconds on my F103, as opposed to a minute before.

If one defines a float as 3.159 but doesn;t put the f at the end the compiler has to do some things to convert it, and I think without the f instruction to the compiler to treat it as a native float there must be some conversion to 32-bit integer and then back to float. Not sure, but it is something like this.

There should be some compiler key to resolve the "issue". At least ARM does have a lot of those that instruct the compiler to use/not use the FPU, to set the float type to be default one (so you don't have to type annoying f in the end of fractional numbers), and so on.

Update: I applied these compiler keys, as well as replaced all "doubles" with "floats" and now I am getting 1750 iterations per second (as opposed to 1500), still Madgwick algorithm being the most time-consuming part in each iteration.

[kriswiner]

This has more to do with defines in Arduino.h. No need to use them with an ARN Cortex M4F. In most cases, using the defines is benign. In this case using the PI define costs performance. It's just that simple. Using pi = 3.14159f, replacing the Arduino.h PI define solves theproblem. As to why, I don;t know and don;t really care.

On Thu, Sep 7, 2017 at 12:09 AM, TediumRemedy notifications@github.com wrote:

I am using a custom Arduino core for the L4 so not ST HAL.

But the original code is supposed to work on a regular Arduino as well? Or just Teensy v3 (which as I understand have the same characteristics as my F103)? If yes, how much time does Madgwick algorithm take to converge?

If one defines a float as 3.159 but doesn;t put the f at the end the compiler has to do some things to convert it, and I think without the f instruction to the compiler to treat it as a native float there must be some conversion to 32-bit integer and then back to float. Not sure, but it is something like this.

There should be some compiler key to resolve the "issue". At least ARM does have a lot of those that instruct the compiler to use/not use the FPU, to set the float type to be default one (so you don't have to type annoying f in the end of fractional numbers), and so on.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU9250/issues/178#issuecomment-327708375, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qnGwH89zJZbNid0Kcwyd9g4d6745ks5sf5apgaJpZM4O_Wuo .