Wednesday, December 12, 2012 Space!

This might seem like a radical departure from the normal content of my blog, but I assure you that by the end of the post you will see that it is not. But yes, for I think the very first time I am going to post about a computer game! I'm not much of a gamer: the only game for which I ever achieved "fan" status was Gran Turismo, an epic racing game that frustrates most players because of the hyper-realistic physics engine.

Now I think I have achieved fan status for a new game: Kerbal Space Program, an epic space game that frustrates most players because of the hyper-realistic physics engine.

The Kerbals are a race of tiny green men who choose to go to the moon and do other things, not because it is easy, and not because it is hard, but because they seemingly have nothing better to do with their time and no monetary constraints or self-preservation instincts to keep them tied to the ground on their home planet, Kerbin.

"This will certainly go somewhere when we press the launch button."
The game has been under development for two years and is still pre-release. I was introduced to it by my brother back when there was only Kerbin and one moon. There is now a free version (v0.13.3) and a paid version (v0.18.1 at the time of writing). The paid version includes a vast solar system, more parts, and more features such as EVA (spacewalking) and docking. The real benefit of the paid version is that it gets you access to any and all future updates including the release version.

Thus far the pre-release versions have been true "open-world" games...except even that concept ceases to capture the nature of the game when there are six worlds and many moons to explore. While future versions will likely have "career" modes with a set of missions and a budget, the game right now has no concept of money or points. You build a spacecraft out of a set of parts, and then fly it to wherever you want.

Including, if you want, the top of the vehicle assembly building.
The parts inventory is made more entertaining by the descriptions of what each part does, which reflect the essential character of the Kerbals to some extent:
"The TR-18A Stack Decoupler is equipped with a (hopefully) small explosive charge, that will sever the structural linkage between itself and whatever it's connected to."
 "A monster of an engine for heavy lifting purposes, the Mainsail's power rivals that of entire small nations."
Also, parts are not limited to spacecraft: newer versions of the game include jet engines and aircraft parts, as well as a horizontal runway for commencing normal flight:

But although the sandbox aspect and the snap-together rockets and relatively humorous Kerbals make the game seem like it would be a good iPad app to kill time on the bus, the real nature and challenge of the game comes from the physics engine, which is based on real orbital mechanics in the Kerbol System, where planets are generally smaller but denser than those of the actual solar system. (Kerbin has the same surface gravity, 9.81m/s², as Earth, but is only 600km in radius.)

The first thing KSP teaches you is just how damn hard it actually is to get something into orbit. Getting into orbit is not the same as getting into space. A balloon can get into space (almost). To get into orbit, you have to both get out of the atmosphere and build up enough horizontal velocity so that you no longer need to spend fuel to fight gravity. (You fall as fast as the planet curves away from you.) For low Kerbin orbit, this requires a speed of about 2,000m/s.

But because you're fighting gravity and aerodynamic drag on the way up, the actual amount of propulsion needed is much higher than would be required to go from 0 to 2km/s in space. In fact, the actual speed increase (ΔV) you would be able to achieve in space using the amount of fuel required to launch into low Kerbin orbit is something like 4.5km/s. To put any sizable payload, like a ship that can go to the moon (called Mun in the game) and back, into orbit requires a pretty large rocket.

Note the speed is still well below orbital velocity.
So the next thing the game teaches you is what spacecraft are mostly made of: fuel. The rocket equation tells you that the ΔV you can achieve with a particular rocket is limited by only two things: how fast the exhaust is, which is a property of the engine, and what fraction of the rocket's mass gets thrown out the back. Only the ratio of starting to ending mass matters, so a small rocket or a large rocket can get into orbit equally well if they have the same engine and are both 70% made of fuel. The only reason to use a larger rocket is so you can put more final mass into orbit.

The realistic physics lead you to create multistage rockets. Once on stage's fuel is used up, you detach it to get rid of the dead weight (thereby increasing the percentage of the remaining mass that is fuel). There are also trade-offs among different engines: some have higher exhaust velocity but too low of a burn rate to produce enough thrust to get into orbit. These are better for maneuvering in space. So you wind up having to think carefully about the design of the spacecraft if you want to go farther.

For example, you can go to Duna, the Kerbol System equivalent of Mars.
Another cool feature just recently added to the game is docking. If you think aiming for a small moon is hard, try aiming for another ship which has no gravitational attraction with which to pull you in when you get close enough. Maneuvering two ships in orbit to the point where they could be docked was by far the hardest thing I've had to do in the game so far. But the reward is an almost unlimited ability to build larger ships or refuel in space.

The game does not (yet) have an autopilot that will help you launch, land, dock, transfer orbits, etc. But it does have a nifty maneuver planner that will show you the anticipated result of a maneuver at some point in your orbit. It will show you which way to point your ship and give you a countdown of how long to burn your engines to get where you want to go. But you still control the pointing and burning, so it's still a bit hard to do really precise long-range orbital maneuvers. For example, it's possible to do single slingshots but something like a Voyager trip would be very hard to do without a more advanced planning and autopilot system.

So far, I have been able to make successful trips to the Mun and return. I also made a one-way trip to Duna, which was punctuated by a harrowing untested parachute descent which barely cleared a crater wall.

Clearing the crater wall by about 1km while still going 0.5km/s...
Looking out from the crater rim to the landing site.
My current spacecraft, designed from scratch for interplanetary travel in v0.18.1, looks like this:

Stage 1 is driven by four Mainsail engines, the largest in the game, and burns for the first ~75 seconds of the launch. Stage 2 has a single Mainsail engine and burns for another ~85 seconds. These two massive stages are able to produce a total ΔV of 3.39km/s (Yes, I calculated it. As an interesting comparison, the ΔV possible from the two stages combined into one, with five engines all burning, is about 2.92km/s.) While quite heroic given the massive payload, this is not enough to get into low Kerbin orbit, so Stage 3 has to do some work on the way up.

Stages 3 and 4 combined are the interplanetary portion of the ship, designed for taking three Kerbals to the far reaches of the Kerbol System, and maybe sometimes back.

Stage 3 uses four of the "atomic" engines (strange name since they run on normal liquid fuel...) which are the most efficient stock engine (highest exhaust velocity). But they have relatively low thrust, so they're not great for getting off the planet. They work best for long burns to perform transfer orbits. Stage 4 is the lander itself, which uses the "Poodle" engine. This engine has enough thrust to get off a small planet or moon. You can see it landed on the Mun in the first image of the post.

Stage 3 and 4 can produce a whopping 5.67km/s total ΔV. That should be plenty to go to most destinations and back from some. I think it can do a landing and return from Mun, Minimum, or Duna, although the latter two are untested. A Duna return in particular would be hard due to the uncertain amount of fuel required to land on and take off from Duna. (Minimus requires very little fuel for this since it's tiny and has no atmosphere.) Other planets are either too massive or too far (or both) for a landing and return trip, I think. But flybys and one-way trips to almost anywhere should be possible.

But, Stage 3 consumes about half its fuel just to get into Kerbin orbit. That's why I was so excited to try out the docking feature. Now I can combine two ships in Kerbin orbit and transfer full fuel to one of them. I can even use most of the remaining fuel in the second ship to boost the whole assembly out into deep orbit, a trick that should bump the whole mission's ΔV starting from low Kerbin Orbit to something like 6.52km/s. That amount of fuel should provide plenty of deep space maneuvering ability for going to check out places like Laythe, a potentially habitable moon of Jool (Kerbol Jupiter)...

So many possibilities.
And now I feel the need to apologize for any number of person-hours of productivity this post will cause to be lost forever into deep space.


  1. Hi, I have been looking at your earlier posts with regard to sensorless control. Currently I drive a motor in open loop with the volt/herz method. When I implement the flux observer I have trouble with accumulation of errors in measurements resulting in that the flux curves goes off to plus or minus infinity (over time) - how did you deal with this issue?

  2. I use a low-pass filter in the flux estimator instead of a pure integrator. The low-pass filter behaves like a integrator in series with a high-pass filter, so only AC quantities are passed - DC bias of sensors get filtered out. More description of this method, and some side-effects of it, is in this post:

    I'm working on a document that has more detail on choosing the filter time constant and how it affects performance of the flux estimator.

  3. Tanks! That seems to have solved my problem..