How do you calculate the minimal amount of fuel to arrange for a phase shift?

[CyJackX]

Trying to intercept back to Kerbin with a tiny amount of fuel left; I've luckily managed to get into a flat orbit that intersects with the Kerbin orbit, so I know all I'd need to do really is to wait.  But I know I could be waiting a theoretically very very long time to have a random intercept.

I know it must exist out there, I'm just not sure of the exact wording or name of it, where a tiny amount of deltaV might change that natural intercept from dozens of years to only a few.

Visually, it feels like I'm trying to align two sin waves to match up at a specific trough; is there a calculator or just plain math diagram I can setup?  Knowing the orbital periods of the respective bodies, and being able to see the phase angle at the point of intercept, etc, I know it all combines somewhere to tell me how much to change the period to create an intercept if I can tolerate many years of waiting.

 

Edit: Managed to hack together an idea using sin waves and Desmos.com, just created two waves that showed their orbital periods in terms of days to return to a specific location, then added those waves together to see how they aligned and found a good trough to target.

Edited February 10, 2023 by CyJackX
update

[Leganeski]

Great question!

I don't know what this technique is called either; I can only assume that it's not used in real missions because it's so slow.

What I do in that situation is create a new 0 m/s maneuver, and click the "next orbit" button a bunch of times until there is a reasonably close pass sometime in the future. It doesn't need to be an encounter, just a near miss, and the proximity matters less and less the farther into the future it is. (The maneuver node is just to specify a location in time; the KSP engine has no reason to calculate a near miss 27 orbits from now unless it's right after a maneuver.)

After that, I create a new maneuver node on my current orbit, and adjust it by small amounts in the prograde-retrograde direction. As you've already realized, the small change in orbital period is magnified over many orbits, leading to a large change in how close the intercept is. But because of the second maneuver node in the future, KSP actually calculates how exactly that burn will affect the intercept, so it's pretty easy to get it to hit the target.

 

[Streetwind]

That would be my technique as well, but just to add: you need to make these nodes in reverse order. First a node you can add dV to, and then a second node you can use to calculate future intercepts. Otherwise, if you made the future node first, then any additional node you place after that would be happening after that future node. You need it before.

Make liberal use of the ability to move nodes along the orbital path, to find the optimal place for your minimal burn to affect the desired outcome.

[Leganeski]

15 hours ago, Streetwind said:

That would be my technique as well, but just to add: you need to make these nodes in reverse order. First a node you can add dV to, and then a second node you can use to calculate future intercepts. Otherwise, if you made the future node first, then any additional node you place after that would be happening after that future node. You need it before.

Are you sure? I just tried this to check, clicking "add maneuver" when I had a 0 m/s maneuver node a bunch of orbits in the future. The new node got placed on my current orbit, and adjusting it moved the location of the existing node, confirming that they work properly even if the future node is added first.

(It's not relevant to this question, but the test also showed that changing the nearby node can push the future node across SOI changes, which seems weird to do but I guess makes sense considering how maneuver nodes work.)

[Streetwind]

I... was pretty sure? When playing I plan out missions like that somewhat regularly, making three or four successive nodes to visualize the path I will be taking and the intercepts I'm going to get.

I suppose it depends a lot on whether you're actually making the second node on your current orbit, and not on the first maneuver node's projected orbit. Since the first maneuver node will have no dV in it, its projected orbit will be the same as the current one, and they will overlap. My first instinct is to say that that's a case to avoid, as I would not be able to guarantee clicking the correct orbit every time. It should be safer to first create a node with dV and then clicking that projected orbit for the second node.

[Leganeski]

8 hours ago, Streetwind said:

I suppose it depends a lot on whether you're actually making the second node on your current orbit, and not on the first maneuver node's projected orbit. Since the first maneuver node will have no dV in it, its projected orbit will be the same as the current one, and they will overlap. My first instinct is to say that that's a case to avoid, as I would not be able to guarantee clicking the correct orbit every time. It should be safer to first create a node with dV and then clicking that projected orbit for the second node.

You're right that that's probably the safer option.

When the current and projected orbits do overlap, though, it appears that clicking on them will bring up that position on the current orbit rather than the projected one. (You can tell even before clicking because the position indicator that follows your mouse along the orbit line is blue instead of orange.) However, I don't know whether this is always the case, and I wouldn't be surprised if the choice of which one gets selected was dependent on some weird condition.