Pixhawk totaled hexacopter heavy crash request for help

please, take a look at my last log file:
This time I had very bad luck, my over 3.5 years flying hexa crashed into 40 meter high trees during an autotune attempt of the yaw axis.
I recently updated the firmware for the Pixhawk to the latest v.3.5.3.
As recommended, I made the compass calibration again, also the COMPASS_MOT and the accelerometer calibration.
All parameter and values are fine.

During a first flight without cam I noticed that the copter stopped very slow (the train stop effect, dangerous).
So I raised the values to have a more immediate stop (more jerk).
Then I saw that the yaw behaves strange: clockwise it turns way over the point when I released the input stick on the TX and ccw the yaw turns very very slow. Also during YAW inputs, the copter tends to a wobble, perhaps a kind of “toilet bowl” dance in the air.
Another thing I noticed when switching to autotune for the yaw axis: The voice said: “flightmode switch fail” . What could that be? It happened only when assigning autotune to a free channel (seven or eight in my case).

So my request is, please take a look to the log file:
Is the compass ok?
Is the GPS ok?
What happened to the YAW parameter?
What kind of issue I have with assigning autotune to a channel?

Please find some pics and the log file attached.
Thank you very much!
Over the winter i will build a new hexa, but want first learn what went wrong this time
(I found nearly all parts except a complete leg, except the video 5.8GHz transmitter and except one EMAX motor :frowning: in the forest)
I asked in the forum too, hope to get some help here :slight_smile:

I am not an expert!
But your YAW- Slabilize P. = 0.00

Hi, thank you for the comment. Yes I saw that.
Could that be a reason for a fly-away and my crash ?

Hey , I just reviewed your data log. That copter was a mess for several reasons, so I made a list.

  1. very bad vibrations and lots of clipping in x & y, but not z, all axis had extreme vibrations.
  2. It had many ekf failures and switch overs. It eventually gave up and went into ekf failsafe which is land now.
  3. Your yaw stabilization P term was zero. How did that happen? You were just running yaw with the I term, which is why it was way over shooting. It basically had no yaw control.
  4. You exceeding the capacity of your current sensor so if you have really high current you won’t know what the max current is. There could be a danger of the current shunt resistor over heating and de-soldering its self, which is disconnecting your battery.
  5. Flight mode change failed because it was in ekf failsafe land mode.
  6. Some thing is wrong with your battery. What size is it? It had huge voltage drops, like 50 % at one point.

So your copter did what it had to do with major ekf problems, it landed into the trees. I think most of your problems are from the vibrations. Either you have unbalanced props or some thing is banging into the controller. BTW you were never in auto mode, it was in stabilize until it went into rtl and then land mode.

thank you ver much for taking time to look in my log file :smiley:
This is what I saw: After the update to firmware 3.5.3 I made a new COMPASS_MOT calibration, a new COMPASS calibration and a new accelerometer tune.
Outdoors, I switch on the copter, wait for 3D GPS lock and take off :
Then I flew slowly over the field with the intention to do a new YAW autotune.
When I flipped the switch assigned to autotune (CH8) the copter began a turn, accelerated
by its own to full throttle (this may explain the voltage drop), and with 45° inclination gain some height and a high speed and 3 or 4 seconds later crashed into the trees (good, so nobody hurt).
When I saw the strange behavior, I switched the autotune off and tried to brake the copter with RTL to bring it back.

The only reason for this test flight was that I saw the strange YAW overshoot aftre the fw update to 3.5.3.

My setup is a FY680 frame (Tarot), Pixhawk FC, XRotor 40A ESC, EMAX 650kV motor for 6S, a 6S 6600mAh (10C) LiPo from Multistar, Aeronaut 13" x 5.5 carbon Props. This gave me about 19 minutes of flight time until reaching failsafe=21 Volt to RTL and beep. With this remaining voltage I always reached “home” with no problems. This setup was flying for years and even after longer flights or huge accelerations, the components was warm to the touch (checking from time to time).

I did not touch the Yaw parameters, so I’m surprised that it is zero now! :open_mouth: Could this happen after the firmware update?
Perhaps I’ve overseen something.
The vibrations before this test flight were in the “good range” values. The crazy curves could be the moment when the copter crashes into the trees, bounced around and finally hit the ground. Fortunately, the LiPo was still tight in the belts and provided voltage and so I found the sad remaining pieces with the “lost copter” beep’s . -_-

Later on the bench at home, the crashed copter arms normally and the 5 remaining motors spin in iddle. The flightmodes switched normally, only when I switch to autotune, there I have the warning “flightmode switch fail”.
I’m wondering what could be the cause.(It worked fine before the update)

Thanks again, I hope to get some more hints to understand all this.
I really admire how you read all that info in the log file. :slight_smile: I have to educate myself…

PixHawk Parameter 27 AUG 2017 AC v.3.4.6.param (10.1 KB)

the param before crash (and update) but mostly the same

I’ve used those multistar green batteries, they really don’t hold up under high amp load. The huge voltage sag either shows the age of the battery or over-current. I’m running a 5500 greenbattery and it’s barely enough amps to keep up with a quad (380kv antigrav with 15"). Looks like you were over 60 amps, your battery should be good for 66amps (6.6 x 10c). You should be able to fit a bigger

You might also want to think about a secondary power supply for your FC and accessories. It showed 4.8ish at one point under peak load, which should be fine but at the extremities that could be low enough to starve a GPS or compass if your maxing out your power module (current sense + FC power).

Vibrations tho, are killer. Do you have the FC on any gel or anti-vib plate?

yes, I have the soft blue damper.
It is possible that the LiPo sag so deep because the copter was trying to compensate the crash in the trees and the crash itself with full throttle to gain level again.
What keeps me head scratching is that before the update to 3.5.3 the copter was fine.
The copter also flew missions of more that 5 km with no issues with the 10C Lipo (avoiding dramatic throttle inputs of course)… Thank you for writing :slight_smile:

Hey Bernordo, I am sorry I gave you a completely wrong conclusion. I mistook the fall through the trees as flight. I didn’t look closely at the timing of events. I let my self be lead by false assumptions. I take back all of my list. I looked at the log again in light of the new information you have given. That was a very short flight. Does this sound right, time wise? One third flying, on third going nuts, one third crashing thru trees?
One of the first things I look at after curr, alt, vibes, att, is the motor pwm out puts. Unfortunately you log settings did not include RCIN or RCOUT. This would have quickly and conclusively identified the failure. I compared your attitude vs desired att plots with crash files of known motor failures and yours fits the provide. All the lingering things in my mind that didn’t make sense before was because I had it all wrong. I wouldn’t blame you if you doubt me now, but I am 90% sure you had a motor failure. A hexa needs a lot of extra power to survive a failure. The yaw p param being zero, I have no clue. Although bad, I don’t think it caused the crash. All the bad ekf errors and and " vibes" I saw was the slow motion crash thru the trees. I used mission planner to view the log.

The voltage sag was due to the crash. I guess the crash checker doesn’t work if the copter is still moving, or a time limit wasn’t done yet.

As far as the update, I would say in light of the motor failure it was a perfectly time coincidence. It happens :slight_smile:

Not funny, but you did it: look at the screen on the first post.

Channel 6 opt is set as Stab Yaw kP with Min 0 and Max 1


Stab Yaw kP= 0 or with a low value will lead to weird behavior in previous firmware releases , i.e. rotating the copter by 90° because of EKF , so I guess that it can be the reason of the lost of control as miebret suggest

From the logs it do not appear that you were in autotune but in stabilize mode , for autotune as far as I know you should be in Alt Hold and then engage autotune.

:sleepy: yes, a weird crash. It took for ever looooooong seconds to fall from the over 40 meter high trees from branch to branch with high revs and the blades cutting leaves and branches in a cloud of chipping propellers and then down to the ground, the poor thing was screaming out the crash beeper alarm sound.
The sound of the crash was intimidating and impressive too. :open_mouth:

It looks that I mistype during the parameter setup and that changed the value for YAW. Lesson learned: Look two times and check a third time after updates or upgrading.

I found all motors except one. The five I have on the bench run all good, no damage. So if there is a motor failure it is coincidental the motor which is (still) missing. The ESC was still hanging on the wires and is ok.

I use the LOG_BITMASK = 958. What LOG_BITMASK writes the RCIN and RCOUT too to the black box (log file)?

OMG !! :open_mouth: this is checked by accident!
Yesterday I re- format the SD card, deinstalled and installed the fw v.3.5.3 fresh and new.
It is better to recheck all parameter one by one. -_-
The Pixhawk and RX survived, are good.
Thank you for the crucial point.

yeah, you’re right. It changed unintentional, I mistype.
And yes, the AUTOTUNE is in ALTHOLD but I did not have the chance to switch to because of the surprise of the crash.
I understood in the last two fw versions that a AUTOTUNE is also possible in POSHOLD. So the repetitive correction of the copter position is not necessary (? or less).

The position hold autotune is extremely impressive.I always do roll and pitch seperately for the first autotune.This was a second tune of all three axes.This is with 3.5.0.

All of my motor failures bar two have been caused by bullet connectors.I now solder all my motor connectors solid.Any I have with bullets still on then the male bullet is soldered solid.The other two failures were by blown out ESC and a short in a motor due to the idiot that put the screws in it (that’d be me).

I am extremely careful in the parameter pages if I am using a touchpad.My pad appears to be able to change parameters by itself with no input from me.

I had a similar issue with a pc that had a corrupted hard disk, since that day I always use SSD hard disks for Mission Planner

hmmm… and it is not a good idea to use the scroll wheel of the mouse while editing or looking through the parameter: It lead to changes that you don’t see or became aware of -_-

Walking the dog today I just as a matter of curiosity visited the crash site nearby. And after 11 days I found the second led of the hexa with the video transmitter. Now drying and later look if it survived. :slight_smile: