Calculating Ascent Profiles

[austinjames314]

I've created this so @gruneisen and I can continue a conversation started on the Mechjeb Github.

[gruneisen]

I can say that the manner in which I go about calculating the ascent profile is pretty simple and straightforward. I definitely think that it could be easily implemented into KOS. The hard part is determining the optimum profile, which is what is done in Simulink.

To calculate the ascent profile, I wrote a function for altitude vs. range:

alt(range) = alt_final_(1-e^(-gamma_range)

Of course, it makes a little bit more sense to cast equation in such that range is a function of altitude, since I found it was difficult to perturb the range of the rocket and get into the 'meat' of the above function. This makes it:

range(alt) = 1/gamma*ln(1-alt/alt_final)

Where alt_final is the final altitude you want and gamma is the 'shape' parameter. If you plug this into EXCEL and run it down, you can see how gamma effects the shape of the ascent. This formula is pretty simple and asymptotically converges to the final altitude you choose. For metric units, I found that gamma ~1.0e-06 is a good starting point.

In Simulink, I run the simulation by using PID controllers to keep the gravity vector on the ascent profile vector. Then, I optimize gamma and the start of the gravity turn in order to maximize the velocity at burnout and keep the vertical velocity greater than zero. (I think there are couple of other things I optimize / constrain, but I haven't had a chance to go back into the simulation in about a week and a half).

All this being said, I think programming in the ascent profile function and the control loop to keep the gravity vector inline with the ascent vector in KOS wouldn't be too difficult. But then again, I'm more comfortable with the math side of things than the coding.

[austinjames314]

Well I know what I'm doing this weekend then!

I don't quite see how the velocity works in just yet, but I'll have play in Excel and maybe ask some questions, and then start coding. I'm flat out with RL stuff until tomorrow afternoon though.

Actually I have a question now - I had been thinking of the problem in terms of altitude, pitch and velocity. Not range. (I assume that we're talking horizontal distance from the launchpad. (How does curvature affect this?)). Now though I see that you're modelling the shape that the ascent profile takes on. I assume that this corresponds to the shape that an opitmal gravity turn would take? Can we map your function in some way to give a target pitch (Not the direction the rocket is pointing, but the angle between the velocity vector and the horizon), for a given altitude and velocity? Or am I approaching this wrong?

I'll have to leave it at that and check back in tomorrow.

[gruneisen]

I too thought about problem in terms of altitude, pitch, and velocity however pitch and velocity are really dependent on altitude and range (and yes range is horizontal distance - I take no account of curvature. That's a good point! I'll have to think about that!). Therefore, once you have altitude and range, you can calculate everything else!

The function does not necessarily yield the optimum shape - its just an arbitrary function I chose because I thought it would do well - if you (or anyone else) knows of a a better shape function, then I'd love to use it.

Mapping the function to give a target pitch is done inside my simulation right now by feeding the difference between the angle of the ascent function and the angle of the gravity vector (the angle of the gravity vector being as you described it above - between the vector and the horizon), and then feeding the difference between the two (the error signal) into a PID controller to generate the pitch drive signal. This way the PID controller serves to minimize the error between the ascent profile and the velocity vector by modulating the pitch. My intention had been to use the PID output (gimbal as a function of time or altitude or whatever) as an input to the KSP autopilot. KOS, however, should be able to run the control loop internally and therefore use a dynamic solution rather than a static one.

If KOS can do this difference and PID work internally, then there is no need for the external simulation other than to optimize the shape of the ascent! But that could be done just with trial and error inside KSP...just time consuming, I guess, but not impossible.

[austinjames314]

Yeah I've been working on a general purpose ascent script by trial and error up to this point, and got some very good results and smooth efficient ascents. But I'm trying to get the ascent profile something other than based on magic numbers I've arrived at by trial and error.

If you look at the the files in this repository, you'll see that one of them is a PID library. The 'cooked' control that you can read about in the KOS documentation is basically a hard-coded PID of some kind as well, so that side is definitely covered by KOS, it's just a matter of calculating the appropriate setpoints as the ascent goes on.

We're definitely talking about the same thing. I hope you're online this weekend to talk to while I work on it. I'm in New Zealand (GMT+1200), what timezone are you in?

[gruneisen]

Yes, we're definitely taking about the same thing. I'm in California, so GMT-8:00. I'll be online this weekend, though I may be sporadic - my wife and I just had a child (a major part if the reason I haven't been able to work on my simulations). I should be able to read and chat during naps ;-).

Just so we can link up in the same level, what's your background? I'm a mechanical engineer and do simulations and analysis. Writing out and deriving equations of motion / differential equations are in my wheelhouse, but controls theory is a little on my periphery.

In order to make it more useful, I could go back to excel since it now has a pretty powerful optimization capability built in, but I'd be curious what your interest would be.