The history of this is a bit of a story so I will attempt to be concise. Facts first, then my thoughts. Thanks in advance for reading it all!
The flight files and parameter file are available here: Forum Files.zip - Google Drive
Firmware: customized 4.4.2. None of the custom features should affect this, or ever have
Platform: quad copter
Battery: 4s Li-Ion (I verified as reliable to 12V, manufacturer recommended landing voltage is 11V)
FC: Cube orange
GPS/Magnetometer: Here3+, Here3+ compass is primary, cube compass is backup
Roll: RCIN.C1
Pitch: RCIN.C2
Throttle: RCIN.C3
Yaw: RCIN.C4
CG location: 4% behind geometric center of motors (6mm behind center of 310mm airframe, front to back)
All flights were similar. The failures soon to be discussed occurred during the same basic maneuver: drone oriented away from me, hard pitch back until near top speed, hard pitch forward to stop the drone quickly. This was also attempted in roll, but pitch is more sensitive to this problem.
The problem: at the end of the maneuver, the drone enters an oscillation and can’t maintain altitude, resulting in a crash.
Flights exhibiting the problem are FN1 and FN3. I view these files with plot.ardupilot.org, and the time stamps are minutes since log start. FN1’s crash sequence is from 13:18 to 13:24. FN3’s crash sequence is from 9:10 to 9:14.6. FN1 had the compass calibrated using mission planner. FN3 ran COMPASS_LEARN for about the first ~30 seconds of the flight, and it completed with no obvious problems. Both flights generated compass variances first, then an EKF lane switch (per notifications on my hand held controller). Viewing the logs in mission planner to see the errors indicates that FN1 had a THRUST_LOSS_CHECK moments before impact. FN3 had no errors before impact.
What I mean by compass variance and EKF lane switches (at bottom): Advanced Compass Setup — Copter documentation
I then did FN4 to get a clean flight with yaw CW and CCW, and worked roll and pitch independently. I used FN4 to do a magfit with MAVExplorer.
FN5 was performed after FN4, with the magfit applied and improved Here3+ cable routing. FN5 did not generate an EKF lane switch but did generate a single compass variance under a similar maneuver.
I have observed no performance issues if only compass variance occurs. The compass variance errors appear only on my hand held controller, and not in the flight logs when viewed with mission planner.
All flights had the same PID parameters.
I have 2 specific questions:
- why did my drone enter oscillations in FN1 and FN3?
- how can I know it’s actually fixed after making the changes in FN5? I have done more flights since then with no issue but is there a non-statistical argument for the problem being fixed?
My thoughts:
- PID issue? I could see the rapid pitching, high thrust, and potentially turbulence interacting to cause a control issue. I do sometimes hear slight oscillations when doing this maneuver, even if it doesn’t result in “the problem”. I previously lowered PID gains to make it steady under every other flight condition.
- The magfit made it substantially harder to generate the compass variance errors, and has (so far) prevented EKF lane switches. This seems to indicate it was a mag issue, but how to I verify this for certain?
- I don’t think the EKF lane switches occurred because of vibration, because my vibe values are generally low.
- Some value is compared to EK3_ERR_THRESH, and if it is greater than it switches to the lane with least error. I can’t find what this number is, or if it is recorded. It would make sense if it was XKF3.ErSc, but XKF3.Rerr is supposed to be related and it makes no sense in FN1 and FN3. If it is XKF3.ErSc, then it muddies the water because it remains below EK3_ERR_THRESH until after the drone hits the ground. This makes me suspect that I did hear/see a lane switch, but it actually happened after the crash (I’m watching the drone during the crash sequence, then check the controller for errors after). Is an answer hiding in the EKF_AFFINITY that I can’t find much documentation on? What if I disable the cube’s compass, which performs a lot worse than the here3+ compass?
EKF3 Affinity and Lane Switching — Dev documentation
Bonus question:
3. What are the exact conditions for a compass variance error to be given? I can’t find it. It doesn’t cause issues on its own, but has always been a precursor to EKF lane switches. I’ve been fighting this problem long enough that I’m pretty scared of compass variances.
Many thanks!