Jump to content

1.04 Interplanetary AAR (Updated 11 Nov 15)


Capt-Coulson

Recommended Posts

A 1.04 Interplanetary After-Action Report

********************

Reports

- Chapter 0, Pt 1 - Origins (30 OCT 15)

- Chapter 0, Pt 2 – In the Beginning (05 NOV 15)

Interludes

- Interlude - Kessler Syndrome (03 NOV 15)

- Interlude - From Work-shop to Work-horse (11 NOV 15)

Crew Status

Coming Soon!

********************

Chapter 0, Pt 1 - Origins

First thing’s first; a little bit of context. I’m terrible at KSP careers. I’m not bad at designing things, and I can push past the ‘MOAR BOOSTERS’ phase far enough to ‘not explode’ and make it to the Mun and Minmus…. and then I add more mods, or go back to stock, or dabble in RSS, or an update comes out, or I get tied up building a frame-shattering behemoth in low Kerbin orbit, or…. You get the picture. I restart and I’m back to trying to make orbit.

NOT this time. I’ve managed to push past that initial phase, and onwards to greater things. I got so excited that I decided to write about it. Which is great, except that for the first few years of my program, I haven’t taken any screenshots. Boo. Ah well. I’m not about to bloody restart again; that would defeat the whole point, and you wouldn’t be reading this! Instead, I have decided over two posts to catch up on the last few years of my game as best I can, and this week has been perfect for it – no time to play KSP, but lots of small bites of time with which to write.

In this iteration of the universe, a world not unlike our own is playing out a history not unlike ours, except that the Kuban missile crisis never quite resolved itself, and the Kerlin wall remained standing. The tension that divided our world in two for half a century persisted through the new millennium, and still exists now. Spurred on by the fear of total annihilation and the eradication of all Kerbalkind, various smaller space agencies banded together in 2015 to form a global initiative. With funding from all participating nations, the agency was designed from the ground-up to focus on the colonisation of other worlds and the preservation of Kerbalkind.

So I am currently in Year 5 of the game, and have a number of different projects underway, and assets floating about being useful in some shape or form. The first three years don’t really need much catching up on; I flew into space, I did science, I came back from space. I went to the Mun. I went to Minmus. Only at the end of year three did it get interesting, with my first interplanetary mission to Duna; VOYAGER I. Unfortunately, I don’t have any images of the mission itself, but it was simple enough: a crew of Jeb, Bill and Bob, with a lander, sent out to land on Duna and Ike, and return. They returned pretty much on day one of Year 5, having successfully completed their mission. What I do have is a picture of the Multi-Purpose Exploration Vehicle (MPEV) lander they used being assembled in the VAB:

aJJk0zB.png

This was sandwiched in between a heatshield that could detach and reattach, and the transfer ship, which was basically a Mk1-2 capsule and two hitchhikers bolted onto a tonne of liquid fuel and a single Nerva. It was my first interplanetary mission, and while simple, it taught me a lot, particularly about using more than one Nerva. 25-30 minute burn times are just not fun. The mission left my bank account with some √3,500,000 through contract completions, so I could begin to really kick-start some big ideas I had.

So that’s where we are in terms of overall context. Whilst the orangesuits were away though, Year 4 saw a lot of action that can’t really be glossed over so easily. The following ramblings are mostly for context for future posts, and don’t really reflect chronological activities within the game during that time, but I thought I’d share my main objectives for that year, and then provide a little context on them, as well as summing up all of my existing assets. This post will look at those, and provide a short summary of the different ships I use in my game to date. The next post will look at those ships, provide a list of mods currently being used, and lay out the current objectives for that game year. Hopefully by this point, work will have calmed down enough that I can get back to playing AND reporting as I go! With, of course, less babble and more photos!

gf3reCf.png

Establishing the Core Teams

What is a core team? To me, a core team is a pilot, an engineer, and a scientist. It probably is to most people; one of each skill to cover all your bases. One of my objectives whilst the orangesuits were off at Duna breaking records, was to make sure that by the end of Year 4 (2019 in my game) I would have two ‘core teams’, with every member at least at two stars. This means they would be able to perform basic repair, piloting and scientific tasks, and in my game, is the qualifier for teams to deploy on ‘Other-world’ missions out into the wider Kerbol system. I knew that the orangesuits would hit this target as a team by visiting Duna; in fact, they were all already at level two when they left! So, a number of training flights to the Mun and Minmus were conducted, using established hardware (talked more about in the next post), to bring a second core team up to scratch. This went on throughout the year, and was pretty ad-hoc. In future, the plan is for a more regimented training program to be conducted with new members, and using permanent infrastructure.

Orbital Research and Refuelling Station (ORRS) Demonstration

In order to maintain a permanent other-world presence, it was decided that the first important step would be developing an orbital station capable of providing the necessary support and administration to our explorers. It was envisioned that these stations will become the first foothold in a network of assets that link the worlds of the Kerbol system. With that guiding principal established, the following requirements were put in place:

  1. The station must be modular. This will allow for the future redesign of existing stations.
  2. Each station must be able to support an enhanced crew of 4, for as long as is necessary between transfer windows.
  3. Each station must be capable of processing resources, and hold a store of those resources appropriate to each system.
  4. Each station must possess a laboratory, to enable it to act as the orbital research centre for a given system.

After much fettling and tweaking, a series of 5 modules was designed that could be assembled to create a simple but expandable orbital ‘hub’. The first module forms the core of the station, and is always launched first (subsequent modules can be launched in pretty much any order I choose, though it is generally a good idea to launch the solar armatures shortly after, so that control isn’t lost over the core).

LQaNW26.png

The core consists of a laboratory, and a monopropellant store, with two structural hubs. It holds a large amount of electric charge, and also provides the reaction wheels. The idea is that the structural hub sandwiched between the lab and mono-store will be expanded upon with habitable modules and visiting crewed ships, whilst the hub attached to the mono-store will hold fuel tanks, an ISRU unit, and provide docking space for mining vessels.

The second module is a series of solar armatures:

OaXDkoN.png

Not massively exciting, but these hard-dock to the mono-store ports and provide a basic power supply to the station, enough to run the laboratory and sub-systems. They don’t need to be able to power the ISRU, as any mining vessel will require power for the drills, and when docked to the station this power can be applied to the ISRU. Simple.

Module three is a pair of habitable areas, designed to give some much needed breathing space (literally) to those staying on board:

CDWF5rI.png

The only thing worth noting about their design is that once installed, they’re a tad difficult to get rid of. They only have one docking port, and stack-separated once in place. This is to save on part count, as it means two less docking adaptors on the station. Besides, if a particular station ever needs upgrading, it will provide more of a challenge to replace them!

Module four is a single fuel tank. That’s it. Nothing more to see here.

kCIISL1.png

It’s launched fully loaded, and provides on-orbit storage of LOX products. A pair of these will typically be installed, providing enough storage for most vehicles. Not very exciting, but it does the job.

The fifth and final module is the ISRU unit. It is separate to the core for reasons of modularity – There may be cases in future where I don’t want ISRU capability, but do want a permanent orbital station. It’s pretty much just an ISRU part, docked and strutted on-orbit using KAS. You'll note with all of the additional modules, A 'Service Tug' is attached to move them and dock them once they achieve orbit. It's a pretty simple device, that is disposed of once its job is done. It could stay on orbit if needed, but at the moment there's no need, so they're de-orbited.

QgWqBX2.png

I don’t have any pictures at present of the orbital launches or assembly process, as I did this several weeks ago when I wasn’t recording my games here, and to be honest; it’s just docking and strutting. Instead, here’s an example of a fully assembled ORRS in orbit:

XA9Yqr4.png

This is the second ORRS I've built. The fuel tank with the engine attached is actually the upper stage from the core module launch - i realised during the demo construction that I can just leave it attached, top up the fuel as I add the other modules, and use it to move the station to where it's needed before dumping it. This second ORRS is destined for Duna, but more on that later!

The SPIRITUS Program

SPIRITUS is my third-generation launch family, which was designed around a relatively simple set of tenants:

1. All stages must be recoverable.

2. Each size (2.5m, 3.75m etc.) must have a common core, and can be expanded upon with a variety of boosters.

3. The first stage must have 2100dV, and the second stage must have 1400dV. This is enough to get into an 85x85kmx0° parking orbit with a margin for error.

Rather than developing the rockets all at once, I decided they would evolve in size and variety as the requirements changed. They’re also coded in the following manner: Core size, Number of first-stage cores, Payload in metric tonnes to orbit. So a 23-36 would be a 2.5m, 3-core lifter capable of putting 36 tonnes into and 85x85kmx0° parking orbit.

CfwhD4w.png

The net cost is the actual cost of using the launcher, while the discount is what I use to work out the cost of projects to see if they’re going to be profitable or not. HVN is high-voltage nuclear; the kind of payloads that feature large amount of nuclear material (a few Nerva engines is fine; a ‘Near-future’ nuclear generator and accompanying fuel is not so good when it falls out of the sky).

Below are a few pictures of the launchers. Note the similarity between the 3.75m and 2.5m variants. The 2110 is mostly used for OSS and ORRS assembly:

brcVjw3.png

The 2336 is the workhorse of the group so far, and the only man-rated launcher in the fleet (my threshold for man-rating is 10 successful launches and a 90% launch success rate):

fe1RnzY.png

The 3375 is basically a 3.75m 2336. Currently the biggest launcher in the fleet:

EOYaQ8O.png

Summary of Existing Assets

dVJyvO5.png

So there we are. All set, and on day one of Year 5. Except; not quite. What the hell are all those acronyms and what do they mean? You haven’t explained any of them! Well, I achieved a lot more in Year 4 than I initially planned, and I’ve done a fair bit of setting-up for Year 5 objectives, so in my next post we’ll go through the Kerbol system as it is today, set out my Year 5 goals, and explain what mods I’m using. And, of course, provide a lot more pictures! Then maybe I’ll be ready to move forward. Of course and as always, feedback, criticism and general commentary welcomed and encouraged. Until next time, good day!

Edited by Capt-Coulson
Added links to new posts. Updated title.
Link to comment
Share on other sites

This was made by an accountant.

Hah, this is so true. I mean, apart from the accountant bit. But other than that - nailed it :wink: I've tried to do AARs that follow a story before, but it's just not me. THIS is actually how I play, with spreadsheets and number crunching, and I love it. I guess it's a hang-up from the days where we had to do that in sandbox mode, before career, to make our own careers :P

This is a nice start! Following....
Subbed!
Same!

Thanks!

Link to comment
Share on other sites

Interlude – Kessler Syndrome

It’s been a hectic week – I’m going travelling with work, and the medical staff here don’t have my vaccination record. So guess what? I’m getting them all again. Boo.

In more relevant news, I’m well on track to finishing the second half of Chapter Zero. I’m looking to maintain a cadence of about one post a week (but commit to nothing!), with a midweek interlude on stuff that just doesn’t seem to fit in anywhere else.

So it is that I’m talking about Kessler Syndrome. For those of you that are unfamiliar, this is the baying face of Kessler Syndrome in the world of KSP:

4IR2TkA.png

There’s a good, if quite old, thread on the subject here. That picture is from my current save, and the one that this mission report is following. Up until this point, it hadn’t caused any problems, and my latest rocket family (the SPIRITUS that we talked about in the first post) is about 95% debris free (the occasional fairing finds its way into orbit, but this tends to be on manned launches where health and safety insist they remain attached for the protection of ‘vital crew systems’. Boring.) However, I was playing tonight, and when launching a payload element for interplanetary flight, a number of pieces of debris came to within 250m of my rocket. Had they impacted, I would have been toast.

This has happened to me before, in fact. A space station, many saves ago, was functioned just fine until the part where it spontaneously exploded. Back then, I’d never even heard of Kessler Syndrome, let alone considered it to be the root cause (this was back when the kraken was pretty much the default choice for all your woes). However, a number of astonishing reverts made it quite clear: a booster segment had collided with the station and eviscerated it.

As I mentioned, my current launches are not adding to this problem in any great volume, but I have over 200 tracked pieces of debris (not all pictured), and it’s only a matter of time before the inevitable. I have, using a crude form of what some call maths, estimated the following ‘fun’ facts:

- There are roughly 200 piece of debris in this save game so far;

- Based on a small random sample, the average mass is approximately 2.1 tonnes;

- Therefore the approximated mass of all debris is over 420 tonnes!

- There are 55 pieces in the construction orbit of 85x85kmx0°;

- The circumference of Kerbin at this height is roughly 4300km;

- Therefore, there is a piece every 78km all the way around Kerbin (which means that each piece of debris is, just, closer to another piece of debris than it is the surface).

How I go about tackling this problem in career mode cost-effectively is beyond me, and so far into the future I needn't worry about it. When something does inevitably go ‘kaboom’, it will almost certainly be cheaper to build another, than the cost of removing all the debris. What WILL hurt is that I play with no reverts, and if it’s a manned vessel….

…until next time, good day!

Edited by Capt-Coulson
Clarity/ Wording.
Link to comment
Share on other sites

Get a claw and an ion tug?

So you can play catch the debris between events.

Definitely an idea. It's such a time-consuming process though! And I imagine it eats funds quite readily. Something to look into, definitely. Maybe I'll cost it; fly it once to validate the concept; and then 'sim' the removal of debris over time by just terminating a piece and deducting funds from the save. Food for thought :P

Link to comment
Share on other sites

Chapter 0, Pt 2 – In the Beginning

In the last chapter I set out the objectives for that year, and provided a little context on them, as well as summing up all of my existing assets. This post will look at those ships, provide a list of mods currently being used, and lay out the current objectives for that game year. Work is still as manic as ever, which is good; writing is easier to find time for than sitting down and progressing!

MOD List

This is one of my more modded games, and whilst I am still in the process of adding and tweaking my mod-set, I have pretty much established what I’m using. The only big additions I can see coming in the future would be a ‘rover’ pack of some sorts (as I have never really dabbled with rovers but can see them being essential in moving between colonies) and a ‘TAC-LS’ compatible greenhouse to produce food/water/oxygen for breaking the reliance on Kerbin.

Mpf4PxM.png

I use Ckan to maintain this game, which is a first for me as I tend to go for the manual approach. It’s been a godsend, and I can’t see me going back to managing it all by hand. There are a number of ‘parts’ mods, several tools for keeping track of where things are and when they need attending to, Mechjeb for data feedback, and Kerbal Construction Time for adding a fourth dimension to the gameplay. It really changes how you plan your projects to fit around launch windows and hold vehicles in reserve for emergencies! I also use (and really, have always used) TAC Life Support. This really comes into its own on interplanetary journeys, as I found out during my first Duna trip, and will add even more value when I start establishing my first off-world colonies. I could harp on about any of these mods, but they’re all great, and you should check them out if you haven’t already!

Agency Assets

In the first half of the chapter, I featured a table of different acronyms and what they mean. The bulk of this second half is explaining those a little, as they are the core vehicles my current agency is using to build the space program. I’m going to work outwards from Kerbin, and talk a little about each asset currently deployed.

O7SBVaR.png

There are currently two things in orbit around Kerbin (not counting debris – then it’s more like 200). The first is my second Orbital Research and Refuelling Station (ORRS), ‘Lazarus’. I featured a screen of this in the first chapter half, and nothing has changed, but here is a different angle on things:

Kre5u6q.png

The plan here is to send this out to Duna towards the end of the year, as part of the VOYAGER III mission (more on that later). It will hopefully insert into Ike orbit, and act as a hub for operations there.

The second vehicle is my first Interplanetary Transport Propulsion System (ITPS), ‘Nicodamus’. Both it and the ‘Lazarus’ are orbiting at 85x85kmx0°, which is my designated construction orbit:

ihs98I3.png

A senior docking port provides the connection to the payload, and 6 Nerva engines provide a healthy TWR for up to 28 tonnes of cargo (4500dV rated), or a lighter 11 tonnes (6000dV rated). The ‘Nicodamus’ is earmarked for the VOYAGER II mission (again, more on that later), and I plan to haul a Multi-Purpose Exploration Vehicle (MPEV) and Orbital Survey System (OSS) along for the ride.

That’s everything in Kerbin orbit. Next, we come to the Mun. I don’t like the Mun. It’s thirsty on dV, which is a problem that limits mining and surface operations. Couple that with having Minmus so close by, and (beyond initial scientific yield) it’s difficult to justify trips there. Still, I have to train astronauts somehow, and the occasional contract means I visit every so often:

aEWjTQ9.png

There are three things in orbit around the Mun. The first is a Multi-Purpose Exploration Vehicle (MPEV) lander from a recent training mission. This was left fully fuelled, ready for the next visitor:

cQF99lP.png

There is actually a second MPEV orbiting at an inclination (you can see it in the picture of Munar orbits). I haven’t bothered to photograph this because it’s practically the same, and I’m disposing of it shortly. The third object is worth mentioning, and is an Orbital Survey System (OSS) that is used to identify surface deposits of valuable resource from orbit, working in conjunction with the Surface Mining Vessels (SMVs) to access this ore:

3sOXb6k.png

The picture quality isn’t great, but you’re not missing out on huge amounts. It’s essentially two monopropellant tanks with a service engine at one end, and a dish at the other. Thrilling, but practical and cheap. There is another of there in orbit around Minmus, which you’ll get to see later; I promise. Try not to be too excited.

In fact, we’re moving on to Minmus. This is by far the busiest place, and that makes sense, as it’s my departure point for large missions, a refuelling hub, AND a crew training centre.

1SnVMAb.png

The main asset in orbit is my other ORRS, the ‘Lucina’. This model has deployed, so does not have the core launch stage still attached. It also has an MPEV, which you can JUST about see hiding at one of the central docking ports (read: more screenshots is good, but quality needs working on).

ahYq9QI.png

At the bottom, you can see my Interim Crew Transfer Vehicle (I-CTV) which delivered the first working crew of one pilot and two scientists. It’s called the ‘Interim’ CTV as it took over from my first iteration, which used my old J-30 rocket and had shorter fuel tanks, but it will be replaced (when the program can afford it) with a shorter-range, higher-capacity vessel. This new version will launch up to 7 people into LKO, where a ‘shuttle’ will move them out to Minmus prior to further departure. Consider that a ‘stretch-goal’ for Year 5.

In slightly higher orbits, the two ship icons are the Voyager Class Vessels (VCV) ‘Melampus’ and ‘Magdala’. These are second-generation long-range crew transporters, which are fully reusable and capable of taking a four-man team pretty much anywhere they need to go.

yVh0vcF.png

Their construction is two-part, with the cabin made up of a cupola (the cockpit), airlock and docking node, and sleeping quarters. The engine is essentially an IPTS unit, with added life support. They are the pride of the fleet, and pending their trials on the VOYAGER missions, it is anticipated that more will be produced.

On the surface, we have the appropriately named Surface Mining Vessel (SMV) which collects and delivers the ore for the ISRU on board the ORRS. It has an ore capacity of 4800, and at the time of writing has been tested and approved for use on Minmus and Ike. It takes about 14 days to fill up, and a day to convert all the ore into product. It’s heavy and slow, but works.

mQdcyHe.png

Also on the surface is the second Minmus MPEV. Nothing different to add here, except why it’s on the surface; to reduce part count. I have a pretty beefy computer, but when you have the SMV, ORRS, a VCV, I-CTV and two MPEVs occupying the same space, frames do tend to start dropping. So it’s chilling out, waiting for a future mission.

aE3ZGY2.png

Finally, as promised, the second OSS! So exciting. So very exciting.

giXCwvA.png

Well, that was a disappointment. Stop disappointing me! I blame bad lighting for the poor photo, but we all know it’s a lack of skill. At any rate, the poor, lonely OSS holds this entire operation together, providing data on the best spots for that juicy, juicy ore.

Onwards and outwards, then. My first (poorly documented) (actually, undocumented) visit to Duna left in place some goodies for the VOYAGER III mission to discover.

tINXpmF.png

Actually, just one goody then. Still, it’s a useful one. An MPEV lander, and the deep-space version at that! So what is different about the deep-space version? Well, the main two changes are a larger battery capacity (for overnight stays on the surface), and parachute modules to make the most of atmospheric decent. The dV budget is largely unchanged, but it’s about 20% more expensive, so the accountancy department insisted it only be employed beyond the Kerbin SOI. Fair enough; they control the budget.

vOOdgJ5.png

That tank attached to it is an old Fuel Transfer Vehicle (FTV) that supported the VOYAGER I mission. The FTV was replaced at the beginning of Year 5, with the advent of more powerful lanuchers, by the ERV (below).

Sharp eyed readers will notice that the Emergency Resupply Vehicle (ERV) was not mentioned anywhere here, but was on the list. That’s because it’s only just come into service:

MAZsidF.png

The fuel capacity is much, much larger than the original FTV, and it has multiple nodes for docking. The idea is that this can be used in a dual-role, acting as a hub in Munar orbit for crew training. I don’t want to invest half a million roots in setting up a Munar ORRS, when I can use a disposable ERV to do the same job, and much quicker. Other than that, it will be used pretty infrequently; it is for emergencies, after all.

Year 5 Objectives

Phew. So that’s where we are. As I mentioned in the previous post, we’re currently (pretty much) at the beginning of Year 5, which is the year 2020 in my fictional universe. For this year, I have set the following objectives:

CrDcUiU.png

The costs are rewards are quite fluid, and based on contract returns. The only finance I don’t currently have in place is for the Munar Training Facility, which I’m hoping to get in the form of flag-planting and science returns.

Over the course of the year, I plan to expand the two core teams into two ‘enhanced’ teams. This means adding a scientist to each team, bringing the total number of members in each team to 4. This means that an enhanced team can operate a laboratory on missions, which itself means not only a greater science yield for the expense, but the periods where they are travelling between planets can be filled with useful work.

The second objective has in fact already been achieved. Basically, I wanted to ‘prove’ the technology I was going to send on the second and third interplanetary missions, and Minmus was to be my playground for this. The demonstration ORRS was put into orbit there, as well as an SMV. These have worked well, have required very little in the way of modification – my SMV has had an engine upgrade, but that’ll be discussed later.

Objectives three and four are the big ones for this year. The VOYAGER missions are the flagship project for the space agency, and it is this banner under which all exploratory missions come. VOYAGER II will be my first foray to Eve, and will be an expanded, modernised version of the VOYAGER I mission to Duna. An enhanced crew will travel in a VCV, and an ITPS will carry an OSS to scan Gilly for fuel, and an MPEV to land on Gilly.

The VOYAGER III mission will revisit Duna, carrying more equipment and aiming to establish a basic foothold in the system. Again, an enhanced crew will use a VCV to make their way to Duna, followed closely by an ITPS with an identical payload to that on the VOYAGER II mission. My second ORRS will be built and deployed into low Ike orbit, and an SMV will be placed on Ike’s surface. This will mean refuelling can take place in the Duna system, and the presence of two MPEVs (the new one, plus one from the original VOYAGER mission) will allow for a wider exploration to take place.

Finally, I plan to establish a Munar Training Centre. This objective fell out of the need to train enhanced crews cost effectively, and in time for the VOYAGER missions. In order to satisfy the short time frame between now and the launch window, and at an effective price-tag, I will not be building a third ORRS this year for the Mun. Instead, I will use an ERV in low orbit to provide a source of fuel for the local MPEV, thus reducing cost significantly. When this ERV is drained, another will be launched as and when required.

And just like that, we’re ready to rock and roll. I said in the last post that we are on day one of Year 5; that’s not quite accurate, as my TAC alarm clock screenshot shows below:

mHFED99.png

We’re on day 20, but in those 20 days I pretty much refuelled the two VCVs you saw in orbit around Minmus, in preparation for their missions. So unless you want me to talk about how much fun it is piloting 80 tonnes of ore up, and down, and up, and down, we’ll gloss over that. Hopefully, I will find a couple of nights this week to start making progress. There’ll probably be another interlude between now and then, as I have a few ideas bumbling around that I think I’d enjoy talking about. Until next time, good day!

Link to comment
Share on other sites

Interlude – ‘From Work-shop to Work-horse’

One of the coolest aspects of KSP in my opinion is that we get to design not only the payloads we send into space, but the delivery method as well. There are so many options available, and the most common is undoubtedly the chemical rocket. In one of my previous posts, I talked a little about my current family of launchers, known as the SPIRITUS family. But how exactly do I go about developing these?

UcW3wwh.png

I imagine my process is not dissimilar to most, but I am quite rigid in the steps taken, simply for the sake of uniformity. My launchers are practically identical to look at, and it is the way I designed them that causes such likeness. I started with a set of three core tenants, which I have already discussed. From this, I set out a specification to follow when designing, which also acted as a checklist for the finished product.

[TABLE=class: grid, width: 500, align: center]

[TR]

[TD]Design Aspect[/TD]

[TD]Considerations During Design[/TD]

[/TR]

[TR]

[TD]dV Requirement[/TD]

[TD]2100dV (Atmospheric) 1st Stage; 1400dV (Vacuum) 2nd Stage.[/TD]

[/TR]

[TR]

[TD]TWR Ratio[/TD]

[TD]1.2 on the 1st Stage; 0.9 on the 2nd Stage.[/TD]

[/TR]

[TR]

[TD]Parachutes[/TD]

[TD]Both stages; enough to lower return velocity to 3m/s.[/TD]

[/TR]

[TR]

[TD]Struts[/TD]

[TD]Cross-braced across opposite cores.[/TD]

[/TR]

[TR]

[TD]Fuel Lines[/TD]

[TD]Running in all directions within the stage.[/TD]

[/TR]

[TR]

[TD]Retro-Motors[/TD]

[TD]Applied (in correct direction!) to the upper stage.[/TD]

[/TR]

[/TABLE]

The dV requirements are split over the two-stage design. The first, atmospheric stage should have roughly 2100dV (atmospheric). The second stage needs roughly 1400dv (vacuum). This is enough to make orbit at 85x85kmx0°, with a little margin for error. Fuel Lines are added from the external boosters to the core, and from the core to the externals, allowing fuel to flow in all directions. This means that the boosters do not ‘shed’ through flight, but rather detach with the core as a whole. This is less efficient, but requires less parachutes and therefore less moving parts.

Thrust-to-weight ratio (TWR) is finely tuned to provide a large enough ‘bang’, without damaging the payload. I normally aim for about 1.2 on the first stage and 0.9 on the second, though this is subject to a variance of ±0.1. I know it would be more efficient to aim higher on the first stage, but I like how a lower TWR helps me suppress the trajectory early, and achieve a lower orbit – something useful when playing RSS, for example, where the engines can only be started once, and with limited/ no throttling.

Each stage has to have parachutes, provided by the Realchute mod, that are tuned to carry the dry stage back to Kerbin for a soft landing. This sometimes means draining the upper stage before deorbiting. The upper-stage deorbiting is provided by a number of solid retro motors, which are tested to ensure they can lower the periapsis of the upper stage sufficiently.

Lower-stage cores are then strutted in a linear fashion, at the top and bottom, to ensure they act as a single unit. I’m not so sure how necessary this is, as I use Kerbal Joint Reinforcement, but old habits die hard, and for the cost of two struts, it’s worth it just for effect.

I always start by designing the largest launcher I will use for a given diameter. This will inevitably be a three-core, all-liquid rocket. It is shaped to meet both the specifications in the table, and to match up visually with its sister designs, all the while being monitored for its maximum payload. Single-core variants are literally that – the booster are deleted, TWR and payload is tweaked, and the rocket is tested.

The ‘simulation’ feature in Kerbal Construction time is then used to validate the basic design. I will fly two or three flights, with a mixture of payload sizes and masses, to check how controllable the launcher is in different scenarios. When I am happy, it will join the flight line, and start operations.

I have already discussed that I have certain qualifiers for manned flight and nuclear payloads. These are completely self-imposed, and are there just to add an element of purpose to tracking and recording flight stats.

st42X9u.png

So where will the family go in the future? Well, the table in Chapter Zero shows where we are right now, with two 2.5m and one 3.75m launcher(s). Future development will head down two distinct paths:

- Variations on the external cores within each diameter class, which allows for greater variation in the payload limits. For example, a 2236 might have its two liquid boosters replaced with solids, which reduces the maximum payload but reduces initial cost as well, and is specifically designed for smaller payloads rather than simply being able to accommodate them.

- Increasing the diameter further, through the SpaceY mod (amongst others). 5m, and even 7.5m launchers are being considered, although there is no immediate requirement. This launcher size would be able to loft some of the designs that currently require five, six or more launches (plus assembly and docking). There may be a small cost saving, but the biggest saving will be time, in not having to assemble my missions as much.

But that’s a while off. For now, the focus is on slowly verifying the existing designs for higher-level tasks, and on achieving tasks at all! Until next time then, good day!

RrYdh4e.png

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...