Pand5461

Okay, correction for atmospheric planets: ts = (g - (T + Fd/3) / m + sqrt{ [g - (T + Fd/3) / m]2 - 2*V*(T/m)2/(Isp*g0) } ) * (Isp*g0)/(T/m)2 where T is total thrust (projection onto vertical axis), m is vessel mass, Fd is drag force (projection onto vertical axis, positive number if going down), V is vertical speed (projection onto vertical axis, negative number if going down), Isp*g0 = T/fuel_consumption = effective exhaust speed hs = -V*ts - [(T + Fd/4) / m - g]*ts2/2 - (T/m)2/(Isp*g0)*ts3 / 6 I hope it is possible to get drag value from the API because it's available in-game in Aero GUI. Also, this expression for the burn distance may give better results: hs = (Isp*g0)*(m - f*ts) / f * ln[ m / (m - f*ts) ] - (V + Isp*g0)*ts + ( g - Fd/(4*m) )*ts2/2 where f is propellant consumption rate in kg/s or ton/s. The latter is the proper integration of rocket equation at vertical descent with gravity and (quite simplified) drag, the previous one is the Taylor expansion of the same expression up to the cubic term.

When it fails, what are initial height, vspeed, twr and planet? EDIT: if it's Kerbin and starting vspeed is near or above terminal velocity, then formula is expected to fail

This formula was derived for conditions quite a bit different from what your test case is. And AAARRGH, I've written the wrong explanation for the formula. Now I've redone all the steps to derive it, adry is in fact the Thrust / mass_at_start_of_burn . "Dry" is because it was initially a part of a big landing script, and suicide burn was using the last liters of propellant. In that case, throttling down was not a good option because every extra second of burning devours delta-V, and the lander had barely enough to casually spend few tens of m/s for no good reason. And, although change of TWR from 1.05 to 1.1 during the suicide burn might not seem that big, the actual deceleration changes twofold (because it's TWR-1 that defines deceleration) and the real suicide burn is significantly shorter than constant-TWR one. These are two main reasons I bothered to find a more accurate approximation than simply t = speed / (total thrust / mass - g). The big formula or the short one?

@kerbinorbiter, you mean this: print "hello world". //prints hello world on screen lock throttle to 1. //same as pressing the Z key lock steering to up. //points the craft directly up lock steering to retrograde +r(0,-20,0). // locks steering somewhere retrograde-ish (rotations, or directions are really crazy) Lock steering to heading(90,0). // The way directions are probably intended to be used lock throttle to 0. //same as pressing x on your keyboard wait 3. //waits 3s wait until ETA:APOAPSIS < 15. //Waits 15 seconds until apoapsis You can do this with the periapsis too set y to 90. // sets variable y to 90 ? (please use the code formatting with the <> button) And what you really forgot to mention is that every command must end with a period. And, if you started with mathematical operations on rotations, what is the difference between retrograde+R(0,-20,0) and retrograde*R(0,-20,0).

@linuxgurugamer, ahhh, so many new questions... So, about everything: g is the free fall acceleration at the point where ship is (or rather halfway from there to the surface). On Kerbin, it is roughly g0, but the formula wasn't written with only Kerbin in mind. adry is the acceleration in m/s2, from engines only. 4.58 is clearly too low for Kerbin landing, so I'm assuming it is the acceleration after subtracting g, and the value the formula really required is 14.38. I was very "kind" to omit that vertical speed is signed and negative for going down, many apologies. Glad you figured it out from my vague description. ISP is the average of all thrusters, and (ISP*g0) is the effective exhaust speed in m/s, which in turn is (total thrust in kN/propellant consumption in tons/sec). This is identical to the formula from wiki: The complex formula accounts for mass change during the burn, as @captinjoehenry pointed out. t' = speed / (total thrust / mass - g) is systematically overestimating the time needed because it uses just the high mass at the start of the burn, so in the case of high speeds and low initial TWRs you stop too high above the ground when using it (tested for Mun lander going down at ~100 m/s with TWR ~1.3). BUT, this rough estimate is useful for the estimate of adry: adry ~ Thrust / (m0 - t'*consumption_rate). With the corrected adry, the formula gives 5.42 s burn time and 71.5 m vertical travel, fairly close to your values (91m is clearly too much, because even at constant acceleration, distance is (V2 - V02)/(2a) = (02 - 262) / (2*4.58) = 73.8m, and acceleration increases due to fuel burnout).

I'm wondering why nobody mentioned this: Right-Click on game in Library -> Properties -> Local Files tab -> Browse Local Files gets you to the game folder. EDIT: silly me, it's on the wiki

Although you cannot get Mun-synchronous orbits inside Mun SOI, you can put two sats to the same orbit around Kerbin as Mun's slightly in front of and behind Mun SOI. Then, you need just another two sats on the orbit around the Mun for all your relaying needs.

Well, if you're launching from Kerbin/Duna, you may use gravity assist from Mun/Ike to change inclination. If you are VERY careful, you may even manage to get multiple encounters. This should save a few hundreds m/s. Otherwise, the advice from @Lelitu is probably the best you can get.

@Kobymaru, for a one-dimensional problem, NN solution is overkill (also, ever since I got familiar with the outputs of natural NNs, a.k.a. brains, I tend not to trust even artificial ones). @Kartoffelkuchen, a proportional controller could be enough but that's KSP, people like to over-engineer things here. (In fact, discrete-time P-controller may get unstable in cases when continuous-time one is stable, that's why I suggest adding the derivative term).

Proportional-Integral-Derivative control. In this case, Integral part won't be needed, I think, so it will be just PD-controller So, PD(x) = KP*( x(t) - x0(t) ) + KD* d( x(t) - x0(t) )/dt, where x is the actual value of signal, x0 is what you wanted the signal to be. For those who lives in a discrete time (hint: kerbals do) that changes to PD(x) = KP*Δ(tnow) + KD* (Δ(tnow) - Δ(tprev) ) / ( tnow - tprev), where Δ(t) is short for ( x(t) - x0(t) ), tnow is current time, tprev is the time of previous calculation of Δ(t). So, in the above case X is height, X0 is calculated hs, and KP and KD must be negative numbers (need to throttle up when ship is too low, and throttle up even harder if it goes increasingly below the right height).

But... Throttle is probably PID-controlled? So, it's possible to calculating suicide burn not for full thrust but for 0.9 thrust and use PID to keep the ship always at the suicide burn distance until the touchdown. This is probably how it's done IRL. Some (not exactly) simple math For a vertical descent, if we neglect atmospheric drag, time of suicide burn is (approximately, but suprisingly accurately) ts = (g - adry + sqrt( (g - adry)2 - 2*V*adry2/(Isp*g0) ) ) * (Isp*g0)/adry2 g being the free fall acceleration, adry the acceleration of rocket at full thrust at touchdown (to know that before starting the burn, you of course going to need some guesstimation), Isp the specific impulse, g0 = 9.80665 m/s2, V the vertical speed. Distance travelled in that time is hs = -V*ts - (adry - g)*ts2/2 - adry2/(Isp*g0)*ts3 / 6 So, at vertical part of burn you can assume "nominal thrust" as (maxT + minT)/2, calculate ts and hs for suicide burn at this throttle level, and then keep actualthrottle = nominalthrottle + PID( h - hs(V) ), where h is the actual height above the ground.

I think what was meant is the reverse - what if the engine can't go below 79% throttle?

If problem persist, I recommend you to check SVE thread to see if anyone had similar problems.

Looks like SVE or Scatterer issue. Did you install mods with CKAN?

Or zero the thrust in the VAB. I prefer doing both, just for extra safety.

Okay then, I didn't get that from your original question. But my point is still the same: increased costs reflect the fact that pod has doors (and probably airlocks but who knows).

What? There is a Mk2 Crew Cabin with 0.5t/kerbal, 1050 credits/kerbal, 45 m/s impact, 1400/2000 K. Why such difference in costs? It's the addition of the hatch I think (and hitchhiker container also has ladders!)

@linuxgurugamer, is this code supposed to run in a loop? If yes, for the performance reasons, I'd suggest calculating localg as mu/R^2, where mu is standard gravitational parameter of the parent body, R is distance from body center. In kOS it's as follows: set rb to ship:position - body:position. set localg to body:mu / (rb:x*rb:x + rb:y*rb:y + rb:z*rb:z). Don't know how it looks like for mod development though. From your code, it looks like that FlightGlobals.getGeeForceAtPosition is calculated as a vector, and only its magnitude is used. It adds a lot of unnecessary computations if you only need a scalar.

On second thought, you are right, it must be possible. So, here's the kOS lander code: https://drive.google.com/open?id=0Bw2BzA4x17Y2Tl9OcW5GNkVkcDA. It does landing by trying to maintain constant horizontal and vertical acceleration. So, on the problem in OP. As far as I understand, the number needn't be very exact unless it's close to zero. So, you may integrate retrograde burn until all velocity is killed, then assume distance traveled through burn proportional to vertical speed and estimate when to do suicide burn by that condition. The integration may be done by, say, Verlet scheme because it's computationally cheap and accurate enough, to my experience. Also, timestep of about 2 seconds should be enough, except for final moments of braking. Some concerns: Equations of motion must either be done in inertial frame or centrifugal and Coriolis forces must be accounted for. Unlike vertical burn, the ground height at landing site is generally not the same as right beneath the ship. In the case of vertical burn, if you missed the right moment - you are certainly going to crash. When you have initial horizontal speed, there are two cases - one is when you can't kill all vertical speed at touching the ground even burning straight up all the time, the other when you don't have enough time to kill horizontal velocity before touching the ground. In the former case, you are doomed. In the latter case, the situation can still be fixed by burning a bit upwards from retrograde. Thus, the time shown may be quite a bit misleading.

Erm... Holding Retrograde at full thrust most probably won't work - you won't be able to bleed off horizontal and vertical speed at the same moment. You are going to need either fairly complicated steering or throttling. Stock SAS doesn't do either of that automatically. I can post my continuous-burn landing script somewhere. It is not exactly this exact problem but might give some ideas.

I can guess why no one is even bothering about suicide burns that start with significant horizontal component. The difficulty is to keep the direction of the burn that won't be purely retrograde in such case. As for SQRT in time to burn computations - that might come from the approximate solution of the Tsiolkovsky's equation with gravity, I have to compare it against the formulae I obtained while writing kOS landing autopilot.

My pleasure Thanks for the great mod! Build #15 works just fine on my side (but I have no idea what "Recover to storage" means).

Thanks, @magico13! With the new build, the rollout issue is gone. Editing bug is still there. From what I briefly tested seem to work: Crew assignment (only tested when assigned crew becomes available by the launch time) Rollout -> Launch without changing scene Rollout -> Rollback -> Rollout -> Launch Wait until build completion -> Edit (a finished ship in storage) Rollout -> Rollback -> Edit What does not: Editing ship from build list But now, edited ship appears after the original in the queue, while in the previous builds edited one was first to build. There are still messages of successful removal in the "bugged" case, whereas in the working case there are messages about ID comparison. Maybe I'd better open a Github issue on this? Logs: Editing vessel from list Editing vessel from storage

Yes, the bug is still there on my installation. OS-specific issue?

Oh, sorry for the wrong log. Haven't read the reporting guidelines properly. The issue persists with build #13. It wasn't present in #10, though. Logs are attached. Both times I entered VAB, edited a craft being built and saved edits. #10 - no dupe appears, #13 - there is a dupe (or, actually, an unedited initial craft) in the build queue. For build #10 For build #13