Jump to content

A reusable transfer stage: a good idea?


Recommended Posts

I use something similar to Kashua's, if anything I use fewer engines. Yup, the burns take a while.

I normally make most of the detachable parts moveable- each has a small probe core and some RCS. I normally take around 50% more fuel than I really need, because I don't always get efficient transfers. That means I have some extra fuel when I reach the intended planet. What to do? I just park the extra fuel in a tank with probe core, RCS, and of course some sort of docking port. If the next ship I send that way ends up a little short on fuel, I've already got a tanker available to top it off. Also, having some maneuverability means I can deorbit tanks when they are no longer useful.

I've become a fan of putting large decouplers on BOTH ends of ships/tanks, makes modular design simple. Mounting LV-Ns radially allows you to put a decoupler on both ends.

After seeing Kashua's design, I'm starting to think I am trying too hard to save weight on engines- I've been putting two or maybe 3 LV-Ns on similar payloads. Works, if you have the patience, the real downside is if you have a short time-frame to complete a burn.

Link to comment
Share on other sites

Be careful with parking lots on larger stations though. I have one on mine, and several modules hanging off it, all heavy and with a fair bit of torque, the SAS can try to destroy the station.

Use a large asteroid as the docking point. It should be large and stable enough to allow even large ships to moor safely without need of torque or RCS to remain stationary.

Link to comment
Share on other sites

There is a bug. It's not the usual "SAS ripping apart my space station!" problem.

Just something to watch out for. I don't the the cause has been narrowed down. There are plenty of people who made asteroid-stations. However, there are also ones that tear themselves apart, and it's something to do with the claw.

On occasion when coming out of warp, ships will buckle in half at the joint behind the claw. The whole ship will bend around sideways till it rips itself off of the asteroid. I think this has happened without timewarp also, but that's when it usually pops up.

Link to comment
Share on other sites

Pecan: That's a nice idea/design.

LethalDose: What I do to make something like Pecan's outrigger design plausibly aerodynamic is simple: each of those four arms would get a large nose cone on top, with a decoupler and pair of Separatrons rigged to pop it/them off at the same time that the last or next-to-last stage of the booster ignites (i.e., before circularization - Only You Can Prevent Kessler Syndrome). I do this for anything blunt-topped but otherwise flight-ready (like the Jumbos in Kashua's pic on the first page) without having to put a fairing around the whole thing. I dunno if it would actually work in FAR, but I bet it would, and since I'm just pretending...

Edited by Commander Zoom
Link to comment
Share on other sites

I use primarily modular construction and usually have about four of these in orbit. http://steamcommunity.com/sharedfiles/filedetails/?id=262281838

After the 'payload' rendezvous with my system bus, I can fling smaller craft out, decouple my 'bus' and send it back for a Kerbin aerobrake. If I need shorter burn times, I'll use two system buses in the stack, one near the front, one near the back.

Link to comment
Share on other sites

Be careful, I have it on fairly good authority that the array in question has a nasty exhaust leak and a tendency to explode. Besides, that someone is totally stealing being inspired by your modular ship core. :wink:

:-) I saw you were active in the thread and might comment. Did you ever get to the bottom of that problem? I didn't see anything in the thread on it.

I wonder if such a design is going to work out economically though. It might be cheaper to launch it in a less modular configuration, to save on probe cores, docking ports and RCS systems. I've been working on a Jool-5 entry that has a single stage, reusable mothership that carries its payload near the center of mass, but I'm not sure whether it will be cheaper to save some fuel by dropping tanks and docking new ones upon return to Kerbin. After all, the new tanks will have to be launched anyway to get the propellant up there in the first place...

To be honest the ship started as an exercise in modularity and flexibility (last part of my l-o-n-g tutorial, which I really must finish this week). In practice every component is reusable except the fuel-module launch-vehicles (because I haven't been able to make a reusable LV for a 40t payload that I'm happy with yet). That means my empty tanks fly home too, or are at least de-orbited by another tractor and then parachute down. The engine modules are not meant to return but, yes, to park in orbit until needed again. I don't use a station for this for clutter/stress reasons such as Claw mentioned; instead I just stick them in their own high-ish parking orbit. They have some fuel - not usually as much as in that second picture - and RCS to rendezvous and dock with the tractor, rather than the other way around, because the tractor is pretty impossible to control when it is part-loaded and therefore unbalanced, as you can imagine. Putting RCS fuel and thrusters on them helps the 'core' tractor and again lets me adjust the amount of RCS according to which group of engines I'm using. The twin-nukes just have those little roundified RCS tanks for instance, while quad-nukes might have cylindrical. Again, in practice, I hardly ever need that much RCS fuel though.

The modules have cores in the first place simply so I can enable SAS on them to hold them steady while docking. Since they have cores they need a solar panel (which also assists the tractor) and since they're going to dock or be docked to they obviously need a docking port. Yes, that could be saved by not using the modular engine design but then I forfeit the ability to adjust the number of engines attached. Whether that ability is worth it is a moot point and I haven't really made up my mind either. A second, lighter and non-modular, tractor can be used to dock fuel/engine modules to the larger one as an alternative but then those modules need two ports or the light tractor has to use a claw.

PS: Your mothership looks like it could be the mother of my tractor :-) Same plan writ large.

@ Commander Zoom - I launch the same way, for the same reason but also haven't tried it with FAR.

@ Aethon - that's a nice smaller version of the same thing too. Good one - that small tank is probably a very good size for local independent operation of the nukes.

Link to comment
Share on other sites

:-) I saw you were active in the thread and might comment. Did you ever get to the bottom of that problem? I didn't see anything in the thread on it.

No, never solved it. I can't be bothered to play process of elimination with my mods until I find the culprit (if it's even a mod and not something in my core game install) for something that doesn't really affect gameplay. I'm sure it will disappear when 0.24 drops and I start a new install. (Thread in question for anyone who has no idea what we're talking about.)

To be honest the ship started as an exercise in modularity and flexibility (last part of my l-o-n-g tutorial, which I really must finish this week). In practice every component is reusable except the fuel-module launch-vehicles (because I haven't been able to make a reusable LV for a 40t payload that I'm happy with yet). That means my empty tanks fly home too, or are at least de-orbited by another tractor and then parachute down. The engine modules are not meant to return but, yes, to park in orbit until needed again. I don't use a station for this for clutter/stress reasons such as Claw mentioned; instead I just stick them in their own high-ish parking orbit. They have some fuel - not usually as much as in that second picture - and RCS to rendezvous and dock with the tractor, rather than the other way around, because the tractor is pretty impossible to control when it is part-loaded and therefore unbalanced, as you can imagine. Putting RCS fuel and thrusters on them helps the 'core' tractor and again lets me adjust the amount of RCS according to which group of engines I'm using. The twin-nukes just have those little roundified RCS tanks for instance, while quad-nukes might have cylindrical. Again, in practice, I hardly ever need that much RCS fuel though.

The modules have cores in the first place simply so I can enable SAS on them to hold them steady while docking. Since they have cores they need a solar panel (which also assists the tractor) and since they're going to dock or be docked to they obviously need a docking port. Yes, that could be saved by not using the modular engine design but then I forfeit the ability to adjust the number of engines attached. Whether that ability is worth it is a moot point and I haven't really made up my mind either. A second, lighter and non-modular, tractor can be used to dock fuel/engine modules to the larger one as an alternative but then those modules need two ports or the light tractor has to use a claw.

I've started messing around with a more modular system inspired by yours, with a minor difference: The engines are permanently attached and only the fuel/payload systems are modular. This simplifies fuel management in that I can have fuel lines feeding all engines from a small central tank. I figure nukes are going to be expensive if the current pricing is any guideline so I'll never dispose of them, and it cuts down on probe cores, docking ports and other support systems like electrical and RCS. It does mean that for some payloads the ship will be over-engined, but since it's reusable that won't be too much of a big deal.

The ship I posted is a bit different in that the tanks are also a permanent part of the mothership; I suspect this won't be the best strategy under economics. I'm paying a penalty in fuel to return those big heavy tanks, and I'm going to have to launch new tanks to refuel it anyway so I'd likely be better served by dropping tanks during the mission and replacing them in LKO with the new ones.

Link to comment
Share on other sites

As I mentioned, I have fuel lines running from the core to the outriggers (under the I-beams). That means central tanks can feed all engines in that way; the 2-in, 2-out arrangement was just an alternative for consideration.

Much of the economics depends on the relative cost of fuel vs tanks themselves. We will find out in due time ...

Link to comment
Share on other sites

Uhm, wow. Seeing all these small ship designs that go so far make me think I'm really over complicating my designs. My current design is 378,000 tons and I'm having a hard time just getting it into geosynchronous orbit to deliver its satellite payloads.

Link to comment
Share on other sites

Uhm, wow. Seeing all these small ship designs that go so far make me think I'm really over complicating my designs. My current design is 378,000 tons and I'm having a hard time just getting it into geosynchronous orbit to deliver its satellite payloads.

Generally speaking, less is more in rocket design. If you wanted to share a picture of one of your designs we could help you with it.

Also, I really hope you mean 378,000kg and not 378,000 tons. If it's really tons, then I really want to see a picture of it.

Link to comment
Share on other sites

378 tonnes is a big ship (378 kilotonnes is reserved for Whackjob ^^) and almost certainly over-large for a satellite - unless the satellite itself is massive, of course. Chapter 4 of the tutorial linked in my signature deals with manned orbital flights (<18t) and lunar and easier interplanetary satellites (~41t).

Apart from the satellite and launch/transfer vehicle designs themselves, have you considered your ascent-path, gravity turn and transfer strategies?

Link to comment
Share on other sites

Yah it's kgs. I was even looking at it thinking "maybe I should convert this to tons first. Naw, kgs will work" and still got the wrong unit in there.

Problem with 'less is more' that I've found is you have to put so much on your ships (science jr, all your science equipment, parachutes, communication devices, life support, etc.) that it gets out of control quickly and then you just have to keep adding more and more boosters to have enough fuel (after getting out of Kerbin and establishing orbit) to get to wherever you wanted to go in the first place (and, ideally, back). Here's two of my ships, a lighter one and a heavier one.

Lander

One of my lighter crafts at 424,000 kg. It has a bit more than needed fuel at the top (the four larger fuel tanks) but it can take a lot of fuel to slow yourself down on approach to the surface (especially on the Mun) and then you have to get back out, establish orbit, and escape, then burn down to re-entry so that's why all that's there. Also provides a wide base for landing purposes. This one should actually weigh more but it's the older model before I installed TAC so it doesn't have any of the food and what not on it.

i3qWk1d.jpg

Satellite Deployer

Forwhen my geosynchronous satellites eventually fall out of orbit due to, from what I understand, a floating point decimal error with the RemoteTech mod. This one is 886,000 kg and is five satellites when all is said and done. Has enough fuel to get it to the Mun, Minmus, or geosynchronous Kerbin orbit.

eb7FTEq.jpg

As you can see they both use the same basic design, just the Satellite Deployer needs more fuel so it has a third stage of boosters so that it'll have enough to get into the higher orbit with (and then make all the changes needed to deploy the satellites). Haven't ventured beyond Kerbin yet except a quick run to the sun's orbit for science points, but I expect those crafts will be absolutely massive once I get around to them to carry all the fuel needed for those distances and back.

Apart from the satellite and launch/transfer vehicle designs themselves, have you considered your ascent-path, gravity turn and transfer strategies?

Not sure what you mean by ascent path. I usually bank east once I've got an apoapsis of 75,000 so that I can get a uniform orbit. I can't do gravity turns any more every since I installed FAR because the crafts don't do well when leaned over, so I just burn straight up now a days. No idea what a transfer strategy is.

Edited by Shiv
Link to comment
Share on other sites

For the lander, that does seem pretty heavy for a 1-Kerbal lander, even with the science gear. If you want to lighten it, I'd start by changing the engines, the Mk 55 is convenient and has a good gimbal range but it's not very fuel efficient, and four of them is probably more thrust than you need for a Mun lander. With lighter and more efficient engines, you'll need less fuel - which in turn means you need less engine thrust and can use still lighter engines, a virtuous circle.

For the satellite launcher, you appear to be using shielded docking ports as nose cones. The actual Aerodynamic Nose Cone (with the blue tip) is a third of the weight, and of course no nose cone at all is lighter still.

Link to comment
Share on other sites

Problem with 'less is more' that I've found is you have to put so much on your ships (science jr, all your science equipment, parachutes, communication devices, life support, etc.)

...

Not sure what you mean by ascent path. I usually bank east once I've got an apoapsis of 75,000 so that I can get a uniform orbit. I can't do gravity turns any more every since I installed FAR because the crafts don't do well when leaned over, so I just burn straight up now a days. No idea what a transfer strategy is.

We're at risk of hijacking the thread - If you'd like to PM me a list of the science/comms equipment you are including on your lander I'll attempt to design a ship for you that is less incredibly massive than those.

Ascent path is about the gravity turn, staying at/near terminal velocity, etc. This should actually be easier with FAR (apparently) because the deltaV requirement is lower. Going straight up will require a huge amount more fuel and, therefore, a heavier launch vehicle. Much better to build small and learn how to fly it properly - not a dig, by the way, because I've never managed to get to orbit with FAR (having only tried twice). Transfer strategy is about how you get from LKO to synchronous or Mun orbit, or wherever; Hohmann or bi-elliptic transfer or direct-burn, for instance. Again, the right manoeuvres are 'right' because they save a lot of deltaV, which means you need much less fuel, which means you need fewer/lighter/more efficient engines to lift it, which makes the whole thing much smaller.

Link to comment
Share on other sites

My current design is 378,000 tons ...

Dear god. I nearly choked on my sandwich.

Yah it's kgs. I was even looking at it thinking "maybe I should convert this to tons first. Naw, kgs will work" and still got the wrong unit in there.

Ahh, okay. Crisis averted...

Those are still some fairly large beasts. I like that last picture. It looks interplanetary, and those covered docking ports give it an interesting look.

Link to comment
Share on other sites

We're at risk of hijacking the thread - If you'd like to PM me a list of the science/comms equipment you are including on your lander I'll attempt to design a ship for you that is less incredibly massive than those.

May I point out that you might also do this in public? Opening topics is easy, and I for one would like to eavesdrop.

As to my OP, I'm glad I asked. When I patched together my transfer stage, it didn't occur to me that radial ports might cause a major headache further down the line. Oops.

Link to comment
Share on other sites

For the satellite launcher, you appear to be using shielded docking ports as nose cones. The actual Aerodynamic Nose Cone (with the blue tip) is a third of the weight, and of course no nose cone at all is lighter still.

Yah I think with the stock KSP aerodynamics it doesn't matter, but with FAR installed it makes a difference. There was a thread on the reddit KSP forum where a guy did a test with a single booster and the various types of nose cones, and shielded docking port went the second furthest (sputnik core being the 'best' but that doesn't look very good/logical [not that the shielded port is logical for a nose cone]).

Link to comment
Share on other sites

  • 6 months later...

Sorry to resurrect this thread but it was linked from another thread. I think tractors and tugs are useful for missions within the Kerbin system, but anything interplanetary starts to get real annoying. Even with Kerbal Alarm Clock, you're looking at a long exit burn, up to a two year journey (to Jool or Eeloo), establishment around the target body, another exit burn, another two year transit, then a tricky aerobrake, then rendezvous and docking. Without MJ to automate, aligning close-approach markers, waiting for phasing orbits and doing docking takes tons of time.

It's not worth it for me. RV and docking takes so much time if you want to be efficient. I'd rather use a pre-made transfer section that I've saved as a subassembly.

Link to comment
Share on other sites

Sorry to resurrect this thread but it was linked from another thread. I think tractors and tugs are useful for missions within the Kerbin system, but anything interplanetary starts to get real annoying. Even with Kerbal Alarm Clock, you're looking at a long exit burn, up to a two year journey (to Jool or Eeloo), establishment around the target body, another exit burn, another two year transit, then a tricky aerobrake, then rendezvous and docking. Without MJ to automate, aligning close-approach markers, waiting for phasing orbits and doing docking takes tons of time.

It's not worth it for me. RV and docking takes so much time if you want to be efficient. I'd rather use a pre-made transfer section that I've saved as a subassembly.

How does your pre-made transfer section reduce any of the interplanetary problems you mentioned: exit burn time, transfer time, injection burn time ... and back?

The point is you have more than one tractor vehicle, shuttling backwards and forwards so you resuse them and don't need one for every single mission.

You complain about burn and transfer time then say "RV and docking takes so much time..." !? Five minutes at the beginning and end of a two-year mission so you don't have to pay for, and launch, a whole new transfer section?

Really?

I think you might want to

.
Link to comment
Share on other sites

You complain about burn and transfer time then say "RV and docking takes so much time..." !? Five minutes at the beginning and end of a two-year mission so you don't have to pay for, and launch, a whole new transfer section?

Really?

Not everyone can rendezvous and dock in 5 minutes.

Really.

Link to comment
Share on other sites

Not everyone can rendezvous and dock in 5 minutes.

Really.

True, and in sandbox/science mode there's nothing to stop anyone being as wasteful as they like.

Anyone even slightly caring about cost-efficiency should worry about throwing-away an interplanetary transfer vehicle though, since all any of them need to keep operating is more fuel.

That, of course, introduces the second difficulty - which is making something that can transfer to another planet and come back (or sending a tanker trailing after it ... which is then thrown away ... which defeats the point).

That something is difficult does not affect it's efficiency ("RV and docking takes so much time if you want to be efficient") but absolutely does affect whether anyone can be bothered. Quite rightly, we're only here because it's fun; no point in doing tedious stuff.

And that's my point, which is irrelevant if someone doesn't care about the cost; if you throw-away transfer vehicles, which are the most reusable of ships, you'll end-up having to do an awful lot of tedious contracts just to pay for them. It's the same argument as for re-using (presumably SSTO) launch-vehicles and landers at each end of the journey.

Link to comment
Share on other sites

Sorry to resurrect this thread but it was linked from another thread. I think tractors and tugs are useful for missions within the Kerbin system, but anything interplanetary starts to get real annoying. Even with Kerbal Alarm Clock, you're looking at a long exit burn, up to a two year journey (to Jool or Eeloo), establishment around the target body, another exit burn, another two year transit, then a tricky aerobrake, then rendezvous and docking. Without MJ to automate, aligning close-approach markers, waiting for phasing orbits and doing docking takes tons of time.

It's not worth it for me. RV and docking takes so much time if you want to be efficient. I'd rather use a pre-made transfer section that I've saved as a subassembly.

One way I use them is as q reuseable first stage for the first 1000 m/s

This reduce burn time a lot as the tug has a decent twr. Tug never leaves Kerbin soi

An bonus is that sending stuff like fuel or bases too duna or eve you only need a few hundred m/s to get to target

Link to comment
Share on other sites

This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...