I flew a new quad (loaded 3.4.1) today and experienced some scary behavior. Twice while airborne the quad started moving erratically. I heard something from mission planner about the EKF, but couldn’t make it out. Both times I was in loiter and it seem to only last for a few seconds. Also, on two occasion as I was in hover near the ground (less than 1 m) the quad started drifting uncomfortably back and forth.
I’ve taken a look at the logs but really don’t know what to look at to determine the problem. I see there was an error but I don’t know what caused the error.
If anyone has sometime, I would appreciate a look at the linked BIN file and some insight into what is happening.
After looking at the logs, I noticed several errors which I suspect is what triggered the aberrant behavior. I had no less than 40 subsys 24, ECode 1 errors. This is related to the EKF not liking the yaw value.
After reviewing several threads and replies from Leonard Hall and Randy McKay (thanks guys), I surmised (perhaps incorrectly) Yaw PID values were the root of the problem. For this flight ACT_RAT_YAW_P was 1.635792, ACT_RAT_YAW_I was 0.1635792 and ACT_RAT_YAW_D was 0. And the ACT_RAT_YAW_FILT was 1.7.
I reset the YAW PID values .2, 02, 1 and set the filter at 2. And calibrated the compass and accelerators.
After that, I gingerly took off, hovered for 30 seconds, climbed and did a control check. Satisfied it wasn’t going to fall out of the sky, I did a complete autotune and saved the following PID values: 1.5858, 0.15858 and 0.00. Not a huge difference.
I flew the drone several times with the new PID values and didn’t notice any uncommanded behavior at altitude or near the ground. With the small change in PID values, I am not 100% confident the problem is resolved. The “events” were intermittent and just because I didn’t observe any strange behavior, doesn’t mean the problem is fixed. Also, I noticed the yaw PID values led to some oscillations around the vertical axis, which makes me think the PIDs aren’t quite right yet.
Love to get another set of eyes on the log file to help ascertain the problem. And if anyone has suggested changes to the yaw PID values that will reduce the oscillations, I’d be grateful.
Thanks for the report. So it seems that the EKF “lane” is switching back and forth. In AC3.4.1 (and higher) we have two EKFs running simultaneously and we pick the one that appears most healthy. In this case it seems to be switching back and forth very rapidly (see red markers Err:24 at the top of the graph). I’ve asked Paul Riseborough if he could have a peek to see why this is happening.
Dave, on more than one occasion in your log, the GPs experiences a large glitch, that on one occasion triggered a lane switch. Here is the reported speed accuracy from the receiver:
Innovations for other sensors for the first IMU are low. The second IMU is being affected by vibration and does not make a good backup unit - see poor height innovations:
I would focus the investigation on what is interfering with your GPS as that was the reason for the unsteadiness in position. I would also either improve the vibration isolation or consider disabling use of the second IMU by setting EK2_IMU_MASK = 1 and INS_USE_2 = 0. This will also prevent any lane switching.
I wil look at the switch logic to see if can be made to reduce switching due to large GPS glitches without sacrificing response time to IMU errors.
Thanks for the great review. I looked at logs from my very first flight with this drone. The vibrations looked fine and the other metrics above look excellent.
A few things changed between the two flights: I flashed the latest software, PID values changed from photo A (manufacturer set) to photo B as a result of an autotune. There is a huge difference in the PID valve with the different software loads. And now for the big disclaimer; I crashed the drone. Looks like the only damage was to the props but this log file makes me think there may have been more damage beyond what I can see.
