I’m not sure exactly what you’re asking… But the 2nd flight I took off and it was leaning right for a few seconds… That’s how I have it ‘balanced’ at the moment… W/ too much right right trim. Because when the issue develops it pulls left.
So, I took off, it was pulling right and I was compensating by rolling left. Then it began to tilt left as usual, and I am then compensating by giving it right roll input. I was hovering in one spot the entire time… So all the stick movement is me compensating for the lean.
The time when it begins to pull left is the time IPN in the graph above crosses over zero. I’m not home anymore to look at my logs and am not sure when GPS began working on that flight… But, that is my typical flight… It pulls right for a second due to the way I have it trimmed, then begins going left.
On my other copters, it’s a balance, so when the lean issue develops, my already present right trim cancels out the lean.
On this copter, it’s often leaning too badly for the trim to cancel it.
Hi, probably my experience is not relevant to you but I could confirm you I feel I had a similar problem last year and with the same FCs it was happening now this issue is not happening anymore. In my case was a combination of 2 causes, the first was a bug on the old static notch filter that was not working correctly, in particular in conjunction with a different loop rate (in my case 800 - 1200) and I think @andyp1per found this and resolve it. The second as you mentioned was related to the heavy load on the FC. I’m using a pixracer and with a custom indoor onboard localization system assisted by a single IMU (only 1 EKF) even using the EKF3 have some small effect on the “perfect and consistent level” compared to a better level I could have switching to EKF2 that has a smaller load on the F4.
I’ve had a long chat to @Leonardthall about this. What I had failed to realise is that the notion of “level” is entirely driven by the EKF. So yes bad IMU data will put you out of whack, but so will bad GPS data and bad MAG data etc. So in your indoor flight I think it’s much more to do with the GPS and MAG than it is the sensors, although if you look at NKF1.GX you will also see a big jump in the calculated gyro bias.
So to figure this out properly - and I’m not saying there isn’t a problem, just that there is a lot more subtlety to this that we had thought in a “manual” mode - is to first re-enable all your pre-arm checks and hover in a field with a good GPS lock and MAG calibration. i.e. make sure you can arm in PosHold before you takeoff in stabilize. We can then have a look at that log and see what’s up.
As a side note, if you are going to fly in stab without GPS or mag you should really switch both of these sensors off, as the random data you get from them at different times is definitiely going to affect level.
Finally I suspect there are some EKF settings we can use to more aggresively reject bad GPS and MAG data - but I don’t know what those are as yet.
OK thanks. I think I know which settings tell it how much to trust the data from specific sensors… EK2_GYRO_P_NSE, and similar settings for GPS, Accel, Mag. I tried telling it to trust the gyro LESS when I was hovering inside, but now it’s sounding like perhaps I should tell it to trust it more… I have been only focusing on the gyro, but it’s good to know other sensors will have an effect. Although makes it a bit more difficult to figure out…
It does help explain why the several of us who have posted about the problem have all come up w/ different solutions :).
This sounds very reasonable. It could be the expected behavior even in stabilize.
The ekf estimators performance is based on the fused data from a given set of sensors. If the ekf is attempting to fuse erroneous sensor data, its weighting will be small due to the large innovations (because it is capable of calculating these significant inconsistencies i.e quantify them), thereby disabling auto modes. However, as an example, the GPS may report both a decent number of satellites and quite low hdop due to multipathing etc. The ekf is then attempting to use this data (and similar data)
I have never experienced this drift behavior, but I typically assure that the ekf has a gps fix, even if I do start in acro (I usually land in loiter). I have been flying in conditions of very low temperatures also, without temperature compensation. I’m amazed by the versatility of the software.
When hovering indoors, things usually work fine, but then hdop is 99.99, so ekf will discard gps anyway (should note that I have not looked in detail at the ekf-implementation, except maybe the Matlab version, so my reasoning here should be reviewed/corrected).
As @andyp1per is saying, a test by disabling gps should be tested (AHRS_GPS_USE = 0).
I also noticed (if i remember correctly) from one of your logs that it took a very long time before you got a decent number of gps satellites. Maybe your GPS on your new build has more magnetic interference than your others?
This particular build is using a relatively old (first gen) runcam split, and those are known to cause GPS interference. And yes, this copter takes longer than others to get GPS signal. Then on top of that, some of these logs are me flying indoors which makes the signal even worse.
I guess all of my microcopters are right on the edge of working properly, maybe all for different reasons. And I still think there might be something about differences in the IMU’s… There have been a couple instances where no changes other than replacing the FC fixed it. Of course the act of replacing the FC means resoldering and remounting everything, which could affect the vibrations it’s picking up… which is why I’m not confident making any definite claims about this.
Anyway, I appreciate everyone’s help. I’ll continue posting logs if I think it might be anything interesting… At some point I’ll do the GPS disabled test, and the ideal flight location w/ plenty of satellites test and let you know how it does.
I know a few people have recently started builds w/ these FC’s on small copters, so if anyone else notices any leaning, please post.