I’ve got a 960mm hex with 18" props and 288kv motors that went crazy today. It’s been flying 3.4 since it was released for beta and flew great. I notice the tuning could be better so I thought I do another autotune to see if it would tighten up. Barely got a foot off the ground before it did a complete front flip. Snapped the gear off and broke two propellers, so no too bad. But man, it was violent! I had made two changes to the unit. First I swapped the old 3DR GPS for a new Ublox Neo-M8N GPS. I did this exact swap on my 680X8 and it works great, same GPS unit. The other change was changing the ATC_RAT_RLL_FILT and ATC_RAT_PIT_FILT to 10hz instead of 20 (recommended for larger units autotuning). Again, did this on the 680mmX8 with a great autotune. Another funny thing, there’s no error or crash error in the logs but the parachute fired! 2016-08-30 15-48-53.bin (250.6 KB)
Just noticed something else odd. Playing back the Tlog, the radio telem never get better than 47%. It’s a RFD900 on both sides. Never seen anything less than 95% at 1000m let alone 45% at 4m lol! Also noted the EKF monitor doesn’t go nuts until it’s finished it’s front flip… Wow, any help would be greatly appreciated.
One last thing…if anyone actually is reading this lol. The parachute didn’t eject. I just got tossed out from the force of impact.
The very odd thing is the ATC_THR_MIX_MIN value is 10575. That number should never be higher than 1 and normally it’s 0.1. Can you set this parameter back to 0.1?
What’s worrying is I don’t know how this has happened. Did you by chance load an unofficial version from master at some point? I.e. Copter-3.4-dev? There was a bug that could cause this but I think we fixed it some time ago.
If not, do you have any older logs that I could check (from Copter-3.4)? Maybe that will have a clue as to when this happened.
Ah, by the way, the likely reason the parachute didn’t fire was because the vehicle was always under 10m and there’s a CHUTE_ALT_MIN set to 10 (the default).
I think as a minimum I’ll add a sanity check re these parameters. Thanks again.
Hi,
I do not know if it can helps since years are gone since but in a very early version of Mission Planner, let say 4 or 5 years ago my notebook had a corrupted hard disk with bad sectors and while I was changing some parameters via 433mhz telemetry some others were written with random and odd values .
It never happened anymore since but after that episode I always use double checked SSD drives for Mission Planner.
Ok right. So the older log you kindly posted is from -rc1 and I realise now that we moved/renamed the affected parameter between -rc1 and -rc2 (it was MOT_THR_MIX_MIN, now it’s ATC_THR_MIX_MIN). The most likely cause of the problem was that the eeprom had stuff in the new slot we used. Technically that should never be the case because we are careful to never re-use old slots.
A shot in the dark but have you ever loaded the tricopter or tradheli code onto this flight controller?
No, never loaded anything other than the hex version of 3.4. Strange. Do you think that was the cause of the crash? I thought maybe it may have been a bad compass as there seemed to be a fair bit of interference as well. Of course that shouldn’t make it flip lol!
Ok, great news.
I’m planning to push -rc4 this week which will include the parameter check. We have seen some parameter corruption in another parameter as well (just this morning) so we are investigating and let’s see if it’s related to what you saw.