kOS Scriptable Autopilot System 0.9

[Jasmir]

Hi there, i have still a problem:

The "lock steering to up * V(...)" still touch the roll-axis, and i don't understand why:

clearscreen.
set mOrbit to 30000.
set mAtmoHight to 20000.
set vMinSpeed to 20.

if BODY = "Laythe" {
 set mOrbit to 80000.
 set mAtmoHight to 51000.
}.

if BODY = "Duna" {
 set mOrbit to 70000.
 set mAtmoHight to 41000.
}.

if BODY = "Kerbin" {
 set mOrbit to 100000.
 set mAtmoHight to 71000.
}.

if BODY = "Mun" {
 set mOrbit to 25000.
 set mAtmoHight to 7100.
}.

if BODY = "Minmus" {
 set mOrbit to 24000.
 set mAtmoHight to 5800.
 set vMinSpeed to 5.
}.

if BODY = "Pol" {
 set mOrbit to 15000.
 set mAtmoHight to 4500.
 set vMinSpeed to 5.
}.

if BODY = "Ike" {
 set mOrbit to 25000.
 set mAtmoHight to 12750.
 set vMinSpeed to 5.
}.

if BODY = "Eve" {
 set mOrbit to 121000.
 set mAtmoHight to 97000.
}.

if BODY = "Gilly" {
 set mOrbit to 25000.
 set mAtmoHight to 12750.
 set vMinSpeed to 2.
}.

set pVal to 0.
set sVal to 0.
set hVal to 90.
set pThr to 0.

SAS OFF.
lock steering to up.
lock throttle to pThr.

print "Launching on " + BODY.
set pThr to 1.

wait until verticalspeed > vMinSpeed.
lock steering to up * V(0 - sVal, 0, hVal).

until apoapsis > mOrbit {
 set pVal to apoapsis / mAtmoHight.
 set pVal to pVal * 90.
 if pVal > 89 { break. }.
 set sVal to pVal.
 set hVal to 90 - sVal.
 wait 0.2.
 print "Pitch " + hVal at (0, 2).
 print "Current Apoapsis " + apoapsis at (0, 3).
}.

print "Burning for apoapsis".
unlock steering.
SAS ON.
wait until apoapsis > mOrbit.

set pThr to 0.
print "Please circulize by yourself".
wait 10.

Has someone a hint for me?

[Camacha]

I have noticed a small problem with declaring variables. When you already ran a script with a similar variable, it does not get reset. This might mess produce unexpected results and calculations up.

It is probably how it is actually supposed to work, but I feel that just setting the variables to a number (even if it is just temporarily a placeholder) is safer. I do not use declare anymore, except for parameters.

[Dunbaratu]

I have noticed a small problem with declaring variables. When you already ran a script with a similar variable, it does not get reset. This might mess produce unexpected results and calculations up.

It is probably how it is actually supposed to work, but I feel that just setting the variables to a number (even if it is just temporarily a placeholder) is safer. I do not use declare anymore, except for parameters.

All variables are global and if they didn't last after a program exited then it would be impossible for a subprogram to calculate values meant to be used by the calling program.

What there probably should be is a way to classify variables as local or global explicitly, such that you can pick and choose which ones remain after the program ends, but right now everything is global and everything remains.

[Camacha]

All variables are global and if they didn't last after a program exited then it would be impossible for a subprogram to calculate values meant to be used by the calling program.

I understand, that is why I said that it is probably how it is supposed to work, but it caught me out testing the same script for the second time. As other people might run into to same problem, I thought I would share my findings here. I see no reason to declare a variable instead of setting it.

In other news, I just reworked my code library into modular segments, so that working on them is a lot cleaner and assembling an operational script should be easier too. The only downside is that running the scripts manages to lock up KSP pretty solid now in a way that I have not seen before, so I will have to figure out what is going on. The commands should be the same as before, so it should be in the loading or switching of programs.

Edit: apparently the phrase:

print "Hoverscript engaged for " + hovertime1 + " seconds + " to hover at " + altset1 + "meter.".

locks up KSP completely.

Edited November 18, 2013 by Camacha

[SirJodelstein]

Is it possible to create/edit/read maneuver nodes with KOS?

[Camacha]

Is it possible to create/edit/read maneuver nodes with KOS?

Yes.

NODE                // Direction of next maneuver node, can be used with LOCK STEERING
MAG:NODE            // Delta-v magnitude of maneuver node
ETA:NODE            // ETA to active maneuver node
ENCOUNTER           // Returns celestial body of encounter
NEXTNODE            // Next node in flight plan.

[Sacred Aardvark]

Edit: apparently the phrase:

print "Hoverscript engaged for " + hovertime1 + " seconds + " to hover at " + altset1 + "meter.".

locks up KSP completely.

FTFY

print "Hoverscript engaged for " + hovertime1 + " seconds, to hover at " + altset1 + "meters.".

Here's your problem("):

hovertime1 + " seconds + " to hover at " + altset1

Could do this as well: hovertime1 + " seconds " + " to hover at " + altset1

Weird that it locks up though, I usually get a syntax error on missing/extra quotation marks.

Edited November 18, 2013 by Sacred Aardvark
42!

[dimmy]

i think its better to add the kOS2 mod with following:

you wrote what youwant.

and it compiles in the CSharp script in runtime in this mod, also you can connect toanything in the system (names, etc).

[Camacha]

FTFY

[...]

Weird that it locks up though, I usually get a syntax error on missing/extra quotation marks.

Once I knew which line it was it was not hard to fix. It is just that a hard lockup instead of a 'flagrant error' is unusual like you say, so maybe Kevin wants to investigate.

[Dunbaratu]

Once I knew which line it was it was not hard to fix. It is just that a hard lockup instead of a 'flagrant error' is unusual like you say, so maybe Kevin wants to investigate.

I've seen several cases where when KOS can't comprehend the syntax it gets stuck in a neverending loop (which is what locks up all of KSP. All a mod has to do to lock KSP is just: "while true {}." and KSP doesn't have a safety mechanism to grab control from the mod back again. Granted, detecting infinite loops is one of the classic computer science problems that is mathematically proven to be impossible) But KSP could theoretically mandate a maximum timeslice based on the user setting for physics update timeframes (that number that defaults to 0.1 in the settings screen) and only allow a mod that much time to finish its response to a callout before slapping the mod with a newspaper and saying "NO. I have a physics engine here to keep track of, bad mod, bad." and then suspending the mod. But it doesn't, so a mod that's not responding brings all of KSP down.

[Dunbaratu]

i think its better to add the kOS2 mod with following:

you wrote what youwant.

and it compiles in the CSharp script in runtime in this mod, also you can connect toanything in the system (names, etc).

Okay, start writing it then.

Good Luck.

[erbmur]

Hi All,

Does anybody have a simple-ish script that would calculate terminal velocity? For use with throttle control during takeoff?

[Dunbaratu]

Hi All,

Does anybody have a simple-ish script that would calculate terminal velocity? For use with throttle control during takeoff?

// You need these values in order to do the calculation:
set gConst to 6.67384*10^(0-11). // The Gravitational constant
set e to 2.718281828459 .  // natural log base.
set atmToPres to 1.2230948554874 . // presure at 1.0 Atm's.
set bodyMass to Body(body):mass. // Kerbin's mass.
set bodyRadius to 600000. // Hardcoded For Kerbin, radius not available in BODY struct yet.
set bodyAtmSea to 1.0 // For Kerbin.  use wiki for other worlds.  Not avail in BODY struct yet.
set bodyAtmScale to 5000. // For kerbin.  Use wiki for other worlds.  Not avail in BODY struct yet.
set vdrag to 0.2 // If you have no parachutes on.

// grav acceleration at your current location (i.e. 9.8 m/s^2 for sea level on Kerbin):
// Recalculates to take into account the lessening of gravity as your altitude rises, which matters more for small planets.
lock gravhere to gConst*bodyMass/((usepe+bodyRadius)^2).

// air pressure here:
lock herepress to (atmToPres*bodyAtmSea) * e ^ ( (0-altitude)/bodyAtmScale) .

// Terminal velocity at current altitude:
lock termv to sqrt( (250*heregrav)/( herepress * vdrag ) ).

// Force of drag the air causes depending on your current speed and altitude.
// Not necessary for term vel, but I thought you might like to know it:
lock fdrag to 0.5*( (atmToPres*bodyAtmSea) * e^( (0-altitude)/bodyAtmScale) )*(velocity:surface:mag)^2*vdrag*0.008*mass.

it may have errors because I just re-edited it from a version where I was getting term v at periapsis rather than at current altitude, so beware.

Also beware that case matters. Some of those variables are all lowercase because they had to be to avoid a bug in KOS with lock expressions.

Edited November 18, 2013 by Steven Mading

[Sma]

Is it possible to create/edit/read maneuver nodes with KOS?

Yes.

NODE                // Direction of next maneuver node, can be used with LOCK STEERING
MAG:NODE            // Delta-v magnitude of maneuver node
ETA:NODE            // ETA to active maneuver node
ENCOUNTER           // Returns celestial body of encounter
NEXTNODE            // Next node in flight plan.

Also, to add/create a node (hopefully I remember this correctly)...

set x to node (time:seconds + eta:apoapsis, 0,0,0). //To add a node at Ap. The last zero is prograde, the other two are normal and radial, but I don't remember which order.
add x.

set x:prograde to x:prograde + 10. // Add a deltav of 10m/s 

You could also just add the deltav amounts at the time of creation.

Also to remove it, you can simply use "remove x.", or whatever variable name you used.

[Camacha]

Has anyone had trouble with loops eating up processor time? I noticed considerable lagspikes when running a script that would freely run its calculations, mainly around KSC. As the spikes always occured during that particular script, I first tried editing out things like every lock ... to I could miss, as those run every cycle, as well as any excess readout prints, but that did not seem to help much. When I finally tried a simple wait 0.1. to slow the loop iteration speed down, the lag became a lot less pronounced and the Task Manager also showed barely any maxed out CPU spikes. Still severe spikes, but not capped by the capabilities of the CPU (or actually, core).

I must admit that I am a bit suprised that two scripts can differ that much in CPU workload, especially since my hardware is pretty much up to date. Of course, running multiple mods like FAR and kOS is not helping, as they add a noticable workload.

I've seen several cases where when KOS can't comprehend the syntax it gets stuck in a neverending loop (which is what locks up all of KSP. All a mod has to do to lock KSP is just: "while true {}." and KSP doesn't have a safety mechanism to grab control from the mod back again. [...] But it doesn't, so a mod that's not responding brings all of KSP down.

Good background info, interesting!

[Dunbaratu]

After a bit of googling I've come to the conclusion that there isn't a good webpage out there that tells me the answer to this math problem:

I want to perform a transfer from my orbit to intercept another orbit. Both orbits are ellipses (obviously) but you are NOT safe to make the assumption that they are circular. Your starting orbit can be any arbitrary ellipse, and the target can be any arbitrary ellipse. The intercept has to be timed so me and the target are there at the same time.

You can assume the two orbits have the same inclination plane, so you can treat it like a problem in 2-D space to make it easier. (Solving the inclination problem can be done separately.)

All the help I can find on it keeps containing the assumption the starting orbits are circularized.

SO this is my plan of attack. I'm done for tonight working on KSP but I plan to attack this tomorrow. For now check my logic and tell me if this seems right:

The givens I have or can calculate quickly from what I have are these:

Let v1 be my initial velocity vector right now. I know my speed and my direction relative to the body both me and the target are orbiting (i.e. the sun).

Let p1 be my initial position right now, which I could express in XYZ form or in polar coords as (r,theta), where theta is my angle from some arbitrary point I pick).

Let o1 be the set of orbital parameters I can derive that describe my current orbital shape. All the elliptical parameters should be easily derivable: the semi-major axis, my current angle from periapsis, etc.

What matters is that the new ellipse I make when I burn

Let v2, p2, and o2 be the same thing, but for where my target body is right now. Note if I use polar coords I need to use the same reference zero point for both (I can't measure my theta from my periapsis and my target's from its periapsis since our perapsi (is that a word?) aren't at the same angle.)

Given all of that as starting constraints, here's my math steps to try to cone up with the answer:

Step 1 - Get where my intercept would be if I burned now.

If we assume I will burn prograde (or retrograde, which mathematically should just be representable as a negative number in the prograde direction) ONLY, then presumably I can recalculate a new set of orbital parameters, call them o3, that represent my new ellipse I get after applying the delta V. at that point my old ellipse, o1, becomes irrelevant. What matters is the new one, o3. Given nothing but my starting position and that my new velocity must be some vector pointing along the same direction as my current one, presumably that's enough to constrain all the possible new ellipses I could end up with to just the ones possible with differing speeds in that direction.

So I need to find the intercept point between that new ellipse, o3, and the target one, o2.

I imagine there will be one of three possible results depending on what my new speed is:

- Zero solutions: If my new speed is too slow, then the math to find the intercept of o2 and o3 will have zero solutions, or at least no real-number solutions, as there will be no intercept points.

- Two solutions: If my new speed is too high, then the equations to find the intercept of o2 and o3 will have two solutions, crossing higher above the target, then falling back in again later.

- One solution: If my new speed is just right, then the equations to find the intercept of o2 and o3 will have exactly one solution, barely touching.

Therefore, what I'm looking for is the speed at which I only get exactly one solution to the question "where do 02 and 03 intercept?". Because I see there could be 0,1, or 2 solutions, I'm predicting a term involving a square root will be involved somewhere in the math, in which I'll be solving for where that term is zero. (square root of a negative will be the case where there is no intercept, and square root of a positive will be the case where there's two).

I predict I'll be able to do this, and therefore come up with a new position, p3, which is the position along the target ellipse o3 where I would barely kiss against it and neither miss below it, nor cross above it, if I tried my prograde burn now. In the case of circular starting orbits this is dead simple - it's always 180 degrees from where I am now, and that simplicity is the reason those equations work out so nicely. But for any arbitrary ellipses that doesn't hold true.

Step 2: How many seconds will it take me to get to p3?

This should be simple based just on knowing that i'll get there along the path of o3, and I know my current position on o3 and I know the position p3 on o3.

Step 3: How many seconds will my target take to get to p3

P3 is also a position along the target's ellipse, o2. How many seconds will it take to get there along its o2 path?

Step 4: Solve for which starting position would cause step 2 and step 3 to be the same number of seconds.

That's the position at which to do the burn.

I THINK this is solvable, and probably a lot of the messy terms will fall out along the way.

Can anyone find a flaw in my logic? I'll probably tackle actually doing this tomorrow. I want to be able to get to the more difficult planets in the automated pilot challenge and getting this bit right is crucial.

Edited November 19, 2013 by Steven Mading

[cfds]

Getting the parameters of the new ellipse from distance from the focal point and your momentary velocity is doable. But the problem with ellipses is that calculations of segments of arc or area have no analytical solutions. So you are restricted to numerical methods to find flight times and similar things.

[erbmur]

Code:

// You need these values in order to do the calculation:

set gConst to 6.67384*10^(0-11). // The Gravitational constant

set e to 2.718281828459 . // natural log base.

set atmToPres to 1.2230948554874 . // presure at 1.0 Atm's.

set bodyMass to Body(body):mass. // Kerbin's mass.

set bodyRadius to 600000. // Hardcoded For Kerbin, radius not available in BODY struct yet.

set bodyAtmSea to 1.0 // For Kerbin. use wiki for other worlds. Not avail in BODY struct yet.

set bodyAtmScale to 5000. // For kerbin. Use wiki for other worlds. Not avail in BODY struct yet.

set vdrag to 0.2 // If you have no parachutes on.

// grav acceleration at your current location (i.e. 9.8 m/s^2 for sea level on Kerbin):

// Recalculates to take into account the lessening of gravity as your altitude rises, which matters more for small planets.

lock gravhere to gConst*bodyMass/((usepe+bodyRadius)^2).

// air pressure here:

lock herepress to (atmToPres*bodyAtmSea) * e ^ ( (0-altitude)/bodyAtmScale) .

// Terminal velocity at current altitude:

lock termv to sqrt( (250*heregrav)/( herepress * vdrag ) ).

// Force of drag the air causes depending on your current speed and altitude.

// Not necessary for term vel, but I thought you might like to know it:

lock fdrag to 0.5*( (atmToPres*bodyAtmSea) * e^( (0-altitude)/bodyAtmScale) )*(velocity:surface:mag)^2*vdrag*0.008*mass.

it may have errors because I just re-edited it from a version where I was getting term v at periapsis rather than at current altitude, so beware.

Also beware that case matters. Some of those variables are all lowercase because they had to be to avoid a bug in KOS with lock expressions.

Rockstar baby!

Edited November 19, 2013 by erbmur

[erbmur]

Hi Steven Mading,

I have a quick question about your final equation.

lock termv to sqrt( (250*heregrav)/( herepress * vdrag ) ).

Where does the 250 derive from, and what is your reasoning for setting vdrag to 0.2 further up the code? I'm assuming this as something to do with the drag of the individual parts? Which i think would be different when using FAR (which i do)?

[Dunbaratu]

Hi Steven Mading,

I have a quick question about your final equation.

Where does the 250 derive from, and what is your reasoning for setting vdrag to 0.2 further up the code? I'm assuming this as something to do with the drag of the individual parts? Which i think would be different when using FAR (which i do)?

The 250 is the result of some constants in kip's calculations.

The 0.2 is the stock parts default for all non parachutes. To respond to differing part drag requires a feature KOS does not have yet - the ability to query the craft's parts and their properties.

[Dunbaratu]

But the problem with ellipses is that calculations of segments of arc or area have no analytical solutions. So you are restricted to numerical methods to find flight times and similar things.

If that was true then calculating when to do simplified circular-to-circular Hohmann transfers wouldn't work because you couldn't get the elliptical transfer time elapsed.

(EDIT, oh, no you're right. Hohmann transfers use the trick of just knowing that it's half the orbital period, which is a special case that only works for circular orbits.)

Edited November 19, 2013 by Steven Mading

[Javster]

Wow! I wanted something like this from mechJeb, such as activating soft landing rockets that activate at a low altitude, but this is even better!!

[adammada]

How to set steering to kill horizontal(surface) velocity.

I want to do something like that:

SET x TO -1 * velocity:surface:horizontal

LOCK steering To x.

There is lock steering to Heading and lock steering to velocity surface, but how to set steering only to horizontal component of velocity?

[Camacha]

I noticed that the aforementioned lag spikes happen pretty much every time when a script is repeatedly looping through an until loop. Every second, or sometimes every two seconds, the game will freeze for a tenth of a second or so. The simulation does not seem affected, but when it gets intense it can be very annoying.

Like I said, I have a fairly meaty CPU, so I can not imagine that being the cause of the problem.

Edited November 20, 2013 by Camacha

[Camacha]

There is lock steering to Heading and lock steering to velocity surface, but how to set steering only to horizontal component of velocity?

Are you on a planet? You could use latitude and longitude to figure out how fast you are going in which direction