alterbaron

Preview of a new "expert mode" interface: http://alterbaron.github.io/ksp_aerocalc/expert.html This alternate interface (when done) will tell you your final aerobraking AP or, if the ship crashes into the surface, some other stats like landing phase angle. I also want to add the ability to generate some simple plots (g-force comes to mind).

From a quick read-through, your derivations look good. Just a couple of comments: In your formula for eccentricity, the specific angular momentum H0 should be squared. Edit: I see you did this later in the document, so this first instance is just a typo. Otherwise, the only thing I'd say is to be careful when taking sin(phi) = sqrt(1-cos^2(phi) ). Depending on phi you might need the negative root.

I tried running this simulation. However, the initial trajectory is suborbital. I've verified this with hand calculations as well. Here's the initial orbital parameters I get using your x,y,vx,vy values: => ep: -2012142.246324 => ec: 0.371383 => h: -1634555621.700000 => a: 877572.151386 => rpe: 551657.201923 => rap: 1203487.100848 SS1 (initial suborbital) (Note distances relative to Kerbin center). I get the same value of specific orbital energy as you do. However, the value for the specific angular momentum h in your previous post is incorrect. It looks to me that you calculated h by simply multiplying the magnitudes of the position and velocity vectors (I get your value of about -1.70e9 this way). This only works if the two vectors are perpendicular, which is not the case in this example. Rather, h = rx*vy-ry*vx, giving h=-1.63e9.

Thanks! Very interesting. Thanks for the info! That's a surprising amount of change. If you post your initial conditions, I can run it through my MATLAB scripts (the online calculator's a translation of these) to check for agreement. That's true, but you can get a pretty nice function to work with if you parameterize the problem well: Replacing velocity with specific orbital energy (easily calculated from in-game data) would allow such a formula to be initial-altitude independent. Might be something to consider adding, though I'm worried about making the calculator too complicated/daunting to newcomers. On that note, I've been thinking about adding some sort of "expert mode" with a bare-bones interface that takes your orbital data and spits out a bunch of encounter info, such as max gee forces, time in atmosphere, orbital energies, .etc. A full 3D simulation would fit this sort of tool well. Are you using the same value of Kp = 1.2230948554874 ? (I scraped this number from Mechjeb Source.) Also, are the discrepancies within the margin of error of your input? It's hard to make any conclusions without source code.

Excellent analysis Meithan! Aerobraking is a really fun problem . It's great to see others working on it (and it's good for verification of results as well). Couple questions about your simulation: Are you simulating the hard cutoff for atmosphere? Nvm, from initial post it looks like you are. What numerical integration scheme are you using? Time step? Ideas for further experimentation (no idea if these are any good or not): Can you find approximate equations for aerobraking periapsis for the different planets? Something that could be used with a pocket calculator would be really cool. Would be a function of altitude, velocity, .etc How precise can this be? Similar to above: predicting max gee force as a function of stuff you can compute using data in-game. Would be useful for mission planning.

Thanks! I just realized that I forgot to add a link to the charts for other atmospheric bodies. I've added it to the main post.

That's not a bad idea. Since the aerobraking code already exists, it's just a simple matter of throwing together an alternate interface. It could also give out some other fun/useful stats, like time in atmosphere, max g-force, and final orbit parameters like eccentricity.

Here's a simple way to calculate ln(x) to essentially as much precision as you want (or as much as the computer can handle): INPUTS: x: Number of which to take natural log. n: Number of iterations (controls accuracy of result) OUTPUTS: y=ln(x) sign = 1.0. if x < 1.0 { x = 1.0/x. sign = -1.0. }. a = x/(x-1.0). y = 1.0/a. i = 2. until i > n { y = y + 1.0/(i*(a^i)). i = i + 1. }. y = y*sign. Note that the code won't work when x=1. (ln(1) = 0). Setting n=100 gives you better than 10^-6 accuracy for all 1/10 < x < 10. Setting n=1000 gives you nearly 10^-6 accuracy for all 1/100 < x < 100. Should be more than good enough for use in the rocket equation.

The above plot doesn't include any centrifugal force due to the rotating frame of reference. I played around a bit with including fictitious forces in the computation, and arrived at a model that fits the data pretty well up to the 30km mark. In the force balance used to determine the terminal velocity, I included both the centrifugal force as well as the component of the coriolis force opposite to the direction of gravity. Then, I applied your thrust angle idea to the new terminal velocity equation: F_drag = sin(Thrust_angle) * (gravity + centrifugal_force + coriolis_force*cos(Velocity_angle)) This gave quite a nice fit: Also, I took a look at the thrust angle relative to the orbital velocity direction (prograde indicator on navball): Seems to suggest that above 20km (and with a craft with a high TWR), one should essentially start following the prograde indicator on the navball. This could be explained as maximizing the useful work done by the engine.

If you want trig functions, you could always use: sin(x) ~= 1-(1/2)x^2+(1/24)x^4-(1/720)x^6 cos(x) ~= x-(1/6)x^3+(1/120)x^5-(1/5040)x^7 These are quite accurate when x is between -pi and pi.

Welcome to Laythe:

Hm, looks like I used the wrong engine. The correct engine has more thrust and less mass. I took another look at the challenge thread, and re-adjusted my parameters to properly match the challenge craft. This time, it was able to orbit successfully, with fuel to spare! Craft parameters: Isp(1atm) = 320s Isp(vac) = 370s Tmax = 215kN Fully-fueled mass: 11.15 t Dry mass: 3.15 t Mass after circularization at 74km: 3.1659 t EDIT: Version with more collocation points added: http://imgur.com/a/NuHhi Model source code: https://gist.github.com/alterbaron/6407325 Needs to be tidied up a little, but I hope it's clear enough to follow.

Taking tavert's advice, I converted over to using horizontal and vertical thrust (rather than thrust and thrust angle). With a little tweaking, I've been able to coax some nice results out of PSOPT. I input a model of the SSTO from the launch efficiency challenge to put the program through it's paces. It was able to solve for a launch profile to orbit that challenging craft. However, it used 0.1 tons more fuel than the craft has available. Perhaps with more computation time this will improve? It's still a good result regardless. Here are the results: Pitch as a function of altitude: Thrust Angle Chart Thrust as a function of altitude (there's a bit of noise visible, might account for extra fuel consumption.): Thrust Magnitude Chart Velocity compared to terminal velocity: Low-Altitude Velocity (with Terminal Velocity for Comparison) Chart Final craft mass: 3.2066 tons (craft dry mass = 3.3 tons). There's still some improvement possible, and progress is being made! EDIT: I managed to get a much better result that eliminated the noise in the thrust function above. Interesting things to note (do these make sense?): Ship stays throttled down to maintain a velocity lower than terminal between 10-15km when it could have throttled up again. Ship throttles up past 15km, then throttles down significantly as it pitches towards the horizon. Continuous application of (light) thrust in the upper atmosphere. Final craft mass was 3.2148 tons, so still a little short on fuel. Still, a margin of <0.1 ton of fuel is pretty OK. Optimization took 12 minutes (18k solver iterations) using Legendre collocation method with 40 nodes. NLP tolerance 1e-6. I've tried local discretizations as well (through PSOPT). They run much more quickly and consistently return reasonable results. There's still some noise in the control output though, but they're worth investigating a bit more.

That's a great idea (and a simple change to make). Might be worth looking into, but might make the already hard to solve problem harder to solve.

Not wrong, but pretty impressive if you can pull that off. For two orbits that are already really close, it's quite possible to do the whole thing in IVA without any calculations (but it's a little more fuel intensive.) The math really helps, though, if your target vessel is more than 50km away at the point of closest approach. At these distances, you'll waste fuel like a madman if you just burn towards your target. Instead, a Hohmann transfer (at the heart of this method) is the way to go.