Thanks! Well in the end, a complementary filter is a 'stationary' Kalman filter, meaning that the steady state of the Kalman filter (here 0.005) will be similar to the value you will choose for your complementary filter. So I guess you should get similar results for both.

I also recommend the Madgwick Quaternion update filter :)

Good idea, didn't hear of this type of filter before, definitely worth trying

Did you do that sir? , please give code if you did​@carbonaeronautics

It will be lighter, but for a linear system with Gaussian errors only, the Kalman filter is an optimal solution. You might think of it as a Madgwick filer where the value of "alpha" is determined dynamically rather than being fixed.

you cannot compute the yaw angle with aid of the accelerometer. Therefore, we assume 0 for the yaw angle.

Thanks! I think you are correct, didn't try it but it sounds logical to put it in the setup part and only call it once. Still room for improvement!

have you tried this? i am working on my drone and am always happy to get inprovements haha

How much of that temperature range is applicable?

The iteration length in the while loop. If you see there is a line while(micros()-loop_timer

If its for a drone the results will be similar for both!

@@carbonaeronautics thanks sir for confirmation

This is probably because your hardware is not able to perform the calculations fast enough. The code given uses 4ms as the loop time, and the hardware used (teensy) is fast enough to handle this. And also the IMU output datarate has to fast enough too otherwise the code will endup waiting a long for the data. This will all affect the output. As a probable solution, first find out the time its currently taking for one iteration to complete. And then adjust the code with this new Time Ts. Things should be more responsive now

Only the roll and pitch angles are of interest for an angle mode flight controller, because for the yaw direction you generally do not want to return to the initial position, hence rotation rate control in this direction is sufficient

I was also interested in this. I believe this implementation will not work in banked turns based on a test I just ran. I put the unit level in my car, and then drove in a moderate speed turn in a parking lot. The output (serial monitor) showed a 20 degree change in roll. [No my car doesn't sway that much] Similarly on moderate braking, it showed a 20 degree pitch change. Looking at the code, the unreliability of the 6250's gyros is the root problem (I think). We have the 4 * 4 expression [KalmanUncertainty=KalmanUncertainty + 0.004 * 0.004 * 4 * 4;] that is basically saying that the standard deviation error of the gyro is 4 degrees PER SECOND. Then as the gyro estimate diverges from the accelerometer estimate we apply accelerometer corrections. If a turn lasts 1 minute, we are saying the gyro data could be off 4*60 = 240 degrees (on average)! Without some other way of correcting (like knowing speed and rate of turn, thus can calc centripetal force) we need a gyro sensor that is about 20x more trustworthy. I am using a MPU9250, which is better. I'm going to try reducing the 4 to 2 since the MPU9250 is about 2x better and re-test. Still expect it to be unuseable, but will be interesting to see if the change does what I think it will. Note - I'm a complete NOOB in this area, I may be wrong! See video at 1:54

You'd use a magnetometer for yaw, which would give you constant accurate results regardless if acceleration.

@@marcelloziglioli8954 oh I see thank you so much

The problem is that the accelerometer cannot tell you the yaw angle. So you could integrate the gyro values, but would not have anything to compare them with -- unless you use an additional sensor such as a magnetometer.

Do you mean pullups for the i2C? Are those even really necessary? I've used MPUs before, and I don't have any problem not using those pullups. Have you had problems without those?

Hi, I agree with your opinion

It depends. If you have reliable and low-latency information on the speed of the plane and can assume windspeed to be negligible, then just using orientation data from a gyro can give you a reasonably faithful estimate of the trajectory. That being said, should you not have good airspeed data, you probably need accelerometer data to get a trajectory estimate

I'm using an MPU-9250 with the code, and it seems to work fine on the bench for me. I believe the 9250 is code compatible with the 6050 --- just some of the tolerances are different when I compare the data sheets.

What a coincidence . I also thinking to do it for RP pico w 🌚

Great to hear it works on the Pi Pico as well!

@@P0K0 great , if you need i could provide the full code

@@pykid1915 Thanks man, for your kind words ! but i would rather code it myself ... If i ran into any problems I'll surely ask .

@@P0K0 🤗

That's what brought me here too!

please help me!!!!

I just fix it

how can i stack multiple layers of kalman