# Proposal to merge XFLR5 and PX4

(copied from my blog at hobbyuav.com)

Hey everyone!

I have not found a place where the fixed-wing control for the PX4 is being done so I started this blog.

Above is a Screen shot from XFLR5. I use it to mathematically model the physical form of an airplane. I can then take this description of said plane and then start modeling the flow of air over the surfaces described is the model. You can then send modeled air at it in different angles and at different viscosity. In other words different pitches and yaws as well as different air densities or altitudes.

I use it all the time to make U.A.Vs. I think it should be integrated into the PX4 so that we can start introducing into the mathematical models of the control algorithms, a model of the crafts interaction with its environment (air).  Thus achieving a much more complete  mathematical description of the system.

This can be implemented by modeling the aicraft in XFLR5 then taking the results and generating LUTs of the predicted  air/air-frame interactions. just one example of this would be to use the generated full airplane polar graphs to predict what AOA at a given speed and air density, should produce level flight or even produce a desired vertical acceleration (climb or dive). This would greatly reduce the dependence on the PID loop to achieve a given altitude, making the system much more stable at a greater range of the aircrafts flight envelope.

This can also be applied to different control loops as well. yaw and roll control. It can also be applied to  every control surface as well. XFLR5 can generate tables of inertial moment data as well giving you a Cm polar. this can be calculated for various control surface angles. You can then  take the aerodynamic Cm data and combine it with a physical inertial model to do a full stability analysis. The output of the Cm and the inertial model data can then be feed in to the control loops to achieve desired rotational accelerations instead of purely relying on the PID loop. Giving the control loops a much wider dynamic range that is possible with just a PID loop.

Views: 3579

Comment by Philippe Petit on February 22, 2013 at 8:04pm

Hello wayne,

this is indeed possible. Given a model like you proposed (therefore having a aerodynamic model), it would be very well possible to improve the performance of the controller.

In my opinion there are several possible ways to improve the controller performance if a model is given. Improving the performance of a PID controller is however not the most promising way, as tuning in flight is much faster and a model of the dynamics will not improve the tuning process.

A model can be very useful for other model-based controller like LQR or MPC. These methods require however a full state reconstruction, but as we have the dynamic model of our aircraft, this can be achieved by a Kalman filter or a State observer. If one of these two state reconstructions can be implemented (the Hardware platform must offer enough computational power), a LQR control (Linear Quadratic Regulator) for example can offer a much better performance then PID while consuming considerably less computational power then a PID controller.

Thus summarising my opinion (which is certainly one of many): Implement a Kalman filter or State observer for state reconstruction and implement LQR control. This techniques will offer better performance then pure PID control, but is computational more expensive.

I realize that this is worth nothing as long as it is not implemented, but I think that this might be a feasible way to achieve better controller performance...

Cya phil

Moderator
Comment by Gary Mortimer on February 22, 2013 at 10:32pm

This would be very cool

Comment by Martin on February 23, 2013 at 12:22am

100KM
Comment by crystal garris on February 23, 2013 at 3:10am

@Philippe,

" tuning in flight is much faster and a model of the dynamics will not improve the tuning process"

I respectfully disagree. The problem is PID numbers that work at cruse speed will not work as well at max throttle or near stall. Just for clarification the calculation loop I am proposing actually is an outer loop to the PID inner loop. this should help whatever controller loop you are using.

Basically, all airplanes climb or lose altitude because of the angle of attack combined with the speed of the air flowing over the sufaces and the Cl generated by the overall aircraft.

lets take the techpod for instance. It will cruse at ~35 mph with a airframe AOA of 0 deg. As the airspeed slows the  techpod must fly at a higher AOA to maintain altitude. The control loops are going to try to compensate for the lower then desired altitude error. This will eventually lead greater and greater phugoids the farther you get from the speed at which the PID was originally tuned.

what I suggest is this. Instead of having 1 control loop maintaining the aircraft at 0 deg AOA at all speeds and a second loop controlling altitude. Have the desired AOA calculated based upon airspeed, air density and the aircrafts known Cl / AOA polar. Thus at 35 the techpod should fly at 0 deg AOA at 65 the techpod will fly at some what reduced AOA (level flight)

We already have I awesome kinematic model. we now need to complete the global model with an aerodynamic model and an inertial model. XFLR5 can get you there.

@Martin,

Ya that's just one thing you can do. pre-calculate the PID loops;-) I suggest we use it for much more.

@Everyone

To help facilitate this I will be open sourcing the XFLR5 files I used to design the techpod giving everyone open access to the aerodynamic design.

Comment by MarcS on February 23, 2013 at 4:07am

Hi Wayne,

probably the term you are missing is "gain sheduling", and here I think your idea with using XFLR5 data could be a good one! So you pre calculate tables with resulting moments from control surface movements. These are dependent on speed/AOA. With these values the PID gains are scaled.

My guess is that using the values of XFLR5 you will not be able to instantly have good control parameters, but the relative values for a sheduling should e good. This sholud improve performace and make tuning easier.

One other remark: since we will most likely not measure AOA on our planes, pitch should be used as input...

Comment by Tilman Baumann on February 23, 2013 at 4:36am

Well, if someone comes up with a nice cheap and robust vane for AOA measurement that could be adapted easily.

The benefits are pretty clear. Especially for smooth stall landings.

Comment by Martin on February 23, 2013 at 4:45am

Doesn't AOA=Pitch+Decalage+-IMU mount angle? Why is there a need for a vane?

Another thing - XFLR5 grossly underestimates the drag coefficient of the plane. That would also need to be compensated for somehow.

Comment by Martin on February 23, 2013 at 5:20am

I forgot that the IMU offset from the CG would also have to be taken into account when calculating the AOA.

Comment by Tilman Baumann on February 23, 2013 at 5:22am

AOA is relative to airflow not to ground

Comment by Martin on February 23, 2013 at 5:34am

AOA is relative to airflow not to ground

Somehow that also slipped my mind.

Comment

Join DIY Drones

1

2

3

4

5

6

7

8

9

10

## Groups

163 members

3 members

1470 members

631 members

• ### ArduBoat User Group

259 members

Season Two of the Trust Time Trial (T3) Contest
A list of all T3 contests is here. The current round, the Vertical Horizontal one, is here