DayBlur

@closette - Thanks for the PDFs, they came through fine this time (and are very well written!) I\'ll try to familiarize myself with all the work you\'ve done thus far. For the latest, highest results, I just implemented the \'terminal acceleration\' as you have calculated in your papers, with the additional terms for gravity and centripetal force variation in height in addition to that of the atmospheric density. Also, as mentioned earlier, I left in the sqrt(W/D) term I had to help correct for numerical divergence. I tried to get to the same point from an optimal control standpoint, but had some small discrepancies - probably an error in my derivation somewhere along the line. I\'d be happy to write something basic up on the optimal control solution I derived earlier. Basically, I used an indirect method where you define an augmented Hamiltonian system and solve the boundary value problem. I would recommend 'Applied Optimal Control' by Bryson and Ho as it has a fairly simple treatment of the Goddard problem. I can put together some brief optimal control background information along with the derivation of the solution to the simplified problem (constant gravity, no centripetal acceleration) with modifications for Kerbin\'s drag model. It might take me a few days to find time, so if you have any specific questions in the meantime, feel free to ask. The MechJeb code currently does this (pseudocode): targetRatio = 1.0 falloff = 15.0 velocityRatio = ascentVelocity / terminalVelocity if (velocityRatio < targetRatio) throttleRatio = 1.0 else throttleRatio = 1.0 - falloff * (velocityRatio - targetRatio) end Which seems to be trying to track the terminal velocity rather than utilize the acceleration term that comes from the rate of change of the terminal velocity. This gives a best of 33,594m (or 99.8% of my best), which is close. I\'ve noticed that it applies slightly (~4%) more thrust than me after that initial throttle-back, but I haven\'t looked at it very closely. This problem is very sensitive at these small differences we\'re tracking. If it was the real world, I\'d round it off to 33,500m and call it done! The fact that I get altitudes that can vary by almost +/-10m in different runs using the same autopilot code makes me question the extent that we can rely upon our models. (My current MATLAB model tells me I should be getting almost 1km higher than I am). Glancing over your papers, the only differences that I see between your derivations and mine is that I take into account the variation of gravity (and centripetal acceleration) with height. This gravity term is a couple of orders of magnitude less than the variation due to the exponential atmosphere, but maybe that\'s enough to make a difference? Regarding the centripetal terms, I think the correct solution will be somewhere in the middle. As the rocket increases in altitude, its lateral velocity is less than the \'air up there\', so it would have its lateral velocity accelerated by that side force, but will never actually catch up and co-rotate. I\'m hoping this will all be accounted for nicely in the 2D derivation I started working on for the orbital launch. I\'ll try to log some comparison flights between my control law and what MechJeb is currently using. If you\'d like to post some code or equations for the force to apply given all other states, I can try that out in the autopilot as well.

@PakledHostage Thanks for the link and info, that looks like a good place to start. I think I\'ll try to see how efficiently I can get your 4537m/s stack into orbit, and then see if I can add the parachute. So, I found time to play around with the equations a little more last night and have re-derived a feedback control law taking into account centripetal acceleration and the drag force equation\'s explicit dependence on mass. This time, I tried approaching the problem from the point of view of trying to track the terminal velocity. Taking the partial derivative of the terminal velocity with respect to time gives me the following equations for the \'terminal acceleration\', i.e. the rate at which the terminal velocity is increasing: neglecting centripetal acceleration: v^2*sqrt(m*g/D)*( -1/(h0+h) + 1/(2* ) g = mu/r^2 including centripetal acceleration: v^2*sqrt(m*g/D)*( -1/(h0+h) - 3*w^2/(2*g) + 1/(2* ) g = mu/r^2 - w^2*r (Note: I included the centripetal acceleration in the gravity term) This is essentially the \'a\' in the T - D - W = m*a equation. Typically the latter gives me a ~10 meters of improvement, so that\'s what I\'m using. Note that the m*g/D ratio *should* be 1.0 and can be eliminated from a purely analytical standpoint, but I kept it in there to act as a sort of feedback for any numerical inaccuracies that occur during the integration. Implementing the latter control law in MechJeb\'s ascent autopilot (exactly as above - no other \'fudge factors\'), I can get as high as 33,658m: Here are some plots of the actual flight data for the above flight: Some things to note: 1) W and D stay close through the controller part, which is the \'singular surface\' in the optimal control problem and corresponds to the standard free-fall terminal velocity equation. 2) The TWR starts a bit above 2 and increases. The excess above 2 is used to track the ever-increasing terminal velocity. See also the difference between T and W+D. 3) The thrust actually decreases at first and flattens out before finally shooting up. Holding thrust constant around 45% until around 10km is a pretty good approximation, and I think that matches pretty closely with the strategies I\'ve seen people use here. I made about 5 attempts at following my profile *manually* and was able to get up to 33,560m, which I believe is a new record: I\'m also attaching an Excel file with the log of my data straight from the program and the above plots. I should point out that the altitude displayed in the game differs by a few meters from the internal values I\'m logging (maybe command pod vs center of mass?). There are also a couple more plots of throttle settings (in units of the ticks on the UI) vs both velocity and altitude, which may help if trying to fly manually. I\'ll be interested to see if this allows some even higher manual records to be set by the experienced pilots here. Or by Jeb getting lucky. [edit] clarified the definition of g for the two cases

@closette Thanks for the welcome, and thanks for all the work you\'ve done in this thread. Actually playing the game is fun, but honestly I\'ve enjoyed discovering the laws governing the Kerbalverse even more thus far. Unfortunately, every time I try to download any of the PDFs you\'ve posted, I get corrupt files (on multiple browsers/computers), so please forgive me if I\'m repeating and/or misstating anything you\'ve already explored. I\'m very interested in seeing what you\'ve done, any idea why I\'m having problems? Right now, implementing the feedback control law is as far as I\'ve explored, but I could add some code to log data from my controller in real-time if you want to see the thrust vs time or altitude. Of course, one can plug the control into the dynamic equations and integrate, but I\'d recommend a symbolic package as it could get messy. Alternatively, if you already have a spreadsheet with the state variables (altitude, velocity, mass) defined, you can just plug them into the feedback control law and compare with what you\'re getting. You already know the desired velocity vs altitude, but you\'d have to iterate a couple times if you wanted to get really exact since the mass will be a function of the time history of the control. However, even without iterating, you should be able to compare the two control laws with identical inputs. Honestly, I don\'t expect there to be any significant differences between our curves - you\'re probably as close to optimal as is practical given the (numerical and modeling) uncertainties in the game physics. This solution is the standard Goddard problem solution, which you already seem to be tracking very nicely. As to the theoretical differences, you\'re correct that the goal is to track the terminal velocity point. Applying the equilibrium thrust at each altitude would indeed be \'chasing\' the terminal velocity, which increases with altitude - so you have to be careful about lagging. I believe you identified this early on in saying that you should keep the TWR slightly above 2, but I\'m not sure that I\'ve seen that additional acceleration clearly posted (again, apologies if it\'s in one of your PDFs). I\'m thinking that using the terminal velocity time rate of change would get you most of the way there? In solving the full optimal control problem, the dynamic model coupled with the partial derivatives of the drag model inform the control law not only what actions will help meet the current terminal velocity, but also accelerate appropriately to keep up with it at future time steps. I realized that in my derivation I considered only a standard drag model which is a function of altitude and velocity. In fact, since Kerbin\'s drag model is also a function of mass there will probably be a couple more terms involving the partial derivative of the drag force with respect to mass (again, as part of that acceleration feed-forward term). I\'m sure they\'re small, but I\'ll add them in along with the gravity altitude variation when I have time to re-derive the equations, for completeness. I\'m certainly looking forward to tackling the 2D orbit launch problem. The equations of motion aren\'t much more complicated, especially if I assume a non-rotating Kerbin (but still include the initial tangential velocity). I\'m guessing the most useful formulation would be to minimize the fuel to some target circular orbit. Is there an existing challenge along these lines?

Hey everyone, I just finished reading through and have to say this is a great thread. Lots of really good information, some of which I will definitely have to revisit and think about more. I really like how close to an optimal ascent is possible with relatively simple methods. I\'m very impressed with how high people are getting with manual control. Seeing the humans beating the MechJeb with the same basic approach is awesome! Anyways, after reading this and a couple of other threads to make sure I understand the (flawed) drag model, the atmospheric model, etc., I formulated this challenge as an optimal control problem and derived the (analytical) optimal feedback control law. I was a little rusty, so as a first cut I made a couple of assumptions to simplify things: 1) that the gravity acceleration was constant (ie doesn\'t vary with altitude) 2) non-rotating coordinate frame (I\'m not accounting for any coriolis or centripetal terms) The problem was formulated as a maximization problem on the final height, with the final mass constrained to the empty weight of the vehicle. The structure of the problem results in the three-segment controller you\'ve all seen as the solution to Goddard\'s problem: 1) Since the control (thrust force) appears linearly in the optimization gradient, the system would typically be controlled by a bang-bang controller. This is what happens during the first segment, resulting in max throttle. At max thrust, the rocket accelerates up to what is known as a singular point as far as the control is concerned. Simply put, this means that at this point, the control does not influence the optimization gradient, and therefore has no impact on the optimization problem. Obviously, this means that you can\'t directly solve for an optimal control. In a \'normal\' bang-bang controlled system, you would pass right through the singularity point and immediately apply the opposite control. 2) In this problem, the rocket actually stays on this singularity surface for a finite amount of time, which is why this isn\'t a simple problem. Since we know the system stays on this surface for a finite amount of time, we instead calculate what control is required to keep the system on this surface. This part of the control/trajectory is known as the singular arc. 3) The final stage is obviously to apply zero force once the fuel has run out (this is technically another bang-bang segment where the throttle shuts down to minimum to enforce the terminal constraint of ending with zero fuel mass). A few further notes about the assumptions: - Despite the fact that I assumed gravity was constant with altitude, I\'m using the varying value in my feedback control law. This means that I\'m actually taking into account the varying gravity acceleration, but neglecting terms from the full optimal control law that are a function of the gravity gradient with altitude. These terms are likely small and fairly inconsequential, but it is something that shouldn\'t be hard to add in later. - I haven\'t given much thought to the appropriate way to account for the rotating coordinate frame for this problem. Certainly at least a 2D model would be required to account for lateral accelerations (both coriolis and aero drag). I\'m not accounting for the centripetal acceleration in any of my equations. The optimal feedback control while on the singular arc is: T = D + m*g + m/(D + 2*c*[dD/dv] + c^2*[ddD/dvdv])*(-g*(D + c*[dD/dv]) + c*(c - v)*[dD/dh] - v*c^2*[ddD/dvdh]); The altitude and velocity are v and h, and the mass is m. The [d../d..] terms are the first- and second-order partial derivatives of the drag force with both velocity and altitude. Additionally, T is the thrust force, c is the effective exhaust velocity (ie specific impulse velocity), and g is the gravitational acceleration. The drag model is the one converged upon previously in this thread, so I won\'t repeat it or its partials here unless someone requests them. I don\'t have the machine-like precision some of the people here seem to, so I just modified MechJeb\'s ascent autopilot with my control law. I\'m doing this in KSP 0.15, and the latest (stock) MechJeb (1.8.3) was getting ~33580m. All my testing has been without time warp, but I\'ve been seeing about +/-10m variations with the stock MechJeb. I\'m not sure how the internal physics model is propagating things, but the feedback controller is designed for a continuous system. Obviously both the dynamics and control are discrete in this case, so I would expect sub-optimal performance. To try to combat this, I decided to increase the throttle slightly to combat the numerical lag. I found an increase of ~1% to give good results, increasing my altitude by over 100m. I don\'t like having to fudge things this way, but it was a quick fix. It seems pretty clear to me that theoretical results are not going to be easily duplicated in the game, but the principles should still hold. 33,632 m: Feel free to ask any questions. I didn\'t want to load this post up with too much math, but I\'m willing to go deeper into any aspect of the problem or solution. When I get some more free time, I hope to take a look at the launch-to-orbit problem.