[1.3] kOS Scriptable Autopilot System v1.1.3.0

[madlemur]

SnappingTurtle Ive remember seeing on youtube docking with KOS. So You can try. a ternary operator? Nope ( but not 100% sure).

Steven Mading

I donk know why but my KOS is protesting at this line;/

set velKerbinFromSun to (kerbin:velocity:orbit - sun:velocity:orbit).

Its probably a glitch on my ksp side (I've used :velocity:orbit literally yesterday).

I've done it, a little bit different ( read as: its more code, and its a mess.), in relation to sun position the plane is divided in 4 squares and im checking in witch one is kerbin and duna at one time. that's a lot of combinations but its working for now.

Kerbol is the root SOI. Isn't :velocity:orbit in relation to the parent body?

[Dunbaratu]

Kerbol is the root SOI. Isn't :velocity:orbit in relation to the parent body?

Yeah, you'd think.

Velocity is relative to whatever the CURRENT SOI of the SHIP is. If your ship is around a body, that body's velocity is zero.

To do anything meaningful with bodies, it's always a good idea to get things relative to other things, so it works no matter where the current ship is. Subtracting a vector from another vector is a way to eliminate the "where is the real origin?" from the picture.

[Laie]

Hi, anyone have idea why LOCK STEERING TO Heading (90,20) in atmosphere cause that roll control is oscillating?

It's because of how the controller works. If you look at the inputs in the lower-left corner of the screen, you will see that they are fluttering a lot, constantly correcting for the last 1/100th of a degree. As long as you are using the cooked controls, you'll be stuck with that. If it leads to visible flutter, this means that either a) you have too much control authority or your craft is wobbly. The latter can be real fun if it resonates with the kOS controls (very rare, but can happen).

[Dunbaratu]

It's because of how the controller works. If you look at the inputs in the lower-left corner of the screen, you will see that they are fluttering a lot, constantly correcting for the last 1/100th of a degree. As long as you are using the cooked controls, you'll be stuck with that. If it leads to visible flutter, this means that either a) you have too much control authority or your craft is wobbly. The latter can be real fun if it resonates with the kOS controls (very rare, but can happen).

We'll probably cave in and fix this at some point. I've wanted to leave it wonky so that people write their own controller from the raw components, but as it's the first thing people see, it's a big problem for the mod's reputation. I don't like people thinking "these idiots know nothing about the project they're working on", when the truth is "they know how it could be fixed but fear that fixing it will deny users of the sense of accomplishment of writing their own."

It's meant as a crutch to get people started, not a final perfect solution. But yeah, the resonating oscillations that keep getting bigger over time are a big problem case. I've seen it myself on one of my designs. It seems to be worst when there's a lot of flexibility and bendy-ness to the craft, between the command core and the bulk of the fuel mass, such that there's a bit of a delay between when the command core stops rotating and when the rest of the craft stops rotating. That seems to cause the oscillation cases where over time it swings wilder and wilder until it's uncontrollable. I have Deadly Re-Entry installed and it checks the G forces for pilot survivability. I've had pilots die from experiencing 15 G oscillations during LOCK STEERING during ascent because the rocket was doing the banana dance.

I'd still prefer it to be less than perfect and have a bit of wobble, but it should at least be fixed to the point where the deadly resonance feedback gets dampened.

[Hitokiri]

I've wanted to leave it wonky so that people write their own controller from the raw components, but as it's the first thing people see, it's a big problem for the mod's reputation.

Well, maybe I'm not the right user for this mod - after all I'm not developer, but rather from OPS - I like my scripts neat and stitched together from samples from around the web

The code I put together had simple purpose - to be able to lunch SSTO without my interaction - so I can read my e-mails, be on forum here or do whatever else. If it will require to write my own controller from raw components than it is not something I can achieve in reasonable time - therefore defying the original purpose - save some time. :-)

[Trewor007]

set velKerbinFromSun to (kerbin:velocity:orbit - sun:velocity:orbit).

KOS is still rejecting this line. I get " Object reference not set to an instance of an object" message all the time ;/

[Dunbaratu]

set velKerbinFromSun to (kerbin:velocity:orbit - sun:velocity:orbit).

KOS is still rejecting this line. I get " Object reference not set to an instance of an object" message all the time ;/

I may have time to look at this later tonight. I suspect it's got something to do with the Sun being a minimal CelestialBody that's missing a few things that other bodies have.

[Cairan]

I may have time to look at this later tonight. I suspect it's got something to do with the Sun being a minimal CelestialBody that's missing a few things that other bodies have.

My guess would be that since the Sun is probably the center of the Kerbal Universe (Kerbolocentric? Kopernikus? ), it lacks orbital parameters, hence it can't have an orbital velocity...

[NoPanShabuShabu]

IMO, for working with numbers within an epsilon tolerance it occurs to me that it would be a very useful shorthand for kOS to supply people with a function that works like so:

if WITHIN( x, 5.0, 0.1) { stuff }.

Which means "is x nearly 5.0, within a tolerance of plus or minus 0.1?", and would be the same as this:

if x >= (5.0-0.1) and x <= (5.0+0.1) { stuff }.

Alternately you could use:

if abs(x-5.0) >= 0.1 {stuff.}

Edit: I see Lorentz beat me to that one. I think it's pretty much the simplest way to go.

Edited November 7, 2014 by NoPanShabuShabu

[Camacha]

The code I put together had simple purpose - to be able to lunch SSTO without my interaction - so I can read my e-mails, be on forum here or do whatever else. If it will require to write my own controller from raw components than it is not something I can achieve in reasonable time - therefore defying the original purpose - save some time. :-)

If you want a simple solution, MechJeb is probably a bit more suitable. Maybe Flight Computer.

[Dunbaratu]

I may have time to look at this later tonight. I suspect it's got something to do with the Sun being a minimal CelestialBody that's missing a few things that other bodies have.

Bug confirmed. Sun:Velocity:Orbit causes null reference exception.

Another technique that may work is to get Body2's position relative to Body1 (i.e. Duna:position - Kerbin:position), and then get the relative velocity between them (Duna:velocity:orbit - Kerbin:velocity:orbit). And from that work out if Body1 is traveling mostly toward Body2(VDOT between position and vel is positive) or away from Body2 (VDOT between position and vel is negative). Also take into account whether Body1 is the one in a lower orbit or if Body2 is the one in the lower orbit. From those you should be able to work out whether Body1 is behind or ahead of Body2. If the lower orbit body is behind the higher orbit body, it should be closing the distance. If the lower orbit body is ahead of the higher orbit body, it should be widening the distance.

[NoPanShabuShabu]

To all those who were talking about finding the phase angle between planets, isn't this the simplest thing to do:

set PhaseAngle to duna:longitude - kerbin:longitude +360.

That's using Kerbin as the starting point and Duna as the destination, you can substitute any bodies orbiting the same body. It's also ranging from 0 to 360. If you wanted it to be -180 to +180 then add:

if PhaseAngle > 180 set PhaseAngle to PhaseAngle - 360.

[Bill Brasky]

The code I put together had simple purpose - to be able to lunch SSTO without my interaction - so I can read my e-mails, be on forum here or do whatever else. If it will require to write my own controller from raw components than it is not something I can achieve in reasonable time - therefore defying the original purpose - save some time. :-)

I just wanted to take a moment in light of this comment to reaffirm the modders' vision for kOS and thank them for their effort.

This mod made re-learning stuff like trigonometry and other math concepts I'd totally forgotten fun and worth doing. Learning about PID controllers to write my own SSTO autopilot (with FAR installed) was probably the most rewarding challenge gaming has ever provided. I never cared about math in school and now I'm a professional still struggling with it. My first kid is on the way, and I don't want to admit to him someday that I just don't understand math and programming. Thanks to you guys, I'm taking my first real steps towards not having to (even if they are lil baby steps).

So thank you, and don't compromise on the DIY aspect. If anything, cooked control should have its name changed to 'easy mode.'

Edited November 7, 2014 by Bill Brasky

[Camacha]

This mod made re-learning stuff like trigonometry and other math concepts I'd totally forgotten fun and worth doing. Learning about PID controllers to write my own SSTO autopilot (with FAR installed) was probably the most rewarding challenge gaming has ever provided. I never cared about math in school and now I'm a professional still struggling with it. My first kid is on the way, and I don't want to admit to him someday that I just don't understand math and programming. Thanks to you guys, I'm taking my first real steps towards not having to (even if they are lil baby steps).

Totally off topic, but what always motivates me is that I found out that Brian Cox had other interests when he was in school, just like me, and failed mathematics. Only through dedication and excercise he got to where he is now. I tend to remind myself of that when I am fed up with some problem that won't solve properly. And, of course, seeing the results immediately in a pretty intuitive way through kOS does not hurt either.

Edited November 7, 2014 by Camacha

[Laie]

I've wanted to leave it wonky so that people write their own controller from the raw components, but as it's the first thing people see, it's a big problem for the mod's reputation.

At the risk of sounding like a broken record, but as long as directions are as inaccessible as they are...

Also, my own SSTO ascent script is 8400 bytes @ 25bytes per line. When/If I ever come to terms with directions, I sincerely doubt that I can implement my own controller in less than 1600 bytes / 64 lines. Actually... even if kOS would give me useful directions in a single, one-line function, 64 lines for a controller seem quite tight.

[Dunbaratu]

At the risk of sounding like a broken record, but as long as directions are as inaccessible as they are...

They are not inaccessable. The math for doing so, however, is quite wordy, and with the 10000b limit that's a problem.

Also, my own SSTO ascent script is 8400 bytes @ 25bytes per line. When/If I ever come to terms with directions, I sincerely doubt that I can implement my own controller in less than 1600 bytes / 64 lines. Actually... even if kOS would give me useful directions in a single, one-line function, 64 lines for a controller seem quite tight.

I agree that the limit is too small right now. I've never been a fan of it. It was inherited from Nivekk's old code and I always thought it was a bit small. The ML compiler will help a little bit, in that you won't get penalized for proper commenting and whitespace and long names, but it can't entirely make the 10000b limit reasonable. It's still a problem and I'd like to see it fixed by offering several scaled varieties of the CPU part - one that's large and heavy and small in storage early in the tech tree, and ones that are smaller in diameter but better at storage later in the parts tree.

In the meantime, if you don't like the limit you can always change it. It's in the part.cfg file for the SCS comptronix parts.

[SnappingTurtle]

What I've found is that as long as you're craft has a suitable amount of torque (in all 3 axes) then lock steering is more than adequate for controlling a spacecrafts orientation. If not then you have to write a more complicated control mechanism. This makes it harder to share scripts between crafts without always using a more precise method than lock steering. This may not be so bad if/when user-defined functions are introduced.

Can I request that vectors be given a unary - operator?

Thanks.

[Trewor007]

Steven Mading Thanks. Now the codes is 100%.

NoPanShabuShabu That method gives sometimes very strange readings like 518.

BTW:

is there a suffix for :Body with will give mi the radius of SOI of currently orbiting body? Something like Ship:Body:RadSOI? if not where can I propose that to the mod creator?

[Dunbaratu]

Can I request that vectors be given a unary - operator?

I assume you want it to mean the same thing as (-1)*TheVector ?

Seems reasonable to me. Added to the issues list as => https://github.com/KSP-KOS/KOS/issues/341

[Dunbaratu]

is there a suffix for :Body with will give mi the radius of SOI of currently orbiting body? Something like Ship:Body:RadSOI? if not where can I propose that to the mod creator?

I can remember asking for that ages ago when I was writing kOS scripts but wasn't helping develop it. I guess it never was implemented.

One of the arguments against providing it was that it's getting "magic" data from the simulation, but I would argue that this isn't a fair argument for not including it because the fact that that information is even necessary in the first place is entirely due to an artifact of the simulation. One of the ways the simulation differs from reality is that the simulation will let you escape the gravity well at far less than escape velocity, because you'll escape by merely being higher than SOI radius. All the good math skills in the world won't help you figure out that your vessel will escape even though your orbit is still elliptical and not hyperbolic unless you have that SOI radius number from the simulation to know the point at which the simulation breaks from reality.

So, yeah it should exist => https://github.com/KSP-KOS/KOS/issues/342

[Laie]

In the meantime, if you don't like the limit you can always change it. It's in the part.cfg file for the SCS comptronix parts.

That limit is bearable, IMO, the SSTO thing is far and away my largest script. Instructions/second, however,... but I'd rather not tamper with the defaults. Should I ever share code, I want it to run on other people's kOS just as well or badly as it does on mine. (BTW: is there a place for code-sharing?).

As to kOS cooked controls and wobbliness: I've only experienced resonance once, and that vessel would resonate even with stock SAS (I think that's in the nature of resonance). Most of the time, it's only a question of visible flutter. It may look ugly, or sometimes even scary, but is ultimately harmless. On top of that, it can largely be dealt with in assembly. I've long since learned to build my craft such that kOS can handle them. Compared to writing my own controller, this was the path of least resistance.

[hvacengi]

Instructions/second, however,...

I had to increase my ipu. If I didn't, I was getting this weird error where kOS would try to run each line of my script twice (so it would run the launch, then try to run it again, then execute the circularize node, then try to execute a nonexistent node and fail).

All this talk of doing a PID controller made me look into it again just to figure out which are the part that are holding me back. Looks like my two biggest stumbling blocks are wrapping my head around the coordinate system, and code re-usability. I really miss being able to write a function once and just call it later. I have a couple ideas about how to use locks to do the same thing, but I'll have to see.

I'd also like to chime in on the storage size. I too find my self running out of space, but I don't like the idea of simply editing the config file to increase my capacity. I don't know how complicated this would be, but would it be possible to preset the structure of the multiple volume file system? I like the idea of simply adding additional storage from other kos modules. So one could hold the orbit insertion scripting, another module could hold a log file, and one dedicated to landing, all the while not requiring a connection back to Kerbin. I want to experiment a little with selective boot scripts this weekend to try and make this work, but the last time I tried to adjust the boot script execution I don't think it worked.

[Cairan]

I'd also like to chime in on the storage size. I too find my self running out of space, but I don't like the idea of simply editing the config file to increase my capacity. I don't know how complicated this would be, but would it be possible to preset the structure of the multiple volume file system? I like the idea of simply adding additional storage from other kos modules. So one could hold the orbit insertion scripting, another module could hold a log file, and one dedicated to landing, all the while not requiring a connection back to Kerbin. I want to experiment a little with selective boot scripts this weekend to try and make this work, but the last time I tried to adjust the boot script execution I don't think it worked.

I use ModuleManager configs to add kOS to stock cockpits and pods, and depending on the type, with more or less capacity. The basic command pod (mk1pod) and the external command chair are left without kOS. Also, you can use toggles and boot scripts to power off all kOS-equiped parts except one, rename them, and then power them back up. You could very well do this:

// Boot loader example

AG9 OFF. // Action Group 9 is defined to cut power to all kOS parts except one...
WAIT 0.001.

SET lvm TO LIST().
SET lvm:ADD TO "root".
SET lvm:ADD TO "var".
SET lvm:ADD TO "ascent".
SET lvm:ADD TO "orbit".
SET lvm:ADD TO "reentry".

// A workaround while the "LIST VOLUMES IN foo" issue is resolved in the next update...
SET hdd TO 0.
SWITCH TO 1.
LIST PARTS IN shparts.
FOR part IN shparts {
  FOR mod IN PART:MODULES {
    IF mod = "kOS.Module.kOSProcessor" {
      LOG "RENAME VOLUME "+(hdd+1)+" TO "+lvm[hdd]+"." TO lvmmap.
      SET hdd TO hdd+1.
    }.
  }.
}.
PRINT "Number of kOS-CPUs: "+hdd.
RUN lvmmap.
DELETE lvmmap.
LIST VOLUMES.

AG9 ON.

// Then copy your files to the correct volumes

SWITCH TO Archive.
COPY disp TO root.
COPY staging TO ascent.
COPY approach TO reentry.
COPY chutes TO reentry.
// ... you get the idea.

LIST VOLUMES. // confirm stuff has been copied...

FOR hd IN lvm {
  SWITCH TO hd.
  LIST FILES.
}.

SWITCH TO var.
LOG TIME:CALENDAR+" "+TIME:CLOCK+" Boot complete" TO syslog. // Here we write to our log-dedicated volume "var".
SWITCH TO root.

And here's the Module Manager config I use ... I named it CMkOS.cfg and placed it in the kOS GameData directory...

@PART[Mark1-2Pod]:HAS[@MODULE[ModuleCommand],!MODULE[kOSProcessor]]
{
        MODULE
        {
                name = kOSProcessor
                diskSpace = 7500
        }
}

@PART[*ockpit*]:HAS[@MODULE[ModuleCommand],!MODULE[kOSProcessor]]
{
	MODULE
	{
        	name = kOSProcessor
        	diskSpace = 7500
	}
}

@PART[*probe*]:HAS[@MODULE[ModuleCommand],!MODULE[kOSProcessor]]
{
        MODULE
        {
                name = kOSProcessor
                diskSpace = 2500
        }
}

@PART[*]:HAS[@MODULE[ModuleCommand],!MODULE[kOSProcessor]]
{                                                                                                                                                      
        MODULE                                                                                                                                         
        {                                                                                                                                              
                name = kOSProcessor
                diskSpace = 5000
        }
}

@PART[mk1pod]
{
        -MODULE[kOSProcessor] {}
}

@PART[seatExternalCmd]:Final
{
        -MODULE[kOSProcessor] {}
}

Edited November 8, 2014 by Cairan

[Trewor007]

HI!

I was creating, a part of the code checking current Angle to prograde. Because my 3 point for checking the angle (prograde, kerbin, ship) are 3 different thing they don't share all the necessary suffixes. So i needed to get creative. So now im with a perfectly working code except one thing. the calculation is "rotated" by 90° so 0° instead on being on prograde and retrograde is on the fairest and closest point from the sun. And i have no idea why.

set svx to ship:PROGRADE:YAW -sun:position:x.
set svy to ship:PROGRADE:PITCH -sun:position:y.
set svz to ship:PROGRADE:ROLL -sun:position:z.

set line3 to v(svx,svy,svz). 
set line4 to v((-1)*kerbin:position:x,(-1)*kerbin:position:y,(-1)*kerbin:position:z). 
set kat2 to vang(line3,line4).
 if sun:DISTANCE < kerbinx:altitude+sun:radius {set kat21 to 360-kat2.} else {set kat21 to kat.}.
 print kat21 at (6,4). print kat2 at (6,5).

EDIT: Problem eliminated.

		
set vpp to V(0,-100,0).  
set svx to ship:PROGRADE:yaw -z:position:x.
set svy to ship:PROGRADE:pitch -z:position:y.
set svz to ship:PROGRADE:roll -z:position:z.	

set line3 to v(svx,svy,svz).
set line4 to v(x:position:x, x:position:y, x:position:z). 
set line6 to VCRS(line3, vpp).
set kat2 to vang(line4,line6).

if z:DISTANCE < kal {set kat21 to 360-kat2.} else {set kat21 to kat2.}. print kat21 at (6,4).

Edited November 9, 2014 by Trewor007

[ouch]

Can anyone target ships via script? it seems broken and I know some of my scripts used to work.

for instance:

list targets in targetobjects.

set target to targetobjects[0].

fails with a vessel (ship) not found

even a direct:

set target to vessel("Miner Vtol").

will fail. However:

set target to body("Mun").

will work just fine. Seems like something broke with ship targeting for me. Does anyone else have this problem?

also, I remember I used to be able to switch ships and have kos run on the one I'm not controlling. It seems to turn off telling me it's lost it's target. (I initially set it manually.) But if I go back the ship I targeted it still is...