I had a brief failsafe the other day while in FPV and managed to survive it.
I’m flying Pixhawk on a DiscoveryPro with the APM power module, and EzUHF-JR module on a Taranis. After looking at my logs, it certainly appears that I had a classic Throttle FS (set to AlwaysLand). I toggled my FM to recover, but in looking at the logs, I saw something I’ve not yet seen (but I’m new to APM):
Flying in Stabilize, at about 800 feet away at 60 feet AGL, I got this sequence:
I do not have Battery failsafe enabled, and both my main battery and Vcc were stable during the event (it does not appear to be a brownout). I’m not sure why I got a BATT FS. I would have expected to have, maybe, one of the RADIO_X messages first if this were a throttle FS.
Can somebody crack open my log and help me understand exactly what happened, and why the sequence listed above occured?
I am doing some further tests of why I might have had a radio failsafe, but am trying to better understand what the Pixhawk’s version of the story is.
I’d really appreciate some input on this – I’ve seen a lot of very new answered requests for help with analysis but nobody seems to want to touch this topic. I’m not a mooch, I try to figure this out myself when I can, and I help answer others questions, too.
I’m specifically trying to figure out the battery failsafe question, that’s the vexing part.
Hi Brit. Getting an answer to questions around here can be somewhat…frustrating at times, but hang in there. Embedding pictures of naked women in your post may help.
Your throttle failsafe is pretty straightforward and I think you’ve got a handle on that one. The battery one is a bit strange. Your voltage was set to 14.0 with a 4,000 mAh capacity. You didn’t exceed the capacity at the time of the failsafe reporting but you had been below the 14.0 volts for a little while. I would have expected the battery failsafe to be reported as soon as you went below 14 volts.
It is my understanding (but I’m not certain) that if you have failsafes disabled they will still be reported in the log (??), they just won’t be acted upon by the flight controller. Perhaps someone more knowlegable than I can chime in on that. If it’s the case, than you just got a strangely late report and your FC wasn’t doing anything about it. It was, however, responding to your radio failsafe.
Thanks – I appreciate you having a look. Yes, it is strange, because you will see in the second post a second log with the same parms and voltage dropping below 14.0 for a long time, and no battery failsafe at all. I’m just trying to make sense of it, and to turn this into a learning experience.
I should add, too, that I take failsafe events very, very seriously, because they are a very real way that the innocent public can become involved in a nasty problem. I bench test, then test more, and more, until I really understand all the possible situations, and I practice them as a pilot. This kind of glitch really freaks me out, because it has no apparent cause, and this is alarming to me, after trying to ensure that my quad is as safe as possible, and that I am a skilled pilot that can manage these situations.
I only turn on automatic failsafe actions one by one, only if needed and only once I fully understand how they might be triggered (which is one reason my batt failsafe is off). IMHO, we should never rely on failsafes as a substitute for paying attention to your aircraft (like altitude, distance from home, battery voltages, RSSI, LQ), and I feel that theideal flight control system should alert the pilot about the situation and let him/her decide whether or not to activate the failsafe before it happens automatically. But the AC code is really really good, and when used with a well-built aircraft and an alert pilot, it is hard to beat.
I gotta get to the bottom of the battery failsafe issue – it’s just too unsafe to ignore it.
The battery must remain below the failsafe voltage for 10 seconds before the failsafe is triggered. If there is even measurement noise bringing it back up, it won’t trigger.
If you have a calibrated current sensor, I wouldn’t even bother with voltage failsafe.
jschall – thanks for your reply – maybe you could help with a follow up question?
I don’t have battery failsafe enabled, so why would it trigger? And why did it not trigger at all in the second log where it was below 14 for a long time?
I am really trying to not offend anybody with these repeated requests, but think this topic deserves a closer look and I’d really like to understand this phantom battery failsafe situation that I experienced.
To recap: I got a battery failsafe “error” while not having battery failsafe enabled. You can confirm this in the PARMS section of my log. AND, a day before, with the same config, I hit the same voltage that supposedly caused my batt failsafe (that was not enabled) and it didn’t generate an error.
Can somebody please dig a bit deeper into these two logs I’ve supplied and help me better understand what happened, and how I might avoid it in the future?
[quote=“jschall”]The battery must remain below the failsafe voltage for 10 seconds before the failsafe is triggered. If there is even measurement noise bringing it back up, it won’t trigger.
If you have a calibrated current sensor, I wouldn’t even bother with voltage failsafe.[/quote]
This might explain why every once in a while my Bat FS doesn’t trigger… I do have it fairly close to the knee, so when it goes, it goes fast. I bumped it up a bit.
[quote=“OtherHand”]Hi Brit. Getting an answer to questions around here can be somewhat…frustrating at
It is my understanding (but I’m not certain) that if you have failsafes disabled they will still be reported in the log (??), they just won’t be acted upon by the flight controller. Perhaps someone more knowlegable than I can chime in on that. If it’s the case, than you just got a strangely late report and your FC wasn’t doing anything about it. It was, however, responding to your radio failsafe.[/quote]
Basically it would be a matter of confirming this then.
If you could power your radio separately, (I put mine on a regulator run off the 2S tap of a balance connector), and then bench test going below 14 for long enough to assure that it triggers or not. Bench testing with light load might help assure that there is no noise to restart the trigger timer. Don’t know if it’s neccesary to have altitude for a FS to trigger.
I’m not sure I undersand the logic of your proposed test – I’m running the 3DR power module for my Pixhawk which passes through the voltage to the receiver, and this voltage fluctuates very little per the logs. I still have my batt failsafe value set at 14.0, and have flown it many times since then, and almost all flights end up well below this value, and I’ve had zero Battery Failsafe errors or messages in my logs since then.
Indeed, if someody could confirm whether or not those errors should appear with respect to having ThrFS enabled or not, that itself would be a great help.
By me providing back-to-back flight logs, one with the error, the other without, and no changes to my config, I’m hoping that there is some sort of explanation, or if not, an interest or concern about why this hapened, as unintended battery failsafes could have catastrophic results. I’m surprised that this hasn’t picked up more interest, but am hoping that somebody will check into it at some point.
Your battery failsafe occurred after 10 seconds of voltage below 14v. See figure 1 (you can even count the ticks, they’re at 1hz. It is normal for the error to occur even if no action occurs. The PIXHAWK’s tonealarm should go off as well (at least, it does on git master).
Your radio failsafe caused your copter to enter LAND. You are not logging RCIN, however CTUN.ThrIn goes to zero.
Please check that your THR_FS_VALUE is set per the instructions, with at least 10 units of margin away from your radio’s output when failsafing, and at least 10 units of margin away from RC3_MIN. It is really important that it not be set to a borderline value, as that could cause the copter to disarm in the air.
