[1.3] kOS Scriptable Autopilot System v1.1.3.0

[Dunbaratu]

Huh, so lets say I pass a List type to another file as a parameter, will the same thing still apply or would a copy of the list be made locally in that file?

The file only stores the code prior to loading. Once its running, it's running in the same memory space as the program that called it. And yes, it's the same object passed by reference. It's following the same rules as Java and C# do. Primitives pass by value. Anything non-primitive passes by reference. I don't like this, as it's against the feel of how the rest of kOS works, being that kOS does not feel particularly object oriented on the surface of it. (I mean it doesn't even have local variables except for parameters).

Edited September 1, 2014 by Steven Mading

[madlemur]

Ow. Owowowow.

I'm trying to teach myself orbital mechanics between bughunts and operational firefights here at work, and it's very slow going. My interest is to create some scripts that will do things like: match a target's orbit (including inclination and eccentricity), intercept the target in its orbit (rescue/repair missions), and/or insert itself into the target's orbit at some fraction of its orbital period ahead of or behind the target (satellite deployment). Technically, that's really only two scripts, since an intercept would have the difference of the Mean Anomalies = 0. I was thinking I could use the first to get a solid basis for the next part, which would do straight prograde/retrograde burns to adjust the orbital/angular position of the ship to the target.

It seems (and I may be skimming over or outright missing a step here) that the :LAN, :MEANANOMALYATEPOCH, :ARGUMENTOFPERIAPSIS and I'm sure a few other constants would be of great use. I'm just having trouble gathering together enough concurrent cycles to put them together in a coherent fashion, rather than jotting down quick notes that I can barely decipher later...

I'm not looking for efficiency, just correctness. Can anyone help me understand what the heck I'm doing? Alternately, does anyone know offhand if the frames of reference for the various values I mentioned are compatible? I know that KSP plays fast and loose with coordinate systems, but I'm hoping that they are at least consistent within the current view.

[Dunbaratu]

It seems (and I may be skimming over or outright missing a step here) that the :LAN, :MEANANOMALYATEPOCH, :ARGUMENTOFPERIAPSIS and I'm sure a few other constants would be of great use.

I wouldn't call them "constants", as they'll change the moment you do any thrust.

LAN is probably the most useless one because to do anything with it you have to know what the arbitrary basis ray is that it's referring to. It always has to be defined in terms of something off outside the solar system that stays relatively still (nothing is totally still in the universe, but at least still enough to last for a few centuries before it has to be redefined). In the real world, it's referring to a ray drawn from Earth to a point in the constellation Ares. KSP does not have a constellation Ares, nor in fact does it have such a thing as "outside the solar system". There's nothing for the basis vector to be pointing AT. LAN is therefore an arbitrary number based on something invisible inside the KSP code that we don't have access to.

[madlemur]

I wouldn't call them "constants", as they'll change the moment you do any thrust.

LAN is probably the most useless one because to do anything with it you have to know what the arbitrary basis ray is that it's referring to. It always has to be defined in terms of something off outside the solar system that stays relatively still (nothing is totally still in the universe, but at least still enough to last for a few centuries before it has to be redefined). In the real world, it's referring to a ray drawn from Earth to a point in the constellation Ares. KSP does not have a constellation Ares, nor in fact does it have such a thing as "outside the solar system". There's nothing for the basis vector to be pointing AT. LAN is therefore an arbitrary number based on something invisible inside the KSP code that we don't have access to.

True enough, but if it's consistent, then it doesn't really matter what it's pointing at. The key is being able to determine when we reach the ascending node (and by inference, the descending node), so we can suss out how to match inclination. But before doing that, we'd want to use the argument of periapsis to match the eccentricity of our orbit. Not sure how, yet (the maths are confusing without being able to seriously focus on them due to work and... SQUIRREL!), but there's bound to be a way to use the mean anomaly to help space out a network of satellites.

[Lilleman]

For the inclination, you can take a look here, it's a script from Mission Toolkit.

For the eccentricity however, I don't have any useful link, sorry.

[madlemur]

For the inclination, you can take a look here, it's a script from Mission Toolkit.

For the eccentricity however, I don't have any useful link, sorry.

Yeah... I use the toolkit, but the math is pretty dry, and I have trouble visualizing it. I may have to write it out myself, and work it out that way. I just keep thinking there's a simpler (script-wise) way of doing things. I mean, we've got the inclinations of the orbits and the longitude of ascending node. It seems (again, without actually doing the maths, or being able to fire up KSP to do some field trials) that it should be straightforward to determine the maneuver node to match inclination. It's just been too long since I've done any real work with vector math.

[skips]

Once its running, it's running in the same memory space as the program that called it. And yes, it's the same object passed by reference.

The documentation should be very explicit about this issue. All of the programs that are running are sharing the same name space (i.e., the name "myVariable" is common to all of the programs). This behavior can easily generate problems where a program runs another program that changes one of its variables. The following code demonstrates the behavior:

//  mission controller
//  edit this file to change the mission
//

print "Begin mission.".
legs on.
wait 2.
set landedHeight to alt:radar.
print "Landed height set to " + round( landedHeight, 3).

declare myThrottle.
set myThrottle to 0.
lock throttle to myThrottle.
print "Throttle is " + round( myThrottle, 2 ).

set missionParams to list().
set missionParams:add to landedHeight.

run test1.


print "Landed height is now " + round( landedHeight, 3).

print "Mission complete.".

and

//  test1 - for experimenting
//

print "Mission parameters: ".
for item in missionParams {
    print item.
}


print "Landed height is now " + round( landedHeight, 3).

declare landedHeight.

print "Landed height in tst " + round( landedHeight, 3).

set landedHeight to 0.

print "Landed height in tst " + round( landedHeight, 3).

The output should be

Begin mission.
Landed height set to 4.604
Throttle is 0
Mission parameters:
4.60407543182373
Landed height is now 4.604
Landed height in test 0
Landed height in test 0
Landed height is now 0
Mission complete.
Program ended.

Concerning your documentation woes: you might consider implementing an info suffix for all of your structures that prints out the names of all of the properties and suffixes for that structure. Users can use this capability to determine what is in a structure from the interactive window rather than searching the documentation. Keeping that information up to date becomes part of the maintenance of the structure rather than a separate documentation task.

Finally, it appears to me that the information that you can extract on the engines is woefully inadequate. It is difficult to build scripts that intelligently control the spacecraft when it is not possible to tell how much thrust a throttle setting will generate _and_ in which direction the thrust will be applied. I have tried several approaches and none of them have created usable results. So far the best that I can do is to throttle the engines on and then use the ship:maxthrust quantity with the assumption that it is applied in the ship:facing direction. This approach fails when there are multiple engines and one or more of them have been thrust limited or have no fuel.

Otherwise the kOS has been a blast for writing mission controllers like those that are used for sounding rockets.

skips

[Dunbaratu]

The documentation should be very explicit about this issue. All of the programs that are running are sharing the same name space (i.e., the name "myVariable" is common to all of the programs). This behavior can easily generate problems where a program runs another program that changes one of its variables. The following code demonstrates the behavior:

I'm sure the fact that all variables are global is mentioned in several places.

Concerning your documentation woes: you might consider implementing an info suffix for all of your structures that prints out the names of all of the properties and suffixes for that structure. Users can use this capability to determine what is in a structure from the interactive window rather than searching the documentation. Keeping that information up to date becomes part of the maintenance of the structure rather than a separate documentation task.

It's already a thing we've thought of. Development of basic low-laying infrastructure (like local variables, and self-documenting structures) has been very slow largely because not everyone has had time to be involved of late. Major sweeping changes like would be required to implement such things throughout the C# code require buy-in from everyone, and a lot of the devs have been stuck in real life issues and unable to wrangle the free time for that sort of thing. Marianoapp - the one almost solely responsible for the script compiler that makes "opcodes" and faster execution, has been off in end-of-grad-school crunch time for a while. It's very hard to make sweeping changes when key devs aren't around to get their OK on ripping their code apart and rebuilding it a different way.

Finally, it appears to me that the information that you can extract on the engines is woefully inadequate. It is difficult to build scripts that intelligently control the spacecraft when it is not possible to tell how much thrust a throttle setting will generate _and_ in which direction the thrust will be applied.

What's the use case for building a ship where not all the engines thrust the same direction? I don't understand what you're trying to do from your description.

[penatololiy]

Great mod =)

Change default config in

GameData\kOS\Plugins\PluginData\kOS\config.xml

<?xml version="1.0" encoding="utf-8"?>
<config>
    ...
    <bool name="StartOnArchive">1</bool>
    ...
</config>

for avoid "switch to 0."

[skips]

What's the use case for building a ship where not all the engines thrust the same direction? I don't understand what you're trying to do from your description

Think VTOL craft.

That said, I have a fundamental issue with assuming that the facing of the spacecraft, which is presumably determined by the orientation of the controlling part, is the same as the orientation of the engine, which is a different part. There is nothing in the construction of KSP that requires any specific relationship between these two directions. I think that it would be wise if the mod took the same stance.

skips

[TDW]

Hi

Does any one know of a better way of doing independent throttle controls?

I have tried changing the SET commands to LOCK and moving it out of the UNTIL loop but with lock i get a syntax error.

The action groups are just a temporary measure so that i can test this part independently.

SET THROTTLE TO 1.
SET fl TO 0. // front left
SET fr TO 0. //front right
SET bl TO 0. //back left
SET br TO 0. //back right
SET aux TO 0.
LIST ENGINES IN engList.

// input section not important; used for testing only.
ON ag1 {
  SET fl TO fl + 10.
   IF fl > 100 {
    SET fl TO 100.
  }.
  PRESERVE.
}.
ON ag2 {
  SET fl TO fl - 10.
  IF fl < 0 {
    SET fl TO 0.
  }.
  PRESERVE.
}.
ON ag3 {
  SET fr TO fr + 10.
  IF fr > 100 {
    SET fr TO 100.
  }.
  PRESERVE.
}.
ON ag4 {
  SET fr TO fr - 10.
  IF fr < 0 {
    SET fr TO 0.
  }.
  PRESERVE.
}.
ON ag5 {
  SET bl TO bl + 10.
  IF bl > 100 {
    SET bl TO 100.
  }.
  PRESERVE.
}.
ON ag6 {
  SET bl TO bl - 10.
  IF bl < 0 {
    SET bl TO 0.
  }.
  PRESERVE.
}.
ON ag7 {
  SET br TO br + 10.
  IF br > 100 {
    SET br to 100.
  }.
  PRESERVE.
}.
ON ag8 {
  SET br TO br - 10.
  IF br < 0 {
    SET br TO 0.
  }.
  PRESERVE.
}.

// this is the key part.
UNTIL 1 > 2 {  //again for demo purposes 
  FOR ENG IN engList {
   IF ENG:STAGE = 2 {
      SET ENG:THRUSTLIMIT TO fl.
    }
    ELSE IF ENG:STAGE = 3 {
     SET ENG:THRUSTLIMIT TO fr.
    }
    ELSE IF ENG:STAGE = 4 {
     SET ENG:THRUSTLIMIT TO bl.
    }
   ELSE IF ENG:STAGE = 5 {
      SET ENG:THRUSTLIMIT TO br.
    }
    ELSE {
     IF ENG:THROTTLELOCK = FALSE {
        SET ENG:THRUSTLIMIT TO aux.
      }.
    }.
  }.
}.

[madlemur]

Think VTOL craft.

That said, I have a fundamental issue with assuming that the facing of the spacecraft, which is presumably determined by the orientation of the controlling part, is the same as the orientation of the engine, which is a different part. There is nothing in the construction of KSP that requires any specific relationship between these two directions. I think that it would be wise if the mod took the same stance.

skips

You may have to assume that engines face away from their direction of thrust, then iterate over all active engines, adding up their vectors, scaled by their maxthrust multiplied by their thrustlimit modifier. This would give you the effective vector of thrust. The unpleasant part would be determining the CoT, since I don't immediately see a way to determine the position of the engines. And that also doesn't take into account efficiency changes due to atmospheric density. That's if you wanted to precompute the value. But if you want the current thrust vector, it's even easier, since you can get the current thrust, and you don't have to worry about efficiency or thrust limiters.

I don't know how much additional information is available from KSP, and just hasn't been exposed, and how much would have to be computed by the plugin.

[madlemur]

Hi

Does any one know of a better way of doing independent throttle controls?

I have tried changing the SET commands to LOCK and moving it out of the UNTIL loop but with lock i get a syntax error.

The action groups are just a temporary measure so that i can test this part independently.

I don't think you can set the thrustlimit in kerbscript. You might consider one of the throttle plugins that allows you to use action groups to control the throttles. Of course, then you're limited to the 10 default action groups (until/unless someone adds AGX support to kOS)...

I was wrong!

// This DOES work (if ENGINE is a valid engine)
SET ENGINE:THRUSTLIMIT TO 0.5.

Edited October 17, 2014 by madlemur

[TDW]

I don't think you can set the thrustlimit in kerbscript. You might consider one of the throttle plugins that allows you to use action groups to control the throttles. Of course, then you're limited to the 10 default action groups (until/unless someone adds AGX support to kOS)...

The scrip i posted works the issue i am having with it is that while i can set thrustlimit i cant find a way to lock it and would prefer not to loop it.

i have included the test craft file in the spoiler if you want to play with it. (ag10 starts the engines if you stage them on the script cant tell which is which)

EDIT:

does not seem to work and i didn't want to take up that much space. is there a way of attaching text files to a post here?

EDIT 2: craft file

Edited September 5, 2014 by TDW

[Dunbaratu]

Think VTOL craft.

That said, I have a fundamental issue with assuming that the facing of the spacecraft, which is presumably determined by the orientation of the controlling part, is the same as the orientation of the engine, which is a different part. There is nothing in the construction of KSP that requires any specific relationship between these two directions. I think that it would be wise if the mod took the same stance.

skips

LOCK STEERING is based on where you are pointing on the navball. There is no additional problem kOS is introducing that wasn't already there in the game in the first place. If you're trying to travel in a direction perpendicular to your navball facing you still get the exact same problem in manual piloting - the direction the game thinks you're pointed isn't the direction you're actually going.

Why a special exception for engines? Wouldn't it be sufficient to get the orientation of any part, and not care if said part was an engine or some other sort of part? That is in the vague future plans.

[Dunbaratu]

EDIT:

does not seem to work and i didn't want to take up that much space. is there a way of attaching text files to a post here?

Is there some reason people seem to want to post their raw unformatted ascii text (like kos code) in spoiler blocks instead of in [ code ] [ /code ] blocks? I see that on a lot of forums and I just don't understand it.

[ code ] (without the spaces) works.

[beelzebub]

Thanks, Steve - I'll have a fiddle and report back

Just posting to report complete success with Steve's approach to controlling the pitch and yaw of a rocket independently of its roll. Also the use of the vecdrawargs makes life a lot easier when it comes to debugging. This is a lot more satisfying than lock steering to up!.

For the benefit of others...

First decide where you want to go:

set desiredHeading to heading(90,90).

Then get a vector for the directions along your current pitch and yaw axes:

lock pitchAxis to ship:facing*R(-90,0,0).
lock pitchVector to pitchAxis:Vector.
lock yawAxis to ship:facing*R(0,90,0).
lock yawVector to yawAxis:Vector.

Then get the dot product of this vector and your desired pitch/yaw. The *90 is to convert it to degrees (error of 1 = 90 degrees...)

lock pitchError to 90*VDOT(desiredHeading:vector,pitchVector).
lock yawError to 90*VDOT(desiredHeading:vector,yawVector).

You can get roll error by the obvious way, plus a non-obvious -180:

lock rollTarget to desiredHeading:Roll - 180.
lock rollError to max(facing:Roll,rTarget) - min(facing:Roll,rollTarget).

Feed these into a PID controller and you're good to go!

[madlemur]

The scrip i posted works the issue i am having with it is that while i can set thrustlimit i cant find a way to lock it and would prefer not to loop it.

i have included the test craft file in the spoiler if you want to play with it. (ag10 starts the engines if you stage them on the script cant tell which is which)

EDIT:

does not seem to work and i didn't want to take up that much space. is there a way of attaching text files to a post here?

EDIT 2: craft file

Interesting. Sounds like the documentation needs to be updated. It shows <ENGINE>:THRUSTLIMIT as read-only.

One thing I would do is put a WAIT 0.001. at the end of your UNTIL loop. What may be happening is the loop is executing several times per tick, and something is going sideways. If you put a teeny-tiny WAIT in there, it will wait until the next tick, and cap out at one run-through per tick.

[Dunbaratu]

Then get the dot product of this vector and your desired pitch/yaw. The *90 is to convert it to degrees (error of 1 = 90 degrees...)

Technically, if you want to get degrees you should use inverse trig functions (arccos, arcsin) of the dot product rather than 90*the_dot_product.

The dot product will vary from 0 to 1, and thus you will get a number that varies from 0 to 90 by doing what you're doing, but if you graph the curve of how it varies from 0 to 90, it shouldn't be a straight line like that. It should be a quadrant of a circle.

[skips]

LOCK STEERING is based on where you are pointing on the navball. There is no additional problem kOS is introducing that wasn't already there in the game in the first place. If you're trying to travel in a direction perpendicular to your navball facing you still get the exact same problem in manual piloting - the direction the game thinks you're pointed isn't the direction you're actually going.

Why a special exception for engines? Wouldn't it be sufficient to get the orientation of any part, and not care if said part was an engine or some other sort of part? That is in the vague future plans.

Thank you for your comments. It is clear to me that you and I have very different expectations for this mod. Given that it is your mod, I will back out of the discussion at this time.

skips

[erendrake]

Think VTOL craft.

That said, I have a fundamental issue with assuming that the facing of the spacecraft, which is presumably determined by the orientation of the controlling part, is the same as the orientation of the engine, which is a different part. There is nothing in the construction of KSP that requires any specific relationship between these two directions. I think that it would be wise if the mod took the same stance.

skips

Thank you for your comments. It is clear to me that you and I have very different expectations for this mod. Given that it is your mod, I will back out of the discussion at this time.

skips

Tell us more about your "expectations". So far you havent mentioned anything that sounds impossible or out of line with our vision for the mod.

[madlemur]

So far, I think the core of any expectations mismatch is how much of the underlying KSP data is surfaced in kerbscript. (Well, and I suppose some linguistic theory surrounding how kerbscript is defined; it's no Kerbighan & Kritchie...)

[Dunbaratu]

Thank you for your comments. It is clear to me that you and I have very different expectations for this mod. Given that it is your mod, I will back out of the discussion at this time.

skips

I think it's more accurate to say that I don't understand what you're asking for, and how it would differ from the more generic solution of just getting the orientation of any part (which would cover engines, fuel tanks, whatever), which admittedly doesn't exist yet but we want it to.

[erendrake]

So far, I think the core of any expectations mismatch is how much of the underlying KSP data is surfaced in kerbscript. (Well, and I suppose some linguistic theory surrounding how kerbscript is defined; it's no Kerbighan & Kritchie...)

I would argue semantics around the word "expectation". If there is useful data about craft and parts that isnt exposed no one is more serious than Steven and I about exposing it to you guys. From skips last few posts I cannot tell what he wants let alone what data is missing for him to accomplish his goal. I am seriously asking him for more information so we can resolve his issues.

[Dunbaratu]

So far, I think the core of any expectations mismatch is how much of the underlying KSP data is surfaced in kerbscript. (Well, and I suppose some linguistic theory surrounding how kerbscript is defined; it's no Kerbighan & Kritchie...)

This is certainly a part of any problem. There's a lot of things that would *in principle* be possible but *in practice* given the way the KSP API is structured are very hard to do quickly with limited spare time, using a poorly documented API that often doesn't do what you assumed it would when you start working on a feature.

I remember spending about 8 hours of programming trying to figure out how to the use API to work out how to calculate STAGE:LIQUIDFUEL better when it kept returning wrong numbers. It turns out the API for "find all parts that hold resources that this engine can consume" is a royal mess because theres 3 utterly unrelated things to test for, and also the yellow fuel hoses use a totally different API than every other part does for this, for no apparent reason.

None of this was doucmented -it was all found with trial and error, using a system that takes 5 minutes to run a test after each code change because you have to relaunch KSP and start flying the rocket again from the start sometimes.