Kerbal Space Program

1
Kerbal Space Program

The Missing Manual
(updated for version 0.24.2)
Volume I
Author: Anthony de Araujo1
1
credit to Robert S. and dkmdlb for some much needed typo corrections
2
Disclaimer
The information in this book is for informational purposes only.
Kerbal Space Program is a product developed by Squad. It is currently in

the alpha stage, but has been available for early access purchase for around
2 years.
I am not a lawyer or a rocket scientist, nor am I affiliated with the pro-

ducers of the Kerbal Space Program game.
Any advice that I give in this publication is my opinion based on my own

experience with the game and research I have done about the subject.
The material in this book may include information, products or services

by third parties. Third Party Materials are comprised of the products and
opinions expressed by their owners.
As such, I do not assume responsibility or liability for any Third Party

Material or opinions.
The publication of such Third Party Materials does not constitute my

guarantee of any information, instruction, opinion, products or services con-
tained within the Third Party Material.
Publication of such Third Party Material is simply a recommendation

and an expression of my own opinion of that material.
3
4
No part of this publication shall be reproduced or transmitted, in whole

or in part in any form, without the prior written consent of the author. All
trademarks and registered trademarks appearing in this publication are the
property of their respective owners.
Readers of this book are advised to do their own due diligence when
utilizing the information contained herein.
By reading the information contained in this publication, you agree that

the author is not responsible for the success or failure when utilizing any
information presented.
Contents
1 About the Author 9
2 Introduction 11
2.1 What is Kerbal Space Program? . . . . . . . . . . . . . . . . . 11
2.2 About this book . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3 Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3.1 v (Delta-v) . . . . . . . . . . . . . . . . . . . . . . . 13
2.3.2 Isp - Specific Impulse . . . . . . . . . . . . . . . . . . . 18
2.3.3 TWR - Thrust to Weight Ratio . . . . . . . . . . . . . 20
2.3.4 Staging . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.3.5 Attitude . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.3.6 Prograde/Retrograde . . . . . . . . . . . . . . . . . . . 31
2.3.7 RCS - Reaction Control System . . . . . . . . . . . . . 33
2.3.8 SAS - Stability Augmentation System . . . . . . . . . . 34
5
6 CONTENTS
2.4 Orbital Mechanics - The Mathy part . . . . . . . . . . . . . 35

2.4.1 What is an Orbit? . . . . . . . . . . . . . . . . . . . . 35
2.4.2 Periapsis . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.4.3 Apoapsis . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.4.4 Semimajor Axis . . . . . . . . . . . . . . . . . . . . . . 40
2.4.5 Eccentricity . . . . . . . . . . . . . . . . . . . . . . . . 43
2.4.6 Inclination . . . . . . . . . . . . . . . . . . . . . . . . . 44
2.4.7 LAN - Longitude of Ascending Node . . . . . . . . . . 47
2.4.8 Argument of Periapsis () . . . . . . . . . . . . . . . . 50
2.4.9 Mean Anomaly . . . . . . . . . . . . . . . . . . . . . . 50
2.4.10 Orbital Stability . . . . . . . . . . . . . . . . . . . . . 51
2.4.11 Lagrange Points . . . . . . . . . . . . . . . . . . . . . . 54
2.4.12 Altitude vs. Velocity . . . . . . . . . . . . . . . . . . . 56
2.4.13 Oberth Effect . . . . . . . . . . . . . . . . . . . . . . . 57
3 The Navball 63
3.1 Navball Indicators . . . . . . . . . . . . . . . . . . . . . . . . 65
3.1.1 Prograde . . . . . . . . . . . . . . . . . . . . . . . . . . 65
3.1.2 Retrograde . . . . . . . . . . . . . . . . . . . . . . . . 65
3.1.3 Target Prograde . . . . . . . . . . . . . . . . . . . . . . 66
3.1.4 Target Retrograde . . . . . . . . . . . . . . . . . . . . 67
3.1.5 Maneuver Node . . . . . . . . . . . . . . . . . . . . . . 67
3.1.6 Level Indicator . . . . . . . . . . . . . . . . . . . . . . 68
3.1.7 Other Navball Indicators . . . . . . . . . . . . . . . . . 68
3.1.8 Using the Navball To Change Your Attitude . . . . . . 69
3.1.9 Maneuver Nodes . . . . . . . . . . . . . . . . . . . . . 73
3.1.10 Executing Maneuvers . . . . . . . . . . . . . . . . . . . 81
CONTENTS 7
4 Orbital Maneuvers 85
4.1 Gravity Turn . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
4.2 Circularizing your Orbit . . . . . . . . . . . . . . . . . . . . . 87
4.2.1 Achieving Orbit . . . . . . . . . . . . . . . . . . . . . . 87
4.2.2 Circularization . . . . . . . . . . . . . . . . . . . . . . 88
4.3 Changing your Orbital Inclination . . . . . . . . . . . . . . . . 96
4.4 Aerobraking . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
4.5 Rendezvous . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
4.6 Docking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
4.7 Gravity Assist . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
4.8 Landing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178

8 CONTENTS
Chapter 1
About the Author
I am a software developer with 30+ years of experience. Over the course of

my professional career, I have also been a big game enthusiast during my free
time.
Ive played everything from Tetris, Breakout, Duke Nukem and Doom to
Left 4 Dead, Portal, Space Engineers and, of course, Kerbal Space Program.
I am not a rocket scientist. I am simply an enthusiast of the game with

a knack for research. All the concepts and descriptions that I provide in this
book are my own experiences with the game and are not guaranteed, in any
way, to help you accomplish your own goals in the game.
I strive to provide the technical content in a fashion that a layperson can

easily understand. If you have suggestions about how I could better explain
anything you see here in the book, I would appreciate it if you would drop
me a note about it at admin@mykspcareer.com.
For the real rocket scientists that might stumble upon this book, if I got
anything wrong, please let me know so that I can fix it. I want to provide the
most accurate information possible, but in trying to translate engineer-ese,
or rocket-scient-ese to English I might have made some mistakes. Also bear
in mind that some things I explain in this book might be wrong in the real
world, but may apply in the Kerbal universe, so be gentle.
9
10 CHAPTER 1. ABOUT THE AUTHOR
I thoroughly enjoyed writing this book, and I hope that anyone who is
reading it can glean some useful information from it and have a better, more
enjoyable, experience in the game.
Chapter 2
Introduction
2.1 What is Kerbal Space Program?
Kerbal Space Program is an extremely fun and educational game. Having

always been interested in the space program, I thought I knew something
about space. Turns out I was wrong. My firsts forays into space in Kerbal
Space Program ended in disaster, multiple disasters.
If that is what you are experiencing, do not fret. The learning curve
is rather steep, but once you start to understand the concepts, that I de-
scribe in detail in this book, the game becomes something that is, well. . .
indescribable. . .
Without realizing it, you will be learning concepts about space travel that
you never even imagined!
The game comes with three distinct modes of play: sandbox, science and
career.
In sandbox mode, you have all of the parts available for use and can
create some pretty impressive vehicles.
11
12 CHAPTER 2. INTRODUCTION
In science mode, you start with a few, basic parts, and you must do
research to gain science points which you use to unlock more advanced
parts. While science mode might seem intimidating, it is a very good way to
start learning the game. Since you have access to a limited set of parts, you
can use, and understand, those parts, naturally progressing to more advanced
parts as they are unlocked.
In career mode, you start with a few, basic parts just like in science
mode. You still must do research to gain science points which you can
use to unlock more advanced parts. Besides the science aspect of career
mode, version 0.24 introduced contracts, funds and reputation. These three
resources must be acquired/used over the course of your career. Like science
mode, it might seem intimidating but is also a very good way to start learning
the game. The contract aspect of career mode forces you to use parts in some
interesting ways that you might not have thought of otherwise.
If you start playing in sandbox mode, the sheer number of parts can be
a little overwhelming, which makes the game a little harder to learn.
2.2 About this book
When I first started playing Kerbal Space Program, it was very difficult
to find any type of reference material online. I followed the advice of fel-
low players (shout out to http://reddit.com/r/kerbalspaceprogram) and
watched all the mandatory videos (that means YOU, Scott Manley! https:
//www.youtube.com/user/szyzyg)
I still found it very hard to gain any real knowledge about the concepts
that you need to understand to play the game effectively. So I decided I was
going to figure this stuff out for myself, and publish what I had learned on
a blog. So I created http://mykspcareer.com, hoping to share my knowl-
edge.
The response to the blog was, well, underwhelming. So here I am again,

trying to get this information out there. So I decided to write this book.
2.3. CONCEPTS 13
A lot of the content in this book can be found on the blog mentioned
above, including some features that I, obviously, cant include in the book,
like .craft files.
As I mentioned in the disclaimer above, Im not a rocket scientist, just an

enthusiast of the game with a knack for research, so I hope this book helps
old and new players alike in accomplishing their goals within the game.
If you happen to be a rocket scientist, or just someone smarter than me

(probably not rare), and you see anything in this publication that is wrong,
could be explained better or missing entirely, I would appreciate it if you
dropped me a note at admin@mykspcareer.com.
Any contributions made by third parties will be fully credited in subse-

quent editions of the book.
The fact that you are even taking the time to read this book, makes me
happy to have invested the time to produce it.
2.3 Concepts
There are a myriad of concepts related to orbital mechanics, terminology,

etc. that will help you immensely in learning the game. In this section I will
go over SOME of the ones I think are more important.
2.3.1 v (Delta-v)
delta-v means, literally, change () in velocity (v), and is simply short-hand

used by personnel involved in astrodynamics.
Think of your car: it has a gas tank of finite size; it has an engine of a
specific power (in the case of cars, horsepower), and it has a certain dry-
mass (how much the car weighs, without fuel).
The equivalent of your cars v is not its MPG rating, nor is it the power
of your engine.
Imagine that your car doesnt have an upper speed limit. So we put you
in your car, with a full tank on the salt flats of Utah. You step on the gas,
and hold it down, constantly accelerating, until you run out of fuel. If your
speed, when you ran out of fuel was, lets say, 2237 mph, then that is your
v. Your car has the capacity to change its speed, from a dead stop with a
full tank, by 2237 mph until it runs out of fuel.
Ill take this opportunity to say that when dealing with astrodynamics,
we use the metric system almost universally. So instead of miles per hour,
we use kilometers per hour, or even more frequently, meters per second. 2237
mph works out, in metric, to be almost exactly 1000 m/s.
In your car above, the overwhelming majority of mass of the fully fueled
vehicle is the vehicle itself, the mass of the fuel in your car, when compared
to the total mass of the car is minuscule. In the rocket world, the majority
of mass is the fuel.
As an example, Ill show you the specifications for the Space Shuttle:
The Shuttle itself, just the orbiter, without the big orange tank or the
solid boosters, has a gross liftoff mass of 110,000 kg (this includes payload,
crew, consumables, fuel for the shuttle to use in space, etc). To launch
the shuttle, we add the big orange external tank, and the two solid rocket
boosters which weigh in, fueled, at 756,000 kg and 1,142,000 kg (each booster
is 571,000 kg), respectively. 1,000 kg per ton is a fair approximation for our
purposes, so lets just call the entire shuttle assembly 2,000 tons.
Bear in mind that we burn through the solid rocket boosters in the first
2 minutes of the flight and the external tank runs the shuttles main engines
for a grand total of 8 minutes before being jettisoned, so we use 1,898 tons of
hardware and fuel to launch 110 tons of spacecraft into space. So only 5.8%
of our spacecraft is actual spacecraft, the remaining 94.2% of our spacecraft
is launch hardware and fuel.
2.3. CONCEPTS 15
In comparison, a 2010 Chevy Camaro weighs

in at about 1720 kg and has a fuel tank capacity
of about 20 gallons (19 actually, but 20 makes
our calculations easier). Those 20 gallons of gas
weigh 55 kg. So our Camaro, at 1.8 tons, is
96.9% vehicle and only 3.1% fuel. But our Ca-
maro cant go straight up in the air either. This
Camaro can also accelerate from 0 to 60 mph in
6 seconds, which gives us a very convenient 10 mph/s (4.5 m/s2 ) of acceler-
ation.
Everyone knows that a heavier vehicle gets worse gas mileage. But the
97/3 ratio for our Camaro is pretty negligible. In our example above, of 1000
m/s, the car was heavier when it started to accelerate than at the end when
it was running out of gas. So of those 1000 m/s of v slightly more of it
came from the second half of the tank versus the first half of the tank.
With our space shuttle, however, after 2 minutes of flight, the vehicle
drops the two solid boosters which accounted for 1,142 tons: more than
HALF of the total mass of the vehicle when it was sitting on the launchpad.
So in our example, 20 gallons of gas got us from 0 to 1000 m/s. And the
mass of the vehicle only changed by 3%. In the case of the shuttle, at liftoff
we are pushing 2,000 tons, the total burn time for the shuttle is 8 minutes.
After 41 of the burn time (2 minutes), we shed more than half the mass of the
vehicle. So that last 34 of burn time, theoretically, we are accelerating more
quickly than during the first 14 (not necessarily true, since during that first 14
we also have two additional engines - the two solid boosters - burning).
The point Im trying to make is that the mass of the shuttle changes
VERY rapidly over the course of the launch (8 minutes). In the case of our
Camaro, you can use Newtons Second Law of Motion to analyze the vehicle
since, for all intents and purposes, we can consider the mass of the vehicle to
be constant (it only varies by 3%, slowly decreasing as the fuel tank empties).
When it comes to the shuttle, we cannot use

Newtons Second Law of Motion to analyze the sys-
tem because the mass is not even close to constant
(it varies by 94.2% over the course of 8 minutes!).
Where the Space Shuttles Main Engines (SSMEs -
the three engines we see right below the vertical sta-
bilizer) could not even budge the shuttle off the pad
at its full 2,000 ton liftoff mass, once the shuttle is
already moving at a good clip, and having dumped
the extra 1,142 tons of solid booster mass, they are
more than sufficient to propel the vehicle into orbit
over those last 6 minutes of the launch burn.
Due to this inability to analyze the shuttle sys-

tem performance using Newtons Second Law of Motion, we need a different
mechanism. That mechanism is the Tsiolkovsky rocket equation.
m0
v = Isp g ln m1
where:
m0 is the total initial mass of the vehicle, including propellant;
m1 is the total final mass of the vehicle (after burning all of the propellant)
Isp is the specific impulse for the engine(s)
g is Standard Gravity (9.8 m/s2 )
This equation takes into consideration the rapidly changing mass of the
vehicle and allows us to calculate how much change in velocity the vehicle is
capable of applying to itself.
As you can see above, the equation needs the Isp of the engine to calculate
the v. For now, just accept that rocket engines have Isp values (kind of
2.3. CONCEPTS 17
like the horsepower values you get for car engines, well be discussing those
next).
Now we know what v is and how to calculate it, but why should we
care?
Every maneuver, performed by a rocket, has a specific amount of v

that is required to perform the maneuver. For example: to launch, from
the Kennedy Space Center and achieve a Low Earth Orbit (LEO), it takes
anywhere from 9,300 to 10,000 m/s of v. Once in an LEO, to transfer to
a Low Lunar Orbit (LLO), it takes an additional 4,000 m/s of v. Since
we dont want to just leave our poor astronauts there, we need 1,300 m/s of
v to transfer from LLO back to LEO and then another minuscule amount
of v necessary to deorbit (since atmospheric drag does most of the work).
So a vehicle, tasked with launching to LEO, then transferring to LLO, then
transferring back to LEO and landing, would require a total of 15,300 m/s
of v.
From To v reqd
Low Earth Orbit (LEO) Earth-Moon Lagrange 1 (EML-1) 3,770 m/s
Low Earth Orbit (LEO) Geostationary Earth Orbit (GEO) 4,330 m/s
Low Earth Orbit (LEO) Low Lunar Orbit (LLO) 4,040 m/s
Low Earth Orbit (LEO) Earth-Moon Lagrange 2 (EML-2) 3,430 m/s
Low Earth Orbit (LEO) Moon 5,930 m/s
Table listing approximate v requirements within the Earth-Moon system
If you want to have an idea of how big of a rocket is needed to do that,

think Saturn V, the one that went to the Moon: It was the length of a
football field, at its base it was over half the width of a football field, and
weighed, on the pad, ready to launch, 2,800 tons. Of that total, only 45 tons
worth of spacecraft actually went to the Moon. 1.6% worth of spacecraft got
to the Moon, the other 98.4% of the spacecraft was either burned (as fuel)
or jettisoned (as spent stages).
Thankfully, the developers at Squad realized that making the Kerbal

Solar System an exact replica of our own Solar System would make the game
WAY too difficult to be enjoyable. If you think you have it tough getting into
Kerbin orbit, which only requires 4500 m/s of v, imagine if our flimsy,
wobbly rockets had to be 4 times as big as they are!
2.3.2 Isp - Specific Impulse
Isp is, loosely, the rocket engine equivalent of an Earthbound car engines
miles per gallon. It measures the efficiency of the engine (each engine has
its own Isp). If you have one engine, with an Isp of 800, you might think
that you could get more v if you add a second engine of the same Isp. You
wont, youll get your v faster, but not more of it.
Isp defines how much v you can, effectively, get out of a unit of fuel
(a kg, for example). So if you have an engine with an Isp of 400 and 500
kg of propellant, in a 1,500 kg rocket (so 1,000 kg of rocket and engine, plus
500 kg of propellant) you would have a total v of 1,590 m/s. Lets say
that your rocket takes 4 minutes to burn through those 500 kg of propellant.
So if I was moving at 1,000 m/s when I started burning, when I ran out of
propellant (4 minutes later), I would be moving at 2,590 m/s, a change ()
in velocity (v) of 1,590 m/s.
Too slow for me, Im gonna add another engine on that rocket. So I put
a second, identical, engine on the rocket. Do I get more v? No. My rocket
now will burn through my propellant twice as fast, since I have two identical
engines sucking on the tank, so my burn will only last 2 minutes. And to
top it all off, my final speed, when the burn ends, is now only 2366 m/s!. I
got my v faster (2 minutes versus 4 minutes), but I got less v than with
the single engine. You LOSE a small amount of v because the engine you
added increased the overall mass of the vehicle (dead weight once it stops
burning).
2.3. CONCEPTS 19
Our 1,500 kg rocket had 500 kg of propellant and I said 1,000 kg of

rocket and engine. Consider that the engine was 200 kg (so 800 kg of other
stuff that made up the rocket). I added an additional 200 kg of mass to
the vehicle, so my rockets total fueled mass is now 1,700 kg, and after all
the fuel is burned, 1,200 kg. All the propellant that I burned during my
maneuver had to push 200 kg more of mass during the burn, therefore the
v produced was slightly less.
From this we learn that if I want more v, I have to increase the mass
of propellant available to the engine (assuming the engine remains the same)
*OR* keep the mass of propellant I currently have and increase the Isp of
the engine I am using to burn it (effectively taking the 40 mpg engine out of
the car and replacing it with a 50 mpg engine).
So why dont they just use something like miles per gallon to indicate
efficiency? Because rockets arent cars. The mpg rating on your car is a
rating calculated under specific conditions (usually conditions that benefit
the manufacturer by maximizing said rating). For example: the 30 mpg
rating on your car might be at a constant speed, on level ground, with no
wind. Under these specific conditions, every, theoretically, 30 miles that
you travel, your engine consumes one gallon of gas. If you then turn your
engine off, your car, eventually, comes to a stop. THATS the difference. If
I accelerate my rocket by burning, lets say 200 kg of propellant, in space
(outside of the atmosphere, with no gravity producing bodies nearby), from
a standstill to 1,000 m/s, my speed will remain at 1000 m/s, theoretically,
forever. So how far can I travel on 200 kg of propellant? An infinite distance
(assuming I dont run into anything that exerts force on the vehicle)! So
there is no 1,000 miles/kg of propellant, or any other number related to a
distance that we can use to indicate efficiency of the engine. What exists is
velocity. With those 200 kg of propellant, I can accelerate my vessel by 1,000
m/s, and continue moving at that speed until I do another burn and change
it (or run into something else that changes it).
So in our example rocket, with 500 kg of propellant, if I double the amount

of propellant, 1,000 kg, and leave the single engine, I double my v, right?
Nope, wrong again. Again, its close, but not quite double (2719 m/s),
because at the start of the burn, the engine is pushing more mass (1,000 kg
of fuel now versus the 500 kg it was pushing before), so it does it more slowly
(while expending the same amount of fuel). So after I burn the first half
of my propellant (the first 500 kg), Ive only increased my velocity by 1,129
m/s. That second half of propellant (the original 500 kg) will give me the
same 1,590 m/s of v that it gave me before, which added to the 1,129 m/s
comes out to the 2,719 m/s total v for the vehicle (these calculations are
ignoring the mass of the tanks for simplicitys sake)!
Increasing the mass of propellant of the vehicle when you want more v
is a game of diminishing returns. Yes, more propellant gives you more v.
But every, lets say, 1,000 kg of propellant that you add to your total, gives
you less and less v.
2.3.3 TWR - Thrust to Weight Ratio
One of the bigger issues when building vehicles in the game is finding out if
you have enough engines/thrust to actually get your vehicle off the ground.
The first thing we need to understand is that TWR is calculated by dividing
the thrust of your vehicle by the weight of your vehicle. Both numbers should
be in Newtons (N). Typically, engines have their thrust rated in kN (1000
N), but for the weight we need to do the conversion from kg to N.
Contrary to popular belief, a kilogram (or a pound, for that matter) is

NOT a unit of weight. It is a unit of mass1 . Weight does not exist, unless
there is gravity. So the weight of an object is its mass multiplied by the force
of gravity by which it is being affected. On the surface of Kerbin, the force
of gravity is 9.81 m/s2 . 1,000 kg = 9,810 N on the surface of Kerbin.
The main indicator of whether a vehicle will take off or not is the TWR.
The TWR specifies a value, starting at 0, that indicates how much thrust
you have on your vehicle, compared to the weight of the vehicle. So if your
engines provide 220,000 Newtons of thrust (220 kN) and your vehicle weighs
1
Actually, while there are multiple variations on them out there, in the traditional
English system of units, a pound is the unit of weight/force (there being no notion of
a distinction between weight and mass when it was invented back in the day). The
corresponding unit of mass is the slug - a mass that accelerates by 1 fs2t when a force of
one pound is exerted upon it - Contributed by Alistair Y.
2.3. CONCEPTS 21
39,750 kg (389,948 N), youre not going anywhere. Your engines need to
provide more thrust than the weight of your vehicle to get off the ground.
Our example above has a TWR of 0.56 (220,000 N/389,948 N). The lesson
here is that we need a TWR greater than 1.0 if we want to get off the ground.
If you want to build this vehicle in the vehicle assembly building, its a Mk1
Cockpit, 2 Rockomax X200-32 Fuel Tanks (one on top of the other), and a
Rockomax Poodle Liquid Engine.
What the TWR is specifying is,

in reality, the amount of g-force that
the vehicle is capable of generating.
So if our vehicle is generating less g-
force than what is being exerted by
the planet it is sitting on, its not
taking off. On Kerbin, the force of
gravity is the same as on earth, 1 G,
or 9.81 m/s2 . If our vehicle cannot
overcome the force of gravity, it will
not lift off the launch pad.
If we modify our vehicle, by

adding more, or better, engines, to
have 650,000 N of thrust, our TWR
is now 1.61 (650,000 N/404,663 N).
I replaced the Poodle engine

Figure 2.1: Our non-flying vehicle with a Mainsail which weighs
slightly more. Since we only have to
overcome 1 G of surface gravity, this
tells us that the vehicle will ascend,
off the launch pad, at 0.61 G or 5.98 m/s2 .
But, there are a couple of things

that happen to a rocket as it
launches.
First off, as we discussed ear-

lier, the vehicle loses mass VERY
rapidly. As it loses mass, its weight
goes down, as its weight goes down,
its TWR goes UP !
Example: We start with our ve-

hicle that has 650,000 N of thrust
and weighs 404,663 N. Lets assume,
for this example, that the vehicle is
90,473 N of hardware and 313,920
N (32,000 kg) of fuel (remember
that the shuttle was only 5.8% shut-
tle and 94.2% launch hardware and
Figure 2.2: Our modified vehicle (that
fuel).
flies)
Our launch TWR is 1.61, so we

lift off the launch pad at 5.98 m/s2 .
At 1 minute into the flight, weve
burned 39.4% of our fuel: 123,665
N (12,606 kg). So at the 1 minute mark our vehicle now weighs 280,998
N (28,644 kg) but it still has the same thrust: 650,000 N. Our TWR at 1
minute is: 2.31, so we are now accelerating a 1.31 Gs (12.85 m/s2 ).
At the 2 minute mark, weve burned 75.2% of our fuel and our vehicle
now weighs 168,506 N (17,177 kg), giving us a TWR of 3.86, or 2.86 Gs of
acceleration (28.06 m/s2 ).
The vehicle runs out of fuel at the 2 minutes and 42 second mark. Right
before it runs out of fuel, it weighs 90,752 N (9,251 kg), giving us a TWR of
7.16, or 6.16 Gs of acceleration (60.43 m/s2 )
The second important thing about TWR that we need to understand is

that, according to Newtons Law of Universal Gravitation, masses attract
2.3. CONCEPTS 23
Figure 2.3: This chart shows the change in the TWR of your vehicle over time for
the example vehicle described above (a vehicle that consumes all of its fuel over
the course of a 2 minutes and 42 seconds burn)
each other and that the attraction is proportional to the product of the two
masses and inversely proportional to the square of the distance between them.
What does that mean to us? As our craft ascends from Kerbin, it loses
mass quickly, since gravity is proportional to the product of the two masses
(the planet Kerbin and our ship), the force of gravity reduces as the mass of
our ship reduces. We are also flying (at least for a part of our flight) straight
up, so we are increasing the distance between the two masses. Since the force
of gravity is inversely proportional to the square of the distance between the
two masses, it is reduced even more.
Right above the previous chart, we discussed what the TWR was at the
very end of our burn. We came up with the value of 7.16. I did this calculation
so that you would understand the relationship between the weight of the
vehicle and the TWR. But I slipped a white lie into those calculations. I was
calculating the weight of the vehicle in N by always multiplying the mass in
kg by the 9.81 m/s2 gravitational constant. In reality, the force of gravity is
changing as the vehicle ascends.
In our example, by the time the vehicle ran out of fuel, it was actually
packing a TWR of 9.45.
Figure 2.4: As the vehicle increases its altitude the force of gravity diminishes.
This graph shows the variation in gravity, by altitude, on Earth.)
2.3. CONCEPTS 25
To obtain information like v, Isp and TWR for your vehicles, you can
either do the math, or use one of the various mods that provide that type of
information.
As of this writing the most popular mods that provide this type of infor-
mation are: MechJeb and Kerbal Engineer Redux. More information about
these mods will be discussed in the chapter on Mods in a future volume.
2.3.4 Staging
As we saw above, mass is a big factor. The more mass we have to push with
our engines (for a given Isp), the less v we get out of our propellant. The
problem here is that, in our day-to-day lives, we are not used to thinking of
things in the scale necessary for astrodynamics.
In the Camaro example discussed, we carry 20 gallons of fuel that masses

55 kg. What we didnt mention was the mass of the fuel tank. I have no idea
how much a fuel tank for a Camaro would actually weigh, so lets say 10 kg.
Our Camaros mass, fueled, in total, is 1,775 kg. Of that total, 55 kg (fuel)
plus 10 kg (fuel tank) is for our propellant. Only 0.56% of our vehicle is fuel
tank (fuel itself, if you remember, was 3.1%).
If we want to give our Camaro greater range, we could add another fuel
tank (+10 kg) and fill it with gas (+55 kg). So we add an additional 65 kg of
propellant and hardware (the tank) bringing our total mass to 1,840 kg. This
way we extend the range of our vehicle, at the cost of increasing its mass.
That first tank of gas isnt going to get us as far as it used to because now it
is hauling the second, additional, tank of gas with it. And even after the first
tank is empty, the second tank will not take us as far as the single-tanked
version of our vehicle, because it is still hauling that extra 10 kg of empty
(first) tank with it.
Ideally, once the first tank is empty, we drop it on the road, giving the
second tank its full range (since after weve burned the fuel in the first tank,
and dropped the empty first tank, our Camaro now masses 1,775 kg again).
That is what staging is all about, getting rid of mass that is no longer
needed: empty fuel tanks, dead engines (i.e. engines that have no more
propellant to burn), contingency hardware (i.e. the Launch Escape System
that sat on top of the Apollo command module in the Saturn V launch
system), etc.
We tend to think Empty tank? Only 10 kg? Not worth the hardware
necessary to detach and jettison those 10 kg. . . , but that is car based think-
ing. In the shuttles case, the empty big orange tank has a mass of 26 tons.
Each one of the empty, solid-rocket boosters on the shuttle has a mass of 91
2.3. CONCEPTS 27
tons. Remember that the shuttle itself (no external tank or boosters) has a
mass of 110 tons. So the dead weight on the shuttle, after all propellant is
consumed, is 208 tons (26 tons + 91 tons + 91 tons). Almost TWICE the
mass of the orbiter itself!
The faster your vehicle sheds its dead mass, the more v you will get
from the engines and propellant that you still have, because there will be
less mass to push.
Your vehicle design can, theoretically, have as many stages as you see fit.
Just remember that each stage requires additional hardware (a decoupler or
a separator, at a minimum), which is more mass that you have to push. Also
remember that, at least in game, stage boundaries tend to be the weakest
structural points of your vessel. This means that you have to, typically, use
struts to strengthen the link so it can withstand the stresses of a launch and
maneuvers.
The shuttle is a 3 stage launch system:
1. At liftoff, all three main engines on the orbiter are burning (being fed
from the external tank) and the solid rocket boosters are also burning.
Once the SRBs have exhausted their propellant, they are jettisoned.
That is the first stage, the 2 minutes between ignition on the launch
pad and the decoupling of the SRBs.
2. During the second stage, the orbiter continues burning its main engines
using fuel from the external tank. At this point (2 minutes into the
flight), the external tank has only been 14 depleted. So the second stage
will last, approximately, another 6 minutes. At this point, the external
tank is empty, so we get rid of it. That is the second stage, the 6
minutes between SRB separation and external tank separation.
3. This is the final stage of the system and includes the orbiter alone.
Its main engines are still attached to the vehicle, however they are no
longer used in the mission. In the real world, it is not an economically
sound proposition to jettison 3 $40 million pieces of hardware that
would, presumably, be burned up and destroyed upon reentry. So the
shuttle hauls 10.5 tons (3.5 tons per engine) of hardware around space
and brings it back when it lands.
Fortunately for us, we dont have (yet) congressional oversight committees

or politicians breathing down our necks in Kerbal Space Program, so feel free
to drop your Mainsails in the ocean or leave them in a degrading orbit once
you no longer need them.
Just for completeness sake, Im going to mention here the shuttles Or-
bital Maneuvering System (OMS). Since once the orbiter is in orbit, it can
no longer use the main engines, it needs some type of engine to do orbital in-
jections, orbital corrections and deorbit burns. This is where the OM engines
come in. Fairly lightweight (100 kg) engines, that provide about 300 m/s
of v (it uses about 21.5 tons of propellant to provide that amount of v).
Bear in mind that this OM system is separate from the RCS system (that
we know and love so much in Kerbal Space Program) used by the shuttle.
We currently dont have OM engines/tanks in KSP.
The strangest part about doing staging is that, in Kerbal Space Program,
we have to build our vehicles from the top down. So if I were building a Saturn
V equivalent, I would start with the Command Module (the capsule), would
then add the Service Module, the third stage, the second stage and finally
the first stage.
The basics of staging are as follows:
To separate a stage, you should use a stack decoupler or a stack sep-

arator. A stack decoupler/separator is the type that was used in the
Saturn V. Once the first stage is depleted it separates from the rest of
the vehicle by dropping off of the stack above it.
In Kerbal Space Program, fuel from tanks above the stage bound-
ary (above the decoupler/separator) will not feed through the stage
boundary to engines below the decoupler/separator.
The various stack decouplers, and stack separators, have different de-
coupling forces. This means that they will push the separated stage
(the one being discarded), away from the rest of the vehicle, with a
certain force. In most cases, this force is negligible, since it is a small
force, typically, pushing a large piece of hardware. But in some cases,
people use stack decouplers to launch satellites from their main ve-
hicle and dont take that force into consideration and the satellite ends
up in an orbit different from what they expected.
2.3. CONCEPTS 29
It does not matter if you have struts crossing the stage boundary,
since the struts will automagically disappear when the stack decou-
pler/separator is triggered. You dont have to worry about things not
separating because they are strutted to other things. Obviously, this is
only true in Kerbal Space Program. In real life, things would not work
this way (actually they could, but it wouldnt be a simple strut).
If the part being separated (discarded) IS strutted across the stage
boundary, the decoupling force mentioned above, is affected by the
struts. Despite the fact that the struts DO break upon triggering
the decoupler/separator, it seems they absorb some of the force being
exerted by the decoupler/separator, resulting in the part being pushed
away from the vehicle with less force than if the part had NOT been
strutted. This is true for both stack decouplers/separators and radial
decouplers/separators (see below).
The difference between a stack decoupler and a stack separator is that
the decoupler only severs the connection on one side (the side that
the arrow, printed on the side of the decoupler, points to) and the
decoupler will remain attached to the part being discarded. A stack
separator, on the other hand, severs the connection on both sides. This
means that with a separator, you end up with one vehicle, one discarded
stage and a third part, the separator, floating freely around in space
on its own.
Radial Decouplers function just like stack decouplers, except they are
used radially (sideways/on the side). Think of the solid rocket booster
separation on the space shuttle: they are pushed off to the side as the
shuttle (and external tank) continues to move forward.
2.3.5 Attitude
From here on, you will start seeing the Attitude a lot. For those of you
familiar with the aerospace industry, this isnt a problem, but for those of
us that are not familiar with it, Im going to explain what is meant by
Attitude.
From the Merriam-Webster, attitude is defined as:

the position of an aircraft or spacecraft determined by the

relationship between its axes and a reference datum (such as the
horizon or a particular star)
So? Did that help?
Didnt think so. . .
Heres the problem: a spacecraft doesnt act like any other terrestrial
vehicle with which you might be familiar.
If you fire an engine in a spacecraft, that engine is going to push that

spacecraft in a particular direction. Once you turn the engine off, the space-
craft will continue to move in that direction, at the same speed (i.e. inertia),
unless something else influences that movement.
So. . . if you accelerate your spacecraft in a certain direction, and then

decide you want to stop moving in that direction, you have to turn around
and fire your engines again, to counteract the movement that you imparted
on the vehicle when you fired them the first time.
So its real easy for me to sit here and type turn around, but in space
how do you determine which way is forwards (and therefore, which ways
is backwards)? Compasses dont work. . . theres no north (magnetic or
otherwise). . . I guess you could use the stars for orientation, but what if the
particular celestial body you chose to use as guidance is no longer visible (on
the other side of the planet, for example)?
Thats what attitude is all about. . . rotating your vessel, using a myriad
of different actuators, so that it is pointing in the direction that you need to
point to execute whatever maneuver you want.
The two main methods of adjusting attitude are discussed a little further
below: RCS and SAS (or CMG, as it should really be called). Those are the
mechanisms that are used to change the attitude of you vessel, but how do
we figure out where we should be pointing?
The answer to that is the next section: Prograde/Retrograde. . .

2.3. CONCEPTS 31
2.3.6 Prograde/Retrograde
Prograde is nothing more than the current direction of travel for your vehicle.
There is no magic involved. There are actual sensors on real spacecraft that
can determine which direction your vehicle is moving.
In the game, the navball automatically shows you the information about
prograde and retrograde, but that information IS available on real spacecraft.
It might not be a pretty navball like the one we see in game (sometimes it
is), but its there.
But how does knowing what direction I am traveling help me in any way?
Everything in space is about motion. If you want to slow down, you

point in the direction opposite your direction of movement (retrograde) and
fire your engines. If you want to speed up, you point in the same direction
as your current direction of movement (prograde) and fire your engines. If
you want to change the inclination of your orbit, you point in a particular
direction, 90 from your current direction of movement, and fire your engines.
And so on. . .
But why would I want to do any of those things? Speed up? Slow down?
You just said if Im moving in a certain direction, Ill keep moving in that
direction, at that speed. So what difference does it make if Im going 1,000
mph or 2,000 mph? Or 500 mph?
Because as we will see when we get to the Orbital Mechanics part of this
book, how fast you are going (or not) determines exactly where you are, and
will stay (or not) in space. Remember what I said earlier, or even better,
lets look at Newtons first law of motion:
When viewed in an inertial reference frame, an object either

remains at rest or continues to move at a constant velocity, unless
acted upon by an external force.
One of the trickier words in there is velocity. We tend to think of veloc-

ity as speed, but velocity is in reality a vector quantity that represents
both speed and direction. We might apply a force to an object, like a space-
craft, that doesnt modify its speed, but modifies its direction, therefore we
ARE modifying its velocity.
But your question still is: Im not firing my engines, Im out in space,
so theres no external force acting upon my ship, so who cares?
Thats where you are wrong. There ARE external forces acting on your
ship. Dozens. . . hundreds. . . thousands of external forces acting on your ship
ALL THE TIME. Some to a great extent, some to a lesser extent.
Every single body, from the Sun and Jupiter, to the smallest of the aster-
oids, are all exerting a gravitational force on your ship. Even stars light-years
away are exerting, however minute, gravitational forces on your ship! Think
about it, it is gravity that maintains the solar system in its current configu-
ration, the same way that it is gravity that maintains the Milky Way galaxy
in its current configuration!
All those teeny, tiny little gravitational forces combine to affect your ship,
and every other body in the universe.
In most cases, we can ignore a lot of these forces, because of how small
they are. Typically, you are under the influence of a main body, which
exerts a significant portion of the forces being applied to your ship. In real
life we cant ignore ALL of the forces except the main one, but because
of limitations in the capability of your computer to process these hugely
complex calculations, in Kerbal Space Program, only ONE body ever exerts
force on your ship at a time.
But back to prograde/retrograde. . .
Knowing which direction you are moving (prograde) is EXTREMELY

important, because knowing that one direction, you can figure out all of the
other directions that you will need to know to perform any maneuver.
2.3. CONCEPTS 33
2.3.7 RCS - Reaction Control System
Now that we understand what attitude of the vehicle means, lets see what
we use to adjust attitude. There are two different systems to adjust attitude.
The first of these systems is the Reaction Control System.
Most liquid fueled engines, in real life, have very limited duty-cycles (how
many times they can be fired without requiring a rebuild/refurbishing).
For example, the space shuttle main engines, the 3 big ones on the back of
the shuttle, are refurbished after every flight. They light up, once, during
launch, and burn until their fuel is exhausted. They then return to Earth
with the shuttle and are refurbished before being fired again.
The shuttles OMS (Orbital Maneuvering System) engines, on the other

hand, are built to be fired multiple times between refurbishings.
An interesting scene to watch, in the movie Apollo 13, is the scene where
the astronauts are tasked with firing the lunar modules engine for a second
time for a course correction. The representative, on screen, of the manufac-
turer of the engine (Grumman, I think) makes a comment along the lines
of it wasnt built to do this! and the relief, after the successful firing is
clearly visible on his face! This is exactly because the engine was designed to
fire during the landing, and burn continuously until they reached the surface
of the moon and stay behind when the ascent engine was used to return to
orbit. It was never designed to be fired more than once.
RCS thrusters, on the other hand are designed to be fired hundreds (if
not thousands) of times, before needing to be rebuilt or refurbished. They
provide very small amounts of thrust, compared to the SSME or even the
OMS engines, but are more than sufficient to provide the necessary thrust for
various types of maneuvers. These maneuvers include, but are not limited
to:
attitude control during re-entry
station keeping (small maneuvers performed by orbiting craft to main-

tain its position in space since most orbits degrade slightly over long
periods of time)
docking maneuvers, that require multiple, very small, adjustments to

complete
orientation, pointing the vehicle in a specific direction
deorbiting, in extreme situations, if the craft has lost its ability to

deorbit due to a malfunction of the OMS engines or equivalent
In KSP, the RCS thrusters require a specific type of fuel, monopropellant,

that you must provide for in your craft design.
There are also two different types of RCS thrusters in game: the RCS
block, which is a multi-directional thruster that can provide comprehensive
maneuvering capability to a craft; and the Linear RCS thruster, which pro-
vides thrust in a single direction.
The placement of the RCS thrusters on your vehicle is of paramount

importance if you intend to do precise maneuvers such as docking. Also, if
your craft is very large, multiple banks of RCS thrusters might be necessary,
otherwise the craft will be sluggish to respond to your maneuvers (which
may be fine if you are the patient type). In the future I will go into more
detail regarding RCS positioning and usage within the game.
2.3.8 SAS - Stability Augmentation System
The actual definition of what is an SAS system is a system that uses devices
to STABILIZE the flight of a vehicle. The terminology in Kerbal Space
Program gets confusing when they talk about capsules, cockpits and probes
having SAS Torque. The SAS parts in Kerbal Space Program do indeed
stabilize the vehicle, but the torque provided by the capsules/probes is NOT
SAS torque. The torque generated by the capsules/probes is more aptly
described as CMG (Control Moment Gyroscope) torque.
SAS (Inline Advanced Stabilizer, Inline Reaction Wheel and Advanced

SAS) can be used on your vehicles to reduce the vehicles tendency to wan-
der during flight. Most rockets will have some tendency to pull to one
2.4. ORBITAL MECHANICS - THE MATHY PART 35
side, or to rotate along its axis, etc., unless it is perfectly symmetrical. Once
atmospheric drag is implemented in the game in a proper fashion, this ten-
dency will most likely increase since, even the positioning of a part, such as
a strut, will affect how the vehicle reacts to the atmosphere.
The dampening effect of an SAS unit can be increased by placing multiple

units on your vehicles.
Placement of the SAS units will determine how effective they are in damp-
ening any movement. An example of this would be a short, wide vehicle,
where a significant amount of mass is around the center of mass, and not
lined up with the center of thrust (i.e. asparagus staging). If you were to
place a single SAS unit along the center of thrust (i.e. on the nose of the
capsule), it would not be able to, efficiently, counter movement imparted by
the mass outside of the center of thrust. It will work, just not as well. A
solution in a case like this would be to place additional SAS units, in our
asparagus staging case, on top of each stack in the asparagus bunch.
2.4 Orbital Mechanics - The Mathy part
2.4.1 What is an Orbit?
An orbit is the gravitationally curved path of an object around a point

in space. This means that you are constantly falling toward that point in
space, but you never reach it because your horizontal velocity pushes you
away as you are falling.
An example: a spacecraft in orbit around the Earth. The craft is con-

stantly falling, however it is moving VERY fast horizontally, so as it falls
it misses the Earth, passing beyond the horizon and continues falling. It
is because of this falling that astronauts experience weightlessness. They
are not weightless, but in relation to the vehicle that they are in, they feel
weightless. They are, in reality, free falling around the planet.
When I say VERY fast above, I mean VERY FAST! Orbital velocity for
Earth, in a low Earth orbit (200 - 2,000 km altitude) is somewhere between
15,400 and 17,400 mph!
But what we are going to discuss here are some components of an orbit so
you can understand the terminology that you will see in game, on the wiki,
in the forums and other places where Kerbal Space Program is discussed.
Apsides
An apsis (plural: apsides) is the point of greatest or least distance of a body

from one of the foci of an elliptical orbit. In Kerbal Space Program, we are
acquainted with two of the apsides: periapsis and apoapsis. The reference
focus, in our situation, is always the body that we are orbiting.
2.4.2 Periapsis
The periapsis of your orbit is the point in the orbit at which you will be at
the least distance from the body you are orbiting. It is your closest approach
to the body being orbited.
When we discuss orbital maneuvers, you will see why it is important to

know where this point of your orbit is located. Certain orbital maneuvers
work especially well when performed at specific points in your orbit.
Another important use for the periapsis is that, since it is the lowest point
in your orbit, you can tell whether your orbit will degrade due to atmospheric
effects. If at the lowest point in your orbit you are still above the atmosphere
of the body you are orbiting (for Kerbin: 70km), then you know that your
orbit is stable since you will not encounter any atmospheric effects at any
point in your orbit. You could, theoretically, leave your craft in that orbit,
indefinitely, and it would never fall back to the body it is orbiting.
Obviously, the previous paragraph only applies to bodies that have atmo-
spheres. But even the bodies that dont have atmospheres have a minimum
periapsis of which you should be mindful. For example, on the Mun the
highest mountain peak is 3,340 meters; on Minmus, 5,725 meters; and on
Gilly, 6,400 meters. If you are establishing an orbit around any body, make
sure you verify the highest elevation of that planet/moon, unless you want
to plow into the face of a mountain.
All elevations, including the periapsis and apoapsis, in game are expressed
in relation to sea level of the reference body.
According to Keplers Second Law of Planetary Motion:
A line joining a planet and the Sun sweeps out equal areas
during equal intervals of time
If we substitute planet with vessel and Sun with orbited body,

the law still applies, since physical laws are not exclusive to stars and planets.
We now have:
A line joining a vessel and the orbited body sweeps out equal
areas during equal intervals of time
What this implies is that the vessels velocity is higher when it is closer
to the orbited body, hence lower when it is farther away. Since the periapsis
is the closest the vessel can come to the orbited body (in a given orbit), it is
also the point in the orbit where the vessel has its highest velocity.
In Kerbal Space Program, the periapsis of your orbit is indicated, while

in map view, by a little blue marker with a Pe inside of it. Below is a
picture of what that looks like:
If you hold your mouse over the Pe marker, it will show you the altitude
of your periapsis:
Additionally, if you click on the little marker, it will stay showing the
periapsis altitude even if you move your mouse elsewhere. It is kind of tricky
to click on the marker and not on the orbit at the same time, because when
you click on the orbit, you get the popup asking you if you want to Add
Maneuver.
2.4.3 Apoapsis
Similar to periapsis, above, the apoapsis defines the point, in your orbit,
where your vessel is at the greatest distance from the body begin orbited.
Also, as discussed about the periapsis, it is important to know where, on your
orbit, your apoapsis is located, because there are particular orbital maneuvers
that work especially well, when executed at this point.
According to Keplers Second Law of Planetary Motion, the apoapsis is

the point, in your orbit, where your vessel has the lowest velocity.
Just like the periapsis, the apoapsis is indicated, in map view, by a little
blue marker with Ap inside:
You can mouse over the marker like you can with the periapsis to see the
altitude:
And you can click on it, to keep the apoapsis display showing regardless
of whether you move the mouse or not.
Another detail, that I didnt mention in the periapsis explanation above,

is that below both of the markers, when they show you the altitude, they
also show you how much time until you reach the marker. This is important
because sometimes you need to plan a maneuver at exactly that point in
the orbit. This countdown tells you how long you have until you reach that
marker, so make sure to create the maneuver and leave sufficient time for
ship positioning and burn time before you actually hit the marker.
2.4.4 Semimajor Axis
The longest diameter, of an ellipse (and remember that orbits are, typically,
elliptical; a perfectly circular orbit is, for our purposes, considered an ellipse
with eccentricity of 0), is called the major axis. The shorter diameter is, as
you would expect, the minor axis (just for completeness sake). The sum of
your periapsis distance and your apoapsis distance is the major axis for your
orbit. The semimajor axis is half of that.
If you are in an orbit around Kerbin, and you have a periapsis of 281,969
meters and an apoapsis of 2,438,568 meters, the semimajor axis for your orbit
is 1,960,268 meters
(281,969+600,000)+(2,438,568+600,000)
2
(The 600,000 in the equation above is the radius of the planet Kerbin.
In calculating the semimajor axis, we count the distance to the center of the
body being orbited. Since periapsis and apoapsis are both given as an altitude
from sea level, we need to add the radius of the planet for our calculations.)
The closer your orbit is to a perfect circle, the closer the semimajor axis
will be to the radius of your orbit (in a perfect circle, the semimajor axis IS
the radius).
The semimajor axis is important to determine the orbital period of your

orbit (how long it takes for your vessel to complete one orbit).
The formula is:
v
u a3
u
T = 2 t

where:
a = the length of the semimajor axis of the orbit (in meters)
= the standard gravitational parameter of the body you are orbiting
When performing the calculation, if you are so inclined, remember to

use meters and not kilometers for the semimajor axis. The gravitational
parameter for the various bodies in the Kerbol System can be found in the
Kerbal Space Program Wiki. In the description of each body in the system,
you can find the gravitational parameter listed as shown in the screenshot
below:
In our example above, the orbit with a semimajor axis of 1,960,268 meters
(around Kerbin in this example), the orbital period would be: 9,176 seconds
(a little over 2 21 hours)
An important thing to understand from this is that any orbits that

have the same semimajor axis, have the same orbital period. In our ex-
ample we used a semimajor axis of 1,960,268 meters (Pe=281,969 meters,
Ap=2,438,568 meters), but any orbit that results in a semimajor axis of
1,960,268 meters (i.e. Pe=760,485 meters, Ap=760,051 meters) will have the
same orbital period of 2 21 hours.
Below is a picture of exactly the two orbits described above:

The blue orbit is almost perfectly circular, with a periapsis of 760,051

meters and an apoapsis of 760,485 meters. The gray orbit has a periapsis of
281,969 meters and an apoapsis of 2,438,568 meters and is visibly elliptical.
Both of these ships take the exact same time to complete one full orbit: the
2 21 hours I calculated above.
2.4.5 Eccentricity
Eccentricity of an orbit describes how elliptic an orbit is, compared to a

perfect circle. A perfectly circular orbit is an orbit where the vehicle is at a
constant reference altitude, in every point of its orbit.
Perfectly circular orbits are uncommon. Most orbits are, at least, slightly
elliptical in nature.
In Kerbal Space Program, Kerbin, and both of its moons, have perfectly
circular orbits (the former around the Sun, the latter around Kerbin itself).
Duna, on the other hand has an orbital eccentricity of 0.05. This indicates
that its orbit is slightly elliptical. Eeloo has an eccentricity of 0.26, which
means its orbit is much more elliptical than Dunas. If you use the map mode
in Kerbal Space Program and zoom WAY out, you will see how the shapes
of the orbits of the different planets vary.
In real life, the eccentricity varies from 0.00677 (for Venus) on the low
end, to 0.20563 (for Mercury) on the high end (for planets, not going into
the realm of dwarf planets, comets, asteroids, etc.).
In the last picture shown in Semimajor Axis above, I show two orbits.
The blue one is an (almost) perfect circle, therefore it has an eccentricity of
0. The grey orbit is visibly elliptical (what us common folk call an oval) and
has an eccentricity of 0.55.
2.4.6 Inclination
Inclination describes how inclined an orbit is. To have an inclination (an

angle in degrees), you need some type of reference point. In the case of
orbital inclinations, we use what is called the ecliptic plane.
Draw the Sun on a sheet of paper, then draw the Earths orbit around the
Sun. That gives you a roughly circular orbit. Now take that page and look at
it sideways, that is the ecliptic plane. So if another planet in the system has
an inclination of 60 degrees (very unusual, but useful for our understanding),
that means that if you were to draw its orbit on another sheet of paper, then
you would combine the two sheets at an angle of 60 degrees.
Most inclinations are given with relation to a specific body. In our solar
system, Earth is the reference body, therefore Earths orbit has an inclination
of zero degrees in relation to the ecliptic plane (since Earths orbit DEFINES
the ecliptic plane, it couldnt be any other way).
The planets of Earths solar system, do not all orbit on the same plane,
they have various different inclinations. The same is true of Kerbins solar
system. In Kerbins system, the planet that has the closest inclination to
Kerbins orbit is Duna, at 0.06 degrees.
Inclination is important because, when you are planning encounters, if the

target is on a different plane, then you have to correct for the inclination of
the target, otherwise you will pass the targets orbit with the target above
or below you.
This is a picture, from in game, of two vessels orbiting Kerbin. Both of

these vessels are orbiting at an altitude of 100,000 meters:
The orbit in blue is an equatorial orbit (it has an inclination of 0). The
other vessel (the grey orbit) is NOT in an equatorial orbit; its in an orbit
with an inclination of 25. But what does that mean exactly?
It helps to visualize the inclination by looking at the equatorial orbit on
its edge:
When looking at the equatorial orbit on its edge, it shows as a straight

line. As an extra bonus, this shot also shows the ecliptic plane. As you can
see, the other vessels orbit, when seen edge on, creates an angle between
itself and the ecliptic plane. That angle is 25, and that is why we say the
orbit has an inclination of 25. In our example above, we happen to also have
a vessel whose orbit is aligned with the ecliptic plane, but its the ecliptic
plane reference that defines the inclination angle.
2.4.7 LAN - Longitude of Ascending Node
When an orbit is inclined to the ecliptic plane (has an inclination different

than 0), there will be two points, in that orbit, where the orbit crosses the
ecliptic plane. At one of those points it will be below the ecliptic plane and
will be crossing the plane to above the ecliptic plane. It will be ascending.
So that point will be the ascending node, the other point (where its crossing
the ecliptic from above to below), is the descending node.
So whats this business with the longitude?
The orbit will cross the ecliptic plane at a specific point. Imagine that
you were looking out from the ship at this point, and looking straight down
at the planet you are orbiting. You would be looking at a specific point on
the planet (lets say, in the case of the Earth, you happened to be looking
down at Tokyo). Tokyos longitude is approximately 140 E. So the LAN
(longitude of ascending node) would be 140.
What this defines is the location of the periapsis and apoapsis of the orbit
in relation to the prime meridian (in our case, 140 is relative to the prime
meridian of the Earth).
The picture below shows an elliptical orbit (the same one from our pre-
vious topics), with an LAN of 0:
Notice how the periapsis is on the dark side of Kerbin. The same orbit,
below, with an LAN of 180:
Notice how, now, the periapsis is on the light side of Kerbin. The orbit is
rotated 180 in relation to the orbit that had an LAN of 0. All the other
parameters of the orbit remain the same: periapsis, apoapsis, semimajor axis,
eccentricity, inclination, etc.
With an orbit that is elliptical, we have two main points: the periapsis
and the apoapsis. The LAN defines, indirectly, where those two points are in
the orbit, in relation to a longitude system defined for the body it is orbiting.
Now you might say, but Mars (or Duna, for that matter) doesnt have
any defined longitude system!. Well, youre right, kinda.
We, humans, self-centered creatures that we are, defined OUR longitude

system in relation to the prime meridian. Over the millennia, the prime
meridian has varied in location (the place we call longitude 0), until finally,
in 1884, we as a species, decided we needed one standard. We elected the
Greenwich Meridian to be THE Prime Meridian and it has been ever since.
Even so, that is not the prime meridian that we use when defining the
LAN of orbits. The prime meridian for orbital parameters is called the origin
of longitude. For Earth-based LANs (and any heliocentric orbits) we use the
First Point of Aries.
The First Point of Aries has been the origin of longitude for a very long
time. It is still used as the origin even though, due to the precession of the
equinoxes, the point is no longer in the constellation of Aries.
For bodies outside of the Earth solar system, another prime meridian is
determined by a method WAY too complicated to explain here, and angles
are measured from that meridian. For our purposes, the LAN has a reference
meridian, in the Kerbol system, that is used to calculate the LAN.
For orbits that have an inclination of 0, the orbit never actually crosses
the reference plane (it is not inclined in reference to that plane, hence the
inclination of 0), it is established that the LAN is also placed at 0 longitude.
2.4.8 Argument of Periapsis ()
The argument of periapsis, typically symbolized by , is the angle between

the longitude of the ascending node and the periapsis of the orbit. Adding
the argument of periapsis to the longitude of the ascending node gives us
another parameter: the longitude of periapsis. However, in many circles the
terms longitude of periapsis and longitude of periastron are often used
as synonyms to argument of periapsis.
So it is a parameter, in the strict sense, but probably nothing that we
need to worry about in the game.
2.4.9 Mean Anomaly
The mean anomaly of an orbit is a parameter relating position and time for
a body in a Kepler orbit.
Keplers law stipulates that the line connecting the orbiting body to the
focus of its orbit sweeps equal areas in equal times during its orbit.
The mean anomaly can vary from 0 to 2 radians. But it is not an angle.
It is proportional to the area swept, by the line connecting the orbiting body
and the focus of the orbit, since the last periapsis.
It is kind of an indicator as to how far, past the periapsis, the orbiting
body is in its journey around the orbit.
Most of the parameters that we have seen up until this point have been
parameters that describe the orbit as a whole: how high it is at different
points (periapsis and apoapsis), how inclined it is in relation to the ecliptic
plane (the inclination), how oval or round it is (the eccentricity), where the
orbit crosses the plane when it is inclined (the longitude of ascending node)
and where the periapsis is in relation to the LAN (the argument of periapsis).
The one thing that we have not described until now is: Where is the
orbiting body, on this elliptic orbit that we so painstakingly defined, right
now? Thats what the mean anomaly does.
This concludes the section about orbital parameters. Below is a graph
that illustrates SOME of the concepts explained so far:
2.4.10 Orbital Stability
Ive mentioned stable orbits a couple of times so far. But what is a stable
orbit? A stable orbit is an orbit that will not degrade over long(ish) periods
of time. In real life, a stable orbit is very hard to achieve. There are just too
many factors that play into the stability of an orbit for it to be considered
100% stable.
The International Space Station (ISS), with an orbital periapsis of 330 km,
is still subjected to drag from Earths upper atmosphere. This drag causes
the station to slowly lose altitude, over time, which makes it necessary to
fire engines on the station to correct its altitude. But there are other factors
that contribute to the lack of orbital stability for any body orbiting another.
All of the bodies in the Solar System exert some influence, however
minute, on every other body. This means that even if the ISS was com-
pletely free of the atmosphere, the gravitational pull of the Moon, the Sun,
Jupiter, and even tiny little Mercury are all influencing its orbit.
By far, the Earth, being the body that is closest to the ISS AND the
body around which the ISS revolves, has the greatest influence on the ISSs
orbit. But its orbit will change, very slightly, over long periods of time, due
to these other influences.
But enough about real-life, its depressing.
In Kerbal Space Program, things arent quite like that. This whole busi-
ness of calculating all the little, teeny tiny influences of multiple bodies upon
each other is what is known, in the astrophysics community, as the n-body
problem. There is no exact solution to the n-body problem for n 2. For
any system, that needs to be analyzed, that contains more than 2 bodies,
the best we can do is an approximation, and even that takes A LOT of work.
Much more than our measly little desktop computers are capable of in any
realistic timeframe that would make the game still playable.
So, we are limited, by the physics engine used in the game, to 2 bodies.
So if a ship is orbiting Kerbin, Kerbin is one body and the ship is the other.
The games physics engine doesnt take into consideration any other bodies
within the system that might be influencing the ships orbit. This makes
orbits that we establish, in game, more stable than they would be otherwise.
So in game we dont have to worry about all the other bodies in the system
influencing our vessels orbits.
This however, has some drawbacks. To be able to have transfers from

one body (i.e. Kerbin) to another body (i.e. the Mun), at some point the
system has to stop considering Kerbin our first body and switch over to the
Mun (our ship is the second body in both cases). This is resolved by what is
called Spheres of Influence (usually abbreviated as SOI or SoI). Kerbin has
a specific SOI that extends from Kerbins surface to a specific height. Every
other body in the system, similarly, have their own SOIs defined. Once your
vessel leaves Kerbins SOI it is shifted to another SOI. If your ship is not
near enough to another body, to be within that bodys SOI, then the SOI of
Kerbol (the games Sun) is used.
Below is a screenshot of a typical Mun transfer:
In this picture, the blue orbit is your orbit, within Kerbins SOI, the little
circle at the point where the blue transitions to the yellowish line is what is
called a Mun encounter. Once we cross that point in the orbit, we are no
longer within Kerbins SOI, we are then in the Muns SOI.
The yellow orbit, further along, transitions to the purple orbit, the little
circle on the threshold identifies it as Mun Escape. This means that left to
its own devices, the ship will transition into the Muns SOI and continue on
until it leaves the Muns SOI and transitions back, in this particular case, to
Kerbins SOI. If I let it go even further along this trajectory, it exits Kerbins
SOI and transitions to Kerbols (the Suns) SOI and establishes itself in an
orbit very similar to Kerbins own orbit around the Sun.
These spheres of influence are what allow the games physics engine to
resolve the 2 body problem. Any given vessel is only, ever, in one sphere of
influence at any given time.
But the 2 body physics limitation also causes a problem with. . .
2.4.11 Lagrange Points
Lagrange points are, in astrophysics, defined points, near two bodies, where
a 3rd body (and herein lies the problem) can maintain a consistent position.
The calculations of these points requires some intense mathematics that the
games physics engine is not capable of executing within a timeframe that
would make the game playable.
Essentially, a body can position itself at one of these Lagrange points

(there are five) and remain in a constant position, in relation to the other
two bodies.
This graph indicates the position of the Lagrange points in the Earth-Sun
system:
At L1, the body is stable. The pull from the Suns gravity, and the pull
from Earths gravity, drag the body around the Sun in the same exact
amount of time as the Earth takes to orbit the Sun (which is odd, as well
see in a bit). L1 is the most intuitive of the Lagrange points: it makes
sense; the body is being wrestled by the other two bodies gravitational
forces, therefore doesnt quite react as it should.
The other four Lagrange point are less intuitive, but they exist nonethe-
less. Any object placed at those points, will remain in that exact same,
relative spot (not so much a spot, in the case of L4 and L5, as an area).
But why should they react any differently?

2.4.12 Altitude vs. Velocity
In any orbit, the semimajor axis (so indirectly, the periapsis and the apoapsis)
defines the orbital period.
An orbit with a semimajor axis of X has an orbital period smaller than an

orbit with a semimajor axis of 2X. Im not going to go into the mathematics
and give you numbers, just accept that it is true. Crunch the numbers if you
dont believe me.
If I am orbiting Kerbin at 100 km, I am moving faster than another ship

that is orbiting Kerbin at 200 km. If the ship at 200 km takes X amount of
time to complete one full orbit, my ship will complete one full orbit in some
fraction of X amount of time. So for every orbit that the 200 km ship makes
I make more than one orbit at 100 km. Effectively, Im pulling ahead of
the other ship.
If I were to raise my orbit to 300 km, then I would be the one moving
slower than the one at 200 km and it would pull ahead of me (or catch up,
if it were already behind).
The further the ships are from the center of mass they are orbiting, the
slower they move to maintain that orbit (Im assuming all circular orbits
here, just for sanitys sake).
We discussed the same concept when we were discussing periapsis and

eccentricity. As I approach my periapsis (in a non-circular orbit), I gain
velocity (because Im closer to the planet). When I reach my periapsis, I am
at the closest point I will ever be to the planet, so I am also as fast as
Im going to get in this orbit. As I pass the periapsis and head toward the
apoapsis (gradually getting further from the planet), my velocity decreases
until I reach the apoapsis (furthest point, lowest velocity) and start heading
back to the periapsis again to begin the next cycle.
This is what is odd about bodies at Lagrange points. If a body is at

the L1 point, it is, by definition, closer to the Sun than the Earth is, so it
should be moving faster than the Earth, pulling ahead of the Earth in its
orbit. However, it doesnt. Because of the interaction between the Suns
gravity and the Earths gravity, the body moves as fast as the Earth does
around the Sun, effectively maintaining its position with relation to both the
Sun and the Earth.
I think this information might come in handy later, in something called

rendezvous, so keep it in a safe place.
2.4.13 Oberth Effect
As we learned in high school physics, objects in motion have kinetic energy.

Kinetic energy is best described as the energy the object gained by being
accelerated to its current speed.
The Oberth Effect, after Austro-Hungarian-born physicist Hermann Oberth,

describes how a vehicle employs its kinetic energy to generate more mechan-
ical power, resulting in more usable energy, by the application of an impulse,
usually provided by a rocket engine, while in close proximity to a gravita-
tional body.
If we skip all the math and get right down to the meat of the matter,
what this means to us, in Kerbal Space Program, is that:
The same amount of thrust expended (v), at a given point in our orbit
will result in a final velocity (at distance) to be much larger than expected,
depending on where in that orbit the burn occurs.
In a previous section, I mentioned that knowing where the periapsis and

the apoapsis of your orbit is important, because certain maneuvers work
especially well when executed at exactly those points. The Oberth maneuver
is one of those maneuvers that works especially well when executed at the
periapsis of your orbit.
Imagine an elliptical orbit around Kerbin, with a periapsis of 100,000

meters and an apoapsis of 300,000 meters.
Your vehicle is moving its fastest when it is at the periapsis and its slowest
when at the apoapsis. Those speeds, for this orbit are: at your periapsis you
are moving at 2,383 m/s. At your apoapsis, you will be moving at 1,853
m/s.
If we now create a maneuver, at our periapsis, where we expend 100 m/s

of v, this is what our maneuver would look like:
Our apoapsis was raised to 498,000 meters (an increase of 200,000 meters),
and our periapsis remains the same. The velocities at both points are now:
2,483 m/s at the periapsis (what it was + 100 m/s), but our velocity at the
apoapsis has changed to 1,581 m/s.
If we do the maneuver, the same 100 m/s increase, at the apoapsis, the
maneuver looks like this:
In this case, our apoapsis remains the same, and our periapsis increases
to 251,000 meters (an increase of 150,000 meters). The velocities at both
points are: 1,953 m/s at the apoapsis (what it was + 100 m/s), but our
velocity at the periapsis is now 2,066 m/s.
In the first case, we increased the semimajor axis of our orbit by 100,000
meters, but in the second case, we only increased it by 75,000 meters. Since
the specific orbital energy is dependent on the semimajor axis of your orbit,
the specific orbital energy, after the burn, was higher in the first case (burning
at periapsis) than in the second, even though the total amount of v, and
fuel, expended was the same.
The reason for the gain in energy is as follows: When the rocket expels
propellant, that propellant is expelled at a specific velocity. When compared
with the velocity of the vehicle that is expelling the propellant, part of the
energy expelled is lost in the mass that is expelled but part of it is kept by the
vehicle. Example: If the velocity of your vehicle is 1,000 m/s, and propellant
1
is expelled at 2,000 m/s, then your vehicle might retain 10 of the energy of
the propellant, the remaining 90% of the energy is lost with the propellant
(not lost, but stays with the propellant expelled). If the velocity of your
vehicle is 5,000 m/s and propellant is expelled at the same 2,000 m/s, your
vehicle might retain 40% of the energy of the propellant, only leaving the
propellant 60% of the original energy.
The bottom line is that it is more efficient, energy-wise, for you to do

burns of this type around your periapsis than it is anywhere else in your
orbit.
Chapter 3
The Navball
This is your Kerbal Space Program Navball:
63
64 CHAPTER 3. THE NAVBALL
Right off the bat, couple of things:
If you want to hide the navball, click on the little black arrow (right
above where it says Orbit in the above picture), or press the .
(period) key ON THE NUMERIC KEYPAD.
If its not showing (like the default in map mode), same thing, either
click on the little black arrow at the bottom of the screen, or press the
. (period) key on the numeric keypad.
The navball shows you, at different times, certain characteristics of your

vehicle that are important:
which direction your vehicle is pointing;
which direction your vehicle is moving;
which direction your target is located;
how much you have to fire your engines to accomplish a maneuver;
which direction you should fire your engines for a maneuver;
how much throttle you are currently using;
what mode the navball is in;
etc.
Im going to explain each indicator on the navball separately. Where they

are related to another indicator I will mention that.
The first thing we have to understand about the navball, is that it works
in different modes. In the picture above, our navball is showing Orbit:
and 335.6m/s. This indicates that our orbital velocity is currently, 335.6
m/s. We can click on the word Orbit: and it will change to Surface: and,
probably, show a different speed. The speed shown when in Surface mode
3.1. NAVBALL INDICATORS 65
is the speed in relation to the surface of the body we are orbiting, launching
from or landing on.
Additionally, if you have a target selected, and click on Surface on the

navball, it will switch to Target and show another speed. The speed shown
is the relative velocity between your vehicle and the target (how fast you are
moving towards, or away from, your target).
So, we basically have three modes that the navball can operate in: well
call these Orbit mode, Surface mode and Target mode, hopefully,
consistently, throughout the book.
3.1 Navball Indicators
3.1.1 Prograde
In Orbit mode, the prograde indicator tells you which direction you
should point if you want to be facing the exact direction that your
vehicle is moving. If you want to increase your orbital velocity,
point prograde, in Orbit mode, and thrust in that direction.
In Surface mode, the prograde indicator tells you which direction you
should point if you want to be facing the direction that your vehicle is moving
relative to the surface of the body you are orbiting/launching/landing. If you
want to increase your surface velocity, point toward the prograde marker, in
Surface mode, and thrust in that direction.
In Target mode, the prograde indicator tells you which direction you
should point if you want to be facing the direction that your vehicle is moving
relative to your target. If you want to increase the relative velocity between
your vehicle and your target, point toward the prograde marker, in Target
mode, and thrust in that direction.
3.1.2 Retrograde
In Orbit mode, the retrograde indicator tells you which direction

you should point if you want to be facing the direction exactly op-
posite of that which your vehicle is moving. If you want to decrease
your orbital velocity, point retrograde, in Orbit mode, and thrust
in that direction.
In Surface mode, the retrograde indicator tells you which direction you
should point if you want to be facing the direction exactly opposite of that
which your vehicle is moving relative to the surface of the body you are
orbiting/launching/landing. If you want to decrease your surface velocity,
point toward the retrograde marker, in Surface mode, and thrust in that
direction.
In Target mode, the retrograde indicator tells you which direction you
should point if you want to be facing the direction exactly opposite of that
which your vehicle is moving relative to your target. If you want to decrease
the relative velocity between your vehicle and your target, point toward the
retrograde marker, in Target mode, and thrust in that direction. This ma-
neuver is commonly referred to as canceling or zeroing your speed relative to
the target.
3.1.3 Target Prograde
This indicator is, in my opinion, erroneously called the Target Pro-

grade indicator. I dont like that nomenclature because it alludes
to the fact that this indicates the prograde direction that your tar-
get is moving. That is NOT the case. What this indicates is what
vector you have to follow to get to your target. It indicates where
your target is in relation to your ship. If you accelerate directly towards
your target by pointing at this indicator and engaging your engines, it will,
indeed, become your target prograde indicator, but not quite.
Basically, this is the direction that you want to point your ship if you
want to go towards your target. It is only HALF of the puzzle you will need
to solve to do a rendezvous with a target.
Obviously, this indicator will only show up on your navball if you have a
target selected.
3.1.4 Target Retrograde
This indicator is also, in my opinion, erroneously called the Target

Retrograde indicator. I dont like that nomenclature because, like
its brother, it alludes to the fact that this indicates the retrograde
direction that your target is moving. That is NOT the case. What
this indicates is what vector you would have to follow to move away
from your target.
Basically, this is opposite the direction that you would point your ship if
you wanted to go towards your target.
Obviously, this indicator will only show up on your navball if you have a
target selected.
Note that pro and retro are directions that are 180 from each other.
Prograde is opposite (180) from retrograde. Target prograde is opposite
(180) from target retrograde.
3.1.5 Maneuver Node
This indicator tells you which direction to point your vehicle to

execute the maneuver that you have created. You create maneuvers
in the map screen and once you have adjusted the maneuver to your
liking, this is the indicator that you should follow when executing
the burn.
Please note that when you create a maneuver node, this indicator shows
up immediately on your navball, but you should only execute the maneuver
once the correct time arrives.
If you do not currently have a maneuver established, then this indicator

does not show up on the navball. If you have multiple maneuvers planned,
then this indicator is for the next maneuver.
3.1.6 Level Indicator
This is the last indicator that shows up inside the navball. It indi-
cates where the nose of your vehicle is pointing. Note that this
indicator does not move. As you change the attitude of your ve-
hicle, the navball rotates underneath the level indicator to display
your current attitude.
3.1.7 Other Navball Indicators
There are a few more items that we need to discuss on the navball and then
we will discuss maneuvers.
Below the artificial horizon (the blue/brown bally part of

your navball), is your heading: HDG. Your heading is indicated
in degrees and is counted, clockwise, from whatever is considered
North on the navball (indicated by the solid red line going up
and down the navball, assuming you are level).
On the left side of the navball (between 6:30 and 10 oclock,

if the navball were a clock face) is your throttle indicator. It has
a little white arrow indicator that tells you where your throttle is
positioned. The very bottom of the scale, your engines are off, the
very top of the scale, your engines are at full thrust. The scale also
has a red area that currently is not used by the game. Im assuming
that this will be used in the future when it is possible to throttle
your engines over their rated thrust.
On the right side of the navball, similar to the throttle indicator

on the left, is the G-force meter. This meter indicates how many
Gs of force your craft is undergoing. This indicator, in the real world, is used
to assess the stress being imposed upon the vehicle and the occupants.
Notice that the G force scale starts at -5 Gs and goes all the
way up to 15 Gs. The danger zone starts at 9 Gs (the red area
on the dial) and should be avoided whenever possible.
G forces must be kept within tolerable levels both for the air-
frame and for the crew. Excessive G force on the airframe can cause
rapid unplanned disassembly and excessive G forces on the crew can
cause everything from lightheadedness and loss of consciousness to
death.
In Kerbal Space Program, G forces are not taken into consid-

eration (yet) in the stock game. I believe there are mods in the community
that implement some excessive G force consequences.
On the left side of the navball, right above the throttle indicator,
is the RCS indicator. This is simply an on/off indicator to tell you
whether RCS is turned on or not. If it is lit up green and says
RCS, then your RCS is on. If it is black, RCS is off. To turn
RCS on or off, press the r key (default key).
On the right side of the navball, right above the G force meter,
is the SAS indicator. Like the RCS indicator, it is simply an on/off
indicator to tell you whether SAS is turned on or not. If it is lit up
white, and says SAS, then your SAS is on. If it is black, SAS is
off. To turn SAS on or off, press the t key (default key).
These are all of the characteristics of the navball itself. Lets talk about
navigating with the navball.
3.1.8 Using the Navball To Change Your Attitude
or What is all this talk about prograde and retrograde?
First lets clarify what attitude is. Ive mentioned it a few times before so I
want to make sure we understand what I mean. The attitude of an aircraft (or a
spacecraft) is the orientation of that craft relative to its direction of travel.
In space (and even in the air), you can turn completely around from your di-
rection of travel and still continue in that direction of travel, rear-first indefinitely
(not indefinitely in the air, obviously). You can turn your vessel up, down, side-
ways, in any direction that you want and your direction of travel (or speed, for
that matter) is not changed at all, until you fire your engines. This is unfamiliar
ground for people only exposed to terrestrial modes of transportation and therein
lies the problem.
In astrodynamics we use the attitude to describe the orientation of the vessel

in relation to its direction of travel. So if I launch a rocket in a straight line at
the Moon (lets assume that both the Earth and Moon are stationary objects for
this example) and Im going 1,000 m/s. If the nose of my rocket is still pointing
at the Moon, we say that the rocket is pointing prograde. So if I were to tell
you point prograde, that means point your rocket in the exact direction that it
is moving, in our example, straight at the Moon.
If I were to tell you point retrograde, that means point your rocket in the
direction exactly opposite of the direction that you are moving (i.e. point the tail
of your rocket in the exact direction you are moving), in our example, straight
back at the Earth.
The main reason why these two directions are important is that in space there
are no other reference points to which you can really point. I cant say stuff like
turn 15 north-northeast once you pass the mountain range because north-
northeast has no meaning in space, nor are there any mountains up there (unless
you count the asteroids).
We need some reference points to plan maneuvers. Prograde and retrograde

are two of them. Radial and anti-radial are another two, normal and anti-normal
are another two.
Youre thinking Oh crap! What is that all about?. Simple.
Youre in another ship, orbiting Earth (or Kerbin, it doesnt matter), counter-
clockwise (as seen from the North pole), at a constant altitude, lets say 1,000 km,
traveling at a constant speed. Your orbit is (unnaturally) perfectly circular.
Your ship is pointing straight in the direction that it is moving. You are
standing in the cockpit, looking out the windshield, straight ahead. Your head
is pointed in the same direction as the planets North pole, and your feet are
pointing in the same direction as the planets South pole.
Where you are looking is prograde.
Right behind your head (180 from prograde) is retrograde.
Straight up, from the top of your head in the direction of the ceiling, is normal.
From the bottom of your feet, straight down (180 from normal), is anti-normal.
Now raise both of your arms straight out from your body (like a +).
Where your left hand is pointing, straight at the center of the planet you are
orbiting, is radial (or radial in).
Where your right hand is pointing, away from the center of the planet you are
orbiting (180 from radial), is anti-radial or (radial out).
If I now need to give you directions like point 30 anti-radial from prograde
and 15 normal from prograde, you know that, assuming you where pointing
straight at prograde to start, that you have to rotate your ship 30 to the right
and 15 up. My entire direction system is now based on prograde, since knowing
that, I can derive all the other 5 cardinal points.
Even if your ship is rotated 180 on its long axis and you are, from an external
observers point of view (your head is now pointing in the direction of the planets
South pole), standing on the ceiling, you know that normal is above your head
only if your left arm is pointing radial in. If youre upside down like I said, your
left arm will be pointing away from the planet (radial out) and your head will be
pointing anti-normal, so you know that the directions I just gave you should now
be: 30 to the left and 15 down from your frame of reference.
So lets take a look at the first picture in this article again:

Right above the HDG indicator at the bottom, you see a little vertical yellow
line. Thats the very tip of the prograde indicator. If your ships attitude were
the one pictured here, and I told you turn prograde, what would you do on your
keyboard/joystick to get there?
You would press the w key to push the nose of your vessel (shown by the
fixed level indicator in the middle of the navball) down towards the prograde
vector which is below your nose in this picture.
You can also think of the w key as being up, as in the direction I want the
navball to rotate. So the level indicator stays put (it never moves), the navball
rotates up (the line that divides the blue from the brown in the navball, moves
vertically up your screen), bringing the prograde indicator with it, until it is lined
up with the nose of my vessel.
It depends on how you see things. The pushing up/forward means nose down
paradigm comes from aviation (from where most astronauts were recruited) where
to push the nose of a plane down, you push the control yoke forward. Im not here
to say whether one interpretation or the other is right, there is no right, its
anti-radial, remember? Its all a matter of interpretation and whatever works for
you is the best.
I only explain this here because throughout this book I will say (and have
already said, above) up and down. When I say up I mean press the s
key to move your nose up; when I say down I mean press the w key to move
your nose down. I want to avoid the confusion of you said down, so I pressed
s even though s is below w on the keyboard, s is up, w is down.
Thats what works for me, so thats how I use them. If you understand them the
opposite, thats great, it works for you, but then you have to translate what I say
into your terminology.
Now that we understand the basic directions involved in maneuvering in

space our next section will cover maneuver nodes.
3.1.9 Maneuver Nodes
To create a maneuver node, you have to switch to map view ( m key). If you now
click anywhere on your orbit (the blue line in map mode), a popup will appear
with a button Add Maneuver. If you click on that button, a maneuver node
is created. When created, the maneuver node doesnt do anything, its just a
placeholder. When you start playing with the little handles (6 of them, attached
to the maneuver node along the 6 different cardinal directions we just discussed)
the maneuver node starts to have meaning.
One of the golden rules of orbital maneuvers is this: any change you make
to your orbit, affects the opposite side of your orbit. Example: If I speed up,
by thrusting prograde, at my apoapsis, I raise my periapsis. If I thrust prograde
at my periapsis, I raise my apoapsis. Similarly, if I slow down, by thrusting
retrograde, at my apoapsis, I lower my periapsis. If I thrust retrograde at my
periapsis, I lower my apoapsis.
So a very common orbital maneuver, that we will discuss in more detail later, is
circularization. Typically, when you launch a craft, youre launching it upwards
from the planet. Im not going to say straight up, because thats a bad idea, but
it is in a generally upwards direction.
If you look in map mode, as youre launching, you will see a parabola forming.
The very top of your parabola, your highest point, is your apoapsis, and should
have a little blue Ap indicator on it. What that parabola is showing you is
that, if you leave your ship on its current trajectory, it will, eventually fall back to
Kerbin. We have an apoapsis in our trajectory, but no periapsis. Actually there
IS a periapsis, its ZERO, so the game doesnt show it. But its there.
If I want to get into orbit, I need to make both my apoapsis and my periapsis
higher than 70,000 meters (for a Low Kerbin Orbit). Lets assume my apoapsis
is at 80,000 meters already, my engines are turned off and my current altitude is
50,000 meters. Im essentially coasting towards my apoapsis. What do I do to
get into orbit? What am I trying to accomplish?
Low Kerbin Orbit is a trajectory where both apoapsis and periapsis is above
70,000 meters.
Ok. . . checklist time:
Apoapsis above 70,000 meters: check
Periapsis above 70,000 meters: not so much
But wait a minute, didnt we just talk about raising periapsis? Oh yeah. . . If
I speed up, by thrusting prograde, at my apoapsis, I raise my periapsis. Lets
do that. . .
I line my ship up, pointing prograde. Wait for the apoapsis, and fire my engines.
Nothing seems to happen initially, but my orbits getting wider. No, wait! A
periapsis just showed up on the other side of the planet. 5,000 meters. . . 10,000
meters. . . 50,000 meters. . . 80,000 meters! Quick, shut down the engine ( x key).
My orbit is now circularized (hopefully its roughly circular). Thats called
winging it.
Lets try that in a less stressful, more planned, way.
Were back at 50,000 meters. Apoapsis is at 80,000 meters. Engines are off.
Were coasting towards our apoapsis.
In map mode. Create a maneuver node AT your apoapsis:
Click on the little blue Ap indicator (notice the little blue dot on the orbit
near the apopasis indicator)
and select Add Maneuver.

This creates a maneuver node

Now what we did before was to thrust prograde, so were going to plan this
maneuver in the same fashion.
So grab the little prograde marker on the maneuver node (it looks the same
as the prograde marker on the navball) and pull it slowly away from the center of
the maneuver node. An orange-ish line appears on the map. Thats the new orbit
you will have, if you execute the maneuver node. Theres also an orange-ish Ap
and Pe indicator that tells you what your apoapsis and periapsis will be in this
new orbit.
If your periapsis isnt high enough (or hasnt shown up at all yet), keep stretch-
ing that prograde marker handle. The process here is: adjust maneuver by drag-
ging prograde handle; release mouse; mouse over (orange) periapsis to see height;
and keep doing that until the periapsis is high enough. Made it too high? Ad-
just maneuver by dragging retrograde handle; release mouse; mouse over (orange)
periapsis to see height; and keep doing that until the periapsis is where you want
it.
Once youve adjusted your maneuver properly, you should have a roughly circu-
lar orange-ish orbit around Kerbin with both an apoapsis and periapsis of, roughly,
80,000 meters.
Lets check out our apoapsis and periapsis for the new orbit:
Not perfect, but close enough. Both apoapsis and periapsis are out of the
atmosphere.
So lets switch back out of map mode. Press m again.
Theres something new here now. Some kind of meter along the right side of
the navball that wasnt there before. That meter tells you how much thrust is
required to complete the maneuver the way you set it up. So it will say something
like 1128.2 m/s.
Below the meter is an estimated burn time, Est. Burn, that indicates, based
on the capacity of your engines, how long the computer thinks it will take, at full
thrust, to generate that 1128.2 m/s worth of thrust, in our case, 47 s.
Below the estimated burn time is another line of text that says: Node in T-
48s and is counting down. What this indicates is that you are 48 seconds away
from reaching the maneuver node you created.
Now we have a maneuver node all set up the way we want it. Lets execute
that maneuver.
3.1.10 Executing Maneuvers
The orbit that you saw in map mode:

is calculated as if the maneuver were executed in an instant. This means that

for your orbit to end up exactly as projected, you would have to change your
velocity by 1,128.s m/s instantly, the moment you hit the node. Since that is
physically impossible, because your engines dont work that way, it is an estimate.
Since it is an estimate, were going to do our best to estimate how to execute

the maneuver as well.
Remember that any change you make in your orbit, affects the opposite side of
your orbit (i.e. burning prograde at apoapsis, raises your periapsis and vice-versa).
Therefore we are executing our burn at our apoapsis (to raise our periapsis from
zero, in this case). But if my burn is going to take 47 seconds and I start it exactly
at the node, per the countdown clock, I will be executing the burn, effectively,
AFTER having passed my apoapsis.
A good rule of thumb, to execute a burn, is to split the burn evenly around
your node. So if the burn is 47 seconds, cut that in half, 23.5 seconds, and start
executing the burn 23.5 seconds BEFORE hitting the node; and continue burning
an additional 23.5 seconds, after the node. That way the error in your maneuver
is distributed evenly at both sides of the node.
This technique does not work very efficiently if your burn time is very long
(i.e. more than a minute). This is because the longer the burn, the more off the
prediction of the resulting orbit is going to be (because the prediction assumes 0
seconds of burn time for the maneuver).
An even better approach is to execute the maneuver in steps. In this particular

case, we cannot execute the maneuver in steps. Because this is a circularization
maneuver, you dont have the luxury of executing a smaller maneuver now, and
executing another small maneuver on your next orbit. There will be no next orbit
unless you circularize your orbit.
An example of a maneuver that can be executed in steps is one where you wish
to change your inclination by 90. Lets assume that you are in a circular orbit, at
80,000 meters.
The v for a 90 inclination change is enormous. 3,188 m/s. The estimated

burn time is 1 minute and 56 seconds. A burn that long will result in your orbit not
being even remotely close to the target you set, because the burn will be executed
almost 1 minute before the node and last until about 1 minute after the node.
In a case like this, you would be better off executing a smaller inclination
change, for example, 20; on your next orbit, execute another 20 inclination
change; and so on until you have achieved the desired orbit. Please note that
doing it this way does not make the maneuver cheaper in any way. You will still
expend the same 3,188 m/s of v to make the full 90 inclination change, but you
will have more control over the resulting final orbit by doing it in steps. In fact,
the multiple maneuvers might cost you a little more in terms of v, because of
the inevitable errors in piloting.
But enough about the economics of maneuvers. . .
To execute any maneuver, you want to adjust the attitude of your vehicle, to
point to the maneuver node indicator on the navball.
Once you are pointing directly at the maneuver node indicator, you should
wait until the appropriate time to start your maneuver. The discussion above, on
when to execute a maneuver, is simply a suggestion that I follow when executing
maneuvers. You are free to execute the maneuvers in the fashion that you see
best.
As you fire your engines, you will notice the v meter on the right side of the
navball start to decrease. Once it reaches 0, you should stop your engines. Also
note that during the maneuver, you should try to keep your vessel pointed in the
right direction, towards the maneuver node indicator.
If you go off course slightly, you do not have to worry, because both the
maneuver node indicator and the v meter are recalculated, in real time, as you
execute the maneuver. The system does its best to make sure that, when you
are done executing the maneuver, you end up with an orbit as close as possible to
what was projected when you created the maneuver node.
A tip for executing maneuvers: As you approach the end of your burn (when
the v meter is almost empty), you might want to throttle down your engines
slowly. That way you have more control over the cut off, as close to zero as possible,
for your maneuver. If you have a very powerful engine, or set of engines, it will eat
through the required v pretty fast, and that will make it harder for your to cut
the engines at the appropriate time, most likely overshooting your maneuver.
Just remember that the burn time was calculated at full thrust, so if you
throttle back the end of the burn, it is going to take longer, so take that into
consideration when splitting your burn around the node. Give yourself an extra
few seconds of total burn time for a controlled shut down of your engines.
Now that were experts in maneuvers, lets start discussing the different
types of maneuvers that are typically executed in game.
Chapter 4
Orbital Maneuvers
4.1 Gravity Turn
A gravity turn is a maneuver that is used to optimize the trajectory of the vehicle
during launch (or landing). Its main purpose is the utilization of the bodys
gravity to assist in steering the vehicle to its desired trajectory.
It has two advantages over using solely thrust in controlling the vehicle:
1. We dont use the thrust to steer the vehicle, therefore more thrust is available
to accelerate.
2. During ascent, the vehicle can maintain a low angle of attack (or zero). This
minimizes the stress put on the vehicle from aerodynamic forces, allowing
for a less robust, therefore lighter vehicle.
Why use a gravity turn?
During launch, the vehicle goes straight up, gaining vertical speed and altitude.
Gravity, at this point, is acting directly against the thrust of the vehicle, lowering
its vertical acceleration. The losses that occur during this phase of the flight are
known as gravity drag.
85
86 CHAPTER 4. ORBITAL MANEUVERS
The sooner the vehicle pitches over its ascent, the sooner the effects of gravity
drag can be minimized. The earlier this pitch over happens, the better. If the
vertical velocity of the vehicle is high when the pitch over maneuver is executed,
the aerodynamic loads on the vehicle can be very high. This is the general rule,
in real life.
In Kerbal Space Program, the general rule of thumb is to initiate the pitch
over maneuver anywhere between 7,000 meters and 15,000 meters of altitude.
In real life, the angle (not the heading, how much we pitch the vehicle over; the
heading is entirely up to the desired trajectory, though in most cases in the game
we are aiming for an equatorial orbit, therefore the heading is 90) into which we
turn the vehicle, during the pitch over maneuver, varies with the vehicle.
An important part of an ideal gravity turn is that the gimbaling of the engines
is only used during the initial pitching over maneuver. From that point forward the
vehicles engines should always be pointing straight down the axis of the rocket.
Gravity will slowly turn the rocket further and further towards the horizon as
the rocket accelerates. By no longer actively turning the rocket in one direction or
another, we minimize the aerodynamic stress that the rocket incurs as a result of
such maneuvers. The intent of a gravity turn is to, by the time the rocket levels
off (is flying parallel to the ground), have gained sufficient altitude and velocity to
be in a stable orbit.
With vehicles that are launching from a planet with a dense atmosphere, the
smaller the angle of the initial pitch over, the better, since our main goal in this
scenario is to get out of the thicker part of the atmosphere more quickly. The
faster we get out of the thicker part of the atmosphere, the more we reduce the
aerodynamic drag and aerodynamic stress that the vehicle will suffer during launch.
Maximum dynamic pressure is another concern during launch. In Kerbal Space

Program, as of this writing, it is not yet a concern. Once aerodynamic calculations
are included in the KSP universe, it might need to be addressed.
Maximum dynamic pressure, sometimes referred to as max Q, is due to the

build up of dynamic pressure due to the acceleration against the thicker part of the
atmosphere. Again, similar to the turn early or turn late for the gravity turn, it is
a tradeoff between gaining more speed while in the lower part of the atmosphere
and making the vehicle heavier, since it needs to withstand greater pressure, or a
lighter vehicle and gaining less speed while in the lower atmosphere.
4.2. CIRCULARIZING YOUR ORBIT 87
The space shuttle, for example, throttles back its main engines during the
initial phase of the ascent as it approaches max Q to reduce stress on the airframe.
Once it passes through the thicker part of the atmosphere, it accelerates again to
maximum thrust to gain speed as fast as possible.
4.2 Circularizing your Orbit
4.2.1 Achieving Orbit
Achieving orbit, for the first time, is one of the most gratifying experiences that
you will encounter in game. A lot of beginners in the game tend to launch their
rockets straight up. Launching a vehicle straight up will not put your rocket in
orbit. A lot of times, even going up at all can be a challenge.
For our purposes, we will consider an orbit as a trajectory that your vessel
follows in such a way that it will never fall back down to the body it is orbiting.
If we take Kerbin as an example, for the vessel to not fall back to the planet, we
need to satisfy a single condition:
The trajectory has to be high enough, at all points, that the vessel is no
longer being affected by the atmosphere (which causes drag and makes the
vessel lose speed)
The parameters of such an orbit are fairly simple: At no point, in our orbit,
should our vessel go below 70,000 meters.
Orbiting is not so much about vertical velocity, as it is about horizontal velocity.

For an object to orbit another object, it needs to have a horizontal velocity, in
relation to the object it wishes to orbit, high enough that it will constantly miss
the object as it continuously falls towards it.
What that velocity needs to be varies according to the altitude of the orbit:
the closer the orbiting object is to the body it is orbiting, the higher the required
velocity to maintain that orbit. The previous statement assumes that the physical
characteristics of the two bodies are the same in all cases. Also note that the
orbital velocities listed in the table below are velocities assumed to be parallel
to the surface of the body being orbited. It is entirely possible to achieve the
velocities stated below, but if that velocity is not in the right direction, it will not
result in an orbit.
A few examples:
Altitude Orbital Velocity

70,000 m 2,296 m/s
100,000 m 2,246 m/s
Orbital Velocity around Kerbin
200,000 m 2,100 m/s
400,000 m 1,879 m/s
1,000,000 m 1,486 m/s
What this table shows us is that to establish an orbit at, for example, 100,000
meters, we need to be moving, horizontally, at 2,246 m/s. While it is possible to
go straight up until we reach 100,000 meters and then turn and accelerate to the
necessary 2,246 m/s, it is not, from the standpoint of energy expended, efficient
to do that. This is why we typically use a gravity turn during launch. The
purpose of the gravity turn is to impart as much horizontal velocity during our
launch phase as we possibly can. That leaves us less velocity that we need to add,
once we get out into space, to establish the orbit.
A typical launch, whose purpose is to establish an orbit, will involve getting

our apoapsis above 70,000 meters and imparting some degree of horizontal velocity
(by means of a gravity turn), before reaching the apoapsis. An important thing
to remember is that when you are launching a rocket, it does not behave like a
common terrestrial vehicle, you might be at 50,000 meters of altitude, but if your
apoapsis is already at 70,000 meters, or more, you can shut down your engines
and coast the rest of the way. Once we reach the apoapsis, we have to execute a
maneuver that is called. . .
4.2.2 Circularization
The circularization burn is the maneuver where we take our parabolic trajectory
and transform it into an actual (somewhat) circular orbit. In a typical launch, we
might reach our apoapsis with an orbital velocity of 2,030 m/s. Since orbital
velocity (at 100,000 meters) is 2,246 m/s, that means that we need to add another
220 m/s of velocity to establish an orbit.
There are a couple of different schools of thought on how the circularization

burn is supposed to be done:
Point prograde at your apoapsis and burn
Point at the horizon at your apoapsis and burn
Technically speaking, these two methods are essentially the same. The differ-
ence lies in interpretation of prograde and horizon. In a perfect system, where
I could impart changes in velocity instantaneously, both of these scenarios would
be identical. However, that is not the case. I cannot instantly increase my velocity
by 220 m/s.
When you are EXACTLY at your apoapsis, prograde IS exactly at the horizon.
The problem is that you are only AT your apoapsis for a split second. Your
trajectory, before the circularization burn, is a parabola. This means that you
reach the peak of that parabola at some point in time and IMMEDIATELY start
the downward leg of that parabola. Since prograde means the direction that you
are moving, your prograde vector is pointing slightly upwards before reaching
the apoapsis, it is perfectly horizontal AT your apoapsis, then immediately shifts
to point slightly downwards as you start the descending leg of your trajectory.
The result of this inability to instantaneously accelerate means that whichever

of the two methods described above you choose, will result in an approximation to
the ideal circularization burn. Feel free to use whichever method suits your play
style. For the purposes of this tutorial, I am going to discuss the circularization
method using a maneuver node at our apoapsis.
Switch to Map Mode ( m key) and create a maneuver node at your apoapsis,
by clicking on your orbit as close to your apoapsis as possible. You might want to
zoom way in so that you have better control over where, exactly, the maneuver is
created.
Drag the prograde vector away from the center of the maneuver node. As you
do so, you should see the orange-ish colored line that represents what your orbit
will be after executing the maneuver.
Once your periapsis is (about) the same height as your apoapsis, your maneuver
plan is complete.
Look at the Est. Burn time and the time to Node, next to the navball.
This particular maneuver that I performed came up with a little bug that is
important to discuss. The computer calculates your Estimated Burn based on the
engines that you have on your craft. However, when I was establishing this orbit,
I was throttled way down, because I was trying to adjust my apoapsis as close
to 100,000 meters as possible. When the game goes to calculate the burn time,
instead of it using the total thrust of the engine, it uses the last thrust that was
actually used on the engine(s). So it came up with this great 2 hour and 12 minute
estimate. Not very useful, but I assume that it will be fixed at some point by the
developers.
The actual burn time for this maneuver was 10 seconds. Lets just make
believe the computer did it right to illustrate my point.
Take the estimated burn time and divide it by two. You are going to start your
burn at around T- 5 s. This is because, since the burn will be an approximation
(because I cant change my velocity instantly), I want to split the error that I
am introducing to the burn, evenly, on both sides of the point where the computer
expects the burn to happen. The net result of doing it this way is that the deviation
from optimal that I introduce before the node is reached is cancelled out by the
deviation I introduce after the node is reached. This is not optimal, but its the
best our poor Kerbals can do with the tools at hand, maybe someone will come
up with some type of autopilot that can do this better. But. . . moving on. . .
Change the attitude of your vessel to point at the blue maneuver node indicator
on the navball.
When the time arrives, fire your engines
Notice how when I started the burn, the estimate got more realistic. This is
one of the characteristics of both the v meter and the maneuver node indicator
on your navball. For the duration of the burn, they will constantly update for the
same target trajectory. This means that if you deviate from either the path or the
burn profile (youre not burning full throttle, or worse, your stage runs out mid-
burn and you have to switch to another stage) both the meter and the indicator
will update for the new total v that still needs to be expended and the vector
you should follow. All so that your final trajectory ends up where you projected
with the maneuver node (or as close as possible).
Watch the v meter next to the navball, it will slowly countdown the required
v for the burn
When you are close to the end of the burn, throttle down a bit. This gives you
more control over engine shutdown, so you can cut the engines at the right time
and not overshoot your goal.
Cut engines ( x key) as soon as the v meter reaches 0.0 (or as close as you
can get without overshooting).
Notice that the countdown reads T + 11s. If I started the burn at T - 5s,
that means I burned for about 16 seconds total. But wasnt it 10 seconds? The 10
second estimate is based on full throttle until shut down. Since I throttled down a
little at the end of the burn to better control engine shut down, I spent about 3-4
seconds extra burning those last 5-6 m/s off the clock, hence the difference. Also
throw in a second or two before I took the screen shot
4.3 Changing your Orbital Inclination
There are a number of different reasons why you might want to change your incli-
nation:
You want to rendezvous with another vessel, that is in an orbit with a

different inclination
You have some particular inclination that will work better for your vessel
(i.e. a communication satelite, a mapping satelite, etc.)
You want to transfer to another planet that is on an orbit with a different

inclination than the planet you are currently orbiting
You just want things to be organized

4.3. CHANGING YOUR ORBITAL INCLINATION 97
Depending on the inclination change that you need, there are a number of
different ways that you can proceed. Some of them are expensive (in terms if v),
others are cheap (or cheaper, at least).
As an example, look at the inclination change that we discussed in Executing

Maneuvers. That was an inclination change of 90You were in an equatorial orbit,
and wanted to change to a polar orbit. That is a hugely expensive maneuver,
executed as was described. There are other ways to execute inclination changes
that are more economical.
Here is our current orbit:
As you can see, we are in an equatorial orbit at approximately 100,000 meters.

What we want to do is change this orbit so it is still at 100,000 meters but is
at an inclination of 90 (a polar orbit). The maneuver described below will save
you v by changing your orbit into a highly elliptical orbit before attempting the
inclination change. The main steps of the process are:
Burn prograde at the periapsis of your current orbit to raise your apoapsis
until your orbit is highly elliptical. You burn at your periapsis to take
advantage of the Oberth effect.
When at your apoapsis, burn to adjust your inclination as desired. This

should require much less v than the maneuver as originally described.
Furthermore, we do the inclination change in steps. With our first burn we
will make the orbit 30 inclined to the ecliptic plane
Notice how we kept the periapsis where it was. Next well do another burn,
also at our apoapsis, and change the inclination to 45
One last burn, to 90 (we could do smaller increments and save even more
v, but this demonstrates what I want to communicate well enough)
After your inclination is adjusted, burn retrograde at your periapsis to cir-

cularize your orbit once again.
And now we have a polar (90 inclination) orbit.

Lets look at the cost of this maneuver:
Initial apoapsis change: 504.8 m/s
First inclination change (to 30): 407.6 m/s
Second inclination change (to 45): 307.7 m/s
Final inclination change (to 90): 701.9 m/s
Recircularization at original altitude (100,000 m): 504.9 m/s
Total cost of the maneuver: 2,426.9 m/s of v
If we try to execute this maneuver in one step, without the raised apoapsis,
this is what we get:
A maneuver that costs 3,176.5 m/s. Doing it our way, we saved 750 m/s of
v!
This works because when you do the inclination change, far away from the
orbited body, you can make a much smaller adjustment, and that adjustment is
amplified by the increased distance from the orbited body. But why?
Imagine you are holding a laser pointer and point at a wall from 1 foot away.
For you to move the projected dot on the wall 1 foot to the right, you need to
rotate your hand a certain amount. Now back away from the wall 10 feet. Point
at the same initial spot on the wall. Move the projected dot 1 foot to the right.
Notice how much less you had to rotate your hand to achieve the same amount of
movement.
This is true of pretty much all maneuvers you make in the game. The ear-
lier you can make an adjustment to your final target trajectory, the easier (and
cheaper) it is to do so. An example: You create a maneuver for a Mun intercept
and you have a Mun periapsis of 20,000 meters. While you are still in Kerbins
sphere of influence, you can make a very small change to your course (typically,
using any engine the change will be TOO LARGE to manage effectively, so you
usually use RCS for these kinds of changes), on the order of 3 m/s, and you can
affect your final periapsis around the Mun by tens of thousands of meters.
If you wait until you are halfway to the Mun to adjust, you will have to expend
more v. The closer you get to the Mun, the more v you have to expend to
perform the same adjustment. So always adjust early, as early as you possibly can!
But the above explanation was an alternative to a radical 90 inclination

change. Typically you are not going to be doing changes of that magnitude in
your inclination. A typical inclination change is of a few degrees, just tweak-
ing your orbit really. To perform a maneuver like that is much easier than the
maneuver described above.
Lets take a typical equatorial orbit. We have an inclination of 0.
If we want to transfer to Minmus, an equatorial orbit is not the greatest because

of Minmus 6 of orbital inclination. Before trying a transfer maneuver, we should
align planes with Minmus. That means we are going to make our orbit have the
same inclination as Minmus orbit.
In Map Mode ( m key), zoom out until you can see Minmus, and click on it.
This will bring up a dialog, click Set as Target.
Minmus and its orbit will now be yellow in your map view.
Zoom back in to your orbit around Kerbin. Create a maneuver node at the
ascending node on your orbit. It is marked by a little yellow marker with AN
in it.
Adjust your camera-view so that you see your orbit and Minmus orbit edge
on, so that they both appear as lines to you. Also make sure that you are looking
from an angle that the ascending node marker and the descending node marker
are right on top of each other
Drag the anti-normal maneuver handle away from the center of the maneuver
node until your orbit is lined up with Minmus orbit
Execute the node: Point your vessel at the blue maneuver node indicator on
the navball; Calculate your burn start time (T - half the burn time); and burn
until your v meter reaches 0.0.
Your orbit is now at the same inclination as Minmus, making any transfer you
want to do there, that much easier.
4.4. AEROBRAKING 109
4.4 Aerobraking
If you have ever reentered the atmosphere of Kerbin with a ship, you know that
you lose velocity VERY fast as you hit the lower levels of the atmosphere. It is
that loss of velocity that we are trying to exploit when we perform an aerobraking
maneuver.
Most approaches to a planet involve a hyberbolic trajectory (one that doesnt

orbit the planet, as much as swing by it). This means that typically you approach
a planet at a high velocity in such a fashion that your trajectory is changed by
the influence of the planets gravity on your vessel, but not changed enough to put
you in an orbit around that planet.
Typically, we resolve this issue by firing retrograde at our point of closest

approach to the planet and establishing an orbit around it. An alternative to this
method, when the target planet has an atmosphere, is to use aerobraking.
So Im coming into Dunas sphere of influence FAST!

WAAAYYYY before I get there, I adjusted my trajectory so that my periapsis

around Duna, on arrival, is in the atmosphere. Dunas atmosphere extends 41,447
meters from the surface. As you can see in the picture below, even though I
am 29+ DAYS away from reaching Duna, Ive already established a periapsis of
24,000 meters. Im going to adjust this further to be around 12,000 meters for
maximum aerobraking effect.
As soon as I reach Dunas sphere of influence (SoI), I now see that my periapsis
is 89,569 meters. This is because the estimate that I was shown, before actually
getting there, was slightly off.
One last final adjustment to my periapsis using RCS, because the engine would
be WAY too powerful for this minute adjustment.
Look at my trajectory from another angle. According to the computers pro-

jection, I will swing by Duna and escape on a hyperbolic trajectory. What the
computer is not taking into consideration is the aerobraking that is going to occur.
Now if we wanted to enter orbit around Duna, and get off that hyperbolic
trajectory, typically what we would do would be wait until we reach our periapsis,
burn retrograde to lose velocity and make our trajectory elliptical and eventually
(somewhat circular). Problem with that is that uses fuel. This is where aerobrak-
ing comes in, so lets do this!
Im coming in FAST, and gaining velocity as I approach my periapsis (Im

currently at 670,000 meters)
50,000 meters, going 1500+ m/s. Hang on cuz here we go!

I hit the dense part of the atmosphere HARD, my vessel loses velocity QUICKLY.
Enough so that my hyberbolic trajectory
is now transformed into a highly elliptical orbit around Duna.

And still losing speed, lowering my apoapsis even more
I zip through Dunas atmosphere, losing a lot of my velocity, but not enough
to actually land, and come out the other side of the atmosphere still moving at a
good clip.
My apoapsis is now high above Duna
When I hit it my apoapsis, I can thrust prograde, very little, just to lift my
periapsis out of the denser part of the atmosphere, but still leave it inside the
atmosphere. We dont want to do another hardcore aerobraking session like the

last one, but we still want to use the atmosphere to lower our apoapsis some more.
I come around to my periapsis a second time and my apoapsis drops some

more due to the aerobraking.
I can repeat this process, as many times as I want, each pass lowering my
apoapsis some more, until I have an apoapsis at the height that I want. After my
third pass through the atmosphere
After my fourth pass

And I can continue orbiting Duna for as long as I want, each pass, in this
case, lowering my apoapsis by only 500 meters. Thats pretty precise control. If
I wanted to lower it faster, just dip my periapsis further into the atmosphere; if I
want to lower it slower, lift my periapsis a little bit more up in the atmosphere.
Once Im at the height that I want, I can thrust prograde at my apoapsis to

bring my periapsis completely out of the atmosphere and circularize into a stable
orbit.
Or I can even let it go all the way until my apoapsis also falls into the atmo-
sphere, making my trajectory sub-orbital, and I can then (try to) land.
And there you have it, I successfully established an orbit around Duna (or
landed on Duna, depending on which scenario you followed above), while expend-
ing very little (or no) v. The amount expended would be typically less than any
minor orbital correction that you might make on a typical mission. All thanks
to aerobraking. Unfortunately, this maneuver only works on planets that have an
atmosphere, but the larger and denser the atmosphere, the better it works!
Lets do the math for the above maneuver: When I first entered Dunas SoI,
I used RCS (about 2.2 m/s worth) to readjust my periapsis; after my first trip
through the atmosphere, I burn 9.2 m/s worth of v to lift my periapsis almost
out of the atmosphere; after A LOT of orbits, I finally used 56.5 m/s of v to
circularize my final orbit. If I went for the landing scenario, dont count that last
56.5 m/s.
To summarize:
Establish 150,000 meter orbit around Duna using aerobraking: 67.9 m/s of
v
To land on Duna, using aerobraking: 11.4 m/s of v
With those kinds of budget, you dont even need an engine! You could do the
whole thing with RCS!
4.5 Rendezvous
Heres the setup. . . I have one ship orbiting Kerbin at an altitude of 1,000,000
meters. It has an orbital inclination of 45. The second ship is in a 500,000 meter
equatorial orbit (inclination of 0). The blue orbit in the picture below is the ship
at 500,000 meters. The yellow orbit is the ship with which I want to rendezvous.
This is going to make this section longer, but I did it for two reasons:
4.5. RENDEZVOUS 123
With this inclination and altitude, I avoid falling behind Kerbins shadow,
so the screenshots should be better.
This will give me the opportunity to show how you incorporate an inclination
change into your rendezvous process.
Make sure you click on your target ship and select Set as Target (this is what
makes the orbit yellow, and shows you the ascending and descending nodes).
The first thing we want to do is match planes. At the Ascending Node in my

orbit
I create a maneuver node and adjust by pulling the anti-normal indicator (pink
triangle with spikes) down until I have about half the plane change done.
4.5. RENDEZVOUS 125
If I look at my proposed orbit from another angle, youll notice that the apoap-
sis raised significantly
I can pull the retrograde marker a little to bring that back, if I want, but were
going to need to do something like that anyway (since its almost exactly at the
1,000,000 meter mark) so Ill just leave it.
Lets execute this node:

4.5. RENDEZVOUS 127
Our orbit looks like we expected.

Now we do another inclination change. Same thing: create maneuver at as-

cending node; adjust anti-normal again
4.5. RENDEZVOUS 129
Inclination looks good, but apoapsis got way out of hand now
So lets adjust the retrograde marker of the maneuver node and bring that
back
4.5. RENDEZVOUS 131
We execute this second maneuver
Then we time accelerate. Do a couple of orbits, until the intersect markers are
somewhat close (couple of hundred kilometers)
1
Now create a maneuver node about 4 of an orbit BEFORE the intersect
4.5. RENDEZVOUS 133
Drag the prograde marker on your maneuver node, until the 2 purple intersect
markers are REALLY close
And there we have an intersect of 4.8 km (not the closest in the world, but
it will do for us). Couple of things we can do here if we cant get a close enough
intersect:
Tweak the other attributes of the maneuver node like radial-in or radial-out
to see if we can get a better intercept (least effective)
Click and hold on the middle of the maneuver node (it turns white) and
drag it around your orbit to find a better spot to execute the node (most
effective)
Or delete the maneuver node altogether and create a new one (more work,
but also effective)
Also remember that you can try for the intersect at either the purple intersect
(2nd intersect) markers OR the orange intersect (1st intersect) markers.
Whichever one you can get to be close first, better for you.
Execute the node

4.5. RENDEZVOUS 135
We now have a pretty decent intersect. Now we need to get there and establish
an orbit identical to the target ship. To do this, what we want to do is get to
the intersect and zero our velocity in relation to the target. If we are (practically)
in the same orbit as our target and we are moving at the same speed, we will be
stationary in relation to each other.
So if we want to have a zero velocity in relation to the target, we need to put

our navball in Target mode. Click on the navball where it says Orbit until it
says Target. If you were paying attention when you clicked, youll have noticed
that the prograde/retrograde markers on the navball jumped around when you
clicked. If you didnt, do it again, Ill wait here. . .
The reason they jumped is that the prograde and retrograde markers on the
navball are now indicating your velocity vector in relation to the target. And the
velocity being shown is also in relation to the target. Our objective here is that
once we reach the intersect, we want to make our velocity 0 m/s (or as close as
we can get it to zero). Like I mentioned above, if we have no velocity in relation
to each other, we are stationary in relation to each other. Thats what we want!
Time warp to the intersect. Dont get too crazy with the time warp or you
will overshoot the intersect, and you cant just come around for the next try, it
doesnt work that way.
4.5. RENDEZVOUS 137
Notice that as we pass the orange intersect markers (1st intersect) on the orbit,
the purple ones (2nd intersect) turn orange, since what was our 2nd intersect now
became our 1st intersect.
Once we are near the intersect (notice how Im 1 minute away from the
intersect)
4.5. RENDEZVOUS 139
Point retrograde on your navball and turn on SAS ( t key). Time your burn
so that you have enough time to bleed off the speed that you have in relation to the
target (in my case, 223.4 m/s). Lets call it 25 seconds. So when Im 25 seconds
from the intersect I will activate my engines.
I cancelled (almost) all of my velocity in relation to my target and am now

sitting at 5.9 km from the target and our relative velocity is almost zero. So were
pretty much stationary. My original intersect said 4.8 km and Im at 5.9 km. The
discrepancy is because of how I executed the zero your velocity maneuver. I
didnt wait until the very last minute and burn full thrust, I slowly burned off the
speed in a controlled fashion, so yeah, it wont be exact. But 5.9 km is still a
respectable intersect, and dont let any of the 0.1 km and 0.2 km intersect pilots
tell you any different.
Using RCS (since my velocity is so low now), I point retrograde again and
bring our relative velocity to zero.
4.5. RENDEZVOUS 141
Now we need to get closer. . . point at your target prograde indicator in the
navball (pink circle) and thrust to about 10 m/s. Youre going to see people
saying thats WAY too slow if youre at 6 km!. Whatever. . . this whole thing
took me 15 minutes of real time to do, Im not in that much of a hurry! Let them
go thrusting about at 60 m/s and well see who ends up with solar panels still
attached and who ends up without.
Notice how the prograde marker popped up in front of us on the navball,

because thats the direction Im moving. But also notice how it is not EXACTLY
on top of the target prograde indicator. That means we are not moving EXACTLY
in the direction of the target, but a little off. What we want to do is pull that
yellow prograde marker into the middle of the target prograde indicator.
To do that, there are two different methods that we can use. The first method
is:
4.5. RENDEZVOUS 143
point to the spot that is almost exactly opposite of the yellow prograde
marker on the other side of the target prograde marker
See how Im pointed to almost the exact opposite position, compared to the
yellow prograde, except on the other side of the target prograde marker? Use RCS
forward ( h key) to thrust in that direction A LITTLE BIT to pull the yellow
prograde marker where you want it. Wherever you are pointing when you thrust
is where the prograde marker is going to move towards.
I screwed that one up, on purpose. See how my prograde is now to the right
of my target? Point to the left of the target and thrust there
4.5. RENDEZVOUS 145
Now were all lined up, heading toward the target. But all this thrusting to
adjust the markers has brought our speed up to 53.9 m/s. . . lets slow that down,
we dont want to plow into the other ship. Point yellow retrograde, and fire your
engines (since its a pretty decent amount of velocity, RCS will take too long), but
use a slow burn, you dont want to overshoot. . . bring it down to the 10 m/s we
wanted.
Notice how retrograde and target retrograde are also lined up.
The second way to adjust youre prograde when closing on the target is:
4.5. RENDEZVOUS 147
use the RCS keys ( i , j , k and l to adjust your trajectory
So. . . if you were in this situation:

you would press the i key to push the prograde indicator down toward
the target indicator
if you were in this situation:

4.5. RENDEZVOUS 149
you would use the j key to push the prograde indicator left toward the
target indicator.
One of the big advantages of the second method is that you will not end up
with your closing speed as high as the first method (53.9 m/s), which can be very
important if you are closing from a smaller distance. At smaller distances, you
dont want to end up accelerating too much toward your target, or bad things will
happen.
So. . . whatever method you use, eveything should be lined up and you should
be approaching your target at a reasonable speed. . .
If its taking too long to get to the target, DO NOT ACCELERATE

MORE! Use time warp. Im not saying you have to only do rendezvous at 10
m/s, what Im saying is: find a velocity you are comfortable with and stay there.
Dont adjust your velocity to speed things up. Use time warp, because once you
are REALLY close, you can instantly leave time warp. If you accelerated to make
things go faster, when you are REALLY close, you CANT instantly slow down
(gotta point in the right direction, fire engines or RCS, be careful not to overshoot,
etc.). Its a lot harder to do that on-the-fly when you are 20 meters from your
target and going too fast!
Depending on how well aligned you managed to get those two markers, they
will tend to drift as you get close to your target (I did pretty good actually, they
only drifted a tiny bit and Im already at 196 m). If they drift, use the same
process you used to align them initially, to realign them.
Im moving WAY too fast (see? I told you!). . . gotta slow down. . . Bill jams
on the brakes
4.5. RENDEZVOUS 151
Now align your prograde vector again, using either of the two methods de-
scribed above
A little bit of time warping and here we are, up close and personal, with our
target ship. 12 meters is not bad to start a docking procedure, but well do that
in the next section.
4.5. RENDEZVOUS 153
Before wrapping up, some other tips to discuss:
When trying to adjust your velocity, if the change is small (less than 5-10
m/s), use RCS.
Using RCS forward ( h key) is the same as using your engines to thrust
very slowly in the direction you are pointing. This is sometimes exactly what
you want/need: very fine adjustments. Likewise, RCS backwards ( n key)
is very useful for reducing your velocity without having to do space-flips
(see below).
If you are pointing prograde and want to reduce your velocity, it is more
efficient to STAY pointing prograde, and thrust RCS backwards ( n key)
than to flip 180 and thrust forward and then have to flip 180 again. It
will save RCS monopropellant and even if you are only using torque to
turn around, its still a lot faster to thrust backwards than to flip around.
Obviously, this doesnt apply if you have to make a significant change in your
velocity (requiring engines), since engines dont thrust backwards (unless you
mount a set facing forward on your craft, theres nothing to say you cant!).
Ditto if you are pointing retrograde, but need to increase your velocity. Just
thrust backwards, same concept.
Another adjustment you can make, similar to the two above. If we want to
pull the yellow prograde we thrust forward after pointing in the appropri-
ate direction. But if we overshoot our target prograde indicator (we pulled
it too much), you dont have to turn and adjust again. Just thrust backwards
(assuming you are using RCS), if thrusting forwards pulls the prograde,
thrusting backwards pushes it away from wherever you are pointing!
Always try to be as precise as possible when positioning the yellow prograde

vector over your target prograde vector. The more precise you are, the less
adjustments you will have to make to your trajectory as you get closer.
In my example above, I was only pointing a little off the target indicator,
to illustrate the point, but you can point further away and use less thrust
to achieve the same correction. I only did not do that because if I pointed
90 away from the target prograde indicator, it wouldnt have been visible
on my navball and my explanation would be vague. Just make sure that
the vector you are pointing is correct (if yellow prograde is to the left, you
point to the right; if yellow prograde is above, you point below; etc) for the
adjustment you want to make.
And finally, keep your velocity in check. Those darn solar panels are attached
with bubble gum and will fall off at the slightest nudge! Use time warping
liberally during rendezvous. Use it a lot, but not high time warps otherwise
debris will happen!
Just so you have an idea of how hard this was: Even with making sure to
take all the screenshots at the right times, actual play time from the very first
screenshot to the very last screenshot in this section, was about 15 minutes real
time. Game time was a lot more than that due to the time warping (especially
when I was waiting for that 200 km intersect). All maneuver nodes were created
manually, no MechJebbing any of them. I did Hyperedit both of those ships into
their initial positions, but that was it. Infinite fuel was on (but probably didnt
need to be).
4.6. DOCKING 155
I did dock both of those ships together after completing this section so I can
use the same two ships in the next section Docking. Ill undock them and move
them about 50 meters apart before starting that one.
This was a very fun section to write and I hope you enjoyed it!
4.6 Docking
Our Starting Point
Were going to continue where we left off in the rendezvous section. At the end of
that section, we were 12 meters from our target. Since I know that it is sometimes
difficult to achieve an approach that close, Im going to back away from our target
vessel and start the docking procedure from around 50 meters.
So our starting point will be our two vessels, with 0 m/s relative velocity
between them, and about 50 meters apart.
Pre-Docking Checklist
Make sure your navball is still set to Target mode. If its not, click on where it
says Orbit or Surface, and the speed right underneath, until it says Target
Typically, at this point in the maneuver, you will not be using engines. We
are way too close to our target and we dont want to ram into it, so if you havent
already, start using RCS. Turn on RCS by pressing the r key.
Another thing that we have to do to prepare for the docking procedure is to

select the port, on our ship, that we are going to use to dock. Right click on the
port, and select Control From Here.
This is VERY important if you have ports that are not lined up with your
pod/probe (like on my ship). When you are using docking controls (like the
IJKL/HN keys, or WASD/Shift-Ctrl keys in docking mode), the direction that
your ship is going to move when you press a key is in relation to whatever port
on which you said Control From Here. So in the case of my ship, which has its
docking port mounted on the side of the main body of the craft, if I dont Control
From Here on the correct port, my controls will be crazy to understand.
4.6. DOCKING 157
If done properly, on my ship, for example, when I press h to move forward,

the RCS is going to thrust in such a fashion that the docking port I am controlling
from moves forward (which means the ship, as a whole, will be moving sideways).
Another thing that you should do is decide which port, on the target ship, you
wish to dock TO. Right click on that port and select Set As Target.
If you still cant pick out the target docking port on the target ship to be able
to right click on it, youre not close enough. Setting the target to the specific port
makes the game now show you the distance between YOUR docking port and the
target docking port. When you set a ship as a target (like you did in Map mode for
the rendezvous), the system is actually targeting the ships center of mass. Since,
typically, the docking ports are not located at the center of mass, the distance
indicator to that center of mass doesnt really help us for the docking procedure.
So once you are close enough, target the specific port with which you want to dock.
Before trying to do any close-up-and-personal maneuvering near your target,

switch your camera to CHASE mode (press v a few times, until it says Camera:
CHASE).
Once your camera is in Chase Mode, rotate your camera (by holding the right
button and moving the mouse) until you are looking straight at the backside of
your docking port. In the case of the ship being used for this tutorial, since I have
two docking ports on opposite sides of the ship, I want to be looking straight down
at the docking port opposite the one from where I am controlling.
4.6. DOCKING 159
Another tip is that if you are using RCS, you can point at your where you
want to go (prograde/target) and press h to thrust forward. When you want to
brake, instead of flipping your ship around and pressing h , just point prograde
and press n (RCS thrust backwards). That way you dont waste time turning
your ship around dozens of times, which also uses RCS.
Now that you have positioned your camera properly, in Chase Mode, the IJKL
keys make sense: i = down, k = up, j = left and l = right, just
like your WASD keys. While WASD will rotate your vessel in the corresponding
direction, IJKL will translate your vessel in that direction. What is translation?
Imagine you are standing up straight: to rotate left, you turn your entire body
left to face left; to translate left, you would continue facing the same direction and
you would side-step left. It is also called sliding or strafing in some games.
Its NOT changing your orientation but still moving.
The next thing we want to do is position our target ship so that our docking
process is easier. If you are in a ship in orbit, pointing prograde, as you circle
the planet you are orbiting, your ships orientation doesnt change (the prograde
slowly moves away from the nose of your vehicle and loops around a complete
360 for every orbit you complete). The net result of this is that if you are in a
separate vehicle, stationary in relation to that first ship, it looks as if that ship is
tumbling in front of you.
In real life, there are usually pilots in both ships and they can maintain a
certain attitude to avoid the ship tumbling out from under you as you are trying
to dock with it, but in Kerbal Space Program, where we can only control one
ship at a time, these attitude changes of the target ship, along the course of its
orbit are unavoidable. There is, however, a trick to minimize this problem. If
you orient the docking port of the target ship to point EXACTLY in the normal,
or anti-normal direction, the ship will still tumble, but in such a fashion that
the docking port, for your purposes, is stationary (because the ship is tumbling
around the docking port).
To accomplish this, switch to your target ship (pressing the [ or ] keys),

and select the port you were going to dock with and Control From Here on
the docking port you want to use. Now on your navball, point in the normal
direction. In an equatorial orbit, if you were pointing prograde to start, turn 90
towards the planet (radial-in), then 90 up (in the direction of the north pole
of the planet). In an equatorial orbit, my navball should look like this:
4.6. DOCKING 161
Because my ships are not in an equatorial orbit, my navball, for this maneuver,
will look like this:
Once you have positioned your target ships docking port pointing normal,
turn on SAS ( t key). Good!
Switch back to your original ship (pressing the [ or ] keys). Since we

switched vessels, we lost our target designation, so right click on the target docking
port on the target ship again and select Set As Target. Just to make sure, select
the port you want to use for docking on your ship, right click and select Control
From Here.
If we want these docking ports to connect, they have to meet as flat as

possible. Since we oriented the target ships docking port in the normal direction,
we have to orient the docking port, on the ship we are docking from, in the anti-
normal direction.
For an equatorial orbit, anti-normal on the navball, will look like this:
In my case, my antinormal direction looks like this on my navball:
We do the same thing we did on the target ship and lock in SAS ( t key)
on our docking ship. If weve done this properly, we can now use the translation
controls on our docking ship and the orientation of our docking port will not change
(if it does, SAS will bring it back to where we want it). Now its just a matter of
getting the two docking ports in front of each other and then closing the distance
between them.
4.6. DOCKING 163
Before we move on to docking these two ships I want to discuss the orienting
of the ports to normal and anti-normal. If you are not in an equatorial orbit, it
might be difficult to figure out where those two points are on the navball. An easy
way to figure that out is to create a dummy maneuver node, and adjust as if
you were performing a burn in the desired direction. Doesnt matter how long
of a burn since you wont be actually executing it.
Once youve created the node, there will be a maneuver node indicator on your
navball in the exact position that you need it. Orient your ship in that direction,
engage SAS ( t key), and then you can delete the maneuver node.
This is where we currently stand, docking ports are aligned (orientation-wise)

properly. and were still about 50 meters from our target. (I know this screenshot
is horrible, but it was the best I could do. Trust me, theyre aligned in this picture).
Docking
Before we actually start the docking process, lets look at some tips on using RCS:
Use RCS sparingly. . . if you are holding any given RCS thrust key for more
than 1 second, youre doing it wrong! The closer you get, the shorter the
bursts should be (really just quick taps on the keys).
Learn the translation controls IJKL/HN as opposed to WASD/QE. That

way you can leave the WASD keys to adjust orientation with your left hand
(or just let SAS take care of rotation, if you set it as described above), while
still translating using IJKL with your right hand.
For the beginners (people who dont have experience docking), only adjust
one axis at a time. Example: use the I/K keys to adjust your up and
down position until your docking port is at the same height as the target
docking port. Once you are done that part of the maneuver, your velocity
in relation to the target should be 0 m/s (or as close as possible). THEN
start using the J/L keys to adjust your left and right position until your
docking port is aligned properly with the target docking port. When you
are done with that part of the maneuver, again, your velocity in relation
to the target should be 0 m/s. While this process consumes more RCS
monopropellant (instead of making a bee-line straight for the docking port),
it is much easier to accomplish this way.
Use time warping to accelerate the process. Dont increase your speed to
much over 0.1-0.3 m/s during the final approach. Example: youre too
high in relation to the target port: quick burst of RCS using the i key;
your ship will start to slowly move down; If youve got 10-20 meters that
you need to go down, time warp; once you are near perfect position, exit
time warp; quick burst of RCS using the k key (to cancel out the initial
burst when you pressed the i key); you should now be stationary again;
The objective of our docking procedure is to make the two ports come into
contact as flat as possible. We already know that the ports are currently flat
in relation to each other because of the pre-docking steps we took above.
Since we did the Control From Here on the docking port we are using, the
navball is now oriented as if we were inside the docking port, looking straight
out. This is where our problem currently is:
4.6. DOCKING 165
The target indicator is nowhere near, where it needs to be. For us to be able
to dock, the target indicator needs to be dead-center on our navball.
Lets deal with the up/down position first.
I can see in the navball picture right above that my target is below me. So
I thrust with RCS down ( i key). The target indicator slowly moves up. When
the target indicator is almost centered, vertically, in the navball (about halfway
up)
I thrust RCS up ( k key) to cancel my downward movement, until Im at

0.0 m/s again.
Now lets deal with left/right. As you can see in the last navball picture,
target is far to the left, so I thrust RCS left ( j key). The target indicator slowly
moves right towards the center of the navball
As the target indicator gets close to the center, we see that our vertical align-
ment is not great. I stop the sideways movement by thrusting RCS right ( l
key) back to 0.0 m/s. Lets readjust that vertical. I thrust RCS down again ( i
key).
4.6. DOCKING 167
After a few more small adjustments, I stop my movement and it looks like Im
perfectly aligned. Now we move in for the docking. Thrust RCS forward ( h
key).
As we start to move forward, we notice how the target indicator drifts away
from center pretty quickly. This means we werent as perfectly aligned as it looked.
The closer you get the bigger the tiny discrepancies will show. So we stop, thrusting
RCS backwards ( n key).
And readjust the centering of the target indicator in the navball. Nice and
centered again.
Up until this point, I only showed you screenshots of the navball. I did this
for a reason. When you are maneuvering in to dock, thats where you should be
looking. The directions on the navball (up, down, left and right) dont change. If
you look at the ships, depending on the position that your camera is in, they could
4.6. DOCKING 169
be completely backwards. However, once you get really close (like the 5 meters
Im at now), you are pretty much docked and its just a matter of nudging them
together, so at this point watch the ships.
Lets try moving in again. . . h key. . .
As we move in, we very lightly control position using IJKL. TINY, TINY
bursts. Were at 3 meters. This might work! But Im in the dark again, let me
rotate that camera so we can actually see this docking.
2.9m. . .
4.6. DOCKING 171
2.7m. . .
2.5m. . . This is where the magnets on the docking ports kick in and start to
pull your two ships together. . .
2.4m. . .
4.6. DOCKING 173
And were docked!
Docking is a very delicate and complex maneuver. Your biggest enemy when
docking is velocity. Make sure you keep the velocity as low as you possibly can.
Use time warping to get through the long boring parts. The more gentle you are
on the RCS controls, especially during those last few meters, the more successful
you will be.
The ships used in this tutorial have docking ports mounted radially. I do
not suggest you do that. It is much simpler when the docking port is oriented
forward from the normal position your ship flies. However, design constraints
sometimes force you to do things like mounting them radially. Once you have a lot
of experience with docking, you can probably mount them anywhere you want and
not notice the difference. For starters, stick with mounting them forward (unless
you cant for design reasons).
There are some very important things to know about docking and docking
ports:
1. Docking ports must be the same size to dock to each other. You cannot
dock a Clampotron Jr, to a regular sized Clampotron, or a regular sized
Clampotron to a Clampotron Sr.
2. A very common mistake is putting the docking ports on backwards. This is
especially true of the Clampotron Srs. Whichever side is up (in the VAB),
or front (in the SPH), when first picking the docking port from the parts
list, is the side that actually docks. If you are not sure which side is up, grab
the part and press space in the VAB/SPH and that will reset the parts
orientation to as if you had just picked it from the parts list.
3. When docking ports are close enough together to dock, there is a magnetic
force that they exert on each other to complete the docking, sometimes
having SAS on when trying to dock, causes it to not dock. You can still use
SAS during the docking maneuver, just make sure to turn it off for that last
half meter or so of approach.
4. When you undock two docking ports, the magnetic force mentioned above
turns off to allow you to separate the two vessels without pulling them
back together. The magnets only reset if you move the docking ports a
certain distance from each other (something like 5-10 meters). So if you
just undocked (usually to adjust a docking position) and cant redock, try
backing away about 5-10 meters and THEN redocking. Some people have
said that quick saving and quick loading also resets the magnets, I have not
confirmed this.
5. The Rockomax HubMax Multi-Point Connector DOES NOT HAVE
DOCKING PORTS ON IT!. If you want to dock to it, you HAVE to
add the docking port to it. Ditto for the BZ-52 Radial Attachment Point.
6. The Inline Clamp-O-Tron and the Clamp-O-Tron Shielded Docking Port,
on the other hand DO HAVE docking ports built into them. You have to
right click the part to open and expose the docking port once you have
launched (cant do the right clicking part during assembly).
I sincerely hope that this section helped you learn the fine art of docking!
4.7 Gravity Assist

A gravity assist, also known as: gravitational slingshot or swing-by, is a maneuver
where a spacecraft approaches a planet, moon or other celestial body, and uses its
4.7. GRAVITY ASSIST 175
gravity to alter its course and/or change its velocity.
The strange part of a gravity assist is that it looks like it shouldnt work. Take
a look at the diagram below:
In the diagram above, the length of the arrows represent the magnitude of
the velocity. The longer the arrow, the higher the velocity. Looking at the above
diagram we see that the vehicle approaches Jupiter at a specific velocity, gains
velocity, due to Jupiters gravitational influence, reaching its highest velocity at
the closest approach to Jupiter, and then slowly loses velocity as it leaves the
influence of Jupiters gravitational field. Its velocity is the same as it leaves as
when it entered.
If you were standing on Jupiter watching this maneuver, you saw a craft ap-
proaching Jupiter at, lets say, 1,000 m/s. As it fell into Jupiters gravity well, it
picked up speed, until at its closest approach it was moving at, lets say, 1,500
m/s. Then it started to lose velocity, at the same rate that it gained it, until
once it leaves Jupiters gravity well, it is moving at the same 1,000 m/s that you
observed when you first saw it approaching.
So, whats the point?
The point is that all the velocities discussed in the previous two paragraphs,
and shown in the diagram are in relation to Jupiter (or to you standing on Jupiter).
Jupiter is not a stationary object. It is moving around the Sun at a pretty

good clip. When you perform a gravity assist, you steal some of that velocity
from Jupiter and add it to your vehicles velocity.
Look at this diagram that includes a vector for Jupiters movement around the
Sun:
When you add in Jupiters movement vector (the red vectors above), you can
see that both the Vin and Vout (blue) vectors are larger than the simple vehicles
velocity vectors (black).
Lets put this in context:
If you were standing on the Sun (bring sun block!) and were watching this
maneuver, you would see that the vehicle is traveling at a velocity of, lets say,
2,000 m/s, in relation to you, around the Sun. It is approaching Jupiter at 1,000
m/s, just like before. From your standpoint, Jupiter is also traveling at a velocity
of, lets say, 1,000 m/s, in relation to you, around the Sun.
You see the spacecraft gain velocity as it approaches Jupiter, and you see it
lose velocity as it moves away from Jupiter, but from THIS standpoint, outside
of Jupiters frame of reference, the gain and loss are not equal. As it approaches
Jupiter you see it gain way more than the 500 m/s that the observer on Jupiter
saw, because you also see it gain the angular momentum of Jupiters orbit, so you
see, for example, a gain of 1,300 m/s. The vehicle is now moving at 3,300 m/s
in relation to the Sun. As it departs Jupiters gravity well, it loses those same
500 m/s that the observer on Jupiter saw it lose, but it keeps that 800 m/s, that
it gained from Jupiters orbital velocity, ending up, to you, looking like it is now
moving at 2,800 m/s and on a different trajectory than what it was on before.
The important part of this whole thing, is that it was accomplished without
expending any fuel. All using gravity. You can adjust your approach to the body
that you want to use for a gravity assist so that the angle, and the amount of
speed you gain, when you leave their gravity well, is the one you want.
4.7. GRAVITY ASSIST 177
This entire process also works to reduce your velocity. The only thing that
changes is the direction in which you approach the body you want to use for the
gravity assist. If you perform the maneuver as below, you will lose orbital velocity,
proportional to Jupiters orbital velocity. If we use the same numbers we used
above, your resultant orbital velocity, in relation to the Sun would be, after the
maneuver, 1,200 m/s; instead of gaining 800 m/s, your vehicle would lose 800
m/s.
Disclaimer: All the numbers used in the two examples above are completely
random and used for example purposes only. Jupiters true orbital velocity is more
like 13,000 m/s. The proportion of velocity gained/lost in the two maneuvers is
also completely random. The numbers were chosen to illustrate the point that you
gain/lose some fraction of the bodys orbital velocity, but not all of it.
The actual result of a gravity assist maneuver, be it to gain velocity or lose

velocity, will vary in accordance to the angle at which you approach the body and
the distance of your closest approach to the body.
A gravity assist is not really a maneuver that I can simulate on demand,

especially if you consider that I would have to show you multiple maneuvers, very
similar in nature, with small variations so that you could evaluate the different
end result of each maneuver based on the variations.
I will leave you here with this information and hope that it helps you executing
this type of maneuver.
4.8 Landing
Landing sounds like a fairly simple maneuver, however it is one of the more complex
maneuvers that you will execute in the game.
The reason it is difficult is that for you to land successfully (without explod-
ing or otherwise destroying your vehicle), you must do so at a very low velocity,
typically less than about 5 m/s. The problem is that for you to maintain proper
attitude when you are moving this slowly and being pulled by gravity, all at the
same time, is very difficult because your ship is very unstable. Using SAS to
control your attitude at this phase of the maneuver is HIGHLY recommended.
Another point that sometimes people overlook, is that for you to land suc-
cessfully, your velocity, in relation to the surface that your are trying to land on,
should be as close to 0.0 m/s as possible. However in game, there is no indicator of
your horizontal velocity. You have to gauge, based on the vertical speed indicator
(next to the altimeter), and the speed indicator (above the navball) and kind of
deduce what your horizontal velocity might be. Usually its easier just to view the
terrain and see if you are moving in relation to it.
Disclaimer: I dont claim that this is the best or most efficient way to perform
a landing. Im sure there are people that can do this WAY better than I can, but
this WORKS (not that any other method doesnt). If you like my method, enjoy,
if you dont like my method, write a thorough description on how to perform this
better and I will be happy to include it in the next edition of this book.
But lets try to do this. Our starting point is a circular, equatorial orbit at
30,000 meters, around the Mun. Our intention is to land somewhere north of the
big crater that sits right below the equator of the Mun.
4.8. LANDING 179
Our first step in landing is to do a deorbit burn. What that means is we want
to transform our now, perfectly, circular orbit, into a suborbital trajectory. To
do this, we wait until we are about 14 of the way around the Mun, BEFORE our
desired landing site, and burn retrograde.
We want to burn retrograde enough so that our blue trajectory line ends up
slightly AFTER where we want to land. The reason for this is that the blue
trajectory line is a perfect parabola and we dont want to perform a parabolic
landing maneuver (they are possible, but extremely difficult). What we want to
do is make our trajectory overshoot our target landing site by a little bit, this
means we will still be in the air as we pass over our desired landing site.
4.8. LANDING 181
It is at this point that we want to burn retrograde again to lower our velocity
to virtually 0.0 m/s. This will allow us to descend straight to our desired landing
site.
If you do this correctly, and follow your retrograde vector as you burn, you will
end up with your retrograde vector pointing straight up to the middle of the blue
part of the navball (which means your prograde vector is straight down, which is
what we want!).
4.8. LANDING 183
When we turn off our engines at this point, we will start to gain velocity again.
This is the Muns gravity pulling us down. This is where things get complicated.
We dont know how high up we are because the altimeter on the main flight screen
is showing altitude to sea level. The actual surface of the Mun is going to show
up WAY before that reaches anything close to 0. The only way, without mods, to
know your true altitude in relation to the surface is to check the radar altimeter
in the cockpit. Press c .
As you can see, the radar altimeter is showing that we are about 800 meters
above the surface. Quick switch back to regular flight screen ( c again)
Our dumb altimeter is telling us we are 3,600 meters off the surface. We do
the math and figure that we should reach the surface when the flight altimeter
reads somewhere around 2,800 meters. Dont cut it too close or ground will show
up faster than you think. But well double check that anyway.
We continue to fall. Were expecting surface around 2,800 m. So what I like

to do is wait for a nice round number (3,000 m, in this case) and double check our
math. So I wait until 3,000 rolls around on the altimeter.
4.8. LANDING 185
Once Im there, I press c to switch back to the cockpit. If our math is right,
our radar altimeter in the cockpit should be showing about 200 meters
Bingo! It looks like its a little below 200 meters, so lets readjust our estimate
of surface from 2,800 meters to 2,850 meters just to be on the safe side.
Time to slow down big time

This is where things get hairy. The slower you are going, the harder it is to
keep that retrograde vector at the top of the navball (pointing straight up). But
you have to chase it! Make sure it stays at the top! Throttle up and down to keep
a reasonable velocity (something between 3-10 m/s).
Were still descending

4.8. LANDING 187
Were at 2,919 meters. Our radar altimeter should be marking around 75-100
meters if our math is right. Lets see.
Looks like almost 100 meters exactly (itll be nice when we have a digital radar
altimeter). So lets assume were gonna be reaching the surface at about 2,820
meters. Nice and slow
We can see our shadow! Altimeter is reading 2,823 meters (dont know why I
cut that out of the screenshot). Still controlling throttle up and down to maintain
a low vertical velocity.
4.8. LANDING 189
And were down! Cut thrust ( x key) so it doesnt hop back up in the air.
And your landing is complete!
And it looks like we ended up where we wanted!

A brief recap:
Burn retrograde about 1

4 of an orbit before your desired landing site
Burn until your trajectory ends slightly beyond your desired landing site
Once you are over your landing site, burn retrograde to 0.0 m/s. You are
now falling straight down
Control descent (throttle up/down) to maintain both a reasonable velocity

and a good attitude for the vehicle
Check true distance to surface via radar altimeter in cockpit. Estimate

regular altimeter surface altitude.
Recheck true altitude/altimeter reading often during descent. Adjust esti-

mate accordingly.
Below 100 meters true altitude, keep speed low (less than 5 m/s).
Watch for shadow (day landing) or use lights on your vehicle (night landing)
to gauge visual distance to surface
4.8. LANDING 191
Try to land with less than 5 m/s of velocity (less than 3 m/s is even better)
Cut engines immediately upon touchdown
Call Mission Control and say The Eagle has landed! or some other mem-
orable phrase.
Suicide Burn
or How I learned to live dangerously!
A suicide burn is a very aptly named maneuver because in many instances it

will result in pieces of ships and/or kerbals strewn across the landscape.
My above landing procedure, while easy, is not even close to an efficient

landing. I used more than half of the fuel in the two stage lander to accomplish
that landing.
The most efficient way to land is to wait until the last possible moment, and
burn retrograde at full thrust in such a fashion that as you reach the ground,
you velocity is exactly 0.0 m/s (or low enough that things dont fall apart upon
touchdown).
I have two problems with suicide burns:
1. I dont know, with any degree of certainty, my exact altitude above the
surface. This information is crucial to know exactly when to start a suicide
burn (remember, you start it at the last possible moment)
2. I dont know, with any degree of certainty, how fast my vehicle can decel-
erate. This can be mitigated if Ive flown the same vehicle various times
and know how it responds. But remember that the vehicle will perform
differently depending on its mass. If I have full tanks, it will be sluggish, if
Ive already burned off have my fuel, it will be more responsive.
So, a suicide burn to me sounds like, well. . . just plain suicide (I guess the
burn part comes in when the explosion happens).
But we can work with this. . . instead of being super cautious (like I was above)
and decelerating to 10 m/s at 200 meters of altitude, you can semi-suicide and
let it ride until about 100 or even 50 meters, then burn full thrust to cancel all
that vertical velocity, and just be cautious those last 25-50 meters. Its really up
to you.
A suicide burn is nothing more than a launch in reverse and is truly the most
efficient (fuel-wise) method of performing a landing. I think an unassisted (i.e.
manual) suicide burn is just crazy. No one in real life would even attempt to per-
form such a maneuver without the assistance of a computer (MechJeb, anyone?),
but to each his own. It would be like giving the astronauts on the shuttle manual
control of engine gimbals to maintain the attitude of the craft during launch (yeah,
that would end well!).
I hope this information will help you on your way to planting flags on various
celestial bodies in the Kerbol system!
Thank You!
Thank you for reading this book! It was a joy to write and I anticipate the other
volumes will be the same.
Stay tuned for news on the next volume!
193

Kerbal Space Program - The Missing Manual - Volume I

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Kerbal Space Program - The Missing Manual - Volume I

Hochgeladen von

Copyright:

Verfügbare Formate

1

The information in this book is for informational purposes only.

Kerbal Space Program is a product developed by Squad. It is currently in

I am not a lawyer or a rocket scientist, nor am I affiliated with the pro-

Any advice that I give in this publication is my opinion based on my own

The material in this book may include information, products or services

As such, I do not assume responsibility or liability for any Third Party

The publication of such Third Party Materials does not constitute my

Publication of such Third Party Material is simply a recommendation

No part of this publication shall be reproduced or transmitted, in whole

By reading the information contained in this publication, you agree that

1 About the Author 9

2.1 What is Kerbal Space Program? . . . . . . . . . . . . . . . . . 11

2.2 About this book . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.3.2 Isp - Specific Impulse . . . . . . . . . . . . . . . . . . . 18

2.3.3 TWR - Thrust to Weight Ratio . . . . . . . . . . . . . 20

2.3.7 RCS - Reaction Control System . . . . . . . . . . . . . 33

2.3.8 SAS - Stability Augmentation System . . . . . . . . . . 34

2.4 Orbital Mechanics - The Mathy part . . . . . . . . . . . . . 35

4.1 Gravity Turn . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

4.2 Circularizing your Orbit . . . . . . . . . . . . . . . . . . . . . 87

4.2.1 Achieving Orbit . . . . . . . . . . . . . . . . . . . . . . 87

4.3 Changing your Orbital Inclination . . . . . . . . . . . . . . . . 96

4.4 Aerobraking . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

4.5 Rendezvous . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

4.6 Docking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

4.7 Gravity Assist . . . . . . . . . . . . . . . . . . . . . . . . . . . 174

4.8 Landing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178

About the Author

I am a software developer with 30+ years of experience. Over the course of

I am not a rocket scientist. I am simply an enthusiast of the game with

I strive to provide the technical content in a fashion that a layperson can

2.1 What is Kerbal Space Program?

Kerbal Space Program is an extremely fun and educational game. Having

2.2 About this book

The response to the blog was, well, underwhelming. So here I am again,

As I mentioned in the disclaimer above, Im not a rocket scientist, just an

If you happen to be a rocket scientist, or just someone smarter than me

Any contributions made by third parties will be fully credited in subse-

There are a myriad of concepts related to orbital mechanics, terminology,

delta-v means, literally, change () in velocity (v), and is simply short-hand

In comparison, a 2010 Chevy Camaro weighs

When it comes to the shuttle, we cannot use

Due to this inability to analyze the shuttle sys-

m0 is the total initial mass of the vehicle, including propellant;

Isp is the specific impulse for the engine(s)

g is Standard Gravity (9.8 m/s2 )

Every maneuver, performed by a rocket, has a specific amount of v

Low Earth Orbit (LEO) Earth-Moon Lagrange 1 (EML-1) 3,770 m/s

Low Earth Orbit (LEO) Earth-Moon Lagrange 2 (EML-2) 3,430 m/s

Low Earth Orbit (LEO) Moon 5,930 m/s

Table listing approximate v requirements within the Earth-Moon system

If you want to have an idea of how big of a rocket is needed to do that,

Thankfully, the developers at Squad realized that making the Kerbal

2.3.2 Isp - Specific Impulse

Our 1,500 kg rocket had 500 kg of propellant and I said 1,000 kg of

So in our example rocket, with 500 kg of propellant, if I double the amount

2.3.3 TWR - Thrust to Weight Ratio

Contrary to popular belief, a kilogram (or a pound, for that matter) is

What the TWR is specifying is,

If we modify our vehicle, by

I replaced the Poodle engine

But, there are a couple of things