Plane finally stalled, while in auto mode

Even without an external airspeed indicator installed (so cannot use ARSPD_USE), I believe ardupilot is still using some form of airspeed for control. I used to have very high confidence in ardupilot ability to respect the ARSPD_FBW_MIN value. I thought I can set the LIM_PITCH_MAX, TECS_CLIMB_MAX, TECS_PITCH_MAX to any crazy value, and ardupilot would still respect the ARSPD_FBW_MIN. I had a motor/esc burnt out once, during climb phase in auto mode. Screen disappeared for a second and reappeared. Plane changed to a level attitude when I regained video, then nose down attitude and slowly descending. I didn’t know my motor was gone at the time as throttle position was still showing 100%. Thus, I tried to put full back elevator to stop the descend, switched to FBWA mode and continued to command full back elevator all the way until the plane glided back safety to shore. I was impressed.

Until I decided to change TECS_PITCH_MAX from 15 degree to disable. Not even sure why we need this parameter in the first place. It overrides LIM_PITCH_MAX in auto throttle modes to reduce climb rates. If ardupilot wants to reduce climb rate, then it should simply reduce throttle. By setting it to default 15 degree, I have the plane screaming at full throttle climbing at 60+km/h, which is not very efficient. After removing TECS_CLIMB_MAX, the plane tried to climb disregarding airspeed until it hit 3m/s and stalled. ARSPD_FBW_MIN was set to 9m/s. Don’t think it has anything to do with TECS_PITCH_DAMP or TECS_SPDWEIGHT because the plane had been flying and decelerating below 9m/s for a very very long time before it finally stalled.

Why is ardupilot maintaining minimum speed when motor/esc was blown, but disregarding it totally when TECS_PITCH_MAX is removed during climb? In both cases, TECS_SYNAIRSPEED is set to disable.

No! https://ardupilot.org/plane/docs/tuning-cruise.html#adjusting-cruise-mode-speed

When the motor/esc was blown, the STAB_PITCH_DOWN was set to 2 degree but I was seeing at least 10 degree nose down. So the nose-down pitch I saw is actually not a nose-down command from ardupilot, but rather caused by the plane very fwd c.g.

Reading the TECS tuning guide regarding set max pitch, it says if airspeed falls below ARSPD_FBW_MIN during climb then either reduce LIM_PITCH_MAX or increase THR_MAX. So even with an airspeed sensor installed, there is still a chance the airspeed can go below ARSPD_FBW_MIN ? Wouldn’t it be good to have a function such that when stall prevention is set to enabled, for example, then ARSPD_FBW_MIN will always be adhered to regardless of how the other parameters are set. (e.g. LIM_PITCH_MAX, FBWB_CLIMB_RATE, TECS_CLIMB_MAX, TECS_PITCH_MAX)

Just did some testing by enabling TECS_SYNAIRSPEED. Seems to be working fine and I think we can close this. I set max pitch max climb to some very high, unachievable value, and I can see ardupilot is trying, albeit slowly, to maintain min. speed. Works better in smooth condition, as the correction is slow and I can still get the plane to stall several times. In FBWB mode, I can hold full back elevator and it would command lower pitch as speed approaches min. speed. Glad to learn that min. speed is taking precedence over other parameters.