kOS Scriptable Autopilot System 0.9

[kilman54]

TMS,

Lock statements don't work inside programs except for the throttle. Also, I suggest always using lowercase letters except inside a print quotation as it sometimes bugs out.

Since steering does not actually lock, you have to create an until loop to continuously lock the steering to the new value. You would also run your general burn loop inside the same until.

clearscreen.
set closeprogram to 0.

set yaw to 0.
set pitch to 90.
set roll to 0.

set inittime to missiontime.

set vardirection to up + r(yaw,pitch,roll).
lock steering to vardirection.

until closeprogram = 0 {
   set newtime to missiontime.

   if (newtime-inittime)>5 {
      set pitch to -90.
   }.

   set vardirection to up + r(yaw,pitch,roll).
   lock steering to vardirection.
   print "Steering is Y:" + steering:yaw + " P:" + steering:pitch + " R:" + steering:roll at (0,0).

   if Some Condition {
        set closeprogram to 1.
   }.
}.

[Sma]

A fix for this bug will be in the next update

Ok cool I'll have to remember to check the title so i don't miss when the update comes out.

[Sma]

Having some trouble here. Trying to get to grips with some basic directions and use of variables while in orbit.

Here's my script:

clearscreen.

set yaw to 0.
set pitch to 90.
set roll to 0.

lock VarDirection to up + R(yaw,pitch,roll).

lock steering to VarDirection.
print "Heading is Y:"+yaw+" P:"+pitch+" R:"+roll.

wait 5.

set pitch to -90.
print "Heading is Y:"+yaw+" P:"+pitch+" R:"+roll.

wait 5.

I lock VarDirection to the directional variables of yaw pitch and roll. I then lock steering to VarDirection and that command is honoured.

When I change the pitch variable, the steering doesn't alter, yet the printouts acknowledge that the pitch variable has changed.

What am I doing wrong?

I would imagine the print out changes because you're using set. I'm not exactly sure how lock/set works, but what if you try using lock instead of set for pitch, yaw, and roll?

On another note...I think I might change my program to use yaw, pitch, and roll like this. That way I can display the pitch on the terminal.

Edited September 8, 2013 by Sma

[TMS]

From the 'readme', I had understood that LOCK would continually refresh to the latest input values. I'm no doubt missing something simple.

[Dunbaratu]

From the 'readme', I had understood that LOCK would continually refresh to the latest input values. I'm no doubt missing something simple.

This is true. But it ALSO says that some things MUST be used with LOCK. I've found that trying to set a throttle to a setting and then decouple it from the controlling variable (using "SET" for a one-time-only change rather than a constantly updating change) doesn't do anything at all with things like throttle.

If you want to do this:

step 1 - set the value of foo to 0.5.

step 2 - set the throttle to foo.

step 3 - change the value of foo but leave the throttle where it was.

Then there isn't currently a way to do that without adding a second intermediate variable in between foo and throttle, like so:

step 1 - set the value of foo to 0.5.

step 2 - set the value of bar to foo.

step 3 - lock the throttle to bar.

step 4 - change the value of foo.

[Dunbaratu]

Further proving that you are 1. not listening and 2. not even aware of how when-then works.

Wrong and wrong. Your response below proves that you are continuing to choosing to pretend I was saying something dumber than what I said, in order to troll:

When-then is a one time trigger unless you put it in a loop. Got anything else chief?

AND UNTIL IT TRIGGERS IT CONTINUES TO CHECK. Which is exactly why I mentioned the continual checking as an important difference between this and having an actual ability to perform a check just once and potentially exit from somewhere that isn't in a loop. If the check is NOT true and does NOT trigger then the code keeps that continual checking going for the rest of the life of the program even though I didn't want to set up a continuous check like that, I just wanted to check once. It only stops the continuous checking over and over and over each cycle AFTER it triggers once. BEFORE that it does exactly what I said it does. It executes the check expression repeatedly to find out whether or not to trigger it. In a language that executes slowly, that difference really matters.

EDIT:

BTW I'm pretty sure Kevin said he was going to look into an exit and run command. That will do exactly what you want anyway. You can even have it run separate error prints based on what error condition you have had. You can just name some txt files. So there you go. What you want is coming in some fashion anyway.

By that statement you have left yourself with only these two choices:

(A) Lay into Kevin Laity with the same vitriol you laid into my post with, since by the claims YOU made here this is a feature that enables bad programmers who don't know what they're doing.

( Admit that you were trolling and apologise for that, if you actually think having this feature is okay and know you were being deliberately dishonest by pretending it was a horrible idea only used by bad programmers.

[Dunbaratu]

Having some trouble here. Trying to get to grips with some basic directions and use of variables while in orbit.

Here's my script:

clearscreen.

set yaw to 0.
set pitch to 90.
set roll to 0.

lock VarDirection to up + R(yaw,pitch,roll).

lock steering to VarDirection.
print "Heading is Y:"+yaw+" P:"+pitch+" R:"+roll.

wait 5.

set pitch to -90.
print "Heading is Y:"+yaw+" P:"+pitch+" R:"+roll.

wait 5.

I lock VarDirection to the directional variables of yaw pitch and roll. I then lock steering to VarDirection and that command is honoured.

When I change the pitch variable, the steering doesn't alter, yet the printouts acknowledge that the pitch variable has changed.

What am I doing wrong?

I've had trouble getting "LOCK" to work with an expression. I can make it work with just a variable, like so:

LOCK var1 to var2.

but not with an expression like

LOCK var1 to var2 + 4.

I don't know if that's intentional or not. The documentation is a bit sparse about it.

Edited September 8, 2013 by Steven Mading

[KevinLaity]

I've had trouble getting "LOCK" to work with an expression. I can make it work with just a variable, like so:

LOCK var1 to var2.

but not with an expression like

LOCK var1 to var2 + 4.

I don't know if that's intentional or not. The documentation is a bit sparse about it.

The example you've got there should be fine, I'll look into it.

[ddavis425]

If I have a barometer on my ship, is there a way to get the data from it to use in kOS?

[KevinLaity]

Hey guys, just wanted to quickly say, let's try to keep this thread positive and avoid making things personal.

[KevinLaity]

If I have a barometer on my ship, is there a way to get the data from it to use in kOS?

Not yet, this is a planned feature though

[Sma]

So far in my testing, I've managed to get a rocket, using a central rockmax engine and 4 skippers, with infinite fuel turned on to orbit (didn't want to deal with auto staging at the time), and circularized to with in about 36,000m. If I change one thing in my code, even the slightest, pitch by 2 or 3 degrees, throttle by .2 or so, it gets way off, or in some cases it goes into Kerbin escape. I do have it changing the pitch (in 5 degree increments, depending on where the PE is) the closer it gets to circularized, similar to how it works when you set a node.

Decided to try a rocket with stages, and haven't yet figured out how to manage the stages (strap on liquid boosters). I did manage to get it into orbit though, once AP and PE were pretty far about, but last few tries, AP ended up almost to the Mun. That is with manual staging though and not getting it done fast enough.

Problem with auto staging is (at least in my current thinking), if the boosters are running at the same time as the main engine, the boosters will run out before the main engine does. I'm thinking though if I set the staging so the boosters are on their own stage, I could grab the maxfuel for the boosters and put it in a variable. Then at launch, maybe have it stage twice to light the main engine, and right after grab the total fuel. Then compare maxfuel - boosterfuel to stagefuel (<= and >= would be handy in this case, but for now using "and" will work I guess), at which point, if I'm correct, the boosters should be empty, and I could stage. I can't even begin to imagine how this would work with asparagus staging though lol.

Edit: Oh, and this is using the same "generic" program. I guess for asparagus staging, you have to just program the fuel values for the boosters. Something like set aspSt1fuelMax=540 or whatever, and then compare against remaining fuel.

Edit 2: Still using the same program, I was expecting the rocket to run out of fuel in the lower stage, so I could see if the upper stage would...well stage...but this time it got to an orbit of 190,000 x 100,000. I think the only difference between this launch, and a previous launch with an AP near the Mun was a few second delay in staging the boosters lol tricky tricky.

Oh, and I am successfully using time warp (physic time warp, because it's too low during the coasting phase).

Edited September 9, 2013 by Sma

[xZise]

Hi, is there a way to check negative verticalspeeds? I tried the following code:

SET -pref_v TO -altitude/-100.
IF -verticalspeed > -pref_v {
  …
}.

The minus signs are only all possibilites where I tested it. Of course I tried it only with one sign at a time. I always get “Error: Unrecognized term: ''.†(except for the first minus, there I get only a syntax error).

Now how do I check negative verticalspeeds variably?

Fabian

[Dunbaratu]

Is the version on kerbal Spaceport right? It says it's version 0.5 on the spaceport website, however when I download and install it, the following all produce "Unrecognized term" errors just like they would have before the update:

print sin ( 45 ) .

print cos ( 45 ) .

print abs ( -1 ) .

I wiped my install and re-installed fresh from the download just to be absolutely sure. Then I removed the CX-4181 part from the craft and put a new one on from the toolbox panel, just in case there's a part change it needed. Same result.

[Dunbaratu]

Hi, is there a way to check negative verticalspeeds? I tried the following code:

SET -pref_v TO -altitude/-100.
IF -verticalspeed > -pref_v {
  …
}.

The minus signs are only all possibilites where I tested it. Of course I tried it only with one sign at a time. I always get “Error: Unrecognized term: ''.†(except for the first minus, there I get only a syntax error).

Now how do I check negative verticalspeeds variably?

Fabian

There appear to be some syntax parsing bugs with using a unary minus sign (a dash with only one operand on its righthand side, meaning its used as a negative sign, rather than being used as a binary operator with an operand before and after, meaning it's used as a subtraction operator). It sometimes is recognised and sometimes isn't.

The method I've resorted to to be parsed reliably is to always use the dash as a subtraction, and when I want to use it for negation I have to use it to do zero minus x instead, for example.

Replace -verticalspeed with ( 0 - verticalspeed ).

It's not ideal and is probably slower than using it correctly, but at the moment using it correctly doesn't seem to work right.

[xZise]

Ah! Interesting approach I'll test it. It's not finished so I can accept when I have to use 0-x, as this will most likely get fixed.

Fabian

[SiliconPyro]

I've created a kOS Wiki, which can be found HERE. It isn't much yet, but I hope to expand it greatly with detailed information on every operator, lots of example scripts and some community tutorial videos.

[Sma]

For checking negative verticalspeeds couldn't you also multiply by -1? Maybe I don't understand the question exactly, but if you just want to check for a negative verticalspeed wouldn't if verticalspeed < 0 work?

[JewelShisen]

So far in my testing, I've managed to get a rocket, using a central rockmax engine and 4 skippers, with infinite fuel turned on to orbit (didn't want to deal with auto staging at the time), and circularized to with in about 36,000m. If I change one thing in my code, even the slightest, pitch by 2 or 3 degrees, throttle by .2 or so, it gets way off, or in some cases it goes into Kerbin escape. I do have it changing the pitch (in 5 degree increments, depending on where the PE is) the closer it gets to circularized, similar to how it works when you set a node.

Decided to try a rocket with stages, and haven't yet figured out how to manage the stages (strap on liquid boosters). I did manage to get it into orbit though, once AP and PE were pretty far about, but last few tries, AP ended up almost to the Mun. That is with manual staging though and not getting it done fast enough.

Problem with auto staging is (at least in my current thinking), if the boosters are running at the same time as the main engine, the boosters will run out before the main engine does. I'm thinking though if I set the staging so the boosters are on their own stage, I could grab the maxfuel for the boosters and put it in a variable. Then at launch, maybe have it stage twice to light the main engine, and right after grab the total fuel. Then compare maxfuel - boosterfuel to stagefuel (<= and >= would be handy in this case, but for now using "and" will work I guess), at which point, if I'm correct, the boosters should be empty, and I could stage. I can't even begin to imagine how this would work with asparagus staging though lol.

Edit: Oh, and this is using the same "generic" program. I guess for asparagus staging, you have to just program the fuel values for the boosters. Something like set aspSt1fuelMax=540 or whatever, and then compare against remaining fuel.

Edit 2: Still using the same program, I was expecting the rocket to run out of fuel in the lower stage, so I could see if the upper stage would...well stage...but this time it got to an orbit of 190,000 x 100,000. I think the only difference between this launch, and a previous launch with an AP near the Mun was a few second delay in staging the boosters lol tricky tricky.

Oh, and I am successfully using time warp (physic time warp, because it's too low during the coasting phase).

Use the stage:liquidfuel check. that should only look at the ones in the current stage.

[Apollo13]

I've created a kOS Wiki, which can be found HERE. It isn't much yet, but I hope to expand it greatly with detailed information on every operator, lots of example scripts and some community tutorial videos.

Great idea. Especially the sample scripts. I gave you a Rep for starting this.

[Dunbaratu]

For checking negative verticalspeeds couldn't you also multiply by -1? Maybe I don't understand the question exactly, but if you just want to check for a negative verticalspeed wouldn't if verticalspeed < 0 work?

That has the exact same problem.

If the unary negative operator has syntax problems saying " - verticalspeed" then it also has problems trying to say " -1 ".

[SiliconPyro]

Great idea. Especially the sample scripts. I gave you a Rep for starting this.

Thanks. I hope it becomes the right resource for people to learn kOS.

[Sma]

Use the stage:liquidfuel check. that should only look at the ones in the current stage.

This is true, but if your launch stage has side mounted liquid boosters and your main engine is burning too, it all gets added together, it doesn't register the side boosters as a separate state, unless of course you don't light your main stage.

With my idea of having a variable for the max fuel in the boosters, before launch, it sort of works, but there's a delay for some reason. Possibly from poor programming on my part, or lag in running through the loop, or some math error (again on my part). Thought, doing the math it seems to work out. I have it print the difference, which by the time it prints is 690.

Just now I changed the positioning of the code that grabs the liquidfuel after the main engine is lit, this time the difference is 706, Don't think I can get it any higher, due to lag. I do have a wait statement, because otherwise the staging can't fire back to back. I guess for now it'll have to do though.

[Glockshna]

I'm having some trouble with getting this to work with MechJeb. Whenever I attach MechJeb to a spacecraft and try to run a program it freaks out and won't keep the ship straight. It will spin it in circles on all axis. The same ship without mechjeb will function perfectly. Any solutions? Sorry if this has already been asked. There are 58 pages to this thread that's a lot to read through.

[kilman54]

SMA,

You would get more accurate fuel values if you activate the asparagus stages first, check the fuel, then active the main engine - all before launch.

Assuming all asparagus stages are identical:

set acount to 3. // How many stages are asparagus.
set totalfuel to <liquidfuel>.
stage. wait 1. //all asparagus stages activated but not main engine.
set aspfuel to stage:liquidfuel. //total fuel in the 3 stages
set eachstagefuel to aspfuel /acount.

stage. //main engine start and clamp release
lock throttle to 1.
set x to acount.
set spentstages to 0.
until x = 0 {
   set currenttotal to <liquidfuel>
   if currenttotal < (totalfuel-(eachstagefuel *(spentstages+1)) { 
      stage. 
      set x to spentstages+1. 
      set spentstages to acount-x. 
   }.
}.

Obviously, you have to adjust to include launch code, like the gravity turn but it's a start!