Yasmy

Allow me to make a suggestion. I have seen many math and physics students insert numbers into equations first, then solve for the desired quantity. This is more work and less instructive than solving the equation first, and then inserting numbers. The solution is meaningful before you put in numbers. It is more work because you have to resolve the equation if you want to change any of the numbers. It is also more to write down, since numbers are longer than symbols, usually. It is less instructive because in the end all you have is number soup. You can't easily look at a pile of arithmetic and see the meaning or the effect of each term. Let a = 1/8. The fuel mass is x. The dry mass is a*x. The full tank + fuel mass is (1+a)*x. Now solve for x: dv = ve ln((m + (1+a)*x)/(m + ax)) e^(dv/ve) = (m + (1+a)*x)/(m + ax) x = m (e^(dv/ve) - 1) / (1 - a (e^(dv/ve) - 1)) x = m / ( 1/(e^(dv/ve) - 1) - a) I skipped a couple simplification steps along the way, but nothing difficult. Now you can reuse this equation, changing ve or m without resolving from the rocket equation. You could plot the fuel mass versus dv. You can think and reason about a mathematical function in ways you can't to something like x = 500 tons. Edit: To elaborate, let's look at the effect of the dry tank fraction, a. I said we could reason about an equation, so let's do so. If a gets bigger, the denominator gets smaller, so x gets larger. If your tanks weigh more per unit fuel, you need more fuel to push the thicker tanks. We already knew this had to be true from our understanding of the rocket equation, but we now know exactly how the dry fuel fraction enters into the wet fuel mass.

If you are dropping tanks, you need to calculate the delta-v for each stage individually. Each stage has it's own wet to dry mass ratio, which you should reevaluate after dropping tanks and separators. Then the total delta-v is the sum of the delta-v of each stage.

There are a number of mods which display basic orbital information. Kerbal Engineer Redux (KER) is a community favorite. Other people will happily chime in after me with other recommendations. Edit: And of course, the 5th Horseman will chime in while I'm typing

I miss MuMech's muon detector. It was a great little toy. It beeped faster the closer you got to anomaly. I used to use scansat on orbital probes for finding the general location of an anomaly, and the muon detector on rovers and landers to locate anomalies. It had the feel of exploration and discovery. I visited a ton of anomalies without knowing beforehand what I would find. Without spoiling, let me just say that several anomalies are really cool. Sadly the muon detector is long gone. I think 0.17 or 0.18 is the last time it worked. Edit: Just checked out Contract Pack: Anomaly Surveyor. Neat. Thanks for the pointer.

There is an old thread on here about this. Haven't found it yet. But this thread contains the same solution. See also this and this..

So how does KSP model the moments of inertia of a craft? Is each part treated as a point particle, a solid body, a shell, or as something part shape-specific? I guess we could do some rotational acceleration tests of full and empty fuel tanks and other parts to find out, but someone must know already. For a large vessel, a point-particle model should work just fine, but it could behave poorly for some corner cases. Without knowing how rotational inertia works in KSP, it is hard to make a good physics based argument. One thing you could try is to change the physics max time step, I think. I could be wrong. I don't know much about this. But if you can slow down the integrator, and still have stability issues, then maybe it's a design flaw, and not something like buildup of numerical errors. But this is highly speculative. You seem to lose stability when you crank up the throttle to max. Does it become unstable if you leave it at half throttle? It entirely possible that your stability is a function of your angular velocity. You could be unstable when your angular velocity passes some natural resonant frequency in the craft. (Top-loading washing machines operate in the opposite manner: Below a certain speed, they are unstable and so they are kept locked on axis. Above a certain speed, they become self-centering: the basin is unlocked and allowed to float on springs, so that uneven loads do not cause the machine to wobble or break. This works because the force is out of phase with the displacement above the resonant frequency, and the basin is driven back towards the center.)

*Technically* you reached orbit as soon as you lifted off the pad. Just not sustainable due to degeneracy pressure. But it was an orbit.

Very cool. Thanks. What do you use to collect data this data in flight?

Let's look at the point where you first go into eclipse, and draw a right triangle: The hypotenuse goes from the center of Kerbin to the spacecraft: c = 3468.75 km = orbital altitude plus Kerbin's 600 km radius. Leg 1 goes from the center of Kerbin to the limb of Kerbin: a = 600 km. Leg 2 goes from the spacecraft to the limb of Kerbin (the point where you see the sun getting eclipsed): b = sqrt(c^2 - a^2). Find the angle between the center of Kerbin and the limb of Kerbin: sin(theta) = a/c = 600 / 3468.75. theta = asin(600/3468.75) = 9.96 degrees. Now the angle eclipsed by Kerbin is twice this angle, which you can see by drawing similar triangles behind Kerbin. Kerbin has a 6 hour day, so it rotates 360 degrees in 6 hours. So how long does it take to rotate 20 degrees? 6 hours * 20 / 360 = 1/3 of an hour. 20 minutes.

very nice. since you have all of this acceleration versus time data, did you integrate it to find your total delta-v and delta-v losses?

For kicks, I just calculated a three-burn eyeball method. The eyeball part is the fact that the initial burn is directly over where you want to be in KEO, such as directly over KSC. This is less efficient than a two burn Hohmann transfer, but in practice, only by a small amount (40 m/s delta-v). I wouldn't necessarily recommend this method, particularly if setting up a multi-spacecraft constellation. Like I said, I'm just doing this for kicks. I like equations as much as I like explosions. I just figured some people might like a method which is easy to eyeball. As a warning, I haven't fired up KSP yet to test this out. The method is the following: 1) From circular LKO, perform burn 1 to raise your apoapsis to some radius r1. 2) Orbit an odd number of half orbits, ending up at apoapsis. 3) Burn 2 brings the periapsis up to KEO altitude. 4) Orbit an odd number of half orbits, ending up directly above your original maneuver location. 5) Circularize into KEO. There are 3 free parameters here to play with: the number of complete orbits before the final half orbits in steps 2 and 4 above, and the number of times Kerbin rotates during the process. Call those integers n, m, and l, respectively. Picking n, m and l, you can solve for r1, the apoapsis for your initial burn, to make sure you end up back over your starting location. Basically, solve for the value of r1 such that the time for (n+1/2) orbits in the initial transfer orbit plus the time for (m+1/2) orbits in the second transfer orbit equals the l times the orbital period of Kerbin, so that Kerbin has rotated an integer number of times by the time you get to KEO after also orbiting Kerbin an integer number of times (n+m+1). Begin in a circular orbit at altitude 80.000 km above Kerbin sea level. Perform the first maneuver directly over the location you wish to be in KEO above. Burn delta-v1 of 622.94 m/s to raise your apoapsis to 2312.348 km altitude. Orbit 1 and a half times to apoapsis. Burn delta-v2 = 470.65 m/s at apoapsis to raise the periapsis up to KEO altitude of 2868.741 km. Orbit 0 and a half times to apoapsis directly over your target location. Burn delta-v3 = 44.99 m/s at apoapsis to create a circular orbit with period 21599.912 seconds. Total cost: 1138.58 m/s. Equivalent 2-burn Hohmann transfer cost = 1099.34 m/s. Here's my matlab code if anyone wants to play with it. If you don't have matlab, it shouldn't be too hard to make the same code work in Octave, which is free software. % Released under the MIT License. % Copyright 2015 by the person known as Yasmy on the ksp forum. function r1 = find(n,m,l,altitude) mu = 3.5316e12; T = 21599.912; R = (mu * (T/2/pi)^2)^(1/3); Rk = 600000; r0 = altitude*1000 + Rk; F = @(r1)(l*T*sqrt(8*mu)/pi - (2*n+1)*(r0+r1).^(3/2) - (2*m+1)*(r1+R).^(3/2)); [r1,fval] = fsolve(F,(r0+R)/2); if (r1 < r0) || (r1 > R) disp('nice solution not found'); else dv1 = sqrt( mu/r0) * (sqrt(2*r1/(r0+r1)) - 1); dv2 = sqrt(2*mu/r1) * (sqrt(R/(R+r1)) - sqrt(r0/(r0+r1))); dv3 = sqrt( mu/R ) * (1 - sqrt(2*r1/(r1+R))); fprintf('Begin in a circular orbit at altitude %.3f km above Kerbin sea level.\n', altitude); fprintf('Perform the first maneuver directly over the location you wish to be in KEO above.\n'); fprintf('Burn delta-v1 of %.2f m/s to raise your apoapsis to %.3f km altitude.\n', dv1, (r1-Rk)/1000); fprintf('Orbit %d and a half times to apoapsis.\n',n); fprintf('Burn delta-v2 = %.2f m/s at apoapsis to raise the periapsis up to KEO altitude of %.3f km.\n',dv2,(R-Rk)/1000); fprintf('Orbit %d and a half times to apoapsis directly over your target location.\n',m); fprintf('Burn delta-v3 = %.2f m/s at apoapsis to create a circular orbit with period %.3f seconds.\n',dv3,T); fprintf('Total cost: %.2f m/s.\n',dv1+dv2+dv3); fprintf('Equivalent 2-burn Hohmann transfer cost = %.2f m/s.\n', sqrt(mu/r0)*(sqrt(2*R/(r0+R))-1) + sqrt(mu/R)*(1-sqrt(2*r0/(r0+R)))); end end

It is true that third and forth time derivatives don't normally have much of a practical application. This is largely because mechanics is usually completely determined by first and second time derivatives. You may wish to look at the jerk and jounce to characterize your system, but you don't need them to solve the equations of motion. You don't need jerk and jounce in KSP to simulate your rocket. Unless the higher order derivatives enter the differential equations describing your system, you generally have no need for them. Like K^2 said, in perturbation theory, you can have an infinite series of higher order derivatives. These may be time derivatives, spacial derivatives or derivatives in some abstract quantity. Sometimes you can find a sum for the infinite series without taking derivatives. More commonly, the higher order terms can be ignored because you can prove that successively higher order derivative terms contribute a negligible amount compared to lower order derivatives. If you can simplify your system by throwing out higher order terms, and still get the same answer to as high of precision as you need, there is no practical use for the higher order terms. I often work with elastic deformation models of cell membranes with second, third and forth order spacial derivatives. The derivatives are needed to characterize the energies associated with bending, compression, stretching and curvature of an elastic layer. You could use the same model to describe the energy associated with bending or deforming a mattress. The reason why there are no fifth and sixth order terms in many elastic models is that for normal deformations, the shape and energy of the deformed object are very well approximated by the forth order model. By the time you deform your system enough that the simple forth order model breaks down, you often also start breaking your physical system. (I.e., "plastic" deformations which permanently change the shape of your object by kinking or breaking in pieces.) Some viscoelastic fluid models use 5th order derivatives. The rule in physics is simple: Use the simplest model or theory which matches experiment. If you have no need for higher derivatives in your theory, don't use them. If you do, do.

Likely scenarios: 1) The moon formed from the same cloud of material as the parent, in which case it was already captured. 2) The moon formed from ejecta from the parent as a result of a collision with the parent. Much less likely: 3) The moon formed from a portion of an asteroid which broke up due to tidal forces from the planet. The remaining portion was not gravitationally bound and left the orbit of the planet. Many asteroids are fairly weakly bound material, so breakup due to tidal forces is not unusual, but you have to have just the right conditions to leave some material behind. (I just noticed that cantab said essentially the same thing: binary objects can have one member captured.) 4) The moon formed from debris of asteroids which collided. Space is big, and asteroids are tiny. This is incredibly unlikely, but not impossible.

Thanks for the test, FancyMouse. Definitely different from my 0.90 test, which showed identical consumption in x vs + setup. I still have 0.90, so I could retest that and current. Maybe later.

That is just wacky behavior, Sharpy. Who ordered that silliness? I'm going to have to do some more testing to see that for myself. My tests were done without Precise Mode on, but I did not test at arbitrary angles like you are depicting. Just in ijkl and in diagonals (ij, il, jk, kl). They definitely conflict with Alshain's image. (Which I expected to be correct, but found to be wrong.) - - - Updated - - - Vist's question is very easy to test. Build a core with RCS, duplicate it, rotate by 45 degrees, or any arbitrary number of degrees, attach the two and launch. If orientation of the RCS blocks matters, translations will induce rotations. Easy-peasy. I did a quick test, and it worked just fine. I didn't quantify monoprop usage as a function of angle mismatch, but there were no induced rotations.

Below there are two shots of the same craft. The RCS blocks on the diagonals are in a different action group from the blocks in the cardinal directions, for easy testing. Define the thrust of one RCS block as T, and the monopropellant consumption rate as R. You may expect the net thrust and fuel consumption of the two craft to be: Cardinal: 2T, 2R Diagonal: 4T/sqrt(2), 4R Thus you may expect the thrust per unit fuel to be T/R and T/R/sqrt(2), respectively. I did. I did a large number of tests with different test rigs in space and on the pad. For all my tests, the net thrust and fuel consumption rates were essentially identical. I timed the fuel drain in the tests below, and I measured the accelerations, and they were the same. To me this says that as far as RCS placement goes, don't try to use logic/physics/math. Slap em on, and they will work the same in either configuration. Someone else may wish to verify my tests. I haven't done them since 0.90.

I used to believe (based on "common sense") that RCS block orientation mattered, but after some Kasuha-style extensive testing, it appears that orientation is meaningless for RCS. Having RCS blocks on the diagonals neither uses twice as much fuel per second, nor produces net thrust reduced by 1/sqrt(2) per firing block, relative to placing rcs blocks on the cardinal directions, when firing in a cardinal direction (ijkl).

Roughly: Ike -> Duna -> Jool: 1158 m/s Ike -> Jool: 1266 m/s Direct vs slingshot table.

Let's do the math. It's just the change in specific kinetic energy (kinetic energy divided by mass): Forward: de = 1/2 (v+dv)^2 - 1/2 v^2 = 1/2 (+ 2 v dv + dv^2) = 1/2 (2*100*10 + 10^2) = 1050 m^2/s^2 Reverse: de = 1/2 (v-dv)^2 - 1/2 v^2 = 1/2 (- 2 v dv + dv^2) = 1/2 (-2*100*10 + 10^2) = -950 m^2/s^2 So yes, it is slightly less efficient in reverse. Next, if we take the derivative, de/dv, we get de/dv = v. (Drop the 1/2 dv term, as usual in calculus when taking derivatives. It is infinitessimal.) This is the Oberth effect: The change in specific orbital energy with respect to velocity is equal to your current velocity. That's all there really is to it: kinetic energy is quadratic in velocity, so the derivative is linear in velocity.

I think we are going to have to agree to agree. If you look at the numbers I posted earlier, they tell the same story you are telling now. I did have 3 modifers to warn people that I wasn't talking about every moon to every planet: Occasionally, sometimes and for instance, and I also provided the raw data so people could draw their own conclusions.

Everything else you said was correct, but this isn't. Duna doesn't cost too much to get to from interplanetary space near Kerbin. Same goes for Eve. Occasionally going from a moon directly interplanetary is cheaper than going from LKO, and sometimes it is even cheaper than dipping down to LKO to perform the burn. For instance, going directly to Duna or Eve from the Mun is cheaper than dipping down to Kerbin.

I do this around other bodies as well. I place my station or return vessel just high enough to get the minimum warp I need to maintain sanity. I hate having to switch vessels to warp fast enough to do something.

Here's the rough delta-v cost for going interplanetary either via dipping down to the parent for a powered slingshot, directly from a moon, or from low orbit around the parent. These calculations assume no inclination changes and zero eccentricity orbits, so it can be significantly off. I post it more as a general guideline. I'm going to agree with others that departing from LKO is easiest. Bringing fuel from Minmus to an LKO depot is a lot more wasteful, but so much easier. Fuel tugs, being almost all tankage, tend to be much easier to fly and dock than interplanetary vessels, and can have fabulous total delta-v. Timing is also trivial from LKO. That said, if your interplanetary vessel is low on total delta-v, topping off at Minmus could enable you to complete a mission which you couldn't if you departed directly from LKO. Transfer burn delta-v [m/s]. Does not include capture at the target. Moon -> Target: Moon->Parent->Target Moon->Target Parent->Target Gilly -> Moho: 776 1367 1643 Gilly -> Kerbin: 507 497 1373 Gilly -> Duna: 775 1364 1642 Gilly -> Dres: 1308 2476 2176 Gilly -> Jool: 1648 3048 2517 Gilly -> Eeloo: 1786 3264 2655 Mun -> Moho: 1135 1509 1699 Mun -> Eve: 462 348 1024 Mun -> Duna: 498 414 1060 Mun -> Dres: 987 1279 1550 Mun -> Jool: 1361 1840 1924 Mun -> Eeloo: 1520 2065 2084 Minmus -> Moho: 943 1958 1699 Minmus -> Eve: 270 440 1024 Minmus -> Duna: 306 567 1060 Minmus -> Dres: 795 1700 1550 Minmus -> Jool: 1168 2319 1924 Minmus -> Eeloo: 1328 2559 2084 Ike -> Moho: 1970 2159 2118 Ike -> Eve: 908 975 1055 Ike -> Kerbin: 464 421 611 Ike -> Dres: 658 671 806 Ike -> Jool: 1158 1266 1306 Ike -> Eeloo: 1382 1518 1529 Laythe -> Moho: 2228 1273 3135 Laythe -> Eve: 2109 1131 3015 Laythe -> Kerbin: 2049 1063 2955 Laythe -> Duna: 1979 986 2886 Laythe -> Dres: 1906 909 2812 Laythe -> Eeloo: 1893 896 2799 Vall -> Moho: 1835 1334 3135 Vall -> Eve: 1715 1099 3015 Vall -> Kerbin: 1655 980 2955 Vall -> Duna: 1586 844 2886 Vall -> Dres: 1512 702 2812 Vall -> Eeloo: 1499 678 2799 Tylo -> Moho: 1807 1298 3135 Tylo -> Eve: 1688 1141 3015 Tylo -> Kerbin: 1627 1067 2955 Tylo -> Duna: 1558 988 2886 Tylo -> Dres: 1484 913 2812 Tylo -> Eeloo: 1472 901 2799 Bop -> Moho: 1452 1652 3135 Bop -> Eve: 1332 1275 3015 Bop -> Kerbin: 1272 1068 2955 Bop -> Duna: 1203 811 2886 Bop -> Dres: 1129 510 2812 Bop -> Eeloo: 1116 455 2799 Pol -> Moho: 1335 1739 3135 Pol -> Eve: 1216 1332 3015 Pol -> Kerbin: 1156 1104 2955 Pol -> Duna: 1086 815 2886 Pol -> Dres: 1013 462 2812 Pol -> Eeloo: 1000 394 2799

First stop in low Kerbol orbit is almost never a good idea, unless you plan on going interstellar. Getting to Kerbol is harder than getting anywhere else.

Are you leaving both RCS and SAS on? If so, your drift could be caused by RCS changing your orbit. Do you have a lot of part clipping? That could cause phantom forces. Are you processing fuel in flight? Maybe moving mass from one part of the ship to another is causing a problem. (I hope not. It shouldn't.) If you time warp, does the closest approach change during warp? If you don't mind digging through save files, 1) quicksave when you have a close rendezvous set up. 2) manually copy the quicksave somewhere else 3) wait until the rendezvous has drifted apart 4) quicksave and back it up again 5) Find the ORBIT sections for the two crafts in the two different quicksaves. If either of the ships is drifting, it will show up in the orbital parameters.