Replies to This Discussion

DeveloperPermalink Reply by Doug Weibel on October 2, 2010 at 6:36am

Hello Stephane

You are right in that we do not correct the wind in the present code. It will be a future upgrade. There are various ways that you can compute the wind. In fact you can do it without the magnetometer. Search the site for a post by Bill Premerlanni describing an algorithm he developed to compute the wind based on measuring changes in the rotation during turns. We have not decided what algorithm we will use. Perhaps we will use Bill P's as not everyone uses a magnetometer.

The core functionality of APM for fixed wing application does not really require knowing the wind. The way that we compute yaw will cause the indicated yaw to be biased to counteract the effect of a crosswind within a matter of seconds. However we do plan to add a wind calculation for doing more advanced things like your suggestions.

• ▶ Reply

Permalink Reply by William Premerlani on October 2, 2010 at 10:12am

Hi Doug,

Thanks for the mention of wind estimation algorithm. Here is a link to the theory.

When the wind is constant in time and space, the algorithm works very well. If it is changing in time or space, it takes a few seconds for the algorithm to track the new value.

Attached is a picture showing the track of my EasyStar on a windy day. The yellow arrows indicate the computed wind vectors, without benefit of a pitot tube or a magnetometer. The plane icon indicates the orientation of my plane.

The computed wind direction matched pretty well with manual measurements.

Best regards,
Bill

• ▶ Reply

Permalink Reply by Stephane Rocca on October 2, 2010 at 10:43am

Hello Bill,

Really nice job !
I was writing my answer, so I didn't saw your post before to launch mine.

In your pdf, you explain you can compute, even with pitch variations, without yaw variation. It seems to be robust on this picture : is that as robust with only pitch variations ?

With a 10Hz GPS, at what minimal time do you think you can decrease the update of wind vector ?

Thanks

• ▶ Reply

Permalink Reply by Curt Olson on October 3, 2010 at 4:30pm

Hi Bill,

I've looked at your theory write up again (and have browsed through it in the past as well.) I currently have a mechanism for estimating true wind speed and true airspeed that is working pretty well, but it would be fun to play with your approach to see how they compare. I don't have a DCM matrix handy on my system; I've always worked with euler angles and quaternions so I don't think in DCM's. But I do have a pretty accurate phi, theta, psi (roll, pitch, yaw) in the NED frame. How much effort would it be to reformulate your equations based on phi, theta, psi, instead of the DCM or are there other magic elements of the DCM that are required to make this work?

Thanks,

Curt.

• ▶ Reply

Permalink Reply by William Premerlani on October 5, 2010 at 5:32pm

Hi Curt,

Once you have air speed, there are any number of equally good ways to use it and ground speed to estimate wind speed. The focus of the method that I describe is computed air speed without a pitot.

The basic idea is to take the ratio of the magnitude of the change in ground speed vectors, divided by the magnitude of the change in the orientation vector extracted as one of the columns in the DCM.

The simplest way for you to try it out is to compute just those three elements of the matrix from the roll, pitch, and yaw angles. What you need are the three direction cosines of the angles the fuselage makes with the X, Y, and Z earth axes. There any number of websites that will show you how to do it.

Best regards,
Bill

• ▶ Reply

Permalink Reply by Stephane Rocca on October 2, 2010 at 10:21am

Hello Doug,

And thanks for your answer, I had a look on the Bill Premerlani's method : that's great ! And whitout the expensive magnetomoter and pitot tube... Impressive...

I just give you my personnal fealing (if it can help), as a paraglider pilot (you seams to be pilot too, so you already know that) : paraglider flies at approx 35 km/h, which is low speed. Even in a relative calm weather afternoon, you can find a HUGE thermal, just coming from nowhere ! The effects on instant air speed variation are very radical : this is the reason why we can have very big collapse of the glider, and other dangerous behaviour of the wing.

The most dangerous is a rear top coming gust : with low airspeed aircraft, you can be in an instant stall condition, which is a really, really bad situation !
If you still can take the manual control of the aircraft, it's ok (with a bit of adrenalin), but at the moment, the alpha APM loop may loose its matrix for a while...

Sure it's not a concern in many usage of the board / aircraft, you're true.

Do you know other differents algorithm we can use on that specific point ??

• ▶ Reply

DeveloperPermalink Reply by Doug Weibel on October 2, 2010 at 3:20pm

Hi Stephane,

If I understand your point correctly then no, it is not a concern. The DCM algorithm will not loose track of the correct orientation in a stall condition unless the rotation rate exceeds the limits of the gyros. Even in this case it will not "tumble", but will be off by some amount in one or more axis for a bit. It will self correct fairly quickly, and for most airframes a stall will not produce nearly fast enough rotation rate to saturate the gyros. I have looked at many flight logs from ArduPilot and APM which included stalls, spins, and even smooth aerobatics, and in general the AHRS portion of the system always stays pretty true to real orientation.

We have many in the community that fly "slow" aircraft, and I have joined the group recently with a Skywalker, so have a greater appreciation of the problems associated with them than I used to. Full scale I fly a high performance sailplane, and have no worries of collapsing a wing ;)

For slow aircraft the majority of UAV problems I have seen (IMO) come from people not respecting the stall characteristics of the aircraft. UAV's are configured with speeds too low for the bank angles permitted, especially taking into account gust factors. A large percentage of people are not using airspeed sensors which exacerbates the problem. I think that if you stick to basic aerodynamics you can work through most mission/performance problems. If you are going to want 45 degree bank angles, you have to understand that you cannot fly at 1.1 times the zero bank stall speed. If you want to fly in winds of 10 gusting 20, again you cannot fly near the benign stall speed.

We have put some "exception" code (eg the "crash checker") to catch and assist recovery when bad things happen. If you try any other ideas and they appear beneficial after flight testing we'd love to hear about them.

• ▶ Reply

Permalink Reply by Stephane Rocca on October 3, 2010 at 3:25pm

Hello Doug,

I agree with you on all that points... I hope you don't believe I'm trying to explain you how to code that board !! So I tell you again : you did an impressive work on that : no contest is possible !

What I wanted to say is :
- flying in auto mode without a pitot tube is at your own risk... Especialy if your plane is a slow speed one. When the weather is strong, even with pitot tube, it could be a good practice to detect gusty conditions and other environnemental parameters, in order to improve security parameters like the bank angle limit and others... To prevent stall, for example.
- to detect wind variations at a high frequency, a magnetometer appears to be necessary (but perhaps I should take a look at the Bill's script).

Everything is there :
" If you want to fly in winds of 10 gusting 20, again you cannot fly near the benign stall speed."

In other words, something like this :

if( MEAN_delta_wind_speed > 5 ){
target_speed += MAX_delta_wind_speed + 2;
if( target_speed > max_airplane_speed ){
Go_back_home("hurry!!")
}
}

But the impact on CPU and RAM may perhaps be dramatic...
Keep on your great work,

Regards

• ▶ Reply

Permalink Reply by Tero Koivunen on October 5, 2010 at 11:30pm

Wind vector changes with height...
And one thing what happened to me, when wind was too strong (with AP):
http://diydrones.com/forum/topics/dont-be-too-exited-you-take
I ordered new APM + IMU + Airspeed sensor + Compass module(magnetometer out of stock) ;-)

• ▶ Reply

Permalink Reply by Dave Whittington on October 6, 2010 at 5:36pm

I have asked our APM coders to consider adding Mr. Premerlani's code to the APM world when they get a chance (Issue #174).
I made a guess at the required code based on the scaled fixed point code for the UavDEVBoard and Bill's Wind Estimation paper that he points to above. I don't know how to connect it to the APM DCM matrix column nor compute the GPS NED components but here it is anyway for your perusal - it's not very complex and it should only be calculated about every second or when the yaw angle changes by several degrees:

//Estimated Wind Vars
float groundVelocityHistory[3] = { 0.0f , 0.0f , 0.0f } ;
float fuselageDirectionHistory[3] = { 0.0f , 0.0f , 0.0f }
float estimatedAirspeed = 0.0f ;
float estimatedWind[3] = { 0.0f , 0.0f , 0.0f } ;
float groundVelocity[3] ;
float groundVelocitySum[3] ;
float groundVelocityDiff[3] ;
float fuselageDirection[3] ;
float fuselageDirectionSum[3] ;
float fuselageDirectionDiff[3] ;
float magVelocityDiff ;
float magDirectionDiff ;
float magHorizontalVelocityDiff ;
float magHorizontalDirectionDiff ;
float angleVelocityDiff ;
float angleDirectionDiff ;
float thetaDiff ;
float costhetaDiff ;
float sinthetaDiff ;
int EstWindex;
float EstWtemp;


//Estimated Wind Code
void rect_to_polar(float x, float y , float& angle, float& magnitude)
{
//Defined so that x=-1.0, y= 1.0 results in angle = 135 deg and 1.41 magnitude
// angle (deg) = (180.0f/3.1415925f)* atan2(y,x);
angle = atan2(y,x);
magnitude = sqrt(x*x+y*y);
}


void estimateWind( void )
{


//DHW - need to interface to GPS.x/y/z and fuselage X column of DCM - execute once a second!
// The next six lines are for TEST ONLY

groundVelocity[0] = 1.0f ;
groundVelocity[1] = 0.1f ;
groundVelocity[2] = 0.1f ;


fuselageDirection[0] = 1.0f;
fuselageDirection[1] = 0.2f ;
fuselageDirection[2] = 0.2f ;

for ( EstWindex = 0 ; EstWindex < 3 ; EstWindex++ )
{
groundVelocitySum[EstWindex] = groundVelocity[EstWindex] + groundVelocityHistory[EstWindex] ;
groundVelocityDiff[EstWindex] = groundVelocity[EstWindex] - groundVelocityHistory[EstWindex] ;
fuselageDirectionSum[EstWindex] = fuselageDirection[EstWindex] + fuselageDirectionHistory[EstWindex] ;
fuselageDirectionDiff[EstWindex] = fuselageDirection[EstWindex] - fuselageDirectionHistory[EstWindex] ;
}


rect_to_polar(fuselageDirectionDiff[0], fuselageDirectionDiff[1], angleDirectionDiff, magHorizontalDirectionDiff);


rect_to_polar(groundVelocityDiff[0], groundVelocityDiff[1], angleVelocityDiff, magHorizontalVelocityDiff);

thetaDiff = angleVelocityDiff - angleDirectionDiff ;
costhetaDiff = cos(thetaDiff) ;
sinthetaDiff = sin(thetaDiff) ;


rect_to_polar(magHorizontalDirectionDiff, fuselageDirectionDiff[2], EstWtemp, magDirectionDiff);

rect_to_polar(magHorizontalVelocityDiff, groundVelocityDiff[2], EstWtemp, magVelocityDiff);

//MINROTATION should be maybe 2 degrees or so - don't really know

#define MINROTATION ( 0.2f * 1.0f )

if ( magDirectionDiff > MINROTATION )
{


estimatedAirspeed = magVelocityDiff / magDirectionDiff ;

EstWtemp = estimatedAirspeed * (costhetaDiff * fuselageDirectionSum[0] - sinthetaDiff * fuselageDirectionSum[1]);


estimatedWind[0] = (groundVelocitySum[0] - EstWtemp ) / 2.0f;

EstWtemp = estimatedAirspeed * (sinthetaDiff * fuselageDirectionSum[0] + costhetaDiff * fuselageDirectionSum[1]);


estimatedWind[1] = ( groundVelocitySum[1] - EstWtemp ) / 2.0f;

estimatedWind[2] = (groundVelocitySum[2] - estimatedAirspeed * fuselageDirectionSum[2]) / 2.0f ;

for ( EstWindex = 0 ; EstWindex < 3 ; EstWindex++ )
{
groundVelocityHistory[EstWindex] = groundVelocity[EstWindex] ;
fuselageDirectionHistory[EstWindex] = fuselageDirection[EstWindex] ;
}
}
return ;
}

• ▶ Reply