xeger / kos-ramp

Relatively Adequate Mission Planner: a rudimentary, scriptable autopilot for kOS.
Other
55 stars 23 forks source link

node_alt seems to only work with eta:apoapsis/periapsis or low eccentricity #38

Closed ghost closed 6 years ago

ghost commented 6 years ago
  1. Why was the vom changed from velocityAt(ship,burnTime) to ship:velocity? What could current velocity possibly have to do with some future burn?

  2. Was it tested with other than eta:apoapsis/periapsis with orbit:eccentricity > 0.1 or even greater?

  3. What is the math behind it? I was trying to use similar math to patch node_hoh, still not successful. What crossed my mind was, that if I want to change the orbit at some arbitrary time, then it could be necessary to add radialOut factor.

https://en.wikipedia.org/wiki/Orbital_speed#Precise_orbital_speed v = sqrt(body:mu*(2/r-1/orbit:semiMajorAxis)) but that only gives the magnitude, not the direction, for that you will need tangent, which could have different direction from the original (starting orbit) and that leads to complicated stuff I was not able to crack.

P.S.: Note: The tangent line always makes equal angles with the generator lines (from the point to both foci). Should not be that hard to get the direction (get the angle between generator lines, 180-that, divide by two). Then normalize and multiply with equation above. Substract original speed vector, separate normal, radial and prograde (normal should be zero), add node.

mathuin commented 6 years ago

I was the one that made the changes you mention.

  1. vom was changed because node_apo.ks had local vom is ship:obt:velocity:orbit:mag. and node_peri.ks had local vom is ship:velocity:orbit:mag. both of which are equivalent according to the kOS documentation. All three definitions of vom had the same comment string: // actual velocity. Current velocity is relevant to the future burn because it is used when calculating the future orbit properties.
  2. It was definitely tested with other than eta:apoapsis/periapsis -- I use it for my highly elliptical polar orbit mission -- and I also tested it on multiple missions to Mun and Minmus which I believe use high inclination values but I can't test that at the moment. If you have any craft and mission files which exhibit misbehavior, please share them and I'll be happy to try to figure it out.
  3. http://www.braeunig.us/space/orbmech.htm#maneuver is the source I am using for math here.
ghost commented 6 years ago
  1. Then node_alt was correct and both node_apo and node_peri were wrong. Do you agree?
  2. I am talking about ECCENTRICITY not inclination. It sure works for circular orbits, because the speed is the same everywhere, but that is not true for elliptical orbits.
  3. Yeah, see my Interplanetary Hohmann PR. Look how I now calculate the dV vector and split it to radial,normal and prograde. I thing something like this should be used here as well.
mathuin commented 6 years ago
  1. I'm not sure -- can you explain why node_alt was correct?
  2. I meant to say eccentricity, not inclination. Entering the Munar SOI always seems to involve hyperbolic orbits which by definition have eccentricities in excess of 1. I apologize for my mistake.
  3. The nodes for altering the altitude of the orbit are either prograde or retrograde depending on whether they are raising the orbit's altitude at the far point or lowering it. There is no reason to worry about radial and normal vector components, it's all forward or back.
ghost commented 6 years ago
  1. The deltaV of burn is always the difference between velocity at future time of transfer orbit and the velocity at that future time before burning. Imagine running the script near periapsis (when current velocity is high, e = 0.5 for example) and near apsis (when velocity is lower) .
  2. Ok, but rather think about e = 0.5, highly elliptical.

SCRAP THAT, see next two comments.

ghost commented 6 years ago

The correct code appears to be this:

// Change altitude on opposite side of the burn.
// Default parameters circularize at periapsis.
// NOTE: circularizing at apoapsis by default may sound better but it would crash for e >= 1.

// desired altitude
parameter alt is periapsis.
// time of burn
parameter t1 is time:seconds+eta:periapsis.

// pre-burn conditions
local p1 is positionAt(ship, t1)-body:position.
local r1 is p1:mag.
local v1 is velocityat(ship, t1):orbit.

// prograde, normal and radial-out normalized
local pv is v1:normalized.
local nv is vcrs(v1,p1):normalized.
local rv is vcrs(nv,v1):normalized.

// post-burn conditions
local r2 is alt+body:radius.
local v2 is sqrt(body:mu*(2/r1-2/(r1+r2))) * vcrs(p1,nv):normalized.

// create node
local dv is v2 - v1.
add node(t1, vdot(dv,rv), vdot(dv,nv), vdot(dv,pv)).
// note that vdot(dv,rv) is zero if you burn at peri/apo-apsis
// and vdot(dv,nv) should always be zero (not changing inclination)

Basic Orbit shows eccentricity 0.0000 when I run this with e=0.5993, original was e=0.01. It sets the altitude even if I run it with +600s, the original is unable to do that.

P.S.: Note that there is no current velocity/position involved anywhere, because it is irrelevant. The only thing I do not understand is -body:position, should be -positionAt(body,t1) instead, but that does not work, strange.

ghost commented 6 years ago

I think I know why the script works (at apo/peri): vom^2 = body:mu*(2/r-1/sma1) these two cancel out, completely unnecessery term that was just confusing me. You end up with v2 is sqrt(body:mu*(2/r2-1/sma2)) which is correct.

My version works for any nodeTime (renamed to t1).

mathuin commented 6 years ago

I think I see what you are saying. Thank you for being patient. If you put your code into node_alt.ks and post a PR I will happily test it first before your other code because making this work properly is very important.

ghost commented 6 years ago

Included in #40