Change the maneuver tool to compute the predicted path in the moving orbital frame

[Darta01]

tl;dr: summary at the end of the post

I am aware the problems of the current maneuver planning tool have already been discussed on this forum by multiple players: the prediction stopping when out of fuel, the inability to set the maneuver at the next orbit, the lack of number entries, the inaccuracy of the progress bar... Here I want to bring a mathematical insight to why, even with all these problems dealt with, the current maneuver planning system would still be inadequate.

The current advantages of the maneuver tool are the ability to see the real trajectory followed by the spacecraft during the burn, and to evaluate its end point. It is a huge advantage, especially for long burns. However, the predicted path is computed by assuming the direction of thrust is constant, and set at the beginning of the burn, and that is the heart of the problem.

Take for example the following vehicle, that has 4072m/s of ΔV and a TWR of 0.29, placed on a 100x100km orbit. I want it to transfer to a kerbostationary orbit at 2863km of altitude.

Picture: Test vehicle

With a theoretical instant impulse, the Hohmann transfer is 651m/s for the apoapsis raising (going from the 100x100km orbit to a 100x2863km one), and 424m/s for the circularization at apoapsis (from 100x2863km to 2863x2863km). The return trip costs the same, 424m/s for periapsis lowering and 651m/s for circularization at 100km. These are the ΔV computed by the maneuver tool in KSP1, because it was computed assuming an instant impulse.

Picture: Principle of a Hohmann transfer

Of course in a real situation the maneuver is not instantaneous, and the player has to find a way to perform the maneuver with this limitation. In KSP1, the usual technique was to point the spacecraft in the direction of the maneuver, and start the burn when the time before reaching periapsis is half the duration of the maneuver. So basically the node is approximately in the middle of the real maneuver.

By doing this technique, the ΔV is 659m/s for the apoapsis raising and 424m/s for the circularization at kerbostationary altitude. The return trip costs 424m/s for the departure and 651m/s to circularize at 100km. With different spacecrafts, the ΔV cost varies according to their TWR. For this spacecraft in particular with an initial TWR of 0.29, the cost is very close to the theoretical Hohmann transfer (only 8m/s of loss).

Picture: Direction of thrust with KSP1 method

In KSP2, the new maneuver planning tool computes the predicted path of the spacecraft during the whole duration of the maneuver, assuming that it is pointing in the maneuver direction. This direction is inertially fixed, and computed in the orbital frame at the start of the maneuver. This means it is no longer possible to place the node at the middle of the maneuver. When planning an apoapsis/periapsis raising/lowering, if the player sets a prograde/retrograde maneuver (as was done in KSP1), the spacecraft will be pointing straight in prograde/retrograde direction at the start of the maneuver, and slowly drift away as the orbital frame changes along the trajectory.

By doing this technique, the ΔV is 700m/s for the apoapsis raising and 426m/s for the "circularization", but the orbit is much more elliptic than KSP1's technique (2847x2880km instead of 2863km). And the return trip costs 424m/s for the periapsis lowering and 671m/s for the circularization but again it is impossible to circularize with this kind of maneuver. The resulting orbit is 59x151km. So the ΔV cost is much higher using this naive technique introduced by the new planning tool. This is due to the thrust direction being suboptimal.

In these maneuvers (apoapsis/periapsis raising/lowering), the goal is to gain or lose orbital energy. The optimal way is to thrust in the prograde or retrograde direction, every other direction introduces a loss. The greater the direction difference, the higher the loss. KSP1's technique keeps the thrust direction pretty close to the optimal direction, therefore the ΔV is close to the theory. In the naive KSP2 method, the direction is prograde/retrograde at the beginning, but the difference is much higher at the end of the maneuver, therefore the loss is much greater. In this particular case, the loss is 81m/s, 9 times higher than with KSP1's planning tool.

Picture: Direction of thrust with KSP2 naive method

Picture: Resulting orbit after the periapsis circularization

With KSP2 current tool, it is in fact possible to perform the same maneuver as with the KSP1 method, but the player needs to correct the direction of thrust with a radial-in/radial-out component. So the new method would look like this for a circularization at periapsis: set a maneuver at periapsis with a retrograde component so that the apoapsis is approximately at the good altitude; move the maneuver so that the the periapsis is in the middle of the path; add a radial-in component to the maneuver so the resulting orbit is closer to a circle; tweak all three parameters until the projected orbit is as close to a circle as you want.
It takes only five minutes to do in KSP2 what took two clicks in KSP1. What an upgrade!

Now what I'm proposing is to change the way the planning tool computes the maneuver direction. For these kind of maneuvers, I would like the maneuver to be computed in the orbital frame that moves with the predicted path. Which means, when a maneuver is set with a prograde component, the maneuver marker stays exaclty prograde during the whole duration of the maneuver.

Picture: Direction of thrust always prograde

This is what happens when you burn always prograde/retrograde in my example. The apoapsis raising costs 652m/s of ΔV. It is very close to the theoretical ΔV, but as a side effect it also raised the periapsis by 7km. Therefore less energy needs to be gained at apoapsis, and the circularization costs only 418m/s. The total is less than a Hohmann transfer. For the return trip, the periapsis lowering costs 417m/s of ΔV. For the circularization at periapsis, I start the maneuver at such an estimated time so it ends at the periapsis, and it costs 644m/s. As I don't have an adequate planning tool, the circularization is not perfect, so the resulting orbit is 97x105km, but still way better than with the current planning tool. Again the ΔV is less than the theoretical Hohmann transfer. The total gain is 19m/s, minus some ΔV needed to properly circularize.

The difference is even greater between the KSP2 naive method and the one I propose when the TWR is lower or the burn longer (e.g. for interplanetary departure/arrival).

 

So with this change, the planning tool would allow the player to negate the losses induced by a suboptimal direction of thrust. However I don't think the current planning tool should be totally discarded, because in some cases maneuvers need to be planned with an inertially fixed direction.
Here are cases I can think of where the maneuver should have a fixed direction:
    - plane change (changing the inclination)
    - fly-by corrections (changing the orbit in another SOI)
    - target corrections (reaching another spacecraft)
It is not anecdotic, so it is better to keep the current tool available to the player. But the default planning mode should be the moving orbital frame, because here are cases where it is essential:
    - orbit changes (periapsis/apoapsis raising/lowering)
    - circularization
    - rendez-vous
    - lunar/interplanetary departure
    - interplanetary arrival (injection burn)
    - targeted landing
    - suicide burns
Theses maneuvers are the heart of KSP2 game loop, there are essential to go anywhere.

Ideally, I would like to have an option on the planning tool to compute the path either:
    1. In the moving orbital frame
    2. In inertially fixed frame
    3. As an instant impulse
The third one can still be useful to plan certain maneuvers that are not possible with the current spacecraft. For example, the player sets a station in high altitude orbit of Kerbin (with no engine), and now he/she wonders how much ΔV it would costs to reach the Mun with a space tug or a resupply module. With instant impulse planning tool, he/she can have that information that is not available in the VAB trip planner.

 

 

TL;DR
The current maneuver planning tool computes the future path by assuming the spacecraft points in a fixed direction. This is useful only for some very specific cases. In most cases such as orbital raising/lowering, interplanetary trajectories or landing, it is suboptimal to say the least.
A better way would be to compute the maneuver in the moving orbital frame. It would be easier to plan in terms of QoL, and cheaper in terms of ΔV cost for most maneuvers.

 

P.S.

This posts echoes @Superfluous J tutorial (Don't just burn prograde!), where he/she shows the prograde maneuver is nowhere near optimal in terms of ΔV for an interplanetary departure. However, I would say the title is misleading: you SHOULD burn prograde and stay prograde, just not in the direction of the maneuver 

Edited March 11 by Darta01
Added reference to Superflous' post

[MirageNL]

I noticed this problem as well. Setting up a long  enough prograde burn can even cause the periapsis to drop below the surface. Keeping the direction relative to the trajectory instead of fixed would definitely be a big improvement.

24 minutes ago, Darta01 said:

Here are cases I can think of where the maneuver should have a fixed direction:
    - plane change (changing the inclination)
    - fly-by corrections (changing the orbit in another SOI)
    - target corrections (reaching another spacecraft)

For a plane change, wouldn't it also be better to maintain an (anti-)normal direction instead of a fixed one? A fixed direction also changes the Ap/Pe and has to be corrected by the pro-/retrograde direction. The other two maneuvers are usually small burns involving a lot of fiddling, so I don't think it would matter a lot whether they're relative to the trajectory or to a fixed frame. As for the fuel limitation, wouldn't it be possible to just use the remaining dry mass for calculating the continued trajectory? It would need to be clearly marked red of course. In any case, I don't think there need to be any additional maneuver node modes, that would just make it more complicated.

[magnemoe]

Now the solution here is to set the node before intended Pe, flight plan mod does this then generating nodes as an example. 
I also agree burning along in direction of trust is more effective. 

I ran into an issue sending the 300 ton lander to Duna, as it was so heavy I had to circulate using the nuclear engine and setting up the burn to Duna I found I needed 1700  m/s to leave Kerbin SOI. 
All my other interplanetary crafts had a chemical core or second stage with 600-1100 m/s left for the initial kick. 
Solution was to divide burn up in two burn first of 600 m/s and 700 m/s for Duna intercept. 
Now the benefit of prediction is that I saw this and could correct. 

I also used this prediction to land on Tylo, An pure landing burn would crash, but adding an outward component keeping me up until I killed my velocity just above the landing spot. 

 

[Presto200]

This would probably improve the accuracy of the maneuver plans also which has been a concern especially with interstellar on the horizon (the devs said in an interview that interstellar will not have a special maneuver node system and it’ll be the same as what’s used currently)

[magnemoe]

20 minutes ago, Presto200 said:

This would probably improve the accuracy of the maneuver plans also which has been a concern especially with interstellar on the horizon (the devs said in an interview that interstellar will not have a special maneuver node system and it’ll be the same as what’s used currently)

Agree, now I'm very impressed with the burns in KSP 2, doing an 3 Km/s burn and its inside the SOI of target, have fun doing that in KSP 1  

[kdaviper]

You can also achieve a similar result to the ksp1 method by (in addition to moving the node back) pointing radially in as well to get a maneuver tangential to periapsis.

[Darta01]

3 hours ago, magnemoe said:

I also used this prediction to land on Tylo, An pure landing burn would crash, but adding an outward component keeping me up until I killed my velocity just above the landing spot. 

With the proposed method, you could set a purely retrograde maneuver node, and at some point the spacecraft would eventually kill its velocity. So that kind of landing would be easier to plan, and with greater fuel efficiency

1 hour ago, Presto200 said:

This would probably improve the accuracy of the maneuver plans also which has been a concern especially with interstellar on the horizon (the devs said in an interview that interstellar will not have a special maneuver node system and it’ll be the same as what’s used currently)

I'm not sure it would make any difference. The predicted path would rely on the same type of computation, just with a different formula for the direction of thrust. I don't know what concerned players describe as an accuracy problem, but if it is purely calculation accuracy (like floating point precision), the problem would not be solved by my proposition.

34 minutes ago, kdaviper said:

You can also achieve a similar result to the ksp1 method by (in addition to moving the node back) pointing radially in as well to get a maneuver tangential to periapsis.

Yes, I talked about that somewhere in the middle of my post. The main issue is that it was way faster, easier, more precise and more intuitive to do so with the instant impulse planning tool in KSP1

[Darta01]

5 hours ago, MirageNL said:

For a plane change, wouldn't it also be better to maintain an (anti-)normal direction instead of a fixed one? A fixed direction also changes the Ap/Pe and has to be corrected by the pro-/retrograde direction.

For small inclination changes, it does not make a lot of difference I guess. With large angles but short burns (high TWR), the best thing to do is, as you said, to plan a maneuver in fixed direction with both a normal/anti-normal and retrograde direction. With very low TWR, the best method is to perform multiple plane change maneuvers, at both ascending and descending nodes, again in fixed direction. With semi-low TWR (long burn but still achievable in a single burn), I'm not quite sure what is the best method, but I would say it should be in fixed direction

5 hours ago, MirageNL said:

As for the fuel limitation, wouldn't it be possible to just use the remaining dry mass for calculating the continued trajectory? It would need to be clearly marked red of course. In any case, I don't think there need to be any additional maneuver node modes, that would just make it more complicated.

It could be a solution. I prefer the solution with three modes, but if there is a solution to overcome the fuel limitation and the two first modes are implemented, then the third one has little use. So if the devs have good reasons not to implement the last mode, I'm ok with that.

[MirageNL]

12 hours ago, Darta01 said:

With large angles but short burns (high TWR), the best thing to do is, as you said, to plan a maneuver in fixed direction with both a normal/anti-normal and retrograde direction.

Actually, for large inclination changes (>43^o for LKO) it would be better to raise your Ap, do the inclination burn there and then lower the Ap again. But besides that, I suspect you're right. Keeping the direction normal to the trajectory would keep the Ap/Pe nicely constant, but it's probably less efficient in terms of deltaV than a fixed burn. Anyone wants to do a comparison?

I do think the retrograde adjustment is a bit of a hassle. Maybe we could have the (anti-)normal node take this into account, automatically adding a retrograde component to keep the shape of the trajectory intact? Though I'm not sure if that could entirely work with a fixed direction. It might also screw up (anti-)normal correction or intercept burns.

[Lowi_Sace]

20 hours ago, Darta01 said:

Ideally, I would like to have an option on the planning tool to compute the path either:
    1. In the moving orbital frame
    2. In inertially fixed frame
    3. As an instant impulse

In the current game vehicles cannot turn while time warping. That is probably why the maneuver is a inertially fixed frame. For very short maneuvers the difference is really minimal and for long ones it is not helpful because of the lack of time warp. This was for a while in a bug report, but is put out of it because it takes a while until vehicle turning during time warp will be possible in the game. I am convinced that point 1 will be implemented in the future. The Devs talked about some interstellar burns might take years and for that option 1 is necessary. Personally do not see the need for option 3 if we have a well implemented option 1 and 2

[Darta01]

7 hours ago, MirageNL said:

Actually, for large inclination changes (>43^o for LKO) it would be better to raise your Ap, do the inclination burn there and then lower the Ap again.

That's right, I forgot about this method

6 hours ago, Lowi_Sace said:

In the current game vehicles cannot turn while time warping. That is probably why the maneuver is a inertially fixed frame.

That would mean the dev team chose to temporarily fix a bug by adding another bug and never talked about it...

[Lowi_Sace]

14 hours ago, Darta01 said:

That would mean the dev team chose to temporarily fix a bug by adding another bug and never talked about it...

As we all know the game is a work in progress and stuff like timewarp are stil progressing. I would be suprised if we do not get option 1  before the interstellar update. For such long burns that is an absolute must. aslo imagine turning those huige ships without timewarp.