Flying 3.5rc solo version
Green Cube 2.1 all stock otherwise
Sunny day light wind
Received a critical low battery alarm on a battery that later showed to have 77% charge
Pushing home hard I centered the sticks from a full pitch forward to throttle all the way down, when I centered sticks close to home solo began to pitch back to slow and then fell to the ground
The battery later flew fine after collecting up the pieces and putting two props back on that appeared to have spun off and were sitting on the ground in pristine condition
It appears the smart battery ceased reporting data while you were flying. Many of the values it reports will go to zero if there is no data. Which I’m sure the GCS (Solex app in this case) saw as holy crap the battery is dead." Blue line is your altitude just to illustrate flight. Yellow line is volts which seems to stop updating but holds the prior value at 15.3 volts. Current and temperature both cease receiving data and go to zero.
This seems benign and should be a boring problem. But then as we see in the video, just as you arrive back at your landing zone, it appears to just turn off!! The motors stop and the logging stops too. Like it just shut off completely in mid flight. Did you notice if the battery’s status lights were on, if the motor pod LEDs were on, etc? I have a theory. It’s a scarey theory though.
So it looks like the battery malfunctioned. It ceased communication. Then it times out and shut off. These batteries turn themselves off when they sense there is no load. Which is why if you turn it on without being connected to anything, it times out and turns off. Clearly it was under load, so it shouldn’t have done this.
I think it is safe to say this is not related to Arducopter, the new battery monitoring stuff, etc. Just a battery malfunction. And thankfullyan exceedingly rare one.
Are you thinking that the lack of data communication caused it to time out and shut off? That shouldn’t be a problem. SMBUS communication isn’t required for the battery to be held awake. All it needs is a load with current flowing. You can unplug the SMBUS completely and it will stay on.
Or are you thinking possibly the way we’re requesting data from the battery scrambled it’s brain and causing it to turn off? What hz are we currently requesting the data at?
Not the most educated here but it seems to me if the FC and software were smart enough to respond to my get your butt home commands then surely there has to be someway for it to know it is still airborne, and not out of power.
Now if this is logic in the battery and as Matt said the battery itself timed out, that might be harder to prevent.
The battery time out makes sense, but Dang!!!
Thanks again for all the hard work!!!
There is no means by which ArduPilot would ever say “I think my battery is low so I’m going to shut down now.” It will continue to function so long as the power is on. So I don’t believe it was ArduPilot / Pixhawk / Companion Computer that shut anything down. Based on the video and the logs, the smart battery malfunctioned, then after the smart battery’s internal time-out timer expired, the smart battery turned itself off. It is sheer luck you were directly over your landing spot when the clock ran out!!
By the way, I had a quick look at the 166.bin log and as Matt has said, it looks like a power failure in flight (luckily at a low altitude) because the logs simply stop. We don’t see the impact in the logs.
Of course, a massive software failure would look the same but this is unlikely.
I think like Matt has said we should just keep an eye out for any repeat events. Also we should improve the smart battery health reporting.