Minmus – Kerbalism

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…

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.

Tag: Minmus

Kerbin Moon Circuit Royale: A Short Film

How to Automate a Minmus Landing