1
$\begingroup$

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!

Thanks in advance!!

$\endgroup$
6
  • $\begingroup$ 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. $\endgroup$ Jun 24, 2023 at 1:01
  • $\begingroup$ 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? $\endgroup$
    – Frank
    Jun 24, 2023 at 1:34
  • $\begingroup$ 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. $\endgroup$ Jun 24, 2023 at 1:37
  • $\begingroup$ By a run I mean a full optimisation $\endgroup$ Jun 24, 2023 at 1:56
  • $\begingroup$ 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. $\endgroup$ Jun 24, 2023 at 4:27

1 Answer 1

0
$\begingroup$

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.

https://ntrs.nasa.gov/api/citations/19670026339/downloads/19670026339.pdf

So the next step is to research the heck out of the available off-the-shelf optimizers with an eye to how you are going to present the trajectory problem to the optimizer such that it will produce efficient, stable, and robust solutions. You also want to be able to characterize the trajectory space near the optimum in terms of level sets or some such so that sensitivity to perturbations can be accessed. Keeping a list of all the constraints and analytics that you might want to add at a later date can definitely influence the methods of optimization that you choose.

One way to approach this problem that allows for easy skeletonization and later refinement is to treat points on the trajectory as indexed by a constant time step. Given P1(t1, Va, Vb, Vc), P2 is found by applying the acceleration vector for time increment t2-t1. Use the difference between the acceleration vector at P1 and the acceleration vector at P2 as the parameter associated with P2 in the optimizer*. You are optimizing a sequence of mostly smallish acceleration vector changes. This is the front-end of Calculus-of-Variations approach. You need to tally the change in mass associated with each step and use it in the acceleration formula for the next time interval. This is where things can get messy from a numerical methods perspective, and why it is crucial that you analyze the problem and nondimensionalize the parameters such that they don't become unstable. The incremental acceleration angles and changes in mass flow associated with changes in the acceleration vector are well behaved in terms of scaling. And they basically have a linear relation to the parameters that the optimizer is working on.

Once you have an approximate trajectory that takes care of the big delta V budget items within the structural constraints of the vehicle, you basically start all over again with a model that has vehicle dynamics factored in. You need models for steering commands that get you to the acceleration vectors you need. These often have a lot of awkward coupling features like needing to thrust one way in order to increase pitch rate the other way. So a control input to pitch over a bit actually consists of a protracted series of motor gimbal commands. This gets into the theory of bump functions and local support operators within optimization strategies. If you have some feeling for how much Isp you piss away doing a pitch maneuver, you can kick that into the upstairs model. But it varies over flight time quite a lot.

$\endgroup$
2
  • $\begingroup$ Thank you for the detailed response! All of the talk on the actual implementation of an "ideal" model was really cool to read about, and it makes perfect sense in terms of actually getting a rocket to work. My major in college was aerospace with a specialization in control design, so who knows, maybe I will actually get to play around with a real version of this one day. $\endgroup$
    – Frank
    Jun 24, 2023 at 1:26
  • $\begingroup$ On to the real crux of my issue though, yeah I figured it would be more complex than I thought. My system does currently account for the external constraints of my system (Max axial loading, max shear loading, max/min thrust, Drag, ISP vs Altitude, etc etc) but I just dont know how to start with actually optimizing the two internal controllable variables: Mass Flow and Angle of attack vs time (again assuming instant and perfect turning and throttling). That link you sent did not work, do you have any recommendations on how I could actually begin approaching the control variable optimization? $\endgroup$
    – Frank
    Jun 24, 2023 at 1:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.