eta:ascendingnode and eta:descendingnode

[ghost]

Any chance you fabulous people could add these two? ...or tell me I've missed somewhere else I can find the info :) ship:obt:inclination is nice but without knowing the ascending/descending nodes I can't really think of anything to change the inclination in an efficient manner.

[erendrake]

I should have added Longitude of the ascending node or LAN, that would let you calculate a lot more than just the ETA to AN or DN. Would that suffice?

Looking at the KSP code i am not sure where the origin of LAN is. i will have to experiment with it

in other news i think ill also add argumentOfPeriapsis meanAnomalyAtEpoch

i think that giving all of the Keplerian elements and orbital state vectors of orbits gives you choice as to how you want to calculate your orbits.

[SolarLiner]

Yeah sure, DN is just LAN+-180

[Dunbaratu]

Is it Longitude by the body's reckoning or is it longitude by the kerbal universe (which uses some unspecified direction in space as the basis).

[erendrake]

@Dunbaratu in real life it is based on the http://en.wikipedia.org/wiki/First_Point_of_Aries as the vernal equinox but with Kerbin having no axial tilt i am not sure what point they pick. I/We will have to experiment with it :)

[ghost]

@erendrake if you give us all Keplerian elements that'd be perfect of course. But please also add eta:AN and eta:DN for ease. I really want to avoid KSPs rotating frame of reference whenever possible ;)

[baloan]

@MrOnak: have a look at the incnode script at http://ud.baldev.de/ksp/kos/mtkv3. It should do what you want. It works by using the angular momentum vectors as a basis for determining inclination and calculating maneuver node eta/direction. The script is tested for Kerbin/Minmus transfers only but should be easily adaptable for interplanetary transfers. I recommend drawing a diagram of the vectors involved (body position and velocity, angular momentum before & after maneuver, deltav and angular momentum change/torque) to understand what is going on. You can watch the script in action at 4:45 in this video http://youtu.be/8uRO1GsPrGM.

[Anbalsilfer]

I have to second this request. This feature should be added for convenience. Changing the inclination of an orbit is certainly a common enough usecase to merit its inclusion.

[Dunbaratu]

The KSP API does not provide this directly. It gives the position of the Ascending Node, but there appears to be no way to get a time from a position. You can go the other way and get a position from the time. Which is weird because the game obviously knows how to do it when you click a spot on the orbit to add a node. But its not in the API anywhere I can find it.

[aboyaniv]

hello. I have found how to get the time to An and Dn :

I have added : TIMETOASCENDINGNODE , TIMETODESCENDINGNODE and ECCENTRICITYANOMALY at my local KOS copy to OrbitInfo class at InitializeSuffixes() and it work fine.

AddSuffix("ECCENTRICITYANOMALY", new Suffix(() => orbit.eccentricAnomaly)); AddSuffix("TIMETOASCENDINGNODE", new Suffix(() => { var time = orbit.GetDTforTrueAnomaly((360.0 - orbit.argumentOfPeriapsis) * UnityEngine.Mathf.Deg2Rad, orbit.period); return time < 0.0 ? time + orbit.period : time; }));

AddSuffix("TIMETODESCENDINGNODE", new Suffix(() =>{ var time = orbit.GetDTforTrueAnomaly((180.0 - orbit.argumentOfPeriapsis) * UnityEngine.Mathf.Deg2Rad, orbit.period); return time < 0.0 ? time + orbit.period : time; }));

but I don't know how to do a merge request , it's my first time :-) Is it possible for some one to add this to the code ?

[Dunbaratu]

@aboyaniv : Thanks for the heads-up. I think we should split it out into a separate method call rather than writing an expression that long into the AddSuffix call, but if the solution works, this should be useful.

[abenkovskii]

@Dunbaratu, @erendrake suggested making this calculation in the KSLib.

[erendrake]

I did, I think its a great place to take data that we have exposed and transform it in a shared kerboscript library. @abenkovskii mentioned that there might not be enough data, specifically orbit.GetDTforTrueAnomaly to correctly calculate these?

[hvacengi]

If we were going to implement it, I think I'd prefer a generic function to give you the eta to a given true anomaly. Then the calculation of the desired true anomaly could be in the hands of the user, and could be flexible enough to calculate other useful "nodes".

But I'm not sure something that powerful belongs being exposed outright to the user. It isn't any more egregious than the ability to use velocityat and positionat and essentially is the inverse operation. Maybe I'm just bitter since I spent the last couple of evenings writing a script to give me the eta to a given true anomaly value :wink:

erendrake commented while I was writing, so in response: there is enough data presented now to do the calculation in kerboscript. It probably isn't as accurate as orbit.GetDTforTrueAnomaly but it's good enough for government work.

[aboyaniv]

i have tried to create a kOS script that do the same as orbit.GetDTforTrueAnomaly for the last week but for some reason i was unable to calculate the eccentric Anomaly to be equal ( or even close ) to orbit.eccentricAnomaly using kepler lows . i did it in two ways :

1. eccentricity + mean anomaly (rad) => eccentric anomaly.
2. eccentricty + true anomaly (rad) => eccentric anomaly. i got same results but not the same as KSP.

maybe KSP use some other internal format? If any one what i can upload the scripts for review.

[hvacengi]

Looks like that's the issue is your equations for eccentric anomaly are incorrect. This site lists the full equations: http://www.braeunig.us/space/orbmech.htm#position and an example calculation: http://www.braeunig.us/space/problem.htm#4.13 They work well when true anomaly is known, finding true anomaly from a time delta requires numeric iteration to find eccentric anomaly. Just remember that the example assumes radians, and kOS works in degrees. Also you'll need to account for arccos always returning an angle from 0° to 180°.

It took me until yesterday to figure out I had replaced one of the cos()s with a sin(), but once I had that fixed my script was very accurate.

Good luck!

[aboyaniv]

Hi hvacengi. I know I'm going out of the scoop of this issue , I did try the new script compare to my old script I get the same eccentric anomaly... what am I missing? is that something related to right hand left hand ? Old Function ( got it from WIKI): // ae = eccentricty // af = true anomaly (rad) DECLARE local sinE to ( (sqrt(1 - ae^2)sin(af)) / (1 + ae * cos(af)) ). DECLARE local cosE to ( (ae + cos(af)) / (1 + ae \ cos(af)) ).

DECLARE local bE to ARCTAN2(sinE, cosE). //currnt ECCENTRICITY ANOMALY

New Function (hvacengi recommendation): declare local ecc to Ship:OBT:ECCENTRICITY. Declare local CAnomolyRad to Ship:OBT:TRUEANOMALY * 0.0174532925. ( to rad) declare local E0 to arccos( (ecc+cos(CAnomolyRad )) / (1+ecc*cos(CAnomolyRad )) ). //currnt ECCENTRICITY ANOMALY

[hvacengi]

You need to use degrees instead of radians because kOS uses degrees when calculating trig functions.

declare local ecc to Ship:OBT:ECCENTRICITY.
declare local trueanom to Ship:OBT:TRUEANOMALY.
declare local E0 to arccos((ecc+cos(trueanom))/(1+ecc*cos(trueanom))).
if trueanom > 180 { set E0 to 360 - E0. }

The last line adjusts for the case of angles greater than 180°. Technically it isn't exact, but I haven't taken the time to think about the precise solution. Between the scale of the inaccuracy, and the narrow band where it's a problem it hasn't been high on my priority list.

It's possible your existing calculations are also accurate and just need to be adjusted to use degrees as well. I didn't take a lot of time to review those equations and compare them to my references.

If you want to compare it to what is shown in Kerbal Engineer Redux, you'll need to convert to radians again, because KER currently has a bug where it shows these values in radians rather than degrees.

[aboyaniv]

Thanks hvacengi! i had Deg and Rad variables mixes is the formulas. finally it's working! a kOS function that return ETA for true anomaly deg.

So , what is the decision ?
Can i submit my function to KSLib or you will be adding orbit.GetDTforTrueAnomaly to the kOS system? (or none of the above :smile: )

[FalcoGer]

I'd love to have this, too. I've been trying all day to implement this, but relative to a target, not the equatorial plane.

The best I could come up with is creating a math function to determine the distance of a point to a plane. the plane is defined by a point (orbiting object) and a normal vector (i create that with a cross product of the orbital velocity of the object at one point and then again 1/4 orbital period later). I add the normal vector to the point to determine if it makes it further away (above the ecliptic plane) or closer (below).

with that function I then do a search over the orbit and when the sign flips from below to above or the other way around I have my AN/DN in regards to the target.

First I tried a binary search over half an orbit. But then I realized that it's possible for both AN and DN to be closer together (in time) if they're near the PE.

It's a major pain in the butt so far...

[nuggreat]

There are functions in the library lib_navigation.ks for calculating the angle from the ship to the AN or DN, target or equator depending on the function. With the angle it is a strait forward to apply anomaly calculations and arrive at the ETA to the AN or DN.