The fuel tanker problem and how it relates to KSP!

[tntristan12]

Hello everyone! So my latest project in KSP has been to establish a round of mining operations on the Mun using the ever fantastic Kethane mod. Well, as I am sure some of you have experienced, moving Kethane around from place to place can be a bit tricky depending on how much you want to move and where you want to get it. Sure, throwing together rockets in KSP and playing with them until they work is fun, but I also get a sense of enjoyment out of understanding how things work, which is why I'd like to think I make a pretty good engineer. So I put on my thinking cap, shut off KSP for a little while, got out my pen and paper and started designing a spacecraft at the drawing board level!

Well, I got in deeper than I thought I would. I guess you could say I nerd-sniped myself, but in the end I started probing into delta-v optimization for fuel tanker type spacecraft. Now, what do I mean when I say "fuel tanker"? No, I'm not talking about the Exxon Valdez! A fuel tanker type spacecraft in the manner I've defined it is a spacecraft that adheres to a strict two-phase mission profile that can be repeated indefinitely for as long as needed. The underlying principle is that a fuel tanker must not touch its cargo stores of fuel before reaching its destination, and once it gets there it uses a predetermined amount of the cargo to refuel, offloading the rest. The entire cycle looks something like this:

So what makes this so tricky? Well, have you ever built a spacecraft designed to do just that, only to find that the amount of fuel you burn to get it where you need to go was greater than the amount of fuel you brought on as cargo? Fortunately I managed to derive a series of equations that serve as a sort of rule book for designing fuel tanker spacecraft, and I documented my findings in .pdf form, which I am linking...

iiiHERE!!!

...for all the world to read. Think of it as my gift to the KSP community for helping me get my rockets off the ground in the first place, and realizing my love for aerospace engineering and rocket science in general. I wouldn't be where I'm at today - pursuing a master's degree in Aerospace Engineering while researching space debris management at a tier one university - if it weren't for you guys.

Anyway, enough of that sentimental fuss! Let's get down to the mathematics of it all. I won't touch on all the math in this post because I've laid it all out for you in the .pdf, but I will explain my results and what they mean, and how you can use them to build better rockets! The first thing I came up with (which actually turned out to be the easiest part of this whole thing) was the whole idea of "mass targets." A mass target in the context of a regularly repeated, delta-v managed mission such as this, is basically the mass you want your spacecraft to be at when it gets to a certain point in the mission. It's the point where you evaluate how much delta-v you've used, and how much delta-v you've got remaining.

You can experiment with this in the VAB now that we have tweakables - using a mod such as engineer redux or mechjeb, you can change the amount of fuel in your spacecraft and see how much delta-v you have. Unfortunately with Kethane you can't use the tweakables bar to add Kethane to the tanks, so you're going to have to add the result to your mass manually and use the Tsiolkovsky Rocket Equation to determine how much delta-v you'll have at that point. Although with mass targets, using TRE to calculate delta-v is really more of a reality check than anything.

So, what are the mass targets for a fuel tanker mission cycle? Here they are:

Let me explain. R_1 and R_2 are the mass ratios over the first and second legs of the mission respectively. They are calculated from TRE, and given by R = exp(- delta_v / (9.8 * I_SP)). R_12 is equivalent to R_1 * R_2, which can itself be physically interpreted as the mass ratio that would result if the tanker did not take on cargo during the mission cycle. Again, this is all explained in more detail in my document so if you're confused or curious to know more please check it out!

Anyway, m_cargo is the amount of propellant the tanker will take on. If you're using Kethane then you don't have to worry about adding fuel and oxy masses because Majiir did such an excellent job balancing the mod that conservation of mass is totally observed and if you convert a quantity of Kethane to fuel and oxidizer you'll get the same aggregate mass of both as you had of Kethane when you started, so for all intents and purposes Kethane == Fuel + Oxy.

Oh, and m_offload is the amount of propellant you are intending to offload at the final destination. Now, don't try to be clever and set that equal to m_cargo because it won't work. The laws of thermodynamics prohibit you from getting something for nothing, just like in the real world. So, if that's the case then how much cargo can you take on and offload for a given design? Well the relationship between them turns out to be

Okay, yes I know. Lots and lots of symbols, I'm sorry! Let me go through some of them and hopefully they'll make sense. m_struct is the structural mass of the spacecraft. This includes the mass of everything that isn't fuel or fuel tanks, so that means engines, struts, trusses, wings, landing gear, ladders, parachutes, mystery goo, snacks, everything. Try to overestimate that number if you can't figure out exactly what it is because your craft has too many parts or whatnot. It's better to over-engineer than to under-engineer. f_bft and f_cft are what I call the fuel tank factors. I broke them apart into two because Kethane tanks weigh a lot more than stock KSP fuel tanks, but each represents how much mass of fuel tanks you will need for a given mass of fuel. f_bft is for the burnable fuel tanks, or non-cargo fuel. f_cft is therefore the fuel tank factor for the cargo/Kethane tanks. For stock KSP tanks that carry both fuel and oxy, f_bft is 0.125 and for unedited Kethane tanks, it's something like 0.205.

Generally you will know either the m_cargo or m_offload that you are trying to design for. If you have a tanker that's picking up from a surface base you may want to fix m_cargo and then solve for the optimal m_offload of your design. If you are dropping off Kethane to another site and you only want to make one trip, fix m_offload and solve for m_cargo. However, there is one more thing you have to keep in mind...

As I said before, there is a point where you are just asking too much of your spacecraft, and to get someplace you will need to burn more fuel than you carry to get there. I call this a design-based profitability deficit. In order to avoid a deficit, your spacecraft design needs to satisfy what I call a positive performance condition. It is an inequality that takes your delta-v requirements for the mission and tells you whether you're go or no go. I derive what it looks like for both ideal (completely massless parts except for the fuel) and phsycal (non-ideal) fuel tankers, but for this post I'll only post the latter (document and all that):

That diagram there shows the difference between physical and ideal positive performance regimes, given a set of example parameters. There's a couple new symbols but they're not really new. e_struct is the design inefficiency of the spacecraft, or m_struct / m_cargo. f_ft is what I called the general fuel tank factor, or 1 + f_bft + f_cft. For KSP if you're using stock tanks for burnable fuel and Kethane tanks for cargo this is something like 1.33.

Finally, once you know that your spacecraft is operating well within the positive performance regime, you can tell exactly how much profitability your tanker has by using this equation:

There really isn't anything new in this equation. In general, if you follow these equations you will get a solid functioning fuel tanker. Now, my document is very general - it doesn't mention KSP anywhere - but it can be applied to KSP just as much as it could be applied to real life. I tested a simplified set of these equations before and it helped me design and build my very own orbital hopper, to deliver fuel from the surface of the Mun to orbit, where it will rendezvous with another tanker that is more suited to make the return trip to Kerbin.

Isn't she a beaut? To date she's my most strategically built spacecraft in KSP! I designed her with an m_cargo of 32 tonnes (or 16,000 kethane units), and based on delta-v requirements (I estimate that the trip to/from Munar orbit is about 900 m/s one way) it came out to an m_offload of 12 tonnes (6,000 units). That's a profitability of 37.5% but I'll take it! Her structural inefficiency is actually also about 37.5%, which is decent. I am currently applying everything I've learned since then to the construction of a highly fuel efficient nuclear tanker that will move cargo from Munar orbit to Kerbin orbit. After that? Who knows! Maybe I'll start running interplanetary tankers one day!

[John FX]

I just decided to cut out the middle man and have the largest fuel tank with the minimum other mass. I worked out 1kn of thrust could lift 2T from the surface of Minmus so built accordingly. It has some NERVA in the core and some extra radial engines just for liftoff. It could get to minmus orbit using hardly any fuel. Getting the whole thing back to LKO used less fuel than getting to Munar orbit...

IIRC All the orange tanks were full in Minmus orbit but the kethane tanks were empty. I think it was about 32K of kethane.

It was a while ago and I was going through a `whackjob` phase...

I must agree, your miner is a beaut. It has a very functional look. I bet it is hard to tip over.

[tntristan12]

Yes I suppose you could just spam fuel tanks at it until the problem goes away. Even then you're still satisfying the equations, which don't actually prohibit large constructions. I wanted to measure out how much fuel was being delivered versus how much was being used.

[Captain Sierra]

*Grabs calculator* Time to test stuff! I once made a Duna fuel tanker running on LV-909 engines. In a test, it landed and took off under full payload without refueling. It was able to take a whole orange tank of fuel down and back up and it carried about as much fuel for flight as it did payload, but it had enough to orbit on Duna, rendezvous, and dock.

It was later wiped out when a virus killed two of my three KSP installs at the time.

[tntristan12]

Huh, I got moved. Guess I was right the first time!

[Tracer13]

tntristan12, good job on the math! Good luck on the degree.

(Keep an eye on this guy, he's going places!)

[John FX]

Yes I suppose you could just spam fuel tanks at it until the problem goes away. Even then you're still satisfying the equations, which don't actually prohibit large constructions. I wanted to measure out how much fuel was being delivered versus how much was being used.

What I would suggest if that is important then is to not mine from Mun. Mine from Minmus as you will use about 80% less fuel. This means that for the same drills, engines, infrastructure, and fuel you can carry a LOT more payload.

In the image above I get 18 orange tanks of fuel into orbit around Minmus for 32k of kethane fuel costs. That`s 43920 liquidfuel and the corresponding Ox as well as a fair amount of Mono.

Edited January 7, 2014 by John FX

[tntristan12]

I love math. I do it all the time! One time I read about a guy who made it for a living. His name was Heisenberg.

[tntristan12]

What I would suggest is to not mine from Mun. Mine from Minmus as you will use about 80% less fuel. This means that for the same drills, engines, infrastructure, and fuel you can carry a LOT more payload.

Minmus does have that benefit, yes. But it's also not tidally locked so I would need to place a network of commsats there to control my unmanned assets (remote tech).

Edited January 7, 2014 by tntristan12

[John FX]

Minmus does have that benefit, yes. But it's also not tidally locked so I would need to place a network of commsats there to control my unmanned assets (remote tech).

Only a couple. If you don`t want to bother with the upkeep then just launch about 8 on orbits with long resonances. Just put some minisats around minmus and a couple of longer range uplinks in polar orbits to contacting Kerbin.

I used remotetech a fair amount but once I had a systemwide reliable network I decided to not have the lag and as I could get a signal everywhere there was no difference anymore. As I say, that picture was from my `bigger is better` phase but once the system is full of mining operations that can drain a kethan patch on a single sitting and you have a bus shuttle service set up running between the planets and you don`t need to think about fuel because it is everywhere then it was like fuel was removed from the game. The only launches I did were to LKO to bring up crew to the `bus station` and take them down again. My kerbals were doing pleasure cruises of the system on cruise liners.

So now I write programs to launch, rendezvous and land in KOS. I imagine once I have recreated mechjeb I`ll stop that too.

[tntristan12]

Well, this is embarrassing! I caught some blatant algebra errors in my document which gave the wrong equations for (19) and (20). I didn't catch it because by sheer luck they happened to simplify to the ideal case and seemed reasonable enough. However, this time I've tested it and used it to build an orbital tanker in KSP. The numbers really did work out this time, so I uploaded the fixed file here: http://www./view/syr11r983tbb2ry/Fuel%20Tanker%20Problem.pdf!

Edited January 9, 2014 by tntristan12