Meithan

[quote name='EdFred']That new dV map is most helpful. I was testing last night however to see what it took for 80km LKO and I was able to get it done for between 3000 and 3100 dV so some of those numbers may be a bit conservative.[/QUOTE] If you optimize for cost efficiency (funds per tonne of payload) and not for lowest-Δv-to-orbit, I've found that 3400-3500 m/s is about right for the typical ascent.

Yep, as others have said, the new Δv-to-orbit values are due to the new aerodynamic model. The tl;dr version of it is that KSP now attempts to correctly estimate how streamlined a body is. You see, the aerodynamic drag force experienced by most flying objects is [url=https://en.wikipedia.org/wiki/Drag_(physics)#Drag_at_high_velocity]proportional to its "cross-sectional area"[/url] (the "frontal area" it presents to the airflow). Before 1.0, this area was not properly calculated (it depends on the geometry and orientation of the craft), but simply computed directly from the [i]mass[/i] of the ship: KSP assumed that the cross-sectional area was 8 m^2 per tonne of mass, regardless of shape and orientation. I guess that the rationale behind that choice was that, very roughly, in general heavier ships are "bigger" and thus have a larger cross-sectional area. But this assumption fails to acknowledge the fact that we can build things to be streamlined: simply make rockets tall and slim and you can make them quite heavy without increasing the cross-sectional area. Before, your small 20 tonnes rocket (at launch) had an effective cross-sectional area of 160 m^2: that's as if it had a frontal diameter of 14.3 meters! Anything heavier than a few tonnes was essentially considered a pancake flying face-on for drag purposes. Hence the soup-o-sphere. Now KSP does an honest try to correctly calculate the cross-sectional area of your ship, and thus streamlined shapes (like most of our rockets) now fly with considerably less drag.

Did you guys see this? [quote]United Launch Alliance (ULA) will begin adding a cubesat dispenser on to its Atlas V missions from 2017, allowing for the launch of up to 24 cubesats alongside its primary mission payload[/quote] [url=http://www.nasaspaceflight.com/2015/11/free-cubesat-rideshares-offered-ula-atlas-v-launches/]Free CubeSat rideshares offered by ULA for Atlas V launches[/url]

Hi, gfrodo. Thanks for your interest! I haven't had much time to work on the app. The features you mention sound very nice. Can't wait to see them for myself. Engine curves are definitely something I've been thinking of doing. I didn't know the bit about the Aerospike tangents being different (we should write helper programs to parse this stuff directly from the game's cfg files). And the Bootstrap issue is something I am aware of but never fixed; I have another website (unrelated to KSP) with the same problem, so it'll be nice to fix it. I definitely think we should collaborate on this. The best thing to do is for me to upload the project to github, so we can work from there. I'll try to do it during the weekend. I'll take the opportunity to do a bit of housekeeping on the code (for instance, separating the code from the html and organizing it into several source files). I'll let you know when it's up.

And this one does 18t to 80 km orbit for 24k funds, without stage recovery: First stage is three Kickbacks, second (serial) stage is one Skipper and an orange tank. Control authority during first stage burn provided by reaction wheel hidden inside fairing (below payload decoupler), with a probe core and two batteries to deorbit the spent upper stage: I'm not claiming any record here (we need a challenge for that! -- Norcalplanner: I'd be willing to review entries or even host the challenge, but I've never done so and I'd need help with the rules), that was just the end result of a couple hours spent redesigning my launchers to be Cheap and Cheerful. I also tried two liquid stages with SRBs and one big central liquid stage with SRBs, but they were more expensive.

Agreed. As a guy who is currently running entirely on recoverable single-stage rockets, I'll attest to how much of a pain it can become. I've had quite a lot of practice now, and I can land close to KSC (usually some kilometers west of KSC) with little effort, and landing legs mean I don't need powered descent. Even so, it's very time-consuming. I think the reentry and landing take more time than the launch itself, so I'm more than doubling the times to launch stuff to orbit. I'm planning a 12-ship Duna flotilla for my next launch window and I'm definitely not looking forward to recovering all those lifters. Honestly, I'm hoping for you guys to convince me to go disposable two-stage again. I'll cheerfully spend more per tonne to orbit just to get rid of the chore of returning the rockets. And staging a stack is cool - I miss it. Hasn't there been a "classic-rocket lowest cost per tonne" challenge in 1.0? I'd be surprised, but a quick forum search didn't find any. RIC is still hosting a Payload Fraction Challenge, but those designs are not meant to be Cheap and Cheerful (and that's the new official name of my preferred design philosophy ).

Yup, this is something that hasn't been mentioned (neither here nor in that other Delta-v vs. TWR discussion thread): recoverable launchers can substantially change the picture, I think. All my launchers are recoverable single-stage with expendable SRBs designs. For instance, my Titan Heavy launcher can put 36 tonnes to ~80 km orbit. The central stage returns to Kerbin and lands on parachutes (it has landing legs to protect the engine on touchdown; it must land on solid ground, though). Recovery close to KSC gives back >95% of the cost of the stage, which has the expensive liquid engine, for <32k total expenditure per launch, yielding less than 900 funds per tonne of payload. And frankly I haven't spent much time optimizing it; I'm sure it can be made cheaper. Anyway, I'll let Norcalplanner get to the previous topics before going into this.

Thanks! Yup, I use the reaction wheel for rotation, and the RCS for translation only. I usually go with 8 linear ports (adding two back-facing ports), which comes at nearly the same cost and weight as 4 RCS blocks. I find that shutting down the main engine during docking is a good idea (I did have some accidents with that when I was learning to dock). If your ship has a reaction wheel (and pretty much all my ships do), there's no point in spending your RCS fuel for rotation. Before I switched to linear ports, I used to alternate switching RCS on and off during dockings to save monoprop on rotations. With the linear ports + reaction wheel, I leave RCS on all the time during docking. It's entirely possible, but IMO it's just not worth the hassle. I think that even with Cheap and Cheerful, there should be cases when a little extra cost/mass/complexity is worth it if it makes life considerably easier. Full 3-axis control during docking is one of such things for me.

Excellent guide, Norcal! I couldn't but nod and nod as I read along. It seems I've converged to a very similar set of rules of thumb, which should be an indication of their general validity. I just have one question regarding RCS: what's your take on the linear ports? They're cheaper than the RCS blocks, even if you need 6 of them to get 3-axis control. Part count is a con, I guess? There's also having to place the front/back-facing ports, which is not always easy (I usually place two in the front/back directions; 8 linear ports cost slightly less than 4 blocks). They have twice the thrust, though, so they provide the same overall thrust.

Very nice SSTO spaceplane, Rune, color me impressed. Definitely surpasses my design ability (I know because I spent three hours last night trying to design an orange-tank spaceplane and repeatedly failed to get it anywhere near orbit). OK so the rocket vs. spaceplane margins are not as bad as I first suggested, but they're still there. Using MechJeb's landing predictions, I usually land my recoverable rocket stages within 2 couple km of the pad, with >95% recovery value. And yeah there's the volume issue, too. I've launched monstrosities without a hitch: as long as they fit in the fairing (and those 3.75 m base fairings are huge) and I can strap some struts to it, there's no problem.

While I love SSTOs, I just find they take too long to get to orbit. They're very low-cost-to-orbit, granted, but an SSTO launch takes 5x as long as a standard rocket ascent, and the launch profile is more complicated. And regarding cost, I have a family of recoverable-single-stage-plus-SRBs rockets that don't fare too bad price-wise compared to SSTOs. For instance, my Titan Heavy launch vehicle (the central stage lands on parachutes) can put 36 tonnes in LKO (75 km orbit) for 32k funds (less than 1000 funds per tonne). An SSTO with that capacity will certainly be cheaper, but not by a huge deal (btw: do you have an SSTO capable of that payload? how much does a launch cost? All I've built is a light SSTO with a ~2 tonnes payload capacity).

I agree with you Rune: in practice I don't do the calculations either, I just throw a maneuver node and play with it too. As you said, what's important is understanding the fundamental principles behind it (the orbital mechanics). For rendezvous, I actually don't use a lower or higher phasing orbit. What I do is first match my target's orbit (close to zero relative inclination and close-ish Ap/Pe), trying to get as close to my target but behind it. Then, I do an elliptical phasing orbit: I raise my Ap a bit so that my orbital period increases. By toying with the maneuver node I can get the extra period to be exactly the time I'm lagging behind the target. The result is a very close intercept on the next orbit once I get back to Pe. The relative speed will also be quite low (a few 10's of m/s usually), so the transfer is close to optimal.

The question makes total sense. If you're willing to spend more delta-v than a Hohmann transfer, you can get a faster intercept by doing a one-tangent burn transfer. The basic idea is that the transfer orbit is a higher-energy orbit (which can be elliptical or even hyperbolic) that crosses your target's orbit instead of touching it tangentially (as the Hohmann transfer does): At intercept, you'll be moving considerably faster relative to your target (and, more importantly, along a different direction), so the speed matching burn will be costly. Robert Braeunig's excellent website (from which I stole the above picture) has the mathematical formulae needed for this kind of transfer. In particular, look at the Orbit Maneuvers section of his Orbital Mechanics page. Due to the way these expressions are written, you'd have to first find the size of the transfer orbit (i.e. its semimajor axis, atx in Robert's notation) by trial and error, repeatedly choosing a value of atx and computing the corresponding time of flight (equation 4.71) until you get the desired transfer time. Then, you can use the other equations to compute the delta-v of both transfer burns as well as the angular position of the intercept (the "true anomaly at second burn"). The phase angle for the start of the transfer can then be deduced from this quantity and the time of flight (in a way similar to what we did for the Hohmann transfer).

It requires solving the Lambert problem mentioned above. In general, unless something is in a circular orbit its angular speed is not constant and figuring out its position along its orbit as a function of time ("where will it be at some specific time t?") is complicated. Circular orbits are the easy case. Just so you get an idea of how complicated it gets, here's one approach to solving Lambert's problem, with an Earth-Venus transfer as worked example: Lambert’s Problem - Prof. Jeffrey S. Parker - UC Boulder

Quite right. Lambert's Problem is the more general version of the rendezvous problem: if I'm at arbitrary position r1 (in 3D) at some time t1, what trajectory gets me to some other position r2 exactly at time t2?

Ah, eccentricity (of either orbit) makes things considerably more complicated, since, for instance, angular speed is no longer constant (in an elliptical orbit, you move slower near apoapsis than near periapsis). The overall logic would still be the same, though: you do a Hohmann transfer to "touch" the target orbit at some point, and you time the start of the transfer so that the target is there when you reach apoapsis of your transfer half-orbit. Btw, I just changed all the equations in the original post for nicely typeset ones (thanks to codecogs!), so everything is easier to read now. Whew. This forum really needs LaTeX support.

The time the Hohmann transfer takes (going from point A to point C). I should have written it with a subscript H, like this: tH, but I was a bit lazy . You can use any unit of length you want, as long as you're consistent. If you use metres for the radii r1 and r2, then you also need to write all other quantities that involve length in metres. For instance, you should write μ in m3/s2. Yup, sorry for not clarifying. When you compute angle stuff, you usually get the answers in radians. To convert radians to degrees, you multiply by 180/À.

It's the same problem as a transfer to another planet; it's all just a matter of phase angles. The math is not difficult if the orbits are circular, coplanar and prograde. Let's also assume that you're planning to intercept the target using a Hohmann transfer - which is a good idea if you're interested in miniziming delta-v. Here's is a diagram of the maneuver (which is simply a Hohmann transfer): You start at point A, your target is somewhere along its orbit, let's say at point B, and since you're using a Hohmann transfer your intercept point is at C. Your initial orbit has radius r1 = (6378.1 + 500) km = 6878.1 km, while the target's has radius r2 = (6378.1 + 700) km = 7078.1 km. The time required by the transfer is simply that of the standard Hohmann transfer: where μ is the gravitational parameter of the body you're orbiting. For Earth, this is μ = 3.986e5 km3/s2 (notice I'm using km for all distances; one must be careful that the units match), so the transfer time is: We also know that the transfer completes half an ellipse, which means that when you reach the target orbit you will have traveled 180° around, and you'll be on the opposite side of the primary. Now, the crucial thing for the rendezvous to work is to start the transfer at the right time so that when you reach point C the target is also there. We know that in time tH you travel 180°, but how much (in terms of angle) does the target travel? Let's call this angle θ. Since the target's orbit is circular, this is easy to compute: where Étarget is the angular speed of the target, which for any circular orbit is given by , with r the radius of the orbit. Substituting and simplifying: Computing this, we get: The correct phase angle for the rendezvous, , is then the difference between the angle you travel, 180°, and the angle the target travels: In this case, we get: This means that the target must be 3.8 degrees ahead of you when you start the transfer if you are to intercept it at C. Finally, the delta-v requirement is simply that of the Hohmann transfer: for the initial burn at A, and for the circularization burn at C, which in this case is the burn to match speeds with the target. The total delta-v is thus about 100.8 m/s. If initially the target is not +3.8 degrees ahead of you, then you'll have to wait for the phase angle between you two to reach that value. If you're at 4 o'clock and the target is at 12 o'clock (and moving counter-clockwise), that means your current phase angle is +120° (target 120° ahead). Since you're in a lower orbit, you're moving faster and are catching up, and thus the phase angle is reducing with time. If you wait enough, it'll eventually come down to +3.8°, at which time you should start the transfer. We can figure out how long that will take by computing the phase angle's rate of change, which is simply the difference between your target's angular speed and yours: Thus, for the phase angle to reduce from +120° to +3.8°, you'll need to wait about 12.1 hours (which is about 7.5 orbits).

Hey Teilnehmer. What I can do is have the code compute solutions for the Dawn + fuel cells separately. I'll look into it when I get some time. I'm definitely interested in seeing the results.

La parte de escanear en busca de mineral no es complicada: simplemente pon el escáner M700 en un satélite y colócalo en órbita polar. No es más difícil (hasta diría que es más fácil) que los contratos genéricos de lanzamiento de satélites. Prueba haciéndolo en Kerbin primero. Cualquier órbita baja es suficiente (menos de 1500 km de altitud en este caso). Para lanzar en órbita polar, simplemente dirige tu cohete hacia el norte o hacia el sur en vez de hacia el este; el resto del proceso de lanzamiento es idéntico (necesitarás sólo un poco más de delta-v). Se pone un poco más complicado si ya quieres extraer mineral y procesarlo o regresarlo a Kerbin desde otro sitio. Los contratos de "extraer X cantidad de mineral en Mun/Minmus y llevarlo a Kerbin" sí son algo complicados y requieren bastante planeación y algo de habilidad/experiencia.

Es correcto lo que dice fitiales. Sólo agregaría que para que funcione el M700 Survey Scanner además de la altitud correcta la sonda debe estar en órbita polar. No sé cuál sea la tolerancia pero debe ser relativamente amplia; prueba inclinaciones >80°.

Pics of the engines added to todo list (I suppose Squad is OK with it?). As for the payload fraction limit, do you mean graying out (or something) solutions with fractions below the limit? Or discarding solutions with fractions below the limit?

There are two mods I can't live without: 1) Kerbal Engineer Redux or MechJeb -- mainly for the delta-v readouts (in the VAB and in flight), but I also use many other info readouts (current TWR for ascents, radar altimeter for landings, accurate node burn times, detailed orbit information, rendezvous data, etc.). 2) Kerbal Alarm Clock -- once you start having several missions in flight (because going to Minmus takes 8 days, and you can do other stuff in that time), this tool is an absolute necessity. It lets you set alarms for distinct ship events (maneuvers, SOI changes, periapsis/apoapsis, etc.) or even transfer windows to make sure that you never miss one. Not necessary but it will make your life much easier: 3) Docking Port Alignment Indicator -- once you get the gist of it, this tool will let you perform flawless, effortless dockings. What I like about it is that after a while of using it you won't even need it anymore.

Ah, I see. It's a decent atmospheric engine. The only problem I see is that it's radially attached, and for those conditions the efficient solution requires only one Thud, which is problematic .

Thanks John! That's the idea . Under what conditions are you getting the Thud as optimal? I haven't seen it often. Being able to add custom engines is a good suggestion. The programmatic part is easy; the not-so-trivial part is building the UI. Added to the "list of planned features". Also, I do have a small Python script I use to read the part cfg files and create the relevant JavaScript code, which I copy/paste into the app. But what would be cool is being able to feed the cfg file to the app and have it automatically add the engine stats, right?