closette

Great work Zephram - you had to do about 40 launches to orbit as far as I can tell. Nicely presented data as well. With this rocket\'s picthover start altitude being so low, I\'ve noticed that after I apply full thrust at ~ 10 km and then coast, the apoapsis starts decaying fairly quickly (say from ~80 km to 75 km if I judge it right). This makes me wonder if a better strategy might be to either: - pitchover, but reduce thrust or even coast to a higher, less dense altitude for a while , and then throttle back up to 100% and/or - aim for a higher apoapsis in the first place, which takes the rocket on a shorter, steeper path out of the air. There might even be a small fuel savings if one does this. Imagine aiming for an apoapsis of 70 100 m for instance - you\'d be stuck in the atmosphere for a long distance and path length. I\'ll be giving these a try, but sadly not as systematically as I would like. If someone can explain why a coasting segment in the atmosphere could never be optimal I would like to know! Also, on the subject of other rockets, TWR is a useful parameterization but without editing .cfg files I don\'t see how to change the mass or weight without also affecting the drag.

I just did a 75 x 79km orbit with 78.07175 kg remaining, slightly better than I could do before. For me, the I let the 'pitchover rate' be determined by the gravity turn, chasing the yellow ball from it\'s 'orbit' position. So I have been trying to optimize the start altitude of the gravity turn, and I\'m finding it\'s somewhere between 11 km and 15 km. A close-to-optimal ascent 'feels' different from the ones which don\'t work out well, hard to explain. Even though (unlike real world rockets) we are not constrained to small angles between heading and velocity, it seems to make sense that lining up both of them will maximize the conversion of delta-v into kinetic energy. However, the few times I have used MechJeb I was surprised to learn how small the 'steering losses' are when compared to gravity and drag. Therefore a pure gravity turn may not be optimal in this case. *EDIT* Sorry guys I\'m an idiot - I read the challenge as requiring a 75 +/- 5 km orbit, not +/- 0.5km as clearly stated. So I would have spent a little more fuel in a circularization burn. I guess I was just happy to reach any kind of decent orbit!

My best attempt: 77.07128 kg remaining after a 77 x 78 km altitude orbit. I don\'t know how to pull up the fuel tank state on a Mac (no right-click) so cannot prove it, unfortunately! (I got the data from the quicksave file, however anyone could edit that so it\'s not good proof). http://i50.tinypic.com/3583mki.jpg] Strategy (all at 100% thrust): vertical ascent to about 12 km altitude, switched the Navball to 'orbit' mode, then pitched over to match the velocity and heading vectors. Kept pitching over in a gravity turn until apoapsis reached about 75 km, then MECO, followed by coast to just before apoapsis, and a final prograde boost to circularize.

Sorry my phrasing was a bit obscure. I was referring to the vertical ascent phase, with no pitchover at all. We were able to establish that for this case only (known as the 'Goddard Problem' in rocket science), the most fuel-efficient ascent speed is one which matches the terminal speed (which increases with altitude). See for example: http://kerbalspaceprogram.com/forum/index.php?topic=7161.msg200489#msg200489 with PDFs attached. Once you go from a 1D ascent to a 2D ascent to orbit, things get much more complicated, but since Kerbin\'s atmosphere is so thick up to about 10 km, almost every ascent path I have seen tried begins with this purely vertical ascent. After a vertical or nearly vertical ascent phase, the initial pitchover angle and its rate of change is still up for discussion, and of course experimental testing.

Will try myself later tonight, but you\'ve set a good standard. Thanks for updating the challenge with my design, let\'s hope you get more takers in the coming week.

Well it\'s a slow day - happy Father\'s Day in the USA - but I think this is a great challenge. In fact 'crowd sourcing' might be one of the better ways to find an optimum ascent path. ESA tried this once a few years ago for one of their proposed interplanetary missions (using a weak stability boundary transfer). I feel I\'m being presumptious since it\'s your challenge, but I propose we use the spacecraft attached, which consists of a pod, ASAS, 3 tanks, 4 AV R-8 winglets: - 0.13.3 compatible so more people can use it (I think - someone please test this) - an ASAS module and 4 AV R-8 winglets for stability and control. I tried using 3 winglets, but that caused 'adverse roll' when pitching over at 90o. - no decoupler or parachute, sorry guys! I gave this craft a whirl (and ended up in a way-too-high orbit) but a nice feature is that 100% throttle results in -close-to-optimal vertical ascent below 12 km, so the challenge should be more about pitchover strategy not throttle control. If you like it, you could copy the .craft file to the first post in the thread for others to use.

I think there was a similar challenge last month for the smallest delta-v to orbit for a given spacecraft but I cannot find it - found it! http://kerbalspaceprogram.com/forum/index.php?topic=11132.msg170932#msg170932 But the more of these the better! Since there are no or few takers yet, might I humbly suggest using a spacecraft with an ASAS and some fins so that challengers can exercise smoother control over the flight? They could replace the parachute and stack decoupler. (Very humane - or kerbale - for you to include them, but not necessary). That way we are comparing strategy and not so much piloting skills. Also, this set-up requires pretty much 100% throttle all the time for fuel efficiency (except when coasting), particularly for the vertical ascent. That should be OK though if it\'s just the pitch angle vs. time that you want to explore. P.S. Mac users don\'t have a right-click button and the usual trick of pressing CTRL-click does not work - anyone know how to pull up tank fuel status on a Mac? (Mousing over the tank still highlights it).

Thanks for the fast reply and the telemetry data. Regarding the sea-level atmospheric density, if you recall this post from Iskierka: http://kerbalspaceprogram.com/forum/index.php?topic=7161.msg116175#msg116175 ...he found the density law you quoted in the code, and an additional 'drag multiplier' variable of 0.008, which explains the discrepancy between your 1.223095 mass units per cubic meter from your density probe, and the 0.009785 normalization which fits the drag equation. If your telemetered atmospheric pressure is in 'bars' = 105 N/m2, then the ratio of pressure to density which you found is a constant 81760 m2/s2 (the mass units cancel out) independent of altitude, which implies an isothermal atmosphere, in disagreement with the temperature readings. We probably were not supposed to notice or care about this discrepancy, and there are many other 'impossibilities' in the Kerbal universe to do with the planet\'s density, Kerbol\'s luminosity, the habitable zone, etc. But my hat is off to those who found it! (The constant pressure/density ratio also implies a sound speed of order Sqrt(81760) = 286 m/s for all altitudes, which would affect re-entry physics later on in the game\'s development.)

I had no idea that temperatures were even defined in Kerbin\'s atmosphere, let alone being able to measure them! Just for reference, in an earlier thread we worked hard to find out the density profile of the atmosphere, and by experiment with atmospheric drag we found that the density is given by 0.009785 Exp[-altitude / 5000 m] mass units per m3, where the command pod = 1 mass unit (which may be 1 kg or 1000 kg, or something in between I suppose). This profile has been rigorously tested in terms of predicted vs. actual behavior of craft in our atmosphere, and in fact has been incorporated into MechJeb, which would not be able to predict orbits or landings accurately if it were any different. The scale height implies an average molecular weight of about 46, which led me to half-jokingly suggest a composition which includes some Xenon or sulphur hexafluoride. See for example: http://kerbalspaceprogram.com/forum/index.php?topic=2062.msg106155#msg106155 I\'m not sure where the separate pressure vs. altitude profile comes from (as shown in the post by PakledHostage above). I do recall that the parachute deploys at a set pressure, but I don\'t know if anyone has tested pressure vs. altitude by altering this set pressure in the .cfg file and then observing when the chute opens. Note that even for Earth\'s atmosphere, which is not isothermal, the density profile is still well approximated by an exponential, at least for altitudes relevant to aviation. Even so, it would not surprise me if pressure followed density as if the atmosphere were isothermal - and the temperature readings are inconsistent with an ideal gas model. The developers have done an amazing job with the physics, but I don\'t expect everything in the game to be self-consistent. Not yet anyway.

Someone with a background in optimal control theory should be able to solve this problem, but from what I\'ve learned, the optimal ascent path to orbit is very rocket dependent. With the atmosphere\'s density halving every ~3500 meters in altitude, most people stay pretty much vertical until 10000m and a bit more. My own rule of thumb is to stay vertical as long as the craft can keep up with the local terminal speed in the atmosphere. As soon as it falls behind, I start a gravity turn and try to time it so that I pop out of the atmosphere going ~ horizontal at 75 km. Then a short coast followed by a circularization burn. I don\'t always succeed and so prefer rockets which have some fuel margin built in. You might also want to check out this thread in the Challenges section of the forum: http://kerbalspaceprogram.com/forum/index.php?topic=13350

You are very kind - in fact most of the work on the atmosphere was done in collaboration with Kosmo-not, jebbe and others. Glad that some of it has been useful! Unfortunately, an optimum 2D ascent to orbit profile remains elusive and may require the full apparatus of optimal control algorithms specific to each rocket, which is beyond my skills. I removed the 2 tanks from my modified EZ Minimun IIs to see if it would help with launch TWR and acceleration (specifically, trying to reach 100 m/s by 1200 m and 250 m/s by 10 000 m), and I did try replacing them with half-tanks at some point in my testing. But since I could at least sometimes get back with RCS only, I kind of forgot about them. For the EB version with SRBs I guess I could put the 2 full tanks back. The nice thing about your design is that one can add and subtract from the first stage easily, without breaking other connections, fuel lines etc.

mknote has the equation for 'n' correct above. It\'s reassuring when experience accords with simple model predictions! 1. You are correct that although TWR=2 is optimal in terms of fuel for ascending vertically in a constant-density atmosphere. As I mentioned above I tried attaching SRBs to the EZ Minimum II, which help by getting up to speed faster and saving a bit of fuel, but did not seem to make a lot of difference to the fuel I had remaining after achieving orbit. So that tells me you are close to optimal in terms of fuel usage. Looking back at earlier calculations, I now see that your launch TWR of 1.5 is still within 90% of optimal, as the graph below shows: (The fuel efficiency is proportional to Sqrt(1-r) / r where r is the Thrust/Weight ratio, so this is what I plotted). As you can see though, for a TWR below 1.5 the fuel efficiency drops off steeply as you spend more time hanging around fighting gravity and getting almost nowhere. So don\'t go much lower in your quest to save on engine mass! 2. As we found in the Goddard problem mini-challenge thread, for a changing atmospheric density, the optimal speed for a vertical climb is equal to the local terminal speed, which of course increases with altitude, and the resulting optimal TWR required to 'chase' the terminal speed turns out to be 2.0 + a/g, where a is the acceleration required to keep up with that increasing terminal speed. Using the exponential atmosphere model and a 'typical' sea-level terminal speed of about 100 m/s (it depends on the rocket\'s maximum_drag factors a little bit), I found that the optimal TWR as a function of altitude should be approximately given by: TWRopt = 2 + 0.1*Exp[+altitude / 5000] where the altitude is measured in meters. Below 10000m the second term is small, but above that it begins to increase quickly, so you are right that above that altitude you need a TWR bigger than 2 (in fact closer to 3) at least until pitchover. I can provide the steps leading to this equation if anyone is interested - it just takes a little time to do the formatting.

I know what you mean, but more careful phrasing is needed. For instance it takes me more energy to change an object\'s speed from 10 to 11 m/s than it does from 1 to 2 m/s, since even in the Newtonian regime, kinetic energy = 12 mv2. (E.g. for a m=2kg mass, the first case requires 121 - 100 = 21 Joules and the second requires 4-1 = 3 Joules). Perhaps a better expression would be 'For you to change your velocity...', since it specifies your instantaneous rest frame as being the one where the energy is measured.

Well I managed to switch the RCS tank and stack decoupler on my own, and personally I prefer it, since I can never make it all the way home with the LFEs alone. I think most people can fly a pod+parachute+RCS fairly well, just not precisely. (The trick is to leave the pod\'s SAS 'on' to provide damping of one\'s control inputs). As for landing back home, all my own ships have landed Soyuz-style (that is with parachute + retrofired RCS) which can be exciting over rough terrain, but I am used to it. I even added SRBs to one version of this arrangent, and replaced two liquid booster tanks with half-tanks, since I noticed that the ascent speeds were slightly below optimal between 0 and 12 km. But I recognise that\'s moving away from the 'Minimun' concept. Oh, on my last flight I tried scraping off the empty tanks (by frantic hopping around on the Mun) only to scrape off the engine instead! Serves me right! As you can see I\'m having a great time with your designs!

Matthias - Welcome, and check out the 'stock repository' in the spacecraft exchange for a wide array of modifiable, stock, Mun-capable ships which can inspire your own designs. One of the latest additions, 'EZ Minimun II', is a lot of fun to fly despite its minimalist approach. I\'ve modified it a bit so that the pod+RCS stay together as a 'lifeboat' if my poor piloting skills cause me to run out of main engine fuel. As for the 'swinging' when using x2 warp, many of my ships do that too. As you ascend, fuel drains out of the tanks causing the ship\'s center of gravity to move down(*), while at the same time the atmosphere gets thinner making control surfaces (such as fins) less effective, so you\'ll find that torques can amplify very quickly and possibly even flip your rocket. My solution is just to go back to 1x time, especially for manual staging or pitchover maneuvers, and hope that the SAS can counteract the torque buildup. (*) For stability, the center of gravity for a rocket should be well above the 'center of pressure', where the aerodynamic forces act, hence the fins are usually placed on the lowest part of the rocket. A good explanation is here: http://exploration.grc.nasa.gov/education/rocket/rktstab.html

I would have told people that I pronounce it 'Muhn' to rhyme with 'gun'. But on reflection after reading the thread title, I realize that I\'ve been saying it in my head the same way one would pronounce 'Moon' with a thick Scottish brogue (think Shrek). No explanation. Oh, and it\'s Kerbin not Kearth, and kerb-o-naut not kerb-a-naut nor kerb-i-naut IMHO.

@ Apotheosist: As I thought, I could not easily repeat my double-tank-scraping trick on the Mun surface. One more suggestion for the EZ Minimun II (which would make it a IIa I guess): I would put the RCS tank+thruster blocks above the stack decoupler, attached to the pod. That way, if and when you run out of fuel for the LFEs on the way home, you can at least get rid of the dead weight and use the pod+RCS+parachute as a 'lifeboat' to get back home. For some reason I could not get this change to work in the VAB, but you may have better understanding of how the components fit. And this change does not affect the weight.

Finally I got to try your EZ Mun ships. The EZ Minimun II was much easier to control, and I managed to get out to the Mun and back safely, even though I was probably not very efficient. I\'m not sure if this was supposed to be part of the flight plan, but when landing on the Mun with some uncorrected horizontal speed, I 'cleverly' managed to scrape off both empty side tanks, while the RCS kept the ship itself from toppling over. This made the trip home easy with the downsized ship: I\'m not sure if I could do that again! I encourage others to try this ship - it was a lot of fun to fly. Apotheosist, I think you should request it be added to the Stock Repository thread so that more people will notice it. Great work!

@Apotheosist - you win a 'fastest response time to a challenge' award as well - amazing. I\'ll give it a whirl later on when I get home. I\'ve noticed that the ascent profiles used by you and Kosmo-not for these mini-ships are quite different from the usual bigger ones (e.g. those Mun ships in the stock repository thread), with pretty much full pitchover by 30 km. At first thought it appears that would put your ship through a long path-length of atmosphere at high speed, which would cause a lot of drag, but it seems to work well in these cases. Fewer parts means less drag and higher thrust/weight ratio I guess. It does show that the optimal ascent-to-orbit profile can be very different between spacecraft. I think I can derive it, but care to share your payload vs. fuel delta-v formula with us? Might be a useful part of a tutorial at some point.

An amazing craft, calling for impressive piloting skills. For those of us who are less coordinated, I have been wondering what a bare minimum craft would need to look like if you had to include an SAS or ASAS module, an RCS tank, and a parachute. Specifically, how many additional LFEs would that require, and how would they be arranged? (Perhaps I could make this a Challenge but I pretty much know who would win it!).

Nothing to be ashamed of - quick and dirty works just fine! I got it to the Mun just as easily as the original. My only other suggestion would be to add another RCS tank and block (of 4 or 6 thrusters) some way down from the existing RCS thrusters, to provide a bit more torque for maneuvering. Rotating the ship around (especially with the first stage attached) is a bit ponderous. I also navigated your original to Minmus but bad piloting left me out of fuel in orbit. Nice ship overall - i had fun with it.

I gave it a try - certainly plenty of fuel in the 2nd stage for touring around the Mun to find a landing spot. However, it\'s a bit slow off the ground due to a low Thrust/Weight ratio to begin with. The most fuel-efficient ascent is one where you boost up to about 100m/s in the first 1000 m, and by 10000m you should be going at least 200 m/s (which yours almost does), ideally about 270 m/s. You could try deleting one tank per engine in the first stage, and adding solid boosters at launch for improved efficiency. I bet you would still have plenty of fuel left over by the time you reach orbit (which will be sooner as well).

@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 = dvT/dt = vT dvT/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?

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.

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?