Hello,
I hade a minor crash with a quad today. With minor I mean only one prop lost 
This is a log from the flight:
https://logs.px4.io/plot_app?log=b478bcc7-b3ef-4551-b3c3-e00351f7d97e
I did a takeoff in manual mode, she climbed approx to 3 meters, then did a spin (to upside down) and crash followed.
About an hour before that I managed to successfully fly her in position and altitude mode.
What might cause that issue?
You can see in the log that the roll rate setpoint went in one direction while the roll rate actually was going the other way.
Also, it clearly tried to counteract this with one motor but without success:
My best guess is that this was a failure of one motor, ESC, or prop.
Are you sure that the prop did not come lose in flight? Or can you check if all motors still work?
Thank you @JulianOes, your assmuption seems to be correct. Motor 4 (connected to output3) actually is deat. It cant figure out what way it should rotate. Thus my assumption is that one of the coils is burn down in some reason. Now i have to figure out what was that reason.
I have Sunny-Sky II 980kV motors with 1045 props and TBS Bulletbroof 25A ESCs (BLHeli_S firmware) with default settings. My main concern is that there is Brake on stop enabled by default. If i undrstand correctly this parameter, then it should actively break motor with sudden high current in counter direction. Can it cause too high current peaks to motor, thus burn it?
ESC itself seems to working correctly with spare motor.
EDIT: Did some quick research. Seems that brake on stop feature goes into play when PWM dissapears (with kill switch for example i presume) so it should not have any affect during normal flight. Correct?
Instead it might be damping feature what can cause problems i guess?
Or it was just bad coincidence.
EDIT2: I did one more test flight. Log is here
https://logs.px4.io/plot_app?log=9d389191-a34b-4884-b3f4-d189acca7ed6
It was quite ok, with manual, altHold and PosHold mode. Little over reacting for control sticks, but in overall quite stable.
Until it again crashed in manual mode. This time ended with broken arm. Motors are working correctly after crash.
From to log i noticed taht vibration is in in red zone. But i can not figure out is it “bad” red, or “quite ok” red?
EDIT3: Tho i can also see similar wierd patten for Output3 just at the time when crash started. According to 3D view it started to trop at 04:26.200
My first response to this problem is to play with the motor timing and maybe a few other ESC settings. It’s pretty easy to confirm in the MAVLink console using the pwm command to test a sharp step in commanded throttle to make sure it happens the same on every motor and to test after making changes. I’ve had no luck on some setups after trying every possible setting until I finally switched the ESCs from BLHeliS ones to others with BLHeli32, so your mileage may vary.
Decreasing MOT_SLEW_MAX or increasing MPC_MANTHR_MIN and MPC_THR_MIN might hide the problem a bit, but it’s best if the motor controller can handle a step input from 0-100% through the console and not have anything unexpected happen. Fair warning that I have noticed the pwm command sometimes causes the uncommanded outputs to get stuck at 0us until rebooted, so you might have to reboot between testing motors. Not sure if this is a bug or a feature, to be honest.
It looks like there is a lot of vibration on your frame! I suggest to detune the rate control a bit and also make sure the props are in good shape.
So i got it somewhat better flying shape with replacing ESCs again. It is able to stay in air now, pid needs some finetuning tho.
But i can not get rid of that vibration. I replaced vibration dampering plate undernath of FC, but vibration is still in red. Props of course are balanced.
Might be that Chineese Pixhawk 1 clone is just bad? I doubt.
@bresch do we have documents on how to set the filter cutoff frequencies for “bad” airframes?
So i changed cheap plastic props to decent carbon ones. Balanced to them near perfect level and these are the graphs what i got:
https://logs.px4.io/plot_app?log=67986b1c-d485-485f-8fec-1af59e9bda2b
Vibration seems to be under controll now.
I’m not that happy with PID graphs yet, but this is whole lot different story.
EDIT: On Actuator Controls FTT graphs, there is IMU_GYRO_CUTOFF timestamp, and after that seemst that something changed. What that graph tells us and what that CUTOFF actually means?
EDIT2: Little thinking got me to this interpretation. Thre is bit high vibration around 40Hz at Pitch axis and around 60Hz at Roll axis, but it does not disturb gyro, since its CUTOFF frequency is set on 30Hz, corect?
Have a look here: https://docs.px4.io/master/en/config_mc/racer_setup.html#filter-tuning
