[1.3] kOS Scriptable Autopilot System v1.1.3.0

[dolphen]

The issue is that you are steering with SAS turned on. Remote tech negates the stock SAS control, and so it fails to steer correctly. The documentation appears to only call this out for setting SASMODE (see here: http://ksp-kos.github.io/KOS_DOC/commands/flight/systems.html?highlight=sasmode#global:SAS) I will modify the documentation to identify that lock steering using SAS is also limited in remote tech. If you turn off SAS, it should start to work. If you vessel is unstable using the current kOS steering code, I'm working on pushing an update to that code as quickly as possible which is significantly more accurate.

Let me know how it goes with SAS turned off.

YOU ARE A GOD AMONG MEN... i.e. it now works. Thank you so much for your help, I can now launch my satellites properly.

[snepel]

Hi all, nice to see there's such a lively thread for this plugin. I just discovered it this afternoon and have been reading up on the docs and seen some YT tutorials / streams with pretty impressive stuff going on!

I've playing for a while (~18 months) using MechJeb, as my personal focus is on designing craft that can fly reproducible missions (and thus rely as little as possible on Kerbal / human interaction during the mission).

So obviously scripting and automation would be the next step for me to take things to a higher level.

When seeing the detailed tutorials and the code that floats around, things seem to be programmed pretty close to the metal so to speak.

I see mostly speed and orientation read outs, followed by complex calculations to obtain values on which new actions can be based.

I can imagine this presents a pretty steep learning curve for the uninitiated (myself included of course).

When I see how kOS is able to co-operate with other mods like KAC, RT and IR, I can't help wondering whether there might be plans to do the same with MechJeb2?

This would greatly improve the ease of adopting kOS for me and allow me to get impressive (moon rover landing etc.) results more quickly.

I expect it's also possible to implement some of MJ's functionality in kOS script, and possibly there are already some libraries available that do so?

Anyway, it's great to see how much is going on here. I've followed some of you on Twitch / YouTube to keep up with developments.

Keep up the good work!

Regards,

Snepel

[mhoram]

Currently I run the "Goddard-Problem: Maximal launch altitude Challenge". (In short: launch a given rocket to the highest possible altitude around 62km)

The scripted kOS-entries of the participants are on the high-end-range of efficiency and it seems like different installations perform differently, which means that I currently have the problem that I can no longer compare the results in a fair way.

Even on the same installation a kOS script results on different launches in altitude changes of 50m or more.

On different computers the altitude discrepancies were in one instance larger than 500m.

By default I have excluded the usage of physics or part changing addons, so this should not be an issue.

KER, MJ, Telemachus, kOS do not interfer with the physics so they should be OK to use.

One problem we have identified so far was the KSP-bug that causes the creation of a wrong physics.cfg file. Also the "physics delta time" config setting has most likely an influence on the results.

There are probably multiple reasons for the variance in results we get on different computers/installations.

To be able to support the challenge as good as possible I would appreciate some information about what could cause these different results.

[Dunbaratu]

Hi all, nice to see there's such a lively thread for this plugin. I just discovered it this afternoon and have been reading up on the docs and seen some YT tutorials / streams with pretty impressive stuff going on!

I've playing for a while (~18 months) using MechJeb, as my personal focus is on designing craft that can fly reproducible missions (and thus rely as little as possible on Kerbal / human interaction during the mission).

So obviously scripting and automation would be the next step for me to take things to a higher level.

When seeing the detailed tutorials and the code that floats around, things seem to be programmed pretty close to the metal so to speak.

I see mostly speed and orientation read outs, followed by complex calculations to obtain values on which new actions can be based.

I can imagine this presents a pretty steep learning curve for the uninitiated (myself included of course).

When I see how kOS is able to co-operate with other mods like KAC, RT and IR, I can't help wondering whether there might be plans to do the same with MechJeb2?

This would greatly improve the ease of adopting kOS for me and allow me to get impressive (moon rover landing etc.) results more quickly.

I expect it's also possible to implement some of MJ's functionality in kOS script, and possibly there are already some libraries available that do so?

Anyway, it's great to see how much is going on here. I've followed some of you on Twitch / YouTube to keep up with developments.

Keep up the good work!

Regards,

Snepel

For a variety of reasons the reddit group /r/kos tends to get a lot more traffic now than this thread here. Mostly it's because the layout of the KSP forums requires that you keep all the talk about a mod in one single-thread, and for a mod as complex with as many questions as kOS has, that format can be a real hindrance. Using /r/kos lets people have different threads for different questions and I think that's why it's being a lot more popular for kOS help these days. This thread is mostly here just so that people who don't know about the reddit group don't get forgotten about.

- - - Updated - - -

To be able to support the challenge as good as possible I would appreciate some information about what could cause these different results.

My first guess would be FixedUpdate rates. Despite the name "Fixed" they're not really Fixed. Given enough of a load on your gaming computer, one run can have a different physics delta time than another.

A far better name for FixedUpdate, that was more honest about what it really is, would be "CappedUpdate". It's an update that you can cap at a maximum rate, but not one that's guaranteed to actually always be fixed at that rate. If your system is under heavy enough load, Unity WILL slow down your "Fixed" updates so your physics delta time is longer than you configured it for. What that configuration option *Really* does is say "even if my computer is running fast and not being taxed too hard, don't allow physics updates to be any FASTER than this, but you can still make them SLOWER than this if you have do.".

Without knowing the actual scripts in question, it's hard to give a more definitive answer to what's going on.

[mhoram]

My first guess would be FixedUpdate rates. Despite the name "Fixed" they're not really Fixed. Given enough of a load on your gaming computer, one run can have a different physics delta time than another.

A far better name for FixedUpdate, that was more honest about what it really is, would be "CappedUpdate". It's an update that you can cap at a maximum rate, but not one that's guaranteed to actually always be fixed at that rate. If your system is under heavy enough load, Unity WILL slow down your "Fixed" updates so your physics delta time is longer than you configured it for. What that configuration option *Really* does is say "even if my computer is running fast and not being taxed too hard, don't allow physics updates to be any FASTER than this, but you can still make them SLOWER than this if you have do.".

Without knowing the actual scripts in question, it's hard to give a more definitive answer to what's going on.

This sounds like a reason why the scripts reach different altitudes when started under identical conditions.

Sando Mutt found an other reason for the discrepancy: temperature changes during the day-night-cycle. This seems to cause differences greater than 500m.

The scripts used so far are available here:

http://forum.kerbalspaceprogram.com/threads/128509?p=2085928&viewfull=1#post2085928

http://forum.kerbalspaceprogram.com/threads/128509?p=2155711&viewfull=1#post2155711

http://forum.kerbalspaceprogram.com/threads/128509?p=2158468&viewfull=1#post2158468

http://forum.kerbalspaceprogram.com/threads/128509?p=2159301&viewfull=1#post2159301

Thanks for your insight and fast response! I believe my consistency issues are now resolved.

[Cairan]

I was AFK for a while, but oh boy I am glad this thing kept rolling!

[astrobond]

Hi All

I'm playing with Kos from some days, and i don't understand why i didn't try this excellent tool before !!!

I'm working on a Kos script to optimise my Eve SSTO ascent, but i didn't found a way to get the actual maxtemp of the ship in Kos to control throttle to have the maximum possible twr without exploding...

Is there a way to get that information ?

Fly safe with Val

[Kemp_J]

Hi all. I've just released the second video in my series looking at kOS. In this episode I talk about variables, variable scope, and use of the LOCK command. The series is starting at the basics and working its way up to more complex topics, so at the moment it's still very focused on beginner topics and getting used to the language. it's probably a bit too basic for most people here, but maybe the new people can benefit

The link is below and, as always, I welcome any feedback or suggestions.

[Alchemist]

Did I do something wrong of does ship:surfacespeed doesn't work right?

the wall of numbers is from

print (vh-VXCL((ship:position-body:position), ship:velocity:surface):mag)+" "+(ship:surfacespeed-VXCL((ship:position-body:position), ship:velocity:surface):mag).

where

local vh is ship:surfacespeed.

(may be couple ticks old)

and I was wondering what's wrong with my landing guidance.

[damerell]

There was an inconclusive discussion on pages 335 and 336. Another mod I use (no idea which, maybe VOID?) has had an update to not use a "broken" surface velocity value from KSP, which may be pertinent.

[Alchemist]

One more option to investigate: ship:surfacespeed may be the velocity projection on the local terrain (with account to its incline!). If so, it just has to be documented properly.

[Dunbaratu]

Did I do something wrong of does ship:surfacespeed doesn't work right?

Known problem, caused by stock SQUAD code, not kOS code. The issue is described here:

https://github.com/KSP-KOS/KOS/issues/1097

We decided to just bypass squad's code and do it ourselves, but that fix is not released yet. In the meantime you could calculate it in your own kos code using the VXCL function (vector exclude).

If you take the surface velocity, and exclude the ship:up:vector from it, you get the projection of the surface velocity into the 2-D north/east plane.

[Alchemist]

Ok, I ran a test and ship:surfacespeed is indeed the component parallel to local terrain surface, not the horizontal plane.

I guess, then it's useful (but mostly for rovers).

Maybe keep this one as it is (just document properly) and add another (horizontalspeed)

[panzerwaffe044]

Hi, all! I'm new to kOS, great mod! I have a few noob-questions. I'm writing my first script with no maneuver nodes, VAB - 1lvl and low tech.

How to order my ship to lock steering to RADIAL and ANTIRADIAL. I'm using LOCK STEERING TO PROGRADE + R(0, 90, 0). It works good if a ship is in circular orbit near Kerbin, but if I try it while on an elliptical transfer orbit it points a bit off the blue marker?

How to warp time until the Mun is in certain position (Phase angle) relative to my ship?

[Alchemist]

I use this for radial

lock steering to -vxcl(velocity:orbit, (body:position - ship:position)).

As for warping to phase angles, you can use something like this:

set warp to 3.

wait until [put your phase angle condition here]

set warp to 0.

[panzerwaffe044]

I use this for radial

lock steering to -vxcl(velocity:orbit, (body:position - ship:position)).

As for warping to phase angles, you can use something like this:

set warp to 3.

wait until [put your phase angle condition here]

set warp to 0.

Thanks! I've just started learning this awesome tool. One more question: can I trigger science equipment activation with no VAB upgrade? As far as I understand after reading the DOCS you can't use Partmodule:doaction without upgrading the VAB, because it doubles the ActionGroups function. I play with RT and haven't established satellite network yet and have no long-range antennae. So I can't do it manually. I don't even have solar panels. Is using the RT flight computer the only way to trigger the science? I'm going to the Mun with low tech and it would be quite a problem to enter the necessary delay, I also don't have patched conics. Maybe there are some functions within kOS I don't know yet...

[Alchemist]

You can't use DoAction calls that call the actions you may sen to action groups in VAB until it's level 3.

You can use DoEvent calls that call the events you can trigger in right-click menu.

Of course, you'll have to make the script search for specifically named part modules and trigger specifically named calls (it's the same name that's displayed in right-click menu near the button).

Or actully this can do the job of triggering all the science (if you want multiple sets, try tags or checking for the names that repeat themselves)

list parts in lp.
for p in lp
{if p:modules:contains("ModuleScienceExperiment")
{set m to p:getmodule("ModuleScienceExperiment").
m:doevent(m:alleventnames[0]).
}}

Note that untriggered experiment has only one event active and we can trigger it with this no matter the actual name.

Edited September 9, 2015 by Alchemist

[panzerwaffe044]

Of course, you'll have to make the script search for specifically named part modules and trigger specifically named calls (it's the same name that's displayed in right-click menu near the button).

Can you give an example of such code for barometer, please.

[Dunbaratu]

One of the most common things I hear people wanting to do with kOS is use it to allow them to perform a basic dumb probe landing, so they can make probe explorations in RemoteTech. Nothing fancy, nothing complex - just something to deal with the landing which can't be done well with just manuever nodes and RT's maneuver node executing flight computer.

So that's what I decided to make be the topic of my next twitch stream. I have a script already prepped that does a "good enough" job, and maybe with time permitting we'll tweak it and improve it during the stream.

I'm also doing it during the weekend so I can go earlier in the day, and thus be friendlier to people on European time and not make them have to watch in the middle of the night.

Twitch channel: http://www.twitch.tv/dunbaratu

Start Time: UTC-5 : 1200 noon, 2015-09-13, Sunday.

Duration: At least 1 hour, no more than 2.

Topic: ca_land.ks - a script to perform a constant-altitude-burn style landing on a zero-atmosphere body, presuming you've already used maneuver nodes to set up the Periapsis right above where you want to perform the landing.

[ThatOneBritishGuy...]

Hey all, sorry to bother you with something so trivial, but I'm a new KoS user. So I read through most of the basic documentation and felt that I could make my own script now. Of course, I went ahead and stole some ideas from the tutorials, but after many hours of extensive testing, my script still won't work. I've practically torn my hair out over this but my script keeps throwing some kind of error midflight about '*' not being a valid parameter specifically on THIS line:

SET atmvel TO ((2 * SHIP:SENSORS:GRAV * KERBIN:MU) / (SHIP:SENSORS * SHIP:SENSORS:PRES)).

. I know this is probably really trivial, and I seem like a total newb asking for help here, but I'd really like someone to take a look at my code and tell me exactly what I'm doing wrong. Thanks in advance for any help.

Clearscreen.SET Circalt TO 90000.
SET Targalt TO 100000.
SET Deorbalt TO 20000.
SAS OFF.
SET POP TO 0.
SET X TO 1.
WHEN SHIP:APOAPSIS > Circalt * 1.05  THEN {
    PRINT "Apoapsis has reached circulization altitude.".
    PRINT "Waiting for apoaps.".
    LOCK THROTTLE TO 0.
}


WHEN SHIP:ALTITUDE > Circalt THEN {
    PRINT "Circulization altitude reached. Starting Burn.".
    LOCK STEERING TO SHIP:PROGRADE.
    LOCK THROTTLE TO 1.
}


WHEN SHIP:PERIAPSIS > Circalt THEN {
    LOCK THROTTLE TO 0.
    PRINT "Optimal orbit achieved.".
}


PRINT "Counting down:".


FROM {local countdown is 10.} UNTIL countdown = 0 STEP {SET countdown to countdown - 1.} DO {


    PRINT "T- " + countdown.


    WAIT 1.


}




PRINT "Throttle to full.".


LOCK THROTTLE TO 1.0.


WAIT 0.2.


STAGE.
Print "And we have liftoff!".
LOCK STEERING TO HEADING ( 90, 90).
WHEN SHIP:ALTITUDE > 120 THEN {
    PRINT "Rocket has cleared the tower.".
}




WAIT UNTIL SHIP:ALTITUDE > 500.
PRINT "Starting Gravity Turn.".
SET atmvel TO ((2 * SHIP:SENSORS:GRAV * KERBIN:MU) / (SHIP:SENSORS * SHIP:SENSORS:PRES)).
LOCK accvec TO SHIP:SENSORS:ACC - SHIP:SENSORS:GRAV.
UNTIL SHIP:ALTITUDE > 70000 {
    IF accvec > atmvel {
        LOCK THROTTLE TO X - 0.1.
        SET X TO X - 0.1.
        WAIT 1.
    }
}


UNTIL SHIP:ALTITUDE > 50000 {
    SET targetPitch TO MAX( 5, 90 * (1 - ALT:RADAR / 50000)).
    LOCK STEERING TO HEADING ( 90, targetPitch).


}


WHEN STAGE:LIQUIDFUEL < 0.1 THEN {


    PRINT "No liquidfuel.  Attempting to stage.".


    STAGE.


    PRESERVE.
}


WAIT UNTIL POP = 1.
SET SHIP:CONTROL:PILOTMAINTHROTTLE TO 0.

Edited September 13, 2015 by ThatOneBritishGuy...

[Dunbaratu]

(SHIP:SENSORS * SHIP:SENSORS:PRES)).

What are you trying to multiply SHIP:SENSORS:PRES by? It looks like you're trying to multiply it by an entire structure - SHIP:SENSORS isn't a single scalar number. Its the set of all the readings. Did you forget to put another suffix after it?

[ThatOneBritishGuy...]

What are you trying to multiply SHIP:SENSORS:PRES by? It looks like you're trying to multiply it by an entire structure - SHIP:SENSORS isn't a single scalar number. Its the set of all the readings. Did you forget to put another suffix after it?

Ah yes, that'd probably be it

I was trying to multiply it by the drag coefficient and for some reason left it as SHIP:SENSORS

It was supposed to be 0.008 * SHIP:MASS * SHIP:SENSORS: PRES (Approximating terminal velocity)

Thanks for the help, I really appreciate it. I'll edit this post if the script works or not (though I think I got it from here).

[Dunbaratu]

Ah yes, that'd probably be it

I was trying to multiply it by the drag coefficient and for some reason left it as SHIP:SENSORS

It was supposed to be 0.008 * SHIP:MASS * SHIP:SENSORS: PRES (Approximating terminal velocity)

Thanks for the help, I really appreciate it. I'll edit this post if the script works or not (though I think I got it from here).

Sadly, that method is waaaaay out of date and doesn't work (i mean the formula 0.008 * mass * pressure). The code will run, but that formula is for the old atmospheric model KSP used to have when it was still in Beta before they fixed it. Now it's waaaay more complex to work out terminal velocity because ,for one thing, it actually matters which way you're pointing. You have lower terminal speed when pancacking through the air than when cutting through it like a knife.

We did recognize that the docs for kOS need to delete that whole section, but that's not happening until the next release (we tend to push new docs at the same time we push a new release out, otherwise the docs would be describing things in the development version that aren't really true for the public yet.)

[ThatOneBritishGuy...]

Sadly, that method is waaaaay out of date and doesn't work (i mean the formula 0.008 * mass * pressure). The code will run, but that formula is for the old atmospheric model KSP used to have when it was still in Beta before they fixed it. Now it's waaaay more complex to work out terminal velocity because ,for one thing, it actually matters which way you're pointing. You have lower terminal speed when pancaking through the air than when cutting through it like a knife.

We did recognize that the docs for kOS need to delete that whole section, but that's not happening until the next release (we tend to push new docs at the same time we push a new release out, otherwise the docs would be describing things in the development version that aren't really true for the public yet.)

Ah, I see. Guess I'll just have to work out some other way to keep efficiency on the high side until the next release. I'm sure I'll figure something out

[Drew Kerman]

I was trying to make a simple craft controller I could use to point the vessel by bypassing RemoteTech - long story short using AGX to bypass RT and have the action groups trigger steering commands. Problem is, RemoteTech still for some reason prevents the script from controlling the vessel locally! Here's the test code I ran:

set done to false.
on AG1 { 
set ship:control:pitch to 0.5. 
print "pitching!".
}.
on AG2 {
set ship:control:pitch to 0.
set done to true.
}.
until done {}.

So, this is supposed to be local code running on the craft itself - I switched off the RT option in the kOS settings. When I run the program and press 1, AGX bypasses signal delay and the console immediately outputs "Pitching!" and yet it takes the current signal delay (65s) for the pitch command to actually take effect.

Surely this isn't as intended otherwise how would you write a program to control a remote ship? Or am I using the wrong ship control methods?