Unstable and slowly changing output data in madgwick filter

[pioradys]

Hello,

we are trying to use madgwick filter in our autonomous sailing boat project. We encountered a problem with output data from madgwick filter. Values of orientation are changing slowly. When we flip our IMU by 90 deegres it takes to 20 seconds to react to such changes. We are aware that changes like these will not happen in real environment but we are concerned anyway. Is it intended or can we somehow improve it? The other thing is that the values are very unstable as we checked and they can differ with about 10 deegrees when the imu is standind still. Is it also normal or our configuration has some mistakes?

[mintar]

Values of orientation are changing slowly. When we flip our IMU by 90 deegres it takes to 20 seconds to react to such changes. We are aware that changes like these will not happen in real environment but we are concerned anyway.

So, these are synthetic values, not values from the real IMU, right? Meaning when you "flip" the IMU, that flip will not be visible in the gyro data, but only the accelerometer/magnetometer data? In that case, it's expected that the filter only converges slowly, because it (simplified) uses the gyro data for short-term corrections and the accelerometer/magnetometer data for long-term corrections.

The other thing is that the values are very unstable as we checked and they can differ with about 10 deegrees when the imu is standind still. Is it also normal or our configuration has some mistakes?

By "very unstable", you mean the orientation has a lot of noise?

By the difference of 10 degrees, you mean a constant offset of 10 degrees to true magnetic north?

If you provide a rosbag of your IMU data, I'll try to look into it.

[lucaslins0035]

I am having the same problem with a real industrial-grade IMU. I am using the Madgwick filter to fuse gyro/acc + mag to get an earth-referenced orientation. The orientation values I get are good, but the filter is converging slowly (a settling time of ~2.0 seconds). Adjusting the gain parameter did not seem to make any difference. My application is an outdoor UGV with relatively slow dynamics, so I was not expecting any trouble with this filter.

The blue curve above is the output of the robot_localization orientation without fusing the Madgwick output, only my raw imu data (not earth-referenced), and the red curve is the output of the Madgwick (earth-referenced). As you can see, there is a delay between them. Is it possible to speed up the filter convergence? Does fusing magnetometer data somehow slow it down?

[JakubKaminski99]

Hi, we have recorded two rosbags, one (BasicFreq.bag) with our default frequency and second (HigherFreq.bag) with the 5 times higher frequency. During the data collection of HigherFreq we had intervals of 10 second (20 for BasicFreq) between every position change in order listed below (we were moving the IMU in the real life):

• default (flat on the surface)
• pitch 90 degrees
• default
• roll 90 degrees
• default
• yaw 90 degrees Increasing the frequency made changes of pitch, roll and yaw more dynamic.

By "very unstable", you mean the orientation has a lot of noise?

By the difference of 10 degrees, you mean a constant offset of 10 degrees to true magnetic north?

We meant that during stable position of IMU values are oscilating up to 10 degrees (e.g. 80 to 90).

Additionally we have a topic called /realData that is used by us for debugging but also as a values that will be used further in the system. There are values presented as raw pitch yaw.

Bagfiles.zip