# Nicias

Members

164

62 Excellent

## 1 Follower

• Rank
Spacecraft Engineer

## Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

1. ## Chasing Ap

You might want to look at this mod: and this thread: I tend to go with a start TWR of 2 for a SRB +drop-tank first stage, then 1.5 for a second stage and 1 for the third stage. I'm working at 10x rescale using SMURFF, so I need quite a bit more DV to get to orbit (~8000) I also found via simultation, that (ignoring atmosphere) an optimal gravity turn uses almost the same dv as porpoising to maintain time-to-ap. (what GravityTurn will do) So, once i get out of the lower atmosphere, I don't mind if I end up porpoising.
2. ## [1.7.3] Community Delta-V Map 2.7

If it's any help I recently found that constant vertical velocity launches tend to use almost the same as optimal gravity turn launches. The benefit is that dv of CVV launches can be calculated analytically. Assuming constant TWR and zero vertical velocity, and neglecting any sideral rotation, gives that if you are taking off from a body with a given mu and r with a certain twr, and going for a zero altitude circular orbit, it takes: (1/2)*Sqrt( mu/r ) * twr * ln( (1+twr)/(twr -1 )) If that helps.
3. ## Landing on Kerbol

Part of the problem is that the inverse-square law for solar intensity is incorrectly modeled in KSP. It should be inverse square of the distance from the center of the sun, but it is inverse square from the surface. This doesn't make much of a difference away from the sun, but when you get close the intensity goes up way faster than it should, with the surface effectively having infinite temperature.
4. ## [1.4][1.7.7] GravityTurn continued - Automated Efficient Launches

I just wanted to share some off-label 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.
5. ## Huge vehicles, mechjeb and thrust vectoring (gimbal)

You might also want to look at the GravityTurn Mod, it is simpler for this task then MJ.
6. ## How do you calculate the time needed to reach a celestial body?

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 over-estimate 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 duna-kerbin departure window is after each kerbin-duna 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. ## Direct insertion to Tylo orbit (math check)

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.

9. ## [1.9.x] Anatid Robotics / MuMech - MechJeb - Autopilot - [2.9.2] [14 February 2019]

I think something is wrong with the dV calculator. If you just put a poodle, X200-32, and RC-001S 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 RC-001S, 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 MJ-dev (and MJ for all) installed.
10. ## [1.4] SpaceY Heavy-Lifter Parts Pack v1.17.1 (2018-04-02)

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.5m-1.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.5-2.5m thrust plate from SpaceY +PART[SYplate3m2mX1]:NEEDS[SpaceY-Lifters]:AFTER[SpaceY-Lifters] { @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 A3-2 Interstage Adapter (Short) @description = (3.75m to 2.5m) Customize your engine clusters, in either an upper-stage (with fairing), or lower-stage configuration - Short. Suitable for Poodle, Mainsail, and Skipper. @mass = 0.25 }
11. ## [1.4] SpaceY Heavy-Lifter Parts Pack v1.17.1 (2018-04-02)

Would it be possible to add interstage nodes to the 5m fairing? (and the 7m fairing from Expanded?)
12. ## System Rescaling Mod for 1.5

I gave it a shot last night and it seemed to work fine actually. Thanks!
13. ## System Rescaling Mod for 1.5

I see that Sigma Dimensions has been discontinued. Is there another mod to play a 10x rescale of the stock system on 1.5?
14. ## [1.8.x] Stockalike Station Parts Redux (Jan 12th)

I'm using stock contracts.
15. ## [1.9.x] Anatid Robotics / MuMech - MechJeb - Autopilot - [2.9.2] [14 February 2019]

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.