Measuring airspeed without an airspeed sensor

Interesting post from the FlightGear blog via Curtis Olson:


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.”

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.

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:

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.)


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: 3371

Comment by Jason Franciosa on December 15, 2016 at 5:37pm

Very interesting! I have not heard of the AuraUAS Autopilot system, is it designed for APM2?

What I would really love to see is a low cost Angle of Attack sensor for sUAS Planes. Get rid of the airspeed sensors all together and just use AoA and Ground Speed.

I think this would be the ultimate solution for mapping systems when flying in windy conditions as it could try to match the desired groundspeed as much as possible and safely fly in near stall airspeeds to reduce ground speed during a tail wind and have nice clear images. Also, for efficiency, if you know what the optimal AoA is for flight efficiency for a given aircraft, you can optimize it much better than maintaining just the airspeed.

Comment by Andrew Rabbitt on December 15, 2016 at 6:18pm

(response cross posted from Curtis's blog)

Awesome work Curt!

Curious why you chose bank angle though. I would suggest vertical acceleration in the aircraft coordinate reference frame would yield a closer approximation and be less dependent on the results of IMU fusion/EKF/WHY. Maybe I’ve got this wrong though – just thinking out loud.

Comment by Curt Olson on December 15, 2016 at 9:09pm

Jason: AuraUAS is an independent effort.  It is primarily a linux app (think raspberry pi, beaglebone, gumstix, etc.) that handles the EKF, PID's, missions and tasks, logging, and communication.  All the sensor and servo IO happens on a hard real time system.  The 'reference' implementation uses an APM2.x with custom firmware as the sensor head.  For python fans, AuraUAS has a *lot* of python under the hood and over time I am migrating more and more of the code to python.  I've been developing the system since roughly 2007 so in many areas it is quite mature.  My focus has been to develop a quality core application, and I've shied away from chasing support for every sensor and every board and every idea so I can try to keep the system as simple as possible.  (I'm very happy other projects do try to be a big tent for everyone, every idea, every sensor, etc. because that is also needed and healthy in the community.)

Comment by Curt Olson on December 15, 2016 at 9:20pm

Andrew: My thought process with choosing bank angle is that cos(bank angle) gives you something proportional to the vertical component of lift.  If you roll into a bank, your nose will drop and you will accelerate (if you don't correct with other controls.)  There may be a more direct way to estimate this effect as you suggest.  I'll need to think about it.  (I have pretty good confidence in the EKF I"m using.)

You may notice in on of the graphs that the peak speeds are missed in the estimator ... so that tells me that the parameters I've chosen don't fully convey the relationship with airspeed and there are additional parameters (or different parameters?) that need to be considered in the model for a better fit.

Another thing I'd like to purse when I have more than an afternoon to fiddle with this is to come up with some physics based equation that relates all these parameters (or better yet, all the correct parameters related in the correct way.)  Then I could throw all my flight data into an optimizer and find coefficients that lead to a best fit.  Ultimately I think that would be a better solution in many ways, but it probably will take much more effort to come up with a representative equation that relates all these parameter correctly.

Yet another interesting idea I heard suggested by one of my coworkers would be to do some frequency analysis in real time.  There should be a short period pitch oscillation in any aircraft that is proportional to airspeed.

And then as Jason suggested in the first comment.  If we had an angle of attack sensor available that would make other useful flight control strategies possible.

Comment by Andrew Rabbitt on December 15, 2016 at 10:41pm

Hi Curt,

My thoughts on choosing vertical acceleration were that lift force is proportional to the square of IAS so, by the time you take elevator position and pitch rate - all directly measurable - you've basically "eliminated all the variables" involved in generating lift force for a fixed-wing (assuming no flaps and a consistent CL-alpha curve). The only flies in the ointment are that vertical acceleration is mass-dependant so the calibration will need to adjust for this but also angle of attack will orient the aircraft frame of reference to add in horizontal acceleration and deceleration.

FWIW, I have been working through the maths on a completely phenomenological model-based controller algorithm but thrust estimation becomes important because it represents a substantial proportion of lift at high angles of attack, which is where you want such a controller to operate well to fly right on the edge of stall. Actually, what I was think of was to generate a target net acceleration vector and use that and the measured acceleration vector to generate a control error term with each axis of the error vector driving the appropriate control surface/throttle (depending on orientation)

Your RBF solution might not be as "pure" but the simplicity is very appealing as once you have a reliable speed estimate you can expand the operational envelope of a simpler linear control system much closer to the edge compared to what is currently flyable.

Comment by Martin Rüedi on December 16, 2016 at 3:46am

Why not do it the way real pilots do (the way the AF447 pilots failed to accomplish)?

Boeing instructs the following actions for a safe recovery from the "unreliable airspeed"-condition:

Maintain control of the airplane with basic pitch and power skills.

  • Establish a pitch attitude and power setting that are appropriate to the situation

From here: click!

Setting correct power and pitch will always put an aircraft within the safe flight envelope. Of course flying like that is much less precise and the flight performance is much less predictable. Flying according to flight plans is strongly impacted and requires higher safety buffers.

Comment by Curt Olson on December 16, 2016 at 6:01am

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.

Comment by Curt Olson on December 16, 2016 at 6:05am

Hi Andrew, you are probably right in your analysis.  My background is computer science so I'm just pretending to be an aerospace engineer here.  You don't have to dive deep to start finding the gaps in my knowledge base.  If you could condense your suggestion down to a sample formula, maybe I could test it out now that I have the code and infrastructure in place to run this on sample flight data.

For what it's worth, I observe that my rbf estimator seems to track much better at low speeds and loses fidelity at high speeds ... maybe that's in part to not properly considering that lift is proportional to the square of IAS?

Comment by Paul Schreiber on December 16, 2016 at 8:55am

Damned that is f*ckn genious! Honestly, a big applause from me.

In terms of safety, redundancy and hardware simplicity this is a quite a step forward.

As you speaking from more reasonable input parameter in your "black box" (so cool) I like to propose some. Not claiming these are better, just different.

I guess you use are using an electrical engine with current and voltage sensor, so:
1. Power consumption from the motor, and 2. prop revs. (What actually matters is the torque, but the power consumption should discribe that value reasonable)

If I have understand your black box principle correct I think this two parameters should also work. A limit is probably a propeller with a not to high pitch/diameter value (everything with smaller or equal one is smooth), otherwise the power consumtion is changing less at low speeds.

Again great work!

Comment by Paul Schreiber on December 16, 2016 at 10:51am

Just got the hint you are not playing with drone stuff. So please ignore my quess you are using an electrical powered plane.


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

Join DIY Drones

Season Two of the Trust Time Trial (T3) Contest 
A list of all T3 contests is here. The current round, the Vertical Horizontal one, is here

© 2020   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service