[KSP 1.12.x] kOS v1.4.0.0: kOS Scriptable Autopilot System

[windystig]

5 hours ago, Steven Mading said:

After reading your post I just made this issue:

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

 

Hi Steven

I found that by playing with a few bits ( e.g. changing 'node:eta' to 'nextnode:eta' )  and removing the line i quoted i managed to get it working.

However, i am using the script to do a maneuver with a shuttle so the line 'LOCK STEERING TO NP' does point the nose at NP, but i need it to nose up about 15 degrees. Is there something i could add to this line that would accomplish that. eg LOCK STEERING TO NP + (followed by an instruction that would make it use NP as a basis then nose up 15)?

Thanks

Daniel

[scimas]

3 hours ago, windystig said:

Is there something i could add to this line that would accomplish that. eg LOCK STEERING TO NP + (followed by an instruction that would make it use NP as a basis then nose up 15)?

You will first need to define what do you mean by 'up.' You either are near Kerbin and want to nose up as in away from surface or in orbit and then nose up might mean towards the normal vector, or many other things. In any case you will need another vector to determine where to point the ship.

Let's say that it's the first case, away from ground. So node deltaV becomes your first vector and the predefined 'UP:vector' second vector. Their cross product (normalize it) will give you a vector that you can use as axis of rotation. Now take the deltaV vector and use Rodrigues' Rotation Formula to get the vector where you want to point your ship.

Do remember that KSP uses a left handed coordinate system when calculating cross products.

[windystig]

5 minutes ago, scimas said:

You will first need to define what do you mean by 'up.' You either are near Kerbin and want to nose up as in away from surface or in orbit and then nose up might mean towards the normal vector, or many other things. In any case you will need another vector to determine where to point the ship.

Let's say that it's the first case, away from ground. So node deltaV becomes your first vector and the predefined 'UP:vector' second vector. Their cross product (normalize it) will give you a vector that you can use as axis of rotation. Now take the deltaV vector and use Rodrigues' Rotation Formula to get the vector where you want to point your ship.

Do remember that KSP uses a left handed coordinate system when calculating cross products.

Hey

As it is for the shuttle it doesn't matter whether the angle change is towards or away from the planet. The burn is using the OMS engines, which are mounted at a 15 degree angle so if i point directly at NP then my actual direction when i burn will be 15 degrees off. So i need to 'nose up' in relation to the NP, regardless of what that means in relation to the planet. I did try using the rotation formula but all that did was lock me to 15 degrees above the horizon. Not 15 degrees about where the NP was.

[scimas]

It should point you properly. Here's a code snippet that might help.

LOCK rot_axis to VCRS(np, UP:VECTOR):NORMALIZED.
LOCK new_dV to np*cos(15) + VCRS(rot_axis, np)*sin(15).

rot_axis is the k vector, np is the v vector from the wikipedia article. You can eliminate the last term since we already know that k and v are perpendicular making their scalar product zero.

So new_dV is your new np, lock steering to it.

[pellinor]

1 hour ago, windystig said:

The burn is using the OMS engines, which are mounted at a 15 degree angle so if i point directly at NP then my actual direction when i burn will be 15 degrees off. So i need to 'nose up' in relation to the NP, regardless of what that means in relation to the planet. I did try using the rotation formula but all that did was lock me to 15 degrees above the horizon. Not 15 degrees about where the NP was.

Ok so you want to orient your shuttle such that the burn vector is 15° below the nose. So you have a vector NP and and need an orientation (i.e. not just where the nose should point but also what the "roll" should be).

First choose a plane by choosing a vector that is normal to NP. This choice is arbitrary, I usually use Facing:Up, which means the ship will not need to roll).

set vUp to VXCL(Facing:UpVector, NP):Normalized.

Now calculate a vector 15° from NP, pointing towards vUp. This makes sure NP is 15° away from the nose.

set vNose to Facing:ForeVector*cos(15) - v*sin(15).

The "roll" part of your orientation makes sure that NP points below the nose, kOS makes this easy with the LookdirUp function. Then the the shuttle is oriented by

lock Steering to LookdirUp(vNose, vTmp).

 

Edited November 17, 2017 by pellinor

[ElWanderer]

1 hour ago, windystig said:

Hey

As it is for the shuttle it doesn't matter whether the angle change is towards or away from the planet. The burn is using the OMS engines, which are mounted at a 15 degree angle so if i point directly at NP then my actual direction when i burn will be 15 degrees off. So i need to 'nose up' in relation to the NP, regardless of what that means in relation to the planet. I did try using the rotation formula but all that did was lock me to 15 degrees above the horizon. Not 15 degrees about where the NP was.

Someone posted about this on the kOS reddit recently:

https://www.reddit.com/r/Kos/comments/77x3n3/script_to_deal_with_crafts_where_the_thrust_is/

Whoa, the forum initially tried to embed the entire reddit post within this post...

[MinimumSky5]

I'm having trouble with this quite simple launch program (I'm building it in stages, so it isn't complete yet)

set throttle to 1.0.
stage.
when velocity > 50 then{
set steering to heading(90, 85).
}

when the program runs, it only seems to run the when command once, rather than wait for the velocity, as it says "program ended" just after the rocket gets off the launch pad. Any ideas?

[ElWanderer]

1 hour ago, MinimumSky5 said:

I'm having trouble with this quite simple launch program (I'm building it in stages, so it isn't complete yet)

set throttle to 1.0.
stage.
when velocity > 50 then{
set steering to heading(90, 85).
}

when the program runs, it only seems to run the when command once, rather than wait for the velocity, as it says "program ended" just after the rocket gets off the launch pad. Any ideas?

The WHEN ... THEN ... syntax does not initiate a loop. Instead it sets up an interrupt that will be triggered when the condition is met. But the program must be running for any triggers to fire.

The traditional thing to try first is to put "WAIT UNTIL FALSE." at the bottom of the script, so it never ends. Or rewrite your code to use WAIT UNTIL ...

Notes:

I don't think you can "set" steering, you need to "LOCK STEERING TO ..."

I think you'd need to check "SHIP:VELOCITY:SURFACE:MAG > 50" (VELOCITY is an object that contains a surface velocity vector and an orbital velocity vector, in turn you need to call MAG to get the magnitude of the vector).

[garwel]

Actually, you can use AIRSPEED for magnitude of surface velocity.

[ElWanderer]

6 minutes ago, garwel said:

Actually, you can use AIRSPEED for magnitude of surface velocity.

Ah, now that I did not know!

[scimas]

Is there any way to detect the current biome of the ship in KOS? As far as I can tell neither SHIP nor BODY has any reference to biomes.

[danielboro]

1 hour ago, scimas said:

Is there any way to detect the current biome of the ship in KOS? As far as I can tell neither SHIP nor BODY has any reference to biomes.

if you have a GPS part like surfec scanner you can get it (or Dmagic mag sensor)
or install an addon called biome for kos. i seen it but never used it

 

set biomescanners to SHIP:MODULESNAMED("ModuleGPS").
if not biomescanners:EMPTY {
    set biomemodule to biomescanners[0]:part:GETMODULE("ModuleGPS").
    lock BIOME to biomemodule:GETFIELD("biome").
}else set BIOME to false.

Edited November 30, 2017 by danielboro

[danielboro]

On 11/17/2017 at 2:05 AM, windystig said:

Hey

I am using the example of the executable node script from the kOS guide to run my own nodes but it keeps failing and i can figure out why. The line that causes the failure is:

wait until abs(NP:pitch - facing:pitch) < 0.15 and abs(NP:yaw - facing:yaw) < 0.15.

The error i get is

Get suffix 'PITCH' not found on object V( then gives the vectors). An attempt was made to get a suffix called 'PITCH' from an object of type 'VECTOR' when that object does not have that suffix usable in that way.

I copied the script from the guide on the page 'Execute Node Script'. i have not tinkered with it so not sure what i'm doing wrong. Any ideas?

Daniel

i use
wait until VANG(prograde:VECTOR,FACING:VECTOR)<0.5.

and for you its
wait until VANG(NP:VECTOR,FACING:VECTOR)<0.5.

Edited November 30, 2017 by danielboro

[guitarxe]

Just a quick general question - are the KOS scripts able to run in the background, or does it only work with currently active vessels?

[Dunbaratu]

2 hours ago, guitarxe said:

Just a quick general question - are the KOS scripts able to run in the background, or does it only work with currently active vessels?

The answer isn't a simple yes or no.

kOS *can* control vessels other than the currently active vessel, but *only if* KSP itself hasn't crippled those vessels to prevent them from working.  And that means the vessel kOS is controlling has to be pretty close to the active vessel.

For kOS to run a program at all, the vessel part it's contained inside of needs to be "loaded" - that's the 2.2km-ish distance everyone talks about.  At this distance you can open the terminal for the kOS computer and interact with it.  BUT, when it does things like try to steer the ship or change the throttle, the ship will stubbornly refuse to do anything in response.  That's not kOS's fault - that's the base game KSP keeping this ship "packed" and preventing its parts from having their full physics effect.

For kOS to actually move the ship, the ship needs to be at the much closer "unpacked" distance, which is sometimes as close as 300 meters.

kOS does allow you to alter these loading and packing distance settings in the stock game to try to allow you to control ships from a bit farther away, but keep in mind you can't control something really far away like on another planet, and if you set the numbers too big, you invite the kraken (because Unity has to simulate things using large magnitude imprecise floating point numbers when you do that)  A full description of this is a long topic, and how you can increase this distance a bit and what it means, is in the kOS documentation itself here if you want to dive in for a long read:

https://ksp-kos.github.io/KOS/structures/misc/loaddistance.html

[danielboro]

set portModsList to ship:PARTSTAGGED("cfh").
print portModsList[0]:name.
portModsList[0]:CONTROLFROM().

 

screen output

GrapplingDevice
'CONTROLFROM' command found a generic part value/
It only works a docking port or command part

 

the claw can be a CONTROLFROM part but this command cant do that
next ill try using action or event to set it

 

Edited December 1, 2017 by danielboro

[pellinor]

57 minutes ago, danielboro said:

set portModsList to ship:PARTSTAGGED("cfh").
print portModsList[0]:name.
portModsList[0]:CONTROLFROM().

 

screen output

GrapplingDevice
'CONTROLFROM' command found a generic part value/
It only works a docking port or command part

 

the claw can be a CONTROLFROM part but this command can do that
next ill try using action or event to set it

 

Here is a piece of code that worked for me (the gMyPort variable points to a part, which can be a dockingport or a claw):

https://github.com/pellinor0/kOS-MissionFramework/blob/master/Script/librdv.ks#L240-L251

It looks like you can only access the "control from here" action from the partModule of the claw. kOS seems to do some special thing for docking ports that it does not do for the claw.

Edit: the relevant part is

if (dockPart:TypeName="Part"){
  // special treatment for claw
  dockPart:GetModule("ModuleGrappleNode"):DoEvent("Control from here").
} else {
  dockPart:ControlFrom.
}

 

Edited December 1, 2017 by pellinor

[danielboro]

On 12/1/2017 at 1:04 PM, pellinor said:

piece of code that worked for me

thanks
saved me som time experimenting to find the correct way to do it
copied your work

 and for the KOS team
I think that ControlFrom should work for any part that can  DoEvent("Control from here") or at list all the stock parts that can

Edited December 5, 2017 by danielboro

[scimas]

Is there any possibility that the MOD function will be changed to calculate the mathematical modulus instead of remainder of integer division?

Also, from the KOS wiki

Quote

The result has the same absolute value as mathematical modulo operation but the sign is the same as the sign of dividend

is not quite accurate. For example, what it implies is (-3) mod 5 would be (-2) - the mathematical modulo 2 with a negative sign; but it's actually (-3) - the remainder of integer division.

Edited December 7, 2017 by scimas
Grammar

[kcs123]

I think that something is lost trough translation from english to other languages. MOD function gives expected result as all other programing language like you described - reminder of integer division. Nothing should be changed in that behaviour, but I'm not sure how to describe it better in documentation, english is not my native language to be able to propose anything better.

[scimas]

Simply removing that sentence should be good enough. The first two statements of the wiki are consistent with what the function does; it's only the last sentence that contradicts the first two statements.

Another thing I need help with, has anyone figured out a way to obtain the local orientation of the surface, basically a normal vector to the surface of the celestial at current position? I don't need exact normal vector at every point, approximation over, say, about 2 m^2 area is good enough too. I want to try to improve my landing and rover control scripts using it.

[garwel]

Has something changed with DEFINED keyword? I use a piece of code like this:

IF NOT DEFINED targetAlt { SET targetAlt TO 80000. }

It is supposed to only define targetAlt variable if it isn't already defined. But the parser says "Unexpected {" on this line. If I use DEFINED(targetAlt) instead, it reports "Undefined variable name 'defined'". How do I use this keyword correctly?

[Dunbaratu]

24 minutes ago, garwel said:

Has something changed with DEFINED keyword? I use a piece of code like this:

IF NOT DEFINED targetAlt { SET targetAlt TO 80000. }

It is supposed to only define targetAlt variable if it isn't already defined. But the parser says "Unexpected {" on this line. If I use DEFINED(targetAlt) instead, it reports "Undefined variable name 'defined'". How do I use this keyword correctly?

Try this:

IF NOT ( DEFINED targetAlt) {

rather than

IF NOT DEFINED targetAlt {

The parser is giving equal precedence to NOT and DEFINED rather than doing DEFINED first, thus it's going left to right and giving IF (NOT DEFINED) targetAlt {.

It's a small bug but one that's known.

 

 

[ElWanderer]

8 hours ago, scimas said:

 

Another thing I need help with, has anyone figured out a way to obtain the local orientation of the surface, basically a normal vector to the surface of the celestial at current position? I don't need exact normal vector at every point, approximation over, say, about 2 m^2 area is good enough too. I want to try to improve my landing and rover control scripts using it.

My slope library is here:  https://github.com/ElWanderer/kOS_scripts/blob/v1.1_draft_changes/scripts/lib_slope.ks / https://github.com/ElWanderer/kOS_scripts/blob/v1.1_draft_changes/documentation/lib_slope_readme.md though all the hard work was taken from episode 42 or 43 of Cheers Kevin's Kerbal Space Programming series on YouTube.

Edited December 7, 2017 by ElWanderer

[ColKlonk2]

KOS automatic launch to orbit with burntime calculation - not bad ... within 4Km of Eccentricity = 0.

https://www.youtube.com/watch?v=a1VB07B4hrg&feature=youtu.be

I'll try next with pure vectors and calcs.