to-9km-and-beyond

The main objective of this program is to be used to optimize the main wing of an aircraft to beat the FAI record for C-1k planes climbing to 9,000m with a 1,000kg payload (https://fai.org/record/4918), currently held by Gary M. Freeman. In other words, the goal of this program is to be used to optimize a main wing around the airplane's climb time to 9,000m.

For any aircraft configuration (set by the user), this program will also produce best wing* and its corresponding climb time to 9,000m. This climb time can then be prepared to Freeman's 5 min 54s record. Using this program, one can easily design (at least the wing) of an airplane, which can beat Freeman's record.

A secondary goal of the project was to have the program be robust. Robust meaning that any component could be easily modified - in a safe manner - by any user familiar with C++. Classes (OOP) were used to accomplish this goal.

Every Airplane has (at least) a mainWing, a Horizontal Tail, a Vertical Tail, Engine(s), Nacelle(s), a Fuselage, a fuel weight, and a payload weight. So, each of the corresponding main components (everything that isn't a single float or integer variable) have their own classes.

"This methodology enables the Airplane class to treat each of these components as a 'black box.' It does not matter, from the Airplane Class's point of view, how the Wing object is implemented, just that we have a type Wing, and we can call on its public member functions."

When I first started to brainstorm and outline how I wanted to do this project, I realized it would be a lot more readable if an OOP language was used. This is due to the fact that having classes is very desirable for this program (especially for its readability).

C++ is a low level, OOP, programming language, which enables more efficiency than say Python. Personally, I am also more familiar with C++ than any other programming language, since most of the courses I have taken for my Computer Science Minor, have been taught in C++. The cost of getting this extra efficiency is that almost everything had to be built from the ground up (like kadenMath functions).

This project really benefits from being efficient. Since the goal is to optimize an object (the mainWing), it just made a lot of sense to use a language known for efficiency.

The drag functions for the three main objects of an airplane (Fuselage, Wing - note a VT, HT, and the mainWing are all “Wing” objects, and Nacelle) are provided by the DragCoeff class. The DragCoeff class has a “calcTotalDragCoeff()” that is implemented to work with any of those three objects.

This function relies on calcParasiteCoeff(), calcInducedCoeff(), calcCompressibilityCoeff(), and calcFormDragCoeff() in order to calculate the total DragCoeff of the object. We assume no separation drag, but in the Airplane Class, we account for this assumption (and other assumptions) by having an EXTRANEOUS_DRAG_MULTIPLIER that is currently set at 15%.

The form factor of any Fuselage object is assumed to be 1.2 and the form factor of any Nacelle object is assumed to be 1.5. This calcTotalDragCoeff() function is used by the Airplane Class (in a calcDragCoeff() - which gives the total airplane drag coefficient at the passed in parameters), namely for power curve functions, but also others.

Since the airplane we are tasked with analyzing in this report has a jet engine, a power curve is necessary to get the best time to climb. (Currently the project doesn’t work with a propeller). As will be explained later, the power curve for any airplane object is calculated at a time step (say 0.05s).

So in order to understand how much excess power the airplane has (and therefore its max rate of climb (RoC)), we need to generate the power curve and be able to calculate where the max excess power is and how much excess power the airplane currently has. This implementation is done discreetly through calcPowerCurveVelocityData(), calcPowerRequiredData(), and calcPowerAvailableData(). calcPowerAvailableData() depends on the CF_34_3B1, which has the thrust curves digitized.

There are also two implementations of some of these functions (namely calcPowerRequiredData()), which differ depending on accounting for flight path angle (gamma) or not. In other words, one implementation assumes a small angle approx (power curve does not depend on gamma), while the other is the accurate power curve. Currently, due not being able to easily solve for gamma (and the time not changing significantly when experimenting with a constant gamma), the power curve functions independent of gamma (small angle approx versions) are used the most.

This program provides (in the Airplane class) a function getPowerCurveCSV(height), that produces the power curve of the initialized Airplane object, at any height the user passes in. Recall that the climb functions rely on calculating and analyzing this curve at very small time steps, so this function is more for the user to understand (and verify) that the power curves, which again are the backbone of the climb functions, make sense. It is also important to note that the implementation of calculating the maxExcessPower() and currentExcessPower() is done by custom math functions in “kadenMath.h”.

The short version of the climb function is, it's an implementation based on time steps. The power curve is calculated and solved at every time step. If the velocity for max excess power is outside of a certain error, a steady level acceleration function is called to accelerate to that velocity (and then climb continues at the new velocity).

If the velocity is inside the error, then we calculate the current excess power (not necessarily the max because of the error), and use that for our RoC. (Essentially height += (currentExcessPower / totalWeight) * TIME_STEP). See the implementation of calcBestTimeTo9km() which relies on calcTakeoffPropertites() and calcBestClimbTime() (which relies on calcSteadyLevelAccelerationTime()) in the Airplane Class for more details.

Finally, this program (in the Airplane class) also provides a getFlightEnvelopeCSV(). This flight envelope is by no means perfect, and does not have a bunch of constraints like structural feasibility, but it can still be useful to show that the program is working as intended (by the graph having resembling a typical flight envelope) and as a quick (first take) graph that can be used to compare different airplane configurations quickly.