Algorithm for Making Interplanetary Transfers (almost) as Easy as Getting to The Mun!

[LethalDose]

Wouldn`t it then be more efficient to start the trajectory from the Mun or Minmus (if you have a refueling base there) to plunge towards Kerbin the fastest speed you can get without losing the gravitational slingshot trajectory by re-entry and do the burn at PE?

I suck at science and that`s most likely why I always have to much fuel, or run out short

I do this frequently. Start at Minmus, refuel there, then drop down to just above Kerbin's atmosphere and have a short ejection burn.

[arkie87]

I do this frequently. Start at Minmus, refuel there, then drop down to just above Kerbin's atmosphere and have a short ejection burn.

Is it more efficient to put the refueling base around minimus?

I suppose it depends whether your goal is to refuel rockets leaving kerbin or returning to kerbin?

[LethalDose]

First, on the "thought" experiment, here are the results (Kinda surprised no one's done this):

• Ejection from Kerbin (75km x 76km parking orbit): 1890.5 m/s to xfer to Jool's Altitude
  
• Xfer from Kerbolar orbit (13.3 Mm x 13.8 Mm): 2592.0 m/s to xfer to Jool's Altitude*
  

*transfer done near Pe as well.

So no, getting there from a Kerbolar orbit is even less efficient than from an LKO parking orbit, even with gravity drag losses from the escape.

On the Oberth effect and gravity wells, I only think the Oberth effect is relevant to gravity wells in that both deal with specific orbital energy (e). Basically, you can (and will) escape from a gravity well whenever e > 0, and exploiting the Oberth effect is just an efficient way to get e > 0 with a minimum expenditure of dV. I'm GUESSING that the exit from the SoI should probably remove the same amount of energy (e_p) from the vessel regardless of it's speed at exit, but that does not mean the dV that is lost is the same during the exit. Indeed, if you understand the Oberth effect, then you should see that a vessel going fast can lose the same amount of energy with a smaller change in velocity than a slower vessel.

Huh, okay maybe the Oberth effect is applicable there too, but it only supports that the faster you eject from LKO, the more dV you get to save. Hence it supports the original point I made in the first response that the difference in the dV costs between LKO ejection and Kerbolar transfer becomes more pronounced when traveling to more distant targets.

Is it more efficient to put the refueling base around minimus?

I suppose it depends whether your goal is to refuel rockets leaving kerbin or returning to kerbin?

This is for leaving Kerbin. It's easy to refuel anything in Kerbin's SoI, its difficult to refuel anything outside Kerbin's SoI. Hence, you want to refuel at Minmus since it's the "last stop" on the way out of the system. It's like refueling right before you get to Death Valley. From a pure dV standpoint, it's not more efficient than a direct exit since you have to get captured and then escape from Minmus plus haul the fuel up there, BUT you can leave Kerbin's SoI with more dV which is what is more important IMO. When you're coming back into Kerbin, refuel wherever you want. It's probably more efficient to refuel the vessel at Minmus, because your capture velocity in LKO will be about 3 km/s (highly eliptical with AP near Minmus), but it'd be a headache to hit and Mun will screw with your orbit

I'm only answering this because the OP asked the question, it's getting pretty far off topic.

And its "Minmus", not "Minimus".

[GoSlash27]

LethalDose,

It is actually more efficient to begin your mission from Minmus, setting aside the cost of hauling fuel up there, it's just harder to make the timing work.

Assuming a fueled ship were to spring into existence orbiting Minmus, it would take very little kinetic energy to fall to a 70KM periapsis over Kerbin, and you'll be doing about 3100M/sec when you arrive for your transfer burn. This saves you a big chunk of DV for the Jool transfer due to the Oberth effect. This would be worth trying in-game for an exact savings in DV, but I'd expect roughly 700M/sec under an LKO departure. According to my back-of-the-envelope calculation it's 160M/sec to set up the 70KM periapsis and a 1,055m/sec burn to get to Jool. I'm interest to see what it actually works out to.

As for returning, it's more efficient to refuel in LKO, as you can aerobrake your excess kinetic energy.

Best,

-Slashy

Edited November 11, 2014 by GoSlash27

[LethalDose]

LethalDose,

It is actually more efficient to begin your mission from Minmus, setting aside the cost of hauling fuel up there, it's just harder to make the timing work.

Assuming a fueled ship were to spring into existence orbiting Minmus, it would take very little kinetic energy to fall to a 70KM periapsis over Kerbin, and you'll be doing about 3100M/sec when you arrive for your transfer burn. This saves you a big chunk of DV for the Jool transfer due to the Oberth effect. This would be worth trying in-game for an exact savings in DV, but I'd expect roughly 700M/sec under an LKO departure. According to my back-of-the-envelope calculation it's 160M/sec to set up the 70KM periapsis and a 1,055m/sec burn to get to Jool. I'm interest to see what it actually works out to.

As for returning, it's more efficient to refuel in LKO, as you can aerobrake your excess kinetic energy.

Best,

-Slashy

/Heavy sigh. at the risk of derailing this FURTHER...

I'ma make this brief: To get the vessel up to Minmus in the first place, it initially takes, say, 950 m/s dV. 950 m/s + 1,055 m/s is about 2 km/s, which is basically identical to burning out of LKO in the first place. That doesn't include the Minmus capture and Minmus ejection dV costs, which is what other people have cited as reasons it's not "more efficient overall".

But, you get to break up the burn and and refuel in the middle, so, as I said, you leave Kerbin's SOI with more dV in the tank.

If you want to continue this line of discussion, we should REALLY start a new thread. I'm not responding to this line (IP ejection from Minmus) anymore in this thread.

I mean it this time. Really.

[GoSlash27]

LethalDose,

I'm fine with moving the transfer efficiency discussion to another thread.

What were we originally discussing? Oh, right... finding transfer windows

Really something the team needs to address in-game, but there are many different work-arounds. I'm going to try out the idea I had back on page 2; place a simple satellite in Kerbol orbit just ahead of Kerbin for planning purposes. Using that, you can set a maneuver node and drag it around, which will tell you how many days you have until the transfer window opens up.

Best,

-Slashy

Edited November 11, 2014 by GoSlash27

[arkie87]

First, on the "thought" experiment, here are the results (Kinda surprised no one's done this):

• Ejection from Kerbin (75km x 76km parking orbit): 1890.5 m/s to xfer to Jool's Altitude
  
• Xfer from Kerbolar orbit (13.3 Mm x 13.8 Mm): 2592.0 m/s to xfer to Jool's Altitude*
  

*transfer done near Pe as well.

So no, getting there from a Kerbolar orbit is even less efficient than from an LKO parking orbit, even with gravity drag losses from the escape.

On the Oberth effect and gravity wells, I only think the Oberth effect is relevant to gravity wells in that both deal with specific orbital energy (e). Basically, you can (and will) escape from a gravity well whenever e > 0, and exploiting the Oberth effect is just an efficient way to get e > 0 with a minimum expenditure of dV. I'm GUESSING that the exit from the SoI should probably remove the same amount of energy (e_p) from the vessel regardless of it's speed at exit, but that does not mean the dV that is lost is the same during the exit. Indeed, if you understand the Oberth effect, then you should see that a vessel going fast can lose the same amount of energy with a smaller change in velocity than a slower vessel.

Huh, okay maybe the Oberth effect is applicable there too, but it only supports that the faster you eject from LKO, the more dV you get to save. Hence it supports the original point I made in the first response that the difference in the dV costs between LKO ejection and Kerbolar transfer becomes more pronounced when traveling to more distant targets.

Yes, we established this multiple times in the past 6 pages (sorry if i appear frustrated).

This is for leaving Kerbin. It's easy to refuel anything in Kerbin's SoI, its difficult to refuel anything outside Kerbin's SoI. Hence, you want to refuel at Minmus since it's the "last stop" on the way out of the system. It's like refueling right before you get to Death Valley. From a pure dV standpoint, it's not more efficient than a direct exit since you have to get captured and then escape from Minmus plus haul the fuel up there, BUT you can leave Kerbin's SoI with more dV which is what is more important IMO. When you're coming back into Kerbin, refuel wherever you want. It's probably more efficient to refuel the vessel at Minmus, because your capture velocity in LKO will be about 3 km/s (highly eliptical with AP near Minmus), but it'd be a headache to hit and Mun will screw with your orbit

I'm only answering this because the OP asked the question, it's getting pretty far off topic.

And its "Minmus", not "Minimus".

Makes sense to refuel before departing Kerbin's SOI, as you could save about 3.3 km/s. Good idea!

- - - Updated - - -

First, on the "thought" experiment, here are the results (Kinda surprised no one's done this):

• Ejection from Kerbin (75km x 76km parking orbit): 1890.5 m/s to xfer to Jool's Altitude
  
• Xfer from Kerbolar orbit (13.3 Mm x 13.8 Mm): 2592.0 m/s to xfer to Jool's Altitude*
  

*transfer done near Pe as well.

So no, getting there from a Kerbolar orbit is even less efficient than from an LKO parking orbit, even with gravity drag losses from the escape.

On the Oberth effect and gravity wells, I only think the Oberth effect is relevant to gravity wells in that both deal with specific orbital energy (e). Basically, you can (and will) escape from a gravity well whenever e > 0, and exploiting the Oberth effect is just an efficient way to get e > 0 with a minimum expenditure of dV. I'm GUESSING that the exit from the SoI should probably remove the same amount of energy (e_p) from the vessel regardless of it's speed at exit, but that does not mean the dV that is lost is the same during the exit. Indeed, if you understand the Oberth effect, then you should see that a vessel going fast can lose the same amount of energy with a smaller change in velocity than a slower vessel.

Huh, okay maybe the Oberth effect is applicable there too, but it only supports that the faster you eject from LKO, the more dV you get to save. Hence it supports the original point I made in the first response that the difference in the dV costs between LKO ejection and Kerbolar transfer becomes more pronounced when traveling to more distant targets.

This is for leaving Kerbin. It's easy to refuel anything in Kerbin's SoI, its difficult to refuel anything outside Kerbin's SoI. Hence, you want to refuel at Minmus since it's the "last stop" on the way out of the system. It's like refueling right before you get to Death Valley. From a pure dV standpoint, it's not more efficient than a direct exit since you have to get captured and then escape from Minmus plus haul the fuel up there, BUT you can leave Kerbin's SoI with more dV which is what is more important IMO. When you're coming back into Kerbin, refuel wherever you want. It's probably more efficient to refuel the vessel at Minmus, because your capture velocity in LKO will be about 3 km/s (highly eliptical with AP near Minmus), but it'd be a headache to hit and Mun will screw with your orbit

I'm only answering this because the OP asked the question, it's getting pretty far off topic.

And its "Minmus", not "Minimus".

LethalDose,

It is actually more efficient to begin your mission from Minmus, setting aside the cost of hauling fuel up there, it's just harder to make the timing work.

Assuming a fueled ship were to spring into existence orbiting Minmus, it would take very little kinetic energy to fall to a 70KM periapsis over Kerbin, and you'll be doing about 3100M/sec when you arrive for your transfer burn. This saves you a big chunk of DV for the Jool transfer due to the Oberth effect. This would be worth trying in-game for an exact savings in DV, but I'd expect roughly 700M/sec under an LKO departure. According to my back-of-the-envelope calculation it's 160M/sec to set up the 70KM periapsis and a 1,055m/sec burn to get to Jool. I'm interest to see what it actually works out to.

As for returning, it's more efficient to refuel in LKO, as you can aerobrake your excess kinetic energy.

Best,

-Slashy

Makes sense on both counts.

[arkie87]

LethalDose,

I'm fine with moving the transfer efficiency discussion to another thread.

What were we originally discussing? Oh, right... finding transfer windows

Really something the team needs to address in-game, but there are many different work-arounds. I'm going to try out the idea I had back on page 2; place a simple satellite in Kerbol orbit just ahead of Kerbin for planning purposes. Using that, you can set a maneuver node and drag it around, which will tell you how many days you have until the transfer window opens up.

Best,

-Slashy

Putting a satallite into orbit ahead of Kerbin should work, but you have to remember to adjust orbit to remove eccentricity (requiring more dV), otherwise, it will rapidly become out of sync with Kerbin.

Obviously i think we would all prefer if we didnt have to do that but could use some tool to find transfer windows (rather than than a tool that gives you transfer windows) without having to switch between crafts...

EDIT: perhaps a contract to make the player do this would be useful?

Edited November 11, 2014 by arkie87

[GoSlash27]

Putting a satallite into orbit ahead of Kerbin should work, but you have to remember to adjust orbit to remove eccentricity (requiring more dV), otherwise, it will rapidly become out of sync with Kerbin.

Obviously i think we would all prefer if we didnt have to do that but could use some tool to find transfer windows (rather than than a tool that gives you transfer windows) without having to switch between crafts...

EDIT: perhaps a contract to make the player do this would be useful?

arkie,

I'm ambivalent about it either way.

It's a game, so I totally understand if the developers don't want to make it too realistic (difficult). Otherwise, people will look outside to web references/ mods/ etc to find their transfer windows.

But something should be done, since people can't make the trip without transfer windows. They don't want the players giving up in frustration, either.

So give them the windows or make them earn them... whichever they decide. But the solution should be in-game.

Best,

-Slashy

[arkie87]

arkie,

I'm ambivalent about it either way.

It's a game, so I totally understand if the developers don't want to make it too realistic (difficult). Otherwise, people will look outside to web references/ mods/ etc to find their transfer windows.

But something should be done, since people can't make the trip without transfer windows. They don't want the players giving up in frustration, either.

So give them the windows or make them earn them... whichever they decide. But the solution should be in-game.

Best,

-Slashy

I think we all agree something is needed in game. But i always prefer tools to figure it out (easily) over being given the answer.

Perhaps a simple GUI to draw tangent lines for the "munrise" technique would be accurate enough...

[Starman4308]

I am personally imagining some toggle in the map view, which when set, gives you the approximate transfer windows as color-coded sections on the orbit of your current body. So, if you had a Jool transfer window in the next Kerbin orbit, that window would show up as a green patch along Kerbin's orbital track.

That, or have some sort of protractor function built-in so you can measure phase angles at arbitrary points of time, possibly with a little notepad attached so the person can write down a table of phase angles.

[GoSlash27]

Or conversely, a tic mark in each planet's orbit to show when it will be in alignment for the transfer window on Kerbin's current orbit.

Either of these would work fine as a "give it to them" solution.

As an in-game solution, you could have a team of Kerbals tasked with finding transfer windows. Asking them questions would cost funding.

Best,

-Slashy

[arkie87]

I am personally imagining some toggle in the map view, which when set, gives you the approximate transfer windows as color-coded sections on the orbit of your current body. So, if you had a Jool transfer window in the next Kerbin orbit, that window would show up as a green patch along Kerbin's orbital track.

That, or have some sort of protractor function built-in so you can measure phase angles at arbitrary points of time, possibly with a little notepad attached so the person can write down a table of phase angles.

So you gave me an idea: instead of spamming all transfer windows in map view or making it toggle-able... why not integrate it into current KSP system: when you target a planet, it shows you the optimum transfer window on the map in map view....

This can probably be programmed into the game right now via a plugin --- is there a plugin that does this?

[John FX]

Kerbal Alarm Clock can be used to set an alarm at the next transfer window to any planet. That functionality built into stock would be a good solution to the OP.

Apart from that I quite like the idea of putting a guidance satellite just outside of kerbin SOI and using it to find transfer windows. If it is a known distance prograde then the time adjustment factor would be easily calculated.

You could used KAC to remind you when they are coming up.

[arkie87]

Kerbal Alarm Clock can be used to set an alarm at the next transfer window to any planet. That functionality built into stock would be a good solution to the OP.

Apart from that I quite like the idea of putting a guidance satellite just outside of kerbin SOI and using it to find transfer windows. If it is a known distance prograde then the time adjustment factor would be easily calculated.

You could used KAC to remind you when they are coming up.

Yes, I am aware of KAC, but, like most people who post about things that already exist in mod form, I am a fan of using minimum amount of mods and/or intelligently integrating mods into KSP environment such that they dont feel like mods and/or clutter the game.

The best example of a mod/plugin that integrates perfectly into KSP GUI environment is a mod called "landing height." When landing, you obviously are more concerned with height above ground than height above sea level. However, in stock KSP, altimeter always shows height above sea level (in IVA mode, altimeter shows height above surface, but this view is less helpful when landing). You could use Kerbal Engineer, which would display height above ground (in addition to height above sea level); however, a better approach to integrate better into the game is that when navball is in "surface mode" altitude displayed on altimeter is height above ground whereas when navball is in "orbital" mode, altitude is above sea level, and the "landing height" plugin does this exactly ( http://forum.kerbalspaceprogram.com/threads/76320 ).

That said, I think integrating transfer window visually into the map view when a body is "targeted" integrates nicely into KSP GUI environment.

Alternatively, an automatic toggle in map view to switch the reference body used to draw the orbital trajectory i.e. if you are orbiting Kerbin, it shows you trajectory around Kerbin (and you can click on it to add maneuver nodes). When you zoom out far enough such that this trajectory is no longer visible, it automatically toggles to show your trajectory around Kerbol instead, and you can click on this trajectory and add maneuver nodes.

EDIT: I am aware that when displaying trajectory around Kerbol whilst orbiting Kerbin, the trajectory would technically be helical; however, for the purposes of the drawing and simplicity, it can just take the trajectory of the body it is orbiting i.e. Kerbin.

Edited November 12, 2014 by arkie87

[JimmyAgent007]

I am personally imagining some toggle in the map view, which when set, gives you the approximate transfer windows as color-coded sections on the orbit of your current body. So, if you had a Jool transfer window in the next Kerbin orbit, that window would show up as a green patch along Kerbin's orbital track.

That, or have some sort of protractor function built-in so you can measure phase angles at arbitrary points of time, possibly with a little notepad attached so the person can write down a table of phase angles.

I said almost this exact thing on page 8, glad to see others thinking along the same line

[arkie87]

I said almost this exact thing on page 8, glad to see others thinking along the same line

Yes, you did. I think i quoted you and thanked you for giving me an idea of how to improve/integrate your idea to eliminate the need for a toggle button

[LethalDose]

This probably isn't going to be a popular opinion here, but oh well.

I don't think launch window indicators need to be included in the stock game.

This reason for this is that there is no single correct method to do any transfer. Don't get me wrong, there are tons of ways to do them wrong, but a stock indicator that gave a single solution would send the message that there is a single right way to do it. I also worry that a stock system that allowed other methods (e.g. bi-elliptic or opposition transfers) or would be too cumbersome or complex to present to many novice players.

Hohmann transfers are the "right" transfer to use to many common destinations, e.g. Eve, Duna, and Jool but, frankly, they suck for transfers to Eeloo, Dres, and especially Moho due to those destinations' orbital eccentricities and inclinations (seriously, people who try to Hohmann xfer to Moho make me sad). This totally fine for mods, but I don't think it's appropriate in stock.

It's also an opportunity for

. In fact, I think that players having difficulty with difficult parts of the game, e.g. interplanetary transfers, makes the community more robust since it encourages these players to come to the forums for help. These reasons are a little bit "meta", but I think it's still valid.

I really think that the stock game does need to provide players with more information in a lot of places (e.g. dV, TWR, orbital incl, Lat/Long coords in orbit, etc. Basically, KER), but I don't think that phase angles for transfers are one of things that need to be added given that we have maneuver node system.

Edited November 12, 2014 by LethalDose

[arkie87]

This probably isn't going to be a popular opinion here, but oh well.

I don't think launch window indicators need to be included in the stock game.

This reason for this is that there is no single correct method to do any transfer. Don't get me wrong, there are tons of ways to do them wrong, but a stock indicator that gave a single solution would send the message that there is a single right way to do it. I also worry that a stock system that allowed other methods (e.g. bi-elliptic or opposition transfers) or would be too cumbersome or complex to present to many novice players.

Hohmann transfers are the "right" transfer to use to many common destinations, e.g. Eve, Duna, and Jool but, frankly, they suck for transfers to Eeloo, Dres, and especially Moho due to those destinations' orbital eccentricities and inclinations (seriously, people who try to Hohmann xfer to Moho make me sad). This totally fine for mods, but I don't think it's appropriate in stock.

It's also an opportunity for

. In fact, I think that players having difficulty with difficult parts of the game, e.g. interplanetary transfers, makes the community more robust since it encourages these players to come to the forums for help. These reasons are a little bit "meta", but I think it's still valid.

I really think that the stock game does need to provide players with more information in a lot of places (e.g. dV, TWR, orbital incl, Lat/Long coords in orbit, etc. Basically, KER), but I don't think that phase angles for transfers are one of things that need to be added given that we have maneuver node system.

I agree with you. But i think one option is to improve maneuver node system to make it possible for players to find transfer window on their own, such as suggestion two posted here: http://forum.kerbalspaceprogram.com/threads/99944-Best-Way-to-Integrate-Transfer-Windows-into-Existing-KSP-GUI-Environment