Spectacular Crashes due to RTL

Hi All,

Let me put up the questions and some analysis 1st, then explain what happened.

1st issue is that my RTL_ALT_FINAL is set to zero and therefore the quad should land in my understanding, but it does not. RTL kicks in due to battery failsafe, raises the altitude as expected, returns to home but does not come down. Does not respond to throttle, crashes when battery dies.
2nd issue is that on failsafe screen I have set Battery reserve capacity to 250mAh and not I cannot set that to Zero anymore. This is a problem because battery FS is kicking in based on estimated used battery capacity and due to inaccurate current measurement, this kicks in too early. Would like to disable this by setting capacity to zero, but cannot go down, only up. Also, there is no -write parameters- button on failsafe screen ?

And here is the story.
Yesterday, take off in stabilize mode, switch to Alt.Hold and initiate Autotune. About 5 minutes later, Battery FS kicks the quad to RTL, raises to set return altitude, returns and does not land. 5 minutes is about half of the expected flight time and I therefore suspect FS was initiated because of reserve mAh. This is why I want to set it to zero. Rest is my fumbling, when it did not come down I switched flightmodes but had already throttled down in attempt to get it come down and throttle up did not save it (no juice ?) .
Today, takeoff and hover on top of arming point (Pos.Hold most of the time), maybe 1m high just to see endurance of battery. Batt_FS kicks in, drone shoots up and does not come down, crashes when battery dies. Did not try any flightmode changes this time, throttle only

Log of these both attached and also pic of RTL parameter settings

Any ideas ?

and the logs seem to be too large,
avail in in here
and here

I checked your *27-16.bin
you start at 12.54v , so it’s a 3S.
fs is trigged at 3,13v /cell, that’s very low , when it’s falling down , you are at 8v4 , (2.8v/cell) - about to damage battery.

You have to know the actual capacity if the battery if you want to trigger fs by capacity - also if it’s the second flight, or it’s not fully charged . you cannot use 100% if a battery’s capacity anyway (as the internal resistance makes the final capacity useless for flight)
So this is for people with full control, or smart battery.

you should trigger battery failsafe by voltage, if you trigged it at at ~9,9v , you would still have good 30 seconds to land.

Good advice.
on 1st flight trigger was set to 10.0 V
for the second flight (what you checked) I went to 9.7 V on purpose as I was only hovering about 1m high

The initial questions why it did not land on its own
and why I cannot set reserve mAh to zero
are still up in the air :grinning:

To disable the battery capacity failsafe, you can go into the full parameter list and search for BATT_CAPACITY and FS_BATT_MAH. Set both of these parameters to 0.

The FS_BATT_MAH is the same parameter as the reserve mAH that you can’t set to 0. MP tries to prevent accidentally setting bad values for certain parameters when using the tuning pages, so maybe it considers 0 mAH to be invalid or unsafe. These parameters can always be set to any value by using the full parameter list or tree, though.

If I get time, I’ll take a look at the log and see if I can tell why it didn’t land.

I looked at the logs. It didn’t land on its own because the battery died before it could. The battery died just as it was beginning to descend after waiting the normal 5 seconds in both flights. It never stayed hovering for more than 5 seconds before starting to land. Everything worked as normal and as expected.

That battery or batteries are probably ruined due to being run flat. I wouldn’t use them for flight anymore. You will need to be much more careful with the battery parameters, setting them to a more appropriate higher level.

The initial questions why it did not land on its own

RTL_LOIT_TIME is 5sec, and it loitered for 5 seconds with stable desired altitude before started to
descend (see red line)

and why I cannot set reserve mAh to zero

That’s strange, probably because of child-proofed MissionPlanner methodology (with bugs).
Use APMPlanner2 , Qgroundcontrol or MAVproxy , and set FS_BATT_MAH = 0

Set FS_BATT_MAH to 0 in the full parameter list and write it.

Thanks everyone,
good advices, I’ll definitely bump up the failsafe voltage,
change reserved mAh to zero directly from parameter tree
and reduce RTL loiter time.

For the sake of my education one question though.
If I understand this right, cone slope being set to 3 (=default)
would mean every one meter off from home position would introduce 3 meter climb until cone or final altitude is reached, whichever occurs first, right ?

Reason I’m asking is that I would have expected to be within cone when I was very close to home and maybe 1m high.
If I was not, quad should have reached the cone fairly quickly once ascend started, yet it went all the way up to Final altitude ?

RTL cone slope value is vertical height of inverted cone versus 1meter width from center.
For a wider cone , so the craft wont climb so much, use a lower value like 2. Check you RTL minimum climb value too.
This diagram from the linked thread helps: