kOS Scriptable Autopilot System 0.9

[weissel]

This sounds right; executing two scripts on the same unit at the same time is not possible. This is logical; when the unit is busy with the program it is instructed to execute, there is no time for another.

Of course you can run several programs at the same time (or nearly so) on one unit. Both in the real world (time sharing the resource, running on interrupts, see also the Apollo Flight Computer and it's famous overflow) and in kOS.

Look at some code helping to evaluate a gravity turn curve and/or ideal speed curve (for a given craft):

...
lock dircheck to up * R(0,0,180).
lock fyr to facing:yaw - dircheck:yaw.
...
when (airspeed > 2) then { 
    until (altitude > 70000) {
        wait 0.2.
        log round(altitude) + "m, " 
            + round(airspeed,1) + "m/s, " 
            + round(pitch,1) + "deg, (" 
            + round(fyr + 90,1) + " real / "
            + round(pitch - fyr - 90,1) + " off) "
            + round (tVar*100) + "% at "
            + round(missiontime,1) + "s" 
            to gravityturn.
    }
}
...
when altitude > 300 then {
    set pitch to 88.    // get away from the pad!
    sas off.
    lock steering to heading 90 by pitch.  
        //note: DON'T use "heading ... by ..." any more
}.
when altitude > 8000 then {
    lock pitch to 80 - (altitude / 1000 - 8)^0.7 * 3.5.  
        // experimental values, probably really wrong
}.
when (altitude > 39000 or pitch < 10.5) then {
    unlock pitch.
    set pitch to 10. 
}.
...

lock throttle to tVar.
stage.

until (altitude > 30000 or apoapsis > 75000) {
   ... (try for ideal speed) ...
}

... (circularize with external scripts -
     vary prograde in a binary search, 
     then execute node) ...

... (log the amount of fuel left) ...

2 threads running most of the time, a third one pops up at predetermined points and does a bit of work.

In fact, there's another when+until in the original code, printing (pitch) stats every time unit and longer than the other when.

[Dunbaratu]

2 threads running most of the time, a third one pops up at predetermined points and does a bit of work.

In fact, there's another when+until in the original code, printing (pitch) stats every time unit and longer than the other when.

Except those aren't threads. Look at the github code. "when" conditions are inserted checks between statements in a single thread. If you have two pending When checks, and are running statements, you get behavior like this, in a single thread:

Do statement 1.

Check WHEN condition 1.

Check WHEN condition 2.

Do statement 2.

Check WHEN condition 1.

Check WHEN condition 2.

Do statement 3.

Check WHEN condition 1.

Check WHEN condition 2.

etc.

If it was truly multithreaded, then the checks could occur in the MIDST of performing a statement, rather than waiting for the entire statement to end.

i.e. you are guaranteed that in kOS, if you have this statement:

print "value is " + sin(angle) / (x^2+y^2+z^2)^0.5 .

that no WHEN, or ON conditions will interrupt that in the midst of all that calculation of the expression. You know the value will be calculated and printed BEFORE the next interruption.

Because it's executing things in serial, and just inserting the ON and WHEN checks between the lines of code you're running.

[Zander]

There is no pitch function? how are you getting it to return the pitch??? that command isnt in the command reference and isnt working for me.

[Dunbaratu]

Hey all,

We have all lamented the lack of a proper 0.23 release on the spaceport and the OP of the KOS thread. I am getting ready to have my first release of new features and I wanted to get some assistance with testing.

I have posted this pre-release on Github for now

https://github.com/erendrake/KOS/releases/tag/v0.10.0

Thank you for taking up the torch and trying to make a spaceport release for this.

I tried using this new version to recreate my Duna mission from the challenge thread, as a regression test:

Here's my findings so far. I didn't finish the Duna mission because these problems were making it hard to continue:

This one is Critical: The DELTAV component of maneuver nodes is now returning an unusable, unidentified object type.

Previous behavior in 0.9.2:

A maneuver node's DELTAV component is an object of type Vector. It's expressed in KSP's native XYZ coordinate system. This means it can be used directly with "LOCK STEERING TO ...", and you can use a further suffix like :MAG on it.

Behavior in this new 0.10:

A maneuver node's DELTAV component is now an object of type ????dunno. When printed it looks something like this:

[0 , 0 , 9]

I suspect those 3 numbers are the radial-out, normal, and prograde components of the node's delta-V. (It used to be a vector in the native XYZ coordinate system.)

There are effectively 2 things this changes:

1 - The rotation of the coordiante system of the 3 'legs' of the vector is different - now it's rotated to the node's orientation.

2 - The type of the object isn't of type Vector anymore, and whatever this tuple's type is, its not one that kOS allows script writers to make use of. We can't really use this object - can't get at its 3 component parts for example.

#1 is a little annoying, but I could work with it if I had to.

It's #2 that makes this a critical problem. I don't know what the C# type of this object is, but whatever it is, it's not one that has support for kOS script writers to use it, and therefore DELTAV isn't usable in this form.

Was this change of type for DELTAV intentional or was it a mistake?

Annoying but could be workable: The execution speed dropped a LOT. I don't know if this is KSP 0.23's fault or not. As an example of this, in kOS 0.9.2, my brute force guessing algorithm that creates and deletes maneuver nodes created about 2 guesses per second. Now it makes about 1 guess every 4-5 seconds using the same code. I haven't traced down whether it's just one specific line of code that is now slower or if it's just in general all lines are slower.

A bit of new functionality not working: The new command "unset ALL" still left behind some variables in memory that stayed in the persistence file, and prevented reloading the craft. It's not unsetting all the variables.

The ZIP package is 'rooted' in the wrong spot: The standard method of unpacking a ZIP for a spaceport mod is that the user unpacks it into the GameData directory. Your ZIP file contains GameData inside it at the start of the paths, meaning you'd have to unpack it into the root of KSP rather than into GameData. If you unpack it the way you'd expect to (CD into GameData first and unpack it there) then you end up with a GameData inside your GameData, which in turn means the GFX textures aren't where the mod expects them to be and the terminal window doesn't show up.

That's what I found so far. The manuever Node problem pretty much stopped the rest of my testing for now.

[erendrake]

+Steven Mading, Thanks so much for testing this out for me!

This one is Critical

Apologies for that, the node object has a deltav property that is a Vector3d rather than a Vector and i was trying to figure out how useful it would be and left it when I commited

I have reverted the DELTAV keyword back to its 0.9.2 behavior and it will be in the next release. Just FYI there is an existing undocumented BURNVECTOR keyword available that should have the behavior you need till i get it fixed.

Annoying but could be workable

Ill have to investigate all sorts of performance issues KOS has right now. it has a ton of brute force algorithms, for now im going to try and blame it on 0.23

A bit of new functionality not working

Ill have to admit i did not write the UNSET ALL code but instead got it from a pull request, I didnt find the bug you did in my testing so ill see if I cant track it down. if you could give me something shorter than your whole duna mission that produces the same bug that would be a big help!

The ZIP package is 'rooted' in the wrong spot

I wasnt sure exactly where to root the ZIP, It seems like every author has their own style, your suggestion is reasonable.

Edited January 16, 2014 by erendrake

[Dunbaratu]

Ill have to admit i did not write the UNSET ALL code but instead got it from a pull request, I didnt find the bug you did in my testing so ill see if I cant track it down. if you could give me something shorter than your whole duna mission that produces the same bug that would be a big help!

Tomorrow I'll try to see if I can reproduce it with something smaller.

By the way, thanks for the List() datatype. Once it's working well and tested a bit more, one thing I think it would be VERY useful to do with it is to alter all the LIST commands to have them be able to return things of type List(). For example "LIST TARGETS into MyVar."

[Nando]

Tomorrow I'll try to see if I can reproduce it with something smaller.

By the way, thanks for the List() datatype. Once it's working well and tested a bit more, one thing I think it would be VERY useful to do with it is to alter all the LIST commands to have them be able to return things of type List(). For example "LIST TARGETS into MyVar."

kOS dosnt load variables in scientific notations. e.g. 6.674E-11.

[Dunbaratu]

kOS dosnt load variables in scientific notations. e.g. 6.674E-11.

We're aware of that. The bug I was reporting was that the new UNSET ALL command didn't actually unset all the variables. The fact that it left variables in the persistence store file was merely the evidence that made me discover the UNSET bug. Had UNSET ALL unset everything, there shouldn't have been variable values in the persistence store.

Edited January 17, 2014 by Steven Mading

[weissel]

Except those aren't threads. [...]

If it was truly multithreaded, then the checks could occur in the MIDST of performing a statement, rather than waiting for the entire statement to end. [...]

Because it's executing things in serial, and just inserting the ON and WHEN checks between the lines of code you're running.

Not intending any disrespect, but ...

• at what granularity does a "truly multithreaded" system interrupt the execution of one thread for another? And what's the rationale for that exact granularity?
  
• how do you execute things in parallel when you have a single core machine? You do not claim single core machines can't have threads, right?
  
• have you ever benchmarked simple and complex statements in kOS, and looked what happened if when code ran at the same time? If not, you're in for a surprise ...
  
• what do you call these non-threads, btw?
  

[weissel]

There is no pitch function? how are you getting it to return the pitch??? that command isnt in the command reference and isnt working for me.

Kindly read the part where I "set pitch to ..." and, later in the ascent, "lock pitch to ...". "pitch" is a variable containing the pitch I want to archive, not the pitch I currently have. I use "pitch" in "lock steering to heading 90 by pitch." (which is a deprecated way to lock steering).

Since I am only pitching in the yaw axis, I make the pitch I have available as the current yaw angle versus the straight up direction, using:

lock dircheck to up * R(0,0,180).
lock fyr to facing:yaw - dircheck:yaw.

I tried to make that all clear by including all relevant lines in the code snippet. Below 300m I run on SAS btw., that's why I turn it off there.

[Dunbaratu]

Not intending any disrespect, but ...

• at what granularity does a "truly multithreaded" system interrupt the execution of one thread for another? And what's the rationale for that exact granularity?
  

The granularity of the operating systems' own native context switching and process task switching speed - which can interrupt after any machine language instruction. A statement as complex as an expression in kOS can be composed of many underlying instructions. If it was multithreaded then it could interrupt in the middle of executing the expression because the granularity would be on those instructions, not on the high-level language's line of code.

Also, the other reason it's not multi-threaded is that you can't choose to run any arbitrary code that way- you have to pick specifically limited things you can do with WHEN and ON instructions. You can't say "fork a thread and run this arbitrary block of code in it, while this thread continues on and runs this other code."

And even if you think it can still be multithreaded even if the granularity is one line of kos script, it's STILL not multithreaded because the "threads" don't execute interleaved with each other. Consider this example:

WHEN .... THEN do a block consisting of statements A,B,C,and D.

statement 1

statement 2

statement 3

statement 4

If the conditions of the WHEN check were satisfied after statement 1 ran, and it really was multithreading, then you might be able to get this execution to happen in this order:

statement 1

statement A (from the WHEN/THEN)

statement 2

statement B (from the WHEN/THEN)

statement 3

statement C (from the WHEN/THEN)

statement 4

statement D (from the WHEN/THEN)

But you can't get that result. It blocks the execution of the main line program until the entire body of the WHEN/THEN is done, like so:

statement 1

statement A (from the WHEN/THEN)

statement B (from the WHEN/THEN)

statement C (from the WHEN/THEN)

statement D (from the WHEN/THEN)

statement 2

statement 3

statement 4

Edited January 17, 2014 by Steven Mading

[erendrake]

@weissel Nothing in KOS currently runs concurrently, It is all done on a single thread. We might be on our own thread from the rest of KSP but i doubt it.

Edited January 18, 2014 by erendrake
speculation on plugins having their own thread

[Zander]

Can someone please help me. I want to run multiple KOS terminals at the same time which means I want to modify KOS computer parts so that they don't recognize eachother and act independently of eachother. I want to have 4 of them and its ok if they are listed as different names in the VAB (IE: KOS computer 1, KOS computer 2) the important thing is they all execute commands/scripts and run as if the other ones don't exist. I think this should be fairly easy to do by modifying a few lines in the .dll or something. They can all share the same archive.

If someone can do this I would be really grateful and I think a lot of people would be too.

BONUS: if it is additionally possible to make the Individual KOS computers be able to instruct eachother to copy and run programs that would be a huge help but this is just optional. It is not critical to what I need to do.

Ideally I would like to open one computer and run a program on it that instructs the other computers to copy and run different programs.

Edited January 19, 2014 by Zander

[Dunbaratu]

Can someone please help me. I want to run multiple KOS terminals at the same time which means I want to modify KOS computer parts so that they don't recognize eachother and act independently of eachother. I want to have 4 of them and its ok if they are listed as different names in the VAB (IE: KOS computer 1, KOS computer 2) the important thing is they all execute commands/scripts and run as if the other ones don't exist. I think this should be fairly easy to do by modifying a few lines in the .dll or something. They can all share the same archive.

If someone can do this I would be really grateful and I think a lot of people would be too.

While it is supposedly possible to run multiple kOS programs at the same time, and there are examples of launching two rockets at the same time flying together, there is only one kOS terminal at a time in the GUI. So it's very hard to watch the programs run and see what they're doing at the same time. You can't open both terminal windows on both parts. The window is either showing you what part1 is doing, or what part2 is doing, but you can't seem them on the screen at the same time.

[Zander]

While it is supposedly possible to run multiple kOS programs at the same time, and there are examples of launching two rockets at the same time flying together, there is only one kOS terminal at a time in the GUI. So it's very hard to watch the programs run and see what they're doing at the same time. You can't open both terminal windows on both parts. The window is either showing you what part1 is doing, or what part2 is doing, but you can't seem them on the screen at the same time.

Thank you for your reply, Yes I know this, this is why in my post I asked someone who knows how to please make me a modified version of KOS that allows what I want. I think it should be very simple to do.

[Crown]

Hello,

I just downloaded kOS to 0.23 and I can't select the terminal windows. I can close it and toggle power but it stays semi-transparent and I can't type anything. I am sure this is due to the fact that the latest kOS version is for 0.22. But is there a solution to this except from waiting for an update?

edit: Oh, and the downloaded kOS folder is copied into the GameData folder.

Edited January 19, 2014 by Crown
location of kOS folder

[TheDude]

Greetings,

Is it possible for KOS to run on an unfocused ship?

What I'm thinking is to have a rocket with several satellites attached. During flight the rocket will detach a satellite at which point the satellite will start running a KOS script to burn to the right place, execute a circularization burn, shutdown the engine, deploy solar panels, etc. All the while I'm still focused on the rocket while it continues on it's merry way to the next satellite launch point.

Is this possible with KOS?

If so, how do you get the program running on the satellite ?

Best regards,

The Dude

[Zander]

@Crown

download the hotfix on page 241 of this thread.

@TheDude

Kos doesnt work if a vessels' physics are unloaded. The game automatically unloads vessels farther than 2.5km. So you need to download KOS and also download this mod

http://forum.kerbalspaceprogram.com/threads/48720-TT-NeverUnload-Vessel-Unloading-Preventer

follow the instructions for that mod to use it

then place a KOS module on the satelite (or add

MODULE

{

name = kOSProcessor

}

to the part .cfg of the satellite probe core

then before launch open the satelite KOS terminal (by right clicking the kos module or probe core)

type "Copy scriptname from archive." press enter

launch and when you want to release the satelite

open up the satelite terminal again type "run scriptname." press enter

then make sure inside "scriptname.txt" you write the code that releases the satellite and does its orbiting burns and stuff. PM me if you need help writing that.

Edited January 19, 2014 by Zander

[Crown]

@Crown

download the hotfix on page 241 of this thread.

Thanks. Worked.

(Link to the post on page 241)

[Bizz Keryear]

OK, I admit I dropped out and haven't read anything at least from page 234 onwards.

Kevin had not made any form of contact to me anymore and I occasionally see tweets from him (last on 16. Jan. about his apple work laptop)

Anything I have heard about him so far was like I won't come back.

So I think its time to think about kOS reloaded...

[Dunbaratu]

OK, I admit I dropped out and haven't read anything at least from page 234 onwards.

Kevin had not made any form of contact to me anymore and I occasionally see tweets from him (last on 16. Jan. about his apple work laptop)

Anything I have heard about him so far was like I won't come back.

So I think its time to think about kOS reloaded...

You should be aware of these two things:

1. eerandrake is trying to make a version 0.10 for posting on spaceport. See this post:

http://forum.kerbalspaceprogram.com/threads/47399-kOS-Scriptable-Autopilot-System-0-9?p=909908&viewfull=1#post909908

2. woodywood245 is starting over with a from-scratch project called Jebnix to make an entirely new archetecture for it that can support kosscript code, but also do more. That link is here:

http://forum.kerbalspaceprogram.com/threads/65005-Jebnix-A-kOS-Alternative

Jebnix looks very cool, but as a new project from scratch I expect it to take a long time before anything usable comes out of it, and in the meantime having a working 0.10 would be very nice.

[whaaw]

hi

how can i print my nextnode:deltav:mag. it wont work any more i can get the nextnode:deltav. but i need the number:-)

EDit. i compiled newst version from erendrake by myself solved the problem.

commit: GITHUB

Edited January 20, 2014 by whaaw

[Crown]

[...]Anything I have heard about him so far was like I won't come back.[...]

Can you confirm this with a tweet from him?

[Dunbaratu]

hi

how can i print my nextnode:deltav:mag. it wont work any more i can get the nextnode:deltav. but i need the number:-)

EDit. i compiled newst version from erendrake by myself solved the problem.

I'd really like to see that version hosted somewhere precompiled. I stopped testing because of that problem. It pretty much broke all my mission scripts.

[weissel]

@Steven Mading

The granularity of an OS'ses native context switching ... hmmm. kOS seems to switch context after every statement itself --- i.e. inserting WHEN and ON checks right there. So I submit that it does do context switching and "process task" (in as far as we have them, having only stuff like WHEN) at it's own native context switching granularity.

The "after any machine language instruction" is at least misleading, I doubt you can switch context within the time of every single machine language instruction read, and in fact you'd need an external trigger for such stuff (i.e. time slices and interrupts --- which supposedly could happen at any time).

The fact that a complex kOS expression can be composed of many underlying instructions is misleading, too, after all, modern x86 CPUs use microcode to offer a CISC interface and a RISC's advantages --- which means a given CISC instruction to the CPU might expand up to hundreds or thousands of RISC instructions that the core CPU can actually handle. (See the similarity? On one side, the external view of larger blocks, on the other an internal view of many many small blocks ...)

So by that reasoning an OS could only be multithreaded if it was able to interrupt any single internal CPU instruction (in RISC) in any place of the RISC code the CISC instruction expands to. Hmmm ... maybe your definition of "multithreaded" is not quite as useful as it seems.

One must never forget that the "computer" and "cpu" as implemented in kOS is not identical to what you are used to on Earth. It's a quirky, kerbally language and a quirky, kerbally CPU. One, where --- as far as I can benchmark it --- every single instruction seems to take the same amount of time, no matter if it's simple or complex. A "set x to VERY_COMPLEX_FORMULA." takes as long as "set x to 1.". Which means there's no reason for a granularity smaller than a statement ...

Also, the other reason it's not multi-threaded is that you can't choose to run any arbitrary code that way- you have to pick specifically limited things you can do with WHEN and ON instructions. You can't say "fork a thread and run this arbitrary block of code in it, while this thread continues on and runs this other code."

Uh --- which things would be prohibited? Examples please?

You cannot "fork", that's right, it's not a new process, you share variable space and environment (like which volume you're looking at) ... but --- except for it being a thread and not a process and all that that implies --- what code would be prohibited?

And even if you think it can still be multithreaded even if the granularity is one line of kos script, it's STILL not multithreaded because the "threads" don't execute interleaved with each other. Consider this example:

WHEN .... THEN do a block consisting of statements A,B,C,and D.

statement 1

statement 2

statement 3

statement 4

If the conditions of the WHEN check were satisfied after statement 1 ran, and it really was multithreading, then you might be able to get this execution to happen in this order:

statement 1

statement A (from the WHEN/THEN)

statement 2

statement B (from the WHEN/THEN)

statement 3

statement C (from the WHEN/THEN)

statement 4

statement D (from the WHEN/THEN)

But you can't get that result. It blocks the execution of the main line program until the entire body of the WHEN/THEN is done, like so:

statement 1

statement A (from the WHEN/THEN)

statement B (from the WHEN/THEN)

statement C (from the WHEN/THEN)

statement D (from the WHEN/THEN)

statement 2

statement 3

statement 4

Did you even try your example?

Here, I'll give you an expanded version:

clearscreen.
set x to 0.
when (x == 1) then { 
    print " A".
    print " B".
    print " C".
    print " D".
}.
when (x == 1) then { 
    print "  a".
    print "  b".
    print "  c".
    print "  c".
}.
set x to 1.
print 1.
print 2.
print 3.
print 4.

I get

1
 A
  a
2
 B
  b
3
 C
  c
4
 D
  d

What do you get?

@erendrake

So 'running concurrently' can never happen in a single core system, as --- essentially --- the single core can only do one thing at a time and to the core everything is the same thread? Correct?

@Zander

You cannot have multiple kOS terminals visible at the same time, but (e.g. using action groups and defocussing the visible terminal before using them, so they're not caught and blocked as input by the terminal) you can trivially switch to the other terminal at nearly any time.

By default each CX-4181 kOS computer core module acts completely independent of other CX-4181 modules. They have their own CPU, their own Volume ... You can make them interact, though, through accessing the other's Volumes (if on the same ship) or (if in range) both using the archive ("switch to archive" == "switch to 0"). Beware, the numbering (except 0/archive) changes for each CX-4181 module, as the local Volume is always '1'. Naming the Volumes looks smart in that case.

You may also need to switch to each CX-4181 module and start their master program (loads files into the volume, names the volume, runs other code ...) by switching through the terminals of each CX-4181.

You see: no need to change anything in kOS.

As to one kOS core instructing another one: just pass the messages via writing a pre-determined into a pre-determined Volume and let the cores to be instructed read regularly from that file. Easy as apple pie. You may want to look at some form of locking, though, so no half-written command will get the receiving core do funny things and crash.

Actually, you can run multiple threads on one CX-4181 --- just let the additional programs load and be triggered as "WHEN" clauses. Beware, though, you only have 10,000 characters ...

As to watching multiple kOS units running in parallel: just use "log to" and watch the output file(s) on an external window outside KSP with e.g. tail and filter as wanted using grep. (OK,for windows you'll probably need some fiddly for-pay GUI tool.)

Edited January 24, 2014 by weissel
Reduce tag font size