Quadcopter, APM2.5, Arducopter 2.9.1b.
During an Auto flight mode (with hovering on a fix position), it crashs down uncontrolable from 80m altitude. I did repeat this mission many times before, never such problem.
When I look at log/tlog files(atatched), I noticed at the middle of the Auto mission, at 80m, it "Disarmed" for no reason.The log files shows altitude stop at 80m, throttle stops at medium value.
It looks for me APM2.5 was reset in middle of the flight. Could someone confirm this?
Battery was at 64%, no errors in log file.
What could be the reason for this? It scares me a lot.
PLEASE, I need to find why happened.
Add my issues to the list that are similar to this discussion. I've heard the ground station say 'disarmed' after the drop began and didn't think anything of it at the time.
I've been able replicate the problem while having a video camera watching it in close range. You can see the LEDs go out with the motors continuing their last command for a few seconds before they shut down.
In the video, it shuts down at 0:47.
This seems to occur for me while in AltHold, it will fail within 3 to 8 minutes. I've completed multiple 10-12 minute flights with it only in Stabilize with not issues.
That looks like a classic brownout. Are you powering using the APM Power Module? And what equipment do you have connected and how? And where is that 1/2 or 1 Watt LED plugged in?
I'm using an APM power module with the JP1 removed. The ESC have their +5 voltage output cut so that they are not going to the APM. The LEDs are connected via transistors so that they are not drawing power directly from the APM. I have the 3DR telemetry and the uBlox GPS connected with no other hardware connected (other than the LEDs).
This hasn't been happening in stabilize doing the same type of flights. If it was a problem with to much draw from the LEDs, then it would happen doing all flight modes. It couldn't be motor draw as using 4S so I would never go below about 13 volts from the batteries and the logs show never going below 14.5 at the lowest. Also, as you can hear, the motors didn't reduce their rpm at the instance of reset.
I'll see if I can replicate it without the LEDs just to be sure. It definitely won't hurt, since I have that contraption. :)
wow... really scary...
did you do any TX control after LED go out? It looks LEDs starts again themselvs, can you confirm?
"with no other hardware connected (other than the LEDs)."
also not minimOSD connected, correct?
Once the LEDs went out, I set the transmitter down immediately. I actually forgot to turn AltHold off, but thought about it after the APM came back up and I set it back to Stabilize after that, so probably at least 15 seconds after the APM reset.
I did nothing on my side to reset or restart the APM, so they started back up on their own.
Nice testing rig BlackNova and a great way to demonstrate the failure.
In fact, you could probably get away with some small coaxial cable and clip leads connected to Vcc and run to a DVM (recording DVM would be nice) for external confirmation of the voltage. This would eliminate the issue of trusting a good Vcc recording.
Again, super way to prove the problem, save props, and save the aircraft. A++
Actually, I have a PC oscilloscope that I could use. Let me see if I can do that.
Removing the external LEDs from the APM had no effect; it still reset during AltHold.
I also attached an oscilloscope to the +5V and ground rails of the input connections. It never deviated from the attached screenshot. The software doesn't really have a way to record constantly. Not sure if the input rails are the best location to detect deviations in voltage, but they are the easiest to get to without pulling everything apart. If there's a better location, let me know and I'll try to attach the oscilloscope there.