Missions!

KSP does not have missions, it has contracts.  What the hell are you talking about?

That is technically true.   In KSP the official concept of a quest is really called a "contract" in keeping with the whole space program theme.  However, missions do exist as a concept even if not supported by mechanics.  There are various definitions for what a mission can be, however, for now, let us assume that a mission is any operation involving a flight, atmospheric or through space, that has some purpose in advancing the goals of our space program.  Missions include completing contracts, but there are other reasons to embark upon missions.  Lets just talk about a few and why performing a variety of mission types other than just completing contracts is important to the success of our space program.   In doing so, we may be able to get our arms around the realm of possibility when faced with the question, "now what?"

Mission: Contracts

Contracts are the life blood of our space program, because the advancement of our program depends almost entirely on our ability to pay for parts, fuel, recruits and buildings.  Contracts also augment our scientific knowledge by awarding a small number of points upon completion.  The amount of points can add up rapidly over time.  Contracts also provide an increase (or decrease) in reputation for our program upon completion (or failure).   Reputation is a slushy currency.  It can be converted into science points of funds.  It can also be accumulated to unlock better quality missions.  As such, reputation points, if accumulated, act as a kind of investment into future missions.  This can enhance the growth rate of the program as it matures.

Mission: Infrastructure

Infrastructure includes hardware and kerbals that are strategically deployed to enable the success of future missions.  Often when designing a mission, it helps to fly a few mission beforehand to forward deploy resources that are needed for the actual mission to succeed.   Reasons why infrastructure might be needed are many and varied, but they include:

• Staging fuel in orbit to extend the range of a deep space mission
• Staging parts in orbit to incrementally build a deep space vehicle rather than attempting to launch an impractically large structure from the KSC pad
• Mining and refining resources into fuel to be used for space operations rather than launching fuel from Kerbin at greater expense
• Enabling communications (when using the RemoteTech mod)
• Establishing a permanently manned space presence that can serve as an abort location for busted missions among other uses

Mission: Prototyping

Spaceflight and atmospheric flight is risky business.  Risk is such an important factor in managing any flight operations program that it is a central aspect of all program management activities.  A risk can be defined as any undesired incident that can occur during a flight resulting in the loss of capability, crew or equipment.  Prototypes are built and tested to minimize certain kinds of risks, especially those risks caused by design flaws.

The purpose of a prototype mission is to test a prototype design.  A prototype design is usually created when the program manager (us) is not sure whether or not a design will work as intended.  For example, we may want to launch a crew of two kerbals into orbit around the mun.  Replacing each Kerbal will cost us at least 125,000 (can be much higher if we already have other kerbals active in our program).  The total cost of the launch vehicle and payload that can put two kerbals into orbit around the mun is probably somewhere around 20,000.  Lets say for argument's sake that we have designed a solid fuel booster stage for the launch vehicle that relies on a radial attachment to attach itself to the main engine stack, and let us say that we have never tried to use radial attachments and are unsure if they will fail during the flight do to the high sheering forces produced by the booster engines.  It could be said then that there is a risk that the attachment will fail resulting in a complete loss of all stages including the payload and the loss of both crew members.  The total cost of this loss can be calculated as 20,000 (vehicle) + 125,000 (crew replacement) = 145,000.   

Rather than launching and hoping for the best, we act wisely as managers of our program and we decide to build a prototype vehicle to test out the attachment parts under realistic conditions.   First, we build the launch vehicle exactly as we intend to launch it.  Then we build a payload by replacing the manned command pod with an unmanned probe core.  Not only does this lower the cost of the vehicle to 18,500, but it also allows us to perform the testing without risking our crew.  If the prototype fails, we lose only 18,500.  If it succeeds, we may even get some of that 18,500 back as recovered parts.  Once we complete the prototype mission, we are out the cost of the prototype vehicle, and now we can adjust the attachments to make them sturdier, or perhaps do nothing at all if the testing went fine.   Now we can run the actual manned mission using this launch system at a much reduced risk of failure.  And rather than accidentally losing 145,000 on a failed manned mission, we intentionally spent 18,500 to ensure that the chances of the greater loss are minimized. 

Flying a prototype mission lowers risk.  It allows us to test complicated designs without risking the valuable lives of our crews or risking valuable payload equipment.  Prototype vehicles do cost money.  So what we are doing is effectively "buying down" risk by paying for the prototype mission.  The actual activity we perform to buy down risk is known as a "mitigation".  So prototyping missions exist so that we can mitigate risk by buying it down.  This is an important concept in any program management strategy, and one well worth taking a closer look at!

Mission: Exploration

Exploration is a mission that we perform to expand our scientific knowledge of the Kerbol solar system.  Exploration may include mapping the surface of a planet from orbit, searching for mineral deposits that can be exploited, or searching for a suitable location to build infrastructure, such as a planet-side station.

Exploration can be manned or unmanned.  Most initial exploration makes use of unmanned probes, because they have less mass as payloads than manned command pods and are also generally cheaper to build.   Additionally, probes have much longer exploration ranges due to the fact that they need not ever return to Kerbin like manned vehicles.  This mean that a probe's delivery system can use 100% of its fuel to go to far away destinations without ever needing to return.

Most of our scientific knowledge (science points) will be obtained from exploration missions.  Probes will often be fitted with instruments to observe and measure the characteristics of planets, moons, asteroids and even Kerbol itself.  This data might then be transmitted back, as is the case with most unmanned cores, or returned and recovered on Kerbin for more efficient analysis.

Exploration is a crucial element of any space program.   It provides the primary means by which we obtain scientific knowledge, which is essential to unlocking advances in technology and enabling a broader range of missions, including longer range exploration.

Mission: Rescue

We have all been there.  Despite our careful planning, we launched Bill on a mission to explore the surface of the mun.  Everything went to plan.  Bill landed on the surface and took one small step for a kerbal and one giant leap for kerbal-kind.  And when he got back into his lander, he checked the fuel gauge and realized, there is not enough for a return flight to Kerbin.  Bill just became a permanent mun resident---unless....we can launch a rescue operation (with more fuel this time please) and get him off that rock before his air runs out.  That's the "rescue" mission.

Mission: Learning the Mechanics

A new program manager may find piloting a rocket into orbit a rather daunting task.  To close this experience gap, the program manager may build a simple rocket or airplane to just teach how to fly and establish a stable orbits.  This comes at a cost--nominally the cost of the vehicle and possibly the loss of a kerbal if a manned mission is destroyed.

Mission: Just Because You Can!

At the end of the day, the kind of missions available and their potential is really an exercise in engineering creativity.   Sometimes we may just launch a rocket to just show that a certain feat can be done.   Maybe we just want to bump up the experience level of one of our pilots before he's assigned to a long range mission to Duna.   Whatever the case may be, the possibilities for the kinds of missions that you execute are entirely up to you, the program manager.  Just try something out and see where it goes!

Multipurpose Missions

For cost reasons, it can be very advantageous to lump two or more missions into a single flight.  For example, we may have a contract to take a tourist into orbit around Kerbin.  At the same time, we may have a contract to test a solar panel while in orbit.  Yet at the same time, we may want to gather some scientific data using an instrument to which we recently gained access.  And YET at the same time, we also have to rescue poor Bill who ran out of fuel while landing on the mun and cannot get home.   Can we do all of that on one flight?  Probably or the entire crew will perish trying.  Good odds, so get the engineers on this right away!

Conclusion

Managing a successful space program means knowing what kinds of missions are possible and being creative to invent new missions based on the situation at hand.   Program managers think ahead and will design a sequence of missions to support an overarching space exploration program.  These missions will be a variety of types.  An example of a sequence supporting an initial program whose aim is to put a kerbal in stable orbit around Kerbin might be as follows:

1. Execute a series of contract missions to build up funds and piggy back scientific instruments to complete exploration missions on the same flights as the contract missions.  These exploration missions will unlock the parts needed to build a spacecraft to get to the mun.
2. Once feasible, build a probe and launch an exploration mission to the mun to collect more scientific data.  
1. This flight also allows us to perform a prototype mission on heavy launch vehicle designs that will be used for the actual manned flight.  
2. As an added bonus, we can use the mission to learn the mechanics of performing transfer orbit skills that we will need to make the transfer orbits to the mun and back during the actual manned flight.
3. Once a heavy launch vehicle is designed and is well tested during prototype missions, attach the payload to the launch vehicle and then perform the actual manned flight.  This flight may have contract missions to perform and it will likely involve an exploration mission involving EVAs.

So there we have it.  A look at how missions are more varied beyond what we are contractually hired to do.  Often, we undertake non-contractual missions to improve our ability and capacity to complete advanced contracts.  As such, it is important that we execute a variety of contracts and to do so intelligently in a way that directly supports our short and long term goals.

Greetings, Fellow Kerbonauts!

I started to write about KSP as a sandbox simulation and listing a series of guiding constraints that I personally follow to make the game a bit more interesting to me, but I got bored of writing it, so I assumed that others might also become even more bored trying to read it.  So I've decided to write about a practical topic instead--how to minimize debris fields around Kerbin also known as "avoiding creating a minefield of junk flying at bullet speeds in space!".  This is my first foray into writing about flight operations and rocket design techniques based on my own experiences.  If you have your own technique or lessons learned that you would like to share, please do!

So a bit of background about what is meant by debris fields.

Most players encounter debris the first time within their first few missions.  A basic starting rocket might consist of a command pod, a fuel tank, an engine, and a separator ring between the fuel tank and the command pod.  The rocket launches and ascends to a mid-level altitude.  Then the separator is activated and the command pod and the engine/tank assembly split apart. Just like that, the first bit of rocket debris has been created by your space program!  The command pod remains under player control and will typically deploy a parachute, splash down into water, and be happily recovered along with the green guy sitting bravely throughout this flight inside.  The fuel tank/engine assembly falls as uncontrolled debris back to Kerbin, and if we are lucky, it will crash harmlessly into the water or some barren patch of land.

This simple example illustrates how debris is generated during sub-orbital flights, which are those flights where "what goes up must come down".  However, rocket science defies conventional wisdom and not everything that goes up will come down.  When this happens, we have created what KSP calls persistent debris.

Debris comes from many sources.   Here are just a few examples:

• Fuel tanks and engines (possibly attached to each other) jettisoned during launch staging or after orbital transfer burns
• Separators that have been .... er separated
• Parts jettisoned to fulfill a contract mission
• Forgotten parts (and various tools) that floated away
• Parts left-over floating around Kerbin after a catastrophic failure (or Kraken attack!)
• Probes and satellites that ran out of electricity and forgot to deploy/orient (or attach) solar arrays
• Payload fairings jettisoned once a rocket has reached space.  Payload fairings typically come from add-ons (mods) like the Procedural Fairings mod.
• Or even a command pod with a stranded (and cheerfully bitter) kerbal inside who left home without enough fuel to de-orbit his space craft and return home

Sub-orbital debris is generally not a problem.  It is jettisoned while the space craft is a sub-orbital trajectory, so no matter what the space craft decides to do at that point, the debris will almost always remain on the original sub-orbital trajectory.  The fate of sub-orbital debris is always the same.  Eventually, it will re-enter the atmosphere (if one exists) and make a sometimes spectacular crash on the planet or moon's surface.  This is an important mechanic when attempting to control how much debris is generated during mission operations, as we will soon see.

Orbital debris is a different problem than its sub-orbital cousins.  Orbital debris is one kind of persistent debris, which means it sticks around until removed.   Since it sticks around, it can get in the way of later missions.  If debris gets in the way, it could cause a collision, which, if forceful enough, could create a catastrophic failure for an otherwise perfectly healthy rocket on its way to places far away.   "Space is vast, and so the chances of collision are very small.  Why should we care?" you ask.  All of that is true.  The space around Kerbin is three dimensional and consists of millions and millions of cubic kilometers of open space.  However, most people tend to launch their rockets the same or in very similar ways.   I would even wager that most people tend to launch into equatorial orbits heading east with an altitude of anywhere between 75km and 125km.   That would seem pretty typical to me.   Since these parking orbits are normally used repeatedly, the debris ejected while in a parking orbit could create hazards for future flights using the same parking orbit.

It is worth noting here that even debris jettisoned during transfers from an orbit around a main body (e.g. Kerbin) to a target body (e.g. Mun) could still be very hazardous.  Debris that is in a transfer orbit trajectory will have one of three fates.  First, it might just crash into the target body.  Second, it might slingshot around the target and end up in an escape trajectory, which usually puts the debris in orbit around Kerbol, the central star.   Third, the debris could end up in a free return trajectory and fall back to the main body.  In a free return trajectory scenario, the debris might return to the main body and crash or it might assume a very highly elongated orbit with an apoapsis as high as the target body.  Debris in these highly elongated orbits are particularly dangerous because they tend to intersect low-altitude parking orbits at extremely high speeds due to the fact that a vehicle's orbital velocity is at maximum when crossing periapsis.  Luckily, the window of these intersections is very narrow.  Still, the danger exists.

So, for those of us that like to keep the traffic lanes of space clear of hazards, minimizing the creation of orbital debris is an important aspect of rocket design and flight operations.  So what are come things that can be done to keep the launch lanes clear of these supersonic surprises?

1. Design rockets where nearly all stages that have to be jettisoned are separated before the first orbital insertion burn after launch.  Any debris created before the first orbital insertion burn will be on a sub-orbital trajectory and will eventually re-enter the atmosphere, crash and be removed.  Anything jettisoned after the orbital insertion burn will remain in that orbit and become persistent, which is something that should be avoided.
2. Make debris removal a built-in feature of the upper stages of your rockets.  Many rocket designs will have 2 or more stages including the payload itself.  Bottom stages are used for the orbital insertion burn and transfer orbits and subsequent orbital insertion burns to distant places.  Sometimes they are used for transfer orbits that return to Kerbin so are never separated along the way.   The stages above the bottom stage might be used for landing and ascent from a distant moon or planet.  The upper stage might even separate from the bottom stage and perform its own re-entry burn.   Whatever the design might be, what is important for designing in debris reduction is making sure each stage that is placed into stable orbit has a way of being recovered, destroyed, or placed into an orbit that is "out of the way".
3. Make debris removal pay off!  Recently, Squad introduced a feature in KSP where recovered parts result in a return of some of the cash required to build them.  Consequently, exercising smart debris removal can result in lower overall mission costs.  It is even rumored that KSP may implement a limited part supply system in the future.  What this means is that parts that are used come from a finite pool.  Parts recovered are returned to the pool.  Once the pool of parts is exhausted, that kind of part cannot be used until replenished.  So, exercising some control over debris recovery might also improve the availability of parts in the future.
4. Try to recover separated parts that cannot be recovered on their own.   For me, this usually means parts jettisoned in orbit to fulfill a requirement of a contract.  If "testing" separators, make both parts attached to the separator an independent, recoverable vehicle.  Another approach might be to use a mod like the Kerbal Attachment System to rope in a detached part using a wench and radial connector and then drag it back into a sub-orbital trajectory (on re-entry).  The same approach can be used to recover dead probes/satellites or large stage debris (fuel tanks) in orbit.  It might also be possible to use the latest asteroid capture claw for this purpose.

Here is an example of rocket trajectory illustrating how debris is controlled during flight.  This trajectory is basic and is possible early in KSP when playing the career mode.

The key elements of this design include two booster stages (Stage S-III and S-II which are designed to coast the payload to a sub-orbital apoapsis of at least 75km, which is just outside the atmosphere.  These stages are separated before the suborbital insertion burn at Step 6 and retain their sub-orbital trajectories while Stage I and its payload are rocketed into a stable orbit.  Eventually Stages II and III will crash back to Kerbin, removing them from the simulation.  Stage I and the payload remain in stable orbit until the decision is made to return to Kerbin.   At Step 9, a retro-grade reentry burn is performed, which creates a new sub-orbital trajectory for Stage I and the payload.  At this point its not uncommon for Stage I and the payload to be separated.  Stage I is usually destroyed on reentry and the payload deploys parachutes to make a soft landing in somebody's backyard.  Throughout this entire mission, none of the parts from the launched rocket are left behind as persistent debris.  None of the lower stages were jettisoned while in stable orbit, and the Stage I module remained attached to the payload until the reentry burn was performed.

This is really simple example of how debris is minimized during rocket design and flight operations.  More complex missions, such as a trip to Duna, would require more sophisticated planning.  In some cases a decision might have to be made whether a little extra delta-v might be needed in the upper stages of a trans-planetary rocket to dispose of a jettisoned stage on the way to Duna, causing it to crash into the planet while the rest of the expedition happily burns into a stable orbit around the red planet.   When designing a rocket, a little extra delta-v can add up to a big change in the lower stages.  Whether or not the extra weight at launch is worth the benefit of minimizing debris, is entirely and completely up to you, the program director!

Until next time, Smooth Launches!

Greetings!

Thank you for visiting Enlas Space, where you will find my endless ramblings about the Kerbal Space Program, the wonderful space simulation game from Squad.   If you have never heard of the Kerbal Space Program before, I highly suggest you visit the Official Kerbal Space Program website without further delay!

We'll be talking about anything Kerbal that comes to my mind.  Design notes, flight techniques, latest kick-ass mods, accomplishments, tales of interest!

So anyways what is KSP?  To introduce KSP, one must first learn about Kerbals.  Kerbals are little green men that live on the planet Kerbin, which orbits the star Kerbol.  Kerbals have advanced far enough in their civilization to begin to reach for the stars, so they founded the Kerbal Space Program, and they put YOU in charge!   However, reaching for the stars is not something these little green men can do overnight.   At first, they will take small steps, flying within their atmosphere and in sub-orbital flights.  As their knowledge grows, they will reach further into the heavens, achieving orbit around Kerbin, and then from there to places far beyond!

While managing the space program, your job will be to design the space craft (and aircraft) that will slip the surly bonds of Kerbin and plunge deep into the mucky (and delicious) pudding of the Mun!   Spacecraft are assembled from parts such as engines, fuel tanks, command pods, or even specialized parts that can perform science, and experiments, and other....things.   As every Kerbal knows, space craft design is mostly stacking things and pushing the ignition button to see what happens.  Presumably, that's obvious.  Even so, each craft has to be designed with some purpose in mind building on the lessons learned from previous disast...erm, educational flights.  Care must be taken to ensure that each rocket has enough thrust and fuel to reach its destination!

After designing spacecraft, your next job is to assist the brave kerbonauts (the green men that fly rockets) in flying the rocket designed for them.   This includes performing engine burns, separating rocket stages, deploying solar panel arrays, and even taking the pilot for an EVA (that's Extra-Vehicular Activity for the un-initiated!) in the blackness of space. Just remember your training---never EVA behind an armed engine nozzle a few seconds before the next maneuver.   Bad.

But managing a space program is more than just designing and flying rockets.  For one thing, all of these rockets cost a lot of money to build and Kerbals really don't know anything about rockets anyways despite wanting a first class (or perhaps second class) space program.   This means that your program will need to perform contracts for companies on Kerbin to raise funds to build new rockets.  Additionally, on each mission (or at least some of them) your kerbals will need to perform scientific research, which, when returned to Kerbin, can be used to unlock more advanced parts for your latest rocket designs.   Eventually under your management of the program, Kerbals will steadily advance in their exploration of their solar system at an minimal acceptable cost of lives.  (note from GK: just remember, even kerbonauts have families, so be kind to them.)

So there you have it.  The first ramblings of a kerbal space program director.

Smooth launches!

Enlas