Hi all,

I need some help interpreting the attached log file.

Scenario :

I was flying my Arducopter Y-6, (What a machine, by the way!)
APM 2.6


Stock hardware, no mods or changes.

5300mah 3S Lipo

Took off, flew around for about 30 secs, hit LOITER at about 3m Height. Held perfectly.
Throttled up, climb out to about 30 meteres, still in LOITER.

Hang around at this altitide for around 2 minutes, slowly yawing left and right to get some nice camera shots.

SUDDENLY, no power, ALL the motors stop, and the copter falls to the ground tumbling from about 20 meters up. During the fall I changed to STABILISE, and applied full throttle, nothing.

Amazingly only damage is one broken prop, this is one tough bird!

Now I have tried to decipher the logs. I have checked the following graphs:

VOLTS - battery was 12.4 at full , dropped quite quickly, but never below 11V

Satts - 7 satellites all the time, HDOP 1.8VCC - 5.0 to 5.5 V all the time, so no brownout on the APM

the only funny I can see is the graph of Throttle in vs throttle out, As the motors quit, the throttle out goes haywire, but no indication WHY.

I think perhaps I just dont know where to look..

Any Ideas? Any help will be greatly appreciated.


Views: 4531


Reply to This

Replies to This Discussion

OOPs Sorry Forgot the graph that looked strange to me, especially around the Crash time just after 5500

what happened here? there was a reply from Pieter , now its Gone!

Pieter, did you delete your reply?

Have you tried mapping the zacc and sonar ? i have had some falls and often its a sonar spike.

No, The IMU logging was unfortunately not switched on, and im not using a sonar.
Will test vibrations on the accelerometers today and post the results, but It held loiter fine on the preceding flights so I dont think Vibrations were a big problem.

It looks like a mechanical failure.  I'd say the ESCs overheated or perhaps they hit their low voltage cut-off (maybe it's set too high?).  The reason I say this is that even before you switched to stabilize mode the autopilot gunned the throttle as it noticed it was falling but this did not slow it's descent.  We can also see you switching to stabilize and gunning the throttle but the copter continues to come down.  I can't imagine what that could realistically be besides the battery, power distribution board or ESC failing to provide power to the motors.

Randy, Thank you for taking a look.

You are confirming my suspicions about the Hardware Failure.

I will check the ESCs cutoff, they are the Stock Maytech ones as supplied by 3DR, unchanged programming, but will take a peek.

I suspect a dry joint at either the PDB or a bad "Deans" plug.

Again my Gratitude for all the suggestions and log analisys.
Will let everone know once I get to the bottom of this.

So to hear about your crash. Can feel with you. Luckily you just lost a prop. My copter was a total disaster.

Just a side question:

I can't get the APM2.5 to log the data you guys analyze all the time. The one crash I had produced no usable logs at all.

They were all there, but not showing any graphs.

What does that mean? Are the logs there, but no data?

Have you followed THESE instructions to the letter?

Now that I have learned what to look for I am happy to pay it forward by helping you interpret what you are seeing, let me know.

oh, no. Just flashed 3.0.1 and flew. No settings.

Thanks for the link.

Yea guys I can feel for the developers, I am guilty of this too sometimes. When you get to the part of the manual where you put the props on, DO NOT JUST GO AND FLY!!

There is MUCH more of the manuals and instructions to read, like compassmot cals, Declination, magfield checks, tuning, and Log analisys. DO THESE CHECKS!

More steps in the GCS to stop people just flying are needed me thinks. Don't let the thing arm until they have followed some instructions.

Then on a more portable GCS a checklist that stops you flying until you tick the boxes..

Unfortunately pushing this back to the human process is never the best solution. Adding more steps just adds more sources of failure.

If there was an automated startup QoS check on ESC's that might be better, and beep/alert message if that fails (eg: "Motor Output 3 timings outwith tolerances").

How that is achieved, I have no idea,  but it's a far more reliable way than relying on the human as the catchall.

Reply to Discussion


© 2020   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service