closette

Attached is a PDF of some restricted solutions I found analytically, on the assumption that 'g' and the drag factor are both constant, and that the Thrust/Weight ratio is held constant (different from constant-thrust). Even with these simplifications, the functions are hard to evaluate (exponential integrals), and it would be better to use a numerical method such as RK4, although if you use a smaller time-step (0.01s) you can use a simple step-wise linear method, as jebbe and I did for the Goddard Problem challenge thread, here: http://kerbalspaceprogram.com/forum/index.php?topic=7161 Kosmo-not implemented something similar just by using an Excel spreadsheet to update the mass, velocity, thrust etc. in each timestep (referenced in the same thread above). We all learned a lot about the atmosphere and optimal ascent strategies in that thread! For constant thrust (therefore dm/dt = constant), even assuming a constant-density atmosphere I cannot get an analytical solution. If someone is interested enough I can post the C++ code I use, but you have to edit the thrust, mass, and drag factors for each particular rocket, using information from the KSP Parts Wiki.

Unlike a purely vertical ascent (known as the 'Goddard problem'), finding the most efficient ascent-to-orbit profile is a difficult optimal control problem and unique to each design, although there is a Challenge now on the forums to get to 100km orbit with the least delta-v, and some players are doing better than MechJeb I believe (yay humans!). Without much to back it up, I tend to start my gravity turn when the craft can no longer 'keep up' with the optimal terminal speed for vertical ascent. My ad hoc reasoning is that 'gravity drag' is then dominating over 'air drag' so it\'s time to start building up orbital speed. By 30km altitude the terminal velocity for most craft is equal to the orbital velocity, so I try to be pitched over by at least 45 degrees by then. But not too far over, or you\'ll have to push through many km of atmosphere before getting out! I used to be fussy about steering the craft exactly to align the thrust and velocity exactly during the gravity turn, but I learned from MechJeb that 'steering losses' are generally small compared to gravity and drag losses. It\'s even possible that such a pure gravity turn is NOT the optimal ascent profile for some rockets. But these are details that should probably not appear in a beginners\' tutorial - better that they be discovered by practice and patience using a given launch vehicle. I\'m still learning from my mistakes!

Fair points - perhaps 100 m/s minimum by 1000 m is more attainable. That\'s where SRBs come in - don\'t leave home without \'em! Lots of thrust for just long enough to get you up to speed, then away they go. The initial TWR for an SRB+radial decoupler is 5.9, which can only increase the overall launch TWR of your craft if it\'s carrying any payload at all (from an ASAS module to a Mun lander). I agree that by 10km one\'s vertical speed should be in the 200\'s (280 m/s is the optimum ascent speed at that altitude). When staging I often see a small dip in speed. It\'s hard for this not to happen if you\'re at 100% thrust, because just before you stage compared to just after, you have more engines with nearly-empty tanks and therefore a higher instantaneous TWR. Hard to quantify but a few m/s drop is OK. As for optimum TWR, I looked back at some calculations I did (attached, cleaned up a bit from an earlier version I posted months ago) and the efficiency vs. TWR curve in that document shows a very broad maximum around the optimum value of 2. In fact any value of TWR from 1.5-3.0 gets you at least 90% of the maximum efficiency. I would want beginners to know that they should design for TWR of at least 1.5 at low altitude where the atmosphere is thickest. Any less, and your slow slog upwards means your 'gravity loss' will be very large and you\'ll drain your tanks without really getting anywhere or getting close to 200 m/s by 10 km.

@Excalibur, A good start to a plain-language guide. Wish there was something like that when I was starting out. Some of the statements about ascent in the first 10km are not quite right though. I don\'t want to toot my own horn but this post in the Goddard Challenge thread summarizes what Kosmo-not, Jebbe, Izkierka, others, and myself discovered about an efficient vertical ascent: http://kerbalspaceprogram.com/forum/index.php?topic=7161.msg106460#msg106460 For this 'most efficient' ascent you need at least a TWR of 2, in fact the capability of 2.5-3 would be a sensible range. A TWR of 1.0-2.0 at launch makes for an excruciatingly slow and inefficient ascent (as I found out in my first attempts at rocket building). MechJeb implements this optimal ascent scheme for the vertical part of the ascent to orbit, but the post referenced contains an ideal speed vs. altitude table for manual flight. If you follow it closely, you\'ll end up with about 50/50 'gravity loss' vs. 'drag loss', but in practice 60/40 or 40/60 would not be too bad. (The efficiency curve has a broad maximum). If you have the choice, better to go up a little too fast than a little too slow. And from launch, it\'s best to get up to ~120 m/s as quickly as possible - by 1000 m altitude if you can - so use full thrust (+SRBs), then throttle back if you have to. You certainly would not want to include all this detail in the guide - perhaps mention that there is a 'compromise' speed between gravity and drag losses on ascent. But I\'ll leave the wordsmithing in your very capable hands.

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

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!

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

Cosine I think, unless someone needs to cosign your loan for the spacecraft OK I always seem to be the one to ask - how did you calculate that? I can see how to do so in principle - at a given position, a change in velocity vector delta-v will change the orbital energy and angular momentum, related to semi-major axis a and eccentricity e , and the periapsis is just a(1-e), but it seems like an involved calculation to find the direction (and magnitude) of the minimum delta-v required. (And i could not find any version of this already worked out online). Even a brute-force search over magnitude and angle (with a spreadsheet) would be quite impressive, but you\'d have to do it for each situation. Care to share how you did it? This comes up a lot when entering Kerbin\'s SOI on the way back from the Mun. Thanks in advance?

MET = mission elapsed time MECO = main engine cut off Can\'t add any more here - what you\'re doing is great, and worth writing up as a tutorial.

I doubt if my Mun rockets would do much better if launched straight at the Mun, but here is an excellent video by astrophysicist Scott Manley which demonstrates the advantages of pitching over, even when on an escape path: In short, using thrust to increase orbital speed, as opposed to altitude, saves you from having to lift a lot of fuel 'uphill' against gravity.Hope this helps.

Hi Ivan, Correct that to keep up with terminal speed on ascent, you need at TWR of at least 2 at launch - in practice more like 2.5-3 so that you can get up above 100 m/s quickly and keep accelerating from there - that\'s what I use SRBs for. I appreciate that with the 'dead weight' of a Mun lander/return vehicle this is difficult to achieve a launch TWR > 2, but it\'s not impossible. Some of the Mun vehicles listed under Darkshadow\'s Stock Repoistory thread have some good examples. and recently I recall that Kosmo-not won a challenge with minimalist Mun return vehicle (which takes a lot of careful flying, but which HAS to be fuel efficient on ascent). As I mentioned, my craft tend to fall behind the optimal speed vs. altitude curve after around 12000 m, but as long as one isn\'t too far off the optimum values at low altitude, the hit on fuel consumption isn\'t too bad. But my early over-built Mun rockets which struggled upwards at ~60 m/s for the first 10000 m were horrible in terms of fuel efficiency. It sounds like your Mun return craft is a bit on the massive side, by the way, given that a pod + parachute + 2 RCS tanks can make it all the way back from the Munar surface to Kerbin, so more SRBs at launch would be called for. And perhaps convert 3 of your first stage engines to tricoupler + 3 LFEs to triple their thrust (just make sure you jettison these gas guzzlers early). Hope this helps...

In fact Kerbin still needs a strong greenhouse effect to stay warm enough for grass and liquid water. Thankfully the atmosphere appears to have a high molecular weight (from the scale height), and my favorite candidate for a major constituent of it is sulfur hexafluoride, SF6, which is a greenhouse gas.

That might work for a Munar ascent, but for Kerbin you have drag breaking the symmetry as well as fuel use, so the ascent to orbit guidance is a unique problem on its own. And staging might be involved. For those reasons I\'ve been trying to find a workable SSTO optimization for a Munar ascent. Using a 'shooting' forward-propagation method with a linear tangent steering law and full thrust to see where one ends up after a set time with a given starting pitch and pitchover rate seems to be one way to go. That would generate a table of final orbital states given those initial conditions, and one could pick the closest desired. I\'m admittedly a bit out of my depth on the literature though...

Keep trying - it took me over a week to progress from 'fatal crash on the Mun' through 'survivable hard landing on the Mun' and 'soft landing on the Mun but no return' to an eventual 'safe landing and return from the Mun'. And sometimes I still break the spacecraft on Mun landing. > I have attached an updated version of the craft which uses the 0.14 lander legs in place of the winglets. Use the 'G' key to deploy the legs for landing. Good luck, and check out some of the threads on this message board to see how others make it back from the Mun.

Just a couple of points: - As the 'someone who did the math' http://kerbalspaceprogram.com/forum/index.php?topic=7161.msg106460#msg106460 I feel I should point out that the efficiency vs. ascent speed curve is fairly broad around the maximum so you need not follow those speeds exactly - plus or minus 20% is OK. In fact I fly my usual craft faster than the most efficient speed at the beginning of its launch (so as to burn off some fuel weight ), but I still end up about 20% slower than optimal by 12000m. Not a big deal. - As for 2D optimal trajectories from Kerbin to orbit, I\'ve been doing a lot of reading about optimal control theory, gravity turns, linear tangent steering etc. and it\'s not an easy problem to solve. (Even the lunar ascent profile with no atmosphere is difficult enough). For Kerbin, turn too early or too flat and you\'ll waste fuel scraping through a long path length of the atmosphere. Turn too late or too little and you\'ll get a nice sub-orbital flight but no orbit. I tend to wait until about 25km to begin my gravity turns, which is higher than many of you, but can get me into an ~85km orbit if I do it right. For a higher orbit, I just Hohmann transfer from there, although that takes more time than a direct insertion. If someone else (an aerospace engineer) can come up with an efficient launch-to-orbit rule-of-thumb as I did for vertical ascent, we\'d all be very interested to see it!

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.

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

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

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

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!

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 v2/r, which gets smaller with increasing radius r, as opposed to r omega2. 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!

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

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.

Keep at it AlexanderB, and you\'ll get the hang of it. The lander I use has an ASAS module (which I leave behind on the Mun) to make controlling it less 'twitchy', but I found that trying to be a prefectionist when nulling out lateral speed did me more harm than good. I\'ve skidded into a safe landing with 4-5 m/s lateral motion, but again the lander I use is short, not tall, so less likely to topple. Doesn\'t mean I get it right every time though, which is part of the fun of the game!

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/m3, 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/s2), 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)