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.

Nice simulation. I'm actually quite surprised at how little that thrust oscillation affected the final result. Another update: I've been able to solve for an optimal ascent trajectory for a body without an atmosphere, which is kind of cool in its own right. Here's the results from a test ascent from the surface of Kerbin (with the atmosphere removed): Altitude wrt. Time Thrust wrt. Time Thrust Angle wrt. Altitude The target orbit was set to 400,000m altitude. The ship model used was the same as in the first test, but the engine Isp was set to 800s so it would have enough fuel to orbit. There's a lot of noise in the "thrust profile" function whenever the thrust is zero. This is because there's no preferred direction to point your ship when the thrust is zero. (Is there a way to eliminate this noise?) I've had partial success with ascent in the atmosphere. The program definitely figures out to do a gravity turn (beginning around 10km) and to do a burn at periapsis, but the output is still quite messy: Atmospheric Ascent Thrust Atmospheric Ascent Profile I'll play with the program and model some more to see if I can get a better result.

Alright, another quick update: I ran the vertical ascent solver on the same craft, but doubled the TWR. The results are in agreement with the analytical solution of terminal velocity ascent. This is quite reassuring. I'll try to solve the full ascent into orbit problem next.

Here's why the flat lines happen (assuming I understand the plots correctly): Since the planet rotates under your ship while orbiting, an inclined orbit will, in the worst case, bring you over every piece of land within some interval of latitude centered on the equator. The maximum elevation by inclination is then determined by the highest point in this region. It will stay constant until the region grows to include a new, higher point, at which point the maximum elevation will jump to this new value and stay there. (Until the next higher point is included and so on.)

I neglected the hard cutoff in this first run. I wouldn't imagine it would have any measurable effect (other than perhaps making the optimization problem a bit more difficult to solve). Drag acceleration at the cutoff point should be on the order of 10^-3 m/s^2 from a quick calculation. I wonder how significant this effect actually is. Correct me if I'm wrong, but couldn't you just zero out the drag term in the differential constraints if r>r_cutoff?

Good point! I often make stupid mistakes when working with polar coordinates (like the problem of adding r_dot and theta_dot in the earlier problem formulation). In this instance I'm quite happy, though, since it might mean the results are less far off than I had thought.

That's a good point. My model for this problem neglected rotation, so there will be a bit of a discrepancy due to that. A quick test in-game gave a final altitude of about 85Km, so there's some other source of error at work here as well. (I'd expect that neglecting rotation would make my result too high rather than too low.) Edit: This might be in part due to the noise in the control function. The biggest problem I had initially was that I was trying to build PSOPT and its dependencies using visual studio. It got messy pretty fast. I ended up just installing it on my Linux VM, though the installation was still a bit tricky. Had to add some includes to a few of the source files to get it to build, along with editing some Makefiles. Also had to make some small changes to the gnuplot interface code in PSOPT, since my system's version of gnuplot used a slightly different syntax than the one expected by PSOPT. Everything else went relatively smoothly. PSOPT's build system is just a bit brittle.

Alright, so I finally got PSOPT working. As a test, I tried to optimize for the case of the purely vertical ascent of a simple craft: Command Pod Mk1 + FL-T400 Fuel Tank + LV-909 Liquid Fuel Engine The goal was to maximize the penultimate height. Here's some plots from the run: Here's the output from PSOPT: PSOPT results summary ===================== Problem: KSP Maximum Ascent CPU time (seconds): 4.790000e+00 NLP solver used: IPOPT Optimal (unscaled) cost function value: -8.153408e+04 Phase 1 endpoint cost function value: -8.153408e+04 Phase 1 integrated part of the cost: 0.000000e+00 Phase 1 initial time: 0.000000e+00 Phase 1 final time: 2.525323e+02 Phase 1 maximum relative local error: 2.604555e-03 NLP solver reports: The problem solved! It looks like the craft couldn't quite manage terminal velocity, but its velocity follows the curve quite closely in the densest part of the atmosphere. I'll try to replicate these results in-game to see how accurate they are.

Thanks for finding those problems. I'll have to make a couple of changes.

I ran a test using KSP's dynamics and a test craft with a high TWR. The objective was to maximize the final altitude for a vertical ascent. Using my solver, this is what I got: Velocity as a Function of Altitude Ascent Overview Using a better solver should allow these results to be refined much further. Nice catch!

Thanks for all the useful info! ICLOCS looks like a nice solution -- I'll give it a shot. I've been able to get my homebrew solver to generate pretty accurate solutions to the (purely vertical) Goddard maximum ascent problem as defined here. (My Result) It's probably too slow to solve more complicated problems, but it was a real learning experience to write. In any case, I have a problem formulation (for a single-stage rocket) ready to plug into whichever solver I can get to work first: EDIT: Problem Formulation