I had to reproduce this a couple of times to believe it.
AC 3.6.10, new install, just finished test flights and tuning.
Time to clean it up so I went in and opened the download logs window in MP, latest beta, and selected clear all logs.
After clicking the confirmation and closing the log download window the gyros went crazy.
Here is a video I took which will be easier than trying to explain it.
Previously to this the AH did jump about when it happened then slowly settle.
I just didn’t catch that in this video.
I had left the copter alone for 5 to 10 minutes but the Bad AHRS message persisted.
If there is any particular parameters or information needed please ask.
The copter is flying very well by the way.
Pixhawk1 (3DR)
AC3.6.10 fresh install
It’s been happening with our custom autopilot from a long time. Whenever I try downloading or try to check logs, the HUD goes crazy with all errors popping up. Disabling log_disarmed helped us. It doesn’t happen often.
I have had this issue since ever. Since the first time…as soon as i confirm to download a log this weird behaving happens without any exception. Direct after reboot everything is finen again. It was the same on every copter version since AC 3.5.5
I thought of mp issues switched between stable and beta…no diffrence.
It would be interessting to know if this happens only when downloading logs over usb or over mavlink too.
In my case its when downloading over usb.
It feels like it depends on probably a higher data transfer rate when dowloading big log files.
By the way, my copter flies great too.
Downloading/deleting log is a CPU and bandwidth intensive task, and easily can add delays to sensor polling which confuses the EKF. This is the exact reason why downloading logs during flight is not allowed.
Just reset your controller after download logs and you are ready to go (you can do it from MissionPlanner (CTRL-F -> and select reboot pixhawk.)
Since you cannot download log while vehicle is armed, this is not a real issue. If you want to fly right after a log download without a reset, then arming checks will stop arming until EKF settle down.
And if somebody disables arming checks then he/she deserves to crash
I think it is not so much the "clearing a log file sends the EKF crazy” as a thing, it is, to me, that this indicates the EKF can be sent crazy by a computational intensive, or specific task.
Which begs the question, how close to this edge is the EKF running in normal time?
I would not have thought that log manipulation was such a problem for the architecture.
Is the EKF this delicate?
How is the EKF upset by this task, and can this be plugged to make the EKF more robust?
nobody deserves to crash, it could happen following a workbench tests where normally you cannot arm without gps… and forgetting to re-enable checks. Could happen to the best of us.
Just my two cents
