kOS Scriptable Autopilot System 0.9

[balu0]

There is a plugin for sensors:

http://kerbalspaceprogram.com/sensor-reporter-kos/

Similar approach could be used for the terrain radar altimeter.

Just use one of stock parts for it.

[Sma]

@Kethevin. Yep its RT2 that causes the problems with staging/keyboard input. I get around that sort of by locking the staging. kOS ignores that so it still "works". Though if you have action groups if you type a number that action group will fire, same with if you've setup the abort action group.

As for your second question, I would think having the probe core face forward and using wheelsteering instead would help. Also maybe put KSP into docking mode (2nd icon on the control panel on the bottom left) might help, though I haven't tried messing with rovers yet so I don't know.

Now for something I'm working on...

I'm trying to get 3 "komm sats" into kerbosynchronous orbit. I have a rocket that launches with the 3 komm sats. Then I'm trying to setup a 4hour orbital period with AP at 2,868.75km, and every time the rocket comes around to AP it will drop off another komm sat which I would then switch to and run a circularization program. My AP is currently above what I want it to be so I'm trying to setup a node to bring it down to 2,868.75km. The way I'm writing my program is so that it can be semi universal, in that if the AP is above or below desired altitude (in this case 2,868.75km) it'll add a node and adjust accordingly. So far I've tried using a formula from the KSP Wiki to calculate deltav needed and then set the node to that, but no luck really with that. The formula(s) I've tried separately are:

sqrt(gp/r1)*(sqrt( (2*r2)/(r1+r2) ) - 1))*1000.

sqrt(gp/r2)*(1 - sqrt( (2*r1)/(r1+r2) ) ) )*1000.

r1 being my starting AP, over 3,000km. r2 is the altitude i want to be at (2868750) and gp is the gravitational parameter of Kerbin (3530.461). The *1000 is to convert from km/s to m/s. The results of using both formulas ends up being around 0.1 something +/- so obviously not what I want. I've tried moving things around (switching position of r1 and r2) which changed it but not the way i wanted lol. I just don't get the formulas I guess.

I've had better results subtracting by 10 from x:prograde until its less than desired altitude, then adding 1 until its just above desired, and so on with progressively smaller numbers. Problem is it never actually lands right where I want it to. Maybe partly because my if statements I was using overlapped or something. The other problem I had was that it started to get major lag after a couple of runs through the program. If I reloaded the save though it was fine.

At any rate, I'm kinda stuck for the moment, I'm gonna try doing the if statements and add/subtract from x:prograde again and see if maybe I can find something that works.

[balu0]

Quick question.

I just funt the "list engines." and "list parts." commands.

Can I do something with the listed things ?

Like toggle and engine or air intake on and off ?

[Sma]

Quick question.

I just funt the "list engines." and "list parts." commands.

Can I do something with the listed things ?

Like toggle and engine or air intake on and off ?

You mean, thats a thing? I haven't seen it before. I'll have to test it out next time im in the game.

[Dunbaratu]

Quick question.

I just funt the "list engines." and "list parts." commands.

Can I do something with the listed things ?

Like toggle and engine or air intake on and off ?

Nope. You can only get the strings on the screen, not into variables.

I figure in order for those to be useful commands, KOS has to first implement arrays, and then implement a way to get the output of a LIST command into an array of objects instead of to the screen.

That's a first step. Then the ability to take an object of type "vessel part" and manipulate it would have to come second.

[Cilph]

Oi. With regards to RT2 / kOS compatibility, anyone mind telling me the best way to contact one of the devs?

[Sma]

Oi. With regards to RT2 / kOS compatibility, anyone mind telling me the best way to contact one of the devs?

As far as I understand it KevinLaity is the only dev working on this. I don't know how often he gets on though. He use to be pretty good about responding, but has been a little slower lately, unless it's just my imagination.

[willow]

@Baloan,

I think the first thing you need is a node chaser script, which simply executes a Node, then a variety of scripts to set up nodes for changing apoapsis/periapsos (=circularization) and a scripts to create nodes that do hoffman transfers. If you have those the rest should become regular math. The specific calculations of transfer windows are at the very least code documented in various mods which all are open sourced.

[Sma]

What I would find really helpful, and it really seems quite realistic to me to enable it, would be a variant of ALT:RADAR that tells you the distance from your craft to the ground in the direction your craft is pointed rather than straight down. In other words, if you are aimed 45 degrees off from "up", then don't report the altitude below the craft, but rather report the distance to the ground in that 45 degree angle. The diagram below shows what I'm talking about. Getting the radar distance along that blue line in my picture is what I'm talking about.

***Awesome lander diagram example***

It makes sense that the radar distance measuring equipment would actually rotate with the craft and give the blue result rather than the green one. And that data is crucial to making a working landing script that can react to unknown landing sites at unknown locations.

Because of the inability to read the terrain, I can't really do a "suicide burn" efficient landing because of the case illustrated in that picture. I end up having to guess what the highest ground MIGHT be based on the wiki entry for the body (all the bodies tell you the max elevation of the highest mountain on that body), and design the suicide burn to "land" at that height first, and then descend from there down to the ground. On rocky bumpy bodies like The Mun, that's an enormous amount of error I have to account for.

What might be neat is if with mod integration, you could add a lazor from lazor systems, to check distance from "target". In this case it would work on anything, buildings terrain etc. Could possibly be used to land on top of a docking port of a base maybe, although I guess manually you can already do that with docking alignment tools and docking cam. Trying to remember if the docking cam had a display that showed distance from objects even if they weren't selected.

At any rate this all depends on if KSP has anything that would allow such things to work, especially with using the lazor idea. Would be awesome though...

Edited November 8, 2013 by Sma

[ANWRocketMan]

I'm having a problem with this(simplified) piece of code:

DECLARE X.
DECLARE I.
DECLARE T.
SET X TO 9.
SET I TO 10.
SET T TO 0.
UNTIL X < 1
{
	SAS OFF.
	LOCK STEERING TO UP + R(0,T + I,0).
	WAIT 5.
	//WAIT UNTIL ROUND(UP:PITCH + T + I) = ROUND(FACING:PITCH).
	SET T TO T + I.
	SET X TO X - 1.
	SAS ON.
}

How do I fix the WAIT statement to actually wait until the facing of the ship is equal to the incremental angle. Currently, that WAIT statement just does not work. Having to wait 4 or 5 seconds per increment is not very nice. And such a fixed wait time does not work if you're turning through 180 degrees.

EDIT: I was thinking i might get the difference between FACING PITCH and the incremental pitch(UP PITCH + T + I), then WAIT UNTIL that difference is smaller than a certain number(say, within 1 degree). But it would seem that WAIT UNTIL does not account for things that happened just before it in the loop. Whenever I use one that might work, it just runs through the loop without even allowing the statements before it to run.

EDIT 2:

There is another problem. I want to use this method because I want to allow for the use of a Speed modifier. This is so that kOS doesn't just rip apart a large vessel or an unstable one when this is used.

Edited November 8, 2013 by ANWRocketMan

[Dexter9313]

Is there a way to have a "when... then..." statement being permanent yet ? I can't figure how to make an auto-staging ascent without this... (Or without putting explicitly 20 "when .. then .."s within themselves.)

[TelluriumCrystal]

I wonder if this will ever evolve into a object-oriented programming language at some point…? With a full palette of sensors for acquiring important information and integration with most major mods?

I suspect I may be thinking a bit too big.

But still, is it possible? Not reasonable, but possible?

[Sma]

Is there a way to have a "when... then..." statement being permanent yet ? I can't figure how to make an auto-staging ascent without this... (Or without putting explicitly 20 "when .. then .."s within themselves.)

Shouldn't be a problem. My self as well as others have written launch scripts that stage when fuel runs out, some using asparagus staging. YOu can do it by either knowing how much fuel you have exactly, and preprogramming that in, or as I did with asparagus staging, set the staging up so the boosters are activated first, so you can grab how much fuel they have. Then you can divide by the number of booster groups/pairs.

Without asparagus staging it's really simple. The example below I just wrote off the top of my head with out testing it on a ship but lets assume you have solid rockets on the side, and the SRBs, main engine(s) and launch clamp are on the same stage, with each progressive stage having the decoupler and next stage engine starting at the same time.

lock throttle to 1. stage. // Power up engines and stage.
sas on. //Turn SAS on temporarily for stability.
wait 10. //Wait 10 seconds.
sas off. //Turn off SAS so heading can be adjusted. No need for SAS until space.
lock steering to heading 90 by 90. //This just orients the craft so it doesn't go crazy during the gravity turn, being as it will rotate on two axis at the same time.

//Do this until apoapsis is 75,000m.

until apoapsis > 75000 {
   if stage:liquidfuel = 0 { stage. } //If current stage is empty stage.
   if stage:solidfuel = 0 { stage. } //If SRBs are empty drop them.
   if altitude > 10000 { lock steering to heading 90 by 45. } //Begin gravity turn.
   if apoapsis > 60000 { lock steering to prograde. } //Start gaining more horizontal speed.
}
//Apoapsis is now 75,000m or 75km.
lock throttle to 0. //Turn off engines.
wait until eta:periapsis < 20. //Wait until eta to periapsis is 20 seconds
lock throttle to 1. //Restart engines.
wait until periapsis > 75000. //Wait until periapsis is above 75,000m
print "Welcome to Space!.".

If you wanted your decoupler and next engine to not happen at the same time you could add a wait command to the staging section like

   if stage:liquidfuel = 0 { stage. wait 5. stage.}

**Edit After re-reading your post, I think you could get by with just adding a simple wait statement. With out seeing your code I'm just guessing but you're looking for something like this:

when stage:liquidfuel = 0 then { stage. }
wait until apoapsis > 75000.

I'm not familiar with using when/then statements but as I understand it it stays in and gets repeated when the condition is true. If that is the case then the above code should keep working until you get to space. Of course at that point you'll need to circularize but thats easy enough.

At any rate, hope all of this helps.

Edited November 8, 2013 by Sma

[AbeS]

Is there a way to have a "when... then..." statement being permanent yet ? I can't figure how to make an auto-staging ascent without this... (Or without putting explicitly 20 "when .. then .."s within themselves.)

For an ascent you could add it to a loop like this:

until apoapsis>desiredOrbit {
  if stage:liquidfuel=0 {stage.}.
}.

For asparagus staging you would need some more thinking though

[mossman]

@Stiggles:

4. How long is your burn? You know your deltav and the acceleration your engine(s) provide (which is deltav per second). Engine acceleration a is F/m (force by mass), set maxA to maxthrust/mass, and then set burnduration to deltav / maxA.

I should point out that since the mass of your vessel is of course varying as you burn this method will yield a non-insignificant error.

Instead, I suggest calculating the burn time by calculating the mass of propellant needed to execute the burn and dividing that by the mass flow rate of your engine.

If you know your craft's starting mass, Isp, and the needed ÃŽâ€V then you can calculate this fairly easily with some algebra and the Tsiolkovsky equation.

ÃŽâ€V=Isp*g*ln(m0/m1) rearranges to m1=m0*e^(-ÃŽâ€V/Isp*g), propellant mass mp = m0 - m1 and the mass flow rate should be (Isp*g)/F, F being the force of thrust from your engines. Keep in mind that g is basically just a unit conversion constant (For Isp in seconds to exhaust velocity) and = 9.80665 m/s^2.

I use this for a handy maneuver autopilot and I usually get errors less than 0.2 m/s ÃŽâ€V.

[lijat]

mossman: I'm using something similar, just out of interest, how do you calculate ISP of you craft? My method is a bit slow it seems

[balu0]

I

Need

Functions

NOW!

I'm almost done with my universal throttle control.. would be nice to use as a "subroutine"

[Dunbaratu]

Is there a way to have a "when... then..." statement being permanent yet ? I can't figure how to make an auto-staging ascent without this... (Or without putting explicitly 20 "when .. then .."s within themselves.)

One thing that might work, assuming you don't mind the time expense of calling another program, is to make the body of the WHEN/THEN be a program file so you can refer to itself inside of itself:

Imagine a small program file consisting of just these lines:

// This is a program file called "whenResponder"
print "doing a thing here".
WHEN blah THEN run whenResponder.  // Note the recursion.  This is the name of this program file itself.

Then from your main file, set it up for the first time:

WHEN blah THEN run whenResponder.

By putting the body of the THEN inside a program file, you give yourself the ability to perform recursion because you can refer to the chunk of code by its name from inside itself, which you can't do otherwise.

That might let you break out of the Klein bottle problem that you want a WHEN/THEN that contains itself inside its own body.

Edited November 8, 2013 by Steven Mading

[baloan]

@Mossman:

You are of course right. But I am using burntime/2 to determine when to start the burn. The error introduced by not exactly centering the burn around the maneuver node should be small. (Incorrectly calculated) burn time in my configuration is ~ 40sec. It'd be interesting to see what the error is - and what effect this has on orbit configuration (apoapsis vs periapsis error).

And to mess timing up: I throttle my engine during the last few seconds to be able to shutdown accurately and exactly hit deltav. That extends burn time and wrecks any calculation assuming full thrust all the time.

Edited November 8, 2013 by baloan

[Sma]

I

Need

Functions

NOW!

Then you program kOS and deal with all the other demands people are making, all the while not getting paid to do so.

I'm almost done with my universal throttle control.. would be nice to use as a "subroutine"

Aside from what I mentioned above you can SORT OF emulate....(kinda, but maybe not really) by running other programs inside of your main program, and using parameters where necessary.

Below is a crude and not guaranteed to work...at all.. program, something I whipped up, without testing. Hopefully it gives you some idea on how this could work. I've only done this once so far using a program trying to set nodes and adjust them to get a desired orbital period. Basically any variable set in your secondary program will carry over into your primary program, and when you "call" the "function" you can pass it variables by putting them in () as shown below with the circularization part.

//main program
set orbitHeight to 100000.
run throttleControl.
stage.

lock steering to heading 90 by 90.
wait until altitude > 10000.
lock steering to heading 90 by 45.
wait until apoapsis 60000.
lock steering to heading 90 by 20.
wait until apoapsis > orbitHeight.

run throttleControl.

run circularize(orbitHeight). // Call sudo/faux function

//throttleControl pseudo code in this example 
if not launched, lock throttle to full. Break
if launched, check speed/altitude, adjust throttle accordingly. Break once adjusted.
check altitude, if apoapsis nearing desired altitude throttle back. Break once adjusted.
if desired apoapsis altitude reached cut throttle. Break

//circularize
declare parameter orbitHeight
lock steering to prograde.
until orbitHeight < apoapsis {
   if apoapsis < orbitHeight-40000 {lock throttle to 1.}
   if apoapsis > orbitHeight-40000 and apoapsis < orbitHeight-5000 {lock throttle to .5.}
   if apoapsis > orbitHeight-5000 and apoapsis < orbitHeight {lock throttle to .1.}
   if apoapsis > orbitHeight {lock throttle to 0.}
}

wait until eta:apoapsis < 20.
lock throttle to 1.
until orbitHeight < periapsis {
   if periapsis < orbitHeight-40000 {lock throttle to 1.}
   if periapsis > orbitHeight-40000 and apoapsis < orbitHeight-5000 {lock throttle to .5.}
   if periapsis > orbitHeight-5000 and apoapsis < orbitHeight {lock throttle to .1.}
   if periapsis > orbitHeight {lock throttle to 0.}
}

[baloan]

1. 
   

@Baloan,

I think the first thing you need is a node chaser script, which simply executes a Node, then a variety of scripts to set up nodes for changing apoapsis/periapsos (=circularization) and a scripts to create nodes that do hoffman transfers. If you have those the rest should become regular math. The specific calculations of transfer windows are at the very least code documented in various mods which all are open sourced.

@willow:

Thanks for your hint which got me thinking about the steps to be taken:

1. node chaser: that is part of the ascent script that I uploaded to the kOS wikia (here). Now that subroutine programs are available I should be able to refactor a standalone module.
   
2. circularization: Needs to find the correct place for maneuver nodes in arbitrary orbits. Something like: establish_orbit(periapsis, apoapsis)and establish_circular_orbit(altitude). And yes, the script should find a solution with good fuel economy.
   
3. docking: you want to be able to combine parts for an interplanetary transfer. Currently no rcs thruster support for translation (forward, backward, etc. see here)
   
4. Hohman transfer: Changing orbit to Mun is easy: establish_orbit(ship:periapsis, rk + mun:altitude). The difficult part is to hit the launch window for the burn so that Mun is actually there when I arrive at apoapsis. I am playing around to find those for a Kerbin Mun transfer. The only way to find an "encounter" seems to be to brute force traverse node times. This might be feasible for Kerbin-Mun, but not for interplanetary transfers where searching for an encounter will take much longer - or will be impossible due to inclination (which is currently not supported. see here).
   
5. interplanetary transfers: without planetary positions relative to their "parent" body, i.e. Kerbol for planets or Kerbin for Mun/Minmus, I cannot calculate transfer windows (relative body positions are currently not supported). As mentioned above, playing around with a node parameters until finding an encounter seems unrealistic - no wonder, space is mostly void and empty; very empty.
   

Edited November 8, 2013 by baloan

[balu0]

Hmm interesting.

Do variables persist?

So if I set X to 2 in 1 program, do X get set to 2 on the other ?

I will have to run some test. If it works like this I can have return values for my "functions"

Thx

[Sma]

1. node chaser: that is part of the ascent script that I uploaded to the kOS wikia (here). Now that subroutine programs are available I should be able to refactor a standalone module.
   

I'm going to have to try that. I grabbed parts of your code from far2 to try for later. I'm trying to get a launcher with 3 komm sats for RT2 into kerbosync. I've got my launcher above 286...blah blah...and have tried getting a node set to the exact altitude needed with not much luck. It just keeps bouncing around the altitude needed. Maybe it'll work for me. Once I get my AP where i want, I have to try and see if I can get the PE to where I need it for a 4hr orbital period...but I'll cross that bridge once I get the AP settled.

[balu0]

Ok done some tests.

TL/DR: variables ar global across all programs, so you can "simulate functions" with "run" command.

here is a quick test code to try:

Program:

clearscreen.
set f1return to 0.
set prog1 to 0.
print "P: f1return " + f1return.
print "P: prog1    " + prog1.

print " ".
print "Call Function".
print " ".

[B]run function1.[/B]

print "Variables from program:".
print " ".
print "P: f1return " + f1return.
print "P: prog1    " + prog1.
[B]print "X created in function, but printed from program:" + x.[/B] //this can be the return value of a function for example
print " ".

"Function"

set f1return to 1.
set prog1 to 1.
set x to 99.
print "variables from function:".
print " ".
print "F: f1return " + f1return.
print "F: prog1    " + prog1.

[mossman]

mossman: I'm using something similar, just out of interest, how do you calculate Isp of you craft? My method is a bit slow it seems

Discounting launch vehicles, none of my craft have used different engine types in the same stage so I just use the posted Isp for the engine I am using.