Time to reach every planet from LKO.

[TeeGee]

Does anybody have a map or wiki page that tells me how long it would take a spacecraft to reach another planet from LKO? I'm trying to plan a mission using tac life support and would like to figure out how much food/water/air I need to bring with me for the trip to and back.

Thanks!

[Drew Kerman]

You're looking for best-case times I assume? Otherwise what are your parameters? The time it takes a craft to get to a planet depends mostly on when you launch (transfer window) and what route you take to get there (direct burn, gravity assist, oberth burns, etc)

[stanz250]

ksp.olex.biz

[LethalDose]

Does anybody have a map or wiki page that tells me how long it would take a spacecraft to reach another planet from LKO? I'm trying to plan a mission using tac life support and would like to figure out how much food/water/air I need to bring with me for the trip to and back.

Thanks!

I'm not familiar with any pages that summarize the travel times, but I agree, it'd be useful info to have for LS mods. The good new is that you can ball-park the values pretty easily. If you have something in orbit, just set up a maneuver node that burns to an apoapsis/periapsis of your target, and then check when that apoapsis occurs by mousing over the AP marker. For instance, I have a space station in LKO at 125 km altitude. To figure out the transfer time to Duna, I just put a node on the dark side of the obit, and increased prograde until the AP laid on top of Duna's orbit (even tho there wasn't an encounter there). I just did it in like 5 mins for the "common" targets, and got the following results for typical ballistic Hohmann transfers:

[table=width: 300, align: Left]

[tr]

[td]Target[/td]

[td]Kerbal time[/td]

[td]Earth Days[/td]

[/tr]

[tr]

[td]Eve[/td]

[td]209 d[/td]

[td]52 d[/td]

[/tr]

[tr]

[td]Duna[/td]

[td]314 d[/td]

[td]79 d[/td]

[/tr]

[tr]

[td]Jool[/td]

[td]2 yr + 287 d[/td]

[td]282 d[/td]

[/tr]

[/table]

DISCLAIMER: These are super quick, dirty "back of the envelope" values. I accept zero responsibility for any dead or MIA Kerbals if any of them are wrong.

These are only done to show it's quick. If anyone thinks these are wrong, feel free to provide more accurate values.

Another option would be to follow these steps:

1. Quicksave
   
2. Launch a "dummy" ship
   
3. Timewarp to your transfer window
   
4. Set up your node to make sure you get an encounter
   
5. Check the encounter time
   
6. Quickload back to your initial save
   
7. Profit!
   

This method also lets you calculate travel times for approaches non-Hohmann transfers (e.g. bi-elliptical transfers, opposition-class missions).

However, don't forget you have to include provisions for your Kerbals to return and for them to stay until the return mission opens. The duration of the stay until return is more difficult to calculate. I'm about to start doing interplanetary missions with TAC - LS, and I think I'm going to just wing it with enough provisions for support each Kerbal for about 220 days (About 2 Kerbin years).

Finally, if you like to do "teh maths", you can calculate the transfer time for a hohmann using:

T = pi * sqrt([(O1 + O2)^3]/8mu)

where O1 is the orbit of the source above the sun, O2 is the orbit of the target above the sun, and mu is the sun's gravitational parameter. I adapted the traditional orbital period equation on the fly, so, again, it may be wrong. Also that equation will probably give you the transfer in seconds, so you'll have to convert to days.

ksp.olex.biz

I don't see where this page provides travel times.

Edited June 15, 2014 by LethalDose

[Lucky 38]

http://alexmoon.github.io/ksp/

That website may help

It offers the time of the trip, when to expect to be there(according to your current game time), transfer Delta V, phase angles etc.

[Kryxal]

The launch planner provides travel times once you tell it to give you a transfer from point a to point b in such-and-such a time window ... and if you don't like that result, you can customize your transfer at greater delta-v cost.

[Claw]

If you are just looking for a quicklook cheat sheet, you can also use many of the deltaV maps. Several list approximate flight times.

Do make sure that the time setting you are using in KSP (Kerbin vs Earth time) matches the deltaV map, or you might run into a problem.

Edited June 15, 2014 by Claw

[TeeGee]

Wow, the time it takes to get to Duna is 1 year... I never realized that until now, and I've been going there since 0.19...

Jool is ridiculous! I LOVE THIS MOD (TAC Life support)!! Now I actually have to design a spacecraft as opposed to an engine with rocket fuel.

[cantab]

For a Hohmann transfer, periapsis and apoapsis matching the orbital radii of your start and destination planets. Semi-major axis of the transfer orbit is the average of those, remember to consider the size of the sun. Orbital period by Kepler's Third Law, and your transfer time is half that period.

[LethalDose]

I LOVE THIS MOD (TAC Life support)!! Now I actually have to design a spacecraft as opposed to an engine with rocket fuel.

I want to frame this statement for everyone who complains that LS shouldn't be stock because its not fun, so I can hit them in the face with it politely show it to them.

For a Hohmann transfer, periapsis and apoapsis matching the orbital radii of your start and destination planets. Semi-major axis of the transfer orbit is the average of those, remember to consider the size of the sun. Orbital period by Kepler's Third Law, and your transfer time is half that period.

Have you found that the sun's radius makes a meaningful difference when calculating transfer times? I understand why it should be included, but I've never found that it makes a substantial difference.

[Claw]

I want to frame this statement for everyone who complains that LS shouldn't be stock because its not fun, so I can hit them in the face with it politely show it to them.

Not to derail (or start a mod war), but I bet for each mod you could find a person who would say "I love it!"

I love MechJeb. I think it's great for many reasons and I don't even use most of it's capabilities. There are lots of people who don't like it at all. I certainly don't want to punch them in the face. (Yes, a joke. I know.)

I'm not saying "don't include LS." I'm just saying that people have different play styles and it's pretty darn hard to pick and choose the game's core elements while still making it accessible. (Perhaps beginner/intermediate/advance modes would help.)

(/end tangent)

[TeeGee]

Well in my humble opinion, LS, DR, and FAR need to be implemented into the core game.

KSP is about teaching players what is involved in managing a space program and building/designing spacecraft to explore the Kerbol System.

If a planet has atmosphere, it needs to obey fluid dynamics in a realistic way (to a degree). Building a pancake in vanilla KSP and getting it into orbit is very easy. What does that teach people about building things aerodynamically?

Reentry needs to be incorporated (yes I know it is planned). Having spacecraft reenter atmo at 2000 m/s and NO heat up is ridiculously illogical.

Kerbals are living entities that require food, heat, water, produce waste, and breathe air. Why wouldn't spacecraft have expendable food, water etc? LS should be part of a rockets payload. As of right now, the ONLY worry anyone has is amount of delta V to get to a planetary body. That's only step 1 of building a spacecraft...

I honestly don't care if squad ever incorporates these things into stock kerbal, because I have this great modding community to give me the mods that I want to make kerbal the game I always dreamed of!

I'm very excited to see what our community comes up with next to improve the kerbal experience!

[MarvinKitFox]

Note that the times listed are for least-fuel, Hohmann transfers.

It is quite possible to speed up the transit, if you are willing to risk a speeding ticket.

For example, in a recent challenge for fastest career mode in btsm, i needed to get to Duna and back. Using as few days as possible, *including* time needed to wait for the planets to align.

Perfect Hohmann transfer would have started in about 56 days, and taken 78 days to get there.

Then a layabout of 236 days before I can even start back, and another 84 days to get back to Kerbin.

I could afford neither the time nor the lifesupport to loaf around for 454 days!

So, i cheated.

Instead of the miserly 8000m/s rocket one actually needs to go to Duna and back, I made a 16800m/s firecracker.

Launch immediately, in *retrograde* orbit direction. Dive down past EVE's orbit, then burn hard once the angle is right and zoom up to Duna.

I got there in 36 days.

I got back in 48 days.

That's a sight easier on the lifesupport than 454 days.

And all it cost me was 4500 m/s going there, and 3700m/s coming back, in excess of the actual needed delta-v the charts ask for.

[Pecan]

...Perfect Hohmann transfer would have started in about 56 days, and taken 78 days to get there.

Then a layabout of 236 days before I can even start back, and another 84 days to get back to Kerbin.

I could afford neither the time nor the lifesupport to loaf around for 454 days!

:-( In a challenge I just got the transfer completely wrong and ended-up at 310 days ^^. Could I borrow you to drive for the next one?

@ TeeGee:

...KSP is about teaching players what is involved in managing a space program and building/designing spacecraft to explore the Kerbol System...

...Kerbals are living entities that require food, heat, water, produce waste, and breathe air.

What are your source documents for these statements?

Building a pancake in vanilla KSP and getting it into orbit is very easy. What does that teach people about building things aerodynamically?

It teaches them that in KSP there are some people who think pancakes can fly and some people who can fly pancakes? A (computer) model always leaves out some features of the real entity and no-one ever said KSP had to teach people about building things aerodynamically.

[StrandedonEarth]

Well in my humble opinion, LS, DR, and FAR need to be implemented into the core game.

KSP is about teaching players what is involved in managing a space program and building/designing spacecraft to explore the Kerbol System.

If a planet has atmosphere, it needs to obey fluid dynamics in a realistic way (to a degree). Building a pancake in vanilla KSP and getting it into orbit is very easy. What does that teach people about building things aerodynamically?

Reentry needs to be incorporated (yes I know it is planned). Having spacecraft reenter atmo at 2000 m/s and NO heat up is ridiculously illogical.

Kerbals are living entities that require food, heat, water, produce waste, and breathe air. Why wouldn't spacecraft have expendable food, water etc? LS should be part of a rockets payload. As of right now, the ONLY worry anyone has is amount of delta V to get to a planetary body. That's only step 1 of building a spacecraft...

I honestly don't care if squad ever incorporates these things into stock kerbal, because I have this great modding community to give me the mods that I want to make kerbal the game I always dreamed of!

I'm very excited to see what our community comes up with next to improve the kerbal experience!

In order to keep this thread on track, I created a thread in the Suggestion forum as a reply.

[GoSlash27]

:-( In a challenge I just got the transfer completely wrong and ended-up at 310 days ^^. Could I borrow you to drive for the next one?

@ TeeGee:

What are your source documents for these statements?

It teaches them that in KSP there are some people who think pancakes can fly and some people who can fly pancakes? A (computer) model always leaves out some features of the real entity and no-one ever said KSP had to teach people about building things aerodynamically.

This is the sort of situation that people stress over when designing a spacecraft and why most of the DV maps are of limited value. Nobody wonders "how long would it take to get to Jool if everything went perfectly" when designing a ship.

If I'm designing something with life support, I want to assume that we miss our rendezvous and have to correct our orbit to intercept on the next pass.

I would say the time for transfer plus one orbit of the target body plus whatever fudge factor makes you comfortable.

Best,

-Slashy

[Claw]

If I'm designing something with life support, I want to assume that we miss our rendezvous and have to correct our orbit to intercept on the next pass.

I would say the time for transfer plus one orbit of the target body plus whatever fudge factor makes you comfortable.

Kind of like we have been saying before. What now if the dV map builds in extra days because it assumes 1 extra orbit. You still have to assume an orbital altitude, so what if it doesn't match my altitude? Then I have to remove someone else's fudge factor to add my own. What if I don't know what the assumed fudge factor is?

Perhaps in this instance there could be an extra set of numbers next to a planet/moon. It would include the time to orbit at a given altitude. Now I know what the assumed altitude is and I can decide how many orbits I want to add (my safety margin), instead of someone just burying that information in the base numbers and me digging it out.

The other factor with "how long does it take to get to Jool if everything went perfectly" doesn't take into account that I can burn a bit harder to get there faster. Now we get into the other complications we discussed earlier. Am I aerobraking, slingshotting, how much oberth, etc. At some point you need to get out the pencil and start making your own dV budget for your profile. dV charts are just guides to get started. It's hard to plan a dV chart that suits everyone's wishes/desires/assumptions/profiles.