Maneuver plans - fixed and relative burn modes

[Lyneira]

A maneuver plan in KSP2 differs from KSP1:

• Takes into account that the burn is not instant, which should lead to a better trajectory prediction.
• Burn starts at the point where you place the node.
• Can be executed in timewarp, making it feasible to do long burns with low TWR engines.

Unfortunately, the current implementation suffers from some "worst of both worlds" issues:

• When a prograde burn is long enough for the orbit to noticably curve during it, you can end up with significant cosine losses as you end up burning pretty far off prograde towards the end of the burn. The KSP1 method of executing a burn half of the time before a maneuver and half the time after reduced these cosine losses as the burn is aligned better with the trajectory.
• When doing significant inclination changes and tracking the maneuver with SAS, the maneuver target changes drastically as you perform the burn, leading to a trajectory that is far off what you planned and sometimes even puts you on a suborbital trajectory!
• When doing a very long prograde burn with an ion engine and you want to timewarp, you have to keep returning to 1x speed to adjust your heading.

The proposed solution is to split this up into two modes for maneuvers - fixed and relative. The mode affects how the trajectory is predicted, the burn start point and the maneuver target (and tracking with SAS).

Fixed (default mode):

• Useful for short duration burns, like ejection burns from LKO with methalox engines.
• Calculates a sort of "secant" for the burn, centered on where you placed the maneuver.
• Starts roughly half of the time before the maneuver's placement on the orbit.
• Maneuver target remains fixed on the sky during the burn except when the burn deviates from the plan. This is how the maneuver target worked in KSP1.
• Benefits: Lower cosine losses from burning off prograde, quick corrections possible during or at the end of the burn without needing to make a new correction maneuver.

Relative:

• Useful for long duration burns, like spiralling outward from LKO using an ion engine.
• Starts where you placed the maneuver.
• Maneuver target is relative to the current trajectory, so it will move across the sky as you orbit during the burn.
• Ideally, the vessel also keeps tracking the maneuver correctly during timewarp.
• Benefits: Lower cosine losses (A prograde burn will remain prograde during the entire burn), allow for fast-forward low TWR burns with nukes or ion engines without needing to return to 1x timewarp repeatedly.

Credits:

Inspired by a post from @Sea_Kerman in the Hotfix 0.1.3.2 release thread:

 

Edited July 13, 2023 by Lyneira
Add burn heading issue under timewarp

[Alchemist]

I second this.

 

Additionally, I would propose the option to override TWR. It's all cool that it can take into account TWR changes during long burn, but it's not always what we aim for. Sometimes we just need to predict a maneuver vector to then prepare for it.

I would imagine following set of switches:

TWR:

1. Dynamic - what we seem to have now. Also, switching to this mode should update engine status every time (in case you switch something on and off).
2. Current - assumes current value constantly.
3. Custom - input any value. Maybe you're planning for another vessel.
4. Instant - KSP1 style, no integration, just instant change in velocity. (it's your own decision what to do if the burn gets too long).

Burn mode:

1. Direct - current option. Start from maneuver node and keep pointing in the same direction (as set from the initial trajectory at the point of maneuver)
2. Secant - start half the burn before maneuver point and keep direction (as set from the initial trajectory at the point of maneuver)
3. Relative - start from the point, but the vector is set in relation to the momentary velocity (like keeping prograde or keeping normal) at each moment of the maneuver (in instant mode should still integrate the way speed change affect further burn, just disregarding the ships movement along the orbit).

Integration - to see how much still left. No, not the timer, give us a proper remaining delta-v reading as well!

1. Projection - integrates the total delta-v spent along the maneuver axis. Does not react to off-axis component (if your thrust is off-axis or you turn too sluggishly - it's your problem).
2. Full integration - adds all non-gravity acceleration and compares to maneuver vector. can adjust the remaining maneuver vector to account for any deviations from intended direction (For relative burn mode might require a bit different algorithm, like integrating vector-relative deviations).
3. End velocity difference - KSP1 method, with maneuver vector being the difference between current and desired end-orbit orbital velocity at this point of time. (might not work for relative burn mode).

 

 

Example of advanced application: a low-TWR transfer to Moho from LKO. (based on what I found most efficient in KSP1 for a heavy nuclear-powered mothership - but fully utilizing all these features)

Step 1: Set maneuver mode to Instant TWR, Direct burn and Projection (so that maneuver direction stays constant). Calculate ejection maneuver vector (using prograde, normal and positioning along the orbit - feel free to add as much normal as necessary, you won't waste delta v on it in the actual burn) that gives you desired interplanetary trajectory.

Step  2: burn prograde for a  short time  when passing by the node over multiple orbits, repeatedly raising the apoapsis until you get it to several thousands kilometers (at which point you can can go hyperbolic on the next pass

Step 3: now use normal/antinormal at apoapsis to adjust the orbital plane with the ejection vector.

Step 4: Set mode to Dynamic, Relative, Full integration - and recalculate with mostly prograde burn starting short before the periapsis - you should be able to find a solution that will give you about the same interplanetary trajectory you planned for.

Step 5: just execute the burn!

(And yes, this elliptical spiraling is more efficient than circularly spiraling outward because of Oberth effect - unless you're trying to move interstellar ship on ion engines, that might not have TWR even for this).

[Sea_Kerman]

Of course with all these options we have to set a sane default that will work for most things a new player would want. Perhaps dynamic, secant, end velocity

—

Also, didn’t they fix the plane change drift issue?

Edited September 18, 2023 by Sea_Kerman

[Alchemist]

Yeah, I guess secant is really more understandable in terms of "burn prograde at periapsis to raise the apoapsis" or "burn normal at descending node to match the orbital plane" than constantly fiddling with the start point as well. Timely start combined with dynamic burn prediction would be the best of both worlds (KSP1 and current KSP2 systems).

As for the optimal integration mode, I'm not fully sure which one is the best, as both delta-v integration and end-velocity comparison have potential to get quite off if you drift significantly off the predicted path (although with dynamic TWR burn planning getting too off is not as easy as with KSP1 instant burn calculation). Also, combining end-velocity with dynamic long burns needs some smart accounting for gravity...

 

Speaking of integration, here's another idea which is only applicable for ejection burns, but should be the ultimate answer for interplanetary transfers:

• velocity at ejection - similar to end-velocity, but aims to match the velocity (relative to current celestial body) at leaving SOI, rather than velocity at given time moment. But just comparing SOI-edge velocities doesn't work until you are already very close to desired trajectory, so it's more along the lines of "by how much I need to change my current velocity to have the desired velocity at the edge of SOI" (disregarding exact coordinates or time of SOI leaving: just matching ejection vector is typically more important if you're slightly off the initially predicted trajectory).

[VlonaldKerman]

I think I made a post about this a while back, and I agree. I would add one thing- the ability to plot a trajectory using the “fixed” point-thrust mode, then convert it into a relative one (approximately).

One of the main issues with the new maneuver nodes is that you can’t just make a maneuver at your apoapsis to circularize- where you make your maneuver depends on the length of your burn. You should be able to make a maneuver in this simple mode, and have the game recalculate to find a true trajectory of best fit which approximately matches the trajectory you made in instantaneous impulse mode.

I haven’t really thought this through, but I THINK this solves your cosine loss problem. The cosine loss is really just burning at the wrong time in your orbit.

I THINK…

 

PS if you have math that shows I’m wrong I’d be interested.