Yasmy

Let's find out: v^2 = mu (2/ r_SOI - 2/(r_SOI + r_LDO)) mu = 3e11 m^3/s^2 r_SOI = 4.8e7 m r_LDO = 4e5 m v = 10 m/s So, 10 m/s * sqrt(2 - 2 cos(73)) = 24 m/s. (Law of cosines for a triangle with two length 10 sides with a 73 degree angle between them.) Nailed it, MarvinKitFox!

This is only (approximately) true for very small changes in altitude. Otherwise, the acceleration due to gravity is not constant. (g® = GM/R^2.) I'm guessing you probably know this but just misspoke at the time. Either way, calculating impact velocity based on change in gravitational potential energy, which is what I think you did, is correct.

This is fairly minor, but it always bugs me. Your large lander appears (I could be wrong) to have the RCS thrusters on the ordinal points (NE, SE, SW, NW) rather than on cardinal points (N, E, S, W). If you thrust in a cardinal direction, approximately 29% of your RCS fuel is wasted, since your thrusters thrust at 45 degrees to your net thrust direction.

Throwing another Jeb on the pile:

My preferred phrasing is "Theory and practice are closer in theory than in practice." But I'm still left with the questions as to why the current maps don't suit his purposes. It is inaccuracies in the delta-v values or is there something else that he wants to see on the maps, presented in a new way? All we know is that he doesn't like the current maps.

I understand why people want to calculate their own delta-v maps. I've done it myself. But I don't understand your post. But what kind of map do you want? Why do the normal delta-v maps not suit your purpose? What do you not like about the currently available charts? What would your map have that the x6.4 map doesn't have? I am quite curious. As a side note, calculating delta-v to orbit from a body with an atmosphere is just an approximation. Expect it to be wrong by as much at 10%. The only way to get a good answer is to simulate it, either with a custom integrator, or with one designed specifically for this problem (for example, Kerbal Space Program makes a good KSP simulator.)

Physics warp is no more of a cheat than normal warp. Instead of hitting , or . to increase/decrease warp, hit Alt-, or Alt-. to increase physics warp. During physics warp, the full physics simulation is run, but at a larger time step. To within the accuracy of the physics engine, the results should be the same as at normal speed. But if you have a large, clunky ship, Bad Things can happen, such as Rapid Unplanned Disassembly.

If you want to save 100 m/s by using the Mun to assist in escaping Kerbin, that's cool and all. It's fun. But it's not a delta-v saving strategy, because if you escape Kerbin, wait for a window, then burn to Jool or Moho, you will spend approximately 1500-1700 m/s more delta-v than burning directly from LKO. Roughly, without plane changes, to +/- 200 m/s: Kerbin -> Interplanetary + Interplanetary -> Jool ~= 1000 + 2700 m/s Kerbin -> Jool ~= 2000 m/s If you don't care about the extra delta-v, no worries. Do whichever floats your fleet. If you do care, don't park in interplanetary space.

The most fuel efficient way would be to assemble in LKO and do your transfer burn in stages, like the Mars Orbiter Mission (Mangalyaan). Burn for a few minutes each time you reach the correct side of Kerbin, then shut down the engines, complete most of an orbit, and continue elongating your orbit. Of course, fuel efficiency may not be your priority. If it was, you might not build such monstrous vehicles which take hours to accelerate. Assembling in high Kerbin orbit or in interplanetary space is always a delta-v loss, but if that doesn't concern you, then go for it. Another option is to send a fleet of individual rockets. The beauty of KSP is that you get to try every method. You get to decide what "best" means on a mission-by-mission basis. You've left such an open ended mission design question for us. What are your concerns? What do you want to do? What sounds fun to you?

I agree with GoSlash27. Why do you need an escape system and discardability? Discardability doesn't hurt (except financially), but when does it help? I think you'll find that flying high and fast you can go quite far without fuel. Plenty far enough perform a safe unpowered landing someplace smooth, even if you run out of fuel over mountains. Are you trying to save the capsule because it can store science?

If you are worried about not fulfilling one of the contract requirements, open up the contract pane in the top right corner of the screen next to resources. Met conditions are highlighted in green. Unmet conditions are in grey. No guesswork needed.

2) A maneuver node editor such as Precise Node makes fine-tuning maneuver nodes very easy. A) Drop a node near your current location. Hit Tab repeatedly until your intended target is your current focus. (Backspace to focus on your ship again.) C) Zoom in until just your target and your encounter trajectory are visible, ie, well within the target's SOI. D) Adjust your node until it is where you want it. Zoomed in like this on your target, it is very easy to see the effects of adjustments in the three velocity components (prograde, radial, normal), and thereby easy to judge how to set up the correct burn. E) If the adjustments are too small to perform accurately with your engines or RCS ports, move the node forward in time and try again.

Set your branch cut after subtracting angles, not before: Assuming these lines are good: set Angle1 to obt:lan+obt:argumentofperiapsis+obt:trueanomaly. //the ships angle to universal reference direction. set Angle2 to target:obt:lan+target:obt:argumentofperiapsis+targ et:obt:trueanomaly. //target angle Then: set Angle3 = Angle2 - Angle1. set Angle3 = Angle3 - 360 * floor(Angle3/360). Now 0 <= Angle3 < 360, and describes the number of degrees your target is ahead of your ship.

This is just a choice by the developers to make decoupler joints be less rigid than normal joints. Use strut connectors, or deal the the flex.

1) Drop a maneuver node near your current location. 2) Go to map mode and hit tab to change your focus until it lands on Gilly, then zoom in so that your orbit and Gilly are the only things in view. 3) Now when you adjust the maneuver node, you can see exactly how each little tug moves your orbit towards or away from Gilly, and it is pretty easy to figure out how to set exactly the encounter you want. It helps to have a node editor mod so fine adjustments are possible, and you don't have to keep zooming out and clicking your node to make the handles pop up every time you click somewhere on the screen. I use this method to fine-tune all my encounters, whether it is an initial transfer burn, a mid-course correction, or a near-SOI last minute adjustment. Works great. If you can't generate the encounter you want from your current location, move the maneuver node to the AN/DN and try again.

Well, you did kind of miss the joke. The joke is that that widely available simulation software for home computers is called Kerbal Space Program.

How about you give us the orbital parameters to play with? Even if you are not yet docked to it, the asteroid's parameters are in your save files. Now, lets do some math... Givens: mu and R for the parent body, Pe, Ap, APe (argument of periapsis) and i (inclination). Then a = (Ap + Pe + 2R)/2 e = (Ap - Pe)/(Ap + Pe + 2R) Let P2 be your target Periapsis. Case 1: Plane change at the farthest node, followed by lowering periapsis from apoapsis. We don't know or care if it is the AN or the DN, so call it the SN, for slow node. rSN = radius at the slow node = a (1-e2) / (1 + e cos(APe)). (Actually, if pi/2 <= APe < pi/2, replace APe with pi-APe.) vSN = speed at the slow node = sqrt(mu (2/rSN - 1/a)) Burn 1 is the plane change: ÃŽâ€V12 = 2 vSN2 (1-cos(i)) Burn 2 lowers Pe to P2: ÃŽâ€V2 = sqrt(mu (2/(Ap+R) - 2/(Ap + Pe + 2R))) - sqrt(mu (2/(Ap+R) - 2/(Ap + P2 + 2R))) ÃŽâ€V = ÃŽâ€V1 + ÃŽâ€V2 Case 2: Circularize, followed by combined plane change and periapsis lowering burn: Circularize: ÃŽâ€V1 = sqrt(mu/(Ap + R)) (1 - sqrt((Pe + R)/a)) Now we are at v2 = sqrt(mu/(Ap + R)) at inclination i, and want to go to v3 = sqrt(mu (2/(Ap + R) - 2/(Ap + P2 + 2R))) at zero inclination: ÃŽâ€V2 = sqrt(v22 + v32 - 2 v2 v3 cos(i)) ÃŽâ€V = ÃŽâ€V1 + ÃŽâ€V2 Of course there are many variations on these cases, but these are the simplest two. For example, you could burn at Pe to push your Ap out first. Maybe someone will feel like making plots of the two cases: for a few different eccentricities, make 2D plots of the difference between case 1 and case 2 vs APe and i...

B: You are correct, and B: Use physics-less parts. Stock trip to Jool in 2 hours, and back to Kerbin in a second or so by Mr. Manley: If that's your thing, go for it. I prefer time warp. (Though max time warp to Eeloo does take quite a long time.)

It is not true that the average acceleration is (initial + final acceleration)/2. Your formula might work fairly well for some rockets, but not for all. This is because the acceleration is not a linear function of time. Assumptions: constant thrust (F), Isp, and fuel consumption (dm/dt = c). Let the burn time be T, the initial mass be m0 and the final mass be m1 = m0 - c * T. a(t) = F / m = F / (m0 - c * t) The average of a(t) is a_avg = 1/T * (the integral of a(t) from 0 to T). You should not be surprised to discover this gives the rocket equation: a_avg = 1/T (F/c ln(m0/(m0 - c*T)) = F/(m0-m1)/T * ln(m0/m1) = Isp/T * ln(m0/m1) Then, like The_Duck said, dV = average acceleration times time: dV = Isp * ln(m0/m1). So when will your formula work well? For small mass loss: (m0-m1) << m0. Then ln(m0/m1) is approximately linear in mass loss: ln(m0/m1) ~ (m0-m1)/m0. And since mass loss is linear in time at constant thrust, for small mass loss, the average acceleration is also approximately linear. TLDR: If you use a small amount of your total mass, dV ~ (final - initial acceleration)/2 * time. But if you use a bunch of your mass, you have to use the rocket equation. Edit: ninjad!

In addition to the fine comments above, I'm going to give the standard advice: moar struts. Or, at least, better strutting. Specifically, those side arms appear to only be restrained radially. They could use some axial (lateral) restraint to prevent side to side motion. It looks to me like the attached vehicle is doing a good job of indicating lack of rigidity in the main craft.

Inclination changes can be trivial when going between moons. It is not like changing your inclination when you are in a stable orbit. Once you have an intercept with a distant moon, small normal (out of plane) adjustments greatly change the latitude of your swing-by, which will greatly change the inclination of your orbit once you exit the moon's SOI. It's the same as adjusting your inclination around a planet from far away on an interplanetary transfer trajectory. Tiny out of plane adjustments make huge changes to your exit inclination.

Picking a window depends on your mission criteria. Delta-v, time until next window, transfer time and relative orbital inclination are some possible criteria. For many people, the next available reasonable delta-v maneuver is what people care about, much more than transfer time. This is typically a Hohmann transfer for which you will go half way around the sun to get to your target. So the transfer window occurs when the target planet will be half way around the sun from where you are now when you get there. This does not typically occur when the starting and ending planets are near each other. If what you care about is transfer time, you could create a rocket with many times the minimum delta-v needed, and get there much faster. But it is very inefficient. It sounds like what you really should look at (after figuring out how to get the transfer time down to nominal) is the soonest return launch date from Duna. Then budget life support for the number of days between launch from Kerbin and return to Kerbin from the next Duna to Kerbin launch window after Duna arrival. Extra fuel spent reducing transfer time probably won't pay off on the voyage out since you have to wait for a return window.

@LethalDose 1) If the delta-v map that we used is inaccurate, well, sure, my numbers will be wrong. I didn't vet the dV map. But I am not wrong that circularization at planet B on an interplanetary trajectory from planet A (capture + circularization, if you prefer) is the same delta-v as escape + transfer from B to A. Just play the maneuver backwards in your head. (Gravity is symmetric under time reversal.) Looks like metaphor gave us a better map. It appears he also supports my statement that for the reverse trip, just a) read the numbers in the opposite direction, and regard the outgoing transfer burn as part of your incomming circularization burn. 2) It is not true that the transfer cost from Kerbin to Duna is the same as Duna to Kerbin. Why speculate? I gave the formulae for a Hohmann transfer. You don't even have to plug in numbers. Clearly dv1 is not equal to dv2. Which is the same as saying swapping r1 and r2 in dv1 gives a different transfer burn.

Really, I should just let the above equations stand for themselves. Trust the math. But I'll just use LethalDose's example of Kerbin to Duna: LKO to escape: 950 m/s escape to Duna: 110 m/s Duna circularization: 370 m/s Kerbin to Duna in two burns: ÃŽâ€V1 = 950 m/s + 110 m/s = 1060 m/s for escape + transfer ÃŽâ€V2 = 370 m/s for circularization ÃŽâ€V = ÃŽâ€V1 + ÃŽâ€V2 = 1430 m/s Duna to Kerbin in two burns: ÃŽâ€V1 = 370 m/s for escape + transfer ÃŽâ€V2 = 950 m/s + 110 m/s = 1060 m/s for circurlarization ÃŽâ€V = ÃŽâ€V1 + ÃŽâ€V2 = 1430 m/s

Geschosskopf, you are reading the charts wrong in reverse. You have to reverse the order of the burns. Delta-v charts work perfectly fine in both directions. A Hohmann transfer is a completely reversible process. It costs the same either way, provided you don't aerobrake. 1) Go from small circular orbit to large circular orbit: Burn V1 raises apoapsis. Burn V2 raises periapsis. 2) Reverse the process: Burn -V2 lowers the periapsis. Burn -V1 lowers the apoapsis. (And yes, in practice, it does actually work like this. Try it out from LKO to higher orbit and back.) I.e.: On the reverse trip, the transfer burn reverses the old circularization burn, not the old transfer burn. Let's look at the ÃŽâ€V cost of a Hohmann transfer: Now here's the trick. Go ahead and try this at home. It's one line of algebra. Exchange r1 and r2 in ÃŽâ€Vtotal and you find ÃŽâ€V(r2, r1) = -ÃŽâ€V(r1, r2). It makes no difference which one of r1 and r2 is bigger. If you include the effects of escaping and circularizing around massive bodies at either end, you find the same thing. Escape + transfer going from Kerbin to Planet X is equal to circularization at Kerbin inbound from plaent X. Circularization at Planet X from a Kerbin transfer orbit is equal to escape and transfer from planet X to Kerbin.