[1.3] kOS Scriptable Autopilot System v1.1.3.0

[TheClassiestMedic]

This is such a great mod! Or would be... if it would work. I can't wait to make autopilots and whatnot, but upon trying to open the interface, I get an error about missing textures. I double-checked the GFX folder and all four are there, just like they are in the .zip from SpacePort. Does anyone have any insight into how I could get this to work? I have TextureCompressor, could that be it?

I doubt it, seeing as there is no custom config for kOS under 'GameData\BoulderCo\textureCompressorConfigs', so I don't think TextureCompressor would find reason to muck with the HUD layout images

Edited March 31, 2014 by TheClassiestMedic

[Dunbaratu]

This is such a great mod! Or would be... if it would work. I can't wait to make autopilots and whatnot, but upon trying to open the interface, I get an error about missing textures. I double-checked the GFX folder and all four are there, just like they are in the .zip from SpacePort. Does anyone have any insight into how I could get this to work? I have TextureCompressor, could that be it?

Are your files for kOS arranged in exactly the following way? Your base folder may be different from mine., but everything from "KERBAL SPACE PROGRAM" on down should be the same:

Folder PATH listing for volume BOOTCAMP
Volume serial number is EA40-27E1
C:\PROGRAM FILES (X86)\STEAM\STEAMAPPS\COMMON\KERBAL SPACE PROGRAM\GAMEDATA\KOS
|   Readme
|   
+---Flags
|       kOS-Logo.png
|       
+---GFX
|       FontFinder.png
|       font_sml.png
|       monitor_launch.png
|       monitor_minimal.png
|       
+---Parts
|   \---kOSMachine1m
|           model.mu
|           model000.mbm
|           model001.mbm
|           part.cfg
|           
\---Plugins
    |   kOS.dll
    |   
    \---PluginData
        \---kOS
                config.xml

[Dunbaratu]

Has anyone had this problem with 'lock steering'?

As long as my craft has some mass located radially away from the central axis, helping give it a lot of rotational inertia, the steering algorithm seems to be able to correctly work out how to dampen its inputs to stop oscillations:

But once I drop that raidal mass away so the entire ship consists of only parts centered exactly on the axis, like this:

Then the steering keeps oscillating the roll back and forth, as if a pilot was pressing "Q" for a full second, and then "E" for a full second and then "Q" again and then "E" again and so on. The oscillation seems to progressively get bigger and bigger the longer I leave the steering locked. It starts out small, and then after a few minutes it's oscillating through a range of about +/- 70 degrees. It seems the steering code doesn't handle the case very well where the rotational control available from the torque wheels is large compared to the rotational inertia resisting it. It doesn't just overshoot and move a bit too far, the oscillations build on each other and get bigger and bigger.

[Joe32320]

Is there a relatively simple way to determine the heading of the prograde and retrograde markers on the nav ball (both surface and orbit markers)?

[Weadme]

The comptronix part looks very similar to other parts. Go to the "control" tab and hover over all the parts there to make sure none of them are it.

If you're sure that it's not there, then check your installation as follows:

Is the part located here?

Kerbal Space Program -> GameData -> kOS -> Parts -> kOSMachine1m ->

You should see these files there:

model.mu

model000.mbm

modeloo1.mbm

part.cfg

If you don't see that in that location, then you probably exploded the ZIP file in the wrong place.

Thanks for the replies. Turns out I was an idiot I downloaded the zip file from github, instead of the spaceport (how on earth did I miss that huge red 'Download now!' button? )

Now I have all the files. Let the scripting begin!

[Dunbaratu]

Thanks for the replies. Turns out I was an idiot I downloaded the zip file from github, instead of the spaceport (how on earth did I miss that huge red 'Download now!' button? )

Now I have all the files. Let the scripting begin!

Ah yes. The files on Spaceport have everything, but not up to date with the latest development changes. To get the latest version, from scratch, you get the spaceport zip first, and then on top of it install the github zip, which replaces the .DLL code, but doesn't ship with all the other files.

[Dunbaratu]

Is there a relatively simple way to determine the heading of the prograde and retrograde markers on the nav ball (both surface and orbit markers)?

Short answer, get into orbit, then try experimenting with these statements to see what they do:

lock steering to mysteer.

// followed by these, try them one at a time and watch the effect:
set mysteer to velocity:orbit.
set mysteer to (-1)*velocity:orbit.
set mysteer to velocity:surface.
set mysteer to (-1)*velocity:surface.

(The reason for using the intermediate "mysteer" variable instead of locking directly to the vectors is because of a bug in how the interactive terminal works. The parser breaks when you try to lock the same variable a second time from the interactive terminal, and you'd have to toggle power on the unit to fix it.)

Edited March 31, 2014 by Steven Mading

[Joe32320]

Short answer, get into orbit, then try experimenting with these statements to see what they do:

lock steering to mysteer.

// followed by these, try them one at a time and watch the effect:
set mysteer to velocity:orbit.
set mysteer to (-1)*velocity:orbit.
set mysteer to velocity:surface.
set mysteer to (-1)*velocity:surface.

(The reason for using the intermediate "mysteer" variable instead of locking directly to the vectors is because of a bug in how the interactive terminal works. The parser breaks when you try to lock the same variable a second time from the interactive terminal, and you'd have to toggle power on the unit to fix it.)

I should have been clearer. Basically I'm creating a landing program, and at low speed the retrograde marker moves about alot and the ship ends up trying to chase it with comedic results. If I could get an idea of what heading the marker was in, then I could tell the steering to lock to that heading at a pitch of 85 to the horizon, so the retrograde marker slowly goes back to the top of the navball, and the ship doesn't chase the marker too much.

I hope that makes sense.

[Ralathon]

I should have been clearer. Basically I'm creating a landing program, and at low speed the retrograde marker moves about alot and the ship ends up trying to chase it with comedic results. If I could get an idea of what heading the marker was in, then I could tell the steering to lock to that heading at a pitch of 85 to the horizon, so the retrograde marker slowly goes back to the top of the navball, and the ship doesn't chase the marker too much.

I hope that makes sense.

Are you trying to hover or something? Because during the final stages of a normal landing your retrograde vector should always be pretty close to the zenith.

[Dunbaratu]

I should have been clearer. Basically I'm creating a landing program, and at low speed the retrograde marker moves about alot and the ship ends up trying to chase it with comedic results. If I could get an idea of what heading the marker was in, then I could tell the steering to lock to that heading at a pitch of 85 to the horizon, so the retrograde marker slowly goes back to the top of the navball, and the ship doesn't chase the marker too much.

I hope that makes sense.

Well at first you said you *wanted* to point prograde or retrograde which is why I gave the answer I did. Now you're talking about the situation where you emphatically do NOT want to do that. Those markers moving around the navball really are the true retro/prograde markers, and it's correct that they do that when you get near zero vertical velocity.

What you really want is not "how do I steer retrograde" but rather "how do I NOT steer retrograde in this one instance"?

And here's how I did it ages ago, although there may be something coming soon that makes it easier:

http://kos.wikia.com/wiki/Tutorial_-_KOS_0.61_and_above:_Finding_surface_dynamic_information

It rotates the frame of reference using matrix math so it turns your velocity:surface into north, east, and up components instead of KSP's native xyz which is a mess.

In a nutshell, you use tfXYZToEnu from that page to take any vector (in this case velocity:surface) and transform it into tfE, tfN, and tfU for its east, north, and up components.

Once you've split it into east, north, and up, then you can work out what you want to do with that information, for example, if you're going east at 5 m/s, and north at -5 m/s, then that means you're drifting on a heading of 135 degrees (southeast).

For a general solution, the compass heading you are drifting on will be derivable by using the trig function arctan2(tfN,tfE).

Once you have the compass heading, you can do something like this:

lock steering to heading(-compass,85).

to aim mostly up, but tilted 5 degrees off opposite of your current surface drift.

[TheClassiestMedic]

Are your files for kOS arranged in exactly the following way? Your base folder may be different from mine., but everything from "KERBAL SPACE PROGRAM" on down should be the same:

Folder PATH listing for volume BOOTCAMP
Volume serial number is EA40-27E1
C:\PROGRAM FILES (X86)\STEAM\STEAMAPPS\COMMON\KERBAL SPACE PROGRAM\GAMEDATA\KOS
|   Readme
|   
+---Flags
|       kOS-Logo.png
|       
+---GFX
|       FontFinder.png
|       font_sml.png
|       monitor_launch.png
|       monitor_minimal.png
|       
+---Parts
|   \---kOSMachine1m
|           model.mu
|           model000.mbm
|           model001.mbm
|           part.cfg
|           
\---Plugins
    |   kOS.dll
    |   
    \---PluginData
        \---kOS
                config.xml

Yes, all the files are there, except for 'config.xml', which I assume is generated because it's not present in the .zip

The error occurs even when I remove all other mods... I've no clue how to fix it

[Joe32320]

I did say that I wanted to know how to "determine" the (compass) heading of the various markers, rather than "point" the ship towards a marker. That said, thank you for the information, I'll give it a go. (I forgot the kOS wiki existed).

[P.Funk]

I can't really read 44 pages so I'm just gonna ask, is there anyone who has or knows if you could use this to create a level autopilot for atmospheric flight? Basically something that will vary pitch angle to achieve a stable altitude or a null vertical velocity.

I browsed the syntax list and didn't see anything specifically for that. I don't mind doing work on my own to achieve it, I just want to know if I'm sniffing under the right tree.

[Dunbaratu]

Yes, all the files are there, except for 'config.xml', which I assume is generated because it's not present in the .zip

The error occurs even when I remove all other mods... I've no clue how to fix it

Well, then I have no idea.

You are correct that config.xml is autogenerated by the mod when you run it.

In fact, the fact that it's missing helps indicate something : that the mod didn't actually run.

[Dunbaratu]

I did say that I wanted to know how to "determine" the (compass) heading of the various markers, rather than "point" the ship towards a marker. That said, thank you for the information, I'll give it a go. (I forgot the kOS wiki existed).

A lot of what's in the wiki is out of date and becoming more and more incorrect as time goes on. It was basically created because Kevin Laity didn't want to make comprehensive documentation so a fan-made documenting project was started but we were mostly guessing by trial and error how things worked. Documentation is in the plans for the newer iteration of kOS so keeping the wiki up to date is no longer a top priority.

[Dunbaratu]

I can't really read 44 pages so I'm just gonna ask, is there anyone who has or knows if you could use this to create a level autopilot for atmospheric flight? Basically something that will vary pitch angle to achieve a stable altitude or a null vertical velocity.

I browsed the syntax list and didn't see anything specifically for that. I don't mind doing work on my own to achieve it, I just want to know if I'm sniffing under the right tree.

It should be possible. You can read your verticalspeed with the term 'verticalspeed', so you should be able to write something that adjusts the pitch depending on the vertical speed, to try to seek a vertical speed of zero.

[P.Funk]

Yea, I saw that. I basically posted earlier as I was about to go out without having reviewed everything. By looking at it more closely it should be relatively simple to tell it to do something like say:

set ship:control:pitch to 0.1 when verticalspeed > 0

Or something? Right now I'm not looking for anything too sexy. Basically my goal would be to recreate a program that would emulate the autopilot on the real life A-10. Basically its a Pitch, Heading, Altitude hold autopilot that is not integrated into the throttle so it literally just has 3 modes that allow either level flight at a fixed altitude, level flight at a fixed vertical pitch of the velocity vector, and fixed altitude with a fixed bank angle.

So far looking over what KOS is capable of I'm wondering if its even possible to have it respond to the altitude hold settings by using the altitude at the time it was activated and not one I enter as a fixed interger. Possibly I guess once I get into it. The other thing that I'm curious about is whether it can distinguish the velocity vector from the pitch of the longitudinal axis of the aircraft. This would be more useful than just telling it to maintain a given pitch or pitch a given amount until vertical velocity is zero.

Anyway, I haven't even tried yet so I'll get down to it and be back when I have some results.

[Dunbaratu]

Basically its a Pitch, Heading, Altitude hold autopilot that is not integrated into the throttle so it literally just has 3 modes that allow either level flight at a fixed altitude, level flight at a fixed vertical pitch of the velocity vector, and fixed altitude with a fixed bank angle.

The most useful thing for what you want is probably the 'lock' command. If you can think of a math expression to respond to the changing conditions, it works well.

For example, to lock altitude to the altitude you started the code at, something like this might work:

// current altitude at the start of the program.
set startAlt to altitude.

// The desired vertical speed - want it to be negative if above startAlt, or positive if below startAlt.
// In this example, the vertical speed desired is 1 m/s per 10 meters off from the target altitude.
// You might have to tweak that up or down.
lock seekVSpd to (altitude - startAlt)/10.

set curPitch to 0.
until 0 { // loop forever - probably need a good end condition for a real program.
  set curPitch to curPitch + (seekVSpd-verticalspeed)/5.
  set ship:control:pitch to curPitch.
}.

I haven't tried compiling that or anything. It's just a first guess at how I might do an altitude maintainer for an airplane. It's supposed to adjust pitch more strongly the further the verticalspeed differs from the desired verticalspeed, where in turn the desired verticalspeed is itself dependant on how far off you are from the desired altitude. Its sort of a lazy attempt at something like a PID controller.

Give it a try and see what's wrong with it and go from there. I doubt it will work out of the box.

[Dunbaratu]

In the past I had a very convoluted algorithm for detecting when to do an asparagus stage and it had gotten messy and ugly as I tried adding more support for solid boosters and different sorts of arrangements. It was based on trying to watch the rate of losing consumables (sometimes by measuring fuel, other time by measuring mass), and deciding that if the rate of consumption drops it must be because an engine stopped.

But I realized that some of the new features added more recently to kOS solved this problem ages ago and I just didn't notice.

// Check for flameout of any of the existing engines:
set numOut to 0.
list engines in englist.
for eng in englist { 
  if eng:flameout {
    set numOut to numOut + 1.
  }.
}.

If numOut is > 0 after running that code, then at least one engine is trying to be throttled that isn't working because it's starved of fuel, so it's time to asparagus stage. Changing the code to use this instead reduced the bytecount of my script by about 1000 bytes or so.

I thought 'flameout" was just for jet engines starved of air, but it works on rockets too, and triggers when any starved resource is stopping the engine from working (lquid fuel, solid fuel, oxidizer, whatever).

But it turns out you do need to have the throttle > 0 in order for KSP to flag the engine as flamed out. If your throttle is idle, then eng:flameout will always return false no matter what.

[TranquilTempest]

Newbie here writing a custom throttle control script. Is there a way to directly determine how much thrust you're getting from SRBs, if SRBs and liquid engines are burning simultaneously? I want to calculate throttle position based on maxthrust and desired acceleration, but don't know how to account for SRBs in this scenario.

[CaptainKipard]

How do I get or set values in a specific engine in a list?

[Sacru]

How do I get or set values in a specific engine in a list?

There are only getters, not setters, for engines at the moment, see here: http://erendrake.github.io/KOS/structure/engine/

An example to get the current thrust for the first engine in the list.

list engines in foo.

print foo#0:thrust.

Newbie here writing a custom throttle control script. Is there a way to directly determine how much thrust you're getting from SRBs, if SRBs and liquid engines are burning simultaneously? I want to calculate throttle position based on maxthrust and desired acceleration, but don't know how to account for SRBs in this scenario.

I cannot work out what causes the order the engines are listed in, so I am not sure how to end up with the solid fuel rockets at a specific point in a list. Though you can call on the length of the list and make a loop looking at its values, such as the ISP, to determine certain things. The example below is messy as I just made it up now and the list# will not work with anything but an integer, as in you cannot set x to 1 then call on foo#x.

list engines in foo.

set x to foo:length.

set y to 0.

until y = x

{

when y = 0 {if foo#0:isp < 275 {set result to result + foo#0:thrust.}. set y to y + 1.}.

when y = 1 {if foo#1:isp < 275 {set result to result + foo#1:thrust.}. set y to y + 1.}.

when y = 2 {if foo#2:isp < 275 {set result to result + foo#2:thrust.}. set y to y + 1.}.

//etc

}

[Hans Dorn]

That's a bit tricky. The numbering of the engines depends on how the editor has put together your rocket in the VAB.

It also changes after each staging!

You can do something like:

list engines in e.print e.

To see how the engines are numbered for the current phase of staging.

Use e#3 to access engine 4. (Indices start at 0 IIRC)

Cheers

Hans

P.S: Beware of rapiers, they generate 2 entries in the list!

[Dunbaratu]

when y = 0 {if foo#0:isp < 275 {set result to result + foo#0:thrust.}. set y to y + 1.}.

when y = 1 {if foo#1:isp < 275 {set result to result + foo#1:thrust.}. set y to y + 1.}.

when y = 2 {if foo#2:isp < 275 {set result to result + foo#2:thrust.}. set y to y + 1.}.

On a side note, the "#" operator isn't particularly useful because of how it only works with hardcoded literals in the code like that. It would be useful if you could do this:

foo#y

using a variable for the index. (But since kosscript programmers don't directly control the datatype of numeric variables, it would have to be implemented to deal with cases where y is implemented in a floating point format - i.e. it should handle when y = 2.0 just as well as when y = 2. ).

Right now the only way to access an element of a list in a truly generic varying way is with the list's for loop. Even if you know ahead of time "I want to access the Nth element where N is stored in a variable", you still have to iterate over them from the beginning to get to it.

I was considering starting to contribute to the code by trying to implement this after I get a handle on the parser generator tool used by the code.

Edited April 1, 2014 by Steven Mading

[Dunbaratu]

Newbie here writing a custom throttle control script. Is there a way to directly determine how much thrust you're getting from SRBs, if SRBs and liquid engines are burning simultaneously? I want to calculate throttle position based on maxthrust and desired acceleration, but don't know how to account for SRBs in this scenario.

You can get the name of the engine, but then you have to know which engines are named what, making it impossible to write a script that will generically work regardless of what mod parts are installed. The script has to know the names of all the SRB parts installed in the game.