Jump to content

[1.2] Real Solar System v12.0 Dec 8


NathanKell

Recommended Posts

Yeah, that is true. Do you need MF? I don't really understand how it works...

Presuming you're using real fuels, it basically modifies the stock fuel and oxidizer, adds new fuels and oxidizers, along with making it so certain kind of engines can only use certain kinds of fuel. The latest version also changes ISP scaling so thrust is affected depending on altitude, not fuel flow.

As an example of how you should use these fuels, I'll show you using a rocket I made.

80E2E33E0DFD571D0298D88A05CF7D4A44DB8408

This Saturn V-esque rocket is carrying a Mun Lander + a Command/Service Module.

The first stage is using Liquid Fuel (which I believe has been modified so it's basically RP-1) and Liquid Oxygen (which I shall refer to as LOX). While this makes it really heavy (the first stage makes up a great deal of the rocket's weight), this also gives the first stage a lot of thrust, and decent ISP at sea level. (Had I used hypergolic fuels, while it would still have lots of thrust if used in a vacuum, in a sea level launch like this it would be so underpowered it wouldn't be able to take off thanks to their abysmal ISP in atmo)

The second stage uses Liquid Hydrogen (which I shall refer to as LH2) and LOX. Since LH2 is far less denser than Liquid Fuel, this means that it's much lighter than what the size would indicate, along with having a great ISP. Thrust is not as powerful as it could be compared to the Liquid Fuel/LOX option for that engine however.

The third stage that does orbital insertion and trans munar injection is, again, LH2 and LOX. Same deal as the second stage.

After that, the C/SM takes over for Munar Orbit with its hypergolic fuels of UDMH and...N2O4, I believe? As I noted before, hypergolic fueled engines don't really fare that well in atmospheres due to their abysmal ISPs at sea level. In a vacuum environment however, they are much better due to their much higher ISP there.

There is something else I nearly forgot to mention. Due to how LOX and LH2 can only be liquids at very cold temperatures, they are considered cryogenic fuels. This has the side problem that since they require very low temperatures to stay liquid, once you move them out of the VAB the cryogenic fuels will start to slowly boil off. For lliftoff and insertion stages that are merely going to the Mun, the boiloff isn't too much of a problem to hinder you. If I had been using cryogenic fuels for my C/SM or lander however, I could have ran into the problem that the travel time required to reach the Mun might have made my landers too underfueled to actually make a landing thanks to boil off.

By comparison, hypergolic fuels can remain liquid at much higher temperatures, so boil off isn't a problem. Hence why I'm using them for both the C/SM and the Munar lander.

And if you don't understand this explanation, don't feel bad, I kinda suck at explaining things. :P

Link to comment
Share on other sites

Success! After 5 hours of testing and modifying my vessel and its launch profile I have been able to place my first small satellite in a stable orbit around real sized Kerbin!

Separation from the 4th stage:

fz526v.jpg

Unfolding of solar panels:

16jggtd.jpg

View of the satellite after the 4th stage of my SSLV burnt retrograde to reenter Kerbins atmosphere:

zns9yw.jpg

Thanks to everyone who is working on Real Solar System and other realism mods. This game is soo much more fun this way!

Link to comment
Share on other sites

Actually that's the reason MJ's ascent AP is fundamentally wrong - ascent profile is cued by velocity, not altitude. I fly everything manually, and usually go like this - until 60 m/s I fly strainght up (rolling to the launch azimuth as required), then turn to about 2-3 °, wait until I get to about 160 m/s, then turn for another 5° to so. Next turn is at around 0.8M to another 7-8 degrees (to a total of 20° from vertical) and wait until I pass transonic region (velocity over 1.2M) . After than I follow the lower border of velocity indicator until I'm about 45° pitch and travelling about 4-5M. At that point I'm usually high enough to get rid of payload faring. After fairing jettison I switch to orbital indicator and slowly turn to the center of it and start watching my apoapsis, slowly turning toward horizon as Ap approaches that of a target orbit. My upper stage is usually underpowered (the most pathetic example being Atlas V, it's Centaur upper stage is severly underpowered even in dual-engine configuration and reaches TWR of 1 only after half of its' fuel is burnt, especially in configuration with solids), so I try to shoot to the upper border of orbital velocity vector and keep above-horizon trim after passing apoapsis. Once TWR exceeds 1, I watch my vertical velocity and try to bring it to zero (which means that I'm at Apoapsis and flying level).

Yeah I agree but the huge rockets are just painful to control. Dynamic warp helps but it's still annoying, I'd rather fly inefficiently with MJ than fight the lag myself.

Link to comment
Share on other sites

Yeah I agree but the huge rockets are just painful to control. Dynamic warp helps but it's still annoying, I'd rather fly inefficiently with MJ than fight the lag myself.

Well there is an easy solution to that problem - haul it up in parts and assembly on orbit :) Besides I didn't notice any lag even when I was flying a monster rocket that hauls 100 tonnes to orbit. It is a bit hard to control, but nothing that any good pilot couldn't handle.

Link to comment
Share on other sites

Well there is an easy solution to that problem - haul it up in parts and assembly on orbit :) Besides I didn't notice any lag even when I was flying a monster rocket that hauls 100 tonnes to orbit. It is a bit hard to control, but nothing that any good pilot couldn't handle.

I think stretchy tanks save a LOT of part count. Never had any issues with fps either, even with my low end Pentium G 2120.

Link to comment
Share on other sites

Success! After 5 hours of testing and modifying my vessel and its launch profile I have been able to place my first small satellite in a stable orbit around real sized Kerbin!

Congrats, Miller. As a further suggestion on figuring out how to fly your rockets with the Real Solar System mod, I recommend looking up real rocket designs and watching a few launch vids, paying special attention to the orbital parameter callouts. Thanks to Nathan's mod and Ferram you can fly real launch vehicles now just as god* intended.

(*) aka rocket scientists

Take for instance a Falcon 9 (v1.1):

payload to orbit: 13150kg

total liftoff mass: 505.8 tons

mass fraction to LEO: ~2.6 [%]

liftoff TWR: 5885 [kN] / 9.81 [m/s^2] / 505.8 [tons] ~ 1.19

From the posted info you can even calculate propellant loading, stage mass and delta-v (simplifying here a bit by ignoring Isp non-linearity during initial ascent):

First stage avg thrust: 6278.5 [kN]

First stage avg Isp: 296.5

First stage burn time: 180 (3 minutes)

First stage propellant load: (6278.5 [kN] / 9.81 [m/s^2]) * (296.5 / 180 ) ~ 388.5 [tons]

First stage delta-v: 296.5 * 9.81 [m/s^2] * ln(505.8 [tons] / (505.8 [tons] - 388.5 [tons])) ~ 4250 [m/s]

Second stage thrust: 800 [kN]

Second stage Isp: 340

Second stage burn time: 375 (6 minutes, 15 seconds)

Second stage propellant load: (800 [kN] / 9.81 [m/s^2]) * (340 / 375 ) ~ 73.9 [tons]

Estimating the second stage initial mass is a little bit a of guesswork, but we start with the initial empty vehicle mass:

505.8t ((liftoff mass)) - 388.5t ((first stage propellant)) - 73.9t ((second stage propellant) - 13.15t ((payload)) ~ 30.25t

If the structural overhead vs propellant load is roughly equivalent to the first stage, then the empty second stage masses: 30.25t * (73.9 / (388.5 + 73.9)) ~ 4.83t

So given an initial mass of the second stage being: 4.83t ((structure)) + 13.15t ((payload)) + 73.9t ((propellant) ~ 91.88t

We get:

Second stage TWR: 0.89

Second stage delta-v: 340 * 9.81 [m/s^2] * ln(91.88 [tons] / 17.98 [tons]) ~ 5440 [m/s]

So in total, the Falcon 9 v1.1 has a delta-v of roughly ~9.5km/s and the TWR ratios above. Take all of the calculations with a grain of salt, they are pretty much back-of-the-napkin kind of stuff and it's possible I'm totally off, but these numbers at least appear plausible to me. I'm sure if I've made a grave mistake somewhere, other kind forum users will readily tear me a new one :D

Edited by diablos
typos
Link to comment
Share on other sites

For the past few days I have been trying to make a vessel that is capable of positioning my small hexasat in a 400km LEO orbit. The payload is pretty small weighing just about 0.2 tons. The whole vehicle is 4 stage and it has a delta-v of around 10.2 km/s. No matter what launch profile i tried, it never reached stable orbit. Any ideas? 20fuv85.jpg

I quoted the picture to point out the most massive flaw in that: The turn end altitude the same as the orbit altitude. As a result you spend most of the time burning diagonally to the ground, gaining altitude but not gaining horizontal speed. The goal should be clear the atmosphere as early as possible, but also increase horiz vel as early as possible.

There are already tons of examples in this own thread, but they are buried a few pages deep. I have a feeling that people will start asking repeatedly the same questions to the infinity.

Link to comment
Share on other sites

Actually that's the reason MJ's ascent AP is fundamentally wrong - ascent profile is cued by velocity, not altitude.

I went to one of my space books, and quoting it:

"The pitch program is often specified in terms of an initial pitch angle at some epoch (not necessarily liftoff) and a desired angluar rate, dα/dt, as a function of time. This closes Eqs. (5.11) and allows integration of the trajectory from the launch pad to burnout conditions."

Space Vehicle Design, Michael Douglas Griffin.

Therefore MJ AP is not wrong... it is just simple. It gives the possibility to define a curve with three control points, and it works as long as the user gives correct info for these three control points.

Link to comment
Share on other sites

AndreyATGB: is it really more memory intensive? I thought I fixed that issue.

asmi: Yeah, I always start my turn in MJ at 100m/s and try to tweak the other params so I have a zero-lift ascent, but it'd be much easier if one could do it with velocity not altitude. Maybe we can wheedle it out of sarbian? :)

Exposure, that's an excellent explanation!

There's a few additional points I'd like to make, though, just to fill in a couple gaps.

First, hypergolics as fuel don't, per se, have worse sea level performance--indeed, the penalty to "standard" Isp is identical, 0.95x a kerolox engine. What you're seeing is that most hypergolic engines are either orbital maneuvering engines or upper stage engines, and thus the nozzle is optimized for vacuum. MFS does have some lower-stage and L+ engines set up for hypergolic, and those will have decent sea-level performance. Try, for example, the NovaPunch Matriarch: it has 4500 thrust and a sea level Isp of 283 at TL4.

The main reason to use hypergolics is they ignite automatically, which will become an issue when Engine Ignitor is supported automatically.

The fuel mode that loses out at sea level is actually hydrolox: while you usually get approx 1.3x the Isp of a kerolox (baseline) engine, you get only 60% the thrust and 0.7x-0.97x the proportional sealevel Isp (i.e. only 0.91 to 1.26 the sea level Isp of a kerolox engine, vs 1.3x the vacuum Isp).

Make sure, if you're making a hydrolox stage, that you're using cryogenic tanks; they will be lighter and will lower the loss rate of the fuel. The Jumbo 64 is one, and there's a cryogenic superstretchy.

Finally, remember to set your engine TechLevels as desired. Some engines start out as 1945-level technology, but can be upgraded to present-day performance. Techlevel is set the same way fuel mode is, in the Action Editor pane of the VAB/SPH with the engine selected.

Miller: conrgats!

Another reason you're underperforming is the incredibly high TWR, as people have been saying. TWR on liftoff is usually around 1.2 (make sure the TWR you're looking at is the SLT column in Mechjeb stats; click All Stats to make it show up. That's your actual liftoff TWR at sea level (because thrust decreases in a linear relationship with Isp).

Link to comment
Share on other sites

Therefore MJ AP is not wrong... it is just simple. It gives the possibility to define a curve with three control points, and it works as long as the user gives correct info for these three control points.

Actually it IS wrong and your quote clearly explains why. Regardless, if there is only one parameter that should aid ascent, it should be velocity as altitudes are very different for different vessels, while velocities are pretty much the same.

Link to comment
Share on other sites

I made a code in KOS based on asmi's AP if anyone is interested :) works neatly in my tests!


set Final to 300000. //Target Orbit
set t to 0.
Lock throttle to t.
set Mach to 343.2.

// Converting from Vector to 'NavBall'
lock tfv to velocity:surface.

lock tfA to latitude.

lock tfuy to up:yaw.
lock tfB to 0 - tfuy.

lock tfW to tfv:x*cos(tfB) + 0 + tfv:z*sin(tfB).
lock tfN to tfv:x*sin(tfA)*sin(tfB) + tfv:y*cos(tfA) + tfv:z*(0-sin(tfA)*cos(tfB)).
lock tfU to tfv:x*(0-cos(tfA)*sin(tfB)) + tfv:y*sin(tfA) + tfv:z*cos(tfA)*cos(tfB).

lock tfE to 0 - tfW.

lock tfradius to (tfe^2 + tfn^2 + tfu^2)^0.5.

lock incl to arcsin(tfu/tfradius).

// End of conversion, didn't include azimuth because it isn't needed in this program

set flag to 0. //You'll know what this is for later

stage. // Can be removed, depends on staging, like turning engines on before launchclamps
set pVal to 90. //pitch value
lock steering to heading 90 by pVal. //90 means East, 0 means North, if you want a different angle change that 90
Print 3. wait 1. //Countdown
Print 2. wait 1.
Print 1. wait 1.
set t to 1.
stage.
Print "Launch!".

when tfv:mag >= 60 then {Print "Gravity Turn.". set pVal to 85.}. //tfv = surface velocity vector
when tfv:mag >= 160 then {set pVal to 80.}.
when tfv:mag >= 0.8*Mach then {set pVal to 70.}.
when tfv:mag >= 1.2*Mach then {
until incl<=50 { //Incl obtained from the conversion
set pVal to incl-5.
}.
}.
when tfv:mag >=4.5*Mach then {
until apoapsis >= Final*0.85 {
set pVal to incl-10.
if incl<=0 {break.}.
}.
lock steering to prograde.
set t to 0.5.
set flag to 1.
}.
when flag = 1 then { //Here is the flag's purpose
wait until apoapsis >= Final.
set t to 0.
set flag to 2.
}.
when flag = 2 then {
// Insert Circularization Program Here
set flag to 3.
}.
wait until flag = 3. // This needs to be here or the program ends in like a second

EDIT: The program does not include staging, because there are many different combinations! Make sure to add that or do it manually!

Edited by AbeS
Link to comment
Share on other sites

Actually, in the interest of accuracy I have to amend part of the above. When I said even the ones that come from NASA what I really meant was especially the ones from NASA. And that's not done here, the cameras themselves on some of the probes were tuned to filter them. I have no idea why. If you look at the Viking images, focus on shots that include the lander's hull. The Martian atmosphere itself shouldn't filter the light enough to tint the white hulls red and yet in a lot of those shots they're noticeably pink.

I know there is some debate about the NASA colouring of pictures, but I also know that for the rover missions a lot, and I mean a lot of camera calibration, benchmarking and testing was done in pretty much every conceivable light condition to ensure accurate colour reproduction. They deemed it essential for certain measurements and experiments. Even the NASA guys though it was a crazy amount of testing.

I have a hard time believing that NASA would structurally spread misinformation about the colours. Unless someone can bring some really strong evidence to the table about the more recent missions, I feel the only reasonable conclusion it that Mars is red/pinkish as anything almost all of the time, as it is a huge dustbowl of pretty must exclusively red dust.

Link to comment
Share on other sites

Outside of mimicking real life rockets, how do you guys calculate/figure out your different tank sizes for different fuels? The hypergolic bit should not be too hard, but hydrolox and kerelox has a bit of a grey area.

Is there an elegant way of doing this, besides old fashioned trial and error?

Link to comment
Share on other sites

Outside of mimicking real life rockets, how do you guys calculate/figure out your different tank sizes for different fuels? The hypergolic bit should not be too hard, but hydrolox and kerelox has a bit of a grey area.

Is there an elegant way of doing this, besides old fashioned trial and error?

Actually you don't need to calculate the size of the tank. All you need to know is how much delta V you want from the stage and then shape the fuel tank to your liking. For example, you have a payload + upper stage (and engine of course). Stick a mechjeb on, it will show you the masses, TWR and Delta-V. If you need more delta V, just drag the tank to make it a little bigger. If you drop below the needed TWR, then you need a stronger engine or a third stage. If you need better efficiency, try something with better Isp...

Does this answer your question or I've misunderstood.

Link to comment
Share on other sites

Kerolox has almost the same impulse per unit volume as stock KSP's LF/Ox. Hypergolic NTO/MMH is denser, but the engines have lower specific impulse; you'll get more impulse per unit volume but it'll be more than proportionally heavier. Hydrolox...I don't have a rule of thumb for that. Haven't played enough with it to know (my personal space race is barely in alt-1960).

Link to comment
Share on other sites

Does this answer your question or I've misunderstood.

Kind of. I meant calculating each stage size in a rocket with multiple stages using different fuels, so for instance a lower kerelox stage with an upper hydrolox stage, possibly with some solid boosters to boot (which are now also modular). I assume this is not done by guessing when it comes to the real thing, but I would not know how to properly calculate something like that.

I guess it would help plotting graphs of a number of things (tank size, atmospheric density/drag, fuel density/efficiency) and how those relate to each other, but how to do this properly eludes me at the moment.

It seems like fun to work out though, so maybe I should not ask this here :D

Link to comment
Share on other sites

Outside of mimicking real life rockets, how do you guys calculate/figure out your different tank sizes for different fuels? The hypergolic bit should not be too hard, but hydrolox and kerelox has a bit of a grey area.

Is there an elegant way of doing this, besides old fashioned trial and error?

I'm not sure if that's the elegant solution or not, but here is how I do it:

Before you begin a design, you need to know three things - maximum payload mass, maximum payload dimentions (to make sure the fairing you use is large enough to accomodate the payload), and destination orbit. From what I see on forums, PLF size is often neglected during design, which leads to a problems with aerodynamics so make sure your PLF is not too wide.

Now, if your target orbit is beyond low orbit, I generally choose three-stage design with first two orbiting a payload coupled to the last stage which will provide dV necessary for orbital maneuvers (I call it "orbital unit" or OU).

First build that OU - since once you're on orbit TWR doesn't matter anymore, the only limitations here are your patience (if you're willing to wait for long burns to gain more efficiency) and availability of engines at your disposal. Put on the Stretchy Tank(hereinafter ST) and engine and keep extending it until it has enough dV for orbital operations and deorbit (keep in mind that deorbit will be performed without payload, so dV will greatly increase after payload separation).

Now, for the hard part - launch vehicle. That part is largely limited by what kind of engines you've got, but the goal is to distribute ~9.3 km/s of dV needed to get to the parking orbit (I generally use orbits in 180-250 km range) among your stages. I usually try to split it more or less even.

They way you do it is you strap ST to the OU (via decoupler of course), put engine that has thrust of approximately 4-5 times of your OU full weight, and extend your tank until you hit initial TWR of approximately 1 (in practice I use values in the range of 0.8 to 1, except for Altas Centaur stage). After that, strap first stage and do the same, but this time make sure your SLT (sea level thrust, use "show all stats" button in MJ to display it) is at least 1.1.

Check your total dV budget at that stage, if it's enough for the mission, put on stage separation motors, strut stages together and go for a test launch.

If your dV is too low, you'll need to use strapon boosters. If your dV budget's deficit is less than ~600 m/s, go for a pair or quartet of solids (depending on what kind of solids you've got handy), and extend your first stage. The idea is that by the time your solids are gone, your TWR needs to become at least 1.1.

If you're short by more than that amount of dV, consider using liquid boosters with the crossfeed, or without it. I usually go without CF if my deficit is below 1 km/s, in this case I do essentially the same thing I do for solids above - enlarge the core stage so that bt the time of boosters sep its' TWR would exceed 1.1.

In case you go with crossfeed, do not change your first stage, but add 2 or 4 boosters (depending on the engines you've got) so that you make up for the deficit.

Remember these things:

1. ALWAYS strut your stages together on top of interstage (you can make lower stage a bit wider if something - typically decoupler - gets into the way of struts) AND decoupler to the lower stage.

2. Check all places where heavy part is connected to MUCH lighter one (by "much" I mean more than ~50 times difference) - these are spots with risks of structural failures. Strut them as necessary or at very least keep them in mind so you'd know what to do in case rocket starts falling apart on the launchpad.

It requires some practice, but trust me once you do it first few times you'll get a hand of it!

Link to comment
Share on other sites

Answer to Nathan about RAM, I don't think your mod uses more ram, what I meant was the need for many other mods to make this more enjoyable ends up using more ram. Also, unrelated, how do I get clouds on the surface? They work in the space center view but not in flight for some reason (only above 70 or so km).

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...