15 | Combine a gyroscope and accelerometer to measure angles - precisely 

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.

Is Madgwick the same as an alpha/beta filter?

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 :)

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

That's what brought me here too!

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 🤗

How much of that temperature range is applicable?

@@isaacclark9825 Well, a 1 degree per second drift from the start up zero rate strikes me as causing a lot of control problems. [In 30 seconds, that's a 30 degree drift]. Based on the spec, that would happen with a 6 degree C change in temperature. Pull the quad out of a warm car, start up, and fly on a cool day could easily exceed 6C.

@@bryanlaplante8258 The entire idea of the Kalman filter is to deal with exactly that problem. The gyro has significant drift, but not much high-frequency noise. Since its output is a rate of change, rather than a specific angle, its output is going to be integrated, which is a low pass filter, so the output has some useful info. By contrast, the accelerometer has lots of high-frequency noise, but it measures angles directly. The accelerometer has essentially no drift. Sensor fusion is used to get a great result from two sensors with complementary strengths and weaknesses. You can get gyros with smaller drift but you will have to pay for that.

If you are going to assume common gain, you would use a complementary filter. The code would be much simpler and a less powerful processor could be used. The complementary filter is the most commonly used approach for flight controllers. It would be interesting to compare the performance of a drone using each approach. My hypothesis is that any differences in performance would be very subtle, but that the Kalman approach is superior if the computing resources are sufficient. On the other hand, using aTeensy is a bit more expensive than solutions than using a less capable Cortex-M4 processor, which is what almost everyone else does.

True. The system described here makes the assumption that the acceleration of the quadcopter is negligible so that the accelerometer measurements translate to pitch and roll. If the airplane is in free fall, the no acceleration assumption is bad, and the system does not work well.

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

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.

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

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

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

please help me!!!!

I just fix it

how can i stack multiple layers of kalman

Hi, I agree with your opinion

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?

That is not surprising. The processor on a Teensy 4.0 is nearly 100 times more powerful than the processor on that R3.

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

@@dsdy1205 Absent a compass or gps, you simply cannot get reliable heading data from a gyro and accelerometer alone.

@@isaacclark9825 I mean, that very much depends on how good your gyro and accelerometer are. Clearly it's possible else inertial navigation systems would never work, but it does demand a certain ceiling of noise in your sensors.

True. INS systems that are capable of high accuracy do not rely on inertial measurement systems the size of computer chips and with costs under 20 dollars. They use a completely different technology and are closer to the size of a small refrigerator. I believe those used on missile submarines back in the 50's used gyros only, so there was no sensor fusion. Sensor fusion requires a correcting source of heading information to overcome the limitations of the drifty grro information that comes with tiny, solid-state gyros. IMU Accelerometers do not provide heading information. But adding a magnetometer can help, but those things have their own issues. Adding GPS helps even more.

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.

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