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.
2013-04-17%2019-39%205_Crash80m.log
2013-04-17%2016-14-16_Crash80m.tlog
Replies
I think I had the same problem. I also cut all the 5v leads but after a disarm in flight and the rebuild, I measured the output +ve bus line and found it only reached 3.2v. It must have been just enough stray voltage to keep all the ESC's and output stage alive for 99% of the flights and then splat!
Now I put a bec on both the input and output sides and have not had the same issue.
I just completet my hexa.
I tested telemetry yesterday, I armed the copter (no props, sitting on my bed) and checked smth. when suddenly it disarmed itself.
Is there a timer for when armed, but the throttle is still down?
Or is this a bug, the same criro1999 encounterd?
I went back to 2.9.1 firmware, which is where I was originally having the resets, and I am NOT able to reproduce the problem.
Here's a summery of my testing, all on the test rig:
Firmware 2.9.1:
1) In stabilize mode, 11 minute flights, 2 flights successful.
2) In AltHold mode, 4 flights, all with resets, about 3 minute, 6 minutes, 4 minutes, and 3 minutes into the flight.
Loaded firmware 2.9.1b:
1) In AltHold mode, 11 minute flights, 2 flights successful.
Loaded firmware 2.9.1:
1) In AltHold mode, 11 minute flights 2 flights successful.
It's been a couple of months ( I think ) since I originally put 2.9.1 on and I do not remember if the problems immediately started after the load. I have all of the telemetry logs, so I'll go through them and see if I can piece together when and if.
Thanx to all for looking at this,
Johnny
As part of the firmware upload process it runs a verify to make sure that it's loaded properly so I'm surprised that the cause appears to be corrupted firmware.
You're right that a brown-out looks just like any other sudden death. Most of the time sudden deaths are caused by brown-outs but maybe not in this case.
If the issue withe the VCC voltage is what I think it is, the bug is exposed for all analog reads (including sonar) when you start using any of the analog pins above 10. Basically this means when you start a battery voltage or current sensor like the 3dr power module. I've heard that the bug has been there for a long time but so few people were using the current modules before they became standard equipment with the APM2.5+ that we recognise the cause.
You sure get marks for persistence..sorry i couldn't be of more help...i've had my head down trying to get the next version ready to ship.
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.
voltage.JPG
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++
Troubleshoot on!
-=Doug
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.
Telemetry.zip
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.
http://diydrones.com/forum/topics/hexicopter-rolls-90-degrees-and-d...
I was sure the Vcc was not the reason quad did fall out the sky. It is just an graph interpretation.
But looking again to log file, I did find next variable "time_boot_ms" which make me believe the APM was reset (reboot) in-air.
If you look at the graph below you notice how this variable is rebooting.
When I did compare this variable with a regular flight, without crash, I did notice always this graph was an ascending curve, never descending. I did look to at least 10 logs different logs and never see this variable descending ("rebooting").
Please correct me if I am wrong.
Well now, this just goes to show you that your grandmothers were correct when they told you 'every little bit counts'... (sorry folks, it was just hanging there...)
So, with the Vcc mystery solved, our friend still has a problem of his aircraft falling out of the sky. Once he gets us a good Vcc plot (or tlog), we can proceed.
Mucho Gracias to Bill Bonney and Tridge for bringing this information.
Criro1999 - load up the code and try again!
-=Doug
-
1
-
2
of 2 Next