kOS Scriptable Autopilot System 0.9

[Camacha]

I don't really like RT, because usually you are the computer on board of the probe / vessel so why should there a delay in the execution of the commands...

The way I view it you are not the computer, you are controlling the probe from Kerbin. That means having to have contact and having a delay. No contact means no control, which would not happen if you were the computer.

But I have to admit it would actually make sense with this...at least in some ways**.... so while kOS is the computer on the vessel which executes the commands directly, your inputs are the remote commands from the control center.

Exactely Remote Tech takes astronauts in account by allowing you to create a secondary control center in space or on a planet surface.

Edited September 17, 2013 by Camacha

[Dunbaratu]

Okay I *think* I've worked out that in the velocity vector, X is Up, Y is North, and Z is East. I worked out that Z is east by comparing the surface to the orbital velocity vectors when sitting on the ground. The fact that X is up is the weird part I'd have never expected that. But I just made a program to print out the velocity again and again in a loop while I launched straight up and watched the numbers change. I worked out north the same way.

[GavinZac]

0.6+ has somehow made a previously working craft now no longer reach orbit. Any ideas why? It simply runs out of fuel far earlier than before.

[MorroW]

Check with 0.61 as there has been some changes.

[Bizz Keryear]

The way I view it you are not the computer, you are controlling the probe from Kerbin. That means having to have contact and having a delay. No contact means no control, which would not happen if you were the computer.

But without kOS thats dosen't make any sense, cause it would mean there is no computer on board....

And just assume Voyager that way:

... Yay! The command 1 have send 1 year ago has finally reached the position of the probe, it had to make a sudden change cause of the new meteoroid we have seen in the video stream in close proximity ... Which actually was send 2 years ago ... and that was also the time the probe has crashed into it....

What i am meaning is it makes sense to steer remote toys like that. Toys that are in close range. But it doesn't even make sense to control low orbit spacecrafts that way, cause at some point yo lose connectivity for a short while. And landing on a celestial body would be impossible due the latency. Instead they get commands like in 10km height start the decelerating burn and if you are strait up keep you down speed nice and slow until you touch down.

It is really actually so that (IMHO) that what the computers in a real spacecraft do, does in KSP the player ... or Mechjeb ... or to have a little more fun kOS ...

[GavinZac]

Check with 0.61 as there has been some changes.

Yes, the plus means in all (both) versions since 0.6.

[orgustott]

Is there any plan to include arctan, arcsin, arccos, as commands because with the new system of direction control "lock steering to XX by YY" you really need to calculate angles and there is no way to do it.

[zoranbrasnjo]

HI Everyone, This is awesome addon, I would appreciate any help if someone could help, I was trying to programe my z map satelite launch, and after few lines of code my KSP always freeze, becomes non responive program, when I run my program, it becomes very frustrating becouse I have to start KSP all over again and it takes 5 min every time to load game(becouse I have lot of addons...). Have I done something wrong with my coding or is it something else?

this is my coding:

 print "THIS IS LAUNCH PROGRAMMING 
FOR Z MAP SATELITE SPACECRAFT".
WAIT 3.
LOCK STEERING TO UP + R(0,0,180).
PRINT "SETTING MAIN ENGINE TO MAX".
WAIT 1.
LOCK THROTTLE TO 1.
WAIT 1.
PRINT "LIFTOFF IN 5".
WAIT 1.
PRINT "-----------4".
WAIT 1.
PRINT "-----------3".
WAIT 1.
STAGE.
PRINT "-----------2 MAIN ENGINE ON".
WAIT 1.
PRINT "-----------1".
WAIT 1.
STAGE.
PRINT "--------LIFTOFF-----".
WAIT 3.
PRINT "ROLL PROGRAM".
WAIT 1.
LOCK STEERING TO UP + R(0,0,90).
WAIT 1.
LOCK THROTTLE TO  0.7.
WAIT 1.
PRINT "CHECK ROLL PROGRAM COMPETE".
WAIT 15.
PRINT "MUST MANUALY STAGE SRBS".
WAIT 15. 

there was more code but I deleted it and I try to run it like this and game freezes again when I run program?

anyone , help???

p.s. it was working previously, this is 5 times in row I got KSP(non responding), I did not change game in any way from previous attempts to run programs.

Edited September 18, 2013 by zoranbrasnjo

[razark]

How far through the program does it get?

[GavinZac]

Zoran, try making sure each print statement is only one line. Like this:

print "THIS IS LAUNCH PROGRAMMING".

print "FOR Z MAP SATELITE SPACECRAFT".

[rhoark]

Is the CALL function how we're going to get science data?

[zoranbrasnjo]

Zoran, try making sure each print statement is only one line. Like this:

print "THIS IS LAUNCH PROGRAMMING".

print "FOR Z MAP SATELITE SPACECRAFT".

thanks, I will try it, well I started from scratch with new spacecraft and new program and it works so far, but still my zsat is cursed

[rhoark]

I tried

set target to "Mun".

and it said, "Vessel not found". Is this supposed to work?

[sirkut]

Is the CALL function how we're going to get science data?

I don't know about that but CALL is used to be able to call methods from other mods(plugins) provided that the author registers those methods.

[Secret Squirrel]

I tried

set target to "Mun".

and it said, "Vessel not found". Is this supposed to work?

From what I know of the target function is ships only and only within range of your ship. More antennas more range. I think that's how it works.

[Motokid600]

So where's the Archive folder now? .61 just came out and if I'm not mistaken the mod now goes into gamedata as all the others, yes? Because kOS can't find my program now. I tried placing it in every plugin folder there is. No luck. "Switch to archive." Can't find it either.

[Sma]

So where's the Archive folder now? .61 just came out and if I'm not mistaken the mod now goes into gamedata as all the others, yes? Because kOS can't find my program now. I tried placing it in every plugin folder there is. No luck. "Switch to archive." Can't find it either.

Kerbal Space Program\Plugins\PluginData\Archive is where mine is and it works fine, so long as I am in range of KSC or at an orbit of about 100,000m with an antenna.

[Sma]

And my five cents to the steering. It wobbles like hell. Most likely (IMHO) its caused by handling the floats wrong. Even if the if in the program is an exact value is given, the interface should add an tolerance (or so)

I don't know if you're using 0.61, but it's MUCH better now, as far as I have tested it anyway. I do get "odd" rotations when changing orientation of my rocket, but I think that is in part due to roll not really being implemented (if I understand correctly).

Funny thing: I've just read the wiki article about volumes for the 1st time. I've always wondered why the volume one is only 10Kib big when you have an infinite big Archive. Since I have switched to archive in the prelaunch phase I haven't figured out that its not meant as accessible as soon you are further away.

My suggestion are: 1. only fully accessible (and that includes that you are kicked out as soon you not matching those conditions) in close range to KSP in landed or prelaunch phase. That also means executing files.

If you are off the ground then the comm range kicks in which kicks you out of the archive volume as soon as you leave the range (currently one of my crafts is executing files from archive and its in a about 200km orbit and has no antennas)

Also a low baud rate (copying files will take time) which gets even lower as closer you get to the max antenna range (noise).

Also add an exception for a file named "nextVessel.txt" folder in archive. This is for the reason that you don't always have the time to prepare the vessel manually. The file "nextVessel.txt" should automatically executed the next time a new vessel will be at start. (for copying files in prelaunch and set things up). Like any other file in the archive the execution should be interrupted as soon as the vessel launches. which actually shouldn't affect any files which this program has launched from volumes on the actual vessel.

It is my understanding that the only thing at the moment that is under the "range limitation" is the command to switch to the archive. Eventually to do anything on the archive you'll have to be in range (with appropriate dish(es)/antenna). The idea being that while you're at KSP you load up your rocket with programs from the archive, launch and then not really need access to the archive, except for maybe updates to your programs.

And at last but not at least a question: Was there a possibility to control the KSP timewarp with the script or have I only dreamed it? (could swear I have heard it in one of the videos but can't find it anymore anywhere) And if it is, whats the command?

set warp to 1.

In this case setting it to 1 is setting it to 2x, setting it to 2 would be 3x and setting it to 3 would be 4x (of physical acceleration). Setting it to 0 sets it back to normal time.

Would be nice to have that linked somewhere central. I am actual too lazy (right now) to do it (set up the highlight) in Notepad++.

Here is the link to the forum post for the IDE http://forum.kerbalspaceprogram.com/showthread.php/47693-WIN-the-kOS-IDE?highlight=Kerbal I guess I could add this to the wiki, though ATM I don't have the wiki link, plus I'd rather leave it to the developer of the IDE or Kevin to decide if it should be there.

Like said above I don't see the reason as long as you can stay in archive.

It just hasn't been fully implemented yet. Eventually you won't be able to stay in the archive once out of range.

I don't really like RT, because usually you are the computer on board of the probe / vessel so why should there a delay in the execution of the commands...

As someone else mentioned, with RT it's like you're sitting at the controls at KSC (or a command center). Of course, you're "at" the vessel that you are controlling, but you can sort of think of that as watching a computer generated display of the vessel. Sort of similar to the Mars landings, they had the computer graphics showing real time data from the landers, but in reality by the time the computer graphic showed it was landed, it was already landed in real life. At least, that's one way to look at it I guess.

One thing I didn't try with RT2 playtesting, was if I setup a delay to do something and switched to something else, would it do that?

[TMS]

I tried

set target to "Mun".

and it said, "Vessel not found". Is this supposed to work?

Not sure if all objects (like planets) have been made available like this.

Try targeting Kerbin.

[rhoark]

With RT in upheaval, I simulate the effect by interacting with unmanned vessels only through kOS.

[Dunbaratu]

thanks, I will try it, well I started from scratch with new spacecraft and new program and it works so far, but still my zsat is cursed

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.

[Sma]

Hello all, just joined the forums cause I have been working on this launch program and it has been finished! Thanks to the new update I was able to create the best criteria that I can think of for getting a rocket to the correct (and nearly perfect) circular orbit! Here is a list of the implementations I have added to my launcher that I set out to accomplish:

During the vertical ascent and beginning the gravity turn: I created a loop between ground and 25,000m that adjusts the throttle so the craft is always flying at terminal velocity. This from what I have read is the most optimal solution.

Once desired circular orbit altitude has been reached: I created a control logic that keeps slightly adjusting the apogee during atmospheric ascent. This produces consistent results of the apogee being within 10m of desired circular orbit altitude. Example: if I set my desired circular orbit to 100km the biggest difference I have seen is 100,010m.

Upon reaching apoapsis and beginning burn to circularize orbit: I created a control logic that adjust the angle of the burn so the craft is always behind or at the apoapsis until the vehicle reaches the appropriate orbital velocity. With arcsin arccos and arctan functions (which I hope will be implemented! ) I can make the logic more concrete and physics based.

I am really proud of it and I wanted to show it off for people to see and comment on it. If you have any questions, comments, or what to know more feel free to ask. Also if you have any other challenges you think I can take up please let me know! I am excited to use this mod more!

That's pretty cool, closest I got my circular orbit was 113,320 x 100,503. Tried it again and AP was around 136,000 I think, for the same rocket. As long as it's with in that range though I'm pretty happy.

Quick question though, do you have yours setup to handle asparagus staging? I use it in mine though I got part of the code to check the fuel I think from someone else, though I can't remember who now.

Variables set before launch (hopefully I grabbed all the needed bits ) :

set spentStages to 0. // Used for determining how many booster stages have been dropped.
set totalFuel to <liquidfuel>. 
set aspCount to 3. // Number of asparagus stages. Set to 1 if all boosters are to be dropped at the same time.
stage. wait 1.
set aspFuel to stage:liquidfuel. // Total fuel in booster stages.
stage. wait 1.
set eachStageFuel to aspFuel / aspCount. // Amount of fuel for each pair of boosters in asparagus staging.

Then obviously set your direction, throttle up and stage to release the clamps.

and the code to detect if an asparagus stage has burned out (has to be in a loop so it gets checked over and over again until all boosters have been dropped):

  set currentTotal to <liquidfuel>.
  if currentTotal < (totalFuel - (eachStageFuel * (spentStages + 1))) and spentStages < aspCount { 
    set spentStages to spentStages + 1. stage.
  }.

Being as that I had seperate loops I had to copy/paste it into all my loops. After that you just use the normal stage fuel check. Also I'd imagine for solid boosters you could use

stage:solidFuel

to detect solid fuel burn out, I haven't tried it yet though.

Edited September 17, 2013 by Sma

[Dunbaratu]

Thinking about how many antennas I'd have to festoon an eeloo mission with, I think multiplying comm distance according to number of antennas is not the right strategy.

Best case: communications pass through a sequence of relays, a la remotetech. Selection of antennae imported from RT and/or AIES have ranges varying from 16's to low orbit up to 2.5m dishes that reach anywhere.

Good enough: communicotron 16 works within minmus distance, and 88-88 anywhere in the solar system.

I had a look at the code on GitHub and it appears to be getting the range by running some loops that amount to the following formula, as far as I can tell:

let longAntCount = number of long antennas deployed and active on craft.

let dishCount = number of dish antennas deployed and active on craft.

range = ( 75000m * ( 1 + longAntCount ) ) * ( 10 ^ dishCount )

So with no antennae you get 75,000m : (75000*(1))*1

With 3 long antennae and no dish antennae you'd get 300,000m : (75000*(4))*(1)

With no long antennae and 3 dish antennae you'd get 75 million meters: (75000*(1))*(10^3)

With 3 long antennae and 4 dish antennae you'd get 3 billion (*) meters: (75000*(1)*(10^4)

(*) - I used the word "billion" in American English meaning. If you're British, pretend I said "thousand million".

Again, what antennae do to your range is another thing it would be good to have documented if this is meant to be accessible to the everyman. Having to read the source code to get basic documentation sort of runs contrary to the goal of making it easy for people who aren't normally programmers. And if you want to send a probe out to Jool, you NEED to know this sort of information.

Edited September 17, 2013 by Steven Mading

[rkman]

I'm positively shocked and elated to find that apparently KOS now includes telecom functionality.

So being the radio nerd that i am (by education, also former HAM), i'v got to pitch in regarding realism of telecommunication. Just a "for you consideration":

As probably many of you are aware the way to increase comms range of spacecraft in real life is not to put more antennas on the craft.

One reason is that the gain of dish antennas does not stack because the E/M fields of two dish antennas placed next to each other essentially do not interact, unlike non-dish directional antennas (Yagi antennas).

The way to increase range is to have a larger dish and/or a more powerful transmitter. In KSP the practical consequence of a more powerful transmitter is in the increased power requirements: more RTGs, solarpanels, batteries - which adds mass to the craft. Although a more powerful transmitter and larger dish antenna by themself also add mass, that is far less a concern.

Also, inverse-square law applies: twice the range requires 4 times radiated power, either by having a transmitter that is 4 times as powerful (and has 4 times the power requirements) or a dish that has 4 times the surface area (2 times the diameter), or some compromise between those.

For the sake of completeness: irl most of the comms power requirement is covered by the ground stations, which have very large dishes with a gain factor in the order of a million or so.

[Dunbaratu]

I'm positively shocked and elated to find that apparently KOS now includes telecom functionality.

So being the radio nerd that i am (by education, also former HAM), i'v got to pitch in regarding realism of telecommunication. Just a "for you consideration":

As probably many of you are aware the way to increase comms range of spacecraft in real life is not to put more antennas on the craft.

One reason is that the gain of dish antennas does not stack because the E/M fields of two dish antennas placed next to each other essentially do not interact, unlike non-dish directional antennas (Yagi antennas).

The way to increase range is to have a larger dish and/or a more powerful transmitter. In KSP the practical consequence of a more powerful transmitter is in the increased power requirements: more RTGs, solarpanels, batteries - which adds mass to the craft. Although a more powerful transmitter and larger dish antenna by themself also add mass, that is far less a concern.

Also, inverse-square law applies: twice the range requires 4 times radiated power, either by having a transmitter that is 4 times as powerful (and has 4 times the power requirements) or a dish that has 4 times the surface area (2 times the diameter), or some compromise between those.

For the sake of completeness: irl most of the comms power requirement is covered by the ground stations, which have very large dishes with a gain factor in the order of a million or so.

Probes also try to save on transmitter power requirements by using directional antennae, which don't try to pick up signals in all directions like a car radio or a mobile phone does, but only pick up signals and only transmit signals from a specific narrow direction. A vitally important part of the various mars rovers is the software that autonomously works out the rover's position in the solar system in order to know which way to point the antenna to aim it at Earth. If that goes wrong nothing else can work.