Jump to content

I need someone help me do some math for launch optimization


SaturnV

Recommended Posts

Did you try different values for terminal velocity ? like from 100% to 110%, just to see if one gets you more altitude ?

And how strong is the centrifugal force ? never really used it.

Edited by NikkyD
Link to comment
Share on other sites

Did you try different values for terminal velocity ? like from 100% to 110%, just to see if one gets you more altitude ?

In KSP, terminal velocity is pretty rigid, as far as craft design goes. The drag coefficient of almost any craft is going to be almost exactly 0.2, and that means terminal velocity at 1atm of almost exactly 100m/s.

But if you mean due to change of starting conditions, like if you started from sufficient elevation that results in lower terminal velocity, yes, maximum altitude will greatly improve. If you want to consider extreme case of rocket in vacuum, take a look at the red velocity curve above. See how it starts as a straight line, but then curves in right as it crosses terminal velocity line? That's where drag becomes more significant than gravitational force. If there was no air, that line would continue straight. In fact, it'd curve up a bit as your ship gets lighter. However, the cutout point would be exactly the same. So if you mentally extend this straight line to the 30s mark, you can see that final velocity would easily be twice as high, resulting in more than 4x the altitude! Naturally, an increase of only 10% is not going to be anywhere as extreme, but it'd help. The optimized solution is pretty much the same, though. Gun the throttle until you almost reach terminal velocity, then ease off to TWR of 2 as you settle at terminal velocity, and continue ascent. How that holds up when I throw in gravity turn, we'll, hopefully, soon find out.

And how strong is the centrifugal force ? never really used it.

Considerable! The value is (angular_velocity)² * (distance_from_center). And you get angular velocity by taking (2 pi)/(sidereal_period). The game actually takes this into account (as well as Coriolis force). In my simulation, it boosted me from apex of 5,200m to over 5,800m. Of course, with actual apex being at 5,488m, I'm still not sure if this is exactly right. But it gives you an idea of how significant centrifugal effect is.

Link to comment
Share on other sites

2 Things just came to mind.

1) The minimum starting altitude is 71m (thats the runway, maybe the platform is a bit higher), if you attach your rocket to that crane and pull it all the way up to the ceiling you can start at almost 150m. Thats 1,6% less atmosphere!

2) If 80m on the ground are 1,6%. Even a small rocket is between 5 and 10m long. What point does the game take as reference for calculating the drag ? Highest ? center ? Engine ?

Link to comment
Share on other sites

Ok, so i enhanced my sim to take fuel consumption = mass reduction into account.

I built a simple rocket, one rockomax 48-7s, one 1-ton fuel tank and mk1 cockpit (no monoprop) (and the mechjeb part).

I launched the rocket straight up, every 10s i escape-paused the game and compared numbers, also i compared the altitude and speed when the thrust stops (out of fuel) and the max altitude.

I'm pretty close...

Game

Thrust-phase to 18735m with 492 m/s, coast to 30440m

my sim

Thrust-phase to 18636m with 491 m/s, coast to 30199m (thats -99m, -1 m/s, -241m)

Because the velocities seem to match over the entire flight (i checked every 10 sec) i seem to gain less altitude than the game.

I also set my values to the games and just calculated the coasting phase, i also was short by some meters. I reached 30391 (-49m).

I implemented the centrifugal force, but im not sure if it works as it should. And maybe its truely something like coriolis, im not off by far.

Anyone got any ideas ?

Link to comment
Share on other sites

With 30km ascent, Coriolis will start to make a difference in a rotating frame. That's kind of why I went with a <6km launch for early tests.

I've gone to orbital flight now, but I still haven't sorted some minor inaccuracies in simulation.

Link to comment
Share on other sites

I chose the test rocket because it has a TWR of less than 2 so it never reaches terminal velocity so that the whole thrust-correction is left out.

Numberobis mentions in his scripts

Explanation for the systematic error, in part, is that the altimeter measures about 20m off from the engine -- below during launch on Kerbin, above while crashing on Eve.

maybe the game assumes different values than what it tells through the GUI.

edit: the 20m thing is about calculating ISP

edit2: If i take the fuel flow from the wiki page and linearly interpolate, i am off by a lot. The games "right click" engine info is said to be inaccurate ?! is that true ? where can i get true real time fuel flow units that are accurate ?

Edited by NikkyD
Link to comment
Share on other sites

Just compute fuel flow yourself. It's thrust/(ISP*g0). The game uses g0 value of 9.82m/s². ISP should be linearly interpolated between the low and high values based on pressure. (The full formula is more complicated and discussed in this thread. But for engines with just 2 key values it's going to be linear interpolation.)

Link to comment
Share on other sites

Ok, did that.

Now im pretty much dead-on accurate. The error now results in reading values from the game that is paused somewhere within a second whereas my sim gives me 10ms accurate readings.

Im sorry to say that centrifugal force makes 1% difference, i cannot confirm the 5000 to 5800, but tbh i didnt recreate your rocket.

Time to clean up my java class :D

Link to comment
Share on other sites

timestep is 10ms or 100 calculations/steps per second.

Integrating where ? i must confess... i dont really know what to do with both of these guys ;)

(but im still error < 1%)

edit: i think its euler, but im not good with math terms, im more hands on

Link to comment
Share on other sites

I got some preliminary results for a 2D optimization case with a gravity turn. Unfortunately, I've messed up the mass of the rocket, but that's not a huge deal, as far as these results go.

Because optimization is local, I had to start with something that gives a believable ascent program. I chose to go with something very simple. Vertical ascent to 8km, gravity turn to 45°, continue burn until apex is at 80km, and then burn prograde to establish orbit. Here is the graph of the control inputs.

3wj9.png

Blue line shows rocket's angle in radians, with 0 corresponding to vertical, and +pi/2, which is marked with a dashed line, corresponding to a rocket pointing directly East. Magenta line is throttle position. It's always full throttle, except for the coasting region to reach orbital altitude.

So this was the starting program which I fed to the genetic algorithm. I've ran 10k iterations with 100 genomes in each, corresponding to 1M launches. The criterion for optimization was amount of fuel left over in second stage, while any trajectory that did not reach orbit at all would be discarded. And this is what I got.

9lxf.png

There are several things worth noting right away. First, the throttle remains at 100% throughout the whole flight, except for the coasting region. Unfortunately, I believe that to be an artifact of the "mutation" algorithm, which I will revise. However, the other bit is interesting. The gravity turn begins as a counter-rotation. I don't think that's actually helpful directly. But rather it's an indication that the turn should have been more gradual. The actual control input is rate of rotation, rather than the angle, and correcting a large jump in initial program would not be easy. Instead, rocket beings the turn with countersteer, so that eventual angle change isn't as high.

Which brings us to the next bit. Actual velocity. Here is the graph of the speed of the rocket as a function of time.

t7bl.png

Here, I have original program in red and the optimizer output in blue, as before. Thin blue line is terminal velocity at relevant altitude. Here, I wanted to point out a few things. First, on both graphs you can see a sharp cusp at around 70 seconds. That's stage separation. Doesn't appear to cause any difference in burn procedure. The other bit is slower decay of the blue line once it begins to coast around 120s mark. Why? Because optimized flight is at higher altitude. Let me show the same graph broken up into components.

o5j2.png

Here, I have vertical and horizontal axes correspond to vertical and horizontal speed. Negative X corresponds to moving East. Here we can clearly see that the rocket ends up with more vertical velocity at the cost of horizontal speed, resulting in lower air density by the time the engines cut out.

So what I want to do next is start out with a much smoother gravity turn, so that it doesn't result in that sharp jump, as well as allowing the system more freedom on the throttle. There are several things I can do that. And, of course, I'm going to fix the rocket mass to correspond to an actual thing from KSP.

Link to comment
Share on other sites

@K^2:

Very interesting analysis. I have some questions though:

1. Your model appears to have optimized the rocket's pitch angle in the region between ~130 seconds and ~205 seconds while the rocket was coasting. What is your model attempting to minimize in this flight regime? Is the aerodynamic drag a function of the rocket's angle of attack in your model? If so, why wouldn't it be most efficient to simply maintain a 0° angle of attack while coasting?

2. If I understand correctly, you are optimizing an artificial launch profile where the rocket launches vertically, abruptly pitches over to 45° at 8000 m altitude and then proceeds to climb to orbit. Your optimized profile does not appear to have strayed very far from your initial seed profile. A real-life rocket flown this way would be subjected to very high transverse aerodynamic loads and may even break up as a result. (See videos of the recent Proton-M launch failure for an example of a rocket breaking up in flight due to transverse aerodynamic loads.) Even in KSP, many rocket designs would not have the control authority to execute such an abrupt maneuver. Even ignoring those considerations, an abrupt turn is easily demonstrated to be sub-optimal. How does your model perform if you use it to optimize a launch profile that uses a true gravity turn? Does it find profiles that are more optimal than those flown by competitors in Tarmenius' Launch Efficiency Exercise challenge?

3. How does your model compare to the optimizations calculated by TheDuck, et al. in Closette's Mini-challenge: max altitude with this supplied spacecraft challenge? I would think it would be fairly straight forward to run your model with the same parameters that they used. Would it be a good benchmark test for your algorithm?

Link to comment
Share on other sites

Whats the data on the mini-challenge craft?

IIRC, the Isp was constant in v0.15 and prior versions of the game (i.e. it did not vary with altitude). Looking at an old copy of v0.15 that I still have on my computer, here's some relevant data for the mini-challenge rocket:

1. The Isp of the engines was 579.4 seconds.

2. The thrust was 200 kN.

3. The engines had a mass of 2 tonnes each.

4. The fuel burn was 8 litres per second per engine at full throttle.

5. The two tanks had a capacity of 500 litres each and contained 2.2 tonnes of fuel. The empty mass of the tanks was 0.3 tonnes. The full fuel mass of the tanks was 0.3 + 2.2 = 2.5 tonnes.

6. The tricoupler had a mass of 0.8 tonnes.

7. The ASAS module had a mass of 0.8 tonnes.

8. The command pod had a mass of 1.0 tonne.

Edited by PakledHostage
Link to comment
Share on other sites

1. Your model appears to have optimized the rocket's pitch angle in the region between ~130 seconds and ~205 seconds while the rocket was coasting. What is your model attempting to minimize in this flight regime? Is the aerodynamic drag a function of the rocket's angle of attack in your model? If so, why wouldn't it be most efficient to simply maintain a 0° angle of attack while coasting?

The actual control input is rate of turn. So if it's trying to change its angle at circularization, any turn input prior to that is going to be an adjustment. So these end up distributed almost evenly through the coasting region.

All of the parts in the test rocket are default drag model, which does not take angle into account.

2. If I understand correctly, you are optimizing an artificial launch profile where the rocket launches vertically, abruptly pitches over to 45° at 8000 m altitude and then proceeds to climb to orbit. Your optimized profile does not appear to have strayed very far from your initial seed profile. A real-life rocket flown this way would be subjected to very high transverse aerodynamic loads and may even break up as a result.

And you can see that it was trying to get rid of that abrupt change. So yes, what I'm working on now is starting with something a bit better. Currently, the seed has a turn that starts at 30s and ends at 130s.

3. How does your model compare to the optimizations calculated by TheDuck, et al. in Closette's Mini-challenge: max altitude with this supplied spacecraft challenge? I would think it would be fairly straight forward to run your model with the same parameters that they used. Would it be a good benchmark test for your algorithm?

I'll try it out.

Edited by K^2
Link to comment
Share on other sites

Did some mechjeb launches... need some explanation / clarification

1) (coriolis) when i launch straight up, i have the planets rotation speed. The further up i go, the more the planet is moving/rotating faster than i am. The planet is rotating towards east, so i move west !? correct ?

So if i perform the turn somewhere near the AP, my 2D launch would go up, then bend left and fly off to the right...

2) how do i bring oberth into all of this ?! horizontal speed at lower altitude is worth more orbital speed than at higher altitudes ?! but how much...

Link to comment
Share on other sites

1) (coriolis) when i launch straight up, i have the planets rotation speed. The further up i go, the more the planet is moving/rotating faster than i am. The planet is rotating towards east, so i move west !? correct ?

So if i perform the turn somewhere near the AP, my 2D launch would go up, then bend left and fly off to the right...

Just do everything in a rotating frame of reference. Add centrifugal and Coriolis forces to your rocket. Centrifugal acceleration is Ω × (r × Ω), while Coriolis is -2 v × Ω. If you need forces, multiply each one by mass of your rocket. From there on, you just work with it as Newtonian problem in 2D without further complications.

2) how do i bring oberth into all of this ?! horizontal speed at lower altitude is worth more orbital speed than at higher altitudes ?! but how much...

You don't. The fact that thrust doesn't decrease with velocity already gives you a power boost at higher speeds. Power is equal to F∙v.

Link to comment
Share on other sites

im struggling with understanding the following

When i start straight up, shortest possible path through the thick atmosphere, then i coast for over a minute to 80 km. 20 sec before i reach AP i turn east, full thrust.

So i accelerated in the most efficient way to reach the altitude and didnt waste any force to gravity but accelerated horizontally where i had zero drag resistance.

I built a test rocket with 4100dv, with this attempt i reached 1600 orbital speed when the fuel ran out.

If i launch with mechjebs auto with turn at 8 and 40%, i reach 1900 orbital speed...

So im wondering where am i losing in the first attempt or what effect gives the second one this gain. Thats why i brought oberth into this.

Link to comment
Share on other sites

What stats should i watch ?

Delta-V expended, Gravity Losses, Drag Losses, and Steering Losses.

Im still not one step further. If i want my sim to go 2D, then i need to know what it should aim for. Every degree in angle gives me what and costs me what ?!

I'm not sure I understand the question. For ascent to orbit, you need to impose a final condition of desired altitude, zero vertical speed, and the horizontal speed needed for a circular orbit at that altitude.

Accounting for the rotating reference frame means you need to add the extra terms K^2 described to your dynamics. Or you can work in Cartesian (x-y-z) coordinates as long as you account for the correct variable direction of the gravity force, but then your final conditions are more complicated.

Link to comment
Share on other sites

This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...