Better atmospheric ascent phase

[Noiredd]

From my own experiences, half the time of developing a launch script (that is, the vehicle, sequence, controls structs) is tuning the verticalAscentTime and pitchOverAngle values to get a good atmospheric ascent (going too much "up" increases the apoapse so much that UPFG has to burn downwards to cancel it out, in extreme cases the algorithm fails to converge; going too much "forward" doesn't gain enough altitude and UPFG has to burn up more than otherwise necessary, in extreme cases the vehicle RUDs).

It could be useful to have more control over the early ascent, for example by using control points: "at time T rotate to pitch P" and a soft interpolation (kind of how the old PEGAS worked). On the other hand, this increases the overall complexity of the system, which was designed for simplicity to begin with.

EDIT: This is being put on hold as I do not have enough free time to actively work on this anymore.

[gsarducci]

I'm finding this the most confounding thing about building a launch sequence. In some instances I've found it impossible to arrive at a ballistic trajectory that satisfactorily transitions me into a meaningful convergence. I've been doing historical flights chronologically and this seems to be especially difficult for stages like Titan II GLV. If I go vertical more than 8 seconds it starts to drift, then when it goes to capture a heading it pitches over too much translating to that. (Given the engine configuration of the rocket, I wonder if a roll to 0 before pitchover would solve the translation problem.) If I control the rocket myself I tend to fly a shallower gravity turn until I'm into the upper atmosphere where it's safe to diverge from prograde and shape the orbit from there. Since PEGAS tends to act strangely if I'm in any part of the atmosphere, any attempts shape a pure gravity turn such that I'm in space when PEGAS activated results in me well overshooting my orbit and forces PEGAS to either radically change course or in some cases failing to converge.

This is definitely a learning experience! :)

[TheGrover]

The goal isn't to be all the way to space when the UPFG kicks in. That will almost certainly cause some funky flight paths.

The goal is to have the UPFG kick in after you've passed the thicker parts of the atmosphere, so that atmospheric affects are negligible.

If you're playing with RO, I find that to be about 60km.

Also, the 1000m/s at 45degrees pitch isn't a perfect requirement. If your rocket has a high TWR first stage and a very low TWR second stage, you may want to give the guidance a little assistance by aiming s little higher with the atmo-ascent.

Generally, when the UPFG kicks in, if it points within 25 or 30 degrees of prograde, I'd call that a valid ascent. I've managed plenty of launches this way. If the difference is greater than that, look to change your atmosphere ascent, probably by changing the vertical time by a second or two, so that your pitch is a little closer to what the UPFG was thinking when it kicks in.

That said, with unbalanced TWRs, it may well be that your upper stages need to pitch up and you just accept that

[Noiredd]

@gsarducci @TheGrover What kind of pitch control would you like to have for the atmospheric ascent? I'm currently torn between the current approach (which is easy-hard: easy because you only control 2 parameters and it's within anyone's reach to tune them to get a good enough ascent, but hard because it can sometimes take many tries to get it right) and something that the old PEGAS had.
I used to calculate a pitch table for each vehicle: it bound time with pitch angle in a form of control point series. It was hard-easy, because coming up with those points was quite difficult (how to tell what should the angle be at T+45 seconds? I used MATLAB to calculate it for me), but eventually easy because it gave flawless ascents every time. Unfortunately, creating the pitch program was something I think is way beyond an ordinary user - and by "ordinary" I mean ordinary even by the PEGAS user standard.

So what I'd like to hear is some ideas: what kind of pitch control would give the freedom you need, at the level of effort you're willing to go through?

[Patrykz94]

I think something like the MechJeb ascent path editor would be quite good.

In there you specify the altitude/velocity at which to start the gravity turn, alititude at which to end the turn and, final flight path angle (i.e. the turn should end at 60km and from there on, rocket should be pointing 25 degrees from the horizon) and turn shape (percentage) which decides how the turn will look from start to end (i.e. lower number means more aggressive turn early on which smooths out later for high thrust stages, and higher number means turn more gradually for lower thrust stages).

I can get a working prototype done and from there you can see if you'd be happy with something like that?

Also, do you think this should replace the current atmospheric ascent phase or should both systems be available for user to choose?

[Noiredd]

If you're willing to work on this then I'll happily review a prototype (currently I'm very busy with real life, but a week or two from now I expect to have enough time for this). I'd see this more like an option, as replacing the old system would break backward compatibility with at least my own craft files. Switching between the new and old systems should be, in my opinion, done on the controls level. I can easily imagine a situation in which one can either define their controls using the old (current) style (verticalAscentTime and pitchOverAngle) and get the old ascent working, but they could also skip these keys and use your new system by configuring whatever keys you want this lexicon to have. I'm open to ideas - might be a good idea if you gave me an outline of how you'd like to solve it before you commit yourself to coding this :)

[Noiredd]

Related PR: #35