kOS Scriptable Autopilot System 0.9

Camacha · December 17, 2013

I have had a number of quasi lockups that seem to be related to kOS not having a target, or the vehicle itself being targeted. The screen goes black, although the interface is still visible, and the altimeter shows the same number on all digits, going through 0-9 repeatedly.

Once I found out what seemed to cause it, I could work around it, although kOS sometimes seems to lose its target randomly.

So, supposedly KSP 0.23 is going to appear real soon now. With Kevin still gone are there any ideas about what to do about the 0.23 update? I'm going to save off a snapshot of my 0.22 game now just in case there's compatibility problems with 0.23 that could take a very long time to fix without the project admin around.

Chances are nothing needs to be done, since 0.23 supposedly does not have big changes under the hood.

razark · December 17, 2013

I think that with Kevin missing for a month and a half and a new KSP version, it's probably time for someone to take over and create a new version. IIRC, the license allows this.

John F. Kerman · December 17, 2013

Well, if someone does, I have a couple of feature requests:

The 10kb limit on the craft harddrive is too low for what I want to do - after browsing the github sources it seems this is a hardcoded value & should be simple enough to change.. but: is it an arbitrary limit or is there a reason for this? If it's arbitrary, it'd be nice to have this as a setting in the part files (you could keep the 10k limit for the 'stock' computer & have additional parts with more space). I'd make this change myself if I knew anything about the part file formats...

Support for commandline arguments would be useful as well (simple DOS batch script style %1, %2 etc would be fine). For example, "run hover <altitude>." to run a script that makes a craft hover at <altitude>. I can work around this by using ag1/ag2 to increment / decrement a variable but it's just more code space that could be used for more important things.

Oh, and here's a work in progress script that might help people out. (this one is over the 10k limit, but you can delete the animation stuff to run it). Disclaimer: Most of the actual hovering stuff isn't working yet, and I can't remember if this version has the correct mass / acceleration calculations or not


print " =============================================== " at (0,0).
print "| Hover Testbed v0.1                            |" at (0,1).
print " =============================================== " at (0,2).
print "|                                               |" at (0,3).
print "|     Speed :                                   |" at (0,4).
print "|  Altitude :                                   |" at (0,5).
print "| VertSpeed :                                   |" at (0,6).
print "| Direction :                                   |" at (0,7).
print "|      ProG :                                   |" at (0,8).
print "|    RetroG :                                   |" at (0,9).
print "|      Mass :                                   |" at (0,10).
print "|    Thrust :                                   |" at (0,11).
print "|  Throttle :                                   |" at (0,12).
print "|       TWR :                                   |" at (0,13).
print "|                                               |" at (0,14).
print "|                                               |" at (0,15).
print "| Mode:                                         |" at (0,16).
print "| Target Height:                                |" at (0,17).
print "|                                               |" at (0,18).
print "| Hovering over                                 |" at (0,19).
print " =============================================== " at (0,20).
print "= +==+  +==========+                            =" at (0,21).
print "= |  |  |        |                            =" at (0,22).
print "= +==+  |          |                            =" at (0,23).
print "=       |       (: |                            =" at (0,24).
print "=       +==========+                            =" at (0,25).
print "=                                               =" at (0,26).
print "= 1 - Increase Target Height                    =" at (0,27).
print "= 2 - Decrease Target Height                    =" at (0,28).
print "= 3 - Change Mode                               =" at (0,29).
print "= 4 - Animation test                            =" at (0,30).
print "= 5 - End Testbed                               =" at (0,31).
print "= ====================   ====================== =" at (0,32).
print "= ActionPress: .      = =                       =" at (0,33).
print "=                      =                        =" at (0,34).
print " =============================================== " at (0,35).

print body at (16,19).
set targetheight to 0. print targetheight + "m " at (16,17).

set done to false.
set actionPressed to 0.
set keypressed to false.
set frameupdate to 0.
set framerate to 2.
set animframe to 0.
set mode to 0.

lock surfaceVec to velocity:surface.
lock speedx to (surfaceVec:x * surfaceVec:x).
lock speedy to (surfaceVec:y * surfaceVec:y).
lock speedz to (surfaceVec:z * surfaceVec:z).
set speed to sqrt(speedx + speedy + speedz).
lock height to altitude.

lock vertSpeed to verticalspeed.
lock craftDir to steering.

set tbThrottle to 0.
lock throttle to tbThrottle.
set animate to false.

set speedLastFrame to speed.
set heightLastFrame to height.
set ascending to false.
set timeLastFrame to 0.
set acceleration to 0.

until done
{
    set deltaTime to time - timeLastFrame.

    set speed to sqrt(speedx + speedy + speedz).

    set deltaHeight to height - heightLastFrame.   
    if deltaHeight < 0
    {
        set speed to 0 - speed.
    }.

    set deltaSpeed to speed - speedLastFrame.
    set speedLastFrame to speed.

    if deltaTime > 0
    {
        set acceleration to deltaSpeed / deltaTime.
    }.

    print speed + "   " at (13,4).
    print height + "   " at(13,5).
    print vertSpeed + "   " at (13,6).
    print craftDir + "   " at(13,7).
    print prograde + "    " at(13,8).
    print retrograde + "   " at(13,9).   
    print mass + "   " at (13,10).
    print maxthrust + "   " at (13,11).
    print tbThrottle + "   " at (13,12).
    print maxthrust / (mass * 1000) + "   " at (13,13).
    print time + "   " at (13,14).
    print acceleration + "   " at (13,14).

    if (mode = 0)
    {
        print "Basic                  " at (7,16).
        if targetheight > height
        {
            set tbThrottle to 1.
        }.

        if targetheight < height
        {
            set tbThrottle to 0.
        }.
    }.

    if (mode = 1)
    {
        print "Not implemented        " at (7,16).
    }.

    if (mode = 2)
    {
        print "Not implemented        " at (7,16).
    }.

    set speedLastFrame to speed.
    set heightLastFrame to height.

    if animate
    {
        if animframe = 0
        {
            print "| Animation test            ===     ===     === |" at (0,16).
            print "|    =  =    =  =    =         =   =   =   =   =|" at (0,17).
            print "|=  =    =  =    =  =          =   =   =   =   =|" at (0,18).
            print "| ==      ==      ==            ===     ===     |" at (0,19).
        }.

        if animframe = 1
        {
            print "| Animation test=           ==     ===     ===  |" at (0,16).
            print "|=    =  =    =  =            =   =   =   =   = |" at (0,17).
            print "| =  =    =  =    =  =        =   =   =   =   = |" at (0,18).
            print "|  ==      ==      ==          ===     ===     =|" at (0,19).
        }.

        if animframe = 2
        {
            print "|=Animation test==          =     ===     ===   |" at (0,16).
            print "| =    =  =    =  =          =   =   =   =   =  |" at (0,17).
            print "|  =  =    =  =    =         =   =   =   =   =  |" at (0,18).
            print "|   ==      ==      ==        ===     ===     ==|" at (0,19).
        }.

        if animframe = 3
        {
            print "|=Animation test ==              ===     ===    |" at (0,16).
            print "|  =    =  =    =  =        =   =   =   =   =   |" at (0,17).
            print "|   =  =    =  =    =       =   =   =   =   =   |" at (0,18).
            print "|    ==      ==      =       ===     ===     ===|" at (0,19).
        }.

        if animframe = 4
        {
            print "| Animation test  ==            ===     ===     |" at (0,16).
            print "|=  =    =  =    =  =          =   =   =   =   =|" at (0,17).
            print "|    =  =    =  =    =         =   =   =   =   =|" at (0,18).
            print "|     ==      ==            ===     ===     === |" at (0,19).
        }.

        if animframe = 5
        {
            print "| Animation test   ==          ===     ===     =|" at (0,16).
            print "| =  =    =  =    =  =        =   =   =   =   = |" at (0,17).
            print "|=    =  =    =  =            =   =   =   =   = |" at (0,18).
            print "|      ==      ==           ==     ===     ===  |" at (0,19).
        }.

        if animframe = 6
        {
            print "| Animation test    ==        ===     ===     ==|" at (0,16).
            print "|  =  =    =  =    =         =   =   =   =   =  |" at (0,17).
            print "| =    =  =    =  =          =   =   =   =   =  |" at (0,18).
            print "|=      ==      ==          =     ===     ===   |" at (0,19).
        }.

        if animframe = 7
        {
            print "| Animation test     =       ===     ===     ===|" at (0,16).
            print "|   =  =    =  =    =       =   =   =   =   =   |" at (0,17).
            print "|  =    =  =    =  =        =   =   =   =   =   |" at (0,18).
            print "|==      ==      ==              ===     ===    |" at (0,19).
        }.

        if animframe = 8
        {
            print "| Animation test            ===     ===     === |" at (0,16).
            print "|    =  =    =  =    =         =   =   =   =   =|" at (0,17).
            print "|=  =    =  =    =  =          =   =   =   =   =|" at (0,18).
            print "| ==      ==      ==            ===     ===     |" at (0,19).
            set animframe to 0.
        }.
    }.

    print " " at (15,33).

    if ag1
    {
        print "1" at (15,33).
        set actionPressed to 1.
        set ag1 to false.
        set keypressed to true.
    }.

    if ag2
    {
        print "2" at (15,33).
        set actionPressed to 2.
        set ag2 to false.
        set keypressed to true.
    }.

    if ag3
    {
        print "3" at (15,33).
        set actionPressed to 3.
        set ag3 to false.
        set keypressed to true.
    }.

    if ag4
    {
        print "4" at (15,33).
        set actionPressed to 4.
        set ag4 to false.
        set keypressed to true.
    }.

    if ag5
    {
        print "5" at (15,33).
        set actionPressed to 5.
        set ag5 to false.
        set keypressed to true.
    }.

    if keypressed
    {
        if actionPressed = 5
        {
            set done to true.
        }.

        if (actionPressed = 1)
        {
            set targetheight to targetheight + 50.
            if targetheight > 1000
            {
                set targetheight to 1000.
            }.

            print targetheight + "m " at (16,17).
        }.

        if (actionPressed = 2)
        {
            set targetheight to targetheight - 50.
            if targetheight < 0
            {
                set targetheight to 0.
            }.
            print targetheight + "m " at (16,17).
        }.

        if (actionPressed = 3)
        {
            set mode to mode + 1.
            if mode = 3
            {
                set mode to 0.
            }.
        }.

        if (actionPressed = 4)
        {
            if animate
            {
                print "| Mode:                                         |" at (0,16).
                print "| Target Height:                                |" at (0,17).
                print "|                                               |" at (0,18).
                print "| Hovering over                                 |" at (0,19).
            }.

            toggle animate.
        }.

        set actionpressed to 0.
        set keypressed to false.
    }.

    if frameupdate = framerate
    {
        set frameupdate to 0.
        set animframe to animframe + 1.
    }.

    set frameupdate to frameupdate + 1.
    set timeLastFrame to time.
}.

Edited December 17, 2013 by John F. Kerman
quotes don't work for code!

Sma · December 17, 2013

Well, if someone does, I have a couple of feature requests:
The 10kb limit on the craft harddrive is too low for what I want to do - after browsing the github sources it seems this is a hardcoded value & should be simple enough to change.. but: is it an arbitrary limit or is there a reason for this? If it's arbitrary, it'd be nice to have this as a setting in the part files (you could keep the 10k limit for the 'stock' computer & have additional parts with more space). I'd make this change myself if I knew anything about the part file formats...
Support for commandline arguments would be useful as well (simple DOS batch script style %1, %2 etc would be fine). For example, "run hover <altitude>." to run a script that makes a craft hover at <altitude>. I can work around this by using ag1/ag2 to increment / decrement a variable but it's just more code space that could be used for more important things.

Kevin is/was planning on adding different parts that would have faster processing and more storage space (at the cost of more power).

As for command line arguments, you can use a parameter to sort of accomplish what you mentioned:


run launch(100000,90000)

[code]
declare parameter altAp.
declare parameter altPe.

lock throttle to 1.
sas on.
stage.
wait 10.
sas off.
lock steering to heading 90 by 90.
wait until altitude > 10000.
lock steering to heading 90 by 45.
sas off.
wait until altitude > altAp - 30000.
lock steering to heading 90 by 20.
wait until apoapsis > altAp.
lock throttle to 0.
wait until eta:apoapsis < 15.
lock throttle to 1.
wait until periapsis > altPe.
lock throttle to 0.
unlock all.
sas on.
panels on.

Just a simple/off the top of my head way of doing it.

Sma · December 17, 2013

So, supposedly KSP 0.23 is going to appear real soon now. With Kevin still gone are there any ideas about what to do about the 0.23 update? I'm going to save off a snapshot of my 0.22 game now just in case there's compatibility problems with 0.23 that could take a very long time to fix without the project admin around.

Making a backup copy of your current game is always a good idea anyway with new updates, just in case mods get broken. Fingers crossed though that mods still work after tomorrow.

John FX · December 17, 2013

Although you already got one solution it can't hurt to have more tools in your toolbox of solutions, so here's another technique that works to find your radial-in direction without much math: Use a maneuver node to find it, like so:

1 - Make a dummy maneuver node at the point where your periapsis would be if you didn't burn, with a delta-V of -1,0,0.

2 - Add it to the flight plan.

3 - Read the delta-V vector of it.

4 - Remove the node from the flight plan. It served its purpose which was just to tell you which way to burn.

5 - Use the delta-V vector from step 3 as your steering direction.

Code would look like this:


set dummyNode to NODE( time:seconds+ETA:periapsis, (-1), 0, 0 ).
add dummyNode.
set radUnitVec to dummyNode:DELTAV.
remove dummyNode.
// "radUnitVec" is now a unit vector pointing in your radial-in direction.  You can steer by it:
lock steering to radDir.

What this does is that instead of a slowly rotating burn that turns as your velocity vector rotates, it will point you at what the radial in direction *will be* at periapsis rather than which way it is right now, and it has you burn in a straight line that way, as shown below in direction 2:


KEY:
@@ = where your ship is now.
1 = Direction of radial-in now.
2 = Direction of radial-in later at periapsis.


                                .....
                            ..@@_____\ 2.
                         ...   \     /                   
                       ..       \ |        
                     ::        __\| 
                   ::             1.        
                  :                 ****
                 :               **********
               Pe______\        ************
                :      /        ************
                 :               **********
                  :                 ****
                   ::                      
                     ::
                       ..  
                         ...
                            ....
                                .....

Nice one. I like simple solutions like this for complex problems. I like the way it gives me radial in for any point on my orbit also.

cm2227 · December 17, 2013

You know what would be great? Accessing kOS via remote terminal. I don't mean RemoteTech, I mean having a second PC (over LAN or internet) and logging in to the kOS unit on the craft (like Telemachus). That way you could use for example your laptop as a realistic way to access and display your guidance computer.

Then I would grab the oldest-looking laptop, view the kOS Terminal full screen and gain seven nerd points.

Edited December 17, 2013 by cm2227

Nakara · December 18, 2013

Anybody knows if this mod works in 0.23?

I've installed it but I'm not able to focus the terminal. (That's the only mod installed) :/

The debug window shows alot of messages complaining about some EditorLogic.Unlock method that cannot be found.

Thanks!

Edited December 18, 2013 by Nakara

MaHuJa · December 18, 2013

messages complaining about some EditorLogic.Unlock method that cannot be found.

I just forked it and tried to compile it, but it doesn't even compile for this version of ksp. However, think I managed to stumble onto a hotfix - both sides of the lock/unlock now want an identifying string. I think I remember a mention in kerbal kon about the bug that was supposed to fix - kOS uses the ship editing "picked up a part" logic to capture game focus. Anyway, I'm about to load up ksp with my own build to test this fix.

Edit1: works beautifully. Now to check the license then stick it in dropbox.

Edit2: GPL makes it simple. Here you go for a working version. Source is the same except adding a string literal for the lock and unlock calls.

https://www.dropbox.com/s/0gmwx6latfb9fth/kOS.dll

Edit3: Pull request added, so whenever he comes back it's only a couple clicks; he won't even have to know what caused the problem.

Edited December 18, 2013 by MaHuJa

Nakara · December 18, 2013

Thanks MaHuJa for this fix

skygunner58203 · December 19, 2013

So this is a really dumb question. I've decided to try this out, and I just can't seem to focus on the terminal. How in the world do you focus on it? I should probably mention that I can make it appear and boot, but it wont let me focus on it.

kiyonisis · December 19, 2013

The new fix works for me - thanks!

However, either I'm having an idiot moment or string comparisons seem to be broken when run inside of a file. For example, trying to run

if STATUS="LANDED" {print "test".}.

used to work, but now I get an error.

MaHuJa · December 19, 2013

Skygunner85203 - the focus functionality broke with .23 so you want the hotfix I provided 2 posts over yours.

Kiyonisis - I'm able to reproduce it; it only seems to happen in an if. As a workaround,

set bol to status="landed".

if bol { print "test". }.

seems to work. Dunno what's causing that problem. You say this broke with .23? Or is this a script you haven't tested in a while, say a previous kOS version?

skygunner58203 · December 19, 2013

Thanks MaHuJa! I was searching for a button to hit and tutorials on google. If I had gone back one page, I'd have seen that. All working now. Now to find new ways to kill off my kerbals

John FX · December 19, 2013

I`ve noticed a change which will affect a few programs. I`m trying to launch but before launch the engines turn on and slowly increase throttle for 7 seconds before launch. time:seconds seems to be actual time not ingame time now.

set x to 10.
set st to time:seconds.
lock ct to (time:seconds-st-5).	
until x=0 {
	Print "T-"+ x +" " at (0,0).
	wait 1.
	if x=0 {
		print "Main Engine Ignition" at (0,1).
		stage.
	}.
	if ct<0 {set ct to 0.}.
	lock throttle to ct/7.
	set x to x-1.
}.
lock throttle to 1.
print "Liftoff".
stage.

I am wanting ct to start at T-7 at 0 and be at 7 at t-0 by locking it to the time:seconds which should be in-game time and that is what it was pre 0.23 but now it is actual time, which puts things out of whack as the game runs slower than realtime especially on the pad.

I`ll lock it to missiontime for now but I thought I would let you know.

I will try this


set x to 10.
lock ct to (missiontime:seconds).	
until x=0 {
	Print "T-"+ x +" " at (0,0).
	if x=7 {
		print "Main Engine Ignition" at (0,1).
		stage.
	}.
	lock throttle to ct/7.
	set x to x-1.
	wait 1.
}.

Ok that fails because missiontime does not start until you actually liftoff...

Anyone know a way of getting the ingame time in 0.23? I`ll have to set up microloops/waits to increment the throttle otherwise which is not my preferred solution.

I have ended u using this. Not perfect.


set x to 10.
set tog to 0.
set count to 0.
lock throttle to ((7-(x+count))/7).
until x=0 {
	Print "T-"+ x +" " at (0,0).
	if x=6 {
		print "Main Engine Ignition" at (0,1).
		stage.
		set tog to 1.
	}.
	if tog=0 {wait 1.}.
	if tog=1 {
		set count to 0.9.
		until count<=0 {
			set count to count-0.1.
			wait 0.1.
		}.
	}.
	set x to x-1.
}.

Edited December 19, 2013 by John FX

John FX · December 19, 2013

Sorry for the double post

Edited December 19, 2013 by John FX

AeroEngy · December 19, 2013

@John FX

I don't have an answer for you problem on how to get in game time. However, I thought I would share that I am having some odd time problems since the updated. This may or may not be related to the changes you are seeing in game.

It seems for me game time is running at about 1/3 the speed using the same stock rocket (~3 seconds real time for every 1 on the mission clock). The frame rate still seems good and I can pan around the rocket and change views fairly smoothly. The simulation is just running extremely slow for some reason. I delete and reinstalled KSP without mods and it didn't help. This morning I read some threads in the Support forum about similar problems. There were some suggestions about changing the Max Physics Delta Time setting back to 0.1 that I am going to try when I get home. Apparently pre-update the default was 0.1 and now it is 0.04s ... for what it is worth. The game is completely unplayable for me until there is an update or I can find the right setting to tweak.

MaHuJa · December 19, 2013

time:seconds seems to be actual time not ingame time now.

Which, if correct, means the entirety of vanilla ksp is fubar.

The time command is sourced off of KSP's "Planetarium" class, which tracks ingame time.

I don't know the KSP internals very well, but it's not a stretch to assume planet positions/rotations, orbits, maneuver nodes, you name it, it relies on it.

More likely, that magic number bit you.

In the first code sample, you're doing -st-5, and later you lock the throttle to ct/7. This seemed to me like a curious mismatch - You say you want 7 seconds, so is the former magic number (5) the source of your problem?

(If so, it's easy to miss - and keep missing - as long as you're using magic numbers like that. Are you very low on storage space?)

Wait, on the other hand, is real time. (UnityEngine's deltatime, which I believe is time since last frame was rendered. So the loop will stop dead for a full real second in each iteration.)

John FX · December 19, 2013

Which, if correct, means the entirety of vanilla ksp is fubar.
The time command is sourced off of KSP's "Planetarium" class, which tracks ingame time.
I don't know the KSP internals very well, but it's not a stretch to assume planet positions/rotations, orbits, maneuver nodes, you name it, it relies on it.
More likely, that magic number bit you.
In the first code sample, you're doing -st-5, and later you lock the throttle to ct/7. This seemed to me like a curious mismatch - You say you want 7 seconds, so is the former magic number (5) the source of your problem?
(If so, it's easy to miss - and keep missing - as long as you're using magic numbers like that. Are you very low on storage space?)
Wait, on the other hand, is real time. (UnityEngine's deltatime, which I believe is time since last frame was rendered. So the loop will stop dead for a full real second in each iteration.)

This does seem to be a cause of my problem when combined with the issue in the post above yours. the discrepency between ingame time and realtime. My loop waits for what it thinks is a real second and that takes about 2 seconds of game time and 3 seconds of real time...

EDIT : Have they done some tricksy programming to get more frames between physics ticks which is messing up time?

MaHuJa · December 19, 2013

Coming back and seeing the code again with fresh eyes; That code was never correct in the first place. It's not that it broke ("I`ve noticed a change") but that you couldn't see what was was wrong with it before.

Probably better explained by this page: Programming by coincidence

(It's aimed at professional programmers, for the average kOS user its advice is partially overkill. Heck, we're in the business of killing kerbals with our mistakes, right? :cool: )

OTOH you have two problems:

1) you are assuming realtime and gametime are in sync, which is in my experience rarely the case.

2) wait 1. does NOT wait 1 second, it's 1 second plus however long it takes before it starts the next frame update after that.

To do it correctly*, i suggest you code for a wait random(0.5) . (if random existed) - which is really about prohibiting any form of set x to x-1. (for a time-related value) in favor of something along the lines of set x to floor(time:seconds - st). Match that with a wait 0.1. and all will be well.

EDIT : Have they done some tricksy programming to get more frames between physics ticks which is messing up time?

Usually one would do the opposite. There's no point in drawing the same frame twice (the situation would not have changed), but multiple physics ticks between frames can smooth out problems that occur from big physics steps. For simulations that don't solve the big physics steps by putting things on rails, that can be a pretty big deal.

John FX · December 19, 2013

Coming back and seeing the code again with fresh eyes; That code was never correct in the first place. It's not that it broke ("I`ve noticed a change") but that you couldn't see what was was wrong with it before.
Probably better explained by this page: Programming by coincidence
(It's aimed at professional programmers, for the average kOS user its advice is partially overkill. Heck, we're in the business of killing kerbals with our mistakes, right? )
OTOH you have two problems:
1) you are assuming realtime and gametime are in sync, which is in my experience rarely the case.
2) wait 1. does NOT wait 1 second, it's 1 second plus however long it takes before it starts the next frame update after that.
To do it correctly*, i suggest you code for a wait random(0.5) . (if random existed) - which is really about prohibiting any form of set x to x-1. (for a time-related value) in favor of something along the lines of set x to floor(time:seconds - st). Match that with a wait 0.1. and all will be well.
Usually one would do the opposite. There's no point in drawing the same frame twice (the situation would not have changed), but multiple physics ticks between frames can smooth out problems that occur from big physics steps. For simulations that don't solve the big physics steps by putting things on rails, that can be a pretty big deal.

That is quite possible. When coding this I am learning KOS. What is the correct way to only use the ingame time to, for example, smoothly increase throttle from 0 to 1 over 7 seconds ingame so fuel usage is right?

Is there an ingame as opposed to real world version of time:seconds? EDIT 2: time:seconds IS the ingame time

EDIT : "So the loop will stop dead for a full real second in each iteration" has just sunk in. game time is fine, real time is not matched to that and my code only worked previously by coincidence. So would something like this be better?


sas on.
set x to time:seconds+10.
set tog to 0.
lock throttle to ((7-(x-time:seconds))/7).
until 0 {
	Print "T-"+ (x-time:seconds) +" " at (0,0).
	if x-time:seconds<=7 and tog=0 {
		print "Main Engine Ignition" at (0,1).
		stage.
		set tog to 1.
	}.
	if x-time:seconds<=0 {break.}.
}.
lock throttle to 1.
lock stagefuelmax to stage:liquidfuel.
print " ".
print "Liftoff".
stage.

Yes, that has the behaviour I am looking for. Thank you very much. I`m glad I understand KOS a bit better now and how it treats time.

Edited December 19, 2013 by John FX

AeroEngy · December 20, 2013

Although you already got one solution it can't hurt to have more tools in your toolbox of solutions, so here's another technique that works to find your radial-in direction without much math: Use a maneuver node to find it, like so:

1 - Make a dummy maneuver node at the point where your periapsis would be if you didn't burn, with a delta-V of -1,0,0.

2 - Add it to the flight plan.

3 - Read the delta-V vector of it.

4 - Remove the node from the flight plan. It served its purpose which was just to tell you which way to burn.

5 - Use the delta-V vector from step 3 as your steering direction.

Code would look like this:


set dummyNode to NODE( time:seconds+ETA:periapsis, (-1), 0, 0 ).
add dummyNode.
set radUnitVec to dummyNode:DELTAV.
remove dummyNode.
// "radUnitVec" is now a unit vector pointing in your radial-in direction.  You can steer by it:
lock steering to radDir.

What this does is that instead of a slowly rotating burn that turns as your velocity vector rotates, it will point you at what the radial in direction *will be* at periapsis rather than which way it is right now, and it has you burn in a straight line that way, as shown below in direction 2:


KEY:
@@ = where your ship is now.
1 = Direction of radial-in now.
2 = Direction of radial-in later at periapsis.


                                .....
                            ..@@_____\ 2.
                         ...   \     /                   
                       ..       \ |        
                     ::        __\| 
                   ::             1.        
                  :                 ****
                 :               **********
               Pe______\        ************
                :      /        ************
                 :               **********
                  :                 ****
                   ::                      
                     ::
                       ..  
                         ...
                            ....
                                .....

I think you were just showing how to use dummy nodes to set directions in the future which is very useful. However, this problem got me thinking ... which is dangerous. Anyway I was wondering what the correct thrust direction should be on a hyperbolic flyby like in John FX's example to either raise or lower your periapsis. I generally just use radial in and out but didn't think that it was 100% correct. I knew from doing it in game that it must be pretty close ... so I started deriving equations and putting stuff in Matlab. This is the result. Turns out the optimal direction is perpendicular to your current position vector. Which when really far out is pretty close to the radial in/out directins. When looking at the equations for orbital energy and Rp this makes sense since burning perpendicular to R will have the greatest impact on your angular momentum ... Anyway thought some of you might find it interesting.

Sketch of the test setup I used. Essentially vary the dv thrust angle (beta) and see what causes the largest effect.

Matlab output: Setting R to [5 -50]*KerbinRadius, V to [0 1500], dV magnitude to 100 and varied beta from 0 to 360.

Note the max and min are at 90 & 270 degrees wrt the position vector R.

Edit: Sorry John FX I know this is exactly the opposite no math approach that you originally mentioned ... but I couldn't stop myself.

Edited December 20, 2013 by AeroEngy

Dunbaratu · December 20, 2013

So we've been waiting on Kevin so as not to steal his project away from him while he's sorting other things out, but it looks as if the 0.23 KSP update may be the thing that forces the issue, since kOS 0.92 doesn't work iwth 0.23 KSP. (It's not just a matter of it not compiling the source code, even the precompiled version on Spaceport doesn't work anymore - I'm playing through a new career and the SCS part doesn't show up in the tech tree in 0.23.

MahuJa 's work to make it go in 0.23 is nice but the time may have come to make an official fork and start up a new github page. I would have otherwise preferred to give Kevin more time but the fact that 0.23 requires a recompile sort of makes that nicety impossible.

John FX · December 20, 2013

I think you were just showing how to use dummy nodes to set directions in the future which is very useful. However, this problem got me thinking ... which is dangerous. Anyway I was wondering what the correct thrust direction should be on a hyperbolic flyby like in John FX's example to either raise or lower your periapsis. I generally just use radial in and out but didn't think that it was 100% correct. I knew from doing it in game that it must be pretty close ... so I started deriving equations and putting stuff in Matlab. This is the result. Turns out the optimal direction is perpendicular to your current position vector. Which when really far out is pretty close to the radial in/out directins. When looking at the equations for orbital energy and Rp this makes sense since burning perpendicular to R will have the greatest impact on your angular momentum ... Anyway thought some of you might find it interesting.
Sketch of the test setup I used. Essentially vary the dv thrust angle (beta) and see what causes the largest effect.
http://i.imgur.com/mnvgWEW.png
Matlab output: Setting R to [5 -50]*KerbinRadius, V to [0 1500], dV magnitude to 100 and varied beta from 0 to 360.
Note the max and min are at 90 & 270 degrees wrt the position vector R.
http://i.imgur.com/jkMVf4K.png
Edit: Sorry John FX I know this is exactly the opposite no math approach that you originally mentioned ... but I couldn't stop myself.

So 90 or -90 degrees from up in the plane of surface travel?

Also, I have searched the WIKI and looked on the list of all commands n stuff but cannot find how. Could someone let me know how to print 3.1415926 as 3.142 or 3 or 3.14156

Edited December 20, 2013 by John FX

diomedea · December 20, 2013

Also, I have searched the WIKI and looked on the list of all commands n stuff but cannot find how. Could someone let me know how to print 3.1415926 as 3.142 or 3 or 3.14156

set PI to 3.1415926.

print round(PI,3). // output= 3.142

print round(PI,0). // output= 3

print round(PI,5). // output=3.14159

kOS Scriptable Autopilot System 0.9

Recommended Posts

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites