Arduplane stall avoidance

[James Betker]

Hey guys, new member on this group.

I've damaged two planes now due to the lack of a true stall avoidance algorithm in the Arduplane code. It seems to me that it would be pretty simple to add a Vs parameter and an option to lower the angle of attack under all Arduplane-controlled modes (e.g. not manual) whenever airspeed decays below Vs. For me it is always preferable to lower the nose and risk a hard landing due to low altitude then to stall and spin in. 

It seems like this would be a very desirable feature for planes. Is there some configuration setting that is already available that accomplishes this that I'm missing?

[Charles Taylor]

Vs would provide very limited protection from stalling. People are usually changing payloads and battery size constantly so Vs will could always be changing. Also Vs only comes in handy during smooth level flight. An airplane can stall at any airspeed above Vs. For example in a turn stall speed increases with Bank angle. Even in straight and level flight if you pull back hard enough it will stall (turbulence can have the same effect). What would be better is an angle of attack estimate and limitation or an actual AoA sensor since a wing always stalls at the same AoA. I've seen some nice DIY solutions for a sensor but I don't think any have been implemented in arduplane.

[john...@gmail.com]

This is a hard problem. Mostly because there are many internal (weight, cog etc.) and external (speed, wind etc.) factors that all combine and affect stall behavior differently for each case.

The proper solution (how real airplane pilots do it), would be to "listen to the aircraft". Meaning that just before a stall, the plane will start to feel very light on the stick. It should theoretically be possible to detect the same thing by looking at the stabilization values and how they change just before a stall.

- JAB

[James Betker]

I'm going to have to respectfully disagree. I am a licensed private pilot, and I can tell you that in the full-sized world, payloads tend to change MUCH more than in our world, where we have batteries that always weigh the same amount, charged or uncharged. A bank angle of 45 degrees translates into a 20% increase in stall speed. If you were to introduce a feature such as this, you would need to simply add a page on wiki instructing people on how to determine Vs and how to properly add the safety margins. I agree, an AoA sensor would be the best solution, but airspeed would work, and has worked in the full-sized world, well. 

[john...@gmail.com]

The model airplanes we deal with are generally much more sensible to changes in CoG/weight then full scale, since the physics does not scale linearly.

There are many examples of full scale designs that fly great, but if scaled down to R/C sizes without modifications are terrible with nasty stall characteristics. The Predator style of UAS being a popular example. Another being R/C turbin jets who would be almost impossible to fly if scaled down completely true to the original jet fighters.

[James Betker]

Do you have a source for that? Miniature turbines are a difficult problem because the flow equations that they rely on for moving air deal with surface area to volume ratios - you move a smaller amount of air per surface area of the inlet as you decrease the size of the inlet. This does not necessarily have anything to do with the dynamics of a stall.

Regardless of the actual dynamics, this is still something that could be programmed in. We ask our autopilots to essentially emulate humans onboard our model aircraft, but can you imagine a world where human pilots were not taught that "if you go below xx speed, the airplanes wing will stall and you will spin into the earth"? Seems unfair to the autopilot. If this is not a feature that is present, or being worked on, I will put some time into it in the next few months. I just wanted to gauge what's being done, if anything.

[Charles Taylor]

I am a licensed commercial pilot and a calculated Vs is not the save all to stalling.  Like I said an airplane can stall at any airspeed.  I agree that adding a Vs limitation that scales based on bank angle to arduplane can help prevent certain stall conditions.  But even in full scale aircraft stall warnings are based on AoA not Vs.  Even in a small Cessna or Piper its based on AoA to warn the pilot the aircraft is approaching stall.  All I am saying is it won't prevent a plane from stalling in all situations.

[Jonathan Challinger]

The issue isn't really preventing stalls - I think that's fairly easy with a couple of constraints. The issue is with making hardware failures worse. At the moment, an airspeed failure doesn't seem to kill the airplane, but it might if we were trying to prevent stalls.

We do need to have the optimal behavior based on our best knowledge of the aircraft's state and pilot input, and I don't think that optimal behavior excludes stall prevention.

[Francis Henderson]

I am a licensed private airplane pilot, RC flier, and plane autopilot enthusiast. It is astonishing our autopilots are flying without knowing aircraft stall speed (Vs).  Much is derived from knowing one Vs test point at known weight.  For example, the affects of change in weight on Vs are easily computed using known formulas.  Likewise, banked turn or accelerated stall minimum speeds are calculated on the fly using formulas at the link below

Given one Vs test point and new current weight (if any), the plane autopilot derives takeoff speed, landing approach speed, and avoids getting too close to different Vs minimum speed limits during accelerated turns.

http://www.inertial-solutions.us/pdf_files/Stall%20Speed.pdf

Airspeed is so important the autopilot always has an opinion about it whether coming from the GPS sensor or from the Airspeed sensor. Therefore, I disagree with the argument that preventing stalls endangers the airplane because airspeed sensors might fail.  One of these two redundant sensors (GPS and/or Airspeed) has to work else all is lost.  Alternatively, running plane autopilot without stall prevention seems a reckless thing to do.

As Andrew Tridgell points out, as the autopilot evolves we users have rising expectations.  Therefore in keeping, Stall Speed and Lift/Drag ratios are further discussed at the following link:

http://www.inertial-solutions.us/pdf_files/Learning%20and%20Using%20Lift-Drag%20ratio.pdf

Nelson Henderson

[David Armstrong]

just to say i'm most interested in having some stall preventive measures , for one reason , i'm using gas turbines 

[Paul Riseborough]

There are some simple changes to FBW-A coming which will alleviate the likelihood of stalling in that mode which are based on a pitch down bias that is added progressively as throttle is reduced from 50% to zero.

There are significant negatives to providing stall protection based on airspeed in control modes that have been designed to be not reliant on airspeed sensing. Such a mode if implemented would leave the plane vulnerable to failure of the sensor. Remember that many users cannot fly safely in full manual mode and rely on stabilise or FBW-A to get up and down in one piece.

Auto modes under airspeed control are a different matter. There are a few simple changes that would help, but both rely on the user correctly entering a stall speed (most users cannot read graphs and cannot do maths so we would need to have a simple calculator they can use based on weight, wingspan and wing chord).

1) TECS has minimum speed that it protects, this could be limited to be no less than 1.3 Vstall
2) The bank angle could be limited as function of the square of airspeed/Vstall to prevent dynamic stall. This is a simple change.
3) Augment 2) with a pitch rate/g limiter based on the square of airspeed/Vstall ratio. This is not such a simple change.

My advice in the short term until the new FBW-A feature arrives is to set the TRIM_PITCH_CD to a value that allows the plane to glide at a safe speed with throttle off. You can then use a bit of KFF_THR2PTCH so that on 505 throttle it flies at a constant height. This will make it nicer and safer to fly in FBW-A.

[Andrew Tridgell]

Hi All,

Thanks Paul for your comments. I thought I'd add a few more comments on
the general approach we've taken. We can change approach, but it isn't
nearly as obvious as it may at first seem.

First off, there are a number of very big differences between flying an
RC model and flying a full sized aircraft when it comes to stall
speed.

The first big difference is the accuracy of the airspeed
measurement. The accuracy of airspeed sensors rises rapidly with
airspeed, because airspeed rises as the square root of differential
pressure. If you are flying at 50 or 100 knots then you can measure
airspeed very accurately. If you are flying at 15 knots then the
accuracy of airspeed measurement is much worse. So a typical R/C model
loses out in several ways:

1) it flies much slower than a full sized aircraft, so the absolute
accuracy is much lower. For a typical foamie like a Bixler with a
stall speed well below 20 knots the accuracy of a typical airspeed
sensor setup may be off by 25% or more.

2) the uncertainty in airspeed measurement means that the usual rules
like 1.3 times stall are pretty bad, as the error in the measurement
is close to the margin you are allowing for

3) R/C models change airspeed as a proportion of stall speed much more
rapidly. A small gust, a bit of up pitch etc can change airspeed on a
foamie by more than the usual 30% stall margin in a second or two

4) getting a good estimate of the stall speed on a R/C model can be
quite tricky, whereas full-size aircraft come with all the data you
could want. If we asked users to deliberately stall to estimate stall
speed then for many people that would be the last flight they would do
(how many people on this list know how to get an X8 out of a
stall/spin?).

That is the first big difference. The second big difference is the
consequences of getting the airspeed wrong. In a full sized manned
aircraft if you stall then people can die. Preventing stall is an
absolute priority.

In a R/C model if you stall you can lose a few hundred dollars of model
airframe. Conversely, there are situations where if the aircraft got the
airspeed wrong and decided to force the nose down hard, overriding the
R/C pilot on the ground, then you could injure people on the ground.

That doesn't mean we shouldn't prevent stalls - obviously we should. I
just wanted to make sure everyone understands there are different levels
of priorities with R/C models.

Now that we've got that background, I'll try to explain the current
situation with ardupilot and stalling of fixed wing aircraft.

We have two classes of flight modes. The first class is "manual
throttle" and the 2nd class is "auto throttle".

The manual throttle modes are:

MANUAL
TRAINING
STABILIZE
FBWA
AUTOTUNE
ACRO

The auto throttle modes are:

FBWB
CRUISE
LOITER
RTL
AUTO
CIRCLE
GUIDED

In all of the auto throttle modes the TECS speed/height controller is in
charge. It operates in one of two modes:

- if it has an airspeed sensor available then it actively controls
airspeed, keeping it at the target speed. If airspeed drops more
than 2 m/s below ARSPD_FBW_MIN then it goes into "panic gain
airspeed", drops the nose and puts on full throttle. Because it is
actively controlling airspeed it very rarely does that, but it will
force the nose down if it needs to.

- if it doesn't have an airspeed sensor then it instead uses
TRIM_THROTTLE to set the basic throttle level, and then raises and
loses throttle and pitch to attain the desired altitude. A
synthentic airspeed from the IMU and a wind estimate is used for
surface speed scaling, but not for airspeed control. In our
experience this is more reliable then using the synthetic airspeed
as wind estimation often isn't very accurate.

As Paul points out, there are ways that TECS could be smarter about
stall protection, but I think this email thread is really not about the
TECS modes. Pilots tend to get themselves into trouble in FBWA or
STABILIZE, not in auto throttle modes.

Ok, so now let's think about the non auto throttle modes. Some of them
clearly have to have no stall protection. It would make absolutely no
sense to have automatic stall protection in MANUAL, TRAINING or ACRO
modes, as it would defeat the purpose of those modes.

So really it is just FBWA and STABILIZE modes that we need to consider
(as AUTOTUNE is just an FBWA varient).

As Paul says, these modes are the fallback modes for many/most people
flying ardupilot on fixed wing aircraft. When something is going wrong
in one of the more sophisticated modes then you change to FBWA to
recover. Many (most?) people flying ardupilot are not comfortable flying
their aircraft in MANUAL mode. That is unfortunate, but it is also
true. It is partly a result of FBWA making flying so easy that people
don't get practive in MANUAL (and that is largely why I added TRAINING
mode, to try to help people to learn to fly in MANUAL with some
assistance).

If we made FBWA have airspeed based stall protection then if the
airspeed was off even by a small amount it would make landing very
difficult. Airspeed based stall protection using synthetic IMU based
airspeed would trigger far too often, and is likely to crash more planes
than it saves.

That doesn't mean we can't do anything however. I've just added a new
parameter which is meant to address exactly this problem:

http://plane.ardupilot.com/wiki/arduplane-parameters/#Low_throttle_pitch_down_trim_ArduPlaneSTAB_PITCH_DOWN

the new parameter STAB_PITCH_DOWN makes the aircraft automatically pitch
down when you lower the throttle in FBWA mode. The reason I added it is
I noticed that the likelyhood of stalling ardupilot has increased
lately. I think the reason for that is the introduction of AUTOTUNE.

Before we had AUTOTUNE most users had very badly tuned pitch
loops. Combine this with the way that most R/C models tend to natually
put their nose down when you lower throttle meant that the plane
automatically compensates for lower thrust by putting its nose
down. That is the same reason why normal R/C models don't stall all the
time.

Now we have AUTOTUNE we have a lot more users with good pitch
tuning. That means when you lower the throttle the pitch stays exactly
the same in FBWA mode, unless the pilot knows to push the nose down with
the elevator stick. So users are now more likely to stall as their plane
is now better tuned!

The STAB_PITCH_DOWN parameter solves this by automatically lowering the
nose when you lower the throttle. It is a very simple mechanism that
doesn't rely on an airspeed sensor, and it works well (I've done a few
flights with it already).

I've made the default value of STAB_PITCH_DOWN be 2 degrees, but I am
considering making it 3 degrees. It basically depends on how draggy your
aircraft is.

Anyway, if you read this far then thanks for your patience. I hope you
understand a bit better why things are how they are in APM:Plane! Paul
and I are very happy to consider changes to how things work now, but
please take into account the above factors.

Also, if you really don't like the lack of active airspeed based stall
protection in FBWA mode then please try FBWB or CRUISE mode. You may
want to raise FBWB_CLIMB_RATE a bit though - it is quite low, and for
general "flying about" it can be far too low. A lot of R/C models can
climb an awful lot faster than the default of 2 m/s.

Cheers, Tridge

[David Armstrong]

at least a flash indicator on the qroundcontrol of an impending or possible stall event

based from airbourne events , could this be a possible step , rather than an impending " i'm taking over even if you dont like it approach " from the controller 

or at least a switchable option perhaps ?

[David Pawlak]

It's relatively clear that 1) synthetic stall detection is not as easy as it sounds, and 2) results, although probably quite satisfactory, are not bullet proof.

So the other option mentioned a few times here is AoA (Angle of attack) sensor. This is a very solid indicator of stall potential. The critical angle may vary slightly depending on load, but since it is a non-linear function, the breaking point based on weight/speed, is very abrupt and differs very little from light load to heavy.

Big airliners measure the angle and use other feedback through the autopilot, mostly related to wing configuration, to decide on the precise stall angle. Smaller aircraft (a great proportion of gen. av. planes) have a Stall sensor. A tab set to a specific angle that receives enough force to overcome a spring at the stall(+x) angle. 

A sensor like that would reduce software complexity immensely, and increase functional security. Pre-flights, such as we all do (right?) would check the sensor before flight, as do all gen, av, pilots.

[James Betker]

Andrew / Paul - Thank you very much for your input. What you are saying makes a lot of sense. Given this information, I think I can tune my plane to better avoid stalls. I think this post by Andrew might be useful to others if it was put into a wiki page. I know when I was setting up APM for my plane, I was very confused as to what parameters I should be setting to prevent stall - I figured ARSPD_FBW_MIN played a role but there is no documentation to suggest that this is as hard a minimum as Andrew suggests it is.

Thanks again!

[Andrew Tridgell]

Hi All,

After writing my long explanation of why we don't currently do "takeover
if about to stall" in FBWA mode, I then realised there is one case when
we could do it!

If the user has a geofence enabled then they already need to be prepared
for the autopilot to take over in case they breach the fence or altitude
limits. They also have to disable the fence when landing. So the safety
argument about not wanting to override the pilot when in FBWA largely
disappears if the fence is enabled (especially if a FENCE_MINALT is
set). As the fence is on a R/C channel, the user can disable it quickly
if they need to.

So we could potentially have stall avoidance in manual throttle modes if
the fence is enabled, essentially making it part of the geofence
system. That could work in a number of ways:

- we could add more down pitch if in FBWA mode
- we could add more throttle
- we could takeover into GUIDED mode (like we do for fence breach)

So maybe we should add a FENCE_MINSPEED parameter? It would default to
zero, meaning no stall protection.

Cheers, Tridge

[Andrew Tridgell]

Hi John,

> The proper solution (how real airplane pilots do it), would be to "listen
> to the aircraft"

This could be really worth pursuing I think.

One of the problems with flying in STABILIZE or FBWA mode is that the
attitude controller tends to hide the normal signs that you are close to
a stall. When flying manually a plane starts to get "soft" as you get
too close to stall, and you know you need to gain speed. When in FBWA
mode with well tuned roll and pitch loops this tends to get hidden from
the pilot, and the plane seems fine right up to the point that it
stalls.

It would be really interesting to see if there are clear enough signs in
the the controllers internals of a stall to use as a stall warning.

Cheers, Tridge

[Andrew Tridgell]

Hi David,

> at least a flash indicator on the qroundcontrol of an impending or
> possible stall event based from airbourne events , could this be a
> possible step , rather than an impending " i'm taking over even if you
> dont like it approach " from the controller or at least a switchable
> option perhaps ?

yes, the GCS could certainly do that. When I fly I tend to have MAVProxy
with the speech and sensors module enabled, which means it announces
airspeed changes. I use that to help with getting the right landing
speed for larger models.

I think it would be worth opening an issue in your favourite GCS to ask
about adding an audible stall warning.

Cheers, Tridge

[Robert Lefebvre]

Could you not look at the amount of I-term built-up?  I-term should capture long-term excursions from normal flight control, as would happen with soft controls?

--
You received this message because you are subscribed to the Google Groups "drones-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Andrew Tridgell]

Hi Robert,

> Could you not look at the amount of I-term built-up? I-term should capture
> long-term excursions from normal flight control, as would happen with soft
> controls?

I don't think I term would build up. I haven't actually analysed a
near-stall log, but I would expect it to be symmetric for roll, and
thus not have a large I term (for roll at least).

I know there has been some research into a synthetic angle of attack,
for example:

http://diydrones.com/profiles/blogs/airspeed-angle-of-attack-sideslip-and-flight-path-vector

that may be the best place to start? If the ideas in that paper work in
real R/C aircraft it could be very worthwhile.

Cheers, Tridge

[Robert Lefebvre]

That's a good point about the roll.  I guess I was thinking more about the elevator. It's been a little while since I flew an RC airplane, but as I recall, you have to hold in more and more elevator as airspeed falls, to hold an altitude. If I recall correctly, you guys have gone to a system using Feedforward for the control movements?  Wouldn't the Feedforward becoming increasingly inaccurate at low speeds, requiring more P and I correction?  That goes to the statement that control is "mushy".

Cheers, Tridge

[Paul Riseborough]

Rob, the plane pitch and roll loops use a combination of gains applied to feed-forward on rate demand, angle error, rate error and  integral on rate error. See the block diagrams at the bottom of this page for the topology.

http://plane.ardupilot.com/wiki/roll-pitch-controller-tuning/

[David Armstrong]

Robert , the last thing you want to do in a stall is up elevator ! , we are taught get the nose down and increase speed
the problem becomes , that in a plane if you reach a stall , due to dynamics , you will tend to drop a wing which will put you in a spin ,nose up if your unlucky , so what you need to do is get the nose down , increase speed this will give some authority to the alerons and elevator which you would loose in the stall , due to lost airspeed

it's another reason i practice autorotations on the heli from a great height , we dont want these ending in a refuse bag on landing

the problem with turbines is even worse as you have a lag , as speed is not instant , so stalls can happen
without you realising , so any notification of a stall condition or possible one , can be helpful

[john...@gmail.com]

>It's been a little while since I flew an RC airplane, but as I recall, you have to hold in more and more elevator as airspeed falls, to hold an altitude.

That is correct, it's this behavior in the autopilot that causes the stall (increase in angle of attack) when taken to far. Must commonly this happens at low speed, but it's also possible to do at high speeds which can be a very brutal affair. But for simplicity and with the typical UAS airframe in mind,  I guess we can focus on low speed stalls.

In layman's terms when close to a low speed stall, you should expect to see larger then usual control inputs to maintain attitude, and slower then usual response to any directional changes in the airframe. The first indication would be increasingly larger elevator inputs, and right at the stall point little or no response from ailerons.

So basically we need something like a passive version of the copter auto tune running constantly looking large profile changes that would indicate a near stall incident.

[Stefan Gofferje]

Hi,

for bigger planes like e.g. the ones Tridge flies at the Outback
Challenge, it might be worth looking into using stall sensors. There are
a few different concepts but most of them are fairly easy and should be
reasonably easy to build on a small scale. And detecting airflow loss /
stream separation at the wing would be the definitive stall detection
method :).

-S

--
(o_ Stefan Gofferje | SCLT, MCP, CCSA
//\ Reg'd Linux User #247167 | VCP #2263
V_/_ Heckler & Koch - the original point and click interface

[Ilia Sheremet]

Hello,

I was very lucky to stumble across your post.

I had all this thoughts about lack of AoA precise sensors for low-cost UAVs and it's encouraged me to tackle myself in development one (fortunately my university stimulates this kind of motivation financially). 

At the moment I'm working on a STM32F4 based angle-of-attack\airspeed\humidity\altitude (all in one module sensor) for UAVs and I planed to make Serial and CAN (based on UAVCAN)  protocols connection to it. In my team I have people who are helping me with PCB and the whole module design, whereas my part is firmware. Currently, I have already bought all the sensors and play a bit with them, but I am low on experience with embedded systems programming, especially RTOSes. I have chosen NuttX to have a better understanding of Arduplane source code.

But the thing that discompose the most is a thought that due to my inexperience it might take much more time that I would expected. 

So I want to ask you - do anybody (who has an above mentioned background) would like to help me with this project? By helping I mean taking some tasks and\or having 1-2 online meeting per week. Or even if not - to point me out where it is better to look for this kind of person (on forum, github)? Or maybe you could advice me something else that might help me with my issue? 'cause the next step I want to make is to incorporate it in Arduplane code and it's also will take some appreciable extra time if to do it only by myself and asking for help only on forum (where I can wait for the answer to long, or not even get the solution).

Thank you in advance

and have a nice day.

[Francis Henderson]

While working to assist Stall Avoidance, I found an on-line stall speed calculator using wing dimensions and weight that calculated a stall speed (Vs) estimate for my plane matching my own flight observations on Mission Planner.

http://adamone.rchomepage.com/design.htm

I've written and uploaded a paper to diydrones.com and to my site giving the equations for calculating some Mission Planner parameters tied to the new Vs.  Example calculations are included.  Stall safe flight parameters are the first step towards stall avoidance.

Also, the autopilot could use the new reference stall speed information to avoid stalling in all flight modes except manual.

First, I realize the auto pilot is mechanized using TAS.  The physics rightly drives that choice because of the IMU and GPS sensors, and the navigation task. However, I believe stall avoidance will benefit from converting the best estimate of TAS back to IAS at Standard Temperature and Pressure (STP) so that all stall calculations are as if at one uniform air density.  Ardupilot has all the input needed for converting to an IAS equivalent using initial information from the barometer and temperature sensors during calibration before takeoff.

Second, I believe we have a smoothed EKF estimated TAS better than is provided by the airspeed sensor alone.  Let us use the best speed estimate we have.

Third, airspeed is not the only factor indicating an approaching stall.  Wing g force loading also acts along with airspeed to cause or to relieve a stall condition.  Small downward elevator may increase airspeed slowly, however down elevator is a nearly instant relief to g loads.  It allows time for added engine thrust or wind turbulence (that could be the transient cause) to restore safe speed and wing loading.

Fortunately, the ardupilot z-axis accelerometer is measuring wing g loading directly and continuously.  See equation from the paper below:

 *** Ooops formula lost here.  See paper at link below ***

      If   (Vs  ≥    V(IAS measured) )  then remedy stall

Knowing the new 1 g stall speed at STP from the on-line calculator, the above allows plane ardupilot software to continuously monitor for approaching stall conditions and to take preventative actions by adjusting elevator and throttle.

http://www.inertial-solutions.us/pdf_files/StallAvoidance.pdf

[Jonathan Challinger]

We estimate both IAS and TAS. 

--

[Francis Henderson]

All,

 

I believe APM Plane stall avoidance is a feature we want to continue pursuing.  Therefore, using developer feedback, and seeking to define a guiding Concept of Operations, I’ve iterated again an overall approach and actions to take in each of the 18 flight modes.  Please see the following link:

 

http://www.inertial-solutions.us/pdf_files/2014-11-11_StallAvoidance.pdf

 

The paper briefly describes two simple ways the reference stall speed (Vs) can be learned.  Formulas are provided allowing the autopilot to compute the current stall speed depending on weight changes and g loads.  Stall warning, stall avoidance, and Flight speed recovery thresholds are suggested.  Stall avoidance actions are proposed for each flight mode.

 

For Comment,

Francis “Nelson” Henderson

I wonder if developers see this?  

[Andrew Tridgell]

Hi Francis,

Thanks for your effort on this!

Paul and I had already discussed making the code take account of the
aerodynamic load factor. See the discussion here:

https://github.com/diydrones/ardupilot/issues/1528

plus the earlier discussion on stall avoidance.

So while this had been planned, I hadn't actually implemented it till
today (prompted by your email). See the discussion on the implementation
here:

https://groups.google.com/forum/#!topic/drones-discuss/M_6YY1NweCc

There are a few things in your paper that I think are worth commenting
on.

> APM Plane autopilot needs only three (3) new parameters in order to
> avoid stalling. First, a reference stall speed (Vs) at Standard
> Temperature and Pressure (STP) computed on-line using aircraft weight
> and wing dimensions, plus current weight, if different. That is all
> (Reference Vs, reference weight, and current weight).

right now what we have is ARSPD_FBW_MIN, which is the minimum apparent
airspeed the user wants the aircraft to fly at. Up to now this value has
not been scaled for aerodynamic load factor. The patch set above fixes
that, by both adjusting the bank limit to account for load corrected
minimum airspeed, and adjusting target airspeeds in turns to account for
the load factor.

I'd prefer to not add a weight and reference weight as
parameters. Instead I'd prefer to just document how users should adjust
ARSPD_FBW_MIN to account for adding weight to an aircraft. A wiki page
describing the following would be ideal:

- how to estimate stall speed given aircraft dimensions
- how to measure stall speed using a flight test and log file
- how to adjust stall speed when the weight of the aircraft is changed

then we can keep the single parameter which captures the minimum speed
for level flight, and let the code take account of adjustments for
non-level flight.

The wiki page should also provide advice on how far above the stall
speed that ARSPD_FBW_MIN should be set.

> The autopilots have two airspeed reference systems, True Air Speed
> (TAS) and Indicated (calibrated) Air Speed (IAS). Navigation functions
> (like waypoints or Inertial navigation) need TAS; the piloting
> functions (like turning or landing or avoiding stall) need IAS.

yes, that is captured in ardupilot using the EAS2TAS ratio. We recently
discovered that the use of the temperature sensor in the barometer was
throwing off the EAS2TAS ratio by about 5% or so because the barometer
gets hot as it is in among lots of other electronics. The above patch
set changes it to use the temperature from a digital airspeed sensor
when available, which tends to be a lot more accurate.

> The desirable feature about IAS is that different altitudes and temperatures do not affect stall
> speed, or banked turn speed, or landing speed. For example, the TAS at which an airplane stalls is
> different at different altitudes for the same weight or g loads. However, the air density change
> with altitude affects IAS proportionally to the way it affects wing stall. Therefore, stall speed (Vs)
> for a given weight or g load is at the same IAS even though air densities are different.

indeed. ArduPilot already uses TAS or IAS in the appropriate places, by
using the EAS2TAS scaling factor. If you find a place where you don't
think we use the right airspeed then please let us know. We tested this
by flying at very high altitudes (over 20km) in the SITL simulator,
where EAS2TAS gets very large.

> a. Gear Down state (fixed or retractable gear are down), Flap setting percentage 0% to 100%
> where 0% is the special no flaps case. The data structure will contain a 0%, 33%, 66%, and
> 100% stall speed flap setting reference points. Servo settings at points in between are
> interpolated. Rarely, will the 33%, 66%, and 100% data points be provided, but they are not
> excluded from the software design.
>
> b. Gear Up state (retractable gear case or no landing gear), with flap setting percentage 0% to
> 100% where 0% is the no flaps special case. As above, the design does not exclude stall speed
> estimates at partial flap settings. Autopilot software must take care the structure is safely
> initialized and defend against GCS omissions or errors.

right now ArduPilot is not aware of whether landing gear is down, and in
fact very few ArduPilot users fly with retractable landing gear. I don't
think adding different airspeed handling for gear down is worthwhile at
this stage.

I also don't think we should ask users to enter mimimum airspeed for
different flap settings. We need to strike a reasonable balance between
configurability and complexity, and I think having to enter minimum
airspeed numbers for different flap settings goes too far down the
complexity path.

> An over simplified event driven state machine approach is used for thinking through Stall
> Avoidance suggestions in each of the 18 APM Plane Flight Modes . It does not apply to Copter or
> Rover.

there are actually only 3 flight mode categories from the point of view
of stall avoidance. They are:

CAT1) manual attitude control and manual throttle control (MANUAL,
STABALIZE, TRAINING and ACRO)

CAT2) automatic attitude control and manual throttle control
(FBWA and AUTOTUNE)

CAT3) automatic attitude control and automatic throttle control
(CIRCLE, FBWB, CRUISE, AUTO, RTL, LOITER and GUIDED)

The details of the individual flight modes within each category doesn't
matter for stall avoidance.

The stall avoidance techniques available in the 3 categories are:

CAT1: no stall avoidance possible, pilot may in fact be deliberately
stalling the airframe

CAT2: stall avoidance via limiting bank angle is possible. We cannot
use throttle control in these modes

CAT3: stall avoidance via both bank angle limiting and throttle/pitch
control is possible (via the TECS controller).

> I diverge for a moment to note the autopilot does not have direct feedback from the motors.
> Eventually this needs to be corrected no matter whether petrol or electric power. Stall Avoidance
> needs to know immediately whether servo PWM signals to the throttle have actually added
> power.

that may be possible in the future with some types of ESC (eg. CANBUS
ESCs), or could possibly be inferred from current draw. I'm not sure we
actually need to know this though, as TECS will automatically put the
nose down if raising the throttle doesn't gain enough speed.

It would be useful to know if the motor is dead for a failsafe, where
the autopilot can do an emergency land on motor failure, but I think we
should leave that for a separate discussion.

> The event generator is a simple piece of code primarily responsible for calling the state machine
> with two indexes into the function table. The event generator always loads the new 32 bit Real-
> Time Counter (RTC) and the new Vccs into the state machine’s associated data structure. RTC time
> tags give states the ability to perform delays. The event generator does not decide anything based
> on state because that is accomplished by the indexing. The event generator may log exception
> conditions or trace the state machine if trace is enabled.
>
> The event generator could be called at the Plane 50 Hz loop rate, but I think no less than 10 Hz.
> State Machine decision making is as fast as indexing into an array of function handles. State
> machine function handlers may manipulate the Vccs stall thresholds used for comparisons by the
> event generator (1.3Vs, 1.2Vs, 1.07Vs). The event detects a speed level, however the state
> machine determines falling or rising edge. Flight Mode is the first index into the state machine.
> Event is the second index. Both are stored in the state machine structure, but are extracted and
> passed to the state machine execute function in order to extract and call the chosen function.
> Event indexes could be:

Have you had a chance to read through the current code so you understand
the structure? Discussions of general stall avoidance strategies are
very welcome, but this sort of detailed code structure suggestion
doesn't really help unless you relate it to the current code structure.

> Some of the 18 Flight Modes (states) need to progress through sub-states, for example when
> transitioning between modes. Following are suggested concepts of operation for Stall avoidance
> in each flight mode:

there seems to be some misconceptions on how some of the flight modes
work in your table. I'll add some notes below.

> FBWA MODE
>
> Stall is actively avoided in FBWA mode. Verbal stall warning triggers are sent to the GCS on the
> qualified event falling edge “IAS(ekf) is between 1.2Vs – 1.07Vccs” thus causing the GCS to say,
> “Approaching Stall, add power” because the pilot controls the throttle.
>
> When the event falling edge “IAS(ekf) is below 1.07Vccs” qualifies as valid, trigger the GCS to say
> once, “Avoiding Stall, leveling wings, lowering nose .” Level the wings using constant 20% aileron
> servo deflection until level or until IAS(ekf) rises above the original 1.3Vccs threshold.
>
> Simultaneously reduce the angle of attack by pitching the nose down 2 degrees per second, but
> not to exceed 6 degrees below the horizontal

We don't have a direct AoA measure in ArduPilot, so we'd need to proxy
it with pitch. Controlling pitch to avoid stall in FBWA mode is
problematic as it could lead to not being able to take off. A lot of
users takeoff in FBWA mode, and on the initial hand launch the airspeed
may be quite low, plus the airspeed estimate will be very poor if you
don't have an airspeed sensor as it won't yet have had a chance to build
up a wind estimate.

The patches I link to above do add bank angle limits based on load
factor in FBWA, which I think is fine. We may add a pitch limit later,
but I don't think we should go as far as pitching the nose down if the
user is asking for a positive pitch. If the user wants full staill
avoidance they should really be using an auto-throttle mode like FBWB or
CRUISE.

> The autopilot does not intervene to control the throttle because it violates the FBWB concept.

FBWB is in fact an auto-throttle mode, and uses TECS, so it can benefit
from the full stall avoidance strategy by adding power and lowering the
nose.

> AUTOTUNE MODE
>
> Stall avoidance is active in Autotune Mode by making GCS announcements and by limiting up
> elevator excursions. Otherwise, Autotune is treated like Manual mode –
> no intervention.

AUTOTUNE is actually the same as FBWA mode. The only difference is that
it learns attitude controller gains while flying. See FBWA comments above.

> TRAINING MODE
>
> Stall avoidance is active in Training Mode. Intervention is similar to Autotune Mode by making
> GCS announcements and by limiting up elevator excursions.

TRAINING mode is a full manual mode. It is designed for teaching manual
flight. Stall avoidance is inappropriate.

> CRUISE stall avoidance needs more throttle. However, the autopilot does not intervene to control
> the throttle because it violates the CRUISE concept.

CRUISE mode is a auto-throttle mode. CRUISE mode operates the same as
AUTO mode, except that the user controls where the target waypoint is
with the sticks.

> In LOITER Mode the autopilot is thought to control attitude but not
> throttle.

LOITER is an auto-throttle mode.

> TAKEOFF MODE

There is no separate TAKEOFF mode, it is part of AUTO, but the throttle
is set to 100%, and a target pitch is set in the mission.

> LANDING MODE

there is no 'LANDING MODE', it is part of AUTO, but with different
target airspeed.

See http://plane.ardupilot.com/wiki/flying/flight-modes/

I do like the suggestion of a GCS warning on approching stall, but we
need to find a way to prevent lots of false positives. For example, if
you are holding the plane on the ground before takeoff in FBWA mode then
the plane doesn't actually know it isn't flying yet. So it will think it
is stalled. We don't want the GCS to be shouting "stall warning" at the
user.

We could use some heuristics to guess if we are flying or not, and we do
use heuristics like that in other places in the code, we'll just need to
try to make it not too annoying.

Cheers, Tridge

[Francis Henderson]

Hi Andrew,

Once again I'm astonished how quickly new features are implemented.  For example, changing to use the much better external temperature reading from the airspeed sensor happened so quickly.

>>there are actually only 3 flight mode categories from the point of view of stall avoidance. They are:

>> 

>> CAT1) manual attitude control and manual throttle control (MANUAL,

>>       STABALIZE, TRAINING and ACRO)

>> 

>> CAT2) automatic attitude control and manual throttle control

>>      (FBWA and AUTOTUNE)

>> 

>> CAT3) automatic attitude control and automatic throttle control

>>      (CIRCLE, FBWB, CRUISE, AUTO, RTL, LOITER and GUIDED)

>> 

>>The details of the individual flight modes within each category doesn't matter for stall avoidance.

>> 

>>The stall avoidance techniques available in the 3 categories are:

>> 

>> CAT1: no stall avoidance possible, pilot may in fact be deliberately

>>       stalling the airframe

>> 

>> CAT2: stall avoidance via limiting bank angle is possible. We cannot

>>       use throttle control in these modes

>> 

>> CAT3: stall avoidance via both bank angle limiting and throttle/pitch

>>       control is possible (via the TECS controller).

Thanks for identifying the three (3) flight mode categories above.  It outlines very well in what Flight Modes the newly implemented Stall Avoidance code is working and what it does.  I believe all the Cat3 flight modes are near level flights so that the "dynamic load" (g forces) are primarily due to banking in a balanced horizontal turn.  Therefore correctly, vertical accelerations can be ignored.  As you imply, a safety margin between the stall speed and ARSPD_FBW_MIN speed should take care of small fluxuations in vertical accelerations.  However, if we ever change our minds about wanting to provide stall protection in Training Mode or Autotune Mode, then we might find ourselves limiting vertical acceleration.

>>.... TECS will automatically put the nose down if raising the throttle doesn't gain enough speed.

TECS automatic action is so much better than the 2 degrees per second nose down scheme I suggested.  I believe TECS will drop the nose to maintain minimum airspeed whether or not power is available.  I suspect a power loss event is detected (a separate discussion).

 

>>right now what we have is ARSPD_FBW_MIN, which is the minimum apparent airspeed the user wants the aircraft to fly at. Up to now this value has not been scaled for aerodynamic load factor. >>The patch set above fixes that, by both adjusting the bank limit to account for load corrected minimum airspeed, and adjusting target airspeeds in turns to account for the load factor.

>> 

>>I'd prefer to not add a weight and reference weight as parameters. Instead I'd prefer to just document how users should adjust ARSPD_FBW_MIN to account for adding weight to an aircraft. A >>wiki page describing the following would be ideal:

>> 

>> - how to estimate stall speed given aircraft dimensions

>> - how to measure stall speed using a flight test and log file

>> - how to adjust stall speed when the weight of the aircraft is changed

>> 

>>then we can keep the single parameter which captures the minimum speed for level flight, and let the code take account of adjustments for non-level flight.

>> 

>>The wiki page should also provide advice on how far above the stall speed that ARSPD_FBW_MIN should be set.

 

I will submit written contributions for the Wiki above.   I've already examined analyzing stall speed from wing dimensions, and I've written up how to do the flight test.  I think the on-line stall speed calculator is good enough. It matched my flight tested Vs. I wonder if you think so?  Link below:

http://adamone.rchomepage.com/design.htm#calculate

Thank you for this very thoughtful and detailed reply.  Now that I have free time, I plan to become more familiar with the code.  I watch your work every day on Drones-Discuss.

 

With Appreciation.

Francis "Nelson" Henderson

[Francis Henderson]

Hi Andrew,

I've written up what could be useful input for the New Stall Avoidance Wiki Page.  The MS Word and pdf links are below:

http://www.inertial-solutions.us/pdf_files/WikiStallSpeedInput.pdf

http://www.inertial-solutions.us/pdf_files/WikiStallSpeedInput.docx

Hope the content is helpful.

Francis

On Tuesday, November 11, 2014 10:51:41 PM UTC-5, Andrew Tridgell wrote:

[Evan Slatyer]

If anyone is interested, I've got an angle of attack sensor on my plane. It's essentially a US Digital MA3 encoder with a laser-cut vane on the shaft. Actually testing its accuracy is difficult (without anything to compare to), but the results seem reasonable so far. If anyone has a good way of testing it, I'd love to hear about it.

The MA3 outputs PWM, and the PX4 has plenty of spare timers to accept PWM inputs. I put it on the USART2 RTS pin since that's not connected to anything else. I think the encoders cost about $70 each, which isn't particularly expensive for a big plane.

Cheers,
Evan

[Francis Henderson]

Hi Andrew,

Will you please take a look at the link below.  It seems  “aerodynamic_load_factor” and “load_factor” are used interchangeably by mistake and that “load_factor ” is never initialized or loaded with any value.  Whereas, “aerodynamic_load_factor”  is correctly initialized to 1, and is later loaded with 1/sqrt(cos(bank angle)) as expected.

http://www.inertial-solutions.us/pdf_files/load_factor_inspection.pdf

Best Regards,

Francis

On Tuesday, November 11, 2014 10:51:41 PM UTC-5, Andrew Tridgell wrote:

[Francis Henderson]

Hi Andrew,

Quite possibly I should steer clear of such suspicions below since I am too new and fighting with GitHub getting resynchronized with the remote, and I have a lot to learn.  So, I am having second thoughts about having said anything about "load_factor", not wanting to make busy work,

I have been waiting for the 2nd I2C fix to release before I again fly the big plane with the long I2C airspeed cable.  Last time it was an analog cable..  Looking forward to the coming release.

Francis

[Andrew Tridgell]

Hi Francis,

No problem, I don't mind at all when people point out what they suspect
is a bug. In this case it isn't a bug. The variable load_factor is a
local variable inside the AP_TECS library. It is passed in from the
aerodynamic_load_factor in the main vehicle code.

The reason it works that way is the AP_TECS library doesn't have direct
access to the aerodynamic_load_factor variable, and doesn't have all the
information required to calculate it. So it gets passed in instead.

Cheers, Tridge