Pand5461

Members
  • Content count

    314
  • Joined

  • Last visited

Community Reputation

174 Excellent

2 Followers

About Pand5461

  • Rank
    Sr. Spacecraft Engineer

Profile Information

  • Location ☆☆☆☭

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

Enable
  1. Pand5461

    how to win this contract

    No, they mean you can't unlock science nodes that cost more than your building allows. With resource transfer unlocked, you can transfer liquid fuel/oxidizer/monoprop/ore/xenon/electricity between tanks (or batteries, in the case of EC). Maybe not critically needed right now for you, but will be required when you start building bases and get contracts for resource delivery. I suggest taking rescue, rendezvous and EVA. They will be accomplished in the same mission. Overall, taking several contracts that can be done in one launch is a good idea, especially with expendable rockets (I know, they are not trendy these days but reusable rockets are not readily available in the early game and even in a late game require more attention than expendable stuff). Oh, and don't forget solar panels and monoprop for the rescue mission. Before you get proficient with rendezvous, you're going to spend lots of EC and RCS fuel.
  2. Pand5461

    how to win this contract

    If you have too much final velocity, you can try throttling down the engines (or setting thrust limiter to a lower value, if it's possible at your current career level). Overall, try not to take contracts that involve crazy Part+Alt+Speed combinations. They usually pay less than you spend trying to complete them.
  3. There is a formula to decide whether a bielliptic inclination change is better than a single-burn: where ra is the ratio of transfer orbit apoapsis (plus the body radius, of course) to the radius of initial circular orbit, i is the inclination change. Consequence: for changes less than 2arcsin(1/3) = 38.94°, single burn is favourable. From 38.94° to 2arcsin(sqrt(2) - 1) = 48.94°, a bielliptic transfer with some finite apoapsis radius is optimal. For inclinations changes by more than 48.94°, a bi-elliptic change with any apoapsis radius will be better than a single-burn change.
  4. Pand5461

    Reaching orbit, Mechjeb vs IRL

    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.
  5. Pand5461

    Getting hit by space debris.

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

    Getting hit by space debris.

    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.
  7. The MM version seems dated. 2.6.6 was released in June 2015, way before KSP 1.2.2 came out (December 2016).
  8. 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.
  9. Pand5461

    Mod to control 2 crafts at same time?

    Edit: Ninja'd
  10. Pand5461

    The Equatorial Minmus Challenge

    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.
  11. Pand5461

    The Equatorial Minmus Challenge

    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):
  12. Pand5461

    The Debate of Solid vs Liquid

    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.
  13. Pand5461

    The Debate of Solid vs Liquid

    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.
  14. Pand5461

    [1.4.1] kOS v1.1.5.2 : kOS Scriptable Autopilot System

    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.
  15. Pand5461

    [1.4.1] kOS v1.1.5.2 : kOS Scriptable Autopilot System

    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.