kOS Scriptable Autopilot System 0.9

[erendrake]

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.

Im at work so i wasnt able to run it in KSP but i have put up a new installer with just the change you wanted. I should have done it before.

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

[erendrake]

@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?

To a single core system it is not true that everything is on the same "thread", it only executes one thread at a time but each process has at least one execution thread of its own. The code in KOS is synchronous, never attempting to spin off another thread. If you are seeing out of order execution, you should report is as a bug.

[erendrake]

I have another pre release version available on github.

v0.10.0 Prerelease 3

v0.10.0P3

I feel pretty good about this one as i have successfully run all of my scripts and a few others that have been posted around the forums here and so far, they have all run successfully like they did in 0.9.2.

If there are no objections for a day or so, ill try and get this up on the spaceport and the OP.

Edited January 21, 2014 by erendrake

[Dunbaratu]

To a single core system it is not true that everything is on the same "thread", it only executes one thread at a time but each process has at least one execution thread of its own. The code in KOS is synchronous, never attempting to spin off another thread. If you are seeing out of order execution, you should report is as a bug.

I don't think weissel was claiming that kOS is multithreaded ON the host computer (your PC) but that the fake virtual computer it presents is multithreaded. That just like a real computer with a single core handles the threads of processes by switching between them very fast in serial, that kOS also in its own single host OS's thread does the same thing - it switches between the threads of the fake virtual computer in serial.

While this is perfectly plausible and kOS could have been written that way, I didn't see it behaving like this when I last tested how WHEN/THEN worked.

Edited January 21, 2014 by Steven Mading

[Cilph]

To whomever is going to take control of kOS, contact me with wishes on how you want to do RT2 integration.

[Dunbaratu]

[ I edited this to remove weissel's unnecessary hubristic large font tags.]

@Steven Mading

I get

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

What do you get?

I always got the behavior I described already. Which does not interleave the outputs like this, but does what I already described. The "when" interrupted the main program and didn't give control back until it hit the end of its THEN block.

If I'd gotten behavior like you describe I'd have agreed with you.

But I admit that my experience testing this was several kOS revisions ago.

Could this be behavior that changed with versions? Kevin had been fiddling with the execution contexts a lot when he increased the speed by 5x, so this may be behavior that changed then. I assure you, the interleaving of output is NOT what it did the last time I tried this. I tested it specifically because it was badly documented how it worked and therefore trying it was the only way to see how it worked.

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?

The only thing that I saw running concurrently was NOT the body of the THEN, but merely the conditional checks of the WHEN. The WHEN condition check was interleaved between every statement in the main program, but the body's statements weren't. So with the construct "WHEN foo THEN bar", the only things that could be really threaded were the things you could put in foo, not the things you put in bar. i.e. only the conditional boolean checks were behaving in a threaded way. Once they triggered, the body would run in serial.

I believe you that the behavior has changed. But it wasn't like this the last time I experimented to learn how WHEN/THEN work. I explicitly tested for whether the THEN body ran concurrently by performing a test exactly like the one you demonstrate here and it didn't. At least, not about 5 months ago it didn't.

Edited January 21, 2014 by Steven Mading

[Zander]

@weissel

I tested and you are right. It works. But it is very troublesome to have to open and close each terminal like that. Is there any way I can create a script that commands other KOS computers to independently run scripts in their own terminal in the same way you can do it manually by opening each terminal?

If not is it possible to have multiple terminals open at the same time?

thanks

[Dunbaratu]

I have another pre release version available on github.

v0.10.0 Prerelease 3

v0.10.0P3

I just tested it with my old Duna mission script again and it worked as far as I had time to test it for. I tested it up to the point of landing on Duna, then had to call it quits and go to bed. The rest of the Duna mission script after the landing on Duna just consists of calling the same programs again with different parameters so if it works up to the point of landing that means I've exercised all the software in the mission at least once already. So I'd say it seems to be working.

It works great now. The DELTAV problem is fixed *AND* it's also running at full speed again. I don't know what changed but whatever it was it fixed the big lags that were in the previous 0.10 version (granted it still has the choppiness that kOS has always had, but it's now back to performing on par with how it used to run in 0.9.2).

I haven't tested any of the new functionality in 0.9.2. This was just a regression test using old scripts. Some of that new content could trim down a lot of my scripts. For example I had my own private body database for all the planetary information which looks like it will be obsolete now with the new BODY: fields.

Did anyone ever add the natural log function: ln(x) ? It's needed to answer the math problem: "Given the scale height and sea level pressure of the body's atmosphere, and a desired air pressure P, calculate A, the the altitude above sea level at which the air pressure will be P." My ascent script uses this to calculate the altitude at which to begin tipping over. At the moment it resorts to calculating it by approximating ln(x) by a series calculation in a loop prior to liftoff, which is a bit clunky but works.

Edited January 21, 2014 by Steven Mading

[sarkun]

Did anyone ever add the natural log function: ln(x) ? It's needed to answer the math problem: "Given the scale height and sea level pressure of the body's atmosphere, and a desired air pressure P, calculate A, the the altitude above sea level at which the air pressure will be P." My ascent script uses this to calculate the altitude at which to begin tipping over. At the moment it resorts to calculating it by approximating ln(x) by a series calculation in a loop prior to liftoff, which is a bit clunky but works.

Sensor reporter adds a few math functions, ln(x) among them. Don't know if it works in 0.23 though, I kind of abandoned kOS until it gets stable again.

http://forum.kerbalspaceprogram.com/threads/51211-Sensor-Reporter-for-kOS

[Dunbaratu]

Sensor reporter adds a few math functions, ln(x) among them. Don't know if it works in 0.23 though, I kind of abandoned kOS until it gets stable again.

http://forum.kerbalspaceprogram.com/threads/51211-Sensor-Reporter-for-kOS

The author of sensor reporter has chosen to go with making a new kOS-like mod from the ground up. It looks like a very cool project, but as it's being made from scratch it will likely be a while before anything is released, I imagine.

[whaaw]

How does the new commands work Bodyathmosphere, atm, exists, they wont work for me. also tryed body:atm bodyatmosphere:atm. i dont get it just from source code.

[Nando]

How does the new commands work Bodyathmosphere, atm, exists, they wont work for me. also tryed body:atm bodyatmosphere:atm. i dont get it just from source code.

print body(ship:obt:body):atm:height.
print body(target:obt:body):atm:height.
print body(body):atm:height.
print body("duna"):atm:height.
print bodyatmosphere("duna"):height.
print bodyatmosphere(ship:obt:body):height.
print bodyatmosphere(body):height.

[weissel]

@Steven Mading

Sorry for the tags' font size. It seems I overdid it. Reduced.

I always got the behavior I described already. [... snip ...]

That explains it. Had I gotten the results you had observed, I would of course have had to agree with you. And since you got those results, obviously that was yet another part of kOS which was changed.

@Zander

Until there's an 'auto-run' command implemented, you'll have to start each kOS unit's processing via the terminal, as far as I can tell; I've not yet worked much with multiple kOS units on a single entity, so I don't know.

@erendrake

To a single core system it is not true that everything is on the same "thread", it only executes one thread at a time but each process has at least one execution thread of its own. The code in KOS is synchronous, never attempting to spin off another thread. If you are seeing out of order execution, you should report is as a bug.

I guess it depends on the point of view. To the CPU, it's all one code stream (one thread), to the programs it's one or more processes of one or more threads each, to the OS it's multiple processes and threads that have to be spun into the single stream of code pushed to the CPU.

In kOS I (seem to) get a round-robin execution of the main code and each active WHEN group, one command at a time. So the 'synchronus code in kOS' is comparable to the CPU, while each WHEN (and the main code strea,) is comparable to a program with multiple threads, wheras the round-robin distributing part of kOS would be comparable to the OS spinning together multiple threads.

To the programmer it doesn't matter much --- ignoring speed optimization --- if the OS your program is running under is actually emulated in a single thread (like kOS) or emulated on multiple threads or runnning on a virtual machine with one or more cores available to it or running natively on a single core or multi-core machine. It matters if the execution is (pseudo)parallel or not. kOS does pseudo-parallel, which is what matters, as you can run several code parts 'at the same time' --- opposed to "you can't run out of order at all --- no WHEN, no ON" or "an active interrupt (WHEN, ON) blocks the execution of everything else until it's done".

[erendrake]

@weissel

In kOS I (seem to) get a round-robin execution of the main code and each active WHEN group, one command at a time.

Exactly, one at a time. In a Superloop.

To the programmer it doesn't matter much

to the programmer threads matter very much. If you use more than one you must synchronize context when you want to migrate between them.

(pseudo)parallel

Does not exist, its either parallel or series.

I guess it depends on the point of view.

no, it doesnt. Superloop != Multithreading. I suspect that "Thread" doesn't mean what you think it means.

[Dunbaratu]

In kOS I (seem to) get a round-robin execution of the main code and each active WHEN group, one command at a time.

That's still a huge difference. Real multithreading doesn't guarantee anything about how nicely interleaved the threads will be. Maybe on one run you happen to switch between thread 1 and thread 2 letting each run one line before context switching, and maybe on the next one you get 2 instructions in a row from thread 1 before it goes over to thread 2. The guarantee of one line from 1 followed by one line from 2 followed by one line from 1 and so on is very unlike multithreading. In real multithreading if there's points where the threads must have their behavior synchronized in order to make the algorithm work, you have to work out a handshaking system between them to make it happen. You can't rely on a perfect line by line round-robin.

In other words, with actual multithreading, not only do the threads run at the same time, but they run at *their own independent speeds* as well. The scheduler may use lots of strange esoteric criteria to pick which one runs faster, and you're not meant to write code that makes any assumptions about how that will work out. In actual threading, if one thread is running a statement that's time consuming and slow, the other thread might have executed several statements in the meantime. They don't nicely interleave one to one.

Edited January 27, 2014 by Steven Mading

[check]

I made the following video over a month ago, but just uploaded it now. It's a timelapse of a completely autonomous rover drive over Duna, guided only by a kOS script. The script accounds for the rovers speed and attitude so it doesnt make adjustments to heading when the rover is going too fast or is on uneven terrain, minimizing (but not completely eliminating) the risk of flipping over.

Video

Script:

clearscreen.
Print "Duna Pole to Pole by check".
set waypoint1 to latlng(-41,-10).
set waypoint2 to latlng(-35,-18).
set waypoint3 to latlng(-28.5,-24.3).

set waypoint4 to latlng(-28.3,-30.2).
set waypoint5 to latlng(-19,-42).
set waypoint6 to latlng(-7.8,-35.9).

set waypoint7 to latlng(1,-19).
set waypoint8 to latlng(4.6,-13.8).
set waypoint9 to latlng(8,-5.5).

set waypoint10 to latlng(17,17).
set waypoint11 to latlng(31,37).
set waypoint12 to latlng(47.5,44.8).



set nextwaypoint to waypoint1.
set w to 1.
until w = 13 {
lock wheelthrottle to -0.2.
wait 3.
lock wheelsteering to nextwaypoint.
lock wheelthrottle to 0.1.
wait 5.
lock wheelthrottle to 0.5.
until nextwaypoint:distance < 50 {
print "Waypoint "+w+ " "+nextwaypoint distance at (3,3).
	if inlight = "True" {lights off.}.
	if inlight = "False" {lights on.}.
set x to up - facing.
set attitude to sqrt((x:pitch)^2+(x:yaw)^2).
if attitude > 2 {unlock wheelsteering.}.
if surfacespeed > 14 {lock wheelthrottle to 0.1.}.
if surfacespeed < 14 {lock wheelthrottle to 0.5.}.
if surfacespeed > 18 {lock wheelthrottle to -0.1.}.

if attitude < 2 {lock wheelsteering to nextwaypoint.}.
}.
set w to w +1.
if w = 2 {set nextwaypoint to waypoint2.}.
if w = 3 {set nextwaypoint to waypoint3.}.
if w = 4 {set nextwaypoint to waypoint4.}.
if w = 5 {set nextwaypoint to waypoint5.}.
if w = 6 {set nextwaypoint to waypoint6.}.
if w = 7 {set nextwaypoint to waypoint7.}.
if w = 8 {set nextwaypoint to waypoint8.}.
if w = 9 {set nextwaypoint to waypoint9.}.
if w = 10 {set nextwaypoint to waypoint10.}.
if w = 11 {set nextwaypoint to waypoint11.}.
if w = 12 {set nextwaypoint to waypoint12.}.
}.
lock wheelthrottle to -0.1.
wait until surfacespeed < 3.
brakes on.
unlock all.

Note: It didn't get much past waypoint 1. lol.

[weissel]

@erendrake

Should I now just quote your "Exactly" and claim you fully agreed with me? You did a similar thing to me. I didn't say "threads don't matter to programmers". I said the "hardware" (real or emulated) didn't matter much. OK, only as long as it's fast enough.

(pseudo)parallel

Does not exist, its either parallel or series.

Single core CPU, no hyperthreading, running e.g. Linux: can it run programs and threads in parallel (and how does it do that, then) or only in series (and how comes the user gets the impression it can)?

no, it doesnt.

Pray tell: how does the CPU know if a program has one or multiple threads?

Superloop != Multithreading.

Educate me: which necessary part of the definition (URL please!) of being capable of running multiple threads does a superloop not have?

I suspect that "Thread" doesn't mean what you think it means.

What do you think "Thread" means?

@Steven Mading

That's still a huge difference. Real multithreading doesn't guarantee anything about how nicely interleaved the threads will be.

Are you saying not guaranteeing a certain interleaving is a necessary precondition of multithreading? OK, fine, kOS doesn't guarantee it: no guarantee in the documentation for the user/kOS programmer.

I can see your reply: "But kOS does it that way."

I'll answer

1. currently, yes, but that may change in the future, as it's an implemention detail
   
2. So kOS would feature "real multithreading" if it pulled the next thread at random from the list of runnable threads?

and I'd add that I can't see an advantage switching from round robin to random.

In real multithreading if there's points where the threads must have their behavior synchronized in order to make the algorithm work, you have to work out a handshaking system between them to make it happen. You can't rely on a perfect line by line round-robin.

When you have no guarantee for X to always be the case, you must assume X may not always be the case, but not that it never will be the case. Right?

In other words, with actual multithreading, not only do the threads run at the same time, ...

Can a single CPU (no hyperthreading etc.) support multithreading, as it can only run a single instruction at a time? That's kinda important here to understand you correctly ...

... but they run at *their own independent speeds* as well. The scheduler may use lots of strange esoteric criteria to pick which one runs faster, and you're not meant to write code that makes any assumptions about how that will work out.

kOS uses an esoteric criterion known by the mystical name 'round robin', so we're golden.

And (obviously) you're not meant to write code that assumes something which is not guaranteed. Which means that in the cases where you have a guaranteed scheduler behaviour, you can (and sometimes should) write code that makes assumptions on the guaranteed behaviour. Say, when you are guaranteed to have at least of so-and-so-many microseconds runtime per time unit and you must guarantee to produce a certain result within so-and-so many time units.

In actual threading, if one thread is running a statement that's time consuming and slow, the other thread might have executed several statements in the meantime.

In kOS all commands (that do not wait or (untested:) run other programs) seem to take exactly the same time. Just as with a RISC CPU. Which means there simply are no time consuming or slow commands. Life in the Kerbol system is strange, just look at the density of the planets.

However, a calculation made from several commands may be faster or slower than another one with a different number of steps, so one may present you with results earlier, and you might have to sync them.

[erendrake]

Single core CPU, no hyperthreading, running e.g. Linux: can it run programs and threads in parallel (and how does it do that, then) or only in series (and how comes the user gets the impression it can)?

The Operating system can hold multiple memory contexts, but no it cannot violate the rules of the underlying hardware. Users think it can because there are millions of clever engineers in the world, upkeeping this illusion.

Pray tell: how does the CPU know if a program has one or multiple threads?

It doesnt. it doesnt know about programs or threads or processes.

Educate me: which necessary part of the definition (URL please!) of being capable of running multiple threads does a superloop not have?

I did not say that a superloop can not manage additional threads. I said that a superloop is not the same thing as multiple threads. you are conflating.

What do you think "Thread" means?

The smallest unit that the OS's scheduler can manage.

You are smelling strongly of Troll. I am not going to respond to you again on this. kOS is single threaded.

[erendrake]

I made the following video over a month ago, but just uploaded it now. It's a timelapse of a completely autonomous rover drive over Duna, guided only by a kOS script. The script accounds for the rovers speed and attitude so it doesnt make adjustments to heading when the rover is going too fast or is on uneven terrain, minimizing (but not completely eliminating) the risk of flipping over.

Video

Script:

clearscreen.
Print "Duna Pole to Pole by check".
set waypoint1 to latlng(-41,-10).
set waypoint2 to latlng(-35,-18).
set waypoint3 to latlng(-28.5,-24.3).

set waypoint4 to latlng(-28.3,-30.2).
set waypoint5 to latlng(-19,-42).
set waypoint6 to latlng(-7.8,-35.9).

set waypoint7 to latlng(1,-19).
set waypoint8 to latlng(4.6,-13.8).
set waypoint9 to latlng(8,-5.5).

set waypoint10 to latlng(17,17).
set waypoint11 to latlng(31,37).
set waypoint12 to latlng(47.5,44.8).



set nextwaypoint to waypoint1.
set w to 1.
until w = 13 {
lock wheelthrottle to -0.2.
wait 3.
lock wheelsteering to nextwaypoint.
lock wheelthrottle to 0.1.
wait 5.
lock wheelthrottle to 0.5.
until nextwaypoint:distance < 50 {
print "Waypoint "+w+ " "+nextwaypoint distance at (3,3).
	if inlight = "True" {lights off.}.
	if inlight = "False" {lights on.}.
set x to up - facing.
set attitude to sqrt((x:pitch)^2+(x:yaw)^2).
if attitude > 2 {unlock wheelsteering.}.
if surfacespeed > 14 {lock wheelthrottle to 0.1.}.
if surfacespeed < 14 {lock wheelthrottle to 0.5.}.
if surfacespeed > 18 {lock wheelthrottle to -0.1.}.

if attitude < 2 {lock wheelsteering to nextwaypoint.}.
}.
set w to w +1.
if w = 2 {set nextwaypoint to waypoint2.}.
if w = 3 {set nextwaypoint to waypoint3.}.
if w = 4 {set nextwaypoint to waypoint4.}.
if w = 5 {set nextwaypoint to waypoint5.}.
if w = 6 {set nextwaypoint to waypoint6.}.
if w = 7 {set nextwaypoint to waypoint7.}.
if w = 8 {set nextwaypoint to waypoint8.}.
if w = 9 {set nextwaypoint to waypoint9.}.
if w = 10 {set nextwaypoint to waypoint10.}.
if w = 11 {set nextwaypoint to waypoint11.}.
if w = 12 {set nextwaypoint to waypoint12.}.
}.
lock wheelthrottle to -0.1.
wait until surfacespeed < 3.
brakes on.
unlock all.

Note: It didn't get much past waypoint 1. lol.

I havent messed with rovers much yet with KOS. How well does the negative throttle work? I have been trying to figure out how to make brakes not so binary to help with missions just like this.

Thanks for sharing!

[check]

I havent messed with rovers much yet with KOS. How well does the negative throttle work? I have been trying to figure out how to make brakes not so binary to help with missions just like this.

Thanks for sharing!

Works pretty well. Much less likely to flip the rover over, I found. The trade off is your stopping distance is increased.

[erendrake]

Mind showing us a shot of the rover? i have been trying to figure out how i want to deal with having only one part so far and i want to see how you integrated the part into the structure.

[check]

Here you go. Nothing fancy.

[Keloooe_Pest]

Hey I have full electric charge on my crafts but when I open the terminal, it appears grayed out and I can't type anything into it, it loads the terminal just fine when booting up and still nothing happens to the terminal, any help?

[erendrake]

Hey I have full electric charge on my crafts but when I open the terminal, it appears grayed out and I can't type anything into it, it loads the terminal just fine when booting up and still nothing happens to the terminal, any help?

I have a new build available that will fix your issue. https://github.com/erendrake/KOS/releases/tag/v0.10.0P3

[Dunbaratu]

You are smelling strongly of Troll. I am not going to respond to you again on this. kOS is single threaded.

Agreed. The constant use of the disingenuous technique is a clear sign that the goal is to lengthen the argument rather than have anything conclude. I'm willing to argue with someone who I think genuinely believes a contrarian thing. But I'm not willing to waste the time arguing with someone who I suspect might be pretending to believe a contrarian position just to be abrasive rather than genuinely believing it.

And it doesn't matter anyway. kOS works exactly like it works regardless of what it's called. I'm glad to have learned from weissel that kOS behavior had changed since I last tested it, even though I do not agree that this behavior is what the word "multithreading" actually means.

Edited January 28, 2014 by Steven Mading