yaw slowly go back to one specify value after rotating

[AlexHaijiaZhu]

Hi Kris, First of all, thank you for sharing the code. It helps a lot so far. I met this weird issues, and I tried google it but can't find any answer, I hope you can give me some idea on how to solve this problem.

System setup: OS: windows 10 IIC lib: i2cdevlib Sensor: SparkFun 9DoF Razor IMU M0

After calibrate the magnetometer (http://diydrones.com/profiles/blogs/advanced-hard-and-soft-iron-magnetometer-calibration-for-dummies), every thing look fine, the output is quite stable. However, when I rotate the sensor alone yaw axis, the output value did change, and then slowly go back to the original value.
Attached is the out put: As you can see, the blue line represents yaw, I stopped rotating (marked in red circle in the picture) but the output value is not stable after that.

As for the sensor, I place this side up.

Thanks, Alex

[kriswiner]

Well there are two things assuming you mag and accel are well calibrated.

You need to make sure you pass the madgwick function the sensor data in NED coordinates. So in your case, ax, ay, az, gx, gy, gx, my -mx -mz. I usually also multiply the a-data by -1 but this won't affect the drift.

The other possible problem is the processor speed. What kind of fusion rate are you able to achieve with this AVR pocessor? If you use accel/gyro sample rates of 200 Hz or so, then you will need to run the fusion at > 1 kHz to get reasonable responsiveness.

[AlexHaijiaZhu]

Hi Kris,

Thanks you for your response. I have rewrite my programming completely, and the yaw is working properly. I didn't know what's wrong with my code, but I will figure it out later.

This is a ARM m0 processor and is very powerful compare to atmega series. I can achieve around 450 hz fusion rate.

In you code (MPU9250BasicAHRS.ino), you said:

"With these settings the filter is updating at a ~145 Hz rate using the Madgwick scheme and >200 Hz using the Mahony scheme" and "This filter update rate should be fast enough to maintain accurate platform orientation for stabilization control of a fast-moving robot or quadcopter."

But here you said:

If you use accel/gyro sample rates of 200 Hz or so, then you will need to run the fusion at > 1 kHz to get reasonable responsiveness. Can please explain more about that?

Thanks, Alex

[kriswiner]

You really 5-10x the sample rate for accurate orientation estimation

On Fri, Jun 23, 2017 at 12:17 PM AlexHaijiaZhu notifications@github.com wrote:

Hi Kris,

Thanks you for your response. I have rewrite my programming completely, and the yaw is working properly. I didn't know what's wrong with my code, but I will figure it out later.

This is a ARM m0 processor and is very powerful compare to atmega series. I can achieve around 450 hz fusion rate.

In you code (MPU9250BasicAHRS.ino), you said:

"With these settings the filter is updating at a ~145 Hz rate using the Madgwick scheme and >200 Hz using the Mahony scheme" and "This filter update rate should be fast enough to maintain accurate platform orientation for stabilization control of a fast-moving robot or quadcopter."

But here you said:

If you use accel/gyro sample rates of 200 Hz or so, then you will need to run the fusion at > 1 kHz to get reasonable responsiveness. Can please explain more about that?

Thanks, Alex

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU9250/issues/153#issuecomment-310751041, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1quHwGb32-D-ZkoZdYCWCeO9jtzx2ks5sHA86gaJpZM4OAj8F .

[Patrickyp]

can you attach code you used to fix yaw alex?

[Patrickyp]

HI kRIS,

Is the fusion rate the number that is printing out in debug mode as "rate = 1301.90 hz"? When I turn the magnetometer 90 degrees it takes 3-5 seconds for the serial monitor to get to the correct value is this delay normal for 1300 hz rate?

[kriswiner]

If you are running the sensors at ~200 Hz using the Madgwick algorithm then yes, this seems about normal to me.

On Mon, May 21, 2018 at 4:16 PM, Patrickyp notifications@github.com wrote:

HI kRIS,

Is the fusion rate the number that is printing out in debug mode as "rate = 1301.90 hz"? When I turn the magnetometer 90 degrees it takes 3-5 seconds for the serial monitor to get to the correct value is this delay normal for 1300 hz rate?

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

[PhoenixZh]

Hi Kris,

Thanks you for your response. I have rewrite my programming completely, and the yaw is working properly. I didn't know what's wrong with my code, but I will figure it out later.

This is a ARM m0 processor and is very powerful compare to atmega series. I can achieve around 450 hz fusion rate.

In you code (MPU9250BasicAHRS.ino), you said:

"With these settings the filter is updating at a ~145 Hz rate using the Madgwick scheme and >200 Hz using the Mahony scheme" and "This filter update rate should be fast enough to maintain accurate platform orientation for stabilization control of a fast-moving robot or quadcopter."

But here you said:

If you use accel/gyro sample rates of 200 Hz or so, then you will need to run the fusion at > 1 kHz to get reasonable responsiveness. Can please explain more about that?

Thanks, Alex

hi, I got the same problem now, can you please tell me how you solved your problem?

[droter]

I had the same issue. Went through the Sensor Calibration again here: https://github.com/Razor-AHRS/razor-9dof-ahrs/wiki/Tutorial#sensor-calibration

Make sure you do a good Extended magnetometer calibration also.