[1.3] kOS Scriptable Autopilot System v1.1.3.0

[Snoman314]

For as far as I can tell you are trying to do something with a rotation and a vector and that means getting messed up by the rotational system. I think you are expecting something that it is just not going to do. Look at the new ANGLEAXIS command instead, which is designed to deal with things properly. You also might want to take a look at Steven's video about this stuff. If I remember correctly your question is answered almost literally, in this case with the Mun.

Alright I'll try watching that video again tomorrow. Maybe the third time will be the charm.

[Dunbaratu]

why the F*** Doesn't it work like it's supposed to in the first place?

It works exactly like it's supposed to. The problem is that what it's supposed to do versus what you'd reasonably expect it to from the terminology don't match, and part of that is what is in my opinion a major terminology mistake made by the mod's original author back to the early days before we had our hands on it. What they *actually* do when you say R(a,b,c) is rotate C degrees around the UNIVERSE's Z axis, then A degrees around the UNIVERSE's X axis, then Y degrees around the UNIVERSE's Y axis. These have nothing to do with the ship's orientation at all.

That terminology mistake is this: He chose to call the three components of a R() direction by the names :pitch, :yaw, and :roll. The moment those magic three words are used, people immediately think in terms of a ship-oriented reference frame, and that's utterly wrong.

So the error you're making is this:

- When you thought that dir*vector rotates the vector, you were right.

- When you thought that sun:position is a vector pointing toward the sun from your ship, you were right.

- When you thought that R(90,0,0) meant to rotate around a line that is perpendicular to sun:position, you were wrong.

It rotates around whatever happens to be the X axis of the universe at the time. Because that might not even be perpendicular to the sun's position, it might not *look* like a 90 degree rotation to you. Rotating a vector around an axis that is not perpendicular to it causes the vector to sweep a cone shape, if you can catch what I mean from that.

We can't help that the universe's XYZ axes are weird - that is inherited from KSP itself. And it's useful to have access to a means of rotating around those raw axes directly, which is what the R() tuple does. So it's not that it's not working like it's *supposed* to, but that it does a poor job of communicating to the user what it is that it's supposed to do, because of the awful terminology choice to use the words Yaw, Pitch, and Roll.

Now, with that aside, how do you get what you actually DO want?

What you want is to start from a direction aimed at the sun, and then pitch down 90 from that. Do you mean 90 relative to however your ship is pointed at the time, or 90 relative to the SOI planet, or.....

I have to understand what "down" you meant, and if you tell me I can try to give an example. It may be better to phrase it differently - describe what you want your final orientation to look like- which way is the nose pointed, which way is the top of the ship pointed, and which way are the wings pointed.

Edited January 5, 2015 by Steven Mading

[Deep silence]

I am starting to use kOs, and first of all, thanks a lot for the doc! It might be missing some details (ALT: and ETA: things), a tutorial about vectors, but it is a usefull doc.

Anyway, I am having a problem with a trigger that is rejected as too long, but I do not get why...

The code is the following :

[SOME CODE]

// GRAVITY TURN ////////////////////////////////////////////////////////////////////////////////////////////////////
PRINT "Gravity turn.".
WHEN SHIP:APOAPSIS > targetAltitude THEN {
    PRINT "Circ trigger1.".
    SET step TO "circularization".
    PRINT "Circ trigger2.".
}

LOCK STEERING TO HEADING(90,80).


SET prevEta TO ETA:APOAPSIS.
SET startAlt TO SHIP:ALTITUDE.
SET startPitchDif TO SHIP:FACING:PITCH.


// WAIT FOR ORBITREACHED
UNTIL step = "circularization" {  
  WAIT 1. // so that SHIP:ALTITUDE!=startAlt
  PRINT "Grav turn.".

  // adjusts pitch
  SET altDelta TO (targetAltitude - startAlt) / (SHIP:ALTITUDE - startAlt).
  LOCK STEERING TO Up + R(startPitchDif - (altDelta * startPitchDif),0,0).

  // adjusts thrust
  SET newEta TO ETA:APOAPSIS.
  IF newEta < prevEta {
    LOCK THROTTLE TO THROTTLE - throttleDelta.
  } ELSE {
    LOCK THROTTLE TO THROTTLE + throttleDelta.
  }
  SET prevEta TO newEta.
}
[SOME CODE]

And the logs are :

Gravity turn.
Grav turn.
Ran more than 1500 instructions in trigger bodies, etc...

As my triggers are all only one or two lines of code, how is this error possible?

[undercoveryankee]

I am starting to use kOs, and first of all, thanks a lot for the doc! It might be missing some details (ALT: and ETA: things), a tutorial about vectors, but it is a usefull doc.

Anyway, I am having a problem with a trigger that is rejected as too long, but I do not get why...

The code is the following :

[SOME CODE]

// GRAVITY TURN ////////////////////////////////////////////////////////////////////////////////////////////////////
PRINT "Gravity turn.".
WHEN SHIP:APOAPSIS > targetAltitude THEN {
    PRINT "Circ trigger1.".
    SET step TO "circularization".
    PRINT "Circ trigger2.".
}

LOCK STEERING TO HEADING(90,80).


SET prevEta TO ETA:APOAPSIS.
SET startAlt TO SHIP:ALTITUDE.
SET startPitchDif TO SHIP:FACING:PITCH.


// WAIT FOR ORBITREACHED
UNTIL step = "circularization" {  
  WAIT 1. // so that SHIP:ALTITUDE!=startAlt
  PRINT "Grav turn.".

  // adjusts pitch
  SET altDelta TO (targetAltitude - startAlt) / (SHIP:ALTITUDE - startAlt).
  LOCK STEERING TO Up + R(startPitchDif - (altDelta * startPitchDif),0,0).

  // adjusts thrust
  SET newEta TO ETA:APOAPSIS.
  IF newEta < prevEta {
    LOCK THROTTLE TO THROTTLE - throttleDelta.
  } ELSE {
    LOCK THROTTLE TO THROTTLE + throttleDelta.
  }
  SET prevEta TO newEta.
}
[SOME CODE]

And the logs are :

Gravity turn.
Grav turn.
Ran more than 1500 instructions in trigger bodies, etc...

As my triggers are all only one or two lines of code, how is this error possible?

I'd be suspicious of the "LOCK THROTTLE TO THROTTLE + <stuff>" lines. If I remember right, a LOCK is implemented as a trigger-like chunk of code that gets fired whenever any of the variables on the right-hand side change. If you LOCK a variable to an expression that includes itself, an implementation that wasn't testing for that pathological case would likely evaluate the lock recursively.

I'd do something like "SET targetThrottle to <stuff>. LOCK THROTTLE to targetThrottle." and then do the updates as "SET targetThrottle to targetThrottle + <stuff>."

[Dunbaratu]

If you LOCK a variable to an expression that includes itself, an implementation that wasn't testing for that pathological case would likely evaluate the lock recursively.

Yes this causes recursion. LOCK X TO X + 1. It would take a lot of work to change it because in this case X is really a function, not a variable, so there's nowhere for it to actually be temporarily stored while being re-evaluated.

[Deep silence]

You are right, thanks a lot!

[undercoveryankee]

Yes this causes recursion. LOCK X TO X + 1. It would take a lot of work to change it because in this case X is really a function, not a variable, so there's nowhere for it to actually be temporarily stored while being re-evaluated.

I'd be happy with detecting a recursive lock and giving an informative compile-time error. Even if someone had time to overhaul the implementation to do something useful, I'm not sure what usable semantics would be.

[Snoman314]

It works exactly like it's supposed to. The problem is that what it's supposed to do versus what you'd reasonably expect it to from the terminology don't match, and part of that is what is in my opinion a major terminology mistake made by the mod's original author back to the early days before we had our hands on it. What they *actually* do when you say R(a,b,c) is rotate C degrees around the UNIVERSE's Z axis, then A degrees around the UNIVERSE's X axis, then Y degrees around the UNIVERSE's Y axis. These have nothing to do with the ship's orientation at all.

Ahhhh!! Finally the light comes on! Thankyou! Your post should totally be in the documentation.

That terminology mistake is this: He chose to call the three components of a R() direction by the names :pitch, :yaw, and :roll. The moment those magic three words are used, people immediately think in terms of a ship-oriented reference frame, and that's utterly wrong.

So the error you're making is this:

- When you thought that dir*vector rotates the vector, you were right.

- When you thought that sun:position is a vector pointing toward the sun from your ship, you were right.

- When you thought that R(90,0,0) meant to rotate around a line that is perpendicular to sun:position, you were wrong.

It rotates around whatever happens to be the X axis of the universe at the time.

Yep, I get it now. Where I went wrong is here:

In your thinking, you can largely think of Directions as being Rotations and Rotations as being Directions. The two concepts can be used interchangably.

So I then understood that a direction rotated 90 degrees around the X axis, when then applied to another vector as a rotation, would rotate that vector around some X axis perpendicular it, not around the universe's X axis. So obviously (well obviously now I understand that) I need to find a direction that describes a 90 rotation around an axis perpendicular to the sun position vector. I now see the requirement for the new direction functions!

Because that might not even be perpendicular to the sun's position, it might not *look* like a 90 degree rotation to you. Rotating a vector around an axis that is not perpendicular to it causes the vector to sweep a cone shape, if you can catch what I mean from that.

No I get it. As soon as I read your first couple of sentences, it all clicked. I guess I had been too close to the problem for too long, and I kept going back to the same interpretation of the documentation.

We can't help that the universe's XYZ axes are weird - that is inherited from KSP itself. And it's useful to have access to a means of rotating around those raw axes directly, which is what the R() tuple does. So it's not that it's not working like it's *supposed* to, but that it does a poor job of communicating to the user what it is that it's supposed to do, because of the awful terminology choice to use the words Yaw, Pitch, and Roll.

Fair enough. Maybe the documentation could be clarified on this point?

Now, with that aside, how do you get what you actually DO want?

What you want is to start from a direction aimed at the sun, and then pitch down 90 from that. Do you mean 90 relative to however your ship is pointed at the time, or 90 relative to the SOI planet, or.....

I have to understand what "down" you meant, and if you tell me I can try to give an example. It may be better to phrase it differently - describe what you want your final orientation to look like- which way is the nose pointed, which way is the top of the ship pointed, and which way are the wings pointed.

OK, so with all the above in mind, I wrote this:

Print "===============================================".
Print "Orienting to point Solar panels facing Sun".
Print "===============================================".

//The goal here is to get the ship's +Y axis pointing directly at the sun, by pitching down
//by 90 degrees from an (imaginary) start state of pointing at the sun with the ship's roll
//relative to the ecliptic being zero.

SET a TO V(0,1,0). //A vector pointing in the Raw +Y axis direction.
SET b TO SUN:POSITION:NORMALIZED. //A vector pointing to the sun.
SET rotAxis TO VCRS(a, . //A vector (hopefully) pointing to the right as you look at the sun.
// Oops! I had to swap the above as it seems that even the cross product is left handed in KSP.
SET startDir TO LOOKDIRUP(b, a). // A direction pointing to the sun, up oriented towards +Y(Raw).
SET rotDir TO ANGLEAXIS(90, rotAXIS). // A direction that gives the required rotation (hopefully).
SET finalDir TO rotDir * startDir. // The direction I want to be pointing in at the end

LOCK STEERING TO finalDir.

WAIT 60.

Success! Thanks for your help Steven. Both your video, and especially your post in response to my barely filtered frustration.

Edited January 6, 2015 by Snoman314

[Dunbaratu]

I'd be happy with detecting a recursive lock and giving an informative compile-time error. Even if someone had time to overhaul the implementation to do something useful, I'm not sure what usable semantics would be.

Well it already does detect a problem and mentions it - the recursion went on too long and blew past the limit - I don't want to prevent recursion in case there's some weird way it can be useful. What might be better is to improve the "config:IPU exceeded" message to make it show exactly what it was executing when it happened. Then it would at least highlight the LOCK statement that caused it.

[roxtonro]

Hi all,

I just wanted to express my appreciation for the considerable effort you've put into this release of kOS over the holidays. The new documentation totally rocks, thank you very much!

And I must point out Stevens excellent video that finally brought closure to the bane of piloting a vessel .. frame of reference

Can't recommend kOS enough.

Great work guys, Happy New Year!

P.S. For those of you who would like to know what to do with all this funky kOS goodness, refer to PurpleTargets, Krash Test Kerbals.

[postalbyke]

Wow, got really distracted by all the stuff that's happened since I last logged into ksp.com!

Okay, what I'm here for:

I thought of a way to control kOS from Telemachus (stop me if you've heard this one before!)

Create a script that iterates over the Action Groups, taking each one as a bit, and use one (I chose SAS) as a command bit.

If you use all ten AG's, you would have 1024 possible commands. (2^10, right?)

Well, 1023 if you reserve one for manual ship's control.

Regardless, more than enough to keep you on course remotely. If you need something special, ssh in and build a script, then run it as above.

Somebody check my math and logic, I'm pretty sleep-deprived...

edit: more sense...

So instead of "enter," activate SAS, which will cue kOS to look at the current AG setup.

[Dunbaratu]

I am in the middle of researching how to make a KSP mod have a TCP/IP server in it (it's a bit funky because a KSP mod is unable to spawn processes or threads, and normally at least one or the other is required for a correct TCP/IP server of any sort.) I have a plan that I'm trying to work out involving more than one Monobehaviour and their Update()'s behaving like psuedo-threads.

Anyway the point is that I an trying to tackle the problem of the remotable terminal over a TCP/IP socket, like doing a telnet. First I have to JUST see if it's even possible to have any sort of TCP/IP server *at all*.

[TiLorm]

Take a look at this, it hasn't been updated in a while, but it can run a server.

[RadarManFromTheMoon]

I am in the middle of researching how to make a KSP mod have a TCP/IP server in it (it's a bit funky because a KSP mod is unable to spawn processes or threads, and normally at least one or the other is required for a correct TCP/IP server of any sort.) I have a plan that I'm trying to work out involving more than one Monobehaviour and their Update()'s behaving like psuedo-threads.

Anyway the point is that I an trying to tackle the problem of the remotable terminal over a TCP/IP socket, like doing a telnet. First I have to JUST see if it's even possible to have any sort of TCP/IP server *at all*.

I built a TCP/IP server for the KSPTOT plugin a while ago. It is actually possible to spawn threads but since unity/KSP is not threadsafe, the threads must not use unity or KSP functions directly, so I used non-blocking queues to communicate with the main thread. This way you just check every update cycle if there is new data in the "in-queue", and if so, process it and place data for the client into the "out-queue". Works quite well with minimal impact on game performance.

[undercoveryankee]

Another server that runs inside KSP is Telemachus.

A single-threaded server won't be too bad if you can afford to reject additional connection attempts while one client is connected, or if you have access to the C# features for non-blocking I/O. Here's something I was able to find: http://scatteredcode.wordpress.com/2013/04/29/creating-a-single-threaded-multi-user-tcp-server-in-net/

[Camacha]

I see you finally got around to making file names writeable. Very nice!

Edited January 7, 2015 by Camacha

[Parallax]

i think i found my second favourite ksp mod

forget space ships, just kOS+IR by themselves would make for an awsome game

[erendrake]

i think i found my second favourite ksp mod

http://giant.gfycat.com/SafeHandyFirecrest.gif

forget space ships, just kOS+IR by themselves would make for an awsome game

This is a frankly terrifying use of kOS + IR. Im shutting down this mod's development because i am fairly sure someone is going to build skylab in KSP and it will be all my fault

RUNNN!!!!!

[Camacha]

This is a frankly terrifying use of kOS + IR. Im shutting down this mod's development because i am fairly sure someone is going to build skylab in KSP and it will be all my fault

The option for inverse kinematics has always been a goal for kOS, as far as I am concerned. As it stands it is pretty great already, and with a few improvements it could be an amazing tool. I honestly think I might have had a different career if this would have been around when I was younger (though I am pretty happy where I am).

The addition of pilot controls and access to right click menus really opened up some great options Canadarms, walking robots, you name it.

Edited January 8, 2015 by Camacha

[undercoveryankee]

This is a frankly terrifying use of kOS + IR. Im shutting down this mod's development because i am fairly sure someone is going to build skylab in KSP and it will be all my fault

RUNNN!!!!!

Skylab was pretty harmless (unless a piece hit someone on the head when it deorbited). Did you mean Skynet?

[Camacha]

Skylab was pretty harmless (unless a piece hit someone on the head when it deorbited). Did you mean Skynet?

I would hardly call the pieces that came down harmless A numbers game and some luck resulted in no injuries, but that could have been different.

[whiteout1911]

Hey guys, quick question: does kOS work with IR out of the box? If not, what else do I need?

[Dunbaratu]

Hey guys, quick question: does kOS work with IR out of the box? If not, what else do I need?

Yes.

The features talked about in this video

are now in the release and work fine.

The video was made before they were released and the features have changed ever so slightly since then, but the links in the description to the examples code were updated to the new way.

Read down into the comments of the vid to see the changes that occurred after it was recorded. The video makes it look slightly harder than it now is.

[Pyrobladeich]

I am having an issue. When I send a kerbal on an EVA i can't control there RCS thrusters. The thrusters just spin the kerbal around wildly. Any thoughts.

[Dunbaratu]

I am having an issue. When I send a kerbal on an EVA i can't control there RCS thrusters. The thrusters just spin the kerbal around wildly. Any thoughts.

Uhhhmmmm...... what makes you think this is related to kOS?