Pand5461

Kerbin's atmosphere is 70 km, which is about 11.67% of the planet's radius. On Earth, that would translate to about 750 km of atmosphere. In reality, rocket go to the low-Earth parking orbit at about 250-350 km with a continuous burn. If the payload needs to get to 750 km altitude, a series of transfers from a parking orbit is more efficient. Space Shuttle didn't typically go even that high by a continuous thrusting. It went first to ~110×250 km orbit at about 150 km altitude, dropped the orange tank so that it reentered on the next orbit, and the orbiter itself circularized at apoapsis about a third an orbit after SSME cutoff. In fact, going full gas until you get wanted apoapsis altitude and then coasting to apoapsis is in fact the most fuel-efficient strategy in KSP for most crafts, except very-low-TWR upper stages. A typical KSP rocket is powerful enough to orbital velocity way before it can jump out of atmosphere. The idea that continuous burns at non-maximal thrust are more fuel-efficient than burn-coast-burn sequence is a common misconception here on forums. If you have to throttle down to optimize fuel consumption - the best way is to throttle down all the way to zero! Because in that case, you spend less time thrusting above horizon and having gravity losses because of that. If the atmosphere thickness was about 25 km, then continuous burns would be the way to go.

To fit coefficients into the known functional form for force dependence on position and velocity - yes, maybe. Certainly not for the actual path prediction.

Use AI to compute a motion of a dynamical system when there is a myriad of numerical integration methods with proven accuracy and rate of convergence... Probably CS students who learn things beyond buzzwords are too awkward to show in a fancy video.

The MM version seems dated. 2.6.6 was released in June 2015, way before KSP 1.2.2 came out (December 2016).

Cool! Now I know that there is an explicit way to set maxPressure. Yes, 15000 kPa (150 atm) tolerance should be reasonable. That's about the same pressure as 1500 m underwater, so the pod should weigh roughly as much as a bathysphere.

Edit: Ninja'd

I've now realized, this is essentially what my optimization arrived to. Aaah! Correct use of homophones isn't my strong point, especially after too little sleep and too much coding. On the challenge topic, I'm getting more familiar with kRPC, so probaly I'll be able to continuously tweak departure burn for arriving to Minmus as equatorially as possible. And even do stuff with a proper launch, not Alt+F12-ing ship to orbit.

Peace of cake. A careful choice of the initial orbit, maneuver timing and direction, and the end result: Full video (not disclosing the initial orbital plane):

This can go the level "sugar powder is flammable, too". Kerosene is safer because it does not contain oxidizer. Kerosene is cheaper because of mass production and competitive market. Liquid oxygen is fairly cheap as well, again because it has many industrial uses. Solid fuels and hypergolics are hardly used outside military and space tech, so their production doesn't have to be cost-efficient. Not to mention they are toxic and volatile (high-explosive-type of volatile, not flammable-type), so handling adds even more cost. Also, solid rockets arrive fueled at assembly site, so all assembly operations must be performed with fully-fueled boosters, hence the need of heavy and expensive equipment in the assembly building. And additional safety measures. Looks like, it's size-dependent. Handling bigger SRBs becomes progressively more dangerous, so safety measures rise the operational costs. And, given worse specific impulse, mass of a solid rocket launcher would increase faster with the mass of payload, than the mass of liquid-fueled launcher. Another thing I've dug in the internets, is that solid rocket burn time is determined primarily by its diameter. So, elongating an SRB increases thrust rather than burn time. Given that Space Shuttle/SLS SRB segments have the maximum diameter to transport them by railroad and burn for mere two minutes, all-solid rockets may be unsuitable for delicate payloads because of fast g-force buildup.

That's what KSP gets wrong. From Wikipedia page on Shuttle design: Mind that a solid rocket motor is tonnes of highly volatile material that can set off from any spark, so handling SRBs is quite an issue. Compare that to kerolox - kerosene is easily stored and handled, and liquid oxygen is produced on-site. Another issue is that solid rocket fuel consists of granules of oxidizer (typically ammonium perchlorate) and fuel (aluminum powder) mixed in a polymer binder. If those granules are mixed unevenly, the whole thing may go kaboom in flight. And even if mixing is OK, solid fuel does not burn as smoothly as liquid one, so SRBs are infamous for high vibration level. On top of that, you cannot do a static fire test on an SRB and then put it on a launch vehicle - it needs at least be refurbished (or, basically, made from scratch). So, nope, solid rockets aren't as cheap compared to LF rockets as KSP teaches us.

The good thing about the in-game node:deltav is that it's adjusted accordingly by the game engine, so rotating frame does not matter. The game also updates node:deltav with the progress of the burn Your code for calculation of the remaining dV for ejection seems sane. For a "node without a node", might be an easy-to-implement solution. There is also a solution used on shuttles as "external Lambert DeltaV routine" - constantly recalculate a trajectory that starts at current vessel position and intercepts the target object, obtain dV to change to that trajectory and steer to that dV vector. This is obviously more complicated but quite doable if you can implement an intercept solver (Lambert's problem, one of the solver algorithms is described on the Braeunig's page). On the rotational speed: the frame does 360 degrees in the sidereal period of body (5h 50-something min for Kerbin). This means, if you have a fixed object on surface of planet, then (ship:body:position - object:position) will always output the same vector. This also means that the rate of change of ship:body:position is consistent with ship:velocity:surface in the rotating frame and ship:velocity:orbit in the inertial frame. When the ship gets above the rotating-to-inertial transition altitude, ship:body:position remains continuous, as far as I can tell. That means, coordinate axes do not suddenly align with the SolarPrimeVector on the transition. If you get a ship to a high altitude and query SolarPrimeVector from kOS, you will most likely see it's not V(1,0,0) but more like V(cos(a),0,sin(a)). It's just that it does not change in time at high altitudes at appears rotating (in fact, it's coordinate axes that are rotating) at low altitudes. So, if you have a vector in SolarPrimeVector frame, you still need to convert it to the kOS frame, but then you can use the converted vector indefinitely without worrying that it stops representing the correct direction. I'm not sure whether transition altitude is the same for all bodies or not. Most likely, it's different. I know for sure the transition altitude is not 100 km on the parent body in scaled systems. V(0, 1, 0) is universal, that is correct, just note that ecliptical plane in modded systems is not necessarily normal to this vector (most notable example is RSS). Kopernicus devs can probably better comment on this topic, if you are really interested. Just the orthogonal projections to the newly chosen coordinate axes. We know that SPV = V(SPV:x, SPV:y, SPV:z) by definition, we also assume that SPV:y = 0, meaning SPV lies in the equatorial plane, and SPV:x^2 + SPV:z^2 = 1, meaning SPV is a unit vector. Given that assumptions, the projection of any vector onto SPV is VDOT(oldVec, SPV) = oldVec:x * SPV:x + oldVec:z * SPV:z. This is exactly the X component of the return vector in question. The direction SPV2 orthogonal to the SPV in the XZ plane may be either V(-SPV:z, 0, SPV:x) or V(SPV:z, 0, -SPV:x). I opted to make [SPV, SPV2, V(0,1,0)] a right-handed triplet, so I chose SPV2 = V(-SPV:z, 0, SPV:x), another option will give a left-handed triplet. VDOT(SPV2, oldVec) is the Y component of the return vector.

There's an example script for that that works like a charm in most cases: https://ksp-kos.github.io/KOS/tutorials/exenode.html On other questions: SPV is not a pre-defined variable but hey, I can name a parameter of a function whatever I want. It's an optional parameter, so if none provided it will take SolarPrimeVector which is a pre-defined variable. V(0,1,0) always points to the "Celestial north pole" of Kerbin, and all bodies in stock game or any planet pack (except when Principia is installed) have collinear axes of rotation. That's how KSP's engine is designed. Orbital planes differ, however, so all bodies have axial tilt exactly equal to the inclination of their orbits to the in-game XZ plane. The reason why ecliptics in RSS has such weird inclination is to mimic real-life Earth's axial tilt to the ecliptic plane - RSS devs could not tilt Earth axis, so they tilted the orbital plane. As for using right-hand coordinates, I used those functions for reproducing Shuttle PEG guidance algorithm, and all the vector products in the papers I took it from are in right-handed system. Converting vectors from kOS to a right-handed frame required less mental acrobatics than figuring out the correct order of operands every time I had to code an equation with a vector product.

The reference frame below 100 km at Kerbin is rotating, and inertial above. That means, if you set NodeVel at one moment when ship is below 100 km and plot it some significant time later, the vector would be off because coordinate axes have rotated. The workaround I use is to express vectors in a coordinate frame where X axis is SolarPrimeVector, Z axis is V(0, 1, 0) (guaranteed to be the same direction in game) and Y axis is vcrs(SolarPrimeVector, V(0, 1, 0)). Respective functions to convert a vector to and from that reference frame: function toIRF { // changes to inertial right-handed coordinate system where ix = SPV, iy = vcrs(SPV, V(0, 1, 0)), iz = V(0, 1, 0) parameter oldVec, SPV to SolarPrimeVector. return V( oldVec:x * SPV:x + oldVec:z * SPV:z, oldVec:z * SPV:x - oldVec:x * SPV:z, oldVec:y). } function fromIRF { // changes from inertial right-handed coordinate system where ix = SPV, iy = vcrs(SPV, V(0, 1, 0)), iz = V(0, 1, 0) parameter irfVec, SPV to SolarPrimeVector. return V( irfVec:x * SPV:x - irfVec:y * SPV:z, irfVec:z, irfVec:x * SPV:z + irfVec:y * SPV:x ). } With this, you'll need to SET NodeVel to toIRF(VELOCITYAT(SHIP , TIME + MyNode:ETA):ORBIT). to have the velocity vector in an inertial frame. To plot it, you need to convert that vector back to the standard reference frame: SET NodeVelDraw TO VECDRAW(). SET NodeVelDraw:SHOW TO TRUE. SET NodeVelDraw:STARTUPDATER TO {return POSITIONAT(ship, Time + MyNode:ETA).}. SET NodeVelDraw:VECUPDATER TO {return fromIRF(NodeVel).}.

I must follow the equations, more or less. Thing is, drag coefficient Cd itself depends on the airspeed, so it's not exactly that easy.

Depends on what you are trying to launch and whether you have FAR installed. Lack of fairings can certainly be the reason. Starting from 1.2.2 at least (maybe 1.0.X, don't remember), the craft has to be streamlined to fly in a stable manner, so launching something with a blunt top is definitely not the best idea. With FAR, this is even more pronounced.

@RagnarDa Q is dynamic pressure measured in atmospheres. To convert between the units, you need to know in what units you calculate everything. In your case, density of 1.18 is in kilograms per cubic meter, so 4737 is in (kg / m3) * (m2 / s2) = pascals (Pa). 0.04116 is in atmospheres, 1 atmosphere is 101325 Pa or 101.325 kPa (1 kPa = 1000 Pa). So, the value you get from kOS is 4171.1 Pa, pretty consistent with 4737 Pa from your first estimate.

Well, there will be an upper bound realistically because rockets cannot accelerate instantly (google "brachistochrone" and "torch drive"). But it is ridiculously high to the point it's absolutely impractical gameplay-wise. There might also be a minimax value, meaning that we can calculate minimum deltaV for transfer initiated on specific date and choose the date that has maximum value of such minimum. That deltaV would guarantee that it is possible to reach your destination starting whenever you like but still leaves a room for making mistake you won't be able to recover from.

So, a reusable aerospike SSTO. Too good to be true?

@eberkain ON and WHEN ... THEN triggers only work while the main script is running. Are you sure you activate AG while script is running? To make sure, you can always add WAIT UNTIL FALSE to the end of the main script, effectively putting it into an endless loop.

@scimas, @kcs123 Note on rotations. R(Pt, Yw, Rl) rotates first Pt degrees around global X axis, then Yw degrees around rotated Y axis, then Rl degrees around rotated Z axis. And R(Pt1, Yw1, Rl1) + R(Pt2, Yw2, Rl2) = R(Pt1 + Pt2, Yw1 + Yw2, Rl1 + Rl2). From this, you can readily see that adding R(0,0,Rl) to any rotation induces additional roll angle. In case of R(Pt1, Yw1, Rl1) * R(Pt2, Yw2, Rl2), rotations are done right to left. I will try to explain what happens in this case. Let istar, itop and ifore be the unit vectors of the rotated coordinate system and ix, iy and iz unit vectors of the global coordinate system. Initially, those triplets coincide. After each rotation, starting from rightmost, the whole space rotates to match global (ix, iy, iz) with the unit vectors defining R(Pt, Yw, Rl) rotation. With each rotation, istar, itop and ifore rotate as if they are nailed to the space. So, SHIP:FACING * R(20,0,0) is the orientation of the ship pitched down 20 degrees, where by "pitch" I mean rotation of the ship around its starboard vector. R() + R(0,0,roll) must be the same as R() * R(0,0,roll), at least my kOS terminal tells me so.

@kcs123, NORMALIZED suffix is redundant for direction components as they already are unit vectors (saves a few bytes in script and some IPU).

The problem when you want some deltaV for guaranteed transfer from A to B is there's no upper bound, really. Subway map gives you dV requirements that guarantee that you can in principle travel from A to B with them. However, you may want to have a ridiculously fast travel (say, 1 hour from Kerbin to Duna) and there will be trajectories with that time but they have ridiculous deltaV requirements. You may want to check Transfer Window Planner mod or web-based Launch Window Planner http://alexmoon.github.io/ksp/ to see how timing the launch and time-of-flight affect the mission deltaV requirements.

That is correct. When you know two true anomalies (i.e. angles from Pe direction), you can easily calculate the difference in mean anomalies which easily translates into the time-of-flight. I'm assuming that first burn matches Ap of transfer orbit with the Ap of target orbit. The transfer will take exactly half of the transfer orbit period, which can be calculated from its semimajor axis. And uh-oh, I forgot to say in the previous post that you have to match apoapses by the first burn for fuel-optimal transfer. This also means that, in general case, you have to split the burn at the transfer orbit Ap to match phases, just the same as in the second case.

Not true. The best explanation I managed to find so far (from Levantovsky): Specific impulse is, by definition, the impulse produced by burning unit weight of fuel in an engine. Impulse is measured in Force × Time units, so the units for specific impulse should be Force × Time / Weight. Since weight is a kind of force, the unit of specific impulse is the same as the unit of time. With the introduction of SI in 1960, force is measured in Newtons, and someone clever also noted that it's more natural to specify impulse per unit mass of fuel instead of weight, so the specific impulse becomes the same as the effective exhaust velocity (for rockets, not jets) and should be measured in m/s.

Assuming the initial orbit is circular, there are following cases: Orbits are coplanar Orbital planes are different, target orbit semimajor axis lies on the node line Orbital planes are different, target orbit semimajor axis does not lie on the node line I'm also assuming that initial orbit is lower than target orbit. In the first case, you need to time the first burn to arrive at Ap at the same time the target does. To calculate time to apoapsis for arbitrary orbiting object, you have to use the concepts of mean anomaly and mean motion. Mean motion is the average angular speed of an object in orbit (360° / orbital period), and mean anomaly is time since last periapsis divided by the mean motion. Thanks to Kepler's equation, mean anomaly can be expressed as a function of true anomaly, and from it one can easily get time to apoapsis. In the second case, first burn is to match apoapses in the node opposite to AP, second burn at AP ideally combines matching periapses and inclinations. To get the rendezvous, you'l probably need to split the second burn in two. The second burn raises periapsis to get close approach at the next AP pass and partially corrects inclination, the third one finishes matching orbits. In the third case, first burn is on the side opposite to the highest node of the target orbit to raise the AP, then basically the same procedure of split burn to match orbits and phases but with more trigonometry involved. Also, highly recommend Braeunig website. It has lots of useful information on orbital mechanics and calculation of transfers.