iNAV draining Battery to her death after crash

[StuweFPV]

Current Behavior:
Would not call this a bug - maybe just my lack of understanding but after having had a few crashes somewhere up in the trees it took quite some time to recover the plane. Whilst in most cases the battery was still connected and disarming was possible in all cases iNAV just drained the battery to her death. Most recovered batteries had a cell Voltage of 1-1.5V making them useless to fly again. As there was no physical damage to the batteries it seems like a waste of batteries every time i crash.
Is there a way of telling iNAV to shut down at a certain Voltage level? I would love to control this on a software level rather then fitting a lipo protector into every plane.

Steps to Reproduce

1. plug in a battery
2. let it sit until there is no light on the FC anymore
3. measure the battery voltage
4. recycle battery

Expected behavior

iNAV to shut down the FC in order to preserve battery life for as long as possible without additional hardware

Suggested solution(s)

Set a low voltage limit in iNAV configurator whereby iNAV shuts down or goes at least in some sort of sleep mode where battery consumption is minimal by disabling any output/consumers, lower cpu frequency, disabling any internal sensors, etc. in order to preserve battery life as long as possible

Additional context

I'm not sure if iNAV is capable to shut down an FC completely without any extra hardware in order to truly save the battery. but disabling any outputs/consumers and putting the FC into a sleep mode (i.e. Raspberry, Arduinos can do) could/should minimize the consumption to a few mA in order to buy me 1-2 days for recovery instead of 1-2 hours.

---

• FC Board name and vendor: Matek F405-Wing / Matek F722-Wing
• INAV version string: 2.5.1

[issue-label-bot[bot]]

Issue-Label Bot is automatically applying the label BUG to this issue, with a confidence of 0.83. Please mark this comment with 👍 or 👎 to give our bot feedback!

Links: app homepage, dashboard and code for this bot.

[Jetrell]

@stuwe911 Such a function would be useful with FC's like the F722_Wing, that have Vsw power control (USER1/USER2).
Although most other FC boards do not have that hardware ability. So the battery will be drained more excessively by the VTX and Camera, than by the flight controller.

[StuweFPV]

@Jetrell thanks for your comment. i agree, VTX and cam are surely the biggest drainers but it could also be a stuck servo or maybe a gimbal if used. hence my "request" to switch off all consumers that are attached to the FC. I see the point of this being strongly hardware related. maybe a soft-switch that could turn the battery off - if iNAV would have such a function?
I've noticed on other FC's like Vector or PitLab that they do have a "crash detector" that takes care of this issue. I had planes with iNAV crashing and then they tried to do RTH hanging in a tree (good thing i limited the max throttle to 1700) otherwise everything would've been toast. I understand the challenge of a open system vs. a proprietary so a big challenge for iNAV. but having no solution at all, almost guaranteed to loose your battery and maybe even ESC and motor makes a crash way more expensive then just replacing the foam around the electronic.
Do i miss a trick, setting, something other people use that i don't have or don't know?

[Jetrell]

I've noticed on other FC's like Vector or PitLab that they do have a "crash detector" that takes care of this issue. I had planes with iNAV crashing and then they tried to do RTH hanging in a tree (good thing i limited the max throttle to 1700) otherwise everything would've been toast.

There has been many threads asking for a similar function. #2331
Especially for motor shut down in a FS condition when we have lost radio link and the model has crashed. Under this situation the motor will keep spinning because iNav wants to bring the model home.
Some peoples planes have been set on fire by the ESC when the motor was near stalled for a long period.

[StuweFPV]

yeah even i have put in such a request approx. 2 years ago but to my knowledge nothing has happened on that issue. shame as this is for safety and not a feature. I don't fully understand the priority how iNAV is being developed - looks like by popularity and thumbs-up. on one side understandable but safety should also be a count even if not popular...
thanks for your feedback

[grizewald]

I really can't imagine anything happening with your request either.

The only way that iNav could power down your craft is if it was equipped with a latching relay or similar switch and the flight controller was provided with some way to actuate that switch.

The biggest problem with this kind of arrangement is that to be able to handle the current drawn by a multirotor craft, the relay would need to be able to easily carry the maximum current demanded without getting hot or causing a significant drop in voltage. Such a beefy relay will not be light, therefore adding unwanted extra weight to the build. It also adds another point of failure. If the relay fails in flight, an unpowered crash is inevitable. Even if a MOSFET was used instead of a relay, MOSFETs that can handle hundreds of amps of DC current are rare, large and expensive and cannot implement a latching behaviour like a relay can.

Craft which implement the feature where a VTX can be turned on and off via a channel do so by turning off the voltage regulator which generates the supply voltage for the VTX and not by interrupting the power being supplied to the VTX. The voltage regulator chip has a specific pin to enable or disable the regulator's output. This arrangement removes the issue of needing something which can interrupt the power to the VTX.

The other problem with the flight controller being able to cut all power to the craft is that it's not necessarily a good idea. In many cases, the only way you can even find a downed craft is if there is still power to the VTX or RX so that the signals from these devices can be used to home in on where the quad has crashed. Turning off everything makes that impossible.

So, the obstacle here isn't software or a lack of interest, but the fact that something which can switch hundreds of amps is far from simple, light or cheap and that the functionality you want may be diametrically opposed to what other people want.

The better solution is to avoid situations where a mistake will put you up in a tree or dump your craft somewhere it will be hard to retrieve it from. The fact that batteries cost money and that you kill a battery each time is the hobby's way of punishing you for allowing the crash to happen in the first place!

[shellixyz]

With 2.6 you can set nav_overrides_motor_stop to OFF_ALWAYS and if you have the throttle at zero before it failsafes it won't start the motor