kOS Autopilot

[Dunbaratu]

looks like the engine attributes no longer available

Are you trying to do this using a vessel that contains any of the new engines that were added with the KSP 0.23.5 release?

The engine attributes of the new engines doesn't work yet. Do you get the same problem on a vessel only containing parts from pre-0.23.5 KSP?

The new engines don't use the same part type ID as old engines, which means the kOS code doesn't handle them right yet, I think.

[Hyperlynx]

Could someone please add normal and antinormal system variables, please? I send out ion-powered SCANSat probes that need to be in polar orbit to map properly, and manually changing their inclination to 90 degrees takes several hours of work. I'd really like to be able to script that.

Failing that, could someone please tell me how to derive the normal or antinormal from up, prograde and retrograde? I know how to do that if those were vectors, but they're rotations.

[whirlwind]

Are you trying to do this using a vessel that contains any of the new engines that were added with the KSP 0.23.5 release?

The engine attributes of the new engines doesn't work yet. Do you get the same problem on a vessel only containing parts from pre-0.23.5 KSP?

The new engines don't use the same part type ID as old engines, which means the kOS code doesn't handle them right yet, I think.

Yep, I've tested it on vehicle with only LV909 and 48-7S. It's not so greater problem here to write specific impulse explicitly for each challenge. I use it to calculate burn duration. But if something is broken, then may be in other cases it will be a problem.

[Dunbaratu]

Could someone please add normal and antinormal system variables, please? I send out ion-powered SCANSat probes that need to be in polar orbit to map properly, and manually changing their inclination to 90 degrees takes several hours of work. I'd really like to be able to script that.

Failing that, could someone please tell me how to derive the normal or antinormal from up, prograde and retrograde? I know how to do that if those were vectors, but they're rotations.

I dislike the mod doing things for you that are quickly derivable. Normal and anti normal are derivable using vector cross product.

If you take the cross product of any two vectors you get a new vector that is perpendicular to the plane containing both of the two input vectors. The ordering matters, such that given two vectors A and B, A cross B gives you the opposite direction from B cross A. Which one is which depends on if your world consists of a right-handed or left-handed coordinate system in its XYZ axes. I can't remember which way around KSP's world is off the top of my head.

But anyway, to get the normal vector (and anti-normal) just cross-product two vectors that are in your orbit plane together. One such vector is your orbital velocity. Another such vector is your position relative to the SOI body (or it's position relative to you).

So find the cross-product (using recent built-in function VCRS(A, - it used to have to be done by hand which was slow to execute) of the orbit velocity vector and the body position vector. That cross product will be in either the normal or anti normal direction depending on what order you did it in, and multiplying it by (-1) (scalar) will give you the opposite vector.

I don't remember off the top of my head which way around is which, but you should be able to get it from experimentation.

[Dunbaratu]

Is development stalled? I've got pull requests rooted from versions on April 7 and I'm a bit reluctant to add anything more while they're still pending.

[Hyperlynx]

I dislike the mod doing things for you that are quickly derivable. Normal and anti normal are derivable using vector cross product.

If you take the cross product of any two vectors you get a new vector that is perpendicular to the plane containing both of the two input vectors. The ordering matters, such that given two vectors A and B, A cross B gives you the opposite direction from B cross A. Which one is which depends on if your world consists of a right-handed or left-handed coordinate system in its XYZ axes. I can't remember which way around KSP's world is off the top of my head.

But anyway, to get the normal vector (and anti-normal) just cross-product two vectors that are in your orbit plane together. One such vector is your orbital velocity. Another such vector is your position relative to the SOI body (or it's position relative to you).

So find the cross-product (using recent built-in function VCRS(A, - it used to have to be done by hand which was slow to execute) of the orbit velocity vector and the body position vector. That cross product will be in either the normal or anti normal direction depending on what order you did it in, and multiplying it by (-1) (scalar) will give you the opposite vector.

I don't remember off the top of my head which way around is which, but you should be able to get it from experimentation.

I know I could get the cross product and use that. I'd like to get the cross product of prograde and up, but, as I said in my post, they're NOT vectors. They're Euler angles, and I don't know how to work with those. You can't cross product them.

Put another way: how can I get my velocity and/or the position vector of what I'm orbiting as vectors?

[Dunbaratu]

I know I could get the cross product and use that. I'd like to get the cross product of prograde and up, but, as I said in my post, they're NOT vectors. They're Euler angles, and I don't know how to work with those. You can't cross product them.

Put another way: how can I get my velocity and/or the position vector of what I'm orbiting as vectors?

velocity:orbit is a vector.

ship:body:position is a vector, and when you think about it, ship:body:position is effectively a vector in the "down" direction.

And if you need to transform a rotation into a unit vector, there's a way I worked out ages ago but it's ugly. Also, directions like Up now have a ":vector" suffix to get their unit vector. marianoapp claims it only works on some of them, but I haven't found one yet where it doesn't.

Edited April 20, 2014 by Steven Mading

[marianoapp]

Is development stalled? I've got pull requests rooted from versions on April 7 and I'm a bit reluctant to add anything more while they're still pending.

It's not, I just haven't had much free time lately. I'll review your pull requests today or in a few days max.

Also, directions like Up now have a ":vector" suffix to get their unit vector. marianoapp claims it only works on some of them, but I haven't found one yet where it doesn't.

Try with SHIP:FACING

[Dunbaratu]

It's not, I just haven't had much free time lately. I'll review your pull requests today or in a few days max.

Okay thanks. No rush, I just was reluctant to do anything more until I have a better idea of how those parts will be merged in.

Try with SHIP:FACING

Can't we just take the logic of the transformation matrix operation used on this page:

http://kos.wikia.com/wiki/Tutorial_with_example_-_Conversion_from_Directions_to_XYZs

And make that a built-in function?

It should be possible to make any rotation direction into a unit vector even if it didn't start out that way in the code. In order for rotations to make any sense at all they have to start from some presumed default. iIn order to know what it means to yaw or pitch 45 degrees you have to know what direction it started from before applying the 45 degree change. You have to know what direction R(0,0,0) is first before you can tell what R(45,0,0) is.

Experimentally, it seems that locking steering to R(0,0,0) and locking steering to V(0,0,1) always point the same way, making me suspect that the Euler rotations are starting from the unit vector (0,0,1) and rotating it, which is what the code on that wiki page presumes is happening.

Buried somewhere in the Unity docs I saw reference to something saying that the Euler rotation type in Unity presumes a default starting point for the 'zero' rotation if you don't provide one for it, and the presumed starting point is the camera looking "down the Z axis" with the camera's "up" pointing up the Y axis. It looks like this frame of reference is what's used by KSP as far as I can tell experimentally.

On second thought, instead of doing the matrix math in kos's mod code, I think Unity even has a built-in function to retrieve the unit vector of a Euler Rotation, provided you give it the original starting point (the 0,0,0) that the rotation was a rotation from. (if you don't provide it, it presumes it rotated from a starting vector described as stated above).

Edited April 20, 2014 by Steven Mading

[Hyperlynx]

velocity:orbit is a vector.

ship:body:position is a vector, and when you think about it, ship:body:position is effectively a vector in the "down" direction.

And if you need to transform a rotation into a unit vector, there's a way I worked out ages ago but it's ugly. Also, directions like Up now have a ":vector" suffix to get their unit vector. marianoapp claims it only works on some of them, but I haven't found one yet where it doesn't.

Excellent! Thank you.

[Hyperlynx]

Progress so far:

///////////////////////////////////////////////////////////
// polar
//
// establish polar orbit.
///////////////////////////////////////////////////////////

//NOTE: circularise in a separate file.

print "Beginning polar orbit sequence.".

set startTime to time.

set burnTime to 30.

//http://space.stackexchange.com/questions/3543/why-is-it-best-to-perform-an-orbital-inclination-change-at-apoapsis says it's most efficient to change inclination at apoapsis

//TODO: figure out how to tell whether it's better to go normal or antinormal?

lock steering to VCRS(ship:body:position, velocity:orbit). //normal

//TODO: work out warpCooldown using orbital speed and time warp, rather than hardcode.

if altitude > 70000
{
  set warpFactor to 3.
  set warpCooldown to 20.
}.

if altitude > 120000
{
  set warpFactor to 4.
  set warpCooldown to 57.
}

set burns to 0.

//TODO: need to work out how to stop it from burning if it does reach polar orbit mid burn
until ship:obt:inclination > 89
{
  set warp to warpFactor.
  wait until eta:apoapsis < burnTime/2 + warpCooldown.
  set warp to 0.

  wait until eta:apoapsis < burnTime/2.
  lock throttle to 1.
  wait burnTime.
  lock throttle to 0.
  wait 1. //for ship to throttle down, so we can warp.

  set burns to burns + 1.
}.

print "Polar orbit achieved in " + (time - startTime) + " seconds, " + burns + " total burns.". //time doesn't mean much, because of time warp...

[whirlwind]

How to get the periapsis argument and AN longitude? Right now I just scan and write when ship moved over PE/AN/DN but this method inapplicable for work with non celestial bodies or for very long orbits.

[Dunbaratu]

How to get the periapsis argument and AN longitude? Right now I just scan and write when ship moved over PE/AN/DN but this method inapplicable for work with non celestial bodies or for very long orbits.

In general this is a variant of the math problem "find the line of intersection between two planes." That line of intersection is where the ascending and descending nodes are. In this case the two intersecting planes are your oribtal plane (which can be found by the normal vector obtained by a cross product of orbital velocity and ship's position relative to the planet), and the plane defined by the planet (or moon)'s equator, which always happens to be the XZ plane.

That's just a hint to help. I don't remember the answer myself right now but it should be findable with some google searching.

But what you actually want is MUCH harder to calculate. You don't just want to know the position of the AN and DN, but how long it will take you to get there. And there's a reason those math answers are not readily available to come by with a bit of searching. It's because that's actually a hairy *ugly* math problem. If your orbit is perfectly circular then it's easy. But if it's any arbitrary eccentric ellipse then forget it. Calculating how long it will take you to get to a location on your orbit path typically involves running a numerical approximation algorithm rather than having a nice perfect analytical answer. This is a thing that KSP itself does under the hood, and it's why predictions of ETA times are a bit fluttery. There's a tradeoff between accuraccy and speed where to give a properly static precise answer would require running the algorithm too long for speedy updates in the user interface.

But if you *really* want to do it, and *really* want to jump into the hairy math, here's a link to look at: http://mathworld.wolfram.com/KeplersEquation.html

A solution that might be easier to implement is instead of trying to calculate the ETA, is to realize that you really only want to know when the ETA is getting close to zero so you can do your burn then. To a certain extent, you don't care if the program can figure out whether the intersection is 5 minutes versus 15 minutes away. What matters for making the algorithm work is that the program needs to know the difference between and ETA of 0 and and ETA of 20 seconds or so. So perhaps you can work it out by monitoring a math expression that will tell you if you are or are not at the AN right now, and saying something like "wait until this vector is pointing in nearly the right direction" instead of "wait until such and such a time."

For example, if you can find the line of intersection of the two planes, as described above, then you'll be on that line when your position vector relative to the planet' center is perfectly parallel to that line, which you can work out from the dot product of the two vectors.

[whirlwind]

Thanks for the detailed answer. I've imagined that this is not an easy task. But since the KOS works not so fast, it would be great if these values were taken from the KSP or such complex calculations were implemented in C#. These parameters are an integral part of the orbital parameters. It would be great to get these things in future releases.

[baloan]

Hi, I've installed https://github.com/KSP-KOS/KOS/releases/download/v12.0/kOS.zip on KSP 0.23.5 (a.k.a. ARM) to check for regressions on my original scripts.

Only when I want to bring up the terminal to run programs I see a grey area instead. The terminal window is not working.

Bug, feature or am I missing something?

[erendrake]

Hi, I've installed https://github.com/KSP-KOS/KOS/releases/download/v12.0/kOS.zip on KSP 0.23.5 (a.k.a. ARM) to check for regressions on my original scripts.

Only when I want to bring up the terminal to run programs I see a grey area instead. The terminal window is not working.

Bug, feature or am I missing something?

Do you have remotetech installed? I was fighting a bug right in the end with RemoteTech and i thought i had it licked.

Update: Updated the release with some code i forgot to include. This is exactly why i put it up on Github first

Edited May 1, 2014 by erendrake

[erbmur]

Does anybody know what the situation is with Kos in terms of its integration with remotetech?

I guess what I am really interested in is it's interaction with the signal delay side of things. Does it take into account the signal delay when running code, or being a computer on the probe, will it run in real time regardless of how far away it is from Kerbin? And I guess on the side, does this also mean that it will continue to run if it looses connection and just carry on running the onboard code?

[Dunbaratu]

Does anybody know what the situation is with Kos in terms of its integration with remotetech?

I guess what I am really interested in is it's interaction with the signal delay side of things. Does it take into account the signal delay when running code, or being a computer on the probe, will it run in real time regardless of how far away it is from Kerbin? And I guess on the side, does this also mean that it will continue to run if it looses connection and just carry on running the onboard code?

A related question to consider: if kOS ever gets around to implementing keyboard input, should it operate on a lightspeed delay - If ship has no crew, then assume the operator is typing from far away and cannot interact in real-time to prompts on the screen?

[erendrake]

Does anybody know what the situation is with Kos in terms of its integration with remotetech?

I guess what I am really interested in is it's interaction with the signal delay side of things. Does it take into account the signal delay when running code, or being a computer on the probe, will it run in real time regardless of how far away it is from Kerbin? And I guess on the side, does this also mean that it will continue to run if it looses connection and just carry on running the onboard code?

We are just now releasing a version that will allow you to run code if you are connected and it will continue to run if you lose connection. All of the features you are asking for are on the list of things to do.

A related question to consider: if kOS ever gets around to implementing keyboard input, should it operate on a lightspeed delay - If ship has no crew, then assume the operator is typing from far away and cannot interact in real-time to prompts on the screen?

I think that key input should operate with the delay. Delay stuff gets complicated because I believe we should allow you to send commands even if you done have a connection because you might very well have a connection after the delay is finished. I also believe we should have antenna requirements in stock just like science does. I would love to have power drain when you are using the antenna, just like science does.

We have an endless amount of work to do. Job Security i guess.

[Dunbaratu]

We are just now releasing a version that will allow you to run code if you are connected and it will continue to run if you lose connection. All of the features you are asking for are on the list of things to do.

I think that key input should operate with the delay. Delay stuff gets complicated because I believe we should allow you to send commands even if you done have a connection because you might very well have a connection after the delay is finished. I also believe we should have antenna requirements in stock just like science does. I would love to have power drain when you are using the antenna, just like science does.

We have an endless amount of work to do. Job Security i guess.

It's sounding like user input is going to probably be a dedicated release target unto itself at some point. There's enough bits and pieces that go along with it to make it worth dedicating a release entirely to it alone.

The light speed delay issue gets back to a thing I was thinking about before about user input: There's really two types - blocking line-at-a-time and immediate key-at-a-time. And there's useful places for both. There's times when blocking line-at-a-time input is more logical ("Please type the name of your landing site, captain:"), and places where key-at-a-time input is more logical ("Press A to abort program and return to manual control at any time."). I am picturing that a remote mission in which there's no crew on the craft would be effectively restricted to the line-at-a-time type of input, because key-at-a-time would mean waiting several minutes between key presses, while line-at-a-time would allow you to type it all and hit enter and only wait after that.

[baloan]

I reinstalled and it works now. Some feedback:

1. When a script stops with an error message I miss a "script stopped" message. If I remember correctly the previous version would say something like: "script aborted in line <n>". Works for syntax errors but not for errors like the below "suffix not found".

2. body has to be changed to body:name (not a big deal)

3. Node semantics have been changed

set nd to nextnode.
print nd:apoapsis.
Suffix APOAPSIS not found on object.

How to migrate apoapsis for nodes?

[erendrake]

I reinstalled and it works now. Some feedback:

1. When a script stops with an error message I miss a "script stopped" message. If I remember correctly the previous version would say something like: "script aborted in line <n>". Works for syntax errors but not for errors like the below "suffix not found".

2. body has to be changed to body:name (not a big deal)

3. Node semantics have been changed

set nd to nextnode.
print nd:apoapsis.
Suffix APOAPSIS not found on object.

How to migrate apoapsis for nodes?

in your case it would be

set nd to nextnode.

print nd:orbit:apoapsis.

[/COPY]

The reason for the change is now you have access to all of the rest of the orbit info and if we add more to orbit ( we will ) it will be there for every orbit access method. I think i had listed it in breaking changes but it looks like maybe i missed it, my bad.

[baloan]

in your case it would be

set nd to nextnode.

print nd:orbit:apoapsis.

[/COPY]

Thanks.

The reason for the change is now you have access to all of the rest of the orbit info and if we add more to orbit ( we will ) it will be there for every orbit access method. I think i had listed it in breaking changes but it looks like maybe i missed it, my bad.

I found it here https://github.com/erendrake/KOS/releases which seems to be the deprecated project. It seems to me the doc here http://ksp-kos.github.io/KOS_DOC needs a makeover adding all the new features. Or is there another place for the authoritative docs?

[baloan]

The behaviour for stage:liquidfuel has changed. Formerly stage fuel was 0 when empty.

Now it has some residual value:

Easy to fix but not consistent. Breaks my ascent script. Not mentioned in any of the release notes.

Btw: I lost throttle control after aborting the script. Shift and Control didn't work.

[erendrake]

The behaviour for stage:liquidfuel has changed. Formerly stage fuel was 0 when empty.

Now it has some residual value:

http://ksp.baldev.de/kos/screenshots/stage-empty.png

Easy to fix but not consistent. Breaks my ascent script. Not mentioned in any of the release notes.

Btw: I lost throttle control after aborting the script. Shift and Control didn't work.

That does sound like a pretty lame remainder problem, Would you mind adding a bug in the github tracker?

Throttle control locking has a bug that i am actually working on as i post this. You can watch its progress Here: https://github.com/KSP-KOS/KOS/issues/69