[1.3] kOS Scriptable Autopilot System v1.1.3.0

[Dunbaratu]

Wish we had resizable windows, sometimes the terminal feels like a speck on my screen, and it doesn't look right.

I use Sublime Text for all my code, and I felt the lack of syntax with KOS disturbing:

I think you mean lack of syntax *highlighting*. It has syntax, or it wouldn't work at all. If you're interested, one of the future ideas is to try to find a way to emit syntax highlighting data from the C# code directly into a form that people can easily read through in their own software and convert into the syntax config format of their editor of choice. I've got a syntax file for VIM but it's getting out of date as it's a mess to keep it updated manually every time kOS changes. From the grammar file directly it's possible to do *some* automatic highlighter generation, but it can only tell you things like "that looks like a variable" rather than "that particular variable is one of the special predefined system variables as opposed to a user-defined one". It's trying to spit out that information that I'd like to be able to do some day from the kOS code itself.

Also, GOD DAMN THAT FONT. It's so bold that after a few minutes of looking, it hurts my eyes, not to mention it makes it slightly harder to read. I edited the font image so the letters were thinner, and not bold. Here you go:

It's not bold. It's just the raw Commodore 64 font, which didn't have separate normal and bold modes. The thick letters you see there *are* the normal mode. But it was designed under the assumption you'll be using it with lower contrast colors like the original Commodore 64 default of light blue on dark blue. It's putting it into bright green on black that made it look so "bold".

I find the thick font very handy when making youtube videos, because such videos often don't have *exactly* the same pixel resolution as the original gameplay did, and if the font's lines are only one pixel wide, then they can get smudged away during both the pixel averaging by local encoder software and the pixel averaging done by youtube's own processing on the server.

That being said, more options is always better. I wonder if it would be easy to have a clickbutton to pick font for the terminal window. It would just be a matter of having a handle on both images loaded into memory, and swapping which one is being used at runtime.

[Dunbaratu]

My problem is that I can't do the auto-staging cause kOS doesn't recognize the stage fuel left. It prints the total fuel left as the same amount as the stage fuel left. So I don't know what condition to give for it to work.

Any help?

To help diagnose it I'd have to see what the craft is like. The exact arrangement of the staging list and the separators and yellow fuel hoses (if any) is important to calculating fuel in a stage. Can you make a screenshot of the craft that shows these things, or post the .craft file itself?

[Cortek56]

Hi!

Here is my first contribution to KSP, especially K-OS.

there is a place for scipt an orbiting satellite automatically.

the script is adapted to the "Z-MAP Launch Kit".

It manages the entire launch, orbit, satellite Rocks kerbin to the ground, then opens all the antennas.

To start:

1 - Copy the script below in a "launch.txt" file.

2 - Recorded in the "archive" folder of the mod.

3 - Can the VAB open "Z-MAP Launch Kit"

4 - Insert the KR-2042 between the top of the satellite and communotron 88-88.

5 - Once on the launch pad, open the terminal.

6 - Enter the commands: "switch to 0." / Enter / "run launch." / Enter

7 - enjoy!

Here the script :

clearscreen.

print "3". wait 1.

clearscreen.

print "2". wait 1.

clearscreen.

print "1". wait 1.

lock throttle to 1.

lock steering to up + R(0,0,180).

stage.

wait 1.

stage.

clearscreen.

print "Launch!".

print "Vertical ascent, wait for gravity turn.".

wait 31.

stage.

clearscreen.

print "Vertical ascent, wait for gravity turn.".

print "Stage 1 separated.".

wait 2.

clearscreen.

print "Vertical ascent, wait for gravity turn.".

wait until altitude > 10000.

lock steering to up + R(0,0,180) + R(0,-60,0).

clearscreen.

print "Beginning gravity turn.".

wait until apoapsis > 99600.

lock throttle to 0.

wait 1.

stage.

clearscreen.

print "Stage 2 separated.".

wait 1.

stage.

lock steering to prograde.

clearscreen.

print "Waiting for circularization burn.".

wait until eta:apoapsis < 15.

lock throttle to 1.

print "Burn.".

wait until periapsis > 99500.

lock throttle to 0.

unlock steering.

lock steering to up + R(-180,0,0).

wait 10.

toggle ag1.

stage.

//end program

[Kertherina]

I have a problem for a while now with the steering in kOS.

Most of the rockets i build that also fly perfectly well with manual control are not steerable with the kOS "lock steering" command. Raw controls with ship:control:yaw work. Gimbals / RCS fire in all directions, the net rotation is near zero and if non-zero random.

Here is a sample script, here is the rocket. As you can see in the script, i fix the problem for the launch by using raw controls for the gravity turn, but as soon as the program gets to the first "lock steering" command i get the problem as described.

Here is a video showing the problem, at 0:47 i deactivate SAS with "lock steering to up" and the gimbals go wild. Flying with SAS without kOS works fine, flying manually and with kOS raw controls works fine, only with "lock steering" i get this problem. It's also the same in vacuum, and for small probes (my first guess was that it had to to with rocket size / mass but seems it isn't, had a small probe recently with decent RCS and i had the same problem).

An example for a rocket that does work:

Rocket

Script

There seem to be a few others with the same problem and i read somewhere it might be due to the lack of SAS torque. I play in RSS, so SAS is both near useless and i don't carry any extra with me so i rotate with pretty much only Gimbal and RCS, could this be the problem?

If so, is there is a way to fix this problem or will kOS get fixed to be able to function with RCS / gimbal?

The only solution i could think of so far is custom steering algorithms based on ship:facing and raw controls but i don't really want to go down that road.

[Dunbaratu]

The problem is simply that LOCK STEERING doesn't have a proper PID controller inside it, and just guesses how strong it should steer based on the average craft's rotational ability. That guess isn't correct for rockets that have a large amount of rotation capacity.

We've been debating back and forth on whether or not to fix it, given that the whole point of kOS is writing your own autopilot and making a proper PID controller is part of that. Just handing users one that works out of the box might be a bit too ... mechjeb if you get my meaning.

What I was thinking might be a good idea would be to allow users to adjust a setting that affects the strength of LOCK STEERING's deflections. If it's set to a smaller number, it makes LOCK STEERING use less than it's full amount of possible deflection force. That should dampen away a lot of these feedback oscillations without necessarily giving people a fully working out-of-the-box PID controller. Your own script would still be responsible for deciding whether or not to tell kOS to steer more mildly.

[madbadger2742]

My problem is that I can't do the auto-staging cause kOS doesn't recognize the stage fuel left. It prints the total fuel left as the same amount as the stage fuel left. So I don't know what condition to give for it to work.

Any help?

My solution to the problems with checking fuel levels was to check thrust values instead:

set bmt to ship:maxthrust.
lock throttle to 1.
wait 1.
when (ship:maxthrust<bmt or ship:maxthrust<1) then{
print "Staging.".
stage.
set bmt to ship:maxthrust.
preserve.
}.

if not ship:maxthrust > 0 {stage.}.

Edited October 27, 2014 by madbadger2742

[Kertherina]

Thanks for your answer

We've been debating back and forth on whether or not to fix it, given that the whole point of kOS is writing your own autopilot and making a proper PID controller is part of that. Just handing users one that works out of the box might be a bit too ... mechjeb if you get my meaning.

Speaking of Mechjeb, i for one would love to be able to use it with kOS to steer but as far as i know this is not possible, is that correct?

What I was thinking might be a good idea would be to allow users to adjust a setting that affects the strength of LOCK STEERING's deflections. If it's set to a smaller number, it makes LOCK STEERING use less than it's full amount of possible deflection force. That should dampen away a lot of these feedback oscillations without necessarily giving people a fully working out-of-the-box PID controller. Your own script would still be responsible for deciding whether or not to tell kOS to steer more mildly.

Sounds great to me. Would it be hard to implement? Also, anyone who doesn't want to use an existing steering function could still write his own.

[Lorentz]

The problem is simply that LOCK STEERING doesn't have a proper PID controller inside it, and just guesses how strong it should steer based on the average craft's rotational ability. That guess isn't correct for rockets that have a large amount of rotation capacity.

We've been debating back and forth on whether or not to fix it, given that the whole point of kOS is writing your own autopilot and making a proper PID controller is part of that. Just handing users one that works out of the box might be a bit too ... mechjeb if you get my meaning.

What I was thinking might be a good idea would be to allow users to adjust a setting that affects the strength of LOCK STEERING's deflections. If it's set to a smaller number, it makes LOCK STEERING use less than it's full amount of possible deflection force. That should dampen away a lot of these feedback oscillations without necessarily giving people a fully working out-of-the-box PID controller. Your own script would still be responsible for deciding whether or not to tell kOS to steer more mildly.

I agree with Steven here. If you just want to use an autopilot, MechJeb is the way to go. If you want to *write* your own autopilot, kOS is the tool to use. I would even suggest that the internals of LOCK STEERING remain private. They should work for very simple craft to ease programmers into kOS, but complex and tuneable PID loops should be the meta-game of kOS. Just remember how hard it was to get your first rocket into orbit using stock KSP! To me, the challenge is most of the fun.

As an aside, I have forked the docs on github and am writing a sequel to the quick-start tutorial. My goal is to provide non-programmers with a way to get from simple LOCK THROTTLE commands to a full PID implementation without giving too much away (like a whole auto-pilot system).

Edited October 27, 2014 by Lorentz

[erendrake]

I agree with Steven here. If you just want to use an autopilot, MechJeb is the way to go. If you want to *write* your own autopilot, kOS is the tool to use. I would even suggest that the internals of LOCK STEERING remain private. They should work for very simple craft to ease programmers into kOS, but complex and tuneable PID loops should be the meta-game of kOS. Just remember how hard it was to get your first rocket into orbit using stock KSP! To me, the challenge is most of the fun.

As an aside, I have forked the docs on github and am writing a sequel to the quick-start tutorial. My goal is to provide non-programmers with a way to get from simple LOCK THROTTLE commands to a full PID implementation without giving too much away (like a whole auto-pilot system).

What is your github user name? we are always excited to have more contributors on every part of the project

[hvacengi]

It is interesting to see the differences in how people use kOS. I like the phrasing that it's a mod for people who want to write their own autopilot. But I also think that definition changes depending on the user. Once you've created a way to launch and to execute a node, you could say that you have written the majority of the "autopilot" portion. Where I think kOS really shines is not in allowing you to write your own auto pilot execution, but rather in letting you write your own autopilot course plotting. With kOS I'm not limited to the set of functions that a tool like MechJeb provides, and I don't have to come up with a way to manually place and edit nodes sufficiently. I can use kOS to calculate a Mun gravity assisted launch to Minmus, or to set up a geosynchronous relay network, or a solar system relay network. All of these things are still complicated problems to solve, and they usually happen after you've written and refined your launch and node script. Really, whatever mission you can dream up you can automate using kOS.

So while I agree that more advanced PID "lock steering" is a good thing to leave as a high level exercise, it still makes sense to have some level of tuning or advanced options for other users. Users like myself who have more interest in the math of orbital mechanics than the math of PID for 3d vectors.

I don't want to come off as either ungrateful or as requesting the feature. I cannot imagine using RemoteTech without kOS, and I've gotten to a point where I balance my ships and burn nodes to make sure that I can use the built in features. Some times I need an extra loop to fine tune things, but overall I haven't had a need to write a more accurate implementation. I just wanted to point out a second point of view that might help with the focus of the autopilot discussion.

Thanks to all who develop and contribute to this mod!

[DomDiaemus]

How to get current pitch from the ship?

[GabeTeuton]

Guys is there a way to set pitch, roll and yaw trim to whatever number, i don't need a software with an ingame window or anything, just need to know if there is a command that allow me to manually set the trim to a number, or set the pitch directly to a number (regardless of the relative position of the airplane to 0,0,0)?????

[Trewor007]

DomDiaemus if You want just to see Your pitch:

print SHIP:CONTROL:PITCH.

or

set x to SHIP:CONTROL:PITCH. 
print x at (0,0).

more info is here: http://ksp-kos.github.io/KOS_DOC/structure/control/index.html

GabeTeuton Im assuming that "lock steering to..." is not what You want

SET SHIP:CONTROL:PITCH to 0.2.

more info is in the ling above or here under RAW control: http://ksp-kos.github.io/KOS_DOC/summary_topics/ship_control/index.html

[GabeTeuton]

GabeTeuton Im assuming that "lock steering to..." is not what You want

SET SHIP:CONTROL:PITCH to 0.2.

more info is in the ling above or here under RAW control: http://ksp-kos.github.io/KOS_DOC/summary_topics/ship_control/index.html

That is working with no issues, is there a way to set the pitch trim instead of the pitch itself?? (or any trim for the case...)!

(anyway this really helped me i need to tweak it a little bit but it helps! so thank you!)

PS: even better is there a way to make a cfgs not very complex that the console can execute to set trim/(or pitch for the case) to X, or even better, to ADD a pre-amount of notch to the pitch...

like for instance "exec nose up.cfg" or whatever the cmd is for executing a cfg and the pitch goes to 0.2, execute it again and it goes to 0.4!

Edited October 28, 2014 by GabeTeuton
adding PS

[erendrake]

I must admit that i never added trim to the fine control system because i have never used it in the game. How useful will it be to have access to trim because it shouldnt be that hard to add it.

[GabeTeuton]

I must admit that i never added trim to the fine control system because i have never used it in the game. How useful will it be to have access to trim because it shouldnt be that hard to add it.

You mean that currently there's no access to coding trim?

You may want to look at this request I just made!

http://forum.kerbalspaceprogram.com/threads/98443-Simple-but-Enhanced-Trimmer?p=1507745#post1507745

[Dunbaratu]

You mean that currently there's no access to coding trim?

You may want to look at this request I just made!

http://forum.kerbalspaceprogram.com/threads/98443-Simple-but-Enhanced-Trimmer?p=1507745#post1507745

I think trim might give some people what they're asking for - an ability to make an autopilot that helps the manual controls without overriding them - Let the autopilot control the trim while the player manually controls the main stick. The autopilot can maintain heading, pitch, and whatever with trim-only controls while the human can quickly override them temporarily by moving the main stick.

[DomDiaemus]

DomDiaemus if You want just to see Your pitch:

print SHIP:CONTROL:PITCH.

or

set x to SHIP:CONTROL:PITCH. 
print x at (0,0).

more info is here: http://ksp-kos.github.io/KOS_DOC/structure/control/index.html

I don't think that works... it does not work on my game anyway... the output of that is 0 regardless what pitch is set and at starting point is 90 and gradually reduces per altitude... so it cannot be zero as that command reports. Is there any other command apart from this way to get the current pitch... (not the case of to setting the pitch)

http://www.ribeiros.co.uk/subs/ksp.jpg

SET xx TO SHIP:CONTROL:PITCH.
PRINT "Pitch: " + ROUND(xx,1) + "deg " AT (x,y+18).

Edited October 28, 2014 by DomDiaemus

[Dunbaratu]

I don't think that works... it does not work on my game anyway... the output of that is 0 regardless what pitch is set and at starting point is 90 and gradually reduces per altitude... so it cannot be zero as that command reports. Is there any other command apart from this way to get the current pitch... (not the case of to setting the pitch)

The way that kOS works on the controls is as follows:

  +---- Kerbal Space Prg ---+     +--- kOS -----------------+
  |                         |     |                         |
  |   [1]--------------+    |     |                         |
  |   | Rest of the KSP|    |     |                         |
  |   |    Game        |    |     |                         |
  |   +----/|\---------+    |     |                         |
  |         |               |     |                         |
  |         |               |     |                         |
  |   [2]--------------+    |     |   [4]-----------------+ |
  |   | Input Override |    |     |   | One set of control| |
  |   | Stack picks one|<-------------|   settings        | |
  |   | set over the   |    |     |   +----/|\------------+ |
  |   | over           |    |     |         |      |        |
  |   +----/|\---------+    |     |         |      |        |
  |         |               |     |         |      |        |
  |         |               |     |         |      |        |
  |  [3]------------------+ |     |  [5]----------\|/-----+ |
  |  | One set of control | |     |  | kOS Script code    | |
  |  |    Settings        | |     |  | reading/writing    | |
  |  +-/|\--------/|\-----+ |     |  | control variables  | |
  |     |          |        |     |  +--------------------+ |
  +-----|----------|--------+     +-------------------------+
        |          |
        |          |
      User       User
     Keyboard   Joystick

The problem is that to do what you'd like, it would have to read box [3] from box [5], when what box [5] actually reads is box [4].

When you read SHIP:CONTROL:PITCH, you're reading what kOS's settings have set it to, not what the main game has set it do.

[madlemur]

Many thanks for the clarification Steven.

In this case KOS is flawed since isn't capable of providing basic information in regarding ship positioning, so reading the pitch and code KOS to re-point ship nose at the correct pitch without forcing some pseudo pitch upon it... this means as it stands it is impossible program fine tuning of an orbit.

Bah! Actually, you can get the actual heading of the ship, determine the pitch from that, and fine tune based on that information. The SHIP:CONTROL information is just the control settings, which will be relative (-1 to 1). I have to run, so I don't have time to look it up in the docs, but the information is there, and relatively easy to get.

[DomDiaemus]

The way that kOS works on the controls is as follows:

  +---- Kerbal Space Prg ---+     +--- kOS -----------------+
  |                         |     |                         |
  |   [1]--------------+    |     |                         |
  |   | Rest of the KSP|    |     |                         |
  |   |    Game        |    |     |                         |
  |   +----/|\---------+    |     |                         |
  |         |               |     |                         |
  |         |               |     |                         |
  |   [2]--------------+    |     |   [4]-----------------+ |
  |   | Input Override |    |     |   | One set of control| |
  |   | Stack picks one|<-------------|   settings        | |
  |   | set over the   |    |     |   +----/|\------------+ |
  |   | over           |    |     |         |      |        |
  |   +----/|\---------+    |     |         |      |        |
  |         |               |     |         |      |        |
  |         |               |     |         |      |        |
  |  [3]------------------+ |     |  [5]----------\|/-----+ |
  |  | One set of control | |     |  | kOS Script code    | |
  |  |    Settings        | |     |  | reading/writing    | |
  |  +-/|\--------/|\-----+ |     |  | control variables  | |
  |     |          |        |     |  +--------------------+ |
  +-----|----------|--------+     +-------------------------+
        |          |
        |          |
      User       User
     Keyboard   Joystick

The problem is that to do what you'd like, it would have to read box [3] from box [5], when what box [5] actually reads is box [4].

When you read SHIP:CONTROL:PITCH, you're reading what kOS's settings have set it to, not what the main game has set it do.

Thank you for the clarification.

KOS without a set of default routines aka provide such basic information it becomes a mammoth task just to get anywhere with somewhat precision... SHIP:CONTROL:PITCH doesn't even report the pitch set by other KOS commands... so no way to read the pitch unless coding to keep track where the ship nose is pointing at.

[DomDiaemus]

Bah! Actually, you can get the actual heading of the ship, determine the pitch from that, and fine tune based on that information. The SHIP:CONTROL information is just the control settings, which will be relative (-1 to 1). I have to run, so I don't have time to look it up in the docs, but the information is there, and relatively easy to get.

Cheers for the tip... going to look into that.

[Cairan]

I've been lurking a little more and I'd like to ask if there is such a way to do this in kOS, current or planned in 0.15...

Is it possible to list parts according to their activation stage? Or at the very least, enumerate the number of stages?

We can LIST PARTS and such, put it would be really great to do a LIST STAGES which could return objects with parts, resource, etc. from these specific stages. Or is there already such a function?

An application to a problem I'm trying to solve: a launch autopilot which detects that a staging event will occur during an orbital insertion burn... when SHIP:MASS and SHIP:MAXTHRUST changes after staging, the anticipation formula for the manoeuver node breaks down, it either burns long or short of it.

Another silly idea I've wanted to share, would it be feasible to define extra memory modules using ModuleManager? Say, you want a KAS-compatible punchcard part with 500 bytes of script memory and you swap software from it.

COPY script TO/FROM PunchCard.

Edit:

Looking back at http://ksp-kos.github.io/KOS_DOC_DEV/structure/part/index.html I've found part of my answer with the PART:STAGE suffix ... so at launch it is probably possible to go thru all the parts during pre-launch and initialize a variable with proper number of stages for a vessel without having to edit it by hand.

Edited October 29, 2014 by Cairan
Some more info...

[GabeTeuton]

So first of all i would like to thank erendrake for the support he provided so far and i'm sure he will keep supporting my lack of knowledge... Then I'm going to start asking questions right away haha...

So let's say i want a code that can add/substract a variable to the pitch, would i code something like this? (as of right now, i'm not able to test it myself, please don't ask why haha) but i'll certainly test it tomorrow regardless of being answered or not, ty)

set l to "0". // I'm trying to make "L" a variable to which i can add and substract "I" from
set i to "0.001".  // Making an "I" variable to add and substract to "L"
set SHIP:CONTROL:PITCH to l. // Setting pitch to L so it's set to something i can change, (provided this works)
set ag9 to "set l to l+i". // setting number 9 to adding 0.001 to L (therefore saving the value??, first time i do this L should be 0.0001, second time 0.0002, right????)
set ag10 to "set l to l-i". // self explanatory i hope

Let's say this works, should i save it to a "file" and the "run" the file, and then i should be able to use 9 and 0 to what i meant?

[Dunbaratu]

SHIP:CONTROL:PITCH doesn't even report the pitch set by other KOS commands...

Uhhh.. yes it does.

so no way to read the pitch unless coding to keep track where the ship nose is pointing at.

SHIP:CONTROL:PITCH does not mean the pitch of the ship. It means the pitch of the CONTROLS OF the ship. i.e. if it says -1.0 or +1.0 it means you've got the virtual control stick (from box [4] of my diagram) pushed all the way back or all the way forward.

The actual orientation of the ship is called SHIP:FACING.

If you want to work out the angle between the ship's nose and the horizon - if that's what you meant by "pitch", then you can use vector math to do that:

SET U_VEC TO SHIP:UP:VECTOR gives you a unit vector pointing directly to the center of the sky at the ship's current position.

SET F_VEC TO SHIP:FACING:VECTOR gives a unit vector pointing toward the nose of the ship.

If your nose is aimed at the horizon, then U_VEC and F_VEC should be perpendicular. If it's aimed straight up, then U_VEC and F_VEC are parallel.

You can work out the angle with dot product, or kOS provides a function that already does this called VANG.

VANG(U_VEC,F_VEC) will return an angle in degrees from 0.000 to 180.000. If it's 90 you are pointed at the horizon. If it's, say, 80, then you're pointed 10 degrees up from the horizon, and so on.