Using VSPAero to generate an aerodynamic model for JSBSim in FlightGearUsing VSPAero to generate an aerodynamic model for JSBSim in FlightGear admin 22 October, 2016 - 23:55
Research into alternative methods of building aerodynamic models.
One of the challenges, probably the biggest single challenge, presented to an aircraft modeler is to make a representative FDM from any data that can be collected from publicly available sources. When there isn’t much data it has been a point of much discussion whether to use YAsim or to use a JBSSim model created with Aeromatic, Aeromatic++, DATCOM, or DATCOM+. If you can find wind tunnel data then always start with that; it’s going to give you a much better model than any of the computational prediction methods (including CFD that takes CPU years to complete).
So the challenge is to find a new method to generate a complete aerodynamic model. I started looking at this back in mid 2015 really as a way to create a BAe Hawk aero model.
There are a number of programs that I considered to do this;
- VSAERO – expensive
- APAME I didn’t manage to get any results out due to program instability
- AVL – found it hard to figure out what to do
- PANAIR – Boeing code, reported as being excellent, supporting subsonic/supersonic, but hard to get the right input files.
- PANUKL – no source code so not on my list
- TORNADO – seems good but requires MATLAB
Notice that my lists stops at OpenVSP; as the more I used it the more obvious it became that it was the best of the above list (for me). So I decided to go with OpenVSP for the next part of the process. This was to model an F-15 and to compare the results directly against my existing aerodynamic model which came from the wind tunnel data. Thereby producing a set of results that can be compared directly on the plots by overlaying one set atop the other.
After about 6 months of work I managed to produce an F-15 model that is similar enough to be flyable in what I’d consider to be close enough to the wind tunnel model.
Introduction to VSPAERO
VSPAERO is part of the OpenVSP vehicle modelling suite. It is based on linear potential flow theory and is can use either vortex lattic method or panel method. Other applications using the Vortex Lattice method are Vorlax, AVL, Tornado, HASC, etc. VSPAero does not represent thickness via panels on the surface rather it represents the mean camber surface.
The Beagle Pup experiment
For a good few years I’ve been following the work of Simon “bomber” Morley with interest. He has been building complex models where no data is available by separating the airframe into parts and modelling each component part individually; using XFoil (or other programs) to get the lift/drag curves and computing the rest. This approach is requires a lot of skilled work due to the inherent complexity but should produce representative results. The one area where the amount of manual work becomes prohibitively complex is the interaction of the flow with the surfaces and the interaction of the wakes – I believe that this is probably too complex to model manually due to the amount of calculations that are required.
So with this in mind I decided that it was time to build a model using VSPAero to compare Simon’s work against and decide on the advantages and disadvantages of each approach.
Simon kindly provided all of his data as a starting point; and I’ve manage to find other sources to supplement this data.
Beagle Pup Geometry
The first step of the process is to build the geometry using OpenVSP that will be used by VSPAero. OpenVSP takes a geometric modelling approach which is much better suited to computational aerodynamics than a polygon or mesh based model. Although the 3d models that are built in a 3d modelling package such as Blender can look exactly like an aircraft, most of these models do not have the resolution needed for any sort of computational aerodynamics.
So we’re modelling with numbers rather than drawings. The following are the basic parameters for the Beagle Pup that I am using.
- Length 18.23 ft
- Section 1 : X,Z 0.077 -0.01167, 1.60×3.05
- Section 2 : X,Z 5.39 0.19, 3.0×4.0
- Section 3 : X,Z 8.5 0.77, 3.4×4.1
- Section 4 : X,Z 10.23 0.6, 3.7×4.1
- Section 5 : X,Z 16.74 0.42, 1.99×1.39
- span 31 ft
- chord 3.71869
- area 115.27 sqft
- NACA 63615 a=0.1, (T/C 0.14758, Ideal C/L 0.5806, A 0.141)
- root chord 4.768
- tip chord 2.67
- twist 0
- sweep 3
- Dihedral 7.37
Horizontal Stabiliser :
- span 11 ft
- area 29.4 sqft
- NACA 0008 (T/C 0.08387, camber 0) (NOT SURE ABOUT THIS)
- twist 0
- sweep 0
- Dihedral 0
- height 5.5 ft
- area 19.25 sqft
- NACA 0013 (T/c 0.129, Camber 0) (NOT SURE ABOUT THIS)
- twist 0
- sweep 0
- Dihedral 0
My model follows Rob McDonald’s advice of “(for VSP) with geometry less is more”; so the models are simple, using ellipses for the fuselage, and a low tesselation value. This is based on experimentation with low, medium and high complexity models. Something that looks right doesn’t necessarily generate more realistic data from VSPAero; and it is the geometry that is important rather than lining up with photographs. I’ve used a 3view photograph to estimate basic positions where measurements aren’t available, and then had to tune the exact positions based on the resulting coefficients.
With beta 5 I had to resort to some photogrammetry – simply because of a lack of decent data.
This is what I came up with – and I used this to tweak and align the geometry of the beta 5 version of the model.
Building the aerodynamic data using VSPAero
VSPAero 3.9.1 does have the ability to do “sweep” runs; which is useful for inspecting a range of values, however to build a full set of aerodynamic data requires around 5,300 invocations to collect all of the required aerohex (Cl,Cd,Cy, CL,CM,CN) datapoints and aero derivatives.
From the basic model we build a second set of degenerate geometry for processing by the aero processing tool; the input files are
VSPAero 3.9.1 introduced movable control surfaces, for the Beagle Pup these are used for the Ailerons, Elevators, Rudder and Flaps.
Each VSPAero run generates an .ADB file which can be viewed with VSPViewer
One of the benefits of Simon’s multi component approach is that it is possible to model the aerodynamic of damage (by removing components or adjusting individual parameters that relate to the components). Using VSPAero we can reasonably easily generate a set of linear damage coefficients the model includes
- Wing Damage – a value that goes from -1 to +1, with 0 being no damage, this is a linear effect with +/-1 being a single wing, effectively this is a linear wing asymmetry.
- Horizontal Tail Damage – a value that goes from -1 to +1, with 0 being no damage, this is a linear effect with +/-1 being a single wing, effectively this is a linear asymmetry.
- Vertical Tail Damage – a value that goes from 0 to 1, with 1 being a reduction of 50% of the vertical tail.
VSPAero includes rotor simulation, and this is used to generate a complete set of coefficient modifiers based on the propeller induced velocity.
Results and tuning.
I started to build the geometry on the 8th October, and the first flyable model took 4 days (mostly computational time); as there are geometric tuning that must be performed to balance the model.
A further week was required to tune the model, add the propeller and damage effects and to perform a few complete runs.
The following are compared against the F-15, and whilst the two are very different the F-15 still provides a sound basis for a sanity check of the parameters.
A full set of plots is available in my document Beagle Pup Aerodynamic Model
VSPAero has the ability to control the amount of wake iterations performed; for normal testing this is at 1; however this doesn’t generate much in the way of freestream interactions, so a value of 3 or 4 is used with a full run to get more realistic results from iterating the wakes.
Using VSPAERO mass properties to calculate the moments of ineria
Without wanting to get into a detailed description of what these are – they basically affect the ease at which the aircraft starts to rotate around an axis, and the difficulty it has in stopping rotating. Smaller values are easier, larger values are harder. Big aircraft have very large numbers.
Calculating moments of inertia (Ixx, Iyy, Izz, Ixz) is quite complex, requiring maths and lots of data, e.g. the triple integale and this is where the Mass Properties part of VSPAERO comes in very handy to help us with Ixx, Iyy, Izz and Izx (the other cross products can be ignored as they will always be very small values for a rigid body).
OpenVSP is basically dimensionless; what that means is that you mentally have to add “feet” or “meters” when looking at the numbers; and as long as you’re consistent with the usage all is fine. When generating the mass properties VSPAERO uses the density that you set. Initially I had a hard time understanding how to figure out the density and came up with some very wrong data, until I realised that I was stupidly thinking in lbs instead of slugs. So a quick conversion of the empty weight of the aircraft into slugs, adjustment of the densities to come up with a nearly correct mass (where known) for each part (i.e. engine, and the rest) and I ended up with the calculated mass being the same as the actual mass. This then means that the Ixx properties will also be right, as these are expressed in UnitOfMeasure/UnitOfMass^2.
VSPAERO Mass properties, component results
VSPAERO Mass properties, results
Center of Gravity
Moments of inertia
Deciding on the number of slices to use for Mass Properties in OpenVSP
Refer to the results on the following illustrations (rather than looking at the picture).
The default value is 21, which is reasonable.
65 Slices is better.
200 Slices is more accurate; but in the end 65 is probably close enough.
Tuning of pitch handling;
- Wing incidence 4 degrees, tail 3 degrees.
- AeroRP tuned.
- Adjusted htail position moved in X,Z slightly.
This provides a much more stable pitch response.
Aero for prop effects is now by default turned off but can be added in from the preferences dialog. Aero for gear removed as it is causing instability.
Remembrance day update.
Fixed (or improved) flight handling.
- Elevator response, Pitch moment and stability; it may still be a bit twitchy
- sideslip due to roll
- subtle changes to the geometry to reach better stability.
- removed propeller aerodynamic effects and damage effects – I can put these back in later but they need more work to be useful.
To take off – throttle up whilst controlling the gyroscopic prop effects with the rudder. With no flaps smoothly rotate at 65kts keeping the yaw and roll under control. If you lose control of the yaw then you’ll get excessive sideslip which in turn destroys the lift, generates roll and results in an undesired ground interaction. With 38% (one notch) of flaps you should be able to rotate slightly earlier, but the climb out will be slower and you’ll need to be careful with the power and not to stall.
Landing I tend to come in at 50-60 kts with one notch of flaps, possibly two notches. Depending on weight you’ll stall at around 45 kts.
With this model you do need to keep a watch on the yaw. Rudder will be required to control this. I think this is like the aircraft based on comments that I’ve read – and this is coming out of the aerodynamics – it’s not something that I’ve added.
At this stage let’s keep the testing to take off and circuits – to provide comparative results use Fair weather.
St Catherine’s update
It appears that most of the problems with the twitchy response were caused by a combination of factors, but primarily that the stability derivatives Side force due to yaw (CFYR) , Yaw moment due to roll (CMNP), and pitch moment due to pitch (CMMQ) had the wrong sign along with Yaw due to Aileron (CMNDAD).
The moments of inertia were way too large, but after understanding how OpenVSP does this the new set is much better.
The flaps may still be quite wrong; more investigation is required here.
St Andrew’s day update
This is beta 5 – the pitch moment has again been reworked based on attaining consistent pitching moment across a range of alpha values for the wing. This is 7.257 ft.
The moments of inertia have been tuned to be twice the value that OpenVSP mass properties calculated. I suspect these figures are possibly correct and that given the right mass distribution OpenVSP would certainly be able to calculate the right values, but I don’t currently have this sort of data so for this beta I’m going with a set of tuned values.
Beagle Pup model – drop in additions “FGAddon Beagle Pup” to add this FDM:
Simon Morley’s Engines – extract these into the FGAddon Beagle Pup. These are required.
- The Beagle-Pup from FGAddon is mainly authored by Richard Senior and licenced as GPL.
- Simon’s (T4T) Beagle-Pup is licenced as CC BY-NC-SA 3.0 (http://creativecommons.org/licenses/by-nc-sa/3.0/)
- My copyright on the files BeaglePup-vsp.xml, Systems/Beagle-Pup-controls.xml, Systems/Beagle-Pup-flight-controls.xml are all rights reserved, and are accessible, and may be distributed for purposes of academic review. I may well relicence my FDMat some point in the future if this turns out to be a viable BeaglePup model – however building a Beagle-Pup model is a side effect of this process and not the purpose of the process.