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:
https://code.google.com/p/gentlenav/
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.
Comments
great blog
Matt, i have not heard back from you. this is what it should look like. I would even refine it further if I was going to use it in a feed forward loop.
Thanks for the offer. I will send you the project.
/Matt
If you want to share your project file I would be happy to go over it and make some improvements. Help get your polars more accurate.
On second thoughts, I have a simpler idea.
Something that Aerodyn does not do yet is pitch correction at high roll angles. In a steep banked turn, pitch correction is done by rolling. This can be corrected using the navigation feedback loop but that does not work if you are flying with no navigation target.
I need to add a roll position correction. The question is how much roll correction to use. This relates a little to the navigation problem I just described to Leonard.
The current algorithm uses roll position to determine the amount of pitch load required If the roll position is modified, what pitch load should be used? Should it be modified or kept constant with the original target roll angle?
If the target roll angle is used instead of the actual roll angle for pitch load, this could result in very strange behavior. When rolling from flat to a turn, the aircraft would pitch up badly on the roll command.
Then the target roll angle becomes the actual roll angle with correction added. Then the actual roll angle is different and the correction needs to be taken away again. At some point I was thinking in complicated circles, gave up and went for the simple option to get something working.
Leonard,
If you are still listening in, here is another idea about the navigation.
If your quadcopter has a given bank angle or your fixed wing has a given roll angle, the amount of acceleration you get is dependent on available roll rate. It is not possible to switch acceleration on and off instantly. If your roll rate is low, there is greater difference between demand and actual acceleration. It becomes a control loop delay which adds instability and reduces available gain. This is most obvious if you see an autopilot trying to navigate with a high aspect ratio aircraft. It tends to overshoot the navigation target badly.
Now say that you can predict when you should start to roll to get the amount of acceleration that you want. Instead of waiting to be wrong, you can act early and with precision. This is similar to the algorithm that you just implemented on arducopter except it extends the concept further.
BTW: Bill updated me on the new Arducopter algorithm.
Wayne,
So the lumpiness in the input airfoil should match the lumpiness of my dented Cularis wing.
The polars for the MH32 section on the thermik look close enough to "reality". For that I did use a slightly higher Ncrit but not too aggressive.
Wayne,
ncrit is associated with the ambient disturbances in the flow. The xfoil manual doesn't mention the airfoil surface roughness in this regard. Could you elaborate further on this matter or give a reference?
Morli,
Any ideas are good at this point. Putting sensors on both sides is a good one.
Mark,
Maybe the barometer can go on the other side and NICS done in maths. Either way, I have a better construction plan than I did before.
Thankyou both for the ideas.
Regards Matt
-
1
-
2
-
3
-
4
-
5
of 7 Next