Mini-challenge: max altitude with this supplied spacecraft

[jebbe]

Thanks PakledHostage for that quick calculation! At the precision we are currently trying to aim for, it actually could play a role. However, with our 1d calculations it would be impossible to account for this... Also, shouldn\'t it only have an effect parallel to the equator, and therefore perpendicular to the ascent trajectory? I\'m not really sure about this, but I think it doesn\'t play a role then, since we should be able to decouple the three translational degrees of freedom. Or shouldn\'t we? I\'m not quite clear about this yet...

I would expect the centrifugal force to have an impact though.

[Iskierka]

Coriolis effects usually count as an umbrella term that includes centrifugal effects, but yes, technically, it is only parallel to the equator. I however didn\'t account for this dimension beyond a preset velocity, used for calculating the centrifugal aspect.

Also, any extra acceleration is a lot for this situation. It\'s enough that accounting for Coriolis on Earth would significantly affect pole vaulting records - which seems a very close simile to this situation here. As for calculating it, PakledHostage gave the equations, though in a very strange coordinate system. My data was actually very simple - I was only using python (because it was only intended to be a quick, simple test), and the default floats, with an increase from 1 ms to 0.1ms steps changing results less than a metre; the initial target would be to get all test cases accurate to within 10 metres, which is currently quite far from what we get. Were you tracking the height by altitude or radius from centre? I did the former to reduce float-point errors outside the calculation of g, where they would be (mostly) lost in the insignificant figures, rather than in the metres of altitude.

As for atmospheric density, in the process of playing with the new module loader (which has meant no more work on the simulation), I have found code that results in atmospheric density being taken as 1.223095 mass units per metre cubed. Or, if mass units are kg, then standard Earth conditions. I have not yet found the drag code, however (which may be among the parts which did not decompile) meaning it is quite likely there is another scalar to be applied. One that is close is the ratio of Earth to Kerbin, which, when squared, results in a density between 0.0107 and 0.0109, depending on what size is taken for Earth.

Afterthought: It would be interesting to try make a new part that inherits from liquidEngine, but overrides throttle input to try follow the optimum vertical ascent. Hm ...

[closette]

@Iskierka

It\'s good that you have brought up the Coriolis effect which must play a role, but proably comparable to the modeling effects found by jebbe. It\'s definitely there though, If you do a vertical Goddard challenge launch and switch to map view, you\'ll see the path as a narrow 'arc', and we know that you won\'t fall straight back down to the launch pad.

(In fact I wondered if you could beat Kosmo-not\'s altitude record by purposely pitching over ever so slightly above 10km, to get a 'boost' from Kerbin\'s rotation, but I have not succeeded).

On the model atmosphere, we really don\'t know how drag is calculated from density - we should just form a delegation and ask the developers directly I suppose. (For instance, I would not use the conventional 1/2 factor in front of drag coefficient because it\'s one more floating point operation, but they may have a way of optimizing it out).

Also, if asked I would vote against the use of 'automated thrust profiles' in this game, because it would remove the player\'s 'x factor'. The calculations we do are useful, and can give guidance along the lines of 'stick this list of parameters to Jeb\'s visor', but automated profiles would make the game too much like Orbiter, IMHO.

Also, as we have seen, calculating them is not easy, and doing so in real time especially would up the system requirements for everyone, even those that do not use such a feature. (As a low-end laptop user I am already locked out of Rise of Flight and other games I would otherwise want to play).

[PakledHostage]

As for calculating it, PakledHostage gave the equations, though in a very strange coordinate system.

Come on, Iskierka, you know that I used a non-rotating cartesian coordinate system and that it was appropriate to do so for the purposes of that example calculation. You also know that the units work out. I used MathCAD, which is 'units aware'. Multiplying deg/hr by m/sec can yield a result in g because the unit conversions are done internally.

There\'s already been so much negativity on these forums over the past couple of days, can you maybe try to do your part to improve the situation by improving the tone of your posts? You\'re obviously very knowledgeable, but the sniping tone of so many of your posts is tiring and diminishes your otherwise valuable input.

Thanks.

PH.

[Iskierka]

I was simply commenting that your x, y, z assignments looked strange, though looking again I see that you had velocity vertical. Since centrifugal is the most important to this, I was assuming the velocity would be put in horizontal to get a vertical acceleration, so seeing the acceleration put in x was confusing. At no point was I trying to sound sniping.

As an extra on the auto-throttling liquid engine, I wouldn\'t intend to release it, and it would be limited use anyway, since it would keep you permanently at terminal velocity. I was just wondering about the possibility of using such a part to see just how high this test craft could get.

EDIT: New discoveries with the atmospheric density! Among the flight globals, is a parameter DragMultiplier. This returns 0.008. Multiplied by the atmospheric density, gives 0.009785. Or, almost exactly the densities expected. This then throws my results with my sim into question, but I\'d trust things I can pull directly out of KSP dlls over rough experimental results. The question then is what\'s being missed between jebbe\'s model and KSP.

[closette]

I\'m sure the 'strange' comment was a misunderstanding but I don\'t blame PH for being sensitive because yes, there has been some negativity on other threads. We\'re all scholars here!

Interestingly, if I use a surface density of 0.009785 kg/m³, multiply by the conventional 1/2 factor when calculating drag, and do a very simple constant centrifugal correction to 'g' (i.e. g-> g - 0.05075 m/s²), my version of Jebbe\'s C++ code spits out the following:

[tt]Time-step = 0.01s, surface density = 0.009785 kg/m3.

Burnout height 18091.1m at 87.02s, speed= 578.878m/s, thrust= 78.5439 %

Maximum height reached 33531.9 m at 145.35s for rho_0 = 0.009785 kg/m3.

Flight time = 145.35s, impact speed = -103.75 m/s.[/tt]

Compare that to Kosmo-not\'s winning flight: http://kerbalspaceprogram.com/forum/index.php?topic=7161.msg100978#msg100978.

Coincidence? I\'m not sure, but it\'s a reproducible result.

One correction I made to the code (and Jebbe did so independently I think) is to reduce the impulse of the last time step when the fuel level hits zero part-way through it. That has made the results less sensitive to the time step, which I can crank down to 0.5 ms if I need to in any case.

For a real-world example of what happens when you don\'t account properly for residual thrust, see the 3rd flight of Falcon 1: (at about 2:45 in this video)

[Kosmo-not]

You found me out, closette! I am a robot.

Nah, I\'m just very lucky.

It\'s great to see how far we all have been able to progress with this stuff.

That video made me laugh. How many times has that happened to us?

[closette]

Some people (well 1 person) were interested in analytical solutions to the differential equation of the rocket\'s motion, so I have attached some the of my efforts as a PDF here. Comments welcome.

I would certainly agree that for this problem, a robust numerical method is more useful than the analytic solutions I derived.

By the way, I just tried the challenge using the new v0.14 - similar results, so it appears that the atmospheric drag model (and all the hard work that went into understanding it!) is still valid.

[Kosmo-not]

The first thing I did when 0.14 came around was to check if the drag model was the same. I was a little disappointed that it was.

[jebbe]

Oh, there have been quite some interesting results over the weekend! It would have been nice to get a more realistic drag model, yes...

Iskierka, thanks for posting the actual surface density. Looks like we were already pretty close, but of course, getting the numbers directly from the game promises to be more precise.

Closette, that\'s an interesting result from your midpoint-method. I ran the calculations with the fourth order code as well, and using your simple additive constant for the centrifugal force I get the exact same optimum height, 33531.9m, at a time step of 20ms. Using the actual formula for the centrifugal force, m*omega^2*r, I get a little higher, 33554.6m at 145.38s - but I think we are now really close to the best possible result.

About the influence of the time step: this issue probably arose from the overdraining of the fuel in the last time step, so I think we resolved it in the current implementations. Iskierka obviously thought of this before I did...

And of course the issue of some switch getting activated after activating time warp once remains open, but I don\'t think we should try and model that, since it\'s obviously a bug in the game.

Oh, and the analytical solution - thanks a lot, I\'ll look into it as soon as I can!

Finally: Thank you also for the video, it\'s kind of funny that even SpaceX went Kerbal.

[closette]

Should the centrifugal term be recalculated at every step of the ascent as the rocket\'s distance r (=R_planet +height) from Kerbin\'s center changes? I\'m not sure because if the craft were truly co-rotating at the same angular frequency 'omega' it should remain above the launch pad, which it does not.

Hence without thinking too deeply I used a constant centrifugal term v_surface^2/R_planet evaluated at the surface, but I\'m just not getting my head around the rotating reference frame deal. It may be important in the code for modeling rockets that go higher than this one.

(Singing) 'You spin me right round baby, right round...'

[jebbe]

Should the centrifugal term be recalculated at every step of the ascent as the rocket\'s distance r (=R_planet +height) from Kerbin\'s center changes? I\'m not sure because if the craft were truly co-rotating at the same angular frequency 'omega' it should remain above the launch pad, which it does not.

My brain gets twisted by this again and again, too, but here\'s my view on this, and I\'m sorry if I only write down stuff everyone knows already:

In a non-rotating reference frame, we would stay right above the pad, going up at a speed we can calculate from thrust, gravity and drag - nothing spectacular, although it gave us quite some headache already.

Now, if we start spinning the surface without spinning the reference frame, we get a trajectory that would be very tedious to calculate. I would expect air resistance in particular to be a pain, since the atmosphere would be rotating with the surface, while our craft would not: it would just get an initial lateral velocity from the rotation.

To avoid this mess in our inertial reference frame, we rotate our coordinate system as well, so that we can describe our trajectories more easily. We can now pretend that we are in a non-rotating reference frame, with two exceptions: the two apparent forces we call the centrifugal and the Coriolis force. In our case, the centrifugal term describes the vertical influence of the rotation, while the Coriolis force is responsible for the horizontal deviations.

So to conclude: Yes, the centrifugal term should be recalculated at every time step, but since it involves omega, we would have to recalculate omega as well - it gets changed by the Coriolis force.

Phew - amazing how writing this down gets my own thoughts sorted as well. I think I have a better idea now how we could incorporate the Coriolis force in the 1d calculations; I will try that some time soon. My expectation is that we will end up somewhere in between Closette\'s and my most recent results.

edit: thoughts on how we would have to account for the Coriolis force:

The Coriolis force for a vertically moving object at the equator is

Fc = 2 m omega v_vert

This results in a horizontal accelerating force of

Fa = m d(v_hor)/dt

which we can express in terms of omega,

Fa = - m d(omega r)/dt = - m (r d(omega)/dt + omega dr/dt) = - m (r d(omega)/dt + omega v_vert)

Setting Fc = Fa we get

2 omega v_vert = - r d(omega)/dt - omega v_vert

or

d(omega)/dt = - 3 omega v_vert / r

I\'m not sure if I got the signs right, but in principle this should be fairly easy to incorporate into our codes.

[closette]

and I\'m sorry if I only write down stuff everyone knows already:

Even if that were the case (not!) it wouldn\'t hurt, and what you wrote is very clear.

I doubt if KSP models lateral aero drag forces at all so unlike reality we shouldn\'t have to worry about them.

After some thought I came to a different conclusion - that the spacecraft ascends with a constant lateral velocity v (174ish m/s), NOT constant angular velocity omega. So at each step I tried recalculating v²/r, which gets smaller with increasing radius r, as opposed to r omega².

That seeme reasonable, but constant 'v' would imply that the craft would get 'left behind' Kerbin\'s rotation and end up in the mountains. However from testing the same craft with an extra tank I see that it does stay pretty much over the pad. (I thought not, and was confused by the orbital Navball and the Map view which both show a curved path in space).

Surprisingly it doesn\'t affect the maximum height of this spacecraft much, but I would like to model those that go higher (even above 70km for a while) as well.

So I would encourage jebbe and others to continue looking at the rotation effects. One 'test' that the centrifugal+Coriolis effects are modeled well (for KSP, not necessarily reality) is whether you can also predict where a high-altitude spacecraft should come down east or west of the pad. You could do that for a fixed (100% ?) throttle case so it would be easier to compare the model with the game. Adding the extra tank (in KSP, and the code) will increase the flight time which makes the rotation effects easier to see.

We\'re nearly there, at least with the atmosphere fairly well dialed in. With the centrifugal/Coriolis stuff working for up-and-down flights it will soon be possible to model non-vertical ascents as well - I hope!

[jebbe]

After some thought I came to a different conclusion - that the spacecraft ascends with a constant lateral velocity v (174ish m/s), NOT constant angular velocity omega.

Well, in an inertial reference frame I would agree. However, since we are in a rotating reference frame, the a priori assumption is that in fact omega is constant. This isn\'t true of course, and that\'s why we need the Coriolis force; it corrects omega in the rotating frame, so that in an inertial frame of reference we get a constant horizontal v.

From what I gather, your approach applies the corrections obtained in the inertial reference frame to an calculation within the rotating frame, and I\'m not sure if one can do that... It\'s probably ok as long as you don\'t really move laterally, but I\'m not really clear about this.

That seeme reasonable, but constant 'v' would imply that the craft would get 'left behind' Kerbin\'s rotation and end up in the mountains. However from testing the same craft with an extra tank I see that it does stay pretty much over the pad. (I thought not, and was confused by the orbital Navball and the Map view which both show a curved path in space).

The Coriolis force accelerates an ascending craft westwards, and a falling object eastwards. So I would expect the ship to have some westward velocity component at its highest point, and no more westward movement when it gets back to the ground, but it should end up somwhere in the west - assuming zero aerodynamic drag. It probably wouldn\'t be much though, and the ASAS isn\'t really all that precise, so I\'m not sure if we could measure that - I usually ended up a little north, which clearly is due to the controls. But I have to agree, tests with higher vertical suborbital flights would be interesting!

[Iskierka]

I doubt if KSP models lateral aero drag forces at all so unlike reality we shouldn\'t have to worry about them.

This is quite an odd statement. Horizontal flight? Reentry? All seem fairly draggy to me. If you mean lateral to the direction of travel - recall that the direction of travel -does- have a lateral component regardless, which has to be accounted for.

As for calculating impact point - jebbe has a point with the precision of flight controls. ASAS is known to have enough decay that it can be used, unmodified, to hold an aircraft at constant pitch for a full circumnavigation, despite being (somewhat) designed to hold a true vector. Added to that that we don\'t know how well-placed the craft is on the pad, nor how level the pad actually is (there is no -guarantee- that it is perfectly level. If it\'s not initially placed at precisely 0,0,0 world frame, it\'s quite possible that it isn\'t simply due to minor planet curvature between it and 0,0,0. And I think we\'ve all seen the images of when the guys back at base get bored waiting for a mission to return, and start shuffling the buildings around).

What could be useful/interesting is seeing if it\'s possible to access flight data via the 0.14 API. Without searching too far, the class FlightGlobals has the functions getCentrifugalAcc, getCoriolisAcc, getGeeForceAtPosition, and atmospheric property functions. They can\'t immediately be found, but there may be functions for things like total forces acting.

Addition: However, I\'m quite unconvinced we would be close to finding a general equation for orbital launch maximum efficiency. In this case, we can be sure of what is the most efficient condition: ascent velocity = terminal velocity, as either side of this case results in, so far as both intuition and simple mathematical models can tell, less efficiency due to more fuel being expended against one force than another. With orbital launch, you have an extra parameter, of how much you are 'investing' towards horizontal velocity - and how, exactly, do you determine the relative 'value' of that velocity, compared to your vertical and terminal? Once that is the goal, the conversation will very quickly become very, very complicated, I think.

[closette]

Yes I meant 'lateral to the velocity', and I meant (probably) the velocity in the 'Surface' frame.

There are 2 other drag-related parameters in the config files, minimum_drag (usually equal to maximum_drag, but sometimes greater) and angularDrag (which has values like 2 or 3), but I believe that these are not used currently. (A test - set them to some crazy values and fly around a bit to see if they affect anything).

I\'ve compared the C++ code at full thrust with a few other craft configurations, different numbers of fuel tanks etc., and it seems to do an OK job of predicting the flight profiles. That implies that the atmosphere (surface density 0.009785 kg/m3, thanks Iskierka) and drag behavior are well modeled. An exception appears to be with the new 0.14 'half' tanks which provide more impulse than expected based on the VAB numbers, but I could very well have made a mistake somewhere.

As for the ASAS, agreed it\'s not perfect. What we need are star trackers to reference and hold a direction and roll angle in an inertial frame!

[jebbe]

New iteration - I have now included the Coriolis force into my calculations, and with this I get to an optimum height of 33504.7 m at 145.22s after launch. This is now almost 15m below Kosmo-not\'s record flight - not sure what to think about that... Maybe somebody can look over my procedure and probably find an error in it:

To do the correction, I calculated omega as stated here:

The Coriolis force for a vertically moving object at the equator is

Fc = 2 m omega v_vert

This results in a horizontal accelerating force of

Fa = m d(v_hor)/dt

which we can express in terms of omega,

Fa = - m d(omega r)/dt = - m (r d(omega)/dt + omega dr/dt) = - m (r d(omega)/dt + omega v_vert)

Setting Fc = Fa we get

2 omega v_vert = - r d(omega)/dt - omega v_vert

or

d(omega)/dt = - 3 omega v_vert / r

This is just one more differential equation (this time in the angular velocity) to apply the RK4-scheme to. I then used the corrected omega to calculate a corrected centrifugal force omega^2*r.

[closette]

I can confirm that result with your differential equation for omega. I\'m not great with all this rotating reference frame stuff though and I hope someone else can weigh in on whether that approach is correct.

I have tested my C++ code with this modification, and a simple v^2/r model, against flights with other spacecraft that go higher - way higher - and seem to get maximum altitudes somewhere in the middle of the two predictions. (Try pod+ASAS+3 tanks +1 LFE).

This makes we wonder if we should use one model in the atmosphere (when velocity is shown in 'Surface' mode by default perhaps) on the assumption that the craft is being pushed around laterally by the atmosphere, and another model when KSP decides to switch to 'Orbit' mode, when the spacecraft moves inertially?

One other prediction that might be tested with the Coriolis model is the 'maximum speed over ground' reported in the end of flight summary.

Once this Coriolis stuff is nailed down for vertical flights I think we shall be able to model efficient SSTO (single stage to orbit) trajectories via a 'shooting method'.

[nichampagne]

Hello! First post here. I started attempting this before reading all the info here. After reading, the tip of going full throttle at start to 100 m/s was a big boost.

Here is my very un-scientific way of getting max alt, I just kept trying different things.

Full throttle to 100m/s

hit x and immediately hit shift to increase to the 6 mark on the throttle

hold throttle until 10k

at 10k, give it a quick bump in throttle

repeat for 12k, 14k, 15k and 15.5k

gun it to full at 16k

This method will always get you to at least 33,400 and sometimes more. The controls aren\'t precise enough to control much more than this. Heres a video! I started recording near the Ap of my best attempt yet (33,513) and then a few more attempts afterwards.

<iframe width='640' height='360' src='[url]http://www.youtube.com/embed/4pWdlWBC8CE?rel=0'[/url] frameborder='0' allowfullscreen></iframe>

Kerbal Space Program - Goddard Challenge

[closette]

@nichampagne,

Thanks for telling us your results, and congratulations. You can use F1 (or Fn-F1 on a Mac) to record screenshots of your apoapsis and end-of-flight summary, but the video shows 33514 m with an unmodified spacecraft, so you are 2nd on the leaderboard! I was beginning to wonder if anyone else could break the 33500 m 'barrier'.

If you can get above 33500 m again, a video from launch to crash would be very interesting for us to see.

Quick question - above 16000m fuel is running down fast - do you believe that you are at 100% throttle when the engine cuts out, or are you increasing the throttle at that moment? The 'theory' says that throttle should be at 78% when the fuel runs out for this spacecraft.

Oh, and welcome to the forums!

[Kosmo-not]

An excellent choice for your first post. Congrats on your attempt!

[nichampagne]

I had been gunning it to full at 16 k, and getting to 100% for a split second. Maybe i will try only increasing to the 11 or 12 mark and getting a longer burn.

The next time I do a few attempts in a row, I\'ll record them and hopefully capture a 33500 + run.

[The_Duck]

Hi all,

At jebbe\'s suggestion I am implementing the findings of this thread about optimal throttle control during ascent in my ascent autopilot plugin. Playing with the exact numbers I use in the code, I can get a few meters above the current record using the plugin. Note that the plugin has an advantage over human control in that it can instantly set the throttle to 100% at the start of the flight. So I don\'t know if you want robots on the leaderboard, but the result might be interesting.

Screenshot of 33,531 m flight:

To do this I changed the ASAS on the rocket to use my plugin module for steering instead of the default ASAS code; this only changes one line in the cfg and I did not touch the mass or drag values.

The plugin sets the throttle as a function of altitude and current vertical speed to try to keep the current vertical speed near terminal velocity. I\'m calculating terminal velocity as described by jebbe here. Here\'s the plugin code that figures out what throttle to set:

double ratioTarget = 0.96;
double falloff = 15.0;

//calculate vertical component of surface frame velocity, then divide this by terminal velocity
double velocityRatio = Vector3d.Dot(surfaceVelocity, upUnit) / terminalVelocity(); frame

//below ratioTarget * terminalVelocity, full throttle. Above that quickly reduce the throttle as a function of the excess
//equilibrium velocity will be slightly above ratioTarget*terminalVelocity
if (velocityRatio < ratioTarget) throttle = 1.0F; //full throttle
else throttle = Mathf.Clamp((float)(1.0 - falloff * (velocityRatio - ratioTarget)), 0.0F, 1.0F);
//'Clamp' just keeps the throttle between 0.0 and 1.0

This is just a quick and dirty way of setting the throttle to get approximately the desired velocity. Using ratioTarget = 0.96 ends up giving an equilibrium velocityRatio very close to 1.0. For the first part of the flight, velocity was a few tenths of a percent below terminal velocity; during the last few seconds of thrust this dropped down to a minimum of 2.5% below terminal velocity at engine cutoff. Maybe a control algorithm that actual enforced velocity = terminal velocity could do a bit better.

[Kosmo-not]

If I were to program the throttle, I would do something like this:

pseudo-code:

throttleRequired = (terminalVelocity - velocity) / timestep * mass / maxThrust

if throttleRequired < 0

throttle = 0

else if throttleRequired > 1

throttle = 1

else

throttle = throttleRequired

Is there a function that will return how much thrust your rocket can generate?

[closette]

@The_Duck, that\'s an amazing result! For all that effort and skill of course you belong on the leaderboard, but with an asterisk for using a very cool auto-pilot.

If you can improve on the altitude record further I\'d like to know, since 33531 m is 6 meters higher than my own prediction based on following terminal speed and a simple centrifugal model.

The absolute maximum altitude I can predict from tweaking my code is 33538 m, by the way, so you have a whole 7 meters to go!

Other questions abound, e.g.

- Do you get the same altitude every time? What if you use time-warp on the way up - does that change the result?

- Did you use a constant maximum_drag factor of 0.2 to calculate the terminal speed, as in jebbe\'s post, or did you calculate a weighted average drag factor based on fuel used (slightly above 0.2 because of the tricoupler, which has maximum_drag = 0.3)?

This may help you (and others) - I have attached the full predicted flight profile from my version of jebbe\'s C++ code (with a simpler Coriolis correction and iteration scheme, but it doesn\'t affect much), which contains (altitude, terminal velocity) values for every 0.25s of the flight, and a summary at the end.

If you use these values it would be interesting to see if there was a small improvement in your auto-flown max. altitude.

Thanks so much for trying the challenge and sharing your expertise!