I recently figured out a way to use GPS 3-dimensional velocity data and the direction-cosine-matrix information in real time as a plane flies along, to estimate the 3 dimensional wind vector, and the 3 dimensional air speed vector, without a pitot tube or any other sort of airspeed sensor. It has been tested, and it works quite well.
 
The core of the theory for estimating wind speed is described here.
 
The basic idea is to first estimate the airspeed vector by relying on the fact that the determinant of the direction cosine matrix is equal to one. Therefore, when a plane rotates, the magnitude of the change in the GPS velocity is equal to the magnitude of the airspeed, times the magnitude of the change of the appropriate column of the direction cosine matrix. Then, once you know the airspeed vector, you can compute wind vector. Built into the algorithm is an immunity to any yaw error in the matrix.
 
The algorithm only works when the plane is rotating around the yaw or pitch axis, but not much rotation is needed, and once the wind vector is measured, it can be locked in during straight flights, and used to compute the airspeed even if the plane no longer yaws or pitches. However, when the plane is yawing and pitching, the algorithm produces a steady stream of up-to-date wind estimates, so it will work in situations (like the field where I fly) in which the wind varies in time and space.
 
As a bonus, the algorithm includes the vertical component of the wind, which of course is the slope or thermal lift, so we plan to develop a lift-seeking algorithm for sailplanes.
 
I want to thank Peter Hollands, who contributed a great deal to the development of the algorithm. He implemented the wind-compensation portion of the computations, made a lot of test flights, and wrote scripts to convert the raw telemetry to spreadsheets for analysis, and to kmz files for display in Google Earth.

Here is a jpg file, a spreadsheet, and a Goolge Earth kmz file, from one of Peter's flights.
 
Note in the kmz file that Peter has a plane icon to indicate which way the plane is heading, as determined by the direction-cosine matrix. Note that there is a very clear indication of the crab angle of the plane, so the firmware knows which way the plane is pointing, which way it is moving and which way the wind is blowing.
 
Peter's tests were successful, he was able to fly comfortably in heavy winds, including landing the plane in RTL mode.
 
Wind compensation is presently an option in the MatrixPilot code under the Source tab in the project repository, and will be available in the next release of the download code.
 
Once again, thanks to Peter Hollands and the rest of the UAV DevBoard team.
 
Best regards,
Bill Premerlani

Views: 13787

Attachments:

Reply to This

Replies to This Discussion

Paparazzi uses this same method to estimate wind speed and I can confirm the fact that it's pretty accurate; so infact you can make it with thermopiles as well. Of course given that you know the actual yaw of the plane gives you a more accurate estimate but still.
Great work Bill, I really enjoy your posts...

Regards,
Jose.

Hi

Very interesting article and description of the theory.

In the PDF file, you mention "Implementation will be described in a separate report", has it been released?

Regards,

A.

Having a method to estimate wind speed without a Pitot could be a great addition to an AP for small UAVs, great addition means robustness in poor conditions.  Flying many small UAVs in the rain can cause the Pitot to be plugged by a drop of water.  When the Pitot is plugged the airspeed measured is 0 and this causes severe problems most times the bird dives straight down into the ground quite dramatically.

When equipped with a Pitot you could compare the results from the DCM and the Pitot and when the difference exceeded a threshold you would rely on the DCM method until the Pitot started to behave.

Just my 2 cents,

wade

Hi - this is pretty cool.  In your wind estimation file, you mention that implementation will be described in a different report.  Is that report posted somewhere?

hi William,

i am very interested in your theory and tested the results with a fixed wing. Before the implementation i have tried to simulate the alghorithm with MATLAB and during the simulation and on the air the results are very successful. Now i am trying to implent it for my quadcopter. I guess the fuselage vector for the multicopter must be the third column of the DCM. But there may be a problem with the airspeed vector because it cannot follow the fuselage vector so fast like in the fixedwing. And when i get the change on the fuselage vector during the copter having an angle movement on yaw or pitch plane, the airspeed vector will change its direction and amplitude with a phase delay so the estimation will get an huge error. I am wondering is there any example implementation or any idea for the quadrotor platform?

Best regards

Kadir 

Very interesting idea. First of all, thank you for your contribution. By the way, I have some questions.

No.1

In your paper, 'residual yaw error' is introduced. What is that mean exactly? I guess that the error is induced from the difference between course(COG) angle and heading(yaw) angle. Is it correct?

No.2

In your paper, the vector F is used to represent fuselage vector. And you said that comes from 'the column of the direction cosine matrix'. Is it same as below equation?

F = DCM_B2I x [1 0 0]'

where DCM_B2I is direction cosine matrix from body-axis to inertial-axis, and [1 0 0]' is the unit vector aligned with x-axis of body-axis. So I guess F equal to [cos(pitch) x cos(yaw), cos(pitch) x sin(yaw), -sin(pitch)]'. Is it correct?

Best regards,

Seunghan Lim

What condition can you propose to validate wheter you can or cannot update the wind components? Besides checking if |F2-F1| is bigger then 0, or any threshold.

You talk about checking if the airspeed fuselage vectors rotate by approximatly the same. Can you explain in detail?

Best regards,

Francisco Correia

Reply to Discussion

RSS

© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service