OhioBob

That's true. And if we want to get a little more complex (but not go completely overboard), the best method is probably to treat the transfer as a one-tangent burn, as described here: http://www.braeunig.us/space/orbmech.htm#maneuver The examples provided describe transfers between Earth orbits, but the method can also be used for heliocentric interplanetary transfer orbits. In the latter case, the values of ΔVA and ΔVB would be the values if Vxs at departure and arrival. We would then use Slashy's equation to compute the ejection and insertion Δv. Even this method is somewhat limited because it assumes the initial and final orbits (i.e. those of the planets) are circular and coplanar. @Catbus, for what you are doing I think the one-tangent burn technique might be your best bet. It provides a pretty good ballpark estimate for planning purposes and it's still relatively simple as far as the math is concerned. Trying to be any more precise than this and you'll be getting into some really messy and complex math.

I actually found atmospheres interesting and learned how to model them long before I ever started playing KSP (yes, I'm a nerd). Learning how atmospheres work in KSP was not something I could do on my own; I have to give much thanks to @NathanKell for helping me out and patiently answering all my questions. As far as all those curves go, the ones that are used by the stock atmospheres are: pressureCurve temperatureCurve temperatureSunMultCurve temperatureLatitudeBiasCurve temperatureLatitudeSunMultCurve At a minimum, these five curves should be defined in the Kopernicus configuration file. If not, then the curves of the template are used by default, which means you may not be getting the results you think you are. Almost all the Kopernicus cfgs I've seen define the first three curves and omit the last two. I don't know why this is the case, but it should be something that is corrected going forward. The remaining three curves, temperatureAxialSunBiasCurve temperatureAxialSunMultCurve temperatureEccentricityBiasCurve are recent KSP additions and are not currently being used by the stock atmospheres. This just means that their values are equal to zero, which isn't such a bad thing. No harm is done by leaving them out of the cfg file, but if you want to implement seasonal and eccentricity temperature variations, you'll need to learn how they work.

Yes but it's not easy. The entire web page that I referenced you to explains it all, but it is a very lengthy and involved process. And each transfer is unique, so there's an unlimited number of variations. When I first started playing KSP I wrote my own launch window calculator, but it was way more involved than I can explain here. Now I just use is this one: http://alexmoon.github.io/ksp/. Note that that site acknowledges my web site as providing most of the math. The online version doesn't include the OPM planets, but you can add a planet if you know its orbital elements. Easier yet is to use the mod version, which imports all the OPM planets as well as the stock planets.

Yes, the formula works the same regardless of whether you are departing a planet or arriving at one. Be advised, however, that Vxs is equal to the relative velocity between the spacecraft and the planet. This is the difference between the velocity vectors, not simply the different between the scalar magnitudes. This is important because it is rarely ever possible to achieve a pure Hohmann transfer, the velocity vectors at arrival will almost always be crossing at an angle. It is necessary to take this into account when computing the relative velocity. (edit) You can find more information here: http://www.braeunig.us/space/interpl.htm#hyperbolic

The formulas are the same, you just change the value of r. That is, r = ro + z where z is your altitude. Let's say you want to know orbital velocity in a 80 km orbit around Kerbin, r = 600000+80000 = 680000 m v = SQRT(3.5316E+12/680000) = 2279 m/s

I believe there are three equations that form the bedrock of almost all the calculations we do around here. All have already been mentioned in some form or another, but I'll summarize. Tsiolkovsky rocket equation, Δv = ve LN(mo / mf) Vis-viva equation, v2 = GM (2/r - 1/a) Hyperbolic excess velocity, v∞2 = vbo2 – vesc2 Master those three equations and you'll be in good shape.

Yeah, the Twin-Boar is the best in the game. And the worst for its size is the Rhino. Rather than looking at TWR, I tend to look at engine mass versus propellant flow rate. Looking at TWR makes it difficult to compare engines of different classes, i.e. booster engines vs. orbital engines. Comparing the engines based on how much mass they pump out provides more consistent results. When plotted on a graph we see that most of the engines lie on a nice straight line, with the Twin-Boar and Rhino being the obvious outliers. I've actually added a little ModuleManager code to my installation to bring the masses of the Twin-Boar (+1.5 tons) and Rhino (-2 tons) into line with the other engines so that there is no advantage or disadvantage to using them.

An atmosphere can be easy or complicated depending on how realistic you want to make it and whether or not you want to implement all the available features. Most Kopernicus files I've seen define only three curves - pressureCurve, temperatureCurve, and temparatureSunMultCurve. There are actually five other curves that define how the planet's temperature varies by latitude, diurnal cycle, seasons, etc. When these curves are not defined, the curves of the template are used by default. This means your planet can have some odd and unintended temperature variations. Temperature has no effect on the atmospheric pressure, but it does on the atmospheric density. This means you could get some aerodynamic effects that are uncharacteristic for the planet you are trying to develop. I wrote a rather detailed and lengthy tutorial describing the methods I use to develop an atmosphere. Although it is certainly not the easiest method around, the result is a rather life-like atmosphere.

That's an interesting chart, very useful for comparing specific impulse. Some time ago I tried a different method of comparison in which I wanted to see how much Δv each particular engine could produce. Instead of just looking at Isp, I tried to take into account each engine's mass and thrust. What I did was to take each engine and pile on fuel tanks until it's Eve sea level TWR ratio was 1.2. I then simply computed the Δv. The results showed that the Aerospike, Vector and Mammoth were all about the same and had a clear advantage over all the other engines. After the top three engines there was a pretty big gap back to the Twin-Boar and Mainsail, with the Twin-Boar having a small advantage over the Mainsail*. There was then another big gap back to the Thud. Bringing up the rear was the Reliant, with all other engines being so bad that they were even worth considering. The two surprises were the Aerospike and Thud, with both performing well below what one might except based on their Isp curves. * I actually think the Twin-Boar is underweight given its size and power. If you plot a graph of engine mass vs. propellant flow rate, the Twin-Boar lies off the curve and is underweight by about 1.5 tons. This (unfair) mass advantage is why it outperforms the Mainsail.

Actually the orientation in the VAB and the orientation on the launch pad is the same. It's the camera angle that changes. In the VAB the default camera angle is looking east, while on the launch pad the default camera angle is looking north. This gives the impression that the vehicle rotates 90 degrees when you go from VAB to launch pad, but it really doesn't. As for why they use the orientation that they do, it's so that the rocket moves in directions that correspond to the layout of the command keys on the keyboard. If you want to tilt the rocket to the right (east) then you press the rightmost command key (D). It's the most intuitive way to do it.

That's true. But pitch-over is also about control of the vessel. That's the reason for the roll maneuver - to bring the rocket's pitch/yaw axes into the correct orientation relative to the flight azimuth and horizon. Therefore, when we want to pitch the nose down toward the horizon, we're rotating the rocket about only one of its control axes - usually pitch, though it could be yaw. If the axes weren't correctly aligned, then pitching the hose down toward the horizon would require rotating the rocket around two of its control axes.

Sounds like a good idea. I may have to try that.

When KSC reaches the point where the two orbits cross, then the launch site is located along Minmus' line of nodes. When zoomed out it might be hard to tell on which side of Kerbin the launch site is located, so you might have to angle the view a little bit a zoom in to see where the KSC is. If it is on the side of Kerbin closest to Minmus' ascending node, then you want to launch along a heading that is 6.5 degrees north of due east. If KSC is on the side of Kerbin closest the Minmus' descending node, then you want to launch along a heading that is 6.5 degrees south of due east. The reason we use 6.5 degrees instead of 6 degrees is because we're starting out with some due east velocity because of Kerbin's rotation. To end up in an orbit with an inclination of 6 degrees, we have to over compensate a little bit. (edit) Getting the heading right is usually the hardest part for me. The NavBall just isn't precise enough to dial in on an exact heading, so I generally have to eyeball it and hope I'm about right. If you use KER, there is an orbit inclination indicator that helps. Once I get about halfway through the launch I can see how far off my inclination is and I can start yawing north or south to correct.

You can launch directly into a 6-degree inclined orbit to match Minmus if you launch at the right time. These opportunities happen twice a day when the KSC passes through the plane of Minmus' orbit. I do it it like this: Send your rocket to the launch pad and then switch to the orbital map view. Focus your view on Kerbin (double-click on Kerbin to change focus from rocket to planet). Zoom out until you see the orbit of Mun. Align the view so Mun's orbit is seen edge on. Zoom out until you see the orbit of Minmus. Rotate the view left-right until Minmus' orbit is seen edge on (keeping Mun's orbit edge on as well). The orbits of Mun and Minmus will now been seen as two intersecting lines. Time wrap ahead until the launch site reaches the point where the two orbits cross. Check to see which direction you need to launch to match Minmus' orbital plane, i.e. north of due east or south of due east. Switch back to the launch pad view and launch. Immediately after beginning your ascent, rotate the rocket 6.5 degrees either north or south (as determined two steps earlier). After rotating the rocket, begin your pitch down and fly a normal ascent to orbit. This should get you pretty close to matching Minmus' orbital plane. I always have some error but the correction is usually small and easy to fix.

Unfortunately my expertise ends at editing settings and configuration files. If it takes writing code, then that's beyond me. I'll probably figure out some way to change my mod so Kerbin's period remains 426 days. Thanks anyway.

Actually the pitch axis is pointed side-to-side (east-west) through the cockpit. If we pitch north or pitch south, then we are rotating around an axis that is aligned east-west. The pitch axis is normal to the pitch plane. (edit) Also, the default launch pad alignment has the roof south and the floor north. Really? I've always figured there's only a small number of purists who bother performing a 90 degree roll (those who take the "pitch down" thing literally). I suspect that the vast majority of KSP players just yaw right during launch.

In KSP, the pitch/yaw axes are defined by the orientation of the probe core/command pod. For instance, the hatch of a Mk1 signifies the "pitch up" direction. This makes sense because in real life a spacecraft has defined pitch and yaw directions determined by how the inertial guidance and attitude control systems are set up. A real life rocket's alignment on the launch pad is typically govern by the orientation of the launch tower and the location of access panels and connection points (such as fueling lines, power cables, etc.) Therefore the alignment of a rocket's pitch/yaw axes as it sits on the launch pad is rarely correct for its planned flight azimuth. This is why a rocket performs a roll before it starts to pitch down. It rolls until its pitch axis is perpendicular to the flight azimuth, then it simply has to pitch down to fly along its intended heading. In KSP the default launch pad alignment is has the pitch axis pointed east-west and the yaw axis pointed north-south. If you plan an eastward launch and you want to literally "pitch down" during ascent, then you need to roll 90 degrees before commencing your pitch down maneuver (or rotate the vehicle in the VAB before sending it to the launch pad). However, I think most people dispense with the roll and perform the maneuver by "yawing right". Although we commonly refer to this as a pitch down maneuver*, we are technically rotating in yaw (D key = yaw right). I think the reason KSP does this is obvious - so that the W,A,S,D keys are aligned to the movements of the rocket that we see on our computer screens. If we roll the rocket 90 degrees, then either the keys are misaligned to the observed movements, or we have to rotate the image so we are looking eastward. And if we rotate the image, then we have a difficult time judging the degree of tilt of the rocket (must rely on the NavBall). (edit) * We are pitching down in relation to the horizon even though we may be yawing in terms of the rocket's rotational axes.

Enabling maneuver nodes requires upgrading both the Tracking Station and Mission Control. Either one by itself is not enough.

I'm working on a mod that has changed Kerbin's orbital period from 426 days to 410 days. Unfortunately the calendar still counts off 426 days before turning over to the next year. Does anybody know how to change this so that I can make the years turn over after 410 calendar days? Thanks in advance.

On one of my launches from Eve I was able to make it to orbit from sea level for just under 7000 m/s, but I would never recommend trying that. I think that was a perfect storm of everything happening just right. I agree with Streetwind that 7500 m/s is a more reasonable budget for an efficient design. I also see that you are using Twin-Boars and Thuds. While those engines aren't bad for use on Eve, they're not the best. I tend to group them in tiers, with Aerospike, Vector and Mammoth being in the first tier, Twin-Boar and Mainsail in the second tier, and Thud third tier (OK ISP, poor TWR). With those engines you are going to lose quite a bit of efficiency at low altitude. Streetwind's recommendation of 8000 m/s sounds like a reasonable precaution considering the engines you're using. Always better to have too much than too little. If you have no objection to using modded parts, these engines will provide improved Eve sea level performance: Eve Optimized Engines.

Both orbital velocity and escape velocity vary depending on the radius of the orbit. If you want a table, you may have to compute it yourself. For a circular orbit, orbital velocity is v = (μ/r)1/2 and escape velocity is, v = (2μ/r)1/2 where v is the velocity, μ is the planet's gravitational parameter, and r is the orbital radius (radius of planet + orbital altitude). The gravitational parameters and radii for all of KSP's celestial bodies are: μ (m3/s2) ro (m) Sun 1.17233277E+18 261,600,000 Moho 1.68609375E+11 250,000 Eve 8.17173000E+12 700,000 Gilly 8.28945000E+06 13,000 Kerbin 3.53160000E+12 600,000 Mun 6.51384000E+10 200,000 Minmus 1.76580000E+09 60,000 Duna 3.01363200E+11 320,000 Ike 1.85683680E+10 130,000 Dres 2.14844886E+10 138,000 Jool 2.82528000E+14 6,000,000 Laythe 1.96200000E+12 500,000 Vall 2.07481500E+11 300,000 Tylo 2.82528000E+12 600,000 Bop 2.48683500E+09 65,000 Pol 7.21702080E+08 44,000 Eeloo 7.44108120E+10 210,000

The first thing in planning an interplanetary trajectory is getting the departure phase angle correct, which is the angle between the lines joining the target planet to the Sun and to Kerbin. Obtaining the correct phase angle is mostly about sitting around and waiting until the two planets move into the correct alignment. Launching at an inopportune time results in an inefficient transfer, costing way more delta-v than is necessary. For a trip to Duna the phase angle should be about 45 degrees. The following web page gives more information and includes a tool for calculating maneuvers: http://ksp.olex.biz/ The above tool is only approximate because it doesn't take into account the eccentricity of the orbits. A more accurate tool is this one (it's the one that I use): http://alexmoon.github.io/ksp/ The above also has a mod version that works in the game:

You can also adjust the maneuver node vectors using the scroll wheel on your mouse. Rather than dragging the vectors in or away from the node, just hover your mouse pointer over a vector to highlight it, then use the scroll wheel to add or delete velocity. I find that this provides much better control than is attainable by dragging the vector. There are also mods that allow you to adjust the maneuver node with far greater precision than is possible in the stock game. One of the advantages of these mods is that you can zoom in on the celestial body and adjust the encounter without ever having to return your focus to the maneuver node. If you want to give one of them a try, the mods are Precise Node and Precise Maneuver. I use Precise Node, though Precise Maneuver looks like almost the same thing. I find it to be one of my most indispensable mods.

Although it probably won't help in this case (since you have no solar panels), another possible solution is to send the science one experiment at a time rather than all at once. This works if your battery capacity is too small to make one large transmission, but you have the means to recharge the batteries between each individual transmission. Instead of clicking on the antenna, right-click on the probe core/command pod that stores the science. There should be an option that says something like "Review Stored Data". This brings up pop-up window for each experiment with a send icon that allows you to transmit one at a time.

I've done plenty of space filght simulations and I agree with you. All that we really need to do is generate a force diagram (gravity, thrust, and drag), compute the accelerations, velocities, and displacements, and then repeat. We integrate with respect to time because those force vectors are constantly changing. That's really all there is to it. Many of my simulations have reproduced the results of well documented real life space flights with negligible error (such as here and here), thus proving that my methods are sound. If I'm failing to account for Oberth effect by leaving out some required code, then the real life universe must not have gotten the memo either.