Octocopter suddenly switched to stone modus (crash)

[Max]

It's hard to give advice in such cases, especially with someones expensive equipment on the line. It's also very hard to debug such intermittent events. I personally wouldn't feel comfortable flying it "for real" until I identified the problem. While it could be an obscure bug in the firmware, that doesn't seem to be the likeliest possibility at this point. Until you're sure it's the AQ board itself that is the cause, replacing it might be an expensive waste of time. I guess I would do a couple of things if it were me...

1) check the AQ board and all the wiring for poor connections, especially at ground points. I'd check the board itself with a magnifier to make sure all the pins I soldered are really well connected, again especially at the ground plane (which absorbs a lot of heat when soldering).

2) Figure out what is is really going on with the parameters disappearing or whatever. What you're describing should never happen, nor should firmware get corrupted after installation (during, maybe, but not once it's loaded). If that is what is actually happening, then something is very wrong. First step would be to reproduce the issue at least somewhat consistently and work from there to narrow down the cause. BTW a bad ground can also cause comm issues and weird param read/write problems, though there's error checking in the mavlink protocol which should prevent bad data from being actually used.

Are you loading params via BT connection? Do the problems happen when using a wired connection exclusively? You're not flashing fw via BT, are you?

I think it's very unlikely to reproduce the problem just by running the AQ for a long time. You need to "exercise" it somehow, ideally by recreating the conditions which led to the crash. I'd start by recreating the simpler parts, like "flying" it around with your hands, vs. actual powered flight tests. But you may need to reproduce the whole scenario.

-Max

[Trnquill]

[chschmid]

[Trnquill]

[phynix]

Thank you very much for all your responses. This "not feeling comfortable" is the key issue right now for me. I checked the board as suggested, but didnt find anything that might have caused the crash. I did use a good soldering station for the assembly and rechecked it twice, everything is well connected I think. On this board, one recom had to be replaced because of a broken leg, but also this looks ok now. Unfortunately the colleque that did this replacement for me did hit two pins of the MCU. But I "repaired" them under a stereo-microscope with a realy thin tip (they were just bended a little bit, not broken or ripped of from the housing). Then I checked the connection with a multimeter and also made sure that they where not shorted somehow. Should be OK, or not? This was more then ten months ago, and since then it flew for many many hours on different frames without any incident. All the "strange things" happened recently, all with r224.

I mounted the AQ back on the frame, connected everything except the escs and moved every cable, touched the connectors, shaked the frame relatively hard but the AQ didnt care - everything is fine. I tried with both - 3S and 4S. I did not yet reinstall the firmeware!

I changed parameters (PID-values and frame-values), clicked twice on the store-button, tried to change and transmit other parameters before it has finished writing the previous change. But everything works well, the worst thing that happened is that it didn't store the most recent change.

Of course, I always uploaded the firmeware via FTDI (using the flyduino usb-adapter). All the parameter-changes were done via bluetooth, either using the QGC or the Android-App.

As soon as the parts for repairing the frame are in, I will reassamble everything, strap the copter down and let it run for some batteries. Hopefully this will bring some findings. But I dont have much confidence ...

[phynix]

Alright, finaly the copter is mechanically repaired! So I strapped it down savely and let it run at hoover throttle while connected to QGC via bluetooth. Initially, everything seemed to be fine (two batteries 3S), but suddenly the software on the AQ crashed again (on a 4S pack). But this time, it froze while leaving the motors running! It did not respond to the RC any more and the QGC stated "lost connection". I am happy something like that did not happen in-flight ...

I had to unplug the battery. Without any changes, I tried again. But till now I couldn't reproduce the error .

Assumed that this is related to a "badly" flashed firmeware, is there a easy way to erase it completely before reinstallation? Right now, I can't risk flying with this board, of course.

I realy don't know how to interpret this issue...

[phynix]

With 4S the board freezes relatively often. Randomly, but up to several times per battery. Mostly, the motors are still running, but no more responses to RC-signal, no telemetry and no attitude controller. But still a possible flyaway .

[flyrobot]

Hi,

I think this preventive maintenance should be considered especially for expensive Multirotor.

http://www.rcgroups.com/forums/showpost ... nt=1432%22

John

[hogster]

phynix - Interesting findings about the 4S pack causing more crashes than the 3S pack. Perhaps the regulator is operating at its limit? I wonder how many others are flying on 4S and whether they've experienced any similar issues ...

flyrobot - Very valuable link, thanks for sharing that John. It's actually scary how many parts of our multirotors rely on the friction between connectors to stay airborne!

David

[JussiH]

If you can reproduce it while strapped down, pls provide a log file. That will give us a much better idea of what is going on here.

I didnt get a chance to look at the first log you provided, but if you post it again I´ll take a look.