Finding normal vector to arbitrary orbit

[Aristarchus]

Hi All,

I am trying to write a KOS script that can automatically match an arbitrary orbit (like for the launch satellite contracts). The parameters given are: apoapsis, periapsis, inclination, longitude of ascending node (LAN), and argument of periapsis. I am stuck trying to find the normal vector given these parameters. I know I need to take the cross-product of two vectors within the plane, the LAN and Arg. of Per. stand out, but I can't seem to find them. I have been using this image from wikipedia as a guide.

And came up with the following equations for the vectors.

   LAN        ArgPer
x  cos(        cos(b+c)*sin(a)
y  0            cos(a)
z  sin(      sin(b+c)*sin(a)

a=inclination
b=longitude of ascendng node
c=argument of periapsis

But when I try to visualize them they are all over the place, as you can see.

Does anyone have a better way to find the normal, or could perhaps help me with my equations? My code is below if it is of interest.

Thanks,

A

clearvecdraws().

//Create a vector to center of kerbin
set geo to kerbin:position.
set geo:mag to (ship:altitude/2).
//print geo:mag.
//SET anArrow2 TO VECDRAW(V(0,0,0),geo,RGB(0,0,1),"Geo?",5.0,TRUE).

//Draw global axes for frame of reference
//                      /startPos/ /vector/  //color//        /label/  /size/
set xAxis to VECDRAWARGS( geo, V(200000,0,0), RGB(1.0,0.5,0.5), "X axis", 5, TRUE ).
set yAxis to VECDRAWARGS( geo, V(0,200000,0), RGB(0.5,1.0,0.5), "Y axis", 5, TRUE ).
set zAxis to VECDRAWARGS( geo, V(0,0,200000), RGB(0.5,0.5,1.0), "Z axis", 5, TRUE ).

//readin standard orbrit parameters
set a to ship:obt:inclination.
set b to ship:obt:LAN.
set c to ship:obt:argumentofperiapsis.

//I am naturally thinking of the xy plane being equatorial and z axis through the 
//poles but kos run z axis through poles so I might still be thinking of this step wrong
//set b to 360.
//x=r*cos(theta)*sin(phi)
//y=r*sin(theta)*sin(phi)
//z=r*cos(phi)
//theta=incl
//phi=LAN

//this table summarizes my vector equations.
//so LAN      ArgPer
//x  cos(   cos(b+c)*sin(c)
//y  0           cos(c)
//z  sin(   sin(b+c)*sin(c)

//            x     y   z
set lan to V(cos(,0,sin().  //LAN runs through the equatorial xz-plane
set lan:mag to 200000.
SET anArrow TO VECDRAW(geo,lan,RGB(1,0,0),"LAN?",5.0,TRUE ).

//The argument of periapsis is tilted into the y plane by the inclination, 
//the angle appears to be measured from the LAN
set argper to V(cos(b+c)*sin(a),cos(c),sin(b+c)*sin(a)). 
set argper:mag to 200000.
SET anArrow0 TO VECDRAW(geo,ArgPer, RGB(0,0,1), "ArgPer?",5.0,TRUE).

SET norm to VCRS(velocity:orbit, ship:body:position).
set norm:mag to 50000.
SET anArrow1 TO VECDRAW(V(0,0,0),norm,RGB(0,1,0),"Normal",5.0,TRUE ).

Edited August 4, 2015 by Aristarchus
fix equation

[jkool702]

So I'm not familiar with kOS, but i have an idea you might be able to try. I think the cross product you would need to take is (vector to center of kerbin) x (current velocity vector) (note that these might need to be reversed or else it might be off by a negative sign). You seen to be able to get the vector to the center of kerbin, maybe there is an easy way for kOS to pull up a vector describing your current velocity?

If not, maybe you can numerically approximate it? i.e. make vector from position(@t=t0) to position(@t=t0+eps)?

[Aristarchus]

Thanks for the reply. I just got started with KOS, and am more an aspiring than actual programmer. I am actually just using the vessel orbit as a test case and have found that normal exactly the way you suggested. The problem comes when I try to find the normal to an unoccupied orbit, like what you get when you accept a satellite contract. In that case I only have the five values the game gives. Everything else should be definable from these, but I can't find a match.

Thanks,

A

[FancyMouse]

I don't think argument of periapsis ever matters - inclination and LAN should be enough to determine your normal vector of the orbital plane. I haven't found an easier way to compute (would need to involve an equivalent form of quarternions for 3D rotation and I haven't worked out details), but first try substituting the b,c in your formula with either a,b or b,a?

[Aristarchus]

I have to admit, I am not sure what you are saying, but I did meddle with the angles without any luck. I did find an error in my equation as written, but it didn't solve my problem. I have been focusing on getting the LAN matched, since that only requires one variable. Still no luck though.

[Pecan]

I suspect I'm missing something very important here and am feeling too stupid to see it (excuses: it's very late, I'm very tired and have been to the pub).

'Normal' is 90-degrees to the inclination, rotated by the longitude (of An, or Dn if you want the anti-normal). Radial is a type of tyre. Prograde is what the experts get. Please tell me what the other stuffs about, by PM if it's less annoying to everyone else.

[FancyMouse]

I suspect I'm missing something very important here and am feeling too stupid to see it (excuses: it's very late, I'm very tired and have been to the pub).

'Normal' is 90-degrees to the inclination, rotated by the longitude (of An, or Dn if you want the anti-normal). Radial is a type of tyre. Prograde is what the experts get. Please tell me what the other stuffs about, by PM if it's less annoying to everyone else.

OP understand what normal means. OP is trying to figure out the exact value of the normal vector based on the orbital parameters, i.e. pure math, not just concept of it.

I have to admit, I am not sure what you are saying, but I did meddle with the angles without any luck. I did find an error in my equation as written, but it didn't solve my problem. I have been focusing on getting the LAN matched, since that only requires one variable. Still no luck though.

Try (sin(a)*sin(, cos(a), -sin(a)*cos(). You may need to swap x and z components, and/or flip signs as I can't distinguish from your picture which is x axis and which is z axis, nor their directions.

Edited July 30, 2015 by FancyMouse

[Pecan]

OP understand what normal means...

Anyone understand what "I suspect I'm missing something very important here..." means?

Like, amongst all this learned discussion of vector maths; how come I only see what look like scalars?

You've made my head hurt now because I tried to read that code. Is that KOS these days?

[FancyMouse]

Anyone understand what "I suspect I'm missing something very important here..." means?

Like, amongst all this learned discussion of vector maths; how come I only see what look like scalars?

You've made my head hurt now because I tried to read that code. Is that KOS these days?

I did read that and I tried to clarify things to you as objective as I can. Sorry if it still sounds offending to you and I didn't mean that.

I don't feel anything strange about that piece of kOS code, but I admit I go into this world pretty late - in fact, I've been in this game for just several months and I don't know how kOS used to be.

[mhoram]

An other way to get vectors that are in the orbital plane is to use the current Position and Velocity vector of the ship relative to the planets core. Both vectors are within the orbital plane and can be used for the cross product.

[Aristarchus]

Anyone understand what "I suspect I'm missing something very important here..." means?

Like, amongst all this learned discussion of vector maths; how come I only see what look like scalars?

You've made my head hurt now because I tried to read that code. Is that KOS these days?

Please don't judge KOS based on my crummy programming ability. I have a little experience but I am far from experienced and have rarely needed to display my code. The challenge I am having is how to create the vectors given the scalar properties of the orbit. Once I have that it is just a matter of taking a few cross-products to find the orbital nodes.

Try (sin(a)*sin(, cos(a), -sin(a)*cos(). You may need to swap x and z components, and/or flip signs as I can't distinguish from your picture which is x axis and which is z axis, nor their directions.

I tried a variation of this equation and got a near miss, so I will keep playing with it and see how it works with different orbits. I have been assuming that the x-axis points toward the reference point, but that assumption might be invalid. If the axis was wrong I should just be off by 90 degrees, not ten. Now my head hurts, but I will figure this out.

Edit: It seems that not only does the x-axis not point in the reference direction, but it doesn't point to anything in particular and is not fixed. So the analytic approach may prove fruitless due to the limitations of KOS and the KSP coordinate system.

Edited July 30, 2015 by Aristarchus

[Dunbaratu]

The missing piece of information is what is the Reference Direction of the KSP' solar system, expressed in whatever the current game's XYZ axes are rotated to, which varies as you play the game for complex reasons, which is why it's not just always the x axis or always the z axis. The Reference Direction is some arbitrary made-up direction that stays constant (even though if expressed in XYZ coords it won't appear to be constant, because the universe's coords rotation changes every time you ascend/descend to a planet or moon and the game swaps between planet-fixed and planet-rotating modes.) Usually in Astronomy the Reference Direction refers to some distant star that doesn't move much over time relative to our solar system but is findable in a telescope. That's why we're helpless to figure out what it means in KSP - there is no such thing as a distant star on which to base the vector - the universe outside the solar system doesn't exist - that backdrop of stars is just a fake painting.

Without that Reference Direction, the Longitude of the Ascending Node is meaningless, and it's THAT that you need to really answer the question.

In other cases we've been able to get around this problem because there's an object actually in the orbit so you can get the normal by looking at that object's velocity vector and its position vector. This works great for trying to match orbits for a rendezvous or a dock - but for an orbit that doesn't exist on any object yet, you can't get that information.

In digging through the mostly undocumented KSP API over the last hour or so, trying to find anything called a "reference direction" of any sort, I come up with a google hit or two where other modders claim "Planetarium.Right" might be the reference direction of the LAN. If so, then at the moment you're out of luck because kOS doesn't expose that information to scripts. But if the mysteriously named "Planetarium.Right" is the undocumented secret reference direction of the orbital parameters, then kOS should be updated to expose it, as it is necessary information for the rest of the orbital parameters it returns to be complete.

I've made an issue for this over on the kOS GITHUB site. But I don't know how long it will be before a release containing it is out:

https://github.com/KSP-KOS/KOS/issues/1116

- - - Updated - - -

An other way to get vectors that are in the orbital plane is to use the current Position and Velocity vector of the ship relative to the planets core. Both vectors are within the orbital plane and can be used for the cross product.

The difficulty the OP is having is that in this case there is no such object to get a position and velocity of, because the orbit is a contract parameter defined ONLY by giving the Keplerian values as described. These are the sorts of colored hypothetical future orbits you see in the game when you accept a contract for a satellite but haven't fulfilled it yet and the map view has a colored orbit with nothing in it to help show you were you need to end up. Those sorts of "orbits" don't contain any current object in them.

Edited July 30, 2015 by Steven Mading

[mhoram]

The difficulty the OP is having is that in this case there is no such object to get a position and velocity of, because the orbit is a contract parameter defined ONLY by giving the Keplerian values as described.

Thanks for the hint ... I missed that point.

It is possible to convert Kepler coordinates to Position+Velocity vector. This is a well known procedure.

Here are two documents with the necessary formula:

https://downloads.rene-schwarz.com/dc/category/19

and

http://forum.kerbalspaceprogram.com/threads/93426 (chapter 8)

The best documentation of the kOS reference frames I could find is here:

http://ksp-kos.github.io/KOS_DOC/math/ref_frame.html

But it also does not specify what the Reference Direction is.

[Dunbaratu]

In discussing this with devs, one of the others (hvacengi) did have a way you could use to calculate the Reference Direction indirectly. I consider it a stopgap until a new release is out that just returns the value directly, but for now you can do this:

Even though your intended orbit itself has no item in orbit yet, plenty of other objects do exist in orbit and you should be able to use one of them to get the value this way:

step 1 - Pick any object you like that is orbiting your same SOI body as your intended orbit (i.e. your ship, or maybe the Mun if you're in Kerbin's SOI).

step 2 - Get that object's following orbital parameters: Longitude of ascending node (otherLAN) , Argument of Periapsis (otherAOP), True Anomaly (otherTA).

step 3 - run this calculation: SET UNI_LONG to otherLAN + otherAOP + otherTA.

You now know what the universal longitude of THAT object is right now in it's current position. "Universal Longitude" meaning its angle around its SOI body relative to where the Reference Direction is.

From that, if you like, could could derive the Reference Vector. You know what that object's PLANETARY longitude is on its SOI body, and what its UNI_LONG is - the difference between them tells you how far your SOI body is rotated from the universe's Reference Direction. With that, you can convert the orbital LAN to a planetary LONGITUDE. (remember the planet is rotating so this is only temporarily true for an instant). From a planetary Longitude you can get a GEOPOSITION, from which you can get a XYZ position. That is the position of the Ascending node in XYZ space right now, or at least the position of the surface of the planet underneath it, which is good enough for what you need (it will move, so use it fast to come up with your needed info).

It's a lot of steps and you shouldn't have to go through that, but it may be a while before there's another kOS release so you might have to do this.

I deliberately left the actual code for you to write, because if you're using kOS it's probably because you want to do that sort of thing yourself.

[Aristarchus]

Ok, that makes a lot of sense (sort of). I woke up in the middle of the night last night with a similar idea. Maybe you could let me know if it could work. The only plane that I have absolute knowledge of is the xz-plane. I can cross that with my orbit to find the vector of my ship's LAN and find the angle between that and the x-axis. I can then subtract ship:obt:LAN from that angle to find the angle of the reference vector with respect to the x-axis. From there I just have to add the reference vector angle to the LAN of my target orbit.

I seem to have picked a doozy for my first KOS project, but if the above works I'll feel like a genius.

Thanks again,

A

In discussing this with devs,...

Are you one of the devs for KOS? If so just let me publicly thank you for helping to create a great mod.

Edited July 31, 2015 by Aristarchus

[Dunbaratu]

Ok, that makes a lot of sense (sort of). I woke up in the middle of the night last night with a similar idea. Maybe you could let me know if it could work. The only plane that I have absolute knowledge of is the xz-plane. I can cross that with my orbit to find the vector of my ship's LAN and find the angle between that and the x-axis. I can then subtract ship:obt:LAN from that angle to find the angle of the reference vector with respect to the x-axis. From there I just have to add the reference vector angle to the LAN of my target orbit.

I had originally said you can use any orbiting object, like the Mun, but now that I think of it, the Mun may be a problem given that it is locked on a perfectly zero-incline equatorial orbit. That means its LAN isn't particularly meaningful. I suspect the floating point math will be most stable if you use an object that has the best of both worlds, being both inclined (unlike the Mun), and locked on rails (unlike your ship). Minmus would fit the bill well I think.

Are you one of the devs for KOS? If so just let me publicly thank you for helping to create a great mod.

One of them. I did a lot of work a few months ago - adding functions and local variables, and a few months before that, adding executable suffixes (previously suffixes were passive members that can't take arguments) - but lately I've slowed down a bit and the next update likely won't have a lot of my own work in it. I'm in danger of leaving it too long so I'm starting to forget the archetecture and get rusty. I've got to pick a project and dive back in again.

[Sharpy]

Of course not an answer to what OP is asking, but in case someone finds this topic searching for an answer not for script but in game:

Just pull the Normal marker until it starts "wiggling" switching sides between normal and antinormal rapidly. The resulting orbit is perpendicular to current.

[tomf]

using the PE vector is going to give you problems it it happend to equal the ascending node. Would you be better of taking the vector (0,0,1) and doing the matrix operation to rotate it by tyhe inclination value around the LAN vector?

[Dunbaratu]

using the PE vector is going to give you problems it it happend to equal the ascending node. Would you be better of taking the vector (0,0,1) and doing the matrix operation to rotate it by tyhe inclination value around the LAN vector?

First you've got to get the LAN vector in the first place, which is where the sticking problem was. LAN is expressed in degrees rotated from the universal reference direction, but that universal reference direction is hidden from a kOS script at the moment (although there's a messy way to derive it if you have an orbiting object to use to reverse engineer what it is).