Mini-challenge: max altitude with this supplied spacecraft

[PakledHostage]

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?

Not directly, but there was the Economy of Design challenge. Through a combination of calculations to predict when to start my pre-landing burn and a lot of luck, I managed to get a

(1) Pod-2LFT-LFE stack into orbit and safely back down again (total of 2 tanks).

I also recall reading about Kosmo-not managing to get a

(2) two stage Pod-small LFT-small LFE-decoupler-LFT-LFE stack (total of 1-1/2 tanks) into orbit.

And I seem to remember that there was a group who worked to get a

(3) Pod-small LFT, LFT, small LFE stack (total of 1-1/2 tanks) into orbit using MechJeb.

By my figures, stack (1) has a Delta-V of 4537 m/s, stack (2) has a Delta-V of 4716 m/s and stack (3) has a Delta-V of 5627 m/s. (If I\'m wrong about any of this, I\'m sure someone will be quick to correct me...)

Maybe your optimisation efforts could be applied to a new challenge to get the lowest Delta-V rocket into orbit? Adding a parachute to stack (1) decreases the Delta-V to 4291 m/s. I have always wondered if it would be possible to get that stack into orbit but I haven\'t managed it. Maybe you can do it?

[DayBlur]

@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

[antbin]

DayBlur for President!

[closette]

@DayBlur,

Sorry you had trouble reading my PDFs - not that you need them - but I had a friend process them through a PC and have attached the results below.

From experiment with numerically chasing the termnal speed, it looks like the resulting optimal TWR ends up being what you found, i.e. TWR = 2 + a/g where the acceleration a is that required to keep up with the changing terminal speed with height. (i.e. a = dv_T/dt = v_T dv_T/dy).

This is what my code and MechJeb does, but your higher record altitude tells me that your code is doing 'something' differently. I\'ll have to take a look at the detailed profiles you kindly provided and report back. I LOVE data!

Just a quick note on the small centrifugal terms, which jebbe worked on in detail. An unresolved question is whether one should use constant rotational velocity during ascent (= the velocity of Kerbin\'s equator), or alternatively a 'constant angular velocity' where Kerbin\'s atmosphere causes the rocket to co-rotate with Kerbin all the way up. Differences between these two are, for this rocket at least, too small to tell.

You\'ve revitalized this thread and the investgation as a whole. You also explain what you\'ve done very clearly. Could I prevail upon you to provide a bit more detail on how you derived the optimal control feedback equations?

[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.

[closette]

Hi DayBlur,

I finally managed to look at your flight data (thanks!) to see how your optimal ascent strategy differs. As you predicted 'not by much' is the answer.

The C++ code I was using to predict the maximum altitude is designed to 'chase' the terminal velocity (i.e. provide enough thrust to reach the terminal speed). Yes, I do include the changing gravity, and maximum_drag factor as fuel is used up, and a rudimentary centripetal term, as does the MechJeb implementation I believe. (Although Mechjeb does so using an arbitrary 'falloff' factor which I don\'t quite understand).

it sounds like your method explicitly calculated the acceleration required 'right now' (= v dv/dy) assuming that your ship is already going at the terminal speed. This means that your thrust profile is slightly more aggressive, resulting in a higher speed at burnout (which also happens a little earlier than for mine since you burn fuel a bit faster).

As you say, the differences are only just above the 'simulation noise' of time-steps, time warps etc. but they worked well in your favor!

I do hope you can work on the 2-D ascent problem - there are a couple of related Challenges going on right now (just follow my posts).

I have attached a line-by-line comparison of our ascent methods. Columns beginning with a 'C' are for the 'Closette' model ascent. Those beginning with a 'D' are the 'DayBlur' measured profile.

[KevinTMC]

I hadn\'t run across this challenge until just now, and thought I\'d give it a try in 0.16. I replicated the craft based on the screenshot, added a radial-mount MechJeb (for the ascent statistics) and a parachute and coupler (because I\'m soft-hearted), gave it a go...and was amazed at how much more dramatic the results were.

Gunning it at 100% the whole way, straight up, resulted in an apokerb of around 8850m.

Thrusting at 100% for 5 seconds (to approximately 600m altitude), then at 1/3rd throttle the rest of the way--and again, straight up the whole way--yielded an apokerb of over 345,000m.

The physics model has been tinkered with a bit between 0.15 and 0.16, perhaps?

EDIT: I took the extra pieces off and took a shot at manually piloting the craft into orbit. I succeeded in establishing an equatorial orbit, and pushed it out to 738km apokerb/602km perikerb before running out of fuel.

I\'ve installed a handful of plugins...I don\'t *think* any of the parts used on this craft were affected by that, but I\'m double-checking that now.

.craft file (the one without any stuff added) has been attached.

[Kosmo-not]

The physics model has been tinkered with a bit between 0.15 and 0.16, perhaps?

There is currently a bug in how fuel consumption is related to throttle setting. For full throttle, things are fine. For half throttle, actual fuel consumption is half as much as reported by the engine. This has led to someone getting to the Mun and back on one of the small half tanks.

Here is a link to the bug report: [0.16] [MAJOR] Fuel consumption is wrong at low throttle

Harvester has already fixed this issue for the next update, whenever that may be. Until then, 0.16 should not be used for this challenge.

[KevinTMC]

Aha. That would explain it. Thanks for the info.

Once this is fixed, perhaps a new round of this challenge would be in order? Just reading the thread has opened my eyes to a number of things...and there\'s still ever so much more to learn. (Also, any activity like this that prompts super-smart people like closette to reverse-engineer the physics seems to lead to improvement in the game engine in the end.)

[tvizz]

Lol yeah with the bug you can get 10k+ Delta-V

[closette]

Thanks for the kind words (this challenge was a team effort) and for revisiting the challenge - it\'s been ongoing in some form since 1919! http://en.wikipedia.org/wiki/Goddard_problem.

I\'ve only just installed 0.16 (Mac users had to wait) but it certainly sounds like a fuel problem, and not a change to the atmospheric drag model which I would be very interested in! I\'ll check it out later on but it sounds like a 0.16.1 revision should bring the challenge back to 'normal' and restore honor and dignity to the leaderboard...

[Vector]

Sorry to revive such an old thread (though I think this one is worthy) but is the physics model similar enough for 0.21 for results to be comparable? I am trying to use a different method of optimization and I am unsure of whether to expect the optimum to be the same. I am also having trouble downloading the craft file (if the parts still exist) so if anyone can help out with that it would be much appreciated.

If not then maybe there needs to be a new 1D Goddard challenge (my program is not yet able to handle the 2D case... just a simple extension haha).

[astropapi1]

Vector.

For God's sake, just create a new thread.

[stupid_chris]

The above is right. This challenge dates from .16, it's 100% sure that whatever craft use there is incompatible now. If you want to make a new challenge like this one, feel free to do so Vector, but don't revive old threads like this.

/thread