OhioBob

That's been my observation as well. After the release of 1.0.5, I ran a bunch of aerocapture tests at Jool, Eve, and Duna to see how the new atmospheres behaved. Unfortunately I didn't keep notes on how much ablator was used, but my recollection is that it wasn't much more than about 1/2 in the worst case.

That also makes aerocapture more effective by lowering the ship's ballistic coefficient. What you don't want to do is load up a heat shield with too much mass behind it. For example, a 2.5m heat shield with 5, 10 or 20 tonnes behind it will probably aerocapture rather easily. However, put 30 or 40 tonnes behind it and the aerocapture attempt will be more harrowing with a smaller margin of error. At least that's the experience that I've had in a series of tests that I've performed. The higher the loading on the shield, the deeper into the atmosphere you'll have to descend.

I design my vehicles using some basic rules of thumb, and use KER to compute the Δv. My rules may not always give me the optimum design, but I know from previous studies and experience that I'll get something that works reasonably well. KER is a great tool that eliminates most of the tedious math, but it does have limitations. For a simple single payload mission, KER is usually all that's needed. However, for more complex missions with multiple payloads, or for missions that require multiple launches and orbital assembly, KER just can't provide everything I need to know. That when I use old fashion paper, pencil, and calculator.

I've been guilty of that far too often. I've probably spent at least as much time developing and working with my spreadsheets as I have playing the game. (Of course, the fact that the game keeps changing with each new release is largely to blame for that.) On the good side, I very rarely experience a failure because of a poorly design mission. I will still occasionally get an unstable rocket that requires a trip back to the VAB to adds fins or whatever. But mistakes with Δv might happen only a few times out of a hundred missions, and, when it does happen, it's more likely due to poor piloting than bad planning. Most of my failures are due to either poor piloting or silly procedural mistakes. For instance, I just recently ran out of power on a mission because I forgot to extend the solar panels. Fixing those kinds of stupid mistakes are what quick-saves are for. What really aggravates me is when I leave some small but critical part of a ship, like an antenna. Or when I re-fly an previously designed mission to a new biome on Mun or Minmus, only to I realized when I get there that I forgot to add a newly discovered science experiment. All the math in the world won't prevent the occasional oversight.

You can probably SWAG your way through almost everything but, if you do that, be prepared for most of your missions to either under or over designed. If you want to carry out your missions both successfully and efficiently, you are probably going to have to do at least some math. Mainly you need to know two things: (1) how much Δv do I need, and (2) how much Δv do I have. The first part includes planning out your missions step-by-step, identifying what maneuvers need to be performed, and determining the Δv of each maneuver, which when added up is your Δv budget. The second part involves computing the Δv that each stage of your launch vehicle/spacecraft can produce, and making sure it can perform the maneuvers that make up your Δv budget. You want to match your vehicle to the mission with a reasonable margin. Much of the first part can be determined using a Δv map, and the second part can usually be determined using a mod like KER. However, those tools have limitations. That is were it is useful to understand the math so you can identify instances when the usual data may not be reliable. You can then manually compute what you need to know. An example of where the tools might fail you is when you have a two-part spacecraft, such as an orbiter and a lander. KER will give the Δv based on how the parts are stacked and staged in the VAB. However, in practice those parts may perform some maneuvers while docked together, and others while separated and flying independently. The actual Δv that you'll attain depends on how you fly the mission, which is something KER can not possibly know or calculate. In this case you've got no choice but to compute some of the Δv by hand. Furthermore, Δv maps just give typical values. Transfers to some planets can vary significantly in Δv from one launch window to the next. I highly recommend Alex Moon's Launch Window Planner for planning your interplanetary missions. One place you can go to start to learn the math is my web page, Rocket & Space Technology. The site gives much more information than you need to play KSP, but you can skim through it and study the parts that are applicable. In the Rocket Propulsion page you should at least familiarize yourself with "Tsiolkovsky's rocket equation" (eq. #1.17), "Specific Impulse", and "Staging". The Orbital Mechanics page is a good overview of the subject, it probably wouldn't hurt to skim the whole thing and then concentrate on the parts of greatest interest. You and me both, brother.

I do leave both on. The problem is that I want to rotate using SAS and translate using RCS. When RCS is on, the thrusters fire when I rotate, wasting monopropellant. What I usually do is leave the SAS on all the time. The RCS I turn on when I want to translate, and turn off when I want to rotate.

^ I second this ^

I usually just call them funds, but sometimes for fun I call them "krubles".

For returns from Mun/Minmus, I've been using an ablator mass ≥5% the mass of the vehicle. For example, a Mk1 command pod with parachute and 1.25m heat shield has a mass of 1240 kg. However, I don't want to include the ablator, so I run the ablator slider down to zero, which gives a mass of 1040 kg. 5% of that number is 52 kg, which is the amount of ablator I want the dial back in. Since the ablator increases in 20 kg increments, I set it to 60 kg. So far it has worked pretty well, though I haven't accumulated enough experience to give the method my final endorsement. Surely for high-speed interplanetary intercepts, the ablator percent will have to be higher.

JPL's "Basics of Space Flight" is a very nice reference. It's included in my bibliography. Nice that they have a link to my site.

In most cases, a launch from the surface of Kerbin will add about 1000-1500 m/s in gravity and drag losses. Since orbital velocity is about 2300 m/s, this equates to about 3300-3800 m/s. How much exactly depends on many factors. For instance, early in a career game I usually budget more Δv because I haven't research fairings yet and I'm launching draggy payloads. Later on, as I advance along the technology tree, my launchers become more aerodynamic and the required Δv goes down. Also, the ascent profile that you fly makes a big difference. Flying an efficient ascent just takes practice. One piece of advice, don't get obsessed with trying to minimize the amount of Δv it takes to get to orbit. If you are playing in career mode, then cost is a more important consideration. Experience has shown that cost efficiency does not correlate to Δv efficiency. If it's costing you 3500 m/s to get to orbit and somebody else tells you that they are using only 3300 m/s, don't worry about it. It's entirely possible that your 3500 m/s launch system is more cost efficient than the other guy's 3300 m/s launch system. Also note that the Δv given above are the "vacuum" values. That's what most people use when discussing Δv. The "atmosphere" values become important when discussing liftoff thrust-to-weight ratio.

Yes, that's correct. Aerozine 50 was developed by Aerojet for use in the Titan missile. In the Titan the mixture ratio was about 1.9. Aerozine 50 was also used in the Apollo service and lunar modules, where the mixture ratio was 1.6. One of the reasons for the 1.6 mixture ratio is because at this proportion the oxidizer and fuel have the exact same volume, so the same tanks can be used for both. This can clearly be seen in the LM ascent stage as the two spherical tanks are the same diameter (see below). However, since the fuel has less mass, it's tank is mounted farther from the centerline so the LM remains in balance. This asymmetry wasn't an issue in the descent stage or service module because each had two oxidizer tanks and two fuel tanks, which could be arranged so that similar tanks were opposite each other to balance the mass. Interestingly, my own computations show that NTO/Aerozine 50 produces a higher specific impulse at a mixture ratio of 1.6 then at 1.9. I've never been able to find a good explanation for why Aerojet went with a 1.9 mixture ratio for the Titan.

Well, we know that fuel by itself has the same density as oxidizer/fuel combined, therefore the density of oxidizer must be the same as the fuel. That would make both volume ratio and mass ratio the same. There are several oxidizer/fuel combinations that would have mixtures ratios around 1.1, though none that are commonly used. There's a chart near the bottom of this page that gives several examples. The ones closest to 1.1 are: LOX/MMH, LOX/Aerozine 50, and NTO/hydrazine. (edit) Correction, that mixture ratio should be 1.22, not 1.1. That's a little high for LOX/Aerozine 50, and NTO/hydrazine, but is getting closer to LOX/(ethanol+water) and RFNA/hydrazine

Are you talking about airless planets/moons, or those with atmospheres?

I've just started playing my first game since 1.0.5 was released, so I haven't had a chance to see if my old rules of thumb still work. However, in 1.0.4 my rules for reentry periapsis at Kerbin were: 42 km from LKO, 30 km from Mun/Minmus, and 25-30 km from deep space.

I am surprised our results are so different. In my tests the heat shield began to glow orange shortly after encountering the atmosphere, but everything behind it seemed fine. I didn't experience any significant overheating problems. I tested three different ships, which I hyperedited into a hyperbolic encounter with Jool. Each ship was tested using two different approach trajectories, which I thought represented the likely minimum and maximum velocities for a ship arriving from Kerbin. The velocities at atmospheric entry were about 9660 m/s and 9970 m/s. I tested a range of periapsis to find the minimum and maximum that would result in an aerocapture. I considered an aerocapture anything that resulted in an apoapsis that was (1) above Jool's atmosphere and (2) inside Jool's SOI. The three ships were just something that I threw together to test the feasibility of aerocapture, i.e. they weren't equipped to do anything more than the aerocapture tests. All three used a single 2.5m heat shield, behind which I stacked varying amounts of mass to alter the ballistic coefficient. Below are brief descriptions: Ship #1 - A very small probe consisting of 0.625m and 1.25m parts tucked in behind an oversized 2.5m heat shield. Total mass at entry: 2915 kg. Ship #2 - Consisted of an in-line stack of 2.5m parts. From front to back: heat shield, RC-L01 remote guidance unit, service bay (with RTG and batteries), reaction wheels, X200-32 fuel tank (with fuel only), and a LV-N engine. Total mass at entry: 14,825 kg. Ship #3 - Consisted of an in-line stack of 2.5m parts. From front to back: heat shield, RC-L01 remote guidance unit, Z-4k battery bank, reaction wheels, Jumbo-64 fuel tank, and a Skipper engine. Radially attached to the fuel tank were six SP-L 1x6 solar panels. Total mass at entry: 41,350 kg. Ship #1 is something that I originally tested in either version 1.0.2 or 1.0.4 (don't remember which). I was actually able to achieve an aerocapture with it back in the old version, through just barely and with an extremely small margin of error. Under version 1.0.5, Ship #1 worked like a charm. I had absolutely no heating or stability problems. The periapsis sweet spot was about 165-170 km. For the most part, tests with Ship #2 went pretty smoothly as well. I didn't have any heating issues, but there were some stability problems. Above an altitude of about 153 km it worked fine, but once I got below 153 km the ship wanted to flip around. Once it flipped, it was destroyed in a matter of seconds. The periapsis sweet spot was about 155-160 km. Ship #3 was problematic, not because of heating but because of instability. Because of the ship's high ballistic coefficient, a low periapsis was needed to achieve an aerocapture. The lowest periapsis I could attain without the ship flipping around and destroying itself was 155 km. At the low entry velocity, aerocapture was possible with a 155-160 km periapsis; however, at the high entry velocity aerocapture was extremely difficult. I found a very narrow corridor just above 155 km where I could aerocapture without the ship flipping, though the small margin makes it unpractical. With a more aerodynamically stable ship, aerocapture at high BC/velocity might be possible, probably with a periapsis in the 150-155 km range.

Right after 1.05 was released, I ran a large number of tests at Jool to see how suitable it is for aerocapture. Really high ballistic coefficients don't work too well, but anything with a low to mid BC is pretty easy to aerocapture. Part of the reason for the improvement is that Jool's upper atmosphere thickens with increasing depth more gradually than it did prior 1.0.5. However, I think what is even more important is the change to the heat shields, which now ablate much more slowly than before. The exact periapsis needed for aerocapture is going to depend on the drag characteristics of the vehicle and the entry velocity. In most cases I found that an aerocapture could be achieved with a periapsis somewhere in the range of 155-165 km. For a high BC vehicle and/or a high entry velocity, you should be closer to 155 km. For a low BC vehicle and/or a low entry velocity, you should be closer to 165 km. You'll have to experiment to know for sure. In my experiments, I found that my test vehicles wanted to flip around when I got down to an altitude of about 155 km, which did not end well. If you're going to have to dip that deep into the atmosphere, be sure to take steps to make your ship aerodynamically stable in its heat shield forward attitude.

I usually do a "hot separation", meaning that decoupling and ignition are grouped together in the same staging event. Never had any problem with this.

My only manned mission to Eve was during v0.90. I had accepted contracts for something like "Eve base on wheels" and "plant a flag on Eve". I went ahead and constructed a mission that landed three Kerbals in a large mobile base to fulfill the contracts. However, it was basically a one way mission with no immediate plan to bring them back. After a couple decades stranded on that purple rock, I decided it was finally time to figure out a way to bring them back home. I had never launched from Eve before so this would be my first attempt. Not wanting to build some huge monstrosity of a spacecraft to bring them to orbit all at once, I brought them up one at a time using a small lifter with a command seat. Unfortunately I've lost all my screenshots from those missions, but I still have a save of the vehicle (remember this was pre-1.0, so I didn't have to make everything aerodynamic or have heat shields): There were to be a total of four launches from Kerbin - the three landers/lifters and a return ship. I saw no reason to dock them together into one huge vessel, so they all flew to Eve independently. The plan was to make three separate landings, drive the mobile base to each landing site, have one Kerbal board each of the three lifters and launch, have the return ship rendezvous with each Kerbal in orbit, and have each Kerbal board the return ship via EVA. After all three Kerbals were aboard the return ship, they would have to wait in orbit for the next available launch window, and then they could finally all come home. To validate that the lander/lifter worked before sending all three of them, I first sent one along with the return ship. The plan was to bring one Kerbal up to the return ship and, if that worked, I'd send two more landers/lifters at the next launch window to bring up the other two. Good thing that was the plan because what I didn't realize when I designed and tested my lifter, a Kerbal adds 94 kg to the mass of the vehicle when he's placed in a command seat (he doesn't add anything when he's in a pod). Everything seemed to be going exactly according to plan, but I ran out of propellant before attaining orbit. Fortunately I did a quicksave before launching. I tried again, same result. I couldn't figure out why the results weren't matching my simulations until I discovered I was 94 kg overweight. I then launched unmanned and I achieved orbit exactly as I had planned it (my first ever successful launch from Eve). That told me that my design method was correct, I just needed to upsize to account for the extra 94 kg. (In retrospect, I probably could have left the command seat and used the EVA pack to gain the last bit of velocity needed to attain orbit, but I didn't think of that at the time.) At the next launch window I sent one redesigned lander/lifter (pictured above) to fetch one Kerbal. The mission went off without a hitch and I had one Kerbal aboard the return ship. By now I was getting pretty good at landing close to my target. Once entry started I had no control over where I was going to land. My only control was in selecting the altitude and location of periapsis when performing the deorbit burn. I don't remember exactly, but I think all of my landings were inside of 10 km from the mobile base (I think the closest was about 3 km). Confident now in my design and procedures, I sent the last two landers/lifters at the next launch window and rescued the last two Kerbals. At the first opportunity, they rocketed out of Eve orbit, traveled back to Kerbin, and safely splashed down. With all the time spent waiting for launch windows, and the time spent in transit, it took about 5 years to complete all the flights needed to bring those little green guys back home. I'd like to think there was a nice tickertape parade for them after their long awaited return. Edit: I forgot to mention that I was lifting off from an elevation of about 900 m. I therefore needed more delta V than Temstar's design - about 12,000 m/s total.

OK, I see what you're saying. I agree in principal, but I'm still not convinced that the intersection will occur at about the same velocity everywhere. For example, on Kerbin we can typically deploy our parachutes at a velocity of about 260 m/s at an altitude of about 5-6 km. Under these conditions the dynamic pressure is about 20 kPa. Based on this, we should be able to say that our parachutes can withstand a dynamic pressure of about 20 kPa without failing. During a typical entry at Duna, the dynamic pressure never reaches 20 kPa. The curves don't cross because we are already below the theoretical safe deployment velocity. We should be able to pop the chutes at anytime (ignoring heat) without them failing.

I don't think that's true. We have to slow the ship enough that we can pop the chutes without them ripping off, but the speed to which we have to slow the ship is that at which the drag on the chutes is low enough not to tear the lines. Drag is proportional to the dynamic pressure, so we can probably say that it's safe to pop the chutes when the dynamic pressure is below some threshold value. We have, v = (2q/ρ)1/2 where q is the dynamic pressure and ρ is the air density. If q is a constant, then the velocity at which we can deploy the chutes is a function of air density. The deployment velocity is not a constant, it depends on where we are. Just to be clear, my argument is how I think it should be. This is not necessarily how it currently works in the game.

I just put together the following graph. For each planet it gives, for altitudes up to 25000 m, the velocity at which the dynamic pressure is equal to 20000 Pa. I'm using dynamic pressure because it should be approximately proportional to the tension generated in the parachute lines when the chute is deployed. The higher the dynamic pressure, the greater the force generated and the more likely the parachute will tear lose on deployment. I'm using 20000 Pa because that appears to match the conditions on Kerbin when a parachute can be safely deployed (i.e. 260 m/s at 5200 m). Theoretically, and ignoring heat, it should be safe to deploy a parachute if the conditions place you in the part of the graph above the curve. If you are below the curve, then the dynamic pressure is likely too high to safely deploy the parachute. Of course heating should also be considered when determining when it is safe to deploy. I remind you that this is not what the game does. It is just an example of what the game could do to determine safe deployment speed. The 20000 Pa number is an arbitrary threshold; some other similar criteria could be used as the determining factor.

But to produce a given amount of air resistance at a given altitude, a ship will be traveling much faster on Duna than on Kerbin. Therefore, if I'm going to deploy my parachute at an altitude of 4000 m, I can safely do so at a higher velocity on Duna than I can on Kerbin.

It's tweakable, but the lowest pressure it can be set to is 0.04 atm for main chutes and 0.02 atm for drogues. That works out to the following altitudes (updated for 1.0.5): 0.04 atm 0.02 atm Eve 34 459 m 38 355 m Kerbin 17 590 m 21 204 m Duna 4 448 m 9 266 m Jool 142 580 m 149 810 m Laythe 21 482 m 27 471 m If the pressure were set higher, then the maximum deployment altitude would be lower.

I don't think the parachutes can be deployed before drag is significant because of the minimum pressure setting.