I have two nearly identical copters. Both are running APM:copter on debian Erle-brain on Turbo Ace Matrix-S / Matrix-I frames. They have both flown well in the past. Right now, one of them flies ok and the other is uncontrollable (three hard landings right after takeoff). I have tested various theories, and applied the parameters from the working one to the uncontrollable one.
I have gone through several theories as to what the problem is. My latest theory is that maybe some of the other code running on the Erle-brain (we have code running to operate onboard science instruments) is causing a delayed response to control radio input. Also, we are using the erle-brain branch of ardupilot with a battery monitor fix that I think was suspected of blocking code running and slowing things down?
Anyway, I’m posting the .bin logs from the two latest “hard landings” here in case anyone can find obvious problems that I’m missing. Any ideas appreciated.
Oops, here’s a log from an earlier flight. The story of the attached log is that I meant to do a hover test at a few feet off the ground, but I gave it maybe 5% throttle and it shot up into the sky and I could not control the altitude well so had to bring it down hard. After this flight I thought that maybe the problem was my RC3_Trim value, but I fixed that and then had the other flight in the original post.
In the flight in the original post, I was again hoping to do a small hover, but the copter pitched backwards and flew behind me rapidly and I couldn’t get it under control so brought it down. There was a split second when I thought maybe the pitch was reversed and tried to correct in the opposite direction but that made it worse. Note that I am flying at very high altitude and it’s possible this copter wasn’t perfectly balanced in the pitch axis.
The problem was that I had maxed out the CPU. Onboard I was running ardupilot, mavproxy, and a python code which controls a spectrometer. The mavlink SYS_STATUS.load messages made me think there was plenty of CPU to spare, but I guess SYS_STATUS.load only tells you the percent of CPU usage by the autopilot, not the total usage.
The problems identified by that python script are false positives / not relevant.