[1.3] kOS Scriptable Autopilot System v1.1.3.0

[steddyj]

Word of advice for those increasing the storage space on your kOS modules: I created a ModuleManager config to add kOS to all of my probe cores with a significantly larger storage space (50000 if I recall correctly) and I quickly found that my battery was disappearing at an alarming rate. Through some trial I found that it was the kOS module that was doing this. Power needs scale directlywith the storage space, kOS was consuming 2 EC per sec. Since this is coded in the plugin, I could not override it and ended up putting in a generator module to counteract it. I'm all for kOS requiring power, and I can see the logic behind more storage potentially requiring more power, but this scale seems to need some tweaking.

[Dunbaratu]

Tried the mod yesterday, and found new features missing (or I don't know they exist) which I would really like to have:

1. user-defined functions. Any more-or-less complex program quickly turns into unmaintanable mess of code (tried to create a program for automatic powered lander that uses suicide-burn while keeping in mind the presence of atmosphere (I play with RealFuels, which fixes engine behaviour in atmosphere, but also complicates landing because actual thrust is less than in vacuum and not constant)- 3-way PID for orientation, plus additional one for throttle (for the very last stage of landing sequence, program times suicide burn such that it would bring vertical speed to 0.5m/s at 3 meters above the ground, and after it adjusts throttle to keep that speed until touchdown).

2. connected to previous one - ability to include other files (c-like #include would do). It would allow to reuse code without copy-paste.

3. Ability to control engine's gimbal (for those engine which can gimbal of course). Keep in mind that the engine can have several thrustTransforms for multi-nozzle engines - for example RD-180 has two, while RD-171M has four, and it would be best to have ability to control them independently (for example RD-180 provides roll control by vectoring nozzles in opposite directions).

4. I would like ability to control other CPUs on the same vessel (simplest example - having secondary CPUs on boosters, and start avoidance program (gimbal booster engine away from the core like Shuttle SRBs do) on them just after separation.

Is any of that in plans?

Thanks!

All of it is in the "it would be nice" plans. We're well aware of them all. The chief problem is that kOS is really an enormous undertaking limited mostly by free time rather than by capability. They're all doable. But we have to think in terms of "triage". Some improvements aren't too hard but also aren't that useful, so they aren't high priority. Some improvements are quite useful but require quite a lot of work, so they aren't high priority as they'd prevent other stuff from getting done. The stuff in between those two extremes ends up getting done first.

The telnet stuff I'm working on now would normally fall into that "but require quite a lot of work" category and therefore not be getting done, were it not for the fact that I view it as a pre-requisite for doing proper keyboard input to scripts, which is a big deal everyone wants. I view it as a pre-requisite for proper keyboard input simply because any code to deal with keyboard input would have to be rewritten later on once telnet becomes possible. The telnet isn't higher priority, but it affects the terminal infrastructure in such a way that I'd rather have it fleshed out before fiddling with the other stuff that uses that architecture, like keyboard input.

By the way, erendrake is working on the gimbal thing you listed as #3.

[asmi]

All of it is in the "it would be nice" plans.

Thanks! That's what I figured it would be. One question though - what is your policy on pull requests? I might be able to find some time to help implementing these things I've talked about, but I want to make sure I won't step on anyone's shoes.

Oh, and a quick bug report - ENGINE:THRUSTLIMIT field's setter is clamping incoming value into 0..1 interval, while it should clamp into 0..100 (since that number is thrustPercentage).

[Trewor007]

SET LEFT1 TO SHIP:PARTSTAGGED("LEFT1")[0].
SET LEFT2 TO SHIP:PARTSTAGGED("LEFT2")[0].
LEFT1:GETMODULE("MUMECHTOGGLE"):DOACTION("MOVE -", 1).

Hi im goofing around with IR and i got a question about partmodule.

id tagged all my IR parts, so each part has it one unique tag. And i set every tag to a unique name in kOS.

the problem is that a was thinking i can call the part just like Parallax did when making His bipod walker. But kOS only lets me call a list and when i add a iteration (SET LEFT1 TO SHIP:PARTSTAGGED("LEFT1")[0]), kOS gives me an Can't iterate on an object of type kOS.Safe.Encapsulation.ListValue error.

How can I correctly call a part (not the list where is the part) by its Set name?

Edited January 17, 2015 by Trewor007

[Dunbaratu]

Hi im goofing around with IR and i got a question about partmodule.

id tagged all my IR parts, so each part has it one unique tag. And i set every tag to a unique name in kOS.

the problem is that a was thinking i can call the part just like Parallax did when making His bipod walker. But kOS only lets me call a list and when i add a iteration (SET LEFT1 TO SHIP:PARTSTAGGED("LEFT1")[0]), kOS gives me an Can't iterate on an object of type kOS.Safe.Encapsulation.ListValue error.

How can I correctly call a part (not the list where is the part) by its Set name?

That was a bug in one of the releases that has already been fixed in the most recent releases. Are you sure you have the most recent release? If you do, then something is weird about it because other people are able to do it without getting that error anymore.

[Trewor007]

im running 15.5 but just to be safe ill download kos again

EDIT:now it works. Thanks! probably ive updated it without deleting the old folder first.

Edited January 17, 2015 by Trewor007

[Camacha]

Word of advice for those increasing the storage space on your kOS modules: I created a ModuleManager config to add kOS to all of my probe cores with a significantly larger storage space (50000 if I recall correctly) and I quickly found that my battery was disappearing at an alarming rate. Through some trial I found that it was the kOS module that was doing this. Power needs scale directlywith the storage space, kOS was consuming 2 EC per sec. Since this is coded in the plugin, I could not override it and ended up putting in a generator module to counteract it. I'm all for kOS requiring power, and I can see the logic behind more storage potentially requiring more power, but this scale seems to need some tweaking.

I had not realized that, that is actually very useful to know.

[Vegemeister]

It seems that some things have higher precedence than attribute accessing. Particularly, boolean not. consider this code snippet:

if eng:ignition and not eng:flameout {
    //do stuff
}

This actually fails, with the error "cannot boolean-not EngineValue". To make it work, I needed this instead:

if eng:ignition and not (eng:flameout) {
    //do stuff
}

I found the behavior rather surprising, and I can't think of any situation where people would write their code intending to use it that way.

[Ziw]

To Authors:

When do you plan to release an update? Since version 1.6.0 of RemoteTech the RT2 integration with KOS is broken (works fine with version 1.5.2 of RT2 though). Can you release a quick fix, or we have to wait for a major update Steven was writing about?

[Drew Kerman]

it's probably broken in kOS because Remote Tech changed their namespace (again) so there's really nothing you can do except use 1.5.2 or wait for kOS to update

[Richy330]

Hello!

I don't have much experience with kOS, and am basically new to programming, but i'm figuring things out.

At the moment, I'm trying to write my own automated plane pilot, using raw controls, but i ran into a problem. I am passing a desired pitch of the craft(pitch above horizon) to my script andd it adjustes the control surfaces to achieve this pitch via a PID loop. The problem with this is the PID tuning. It either works super slowly, but stable, or works faster, but becomes unstable at higher altitudes. When i look at the cooked controls, and see how well and quickly they react, it comes to my mind that there must be a better way:).

Could someone pass me an idea how to counter this problem?

My script is this(i hope it's ok to post it here):

clearscreen.



//Attitude Control - Vectors
lock fore to ship:facing:vector.
lock aft to (-fore).
lock up to ship:up:vector.

lock rightrot to ship:facing * r(0,90,0).
lock right to rightrot:vector.
lock left to -1*right.

lock top to vcrs(fore,right).
lock bottom to -1*top.

lock righthor to vcrs(fore,up).
lock lefthor to -1*righthor.

lock forehor to vcrs(right,up).
lock afthor to (-forehor).

//Attitude Control - Angles
lock absaoa to vang(fore,srfprograde:vector).
lock aoa to vang(top,srfprograde:vector)-90.
lock sideslip to vang(right,srfprograde:vector)-90.
lock pitchangle to vang(fore,forehor)*((90-vang(fore,up))/abs(90-vang(fore,up))).
lock rollangle to vang(left,righthor)*((90-vang(top,righthor))/abs(90-vang(top,righthor))). //roll angle, 0 at level flight

set wantpitch to pitchangle.
set wantroll to 0.
set k to 1.

on ag3 {set k to k + 0.1. preserve.}.
on ag4 {set K to K - 0.1. preserve.}.
on ag7 {set wantpitch to wantpitch + 1. Preserve.}
on ag8 {set wantpitch to wantpitch - 1. Preserve.}
on ag5 {set wantroll to wantroll + 1. Preserve.}
on ag6 {set wantroll to wantroll - 1. Preserve.}



set kpi to 0.001 * k. //pitchgains
set kpp to 0.02 * k.
set kpd to 0.002 * k.

when ship:altitude > 100000 then {set kpi to 0.005.
    when ship:altitude > 15000 then {set kpi to 0.003.
  when ship:altitude > 20000 then {rcs on.
   preserve.}.
    preserve.}.
preserve.}.

set kri to 0.   //rollgains
set krp to 0.05.
set krd to 0.05.

set Ep to wantpitch - pitchangle.
if Ep > 10 {set Ep to 10.}.
set Epo to Ep.
Set Ip to 0.
set T to time:seconds.

set Er to wantroll - rollangle.
if Er > 10 {set Er to 10.}.
set Ero to Er.
Set Ir to 0.


wait 0.05.



until false{

set Ep to wantpitch - pitchangle.
if Ep > 10 {set Ep to 10.}.

set dt to time:Seconds - T.
set Dp to kpd*(Ep-Epo)/dt.
set Pp to kpp*Ep.
set Ip to Ip + kpi*(Ep+Epo)*dt.
if Ip > 1 {set Ip to 1.}.

set ship:control:pitch to Pp+Ip+Dp.

set Epo to Ep.

set Er to rollangle - wantroll.


set Pr to krp*Er.
set Ir to Ir + kri*(Er+Ero)*dt.
if Ir > 1 {set Ir to 1.}.
set Dr to krd*(Er-Ero)/dt.
set ship:control:roll to (Pr+Ir+Dr).


print "K= " + K at(0,15).
print "Pp= " + round(Pp,5) at(0,19).
print "Dp= " + round(Dp,5) at(0,20).
print "Ip= " + round(Ip,5) at(0,21).
print "pitchcontrol= " + 100*round(ship:control:pitch,3) +"%" at(0,22).
print "Pitchangle= " + round(pitchangle,2) at(0,23).
print "Wantpitch = " + round(wantpitch,2) at(30,23).
Print "Ep= " + round(Ep,2) at(0,24).

print "Pr= " + round(Pr,5) at(0,26).
print "Dr= " + round(Dr,5) at(0,27).
print "Ir= " + round(Ir,5) at(0,28).

Print "Er= " + round(Er,2) at(0,29).
print "Rollangle= " + round(rollangle,2) at(0,30).
print "Wantroll= " + round(wantroll,2) at(30,30).


set Ero to Er.
set T to time:seconds.



wait 0.05.

}

I am using FAR by the way.

Thanks in advance

[erendrake]

To Authors:

When do you plan to release an update? Since version 1.6.0 of RemoteTech the RT2 integration with KOS is broken (works fine with version 1.5.2 of RT2 though). Can you release a quick fix, or we have to wait for a major update Steven was writing about?

This is on me because i was the one who broke it in RemoteTech I am trying to get a release done today but with a 2 month old baby plans have a way of slipping away

Update: my fears about screaming baby were well founded. i was able to test a fix, i should be able to get the fix and the version changes done and it all out fairly soon.

Edited January 19, 2015 by erendrake

[Ziw]

This is on me because i was the one who broke it in RemoteTech I am trying to get a release done today but with a 2 month old baby plans have a way of slipping away

Update: my fears about screaming baby were well founded. i was able to test a fix, i should be able to get the fix and the version changes done and it all out fairly soon.

Family comes first, don't worry, we'll wait.

[Farex]

Greetings!

This looks really interesting, but unfortunatly I don't have the time to read all 252 Pages, so just a quick question:

Is it possible to make my craft do this?

- if Stage 7 has no fuel left, activate Stage 6

This is really the only thing I would want to have, a fluid, seamless activation of all my lifter stages for the ultimate, most beautiful takeoff and flight to orbit ever.

[Ziw]

Greetings!

This looks really interesting, but unfortunatly I don't have the time to read all 252 Pages, so just a quick question:

Is it possible to make my craft do this?

- if Stage 7 has no fuel left, activate Stage 6

This is really the only thing I would want to have, a fluid, seamless activation of all my lifter stages for the ultimate, most beautiful takeoff and flight to orbit ever.

Hi,

I use this snippet of code for staging (it was posted here on one of those 252 pages)

set stagemaxthrust to ship:maxthrust.
when status <> "PRELAUNCH" and (ship:maxthrust<stagemaxthrust or ship:maxthrust<1) then {
    print "Stage!".
    stage.
    set stagemaxthrust to ship:maxthrust.
    preserve.
}

[Dunbaratu]

Greetings!

This looks really interesting, but unfortunatly I don't have the time to read all 252 Pages, so just a quick question:

Is it possible to make my craft do this?

- if Stage 7 has no fuel left, activate Stage 6

This is really the only thing I would want to have, a fluid, seamless activation of all my lifter stages for the ultimate, most beautiful takeoff and flight to orbit ever.

I usually prefer to go with this logic:

Whenever an engine flames out, start hitting the stage button repeatedly until no more flamed out engines are attached anymore and there is at least one working engine attached (Just like in manual piloting, hitting 'stage' doesn't always have an effect if you've hit 'stage' too recently. It has a cool down period. So what I do is usually hit 'stage' again and again until I see that mass has dropped as proof that it worked.)

set numFlamedOut to 9999. // bogus start value forces loop to occur at least once.
until numFlamedOut = 0 and ship:maxThrust >0 { // ship:maxthrust will zero if no engines are active.
  list engines in engs.
  for e in engs { if e:flameout { numFlamedOut = numFlamedOut + 1. }. }.
  if numFlamedOut > 0 or ship:maxthrust = 0 {
    stage.
  }.
}.

Edited January 19, 2015 by Steven Mading

[Vaulter]

Just leave it here:

list engines in myEng.
set sum_f to 0. // thrust in N
set sum_f_isp to  0. // thrust/Isp


for engine in myEng {
	if ( engine:IGNITION ) {
    set engine_thrust to engine:maxthrust * engine:thrustlimit / 100.
    set sum_f to sum_f + engine_thrust.
    set sum_f_isp to  sum_f_isp + (engine_thrust / engine:isp).
  }


	//print engine + ": " + ).
}


set Isp to sum_f / sum_f_isp.
print "Isp = " + Isp.

Calculate weighted Isp for ship.

[Cairan]

Wow. There's a lot which went in for 0.90 in the latest updates... It's going to take me sometime to get back into it, but with the new "tiers" involved there's room for very interesting stuff for kOS ...

Will read the past 100 pages of the forum to see what I missed!

[Crzyrndm]

At the moment, I'm trying to write my own automated plane pilot, using raw controls, but i ran into a problem. I am passing a desired pitch of the craft(pitch above horizon) to my script andd it adjustes the control surfaces to achieve this pitch via a PID loop. The problem with this is the PID tuning. It either works super slowly, but stable, or works faster, but becomes unstable at higher altitudes.

You're running into pretty much the same problem Pilot Assistant does: nice PID tuning works really well for a very specific situation, but a flight situation changes significantly based on airspeed and altitude (or rather atmospheric density). If you take a look in FAR's readouts, you'll probably find that the instability occurs past a certain high/low level of dynamic pressure / 'Q' (I don't know which in your case, upper atmospheric flight can have either).

High dynamic pressure results in excess control authority and the PID over-reacting (short, sharp oscillations. Typically followed by the plane shaking to pieces)

Low dynamic pressure results in inadequate control authority and PID under-reacting (big, slow oscillations. Spins and other "fun" are the more likely result)

Now, I don't really have much of an idea of what your script does (not a kOS user myself), but the easiest way to get around Q changes in my experience is to have a final scalar you can apply to the PID to change on the fly (if that's not feasible with kOS, maybe some form of lookup to do some mangement as you fly?). As Q increases, you scale down the output. As Q decreases, you scale up the output. It's not linear (that would just be too easy...) so don't try scaling it by dynamic pressure (that ends really badly).

Hope that helps somewhat

[erendrake]

v0.15.6

From github

[h=3]BREAKING[/h]

• PART:UID is now a string. This will only break you if you were doing math on UIDs?
  
• ELEMENT:PARTCOUNT was poorly named and duplicated by ELEMENT:PARTS:LENGTH so it was removed.
  

[h=3]New Features[/h]

• (AGX) Action Groups Extended Support! Thanks @SirDiazo
  
  • Getting or setting groups 11-250 should behave the same as the stock groups if you have AGX installed.
    
  • Groundwork is laid for getting parts and modules by the new action groups.
    

  [*]Gimbals are now a well known module. providing read access to its state

  [*]Added PART:GETMODULEBYINDEX(int). This is most useful when you have a part with the same module twice. Thanks @jwvanderbeck

  [*]More documentation work. http://ksp-kos.github.io/KOS_DOC/

[h=3]Bug Fixes[/h]

• Fixes RemoteTech Integration
  
• Structures can now be correctly ==, <> and concatenated with +
  
• STAGE:RESOURCE[?]:CAPACITY is now spell correctly
  

[Diazo]

Great to see this released!

For those wanting more information, the Action Groups Extended forum thread is here.

Happy KSPing all,

D.

[Farex]

@Vaulter, Steven and Ziw - thank you, may this rep be your loot

[Dr_Goddard]

Congrats on the new release!

I'm still having problems with autorun. It just isn't working right, or simply has limitations I'm not perceiving.

I have 3 cores.

I have three bootX.files (boot.ks, boot1.ks,boot2.ks)

In order to select each of these files in the VAB I have to add a fourth dummy file (boot4.ks)

Now, this worked fine for a while. Core1 runs the user interface. Core2 handles coordinated servo motion. Core3 handles environmental monitoring.

But when I ran into another problem the kraken struck.

I wanted to be able to disable a function provided by the second core (running boot2).

I tried every kind of way through action groups to pass a command to core 2, but nothing worked.

So I struck on another answer. Use an action group to power down the core, and then reboot it when required again! Yay!

BUT, core2 on rebooting refuses to use it's own boot file. It seems to use the last boot file loaded or something.

I don't have the time today to go through it and thoroughly dissect the problem.

I have to step up my C++ study so I can help with this.

                 .--.       .--.
                     \     /"      
            |\       `\___/'       /|
             \\     .-'@ @`-.     // 
              ||  .'_________`.  || 
               \\.'^    Y    ^`.//
               .'       |       `.
              :         |         :
             :       ATHLETE       :
             :        Ver.1        :
             :     _    |    _     :
             :.   (_)   |   (_)    :
           __::.        |          :__
          /.--::.       |         :--.\
       __//'   `::.     |       .'   `\\__
      `--'     //`::.   |     .'\\     `--'
              ||   `-.__|__.-'   ||
              ||                 ||
              //                 \\
             |/                   \|

Edited January 20, 2015 by Dr_Goddard
needed ascii font for logo.

[Parastie]

Question regarding vecdraw and an offset piece. Basically, I have an inline docking port and I'm trying to get the origin of the vector to be the docking port. However, when I set the vector origin to the port origin it generates off the main ship.

I'm guessing the the position is a raw position and I can't figure out the proper syntax to get the ships raw position (as apposed to (0,0,0). I'll post my short script when I get home from work if it'll help. Thank you!

[Dunbaratu]

Question regarding vecdraw and an offset piece. Basically, I have an inline docking port and I'm trying to get the origin of the vector to be the docking port. However, when I set the vector origin to the port origin it generates off the main ship.

I'm guessing the the position is a raw position and I can't figure out the proper syntax to get the ships raw position (as apposed to (0,0,0). I'll post my short script when I get home from work if it'll help. Thank you!

The ship's raw position IS V(0,0,0) in kOS terminology. The weird contradictory coordinate system of underlying KSP is re-origined at the current ship's CoM for all position vectors in kOS (although it's not re-rotated to something sane - it stays at the underlying rotation). Oddly enough, it's still not origined at the vessel for VELOCITY purposes (which would zero your velocity if it was), but rather it reports the velocity at which the rest of the objects in the universe are passing you by.