Nicias
Members
Content Count
161 
Joined

Last visited
Content Type
Profiles
Forums
Developer Articles
Everything posted by Nicias

[1.4][1.7.7] GravityTurn continued  Automated Efficient Launches
Nicias replied to AndyMt's topic in Addon Releases
I just wanted to share some offlabel use I've been getting out of GT. I've been using it to implement constant vertical velocity takeoffs. (Only recommended for vacuum launches, also I've been using 10x rescale and SMURFF so I have DV costs that are about sqrt(10) times larger, but I have much better mass fractions.) The idea is to use just enough vertical thrust to keep from crashing into the terrain. In terms of GT settings, I set the starting velocity to 10m/s (or something small, but enough to give the vehicle time to get truly vertical) time to AP I set to 20s for both start and end. I set sensitivity to 1. I set the desired target orbit. For the starting angle, I use the maximum angle that keeps a vertical TWR of 1. (so Cos(A) TWR = 1 or A = arcsec(TWR) ) When I execute this the rocket goes up, turns to the angle I indicate, vertical velocity stays at about 10m/s (a little more due to the time to turn), and starts to build up horizontal speed. I think GT keeps the vehicle at the starting pitch until prograde drifts down to that pitch.Then it looks to see if the time to Ap (TTA) is under or over the desired amount. If it is over, GT follows prograde, if it is under, it pitches up to push the TTA up. This results in the craft pitching up and down (because of the PID controller I guess) around an ideal pitch angle of arccsc( Thrust/ (mass * (g  centrifugal force))) which decreases as horizontal velocity goes up and mass goes down. Eventually this angle decreases to below prograde and the rocket follows prograde to orbit. Prograde at this point is usually at most a degree or two above horizontal. The only way this fails is if there is higher terrain downrange. Then I just increase the time to AP setting enough to clear the terrain. Once past the terrain, I set it back down to 20s or so. This method is very reliable for me. It usually works on the first short and gets better DV to an actual gravity turn performed by GT. I've done some simulations in mathematica, (single stage) and get that a perfectly executed version of this (TTA fixed to 10s) slightly outperforms gravity turns for initial TWR of 1.5 to 3 on the Mun. (for example with an ISP of 345 and an initial TWR for 2 on the MUN simulation indicates 645 m/s to a 14km orbit, including circularization for a constant vertical velocity, vs 657 for best possible gravity turn) Just thought I would share. 
Huge vehicles, mechjeb and thrust vectoring (gimbal)
Nicias replied to Hoozemans's question in Gameplay Questions and Tutorials
You might also want to look at the GravityTurn Mod, it is simpler for this task then MJ. 
How do you calculate the time needed to reach a celestial body?
Nicias replied to Rover 6428's question in Gameplay Questions and Tutorials
You will probably want food for the way back too. So you should pack 601 foods for the journey. You also need food for the dwell time at Duna. You can overestimate and use the synodic period 1/(1/(Kerbin Year) 1/(Duna Year)) which gives 2.15 years (916 days). This is the time between transfer windows. So you should pack about 1500 days of food. You could improve that guess by looking at when the next dunakerbin departure window is after each kerbinduna arrival window. I did that a while back and found that they are separated by 529 days. So you really only need 1129 days of food. Here is the link where I work this out: 7 replies

 1

 life support
 calculating

(and 2 more)
Tagged with:

Direct insertion to Tylo orbit (math check)
Nicias replied to Nicias's question in Gameplay Questions and Tutorials
I was thinking if doing a Jool 5 with separate Landers going directly to each moon in a flotilla and and crew shuttle going moon to moon. I used to do insertion into a gateway orbit for this kind of mission but had a screwup with my relay sats carrier and so tried the direct insertion and saved a bunch of DV. This is at 10x rescale. 
Direct insertion to Tylo orbit (math check)
Nicias posted a question in Gameplay Questions and Tutorials
Hi, I recently had the idea to try and capture directly into low Tylo orbit from a KerbinJool transfer. The thought was to add Tylo's Oberth to cut down on required dV. What I did was make a node to set my perijool to be the same as Tylo's orbit while far away (thanks MechJeb) Then once I was in Jool's SOI, I made a node almost right away and put in some retrograde to get an intercept with Tylo. Fiddling with this node (adding normal and radial components) I was even able to get the correct peritylo. This cost about 50m/s. Then I coasted down into Tylo's SOI, and burned at peritylo to capture. It saved a TON of dV. I didn't get an accurate estimate because MechJeb's dv calculator had a bug in it for a couple of days. But I had a whole spare stage! So I decided to run the numbers, to see what the savings really was. Here are my calculations. I used visviva for everything. Jool orbital velocity: 4129 m/s. Transfer orbit 2372 m/s. Excess velocity at Jool: 1756s m/s. That velocity at the edge of Jool's SOI (2.46 E 9) with Jools mu (2.83 E 14) gives a SMA of 9.90 E 7 (hyperbolic) That SMA and Jools mu gives a velocity of 3332 m/s at Tylo's orbit (6.85 E 7). Tylo's orbital velocity is 2031m/s, so excess velocity relative to Tylo is 1301 m/s. 1301 m/s at the edge of Tylo's SOI (1.09 E 7) with Tylo's mu (2.83 E 12) gives a SMA of 2.41 E 06 (hyperbolic) That SMA and Tylo's mu gives a velocity of 3141 m/s at 50km (target orbit radius 650,000 ). Circular orbit at that radius is 2049 m/s so the actual burn needs to be 1056 m/s. The deltav map gives 160+400+1100=1660. So the direct injection method saves 36% That seems like way to good to be true. Is my math off? 
I think something is wrong with the dV calculator. If you just put a poodle, X20032, and RC001S together, the dV calculator reports a dV of 11259 and a run time of 439.3 seconds. Both are almost exactly twice as large as they should be. If you just use a RC001S, Nerv, and Mk1 LF fuesalge, MechJeb reports 3305 dv and a run time of 235.3 seconds. Both are about 90% of what they should be. This is with a bare 1.5.1 install with just MJdev (and MJ for all) installed.

[1.4] SpaceY HeavyLifter Parts Pack v1.17.1 (20180402)
Nicias replied to NecroBones's topic in Addon Releases
I find the length of the shroud on the 3.75m 2.5m thrust plate to be too long. I was thinking of make a MM patch to clone the part and make a new "short" version, like there is for the 2.5m1.25m thrust plate. Is there any reason this wouldn't work? Edit: I think I got it to work. This is the patch I used: //add a short version of the 3.52.5m thrust plate from SpaceY +PART[SYplate3m2mX1]:NEEDS[SpaceYLifters]:AFTER[SpaceYLifters] { @name = SYplate3m2mX1T @MODEL { @scale = 1.0, 0.5, 1.0 } @node_stack_bottom = 0.0, 0.1, 0.0, 0.0, 1.0, 0.0, 2 @node_stack_bottom1 = 0.0, 2.5, 0.0, 0.0, 1.0, 0.0, 3 @node_stack_top = 0.0, 0.1, 0.0, 0.0, 1.0, 0.0, 3 @title = SpaceY A32 Interstage Adapter (Short) @description = (3.75m to 2.5m) Customize your engine clusters, in either an upperstage (with fairing), or lowerstage configuration  Short. Suitable for Poodle, Mainsail, and Skipper. @mass = 0.25 } 
[1.4] SpaceY HeavyLifter Parts Pack v1.17.1 (20180402)
Nicias replied to NecroBones's topic in Addon Releases
Would it be possible to add interstage nodes to the 5m fairing? (and the 7m fairing from Expanded?) 
I gave it a shot last night and it seemed to work fine actually. Thanks!

I see that Sigma Dimensions has been discontinued. Is there another mod to play a 10x rescale of the stock system on 1.5?

[1.7.x] Stockalike Station Parts Redux (May 21st)
Nicias replied to Nertea's topic in Addon Releases
I'm using stock contracts. 
Sorta. You can combine two maneuvers if one of them can be made to happen "at a specific time". So circularization works for that. So, set up the plane inclination how you want. Then use the maneuver planner to create a new maneuver to circularize at a fixed time of t=0 seconds after the last node. Then you go to the maneuver editor, and it should have "merge with next node" button. Click that and it will combine the two nodes.

[1.7.x] Snacks!  Friendly, Simplified Life Support
Nicias replied to Angel125's topic in Addon Releases
Has anyone tried the latest version with 1.5.x? 608 replies

[1.7.x] Stockalike Station Parts Redux (May 21st)
Nicias replied to Nertea's topic in Addon Releases
Yeah, right now I just kinda ignore it. If the contract says to add 15 seats, I add 15 seats. The only downside is that I don't get the nice contact completion on hab inflation. The cupola thing is more annoying. 
[1.7.x] Stockalike Station Parts Redux (May 21st)
Nicias replied to Nertea's topic in Addon Releases
Yes, that is correct. Let's say that a station has a hitchhiker and a 8 person inflatable centrifuge (inflated). I might get a contract that requests that I expand the station to support 9 kerbals (and indicates that it currently only supports 4). If I just switch to the station, the check box for "supports 9 kerbals" is checked. I can doublecheck when I get home. 
[1.7.x] Stockalike Station Parts Redux (May 21st)
Nicias replied to Nertea's topic in Addon Releases
I agree. I just wanted the stock contract system to count them as having the crew capacity for the purpose of calculating the current capacity of a station for station expansion contracts. I suppose this was because that system was seeing the "CrewCapacity" variable and not the "DeployedCrewCapacity" variable. So I suggested switching the paradigm. Presumably, the parts report their current capacity as CrewCapacity when retracted and DeployedCrewCapacity when deployed. The contract system only sees the CrewCapacity when making new contracts (It honors "Deployed CrewCapacity" when checking active contracts. It's actually neat watching the contract go green when you deploy the hab.) I was suggesting switching the behavior. So that the parts report their current capacity as "RetractedCrewCapacity = 0" when retracted and "CrewCapacity = 8" when deployed. Nertea said this was impossible for other reasons. 
[1.7.x] Stockalike Station Parts Redux (May 21st)
Nicias replied to Nertea's topic in Addon Releases
Well, crap. That's too bad. I really like the centrifuges, but I also like station building contracts. What would happen if I added my own MM config to changes the CrewCapacity to be the same as the Deployed value? 
[1.7.x] Stockalike Station Parts Redux (May 21st)
Nicias replied to Nertea's topic in Addon Releases
I don't understand how the inflatible/extendable parts are coded, but I see that they have in the cfg's, for example: CrewCapacity = 0 ... DeployedCrewCapacity = 8 Might it be possible to set them up to have: CrewCapacity = 8 ... RetractedCrewCapacity = 0 Of course, that would require recoding. It also might break other things and I have no idea how difficult it would be. 
[1.7.x] Stockalike Station Parts Redux (May 21st)
Nicias replied to Nertea's topic in Addon Releases
Hi, Great Mod! I'm having trouble where the contact system doesn't seem to count the inflated and/or rotation hab sections when doing "expand station" contacts. So it's value of "current supports" number is too low. Likewise it doesn't recognize the large cupola as a cupola. 
I do basically this, but I also have a small module attached to the front of the docking port with a probe core, rcs tank, and rcs thrusters. A couple of meters out I uncouple this module and quickly thrust it out of the way.

Wondering Out Loud: Seven questions
Nicias replied to Bakkerbaard's question in Gameplay Questions and Tutorials
If you turn off crossed on the decouplers and use fuel ducts going up then you might get the behavior your want. 
I don't know how helpful this is, but I realized that for many trips, most of the time is coasting. So if life support supplies (and their containers) are heavy, you want to stage them. Ideally you are never burning with any empty containers. So I have three LS container stages. The first one gets dumped before I burn for capture. The second gets dumped before I burn to go home, the last gets dumped before capture at home. I typically also have a couple of weeks on LS in on the Kerbin capture stage, in case I need to do a twopass capture. This is using Snacks!, which mostly just adds a mass penalty for LS.

No, he's @JP_Magoo is correct. Surface gravity is proportional to M/R^2. Mass is proportional is d*R^3. So, surface gravity is proportional to d*R. If you divide R by 10, you have to multiply d by 10 to keep the same surface gravity. My favorite armchair astronomy fact is related to this. Tidal forces are proportional to M/D^3 (D is distance to body.) M is proportional to d*R^3, so tidal forces are proportional to d * (R/D)^3. Now R/D is (to good approximation) the angle the object makes in the sky. So since the moon and the sun have the same size in the sky, (to good approximation) , the ratio of the tidal forces from each is the same as the ratio of their densities. You can measure the tides to determine that the sun's impact is about half the moon's. So the sun is half as dense as the moon.

Ok, so I mathed the heck out of this. I used Mathematica for all of my calculations. I did everything as if you are going from Eeloo to Kerbin. I could rerun it to go the other way if I just change the AoP of Eeloo to negative its current value. I first ignored inclination. I determined both the dV for transfer with minimum eccentricity at a given departure angle. I also determined the minimum dV for a departure at the given departure angle with periapsis at Kerbin's orbit. The results range from 3141 m/s to 3740 m/s for both methods, departing at apoapsis for worst case and periapsis for best. Note that periapsis is at 0 or 360 degrees and apoapsis is at 180 degrees. https://imgur.com/rzZXYtZ https://imgur.com/usf927a As other have mentioned, the dV is dominated by the Eeloo burn. Now adding in inclination I first did it by correcting the inclination at the AN or DN that is on the way down to Kerbin. Again I used minimum eccentricity and optimized for dV transfers. For the least eccentric I got a range of 3782 to 5013 m/s. Departing at 226 degrees and 291 degrees. The range in inclination change is the largest of the factors. Breaking down the dv budget as Eeloo departure, inclination change, Kerbin capture gives: 3782 = 1221 + 410 + 2151 and 5013 = 1732 + 1289 + 1993. As you see the inclination burn is the biggest factor. (410 versus 1289) https://imgur.com/4LYot79 The same calculations minimizing dv gives: 3584 @ 100 degrees to 4882 @ 309 degrees. With breakdowns: https://imgur.com/SXO9sB4 3584 = 1289 + 203 + 2092 and 4882 = 1664 + 1255 + 1964 The minimum transfer one saves dv on the inclination by going a little farther out. than the mimimum eccentricity one. If you look at the graphs for these two you'll notice a sawtooth pattern to the inclination changes and hence the total. As the departure location of the transfer orbit approaches the line of nodes, the transfer gets cheaper as you are departing closer and closer to the node. As the departure location passes the node (100 and 280 degrees) then you have to correct at the lower node. So that 1255 in the above example is correcting right outside Kerbins SOI. This explains the jumps in the graphs. In practice you could roll that correction into the Kerbin capture and then have Pythagorean and Oberth savings. Finally I allowed for correcting the inclination at either node. That gave: 3619 @ 146 and 4512 @ 10 for least eccentric with breakdowns: 3619 = 1101 + 345 + 2172 and 4158 = 1834 + 417 + 1906 https://imgur.com/iT3COSl dv optimized were: 3531 @ 125 and 4495 @ 8 degrees, with breakdowns of: https://imgur.com/FjXfSgk 3531= 1122 + 265 + 2144 and 4495 = 1835 + 755 + 1906.