# Optimizing Launch to LEO

I recently decided I would try to develop my own launch to LEO optimizer, as I have always been fascinated with the complexity of that problem. I have been using matlab, as I am very comfortable with the language and am able to debug quickly. That being said, I have run into a bit of a snag with the actual "optimization" part of this, and I was hoping someone could help.

As is, I already have completed a simulator using ODE45, that takes in a few variables and outputs the final orbital parameters. Two of these variables are the control variables I am interested in: a "Mass Flow Rate v.s. time" matrix (mDot as I refer to it later), and an "Angle of Attack v.s. time" matrix (AoA). Assuming these are the only two variables I care about controlling for now, how can I go about doing so in a reasonable amount of time?

(For simplicity, just assume this is a single stage, single engine launcher, that can throttle perfectly and instantly from 10-100%. Also, again for simplicity, assume that the highest Periapsis is the "optimal" design)

The only way I have been able to think of solving this is a two step process:

1. Optimize AoA by starting at the end of the matrix and making my way towards the front, making sure to recursively optimize all of the successive rows in the matrix. For instance, this would look something like:
• Change AoA value by (+) or (-)
• If there are no subsequent rows (IE, this is the final AoA Value)
• Check PE
• if new PE is better than the old PE, then save this value. if not, ignore it
• If there ARE subsequent rows (IE, this is NOT the final AoA Value)
• Repeat this entire process, but for the subsequent row(s)
• Change AoA value for this row by (+) or (-)
• Repeat this entire process, but for the subsequent row(s) -End
1. Once a single AoA is optimized, repeat a similar process with mDot, but optimizing AoA every single time mDot is changed to see if this "new" mDot matrix is better or worse.

This cannot be the most efficient way of handling a problem like this, can it? This recursion seems like overkill, and a sure-fire way to make a code that will finish at the heat-death of the universe. I never took any trajectory optimization courses in college, so any help would be appreciated!

• I wrote a similar thing in Scilab, many years and computers ago. I used a genetic algorithm to optimise the path. I probably assumed full throttle all the way. Jun 24, 2023 at 1:01
• I considered a genetic algorithm, but given the two control variables and the time dependence, as well as the ~50 ms run time per sim, I figured that would take a crazy amount of time. How did it turn out for you? Jun 24, 2023 at 1:34
• Sim time should be pretty quick. It was a long time ago, i'd guess an hour maybe for a run. I do have a backup drive which may have the script on it, I'll check. Jun 24, 2023 at 1:37
• By a run I mean a full optimisation Jun 24, 2023 at 1:56
• 50 generations of a population of 12 completed in less than 1 hour. The actual simulation of one launch to orbit completes in less than a second. The launch is modelled in 1 second increments. Jun 24, 2023 at 4:27

Your launch path need only be a simple table of Time, Vx, Vy, Vz. (It is convenient to work in velocity space for most steering problems). The rocket has a flight program. It will compare the flight path table to what its IMU is saying (onboard Time, Vx, Vy, Vz) and then adjust its steering and thrust controls in an attempt to zero the error.

What you need is a copy of the flight software, and you need a model of the flight path conditions if the flight software has any real-time sensors, or a lookup table of these conditions keyed to flight time if that's what the flight software uses. The generation of any lookup tables used by the flight computer will have to be iterated based on earlier runs, so gradient optimization schemes are a good candidate here.

Lets say the course correction routine of the fight computer needs a drag model, The lookup table points to one of 4 drag models - subsonic, supersonic, hypersonic, and exo-atmospheric. You need to supply the lookup table that transitions the drag models at the correct time based on the flight path. The same can be done with the other data that the flight program requires, such as mass estimation.

Within the flight software emulation, you need to include the performance limits of the system.

You can then set up a module to inject perturbations into the IMU data, motor thrust, motor Isp, etc. Thus the optimization will capture these and build in some headroom and robustness as the flight software works to chase the programmed path.

Now the good news, the optimization is pretty darn simple. You have a very detailed flight program that has a very small input field, and it also serves up the measure of merit on a plate.

The external constraints (those that are not part of the flight program) must be baked into the flight path. They are pretty easy to handle. You start out at max thrust for as long as you can until you hit either a G limit or a Q limit. Delta Vs and Vs must respect these constraints. The Q limit becomes a nonissue after a while. AoA (and all other factors) must be constrained to be in the range for which the flight software has been validated. So there tends to be some duplication, with design constraints set tighter than validated performance.

Constrained optimization (with respect to the external constraints) can be handled by lagrange optimization. It is a method every engineer should learn. But it is not the easiest thing to pick up on your own. You need to have a pretty deep understanding of the derivations to code this yourself.