[1.3] kOS Scriptable Autopilot System v1.1.3.0

[CaptainKipard]

Does anyone know how to throttle up in a more controlled way? My way for burns at the moment is precisely timed with throttle locked to mass/startmass giving me constant acceleration. The problem is that the throttle does not go to 1 or 0 instantaneously; there's a short throttle-up period, and a short throttle-down period. I think it's causing my burns to fall short a bit. I'd like to be able to keep my timing code, and throttle up over a specific amount of time, and just increase the burn time by that amount.

[Dunbaratu]

Good news. I just downloaded the 0.23.5 KSP update (the NASA asteroid update) and kOS appears to be working just fine without any need to change it.

I was a bit worried given what happened in the past with the 0.22 -> 0.23 update.

[TranquilTempest]

ARM got released...and I just spent all night writing an ascent autopilot. Here's a video of my progress: http://youtu.be/2hU7JOj3Kjs

The code is pretty ugly, but seems like it can handle a wide range of TWR and maneuverability.

[Hans Dorn]

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

The grammar posted on github (https://github.com/KSP-KOS/KOS/blob/master/Compilation/KS/kRISC.tpg)

actually supports this:

ARRAYINDEX -> @"#";

...

varidentifier -> array_identifier (COLON IDENTIFIER)*;
array_identifier -> function_identifier (ARRAYINDEX (INTEGER | IDENTIFIER))*;
function_identifier -> IDENTIFIER (BRACKETOPEN arglist? BRACKETCLOSE)?;

This should allow for a '#' to be followed by an integer literal or an identifier.

Maybe the next release will include this.

[Hans Dorn]

ARM got released...

Edited April 1, 2014 by Hans Dorn

[Joe32320]

I'm (pleasantly) surprised that kOS's dealings with manoeuvre nodes haven't been broken. Only thing I've had issues with so far is that the throttle dances around alot more than it did in my launch program which causes oscillations end to end in one of my rockets.

I have taken out kerbal joint reinforcer out of my game so I think that caused the oscillations to appear, with the throttle program driving it.

[Dunbaratu]

ed by an integer literal or an identifier.

Maybe the next release will include this.

Supposedly, but in practice it gives an error when you try.

[P.Funk]

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.

Thanks for helping me get started. However when I tried to launch this script I get the following error:

Error on line 0: Suffix 'control' not found on obj etc

Any ideas? I've discovered that it happens anytime I try to execute a 'set ship:control:' command.

I use lots of mods like Ferram but should this be a problem?

Edited April 1, 2014 by P.Funk

[UFO64]

Anyone else seeing a bug with surface velocity in the new patch?

My ship seems to be somehow mixing the X component of velocity:surface into the Z component. It is not a total replacement, but any time the ship has a large amount of up and down travel it will more or less "wash" the Z component out of a useful state.

[Dappa]

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.

It seems you're looking for "velocity:surfaceheading". Just add 180 and you'll be going in the opposite direction.

[erendrake]

Supposedly, but in practice it gives an error when you try.

Sorry about that, I am back from vacation and i am ready to get a real release of kOS out. Thank you everyone for your testing and I would really love to see all of the bugs you find in the tracker so we can get them fixed!

[Dunbaratu]

Sorry about that, I am back from vacation and i am ready to get a real release of kOS out. Thank you everyone for your testing and I would really love to see all of the bugs you find in the tracker so we can get them fixed!

I hope you enjoyed the break.

I sometimes feel like I'm being to "complainy" when I look at the issues list and realize I've gor 4 in a row all from me, so I back off and stop for a bit to keep the "to-do" list from looking too overwhelming.

[TranquilTempest]

Hmm, the new engines are using a different engine module, so the engines list doesn't work with them.

[Sma]

Sorry about that, I am back from vacation and i am ready to get a real release of kOS out. Thank you everyone for your testing and I would really love to see all of the bugs you find in the tracker so we can get them fixed!

Ahh, that explains it then. BOLO for a PM from me with an update. Gotta work on a new one now that the bigger tanks are out. Yep..being vague so everyone can be surprised when it's released. Muhaha >

[Dunbaratu]

Is there a way to find the altitude at which KSP decides to auto-switch from surface velocity to orbital velocity on the navball during an ascent? I'd like to be able to have my script for ascent switch which one it uses to calculate with depending upon that.

[Dunbaratu]

Filename: "stager.txt"

//KOS
// A program that will detect if there's a need to stage right now.
// Takes no arguments, but "returns" these two global variables:
//
//   stageStatus: An integer with the following meaning:
//     0 = Staging did not occur.
//     1 = Staged because the current stage has no fuel.
//     2 = Staged because of a flameout (Good for asparagus or solid boosters on the side).
//
//   stageMsg: A string describing the stageStatus.
//
// Call repeatedly in a program's main loop as you are burning.

set stageStatus to 0.
set stageMsg to "didn't stage".

if (stage:liquidfuel + stage:solidfuel = 0) {
  set stageStatus to 1.
  set stageMsg to "no fuel in stage".
}.
if stageStatus = 0 {
  // Check for flameout of any of the existing engines:
  set stg_numF to 0.
  list engines in stg_eList.
  for stg_eng in stg_eList { 
    if stg_eng:flameout {
      set stg_numF to stg_numF + 1.
    }.
  }.
  if stg_numF > 0 {
    set stageStatus to 2.
    set stageMsg to stg_numF + " engine(s) flamed out".
  }.
}.
// Now actually do it:
if stageStatus > 0 { stage. wait 0.25. }

Call it anywhere, in the midst of any burn for any reason. Ascending, transferring, landing, whatever. So long as you've got your craft's staging list set up in the right order, and all boosters are on decouplers so they can be destaged when they run dry, it seems to handle just about any rocket design, any mix of solid/liquid, and any weird asparagus staging.

Here's a very crude example of use:

print "Stupidly going straight up until all stages spent.".
print "press AG 9 to quit.".

lock steering to up.
lock throttle to 1.
until ag9 {
  run stager.
  if stageStatus > 0 {
    print "Stage Activated.  Reason: " + stageMsg.
  }.
}.

Most scripts at some point end up spinning in a loop like that rather than doing everything by waits, whens, and locks, just because people like to see displays updating what's going on on the terminal. Any time you're in the midst of a burn and in one of those types of loop, just insert a call to stager in that loop somewhere, for all your staging needs.

Edited April 4, 2014 by Steven Mading
Forgot to paste the "Now Actually do it" part from my file to the post.

[Sma]

Guess I've been away too long, didn't know there was a way to detect flame out. Nice work Steven.

I was pretty proud of the 3 stage asparagus staging program I made a while back. Stages were setup so as to be able to measure amount of fuel in the stages (divided by the number of booster stages) and it would compare that to the current stage fuel (all running engines/tanks). Once it dropped a stage, it would factor that in. For the whole thing to work you had to tell it how many paired "stages" you had. Don't think it worked very well for just 1 set of boosters though. After those were all gone it just worked like normal for the other stages.

Just before Kevin quit working on kOS I even had it setup so it could get to geo sync orbit, and adjust the orbital period so I could launch 3 com sats on the same rocket and deploy them 1/3 of the way around Kerbin. Then thats when kOS got broken, as I was working on the code to deploy the sats, and trying to figure out how to get the deployed sat to automatically run a program to circularize. Although for that I think I was going to have to run the program manually, not a big deal though I guess.

[TranquilTempest]

Is there a way to find the altitude at which KSP decides to auto-switch from surface velocity to orbital velocity on the navball during an ascent? I'd like to be able to have my script for ascent switch which one it uses to calculate with depending upon that.

36km, from watching video of an ascent.

[Dunbaratu]

36km, from watching video of an ascent.

Oh yeah I know I could hardcode it for Kerbin like that. I was hoping for a generic works-anywhere solution. The altitude where it happens is different for each body.

[Dunbaratu]

Guess I've been away too long, didn't know there was a way to detect flame out. Nice work Steven.

I was pretty proud of the 3 stage asparagus staging program I made a while back. Stages were setup so as to be able to measure amount of fuel in the stages (divided by the number of booster stages) and it would compare that to the current stage fuel (all running engines/tanks). Once it dropped a stage, it would factor that in. For the whole thing to work you had to tell it how many paired "stages" you had. Don't think it worked very well for just 1 set of boosters though. After those were all gone it just worked like normal for the other stages.

I used to do something similar but then ran into a lot of trouble trying to make it generic for all rocket designs. The problem was that it was normal for there to be some fluctuations in the calculations of fuel loss rate because part of the calculation involved dividing a very small number by another very small number to get a rather normal medium-sized number, which is a calculation that can get rather chaotic, exaggerating small errors in precision into big ones. So I had to have quite a bit of tolerance in the fuel loss rate, and only stage if the change in fuel loss was big enough not to be the result of minor precision errors. That made it really messy to try to make the script work for any rocket, big or small or complex or simple, because the window was vary narrow between setting the tolerance too low so it stages when it shouldn't, versus setting it too high so it fails to stage when it should. Just directly detecting the flameout is much cleaner now that it's possible.

[Dunbaratu]

Is there a way to only lock some but not all the controls using the SHIP:CONTROL technique? At the moment if I wanted to, for example, make an altitude-controlling autopilot, it also locks out all other controls the moment I use ship:control:pitch. Once the computer controls pitch, it also freezes roll, yaw, throttle, etc.

[Dunbaratu]

I've noticed that using the raw controls, it's possible to rotate the craft in an impossibly fast way that you'd never be able to do if rotating by manual control:

For example, I did this:

set ship:control:pitch to 20.0.

and the airplane suddenly starting spinning mega-fast and flung itself apart from centrifugal force, a lot faster than would be physically possible from pressing "S".

It occurs to me that this could be a "cheat" to allow craft with very poor rotational performance to still rotate fast anyway by just picking control numbers larger than 1.0.

[CaptainKipard]

How can I place a maneuver node at apoapsis?

In case anyone wants to know it's:

set x to node(time:seconds+eta:apoapsis,0,0,0).

add x.

Edited April 6, 2014 by Cpt. Kipard

[Camacha]

Is there a way to only lock some but not all the controls using the SHIP:CONTROL technique? At the moment if I wanted to, for example, make an altitude-controlling autopilot, it also locks out all other controls the moment I use ship:control:pitch. Once the computer controls pitch, it also freezes roll, yaw, throttle, etc.

I requested this before implementation, though I am not sure what erendrake actually did

[P.Funk]

I'm still trying to figure out what this means:

Suffix 'control' not found on object

It happens everytime I try to do a 'set ship:control' command.