We encountered a very severe problem in altitude flight mode. The flight controller we use is CUAV Nora. The last crash log is shown in the link below:
Also, this is our video for the crash:
We first try to take off the drone and life the drone steadily. Then, after a few seconds, the drone suddenly goes up with a 100% throttle (as shown in the flight log). We observe the drone going up quickly and set the manual throttle to 0% (while the throttle in the flight log is still 100%). Finally, we kill the drone and cause the crash.
We notice that in the local z plot, there is a short-range of z setpoint (~-3.8 m). We don’t understand where does this setpoint comes from. We are pretty sure we have done the calibration step correclty. So, could someone provide an idea of why the sudden jump happens and also how does the setpoint come from (as shown in the local z plot)?
Also, this link below is one of our normal tests just for reference:
Thanks in adance.
Vibration to the flight controller would be my first guess… I always start at the flight controller and move my way out
Thanks for sharing your experience and sorry to hear about your experience with this crash. As I can see from your second log, I am noticing low-frequency vibrations which may lead to these sudden altitude jumps (accel clipping). May you please share your hardware setup and how your FCU is mounted?
Thanks for your insightful comments. This picture shows our flight controller position (We use velcro to fix the FC):
I think we do have vibration, which we will look into, but from the log since all the estimation data is correct, I think it might not be the final issue. I think from the flight log we found something strange in the thrust. Those two figures show that the thrust is increasing itself even though the velocity setpoint is close to zero:
So, I don’t really understand. Because we didn’t set the hover throttle (which we just use default 50%), is it possible that, in altitude control when RC is in deadzone, it will automatically uses 50% throttle??? And our “actual hover throttle” is much smaller than 50%, so it suddenly jumps up?
I will appreciate if you can provide some comments on my analysis. If I need to set the correct hover throttle, how should I perform that correctly? (also, is that related to Max/min pwm?)
It makes sense that your throttle jumps instantly cause the problem may come from the accelerometer. You may bring ur FCU on top of the frame if you can and use dampers like this one:
Besides, maybe going through this page will help you:
Sorry to hear about the crash. The issue is the same as in Abnormal mission following - #2 by bresch, so simply set the default hover thrust value (
MPC_THR_HOVER) to 0.2 or 20% and you won’t have that issue anymore.You can also reduce a bit the minimum thrust as I mentioned in the linked issue above.
On the plots below, you can see that the thrust jumps when the hover thrust estimate gets valid. This is normally because the integrator that should absorb the step is saturated. However, since you’re not the first one having this issue, I will add some extra logic to apply the hover thrust estimate slowly to avoid this issue.
@mwbb Thrust jumps are often due to the accel clipping as you said, but the reason why this happens is that the velocity estimate starts to freefall (due to clipping) and the controller tries to counteract. In the current issue, the velocity estimate is fine (vz goes negative (UP) after the thrust spike), so the accel isn’t clipping.
Thanks @bresch for correcting me. I did not go through the details unfortunately.
@bresch Thank you very much! It solves our problem.
But one more weird thing: From our observation, if we don’t set the proper throttle, the drone will jump in the first flight after rebooting but will stay good after that. I think that is because it can somehow estimate the hover throttle and temporarily save it. Then, if we restart the controller, the jump will happen again. Maybe you could provide us with more insights on this? (Are we guessing correctly? there is some auto estimator and the FC will temporarily save the value until restarting it.)
If we set the hover throttle to be the correct throttle (25%), it just works perfectly. PS: I think this parameter is very important, so probably PX4 can consider putting it in a more obvious position and provide more comments. That will be more friendly to some new users. Thank you very much.
This is correct, there is a “hover thrust estimator” that learns the hover thrust while flying. Usually, this one gets applied seamlessly by removing the difference in the integrator of the PID controller. However, in your case, the step is too large, and the integrator doesn’t have enough space to store the difference and this is why you see a step. The learned hover thrust is maintained and continuously used for the next flights until reboot, where the parameter is used until the hover thrust is learned again.
Yes an no. In your case, where the actual hover thrust is too far from the parameter, it is important, but the objective of that hover thrust estimator is really to remove the need to set the correct hover thrust via a parameter. So I’ll make sure to fix that to avoid having other users getting the same problem.