Interesting post from the FlightGear blog via Curtis Olson:
Motivation
Air 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?
Comments
airspeed= 9.8/gz*gy/gz/sqrt((gy/gz)^2+1)
where gz =yaw speed
gy= pitch speed
with gz!=0
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.
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.
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 ... :-)
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?
@Jack C., I fully agree that all the certification issue will slow down the implimentation of such an airspeed tool... and probably will recieve lots of criticism.
@Andrew R. , the air desity is a good point. But this will be more or less importent to compensate any force that is generated aerodynamicly on the aircraft, I guess. But I think it could be estimated well by the altitude sensor. And prop revs are no problem if you use the right brushless ESC, isn´t it?
Interesting result Curt. I suspected that high speed may still be an issue. If you added throttle position/motor power and propeller speed, you may improve the accuracy at the high end by giving it a signal it can work with. Unfortunately, prop speed is less than easy to generate with the current hardware - not impossible though.
I think with the prop speed and power though, you will have to add in an air density variable. Have a look at the Selig/UIUC maths behind all their propeller test work here
It's basically a flight simulator which uses machine learning instead of aerodynamics & newton's equation. The reason airliners can't use a flight simulator to double check their instruments is the amount of certification required to upgrade anything.
Hey Curt,
your observation that the aircraft is responding differently to your control inputs, and than the link with this tragic accident is exactly what got me thinking about this years ago. And no matter if its a model or a full scale airplane, a good pilot has some kind of estimated airspeed controlling the aircraft (And it is the same for a car, boat... the human has to adjust and its control outputs) And the capability of the pilot is in my opinion highly connected to this feeling and understanding of the aircraft.
I also discussed this with other people on a chair of flight dynamics I was an assistent. But the feedback was poor and we agreed its a complicated issue. So my comment "genious" is not without reason.
I guess you have achieved something great.
Andrew: when you suggest using vertical acceleration perpendicular to the thrust vector, are you essentially describing the z axis of the accelerometer in the body coordinate frame? If I do that, not a whole lot changes in practical terms ... the fit remains pretty good at the low end of the speed range, and completely loses all fidelity in the upper part of the speed range.
Bojan: my experiment depends on observing that the aircraft responds differently to control inputs at different airspeeds. We pick some parameters that include the important control inputs (elevator, throttle) and the response (pitch rate, airspeed), then feed this to some sort of interpolater. Then in future flights we can hopefully feed these parameters into the interpolator and have it spit back an estimated or synthetic airspeed. My initial model does use bank angle as one of the input parameters so yes, if I continue to use that as a parameter, then the EKF accuracy is important. But I did try Andrew's suggestion which removes any EKF/GPS dendency and that also produces fairly plausible results on the slower end of the speed range.
Because of incidents like air france flight #447 and others, the aviation industry is interested in finding accurate ways to measure airspeed without needing to put a pitot tube out in the airstream and potentially have it subject to blockage by ice, water, insect nests, forgetting to take off the remove before flight cover, etc. There are much smarter people than me working on this. I'm not claiming any special knowledge, I was just thinking about the problem one afternoon and thought it would be interesting to try a little experiment with flight data I have on hand. I wrote a little blog entry, Chris picked it up and reproduced it here. If it gets people interested in the subject, then discussion happens, and maybe better ideas emerge that would work reliably in emergency situations. That would be great. And either way, the aviation industry is already pursuing this and probably way ahead of anything we are talking about here.
-
1
-
2
-
3
of 3 Next