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
Understood. Anyway I rather use a static device to get rid of the inertia related issues.
Note the second hole. It provides the information needed to have an AOA indication.
If you have some manufacturing capabilities you can Do It Yourself.
Parameters identification is more fascinating to me, anyway I figure it's all down to personal taste.
The first one looks very well suited to model airplanes. I think the low airspeed in combination with rotation resistance is the largest obstacle to overcome, but I imagine it is do-able. You would need a very lightweight flying surface attached to the potentiometer. Really, knowing the exact AOA is not all that important, what IS important is knowing the reference (indicated) AOA that the airplane stalls at. Many useful calculations could be derived from that.
Nevertheless you can buy this kind of sensor
Or alfa beta vanes of reduced dimensions
It's hard to find a proper installation position. Sensor operation is affected by plane flight condition. Sensor need calibration.
There are a few reasons why making a vane like this isn't trivial.
Why is it so hard to have a direct measurement of AoA? What if we made a vane like the one below?
Thank you all for sharing.
As Georacer previously stated angle of attack direct measurement can be a problem for little airframes. That problem is also present for real size planes, at high flight speeds.
The base for this kind of estimation is the accurate knowledge of real plane dynamics. The issue is to reduce at minimum the flight test activities.
For a small plane, with a simple reliable Pitot, is possible to get a good AOA indication.
As soon as Open Air Data Computer project produces a reliable data system I hope it will be possible to work on AOA identification also on DIY little platforms.
Suppose you have the whole airplane polar. You flight at 100 km/h at 50 m altitude and the plane weight is 2 kg. With that data you can look-up the angle of attack. The problem is how hard you should work to have that information.
I can lend a hand on the topic
Thanks for the response, SHAQURMZ. It's good to hear that X-Plane is a viable asset for research, as well.
I have experienced the problem with response and parameter mismatch in FlightGear, so this is why I asked: I had fully defined the parameters of the aerodynamic coefficients and the motor thrust in a custom airplane, made test flights with manual control, accessed all possible data via the data server which FlightGear can raise and then ran Least Squares estimation on the responses, eg on the longitudinal axis.
The resulting aerodynamic coefficients came up different than the ones specified! Given that the dynamic model was supposed to be fully known and the estimation procedure still coming out flowed, I took this as a bad sign. So I built a simulator from scratch in ROS, which was the right step towards robotic system integration anyway.
Thanks for the interesting thread guys.
Hi Georacer, An analytical expression of the airspeed is copmuted offline before implenting in the code. It is the one that minimizes the L2 norm of the difference between the nonlinear (actual model) and the linear mode or the error as you mentioned in your comment. What is implemented in the code is an anlytical function of airspeed as a function of model parameters, IMU measurements and control inputs.
Yes you are right the knowledge of the aerodynamical model is required. X-Plane has several capabilities in designing your aircraft. I know it is not open as flightgear but it is still good enough to give you good representation of your aircraft. For, example, X-plane has the capability to specify the airfoil characteristic (lift, drag, pitching moment), Engine/throttle specifications, mass properties and some other parameters related to forces and torques (I didnn't explore them all yet). In X-plane you want find a place where you just input your 6-dof model, but you can express your dynamics by chosing the correct values for the parameters set by x-plane. This is how x-plane is built, to make it more user friendly I think. One good approach is to use the actual flight data and the x-plane flight data like in our case. We use flight data from flight tests using RC C17 airframe and x-plane data. Then you go into a process of dual tuning in order to make your x-plane model as much as possible describing your actual airframe. We are currently working on developing a system for fast, low computation in flight model identification that can be a good feature in arduplane code. We will keep you posted whenever we have updates related to this.
Andrew, looking to hear from you more about your work.