Measuring airspeed without an airspeed sensor


Interesting post from the FlightGear blog via Curtis Olson:

Motivation

Air France #447Air France #447

On June 1, 2009 Air France flight #447 disappeared over the Atlantic Ocean.  The subsequent investigation concluded “that the aircraft crashed after temporary inconsistencies between the airspeedmeasurements – likely due to the aircraft’s pitot tubes being obstructed by ice crystals – caused the autopilot to disconnect, after which the crew reacted incorrectly and ultimately caused the aircraft to enter an aerodynamic stall from which it did not recover.”  https://en.wikipedia.org/wiki/Air_France_Flight_447

This incident along with a wide variety of in-flight pitot tube problems across the aviation world have led the industry to be interested in so called “synthetic airspeed” sensors.  In other words, is it possible to estimate the aircraft’s airspeed by using a combination of other sensors and techniques when we are unable to directly measure airspeed with a pitot tube?

Basic Aerodynamics

Next, I need to say a quick word about basic aerodynamics with much hand waving.  If we fix the elevator position of an aircraft, fix the throttle position, and hold a level (or fixed) bank angle, the aircraft will typically respond with a slowly damped phugoid and eventually settle out at some ‘trimmed’ airspeed.

If the current airspeed is faster than the trimmed airspeed, the aircraft will have a positive pitch up rate which will lead to a reduction in airspeed.  If the airspeed is slower than the trimmed airspeed, the aircraft will have a negative pitch rate which will lead to an acceleration.  https://en.wikipedia.org/wiki/Phugoid

The important point is that these variables are somehow all interrelated.  If you hold everything else fixed, there is a distinct relationship between airspeed and pitch rate, but this relationship is highly dependent on the current position of elevator, possibly throttle, and bank angle.

Measurement Variables and Sensors

In a small UAS under normal operating conditions, we can measure a variety of variables with fairly good accuracy.  The variables that I wish to consider for this synthetic airspeed experiment are: bank angle, throttle position, elevator position, pitch rate, and indicated airspeed.

We can conduct a flight and record a time history of all these variables.  We presume that they have some fixed relationship based on the physics and flight qualities of the specific aircraft in it’s current configuration.

It would be possible to imagine some well crafted physics based equation that expressed the true relationship between these variables …. but this is a quick afternoon hack and that would require too much time and too much thinking!

Radial Basis Functions

Enter radial basis functions.  You can read all about them here:  https://en.wikipedia.org/wiki/Radial_basis_function

From a practical perspective, I don’t really need to understand how radial basis functions work.  I can simply write a python script that imports the scipy.interpolate.Rbf module and just use it like a black box.  After that, I might be tempted to write a blog post, reference radial basis functions, link to wikipedia, and try to sound really smart!

Training the Interpolater

Step one is to dump the time history of these 5 selected variables into the Rbf module so it can do it’s magic.  There is a slight catch, however.  Internally the rbf module creates an x by x matrix where x is the number of samples you provide.   With just a few minutes of data you can quickly blow up all the memory on your PC.  As a work around I split the entire range of all the variables into bins of size n.  In this case I have 4 independent variables (bank angle, throttle position, elevator position, and pitch rate) which leads to an n x n x n x n matrix.  For dimensions in the range of 10-25 this is quite manageable.

Each element of the 4 dimensional matrix becomes a bin that holds he average airspeed for all the measurements that fall within that bin.  This matrix is sparse, so I can extract just the non-zero bins (where we have measurement data) and pass that to the Rbf module.  This accomplishes two nice results: (1) reduces the memory requirements to something that is manageable, and (2) averages out the individual noisy airspeed measurements.

Testing the Interpolater

Now comes the big moment!  In flight we can still sense bank angle, throttle position, elevator position, and pitch rate.  Can we feed these into the Rbf interpolater and get back out an accurate estimate of the airspeed?

Here is an example of one flight that shows this technique actually can produce some sensible results.  Would this be close enough (with some smoothing) to safely navigate an aircraft through the sky in the event of a pitot tube failure?  Could this be used to detect pitot tube failures?  Would this allow the pitot tube to be completely removed (after the interpolater is trained of course)?

Synthetic airspeed estimate versus measured airspeed.
Zoom on one portion of the flight.
Zoom in on another portion of the flight.

Source Code

The source code for this experimental afternoon hack can be found here (along with quite a bit of companion code to estimate aircraft attitude and winds via a variety of algorithms.)

https://github.com/AuraUAS/navigation/blob/master/scripts/synth_asi.py

Conclusions

This is the results of a quick afternoon experiment.  Hopefully I have showed that creating a useful synthetic airspeed sensor is possible.  There are many other (probably better) ways a synthetic air speed sensor could be derived and implemented.  Are there other important flight variables that should be considered?  How would you create an equation that models the physical relationship between these sensor variables?  What are your thoughts?

Views: 3131

Comment by Martin Rüedi on December 18, 2016 at 6:52am

Quote:
Martin: yes of course, basic pitch and power management should always keep you out of trouble.  When I setup my UAV's I will often set strict limits on max pitch angle and max elevator deflection so that it becomes almost impossible for the flight controller to enter the stall region.  But that said, there are use cases for synthetic airspeed.  The obvious one is when your pitot tube becomes obstructed with ice or rain or dirt or whatever.  Another use case (that I personally encountered) is a marine uav designed to be launched from a small boat and land in the water.  It would have been so nice if we didn't need to worry about making the pitot system water proof.

To add something more how this works in manned aviation:

The method complies with these requirements:
- sufficiently accurate and safe for all flight phases
- certifyable
- works exactly for the case of obstructed pitot tube

Steps:
1. There are pitch/thrust settings, which are memory items. These need to be established immediately and manually in case of unreliable airspeed
2. This gives the time to lookup the specific pitch and %N1 figures (for each configuration and flight phase), that would then be used to continue the flight

The point is, that even if the pilot would be provided a synthetic airspeed figure, he still is required to stay actively within a safe flight envelope. Only with the difference that the synthetic airspeed is much less accurate and reliable itself. So margins against overspeed and stall should be enlarged anyway.

What the SOP's in manned aviation accomplish on the other hand, is staying within the safe flight regime without bothering about airspeed at all. And for that purpose, it does not need more than having a lookup table with pairs of pitch and thrust values for any given flight phase.

Here everything is described (and as a bonus a system that at least adds a bit of automation, but is still based on the same pitch&power principles, see section 5):
http://aviationtroubleshooting.blogspot.ch/2009/06/af447-unreliable...

More is not needed. In manned aviation. So, why invest more to get less in the area of drones?

Comment by Curt Olson on December 18, 2016 at 8:43am

Hi Martin, I agree with everything you write.  Especially in the case of flight 447, it was ultimately a human mistake and a terrible tragedy that would not have had to be.  So why go down this path in the area of drones?  For me it's an interesting challenge.  Every once in a while an idea takes hold and grows and I have to scratch it somehow. :-)  The idea of using known physical relationships to extend the reach of the limited sensors we have on board drones has long fascinated me.  There could be immediate uses in self monitoring and reporting problems to the operator.  Pitot tubes specifically can have issues of blockage.  Here in minnesota we've seen typical drone airspeed sensors struggle in very cold weather.  In small drones, pitot tubes stick out awkwardly and they often get damaged just in normal handling and transport.  (We sometimes call that hangar rash in the RC community.)  There are specific use cases such as marine operations where not needing a pitot tube would simplify life tremendously.  In a past life I was involved in a NOAA UAS marine debris survey project.

For what it's worth, the estimator I propose here is far far far from perfect.  But as I run flight data through it, I observe that it is most accurate at the bottom end of the speed range ... between normal cruise speeds down to at or below stall speed.  On launch and landing it starts (or ends) reporting accurately well below stall speed ... I find that interesting.  I could imagine making use of this system (with little change) as a systems integrity monitor.  All that is needed to setup the integrator is past flight data (hopefully covering the speed ranges of interest.)  I would figure out the speed threshold above which the estimator becomes unreliable and ignore ut above that speed.  Below that speed I would start paying attention to the estimator and compare it with the pitot static airspeed.  The match should be close enough that it could report a problem, or serve as an alternative stall warning/safety system.

Now here's an issue: the system I prototyped uses scipy/numpy/python.  So would I run python on board the aircraft, or reimplement the necessary python libraries in C?  Would the estimator even run fast enough to be useful on board?  Or (as you suggest) perhaps it would be most effective to simply monitor pitch and power settings or possibly limiting pitch or elevator deflection to make it extremely unlikely that the flight controller could ever put the aircraft in an unsafe region of flight.

Here's a little story of a crash I had that is perhaps related.  A couple years ago we assembled a flying wing, but installed the pitot tube in a poor location (above the leading edge of the wing) with the static holes 1 mm from the surface.  Any aeroengineer will tell you that's a bad, bad idea, but let's say you inherit the airplane, the demo is 1 week away, you need to test fly it and someone higher ranking makes the final call.  The flight actually went quite well.  The pitot tube errors in cruise were significant, but could be calibrated out, so maybe despite my misgivings, everything would work out ok.  That was true until we attempted an autoland.  As the aircraft slowed down in the turn to base that pressure area above the wing where the pitot tube was mounted moved and increased.  This cause a bigger differential between static and dynamic ports which led the flight controller to think the aircraft was going faster than it was.  As the airspeed slowed, this error increased.  So the flight controller was happily holding the correct 'indicated' airspeed, while the actual airspeed was bleeding off in a negative feedback loop.  The airplane stalled and spun under autopilot control and because it was < 100' above the ground when it happened, there was no chance of recovery.  That is the only time I've personally seen a lipo ignite.

All I'm saying is that anyone who has done a *lot* of flying and will likely have their set of personal stories related to pitot tubes and airspeed.  A synthetic airspeed indicator won't fix human error (whether that happens when the avionics system is integrated or during flight) but maybe it could add another layer of fail safe and help in a few situations that would have otherwise been lost?  And if nothing else comes of this, I've had a chance to scratch an itch, try an idea, see what happens ... :-)

Comment by Martin Rüedi on December 20, 2016 at 6:30am

Hi Curt, I also agree with everything you said. If we really would want to calculate the best possible synthetic speed I just wonder, whether a different approach (more inline with basic flight performance calculations) would provide even better results.

I could imagine that the following software based approach could work:

- The polar curves are stored for each configurations. They allow to calculate the drag [N] at various speeds and weights.

- Similarly thrust curves [N] per power setting are stored too.- From a given thrust setting and the basic flight parameters (pitch, bank, vertical speed if possible), then the speed would be calculated. I feel, that a quite good approximation would be possible.

According to similar principles I programmed the MSFS autopilot 15 years ago, to keep speed constant by adjusting the pitch during an idle descend. At that time I used a very simple polar curve, retrieved by a very simple flight test: measure airspeed over time (starting at top speed and down to minimal speed) while flying with idle thrust and keeping the altitude. This test easily yields the drag in [N] at each speed.

Comment by Matt on January 3, 2017 at 11:04am

Hello, I know I'm late to the party, but I find this very interesting and was wondering why it cannot be a "both together" approach?

For example, have the main speed determined by the pitot, but at the same time run the software solution and do regular comparisons. If the deviations are too high, then it could either be the flight regime (as shown in the deviations in the graph), or for example, if there is a sudden drop in pitot signal, it could indicate that there is a malfunction, and then steps could be undertaken to remedy the situation.

Also, with both pitot and software in parallel, the software could be regularly "calibrated" against the pitot, provided that it is found safe to do so (i.e., the pitot signals don't indicate any problems). Just a thought, I think this is really interesting.

Comment by eduardo on March 26, 2019 at 8:36am

airspeed= 9.8/gz*gy/gz/sqrt((gy/gz)^2+1)

where gz =yaw speed

gy= pitch speed 

 with gz!=0

Comment

You need to be a member of DIY Drones to add comments!

Join DIY Drones

© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service