kOS Scriptable Autopilot System 0.9

[Gaius]

Could always go the basic route and not have line terminators, or....ye olde school route...

10 PRINT "Nooooooooooo!"

20 GOTO 10

[Sma]

10 PRINT "Nooooooooooo!"

20 GOTO 10

lol

[Motokid600]

I haven't tried this yet (It's "late" here and I was moving 12gb of video off of my phone to my computer, through kies air, then to the backup drive. Phone memory card is full and angry birds starwars 2 comes out soon), but Bizz dug up "node" and "eta:node" from the source code (oh and I also noticed it on the git hub readme). You could try printing those and see what happens. For eta:node I would imagine this could work:

set tNode to eta:node.
set atNode to 0. // once node is complete set to 1 to make sure it doesn't keep looping. Also could set it to 1 if mag:node is increasing.
until atNode = 1 {
   if eta:node < tNode / 2 {
      lock steering to node. //Not sure if this is how this works, assuming it's even implemented yet...it is on the git hub readme though
      lock throttle to 1.
   }.
   if mag:node < 10 { lock throttle to 0. set atNode to 1. }. //mag:node is the amount of deltaV needed to complete the maneuver. 
}

That's just a "simple" way that MIGHT work, again as I haven't tested it my self I can't say for sure. To get more complicated you could have it crunch some numbers on how much fuel you have left, mass of your vessel and the amount of thrust you have (to find out how much deltaV you have) and compare that to mag:node to see if you have enough fuel to complete the burn.

Also you could add a check to make sure that the deltaV doesn't increase. You could either put mag:node in a variable before you start the burn and just check that the current deltaV doesn't go over the original deltaV. Of course in that case you dV could be going down then start to go back up again, but at least the engines would cut off before you ended up with an orbit going somewhere you didn't want, or at least if it was it'd be to the point that it could be corrected easy enough. I guess you could also dynamically check it too, at the beginning of the until loop you would set it to a variable, wait a second or two to give it a chance to burn a little then run an if statement to compare actual dV to the variable. If actual dV is higher than the variable then you...err...the program knows something is wrong and cuts throttle.

Thanks ill give that a try.

[check]

Yo,

I have stopped whining and had a look into the source code myself.

Since I haven't found the Q() and R() expression I am sure that have overseen something.

Can someone have a look here tell me if its complete or how many are missing?

Its still WIP though...

Awesome. Any idea what FACING or AV do??

[MP X10L]

Not sure if its intended to work this way:

Took some time until I found what makes my warp-calculation useless. ^^

[Bizz Keryear]

Awesome. Any idea what FACING or AV do??

since AV give back 3 floates I assume it has something to do with Navigation.

Facing (as I understand this) should give back the current R() in which the ship is facing.

But I still have to confirm that.

edit: av is the rotation speed. and facing is odd (can't figure it out)...

edit 2: gee ... v() might be fixed, but R() seems broken.

0.60:

lock steering to heading 90 by 45 + R(0,0,180).

made my ship flying toward 90 by 45 without rotating.

0.61:

lock steering to heading 90 by 45 + R(0,0,180).

still no rotating, but the angles seem random. Worst case so far: real heading 270 by 30.

Edited September 18, 2013 by Bizz Keryear

[Payload]

0.60:

lock steering to heading 90 by 45 + R(0,0,180).

made my ship flying toward 90 by 45 without rotating.

0.61:

lock steering to heading 90 by 45 + R(0,0,180).

still no rotating, but the angles seem random. Worst case so far: real heading 270 by 30.

Hmm Not sure what is going on there. I was thinking about switching over but for now I've been using the V() system with R() to set roll. It's dead on every time.

EDIT: Have you tried setting the rotations first? lock steering to R(0,0,180) + heading X by Y.

On a side note, I've been doing diversion testing. So I have some info to share with you all.

Setting your steering to the retrograde surface vector is dead easy. lock steering to velocity:surface + V(1,0,0).

You can use just surface speed as a check for re-orientation. when surfacespeed < .001 then lock steering to heading 0 by 90.

You will need some kind of accurate hover script. I guess you could wing it if you really wanted.

When you setup your hover script, make sure you set a variable to mission time at the beginning of your loop and set another variable to mission time at the end. You will need to add the loop time into your TWR calc our you will always be over 1.

Edited September 18, 2013 by Payload

[zoranbrasnjo]

In general whenever you have a lockup of the entire KSP game from running your KOS code the first culprit to look for is paired open/close syntax markers in which there is a mismatch of opens to closes. (more opens than closes). That locks it up every time I've done it, reliably, repeatedly.

e.g.:

// no close quote:

print "blah .

// no close parenthesis:

set x to ( y + z .

// no close braces:

if x = 1 { print "x is one".

if x = 0 { print "x is zero".

Any of those will make it hang forever.

Thanks guys, you made my life easier, it works!

[Sma]

since AV give back 3 floates I assume it has something to do with Navigation.

Facing (as I understand this) should give back the current R() in which the ship is facing.

But I still have to confirm that.

edit: av is the rotation speed. and facing is odd (can't figure it out)...

edit 2: gee ... v() might be fixed, but R() seems broken.

0.60:

lock steering to heading 90 by 45 + R(0,0,180).

made my ship flying toward 90 by 45 without rotating.

0.61:

lock steering to heading 90 by 45 + R(0,0,180).

still no rotating, but the angles seem random. Worst case so far: real heading 270 by 30.

Not sure you really need R() in combination with using heading, well...I guess for roll maybe, though I don't really see why, except maybe for planes. Or maybe I'm just not getting it. I assume Kevin will eventually get roll added to heading some how. I'll try putting R() first though and see how that goes.

Isn't this fun?

Now that I've got a relatively ok orbit script, I think for my next trick I'm going to make a geosync orbit script. Particularly one that is capable of putting a number of sats in geosync, or is it kerbosync?

[JewelShisen]

Setting your steering to the retrograde surface vector is dead easy. lock steering to velocity:surface + V(1,0,0).

Tried that. Does not work.

[Payload]

Tried that. Does not work.

Works just fine here. Been using it all day! I have diverted every direction under the sun too. You sure you don't have a control authority problem? I noticed when you do that, the control is really slow to respond compared to just setting the direction in a normal way. It does get there though. I guarantee it. Add some reaction wheels to your craft or maybe some RCS and try again.

Hmm maybe my craft was just wind veining? I'll screw with it some more.

Edited September 18, 2013 by Payload

[JewelShisen]

Works just fine here. Been using it all day! I have diverted every direction under the sun too. You sure you don't have a control authority problem? I noticed when you do that, the control is really slow to respond compared to just setting the direction in a normal way. It does get there though. I guarantee it. Add some reaction wheels to your craft or maybe some RCS and try again.

I have react wheels on it. It steers fine. That code line does nothing. Does not divert the craft. Does not even make it wiggle a bit.

[Secret Squirrel]

I have react wheels on it. It steers fine. That code line does nothing. Does not divert the craft. Does not even make it wiggle a bit.

Just an idea and sorry if its already been suggested, but is your SAS on? If SAS is on and you have a script to lock steering to anything it wont move.

[JewelShisen]

Just an idea and sorry if its already been suggested, but is your SAS on? If SAS is on and you have a script to lock steering to anything it wont move.

Sas never gets touched.

[JewelShisen]

Here is the program I am running:

clearscreen.
lock steering to heading 0 by 90.
lock throttle to 1.
stage.

wait 5.
lock steering to heading 0 by 30.
lock throttle to 0.8.

wait until stage:liquidfuel < 300.
stage.

wait until stage:liquidfuel < 1.
stage.

lock throttle to 0.
until alt:radar > 0 {
wait 1.
print "Radar Altitude:" + alt:radar.
}.

until alt:radar < 5000 {
wait 1.
}.

lock steering to velocity:surface + V(1,0,0).

until verticalspeed < 10 {
print "Radar Altitude:" + alt:radar.
lock throttle to 1.
}.

set VSC to 0.
lock throttle to VSC.

Until alt:radar < 5 {
if verticalspeed > 4 { set VSC to VSC + 0.02. }.
if verticalspeed < 2 { set VSC to VSC - 0.02. }.
}.

[Payload]

Oh no he is right LOL. My craft was just wind veining. HAHA I guess it's good to know that works! It works too well at that. I must have done 100 plus diversion tests!

EDIT: OK I'm pretty sure I have it working now. Just give me a second to make sure I'm not trippin.

Edited September 18, 2013 by Payload

[JewelShisen]

Oh no he is right LOL. My craft was just wind veining. HAHA I guess it's good to know that works! It works too well at that. I must have done 100 plus diversion tests!

Huh? Who was right?

[Sma]

Gotta love being about 500 meters up and getting "unknown term".

[GavinZac]

Is anyone getting latent spinning even when the terminal is off? My crafts are acting as if someone is holding down the 'q' button.

Never mind, I think it's something else. Grr.

Edited September 18, 2013 by GavinZac

[Dunbaratu]

Tried that. Does not work.

This does:

// For prograde. The system insists on only

// understanding steering by R()'s and not by V()'s.

// So you turn a V() into an R() by just multiplying

// it by the no-rotation rotation operator R(0,0,0)

// to force the system to cast it to an R().

set mySteer to R(0,0,0) * velocity:surface.

lock steering to mySteer.

//for retrograde, multiply vector by -1 :

set vs to velocity:surface.

set vsx to 0 - vs:x.

set vsy to 0 - vs:y.

vst vsz to 0 - vs:z.

set mySteer to R(0,0,0) * V(vsx, vsy, vsz).

lock steering to mySteer.

Using R(0,0,0) * V(x,y,z) allows me to live entirely in the sensible world of vectors and 3D space and not use Euler rotations. The only hard part is finding the zero point of the "universe" when I don't have access to the positional numbers, only the velocity. I've been asking mod makers in the development forum how the game's coordinate system is laid out and it's messy. I've got it worked out that the zero point of the universe is the center of your SOI planetary body, and that the universe's coordinates rotate with your SOI body, but only if you're lower than N (N changes depending on body), but when you're higher up than that, then the frame of reference changes such that the universe stays put and the planet starts rotating. All of that I can get, but then it turns out that for whatever strange reason SQUAD decided to make the axes of the system NOT extend through the prime meridian but at some oddball canted angle at about 100 degrees longitude or so... no idea why or how to query for "where is the x axis on this planet?".

Edited September 18, 2013 by Steven Mading

[Sma]

Hmm Not sure what is going on there. I was thinking about switching over but for now I've been using the V() system with R() to set roll. It's dead on every time.

EDIT: Have you tried setting the rotations first? lock steering to R(0,0,180) + heading X by Y.

I tried that just now and all it did was give me problems. Same with putting R() after heading. The problem, I think, is that R(0,0,180) on the navball is the horizon, and I would end up somewhere between 45 and 0. I tried it with "up" and my direction never changed. For now I'm ok with it rotating so that north is on the top left of the navball as opposed to the bottom left. I wouldn't be surprised if in the next update or 2 roll will be a part of heading.

Didn't try lock steering to R(0,0,180) * heading X by Y though.

Update Yeah, that didn't work out so well either lol, it flipped upside down before settling between 45 and 0, upside down too. Was interesting to watch though lol.

Also I've found when using lock steering to heading 90 by 90 it's best to do it either before releasing the clamps or just after. If you wait too long it's the same thing as turning SAS on after your rocket starts to tip over. I'm actually going to have it wait until altitude is around > 120, to give it a chance to "clear the tower" before it rotates around. Not likely to be a problem later on I guess.

Edited September 18, 2013 by Sma

[Dappa]

I posted the following on Github as a bug report, but it'll probably be read by some additional people here, for whom might clear up some confusion about the surface velocity vector. It seems to be flawed at the moment.

The orientation of the velocity:surface vector seems somehow fixed to the planet, and not to the local horizon. This becomes especially clear in a circular equatorial orbit, when the surface velocity vector should remain constant (in direction and magnitude). Instead, it varies wildly, depending on your longitude.

So while the length of the vector is correct, its direction isn't.

Edited September 18, 2013 by Dappa

[Dunbaratu]

I posted the following on Github as a bug report, but it'll probably be read by some additional people here, for whom might clear up some confusion about the surface velocity vector. It seems to be flawed at the moment.

The orientation of the velocity:surface vector seems somehow fixed to the planet, and not to the local horizon. This becomes especially clear in a circular equatorial orbit, when the surface velocity vector should remain constant (in direction and magnitude). Instead, it varies wildly, depending on your longitude.

So while the length of the vector is correct, its direction isn't.

Please read this thread through to the end:

http://forum.kerbalspaceprogram.com/showthread.php/50274-I-can-t-understand-the-coordinate-system-why-am-I-moving-vertically-when-on-ground

I had the same problem and read the code on github and saw that all it's doing is exposing us to the native API's concept of velocity, so I figured whatever weridness was going on must be coming from the underlying mod API. So I asked over there if other mod makers could tell me how the native coordinate system is meant to work.

I think I can work out from the second number of the "UP" tuple what the REAL longitude is relative to the planetary axis and work it out from there. (Squad chose to make the reported longitude to the user not match the coordinate grid underneath for ... uh... no apparent reason. The real zero point seems to be around about 100 degrees longitude for some reason).

[czokletmuss]

Maybe it's a silly question, but is adding this line:

MODULE
{
	name = kOSProcessor
}

to other parts (command pods) sufficient to make them work as a vanilla kOS processor?

[GavinZac]

Maybe it's a silly question, but is adding this line:

MODULE
{
	name = kOSProcessor
}

to other parts (command pods) sufficient to make them work as a vanilla kOS processor?

You can use Module Manager and Sarbian's Module Manager Extensions to put kOS into everything that can command a ship, even future-proof if you add mods or Squad makes new parts, by installing them and placing a text file with this in it in your GameData folder:

@PART[*]:HAS[@MODULE[ModuleCommand]:HAS[!MODULE[kOSProcessor]]]

{

MODULE

{

name = kOSProcessor

}

}

If you just put it in by hand into every original part, the next time you update you'll have to do it again.