Dismiss Notice
Join Physics Forums Today!
The friendliest, high quality science and math community on the planet! Everyone who loves science is here!

Aerospace Kerbal Space Program Tutorial

  1. May 22, 2014 #1


    User Avatar
    Homework Helper
    Gold Member

    "How hard can rocket science be anyway?"

    Kerbal Space Program is a sandbox type computer game that leans heavily on concepts of physics (don't let that scare you though, you don't need a calculator nor a book of equations to play it. It's ultimately very intuitive).

    Given the physics nature of the game, I figure there must be many PFers who play it. And being that the game is so open-ended, I would love to hear how others have fared in their Kerbal adventures. I figure this would be a good place to share your screen captures, success stories, failures, trials and tribulations with the game. (However, in an effort to be kind to Greg, if you have alot of images, preferably put them on the Internet somewhere first and then link to them here, rather than attach them directly to the post.)

    (Btw, I noticed there was another PF thread with the same name and subject that got closed. I'm guessing it was closed because the thread was posted in the Aerospace Engineering subforum. I'm posting this in "Fun, Photo & Games" which I'm thinking fits the appropriate content.)

    I don't know if it's because I used to build model rockets as a kid, or because I've been interested in physics and astronomy for most of my life, or because I play a lot of computer games -- and I do play a lot of computer games -- but less than two weeks ago, on a whim I bought the game on Steam, and I have to say that I have never been so captivated by video a game in decades, maybe ever, as I have with with Kerbal Space Program (KSP).

    [Here's Jebediah Kerman along with Bill Kerman (or is it Bob Kerman. I can't always tell the two apart) gallivanting around on one of their more recent missions to "the Mun" (one of the two moons of the planet Kerbin).]

    For those unfamiliar with KSP, it's an open-ended, sandbox type of computer game. By that I mean that there is no ultimate ending where you "win" the game. Instead, you are given things like rocket parts (and aeroplane parts), and you can put them together to build a rocket (or aircraft) as you see fit. What you do with it once you build it is completely your choice (assuming it doesn't crash or explode). You can try to visit other parts of Kerbin (Kerbal's home planet), try to get into orbit, try to go to a Kerbin moon or even another planet (or a moon of another planet). It's all left up to you, in any order (if at all). Whatever you'd prefer to do.

    Typically though, one starts small, and gets a rocket to work. Then you'll probably strive to get something into orbit. Then you might want to push yourself to transfer that orbit to a Kerbin moon, eventually gaining the skill to land on that moon and return to Kerbin in one piece. A long term goal might be to visit other planets in the system.

    And that's where KSP really shines: its implementation of orbital mechanics. It's difficult at first, but trust me, though trial and error you can easily gain an intuitive sense of things. Two weeks ago I barely knew terms like prograde, retrograde, inclination, ascending node, descending node, apoapsis and periapsis. But today, not only do I know the terms, I comprehend them intuitively. And I didn't even put any effort into it! After a few days playing KSP, it comes naturally! (I'm surprised by this as anyone else.) No mathematical calculations or equations are necessary. (Although you could use math and equations if you really wanted to -- the physics modeled by KSP is conceptually quite realistic).

    Orbital Mechanics
    [Source: Randall Munroe of XKCD, http://xkcd.com/1356/]

    So is it a game for a layman?

    Yes, I think so. A kid can play this game. Many kids do. There is a bit of a learning curve though. Don't expect to be an expert at everything right away. But don't worry, trial and error will take you far. This learning curve has its pros and cons:

    • Con: You have to learn new things.
    • Pro: You get to learn new things.


    The neat thing about that is what one learns in KSP can apply to real life here on Earth. I've gained a new respect for programs like the Voyager and Apollo missions. Conceptually, from a high level, the things you do in KSP are the same sorts of things that are actually done by NASA (and space programs of other countries). There are some exaggerations, of course. It is just a game after all: The Kerbal's "stabilizer" technology is more advanced than anything humans have; the jet-packs on Kerbal space suits or more than an order of magnitude more powerful than those of NASA; the planets are smaller and denser, etc. Yes, there are these differences -- it is a game after all. But conceptually speaking, the intuition gained is priceless. That includes not just orbital mechanics, but the stuff in rocket design like thrust to weight ratios, specific impulse etc.

    (Also it should be noted that the orbital modeling is in the form of conic patches, rather than true, n-body mechanics. But hey, it is just a game, and it doesn't need a extra beefy computer, but that leaves out Lagrangian orbits of course. But it's still good enough for government work.)

    The game is presently in its "alpha" release. In other words, it's not near its official release yet. But it's available for sale anyway in a early release version.

    Being that it's in its alpha phase, it is somewhat lacking in its in-game tutorials (there are some, but they are scant at best). That brings up another part of the learning curve: Early on, it's difficult to know what the game is even capable of doing. This has its own set of pros and cons.

    • Con: Sometimes you might struggle doing things the hard way, only to find out later that the game offers you many other ways to meet your goal, some of which are easy.
    • Pro: There seems to be no end to the game's joy of discovery.
    Case in point: For the first three or four days of playing the game, I had no idea that Kerbals had jet-packs on their space suits. Once while in orbit, one of the Kerbals got separated from his ship and drifted away. I created a new, special rocket with all sorts of ladders and stuff attached to it, that would make it easy to grab. I sent that rocket on a rescue mission to retrieve the lost Kerbal. Little did I know, I could have just switched over to the Kerbal and had him use his jet-pack to get back to the original ship. Doh!

    [Don't do this! It turns out Kerbals have jet-packs. If they get separated from the original ship, switch to the Kerbal (using the '[' or ']' keys), and press 'r' to activate his jet-pack.]

    For this part of the learning curve (and the previous part, for that matter), the Internet is your friend. Just type in "Kerbal Space Program" with quotes, followed by whatever question you have, and you're bound to find a plethora of Wiki pages, blogs and YouTube videos answering your questions. If you find a hit of a YouTube video by Scott Manley, go for that; his videos are comparatively well edited and he gets to the point quickly and stays on point.


    I'll get things started. Here are a few images after I restarted the game in "career" mode.

    [Here's Jeb on Minmus (the smaller of Kerbin's two moons). This is the first Kerbal on a moon (for me in "career" mode anyway).]

    [The rocket I've been using for most of the Mun and Minmus missions (on the launch pad). The first stage (orange part) is in what's called an "asparagus" configuration. By that, all the first stage engines (on the bottom) fire at once (all 17 of them). The outer four fuel tanks feed all the inner (13) fuel tanks until fuel is depleted in them (in the outer four). At that time, the empty, outer four tanks (including engines) are separated to reduce dead-weight, but now all the inner (13) tanks are completely full. Then there is a new set of outer four tanks that feed the inner (9) tanks, and the process repeats once again. (If you've played KSP before and wondering why I didn't use the heavy lifting engines, I'm playing in "career" mode and haven't unlocked them yet). After that, there is a second and third stage that are of the more conventional configuration. All except the fourth, very upper stage (consisting of the command module and lander module) are just to get into orbit around Kerbin.]

    [Laying in a course for the Mun]

    Here is the command module separating from the lander module.

    [Jeb and Bill/Bob doing sciency stuff.]

    [Jeb and Bill/Bob doing more sciency stuff.]

    [Lander docked with command module. Ready to return home with all the science goodness.]

    [On the way back to Kerbin.]

    [Once entering Kerbin's atmosphere, I separate the fuel-tanks and engines. Why did I carry that all the way back to Kerbin? Space junk. KSP keeps track of space debris, and I'd rather not have a bunch of space junk orbiting around if I can avoid it. This way it gets destroyed on descent, and I don't have to worry about it.]

    [Reentry. As of this writing, the game does not implement atmospheric reentry effects, besides drag, and the "showy" flames. I'm led to believe that the developers plan on introducing more realistic reentry effects in a future release of the game.]

    [It's good to be home. (This is actually from an earlier mission than the one's above).]

    On a recent mission I've tried my luck with getting a rover to the Mun.

    [Rover attached to the lander. On the other side is a fuel tank acting as a counterweight. It's not going to waste though, the fuel is to be transferred to the lander's main fuel tanks, once the rover is released.]

    [Jeb and Bill seem quite happy with the new rover. Unfortunately for them, I did a piss-poor job on its design. The rover tumbled out of control and crashed soon after this image was taken. Jeb and Bill barely escaped with their lives. Well, back to the drawing board.]

    [Jebediah Kerman on Minmus, looking home, musing over the existential angst of being.]
    Last edited: May 22, 2014
  2. jcsd
  3. May 22, 2014 #2
    I am going to think about getting this. I was initially scared off when a friend told me it can be rather complex. Thanks for making a tutorial for this game. It should be very useful!
    Last edited: Dec 18, 2014
  4. May 22, 2014 #3


    User Avatar

    Staff: Mentor

    New Wolfenstein is definitely easier.
  5. Jun 1, 2014 #4


    User Avatar
    Homework Helper
    Gold Member

    Efficient launch into orbit.

    Designing a small, simple, efficient and stable launch vehicle to get into Kerbin's orbit can be done pretty easily. But in order to avoid building oversized, overcomplicated, drag prone behemoths (like the one I was using in the first post of this thread), one first needs to know how to perform an efficient launch, in order to build a rocket that does so (rocket design post coming soon!).

    Unfortunately, this is where much information found on the Internet is misleading, or just plain wrong.

    Debunking section

    This is from the Kerbal Space Program Wiki site, iki.kerbalspaceprogram.com/wiki/. I suppose since it's a wiki, I could correct it myself, but I'm rather lazy like that.

    Claim: Upon reaching 10,000 meters: "Throttle your second engine down to 2/3rds power since the atmosphere is weaker here and won't slow you down as much, and you will save precious fuel."

    Truth: That's backwards. If anything, you should be increasing your throttle somewhat after reaching 10,000 meters. That actual amount depends on the specific rocket though, and how fast it's already traveling, so the "2/3" figure is pretty meaningless without more details about the rocket. My point is, holding back on the throttle is much more important in the lower, thicker atmosphere below 10,000 m than it is above it. Only continue to back-off on the throttle if you find yourself traveling at speeds greater than 300 m/s at the time when you hit 10,000 m altitude (the actual velocity depends slightly on the drag of your rocket, and you'd need pretty overpowered rocket for that to happen anyway, so 300 m/s is a good number for most any vessel). Terminal velocity increases quickly at altitudes above 10,000, which is why it's usually a good time to increase the throttle at this point. More on this below. ​

    Here is another one I heard from a YouTube video,

    Claim: When getting into orbit, all your original "upwards velocity" is lost/wasted. In achieving orbit, it's only the "sideways velocity" that matters.

    Truth: That's a little misleading. (btw, the terms "upwards velocity" and "sideways velocity" are not my terms; they were from the video.) It's true that it's wasteful to go straight up for too long when achieving orbit. But not for the same reasons. Orbital energy has two components, kinetic energy and potential energy. The "upwards velocity" (as it was called) eventually gets converted to potential energy, which gets stored in the orbit (albeit initially, an extremely eliptical orbit). The true losses come from a) performing a maneuver such that a component of the thrust vector is parallel to the gravitational acceleration vector (gravity losses), in other words, increasing the apoapsis at a location other than the periapsis. There is a loss associated with the component of thrust being parallel to the gravity vector, which is why prograde and retrograde maneuvers are most efficient at apoapsis and periapsis. Also, orbital energy is only increased by the component of the thrust vector (your heading when you apply thrust) that is parallel with the velocity vector, i.e., parallel to your orbital prograde vector. And similarly, since the initial orbit is so terribly elliptical, it will invariably involve the following: b) later when the orbit needs to be circularized, it must involve course corrections (perpendicular to the velocity vector) that are done at higher orbital kinetic energies. It is most efficient to perform course corrections at the point of lowest, orbital kinetic energy. By that, the gravity turn should be done earlier rather than later. The optimal transition tradeoff between course correction losses and drag losses happens almost invariably at around 10,000 m altitude (specifically with Kerbin). So in conclusion, there are losses associated with this "upwards velocity" but it's not a total loss. I do agree however with the author of the video that going too far straight "up" is wasteful. ​

    "Optimal" (or at least quite efficient) method for achieving orbit (on Kerbin specifically)

    1. Go straight up for the first 10,000 meters. During this time, adjust your throttle to limit your speed. If you go too fast you'll be wasting much or most of your thrust (and thus fuel) to drag forces. The velocity limit changes with height (altitude). At the initial lauch, start off at full throttle, but be prepared to quickly lower the throttle. I can't tell you how much "% throttle" you should adjust to, because it depends on the rocket. Rockets with very high thrust to weight ratio (TWR) will need to throttle back more. Rockets with very low TWR might not need to throttle back much if at all. Here are some general guidlines that should apply to most (nearly all) rockets:

      Below 1000 m, don't travel faster than around 100 m/s
      Below 3000 m, don't travel faster than around 130 m/s
      Below 7000 m, don't travel faster than around 200 m/s
      Below 10,000 m, don't travel faster than around 300 m/s
      Below 12,000 m, don't travel faster than around 400 m/s

      Note that the craft's speed will naturally increase as its mass decreases from less fuel. Increasing speed isn't necessarily a matter of increasing throttle, but often a matter of decreasing the throttle less frequently. After about 12,000 meters allow your rocket to increase speed fairly quickly. You would have to go out of your way to design a silly rocket with ultra high TWR and horrible drag such that you couldn't be at full throttle by 20,000. For any reasonable rocket, you should go to full throttle by about 15,000 m or so, if not before.

      [Figure 1. First 10,000 meters]
    2. We need to step back a little to the 10,000 m altitude point. At 10,000 meters, take a relatively sharp turn to the East (right). (You might still be throttling your engines at this point, so there's more than one thing going on here.) This adjustment is called "the gravity turn, or "gravity roll." Turn until your rocket is pointed about 40-45 degrees above the horizon. Now, you may ask, "is it possible to optimize this, instead of a blanket statement 'turn 45 deg right at 10,000 m'?" Yes, in truth it is possible to optimize it. But it's hardly worth it. The optimal solution in almost every case is something very similar to "make a relatively sharp right to 45 deg at 10,000 m," regardless of your rocket. You could put in the math and fluid dynamics to optimize it, but it's hardly worth the trouble, and you won't gain much by doing so. Suffice it to say this: if your rocket is extremely underpowered, with a very low thrust to weight ratio (TWR), you may need to start your gravity turn a little below 10,000 meters, and a little more gently. For everything else, it's a fairly sharp turn at 10,000 meters.

      [Figure 2. Start gravity turn]

      [Figure 3. Continue gravity turn]
    3. If and when your prograde vector passes your heading vector (you can see this on the navball), change your heading to stay on top of your prograde vector. Continue this until your altitude is about 20,000 meters or so. Remember, you are increasing your orbital energy by aligning your heading (thrust vector) and your prograde vector.
    4. Above 20,000-40,000 feet, adjust your heading such that it lies in between the prograde vector and the artificial horizon on the navball. At this altitude, drag forces are pretty negligible for the velocities we're presently at. But there is another trade-off. Like I keep mentioning, it's only the component of the thrust that's parallel to the prograde vector that adds energy into the orbit. But since you're not at apoapsis, there is also some gravity loss since you're not traveling parellel to the horizon. So we reach a compromise by angling the ship to point in-between the two. Continue this until your desired apoapsis is reached (at least 70,000 meters).* Once a desired apoapsis is achieved, you can cut the engines.
    5. If you've been to orbit before, and you are familiar with the "maneuver node" tool, now is a good time to use it. Set up a prograde maneuver at your apoapsis, and bring up your periapsis. Using the maneuver node tool is nice because it estimates the burn time for you. If you are not familiar with the maneuver node tool yet, this might not be the best time to experiment with it. So alternatively (without the maneuver node tool), prepare to burn prograde sometime before you reach your apoapsis and continue burning until your periapsis rises to its desired level. The amount of time that you start the burn before reaching your apoapsis depends on your rocket. But as a rough guess, somewhere around 30 seconds or so is typical.

    *(If you're trying to win an efficiency contest, you might gain a tiny bit by only bringing your apoapsis in step 4 to only about 63,000 meters or so, then follow through with step 5, and finish up with circularizing the orbit with a Hohmann maneuver on the other side. But that's efficiency overkill if you ask me.)

    Here's a summary of the above looking at the map view.

    [Figure 3. Gravity turn, map view]

    [Figure 4. Prepare to sync up with velocity vector]

    [Figure 5. Drag forces becoming negligible. Increase thrust in the prograde direction to add energy to the orbit.]

    [Figure 6. Remain at maximum thrust in the direction between prograde and the horizon.]

    [Figure 7. Continue the same until desired apoapsis is achieved.]

    [Figure 8. Once desired apoapsis is achieved, set up a maneuver node to finish it off, or alternatively, burn prograde near apoapsis]

    [Figure 9. Thrust, and how it relates to position relative to apoapsis]

    Things can get tricky in step 5 if your rocket is very underpowered. If you don't have the thrust to bring your periapsis up, you might find yourself in trouble. If you find yourself far past apoapsis, and still don't see a periapsis, keep your heading slightly on the blue side of the artificial horizon (on the navball). It's a little wasteful that way, but it might just buy you some time.

    [Figure 10. Thrust with an underpowered (low TWR) vessel]

    At the risk of being redundant, orbital prograde and retrograde maneuvers are the only way to increase and decrease the energy of an orbit (assuming no other forces are involved like drag). I repeat it because it is kind of important. If you ever do a purely radial or normal maneuver, you only change the shape of the orbit. That might be difficult to tell with the maneuver node tool, because it assumes that the thrust vector remains constant, even though the planned velocity vector changes accordingly (thus the velocity vector will eventually contain prograde or retrograde components parallel to the thrust). But if you were to adjust the ship's heading (and thus thrust direction) to always remain perpendicular with the velocity, you would never change orbital energy by only radial or normal maneuvers (and assuming that the orbit does not pass through a solid surface such as Kerbin, with the ship in that part of the orbit).

    (The 10,000 meter gravity turn figure, and the rough terminal velocity figures mentioned above were from experimenting with version v0.23.5 of the game. It's possible that these numbers might change in future game versions if the game's aerodynamic modeling is changed.)
    Last edited: Jun 2, 2014
  6. Jun 2, 2014 #5


    User Avatar

    A minor nitpick - I've noticed that KSPers in general seem to really like to use the term "gravity turn" when what they actually mean is "pitchover". The pitchover is where the rocket's trajectory turns away from vertical, and begins to follow the desired ascent profile to orbit. Ideally, to minimize steering losses, you want to start it as early as possible (much earlier than 10km), but the initial pitchover in such a flight path is much less extreme than your example as well so the first 10-15km or so of flight ends up being pretty near vertical anyways.

    A gravity turn is a careful optimization of the entire post-pitchover ascent profile, designed such that the rocket's thrust is always aligned with its direction of travel throughout the ascent. I don't think I've ever seen someone pull one off in KSP, in part because it is different for each rocket design. The basic idea however comes from the fact that for any rocket in a non-vertical orientation, the acceleration in the horizontal direction is simply F/M multiplied by the sine of the angle (I'll call it A) the rocket is pointing away from vertical, but the acceleration in the vertical is F/M*cos(A) - g. If we start from a stationary position, this will result in a trajectory with an angle away from vertical equal to arctan((F/M*sin(A))/(F/M*cos(A) - g)). If you're familiar with trig functions, you'll notice that because (F/M*sin(A))/(F/M*cos(A)-G) is bigger than sin(A)/cos(A), the resulting angle away from vertical will be larger than A, so the trajectory of an angled rocket will tend to be flatter than you would expect purely based on the angle of the rocket.

    If you start with a rocket flying vertically, you can take advantage of this fact when making your turn towards orbit - after you pitchover (usually not by very much for real rockets - only a few degrees), the trajectory begins to angle over as well. When the trajectory passes the current pitch angle of the rocket, you begin angling the rocket to track the flattening of the trajectory, such that the rocket post-pitchover is always flying at zero angle of attack. This is a very good thing, since it minimizes non-axial loads on the rocket, and it eliminates steering losses after the pitchover (in your example, when you first pitch over at 10km, only 71% of the rocket's thrust is actually acting in the direction of travel, so you have pretty substantial steering losses for a period of time after that). The difficulty however is figuring out at what altitude to perform the initial pitchover, as well as how much to deviate from vertical. If done correctly, the trajectory will flatten due to gravity at a rate such that the rocket ends up horizontal at the desired altitude and at the correct time after launch to achieve orbit. This is also why it is called a "gravity turn" - you are never using the thrust of the rockets to alter the trajectory - you are always burning exactly along your trajectory, and using gravity to steer the trajectory into orbit.
  7. Jun 2, 2014 #6


    User Avatar

    Oh, and as for your figure 10, if you're flying that rocket the same way you were discussing before (45 degree pitchover at 10km), you probably can get it to space if you just adjust your ascent profile into more of a lofted trajectory. This involves intentionally staying a bit more vertical for a bit longer near the beginning of the flight, and making a more gradual turn towards orbit. This gives you a higher initial apogee, and (hopefully) a bit more time to burn at wide open throttle with your underpowered upper stage to build enough speed to make orbit. This is actually done with the Delta IV and Atlas V, if I remember right, since they have highly efficient but relatively underpowered second stages. You do burn slightly more fuel this way than with an optimal trajectory, but sometimes the smaller, lighter engine you can get away with more than makes up for the fuel difference.
  8. Jun 2, 2014 #7


    User Avatar
    Homework Helper
    Gold Member

    The neat thing about Kerbal Space Program (KSP) is how easy it is to experiment. Just build a rocket and try things out! :smile:

    A good measure of Kerbin launch efficiency is how much fuel the rocket has left once it completes circularizing a given, desired orbit around Kerbin. It's easy enough to jot down the remaining fuel from one trial to the next, then use the data for comparison.

    Try different approaches, and see which works best! :smile: (Preferably by changing a single variable at a time, and using scientific method.)
  9. Jun 3, 2014 #8


    User Avatar

    Oh, believe me, I have. It isn't quite as brutally realistic as Orbiter, but it's realistic enough to teach a fair amount about orbital mechanics without the frustration inherent in a more accurate sim (like Orbiter). I also love the cartoonish aesthetic (especially the kerbals), and ease of building new rockets. I was mostly just complaining about inaccurate use of terminology, and giving you some suggestions on how to get a rocket with an underpowered second stage to a stable orbit. It's a great program though, and I definitely think it's a wonderful way for people to learn about spaceflight and orbital mechanics.
    Last edited: Jun 3, 2014
  10. Jun 4, 2014 #9


    User Avatar
    Homework Helper
    Gold Member

    I just took a look at the navball in the images I posted in the last post, and I think I can clear up some confusion by noting that the image in the first pitch-over showed the surface velocity vector. Perhaps I should have clicked on the navball to switch over to orbital velocity before taking the screenshot. (My bad for the confusion.)

    When I made the comments about following the velocity vector after the pitch-over/gravity turn, I meant the orbital velocity vector, not the surface velocity vector. (I agree I should have made that more clear in both the text and the image.)

    I hope this image might clear up some confusion.


    I was talking about two things at once. There's a lot going on when you do the pitch-over (beginning of gravity turn), and I only used one image to convey multiple things.

    At the time of take-off, the rocket has 0 surface velocity. But it already has significant tangential, orbital velocity due to the rotation of Kerbin.

    When throttling down to keep at or below terminal velocity, one should monitor the surface velocity speed, since that's a more accurate number relative to the rocket's speed relative to the atmosphere. When I said, "go straight up," I meant that in terms of the surface.

    But when I said "follow the prograde velocity vector" (and eventually place the ship's heading in between the prograde vector and the horizon) I meant the orbital prograde vector, not the surface prograde vector.

    KSP will automatically switch from surface speed (and surface prograde vector) to orbital speed (and orbit prograde vector) at some given altitude. Or you can switch between them manually, by clicking on the box above the navball, circled in red in the above image.

    Sorry, I wasn't very clear about that in my last post.

    cjl, we're on the same page. :smile:
  11. Jun 8, 2014 #10


    User Avatar
    Homework Helper
    Gold Member

    The Little Rocket That Could

    [Figure 1. Check this **** out.]

    This post illustrates an example of KSP rocket design. The following are the rocket's design goals:

    • Get three kerbals and a bunch of science items to the Mun, in an Apollo style mission: such that two kerbals (and science) land on the surface, one remaining in orbit.
    • All three kerbals are to return.
    • The science equipment must also land on the Mun and be returned to Kerbin.
    • The rocket should get the job done comfortably, and have carry enough fuel to cover a margin of error, in case things don't go according to plan, or modifications need to be made to the flight plan.
    • While the rocket design is not minimal, it shouldn't be wasteful either. It should be designed to get to the Mun comfortably, with a reasonable margin of extra fuel, but no more.
    • Only stock parts allowed on the rocket. i.e., no modded parts.
    • Effort is placed on only using parts that are on the early and mid tier levels of the technology tree, with only a few exceptions, discussed individually below.

    Why an Apollo style mission? Here are some weak, advantages and disadvantages for an Apollo style, two-ship system:

    • There is the potential to save a little bit of fuel, since it is not necessary to land and re-orbit the fuel required for the return trip (and thus, also, the extra fuel required to move the fuel). It turns out this is not that big deal for the Mun due to such low gravity, and close proximity to Kerbin (still within Kerbin's gravity well). But it is a factor none the less.
    • It is good practice for interplanetary voyages involving planets with higher gravity, where a two-ship system's advantages are greater.
    • It's good practice for docking.
    • It lets me demonstrate concepts involved in rendezvous and docking, in a subsequent post.
    • It's kinda cool? I don't know.
    • An Apollo style mission is inherently more complicated because it involves "docking" in orbit. If you are just starting out in KSP, a rendezvous with another ship in orbit, followed by docking, is one of the more advanced aspects of KSP. On the other hand, if you can rendezvous and dock with another ship in orbit, you can do pretty much anything in KSP.

    Why land two kerbals on the Mun instead of just one? Maybe to keep each other company? Or maybe two kerbals on the Mun make for better images for threads like these. I don't know. But I'm going with it.

    Mid/upper stage section

    Figure 2. shows the upper stage of the rocket. This consists of the two parts really, the lander module and the command/service module. The science payload is a little tricky, since it gets shuffled between the two; it starts out on the lander module, and is later to be transferred to the command module.

    [Figure 2. Upper stage of the rocket. This is the stuff we wish to get in close proximity to the Mun.]

    When designing the rocket, start with the mission's end, and then work backwards. Since this ship is broken into two parts, it's slightly more complicated, but I'll start with the command module since that will be returning to Kerbin.

    [Figure 3. Command/service module, top view. The command module is based on the Mk1-2 Command Pod.]

    Notice the docking port on top (Figure 3). That's how it should look when attached to the command pod (more on that later). Figure 4 details the parts.

    [Figure 4. Command/service module.]
    • Docking port: This will eventually dock with one of the two science payload's docking ports, together with whatever is left of the lander.
    • Battery: You can use any battery; just use a lower tech one if you haven't unlocked this one. Put it anywhere on the command/service module (it doesn't even need to go on the command pod itself, just somewhere on the command pod side of the science payload). Various instruments need electrical charge to operate, and a battery is good for those times where the sunlight is obstructed. When one first starts playing KSP, it usually happens that the craft will suddenly lose attitude control, and the player will say, "hey, craft won't respond to my keypresses. Maybe it's a bug," but more likely the craft simply ran out of electrical power. SAS (stability augmentation system) needs electricity to work.
    • Parachutes: Parachutes do need to be attached to the command pod.
    • Ladders: For kerbals to crawl around on. They will be handy for when kerbals are transferred to and fro the lander module. They're not absolutely necessary, since kerbals can use their jetpacks, but they are convenient.
    • Decoupler: Allows jettisoning the fuel tank and engine before re-entry (fewer parachutes required that way, if for no other reason).
    • Monopropellant: That's the RCS thruster fuel.
    • RCS thrusters: Stands for "reaction control system." This is actually a real acronym (not just in the game). These are the maneuvering thrusters for attitude control and can also function for lateral movement. Since we are going to rely on the command pod's built in reaction wheels (SAS, stability augmentation system) for attitude control, we will use these mostly for lateral movement. They are almost essential for docking (docking without RCS is masochistic at best). The plan is to maneuver the lander for docking maneuvers, but it's good to have RCS capabilities on the command/service module too, just in case.
    • Solar panels and arrays: Various instruments require electricity to operate (such as SAS). These generate that electrical power. Why both? Extending the solar arrays requires electricity. The solar panels are there so just in case I forget to extend the solar arrays early on, I'll at least have enough power to extend the arrays.
    • Engine: The engine is one of the smaller engines. That's all that is needed.

    Note that we really do not need much fuel for the return trip. We can reduce a lot of orbital energy using atmospheric breaking on the way back to Kerbin. We should have plenty of fuel for the return trip, even with that, small fuel tank.

    Figures 5 and 6 show and detail the lander module.

    [Figure 5. Lander module, top view.]

    I make note of the docking ports because it's really not clear in the game's instructions which side is the docking side and which side permanently attaches to the rocket. I've had to de-orbit an entire space station because I accidentally put the docking ports on backwards. If placed correctly, you should see a black line and some sort of metal looking handle thing. If you see a yellow triangle, you've got it on backwards. This is true for the regular sized, Clamp-O-Tron Docking Port, and the larger, "Senior" version. (For the smaller, "junior" version refer to the regular sized version, since they share the same basic shape).

    [Figure 6. Lander module.]

    Let's break that down into smaller pieces. Recall that when designing a craft, work backwards. Since we've already discussed the vessel getting back to Kerbin (from the Mun's high orbit), let's discuss the part of the lander that needs to dock with the command/service module. This core of the lander is shown in Figure 7.

    [Figure 7. Lander core. The lander core is based around the Mk2 Lander-can.]

    • Upper, science payload, docking port: This will dock to the command module on the return trip.
    • Science payload: This is just a bunch of stuff for accumulating science points. Load it up with whatever science stuff you've unlocked (except for the barometer and atmosphere stuff. There's not atmosphere on the Mun. On the other hand, you might be able to use the barometer and atmospheric stuff on the final, Kerbin descent).
    • Lower, science payload, docking port: This could be substituted with a decoupler. But a docking port has advantages. It's lighter, and also will allow the command module to have a docking port on its nose, in case the crew decide to get some R&R at Kerbin Station (Figure 8) on the way back. But that's another story.
    • Battery: Once again, feel free to pick a different battery type if desired, or if the type I chose isn't unlocked.
    • Remote Guidance Unit: The Remote guidance unit is completely optional. I included it so that we can hurl the remainder of the lander at the moon before returning to Kerbin (to reduce orbiting space junk/debris). It is not necessary though. We should have plenty of fuel left to take the remainder of the lander back to Kerbin with us, and drop it in Kerbin's atmosphere. Include it if you want.
    • SAS (stability augmentation system). The lander pod already has some built-in SAS, so why have another module? Two reasons: (a), it gave me a place to attach the ladder, and (b) SAS helps keep the rocket from tipping over. I'm not the best at landing, and sometimes there's significant horizontal velocity when the craft touches down. SAS helps prevent the craft from flipping over in such situations. If the craft flips over, nobody will be coming back, barring a rescue mission. So, what is SAS really? Think of it has three, big gyroscopes, one for each axis that can control the ships attitude. This is not science fiction. Humans have this technology. However, the Kerbal's versions are more powerful.
    • Lights: The light pointed upward is for docking. The other lights are just to illuminate the surroundings on the Mun's surface.
    • Monopropellant: That's the RCS thruster fuel.
    • RCS thrusters: In case you didn't catch this above, "RCS" stands for "reaction control system." This is actually a real acronym (not just in the game). These are the maneuvering thrusters for attitude control and can also function for lateral movement. Since we are going to rely on SAS (stability augmentation system) for attitude control, we will use these mostly for lateral movement. They are almost essential for docking (docking without RCS is masochistic at best).
    • Solar panels and arrays: These generate that electrical power.
    • Ladders: Easier to move kerbals around.
    • Antenna/transmitter/communication system (not shown in the figure): You also might want to put some sort of communication system on the craft. They're useful for things like multiple EVA reports and crew reports.

    Note that the lander core has no engines and no rocket fuel. That's because once in Munar orbit, the RCS thrusters are enough to transfer from low orbit to high orbit, rendezvous with the command module, and then dock with it.

    [Figure 8. Kerbin Station, but that's another story.]

    Back to our design. So now we've designed the ship to go from low Munar orbit, all the way back to Kerbin. Now we need to design what's needed to get off the Mun's surface, and at least into the Mun's orbit. That's shown in Figure 9.

    Figure 9. Munar launch engines and fuel tank]

    Notice that there is decoupler involved. If all works out well, we won't even use it. It is there just in case we run out of fuel and resort to RCS thrusters. Dropping the tank reduces mass. Reducing mass increases acceleration for a given force.

    Now we need the capability de-orbit and land on the Mun. We can't use atmospheric breaking, so all the fuel necessary to de-orbit and land, we need to bring with us. That equipment is shown in Figure 10.

    [Figure 10. Mun landing tank and equipment.]

    • Decoupler: One way or another, we will separate this section before reaching reaching Munar orbit on ascent. We might just leave it on the Mun before starting ascent. Either way, this section is destined to stay on the Mun, be it in one, solid piece or many broken pieces.
    • Landing struts: Well, that's sort of obvious.
    • Lights: Those landing lights can be quite useful. They give you an indication when the Mun's surface is approaching indicating that it's time to pour on the thrust (or if its already too late). They are also pretty essential for landing on the dark side of the Mun or in a dark crater.
    • Rocomax Mark 55, radial mounted engines: They have a good amount of thrust for their weight. Sometimes when landing, that Munar surface can come at you pretty quickly. Not to mention, that higher thrust is more efficient, since it reduces gravity losses again (there will be a component of the thrust vector parallel [technically anti-parallel] with the gravitational force vector). Once again, we're in a situation where higher thrust is good.
    • Modular girder segments: Gives the lander a nice, wide stance. I'm paranoid about the landers tipping over on landing, and a wide stance is always welcome.

    So far, we have the design from low, Mun orbit, landing, back to high Mun orbit and then all the way back to Kerbin.

    So now we need to design necessary components to get from Kerbin's orbit to the Mun. That's described in Figure 11.

    [Figure 11. Rocket, mid-stage.]

    The purpose of the mid-stage is as follows:
    • Burn at Kerbin's orbit to transfer to Mun's gravity well.
    • Burn at Mun's gravity well to create a high, Munar orbit.
    • Bring lander module to a low, Munar orbit. (Hopefully)
    • If there is any fuel left, aid landing module in initial descent to Mun. (Optional, but would be nice.)

    Note that we have not added any special equipment to de-orbit this stage, if it doesn't happen to be on a Munar collision course. If we need to, we can put it on a collision course with the Mun by enabling the Mark 55 engines on the lander before separation. More on this later when I discuss "action groups" below.

    So now we're ready to build the launch vehicle.

    [Figure 12. Launch vehicle, center tank]

    All the extra stuff in Figure 12 is optional. This tank and its engines (more below) will almost assuredly reach orbit. Which means if there is no way to de-orbit it, it's going to get left as orbiting space junk.

    If you haven't unlocked parts such as the remote guidance unit, there are other options. (a) Before bringing the rocket's periapsis up to above 70,000 m, separate from the stage whether or not it has any fuel left. You might need to "fly" it later from the tracking station, because KSP seems to presently ignore atmospheric drag unless the thing in question is being "flown." It might take awhile for the orbit to decay, but it is an option. Or, (b) leave it as space junk and clean it up later with a special space-junk-cleaning mission, once you unlock the advanced grabbing unit (AGU), and efficient engine like the atomic rocket motor. Or (c) just leave it as orbiting space junk, if you don't mind orbiting space junk.

    Before moving on, allow me to describe how to build an efficient engine "cluster." Start with the smallest, Rocomax 200 sized tank.

    Engine cluster section

    [Figure 13. Engine cluster part 1]

    Attach a small, structural cube thing (Cubic Octagonal Strut) to the bottom edge of the tank.

    Surprisingly, this small, cube strut (Cubic Octagonal Strut) is the most advanced item in the technology tree that I'm including in this design. If you haven't unlocked it yet, feel free to skip this whole cluster section, and replace them with Mainsail engines.

    The clusters have an advantage over the Mainsail engines do to the clusters' greater thrust, higher efficiency, and greater design flexibility. But it's not a huge difference. The Mainsail's lighter mass makes up for a good part of the difference. The Mainsail engines will still get this rocket into orbit.

    [Figure 14. Engine cluster part 2]

    Place a LV-T30 Engine on the strut. (This is the more powerful, lighter engine of the two LV-T engines; it's the one without gimballing/thrust vectoring).

    [Figure 15. Engine cluster part 3]

    Place a structural adapter on top for aesthetic purposes (optional). Note that this is completely cosmetic. The element actually adds weight and drag. Skip it if desired.

    [Figure 16. Engine cluster part 4 (optional)]

    Now grab the assembly by the original strut and place it aside. (Don't worry, there is some reason behind this madness.)

    [Figure 17. Engine cluster part 5]

    Now put another strut and engine in the center. But this time, use the LV-T45 Engine. The "45" engine adds a little thrust vectoring which can help us steer (when the engine is on). Although it's heavier and less powerful than its "30" sister.

    [Figure 18. Engine cluster part 6]

    Now grab that other "30" assemby that you put aside a moment ago, and begin to put it back were it was. But before actually placing it back ...

    [Figure 19. Engine cluster part 7]

    ... Before clicking it back to position, hit the "x" key to cycle through different symmetries.

    Instead of putting the LV-T30 assembly aside, you may be tempted to turn on the symmetry at the beginning, and place all the parts in groups of 4. There is a problem with doing it that way. The game will often not let you put the part on. If it rejects any one of the four parts you are adding, you will not be able to put any on.

    I find it much easier to build up just one, single assembly first. Then cycle the symmetry at the very end, once the first assembly is complete. That trick save a lot of time and frustration.

    [Figure 20. Engine cluster part 8]

    I chose the x4 symmetry for this rocket. But you could surround the center engine by 2, 3, 4, or even 6 engines. Six surrounding engines is overkill for this particular rocket; More thrust than we need. We're better off here with less mass/weight via using only four surrounding.

    [Figure 21. Engine cluster part 9]

    Once completed, grab the small fuel tank and place the entire thing in its own Vehicle Assembly part. That way, you can easily reuse it, without having to rebuild it.

    [Figure 22. Engine cluster part 10]

    Note that there are many different combinations. If you want more steering capability, put the LV-T30 in the center and surround it with LV-T45 engines. I chose the LV-T45 in the center surrounded by LV-T30 engines, because that cluster is a little more powerful and lighter. Most of these engines are used when we're going straight up and don't need a lot of steering anyway.

    Although engine clusters have higher thrust and greater efficiency than the Mainsail engine, they are much heavier. Clusters make great first stage engines and first stage boosters. But due to their weight, keep them away from all upper stages. You're better off with the conventional, stock engines for any engine that's not firing immediately at take-off.

    Asparagus staging section

    Asparagus staging offers advantages in KSP, and even in real-life (SpaceX Falcon Heavy uses the concept to some extent. http://www.spacex.com/falcon-heavy).

    The idea behind asparagus staging is this: as long as you are carrying around engines, you might as well use them. And once a given pair of fuel tanks are empty, drop them and their associated engines to reduce weight. And finally, cross-feed the propellent such that the remaining tanks remain full (or at least fuller than otherwise) at the time of separation.

    We start with making a single booster, and then we'll hit the symmetry button ("x") later, to add on the asparagus stages in pairs.

    We start off in Figure 23 with the girder and radial decoupler.

    [Figure 23. Asparagus staging, part 1]

    Add a tank.

    [Figure 24. Asparagus staging, part 2]

    Add a nosecone and engine cluster. Note: The nosecone is completely cosmetic. It actually adds mass and drag. (At least for this version of KSP, until the developers redo their treatment of aerodynamics). Skip the nosecone if you wish.

    Then click on the girder, and hit "x" to cycle to by-2 symmetry. We will put these asparagus stages on in pairs.

    [Figure 25. Asparagus staging, part 3]

    [Figure 26. Asparagus staging, part 4]

    Press and hold the Alt key for copy-click.

    "Alt" specifically if you on a PC.
    "Option" specifically for the Mac.
    "Win" specifically if you're on a Linux system.

    [Figure 27. Asparagus staging, part 5]

    Repeat that step until you have three pairs of asparagus stages.

    Then click on the FTX-2 External Fuel Duct to indicate the direction of the fuel transfer.

    Keep the "x2" symmetry on, and it will automatically take care of the both engines in a given pair at once.

    With the FTX-2 Fuel Duct selected, click on one of the first asparagus stage tanks and then on of the second asparagus stage tanks. Notice the arrow. That indicates the direction of fuel flow.

    [Figure 28. Asparagus staging, part 6]

    Do that again, but this time go from the asparagus second stage to the asparagus third stage.

    [Figure 29. Asparagus staging, part 7]

    One more time, but go from the asparagus third stage to the center tank.

    [Figure 30. Asparagus staging, part 8]

    At this point, check the staging on the right and side, and make sure things get staged in the correct order. You might need to move things around substantially.

    Then add some struts. Don't strut together asparagus stages to each other though! It will cause problems when the second asparagus stage separates; struts can pull the second asparagus stage tanks into the third, possibly causing damage. Only connect struts from the asparagus stages to the center stack.

    [Figure 31. Asparagus staging struts]

    Finish off by adding a couple of solid rocket boosters (SRBs) and some wings/fins. Recall, for the engine cluster configuration, I chose power/efficiency over thrust vectoring. We're going to need to steer this thing, which is why I added the wings/fins. they'll be useful as long as we're in the atmosphere.

    I also added a SAS module atop each of the asparagus stage 3 boosters. We're going to need to steer this thing when the pitch-over/gravity turn happens.

    [Figure 32. Final touches]

    When it comes to the staging of the SRB's, there's a problem. We don't really know when the SRBs will be depleted relative to the asparagus stages. For that reason, I put control of the SRBs' radial decouplers using the "Action groups." Then in my staging order, I moved the SRBs' radial decouplers up high.

    Action groups can be extremely useful for things like this. You can use them for things like this (unconventional staging), or to group many items to work together as a group.

    [Figure 33. Action groups]

    I use Action Groups in the following way.
    Pressing '1' causes the SRB separation.
    Pressing '2' toggles the Rocomax 24-77 engines on the lander module.
    Pressing '3' toggles the Mark 55 engines on the lander (the main, lander engines).
    Pressing '4' toggles all solar arrays on the vessel.
    Pressing '5' toggles all extendable ladders on the vessel.

    Eventually, that lander is going to be docked with the command/service module, but it's engines then face the opposite direction. In this situation, it is important to disable the lander module's engines if you want the service module engines to do anything useful. (you could disable them individually by right clicking on them one at a time. But Action Groups makes this much easier).

    And our rocket is complete.

    [Figure 34. Rocket is complete]

    Here it is on the launch pad, from below ('looks kinda ominous from this perspective).

    [Figure 35. Rocket from below]

    But it's really a pretty small rocket. Sure, it looks big when compared to Jeb....

    [Figure 36. Rocket compared to Jeb]

    [Figure 37. Jeb posing with rocket]

    ... But it's really not that big after all.

    [Figure 38. Ready to launch]

    (Trip to the Mun coming soon!)
    Last edited: Jun 9, 2014
  12. Jun 18, 2014 #11


    User Avatar
    Homework Helper
    Gold Member

    "One of these days, Alice. One of these days, ..."

    BANG, ZOOM! Straight* to the Mun!

    Part One: Launch revisited.

    * Okay, maybe not "straight" to the Mun; rather we'll use controlled, transmunar** injection burns.
    ** More on this terminology later in part two.

    So we've built a Mun rocket. Let's see what she can do.


    The purpose of this series of followup posts is to
    1. Continue on from the last post, showing how Kerbal Space Program (KSP) rocket design choices can effect the actual mission details.
    2. Tie together the rocket design discussion and the launch discussions.
    3. Introduce KSP's implementation of orbital mechanics. KSP shines because of its intuitive, and realistic use of orbital mechanics. And we haven't even discussed that yet!
    4. Introduce the maneuver node tool.
    5. Introduce rendezvous and docking.

    Disclaimer section:
    • All images in this series were captured using Kerbal Space Program (KSP) version 23.5. It is likely that soon, some of the material presented here may become outdated as future versions of KSP are released.
    • I'm kind of ignoring aerodynamics to some extent. KSP version 23.5 doesn't treat aerodynamics extremely realistically just yet. And what's more, the available stock parts in version 23.5 don't include aerodynamic fairings (except automatically around upper stage engines), so it's not presently possible to design a very aerodynamic rocket, even if we wanted to. Well, not until a future version of KSP is released that addresses the present aerodynamic constraints.
    • Since the first post of this thread, I have installed two "mods," one being "Astronomer's Visual Pack V3 BETA" (which leverages another mod called the Eve mod) that makes the atmosphere's look nicer. Clouds are added to Kerbin, for example, and other visual effects are added such as aurora. There's no effect on gameplay, however. It's purely visual changes. I've also added the "Enhanced Navball" mod. This adds the normal and radial vectors to the navball, and "ghosts" a couple of vectors if those vectors point on the other side of the ball. This doesn't really have any effect on gameplay either, besides displaying a bit more information on the navball. I'm not really into mods, but I think these two are good to have.
    • As a reminder, the ship we're using is not minimal. It's comfortable. The ship technically has enough space to get five kerbals to the Mun and back (two of them landing on the Mun in the process). If all goes well, there should be plenty fuel to bring the lander module back with the command module if need be. If you're trying to get to the Mun yourself, don't think that a rocket needs to be this big or bigger. You can make it much smaller. If you wish, consider landing just one kerbal based around the Mk1 lander can. If you still want to do a separate command module consider using the Mk1 command pod for that (you'll still need to send and return each kerbal in their own, separate pod of course). Doing it this way can make the upper stage much, much lighter. By making the upper stage lighter all the lower stages can be made lighter by the same fraction. It most certainly can be done. Of course, although it means you'll have to shove a couple kerbals into tiny tin-cans barely bigger then they are for a week or two, it certainly is possible you ruthless tyrant. (Then again, oddly enough, kerbals don't seem to mind that sort of thing.) No, the ship used here is not minimal, it's comfortable. As a matter of fact, it's downright luxurious.

    Okay, let's go. (Or perhaps better, I should say, "all systems go")

    For the crew, we've chosen
    Jebediah Kerman
    Bill Kerman
    Bob Kerman

    Bob Kerman is to be the command module pilot, and Bill and Jeb will EVA (extra-vehicular activity) over to the lander module when the time comes.

    [Figure 39: We have liftoff.]

    I'm throttling down to about 80%, but that's specific to this rocket.

    [Figure 40: First asparagus stage separation.]

    [Figure 41: Solid rocket booster (SRB) separation.]

    Recall that I set up the solid rocket booster, radial decouplers with the "Action Groups." So instead of hitting the spacebar to cause separation, I hit the '1' key, per the way it was set up using the Action Groups.

    [Figure 42: Initiating "pitchover."]

    [Figure 43: Second asparagus stage booster separation."]

    Almost immediately after the pitchover, for this particular rocket and launch of rocket, the second asparagus stage booster separation occurs.

    Per the discussion that cjl mentioned in post #5, I probably should have temporarily disabled the Stability Augmentation System (SAS) for the gravity turn. SAS adds torque to counteract any forces causing the rocket's rotation. Here, after the pitchover, we actually want gravity to act on turning the rocket somewhat (as cjl pointed out). I forgot to disable it though. Instead, I just gradually turned the rocket toward 45o by tapping the 'D' key a bit, every so often, out of habit.

    SAS and the reaction control system (RCS), if enabled, will automatically act to keep the craft from rotating. So if you desire to let the rocket turn over naturally, temporarily disable SAS and RCS, enabling them only if things get out of hand or to make corrections. While I never had RCS enabled for this launch, I did neglect to temporarily disable SAS.

    Something else that I haven't really talked about is that in a real-world situation, you wouldn't want to allow the heading to deviate from the surface prograde vector by much, while still in the lower atmosphere. And that's not because of efficiency, but rather because of control.

    Engine thrust vectoring (when the engine is active), aerodynamic fins/wings, SAS and RCS can all be used to steer the craft; They all can apply torque to adjust and control the craft's attitude. But individually, or even taken together, they all have a limited range of what they can do. That range depends on the particular rocket, but suffice it to say, on any rocket that range is limited.

    If drag forces cause a torque that is outside the combined control range of the thrust vectoring, fins/wings, SAS and RCS then the ship will lose attitude control. This can cause the main-engine end of the rocket to point toward space. "If it starts pointing toward space you are having a bad problem and you will not go to space today." (http://xkcd.com/1133/.) I've had this happen even with version 23.5's limited use of aerodynamics. I suspect it will be even more important in later versions of the game.

    In a more extreme case, deviating the heading too far from the surface prograde vector can potentially cause the ship to break apart. This isn't likely to happen in KSP v23.5, but I imagine it will be in future versions.

    So yes, pitching over to 45 degrees should happen gradually for different reasons than efficiency. You probably shouldn't lean away from the surface prograde vector too much more than that shown in figure 43 and 44, if you want to stay realistic and safe.

    Gradual is relative though. When I say gradual, I do not mean slowly turning from 0 to 45o continuously from lift off to 30,000 meters. That could cause one to be in a world of waste. By gradual I still advise executing the turn from somewhere around 10,000 meters with a possible target of reaching a 45o pitch somewhere closer to 20,000-25,000 meters or so. That's still relatively sharp compared to the rest of orbital insertion. (Oh, and that is specific to Kerbin. Not Earth. Earth has a higher atmosphere with different characteristics.)

    [Figure 44: Continuing the turn. Up to full throttle now."]

    Again, I forgot to temporarily disable SAS for the gravity turn.

    Anyway, although not shown, the heading is starting to approach the orbital prograde vector. Figure 44 shows the surface prograde vector, which is important to keep an eye on for the craft's stability at this altitude. But since we are now coming into orbital prograde vector, and because the drag forces are diminishing, it's time to turn up the juice.

    The orbital prograde vector is to the East of the surface prograde vector (placing it just on the other side [the right side] of the ship's heading on the navball in figure 44 [again though, the orbital prograde vector is not actually shown in the figure though]) because the rocket starts out with a significant eastward velocity due to the rotation of the planet Kerbin.

    [Figure 45: raising the apoapsis up a bit."]

    Once reaching an angle of 45 degrees, keep at this angle until the "time to apoapsis" reaches about 1 minute, or until apoapsis rises significantly above the atmosphere (70,000 meters). This is pretty good advice I heard from one of Scott Manely's videos. It works out pretty well and is easier to follow than my previous advice about following the prograde vector.

    Until the apoapsis reaches its low-orbit insertion value (a little above 70,000 meters) try to stay about 1 minute behind the apoapsis. If the time to apoapsis is less than one minute, raise up the nose of the ship a bit. If it's more than one minute, point the nose of the ship closer to the horizon.

    I concede, it's not the quite the same advice I gave earlier in post #4, but it's easier to keep an eye on, and leads to more consistent results.

    Of course, eventually, if everything goes well, the apoapsis will start shooting away quickly, even with your nose close to the horizon, which also at the time happens to be on top of the orbital prograde vector. I suppose at that point you have a choice to let it shoot away to quickly reach the desired low-orbit insertion altitude, or reduce thrust a little and stay on the orbital prograde vector. Either way, take a sigh of relief knowing that you've just passed into the "thrust? Meh, time to relax instead" part of the launch.

    But I'm starting to get ahead of myself. Back to this launch.

    [Figure 46: Third asparagus stage separation."]

    At the time the image in Figure 46 was taken, we still have a full tank for the primary, center stack stage. The desired low-orbit apoapsis hasn't been achieved yet, but we're not doing to bad. We should end getting to orbit before the fuel in this stage is depleted.

    [Figure 47: Low-orbit, apoapsis is achieved (even overshot it a little).]

    I may have overshot the desired apoapasis a tad, But that's fine.

    So now let's set up a maneuver node to bring up the periapsis (skip ahead a bit if you are already familiar with maneuver nodes).

    The following assumes that you have just increased your apoapsis to be above the atmosphere (above 70,000 m) and wish to use a maneuver node to bring up the periapsis.

    As a rule, there is nothing you can ever do presently, to change the part of the orbit that you happen to be in presently. Any maneuver you do now can have no effect on the particular location of the orbit you happen to be in. Present maneuvers can and do, however, change other parts of the orbit.

    Specifically, burning prograde increases the elevation of the opposite side of the orbit.

    (Prograde is the direction of your velocity, relative to some reference. Here, orbital prograde is your velocity relative to the center of Kerbin. The opposite is called retrograde, and is in the opposite direction of your relative velocity.)

    Left click on the orbit (blue line), near the "Ap" (apopapsis) symbol. Click the "add maneuver" selection. A circle with a bunch of symbols will pop up. Figure 47 shows this, although it's not centered on the apoapsis. This is not a two dimensional circle with a bunch of symbols on it. Rather it is three dimensional with a pair of symbols on each axis. You should recognize two of these symbols, one is the prograde vector and another the retrograde vector symbols that you have seen on the navball already.

    You can shift the maneuver node along the orbit. Click on the center of the node (make sure to change the camera angle [using the mouse] such that none of the 6 symbols also appear in the center) and hold the click. While holding the left mouse button, you can now move the node back and forth along the orbit. Move it over to be directly on top of the blue Ap (apoapsis) symbol.

    Now click on the prograde symbol and pull it to the right. You should see an orange/brown, dotted line on the opposite side of the orbit rise up. By the way, pulling the prograde vector to the right is the same thing as pushing the retrograde vector to the left. Prograde and retrograde are really two sides of the same thing.

    Once the altitude of the orange/brown, dotted line is similar to that of your present altitude (albeit on the opposite side of the orbit), you can stop dragging the prograde symbol.

    [Figure 48: Preparing to raise the periapsis.]

    Once you've created a maneuver node, notice a deep-blue three-pronged symbol on the navball. That is the direction your heading needs to be for the maneuver that you chose by making the maneuver node. That's the direction you need to be in for your maneuver.

    So when preparing to perform the maneuver, adjust your heading so it aligns with that maneuver node symbol. Once you have it aligned, turn on SAS (SAS can be toggled with the 'T' key), so that you don't have to worry about your ship's attitude drifting.

    Notice what's on the bottom right of the navball. It tells you the estimated burn time, and the time until the "center" of the burn.

    In figure 48, time until burn shows "Node in T - 44s"

    When spoken, that's pronounced "Node in tee minus fourty-four seconds."

    I'm sure you may have seen movies, documentaries or historical footage of rocket launches, where you hear, "T minus 10 seconds, nine, eight, seven, six, ..." Well it's the same thing here, except it refers to the center of the node.

    The estimated burn time is the estimated time that it will take to complete the maneuver, once the burn starts, using the information from the last time you fired your engines. (Keep that in mind; if you've staged new engines without firing the new ones, or dropped some mass since the last time you fired your engines, the estimated burn time might be unreliable.)

    So in figure 48, where we have

    Est. Burn 35s
    Node in T - 44s

    we should start burning when the countdown is T - 18 roughly. That about 18 seconds before the node and about 18 seconds after the node, for a total of 35 seconds at full throttle.

    KSP and maneuver nodes do not perform the maneuvers automatically. You still must perform the maneuvers yourself. The maneuver nodes give you valuable information, but they do not perform the maneuvers for you.

    [Figure 49: Executing a maneuver.]

    Figure 49 shows a maneuver in progress. Notice directly to the right of the navball, there is a curved "bar" shaped thing which shows something that is decreasing when time goes on. That is your remaining Δv (delta-v), the change in velocity, that is left until the completion of the node. When that bar hits bottom, your maneuver is completed. Cut your engines by hitting the 'X' key, to immediately stop the burn.

    Once completed, the ship is in a stable, low orbit.

    To be continued...
    Last edited: Jun 18, 2014
  13. Jun 18, 2014 #12


    User Avatar
    Homework Helper
    Gold Member

    ... Continued from part one.

    To the Mun!

    Part two: Getting started getting there.

    Now that we're in a stable, Kerbin orbit. Let's see how our orbit compares to the Mun orbit.

    [Figure 50: Select the Mun as the "target."]

    In the map view, find the Mun, click on it, and click "Set as Target"

    Once you do that, you should notice two lines that extend somewhere from your orbit, to the Mun's orbit. One will be labeled "AN" for ascending node, and the other "DN" for descending node. They are always on opposite sides of the orbit.

    If two small bodies are orbiting around a large body, the planes described by the orbits of the two bodies will always intersect on a line, and that line will intersect either one of the given orbits at exactly two points (well, except for the special case where the orbits are coplanar, in which case they intersect at every point). I'll leave this as an exercise to the reader to prove geometrically.

    But it shouldn't be difficult to visualize this conceptually. Imagine that you have two pieces of flat paper with a common center (the common center representing the more massive of the three bodies). The two pieces of paper can pass right through one another, but both pieces of paper must pass through the common center. There will be a line created where the two pieces of paper pass through each other.

    One each piece of paper there is a circle or ellipse drawn on it, that goes around the center. The line created by the intersection will pass through each ellipse. The two points at which it passes through your favorite ellipse, the ellipse that represents your orbit, are called the ascending node and the descending node (nevermind for now which is which, it turns out to not be particularly important for our purposes).

    One thing to note though, if you wish to rotate your orbit such shares the same plane as the other orbit, you must rotate it such that the axis of rotation passes from an ascending/descending node, through the center, and then through the other ascending/descending node. Using our paper analogy, it means if you want to rotate your piece of paper to share the same plane as the other sheet of paper, you must rotate it on the line created by the intersection between the two pieces of paper.

    Mouse over one of the ascending or descending nodes (either one) You should see a number in degrees. This tells you your orbit's inclination relative to the target orbit. In other words, this is the angle between the two pieces of paper.

    We want to bring this to zero. So place a maneuver node over one of the nodes, either ascending or descending (might as well pick the nearest one that your ship will reach first, given that you still have time to make adjustments before it arrives).

    The pull on the either the normal or anti-normal symbols on the maneuver node (they are the pink/purple symbols), until the AN and DN indicators quickly change position. The When they do, you should notice that your orange/yellow dotted line orbit becomes co-planar with the target's orbit.

    The normal and anti-normal vectors are perpendicular to the plane of the orbit. The normal vector points perpendicular to the orbit if you use the right-hand rule. If you let your right-hand fingers curl around in the direction of your ship (or some other body) along its orbit, with your thumb extended, then your thumb points in the direction of the normal vector. The anti-normal is the opposite direction (or left-hand rule, if you want).

    Figure 51 shows an example of this used for this adventure.

    [Figure 51: Inclination adjustment (1/2)]

    It may be kind of hard to tell in this example (the inclination is pretty small to begin with), but in Figure 51, part of the orbit to the right of the planet is slightly lower (as in dipping toward the south) than the part on the left side of the planet. Since we are orbiting the planet counterclockwise (anti-clockwise) when looking down/south, (the ship moves from left to right when it passes in front of Kerbin in the orientation shown in figure 51), we need to burn normal (up/north, as shown in figure 51) such that we will bring the right side the orbit higher (more north).

    You should be able to get this information simply by playing with the maneuver node, just by fiddling with the normal and anti-normal symbols until the orbital planes line up, and you see the AN and DN symbols switch places (The maneuver must be executed at the original, AN or DN node for this to work -- any other part of the orbit and you cannot zero out the inclination!). When it happens, mouse over one of the new AN or DN symbol positions and confirm that the projected inclination shows either 0.0 deg or NaN. Either one.

    Next, execute the maneuver. Line up your heading with the blue symbol on the navball, and use the maneuver node's, "Time to Node" and "Est. Burn" time to complete the maneuver.

    [Figure 52: Inclination adjustment (2/2)]

    Doing inclination adjustments early make things much easier as you go. If you are new to KSP, I highly suggest doing inclination adjustments early to make things easier.

    Before I continue, I should at least point out that it is not generally more efficient to do them early. It's most efficient to perform these types of maneuvers when the ship is at a lower, orbital kinetic energy -- when its orbital speed is slower, such as when it is high up in the highly eccentric ellipse when moving from Kerbin to the Mun. But that makes everything much more complicated, and you have to get the timing just right, or you will find yourself in the wrong plane to get a close encounter with your target.

    So even though it's not necessarily as efficient, getting into the target's orbital plane early makes everything easier. That's what we're going to do for this series.

    So now that we're in a coplanar orbit with the Mun's orbit, let's set up our transmunar injection burn.

    [Figure 53: Create a maneuver node for the trans-munar injection burn]

    I'm not sure if trans-munar injection is the correct term here. Actually I just made that term up. Sort of.

    If it was Earth and the Moon, it would be called a trans-lunar injection. That's a real term. But we can't really call it lunar since we're not talking about Luna (the Moon), since that's specific to the Earth system. So I'm calling it a trans-munar injection.

    I tried to find a more general term that doesn't refer to the name of specific body. Maybe transorbital injection? That sounds almost perfect. Unfortunately, that one's nearly taken by transorbital lobotomy, which in also involves an injection of sorts, in a manner of speaking.

    [Figure 54: transorbital lobotomy]

    Trans-lunar injection. Trans-munar injection. Transorbital injection. Transorbital lobotomy. It really makes ya think. Oh, wait. Nevermind.

    So anyhoo, create a maneuver node and drag the prograde symbol way out until the projected apoapsis gets close to, but not quite, reaching the Mun's orbit, as shown in Figure 53. Don't go so far that it actually intersects the Mun's orbit. Just make it get close, without crossing it.

    Now click and hold the blue circle in the center of the maneuver node and drag the node back and forth along your present orbit. By doing so, you should discover an encounter, such as shown in figure 55.

    [Figure 55: Drag the maneuver node to find an encounter]

    Drag it a little more and the projected encounter disappears (Figure 56). Also, take note of the two symbols near where the two orbits are close. These are the closest approach symbols. Try to drag the maneuver node are as close as possible; you should get an encounter when they are close enough.

    [Figure 56: Too far and the projected encounter vanishes]

    Play with it awhile, and you'll notice that at some point a sort of maximum is reached near the center, so choose that, giving us a little margin of error on either side. If you want, feel free at this point to play with the prograde and retrograde symbols, to see what effect they have. The other symbols are of not really any use to us for this, particular maneuver. (If we were rendezvousing with another ship, or performing an interplanetary transfer, the radial-in and radial-out symbols might prove very useful, but just not so much here.)

    [Figure 57: Choose something in the middle]

    [Figure 58: Projected trans-munar injection view from different angle]

    When I first started playing KSP, for the the first couple of weeks, I didn't know that it was even possible to drag a maneuver node back and forth. If the first one didn't work out well, I would delete the maneuver node and create a second one. If that didn't work out I deleted it and created a third one, and so on. I was quite surprised and pleased when I realized you can just click and drag maneuver nodes back and forth. That discovery saved a lot of time and effort.

    There are different types of trans-munar injections than the one used here. By bringing the initial projected apoapsis up higher you can discover a free return trajectory type of trans-munar injection. There are two varieties. In one, you go in back of and then wrap around behind the Mun. In the other, you wrap around the moon in a figure-8 pattern, eventually orbiting the moon in a clockwise (retrograde) direction.

    I'm not doing a free-return path here because they are more difficult, and have less margin for error (if you are not careful, you might find yourself slamming into the Mun). I'm using the simple insertion, simply because it's simpler.

    If you would like to discuss other types of trans-munar injections, feel free to post! Stuff like that is what this thread is for. :smile:

    Okay, now that we have a chosen maneuver node, let's prepare for the burn. Line up the ship's heading with the maneuver node symbol on the navball, as shown in Figure 58.

    Might also be a good time to check the remaining fuel (Figure 59).

    [Figure 59: Pre trans-munar injection burn fuel check]

    There's not a whole lot of fuel left in the main, center stack tank. Not complaining! that got us farther than it was designed to do. We only really needed that to get into a low orbit around Kerbin.

    But it does mean that we cannot trust the Est. Burn time shown by the maneuver node. We'll need to start the burn early. Experience tells me that these burns typically take a few minutes, but that wholly depends on the thrust of the next stage, and the mass of what's left of the whole ship. I'll just guess that after the main, center stack tank goes, we'll have 2 1/2 minutes or so left of burn time. It's just a guess though.

    When the time comes, we start the burn (Figure 60).

    [Figure 60: Starting trans-munar injection burn]

    As expected, the main, center stack tank doesn't last long (Figure 61).

    [Figure 61: Main, center stack tank separation]

    Don't worry, that main, center stack tank won't end up as space junk! Recall from Post #10 that we put on an RCS system and a remote guidance unit. That's enough to de-orbit the thing.

    [Figure 62: Continuing burn with mid-stage tank]

    The following set of images show how the orbit increases apoapsis with time.

    [Figure 63: Trans-munar injection burn, map view (1/6)]

    [Figure 64: Trans-munar injection burn, map view (2/6)]

    [Figure 65: Trans-munar injection burn, map view (3/6)]

    [Figure 66: Trans-munar injection burn, map view (4/6)]

    [Figure 67: Trans-munar injection burn, map view (5/6)]

    [Figure 68: Trans-munar injection burn, map view (6/6)]

    Figure 68 shows the final result.
    • The blue line represents our present orbital trajectory.
    • The orange line represents the part of our trajectory where the Mun has the dominant gravitational influence.
    • If we do nothing, and perform no new maneuvers, the purple line represents what our Kerbin orbit would become after escaping the region of the Mun's dominant, gravitational influence.

    One could perhaps better describe the different colors by recognizing the different regions of KSP's use of patched conic approximation of orbital mechanics. But I'll save that discussion for a later post.

    So we haven't got to the Mun yet. We are still near Kerbin. But we are now well on our way! (Figure 69).

    [Figure 69: We are on our way to the Mun!]

    To be continued ...
    Last edited: Jun 18, 2014
  14. Jun 19, 2014 #13


    User Avatar
    Homework Helper
    Gold Member

    ... Continued from part two.

    To the Mun!

    Part three: Getting there

    Let's check our fuel after that last burn.

    [Figure 70: Post trans-munar insertion burn fuel check]

    It's kind of difficult to tell in Figure 70, but it shows that the mid stage tank is just slightly over half full.

    Not bad! We have plenty of fuel left.

    We're not going to use any fuel for awhile anyway. At this stage of mission we just coast (free-fall) up to the Mun.

    It might seem odd at first that we're doing okay on fuel. I mean we've already used roughly 7/8 of the fuel we started with (maybe more than that if you include the solid fuel in the SRBs).

    [Figure 71: 'Time to sit back, relax, and enjoy the view. ...]

    If one's only exposure to space travel was sci-fi shows, one might start to worry. Many people assume that when traveling, 1/2 the fuel would be used on the way there and 1/2 on the way back. But it doesn't work out that way for rockets and space.

    The fuel that is being burned at any given time is not only used to lift and push (accelerate) the payload, but also the weight/mass of all the fuel that will be used to lift and push the payload at a later time. So as one gets to the lower stages, the amount of fuel required balloons up exponentially.

    But as we use up fuel, we also drop mass, meaning we need less fuel to push what's left.

    If you examine the design in post #10, you might notice a pattern such that each stage contains roughly the same amount of fuel as all the stages above it, combined. This general type of pattern is not uncommon in actual rockets.

    But if one's experience is only sci-fi, I can almost appreciate the concern. I mean look at Figure 70, or even later in figure 71. We're still right next to Kerbin and we're already down to 1/8 of our total fuel. Can you imagine going on a road trip with a full tank of gas, getting down to only 1/8 of a tank, and looking out the window to see that you haven't even left your neighborhood yet?

    [Figure 72: ... and listen to collinsmark babble on, it would seem.]

    But we're not using fuel on the way to the Mun. We're just coasting. The engines are shut off, and we just drift up, like a stone thrown up in the air (except without the air).

    Take the Apollo 11 mission. That lasted about eight days. Neglecting the lander on the moon itself, the entire thrust duration of the Saturn V, all the way to the moon, and service module all the way back to back to Earth, as about 20 minutes (was it about 20 minutes? I think it was about 20 min). And that's the entire trip -- not just the launch -- the whole round trip (again, neglecting the lander itself, which spent some time looking for a place not littered with boulders). Twenty minutes of engine burn out of eight days.

    That's what irks me about much science fiction (and other, non-KSP space games, for that matter). Ships seem to keep their engines thrusting all the time. I mean you are just coasting to your destination. Why do you have your engines on? There's nothing to slow you down!

    I remember the old Battlestar Galactica series (I'm speaking of the original series, back in the '70s. I haven't watched the new ones), spaceships bank when they turn. Why are they banking? Airplanes bank because they get a normal force from the atmosphere, but there is no atmosphere in space! Why bank, I ask. Why?

    Then there's sound effects in space. Ya know, I'm going to give space sound in movies a bye. I'll let that pass. Most of the time when there are sound effects in space, the "camera" thus viewer/audience, is placed out in the middle of space in some sort of omniscient existence scenario. I mean if you were really out in the middle of space watching the action, your blood would literally boil as your body bloats up grotesquely. Since there doesn't seem to be any gurgles for help or writhing in pain from the camera position, we can assume the viewer is in some sort of an omniscient situation. So the fact that the viewer would be able to perceive something that resembles sound isn't too much of a stretch.

    And who doesn't love the eery sound of a TIE fighter. Or the satisfying sound of a laser cannon blowing one up. I mean sure, we could remove all space sound, but what would that accomplish? It wouldn't change the storyline. Things would go on the same as before, just quieter. And sometimes the cool sound effects can really make the movie.

    So sound effects I can live with. But why keep the engines thrusting all the time. Is it too much to ask to make that a little more realistic about the engines?

    [Figure 73: Jeeze, collinsmark. It sounds like somebody needs to get a life.]

    Okay I'll give Star Trek's warp drive a bye too. It's hard to speculate about something that doesn't exist. So warp drives need to be on to stay in warp. That's fine, whatever.

    Don't get me wrong, I love a good Star Trek show (I think I have seen every single episode from the original up through Voyager), but every once in awhile they do something bad.

    Like when Picard commands "Full stop!" Full stop? In space!? All right, maybe if Q hurls something in their general direction, "Full stop" might just be short for "decrease the ship's relative velocity with respect to that thingy that's approaching." Or if they are in warp, perhaps "full stop" means to drop out of warp. I'll buy that much.

    But one time, if I remember correctly, the Enterprise was trapped in some sort of endless, empty void of nothing. (It might have been "Where Silence Has Lease," season 2, episode 2; written by Jack B. Sowards and directed by Winrich Kolbe). In this void there is nothing. No edge, no boundary, no stars, no galaxies, nothing (at least it starts out that way). Eventually Picard commands "Full stop!"

    Full stop? Full stop!? Full stop relative to what!? Gah! You - are - in - an - empty - void - of - nothing. It doesn't make any sense!

    "Full, jelly donuts!"

    That's what should have been said, Picard. It makes as much sense.

    <sigh> Am I asking for too much here? Is it really too much.

    [Figure 74: Ground control to Major Tom. Ground control to Major Tom. Can you hear me?]

    <another sigh> Maybe that's why I like Kerbal Space Program. Sure, it might exaggerate some things here and there, but at least it gives a solid try to be realistic for the most part, at least conceptually. Okay, I'll stop. (Full stop! <kidding>)

    Let's see. Are we getting close to the Mun yet?

    [Figure 75: Still drifting.]

    Let's just watch our position in orbit on the map, and compare that to the Mun's position in its orbit, over time.

    [Figure 76: Ship relative to Mun, map view (1/2).]

    [Figure 77: Ship relative to Mun, map view (2/2).]

    Notice that in Figure 76 and 77, we are moving up along the Kerbin orbit, and the Mun is moving up along its orbit.

    The orange line represents a region where the Mun, at least temporarily, will have a dominant influence. It may appear that since we're moving along our Kerbin orbit "up" and "to the left" when we are on the orange section, that we would be moving clockwise with respect to the Mun. Buy that's not the case!

    Remember that the Mun is also moving (as can be seen in figures 76 and 77)! And it is moving faster that we are, relative to Kerbin.

    If you know a little about orbital mechanics, you might be confused by this. You might know that all else being equal, bodies move faster in lower orbits than they do in higher orbits. We are in a lower orbit so we should be moving faster right? No, not in this case; all else is not equal here. We are in a highly eccentric (highly elliptical) orbit, and near its apoapsis. Had we circularized the orbit (to be the same shape as the Mun's orbit) then yes, we would be moving faster. But we have not circularized the orbit (yet) and are definitely moving slower than the Mun, relative to Kerbin.

    The thing to take home from that is the Moon is moving faster than we are, relative to Kerbin, in this part of the orbit, thus we are counterclockwise (anticlockwise) relative to the Mun! This becomes apparent in Figure 78, where our displayed orbit is shown relative to the Mun, rather than relative to Kerbin.

    We are now dominated by the Mun's gravity.

    [Figure 78: Orbit is now dominated by the Mun.]

    Don't misinterpret that as our orbit, and trajectory suddenly shifting. It's not. It's just being displayed differently.

    The orbit in Figure 78 is essentially the same as in Figure 77. It's just the the orange line in figure 77, being relative to Kerbin, is now displayed as the blue line in Figure 78, as relative to the Mun.

    Don't forget the Mun is not stationary. It is moving too, orbiting around Kerbin. Even the blue line is moving since the Mun is moving.

    The blue line is our orbit relative to the Mun. But remember, the Mun, our ship, and thus the blue line that shows the ship and Mun relationship, are all orbiting around Kerbin. The whole kit and kaboodle.

    And since we are moving counterclockwise (anticlockwise) relative to the Mun, that blue line is getting shorter as time goes on. Note that our ship's position remains on that orange line as time marches on -- the Mun and the rest of that blue line are traveling up and to the left faster than we. Well, faster than we are to the left anyway. In the figure, the Mun and the ship might be traveling "up" at about the same rate.

    To be continued. ...
    Last edited: Jun 19, 2014
  15. Jun 19, 2014 #14


    User Avatar
    Homework Helper
    Gold Member

    ... Continued from part three.

    To the Mun!

    Part four: Staying there

    We last left our heros, Jebediah, Bill, and Bob, after their ship reached the Mun's dominant gravity.

    [Figure 79: We've traveled this far!]

    [Figure 80: Pretty close to the Mun now!]

    In the patched conic approximation of orbital mechanics terminology, this threshold of "dominant gravity" is known as the Mun's sphere of influence (SOI). So far, I've avoided using this term; I don't like the term very much. It gives the impression that patched conics treat gravitational effects as all or nothing. That's only half true. It really treats n-body problems as multiple, yet individually distinct, restricted, 2-body problems. And that's a lousy way for me to phrase it; unless you are already familiar with the subject, I have not communicated anything new.

    Let me phrase it another way. I don't think I can get away from avoiding the term sphere of influence (SOI) forever in this series of posts. It is part of patched conics and is what Kerbal Space Program (KSP) uses to model obits. But regardless of how sphere of influence sounds, patched conics are not that bad of an approximation. You would have to go out of your way to look for anomalies, and know what you are looking for, before you would find the differences from KSP to real-world physics.

    So where would you find those differences? Approximation errors would be most obvious in a hypothetical system such as a planet and a moon of equal mass. That's as if two planets of equal mass were orbiting each other, and the two planet system was orbiting the sun. Patched conics would do poorly with that situation. But patched conics work mostly accurately if the sun/star is much, much heavier than any of its planets; and the planets are much, much heavier than any of their moons; and none of the orbits allow bodies in different orbits (such as different planets) to get too close to each other.

    Duna (the Mars analogue) and its moon Ike (no analogue here -- very dissimilar to either Phobos or Deimos) might show the most deviation from accurate models. Duna is only about 16 times the mass of Ike. That's a big enough difference to where you probably would never notice any effects unless you look for them, but if you were looking, that would be the system to look.

    What anomalies would you look for?
    • In a more accurate model, Duna and Ike would orbit around their respective barycenter -- their combined center of mass. With patched conics, Ike orbits around the center of Duna.
    • In a more accurate model, there would be a certain location that exists between Duna and Ike such that you could place a ship at that location and it would remain stationary relative to Duna and Ike, as Duna and Ike orbit each other. This is called the L1 Lagrange point. Similarly there exists a similar location on the other side of Ike called the L2 Lagrange point. L1 and L2 points do not exist using patched conics. Also, locations near the L1 and L2 points would also show the approximation errors, but would diminish somewhat as the distance increases. (And if I'm not mistaken, and depending on the manner in which the "approximation error" is measured, surprisingly the L3, L4 and L5 points might actually be [almost] right on the money -- three examples where two wrongs make a right [almost]. But now I'm getting into this more than I wanted to.)
    • These L1 and L2 points are not limited to Duna and Ike. In more accurate models they would also exist in the Kerbin/Mun system, the Sun(Kerbol)/Kerbin system, and in most every system, in some way or another. But again, unless you were looking to plop something into one of these points/regions, you would never notice.

    I'm not complaining. I think KSP's use of conic patches is just fine given its purpose: it's a game meant for fun. And let's face it, compared to most all other space games where there is no concept of realistic orbits whatsoever, where gravity is treated poorly or even absent, and where ships have their engines thrusting all the time, KSP is several leaps in the right direction.

    But in a short while, I'm going to mention how our ship passes into the SOI of the Mun. Don't think that it leaves behind the influence of Kerbin altogether though. Remember, the Mun itself is still orbiting Kerbin. So by being influenced by the Mun, there is also that influence from Kerbin passed onto it.

    So I'll say it. We've passed into the sphere of influence (SOI) of the Mun. Figure 81 shows our map view.

    [Figure 81: We have entered the Mun's SOI]

    The blue line is not an ellipse. If we are in the Mun's SOI shouldn't we be in orbit around the Mun? And shouldn't it be an ellipse? We are in the Mun's orbit, so to speak, but it's not an elliptical orbit, it's a hyperbolic orbit. So we're on a hyperbola, not an ellipse. Why are we in a hyperbolic orbit? Because our speed relative to the Mun is greater than escape velocity.

    There are two equivalent ways to look this.
    • We are traveling along the blue line, our trajectory relative to the Mun. But our speed is too fast to be captured by the Mun. If we wish to be captured by the Mun, we need to slow down relative to the Mun. Thus we must fire orbital retrograde (orbital retrograde relative to the Mun).
    • We are orbiting Kerbin, but the Mun is orbiting Kerbin at a much faster speed. If we want to be captured by the Mun, we need to catch up to it. We need to reduce the speed at which it is moving away from us. So we need to fire retrograde relative to the Mun's orbit to reduce the speed at which it is shooting away from us.
    In both cases, if we want to insert ourselves into a stable, Munar orbit we must fire retrograde, with respect to the Mun.

    So let's set up a maneuver node.

    [Figure 82: Projected munar orbital insertion maneuver]

    Put the node at the Pe (peripsis) location and pull on the retrograde vector, until a near circular orbit is shown in the orange/brown dotted line. This maneuver will put us in a high, munar orbit.

    Before that though, since we have some time, let's look at our present orbit a little more and then see how our orbit changes over time relative to our Kerbin orbit.

    Notice the circle on the right side of the blue line. That's the point that if we do nothing, we would leave the Mun's SOI. In other words, that's the point where the Mun would no longer be the dominant gravitational body.

    But don't think that as time goes on we will be at that location, way over to the right of where we are now, relative to out Kerbin orbit! No, no, it's not like that at all. We are still drifting up and to the left along the solid brown line (orbiting Kerbin) just as we were before. Relative to our orbit around Kerbin, that blue circle at the end of the line is moving toward us, just as the moon is continuing along its orbit, up and to the left.

    Let's take a look at that with another series of pictures, as time continues.

    [Figure 83: Approaching munar orbital insertion maneuver (1/4)]

    [Figure 84: Approaching munar orbital insertion maneuver (2/4)]

    [Figure 85: Approaching munar orbital insertion maneuver (3/4)]

    [Figure 86: Approaching munar orbital insertion maneuver (4/4)]

    We better get ready for the burn. We line our heading up with the maneuver node symbol on the navbal, which also coincides with the retrograde symbol. Since we are in the Mun's SOI, this is retrograde with respect to the Mun.

    [Figure 87: Preparing to fire retrograde for the munar orbital insertion burn]

    There's still another way to look at this maneuver. Recall that in the last post, I mentioned that we were moving slower than the Mun, with respect to Kerbin, because our orbit was so eccentric? I mentioned that would have a higher orbital speed than the Mun, both relative to Kerbin had we circularized our orbit around Kerbin. Well, look at our orientation relative to Kerbin as we prepare for this burn (Figure 88).

    [Figure 88: Burning retrograde relative to the Mun is nearly the same as burning prograde relative to Kerbin, given our orbital position]

    Relative to Kerbin, our burn is mostly prograde. This is a way of saying that we are speeding up around Kerbin so that we can "catch up" to the Mun's greater velocity, relative to Kerbin. Or looking at it another way, prograde relative to Kerbin brings up or periapsis relative to Kerbin, thus circularizes the Kerbin orbit. We're doing all of these things in one step (and well, that's because all of these things are really just different ways of looking at the same, single thing).

    When the time comes, we start the burn.

    [Figure 88: Munar orbital insertion burn (1/5)]

    [Figure 89: Munar orbital insertion burn (2/5)]

    [Figure 91: Munar orbital insertion burn (3/5)]

    [Figure 92: Munar orbital insertion burn (4/5)]

    [Figure 93: Munar orbital insertion burn (5/5)]

    And we are now in a stable, high munar orbit.

    [Figure 94: Stable, high munar orbit (1/2)]

    The Mun looks pretty peaceful from up here.

    [Figure 95: Stable, high munar orbit (2/2)]

    Next time: Jeb and Bill do some extravehicular activity (EVA)!

    To be continued. ...
    Last edited: Jun 19, 2014
  16. Jun 19, 2014 #15


    User Avatar
    Gold Member

    Why is this so slow? The research center(the land) is slow as a snail. I don't know why. Is is very fast for you?
  17. Jun 19, 2014 #16


    User Avatar
    Homework Helper
    Gold Member

    Just to be thorough, let me say that if you are playing in "sandbox" mode, the research center is not available. You need to play in "career" mode for the research center to open (the research center is where one uses science points to unlock technology).

    The present implementation of the game does seem to have some pretty significant load times when you go from one building to another. It might just be the present version isn't optimized yet, particularly for things like loading times.

    For me, it might take several seconds to load up the research center (or any other building), but once there everything is pretty responsive.

    There's only been a few times when building a rocket in the vehicle assembly building (VAB), where things slowed down to a crawl. I'm not sure why. I guess I did something it didn't like. The problem eventually fixed itself somehow though. I don't know why or how. It doesn't happen often.
  18. Jun 20, 2014 #17


    User Avatar
    Homework Helper
    Gold Member

    ... Continued from part four.

    To the Mun!

    Part five: Low, with a twist

    Jebediah and Bill are itching to stretch their legs. So let's give them something to climb around on.

    [Figure 96: Extending ladders]

    Remember, from post #10 that all the ladders are the craft were previously set up to be toggled by a single press of the '5' key by using the "Action Groups." If we didn't use action groups, the ladders could still be extended by right clicking on each one individually.

    [Figure 97: Jebedaih goes EVA]

    Jebedaih is first to extra vehicular activity (EVA) to the lander module.

    The kerbals could have just used their jetpacks to EVA to the lander pod, but ladders are much less hassle.

    [Figure 98: Jeb makes use of the ladders]

    [Figure 99: Jeb boards the lander pod]

    [Figure 100: And Bill follows (1/2)]

    [Figure 101: And Bill follows (2/2)]

    [Figure 102: All crew accounted for in the lander module]

    [Figure 103: And Bob gets to have some alone time in the command module]

    [Figure 104: Decoupling the command/service module from lander module]

    The first order of business is to separate the command/service module from the lander module. This is done manually by right clicking on the appropriate docking port. Make sure it's the right one! Remember, there's multiple ports on this craft. It could be a pretty embarrassing at this point if the wrong port was released.

    [Figure 105: Decoupling complete]

    We have separation.

    Strange though the the service module's engine's fairing is attached to the landers docking port. I wonder if that sort of thing is a bug in the game. I tested it out before though, and we can still dock with it like that. So it won't cause us any problems. But yeah, it kind of looks weird.

    The next order of business is (for the lander) to prepare for a retrograde burn. After separation from another craft that you need to get back home, it's always a good idea to check that it's not in your way.

    [Figure 106: Check for obstacles]
    • First rule of Flight Club: Do not collide with the command/service module.
    • Second rule of Flight Club: Do not collide with the command /service module.
    We just turn on the RCS for a moment, and do a tiny translational maneuver to get it out of our path.

    From here we just burn retrograde. The idea is to bring down our periapsis for a low Mun orbit insertion. I'm not even going to set up a maneuver node. Sure we could, but it's just going to tell me to burn retrograde anyway. There's really not much of a point. Just make sure to keep an eye on the map and cut the engines when the periapsis is what we want.

    [Figure 107: Wiz by the command module]

    [Figure 108: "We'll be back, Bob."]

    [Figure 109: Periapsis lowered]

    And that should do it. We'll circularize that later when we get to the periapsis as the final part of our Hohmann transfer.

    In the mean time, let's change the name and symbol for the lander. It will make it easier later on, when we rendezvous with the command/service module.

    [Figure 110: Changing the name/symbol of one ship helps distinguish it from the other, in the Map View]

    Set up our maneuver for orbital insertion. I'll use a maneuver node for this one. Maneuvers at periphrasis are more sensitive to timing errors due to the ship's greater, orbital speed.

    [Figure 111: Prepare for low orbit orbital insertion]

    [Figure 112: low orbital insertion complete]

    I like to keep the altitude about 10,000 meters for the Mun unless I don't care where I land. There's a limit to how quickly you can fast forward the time (called "Time Warp" in the game) if the altitude is below 10,000 m on the Mun. We can reduce that later on the final orbit before landing.

    By the way, Mun has some really huge mountains, so be careful when orbiting much less than 4,000 m.

    But I want to land at a specific place. On a previous mission, I saw something unusual from orbit, near the equator (we're already orbiting near the equator) that I want to investigate.

    [Figure 112: Target landing spot is not quite underneath present orbit.]

    But that's pretty easy to fix. We just twist the orbit around a tad.
    1. Create a maneuver node at somewhere around +/- 90o (plus or minus, either one, whichever is more convenient) from the target position.
    2. Adjust the normal or anti-normal vector/symbols (the pink ones) on the maneuver node until our orbit passes above our target.
    3. Perform the burn as projected to change our orbit's inclination.

    [Figure 113: Set up maneuver node, and change the normal/anti-normal until projected orbit is above target]

    [Figure 114: Burn]

    And we're almost ready to land.

    [Figure 115: About ready to begin our powered descent]

    To be continued. ...
    Last edited: Jun 20, 2014
  19. Jun 20, 2014 #18


    User Avatar
    Homework Helper
    Gold Member

    ... Continued from part five.

    To the Mun!

    Part six: Touchdown

    Non-atmospheric, powered descent is also a science. And I don't desired to pretend that I'm an expert on the subject. (But if you would like to discuss it more, please post! That's what this thread is for. :smile:)

    But maybe I can at least trim the obvious weeds and pick the low hanging fruit. In general, what are good strategies for descent, and what strategies are bad? That's a loaded question. There are safety factors, efficiency factors and maybe other factors that are sometimes at odds. There will be tradeoffs and compromises.

    So what is the most efficient strategy? That's a fair question. Let's use that question in a "Truth or Bunk" game. Here I will paraphrase and combine some of the jems and crap that exist on the Internet, and some I might have just made up here, to get hopefully get to the greater truth.


    "Truth or Bunk"

    Challenge: State the most efficient strategy to perform a powered descent for a Mun landing, and describe it in simple terms (the complexity and detailed nuances may be left out for this exercise). Safety concerns may be ignored, with the exception that it is not acceptable to include crashing as part of the strategy. The craft's thrust may be varied. However, the craft has a finite maximum thrust (not an infinite thrust). Don't concern yourself with what's practical, the goal is to describe only the most efficient strategy -- practicality and safety aside -- as long as it doesn't necessitate crashing as a part of the strategy. Also, you may ignore surface features on the Mun, i.e., hills, craters mountains, boulders, etc.

    Contestant #1:
    • Claim 1a: Burn horizontal starting at whatever typical altitude you might orbiting at, until your horizontal surface velocity is 0. Then begin free-falling straight down. Time it just right such that you fire your engines at maximum thrust such that your vertical surface velocity drops to zero just above the Mun's surface. This is called a suicide burn. It's the most efficient way to land, but requires precise timing.
    • Truth or Bunk?: That's just slightly on the "bunk" side, but there's still some truth to be found in there. The claim happens to be true that if you fist find yourself in the situation where your horizontal velocity is zero. If you find yourself in that situation, a suicide burn, as described, is the most efficient way to proceed. But Contestant #1 left the door wide open to the bunk section, by being vague about initial altitude. Certainly if you start the straight-down free-fall from a higher altitude, you will use more fuel that you otherwise would if you started at a lower altitude. That alone keeps it out of the truth section.

    • Claim 1b: Okay, smarty-pants. Same as above except that you start in a very low orbit -- an orbit at just the right altitude such that once you zero out your horizontal velocity you are very close to the surface, just high enough such that when you turn over pointing straight up, you can immediately start your suicide burn not too far above the surface, and just so that the vertical velocity is zero when reaching the surface.
    • Truth or Bunk?: So close. I can't give you the prize, but that's close enough to be taken out of the "bunk" section. It's not 100% there yet. I can't technically call it a truth, but it's not bunk either. I'll give a hint as to why it's not truth: The fact that you found your horizontal velocity zeroed at some distance above the surface in the first place is the reason. But stick around Contestant #1, we'll come back to your claim once we add in other factors like practicality and safety. :wink:

    Contestant #2.
    • Claim 2: Starting at a moderate orbit of 20,000 m, fire the engines at about 30% throttle, and gently follow the surface retrograde vector toward the surface. Once about half way, adjust the throttle and try to maintain surface velocity 5.0 m/s the rest of the way, gently down to the surface, following the retrograde vector.
    • Truth or Bunk?: No. Bunk. I hardly know where to start with that. You're not even accelerating the craft. By keeping the velocity at a constant 5m/s, all that fuel from 10,000 m to the surface is just wasted fighting gravity. This strategy is just awful, efficiency-wise. If ever you must perform a burn with a component parallel or anti-parallel to the gravitational force vector it is most efficient to perform the burn at maximum thrust, thus maximum throttle. There might be hint of hope in there somewhere about following the retrograde vector. And maybe lowering of the throttle near the surface might be good for safety reasons and margin, but not for efficiency. (By the way, if you're curious, I made Contestant #2 up.)

    Contestant #3.
    • Claim 3a: It doesn't matter what your initial orbit altitude is, just burn full throttle, surface-retrograde until your ship's velocity is zero and happens to be just above the surface.
    • Truth or Bunk?: That can lead to a contradiction. You can burn full throttle at surface retrograde to zero out your surface velocity, but there is no guarantee that you will be near the surface when that finishes.
    • Claim 3b: Fine, mister nit-picky. Start at a very low orbital altitude that's exactly the right height, such that when you burn toward surface retrograde at full throttle, and continue to follow the surface retrograde vector, you are just above the Mun's surface when your surface velocity goes to 0. Raise the nose up slightly if you would otherwise cross the surface you happen to get too close the the surface.
    • Truth or Bunk?: That might work out pretty well. It might not be a practical way to land (the ship might be leaning over, and might not be able to right itself when it lands), and might not be very safe either (even a small hill that gets in the way could mean disaster), and it makes a lot of assumptions about the initial orbit height for the mass and thrust of your rocket. But yes, in simple terms, that is the strategy could be pretty efficient.

    In fact though, maximally efficient way is so impractical that it's hardly worth mentioning. Start with an orbit so incredibly low that it actually skims just a hair above the surface. Aim the thrust such that it starts out horizontal (surface retrograde), at full throttle, and then angle the pitch such that the vertical component of the thrust is equal and opposite the difference between the gravitational force and the orbital centrifugal force. In other words, the rocket continues barely skimming the surface, gradually changing its pitch accordingly, until motion stops. But that's just silly. (Or is it?)

    One thing the efficient ways have in common though, they start with a low, orbital altitude, and they use maximum thrust.

    I wouldn't worry too much about the details of this "maximally efficient" descent. The whole point of this "Truth or Bunk" exercise was not to come up with a real and practical solution. Rather it was just meant as a thought experiment, in an attempt to get the reader to think about the extremes -- basically that low orbits and high thrust are involved in an efficient descent. As long as you don't completely neglect those two things, your descent will be good. All the other details are a wash. But now we have to curtail low orbits and high thrust with other constraints of practicality and safety.


    As soon as we add in other factors like practicality and safety, things get more complicated:
    • The Mun has some really high mountains and plateaus, definitely some well over 4,000 meters and others maybe higher. (This is as of version 23.5. The Mun-scape has changed before in KSP and could potentially change again.) It's not practical to just calculate "just the right, low altitude" because the Mun surface is so varied.
    • It's very difficult to tell how high your are above the surface until you are just above the surface. And that complicates everything. The radar altimeter in IVA might help with that, but that's only if you are over a flat, smooth part of the surface.
    • Unless you use install a mod that does calculations for you, it's practically impossible to get the timing of a suicide burn perfect, or for that matter even get close, even if the Mun's surface was nice and smooth.
    • At some point near the end of the landing, you're going to have to bring the ship down slowly and vertically. No, it's not the most efficient thing to do, but it's unavoidable for practical reasons.
    • If there is a particularly specific location (with a small area) where you are trying to land it makes everything more complicated.

    So I'll finish off by saying the best overall strategy probably has a little bit of all the claims above in it somewhere. With that, my best advice at this point is:
    • Use your new-found knowledge of orbital mechanics to bring the final, pre-breaking orbit to a lower orbit rather than a higher one. You don't want an orbit so low that you risk crashing into a mountain, but you don't want one much higher either. Maybe 5,000 meters would be a good orbital altitude for starters?
    • When breaking, keep an eye on what you're moving toward. If it appears that you are going to crash into something, raise your nose up a little temporarily to evade it. Otherwise burn surface-retrograde.
    • If you are approaching an object on a collision course, it's more efficient to take action earlier rather than at the last moment.
    • While burning retrograde to the very end might be a noble goal, it might be better to have a little margin such that your final approach is soft and vertical.
    • If you happen to have plenty of fuel, then you have more flexibility, perhaps even enough to ignore most or all of this.

    I'll leave the rest as an exercise to the reader. Or feel free to post about it! That is what this thread is for.


    And with that, let's get back to our kerbals.

    I'm going to start by ignoring everything discussed above, mainly because we've got loads of fuel. We've got enough fuel to do pretty much anything we want.

    And I'm trying to find a particular structure/thing that I saw on a previous mission while in orbit. But I don't know exactly where it is -- the the basic area in general. So instead of going to a lower orbit, I'm going to stay at the ~12,000 m orbit in hopes of spotting what I'm looking for.

    [Figure 116: Maneuver node placed around the general area of interest.]

    I'm going to put a maneuver node over the general area where I think the thing might be. I have no intention of actually using that maneuver node. The only reason I put the node there is because it informs us, in terms of time, how far away we are from the area of interest.

    [Figure 117: Preparing to start burn. Nothing unusual spotted yet though.]

    We need to start the burn now so as not to overshoot it by too much. Hopefully we'll spot the thing as the burn progresses.

    [Figure 118: Burn in progress, yet nothing spotted yet.]

    [Figure 119: Almost above area of interest. Yet still nothing out of the ordinary.]

    [Figure 120: Object spotted]

    [Figure 121: Moving in a little closer. Trying to find a flat surface too.]

    [Figure 122: Dropping mod-stage tank]

    By the way, that mid-stage tank got us a long way!

    It's a good thing too:

    Back in post #10, just below Figure 11, I said, "If we need to, we can put it on a collision course with the Mun by enabling the Mark 55 engines on the lander before separation." It turns out that wouldn't have worked. There seems to be a "bug" (so to speak) that engines above a lower stage provide no thrust until the lower state is separated -- even if those engines are radially mounted. I could have turned the Mark 55 engines on, and they would have used fuel, but they wouldn't have provided any thrust. I found this out through experimentation. Maybe the developers will "correct" this in a future version of the game.

    [Figure 123: Preparing for final approach]

    [Figure 124: Time to come down a little faster]

    Oh, and don't forget. Hit the 'G' key to toggle the landing gear. For some reason, for me, the first time I need to tap the 'G' key twice. After that, a single 'G' tap toggles the gear. 'Not sure why the second tap is necessary the first time.

    [Figure 125: Almost there]

    [Figure 126: This is why we install landing lights]

    [Figure 127: And we have landed]

    To be continued. ...
    Last edited: Jun 20, 2014
  20. Jun 21, 2014 #19


    User Avatar
    Homework Helper
    Gold Member

    ... Continued from part six.

    To the Mun!

    Part 7: Extra point, or two-point conversion?

    We have touchdown, and all systems look good. But where is that arch structure thing?

    [Figure 128: Zooming out a little]

    [Figure 129: Zooming out some more]

    Oh, my. I totally underestimated the distance to that arch thing. My goodness, how big is that thing anyway?

    It's going to take a long, long time for the kerbals to walk up to that thing. Maybe a shorter time with jetpacks, but I worry if they'll have enough RCS fuel for the trip.

    The lander module has plenty of fuel though. And this is one of the reasons why we designed it with a bit of margin! Just for this sort of thing. (That, and the possibility of performing larger, orbital inclination adjustment maneuvers, but I'll have to save that discussion for another day. It just doesn't fit into this story [feel free to post about the fuel costs and special, efficiency tricks of inclination adjustment maneuvers though. That's what this thread is for!]).

    Since we have the fuel to spare, let's try for another landing, and try to get a bit closer.

    [Figure 130: Don't overshoot it!]

    [Figure 131: How big is this thing?]

    Holy crap! (Figure 132) There is a massive cliff on the other side. Stay the hell away from there.

    [Figure 132: Holy crap!]

    [Figure 133: Bit of an incline, but definitely closer]

    [Figure 134: And we're there]

    [Figure 135: Extend ladders, and we're all set for one small step]

    To be continued. ...
    Last edited: Jun 21, 2014
  21. Jun 22, 2014 #20


    User Avatar
    Homework Helper
    Gold Member

    ... Continued from part seven.

    To the Mun!

    Part eight: What in the world?

    Jeb ventures out first.

    [Figure 136: Jeb steps out onto the ladder.]

    Jebediah is in scientific awe of that arch. What could it be? How could it have possibly formed?

    While Jeb is pondering the arch, let's get some science done like observing the materials bay,the mystery goo and the rest.

    [Figure 137: Doing science.]

    [Figure 138: Doing more science.]

    Also, I forgot to mention, I gave the kerbanauts a secondary objective, in addition to their normal surface samples, crew reports and such.

    One of the primary goals for this mission is to bring all the science materials back to Kerbin (Post #10). That hasn't changed. But for future missions, I want to investigate the feasibility of just taking the data back to Kerbin, so that I can leave behind the bulky science projects.

    If you bring the science back to Kerbin, and successfully recover them as part of your vessel, you get all the science points. If you transmit the data there can be significant point penalty involved; presumably some of the value is lost or maybe the transmission faces some corruption?

    But there is also a third possibility. If you send a Kerbal out on EVA to be up next to and close to the particular science experiment, you can click on the science experiment, and you'll have the option to "Collect Data." That allows the Kerbal to effectively take all the science points and store them in the capsule. That way one can then leave behind the science payload, since it's just dead weight at that point.

    We'll still be taking the science back to Kerbin on this mission. But Bill investigates how easy (or difficult) it is to get collect the science in a situation were no ladders are present near the science.

    [Figure 139: Bill investigates the possibility of collecting science.]

    Bill finds himself in a pretty precarious situation. He keeps wanting to slip off that ledge where he is standing. There are ladders on the ship, but none of them get close enough to science materials to use them to gather science data.

    [Figure 140: Bill is able to start collecting at least some of the science data!]

    There's still a whole other mystery goo container on the other side. Bill tries to use his jet pack to get up there.

    But Oh! He bounces off the side of the ship and falls to the ground straight on his head!

    [Figure 141: Bill falls, smack on his head.]

    Well, you know what they say. If you fall off the horse, ...

    Bill tries again. Oh, no! Bill falls again!

    [Figure 142: Bill falls, smack on his head again.]

    Oh, no. It's a good thing gravity is less up here. Had Bill fallen like that on Kerbin, he may have broken bones and possible spinal problems at this point.

    One more time.

    [Figure 143: Bill falls and tumbles down the incline.]

    Oh no! Bill is tumbling down the hill. He's just bouncing on the ground and tumbling down. Oh, that's gotta hurt. Oh, you can't see it in the image, but that last bounce was a big one. Oh, my. Bill is getting the crap beat out of him. Oh.

    [Figure 144: Bill slides for hundreds of meters on his face.]

    Oh, now he's just sliding. At least he's not tumbling. Oh, but he just keeps sliding. He's sliding on his face! On his face! He just keeps going for hundreds of meters on his face! Oh, poor bill. Sweet, fancy Neptune. On his face.

    Bill collects himself and figures out a strategy for climbing back up the hill to the ship. Meanwhile, Jebediah begins exploring the arch.

    [Figure 145: Meanwhile, Jeb jetpacks up to the top of the arch.]

    [Figure 146: Jeb reaches the top of the arch and plants a flag.]

    Jeb reaches the top of the arch and plants a flag. Having the flag there can be useful since it later acts a a marker, making the arch easier to find next time, if we ever want to come back to it.

    [Figure 147: Jeb on the arch (1/4)]

    [Figure 148: Jeb on the arch (2/4)]

    [Figure 149: Jeb on the arch (3/4)]

    [Figure 150: Jeb on the arch (4/4)]

    To be continued. ...
    Last edited: Jun 22, 2014
  22. Jun 22, 2014 #21


    User Avatar
    Homework Helper
    Gold Member

    ... Continued from part eight.

    To the Mun!

    Part nine: Eclipse

    Jeb uses his jetpack to descend from the top of arch.

    [Figure 151: Jeb descends from the arch (1/2)

    [Figure 152: Jeb descends from the arch (2/2)

    Uh, oh. It looks like we're in the umbra of a Munar eclipse.

    [Figure 153: We're in the umbra of a Munar eclipse]

    By the way, check out the elevation in Figure 153. We're 4718 meters above "sea level." Of course the Mun doesn't have any oceans. But presumably somewhere on the Mun there exists an area that is 0.0 meters elevation. And we're 4718 meters above that.

    And looking at Figure 150 of the last post, there seems to be some mountains nearby that are at a higher elevation than even we are.

    So remember when we talked about powered descent and first getting into a low orbit? Low is better, but no so low that crash into a mountain? Well, here we are already at 4718 meters, and it doesn't appear to be the highest altitude of land on the Mun. So keep that in mind when choosing your breaking altitude.

    [Figure 154: Jeb and Bill board the lander]

    Jeb and Bill are in the lander, but we better not go anywhere yet. The last thing we want is to lose attitude control during our ascent. The lander's batteries should hold plenty of charge to get us into orbit, but to be on the safe side, let's wait out the eclipse.

    Lets turn the lights off to conserve power while we wait.

    [Figure 155: Turn off the lights while we wait.]

    Eclipses are quite common on Kerbin. The Mun's inclination relative to the Kerbin's inclination around the sun (Kerbol) is 0.0 degrees. That means there is a "solar" eclipse and a "lunar" (Munar) eclipse every singe orbit of the Mun (well, that is from a Synodic orbital period perspective, relative to the sun [Kerbol]).

    And the Mun's orbital period is about 6 1/2 Kerbin days, where a Kerbin day is six hours. That means, both a "solar" (Kerbol) eclipse and a "lunar" (Munar) eclipse happens every 6 1/2 Kerbin days, and that's just over every day and a half measured by Earth days. So yes, they happen pretty frequently.

    By the way, is that the right terminology? If an astronaut is on the moon during a total lunar eclipse, is it still called a "lunar eclipse" from his perspective?

    I think it is. I don't think it really matters where you are at. I think it's still called a lunar eclipse, even if you are on the Moon, when the light from the Sun is totally blocked out by the Earth, even if you happen to be on the Moon at the time.

    I'm not 100% sure though. Please post if you have more information on this.

    [Figure 156: Still waiting. <Gah, does he ever shut up?>]

    Here is my logic. If you were observing from a different planet, say Mars or Jupiter, and you noticed the Earth passing in front of the Sun, this would be called a "transit."

    But that term doesn't apply to when we're on the Moon.

    Let's look at it from a different way. Suppose the Moon wasn't involved, and we are on a ship somewhere between the Surface of the Earth and some point in space, such that the entire sunlight is blocked by the Earth. I think the technical term for this situation is called nighttime.

    So the fact that the Moon is involved is what makes it a "lunar eclipse," whether we happen to be there or not.

    [Source: http://xkcd.com/1371/]

    [Figure 157: Finally! <maybe we can get some peace and quiet now.>]

    Okay! we're ready to ascend. Ascending from the Mun's surface is typically easier than landing, for two reasons: (a) you don't need to land, so there's less chance of "crashing," and (b) the lander has less fuel, thus less mass, making it lighter and more maneuverable.

    Since there's no atmosphere, we can turn over immediately and fly mostly horizontal from the beginning.

    One thing you want to do though before taking off is to try or orient yourself correctly. Plan ahead to make sure the ship takes off in the right direction. Accidentally getting into orbit in the wrong direction can have disastrous consequences in terms of wasted fuel.

    In this particular case, since we're near the equator, we'll want to ensure we pitch over on the 90o line on the navball, just like we would when taking off from Kerbin. But that is particular to where we landed this time. It wouldn't be so simple had we instead landed at more extreme latitudes.

    You might want to use the stars for navigation. Check for stars in the map view that line up roughly in the direction you want to go, and then shoot for them when you take off.

    However you go about it, do put some thought into getting your direction right before you lift off. Failing to do this could cause things to turn out pretty poorly.

    [Figure 158: We have liftoff!]

    [Figure 159: We have liftoff! (Map view)]

    I like to set up a maneuver node to finish to finish up the orbital insertion. That way I can compare it to the orbit of the command module, and make sure the inclination is roughly aligned.

    [Figure 160: Getting back into Munar orbit (map view)]

    [Figure 161: Getting back into Munar orbit]

    Before we forget, we need to separate the lander's main fuel tank and engines. If we achieve orbit before separation, it ends up as orbiting space junk! Even though there's fuel left in it, we must separate now!

    [Figure 162: Lander's main tank/engines separation (1/2)]

    [Figure 163: Lander's main tank/engines separation (2/2)]

    From here we can easily achieve a low, Munar orbit with the smaller tank and smaller engines.

    [Figure 164: achieving low, Munar orbit]

    To be continued. ...
    Last edited: Jun 22, 2014
  23. Jun 22, 2014 #22


    User Avatar
    Homework Helper
    Gold Member

    ... Continued from part nine.

    To the Mun!

    Part ten: Rendezvous

    In Kerbal Space Program (KSP), rendezvous and docking can be broken up into several parts:
    1. Orbit matching/coarse approach
    2. Maneuver for close encounter
    3. fine/close approach
    4. actual docking maneuvers.

    To start, select the command module as a target so we can compare orbits (Figure 165).

    [Figure 165. Select the command module as target.]

    One part of the orbit matching usually involves inclination adjustments as shown in Figure 166.

    [Figure 166. Inclination adjustment.]

    Note that inclination adjustments are not the most efficient in low orbits, but they do simplify everything if done early. Had we been hurting for fuel I might suggest putting the ship in a Hohmann transfer orbit first, with the pariapsis near one of the ascending/descending nodes, and then doing the inclination adjustment later when near apoapsis. While that is more efficient, and might save a little fuel, it does complicated matters quite a bit.

    I'll just keep things simple here, and perform the inclination adjustment in low orbit.

    The next step might be raise the lander's orbit to match more closely with the command/service module's orbit. Then use basic orbital mechanics to get closer still: Put the lander in a slightly higher orbit to let the service/command module to catch up, or put the lander in a slightly lower orbit to catch up with the command/service module.

    But I'm going to skip that step. Rough orbital matching is an important concept to know and practice. I almost feel I am doing a disservice to the reader by skipping it here. It's just that we don't really need to that here is all. Do know how to do such things. They're essential for docking a low Kerbin orbit, for example.

    But in our present situation, we can skip the rough orbit matching (now that we've made our orbits co-planar) and find a close encounter in a similar way we did when performing the trans-munar injection maneuver -- except we'll be approaching a ship instead of the Mun.

    Create a maneuver node and pull out the prograde vector. This is similar to the operation we did with the trans-munar injection burn. But this time, pull it out to just intersecting the command/service module's orbit (Figure 167).

    [Figure 167. Orbital maneuver node. Note the "Intersect" points and "Position of target at intersect" points.]

    You can see where the orbits cross there will be intersect points (the intersects of the orbits). Then there are the "target position at intersect points." this is where the target will be when you at the corresponding intersect points.

    Click on the center of the maneuver node, and drag it back and forth. Your goal is to get one of the intersect points to line up as close as possible with the "Target Position at Intersect" points.

    [Figure 168. Drag the center of the maneuver node to make an "Intersect" point closer to the "Target Position at Intersect" point. (1/2)]

    [Figure 169. Drag the center of the maneuver node to make an "Intersect" point closer to the "Target Position at Intersect" point. (2/2)]

    You can also make small adjustments to the prograde/retrograde vectors, and even the radial-in and radial-out vectors in the process. Try to keep the radial-in and radial-out adjustments to a minimum though, since they are less efficient.

    [Figure 170. After a little finagling, I found a close encounter of only 1.3 km. (Smaller is better. 1.3 km is great!)]

    For the first few weeks of playing KSP, I didn't use the "Intersect" and "Target Position at Intersect" markers. Instead I just used the basic orbital mechanics principles to get close to the target. But when I did finally learn how to use them, I found they saved a whole lot of time and effort. Learn them at your own pace. But realize that they really can save you loads of time once you learn how to use them.

    [Figure 171. Start the burn]

    [Figure 172. Start the burn (map view)]

    The next few images shows the two ships in map view as they drift closer together. The burn is completed in these images. The ships are merely drifting together.

    [Figure 173. Drifting together (1/7)]

    [Figure 174. Drifting together (2/7)]

    [Figure 175. Drifting together (3/7)]

    [Figure 176. Drifting together (4/7)]

    [Figure 174. Drifting together (5/7)]

    [Figure 175. Drifting together (6/7)]

    [Figure 176. Drifting together (7/7)]

    So how did I know that the ships would pass so close together? Again, it was by using the "Intersect" and "Target Position at Intersect" markers of the maneuver node tool.

    And now we are ready for our fine/close approach.

    To be continued ...
  24. Jun 22, 2014 #23


    User Avatar
    Homework Helper
    Gold Member

    ... Continued from part ten.

    To the Mun!

    Part eleven: Flight club

    [Figure 177: Approaching target]

    So here we are in Figure 177, approaching the target, command/service module. It's about 12 km away. I might have already adjusted my a little bit already, but we'll get back to that.

    In the mean time, let's review what prograde and retrograde really mean. I know we've been using these terms since the very beginning, but I think it's worthwhile for the reader to not just understand them, but to really comprehend them.


    Prograde/retrograde vector review

    We know that the prograde vector is the relative velocity of our ship, relative to something else. For example, target prograde is the relative velocity of our ship relative to the selected target.

    Target prograde has both a magnitude and direction. It's magnitude is our ship's speed and the direction is the prograde symbol shown on the navball (assuming we have "target" selected on the navball).

    Target retrograde shares the same magnitude as target prograde. But its direction is on the opposite side of the navball. It is also acceptable to define target retrograde as the speed of our target, relative to our ship.

    With the above in mind, take the following quiz. If the answers are not immediately clear, take a few minutes to contemplate the ideas, until you have an "Oh, okay. I get it now" moment.

    • Question 1: Suppose a ship, selected as your target, is drifting in your general direction along a straight line. First it comes toward you, then it passes you a little bit off to the side, and then it continues drifting away from you. Neither ship is thrusting, both ship are simply drifting (and let's ignore gravitational orbits for this exercise). How does your target prograde vector change over this time? How does the target's relative speed change? And how does the position of the target prograde vector change on the navball?
    • Answer 1: There is no change of the target prograde vector. The target's speed does not change. The target prograde vector on the navball remains in a constant position. The prograde vector is not a function of relative position. It matters not if the ship is moving toward you or moving away from you. As long as neither ship thrusts, there is no change to the target prograde vector (neglecting orbital changes caused by gravitational forces).

    • Question 2a: What if the target is quickly moving directly toward my ship, and I want to burn such that it slows down relative to my ship. Which direction should I burn?
    • Question 2b: What if the target is instead moving directly away from my ship, and I want to burn such that it moves away at a slower speed? Which direction should I burn in this situation?
    • Answer 2: Burn target retrograde. Burn target retrograde. The answer to both parts is to burn target retrograde. Burning retrograde will reduce the relative velocity of your ship with respect to the target ship. It does not matter if the ship is moving toward you are away from you. If you want to reduce the relative velocity between your ships, burn retrograde. It's as simple as that.


    Fine/close approach, basic algorithm:

    If you are new to rendezvous, you might want to use this basic, iterative approach for closing the final distance on your target ship.

    1. Burn target retrograde to zero out your relative velocity.
    2. Adjust your heading such that it is pointed at the target's bearing (the target's bearing is the large, pink circle on the navball).
    3. Burn toward the target's bearing a little.
    4. Let the target drift toward you. As the target passes about 90 degrees to your side, go back to step 1.

    Note that step 1 above, is a very natural way to match up your orbits. Assuming that you are very close to your target to begin with, then zeroing out the relative velocities forces your orbit to match up with your target's orbit. Two objects, sharing essentially the same position, and also sharing the same orbital velocity (in both magnitude and direction), have the essentially the same orbit. That's simple physics.

    While this iterative algorithm works, it is not what the NASA and Russian astronauts do when docking with the space station. They use a different approach. Below, the "more advanced" version I'll describe gets a little closer to what is really done.

    Fine/close approach, more advanced:

    If your target prograde vector matches up with the target's bearing, then the target is moving directly toward you.

    Similarly, if the target's retrograde vector matches up with the target's opposite-bearing (anti-bearing?) then the target is also moving directly toward you.

    Rather than iteratively reduce the relative speed to zero, you can adjust your direction to keep the vectors aligned, and thus reduce the distance in a single step rather than multiple, iterative steps.

    Burning in a given direction "pulls" the prograde vector toward that direction.

    Buring in a given direction "pushes" the retrograde vector away from that direction.

    You can do coarse changes by changing your heading to push the retrograde vector toward the opposite, target bearing (anit-bearing?) or push the prograde vector toward the bearing vector. This keeps you on a collision course.

    Once you get closer, you can reduce your relative velocity (burn retrograde), then perform fine adjustments using your RCS system, by performing lateral movements.

    Notice in Figure 177 that I have aligned the prograde vector with the target's bearing. The target is now rushing directly towards me.

    Eventually, I might want to slow down a little by burning retrograde. But I might not want to burn directly retrograde. Instead I burn mostly retrograde, in such a way that I "push" the retrograde vector to the be aligned with the target's opposite-bearing (anti-bearing?) vector, as shown in Figure 178.

    [Figure 178: Align the target's opposite-bearing vector with the target retrograde vector]

    Figure 179 and 180 show an example of "pushing" the target retrograde vector into the target opposite-bearing vector.

    In figure 179 it shows the target retrograde vector drifting just a tad away from the target opposite-bearing vector.

    In figure 180 I align my heading in a direction so that when I burn a tad, it "pushes" the retrograde symbol to be back, right on top of the target anti-bearing symbol. This causes the target to approach our ship directly.

    [Figure 179: "Pushing" the retrograde vector (1/2)]

    [Figure 180: "Pushing" the retrograde vector (2/2)]

    We can even calculate how much time we have until the ships meet. Figure 180 shows that we are approaching at about 30 m/s, and we have a distance of 2.4 km to close.

    So let me get my calculator, ...

    Calculator is out of batteries. Well, let me find a piece of paper. ... Okay, got one.

    Long division sign, ... 30 goes into 2400. ... move the decimal, ... 3 goes into 24, ..

    Oh, that's easy. That's just 80 seconds. I could have done that in my head. Doh! I didn't need a piece of paper for that.

    So how many minutes is that, well it's a little less than a minute and a half. Oh, my. When did I start...

    Retrograde thrust! Retrograde thrust!! 25 m/s. 20, C'mon, Thrust! thrust! thrust! 10, thust! Evasive... AHH, JASUS CRIPES!!! (Figure 181)

    [Figure 181: JASUS CRIPES!!! Image was taken moments after colliding with the command/service module]

    Ah, Jupiter's balls. :cry: I just crashed directly into the command/service module. Oh, man. I just broke every last rule of flight club (see just below Figure 106, post #17). Oh, no.

    Let's check for damage.

    [Figure 182: Collision seems to have torn off one of the solar arrays on the command/service module.]

    Oh, that can't be good. How's Bob doing. I hope Bob is okay!

    [Figure 183: Bob looks dazed. Maybe he has a concussion?]

    Oh, poor Bob. Are you okay, Bob? Oh, he doesn't look like he knows what's going on around him. It seems he got hit pretty hard. Oh, just look at him. Just look at him. Ah, I'm sorry, Bob.

    [Figure 184: Definitely a solar array missing]

    [Figure 185: No damage detected on lander module]

    The lander module seems to have fared a bit better. I think the brunt of the impact was on the flat surface on the bottom of the lander's fuel tank. Let's check in with Jeb and Bill.

    [Figure 186: Jeb seems in good spirits. Bill still looks a little shaken]

    I'm not sure why Jeb is in such a good mood (could he have been knocked cuckoo?). Bill looks pretty shaken up though. Of course that might be because of the previous mystery goo fiasco. 'Hard to tell.

    Let's let the crew regroup. We'll continue with the docking next time.

    To be continued. ...
    Last edited: Jun 23, 2014
  25. Jun 23, 2014 #24


    User Avatar
    Homework Helper
    Gold Member

    ... Continued from part eleven.

    To the Mun!

    Part twelve: Docking

    Now it's time to prepare for docking.

    Get fairly close to the target ship and then zero out the relative velocity. For review, this done by burning retrograde, just enough until the target speed drop to 0.0 m/s. That way they are standing still with respect to one another.

    The right-click on your ship's docking port (the one you are controlling) and select "Control from Here" (Figure 187).

    [Figure 187: Right click on controlling ship's docking port and select "Control from Here."]

    Then, while still controlling the original ship (in this case the lander module), right-click on the other ship's docking port, and select "Set as Target."

    [Figure 188: Right click on the target ship's docking port and select "Set as target."]

    Doing both of those things causes distances to be measured from one docking port to the other. It also causes orientations to be relative to the controlling ship's docking port, as opposed to the capsule or pod. This can be important if the docking port has a different rotational angle than the pod. It helps you align docking points rotationally.

    Now point your maneuvering ship at the target ship. It doesn't need to be perfect for now. We'll come back for a final iteration in a moment.

    [Figure 189: Point your maneuvering ship at the target ship]

    Next, switch over to the target ship using the "[" or "]" keys. Do the same thing of right clicking your own docking port and select "Control From Here" and click on the other ship's docking port and set it as the target (Figure 189). Finish up by pointing the ship at the other ship (in this case you are pointing the command/service module at the lander module, which should already be pointing at you). Use the navball this time. Make sure the ship's heading exactly lines up with the bearing of the other ship (Figure 190). Enable SAS to keep the ship's attitude from drifting.

    [Figure 190: Repeat with other ship]

    [Figure 191: Ships should be pointing at each other now. Use the navball to line up the heading with the bearing]

    Now switch back to the original maneuvering ship (in this case the lander module) using the "[" or"]" key, and align the heading with the bearing one last time on the navball. Enable SAS to keep the ship's attitude from drifting.

    [Figure 192: Adjust the maneuvering ship's attitude one last time. Make sure to align the heading with the target's bearing on the navball. Enable SAS. The ship now point at one another.]

    After this point, the ships are pointed at each other pretty much dead on. There's no need to do any more rotational adjustments (well, not unless something goes wrong).

    The next step is while controlling the maneuvering ship (in this case the lander module), switch the camera to CHASE mode. Cycle through the camera modes by tapping the 'V' key.

    If there is nothing else you remember from this thread, remember this: put the camera in CHASE mode for docking. CHASE mode is your docking's best friend. Well, that and make sure you design your maneuvering craft with RCS. RCS is also docking's friend. CHASE mode and RCS. CHASE mode puts the camera's orientation such that up is always up, left is always left and so on. Switching the camera mode to CHASE mode is a godsend for docking. Don't dock without it.

    [Figure 193: Put the camera in CHASE mode for docking by tapping on the 'V' key, until "Camera: CHASE" mode is selected. Don't dock without it.]

    At this point you have a choice on how to control your ship. (a) The normal RCS control keys, or (b) a remapping of keys in something called "Docking Mode."

    The normal RCS controls are available to you at any time. These are, after toggling RCS on with the 'R' key:
    'I', 'J', 'K', and 'L' keys for translational "down," "up," "left," and "right," and
    'H' and 'N' for "forward" and "backwards."

    If you have a keyboard in front of you, take a look at the layout. They are very similar in relative position as the 'W', 'A', 'S', 'D', and "Shift," "Ctrl" keys that you've been using for rotation and main engines, except they are off to the right for your right hand.

    Or, if you choose, you can instead control the lateral movements by licking on the "Docking Mode" icon at the lower left part of the screen, and then use the 'W', 'A', 'S', 'D', and "Shift," "Ctrl" keys for "forward," "backward," "left," "right," "up" and "down."

    Then you can switch between translational and rotational by hitting the spacebar.

    Here are my views on the pros and cons of switching the "Docking Mode"

    Pros of Docking Mode:
    • Docking Mode allows you to use the more familiar 'W', 'A', 'S', 'D', and "Shift," "Ctrl" keys, even for translational movements.
    • If you use a joystick, you can use the same joystick for rotational and translational movements when in docking mode (switch between rotational and translational with the space bar).

    Cons of Docking Mode:
    • Docking Mode provides absolutely no new functionality that you didn't already have anyway. But now you have to learn a whole new set of key-bindings. In terms of functionality, it doesn't bring anything new to the table.
    • Space Bar is used to switch between rotational and translational while in Docking Mode. But normally, Space Bar is used for staging. Accidentally pressing the Space Bar when not in docking mode can have disastrous consequences, because it will cause the rocket to accidentally stage. Docking mode might give the player a false sense of comfort when hitting the Space Bar.

    So use whichever method you are most comfortable with. If you are curious which I use, I used to use Docking Mode, but now I just use the regular 'I', 'J', 'K', 'L', 'H' and 'N' RCS keys.

    The most important thing though, is switching to Camera: CHASE mode. That will have a bigger impact that anything else.

    So now, back to our adventure. Turn on the lights. This is why we put on the docking lights.

    [Figure 194: Turn on lights. Notice the angular orientation of target docking port.]

    Notice the angular orientation of the target docking port. We want to roll such that the target docking port's black line is "up." We know it has to be "up" because we switched "Control From Here" to our own docking port. When you do that, the proper orientation for the target docking port is always "up." (That, and the fact that we switched to Camera: CHASE mode).

    [Figure 195: A bit of a roll, and we are in the correct angular orientation with the target docking port.]

    And the rest is simply, slowly moving forward (a couple taps and the RCS forward key, whether that be 'H' for normal controls or 'W' for Docking Mode), and then making minor corrections while approaching.

    Try to keep the target's bearing lined up with your heading. Don't make rotational corrections -- instead, just move translationally.

    [Figure 196: Final approach (1/5)]

    [Figure 197: Final approach (2/5)]

    [Figure 198: Final approach (3/5). Move just a touch to the left (per the navball indicaiton).]

    [Figure 199: Final approach (4/5). Uh, oh. Coming in a little too far "up." Better make a "down" correction.]

    [Figure 200: Final approach (5/5). That's better.]

    [Figure 201: The magnets kick in, and we are docked]

    To be continued ...
    Last edited: Jun 23, 2014
  26. Jun 23, 2014 #25


    User Avatar
    Homework Helper
    Gold Member

    ... Continued from part twelve.

    To the Mun!

    Part thirteen: Reunion

    [Figure 202: Docking successful.]

    [Figure 203: Extend ladders.]

    [Figure 204: Jeb and Bill make their way back to command module. (1/4)]

    [Figure 205: Jeb and Bill make their way back to command module. (2/4)]

    [Figure 206: Jeb and Bill make their way back to command module. (3/4)]

    [Figure 207: Jeb and Bill make their way back to command module. (4/4)]

    [Figure 208: All crew accounted for in command module]

    Now it's time to make a decision. Do we take the lander module with us back to Kerbin? Or do we leave it here to be crashed into the Mun at a later time? (Recall, the lander module has a remote guidance pod on it, so we can control it remotely).

    The lander module does have functional solar arrays, and even some fuel left. On the other hand, it's mostly dead weight at this point in the mission.

    "Crash it into the Mun!" "Crash it into the Mun!" we all agree.

    By the way, I should point out that if we had decided to take it back to Kerbin with us, now would be the time to disable the lander module's engines. They're presently pointing in the wrong direction! But since we're going to crash it into the Mun, it doesn't really matter.

    [Figure 209: Separate the docking port on the other side of the science payload]

    [Figure 210: And we are ready to head home]

    To be continued. ...
Share this great discussion with others via Reddit, Google+, Twitter, or Facebook

Have something to add?
Draft saved Draft deleted