Kerbin Moon Circuit Royale: A Short Film

Kerbin Moon Circuit Royale: A Short Film

by aubreygoodman, posted in Short Film

Watch on YouTube: https://youtu.be/9DRUsJ0YmC4

In the realm of hard problems, Kerbal Space Program offers many options. This story focuses on one such problem: land a single Kerbal on both moons in a single mission and return safely using the lowest budget at takeoff. There’s a lot to cover here, so let’s dive right in.

At first, the engineers focused on landing only on Mun and returning. We knew every design decision would be critical to the success of the mission. The first iteration used just a command chair and one of each of the things Jeb needed to maintain control of the vessel. We even considered leaving the battery out, but quickly realized the engine gimballing alone would make it very difficult to pilot. Everyone wanted to give Jeb at least a fighting chance of landing this thing.

It was immediately clear the optimal design would include a big first stage, deploying a tiny orbital vehicle payload to low Kerbin orbit. So, the team hastily assembled the first prototype, and Jeb hopped into the cramped quarters of its command seat. Looking back, it’s pretty clear the fairing was a lot more luxurious than originally anticipated. It ended up being basically a motorcycle in space. The view was amazing!

From low Kerbin orbit, Jeb aimed for a low Mun periapsis to take full advantage of the Oberth effect. Dropping in around 6km, he charted a retrograde burn to settle into a nice equatorial orbit before descending into the munar highlands. He knew he would need less energy to return to orbit if he landed at a high altitude. The landing was amazingly smooth … until the last moment, when there was an unexpected jerk in the pitch input. Forensic evidence from the, uh, “returned craft” would reveal the retrograde vector bounced off the ground plane and went negative. Jeb had to react quickly to prevent catastrophe. His report explicitly praised the helmet designers.

As he left the Mun surface, he pondered his likelihood of surviving the re-entry into Kerbin’s atmosphere without any kind of enclosure. He had to jettison the engine to reveal the heat shield he would use to keep cool during the aerobraking maneuver. The engineers warned about the possibility of some light heating on the re-entry, but Jeb got an A in ablative materials class. He knew this was a suicide mission. He had mistakenly dropped the Kerbin periapsis too low when leaving the Mun, and he had no fuel left to correct the mistake. He hoped for the best, but…

After an appropriate mourning period, Jeb’s brother Jeb announced he would honor his brother’s sacrifice with another attempt. He would use the same craft, but he would make a few adjustments first. He liked the overall design, but he felt there should be just a little more fuel in the third stage. The resulting fairing was a little too close for comfort on the ascent, but he felt like it was a rite of passage and left the discomfort out of his report.

Just like his brother before him, Jeb was able to pilot his modified craft to a smooth Mun landing. And just like his brother, his landing suffered the same awkward pitch jerk, bouncing off the ground. We really need to get that fixed… The landing must have disoriented Jeb. Before the medical team could assess him – and against the advice of the ops team – Jeb decided to chart a course to Minmus. They told him there was no way he could make it, but he tried anyway. Given the recent loss of his brother, everyone at the Kerbal Space Center took this news pretty hard.

It was pure determination that motivated their other brother Jeb to take bold action. At this point, all of Kerbin was devastated by the loss of two intrepid Kerbonaut brothers. The entire planet was reinvigorated when he decided to make another attempt. So, we rallied behind him, made some radical changes to the flight vehicle, and prepared for another potentially demoralizing flight.

This time, we acknowledged the fairing was enough to protect the pilot, but we couldn’t keep it past ascent circularization without making it impossible for the pilot to have any visibility. The only compromise was to use the next lightest part. So, Jeb reluctantly agreed to move the command chair into a service bay. With the doors open, he would be able to see straight up, but the forward view would be fully obstructed. He was going to need to land on instruments alone, and he was up for the challenge.

As he slowly ascended to low Kerbin orbit, he remarked on the durability of this new vehicle. We redesigned the orbital payload to increase the second stage fuel capacity. This gives Jeb enough fuel to land on Mun and begin to return to orbit. The third stage completes the Mun orbit burn, as well as the transfer to Minmus, deorbit, and land. However, Jeb will need almost all the fuel to return to Minmus orbit and transfer into a Kerbin aerobrake orbit.

The engineers agreed with the protective enclosure of the service bay, we could remove the heat shield and use the very highest part of the atmosphere to brake. With the service bay doors closed, Jeb simply kept the vehicle’s only solar panel pointed toward the star and waited in terror for his brother’s fate. He was happy to sacrifice some time to stay alive, so he aimed for a shallow aerobrake at 68km. This proved quite successful, as his suit temperature reported nominal all the way through the aerobrake maneuver and resulting re-entry.

Without the benefit of any space to work, Jeb relied on his instincts to chart a re-entry course, aiming to land at Kerbal Space Center. Subconsciously, he was afraid of exploding, but history will say he was unable to navigate around some troublesome weather, or something like that. As he opened the service bay doors and left his command chair for the last time, he felt thankful for the opportunity to try this in a simulator first. We had all learned some valuable lessons from the practice sessions. Jeb reflected on one particular experience, where he lost consciousness leaving the seat and woke up without enough time to deploy a chute. This time would be different.

As he watched his faithful chariot drift away to inevitable oblivion, Jeb thought about all the hard work and sacrifice made by his family and the engineers who made it all possible. He decided to retire. After all, he now held the record for the best attempt, and his family suffered a heavy burden in the process. He would forever be known as the first pilot to complete the Kerbin Moon Circuit Royale. But, he would not be the last…

How to Automate a Minmus Landing

by aubreygoodman, posted in How To, Mission Planning

Watch on YouTube: https://youtu.be/q7GDV539nnc

I don’t want to start off on the wrong foot and say automating a munar landing was easy, so let me say this instead. I was not prepared for the level of difficulty presented by Minmus. To be clear, the Mun landing required more than 25 attempts to achieve a 50% success rate, and that felt like a near miracle. With Mun, the goal was simpler. Its orbit around Kerbin is aligned with the ecliptic. This was a design decision made by the game designers to make it easier for players to make meaningful progress in the game. I’m glad they did because the game is arguably one of the most difficult on the market. The script suffers the same penalties experienced by new players. Things can go sideways quickly.

To review, the munar automation script stabilizes into low Kerbin orbit at 80km before computing a transfer orbit maneuver with a predetermined prograde delta-v. Then, after executing the maneuver, it settles into an elliptical orbit with a low periapsis before circularizing at 20km munar altitude. Finally, deorbit and hoverslam to land on the surface. Simple, right? Again, no.

Turns out you can’t simply adjust the prograde delta-v and let the script figure things out. After about ten attempts doing exactly that, I realized there were some significant barriers. For one, the Mun is in the way sometimes, and the script takes a looooooong time to find a solution. Also, it became clear there was a lot of room for improvement in my approach to throttle control. At this point, the results were not good. In the rare cases when I was able to chart an intercept course, the maneuver execution was … imprecise … and I ended up on an escape trajectory.

This makes sense, if you think about it. There’s a lag between the moment we detect some condition is satisfied and the moment the engines stop producing thrust. Chalk it up to a symptom of an engine with high thrust and high specific impulse. We overshoot every time, as a direct result of this delay. We can use simple solutions attempting to compensate, like decreasing throttle by 75% when we approach the engine cutoff condition. This only really reduces the magnitude of the observed effect and does very little to contribute to a more robust solution.

Our best approach is to rethink the control strategy entirely. The first time, it was simply a matter of activating engines at full throttle, deactivating when a condition is met. To achieve a more nuanced result, we will need to take into consideration how far away we are from achieving the condition. In mathematical terms, this means using a ramp input instead of a step input. A ramp input is more like slowing down gradually before stopping, whereas a step input is like slamming on the brakes at the last moment.

Let’s start by incorporating a proportional controller. Rather than providing a constant step input to the throttle, we reduce the throttle based on the remaining delta-v required for the maneuver. This allows us to go full throttle at the beginning, when there’s a large gap to traverse, and then reduce throttle as we approach the target. This gives us the ability to exercise fine control at the end of the maneuver when precision is most important.

Using this proportional control technique, the script is able to stabilize on an intercept orbit with Minmus. However, even with our precise throttle control, we still experience strange oscillations around the target in some cases. In one case, this was caused by a less-than where I needed a less-than-or-equal-to. In most cases, though, it was because the conditions were error-prone.

One key error I encountered was assumptions about the precision of the time warp tool. I incorrectly assumed the ETA for orbital transition would be accurate within a second. Sadly, it is not. This means sometimes the warp completes before the vessel enters the Minmus orbital patch. This has catastrophic effects on the automation process, as it picks the planet periapsis ETA instead of the Minmus periapsis, which is highly correlated with my cursing at the game. After sorting out this subtle nuance in the logic, the rest fell into place. Ok, so what does the code look like?

As with the Mun landing script, we use a runmode variable to manage each phase of the mission. We’ll start from orbit this time, to focus on the differences presented by a Minmus transfer orbit. Let’s dive in!

The main difference between Minmus and Mun orbits is the inclination. Minmus is inclined about 6 degrees from the ecliptic plane. Without adjusting the inclination, we may need to wait considerably longer to plot a transfer orbit, as Minmus shifts in and out of plane relative to Kerbin. Also, Mun intermittently interferes, making it more important to match the inclination.

As a result, our first maneuver after achieving stable orbit is to compute an inclination maneuver. We do this by creating a node with a starting delta-v in the normal direction. We move the node forward in time, comparing the inclination of the resulting orbit against the previous value until we detect an inflection point. Then, we adjust the delta-v until the resulting relative inclination approaches zero.

Once we have our maneuver planned, we simply time warp to the maneuver and execute the burn. Here, we use a proportional controller based on the ship’s scalar speed and the maneuver delta-v requirement. The limit condition is defined based on a simple threshold. We cut the throttle when the relative inclination approaches zero. Then, we proceed to the next runmode to compute the elliptical transfer orbit.

This phase uses the same iterative technique with constant prograde delta-v to find a maneuver node time with a Minmus intercept. Once we have a valid transfer orbit planned, we time warp to the maneuver and execute another burn. Again, we use a proportional controller based on speed and delta-v requirement. Again we use a limit condition.

Early versions of the logic simply added the appropriate delta-v and hoped for the best. This often left the vehicle on an elliptical orbit, but not necessarily on a Minmus intercept. This is because of the extended burn time introduced by the proportional controller. Maneuver nodes assume instantaneous impulse, and there’s no way to add so much energy so fast without squishing the meatbags.

A better way to achieve our stable intercept is to use a different condition entirely. Rather than wait for a specific delta-v change, we cut the engines immediately upon detecting a Minmus intercept. This helps to guarantee an intercept, but it’s worth noting this is not an efficient algorithm. It simply results in a well understood landing sequence, where we can re-use the components from our Mun landing script. We use different values for the altitudes, but otherwise the rules are the same. At this point, we have achieved our most significant milestone in the process. Time to enjoy the fruit of our labor.

While we watch the best attempt, let’s reflect again on the difficulty of this challenge. For the Mun landing, it took 25 attempts. This time, it took more than twice as many attempts. In total, this video required 64 attempts to reach the same success rate criteria. It seems only fitting to show all the attempts as one magnificent composite. So, sit back and relax. Enjoy this time lapse of all the attempts at the same time.

space craft landing on moon surface

How to Automate a Mun Landing

by aubreygoodman, posted in How To, Mission Planning

Watch on YouTube: https://www.youtube.com/watch?v=t4dIED5JLos

Getting to orbit with any vessel in Kerbal Space Program is a challenge that should not be understated. Players often make many mistakes in attempts at suborbital flights before they reach a stable low orbit. The road to efficient orbital launch is a long punishing ordeal, ripe with uncertainty. Moreover, every vessel flies differently; hard-learned rules from flight testing with one vessel prove useless or even counterproductive with other vessels. So, to talk about designing an automated control system capable of landing on Mun is to set the bar high. The good news is aiming high is kinda the point.

Normally, it takes a lot of staging and clever redistribution of mass and fuel to coordinate a lunar landing. In the interest of eating the elephant in smaller bites, this exercise uses a vehicle with a modified engine. Our resident rocket scientist adjusted the aerospike to boost the exhaust velocity up to about 10% of light speed. The resulting engine has enough thrust to take off from sea level on Eve and enough fuel to accelerate at 1G for a little over a day. This makes it a little easier to design our automation system. No pesky staging to interfere with our script.

But enough about rocket science… This is about computer science! :nerd:

Any sensible solution likely involves breaking down the problem into smaller chunks we might be able to tackle individually. This is a process called decomposition. While it shares its name with the process of death and decaying organic material, that is precisely the outcome we wish to prevent. It is worth noting in the vacuum of space there is no organic decay. Mostly we just turn into frozen desiccated meat bricks if things go horribly wrong, basically the worst freezer burn imaginable. But this is about robots, not meat bags, and we’re hoping to make robots who protect the meat bags and deliver them safely to a totally inhospitable environment because that’s what they wanted.

Before we dive into the various phases of the mission plan, let’s establish some rules. Ideally, each time we wait for a condition to be satisfied, we want the smallest number of components in our logic. This means using simple conditions wherever possible. Also, we don’t want to overconstrain the operational parameters, or the system may not converge toward the conditions and be forever stuck in a loop. For example, most of the conditions in this experiment use single edge bounded constraints, like “wait until periapsis is greater than threshold.” These simple constraints increase the chance of overall system stability, as they are less sensitive to unexpected side effects.

Our first step is to escape the gravity well and stabilize into low orbit. This is pretty much as simple as going as fast as we can while staying below transonic speed in the atmosphere. This specific craft has its aerodynamic center co-located with its center of mass to enable atmospheric re-entry with engines pointed retrograde without inverting and impersonating a badminton birdie. Plummeting head first in a swan dive into the dirt is the exact opposite of our desired outcome, so it’s helpful if we can orient the vehicle regardless of the environment.

Because we’ve decomposed our larger problem into smaller ones, it’s worth noting these represent discrete phases of our launch-and-land objective. As we review the script in detail, you’ll see this represented by the runmode variable. For example, runmode 1 engages our engines at a safe thrust. Once we reach a threshold velocity, we transition to runmode 2 where the launch profile maintains a TWR of about 1.25 during the ascent. This is the slow gentle climb up to our target altitude of 80km. Once we push the apoapsis to our target altitude, we cut the engines switch to runmode 3, where we coast up to the apoapsis. Just before the peak of ascent, runmode 4 engages and we raise the periapsis up to our target altitude to circularize.

Once we have a stable circular orbit, we move into runmode 5 and begin the process of computing a transfer orbit to the Mun. Using this script, we could launch at any time and still find a valid transfer orbit. This is because we rely on the known delta-v required to make the trip as we consider possible transfer points along our orbit. The script does this by creating a maneuver node and evaluating the resulting orbit. If the maneuver results in an encounter where the lunar periapsis is above ground, we have found a viable transfer point. Otherwise, advance the node by ten seconds and try again. Eventually, we will find an intercept and we move onto runmode 6.

With a valid intercept course plotted, we wait until the maneuver time and then execute the maneuver. There are several ways to do this. In this case, we compute a target scalar velocity and engage the engine until the velocity reaches the target. If we’ve done our homework, this should result in a transfer orbit with a Mun encounter with a subsequent lunar orbit matching our desired parameters. Now we engage runmode 7 where we manipulate time to advance to the lunar encounter, as the transfer takes about a day of real time.

Once we arrive at our encounter with the Mun’s sphere of influence, we activate runmode 8 to begin circularizing into a lunar orbit. We advance time again to bring the vehicle to the periapsis, where we engage the engines once again in retrograde to drop into an elliptical orbit with a low periapsis around the Mun. Once the periapsis falls below its target threshold, we cut the engines and wait until we coast down to the periapsis.

Here, we have one more retrograde burn to stabilize into a circular orbit around the Mun. This design uses a lunar orbit of 20km to reduce the impact of in-game time warp constraints. At this altitude, we engage runmode 9 and wait until we reach a longitude threshold before initiating deorbit. In this case, the specific value was chosen based on manual scouting. It was important for filming to have a landing in the sun. The first landing was indeed in the dark, and it wasn’t very camera friendly.

It’s much better to land on the sunny side where the audience can see it. I’m sure there’s a positivity metaphor in there somewhere… but I’m sure you’re more interested in the landing logic. The deorbit phase completes when we detect the vessel’s ground speed is below a threshold. At this point, we transition into our final runmode, the hoverslam. I found an example KOS script from an engineer at SpaceX, who was kind enough to share the code. Hoverslam is simple: control the throttle during powered descent such that the velocity and altitude reach zero simultaneously. I was extremely pleased with the hoverslam phase, which was fortunately the most reliable part of the experiment.

Now that we’ve reviewed each part separately, let’s put it all together as a time lapse of the best attempt! For what it’s worth, I really enjoy the cloud mod, as it adds a rich context and a sense of realism to take these recordings to the next level.

Okay, so we’ve reviewed all the parts individually and seen a full example of the mission from beginning to end. By now, I’m sure you’re excited about outtakes. Like how did it fail? It turns out it failed in several very tightly clustered groups. Let’s take a look.

First, it failed on overconstrained logic conditions. This version of the script does not show all the terribly stupid things I did in earlier examples. For one thing, I had an extra phase dedicated to lowering the periapsis immediately upon entering the Mun sphere of influence. This extra phase added complexity without adding much value, so I settled on the simpler version you see here. I also had weird logic errors, which didn’t manifest until late in the script. Much like the early pioneers of space travel, we don’t have the luxury of resetting a virtual environment to retry with different code. KSP doesn’t offer the ability to simulate any scenario without first doing all the hard work to get there.

The most common failure I encountered was misinterpretation of conditions upon entering the lunar sphere of influence. The script frequently went rapid fire through the lunar circularization sequence, often skipping important parts and leaving the vessel spinning out of control. Automating time warp was a critical aspect of standardizing this behavior enough to make meaningful recordings. Using manual time warp led to unpredictable results in the script itself, likely because of poor precision. By automating timing in the script directly, the system behavior was substantially more predictable.

With a stable trigger for a landing sequence, the script was able to achieve impressive results, with tight grouping on the final landing locations. All examples use a hoverslam technique to control velocity during descent. In every case, the landing was successful, except one instance when the vehicle landed on a steep incline and was lost shortly afterward.

So, let’s watch a grid of the sixteen best attempts, all together at the same time. If you’re interested, you can watch this same video in real time here. And as always, thanks for watching Kerbalism!

Mining Part 2, Mining Colony

by aubreygoodman, posted in Asteroid Mining, Kerbalism, Mission Planning

Vimeo: https://vimeo.com/324381843

YouTube: https://youtu.be/1MprhkvcIaw

Welcome to Kerbalism! I’m your host, Aubrey Goodman. In this episode, we upgrade a manned surface station into a mining colony.

In our last episode, we landed a construction core on Minmus, ready to expand itself to support higher volume resource processing. Now, it’s time to grow our station into our first mining colony. We need a manned presence to enable ongoing mining operations, extracting resources from the surface.

With asteroids, there is a much smaller opportunity for resources. If the asteroid is only one thousand tons, we spend a lot of energy and time with finite benefit, equal to the mass of the asteroid. We must repeat this for each asteroid we wish to harvest. If the asteroids are small, we may use more resources capturing them than they yield from processing.

Moons are different. Resource abundance on the moon surface is effectively limitless, compared to the cache in the asteroid. Once we’re settled in at a good location, we can produce an arbitrary amount of fuel and send it back to orbit. We’ve chosen Minmus because its surface-to-orbit delta-v is very small. The cost of sending resources from the surface to orbit is much lower than Mun or Kerbin. From the surface of Minmus, we can launch into low planetary orbit for about one third the cost of launching from the planet directly.

The construction core is designed for expansion. The goal is to land the bare minimum mining gear and use it to build the rest on-site. Our station core has both radial and vertical expansion options. After we add processing components, we expand outward with more support struts with the same radial and vertical options. These become new expansion points and we repeat as needed.

Of course, expansion comes with its own challenges. Our first expansion of processing equipment was lost when it overheated and exploded. Fortunately, no other nearby parts were damaged. The expansion plan must include increased solar and thermal management. We also need to leave room for ships to land for refueling. These vessels will not be docking in the traditional sense. They simply land near the station and connect via fuel hose. The hoses are limited in length, so ships will need to land close to the hub and wait for colony crew to attach the hose before fuel transfer can begin. Once attached, the station can transfer stored fuel or make new fuel on-demand, until the ship’s reserves are full. Then, it’s simply a matter of detaching the fuel hose and blasting off to Minmus orbit to rendezvous with an orbital fuel station.

Using this technique, we can deliver fuel within our planetary system to support the needs of any ships traveling between the planet and its moons. As we expand to other planets, we create new mining colonies on moons as needed.

As always, thanks for watching Kerbalism!

Mining Part 1, Construction Core

by aubreygoodman, posted in Asteroid Mining, Kerbalism, Mission Planning

Vimeo: https://vimeo.com/314334638

YouTube: https://youtu.be/HvigCivcMvg

Welcome to Kerbalism! I’m your host, Aubrey Goodman. In this episode, we build a manned station on the surface of a small moon using a construction core.

In our series on asteroid mining, we used unmanned probes with mining equipment to extract and process resources from nearby asteroids. We converted them into fuel and metal, the raw materials required to expand the capabilities of an orbital construction platform. Now we must accumulate enough rocket parts to begin building our construction core.

The core itself has an empty mass of about 20 tons, so we’ll need at least 20 tons worth of asteroid just to provide the bare minimum mass. In KSP, there is no waste from the refining process. In reality, this would involve a consideration for waste management. For our purposes, we’ll simply define our threshold as double the empty mass to be safe.

Turns out we need more than we had available in our captured asteroid, so we need to capture another one. After a bit of patience, we find a viable target and proceed with intercept. This time, we find one much larger, so it will be sufficient for this mission and hopefully others. Our patience pays off! We’re fortunate to secure a huge rock with over 2500 tons of viable resources.

Now, we ferry ore back and forth between our harvester and our construction platform, while the processing equipment churns the ore into rocket parts. After many ferry trips, we have enough raw materials, and construction begins.

While the core is being built, we change the focus of the ore processing equipment. We must convert enough fuel to enable the core to execute the transfer orbit maneuvers and land safely. The core has just enough fuel reserves to make the entire trip from planetary orbit to landing. Once we land, we will be able to make as much fuel as we want.

Also, we need to identify an ideal landing zone, where resources are abundant. We do this using a resource surveyor in polar orbit around Minmus. The surveyor satellite provides a map of ideal landing locations. We select a viable equatorial candidate and begin the landing sequence.

Our station does not have landing gear. Instead, it has heavy pads for its base, so we need to set it down very gently on a flat surface. We selected a landing zone in a flat equatorial region with sufficient resource abundance to support our needs. In our next episode, we begin to expand the capabilities of our surface station to support fuel harvesting on a larger scale.

Thanks for watching Kerbalism!

Asteroids Part 3, Orbital Fuel Infrastructure

by aubreygoodman, posted in Asteroid Mining, Kerbalism

Vimeo: https://vimeo.com/313035570

YouTube: https://youtu.be/s0joNt7b0D8

Welcome to Kerbalism! I’m your host, Aubrey Goodman. In this episode, we build our first ship in space using resources collected from asteroids.

Building things in space isn’t much different from building on the planet’s surface. The laws of physics are the same, and delta-v calculations rely purely on thrust, mass, and fuel. The main reason we build in space instead of on the planet is the cost of sending things into orbit. Every craft we build must use a minimum delta-v to launch into orbit. This means we need exponentially larger launch vehicles for larger payloads. If we build in orbit, we only need to build the payload.

This means our spacecraft designs can now focus on optimizing for mission requirements. It also means we are no longer constrained by the aerodynamic environment. With the exception of atmospheric surface landers or gas giant surveyors, our designs need not take drag forces into consideration, since they will always be in space.

First, let’s look at one of our most important vehicles – the ore tug. This craft will ferry ore between the asteroid harvester and an orbital construction platform. It will need enough fuel reserves to perform the transfer orbital maneuvers required to move between the harvester and construction platform. It needs to account for a full ore storage tank in one direction and an empty tank in the other. This way, we don’t over design and bring more fuel than we need.

Next, let’s consider the construction platform itself. The platform is assembled in space, just like the other stations. We launch various components in phases, starting with a core and adding empty storage containers and fuel tanks. Since we will be building things using raw materials, we will need containers for those materials. The size of our containers will be the limiting factor preventing us from building beyond a maximum mass. We need the materials on-hand to build our craft.

With our fully operational station, we can begin to ferry ore from the asteroid. Here, we use some KSP addons to approximate the logistics of manufacturing. Ore is processed into metal and fuel. Metal is subsequently processed into rocket parts, which we use to assemble our spacecraft.

After we have processed and prepared our resources, we begin construction of our first spacecraft. We’re going to build onto our existing station first to expand its existing capabilities before we start building other things as well. Then we’ll build a construction core, with all the capabilities of our orbital platform.

In our next episode, we land our construction core on Minmus and use it to begin building other components.

Thanks for watching Kerbalism!

Asteroids Part 2, Capture and Harvest

by aubreygoodman, posted in Asteroid Mining, Kerbalism, Mission Planning

Vimeo: https://vimeo.com/311723008

YouTube: https://youtu.be/628eqhhpV5s

Welcome to Kerbalism! I’m your host, Aubrey Goodman. In this episode, we harvest resources from an asteroid and use them to capture the asteroid in orbit.

In our last episode, we intercepted an asteroid and grabbed onto it. We still need to slow it down in order to capture it into planetary orbit. If we don’t slow down, our harvester will be swept out of the planet’s sphere of influence to solar orbit along with the asteroid. Since the whole point is to use the resources within the asteroid, we need a retrograde burn with the asteroid in tow.

We’ve used most of the fuel to position our harvester. If we’re lucky, we might have some fuel to slow down, but there’s a good chance we’ll need to do a little harvesting before we can perform the maneuver.

This is where we begin to encounter the boundaries of what KSP can do. As sophisticated as it is, the unmodified game supports only one form of resource processing – fuel. We can convert ore into various fuels, but we can’t make metal or rocket parts to build directly in space. There are addons to enable this, and we’ll use them in the next episode.

This is also where we surpass the real world capability. The game allows players to grapple an asteroid and extend drills, all with the click of a button. Clearly, we don’t yet have this level of technology available in the real world.

The reason we use a harvester to capture our asteroid is simple. It would be expensive to bring enough fuel to slow down the asteroid, so we bring harvesting equipment along and use it to make fuel after we arrive. By carrying fuel processing components, we can plan to use most of our fuel to intercept and attach to the asteroid. Then, we can mine resources and process them into fuel to fill our tanks before the return trip.

With adequate fuel in our tanks, we perform a retrograde maneuver to settle into stable planetary orbit. The final altitude of our asteroid’s orbit will affect our orbital fuel harvesting operations, so it’s important to consider the details.

If the asteroid inclination is high, we will need extra fuel to ferry ore between the harvester and the processing facility. However, the asteroid itself is massive, so we would need a lot of fuel to move it to a different orbit. In our example, we settle into a circular orbit around the planet, between our two moons, but in a highly inclined orbit.

With an asteroid in stable orbit around the planet, we can begin to use its resources. In our next episode, we refine these resources into metal and rocket parts to build spacecraft directly in orbit. Don’t miss it!

And thanks for watching Kerbalism!

Asteroid Part 1, Intercept and Rendezvous

by aubreygoodman, posted in Asteroid Mining, Kerbalism, Mission Planning

Vimeo: https://vimeo.com/309555177

YouTube: https://youtu.be/0g4-8K4fRVg

Welcome to Kerbalism! I’m your host, Aubrey Goodman. In this episode, we intercept and rendezvous with an asteroid.

As we expand to build stations on other planets in the system, we need to evolve our concept of manufacturing. Instead of building everything on Kerbin and launching to orbit, it makes more sense to build an orbital construction facility and use resources collected from asteroids to build new craft directly in orbit.

Before we can do anything with an asteroid, we need to identify and classify nearby objects worthy of our attention. This is the first part of a sequence of tasks we must undertake in order to collect materials from an asteroid and refine them. A tiny asteroid may have only 15 tons of usable resource material. While it may sound like a lot to the uninitiated, this would yield barely enough fuel to a few maneuvers.

In order to find high value targets, we need a solar satellite with an infrared scanner. With this equipment, we can identify and begin to evaluate possible targets. This new satellite is smaller than our solar relay. It uses less fuel to deploy. We will eventually need more than one, so we can identify asteroids at different distances from the star.

Using our infrared scanner, we begin to identify nearby asteroids. In KSP, there are alerts notifying the player about newly discovered objects. We need to find one on an intercept course with Kerbin. This makes it easier to get to the asteroid. Objects further away or not already on an intercept course will require more fuel and more advanced planning to capture into orbit. The asteroid itself is traveling faster than the planet, so it will not settle into orbit around the planet on its own. We must grab it and slow it down to stabilize in orbit.

In this example, we’ve settled on a target asteroid about 50 tons in mass. Its existing intercept orbit will bring it within 39 thousand kilometers of the planet. This means we need about the same delta-v as a trip to Minmus. Again, we would need much more to intercept with a free asteroid on a solar orbit.

Just as we saw with orbital stations, asteroid harvesters must also be assembled in orbit over several phases. For the purposes of this episode, we will build it on Kerbin and send it into orbit empty. Then, we send support missions to deliver fuel to the harvester in orbit. It would be prohibitively expensive to send the fully fueled harvester into orbit. All that fuel weighs a lot, requiring more powerful engines, which weigh even more. By reducing the payload mass by delivering components in parts, we can dramatically reduce the first stage fuel requirements.

Once we have the harvester fueled up and ready to go, we can proceed with the rendezvous. We do this in four maneuvers.

First, we need to align the harvester’s orbital plane with the asteroid. For highly inclined orbits, this may use a lot of fuel. One of the benefits of being in low planetary orbit is easy access to refuel missions. If you use a lot of fuel changing the inclination, you can top up the tanks before the long trip out to the rendezvous point.

Second, we need a prograde burn to raise the harvester’s apoapsis to match the asteroid’s periapsis. In other words, we raise the high point of the harvester orbit until it meets the low point of the the asteroid orbit.

Third, we need another prograde burn to bring the harvester periapsis up to a point where the two craft come within 50km of each other near the rendezvous point. This is a precision maneuver and requires a bit of finesse to pull it off.

Finally, we burn in the direction of the target to close the gap, ultimately locking onto the asteroid with the grappler. After we have our asteroid locked, we point the solar panels toward the star. Then we can start drilling!

Intercepting an asteroid requires a lot of delta-v. There’s a good chance we used up most of our fuel in the intercept process. Now it’s time to get ready for our next episode, capturing the asteroid down to planetary orbit. We will need to collect ore and process it into more fuel to slow down the asteroid. Stay tuned!

And thanks for watching Kerbalism!

Stations Part 3, Nearby Planets

by aubreygoodman, posted in Kerbalism, Mission Planning

Vimeo: https://vimeo.com/310704564

YouTube: https://youtu.be/V6dT4-zPk8c

Welcome to Kerbalism! I’m your host, Aubrey Goodman. In this episode, we send a manned station to Duna.

After we have built sufficient infrastructure, we’re ready to take a bold step. It’s time to send a manned mission to orbit around another planet in our solar system. In the real world, we would be going to Mars. For the purposes of our discussion, we’ll go to Duna, which is a lot like Mars.

Just as before, we will construct our station in planetary orbit before sending it on its way. This time, though, we need to use completely different designs for the support craft we’ll be taking with us. The science and tourism landers designed in the last episode were meant for landings on moons.

Duna has significantly more mass than a moon. Its gravity is about twice that of the Moon, so we need extra delta-v to land safely. We do get one huge benefit for free. By landing somewhere with an atmosphere, we can use heat shields and parachutes to slow our descent. This saves a lot of delta-v and reduces the fuel requirements for our landers.

Science landers involving samples will need a reserve of fuel to takeoff and return to the station. For now, we will skip the return trip to save on weight. Until we have a more sophisticated refueling option, fuel is a precious resource. We’re also sending relay satellites instead of tourism landers. Ferrying tourists will have to wait. Besides, the landers are no good if they can’t communicate their findings back to home base.

With our station assembled and all its support craft docked, we’re ready to plan an escape orbit! We could simply burn prograde to accelerate out of Kerbin’s gravity, but this would need a lot of fuel. Instead, we rely on the moon to give us a gravity assist. By flying close to the moon’s surface, we take advantage of the moon’s gravity to accelerate us away from the planet.

It works like this. If we encounter the moon on the leading side, in its direct path, its gravity will slow us down. If we find ourselves on the trailing side, in its wake, we will slingshot around it and gain enough speed to escape planetary orbit.

Now that we’re on a solar orbit, outside of Kerbin’s gravitational influence, we can chart a course to Duna. Unfortunately for us, we have chosen our launch timing poorly. We must wait nearly 400 days before our Duna intercept. Clearly, we’ve glossed over the details about planning to sustain a crew for 2yrs until the next resupply mission can be expected to arrive. In the real world, people need to eat.

As we approach the planetary encounter, the station prepares to perform a retrograde burn to settle into a circular orbit. After assessing our fuel status, we determine we have sufficient fuel to deploy our relays before descending into our final orbit to deploy surface landers.

Now that we have stations spreading throughout the system, we need a sustainable way to harvest fuel in space. After watching time lapse video of refueling missions, maybe you’ve started to appreciate the value of finding fuel sources in deep space. In our next episode, we intercept an asteroid and begin to harvest its resources!

And thanks for watching Kerbalism!

Stations Part 2, Lunar Orbit

by aubreygoodman, posted in Kerbalism, Mission Planning

Vimeo: https://vimeo.com/309137882

YouTube: https://youtu.be/YZj6RmCgXJ8

Welcome to Kerbalism! I’m your host Aubrey Goodman. In this episode, we deploy orbital stations to our moons.

In our quest to explore our solar system, we seek new information to help us make sense of the universe, to expand our understanding of physics. Having a manned station in orbit around a moon helps pave the way toward increased traffic to the moon and acts as a support point for missions to its surface.

Just as we did for planetary stations, we first send an unmanned fuel pod into low lunar orbit. This will help prepare for future missions. Deploying a manned science station at the same altitude but on the opposite side of the orbit helps increase utility. The fuel pod acts as a last ditch option for crafts running critically low on fuel. Having both stations on the same orbit at opposite ends effectively doubles the chance a struggling craft can dock with a station.

Orbital science stations act as a staging point for science missions to the surface. We want to make sure we have docking ports of all sizes on these stations, again to maximize utility. Also, since this station will be supporting other smaller craft, it needs a large cache of fuel, monopropellant, and electricity.

After the station is assembled in planetary orbit, with all its supporting craft docked, we’re ready for transfer orbit. With fuel reserves adequately filled, we plan and execute our lunar transfer maneuvers. This means a prograde maneuver from planetary orbit and a retrograde maneuver to settle into a low circular orbit around the moon.

From here, we can send our unmanned support craft to the surface to explore and gather samples. We can also ferry tourists to the surface for a space selfie. Tourism helps generate revenue to stoke the financial furnace to pay for our science missions.

We’ve spent a considerable amount of resources just to deploy stations to our moons. It’s going to take a lot more funding to build and deploy manned stations to other planets. In our next episode, we send a manned station to Duna, which is a lot like Mars. Don’t miss it!

And thanks for watching Kerbalism!