Mini-challenge: max altitude with this supplied spacecraft

[jebbe]

@The_Duck, thanks a lot for giving this a try! Using the plugin solves the main problem we all had when trying to find the highest achievable altitude - having to remodel KSP\'s/Unity\'s physics backend.

I\'d also be very interested to know how far you can get using Kosmo-not\'s scheme. I could also offer a Newton optimizer for the thrust that gets the actual velocity arbitrarily close to the terminal velocity, but it\'s so slow that it would most likely cause extreme lags or even crash the game.

[The_Duck]

pseudo-code:

I don\'t think this is quite right, because it doesn\'t account for gravity, drag, or the change in terminal velocity with time, which should all affect what throttle setting you need to accelerate to terminal velocity in the next time step.

Just now I implemented a PI throttle controller which is able to keep velocity = terminal velocity to better than 1 part in a thousand for essentially the whole flight. There is a ~1 second transient as the controller settles down after it first reaches terminal velocity but after that it is very stable.

I played around with repeatability and time warp. With x2 time warp it, once, got to 33,603 m:

The highest it got on x1 was 33,557 m:

When I was just doing x1 and had done no prior x2 launches, it seemed like it would get to 33,520 m on the first launch after starting KSP, and 33,540 on subsequent launches.

I guess the differences between these various numbers are quantifying the magnitude of the floating point and integration errors in KSP\'s physics.

[closette]

Yes, Jebbe had noted a possible memory effect in the Unity engine regarding time-warp for these launches eariler, so I for one greatly appreciate your careful experiments.

Due to launch and burnout transients, and a possible memory effect of time-warp, any agreement within ~30m between prediction and practice is very good.

Which terminal velocity profile vs. altitude did you use? Could you please attach a table for comparison?

Jebbe and I are still figuring out some possible Coriolis type models (in brief - is an ascending rocket forced to rotate with Kerbin\'s atmosphere, or is its transverse velocity the same as Kerbin\'s surface - and does this change with altitude). So your reported altitudes are extremely helpful. It seems that the first possibility is consistent with your data, at least for the altitude range we are sampling.

[jebbe]

@The_Duck, thanks again for those results, this is really interesting! Especially the part about repeatability - looks like there is in fact a strong dependence on some factors we can\'t control. I\'m guessing this might primarily be the time stepping: I don\'t know how it is done in Unity, but these results make me believe that it\'s just a forward Euler that solves the equations at every frame that gets displayed - which would result in a dependence on the frame rate, which in turn makes me suspect that we might also get different results on different computers. As you said, you are most likely probing KSP\'s floating point and integration precision here.

Just now I implemented a PI throttle controller which is able to keep velocity = terminal velocity to better than 1 part in a thousand for essentially the whole flight. There is a ~1 second transient as the controller settles down after it first reaches terminal velocity but after that it is very stable.

Would be great to see some more details here - could you maybe post the code you use for your optimization, and the resulting v and vt? Would be great to see how you do it!

[hubbazoot]

So I...uh...kinda demolished the previous record.

Uploading video of descent back in now.

Completely stock config. I\'m gonna try again because I think I can do better than I did. Here\'s the flight results.

[Kosmo-not]

I am very interested to see this video you speak of. Can you tell us any other details of the flight?

[hubbazoot]

I am very interested to see this video you speak of. Can you tell us any other details of the flight?

I\'ll leave a hint until I get the video up and can write up the detailed logics of what I did.

Hint: w = ? F • ds = Rocket force - gravity force (1/r^2 and constants) - air friction (e^(-altitude) and constants)

That hint should be enough, and I\'m actually kinda wondering if it\'s too specific...

When the video gets finished uploading, here\'s the link:

http://youtu.be/KNpokNBRd20

[Kosmo-not]

That didn\'t tell me any new information. I guess I\'ll have to wait for the video.

The only thing I can think of is that you started a gravity turn.

[hubbazoot]

That didn\'t tell me any new information. I guess I\'ll have to wait for the video.

The only thing I can think of is that you started a gravity turn.

I used 3 fuel cans in my design instead of 2. Oops.

[Kosmo-not]

I used 3 fuel cans in my design instead of 2. Oops.

Ah, that makes sense. I was going to ask you to check your part config files in case they were edited and forgotten. I was very skeptical because the theoretical max altitude is not far above 35km.

[hubbazoot]

I don\'t edit my config files, I play entirely stock.

[closette]

This thread\'s challenge .craft file is provided for you in the first post - 2 tanks and no parachute.

The theoretical maximum altitude for 3 tanks is around 110 000 m. Attempting this manually I got to around 108 000 m. Your video doesn\'t show what you were doing in the ascent phase, but even at 100% thrust the whole time you should have reached above

80 000m, so I\'m not sure how you could get as low as 40 000m with 3 tanks.

I\'m using my version of jebbe\'s C++ code to calculate these, but you can try it with MechJeb\'s ascent autopilot too (after editing the final orbit and ascent path options it gives).

[hubbazoot]

Yup. Woops. I ended up giving it another shot doing it legit, and I got to 33344

[Saaur]

MechJeb got me to 33573.

[Zephram Kerman]

MechJeb got me to 33573.

Confirmed, sort of. I got a slightly different figure on my hardware. Using McJeb, the slightly modified downloaded ship consistently reached a height of 33,558 m. (I repeated it two more times, just for good measure.)

Using 2x time warp, the peak altitude was 33,586, an increase of 28 m. (I also repeated this two more times.)

This seems to confirm that there are measurable differences in performance between computers. Since your result was right in the middle of mine, I\'m curious if you used time warp or not?

[Saaur]

I actually don\'t remember. Probably no warp while burning and then warp when coasting. Lemme try it more methodically to see what we get.

EDIT

1x warp: 33590, 33575, 33575.

2x warp: 33585, 33587, 33586.

1x burning, 2x coasting: 33587, 33587.

[closette]

Very interesting results - the maximum altitude I can get with a simple physical model programmed in C++ using very small time steps in 33531 m, so your warp-dependent records above that indicate that there\'s more going on in the KSP/Unity/PhysX code than we can know about. You might be getting higher altitudes because of some transient impulse at MECO which does not appear in the model.

When I put up the challenge I didn\'t think too deeply about how sensitive the maximum altitude is to, well everything! Other parameters of the flight (such as time to peak, total flight time, max speed, acceleration and 'max Q') are in very close agreement with a simple model of thrust, mass, and atmosphere, even when the record altitudes vary by ~ 50m.

The dispersion in results might mean that perhaps, just perhaps, it could be possible for a human operator to 'beat' MechJeb in this challenge, but I doubt it. I\'ve been wrong before though!

[antbin]

I\'m not sure how this happened, but I seem to have flown the ship by hand 33,549m on my first attempt.

My computer\'s CPU spec is a bit low - Phenom II X3 710 - but the framerate seemed reasonable on the way up. Not sure if I hit a PhysX bug?

Anyhow, there it is. THROWDOWN!

[edit] Closette\'s speed table was taped to Gusing\'s visor.

[closette]

Bet you can\'t do that again! An outstanding result, and I\'ve updated the leader board in the first post under this thread. Well done! (and RIP Elbert, Gusung, and Rodnie).

[antbin]

Closette, question: Can you tell if your optimal speed profile still holds true with the new aerodynamics in 0.15?

[closette]

It\'s only been a few hours! And I\'m off to see an annular solar eclipse this weekend, so checking out 0.15 will have to wait. What are these 'new aerodynamics' of which you speak?

[Kosmo-not]

I would like to know too. I haven\'t noticed anything different so far.

[DayBlur]

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.

[closette]

Amazing for a first post to the forums (welcome!). I had been hoping that someone with skills in optimal control would work this problem, so this made my day!

I\'ll update the leaderboard at the end of the day, and yes I for one have LOTS of questions, as I am sure some others do. For starters, most of us having been using a method which 'chases' the local terminal speed - by applying full thrust from launch until we reach terminal speed, and then just enough thrust to keep up with the increasing terminal speed with altitude.

This strategy is optimal locally (in other words it uses the least fuel to get from height y to height y + delta-y) but I have always wondered if there was a smarter way to get a global maximum over the entire flight. So I\'d like to learn how your optimal thrust profile differs from the one that chases terminal speed - I can provide tables of numbers and/or code on request.

Thanks for working on this problem. For a real challenge, if you can adapt your code to optimize a 2D ascent-to-orbit (even using a simple constant-g 'flat earth' model) there will be LOTS of interest in that.

[DayBlur]

@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?