[1.3] kOS Scriptable Autopilot System v1.1.3.0

[Dunbaratu]

Well I reached my limit of understanding... after trying several different combinations of commands and thinking of ways to do this i just can't make it work... so i'm after advice or something, if anyone is interested... To get this i made that flow chart or i guess i did to help you guys understand what i'm trying to do in a very visual way... i hope it helps...

http://i.imgur.com/AZ6vyNY.jpg

Thank you!

(i can make it work manually, just adjust the pitch by a very small amount until the VS and VA is 0 (this i'll do when trim is released)... but i would like it to be automated, as an autopilot, if possible)

Why haven't you tried just putting all the conditions in the same loop in one large if/else ladder?

until false {
  if altitude < 5000 {
    if verticalspeed < 10 {
      // do stuff here.
    }
  } else if altitude > 5000 {
    if verticalspeed > 10 {
      // do stuff here.
    }
  } else {   // it's exactly 5000, which seems unlikely as it will always be something like 5000.0001 or 4999.9999
    // do stuff here.
  }
}.

But in general, I think your algorithm is too dependent on boolean conditions and should depend on mathematical continuous sliding scales.

For example, instead of using "if below 5000" and "if above 5000", just calculate this:

SET desiredAlt to 5000.

LOCK altitudeDiff TO (ship:altitude - desiredAlt).

Now if your altitude is above 5000, altitudeDiff is positive, else it's negative, AND the size of altitudeDiff tells you just how far off you are from 5000.

Which you can then use to decide how strong to set your vertical climb to. The farther off you are from 5000, the steeper your ascent or descend should be. Since you have this in a number, you can set it by math, again, like so:

// Lock neededVSpeed to a bigger number the farther off the altitude is, up to a maximum of 20 m/s

LOCK neededVSpeed TO ( - MAX(altitudeDiff/500,20) ).

Now you've got a neededVSpeed that is telling you how much vertical speed you need, and its sign tells you in which direction you need it.

Etc, etc…

Edited November 2, 2014 by Steven Mading

[SnappingTurtle]

It seems that if I reboot or shutdown a terminal when it has locked the steering it becomes impossible to unlock the steering without changing scenes. Shouldn't reboot/shutdown release locks?

[falcoiii]

Trewor007

Thanks for the response, here is the relevant source code. I think it may be the previous script that messes up KOS.

At ikemission on 1, line 1

copy dlaunch from 0.

^

Called from d on 1, line 19

run ikemission.

^

d.txt:

// more code here...

copy dunamission from 0.
run dunamission.
delete dunamission.

print "duna mission done".
wait 10.

//fails in this mission.
copy ikemission from 0.
run ikemission.
delete ikemission.

//more code here...

ikemission.txt:

copy dlaunch from 0.


print "starting dlaunch".
wait 2.
run dlaunch.
wait 2.
//fails here... this never prints.
print "done dlaunch".
wait 2.
delete dlaunch.
delete warpfast.


copy incline from 0.


run incline("Ike").


delete incline.
delete circularize.


copy ike from 0.


run ike.
delete ike.


copy land from 0.
run land.
delete land.
wait 5.

dlaunch.txt:

if altitude > 50000
{
  print "Already in space!".

} else {


unlock steering.
lock throttle to 1.
print "DunaLaunch!".
wait 4.


when ship:liquidfuel < 1430 then { 
  stage. 
}.




set mySteer to up.
lock steering to mySteer.


set diff to 100.
lock throttle to 0.5.


until ( diff < 1 OR VERTICALSPEED < 1 ) {
  SET Y to ABS(facing:yaw - mySteer:yaw).
  SET P to ABS(facing:pitch - mySteer:pitch).
  SET Y to 180 - ABS(Y - 180) .
  SET P to 180 - ABS(P - 180) .

  set diff to Y + P.
  wait 0.1.
}.


lock throttle to 1.


set mySteer to up.


legs off.


toggle AG1.


wait 9.


print "Turning to fix latitude. Waiting for 5000 feet to begin gravity turn.".
print latitude. 
//lock steering to up + R(10*abs(latitude)/latitude,0,0).
wait latitude/10 + 10.
lock steering to up. 
print latitude.


until altitude >4000 and ALT:RADAR > 1000 {
  print latitude.
}.
lock steering to up + R(0,-40,0).


//lock steering to heading (90 + latitude/2) by 50.
print "Beginning gravity and inclination turn.".


print "Waiting for 10000 feet to deepen gravity turn." + latitude.
wait until altitude > 10000.
//lock steering to up + R(0,0,180) + R(0,-65,0).
lock steering to up + R(0,-65,0).


print "Deeper gravity turn." + latitude. 






print "Waiting for apo > 100000.".
wait until apoapsis > 100000.
lock throttle to 0.


lock steering to prograde.
print "Waiting for circularization burn." + latitude.


wait until altitude > 45000.
set warp to 2.
wait until altitude > 60500.
set warp to 3.


wait until eta:apoapsis < 40.
set warp to 0.


wait until eta:apoapsis < 10.
lock throttle to 1.
print "Burn.".




wait until periapsis + apoapsis > 199000.
lock steering to prograde.
lock throttle to 0.
wait 0.1.
print "Burn done.".


}.

[GabeTeuton]

I don't have anything specific to point out in the flowchart two posts ago, but I'm wondering if you are looking at enough variables.

Notably, that flowchart behaves no differently if you are 15m or 1500m above 5000m altitude.

While it is only vaguely similar, I had to include that in the math for my vertical velocity mod. (I was controlling engine thrust to change vertical speed as compared to you adjusting pitch to change vertical speed.)

How fine control do you have? Can you do something like:

Desired vertical speed = (Desired altitude - Vessel altitude)/2; //so desired speed is half the distance to target, negative if above target, positive if below

If(Current Vertical Speed > Desired Vert Speed) then Pitch Down;

If(Current Vertical Speed < Desired Vert Speed) then Pitch Up;

That way as you approach 5000m, the desired speed will decrease automatically and you should damp out any sort of bounce going on from blowing past 5000m at a full 10m/s.

You would have to add a maximum as well, without it if you are really far off, the code above would not stop trying to pitch down until you were pointing straight down.

D.

Very interesting way of setting that, quite compact... I like it...

Why haven't you tried just putting all the conditions in the same loop in one large if/else ladder?

until false {
if altitude < 5000 {
if verticalspeed < 10 {
// do stuff here.
}
} else if altitude > 5000 {
if verticalspeed > 10 {
// do stuff here.
}
} else { // it's exactly 5000, which seems unlikely as it will always be something like 5000.0001 or 4999.9999
// do stuff here.
}
}.

But in general, I think your algorithm is too dependent on boolean conditions and should depend on mathematical continuous sliding scales.

For example, instead of using "if below 5000" and "if above 5000", just calculate this:

SET desiredAlt to 5000.

LOCK altitudeDiff TO (ship:altitude - desiredAlt).

Now if your altitude is above 5000, altitudeDiff is positive, else it's negative, AND the size of altitudeDiff tells you just how far off you are from 5000.

Which you can then use to decide how strong to set your vertical climb to. The farther off you are from 5000, the steeper your ascent or descend should be. Since you have this in a number, you can set it by math, again, like so:

// Lock neededVSpeed to a bigger number the farther off the altitude is, up to a maximum of 20 m/s

LOCK neededVSpeed TO ( - MAX(altitudeDiff/500,20) ).

Now you've got a neededVSpeed that is telling you how much vertical speed you need, and its sign tells you in which direction you need it.

Etc, etc…

I didn't know you could use more than 1 else, i thought it was locked to one else per if, very good... I'm going to search more about MAX in the wiki, as it seems quite useful!

---------------------------------------------------------------------------------------------------------------------------------------

Both ideas are really good, i guess i lack a sense of logic (in order to simplify things a lot) you guys have... I'll try to implement what i learned, maybe even try to merge both ideas !!

Thank you!

[Dunbaratu]

I didn't know you could use more than 1 else, i thought it was locked to one else per if, very good... I'm going to search more about MAX in the wiki, as it seems quite useful!

Stop. Using. The. Wiki.

http://ksp-kos.github.io/KOS_DOC/command/math/index.html

[GabeTeuton]

Stop. Using. The. Wiki.

http://ksp-kos.github.io/KOS_DOC/command/math/index.html

I meant that by the wiki haha, github calls it wiki, or the wiki in github is that one, haha, besides the other wiki it's not as well explained as this one from github... i guess instead of wiki i'll call it documentation from now on!

[VFB1210]

Okay, so suspending the initialization issue for the moment since it isn't a huge issue right now, I have another question. My current project is called AAVNAP, or Advanced AVionics and Navigation Algorithm Package. The goal is to create a fly-by-wire and autopilot system for the KSO super25 shuttle. As of right now, the shuttle is unusable because with FAR the controls are too finnicky to be able to control without computer intervention, but at speeds over anout 170 m/s, SAS causes the control surfaces to twitch violently and generate so much fake thrust that the shuttle quickly falls apart. Thus, my own system is needed.

Currently, the only plan is for fly-by-wire capabilities, in which the computer takes control of the shuttle to keep it stable, while looking to user commands to determine what the shuttle should be doing. I plan to develop full autopilot capabilities in the future, but crawling before walking &c.

My current dilemma is this: kOS locks out user controls while it is in control of the vehicle. This is a feature I want, because I do not want the pilot controlling the vehicle directly, I want the computer to control it according to the pilot's commands. What I want to know is, how can I get kOS to recognize that the pilot is commanding say, a left roll using the Q key, so that it may manipulate the controls to actually make the vehicle perform the maneuver? As far as I know, there is no way to make kOS respond to keypresses. (or even commands entered into the console.) So how may I accomplish this?

[Dunbaratu]

As far as I know, there is no way to make kOS respond to keypresses. (or even commands entered into the console.) So how may I accomplish this?

That is correct, unfortunately. Fixing it is all tied up with the remote-ablity of the terminal, however, since KSP is inherently using gui event-driven styles of input and the terminal through which input should come should be using a stream-based style of input.

Fixing it involves writing a bridge between the gui event-driven input and an input stream for the terminal to read. This is all pie-in-the-sky stuff at the moment.

[Drew Kerman]

As far as I know, there is no way to make kOS respond to keypresses. (or even commands entered into the console.) So how may I accomplish this?

You're only option right now are Action Groups (0-9)

[VFB1210]

That could be a possibility. I have action groups extended installed, and I believe that allows me to map my own keys to action groups. I could use the action groups for input and AGX to bind them to the appropriate keys.

[Cairan]

The reason why an IFNDEF is useful is that for many data types, there is no such thing as an impossible value that doesn't actually ever happen in normal operations.

You need to be able to tell the difference between "this number is zero because it was never defined" from "this number is zero because it was SET to zero."

IMO, an IFNDEF would be a useful thing to add to kOS.

In the meantime, you can also set a variable to some specific value which you would normally not encounter... In my field of work, we log offscale high or offscale low with -9999 and 9999 on dataloggers...

[Dunbaratu]

That could be a possibility. I have action groups extended installed, and I believe that allows me to map my own keys to action groups. I could use the action groups for input and AGX to bind them to the appropriate keys.

Action Groups Extended uses a different API than stock action groups use. kOS does not currently support it, but as I understand it, Erendrake and Diazo are working on adding support. I'd expect action groups extended support to come to kOS a lot sooner than proper input support. Supporting Action Groups Extended doesn't require that all of the terminal system be altered. Input support sort of does.

[VFB1210]

Well I'm away from my computer right now, so I can't test it, but I seem to remember that it was possible through AGX to bind keys to the default 10 action groups, which kOS can access, correct? So the mapping would look something like the following:

AGX Mappings:
W->ag1
A->ag2
S->ag3
D->ag4
Q->ag5
E->ag6

and then kOS would interpret the activation of ag1 as a pitch down command, ag2 would be yaw left, etc. But then again, maybe I'm just remembering incorrectly, and should find some other way to passify myself for the time being.

EDIT: Or maybe it could simply be done through the game's settings panel, or even an AutoHotKey script in an extreme case. Though I think an AutoHotKey script may be preferable to locking WASDQE to action groups in game, at least AutoHotKey scripts can be disabled with ease.

Edited November 3, 2014 by VFB1210

[Diazo]

AGX Dev here.

As things currently stand with the currently released versions of kOS and AGX, if you bind a key that kOS locks out to action groups 1 through 10 in AGX, AGX will toggle that action group as expected and so trigger kOS's "ON AG1" logic.

I will also confirm that I'm talking with Erendrake to see if AGX and kOS can work together to allow more action groups (so AG11 and up). However, we are still at the initial stage of seeing if we can even get our mods talking to one another so I'm not going to promise anything (including the possibility it does not happen if we can't get things working), and certainly not going to take any sort of guess at any sort of release date even if we can.

D.

[VFB1210]

Well, it looks like I have the solution to that issue then! Glad to see that you and erendrake are talking. Hopefully you can get AGX and kOS to work together, that alone would create a lot of potential for complicated user controlled scripts.

[GabeTeuton]

Once again i need help in diagnosing the problem... I implemented the new things i learnt from you guys, but as one single coded block, it didn't work, so i thought i could kind of "debug" the software by removing the clause that locks the relevant variable to the ship pitch, and just let the program run and print what it does, without actually managing the airplane, so i could change the situation by controlling the plane, and see what the program would do... it worked (the idea of debuging it, if debug is the word to what i'm trying to mean)...

Though the program was not doing what i meant... so i decided to test it by condition, so once the first condition worked, then the other ones should be easy based on the first one... so far, so good... now the first condition doesn't work, but as far as i can read in the code, it should work... so i need help identifying what's wrong...

CLEARSCREEN.
SET DESIREDALT TO 5000. // desired altitude setting
LOCK ALTDIF TO (SHIP:ALTITUDE - DESIREDALT). // altdif setting
LOCK NEEDEDVS TO ( - MIN(ALTDIF/250,20)). // needed vs setting, i changed from MAX to MIN, because using MAX, it would always use 20, instead if it's MIN, it will adjust slowly until it hits 20, though it never did.
SET P TO 0. // i noticed that if i set p to anything else than 0, the clause set p to p + X, won't work, if it's in 0, it will work, i need further testing on this, but if set to 0 it works, so this is not a problem.

WHEN AG6 = TRUE THEN {                                             // this is set as so, because if i use "until false" it won't go to the next until false until this one is false, this way works pretty well... (anyhow i'll hear suggestions, though this is not 
    PRINT "DESIRED ALTITUDE= " + DESIREDALT AT (0,0).    // an issue so far
    PRINT "ALTITUDE DIFF= " + ALTDIF AT (0,1).
    PRINT "CURRENT ALTITUDE= " + ALTITUDE AT (0,2).
    PRINT "VERTICAL SPEED= " + VERTICALSPEED AT (0,6).
    PRINT "NEEDED VERT SPEED= " + NEEDEDVS AT (0,7).
    PRINT "CURRENT P= " + P AT (0,8).
    PRESERVE.
}.

UNTIL FALSE {
    IF ALTDIF < 0 {                                                                        // if altdif is negative then
        IF VERTICALSPEED < NEEDEDVS {                                            // if vertical speed is less than the neededvs
            UNTIL VERTICALSPEED = NEEDEDVS { SET P TO P + 0.00001.   // until both are the same, add 0.00001 to P
            WAIT 0.001.                                                                    // without this p would stay in 0.00001 rather than keep adding 0.00001
            IF P < 0 {SET P TO 0.}.}.                                                  // this is supposed to set p to 0 if for instance this clause started to work after the following one, so instead of going all the way to positive, it starts from 0.
            }
        IF VERTICALSPEED > NEEDEDVS {                                            // same as before but inverted, the thing is, this doesn't work, it will keep adding 0.0001 to p regardless of if it's less or more than neededvs************
            UNTIL VERTICALSPEED = NEEDEDVS { SET P TO P - 0.00001.
            WAIT 0.001.
            IF P > 0 {SET P TO 0.}.}.
            }
    } ELSE {SET P TO 0.}.                                                              // just for completeness, i'm testing this condition always under 5000, so it shouldn't matter
 }.

So the problem is what i explained in the ***************, it never checks if that is true or false, so it doesn't do what it's supposed to, if ALTDIF is negative, it assumes verticalspeed is always < neededvs, in other words it never susbstracts 0.0001 from p.- Ideas???

(i hope i made the problem clear)

Thank you as always...

[Trewor007]

Is there a way to set multiple things to one number? so i don't have to write it like so:

set a to 0. set b to 0. set c to 0.

but something like this:

 set a, b, c, to 0 

[madlemur]

I agree it's nice to get these values "magically" (I really, really appreciate it when it comes to fine tuning control algorithms), but as another poster mentionned, in RealLife, you often can not, except in post-flight analysis, determine where the centers of lift and drag are located, specially when it comes to "real" aerodynamics... STS-1 was an humbling mission as Columbia didn't quite behave like it was modelled to, Young and Crippen had to take control to limit side slip on the first S-turn...

As for integrating Ferram's FAR or NEAR, maybe it would be easier instead of modifying the kOS code to make a standalone module which would augment the atmospheric sensor parts (nosecone, among others) with all these magic values, by using ModuleManager? Then you could hook from kOS by calling SENSOR:READOUT... to read the values... wouldn't that work?

Actually, I believe those are Coefficients of Lift, Drag and Mass, since they are all floats, not vectors...

[Diazo]

@GabeTeuton: A couple thoughts.

First, I don't know kOS script but:

 UNTIL VERTICALSPEED = NEEDEDVS { SET P TO P + 0.00001. 

Is this not missing a closing } bracket? 0.00001}.

Second, I don't like that

IF P < 0 {SET P TO 0.}.}. 

line. It would have to be one very well designed plane at a specific speed for a perfectly level flight to equal no vertical movement.

However, I can't actually see anything wrong with the script so no other suggestions.

D.

[madlemur]

@GabeTeuton:

CLEARSCREEN.
SET DESIREDALT TO 5000. // desired altitude setting
LOCK ALTDIF TO (SHIP:ALTITUDE - DESIREDALT). // Positive means you're too high. Negative means you're too low.
LOCK NEEDEDVS TO MIN(ABS(ALTDIF/250), 20). // This is just the magnitude of the desired vertical speed you want.
SET P TO 0. // Initial trim/correction is 0.

WHEN AG6 = TRUE THEN {                                             // this is set as so, because if i use "until false" it won't go to the next until false until this one is false, this way works pretty well... (anyhow i'll hear suggestions, though this is not 
    PRINT "DESIRED ALTITUDE= " + DESIREDALT AT (0,0).    // an issue so far
    PRINT "ALTITUDE DIFF= " + ALTDIF AT (0,1).
    PRINT "CURRENT ALTITUDE= " + ALTITUDE AT (0,2).
    PRINT "VERTICAL SPEED= " + VERTICALSPEED AT (0,6).
    PRINT "NEEDED VERT SPEED= " + NEEDEDVS AT (0,7).
    PRINT "CURRENT P= " + P AT (0,8).
    PRESERVE.
}.

UNTIL FALSE {
  IF ALTDIF < 0 { // Too low, need to climb
    IF VERTICALSPEED < NEEDEDVS { // Nose up
      SET P TO P + (MIN(NEEDEDVS - VERTICALSPEED, 100) / 100).
    } ELSE IF VERTICALSPEED > NEEDEDVS { // Nose down
      SET P TO P - (MIN(VERTICALSPEED - NEEDEDVS, 100) / 100).
    }.
  } ELSE IF ALTDIF > 0 { // Too high, need to descend
    IF VERTICALSPEED > -NEEDEDVS { // Nose down
      SET P TO P - (MAX(VERTICALSPEED + NEEDEDVS, 100) / 100).
    } ELSE IF VERTICALSPEED < -NEEDEDVS { // Nose up
      SET P TO P + (MAX(-NEEDEDVS - VERTICALSPEED, 100)/100).
    }.
  }.
  // Do something with P. I assume it will get folded into the pitch controls.
  WAIT 0.001.
}.

Edited November 3, 2014 by madlemur
Added some linear smoothing of the adjustment value. Could also try a trig or log function to tweak more.

[GabeTeuton]

@GabeTeuton: A couple thoughts.

First, I don't know kOS script but:

 UNTIL VERTICALSPEED = NEEDEDVS { SET P TO P + 0.00001. 

Is this not missing a closing } bracket? 0.00001}.

Second, I don't like that

IF P < 0 {SET P TO 0.}.}. 

line. It would have to be one very well designed plane at a specific speed for a perfectly level flight to equal no vertical movement.

However, I can't actually see anything wrong with the script so no other suggestions.

D.

 IF VERTICALSPEED < NEEDEDVS {                                            // if vertical speed is less than the neededvs
            UNTIL VERTICALSPEED = NEEDEDVS { SET P TO P + 0.00001.   // until both are the same, add 0.00001 to P
            WAIT 0.001.                                                                    // without this p would stay in 0.00001 rather than keep adding 0.00001
            IF P < 0 {SET P TO 0.}.[I][U][B]}.[/B][/U][/I]                                                  // this is supposed to set p to 0 if for instance this clause started to work after the following one, so instead of going all the way to positive, it starts from 0.
            } 

this one is the closing bracket for this bunch

in regards to the second, level flight means no vertical altitude change, in other words vertical speed = 0, and that is acchieved at certain AoA, which changes with the conditions, i believe every body that "flies", will have an AoA for level flight, as FAR calculates it for every plane... WHAT may change in regards to the design is the purpose of the plane, and whether the plane is desgined with an specific purpuse, for instance a bomber that is designed for 10k meters of cruise altitude, will be designed so the level flight at cruise speed is acchieved with an AoA that is closer to 0 or even 0, so it flights "straigt" into the stream rather than pitching up like most planes designed in ksp, though that's something you can achieve, it's just a matter of designing the airplane for a said altitude and speed, and check the AoA provided by far, then Angle the elevons (control surfaces that are specifically meant to change pitch), until the AoA is 0 for those conditions, and you'll have a plane that at said conditions, will flight "straight" or most likely straight... though you may have problems prior to getting to those conditions, like taking off, landing, climbing, etc...

[GabeTeuton]

@GabeTeuton:

CLEARSCREEN.
SET DESIREDALT TO 5000. // desired altitude setting
LOCK ALTDIF TO (SHIP:ALTITUDE - DESIREDALT). // Positive means you're too high. Negative means you're too low.
LOCK NEEDEDVS TO MIN(ABS(ALTDIF/250), 20). // This is just the magnitude of the desired vertical speed you want.
SET P TO 0. // Initial trim/correction is 0.

WHEN AG6 = TRUE THEN {                                             // this is set as so, because if i use "until false" it won't go to the next until false until this one is false, this way works pretty well... (anyhow i'll hear suggestions, though this is not 
    PRINT "DESIRED ALTITUDE= " + DESIREDALT AT (0,0).    // an issue so far
    PRINT "ALTITUDE DIFF= " + ALTDIF AT (0,1).
    PRINT "CURRENT ALTITUDE= " + ALTITUDE AT (0,2).
    PRINT "VERTICAL SPEED= " + VERTICALSPEED AT (0,6).
    PRINT "NEEDED VERT SPEED= " + NEEDEDVS AT (0,7).
    PRINT "CURRENT P= " + P AT (0,8).
    PRESERVE.
}.

UNTIL FALSE {
  IF ALTDIF < 0 { // Too low, need to climb
    IF VERTICALSPEED < NEEDEDVS { // Nose up
      SET P TO P + 0.001.
    } ELSE IF VERTICALSPEED > NEEDEDVS { // Nose down
      SET P TO P - 0.001.
    }.
  } ELSE IF ALTDIF > 0 { // Too high, need to descend
    IF VERTICALSPEED > -NEEDEDVS { // Nose down
      SET P TO P - 0.001.
    } ELSE IF VERTICALSPEED < -NEEDEDVS { // Nose up
      SET P TO P + 0.001.
    }.
  }.
  // Do something with P. I assume it will get folded into the pitch controls.
  WAIT 0.001.
}.

now i have to leave... but thanks, i'll definately try this and see what happens! Thanks for the suggestions! Still getting used to think as a programmer!

[madlemur]

@GabeTeuton:

The problem with checking for VS = 0 is that VS is a float, and once you get away from 0, it's very, very unlikely you'll get back to it. Not saying it's impossible, but given the number of variable factors (AoA, Throttle setting, thrust generated, CoL:CoM positioning, etc., etc) and the fact that computers will loose accuracy when computing floating point numbers, it's better to assume you will never see a vertical speed of exactly 0.0 once you take off. I've edited my code to (hopefully) include a smoothing function to minimize bounce and oscillation while letting the system make significant changes when needed. Once it gets close to the target altitude, it will still fluctuate, but the changes to the control surfaces should be tiny.

[Hitokiri]

Hi, great work on KOS!

I have one question concerning usage KOS in Space Planes, is it advisable? Is KOS ready for it?

Why I'm asking, I made script that brings my SSTO to orbit, while script worked fine for some planes, it doesn't really worked for other for one reason - during atmospheric flight planes is wobbling on "Roll".

The script looks like this:

clearscreen.
toggle brakes.

lock THROTTLE to 1.
LOCK STEERING TO Heading (90,3).

stage.
print "Lunch!".

wait until surfacespeed > 100.

print "Lift off!".
LOCK STEERING TO Heading (90,10).
wait 5.
toggle GEAR.

LOCK STEERING TO Heading (90,45).

wait until ALTITUDE > 10000.
print "10k!".
LOCK STEERING TO Heading (90,20).
UNLOCK THROTTLE.

wait until eta:apoapsis < 5.

print "Rocket Engines!".
LOCK STEERING TO Heading (90,30).
toggle AG1.
lock THROTTLE to 1.

wait until APOAPSIS > 300000.
lock THROTTLE to 0.

lock steering to prograde.

wait until eta:apoapsis < 10.

set x to apoapsis.
lock THROTTLE to 1.

wait until periapsis > x-500.
lock THROTTLE to 0.

toggle AG10.

stage.
print "Finished!".

The unlocked steering after reaching 10k is there for Mechjeb to control thrust in order to prevent flameout of engines as atmosphere thicker

Anyway the

LOCK STEERING TO Heading (90,20).

is the main issue, plane always start ROLL left right and this cause that it will not keep that 20° of pitch.

So what to do with it?

[Dunbaratu]

the fact that computers will loose accuracy when computing floating point numbers,

While that can be a problem, in this case even if that wasn't happening it's STILL a bad idea for @GabeTeuton to be checking for exactly zero. Because even without the artificial artifact of computer floating point precision problems, in the *real* world you're not going to get the system that accurate.

Gabe, imagine this: you work as a general errand runner and gopher in a chemistry lab where your boss has said, "I'm cooling this down until it's 30 degrees, then we can start. Your instructions are to look at this digital thermometer and tell me when it says the temperature is exactly 30 degrees." You say "okay, will do!"

Then you look at it and it says 35.21301.. then 34.2411... then 32.21623.. then 31.01835, then 30.51821, then 30.201262, then 30.013011, then 30.003151, then 30.000045, then 30.00010, then 29.99912, then 29.999941. then 30.00004, then 29.999910. then 30.00004, then 30.000012, then 29.99919.... etc.

At what point should you say "okay that's close enough to 30 degrees that it counts? It's clearly unable to hold it at exactly 30 to more than about 0.001 accuracy."?

This is the problem with what you're doing. Even in the real world an autopilot cannot possibly get the climb rate as accurate as you're looking for here. It will inevitibly waver a bit above and below the desired number. Your job is to ensure that it wavers around that point by as small a margin as possible, not to do the impossible and make it stick to it so precisely that it's accurate up to 12 significant digits. That's utterly impossible.