Octocopter suddenly switched to stone modus (crash)

[phynix]

Thanks for your comments! Yeah, these connectors ... best would be to avoid them. But this time, they weren't the reason. The power-cable to the AQ was my first thought, too. So I moved it and touched the connector with the AQ powered. No problems, no intereruption.

I still don't think that it is a general problem of 4S or with the AQ! It seems to be an isolated case so far.

I worried a little bit about feedback coming from the esc or induction in the signal-cables. But everything seems to be clean.

@Jussi: thank you for the offer, here is a Logfile of the copter strapped down, 4S, with a non-responding AQ in the end with motors still running (logfile must have ended long before I cut the power).

https://depot.uni-konstanz.de/cgi-bin/e ... d9ypspzsm2

EDIT: One thing I forgot to mention: Today I checked the PWM-outputs, the Voltage-in and the 5V of the AQ board with an oscilloscope while running: nothing conspicuous. Nice PWM-signals, clean voltages. No spikes at all.

[JussiH]

Im curious what kind of radio you are using. The log file show small spikes in the throttle channel and radio quality has several drops. Besides that I can not really tell much as it looks like the whole controller crashes and the log ends abruptly.

There is a MSG file generated with each log. Pls post it. If not, pls post a print of the messages in the comm console as the board boots.

What version FW is this? I am not sure if R224RC should plot motor range as 1000-1950. I seem to remember that 224 was after the scaling change. Your problem is consistant with a UKF crash but that was solved long ago.

This could of course be because of the fact that the copter was strapped down, but you have a lot of motor imbalance, and the low end is clipping, indicating you are overpowered for the setup. However, this is probably not linked to the problem, but worth looking into:

[phynix]

The radio I am using is Graupner MX-20 with an GR-24 receiver. Connectec via SUMD and voltage from AQ-board (5V).

The MSG.LOG is attached.

firmeware is r224/b1400. The suggested one for safe flights

The motor-imbalance is caused by the copter strapped down on a surface that is not perfectly leveled. The throttle was just raised slightly above activation-level.

In flight while hoovering, the motor outputs are almost on the same level, pich, yaw and roll close to center. It hoovers with 4S with a throttle_factor of 0.55 (with throttle around 700), so at least not much overpowered.

All that was visible in the last log, unfortunately I have overwritten the sd-card without a safety copy. Shame on me, I know.

[JussiH]

I am a bit at a loss with this.

It sounds like the board is suffering some crash or overflow condition in the table test. The fact that the log is abrubtly cut, is another indicator that could be the cause.

The only advice I can give at this time is to reflash the firmware and see if you can reproduce it on the table. If you can, I will want to take that board in for testing and replace it with a new one.

Yes, thought it was because it was strapped down. Just looked dramatic enough that I would point it out...

[phynix]

Thank you very much for your offer Jussi. I reflashed the firmeware (again r224) tonight. And - I was not able to observe a freezing yet. Now my girlfried told me not to try it any more in the living room .

One more battery tomorrow.

I realy don't have a clue what is / was going on there. It makes absolutely no sense to me right now and as it seems to be a statistical thing - I can't say for sure that the board is safe for flying now .

- only occured with 4S, not with 3S, board flew many batteries (3S) without problems before
- only occured with the esc connected
- but I wasn't able to measure a feedback on the PWM-lines ( with oscilloscope)
- Voltage at the distribution is clean
- 5V of the AQ is clean
- happened after 5 sec of running motors or after 5 min (random)
- sometimes the motors stopped when freezing, but mostly they kept running.
- after reflashing the firmeware, no freezings so far (with 4S)

[JussiH]

Sounds optimistic. I would make a good many tests to make sure the freezing cant be reproduced with the copter strapped down. Then I would progress to very low level flight tests over a "forgiving" surface before going for all out testflights at altitude.

Having these "ghosts in the machine" is rarely good for confidence, and the only way to be reasonably sure a problem is gone is to test thoroughly. Strictly hypothetical, a inducted current on a signal line could maybe in a rare case induce a reset of the controller, but that should stop the motors, not keep them running.

I have seen a Boot/reset loop happen once before on a very early prototype and I tracked it down to the GPS module, since it would only happen with the antenna connected - then it would continously reset and boot over and over again.

You may be looking at something similar here, so pls test in different configurations with different peripherals connected to see if we can track it down to a certain set of circumstances that makes it repeatable.

What generation board is this? 6.0 or 6.1? DIMU or AIMU?

[phynix]

Thank you very much for your support. It is a 6.1 board with AIMU.

Honestly, I was kind of surprised not to see any spikes or drops on the oscilloskope. I thought that a induction on one of the PWM-lines might lead to a freezing of the MCU, but it is just a clean-PWM-Signal directly at the pins. This thinking was supported by the observation, that the UltraESC that I am using on this build seem to produce way more EMI-noise than the SimonK I used before (with them, I got lots of I2C errors on the Alexmos-Controller even so the distance to them was higher). But then: why did it only happen when the motors were connectet ?!? Vibrations? Induction directly on the AQ board? But that would have been way more critical on the last to builds ... on this one the AQ is seperated from the power-distribution by two CFK-Centerplates ... And why with 4S but not with 3S? Or is it just a coincidence?

Of course I will try for one more hour or so whether there is a freezing. And if not, then go flying carefully. Drops from a height of 1m normaly don't do much damage. But non-responding with running motors .... brrrr.

If it is not happening any more, I can't trace down anything - but I know that it still can happen again at any time (I like the expression "ghost in the machine"). Still thinking whether to buy a new AQ (just to make sure) - or to buy eight esc32 and somehow work out the idea of a redundancy with a Multiwii in parallel.

Edid: Concerning GPS: the in-flight crash happened with connected GPS, strapped down it was always with disconnected antenna

[phynix]

Update: I finaly started again flying carefully at low altitudes. At least for 4 batteries 3S and one 4S with no problems. I will continue testing...