-
Posts
272 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Everything posted by Yasmy
-
Oberth Effect (calculation of benefit)
Yasmy replied to Anglave's topic in KSP1 Gameplay Questions and Tutorials
Seems like Anglave's equation, ÃŽâ€v = sqrt(Vf^2 + Vesc^2) - sqrt(Vh^2 + Vesc^2) comes from http://www.projectrho.com/public_html/rocket/mission.php. It is really not clear at all what the equation is for. It appears to describe a situation where you are already on a zero energy (KE = -PE) escape to infinity trajectory headed towards the sun at some far remove from periapsis, say at radius R. It then describes the velocity increase at radius R on the other side of periapsis after performing a burn at periapsis. It compares that to making an immediate burn at your current location. I'm not sure it's entirely correct. I get something slightly different. (Conserve energy before the burn as you go from R to periapsis. Burn. Conserve energy after the burn as you go from periapsis back to R. Find the periapsis burn needed to equal a local burn.) A little further down on the same page is the more appropriate equation to use: deltavee = √(v_inf^2 + v_esc^2) - v_cir v_inf = velocity just before exiting Kerbin's SOI = 2.8 km/s v_esc = Kerbin escape velocity = 3.2 km/s v_cir = 2.2 km/s deltavee = sqrt(2.8^2 + 3.2^2) - 2.2 = 2.0 km/s The savings would be v_inf + (v_esc - v_cir) - deltavee = 2.8 + (3.2-2.2) - 2.0 = 1.8 km/s This deltavee is close to the 1920 m/s figure we were using, and the saving are close to the 1.7 km/s I calculated before. Note though that Snark is correct in pointing out that things are slightly different in the patched conic system KSP uses. The equations from the linked article will be wrong where you cross SOI boundaries. They are fine for operating inside an SOI. -
Glad to help. I'm sure someone will point you to a nice video tutorial. I use one of the transfer calculators to find a transfer window, time warp to the window, plop a maneuver node in LKO and fiddle around until the trajectory points along Kerbin pro/retrograde and it intercepts my target. Sometimes you have to drop a second node in interplanetary space to perform a plane change maneuver before you can generate an encounter.
-
Ignore that post. I was wrong, which is why I deleted it. The 430 m/s was 80 at kerbin (not in interplanetary space near kerbin, but LKO) + 350 plane change at the line of nodes in interplanetary space. But yes, you should exit Kerbin retrograde to go to the inner planets. - - - Updated - - - If you want to follow most delta-v maps, do the Kerbin escape burn and the transfer burn in one go, while still in low orbit around Kerbin. Then it will only take approximately 90m/s more than Kerbin escape velocity to drop your orbit down to Eve. If you escape Kerbin, then perform the transfer burn, it will cost a lot more delta-v.
-
Most delta-v maps do not list the delta-v for the kind of transfer you are doing. Your method is more expensive than the standard insertion from low orbit around the original body.
-
That low delta-v number is not the Kerbin SOI to Eve transfer number. It is the extra delta-v needed from LKO to get an Eve transfer, relative to the delta-v to exit Kerbin SOI. From just outside Kerbin's SOI, on Kerbin's orbit, it costs several hundred m/s to intercept Eve, but if you had initiated your Eve transfer from LKO, it would have cost less than 100 m/s more than Kerbin escape velocity to intercept Eve. You get huge benefits from doing your transfer directly from low Kerbin orbit.
-
Imagine you are in a polar orbit of Kerbin, and the orbit is aligned with Kerbol. You go from directly between Kerbin and Kerbol to directly behind Kerbin from Kerbol in half an orbit. Imagine also that you are pointing normally to your orbit. Thus you are pointing 90 degrees away from Kerbol at all points in your orbit. In a quarter year, you should be still be pointing normal to your orbit, but since Kerbin rotated 90 degrees around Kerbol, you now point directly away from Kerbol. A quarter year later, you'll be pointing 90 degrees away from Kerbol again, and after a total of 270 degrees, you'll face Kerbol for a while. At all times, you should still be facing normal to your orbit, even though the navball swirls around the entire time.
-
Short answer: Yes. Returning is pretty much the reverse of going. (This is because gravity is a conservative force.) Takes 580 to land. Takes 580 to go back to orbit. (Excluding user error and safety issues.) So think about what you are reversing. The first 310 m/s is circularization at the Mun from a Kerbin to Mun transfer orbit. Thus reversing the 310 just puts you back on a LKO-Mun transfer orbit. Imagine doing the capture burn at the Mun, turning around, and immediately burning 310 m/s in the opposite direction. You would be back on the orbit that brought you to the Mun. So burning 310 from LMO does not put you in a LKO, but it can get you back close to Kerbin on a Mun-to-Kerbin transfer orbit. Using Kerbin's atmosphere to slow you down, you can erase most or all of the 860 to turn a Mun-to-Kerbin transfer orbit into a LKO orbit, and most or all of the launch cost as well. This is because friction is not a conservative force. If you didn't want to aerobrake, it would cost 860 m/s to get back into a LKO orbit from your transfer orbit.
-
Oberth effect and propulsive efficiency of rocket engines
Yasmy replied to Arkalius's topic in Science & Spaceflight
Incorrect, Ralathon. The Oberth effect is merely the consequence of power equals force times velocity, P = Fv. Any mechanics where a force is applied independent of v automatically includes the Oberth effect. In fact, eta_p = (F v) / (F v + 1/2 (F/c) (v^2-c^2)), which follows directly from the Oberth effect. - - - Updated - - - This term is just the mechanical (kinetic) part. Initially, the rocket kinetic energy, excluding the soon to be exhaust propellant is 1/2 m v^2 Initially, the rocket propellant (soon to be exhaust) kinetic energy is KE_p = 1/2 dm v^2 Thus the total initial KE is 1/2 (m+dm) v^2. Finally, the rocket kinetic energy is KE_r = 1/2 m (v+dv)^2 Finally, exhaust kinetic energy is KE_e = 1/2 dm (v-c)^2. By conservation of momentum, (m + dm) v = m (v+dv) + dm (v-c), so m dv = dm c. eta_p = percentage of "usable" propellant kinetic energy gained by the rocket eta_p = (KE gained by rocket) / (kinetic energy gained by rocket + kinetic energy remaining in fuel) KE gained by rocket = 1/2 m (v+dv)^2 - 1/2 m v^2 ~= m dv v = dm c v. eta_p = (dm c v) / (dm c v + 1/2 dm (v-c)^2) = (c v) / (c v + 1/2 v^2 - c v + 1/2 c^2) = (2v/c) / ((v/c)^2 + 1) - - - Updated - - - Now let's go back to your last two examples: Case 1: v = 100 m/s, c = 100 m/s. eta_p = 2/(1 + 1) = 1 Case 2: v = 200 m/s, c = 100 m/s. eta_p = 4/(1 + 4) = 0.8 While it is true that in case 2 the propellant loses more kinetic energy than in case 1, the rocket gains even more kinetic energy. Compare the final propellant kinetic energy (1/2 dm (v-c)^2) to the final rocket kinetic energy gain (dm c v): The ratio is (v-c)^2 / (2 c v) Case 1: (100 - 100)^2 / (200) = 0 Case 2: (200 - 100)^2 / (400) = 1/4 In Case 1, the exhaust takes none of the mechanical energy of the propellant. In Case 2, the exhaust takes one quarter as much of the mechanical energy of the propellant as the rocket gets, or 1/5 of the initial propellant KE. eta_p is not the efficiency of kinetic energy gain (which is the Oberth effect: KE gained by rocket = dm c v, i.e., proportional to v.) It is the efficiency of using up the propellant's kinetic energy. (And eta = eta_p * eta_c is the efficiency of using up all of the propellant energy, where eta_c describes the efficiency of combustion and conversion into thrust.) Finally, eta_p is capped because it is impossible for the propellant to lose more kinetic energy than it has. Kinetic energy can not go negative. eta = eta_p * eta_c is capped at 1 by energy conservation, and in practice capped to something less than 1 by thermodynamics. -
Precision Burns - Before the Node, After the Node?
Yasmy replied to Bosun's topic in KSP1 Gameplay Questions and Tutorials
Let's consider splitting the delta-v 50/50 around the maneuver node instead of splitting the burn duration 50/50 around the maneuver node. Question: Given a burn of dV which takes time T, how long (t) does it take to burn dV/2? Let the burn consume total mass mf at a constant rate dm/dt = mf/T. Note that dV is not your total rocket dV and mf is not your total fuel mass, but just the quantities used in this burn. Full burn: dV = Isp * g0 * ln(m / (m - mf)) = Isp * g0 * ln(m / (m - dm/dt T)) Half burn: 1/2 dV = Isp * g0 * ln(m / (m - dm/dt t)) Solve for t, using the identity a*ln( = ln(b^a): t = m/(dm/dt) (1 - sqrt(1 - dm/dt T)) = T (m/mf) (1 - sqrt(1 - mf/m)) Now approximate this for mf << m: t = T/2 + mf/m T/8 + higher order corrections, all strictly positive By inverting the rocket equation, mf/m = 1 - exp(-dV/Isp/g0): t ≈ T/2 + (1 - exp(-dV/Isp/g0)) T/8 Starting your burn at time t before the maneuver node splits the delta-v 50/50 around the maneuver node. I won't say which is better (yet). I'm just doing the math in case anyone wants to try another option. -
Precision Burns - Before the Node, After the Node?
Yasmy replied to Bosun's topic in KSP1 Gameplay Questions and Tutorials
There are two errors here, which can become significant depending on how much of your total mass you use in the maneuver: 1) If you are using a non-trivial amount of fuel, and not adjusting your thrust to account for decreased mass, your acceleration is not constant. 2) If your acceleration is not constant, your average speed is not the average of initial and final speed. (It is the time integral of your speed, divided the by the final minus initial time.) Thus generally speaking, if you split the burn half way in time, you are spending more delta-v after the node than before the node. If your total mass change is small compared to your total mass, the effect can be ignored. -
Need help attaching something
Yasmy replied to KBMODIGITY's topic in KSP1 Gameplay Questions and Tutorials
I often do the following: Decoupler -> girder -> girder rotated 90 degrees so the free node points down -> stack separator -> whatever. -
Glad it appears to be working. As a simple test, try putting a vessel at altitude 600000 m, and behind the ground station by 60 degrees longitude. This makes a 30-60-right triangle, and the angle reported should be 90 degrees. I.e., the satellite should be on the horizon. Then wait until the satellite is behind the ground station by 90 degrees latitude. It should have dropped below the horizon. This makes a 1-2-sqrt(5) triangle, and the angle reported should be (180-asin(2/sqrt(5)) = 116.6 degrees. It's always good to check your code with simple test cases you can do by hand.
-
Take two vectors, v and w. Let v = |v| be the magnitude of v: v = sqrt(vx2 + vy2 + vz2). The magnitude of the cross product is: |v x w| = v w sin(θ), where θ is the angle between v and w. First break v and w into cartesian from spherical coordinates. Calculate: vx = v cos(lat) cos(lon) vy = v cos(lat) sin(lon) vz = v sin(lat) Same for w, but use the latitude and longitude to w. For a point on the surface of Kerbin, for example, v = 600000 m + altitude of the ground above sea level. For a point above a planet, w = (radius of planet) + altitude. Now I'm going to assume that instead of angle θ, the angle between v and w, you want the angle between the zenith (directly overhead) of your ground location and whatever you have in orbit. I For that we need the vector pointing from the ground to the thing in orbit: u = w - v. So calculate: ux = wx - vx, uy = wy - vy, uz = wz - vz, and u = sqrt(ux2 + uy2 + uz2) So the angle Õ between the zenith and the orbiter is obtained from the cross product of v and u: sin(Õ) = |v x u| / (v u). All that is missing how to calculate the magnitude of the cross product: |v x u| = sqrt( (vy uz - vz uy)2 + (vz ux - vx uz)2 + (vx uy - vy ux)2 ) Now just take the inverse sine: Õ = asin(|v x u| / (v u)). Questions?
-
best way to go from equatorial to polar orbit
Yasmy replied to seyss's topic in KSP1 Gameplay Questions and Tutorials
Suppose your initial speed is v. Let's make an inclination change of angle θ only by burning locally. For a pure inclination change, your final speed equals your initial speed, but the velocity vectors differ in direction by angle θ. 1) First, a truly horrible method: Burn dv = v retrograde, so that your speed is zero. Then burn dv = v in the inclined plane. The total cost is 2v, independent of θ. Horrible. Consider this the worst case scenario. 2) The best local, single-burn method is a burn along the hypotenuse of the triangle formed by the initial prograde velocity vector and the final inclined plane velocity vector. The triangle has two sides of length v at angle θ to each other. Use the law of cosines to find the length of the hypotenuse: c2 = a2 + b2 - 2 a b cos(θ). dv2 = 2 v2 - 2 v2 cos(θ) = 4 v2 ((1-cos(θ))/2) = 4 v2 sin2(θ/2). Thus dv = 2 v sin(θ/2). For θ = 90, sin(45) = sqrt(2)/2, and thus dv = sqrt(2) v. 3) Finally, the method of following the normal: Instead of burning along the hypotenuse of a triangle, you are sweeping out the arc of angle θ of a circle of radius v. Thus the arc length dv is equal to v θ. Remember to use radians for arc lengths instead of degrees. 90 degrees = pi/2 radians. So dv = pi/2 v. This method is always costlier than method 2. If this is following the arc of a circle, method 2 is the straight line between two points on a circle. Derivation of this one is a bit more involved. Solve 2 coupled differential equations: ax = d/dt vx = - c vy ay = d/dt vy = c vx The vector (-y,x) is normal to the vector (x,y). So the differential equations together describe thrust normal to the current velocity. The constant c (assuming constant thrust -- not a great assumption if the burn reduces your mass significantly and you don't adjust your throttle) is your angular velocity. A solution is: vx = v cos(c t), vy = v sin(c t). The total burn delta-v is obtained by integrating the acceleration a = sqrt(ax2 + ay2) = c*v from time t = 0 until time T, the time to get to angle θ. The integral of the constant c*v from 0 to T is simply dv = c*v*T. Now looking back at the solution, at what time T is the velocity inclined by angle θ? Ans: When c*T = θ, because the velocity points along angle θ when vx = v cos(θ) and vy = v sin(θ). Thus dv = c*v*T = v θ. (What is the angular velocity c anyway? F = m a = thrust, so c = a/v = TWR*g0/v.) -
ellipse = shape of a closed orbit egg-shaped = shape of an egg. not the shape of an orbit oval = not mathematically well defined. means egg-like. not the shape of an orbit KSP = Kerbal Space Program, a game filled with little green astronauts of questionable courage and intelligence. KSC = Kerbal Space Center, the place on Kerbin where Kerbals build and launch planes, rockets and other dangerous vehicles.
-
How Would you get this Kerbin Orbit?
Yasmy replied to Roady1976's topic in KSP1 Gameplay Questions and Tutorials
I prefer to do everything Kerbaled if possible, but if you are having delta-v issues, why take a command pod for an unmanned satellite contract? Use a probe body. If your burn times are too long, you may have design problems. But you should definitely launch into an inclined orbit. Try to launch into an orbit within 5 degrees inclination of the target orbit. You have to wait until KSC is near the ascending or descending node, and launch at the correct angle (adjusted slightly for Kerbin's rotational speed). You should have enough delta-v with your current vessel. Edit: Multiply ninjaed! -
best way to go from equatorial to polar orbit
Yasmy replied to seyss's topic in KSP1 Gameplay Questions and Tutorials
For planets or moons with atmospheres, the method of raising Ap to just below the SOI boundary, correcting the inclination, and returning to low orbit can be made even cheaper by the ability to aerobrake, if you don't have fixed solar panels or other breakables. But if you don't want to do a multi-step process, burning normal is not the best you can do. Burning normal is fine for very small inclination changes, but for larger inclination changes, burn along the hypotenuse from your old velocity vector to your intended vector. For example, to go from a circular equatorial orbit to a circular polar orbit at the same radius, burn in the direction half way between retrograde and normal. The cost is dv = sqrt(2) v = 1.41 v. If instead you burn normally, following normal as it rotates from polar to equatorial, the cost is dv = pi/2 v = 1.57 v. -
Nice cybersol. And thanks for sending me looking for Meithan's 1.0.2 optimal engine charts. Cool. I was assuming n_engines = 1, basically ignoring Slashy's requirement for a minimum TWR. Though of course, assuming you start with single stage rocket of sufficient but not outrageous TWR, if you replace it with a multi-stage rocket of lower total mass, then the original number of engines per stage must automatically meet the same minimum TWR requirements. I would be careful about inferring too much from my one plot. Other setups may produce something very different. Additionally, for the case shown, the mass optimal fuel split is more like 56%/44%. The final stage mass optimal split is a = 50.6% of the fuel of the single stage rocket, but the initial stage has only about b = 39%. a + b must be < 1 to make up for the added engine and decoupler. The plot also shows the per-stage dvs are quite different. They are the dotted lines. At a = 51%, dv1 = 1.02 * v_e, dv2 = 0.35 * v_e.
-
payload: Mk1 command pod drained of monoprop, tank: 5 FL-T200, engine: LV-909, decoupler: TR-18A p = 0.8, e = 0.5, f = 5 * 1.125, t = f/9, d = 0.05 The plot shows several quantities vs the final stage to single stage fuel ratio, a. Apologies for not making this more color vision deficiency friendly. The middle solid curve (yellow) is the ratio of the masses of a two stage rocket to a single stage rocket. When r < 1, the two stage rocket is less massive. Two stages is favorable for approximately a > 0.14 (by eyeball). I eyeballed the plot and picked a = 0.4 and a = 0.8 as values which had nice round numbers of fuel tanks for both a and b (the lower solid (blue) line). So a = 0.4, b = 0.5 is one rocket, and a slightly worse rocket is a = 0.8, b = 0.2, roughly. b = 0.5 means 2.5 FL-T200 tanks, since the single stage rocket had 5. I've posted a screenshot of the single stage rocket, and the two two-stage rocket. Frankly, I didn't expect to get a solution so easily for the LV-909. First attempt worked. N.B.: My eyeballing was only so-so. b(0.4) = 0.497 (spot on). b(0.8) = 0.15, a bit less than my guess of 0.2.
-
Pretty trivial change, cybersol. Just replace 2e with e in the initial stage delta v equation.
-
Let's do some math. This may not exactly be GoSlash27's problem, but it's well defined and tractable. Assumptions: 1) one engine type with a constant fixed Isp 2) one fuel tank type of fixed full to dry ratio, but of arbitrary size 3) the final stage consists of payload, a fuel tank and an engine 4) a non-final state consists of a fuel tank and engine and a decoupler 5) we start with a known single stage rocket, and wish to know it can be replaced with a two stage rocket with the same delta-v, but total lower mass. Variables for the single stage rocket: p = payload mass t = dry tank mass f = fuel mass e = engine mass v = engine exhaust velocity = Isp * g0 dv = v ln((p+e+t+f)/(p+e+t)) Now for the two stage rocket, define a and b as variables which scale the single stage rocket fuel tank: a*f = final stage fuel b*f = initial stage fuel d = decoupler mass dv = v ln((p+e+a*(t+f))/(p+e+a*t)) + v ln((p+2*e+d+(a+*(t+f))/(p+2*e+d+(a+*t+a*f)) Require the two rockets to have the same dv. Fun with logs: ln(x) = ln(y) + ln(z) = ln(y*z) x = y*z Now do a bit of algebra to solve for b, the scale of the initial stage fuel tank, given scale a: (p+e+t+f)/(p+e+t) = (p+e+a*(t+f))/(p+e+a*t)) * ((p+2*e+d+(a+*(t+f))/(p+2*e+d+(a+*t+a*f)) Solve for b (using a computer algebra system): b = (1-a)*(p+e)*(p+2*e+d+a*(t+f)) / ((p+e)*(p+e+a*f) + a*(2*p+2*e+f)*t + a*t^2) What we care about is the ratio of the initial mass of two stage rocket to the single stage rocket: r = (p+2*e+d+(a+*(t+f)) / (p+e+t+f) Substitute b, and do a pile of algebra: r = (p+e+a*t)*(p+2e+d+a*(t+f)) / ((p+e)*(p+e+a*f)+a*(2p+2e+f)+a*t^2) Plots and thoughts will come later, but here's what you do with this equation: Pick values of p, e, t, f and d. Plot r(a) from a = 0 to 1. If r is ever less than 1, you have a better two stage rocket. Edit: Of course, if we have r(a), we can minimize r(a) to find the mass-optimal final stage fuel scale: a_opt = (-(e+p)^2*t*(f+t)+((e+p)*t*(f+t)*(2*e+f+e*f+2*p+f*p-(e+p)*t+t^2)*(e^2*(4+f-t)+d*(f+e*(2+f)+2*p+f*p+t^2)+p*(f+2*p-p*t+t^2)+e*(6*p+f*(2+p)+2*t*(-p+t))))^(1/2))/(t*(f+t)*(f+e*(2+f)+2*p+f*p+t^2)) Ugly monstrosity, but it should tell you the ratio of fuel tanks in the upper stage of a two-stage rocket to fuel tanks in a single stage rocket. If the ratio is ever less than zero or greater than 1, single stage is best.
-
So what exactly is the benefit of having Lagrangian spacecraft?
Yasmy replied to Tex's topic in Science & Spaceflight
I'm sure all of Earth's (and other planet's) Lagrange points will be used heavily some day, though it will probably be quite a while before we use Earth's L3. Multiple spacecraft (ISEE-3, WIND, SOHO, ACE and others) have used L1 as a local space and solar observation point. L1 is outside of Earth's magnetosphere and bow shock, so it is a good place to monitor the solar wind upstream of and unperturbed by Earth. L1 has a continuous, unobstructed view of the sun. If you are not familiar with any of these missions, check out SOHO. It has produced some of the most amazing movies of the active, dynamic solar surface, corona and even subsurface, featuring flares, sun spots, coronal mass ejections (eruptions which dump huge amounts of plasma into space), flux tubes (loops of magnetic fields jutting from the surface with high energy particles zipping along them), and even deep sun convection cells and whole-sun vibrations (helioseismology). -
Ascend profile - wacky or working idea?
Yasmy replied to heng's topic in KSP1 Gameplay Questions and Tutorials
Same amount of fuel spent = same dV. The Oberth effect says that the faster you are moving along the direction of the burn, the more specific orbital energy you gain or lose from the same dV. initial specific orbital energy: 1/2 v^2 - 1/2 G M / r final specific orbital energy: 1/2 (v + dv)^2 - 1/2 G M/r dE = final - initial = 1/2 (v + dv)^2 - 1/2 v^2 = v dv + 1/2 dv^2 This is the Oberth effect: dE/dv = v + dv It's nothing more than the statement that kinetic energy is quadratic in velocity, and therefore changes, dE, are linear in dv. N.B: Specific orbital energy is total energy divided by mass. Since your mass has nothing to do with the shape of your orbit, it is easier to just remove it from the equation. Literally. And of course, in the time it took me to write this post, I've been multiply ninjaed! -
Thank you, but that is not a good solution. I'll tell you why: 1) The mouse is already in your hand. Reaching for numpad +/- is no easier than looking at where the mouse pointer is before zooming to avoid accidentally mousing over the maneuver node handles. 2) There is a great joy in scrollwheel zooming. Spinning that wheel in or out as far and fast as possible, or zooming slowly. The scrollwheel responds to both direction and speed, while numpad +/- only responds to direction. Pressing numpad + harder won't make you zoom faster. Really, the game should detect which scrollwheel function is currently active, and not transition from one to the other mid-zoom. It can happen in either direction: Scrolling on a radial +/- handle rotates the node such that your mouse may fall off the handle and start zooming the camera. I consider it a misfeature. (It's not a bug, but it's not useful or intended behavior.)
-
Here's the problem: 1) You set up a perfect maneuver node for a perfect orbital transfer or whatever. 2) You zoom the map to look at something, using the mouse scrollwheel, and 3) zooming causes one of the handles on the manuever node to move under your mouse pointer. Suddenly, instead of zooming the camera, the scrollwheel is now changing your maneuver. I don't really want to have to pay attention to where my pointer is just to zoom in and out. Is there a way to disable scrollwheel maneuver node editing? I don't see anything in settings.cfg. Thanks