Kerbal Space Program - There (to KSO) and Back

As a Real™ Aerospace Engineer (BS Aerospace Engineering, Embry-Riddle Aeronatucal University, Prescott), I am absolutely thrilled about the increase in “realistic” space simulations. My go-to for a space-sim fix is currently the Kerbal Space Program, which should be no surprise to those familiar with the simulation genre. The game is an awesome combination of mostly-accurate physics, self-deprecating humor, explosions, and pretty screenshots, all wrapped in an extremely accessible interface.

For today’s AAR, I wanted to share a mission I love to fly over and over again: Kerbostationary orbit. Not only is the scenery at KSO great, but the mission is very straightforward to plan and very easy to execute. I can frequently predict the amount of fuel I’ll use over the course mission to within one liter, even with many different ship types.

The Kerbostationary mission is simple - achieve an orbit such that the spacecraft’s ground position as projected on Kerbin is stationary. This is accomplished by achieving an orbital altitude in an equatorial orbit where the angular rotation of the spacecraft matches the rotation rate of Kerbin. what? A stationary orbit makes it like the planet is standing perfectly still as you orbit about it, which is pretty cool. It’s also quite the accomplishment of orbital mechanical dexterity.

In Real Life™, stationary orbits are used around Earth for communications and research satellites, but in KSP, they’re used for pretty screenshots. And for science!

The mission is simple to calculate: Kerbostationary Orbit occurs at a orbital distance of 3,468.751 km, which is 2,868.751 km altitude above the surface of Kerbin. Altitude is handy to know in KSP, since the sim reports all heights in altitude, not distance from the orbital focus. For clarity, I’ll refer to orbital altitudes instead of orbital distances for the rest of this article, but if you’re doing the math at home, be sure you’re using the correct numbers when you switch back and forth!

For the purposes of science (and to make smaller, more controlled burns), I’ve broken this mission up into several parts:

  1. Ascent from Kerbin to a 100km parking orbit
  2. Transfer to a 250km orbit
  3. Transfer to a 500km orbit
  4. Transfer to Kerbostationary orbit
  5. Re-entry

It is possible to go straight to KSO from the 100km parking orbit, or even ascent, but I like this staggered approach for a number of reasons

We haven’t even strapped in yet, and I’m already going to throw in a complicaiton: to ensure the ascent stage returns to Kerbin instead of clogging up my space lanes, I’ll plan on staging my orbiting vehicle from the lifting stack while I’m in an orbit with an apoapse (farthest distance from the orbital focus) of 100 km and a periapse (closest distance to the orbiting focus) of 15 km. Since I’m breaking my ascent up into two different phases, and each orbit transfer consists of two separate burns (transfer insertion and then circularize), this results in a total of 9 maneuvers (full maneuver table is below).

The first maneuver, ascent from Kerbin through the atmosphere to a 15km/100km periapse/apopase orbit, is very difficult to plan precisely. In KSP versions prior to 1.0, I had great success using 4,700 m/s a rule of thumb for the delta velocity required to achieve 100 km orbit from launch, but the new aerodynamics updates have changed this assumption. Although the actual requirement is heavily dependent on individual characteristics of the ship (drag, velocity profile, etc.), a better rule of thumb is more like 3,800 m/s. I’m still experimenting to find a value that works for me, and I suggest you do the same, but it’s not an awful idea to plan for 3,800 m/s and update future plans as you learn more.

Doing the maths, I come up with the required delta velocity for each maneuver here:

Note: If folks want, I can go more into depth into how I arrive at these numbers (and how you can, too!) in a follow-up article, but for this AAR, I’m just going to wave my hands. “You don’t need to see my orbital mechanics analysis.”

One of the real joys of KSP is the infinite possible ways there are to combine rocket parts and still make a successful mission. Obviously, Maneuver #1 can be executed by any number of ascent stages, combinations of solid and liquid fuel systems (depending on how feel about MOAR BOOSTERS), but I’m going to plan on Maneuvers #2 through #9 being performed by one single stage. This requires that stage to be able to deliver a total of 1,703 m/s of delta velocity, which isn’t too much of a stretch for the default parts in KSP.

Just like the details of the mission planning, I’ll likewise skip over the intricacies of my vehicle design, but here is the Kerbplorer 2000, a ship I designed and built exclusively for the Kerbostationary mission.

This single-crewed re-entry and service module combination with a total delta velocity of about 2,000 m/s is a great workhorse for demonstrating the joys of space flight. It was specifically designed for the Kerbostationary mission, as you’ll see by the end of this mission.

Given this vehicle and the mission plan above, I also calculate the fuel used from each maneuver, and the total fuel remaining, so that I have sometime to check as I execute the mission and can determine whether or not I have enough fuel to complete the mission. On larger missions, with more complexity and uncertainty, I like to plan “rescue holding patterns”, where a stricken ship can safely park if I think I’m going to run out of fuel. Checklists like this one help me figure out whether or not I can pass one of these zones, or if it’s time to call home and start rationing the Pringles and Tang.

On this “mission card”, I also include, for reference, the ideal velocity at burnout and the burn time for each of the maneuvers. This enables me to better plan when to start my burn, and helps me prevent burning for too long, or helps me recognize when something is amiss.

As with all things, setting up a launch in KSP is as easy as clicking the launch button (jealous, Space X?), although I’d still love to see a crawler/transporter animation. In the shot above, the the Kerbplorer sits on top of an over-designed launch stage, built with the old 4,700 m/s delta velocity requirement from pre KSP 1.0. The three orange Rockomax 64 tanks are staged in a sequential order rather than the fancier asparagus, but there’s still plenty of juice to get the Kerbplorer setup in a parking orbit around Kerbin. There’s a reaction control system (RCS) onboard, as well, to help with attitude control up in the thinner atmosphere, but with only 120 units of monopropellant. I only expect to need RCS for the final phase of the ascent stage’s life. I’ve also chosen to put Valentina in the cockpit, my first flight with the new Kerbal.

Liftoff! The two Mainsail engines have more than enough combined thrust to power the 133.9 ton launch stack against Kerbin’s mighty gravitational pull, and Valentina squeals in delight at the 2g leap up off the pad. As soon as I’ve confirmed stable liftoff, I roll the stack to align my pitch control axis with the desired trajectory of 90 degrees. This convention makes trajectory control easier for me and, I like to think, gives my Kerbals a more comfortable ride with g’s pushing them into their seat, instead of sideways or feeling like they’re getting pulled out the command pod windows.

To reduce the amount of energy shed off as drag, I pull the throttles back as the stack approaches 100 m/s velocity. Faster is not necessarily better in atmosphere where energy is shed as a function of atmospheric density and velocity squared. Some of the fancier tools use a metric call “atmospheric efficiency”, which I’m currently skeptical of how it’s being used, but the principle is sound: faster does not equal better.

I begin my pitchover much earlier than in pre KSP 1.0 missions, due to the increased fidelity of the aerodynamic and atmospheric models. I don’t have a specific pitchover schedule worked out just yet but at about 2,000 m altitude I start bumping down in pitch to nudge the velocity vector towards the horizon. While in surface mode, the angle between where your nose is pointed and your velocity vector on the navigation ball is exactly equal to your vehicle’s angle of attack. Since drag is proportional to angle of attack, I try keep that angle as low as a I reasonably can, while still nudging the velocity over. Again, no hard numbers to follow, but I generally move my attitude pipper to the edge of velocity marker and then let the velocity vector catch up before I bump it up again.

I continue to make gentle, incremental changes in pitch and slowly creep up the throttle as I get up into thinner atmosphere. The optimum ascent trajectory through an atmosphere is based on the actual vehicle’s aerodynamic performance, and requires an integrated simulation solution to figure out, but there is a very wide range of trajectories that actually work - no need to try to get it perfect. I’m still refining my preferred method, and do not have precise numbers here, but for this mission I was shooting for a 60 degrees flight path angle and 450 m/s velocity at 15 km altitude.

Once I get to 60 degrees flight path angle, I switch to the map view to see how my trajectory is shaping up. Those of you with mods that show your predicated apoapse altitude on the vehicle screen are giggling to yourselves right now, and for good reason! This is a critical bit of information to have while executing the ascent portion of the mission and it’s distracting to switch between views to get it. I’m warming up to Kerbal Engineer Redux, but still enjoy my vanilla KSP experience.

I mentioned this earlier, but it’s important so I’ll note it again: the value given for apoapse in this view is the predicted ALTITUDE at apopase, not orbital distance. Orbital mechanics equations typically use the orbital distance of a body from the orbital focus, which would be the center of Kerbin in this case. If you’ve got your Bates/Mueller/White book cracked open, remember to add the celestial body’s radius (600km for Kerbin) to these values to get the right value for your equations.

There are two very important pieces of information in the map/orbital display - the predicted apoapse altitude, which I’m looking to get to 100 km, and the time to apoapse. During ascent, the time to apoapse is likely changing - increasing or decreasing depending on what you’re doing at the time, but, in general, a large time to apoapse will translate to a long coast time once the desired apoapse height is reached, so you don’t want it going too far, or you’re going to end up having to cut your engines and start burning again later, which can decrease efficiency.

Of course, with the infinite possibilities in KSP, there are certainly ship or mission designs where a burn/coast/burn profile is actually desired, but I’m shooting for max efficiency, so I use my throttle to control the time to apoapse, while I use pitch to control the rate of change of my apoapse height. Again, no hard numbers, but around 1 minute seems to be a decent lead time on apoapse, and, per the mission, I’m shooting for an apoapse of 100 km…

The net result is a trajectory that culminates in a relatively shallow flight path angle and very gentle thrust for the last section of the ascent, but there’s no need to rush. Besides, I think a smooth transition from ascent to circular orbit is just plain sexy.

I haven’t reached that stage of the mission just yet, however. Once the booster stages are empty, I jettison them - the remaining tank and engine has more than enough delta velocity to complete the ascent stage. I’ve set the staging so that my central engine activates as well, and I also enable the RCS at this point. The gimbaled motion of the Mainsail engine gives it great attitude control while at full thrust, but the low power setting at this phase in the flight can make attitude control difficult.

Now it’s a matter of monitoring the apoapse height, time to apoase, and orbital velocity, and providing minute changes to pitch and throttle to achieve the desired endgame. Math tells me that the orbital velocity at 100km altitude above Kerbin is 2246.1 m/s. I’ve got quite a bit to go, but I need to ensure my apoapse is where I want it once I reach that velocity, so fractional tweaks in pitch are needed to reach and then maintain that 100km apopase prediciton.

As I briefly described earlier, I stop the circularizing burn short of fullly circularized for a seemingly silly reason - I want to ensure my lower ascent stage goes back to Kerbin instead of staying up in space, clogging up the space lanes and cluttering my map display. While KSP gives you the ability to delete unwanted junk and debris from orbits, I try to design and execute my missions to minimize orbital debris to begin with. For this mission, I’ve planned to separate the Kerbplorer from the ascent stage when I reach a 15km/100km elliptical orbit (15km periapse, 100km apopase). This will ensure the spent lower stage returns to the surface of Kerbin, but reduces the total delta velocity needed from the Kerbplorer stage to continue the mission. For this maneuver, I’ve calculated a total delta velocity requirement of 73.8 m/s, which will consume 10.6L of liquid fuel (plus the appropriate amount of oxizder).

Before staging, I do a quick check of the upper stage and ensure all the fuel and monopropellant tanks are topped off, batteries have sufficient charge, solar panels are deployed and producing power, etc. Anal retentive, I know, but the prevents embarrassing separation issues. Alternatively, pressing F5 before a risky maneuver quicksaves a snapshot of the game status which can be restored by pressing (and holding down!) the F9 key - a handy habit to learn!

A successfully separation marks the end of Maneuver #1. With the Kerbplorer 2000’s LV-909 “Terrirer” high-specific-impulse liquid fuel engine activated, it’s now time to execute Maneuver #2 and circularize this orbit before Valentia passes apoapse and starts decaying back to an earlier-than-planned re-entry orbit. Luckily, the circularizing orbit maneuver burn will be short, 6.6 seconds, so there’s no real risk of re-entry unless I really screw this up.

Textbook! I’ve used almost precisely the fuel I predicted (the display resolution rounds to the nearest liter and it shows I used 10L of fuel compared to the10.6 I predicted), and while the orbit isn’t quite as perfect as it could be, both the apoapse and peripase are within 500m of the desired altitude.




For the purposes of science (and showing off), however, I want to get the orbit parameters a bit closer before I execute my next burn, so I use the RCS thrusters at apoapse and then periapse to raise/lower the opposite node to the desired height. If you increase your orbital velocity at one node, you RAISE the other and, conversely, lowering orbital velocity at a node LOWERS the opposite node. With two very short RCS maneuvers at each node, I achieve an orbit of 99,990/99,998, which is a circular orbit with an eccentricity of 0.00004. Not to brag, but this is 10 times better than the ISS’s orbit.

Established in a parking orbit, it’s now time for that essential phase of any mission: screenshots and videos.

Maneuver #2 out of the way, it’s now time to go on to the next maneuver. Another benefit of this mission is that none of the orbit transfers are time critical - you can execute them whenever you want. I try to plan my Kerbostationary transfer so that my final KSO position will be above something interesting on the planet below, but the rest of the orbit transfers (#3, #5, and #7) can be executed whenever the Mission Commander feels like it.

Maneuver #3 is a little beefier than the previous maneuver, a 9.3 second burn netting a delta velocity of 106.2 m/s and consuming 25.4 L of fuel, but the execution is exactly the same: line up on the prograde vector, light the engines, burn until I near the desired apoapse, fine-tune the apoapse height with RCS, and then coast to my new orbital altitude.

Maneuver #3 goes well (it’s not necessary to nail the altitude to within a meter, but man, it feels good when you do!), and the time to apopase to execute Maneuver #4 just flies by - a mere 19 minutes later and Control is yelling at Valentina to pause her audiobook (The Martian) and get back on the controls.

When trying to be precise, timing your circularizing burn to occur exactly at the apoapse reduces the amount of correction you have to make. It’s not always a big impact, as with these small orbits, but the discipline you build here as habit will payoff in interplanetary missions later, so use this opportunity to try to be as precise as you possibly can. The ideal goal is to have the apoapse marker stay on your ship throughout the burn. You can pitch up or down during the burn to play with the marker’s position, but don’t chase a runaway marker. If the marker flies away from you, shut down the burn and just wait until you get to the next marker to do whatever you need to do. One of the benefits of circular orbits is you’re always set up to execute a go-around.

In reality, once the burn has been completed, the apoapse and periapse markers will swing around as the vanishing eccentricity of the orbit magnifies even the tiniest imperfections in your orbit’s shape. When you’re equally distant from both markers (see above pic), it’s time to stop the burn, even if one of the values is still way off. Affecting your prograde velocity at this point is just going to do more damage to your circular orbit.

After Maneuver #4, my circularizing burn to 250 km altitude, the Kerbplorer is saddled in an orbit with altitudes of 249.730 and 250.205 km for periapse and apoapse, respectively, resulting in an overall orbital eccentricity of about 0.001. Valentina seems pretty excited about these results, but I know we can do better. I use the RCS to fine tune the orbit to 250.000 and 249.991 km, or an eccentricity of 18 parts per million (0.000018). This I’m happy with.


Additionally, my fuel usage is going pretty much exactly as predicted: the display shows 186 liters of fuel left, and I’ve predicted 185.9. Nice! self high-five

Time for more screenshots. At this higher altitude, our spacecraft orbits a bit slower (2038 m/s vs 2246 m/s at 100 km altitude), but the surface of Kerbin still races by below us. Even without a timewarp, the movement of the planet below us is quite noticeable. Although we’re two and a half times the altitude, our orbital period is about 44 minutes, compared to the 33 minutes at 100km - not that much difference, really.

Maneuvers #5 and #6, orbital transfer to 500km, go just like the others - smooth as silk, with a little touch up required for a nearly perfect circular orbit (final eccentricity of 0.000008 here). Fuel usage is better than expected, 155 liters remaining with 154.3 planned. One possible reason for using LESS fuel than the ideal plan is that the plan did not account any expenditure of monopropellant: the RCS is helping me achieve some delta velocity that I had planned to get using liquid fuel. This might be considered cheating by some, but when it comes to getting home safe, I’ll take any advantage my Kerbal can get!

Obligatory 500 km altitude screenies (If you’re paying for these by the KB, I hope it’s worth it!):

Next up is the biggest burn of the mission, not counting ascent: Maneuver #7 is a 30.4 second burn that will turn 48.6 liters of fuel into an additional 416.2 meters per second, sending Valentina up from her circular orbit at 500km to an apoapse at the kerbostationary orbit height of 2,868.751 kilometers. As a note, this transfer orbit has a period about twice that of Kerbin (actually, 1.87 times, but who’s counting?). This means that if I wanted to park the Kerbplorer in KSO over some specific landmark, like the Kerbal Space Center, I can start the transfer burn about 90 degrees behind that landmark. The Kerbplorer will catch up to the landmark just as it reaches kerbostationary altitude.

Unfortunately, during this burn, I’m not as quick with the throttle cutoff and I end up with a larger apoapse than I wanted: 2,955.477 km instead of 2,868.751. Although it’s “in the ball park”, astronomically speaking, this vehicle was designed with pretty tight tolerances to the mission, and I need to see if I’ve exceeded my fuel usage allocation. I immediately check my fuel usage and find out I’m not even far enough away from expected to register on the display - 105 liters actually remaining compared to 105.7 liters planned reamining. Satisfied I don’t need to abort the mission, and confident in the remaining fuel margin, I flip the vehicle to point retrograde and use the main engine to correct for most of the error. The fuel display still shows 105 liters remaining. I then use the RCS to fine tune the apoapse, and encourage Valentina to relax on her 96 minute coast on up to the KSO perch. I joke that at least it’s not a three-hour tour, but the radio only returns static.

This particular transfer is the most dramatic of the mission, in terms of the changing relative size of Kerbin. The planet just seems to whoosh away as the Kerbplorer sails along its patch of conic section.

Even though I’m still acutely aware of the need for accurate burn timing, I don’t get as close to my final numbers as I’d like with Manuever #8, my kerbostationary circularizing burn - 2,864.851km/2,871.921km for an eccentricity of 0.001. The actual fuel remaining is 72.54 liters (the extra two digits after the decimal place pop up once you’re below 100 liters of fuel), which compares OK with the 73.3 liters planned, especially considering the earlier mistake. The issue with this maneuver wasn’t so much burn timing as increased sensitivity to velocity errors. With a circular velocity of 1009.0 m/s, a single tenth of a meter per second error has a much bigger impact on orbit shape than at lower altitudes/higher speeds. On the same note, the delta velocity required to further perfect the circularization is well within the capability of our RCS system, so I’m not too concerned about being able to polish this up.


A few well-timed bursts from the RCS thrusters at apoapse and periapse (now 3 hours apart!) result in a fairly well-tuned orbit: 2,868.760/2,868.722 has the best eccentricity yet at 6.6 parts per million, and is pretty darn close to the desired altitude (2,868.751 km). The orbital period of our final orbit is 0.09 seconds shy of Kerbin’s rotational period, which will result in a 1 second error every 11 days, but I think I can live with that.

For those of you who were shaking your head at all the attention I spent on achieving uber precise orbits, here’s where it pays dividends:

[video coming! sorry!]

Primary mission objectives accomplished, Pringles and Tang resources nearly exhausted, it’s time to get our intrepid explorer home.

Although the re-entry transfer orbit might not seem as critical as any of the other transfers, the updates to the KSP aerodynamics and atmosphere models can make successful re-entry pretty tricky. I’m sure you’ve noticed the blocky fairing at the base of the Kerbplorer’s command pod, protecting the heatshield - this device, introduced in KSP 1.0, is absolutely required for most re-entries. Re-entry, which used to be as easy as just getting your orbital trajectory to intercept a planet with an atmosphere, has become a very risky maneuver in KSP 1.0, even for some relatively short suborbital missions.

Our re-entry transfer ellipse from kerbostationary has a theoretical max velocity at periapse of about 3,095 m/s, so we can expect to get hot. Just like real space missions, if the re-entry angle is too steep, the heat-shield will ablate too quickly and then fail before the command pod has slowed down to a safe airspeed, creating less than favorable environments for our current favorite Kerbal. Too shallow and the pod won’t re-enter, skipping back into orbit, with our crew member likely grumbling about it the whole way. Although we don’t have to worry about life-support systems in KSP, I still don’t like to “skip out” on my re-entry approaches.

Now committed to re-entry, I take a moment to check the re-entry vehicle’s status to ensure it’s prepared for the most dangerous portion of the mission - atmospheric interface (it would have been smart to do this before the de-orbit burn, you say?). In this step, I ensure batteries are topped off (no electricity means no attitude control means no pointing the heatshield means Valentina gonna be mad), ports are closed, gear retracted, etc. One exciting new feature of KSP 1.0 is that if you leave your parachute parameters to default, the rescue pod will not be decellerated fast enough and will hit the ground too fast, exploding on impact more often than not. This is not the expected response of a parachute-based recovery system. I’ve found that 500 m deploy altitude is way too late to ensure full deployment of the parachute envelope, and a 1,000 m altitude is much more reasonable. You might find a different height works for you and your spacecraft, but 1,000 has been safe for me every time…so far. Make sure to adjust this before re-entry, though, as it can be tough to click and slide on the interface while the spacecraft is bouncing around in the atmosphere!

The lower section of the Kerbplorer 2000 won’t survive re-entry, but that doesn’t mean we want to cling on to it while it fries to a crisp. We also don’t want to bonk into it during the descent so one trick I’ve picked up is to separate the re-entry module from the service module while pointing 90 degrees from where we’re going. The separation force from the stack decoupler makes sure the two vehicle components will go on separate trajectories through the atmosphere, ne’er the twain shall meet. If you have an aerodynamically complicated lower stage that might swerve in the atmosphere and cause headaches for re-entry vehicles in the neighborhood, you can perform the separation much earlier during the transfer orbit, about 90 degrees before planned re-entry periapse, to ensure the maximum separation on entry to the atmosphere interface, but this is pretty conservative.

At this point, there’s not much else I can do. I use the torque wheels in the command pod to steer the heat-shield to take the brunt of the aeroheating. With the PhysicsSignificance fix in 1.01, it’s safe to turn off SAS and let the combined heatshield/command pod dynamics keep the heat shield pointed the right way. If you have extra gear on there, like Goo pods or whatnot, you may need to be more proactive in maintaining the right entry attitude.

Brainy fact of the day - the white waves following the command pod after the incandescent portion of re-entry (see pic above) are expansion waves, not shock waves. Almost the exact opposite of shock waves, expansion waves occur where the air compressed by the command pod rapidly expands back to atmospheric pressure.

Another technique I continue to experiment with is the timing of parachute deployment. I’ve settled on initially deploying the chute once the surface speed slows to 300 m/s - this seems to work for both the small and large command pods. In the screenshot above, you can also see that the heat shield has only 84.78 units left out of 200 - we burned through more than 50% of our only protection against instant death!

The parachute deployment animation and effects have been redone in KSP 1.0 and I quite like it. The envelope on the basic Mk16 chute takes a couple seconds to fully fill up and fills the air with that terrible flapping noise as it does. The deceleration is still pretty severe, though, so be careful of trying to parachute in complex landers or pods without some of those magic EA-4 struts.

And down! Will Valentina ever realize just how close she was to death at so many parts of this mission? I hope not, because I plan on sending her on a few more!

I hope you enjoyed this AAR, let me know if you’d like to see more.


Wow…that’s pretty mind blowing. So I think I followed all of it except for one part…well, one thing I’m confused on. Is the launch site on the equator of Kerbin? If it isn’t…(like Cape Canveral), do you have to make a burn to go “down” (for lack of a better term) toward the equator and then a corrective one to stop that correction? I mean, I know you will cross the equator with a circular orbit that isn’t on the equatorial plane…but how do you correct it to be ON the equatorial plane (I’m correct in that geo-stationary orbits must be on the equatorial plane right?).

Really cool stuff. Thanks for taking the time to write that up!


Good question, @BeachAV8R! Yes, KSC is on the equator. If it wasn’t, I would need to perform a plane change to get to the equatorial plane before I got to a kerbostationary orbit.

Although I didn’t need to perform any plane changes for this mission, the delta v required goes up as a function of the angle you need to change and your total orbital velocity [ 2Vsin(theta/2) ]. e.g., a 10 degree plane change would cost more at a lower orbit (100km) than a higher orbit (KSO), so I’d probably wait until I was at kerbostationary altitude (2,868.751 km) before performing the plane change. Actually, I’d probably do the plane change while I was at KSO altitude during the XFER orbit, while I still had my periapse down low. Mr. Wizard moment: can you guess why?

@EinsteinEP I dunno…but I’ll make a dumb guess and figure you can use some of the energy during the transfer burn to also change your orbital plane…so you don’t have to do two separate burns (is one burn always better than two in space when you are talking about failure rates and stuff?)…

With plane change maneuvers, the cost in delta velocity is 2Vsin(theta/2), where V is your orbital velocity at the time you make the burn and theta is the delta angle in your orbit. For a given theta, the slower you are going (V) when you make the burn, the less delta velocity you need. With the 500km/KSO transfer orbit, you’re going the slowest at the top of the curve, (700.2 m/s), so it would only take 122 m/s to do a 10 degree plane change. The same maneuver at a 100km parking orbit would cost 392 m/s!

You can combine maneuvers to reduce the number of burns but in the case of a plane change, it’s most efficient to complete the plane change at the slower velocity and then perform a circularization burn afterwards.

Very nice - lots of detail.

I tend to just bumble my way through, and am enjoying the career mode. I would have preferred to have sent up some probes first, a la Sputniks, but Career mode seems to want to do Mercury missions from the get go. :smile:

My tiny ‘I was told there was no math’ tips for new starters (with no mods) would be:

  • Turn on SAS on pad.
  • After 100 m/s is reached follow the Prograde (purple) marker with simple taps.
  • Throttle down at about 300 m/s until you reach 10 km.
  • Cut engines when apoapsis height reaches 70 km i.e. flip to map view to check.
  • At apoapsis raise the periapsis until it flips by burning towards the horizon (in map view again).
  • You’re in an orbit! Go crazy with hopefully lots of fuel left for moon, planet transfers…

This is one of the great advantages of KSP - you can literally start launching rockets within minutes of playing the game for the very first time. The intuitive and easy-to-use vehicle assembly process means even a total noob can make a very powerful rocket.

Getting into orbit is a bit more challenging - you’ve identified a basic ascent profile (except the velocity vector marker is yellow, not purple! :wink: ), and, with a little iteration, ANYBODY can get to orbit. If only cold-starting the A-10C in DCS was that easy…

I love the math bit of it, of course, and the fact that I can fly a mission in KSP within one unit of fuel of what I calculated on paper blows my mind. There’s a little more uncertainty in interplanetary missions, or even Munar fly-bys, but I can usually get very close.

While I don’t use any math to achieve orbit, I don’t use control mods like MechJeb. Plotting the maneuvers manually using the stock Maneuver Node tool taught me so much about how to adjust orbits for more expeditious rendezvous’, more efficient deep-space rendezvous’ with asteroids, and even gravity assists using the Mun to cut down on how much fuel it takes me to go interplanetary.

Not to mention the basic mechanics of how orbits and physics in space work.

1 Like