Interplanetary Transfer Methods and Avoiding the False Trajectory Display Bug

[Starhawk]

On 4/13/2023 at 9:34 AM, Poppa Wheelie said:

Since we'll have to use this "burn to leave the SOI and then make corrections" method for at least the near future

This is an interesting discussion.  I love seeing the creativity and thought that allows players to work around bugs like this one.

Exiting a body's SOI with minimal excess velocity and then plotting a transfer to a destination from Kerbol orbit is a perfectly valid and useful method of astrogation.  I do think it's a good idea to be clear about why this isn't done in real world space flight and what exactly are the upsides and downsides of doing it this way.
Upsides:

1.  It's easy.  This method is very simple and makes sense.  Essentially you do things stepwise.  Burn just enough to leave an SOI and get into a stable orbit of Kerbol.  Then, create a maneuver to get to a destination.
2.  It removes the need for external planning tools.  Once you are outside the SOI of the body you are leaving, you simply create a maneuver that makes your orbit just touch the orbit of your destination and then slide the maneuver around your orbit until you have an encounter.  This process can be fiddly (and may require waiting for the ship to complete one or more orbits around Kerbol) but can be done without any external tools for finding phase angles or launch windows or required dV.
3.   It works completely around the bug.

Downsides:

1.   It takes a lot more dV.  This means, of course, a larger craft requiring more fuel.  This likely means more stages and a more complex ship.
2.   It's not realistic.  This is precisely because of the high dV requirement.  IRL rockets are extremely expensive and complex to build.  Engineers always work extremely hard to make everything as small and light as possible while still functional.  I expect this is only a downside for some players.

As far as downside 1., the question is 'How much more dV does it take?'  The answer, as indicated above, is 'A lot.'.

Let's see just how much.  To do that, I loaded a save with a ship in 80 km Kerbin orbit, and set up a burn to reach Jool's orbit directly.  I then reloaded the same save and burned just enough to leave Kerbin's SOI and then created a maneuver to reach Jool's orbit.

Here's a look at the burn directly from Kerbin orbit.

And here's a look at the 'two burn' method where I burned just enough to exit Kerbin's SOI and then set up a burn from Kerbol orbit to get to Jool's orbit.

So, the single burn from Kerbin orbit requires 1960 m/s of dV to get to Jool's orbit.  The 'two burn' method requires 939 m/s to leave Kerbin SOI and then another 2538 m/s to go from near Kerbin's orbit to Jool's orbit.  So 2538 + 939 = 3477 m/s total.  That's not quite double, but it's way more.

Why does it take so much less if we make the burn in low Kerbin orbit as opposed to in Kerbol orbit?  The answer is The Oberth Effect.  This is a fairly math heavy concept, but the upshot is that fuel burned prograde (or retrograde) while moving at a high velocity low in a gravity well gives you much more 'bang for your buck' than fuel burned prograde (or retrograde) moving at a low velocity high up in a gravity well.  That's not a great description and I'm sure somebody more knowledgeable could come along and give a much more accurate description.  But it's enough to convey the basic idea.

It is still fully possible to use the more efficient Hohmann transfer (the first method above) for all interplanetary burns right now.  You simply have to know which direction you want your trajectory to go compared to the orbit of the body you are leaving, know about how much dV you need to burn, and know when to burn.  You also have to ignore the trajectory line displayed until after you leave the SOI.

Happy landings!

 

 

Edited April 17, 2023 by Starhawk
Added link to original bug report

[Poppa Wheelie]

44 minutes ago, Starhawk said:

You simply have to know which direction you want your trajectory to go compared to the orbit of the body you are leaving, know about how much dV you need to burn, and know when to burn.

Thanks for the test, results, and analysis @Starhawk.  

Since we're specifically talking about the "can't see projected or actual trajectory until after departing the SOI" issue for Duna to Kerbin (and any other planets this may affect), then all options right now are "two burn" options.

I'm interested in the following 3-way comparison.  Assume I have determined transfer window date, phase angle, and dV requirement from other tools.

• Option 1, "Shot in the Dark" or "Flying Blind" option: 
  • Depart Duna on the transfer window date.  Use best guess for placement of the maneuver plan to achieve required phase angle.  Use best fast-finger method to begin and end the burn on time, and to use the exact amount of dV required. 
  • After leaving the Duna SOI, build and execute a "correction" maneuver plan to get the results you actually need.
• Option 2, "On Time Duna Burn" option. 
  • Depart Duna on the transfer window date.  Use best guess for placement of the maneuver plan to achieve required phase angle.  Burn only enough dV to barely exit the Duna SOI. 
  • As soon as possible after leaving the Duna SOI, build and execute a "correction" maneuver plan to get the results you actually need.
• Option 3, "On Time Correction Burn" option. 
  • Depart Duna so as to leave the SOI shortly before the transfer window date.  Use best guess for placement of the maneuver plan to achieve required phase angle.  Burn only enough dV to barely exit the Duna SOI. 
  • As soon as possible after leaving the Duna SOI, build a "correction" maneuver plan and place it as close to the transfer window date as possible. 
  • Execute this "correction" maneuver to get the results you actually need

If you, or anyone else, wants to run this test and post results, that would be great!  If not, I'll give it a go after I finish the Eve weekly challenge (I can't get the game to recognize that my  Eve lander/ascender has separated from the mothership).

[Scarecrow71]

On 4/15/2023 at 9:08 AM, Starhawk said:

Why does it take so much less if we make the burn in low Kerbin orbit as opposed to in Kerbol orbit?  The answer is The Oberth Effect.  This is a fairly math heavy concept, but the upshot is that fuel burned prograde (or retrograde) while moving at a high velocity low in a gravity well gives you much more 'bang for your buck' than fuel burned prograde (or retrograde) moving at a low velocity high up in a gravity well.  That's not a great description and I'm sure somebody more knowledgeable could come along and give a much more accurate description.  But it's enough to convey the basic idea.

While I'm not the smarter math person you were hoping for to explain this, I can say that I view this as the craft being pushed away from the celestial body.  The gravity well is working for you, providing a high amount of external force to push you away.  More force up front equals more initial speed. Which then means you don't need as much fuel to get to optimal speed.  The inverse is true here as well.  When not being assisted by this external force, you have a slower initial speed, which requires more fuel to get up to the optimal speed.

A good example of this, although not exact, is the hammer toss.  The slower the person spins, the closer to that person the hammer will fall once released, unless they apply a great deal of push at the time of release.  If they spin fast, they don't need to push the hammer when release, simply letting it fly away from them.

Edited April 17, 2023 by Scarecrow71

[Wetzelrad]

12 hours ago, Poppa Wheelie said:

all options right now are "two burn" options.

I'm not sure that's accurate. Even without manuever planning and trajectory prediction, burning directly to a SOI encounter should be possible with good timing and good aim. Especially so if you aim for a big target like Jool. Alternatively, if it's true that this bug, for instance in Duna's case, causes trajectory projections to be off by exactly 180 degrees, then it should be possible to create a manuever and rotate it 180 degrees around Duna to get the desired result.

Anyway, practically speaking, you're right. Doing a correction burn is always a good idea.

13 hours ago, Poppa Wheelie said:

• Option 1, "Shot in the Dark" or "Flying Blind" option: 
  • Depart Duna on the transfer window date.  Use best guess for placement of the maneuver plan to achieve required phase angle.  Use best fast-finger method to begin and end the burn on time, and to use the exact amount of dV required. 
  • After leaving the Duna SOI, build and execute a "correction" maneuver plan to get the results you actually need.
• Option 2, "On Time Duna Burn" option. 
  • Depart Duna on the transfer window date.  Use best guess for placement of the maneuver plan to achieve required phase angle.  Burn only enough dV to barely exit the Duna SOI. 
  • As soon as possible after leaving the Duna SOI, build and execute a "correction" maneuver plan to get the results you actually need.

Option 1 will be much cheaper, for certain. Although it might be nice to check exactly how much.

In the trip planner, Duna Intercept represents the tiny amount of added dV it takes to go from exiting Kerbin's SOI to intersecting Duna's SOI. That number would be much higher in orbit around the sun, as I think we all can attest.

13 hours ago, Poppa Wheelie said:

Option 3, "On Time Correction Burn" option. 

• Depart Duna so as to leave the SOI shortly before the transfer window date.  Use best guess for placement of the maneuver plan to achieve required phase angle.  Burn only enough dV to barely exit the Duna SOI. 

This makes more sense than option 2, but I wouldn't expect the savings to be dramatic.

[Starhawk]

This thread has been split off from the bug report since it has diverged sufficiently to be off topic there and it's a useful topic on it's own.

On 4/15/2023 at 10:22 AM, Poppa Wheelie said:

Since we're specifically talking about the "can't see projected or actual trajectory until after departing the SOI" issue for Duna to Kerbin (and any other planets this may affect), then all options right now are "two burn" options.

On 4/15/2023 at 11:55 PM, Wetzelrad said:

I'm not sure that's accurate. Even without manuever planning and trajectory prediction, burning directly to a SOI encounter should be possible with good timing and good aim

Let me reiterate a point from my post above which, no doubt, got lost in the wall of text.
You don't need to use the 'two burn' method to get home to Kerbin from another planet even with the bug.

If you know the required dV and the date of the transfer window you can do the burn to get close to Kerbin return.  Yes there will need to be a correction burn simply because without accurate trajectory prediction we can't fine tune our maneuver node to the needed precision.

The key to all of this is the geometry of Hohmann transfers.  A Hohmann transfer orbit for Duna to Kerbin just touches the orbit of Duna at one end and just touches the orbit of Kerbin at the other end.  In terms of geometry, this means that your trajectory away from Duna should be parallel to the trajectory of Duna's orbit around Kerbol.  Since you are going to a body in a lower orbit around Kerbol, you want to go in the opposite direction as Duna is moving.  This does not take inclination into account, but inclination differences between Duna and Kerbin generally require only small course corrections.

So if you know how much dV you will need and when to leave, you just place a maneuver on your orbit and give it the needed amount of dV prograde.  Then, adjust the camera to be looking directly 'down' at Duna's north pole and then slide it around the orbit until the departure trajectory is parallel to the body you are orbiting.  Grabbing the node to slide it can be a bit fiddly, but it works.  This also requires zooming out a ways to see your result trajectory become almost a straight line so you can tell whether it's parallel or not, zooming in to make it easier to slide the node around in small increments, zooming out to check, etc.  So a bit fiddly, but it works and should require only a relatively small correction burn to achieve/refine your rendezvous with Kerbin.

Now on to the demonstration.

Here is a craft in orbit of Duna.  I overshot the optimal window for my 73 km orbit by about five days but that shouldn't make much difference.  Looking 'down' at Duna's North pole.  The faint red vertical line in the centre of the image is Duna's orbit around Kerbol.  It is moving upward in the image, so we want to go downward when we leave Duna.

Based on that, the maneuver should be somewhere around the periapsis in the above image.

I make a maneuver node there with the dV reported by the external launch window planner, in this case 560 m/s.

This is a little bit off from pointing straight down so I'll zoom in and slide the node around until I get it where i want.

After a bit of adjustment it is pointing straight down along the faint red line of Duna's orbit.

Now I go ahead and make the burn.  Shortly after exiting Duna's SOI I make a maneuver for the course correction.  A very small correction of 31 m/s gets me a nice tight rendezvous.

An additional 5 m/s at the AN was used to tweak the inclination and that's that.

The single burn (plus corrections) method cost 560 + 31 + 5 = 596 m/s

Now for the double burn method.

The burn to exit Duna's SOI from my 73 km orbit cost 357 m/s.  The direction of this burn makes almost no difference because the point is that the minimum needed to escape the SOI is used and thus there is little excess velocity after leaving Duna's SOI.  In any case, I burned to achieve the same trajectory as in the first method.  After leaving Duna's SOI, the result is that I was in almost exactly the same orbit around Kerbol as Duna was, but just a bit behind it.

I set up the burn to return to Kerbin and ran straight into the new behaviour of the maneuver tool.

I can't see how much dV the maneuver will require because the craft does not have enough to get home using this method.  487 m/s are required to get as far as the image above plus the original 357 m/s to exit Duna's SOI makes 844 m/s spent and it still doesn't get the craft back to Kerbin's orbit.  Not sure how much more is needed because of the change to the maneuver tool.

So the double burn method cost 357 + 487 + ? = ?
Thus 844 + ? = ?

Anyway, even in Duna's relatively small and shallow gravity well the Oberth effect makes a huge difference.
 

On 4/15/2023 at 11:55 PM, Wetzelrad said:

Alternatively, if it's true that this bug, for instance in Duna's case, causes trajectory projections to be off by exactly 180 degrees

It turns out that this is not the case at all.  Various bodies have false trajectory predictions that are off angle by varying amounts as seen in this post.

Happy landings!

[Scarecrow71]

48 minutes ago, Starhawk said:

Grabbing the node to slide it can be a bit fiddly, but it works. 

This is one of my serious pain points in KSP2.  In KSP1, you could grab the node and move it with relative ease.  In KSP2, it's hard just trying to grab the thing.  And when you move it - or, at least when I move it - it is jerky and I can never get it where I want it.  And the dV requirement of the burn changes when I move it.  I can provide video to show what happens on a circularization burn if that helps clarify what I mean.

[Starhawk]

24 minutes ago, Scarecrow71 said:

And the dV requirement of the burn changes when I move it.

That should definitely not be happening.  I'll look for that behaviour in my game.

Happy landings!

[Poppa Wheelie]

2 hours ago, Starhawk said:

I make a maneuver node there with the dV reported by the external launch window planner, in this case 560 m/s.

 

@Starhawk, this is great!  I will check it out later today.  What external launch window planner did you use?  This one, or something different?

https://alexmoon.github.io/ksp/

 

[Starhawk]

34 minutes ago, Poppa Wheelie said:

@Starhawk, this is great!  I will check it out later today.  What external launch window planner did you use?  This one, or something different?

https://alexmoon.github.io/ksp/

 

Thanks!  That is, indeed, the one I use.  It works great for me.  Remember that the calendars between KSP1 and KSP2 are different by a year because there was no year zero in KSP1.

 

2 hours ago, Scarecrow71 said:

In KSP2, it's hard just trying to grab the thing.  And when you move it - or, at least when I move it - it is jerky and I can never get it where I want it.

I find that the movement is less jerky when I zoom in to the maneuver somewhat.  When the orbit is a small circle on the screen, it's hard to get the maneuver where I want it.  I spend a lot of time zooming in and out when planning a maneuver. 

Happy landings!

[LeroyJenkins]

On 4/15/2023 at 12:19 PM, Scarecrow71 said:

The gravity well is working for you, providing a high amount of external force to push you away

@Starhawk, @Scarecrow71is on the proper track. The Oberth Effect is related to the Gravity Assist (or sling shot) maneuver. Without performing a dV burn, the sling shot maneuver uses the celestial body's gravity force to add to the vehicle's velocity. Thus increasing the vehicle's energy, and direction. Oberth is just adding more kinetic energy to the sling shot maneuver through mechanical means (ie, thrust). The bigger benefit of the Obreth Effect is when one compares a powered sling shot (vs non powered, gravity assist only, like what the Voyager s/c used - see graphic. At each flyby the s/c velocity get a boost)  that is performed at a lower Pe altitude (ie, higher initial vehicle velocity) than the same dV at a higher Pe altitude (ie lower initial vehicle velocity).

Vector Geometry helps illustrate this, for a non powered Sling Shot

Vector U and V are the components of the total velocity vector of the spacecraft before and after the sling shot fly by. The V+U is larger after the fly by due to U gets added to by the gravitation force (pull) of the celestial body. Or V+U+Vg > V+U (keeping U constant). Now Vg is based on F = (Gc*m1*m2)/(r^2), Gc is the gravitational constant. m1 and m2 are the masses of the two objects, and r is the distance between the two objects. As r gets smaller (ie, the spacecraft gets closer to the celestial body), F increases exponentially, thus velocity (Vg) increase exponentially (as long as you don't enter the atmosphere).

Now, for the Oberth effect. One plans an orbital transfer burn at Pe (ie, where r is its smallest and U is its max) and add a dV burn, you have V+U1+Vg1+dV. If you perform the same dV at an higher altitude (ie, r is larger, U at Pe will be slower, and Vg will be lower as well). Therefore (V+U2+Vg2+dV) < (V+U1+Vg1+dV). So plan your flyby sling shot burns at a lowest as possible Pe altitude, without getting into the planets atmosphere for minimum dV needed.

Edited April 18, 2023 by LeroyJenkins

[Poppa Wheelie]

I used the “Parallel Lines Method” demonstrated by @Starhawk earlier, and I am satisfied that:

• This is the most efficient method
• This method is repeatable

 

Thanks again, Starhawk.  This is the method I will use until the game is fixed.  I learned a whole lot from the entire exercise.

More details of the tests I ran, for those who are interested:

Spoiler

I mentioned in a previous post that I wanted to compare three methods.  Each of these methods does, in fact, require two burns:  the first in Low Duna Orbit, and the second shortly after leaving the Duna SOI.  I would really love to see someone have a Kerbin encounter upon exit of the Duna SOI, with a repeatable process.  

I compared these three Options:

• Option 1:  Flying Blind
  • I used Starhawk’s Parallel Lines method, so although I couldn’t see what was happening outside the Duna SOI, I had a much better visual method of determining where to place the Maneuver Plan
• Option 2:  On Time Duna Burn
  • From Duna orbit burn only enough to depart the SOI
  • Do this burn as close to the external tool transfer date as possible
  • Do a second Maneuver Plan immediately upon exiting the Duna SOI to get the Kerbin encounter
• Option 3:  On Time Correction Burn
  • Same as Option 2, except do the first burn in Low Duna Orbit about 26 days before the transfer date
  • So that the second Maneuver Plan can be done very close to the transfer date

Here are the tool I used, and the Transfer Window date and required dV I got.  These are the only two numbers needed from the tool, although the date needs to subtract one year since the tool does not have a Year Zero as we do in KSP2:  https://alexmoon.github.io/ksp/

• Transfer Window Date:  002y238d00h07m12s (corrected for KSP2)
• Required dV:  642m/s

Here are the results I got:

	Parallel Lines Method	On Time Duna Burn	On Time Correction Burn	dV Map or Mission Planner
Escape Burn dV	642	363	362	360
Correction dV	266	894	874	390
TOTAL dV	908	1257	1236	750
Amt Over Alex Moon	266	615	594	108

Conclusions:

• Parallel Lines Method is significantly better
• On Time Correction Burn is slightly better than On Time Duna Burn, but not by much
• I’m pretty sure that getting much closer to the tool's required dV, and especially to get under the dV Map (Mission Planner) total dV, will be possible once the game is fixed (as I was able to do in KSP1)

Starhawk’s initial dV was much smaller than mine, and the correction was dramatically smaller than mine (31m/s to my 266m/s).  I can only assume that Starhawk had a different transfer window date, and that I am much less skilled at working the correction burn.  Turns out I was able to start the Parallel Lines Method ejection burn only 6 minutes before the Transfer Window Date, I used exactly the required 642m/s of dV, and my lines looked pretty parallel.

I tried building the correction burn maneuver plan three times.  I got 271 twice, and 266 on the final try.

I was pleased to see that the Alex Moon tool matched up on Phase Angle and Ejection Angle.  But, by using the Transfer Window Date, and the Parallel Lines Method, I didn’t really need to eyeball those numbers.

I used this tool to put the interactive protractor over my screenshots:  https://www.ginifab.com/feeds/angle_measurement/

Parallel Lines

60 Degree Phase Angle

220 Degree Ejection Angle

 

[Starhawk]

10 hours ago, Poppa Wheelie said:

the correction was dramatically smaller than mine (31m/s to my 266m/s).

I think what's going on is a misunderstanding.  Probably because I type too much when I get going.

Your ejection trajectory in the 'Parallel Lines' pic isn't parallel to Duna's orbit.  It is mostly downward, but it is angled to the left in the pic rather than straight along Duna's orbit line.

I believe that's why your correction was so large.

The longer orange line that is goes all the way from top to bottom along Duna's orbit line should be ignored.  Only your ejection trajectory needs to be parallel.  I have grabbed your pic and drawn where the trajectory should be for an optimal transfer.

That greenish yellow (yellowish green?) line shows where the trajectory should be.  So it should look more like this.

Anyway, I hope that makes sense.  With that, you should be able to make the course correction much smaller.

Happy landings!

[Starhawk]

I was poking around a bit  to find some posts I remember from the 'old days' and found this thread discussing the Oberth Effect.  Just in case anybody wants a cool rabbit hole to explore.

Lots of great discussion in there.

Lots of math, too. 

Happy landings!

[Poppa Wheelie]

1 hour ago, Starhawk said:

Only your ejection trajectory needs to be parallel

Aha!  OK, I'll try this from the same save and report back.

[Poppa Wheelie]

Success!

Using the Parallel Lines Method as it should be done (sorry that I misunderstood), I actually had an encounter upon leaving the Duna SOI, without the need for a correction!

However, 31 m/s applied at the An or Dn (I don't remember which, but it was not too far along the orbit after leaving Duna), I got a very nice, zero degree inclination, 84km Pe with Kerbin.

Some screenshots:

Spoiler

I changed from this plan:

To this plan:

Exit path looks parallel to Duna orbit

Still looks parallel after the burn

Encounter upon SOI exit!

31 m/s at the An gives this, with an 84km Pe

 

[Starhawk]

2 hours ago, Poppa Wheelie said:

Success!

Using the Parallel Lines Method as it should be done (sorry that I misunderstood), I actually had an encounter upon leaving the Duna SOI, without the need for a correction!

Sweet!

And that, gentle reader, is how we do that.

Happy landings!

[RocketRockington]

On 4/15/2023 at 12:08 PM, Starhawk said:

It's not realistic. 

It's also unrealistic because there's no such thing as a discrete SOI where you pop between one frame of reference and another for keplerian orbital conics.

[Starhawk]

9 minutes ago, RocketRockington said:

It's also unrealistic because there's no such thing as a discrete SOI where you pop between one frame of reference and another for keplerian orbital conics.

Of course there are no discrete SOI's in real life.  Nonetheless 'patched conics' is a pretty good abstraction.

Good enough that it was used for the Apollo program.

Happy landings!

[RocketRockington]

Just now, Starhawk said:

Of course there are no discrete SOI's in real life.  Nonetheless 'patched conics' is a pretty good abstraction.

Good enough that it was used for the Apollo program.

Happy landings!

In some rough approximations for some early guesstimates, I'm sure they did.  But not for actual mission planning.  Apollo wouldn't have had a correct free return trajectory just by using patched conics and hill spheres, for instance.