kOS Scriptable Autopilot System 0.9

[drtedastro]

The idea of running a program when rebooting would be excellent. Like coming out of a 'safeboot', or a safe time... This safe boot prog, would be like a bios and would run whichever prog user had stored in its nonvolatile memory. something like, point ant to kerbin and wait for instructions, or such... Nice stuff....

[Dunbaratu]

The idea of running a program when rebooting would be excellent. Like coming out of a 'safeboot', or a safe time... This safe boot prog, would be like a bios and would run whichever prog user had stored in its nonvolatile memory. something like, point ant to kerbin and wait for instructions, or such... Nice stuff....

It doesn't even need to be that complicated. Just a convention that says "any program file called 'BOOT' that exists on your hard drive will be run when the machine boots. If you want to make a routine to run upon bootup, just call it BOOT."

That would be rather analogous to several real-world operating systems that do or did a thing like that.

[drtedastro]

Sounds great....

[Bizz Keryear]

Regarding your discussion on the Github page: I have been thinking about a way of maybe automatically running a certain script on boot. Preloading, as it were. That seems a lot nicer when playing (I can not count the times I typed copy prog from 0. ... run prog.) and it is also realistic. A craft that shuts down due to an error or some other unforeseen circumstance should really try to run its software, possible extend antennas and phone home. Now, when you reboot, you are just dead in the water.

If the craft is able to phone home, it could even automatically access a script containing new programs/scripts to run. Pretty much like the real thing. I am just not really sure about how you can preload anything on startup, because that is where the repeatedly typing in your program names starts to count after a while.

It would of course be really nice if scripts could run while unloaded. I think of geostationary stationkeeping or long, long journeys. Having the craft look after itself would be ideal, as babysitting the geosync of my satellites is not my favorite hobby and warp adds to the problem quickly. That is at the same time a big hurdle. How is kOS ever going to run different ships at the same time, with physics (on rails it's hard for kOS to do anything) and without player supervision? I suspect that KSP is going to throw a royal fit.

Of course, if the workload could be properly offloaded to seperate cores the problem would be pretty much solved - unless you run many more ships. That would, however, probably mean that physics also have to be offloaded and I am not sure that is even possible.

The idea of running a program when rebooting would be excellent. Like coming out of a 'safeboot', or a safe time... This safe boot prog, would be like a bios and would run whichever prog user had stored in its nonvolatile memory. something like, point ant to kerbin and wait for instructions, or such... Nice stuff....

It doesn't even need to be that complicated. Just a convention that says "any program file called 'BOOT' that exists on your hard drive will be run when the machine boots. If you want to make a routine to run upon bootup, just call it BOOT."

That would be rather analogous to several real-world operating systems that do or did a thing like that.

I also suggest this way back. Was rejected. Was I wanted was if you have a file with a certain name in archive it will be executed as soon as you create a new vessel.

The things is you can edit it outside which is quite comfortable. And within would be commands like

COPY XYZ from 0.
copy ABC from 0.
// and so on
run xyz.

[Sacred Aardvark]

Does anyone know how to unset a target?

If I do this:

set target to "Duna".

Then I can't figure out how to de-select Duna after that (from in the script, I mean).

set target to 0.

set target to "None".

set target to "".

None of the above work. Maybe I'm missing something really obvious.

Old hack re-purposed: "set target to ship:body."

Last time it required an immediate action afterwards, this time it requires a slight delay in accessing target info

[edit] for those who might have missed the earlier discussion, "set target to ship:body" will set your target to the body of whatever SOI you're in, which the game doesn't really like you doing and will clear your target in a fraction of a second. If your intent was to clear your target, no problem. (and if you're quick there's some unreliable trickery that can be made with the split second target)

Edited November 22, 2013 by Sacred Aardvark
some phrasing adjustments

[a1270]

I'll rehash what i said on github here. UNSET ALL/variable will unset user-defined variables. Bulk node removal is targeted for REMOVE ALL NODES, Kevin has said REMOVE is to be generic. Target removal is added to my list but all non-critical issues are getting the backburner as of now. I am uncomfortable about having so many pull request on master.

[Dunbaratu]

I also suggest this way back. Was rejected. Was I wanted was if you have a file with a certain name in archive it will be executed as soon as you create a new vessel.

That doesn't sound like the same suggestion at all. It's a lot more complex and that could be why it was rejected. I'm just talking about a self-contained thing that lives entirely on the module itself that it activates when rebooted.

[erbmur]

I have the sensor plugin and am trying to write something that hovers.

LOCK tVal TO THROTTLE.
LOCK grav TO SENSOR!GRAV().
UNTIL STATUS = "LANDED" {
     SET tVal TO (MASS * grav)/MAXTHRUST.
}.

In theory, shouldn't this cause the thrust produced to always equal the gravitational pull at the current location, therefore having no net acceleration present, causing the craft to hover?

Instead, it causes the craft to rather descend with an acceleration and eventually crash.

Anybody have any pointers?

[Dunbaratu]

I have the sensor plugin and am trying to write something that hovers.

LOCK tVal TO THROTTLE.
LOCK grav TO SENSOR!GRAV().
UNTIL STATUS = "LANDED" {
     SET tVal TO (MASS * grav)/MAXTHRUST.
}.

In theory, shouldn't this cause the thrust produced to always equal the gravitational pull at the current location, therefore having no net acceleration present, causing the craft to hover?

Instead, it causes the craft to rather descend with an acceleration and eventually crash.

Anybody have any pointers?

I have no experience using the sensor mod for KOS, but I can see that you have your throttle lock syntax backward.

Where you do this: lock tVal to throttle.

you need to do this: lock throttle to tVal.

I don't know if that's the only problem you're having, but it's certainly one problem.

[erbmur]

I have no experience using the sensor mod for KOS, but I can see that you have your throttle lock syntax backward.

Where you do this: lock tVal to throttle.

you need to do this: lock throttle to tVal.

I don't know if that's the only problem you're having, but it's certainly one problem.

My bad, it is lock throttle to tVal, just misstyped it.

The sensor mod just takes the value given by the grav sensor. so the variable "grav" will always be the equal to the acceleration due to gravity at the current location. Shouldn't the "SET tVal TO (MASS * grav)/MAXTHRUST." cause the thrust generated to always equal the gravitational pull at the current location?

[a1270]

The other issue is UNTIL, IF, WHEN.. THEN all won't accept string literals for comparison. There is a fix but it needs to get pulled in. SET landed TO "LANDED". UNTIL STATUS == landed { code. }. seems to be a workaround.

[erbmur]

The other issue is UNTIL, IF, WHEN.. THEN all won't accept string literals for comparison. There is a fix but it needs to get pulled in. SET landed TO "LANDED". UNTIL STATUS == landed { code. }. seems to be a workaround.

That would help with the final stage when i actually manage to land and want to cut the engines, but the issue is that it's more like a crash rather then a land because the hover mechanic doesn't seem to function properly.

I guess what im asking is if anybody has an equation that i can use as a hover mechanic? Because mine just seems to make it want to descend rather quickly rather then actually hover.

[CrAzY GeNiUs]

BUG

set p to 0.

print p.

0

if altitude > 1000 {set p to 1.}. // I'm on ALTITUDE 1358 m.

print p.

1

if altitude < 1000 {set p to 2.}. // I'm on ALTITUDE 589 m.

print p.

1

HELP

[AbeS]

Are you running that code when you are at 1358m? Because I don't see any loops in there, so it will only run once and then end.

Try this:

set p to 0.
print "P:" at (0,1).

until 0 {
     print p at (10,1).
     if altitude > 1000 {set p to 1.}.
     if altitude < 1000 {set p to 2.}.
}.

Does that work?

[CrAzY GeNiUs]

Are you running that code when you are at 1358m? Because I don't see any loops in there, so it will only run once and then end.

Try this:

set p to 0.
print "P:" at (0,1).

until 0 {
     print p at (10,1).
     if altitude > 1000 {set p to 1.}.
     if altitude < 1000 {set p to 2.}.
}.

Does that work?

! Thank you ! ! Thank you ! ! Thank you ! ! Thank you !

Edited November 22, 2013 by CrAzY GeNiUs

[Bizz Keryear]

That doesn't sound like the same suggestion at all. It's a lot more complex and that could be why it was rejected. I'm just talking about a self-contained thing that lives entirely on the module itself that it activates when rebooted.

Kevin also stated that one target is that kOS will one day continue programs as soon as you return to the vessel. Due current technical reasons it boots every time you load the vessel.

[Dunbaratu]

The other issue is UNTIL, IF, WHEN.. THEN all won't accept string literals for comparison. There is a fix but it needs to get pulled in. SET landed TO "LANDED". UNTIL STATUS == landed { code. }. seems to be a workaround.

The following part of my descend script has always worked just fine:

      if STATUS = "LANDED" or STATUS = "SPLASHED" {
	if descType = "hover" or descType = "lander" {
	  // Stop moving:
	  set mySteer to up.
	  lock throttle to 0.
	  wait 10.
	  set beDone to 1. 
	}
	if descType = "skycrane" or descType = "skycrane/lander" {
	  SAS ON. // To ensure the payload is holding itself stable.
	  set dMode to 2.
	}.

I thought comparing to string literals only was a problem when the object being compared isn't normally a string. The objects in KOS implement toString() methods that allow them to cast themselves to a string when needed. The problem as you explained it before, is that this conversion isn't being triggered by attempts to compare versus a string literal like it should be, but it *is* being triggered when comparing versus a string variable.

Since STATUS really *is* a string, rather than just masquerading as one, no casting is needed so it works fine regardless of whether you compare it to a string literal or a string variable.

[Dunbaratu]

That would help with the final stage when i actually manage to land and want to cut the engines, but the issue is that it's more like a crash rather then a land because the hover mechanic doesn't seem to function properly.

I guess what im asking is if anybody has an equation that i can use as a hover mechanic? Because mine just seems to make it want to descend rather quickly rather then actually hover.

I do the same thing you do but I don't use the grav sensor and have no idea how it functions.

Instead i just calculate it myself based on body's mass and my altitude and the standard law of gravitation, like so:

  lock heregrav to gConst*bodyMass/((altitude+bodyRadius)^2).

From then on 'heregrav' will be the same thing you're trying to read from sensor!grav.

Where:

- gConst is the gravitational constant.

- bodyMass is the mass of the body you are orbiting (you can get this now from Body(body):mass , which you couldn't before.)

- bodyRadius is he equatorial radius of the body you are orbiting (which I don't think is in the Body struct yet in KOS so you'll have to get it from a wiki search).

set gConst to 6.67384*10^(0-11). // The Gravitational constant - same no matter what body you orbit.
set bodyRadius to 600000 .   // For kerbin, for example.
set bodyMass to 5.2915793*10^22.   // for kerbin, for example.

[Camacha]

I guess what im asking is if anybody has an equation that i can use as a hover mechanic? Because mine just seems to make it want to descend rather quickly rather then actually hover.

What I use is

lock throttle to 1/(maxthrust/(mass*sensor!grav())).

Please note that for some reason this will not maintain a proper steady hover. It comes very close, but will always have a very small upwards acceleration, so some compensatory mechanism is necessary. This is a known thing, comes from KSP itself and is how it should function.

To be honest, that makes it a little more fun I am currently exploring several options, each of which has strong points and weaknesses. Two are already working (dividing and a PID-controller), on the third one I am working at the moment.

Edited November 23, 2013 by Camacha

[erbmur]

What I use is

lock throttle to 1/(maxthrust/(mass*sensor!grav())).

Please note that for some reason this will not maintain a proper steady hover. It comes very close, but will always have a very small upwards acceleration, so some compensatory mechanism is necessary. This is a known thing, comes from KSP itself and it how is should function.

To be honest, that makes it a little more fun I am currently exploring several options, each of which has strong points and weaknesses. Two are already working (dividing and a PID-controller), on the third one I am working at the moment.

Thanks for this!

Your code seems to do the exact opposite of mine. Mine causes it to descend with a tiny bit of acceleration whereas your causes it to lift with a tiny bit. I guess my code is fine after all and the issue is inherent within KSP.

Thanks for making me feel better about myself.

Edited November 23, 2013 by erbmur

[Camacha]

Your code seems to do the exact opposite of mine. Mine causes it to descend with a tiny bit of acceleration whereas your causes it to lift with a tiny bit. I guess my code is fine after all and the issue is inherent within KSP.

This is actually starting to make me think that the problem might not be inherent at all. Maybe it has to do with current vertical speed and the time it takes kOS to switch to the calculated throttle speed, as that is not 0.

Some testing is in order! Could you post the full code you use to get to 0 m/s and hover?

[AbeS]

are you making gravity as a constant? that could really mess up hovering, you should be using

set Gc to 6.67384*10^-11. // Grav Constant
set PM to 5.2915793*10^22. // Planet Mass (stock Kerbin)
set PR to 600000. // Planet Radius (stock Kerbin)
lock alt to altitude + PR. // Real altitude
lock grav to Gc*PM/(alt^2).

If you are using it, forget I said anything

[a1270]

The following part of my descend script has always worked just fine:

      if STATUS = "LANDED" or STATUS = "SPLASHED" {
	if descType = "hover" or descType = "lander" {
	  // Stop moving:
	  set mySteer to up.
	  lock throttle to 0.
	  wait 10.
	  set beDone to 1. 
	}
	if descType = "skycrane" or descType = "skycrane/lander" {
	  SAS ON. // To ensure the payload is holding itself stable.
	  set dMode to 2.
	}.

I thought comparing to string literals only was a problem when the object being compared isn't normally a string. The objects in KOS implement toString() methods that allow them to cast themselves to a string when needed. The problem as you explained it before, is that this conversion isn't being triggered by attempts to compare versus a string literal like it should be, but it *is* being triggered when comparing versus a string variable.

Since STATUS really *is* a string, rather than just masquerading as one, no casting is needed so it works fine regardless of whether you compare it to a string literal or a string variable.

I originally thought it was a casting issue, i'll blame that goose chase on insomnia. After i got some sleep i looked at the parsing itself and it was a simple fix.

What's happening with that code is OR(AND will as well) forces a conversion to boolean. IF, WHEN..THEN and UNTIL have no issue with booleans. The real issue was the regex for the conditional forbids the usage of double quotes and braces. Doing 'status == "LANDED"' should have also converted to boolean but the bug prevented it getting that far.

[Camacha]

are you making gravity as a constant?

We are measuring gravity with the Negative Gravioli Detector. Unless that's off for some reason, it should be perfect. Just like with real reality, it is not

[AbeS]

didn't know we could use the sensors , anyways I would check by printing the grav from the formula and printing the sensor's readings and see if it is accurate?