The quad works fine in stabalize mode but ascends or descends at high speed soon after Alt Hold mode is engaged. I am flying indoors and it either crashes to the roof or lands irrespective of the input.
After analyzing logs I found that the CTUN.ThO and RCOUT.C3 either go to minimum or maximum ignoring the RC input. The logs and plots are attached.
land_00-01-01_05-32-08.bin (806.4 KB)
upcrash2_00-01-01_05-33-40.bin (488 KB)
It looks like you just ran out of battery.
Your throttle was below 1500 and you had a slight descent going which you eventually corrected with a bit of throttle up to 1500, but the only stick movements I see is when the battery gives out.
Have you set your failsafe warnings?
Have you done an auto tune?
what calibrations have you done?
Yes, the battery voltage seems to be dropping as the throttle increases. However, this might not be related to the crash as the same battery is working fine for an APM copter. The battery failsafe is switched off for the same reason. The following observation might be a more probable reason for the crash.
The value of CTUN.Alt is significantly negative as soon as the copter takes off. When we switch to the Alt-hold mode this negative value is being set as desired altitude (DAlt). In the case of landing log it is around -0.8m while in up-crash it is around - 10m. The values of climb rates also seem to be abnormal. The vibration level specially on z seems to be a little off, however it is within the limits (<±5).
The answer is in the question, I believe. You didn’t commanded to descend, but the actual climb rate (as per FC estimation) is negative. So the flight controller tries to stop descending and increases throttle out.
Why FC wrong in its climb rate estimation? I’m not sure but the VibeZ may be the root cause.
But the DAlt is lower than Alt, which I suppose implies that it should result in lower throttle. However, it looks like the whole calculation becomes absurd due to wrong Altitude and possibly due to reasons of the wrong calculation. Even the value of DAlt is decreasing slowly when the input is in deadzone.
Hi, you are flying indoors and the prop wash in the room might be confusing the baro estimates. Make a flight outdoors and post the logs so that the experts can take a look.
And don’t compare RC Out C3 with rc in c3. Rcout c3 is pwm to motor no: 3
As mentioned in the reply before, the BarAlt readings are in agreement with the actual flight but the CTUN.Alt is negative. We had successful Alt-hold flights with different quad (with APM) in the same hall which is large enough to qualify as a indoor sports stadium.
Take the aircraft out side where it belongs…
Thank you all for the replies.
The problem was solved by damping the vibration. Although it looked like the vibration in z was not off by the rules given in documentation.
We are still finding that the curve for CTUN.Alt and CTUN.BAlt match-up better for older versions (tested with 3.3.3) compared to (3.5.2). We are further investigating this.
