Quad fallling out of air with 3.1

I believe this began with 3.1 upgrade, but cant swear…have had the quad (F-450) have all motors suddenly disarm shortly after lifting off in stabilize…this has happened several times at 1 foot hover, but today it happened right after switching to AUTO on the ground and lifting off with TAKEOFF command and fell 10 feet crashing the quad…all motors stopped suddenly as it was climbing…RC throttle was about 50%…

attached are two dataflash logs(I wasnt running MP this time) …one with a short liftoff to low hover with immediate disarming occuring unexpectedly…the next the crash during autotakeoff (which I’ve sucessfully done many times before)…

if its a 3.1 problem, I’ll gladly go back to 3.01! but as a newbie I need some help

I have spent some time analyzing the logs myself…the autotakeoff log is worthless since it ends for some reason before the quad falls out of the air…just shows it going into AUTO, throttle up, climbing…then stops abruptly…

the low hover one is more telling…CTUN throttle in and out are fairly constant from line 800 where the quad lifts off in stabilize mode…to around line 990 where it falls out of the sky (plot BaroAlt)…and I eventually lower the throttle after its on the ground…since THRout is active, the motors should be also…but they all quit at the same time…either power to the ESCs was interrupted or the logs are lying about what ACTUALLY is being fed to the motors…since the APM is powered by an ESC, if power was interrupted (like battery continuity was intermittant) then the APM would have not recorded the fall…it did, so the logs arent showing the actual outputs to the ESCs…(guess I should have had MOTOR logging enabled, but that still wouldnt tell me why it died)

at this point, I can see it die, but cant tell why

Great that you looked at the logs yourself as a first step, very much appreciated.

It looks like a mechanical failure of some sort. I’d guess the batteries don’t have a high enough “C” to provide the required power to the motors. The reason I think this is the barometer altitude falls even though the output to the motors stays high. So although you can’t see the individual output to the motors, you can see the average output to the motors in the CTUN message’s ThrOut field…this value stays high even while the copter is falling.

You’re right that it’s not caused by a brownout because the logs don’t just stop, they show the fall to the ground which means the flight controller was alive and well the whole time.

[quote=“rmackay9”]Great that you looked at the logs yourself as a first step, very much appreciated.

It looks like a mechanical failure of some sort. I’d guess the batteries don’t have a high enough “C” to provide the required power to the motors. The reason I think this is the barometer altitude falls even though the output to the motors stays high. So although you can’t see the individual output to the motors, you can see the average output to the motors in the CTUN message’s ThrOut field…this value stays high even while the copter is falling.

You’re right that it’s not caused by a brownout because the logs don’t just stop, they show the fall to the ground which means the flight controller was alive and well the whole time.[/quote]

the motors didnt sag like it was a battery “c” issue…they instantly and totally stopped,like the copter dis-armed in the air…its definitely not a battery voltage issue…these are high capacity (4s, 5000mah)…and I check their effective output impedance with the charger regularly to watch for aging cells…I use them on my other quads with Naza controllers and they are healthy and strong…
this is what is worrying me…I cant find a logical explanation making me not trust the APM…will revert to 3.01 after I repair the copter tomorrow and see if the issue dissappears…

Double checked…Plotted voltage (I have this monitored from my own voltage divider into the APM) from the CURR log entries…never gets low…just a minor drop as it throttles up…

A disarm even will appear in the logs as EV 11 which I didn’t see in the logs. Here are some other common events. This list also appears on this wiki page: copter.ardupilot.com/wiki/downlo … on-planner.
10 = Armed
11 = Disarmed
15 = Auto Armed (pilot has raised throttle above zero and autopilot is free to take control of throttle)
16 = TakeOff
18 = Land Complete
25 = Set Home (home location coordinates have been capture)

It’s pretty unlikely to be a firmware bug I think. The copter is in stabilize the whole time which is a relatively simple flight mode. We have so many people flying and copters suddenly falling out of the air gets attention! It’s much more likely to be a power issue of some sort.

I repaired the copter(one broken arm, broken prop, some bent pins on the APM, dead BT module) and flew a battery pack arming and disarming and hovering around with 3.0.1…then moved back up to 3.1 doing the same thing and flew a pack hovering around my cul-de-sac…no motor dropout issues, except that alt hold is much less precise than before…so I’ll mark this one up to gremlins…

re Alt hold, I checked the vibs thinking that something there had to have changed affecting alt hold, but am well within the x/y and z recommendations…I might be just more “observant” than before…getting 1-2m slow (5s periods) changes…tried raising Thr_Alt_P and lowering Thr_Rate_P terms…but defaults were best…deviations about the same but chasing was the least frantic with defaults…

seemed like I was getting NAZA like alt hold precision before…ie 1m or less…oh well :unamused:

thanks for trying to help me figure this out…guess I’ll mark it up to unexplained…

Sorry I can’t be of more help. I don’t think we’ve changed anything re the altitude hold (except for when you use sonar) between AC3.1 and AC3.0.1.

Maybe vibrations have changed due to the crash and repair? Or were you flying without a cover whereas previously you had? I’d look at the physical stuff.

going to mark this as solved, but feel free to post another thread if it happens again :slight_smile:
Phil