Octocopter suddenly switched to stone modus (crash)

[phynix]

Hey everybody!

I just had another crash... Unlike the ones before, this time I cant say for sure that the user was the bug . While moderade cruising around (well it was more like hovering, training slow, smooth camera movements), my octocopter suddenly just dropped. Without a warning, no flipping, just like a stone. It seemed like all the motors stopped at the same time (but i cant say for sure). When I arrived at the scene, the Gimbal was still working, so probably no fatal loss of Voltage in the main power distribution. The power-cable to the AQ seems to be fine, too.

The log file does not provide me with any substantial information concerning this crash: It just stops in mid flight. No drop in Voltage_in, no signs of errors in the radio signal. Neither the tumbling on his way done nor the impact is captured from one of the sensors. This leads me to the conclusion that the AQ just stopped working in mid flight.

This copter flew perfect for many lipos, the AQ-board even flew on two differend frames before without this kind of problems (otherwise I would not have put him ont the big octo )

Now I have replugged the power, and all the electronics are working just fine, including the AQ. But obviously I cant trust it right now...

I realy have no clue what could have happened. Anyone has an idea? What can I do to investigate this issue? I love the AQ as the flight caracteristic of the octo is just amazing - but ...

Soeren

[kinderkram]

Sorry for your loss, Soeren!

Please post the log file, maybe some of our experts can have a look at it.
btw: in what mode were you flying - PH?

[joebar.rc]

If all electronics did still work, but the AQ did shut down it was probably the hard fault event.
In case of a software crash inside the FW, the very last thing before 'hang' it will do is shut down all the motors to prevent runaways.
That kind of problems can be very hard to track, maybe if the log shows stacks ..

[hogster]

Not good to hear as I'm planning to put my AQ on a big octocopter What version of firmware are you running?

Hopefully we can find the root cause of this and make sure it doesn't happen again.

Cheers, David

[phynix]

Sry, I forgot to add the details about the setup:

Octocopter, 2500g take-off-weight
ultraEsc 20A
Firmeware: r224
No DIMU, no CAN
Flyduino BT-Module directly connected to Android (no MavToHott at that point)
Graupner SUMD
All power-wires twisted, seperated from signal wires by a CFK-Centerplate

Some more things, maybe someone discovers something;
- at that point, I flew in manual mode
- that was only the third flight with 4S, before that I always used 3S - but the copter flew very good with 3S and 4S.
- Sometimes I had the Problem that the AQ "forgot" major parts of his parameters. I had to re-transfere all of them via QGC at least twice. That always happened while PID tunig, so I thought that this is a transfer-problem and not directly related to the flight controller. It might have happened that I clicked on the "safe to rom" button before it was done storing te things from the previous cklick (unpatient)...
- I remember that today another thing happened that I never had before: directly after arming and rising the throttle a little bit, the motors started running but the only command that the AQ accepted from that point on was rising the throttle. I was not able to stop the motors or disarm the Copter via RC any more! I had to reset the AQ, then everything was fine again. But, I changed a motor port in the frame setting and probably did not reboot the AQ afterwards - so I thought that was the reason. RC-Signal was fine.
- Everything realy seems to be fine again. The AQ behaves normal when moving and wathing the Telemetrie. Motors are arming and running as supposed. but obvously, I did not try a lift off ....
- There is no log-file newer than the one that ends in mid-air. So it realy looks like it is not a disruption in the voltage for the AQ, am I right?


The log can be found here: https://depot.uni-konstanz.de/cgi-bin/e ... mv5nfd49u4

[kinderkram]

Hmmm, there's nothing looking suspicious to me, radio is clean.
It still could be an electrical like bad solder joints or a problem on the board. Could be a bad MCU but that's hard to tell.

You shouldn't take her in the air unless the source of the problem is solved. Can you do a dry log with a full battery and see if it behaves ok? Just let it run until be lipo warning goes off.

If it's a heat problem then you might be able to reproduce the failure...

Sorry I can't tell you on the spot what's going on.

[phynix]

I checked the cable to the AQ board as that was my first suspicion, too. But it looks OK, I moved it with the AQ powered, touched the plug... no interruption. I disambled everything, looking for shorts or loose connections in the power distributions. Couldnt find anything.

I thought about carefully hoovering max 1 m above ground or so for 2 Lipos and see whats happening. But I can also just let it sit somewhere. Or strap it down and let it run, but that will probably just cause a runaway in the UKF. I do (almost) everything that might help. I need to get it back into the air safely as soon as possible - and I don't want to switch to a different FC because I hardly needed a gimbal for filming with this setup *lol*. But as mentioned: it has to be safe...

Probably I have to push my plans to set up a redundant system with a (non-AQ) backup FC... another big gain would be the possibility to safely test every experimental build with the AQ .

[r0sewhite]

If you edit parameters, only the changed parameters will be written, not the whole set. In my eyes it points to a software related problem if parameters are missing after writing to ROM. I have experienced this once with a fw version that someone compiled for me. After returning to a known as stable version the problem was gone.

So if such thing happens, I wouldn't trust the firmware and flash a stable version before flying.

Your problem with the AQ not responding to your disarm command would be another hint for me that there might be something wrong with the firmware.

[phynix]

I cant tell for sure whether the parameters did vanish while storing some changed ones. It was my guess at that time. One time, it did not arm, then I discovered that the attitude estimation was totally off. Some settings including IMU parameters just vanished from storage. After that I did reinstall the firmeware, uploaded the calibration-file and did all the other settings manually. Everything was fine afterwards.

When I moved the AQ from a hexa to the octo, the yaw controll was not working propperly in the beginning. I tripple checked settings, played with the PID and the mechanical alignement of the motors. All of that did not solve the problem. Then I reinstalled the firmeware, and again, everything was fine immediately. So the fimeware is "fresh" on the AQ.

All these problems happend with "official" versions of the firmeware (r224).

So is it possible, that the software in the MCU gets somehow corrupted ?! I know a little bit about programming, but almost nothing about MCUs.

The board is now sitting there plugged in as Norbert suggested. But nothing unusual so far. Neither with 3S nor with 4S.

[phynix]

Just sitting there with unplugged escs, the AQ does not show anything unusual. What is you opinion: fresh firmeware and that's it or not using this board any more for security reasons (and getting a new one even so the 300€ are hurting)?