### Fly-by-polar

Airspeed control is critical when flying sailplanes.  You want to fly close to stall but never beyond it, since that will normally cause a tip stall and great loss of energy.  How do you teach an autopilot to fly on the edge of stall?

One solution is to teach the autopilot about the aircraft geometry and aerodynamics.  First you start with the wing section.  From the wing section you can use a simulation tool to generate aerofoil polars (picture above from XFLR5).  These polars describe the lift, drag and moment coefficients generated at different airspeeds and flap settings.

From the aircraft position and the amount of corrective pitch movement you need, you can calculate the acceleration you require from the wing.  This is known as load.  From load, geometry and aircraft mass, the lift coefficient can be calculated.

From lift coefficient and the wing polar you can calculate the required angle of attack for the wing.  From the required angle of attack, you can calculate required elevator pitch.

From the wing polars, you know the maximum possible lift coefficient.  Now you can avoid increasing angle of attack beyond Cl(max) and avoid stalling.  This is only half of stall prevention.  The other half is in energy management.

Both when gliding and under power, the aircraft loses energy due to drag.  For a glider this determines the descent angle.  For a powered aircraft it determines the engine power.  By using the estimate of drag coefficient from the wing section polar, the autopilot can set the target climb/descent rate and pitch angle.  When power is applied, it adds energy to the system so the estimated climb rate and target pitch increases.

Working in combination with basic estimated climb rate is airspeed error feedback.  Airspeed error is converted into meters of potential energy error and added to the target pitch.  The combination of target estimate and energy feedback are great for stall prevention.

Document describing airspeed by energy management

If you change flap settings then the wing polar changes.  As the flaps are changed, the autopilot has to interpolate between the different wing flap polars.  The result is a smooth transition between airspeeds.

This method also automatically re-trims the elevator for different airspeeds.  It also automatically does airspeed control fadeout.  It also reduces dependency on PID gains.  Some optional gains are still required for different flying styles.

One problem with this method is that it relies on knowing the initial wing-elevator incidence.  At high airspeeds the aoa is small and sensitivity to change is high.  The solution is to have a feedback from the accelerometers comparing to calculated load.  This error feeds an integrator which retrims the elevator.  The result is an even better trim for low speed flight.

Despite all the stall prevention, my first test flight resulted in terrible tip stall when turning downwind.  Adding a little bit of extra airspeed command resulted in lovely smooth turns.  When I went back to the estimated airspeed calculation, I had set airspeed setpoint 2m/s too slow.

If this all sounds new, it isn’t.  It is simply re-applying the basics that we know about aerodynamics.  If you are interested in aerodynamics basics you might start here

The project is based on a branch of MatrixPilot based here:

https://github.com/crashmatt/MP_Aerodyn

The original Matrixpilot project wiki is here:

Aerodyn uses the MatrixPIlot code base for hardware drivers and IMU.  My thanks go to the MatrixPilot team for their support and innovation.

The Aerodyn project also uses a flexible field programmable mixer which is used to move the flight surfaces with accuracy.  This is used to fly this 5m, 10 channel aircraft.  More about that later.

• Great discussion Matt!  Thanks for posting.  Sorry I do not have anything intelligent to add other than to say how enjoyable and educational it is to read a technical discussion.

Cheers,
Andrew.

• @Wayne,

I look forward to introducing you to UDB and MatrixPilot

One of the functions that got thrown under the bus while building this project was autopilot control of throttle.  I figured that if the glider is close enough to the ground to need throttle, I want to be in control of it.  Putting throttle control back is no big issue.

Also, having autopilot control over a 2.5kW motor makes me nervous, no matter how many times I have reviewed the code.

• @bill, Thankyou so much for your support.

@everyone

For those of you who don't know, Bill is the originator of MatrixPilot and it's world class IMU. Bill has worked with Paul Bizzard to bring some heavyweight contributions to the amateur autopilot world.  Many of their innovations have been transferred to other autopilots, including Ardupilot. I can't overstate how important their work has been for us.

There are many more contributors to the MatrixPilot project including Ben Levitt (code architect) and Pete Hollands.  Without the regular chats I have with Pete, this project would have gone off the rails long ago.

• Kees,

Thanks for your support.  I know you have had enthusiasm for this for a while.  I owe the community a good stable working branch to work from.

MatrixPilot_fbw was the branch.  SVN became too difficult to maintain branches so I moved it out to github on the new name MP_Aerodyn.

https://github.com/crashmatt/MP_Aerodyn

Having said that, the trunk is a little broken since I had some early user problems learning github.  Hope to tidy that soon.

Regards Matt

crashmatt/MP_Aerodyn
MatrixPilot for UDB with alternative control based on aerodynamics - crashmatt/MP_Aerodyn
• 100KM
Matt, I can tell we are going to have some very interesting conversations revolving around this idea.

Not only will it help gliders but it will help powered aircraft to avoid occilations which cause drag and premature servo and control ware. So you are using the matrix pilot? Ill have to get me one.ill thow you a pm ;-)
• Moderator

Yep that's it Matthew bring on the era of elegant flight!

• Hi Matt,

Great work. this will help to make glider-flights longer and more efficiënt. Very nice.

I would like to see a branch on UavDevBoard devoted to (e)-gliders and glider missions, so that more people could use that "on the fly" on their models.

Regards,

Kees

• @Gary, now I understand why you think PX4 when you see this.

• Wayne,

I did see your proposal and hoped you would respond to this.  I was half way through this project build when you sent the proposal.  To be honest, I was very focused on getting my own idea done before the flying season. I did not want the distraction at the time.

One of the targets of this project was to remove the need for estimated control gains so the control surfaces are doing exactly what you say.  That is why there is a "elevator pitch demand table".  It translates elevator angle position into the fractional integer units used for the mixer input.  This is not ideal but it is the lesser of two evils.  The other evil is user-autopilot mixing.

Aileron position is an interesting sub topic.  Aileron position is all about making a corkscrew just like a propeller.  It is dependent on airspeed, roll rate, aileron size, effective aileron span, aileron effective authority and wing section.  You can make this calculation quite complicated but a simple version is very effective.

This brings me on to my test flight where I used a Cularis.  I don't do major test flights with the xxxl.  I forgot to adjust the effective aileron span from the xxxl simulation settings.  The result is about twice as much aileron throw as wanted.  That is why my ailerons were too aggressive during the flight.

The Cl of the tail is dependent on the Cm of the wing. It is the ridiculously simple calculation of:

Tail Cl = tail volume * wing Cm.

Might be just me but I find some simplistic beauty in that... unless I am wrong

All said, the tail Cl is normally quite small, the aoa quite small and the force it produces quite small.  In the interests of getting the job done, I chose to ignore the elevator lift force when calculating wing aoa demand position.

but