We have been working for some time on a way to estimate and display important flight parameters such as angle of attack, estimated airspeed (on UAVs that do not have Pitot tubes), side slip angle or flight path vector (FPV) using a simple, robust dynamical model of the UAV and a computational method that is both fast and has computational time guarantees.
Using a hybrid systems approach, the problem boils down to finding a set of analytical solutions to least squares problems, and to identify which solution is the most likely based on an analysis of the residuals. The method executes in real time, at 50 Hz, on an APM. We tested it using hardware-in-the-loop simulation (with X-Plane). As you can see from the video, the real and estimated airspeed closely match (we added some noise to the X-Plane generated IMU data to simulate the actual performance of the APM's IMU), and the FPV/AOA/sideslip evolve realistically.
Because the dynamical model used in this algorithm is fairly robust, it requires only a small number of parameters to work. More details on our WIP paper at RTAS 2014: https://www.mpi-sws.org/~bbb/proceedings/rtas14-wip-proceedings.pdf
Comments
Christian, read your paper. If I get things correctly, for each Force and Torque axis, you evaluate the sum of the forces and torques, based on gyroscope and accelerometer readings. Then you subtract gravity and thrust force and torque to get the aerodynamic effects in order to produce the estimation error, through which you find the airspeed.
However, this can only be done if you know the aerodynamic and thrust model of your plane. I know that for each aircraft Flight Gear allows you to examine the parameters you mention, but does X-Plane allow you to do so as well, being closed-source and all...
Congratulations to Christian et al. I think this sort of work is very inspiring.
A virtual sensor has many advantages and can be used for error checking on real-world sensing systems as well as improving the capability of simple systems.
I've also wondered whether a karman vortex sensor could be used to directly measure true airspeed with more accuracy than the traditional pitot-static system, but it doesn't solve the same problem that Christian's work is doing.
I've been slowly working from the other direction on the maths behind a completely physical model-based flight control algorithm which I need to somehow translate into code to test, but coding isn't a strength of mine. It requires direct measurement of airspeed in some form, so not directly comparable to Christian's effort. I hope to publish a short explanation of my ideas in the near to see I can win some help with the coding effort.
There currently are efforts to incorporate more accurate airspeed sensing than what we get with the cheap $10 probe we are now using with APM and relevant systems.
The devil is in the details, though, and such systems need rigorous calibration and high sampling rates, which, in turn, requires expensive sensors. This is all the more true for AOA sensing via multi-port probes.
My current view is that we won't get such systems in sub $2000 DIY UAVs for the next few years. But, of course, I hope I'll be proven wrong.
A friend of mine has made some jabs in accurate and reliable airspeed sensing, via hardware. He has posted about it here, I think, but here's the link anyway: http://basicairdata.eu/
Now of course the tradition transducer system would not work at our scale, and that doesn't even touch on the aerodynamic complications of such a small vane, but just as we prevailed before, we could do so again. My idea would incorporate an octagonal side-mounted sensor that would work similar to our current pitot system. It would have numerous inlets, at least one on each face. By comparing the inlet pressure of each inlet you could calculate the measured AoA. Cross reference with an algorithm similar to what's posted, and you could end up up with a very accurate system. For yaw and slip sensitive aircraft, the same sensor could be mounted on top (horizontal)
Because you can't mount something like this on a 2.5kg Skywalker. It's a sizing issue really. Let alone the cost, which is at the $1k level.
Thx for explanations. Might be a stupid question but then why not more simply measure AOA and other parameters rather than estimating them via simulation/computation?
Hugues, I will attempt to make this as simple as possible.
First, lets explain why there is a stall speed and why it is incorrect. First off, a wing stalls at a certain angle of attack. This generally can vary very slightly with speed, but we are talking less than 1/2 a degree. So in general it is safe to say that wings will always stall at a certain Angle of attack. Of course, as the angle of attack goes up, the more lift a wing makes, all the way up until the stall threshold. This being said, lets say your aircraft weighs 20 pounds, at 80 mph it might make plenty of lift at 1 degree AoA, however at 25mph it might need to be at 6 or 7 degrees angle of attack to make up for the lack in speed (yet still maintain enough lift to carry that 20 pounds). Therefore to maintain level flight, carrying a set weight, you must adjust angle of attack. This "generally" translates into a stall "speed" because at a certain weight, and a certain speed, you need "x" angle of attack to maintain flight. The aforementioned notion is entirely wrong, however. A stall can also be forced on an aircraft. The best example are fighter or aerobatic aircraft that can sustain extreme "G' forces in a turn, as the AoA increases in a sharp turn, it could easily stall the wing at 10x over the stall speed. THAT is why military aircraft, and most airliners, fly AoA instead of airspeed.
I hope this helps.
Thanks all for your comments.
The estimation method we use is not based on Kalman filtering or artificial neural networks. It is actually much faster than these methods, since the solutions are analytical (each time step requires you to compute a fixed matrix times a vector, and to find the resulting vector of least norm). To make it more accurate, we plan to use L1 regularization for instance, to have a "sparser" result. We'll keep you posted on these developments. Right now our objective is to make the code as compact, fast and easy to install as possible, and accuracy is already pretty good (with less than 1m/s error in the airspeed in average)
Also, the algorithm we use is fundamentally different from the EKF/complementary filter that is built in, in the sense that the estimated airspeed, angle of attack and sideslip is not obtained from position measurements (in fact our algorithm doesn't use the GPS data nor the magnetometer data at all. It only relies on IMU data: accelerometers and gyros, as well as elevator, aileron, rudder and throttle settings). These estimates are obtained using a dynamical model of the UAV, i.e. the input-output characterization of the UAV (thrust model, aerodynamic force model). Therefore this method captures the real time effects of the wind (i.e. gusts), which are averaged out in the GPS based methods. The GPS based method also assume zero sideslip, which we do not here (you can see the sideslip estimates on the video (also from the FPV), and as you can see in steep turns the plane slips inside the turn).
And yes, it would be cool to add stall protection, it shouldn't be too difficult: you could modify the elevator response in the code so that elevator inputs commands an angle of attack (less than the stall angle) rather than a servo position past some angle of attack threshold (like in Airbus A320-330-340-380). This would work much better than the pitch and bank angle limits.
-
1
-
2
-
3
of 3 Next