CBase

Just recently I discovered that optimised gravity turns gather speeds only slightly higher than spaceplanes, so I wondered if a rocket with R.A.P.I.E.R.s would work and how efficient they are ? So by start of last week I did design a SSTO stage for a 36 payload, which happens to be a little overpowered complete return science lab to land on the mun. And after some tweaking on construction and flight engineer support.... it worked ! Going from 3 Vector to 1 Vector and 12 Rapier saved around 38% wet mass on the SSTO stage going down from ~210t to 130t . I never got too fancied about spaceplanes because for bigger payloads proper air balance is a time consuming exercise, but this is about as easy as designing a rocket once you know the dV requirements. The Rapiers do start in closed cycle to assist with rocket lift off, around 200 m/s I do switch them to air breathing mode, throttle later back the only Vector to save fuel. When rapiers get near their speed limit - still below the ceiling altitude for air breathing - everything is throttled back up and switched to closed cycle. And all piloted by MechJebs Gravity Turn So next step: Automate flight engineer tasks in MechJeb Oh and I installed some near future mod with bigger dual mode engines for needs with bigger SSTO.

For me it is all about drag: Bigger sizes have less surface per volume. Note that even sides do produce drag. So center core + 2x side ? Fine. But before going for center+3x side I usually switch to 2.5m. Actually at the next steps ( I am using SpaceY up to 10m ) a factor of 2 is enough to switch for next diameter.

Exactly And my first stages do land near KSC for maximizing funds, although after some successful landings on the runway I don't consider it fun enough to repeat. But the first time to land there: Unforgetable.

My SSTO descend retrograde with some control surfaces at both ends deployed and AoA of roughly -15°. PE at deorbit is arund 10km, deorbit point choosen so that Trajectories prediction is at or slightly east of KSC. For return capsules always try how hard and deep can I set PE without blowing up. Usually it is around 25km and I hardly use dedicated heatshields, but rather burn off any transfer stages and land with parachutes. Actually retrograde burns do help as well as kind of heat shield beyond reducing speed, so I am throttling up any remaining fuel once KER shows 80%+ temperature on my critical part. Just as Snark I do not care about landing spot for mission returns: whatever comes back is usually not worth enough to make a difference in credits and I do not have to get into LKO to time for KSC.

Thanks to SpaceY Extended my first stages are all SSTO without SRB. The first stage might include multiple tubes, but it would still stay until return from orbit in the same configuration.

Actually for every celestial body there is a function to get the surface altitude for any latitude and longitude, so the question is only how do you get it into Matlab ? MechJeb Landing function lets you pick a target on the map and then outputs the altitude as well, while KER has output for a perfect suicide burn.

Actually you might want to go back to launch and plan first: Date and direction of first transfer make huge differences. 900 m/s is not a lot to play when changing interplanetary trajectories. How about using Just enter Kerbin -> Eve -> Kerbin, your start day, some dV limit from orbit and then let it search and sort for fastest solution. If you do an aerobrake for Kerbin, around 1100 m/s dV and 200 days travel time are possible. Note the incliniation: Solutions are not always planar !

I did try a lot with a fork of Trajectories and Mechjeb to land at KSC runway. With few tries and fiddling with some parameters depending on the rocket, I get enough precission to actually hit my intended target +- 200m. However I start from Orbit and can use a savegame to adjust. You want to start from launchpad and hit a target that is only few times bigger than a rocket. This increases your task to get repeatable. My suggestion: get kOS and fully automate the flight. Then note the position where you are landing and place your drone ship there. Now use trajectories to fine tune the very final approach. It will be still hard work.

Oh and about the bullet on a train stuff: The additional energy if viewed from outside is indeed the recoil of the weapon. As the weapon is moving with faster train speed its energy change is higher as well as it changes with v² just like the bullet does.

Although true, it is hard to visualize the reasoning which is what OP struggled with especially if you are not used to think in energy potentials. Since you are only displayed the speed relative to the current body ins KSP, but overall speed counts, it is may as well not intuitiv to understand when you are actually fast. I mean around Kerbin you see ~ 2300 m/s, but once escaped Kerbin around the sun it shows > 9000 m/s ! My mental model is to not think only about the point closest to a body, but think how you are flying on an escape trajectory past a body: First you accelerate as you get closer because the gravity pulls in same direction as your velocity and behind the closest point the gravity pulls back and deaccelerates the rocket. If you fire your engines at the closest point you dramatically change how long you are exposed to the deaccelerating force compared to the time when you where accelerating. So when burning prograde you escape the planet much faster, are less pulled back and therefore faster after escape. Vice versa if you burn retrograde to "catch a planet" you greatly extend the time. Go ahead: Check how many days you are fighting Kerbin gravity if you barely escape it ( 9 days or more depending how close you make it) and compare it with direct transfer to Jool: around 1 day ! Do you now understand why the Oberth effect is so strong ? Mathematically this is actually why energy is proportional to v²: Speed counts and the time you saved by speed. Once you have this model in mind, you can do swing-by's: Clever choose your relative speed when passing a body to make asymmetry in gravity work for you. The effect is smaller than burning 1000m/s at the periapsis, but hey it is there !

Would you mind to share it ? At best generate a fork on github and push your changes. I added some SpaceY engines for instances, the nice think about github is you don't need to host it somewhere, but can use a free html preview: http://htmlpreview.github.io/?https://github.com/cbase2/engine_charts/blob/master/engine_charts.html

Actually you might even save the page locally and just edit the javascript configuration, if you miss sooome engine or see outdated stuff. Nothing is serverside calculated.

Things I learned while doing the challenge with MechJeb and therefore fit better in this thread Using intermediate altitude and hold AP features in MechJeb Gravity Turn did not save dV if the turn is somewhat close to optimal I modified MechJeb to pitch somewhat horizontal instead of throttling down more aggresive if time to AP reaches the limit: no improvement as well in classic ascent profile it was easier to adept profile to the given rocket and harder to screw it up

No benefit as it ruins your total dV to report as result ....

After some more tries with MechJeb Gravity Turn Profile: 3479 m/s, Turn start 25 m/s, Turn start pitch 10.5° I didn't, as I considered it payload. With burned off Monoprop above launch has 3519 m/s left.

@IronMaiden: Could it be that you have a script or addon that empties Monoprop from command pods ? I did several tries with Gravity turns to match your efficiency, but never got better than my classic ascend attempt until I noticed you had more dV in second stage left than me.

3454 m/s dV left MechJeb, Classic Ascent profile, Turn start velocity 30 m/s, Turn end altitude 40km, Turn shape 45% Autostage and Autowarp, nothing else Due to high TWR I actually had to tweak around with Turn shape and altitude. Update: 3456 m/s as well with Turn shape 44%, but could not find a way to shave off one more

Actually this could be solved even by an extension: Add ControlSurface as module to KAL, so it is recognised by SAS and connect one input direction to KAL control value. The big problem is you would need to feed back the torque your KAL provides in order for SAS to correctly use whatever you control. And here I stopped, because I had no idea how to calculate this. And this makes the mentioned issue as well a pretty big extension wish.

Actually once you measure it, you can only throttle down to avoid RUD. The idea is more to optimize next run by partly increasing time to AP, which means you get higher before reducing time to AP and picking up speed.

In science this is known as Goddard problem, although original postulated as question how to maximize final altitude. However once in LKO it is identical to minimize dV required to reach a certain orbit. There have been published tons of papers and numerical algorithms for this problem and although I skipped over only few there are easy to grab concepts. In general: more thrust is better. (Read on before comment ) However in order to reduce drag lost, you want to throttle down once you hit a shape depending limit of dynamic pressure (max Q) in a way to stay just below this limit. I did not research for optimal solutions, but noting Q of roughly mach 1 below 3000m works for me. By chance Mechjeb lets you limit on this If you watch a Falcon9 launch you will as well notice that exhaust plume gets bigger once they pass Max Q. The second addition is that burning through implies that you do not follow a gravity turn as raising thrust does not get you into orbit except you coast to a second burn to circulize. If you include this second burn and coast duration into comparison, you will understand why throttling down saved dV in your experiments: the longer the coast, the bigger the circulize burn, the lower in average was your thrust. So the idea to keep AP close in front is just right, however do not throttle down, but pitch towards horizon to keep time to AP. The solution to manage heat is changing the time AP is ahead including once you first meet this and turn out of vertical ascent. Since Kerbin atmosphere does not match Earth, we will not find a solution in science papers I am afraid.

Are the robotic parts locked ? If not, try to set damping to 0. Close to the limits robotic parts can introduce incredible forces.

In your screenshot RCS is not enabled, although you have RCS thrusters at the nose. Without RCS engine gimbal will counter any derivation from course as control surfaces get less effective at altitude. Be aware that roll and yaw are connected if controls are off axis with center of mass.

Wing drag and lift directional components are only based on the cosinus between wing's lift normal and surface speed. So as long as you are not changing the lift direction like sweeping neither the lift nor drag changes. As a side note: Drag cubes are normally not used for wings, you will find dragModelType = none in all stock wing parts. So sides are only visual. f_drag = -v_surface/v_surface * A_wing * f_drag(abs(cos(angle))) * f_mach( mach ) * rho * v_surface² *global_constants Note: Bold are vectors, all other scalar. angle = angle between v_surface and wing lift normal. f_drag and f_mach are quadratic bezier curves, one to model angle dependency and the other mach related non linear effects. rho is the local air density.

Actually there are plenty of things that go nice inside bays: Parachutes, you can not deploy them anyway at speeds where doors should be closed. Maybe you can even get rid of some airbrakes if you get used to open bays for braking. Gigantor: in space you can fly with doors open and arrays extended as well landed. Just like parachutes: only safe to use when opening doors is less of a problem. A small service bay at front will serve to balance parachutes. In general bays are important to stay closed exactly at atmospheric ascend in order to decresse drag. Anything you do not need during this ascend can go inside. All the other time it is only aesthetic to keep closed.

The lock function requires that the motor current is 0. Which is either at desired position if steady state without gravity forces is reached or extrem points while movement changes direction for short duration or unpowered state.