Drag Updates for Rocket Launches
This article is a Work in Progress that will be updated as necessary with additional experience
The purpose of this article is to define guidelines for updating drag profiles during rocket ascents in Launch Vehicle Designer. The drag properties in question are the values in this window:
Which can set both via Launch Vehicle->Edit Initial State->Edit Drag Properties and as an Action for either a sequential or non-sequential Event. The values in the above image are the default values that will be set when you start a new LVD project and represent a general rocket profile that can produce decent results. However if you want things to be as accurate as possible you will need to tweak these numbers to match your rocket as closely as possible.
For the Frontal Area value reference this wiki page. We will deal with both that and the Drag Coefficient (Cd) here.
It is important to understand the drag coefficient is a value calculated during flight, which means if this is the first time launching a rocket design, stick to the default 0.3 and just allow for underperformance. On subsequent flights, you can plug in the proper Cd values. Unless you want to "simulate" first.
There is no one Cd value for your entire ascent. The Cd value will change throughout the climb and you must account for this.
This article requires that you are using Ferram Aerospace Research so you can extract the Cd values from the game. You could also potentially calculate and log Cd yourself via kOS using this code.
When using FAR, take video of the game screen during your ascent while the FAR window is open and displaying the flight data:
You will then have to go back through and transcribe the Cd values into a spreadsheet. To minimize the workload and still get reasonable results, enter the Cd value for every second of your ascent. If you don't have the data output already, also transcribe the altitude that corresponds to the Cd value.
My current update model is to update Cd at the following altitudes:
1-10km
12km
15km
20km
25km
30km
40km
50km
60km
The main idea here is that as the rocket gets higher it is moving faster and thus spending roughly equal amount of time within all these regimes. This leads to accurate results without getting too tedious.
Create these updates as Non-Sequential Events so that they happen regardless of whatever is transpiring in your launch script. The Cd to enter for each event is the average of the Cd values from that altitude level to the next. So for the first event, set to terminate at 1km, this means you want to update the drag values for 1km-2km. You should be able to select all the Cd values in your spreadsheet between 1km and 2km to get the average value. The following event, which terminates at 2km, takes the average Cd from 2km-3km and so on.
What about the values from launch to 1km? The average of those values is the Cd you use for the Initial State drag value.
Whenever you drop large portions of your rocket, the Frontal Area value will need to be updated. The Cd will not, because you got these values during an ascent so they already take into account staging. However the point at which you stage your rocket will affect the altitude updates. You can determine when your rocket stages by using the Graphics Analysis tool to see at what time the stage active state ends. Now plot a corresponding altitude graph. Say your rocket stages once at 2.5km - make sure every non-sequential altitude drag update from 3km and higher is using the new Frontal Area value. In the staging event there should also be a drag update that uses the new Frontal Area value as well as the Cd from the 2km non-sequential event.
If you are staging at largely different altitudes from when you collected the Cd data being used, this needs to be taken into consideration by expecting some additional inaccuracy.
Another factor that may need to be taken into account is lateral drag due to Angle of Attack not being 0, or the nose of the rocket not being pointed directly into the direction of travel. This exposes the side of the rocket to the air stream and should therefore increase the Frontal Area value. I have a theoretical technique to apply this but it has not yet been tested or verified as practical.
The basic idea is to take a side-profile Frontal Area value using the same technique to calculate the nose-on value. You then consider that 90° of AoA would have the rocket sideways and thus present the full side-area of the rocket. So if the rocket were at 5° AoA that is 5.55% of the side-area now being exposed to the air stream, so you could add 5.55% of the side-area to the Frontal Area value. Of course, now part of the front of the rocket is no longer facing into the air stream...
My first focus is to use the drag updates and ignore lateral drag at this time.