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.
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.
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 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
Just to add some info on the Vcc log spikes, I just completed a flight test with all onboard logging turned off and it made no difference to the Vcc spikes.
Hyperhex 2.9.1b log off 2013-04-23 at 9.20.06 AM.png
Criro1999,
Do you have a GCS, ground control station OR and telemetry radios connected/enable in this setup?
I was looking over the playback of the log, not graphing, and noticed the Vcc value stayed at zero most of the time with some extreme value jumps -- just like the graph shows. More to the point was the % of GCS signal.
-=Doug
This also brings out the question: Where is the Vcc sampled on APM2.x ?
The 3DR Power Module only supplies +5VDC, Gnd(Return,Earth) to the APM distribution for needed power (also depending on JP1 connection); battery voltage and current analog signal that ends up on Pins 84, 85 of the 2560 processor (ADC12/13).
There are many more ADC connections not clearly indicated on the APM schematic.
Perhaps one of the APM hardware devs will chime in here? Regardless I think I will look over the prints more and perhaps sniff around the code.
-=Doug
Interesting how reading about one problem can help with ones own issues.
I have trying to track down a compass problem (drifting up to 90deg in 30sec) without luck and reading here the Vcc anomalies it occurred to me I had never looked at Vcc, and low and behold what do I find, exact duplicates of 0-5 spiked trace. I don't see how this would affect compass and I kind of suspect it is a log problem more than hardware problem, but it does mean I have to pull the thing apart and check every joint just in case. SO I would be most unimpressed with it just being software problems.
APM2.5 powered by 3DR power module, uBEC on output (was switch mode, now linear), no jumper, AC2.9.1 (& b).
Tomorrow I may try going back to 2.8.1 and see if the Vcc trace (and compass drift) are the same.
I had another thought on this...
Did you perform the calibration procedure for using the 3DR power module?
HERE is the link.
If the value stored calibration box is incorrect, that could skew the logging information.
Just a thought.
-=Doug
-
1
-
2
of 2 Next