kOS Scriptable Autopilot System 0.9

[Dunbaratu]

Liking this mod. Thought I would post here my K-prize qualifying run, done completely under kOS control.

It's on SkyDrive - clicky pic below to play.

It's an impressive feat but I can't read any of the text in the terminal in the video. The game was running at high-res, but the video was being captured at low-res, which makes all the writing small and blurred out.

[AbeS]

If anyone is playing with Real Solar System Mod (and FAR obviously) here is an ascent profile I made based on one of asmi's posts! Could be tweaked for Stock Kerbin too

	set Final to 300000.      //Target Orbit
	set t to 0.
	Lock throttle to t.
	set Mach to 343.2.

// Converting from Vector to 'NavBall'
	lock tfv to velocity:surface.

	lock tfA to latitude.

	lock tfuy to up:yaw.
	lock tfB to 0 - tfuy.

	lock tfW to tfv:x*cos(tfB) + 0 + tfv:z*sin(tfB).
	lock tfN to tfv:x*sin(tfA)*sin(tfB) + tfv:y*cos(tfA) + tfv:z*(0-sin(tfA)*cos(tfB)).
	lock tfU to tfv:x*(0-cos(tfA)*sin(tfB)) + tfv:y*sin(tfA) + tfv:z*cos(tfA)*cos(tfB).

	lock tfE to 0 - tfW.

	lock tfradius to (tfe^2 + tfn^2 + tfu^2)^0.5.

	lock incl to arcsin(tfu/tfradius).

// End of conversion, didn't include azimuth because it isn't needed in this program

	set flag to 0.      //You'll know what this is for later

	stage.      // Can be removed, depends on staging, like turning engines on before launchclamps
	set pVal to 90.      //pitch value
	lock steering to heading 90 by pVal.      //90 means East, 0 means North, if you want a different angle change that 90
	Print 3. wait 1.      //Countdown
	Print 2. wait 1.
	Print 1. wait 1.
	set t to 1.
	stage.
	Print "Launch!".

	when tfv:mag >= 60 then {Print "Gravity Turn.". set pVal to 85.}.      //tfv = surface velocity vector
	when tfv:mag >= 160 then {set pVal to 80.}.
	when tfv:mag >= 0.8*Mach then {set pVal to 70.}.
	when tfv:mag >= 1.2*Mach then {
		until incl<=50 {      //Incl obtained from the conversion
			set pVal to incl-5.
		}. 
	}.
	when tfv:mag >=4.5*Mach then {
		until apoapsis >= Final*0.85 {
			set pVal to incl-10.
			if incl<=0 {break.}.
		}.
		lock steering to prograde.
		set t to 0.5.
		set flag to 1.
	}.
	when flag = 1 then {      //Here is the flag's purpose
		wait until apoapsis >= Final.
		set t to 0.
		set flag to 2.
	}.
	when flag = 2 then {
		// Insert Circularization Program Here
		set flag to 3.
	}.
	wait until flag = 3.      // This needs to be here or the program ends in like a second 

The program does not include staging, because there are many different combinations! Make sure to add that or do it manually!

Edited November 11, 2013 by AbeS

[Dunbaratu]

A part of the code looked like this:

	lock tfW to tfv:x*cos(tfB) + 0 + tfv:z*sin(tfB).
	lock tfN to tfv:x*sin(tfA)*sin(tfB) + tfv:y*cos(tfA) + tfv:z*(0-sin(tfA)*cos(tfB)).
	lock tfU to tfv:x*(0-cos(tfA)*sin(tfB)) + tfv:y*sin(tfA) + tfv:z*cos(tfA)*cos(tfB).

Has the bug fix for the problem where you couldn't lock variables that contain capital letters been released on Spaceport yet? Kevin said on github it was fixed but I don't remember there being a Spaceport update since then.

[AbeS]

I didn't really know about that issue, it works perfectly fine and I have the spaceport version

[bsalis]

It's an impressive feat but I can't read any of the text in the terminal in the video. The game was running at high-res, but the video was being captured at low-res, which makes all the writing small and blurred out.

Thanks. It's all blurry from the video compression. I wanted to make sure the video was not too large in size.

If anyone is interested you can have a look at the script here. It's not pretty, but it works fine and can be adapted to other SSTO Spaceplanes. In summary, the sequences are as follows...

Launch and initial Ascent: Launch was just a simple timed sequence. Jet ascent was another simple sequence of small pitch changes based on altitude.

Jet Acceleration: Now things get interesting. From 12Km to the operational ceiling of 24Km, I scaled the pitch to a SIN curve, with an additional 12 degrees. Such that at 24Km, the peak of the curve, I would have 12 degree pitch to hold altitude.

Rocket Ascent and Circularization: This is triggered by fuel quantity. Then some more pitch changes by fuel quantity. Thrust cut when Ap hits 100Km. Circularization burn is triggered by ETA to Ap. Ends when Pe above 99.9Km. Once in orbit I start printing out the distance to KSC each second.

Re-entry: This is triggered upon a certain distance to KSC, but a longitude trigger would have worked just as well. Re-entry burn ends at a specific Pe. I just used a fixed pitch for re-entry, with a small change at 20Km.

Glide Descent: This was the hardest part for me. Beginning at 18Km, i used trigonometry to figure out a glide slope to the KSC runway threshold. Imagine a Right Triangle with the Hypotenuse a direct line from craft to runway. By running this algorithm over and over again, I could work out my deviation above or below the glide slope. I then used a linear scale of the deviation to set pitch (with some other tweaks), so as to hold the craft close to the slope.

As for (yaw) steering to make sure I was lined up with the runway. I just used a linear scale of latitude deviation to set yaw, with a max of 10 degrees and min of 0.1 degrees.

Landing: This sequence starts at 300m, with just holding current pitch, cancelling yaw, and lowering landing gear. At 100m another fixed pitch is used to start slowing vertical descent. Switching to radar altitude, at 20m i used a fixed pitch up to flare for a second. Then used a linear scale to set pitch based upon altitude between 20m and 3.5m. At 3.5m steering was unlocked and brakes turned on.

[Dunbaratu]

Thanks. It's all blurry from the video compression. I wanted to make sure the video was not too large in size.

I'm hitting the same problem right now. I'm trying to edit a narration audio track on top of the video and the cruddy freebie Windows Movie Maker keeps insisting on knocking down the input video quality from 1280x800 to 640x480 regardless of what settings I use.

[Dunbaratu]

An update to my skycrane/lander from before, this time using KOS 0.92:

New things since last time:

• Air pressure and drag taken into account
  
• Parachute database (for air drag calculation)
  
• Speedier loop by moving some things out to lock variables (now that I finally found why locks weren't working before was uppercase letters).
  
• Paranoid behavior that assumes a mountain might spring up in front of it.
  
• Tested on Kerbin, Mun, Duna, Minmus, and Ike with some highTWR craft and some low TWR craft.
  

Things that could be made better using new features of KOS but I haven't done it yet:

(My first goal was just to get it to work and run at all under 0.92 even if it's using methods that 0.92 made obsolete and redundant).

• Sample the air pressure using instruments (right now it calculates it from wiki database information).
  
• Change tfXYZtoENU into a lock expression instead of a subprogram to run each loop iteration.
  
• Add better prediction to the PID control of the throttle so it truly is a real PID controller. (Right now it has problems trying to micro-control the movement of massive landers with low torque that cannot rotate very quickly, as they are always behind in their reactions).
  

But those will probably wait because the next project I'm interested in is a target interceptor. (Select a target craft in orbit around the same SOI body and say "Please park yourself within a distance of X meters from that." and have it fix inclinations, adjust orbit until there's a catch-up, and then match velocities when getting near.) I figure eventually we might have RCS translation thrust available and when we finally do, such a script would be a necessary first step toward docking.

[thox]

I am currently experiencing this:

I don't know if that is a bug or if I'm doing something wrong, but if it is a bug then can it please be fixed soon? And if it isn't can somebody explain how to do it instead?

edit: The print command is only there to demonstrate that 'time + 30' is actually a number, the problem is that the plugin doesn't seem to get that.

Edited November 11, 2013 by thox

[RabbiT_CZ]

Use time:seconds + 30

[AbeS]

Steven how did you get 0.92?

[aNewHope]

Steven how did you get 0.92?

It's out! There's a changelog where you can see the changes. Simply click download from spaceport.

[baloan]

An update to my skycrane/lander from before, this time using KOS 0.92

I like the video.

The altitude issue seems to be a little fuzzy. To make sure the script could orbit over the landing site defined by longitude and latitude and record altitude and alt:radar. Deorbit burn and landing to be done on the next pass - now ground level altitude is known as a fact. This adds aiming for a landing site as a complication, especially if the landing site is not at the equator, though.

[Dunbaratu]

I like the video.

The altitude issue seems to be a little fuzzy. To make sure the script could orbit over the landing site defined by longitude and latitude and record altitude and alt:radar. Deorbit burn and landing to be done on the next pass - now ground level altitude is known as a fact. This adds aiming for a landing site as a complication, especially if the landing site is not at the equator, though.

That would be a good idea except that you can't read radar altitude above about 10,000 m or so. so you can't do it on a world with atmosphere. You'd just get captured on the first pass for being too low.

[Sma]

An update to my skycrane/lander from before, this time using KOS 0.92:

Great video! Shows the potential awesomeness that kOS has. Imagine expanding this just a little more...with a kethane mining rig/convertor.

BTW I like the end of your video. I did something similar when I was in middle school. Got an old camcorder that plugged into a vhs machine, and made a semi stopmotion animation using star trek action figures and a velociraptor toy from Jurassic Park. I think we also had the transport play set, though I thought it lacked special effects so I got an empty jar and put in water and gold glitter, like they apparently did in the Original series. Anyway at the end I added credits that I created using it was either an Atari 1200xl or a C64, cant remember which. I was sad when the rubber drive belt broke on one of them. Was able to switch to a tape drive but that didn't work well either...oh well. I think im done now...before I get even more off topic.

[rpayne88]

I've got a problem. My coding won't save. I'll type and save it, then go into the VAB to tweak the design. When I go back to the launchpad and try to execute the program, it doesn't exist. I wind up having to recode the ship. Right now, I have about 100 lines for each manned ship in three programs: launch to orbit, EDL, and abort. I don't want to be retyping that constantly. Is there any way I could fix this?

[woodywood245]

I've got a problem. My coding won't save. I'll type and save it, then go into the VAB to tweak the design. When I go back to the launchpad and try to execute the program, it doesn't exist. I wind up having to recode the ship. Right now, I have about 100 lines for each manned ship in three programs: launch to orbit, EDL, and abort. I don't want to be retyping that constantly. Is there any way I could fix this?

Maybe this is a stupid question, but have you tried saving your files to the archive?

save filename to archive.

[a1270]

@rpayne88 you'll want to save files to the archive as going back to the VAB creates a new vessel. This also allows you to edit in notepad(++). The archive is located in the Plugins\PluginsData\Archive directory in the main KSP directory. Save scripts as txt files. To switch to the archive you execute "switch to 0." and to switch back to local run "switch to 1.". You can copy files from archive to local by running "copy filename to 1." while on the archive and "copy filename from 0." if you're on the local storage.

[Dunbaratu]

Great video! Shows the potential awesomeness that kOS has. Imagine expanding this just a little more...with a kethane mining rig/convertor.

BTW I like the end of your video. I did something similar when I was in middle school. Got an old camcorder that plugged into a vhs machine, and made a semi stopmotion animation using star trek action figures and a velociraptor toy from Jurassic Park. I think we also had the transport play set, though I thought it lacked special effects so I got an empty jar and put in water and gold glitter, like they apparently did in the Original series. Anyway at the end I added credits that I created using it was either an Atari 1200xl or a C64, cant remember which. I was sad when the rubber drive belt broke on one of them. Was able to switch to a tape drive but that didn't work well either...oh well. I think im done now...before I get even more off topic.

I cheated. I just found a truetype font that looks like a commodore 64, and just used it to mock up that screen in Gimp.

[Dunbaratu]

Steven how did you get 0.92?

The version on Spaceport is 0.92, but the string inside the C# program that reports the version number on the screen didn't get updated and so the terminal window in the game still shows 0.91. This has happened a lot before with KOS mod - with the string showing in the game being behind the version it says it is in spaceport.

[Sma]

I've got a problem. My coding won't save. I'll type and save it, then go into the VAB to tweak the design. When I go back to the launchpad and try to execute the program, it doesn't exist. I wind up having to recode the ship. Right now, I have about 100 lines for each manned ship in three programs: launch to orbit, EDL, and abort. I don't want to be retyping that constantly. Is there any way I could fix this?

As others have said, save to the archive, or, as I do, use an external editor (kOS Win-IDE (for windows) which is syntax highlighted for kOS) and save them to the archive folder (Kerbal Space Program\Plugins\PluginData\Archive).

Then when you get your rocket on the launch pad:

copy *programname from archive.
run *programname.

*programname obviously is whatever name you used for your program.

I cheated. I just found a truetype font that looks like a commodore 64, and just used it to mock up that screen in Gimp.

Lol i guess that works . Not many people still have a c64 laying around. I'm sure if I looked at my parents I could find either the one they had or the one they got me at a garage sale 15-20 years ago (wow...i guess it has almost been that long ago). Who knows if they'd still work though, plus I bet the drive belt in the 1541's has fallen apart by now. I know thats what happened to the atari 1050 drive I had. Even back in the early to mid 90's you couldn't find a replacement belt for it.

[Dunbaratu]

Lol i guess that works . Not many people still have a c64 laying around. I'm sure if I looked at my parents I could find either the one they had or the one they got me at a garage sale 15-20 years ago (wow...i guess it has almost been that long ago). Who knows if they'd still work though, plus I bet the drive belt in the 1541's has fallen apart by now. I know thats what happened to the atari 1050 drive I had. Even back in the early to mid 90's you couldn't find a replacement belt for it.

If you feel a hankerin' for old c64 stuff, these days there are emulators that will run everything on a modern computer.

And yeah the 1541 drive is probably the weakest point in the C64 and most likely to break first. They were considered pretty low quality even back when they came out.

Destroy Him, My Robots.

Anyway, enough old computer nostalgia, back to KOS.

[AbeS]

The version on Spaceport is 0.92, but the string inside the C# program that reports the version number on the screen didn't get updated and so the terminal window in the game still shows 0.91. This has happened a lot before with KOS mod - with the string showing in the game being behind the version it says it is in spaceport.

I was confused because it still says 0.9 in the thread title, didn't know about the updates

[baloan]

I have upgraded the warp script but found something strange. When assigning warp to a variable oldwp and later comparing warp to oldwp kOS throws an error. Not all warp levels are allowed according to this table. You can find out when checking warp which shows the actual warp level. So if you run this script in a 200km orbit you should see level 4 instead of level 6.

declare parameter t1.
// warp    (0:1) (1:5) (2:10) (3:50) (4:100) (5:1000) (6:10000) (7:100000)
// min alt        atmo   atmo   atmo    120k     240k      480k       600k
set dt to t1 - time:seconds.
if dt < 0 {
    print "T+" + round(missiontime) + " Warning: wait time " + round(dt) + " is in the past.".
}
if dt >= 21600 {
    print "T+" + round(missiontime) + " Waiting for " + round(dt/21600) + "d" + mod(round(dt),21600) + "s".
    print "T+" + round(missiontime) + " Wait start @ " + time:calendar + ", " + time:clock.
}
set oldwp to "0".
until time:seconds >= t1 {
    set rt to t1 - time:seconds.       // remaining time
    set wp to 0.
    if rt > 5      { set wp to 1. }
    if rt > 30     { set wp to 2. }
    if rt > 300    { set wp to 3. }
    if rt > 600    { set wp to 4. }
    if rt > 6000   { set wp to 5. }
    if rt > 60000  { set wp to 6. }
    if rt > 600000 { set wp to 7. }
    set warp to wp.
    if warp != oldwp {
        print "T+" + round(missiontime) + " Warp " + warp + ", remaining wait " + round(rt) + "s".
        set oldwp to warp.
    }
    wait 0.5.
}
if dt >= 21600 {
    print "T+" + round(missiontime) + " Wait complete @ " + time:calendar + ", " + time:clock.
}

First time into the loop warp is compared to "0" -> works fine.

Second time into the loop warp is compated to oldpw -> error.

I'd expect to be able to compare oldwp to warp.

Bug or am I missing something?

Note: warpfor calls warpto.

Edited November 12, 2013 by baloan

[Sma]

I've had problems, similar but not exactly....or not at all similar LOL.

I have a formula for figuring out the orbital period. Originally I was using it to tell if node had a specific orbital period, and if not add/subtract from the node to change it. This doesn't work exactly (it kept bouncing back and forth) so I figured out I could work the formula backwards and find out what the Pe needed to be (keeping a relatively static Ap). I got it working but there were a few times (maybe still is i don't remember I was working on it late last night) where it was telling me that I can't subtract a string from a number (well duh) except both variables were created from a formula so they should both be numbers. Or maybe it was from a parameter or previously defined variable. At any rate it was used previously in the formula with out a problem. I fixed it at one point and then it came back again and I don't remember what I did to fix it. I'll work on it later tonight if I get a chance.

So long as it works and I can get the Pe for a 4hr orbital period I should be able to feed the "mostly static" Ap and the future Pe (along with the current Ap/Pe) into the formula you provided a few days ago to get the deltav needed, which I can then plug into a node and I should be good to go. It's amazing how "simply complex" this stuff can be, and how "powerful" it is once you get an understanding of it.

It's been kind of fun, and sort of a little easier than I expect when I was working the orbital period formula backwards. Was pretty proud of my self when I printed out each step and it duplicated the numbers that were put into the formula originally. Once I get that part of it working I think I'm going to break it out into reusable parts for future programs.

On another note, I didn't think >= and != were working yet. Last I knew they weren't implemented, unless I missed that part, wouldn't be the first time.

I have upgraded the warp script but found something strange. When assigning warp to a variable oldwp and later comparing warp to oldwp kOS throws an error. Not all warp levels are allowed according to this table. You can find out when checking warp which shows the actual warp level. So if you run this script in a 200km orbit you should see level 4 instead of level 6.

declare parameter t1.
// warp    (0:1) (1:5) (2:10) (3:50) (4:100) (5:1000) (6:10000) (7:100000)
// min alt        atmo   atmo   atmo    120k     240k      480k       600k
set dt to t1 - time:seconds.
if dt < 0 {
    print "T+" + round(missiontime) + " Warning: wait time " + round(dt) + " is in the past.".
}
if dt >= 21600 {
    print "T+" + round(missiontime) + " Waiting for " + round(dt/21600) + "d" + mod(round(dt),21600) + "s".
    print "T+" + round(missiontime) + " Wait start @ " + time:calendar + ", " + time:clock.
}
set oldwp to "0".
until time:seconds >= t1 {
    set rt to t1 - time:seconds.       // remaining time
    set wp to 0.
    if rt > 5      { set wp to 1. }
    if rt > 30     { set wp to 2. }
    if rt > 300    { set wp to 3. }
    if rt > 600    { set wp to 4. }
    if rt > 6000   { set wp to 5. }
    if rt > 60000  { set wp to 6. }
    if rt > 600000 { set wp to 7. }
    set warp to wp.
    if warp != oldwp {
        print "T+" + round(missiontime) + " Warp " + warp + ", remaining wait " + round(rt) + "s".
        set oldwp to warp.
    }
    wait 0.5.
}
if dt >= 21600 {
    print "T+" + round(missiontime) + " Wait complete @ " + time:calendar + ", " + time:clock.
}

First time into the loop warp is compared to "0" -> works fine.

Second time into the loop warp is compated to oldpw -> error.

I'd expect to be able to compare oldwp to warp.

Bug or am I missing something?

Note: warpfor calls warpto.

Edited November 12, 2013 by Sma

[a1270]

@baloan I sent in a pull request to fix this. Very simple fix, I see no reason why it won't be merged in once Nivekk sees it.