Plane doesn't honor Min Airspeed and stalls

Although FBWA does not control throttle, my understanding is that the TECS should honor the ARSP_FBW_MIN speed by dropping the nose to prevent a stall.

After a spin and crash during 3.02 testing I rebuilt the old Twinstar and tried to figure out what might have happened. I did some testing yesterday and found that if I leave the Throttle at 0% while in FBWA, the plane will slow well below ARSP_FBW_MIN and eventually stall, even without adding elevator.
ARSP_FBW_MIN = 12
TRIM_ARSP_CM = 1350
Please see the screen shot taken at 77% tlog where the speed dropped down to 8 m/s.

I increased to:
ARSP_FBW_MIN = 14
TRIM_ARSP_CM = 15
and tried again at 85% tlog.
[attachment=0]below min speed in FBWA 2.jpg[/attachment]
Again the speed dropped to almost 8m/s.

Why don’t you take this forward directly with 3DR support and post back here, it might be quicker to get an answer. and I am keen to know if this is a bug too.

Sorry for your crash, but its not a bug. In FBWA you are controlling throttle and pitch directly. The pitch is only limited. The TECS is not in control. In FBWB, TECS is in control of elev and throttle. In FBWA you are responsible to keep enough throttle to fly.

Thank you for your response, but I believe you are not correct. FBWA should still honor the min speed by controlling pitch even though it has no control of throttle or altitude. If FBWA controlled pitch directly as you say, it wouldn’t be called FBW. You are describing Training Mode which gives you direct control of Pitch with limits. I have been flying FBWA for a long time and never experienced this before.
I would like to hear from Paul or another Dev on this.

This is how 3DR provides support. Where else would you suggest I post?

This is how 3DR provides support. Where else would you suggest I post?[/quote]
Please note that the APM firmware is not a 3DR product. It’s open source software which is developed by independent individuals as a team effort. 3DR does sponsor the development but the firmware is still no 3DR product, hence the only support is here in the forums through developers and other users.

Iskess,

TECS is not in control of pitch and throttle in FBW-A, the pilot is and there is no airspeed protection.

If you want underspeed protection, I suggest you fly in FBW-B where TECS is controlling pitch and throttle, but you may want to increase the value of FBWB_CLIMB_RATE to match your TECS_CLMB_MAX so you can use the full climb performance of your plane in this mode.

Regards,

Paul

Thank you Paul, I stand corrected. I have never before needed to push the nose over to maintain airspeed when cutting the throttle in FBWA. In the past, the plane just maintains it’s trimmed speed and starts it’s gliding descent just like in Manual mode.
Maybe something is wrong with my trim.

With no stick input, the pitch loop will attempt to maintain what it thinks is a zero pitch angle. If that angle is too nose up to glide, then the plane will slow down and stall. With a non-zero I gain, it will continue to to wind in elevator until it achieves the pitch angle or the integrator hits the limit set by PTCH2SRV_IMAX.

The trouble is for best speed control without an airspeed sensor, you want a zero pitch demand to correspond to level flight (no gain or loss of height) at your cruise throttle, which depending on airframe and how tightly tuned the pitch loop is, can be incompatible with the pitch angle you need to glide with throttle off.

What I do in this situation is use a bit of mixing on my transmitter from throttle to elevator so that when I reduce throttle in FBW-A, the demanded pitch angle demand reduces slightly. Alternatively you could just trim your transmitter a bit nose down in FBW-A.

Another way to reduce this effect is to set the I gain to zero in your pitch loop, so that the pitch controller will not keep feeding in more up elevator trying to maintain pitch angle as the plane slows. if you do this, then it is more important that you have the pitch control trimmed (consider using the TRIM_AUTO feature).

What concerns me a bit thinking about this is that with auto-tune, the average user will probably end up with a tighter tuned pitch loop than they had before - great for height control, but if they are not using an airspeed sensor could lead to an increased likelihood of stalling in FBW-A. We may have to set the I gain to zero on the pitch loop by default if no airspeed sensor is being used.

Paul,
This plane (Twinstar) does have an AS sensor. I have another thread going about a Bixler that does not have an AS sensor, sorry if I’m causing confusion.
What is the reason that FBWA can’t lower the nose a little to prevent flying below Min Speed? I’m not talking about maintaining airspeed like FBWB, but rather just allow the plane to follow its inherent stability once FBW_ARSD_MIN is reached and release some elevator.
I’m sure there is a good reason. Sorry for asking so many questions.

The reason is historical. FBW-A was originally designed as a mode that didn’t rely on airspeed. Your idea of adding a bias to the pitch when airspeed drops below ARSPD_FBW_MIN is worth considering. There are a few things to think about:

  1. The FBW-A mode will then behave differently with and without airspeed sensing. Is that a problem? Probably not.
  2. We need to decide how to schedule the pitch bias with airspeed - eg to we linearly interpolate from a pitch bias of 0 at the min airspeed to max pitch bias at 70% of ARSPD_FBW_MIN, and stay at the max pitch bias for all airspeeds below 70% of ARSPD_FBW_MIN. We can’t step it as that would cause problems with the landing flare.
  3. We then need to add another tuning parameter for the amount of pitch bias. What default value should it be?

[quote=“priseborough”]The reason is historical. FBW-A was originally designed as a mode that didn’t rely on airspeed. Your idea of adding a bias to the pitch when airspeed drops below ARSPD_FBW_MIN is worth considering. There are a few things to think about:

  1. The FBW-A mode will then behave differently with and without airspeed sensing. Is that a problem? Probably not.
  2. We need to decide how to schedule the pitch bias with airspeed - eg to we linearly interpolate from a pitch bias of 0 at the min airspeed to max pitch bias at 70% of ARSPD_FBW_MIN, and stay at the max pitch bias for all airspeeds below 70% of ARSPD_FBW_MIN. We can’t step it as that would cause problems with the landing flare.
  3. We then need to add another tuning parameter for the amount of pitch bias. What default value should it be?[/quote]

I would guess 3-5 degrees would work. It should be the same pitch as required to maintain TECS min sink. Maybe this can be part of a future flight envelope auto tuning process for TECs. Power off glide, hard dive, max climb, etc.

I see why you are using 70%. It assumes that FBW_MIN is approx 1.3 Vs, a safe approach speed with moderate bank angles. So 70% should be right at stall speed with at 1g.

I also see the issues this could cause with the landing flare. We really need a radio altimeter (or laser) so the APM can know when it is in the landing phase. In the meantime, I think people will just learn to keep the speed up when landing in FBWA so they have enough flare authority. I see how some energy reducing wind shear could cause a hard landing.

Thank you for considering this.