Yasmy

Given your assumption of constant mass (i.e., the sepratron fuel mass is tiny), use the terminal velocity equation in http://wiki.kerbalspaceprogram.com/wiki/Atmosphere, but replace GM/r^2 with (GM/r^2 - TMR). v = sqrt( 250 kg/m^2 * (GM/r^2 - TMR) / (rho * d) ) TMR = number of sepratrons * thrust of a single sepratron / mass of return vehicle (i.e., TMR = TWR * g0 = 9.82 m/s^2 * TWR)

There's nothing wrong with my math, to within the stated approximations. Vtarget - VPe is consistent, but it is not the savings. It is merely the Vtarget minus the low-planetary-orbit to moon transfer delta-v, (if what you mean by Vtarget is the delta-v from LKO to enter another planet's SOI.) The savings (or loss) is something like (dv to reach hyperbolic excess velocity V at the parent's SOI from the moon's orbit) - (dv to reach the same hyperbolic excess velocity V at the parent's SOI from parent on a return orbit from moon, ie, Vtarget) - (dv to drop the periapsis down from the moon to the parent). That's not going to give a nice simple value for the savings as a function of the hyperbolic excess velocity V, or as a function of Vtarget.

Here's a table of the approximate costs of going from a low orbit (~10 km above ground or atmosphere) to around a moon to a planet other than the moon's parent, ignoring inclination and eccentricity. The table compares three methods: 1) Dropping down to the parent planet (~ 50km if no atmosphere, atmosphere + 10k otherwise) for the interplanetary transfer burn. 2) Going interplanetary from the moon directly. 3) For comparison, the cost of going from the parent, not starting at the moon. Nephew -> Uncle: Moon->Parent->Uncle Moon->Uncle Parent->Uncle Gilly -> Moho: 776.2 1366.6 1643.4 Gilly -> Kerbin: 506.7 497.3 1373.4 Gilly -> Duna: 775.1 1363.7 1642.3 Gilly -> Dres: 1308.3 2475.7 2176.5 Gilly -> Jool: 1647.9 3047.7 2516.7 Gilly -> Eeloo: 1785.8 3263.9 2654.7 Mun -> Moho: 1135.4 1509.0 1698.5 Mun -> Eve: 462.1 348.0 1024.1 Mun -> Duna: 497.6 414.1 1059.7 Mun -> Dres: 987.4 1278.5 1550.3 Mun -> Jool: 1360.5 1840.5 1923.9 Mun -> Eeloo: 1520.3 2064.9 2083.8 Minmus -> Moho: 943.4 1957.7 1698.5 Minmus -> Eve: 270.1 439.7 1024.1 Minmus -> Duna: 305.6 566.8 1059.7 Minmus -> Dres: 795.4 1699.9 1550.3 Minmus -> Jool: 1168.5 2318.7 1923.9 Minmus -> Eeloo: 1328.2 2558.7 2083.8 Ike -> Moho: 1969.9 2158.6 2117.9 Ike -> Eve: 907.9 975.0 1055.4 Ike -> Kerbin: 464.4 421.2 611.4 Ike -> Dres: 658.5 671.2 805.7 Ike -> Jool: 1158.0 1265.7 1305.7 Ike -> Eeloo: 1381.6 1517.6 1529.4 Laythe -> Moho: 2228.4 1272.9 3134.9 Laythe -> Eve: 2108.9 1131.3 3015.4 Laythe -> Kerbin: 2048.8 1062.7 2955.2 Laythe -> Duna: 1979.5 986.3 2885.9 Laythe -> Dres: 1905.8 908.7 2812.1 Laythe -> Eeloo: 1892.9 895.6 2799.2 Vall -> Moho: 1834.8 1334.3 3134.9 Vall -> Eve: 1715.3 1098.9 3015.4 Vall -> Kerbin: 1655.2 980.1 2955.2 Vall -> Duna: 1585.9 844.0 2885.9 Vall -> Dres: 1512.2 701.9 2812.1 Vall -> Eeloo: 1499.3 677.6 2799.2 Tylo -> Moho: 1807.1 1298.3 3134.9 Tylo -> Eve: 1687.6 1140.9 3015.4 Tylo -> Kerbin: 1627.5 1067.0 2955.2 Tylo -> Duna: 1558.2 987.7 2885.9 Tylo -> Dres: 1484.5 912.6 2812.1 Tylo -> Eeloo: 1471.6 900.7 2799.2 Bop -> Moho: 1451.6 1652.4 3134.9 Bop -> Eve: 1332.1 1275.0 3015.4 Bop -> Kerbin: 1272.0 1068.1 2955.2 Bop -> Duna: 1202.7 810.9 2885.9 Bop -> Dres: 1129.0 510.4 2812.1 Bop -> Eeloo: 1116.1 454.9 2799.2 Pol -> Moho: 1335.3 1739.4 3134.9 Pol -> Eve: 1215.8 1332.0 3015.4 Pol -> Kerbin: 1155.7 1104.1 2955.2 Pol -> Duna: 1086.4 814.5 2885.9 Pol -> Dres: 1012.7 461.6 2812.1 Pol -> Eeloo: 999.8 394.0 2799.2 Like Red Iron Crown suggested, going directly to Eve or Duna from the Mun is cheaper than dropping down and performing the interplanetary burn at Kerbin, but going to any other planet directly from the Mun is more expensive. Also note that dropping down to the parent planet can be used to perform a cheap inclination change for some transfers. I don't have time to type up the equations at the moment. It's just a series of applications of the vis-viva equation, and taking into account the orbital velocity of a body when you cross its SOI.

Normal = bad (points north if you are going east around Kerbin) Radial = bad (points away from Kerbin if you are going east around Kerbin) Prograde = good (points east if you are going east around Kerbin) Don't burn normal or radial. It is a huge waste of fuel. Drop a maneuver node, and pull the prograde marker until you have an escape trajectory. (About 1000 m/s.) Then drag the maneuver node around Kerbin until the escape is parallel with Kerbin's trajectory. You want a hyperbolic Kerbin orbit which takes you to a low eccentricity elliptical Kerbol orbit. (You can make normal direction adjustments to your maneuver node after you create the approximately correct 1000+ m/s prograde burn, to help match inclination with your destination.)

Pecan, you are being unnecessarily pedantic. Quite obviously he meant intersecting Eve from Kerbol orbit to change his Kerbol inclination, which I'm sure you knew.

Yes. So for Kerbin, it should cost about 2*174 m/s extra to insert into a retrograde orbit, or just 174 m/s extra to insert into a polar orbit. Note that the approximately 4500 m/s to Kerbin orbit that many people quote already assumes launching east. I'm not aware of any simple approximate formulae, though a simple ballpark approximation should be possible. But you can't get better than approximate for a problem this complex. Otherwise there are two routes to go: 1) Full simulation 2) Trial and error A few people on the forums have written their own KSP physics simulators to calculate the costs to orbit through an atmosphere. The answer depends on the details of your rocket and trajectory. They calculate delta-v by integrating the equations of motion as the rocket ascends. On the other hand, many people have lifted off from every landable body in KSP many times, and through trial and error have created delta-v maps as guidelines. See, for example, the delta-v map on wiki cheat sheet page.

1) What you have calculated is the orbital velocity at surface level, if Kerbin did not have an atmosphere. For orbital velocity at some radius above the surface of the planet, add the orbital altitude to the planetary radius: v = sqrt(G Pm / (Pr + altitude)) 2) A rotating planet has a non-zero surface velocity. Depending on which direction you head into orbit relative to the surface velocity, the cost to orbit is increased or decreased by something less than or equal to the surface velocity. This is why people pitch over east to orbit Kerbin. It reduces the cost of orbital insertion. If you did this calculation (orbital velocity +/- component of surface velocity along orbital inclination) for an airless planet or moon, you would roughly get the correct delta-v to orbit. To achieve an orbit around a body with an atmosphere there are two other costs: 3) Atmospheric losses: Atmospheric drag is proportional to the atmospheric density and the square of your velocity. You have to expend a lot of delta-v to push though the atmosphere. 4) Gravity losses: Any fuel spent burning radially away from a planet is lost delta-v. Until you pitch over, almost all of your delta-v is lost to gravity (and atmospheric drag on a body with an atmosphere). To orbit, you have to expend delta-v perpendicular to the body's radius. Gravity losses also apply around airless bodies. Any delta-v spend going up to avoid mountains, or to give your engines time to get to orbital velocity is delta-v lost to so-called gravity drag. It depends on your flight profile, but roughly speaking, gravity drag and atmospheric drag for Kerbin orbit are both around 1 km/s. Edit: triple ninjaed!

You have put yourself in the middle of "What goes up, must come down.", i.e., the apex of a suborbital trajectory. So what were you trying to achieve?

Those parts used to have different functions. Now they both just provide torque. Use the lighter one. Some day they will get around to eliminating one of them, or converting into something with a different function. http://wiki.kerbalspaceprogram.com/wiki/Stability_Augmentation_System

Ha! I run a script which auto-commits quicksaves and persistence updates to a git repository. The .sfs file format plays very nice with source code management software: text files which update in chunks, leaving other parts untouched. I would highly recommend it to people making movies. Make commits with nice commit messages so you can easily find your scenes, without having a ton of backup quicksaves lying around. I've had too many problems with KSP bugs and mod bugs messing up my game. Now I can go back in time to any point in the past. If my mission fails because of my stupidity, I leave it be. But I have no qualms about reversing arbitrarily far back in time to solve an exploding ship bug.

Duna's surface speed is about 31 m/s. So it'll cost about that much more to launch into polar orbit, and twice that to launch into a retrograde orbit.

Let's do the simple vessel example: 900 units of Xenon weighs 0.09 t. Initial mass: 0.7 t, Final mass: 0.61 t g0 = 9.82 m/s^2 (KSP reference acceleration. Not the local g or Earth's 9.81 m/s^2.) Isp = 4200 s dV = Isp * g0 * ln (0.7 / 0.61) = 5676 m/s Though for your hypothetical vessel I get 0.73 t, without a kerbal. Kerbals in a command seat weigh 0.09375. Thus: dV = 4200 * 9.82 * ln ((0.73 + 0.09375)/(0.64 + 0.09375) m/s = 4772 m/s.

Looks good to me. (Except 3700 - 2200 = 1500, not 1700.) And if you are willing to aerobrake, you can subtract a bunch of the 950 m/s for Kerbin capture on return.

ninjaed... If you are not using 0.23.5, a stock solution is to change the patch mode to zero in settings.cfg: CONIC_PATCH_DRAW_MODE = 0 Then use Tab to focus on the body you want to refine the maneuver around.

The delta-v maps generally don't include plane change maneuver delta-v. If you are not near the line of nodes when you begin your transfer, the plane change maneuver can be quite large, as you've noticed. Alex Moon's launch planner will give you a low delta-v window, which typically occurs along the line of nodes.

I haven't had any problems landing and taking off from the shores on Laythe as long as your plane is not tipsy. Scouting from air should be sufficient. You may have to land on a bit of a slope, but you can find long stretches of uniform shallow slopes along the shores.

Is it possible that the large number of air intakes up front are adding to your instability? I think they have a higher drag than most parts, so naturally want to twist around to the rear. Someone please correct me if I'm wrong. How do ships orient themselves, for example, on atmospheric entry? I understood it to be through higher drag forces on higher drag parts. Edit: Now I see Claw mentioned the ram scoop on the front...

Probably because launching a mobile reprocessing lab (which doesn't exist) is more expensive and less reliable than launching a pile of new spacecraft. Even if the long term costs of recycling were lower, no agency can get the money to create something to harvest materials for unplanned and unfunded missions. Harvesting materials in space will not be useful or economical until lots of people are actually living in space.

I can't give you a formula to plug number into, or anything that you can do by hand. I also don't know javascript, but I know enough other languages that the code is pretty clear. I'll give you a rough overview of how the code works, for educational purposes. If you have any more questions, feel free to ask. 1) For some trial orbit, (described by current velocity, current radius, and periapsis) which intercepts an atmosphere, the code a) finds where the spacecraft enters the atmosphere (simple geometry) integrates the equations of motion to determine the spacecraft trajectory in the atmosphere (like KSP's physics simulation, rather than being on rails in time-warp) until c) the spacecraft (crashes or) exits the atmosphere, and d) calculates the apoapsis given the atmospheric exit parameters. Integration of the equations of motion is done by the Velocity-Verlet integration method. The equations of motion are F = ma = Fgravity + Fdrag. You can find KSP's drag model in the wiki. KSP atmospheres move with the surface of the planet, so alterbaron's drag model allows you to add or subtract off the velocity of the atmosphere from the velocity of the spacecraft for retrograde or prograde orbits, respectively, when calculating the drag force. 2) Step 1 produces an apoapsis after exiting the atmosphere. It is probably not the apoapsis you want. Since you can't just solve analytically for the periapsis which produces your desired apoapsis, this code uses a root finding method: specifically, the method of bisection. So the code follows the spacecraft through the atmosphere a bunch of times, each time narrowing in a bit more on the trajectory which gives the desired apoapsis, if it exists. 3) If successful, the code spits out not a periapsis, but a maneuver. There are many possible maneuvers which would give you the same periapsis, depending on how much you burn prograde/retrograde versus how much you burn radially. But the different maneuvers would give you different post-aerobraking apoapses. Likewise there are many maneuvers which give different periapses, but the same post-aerobraking apoapsis. alterbaron's step 2 only tests maneuvers which change the direction of your vehicle without changing your current speed. It is a nice way to reduce a two-dimensional problem (burn direction + burn delta-v) into a one-dimensional problem (burn direction, with delta-v determined by keeping speed fixed). This vastly simplifies the procedure in step 2 to find the desired maneuver. You would have to use a two-d minimization method, instead of a root-finding method. It may not always give the minimum delta-v maneuver, but it probably does a pretty good job most of the time.

maccollo and I are basically both just using the vis-viva equation: v^2 = mu (2/r - 1/a), though he stated in conservation of energy form: KE + PE = v^2/2 - mu/r = constant. 1) Use the vis-viva equation at any point inside the Mun's SOI to find your semi-major axis: 1/a = 2/r - v^2 / mu r = current distance from center of Mun (or whatever) = current altitude + body radius (assuming altitude is measured from surface) v = current velocity a = semi-major axis mu = gravitational parameter = G * M = Newton's constant times the mass of the body. 2) Substitute the semi-major axis from step 1 into the vis-viva equation at periapsis (rp) to find your periapsis velocity vp: vp = sqrt(mu (2/rp - 1/a)) = sqrt(mu (2/rp - 2/r) + v^2) Where ever you are in orbit, this calculation tells you how fast you will be going at periapsis. r = current distance from the center of the Mun v = current velocity rp = periapsis distance from center of the Mun vp = velocity at periapsis 3) Then to get your delta-v for circularization at periapsis, just subtract off the velocity of a circular orbit from your periapsis velocity: Again, from the vis-viva equation, the velocity of a circular orbit at radius rp is v = sqrt(mu(2/rp - 1/rp)) = sqrt(mu/rp) 4) dv = sqrt(mu (2/rp - 2/r) + v^2) - sqrt(mu/rp) kOS can tell you v, r, rp and M. I think you have to supply G. Just make sure that r and rp are relative to the center of the Mun, rather than to the surface. Clear?

Basically just echoing maccollo here. It looks like kOS can tell you your current altitude and velocity and your periapsis altitude. Your periapsis velocity, given your current velocity and orbital radius is sqrt(v^2 + mu (2/rp - 2/r)). Subtract off circular orbit velocity sqrt(mu/r). If kOS works in altitude, which appears to be the case, don't forget to add the body radius to the altitudes to get orbital radius at current location and periapsis.

This is the whole point of this thread: Modest deviations from terminal velocity cost less than a percent delta-v to orbit. I.e.: It just shouldn't matter for most people. If delta-v is what you care about, anything in the ballpark of terminal velocity has a tiny effect on delta-v to orbit. Large deviations on the low end (starting TWR < 1.2-1.5) can cost a lot more in gravity drag (5-10% delta-v to orbit) but are more cost effective (engine count/cost/part number).

You're right. I started with (dW/dt)/F=(mgv+mva)/(mg+ma+kv2) = v / (1 + (k/(ma+mg)) v^2), and normalized my definition of efficiency to be 1 at terminal velocity: e = 2 (dW/dt)/F /vT. I didn't realize that I had in the process assumed TWR of 2 when I changed v/(1 + (k/(ma+mg)) v2) to v/(1 + (v/vT)2). That was sloppy. So my analysis incorrectly only applied to flight at a TWR of 2, for which (ma+mg)/k = m|g|/k = vT2. Instead (dW/dt)/F = v/(1 + (k/(ma+mg)) v^2) = v/(1 + (v/vT)2/(TWR-1)).

I'm going to kick this dead horse one more time. I asked how much it matters if you don't follow terminal velocity. Alchemist provided a definition of efficiency, energy gained per thrust, and that efficiency is maximized at terminal velocity. Let's normalize it to be 1 at terminal velocity, vT: e = 2 (v/vT) / (1 + v2/vT2) Suppose you are moving near terminal velocity at v = vT + δv, where δv can be positive or negative. Series expanding the efficiency around terminal velocity: e = 1 - 1/2 (δv/vT)2 + O(δv/vT)3 Small deviations from perfect efficiency had to be quadratic or higher, or terminal velocity wouldn't be a maximum. If you are 10% above or below terminal velocity, your efficiency is only off by 0.12/2 = 0.5%. I.e., it'll cost you less than 25 m/s extra delta-v to orbit at 10% above or below terminal velocity. Of course this only applies in the atmosphere, so total losses to atmospheric inefficiency are even smaller. (Actually, it may be slightly better still, since this is energy gained per thrust, not delta-v gained per thrust. Have to think about it...) Correction: This should have been e = 2 (v/vT) / (1 + (v/vT)2/(TWR-1)).

Yes. The title of this thread was perhaps a bit trollish. I defined "better" TWR strictly from a delta-v perspective. That's because I see lots of people saying you waste tons of delta-v with high TWR. But that is just not true. Decreased gravity drag costs partially offset increased atmospheric drag costs, resulting in a very small delta-v penalty. You do lose efficiency in terms of payload fraction. You need a heavier lifter with more engines to reach higher TWR. In the real world, what matters is dollars, or whatever your national or nationalistic currency is. (Budget + pride + technology payoff + safety.) As others have pointed out above, optimizing for economic cost, for payload fraction, or for overall complexity can be more important than minimizing delta-v. In KSP? Well, I like to optimize for fun. (Though I like to talk about theory about as much as I like playing.)