I have been doing this for a long time, and people oversee the same stuff over and over again. So i got tired of giving the same answers again and again and decided to do something about it. Something that would really help the users not overseeing things, and help them work methodically. Something constructive and easy to use. Something that would reduce trial and error. Something without hidden menus.
So no, i will not give you fish. But i can teach you how to go fishing.
@amilcarlucas
Not very helpful. All steps of your “methodic guide” to step 3 are also done. As you can easily see in the log, all steps and requirements of your methodology (including temperature compensation, notch filter setup and some basic tuning) are also done. (In our case, without the use of your python script system). Vibrations are not perfect, but acceptable (as far I can see.)
@all (perhaps I could ask @xfacta, @dkemxr of someone else to take a brief look at the log file)
The problematic flight should be carried out to collect data for a magfit compensation. We want to test this trust based, as we want to avoid adding more complexity to the system with some kind of additional current measurement just for the backup FC.
The system itself should not have any greater issues, as it flies quite well using a CUAV Nora+ as primary FC. The main differences are, that the Matek as backup system uses a M10 GNSS with magnetometer instead of Nora’s baseline rtk.
My question is, what brought the FC to the DesRoll and DesPitch shortly after loitering without any command input at app. 04:03? To my experiences, if this was a mechanical or desync issue, the DesRoll/DesPitch error should divergent more?
That was helpful. A dud or defective magnetometer seems to be the most likely explanation to me too. This would fit with some strange observations on the workbench.
