kOS Scriptable Autopilot System 0.9

[Motokid600]

Thanks again Steve your a huge help.

[Camacha]

I am not sure these were already mentioned in the topic, but they are now for sure. A mod that has mods, neat-o!

Instruments that are usable through kOS.

Navigation nodes that can be used through kOS.

[Sma]

I am not sure these were already mentioned in the topic, but they are now for sure. A mod that has mods, neat-o!

Instruments that are usable through kOS.

Navigation nodes that can be used through kOS.

Thats cool. Though as far as I understand, Kevin was/is planning on adding the creation of maneuver nodes into kOS eventually.

Interesting thing with the instruments being compatible with kOS is that we can log that data and then create a graph out of it. Though again with 0.22 coming out, that might be a stock function, although in that case it may not be something that can be used outside of the game, so it'll still be good for kOS to have sensor access like this. I could see polling the sensors to determine when to open the chutes as opposed to just going by altitude.

[Bizz Keryear]

I am not sure these were already mentioned in the topic, but they are now for sure. A mod that has mods, neat-o!

Instruments that are usable through kOS.

Navigation nodes that can be used through kOS.

Thanks a bunch I wanted to have that so badly, no time today but I might mentioned it a article in the wiki, soon.

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

@KevinLaity It might be cool to have "on" statement at file operations.

Like e.g.

copy a_file from archive on 2.
// AND/OR
run autolaunch on 0.
// AND/OR
log "my_data" to log_file on archive.
// AND/OR
delete old_data on 2.

and so on. This would get rid of a quite few of "switch to"s.

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

Btw has someone else this wired bug:

After I have created a new vessel (from SPH/VAB or loading a craft file) the first command I enter causes the k-OS computer to freeze permanently, until I reboot it with a power un-&reconnect.

It might be only appear after a few resets to launch, not so sure about that.

[Dunbaratu]

Thanks a bunch I wanted to have that so badly, no time today but I might mentioned it a article in the wiki, soon.

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

@KevinLaity It might be cool to have "on" statement at file operations.

Like e.g.

copy a_file from archive on 2.
// AND/OR
run autolaunch on 0.
// AND/OR
log "my_data" to log_file on archive.
// AND/OR
delete old_data on 2.

and so on. This would get rid of a quite few of "switch to"s.

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

Btw has someone else this wired bug:

After I have created a new vessel (from SPH/VAB or loading a craft file) the first command I enter causes the k-OS computer to freeze permanently, until I reboot it with a power un-&reconnect.

It might be only appear after a few resets to launch, not so sure about that.

At least you've gotten SWITCH TO to work. My recent KOS project is on hold because something is really broken that I'm fairly certain I didn't cause but is some underlying bug in KOS that my code is triggering. When I run my latest attempt at a program it just makes all of KSP freeze and here's the weird thing - not always at the same place.

I even went as far as installing Visual Studio and learning just enough C# to insert debug printing statements in the mod to discover exactly where it's getting stuck. I still haven't worked it out - it gets stuck somewhere outside the actual language processing code. Somewhere in the Update event handling system that executes one line each clock tick just gets hung completely halfway through and I have no idea why.

I still haven't been able to trace down the set of conditions that cause it to happen but I know it only happens with the code that does copying and switching and volume renaming along the lines of what you're doing.

As far as your change, I like the idea in general.

[Dunbaratu]

Btw has someone else this wired bug:

After I have created a new vessel (from SPH/VAB or loading a craft file) the first command I enter causes the k-OS computer to freeze permanently, until I reboot it with a power un-&reconnect.

It might be only appear after a few resets to launch, not so sure about that.

Yes. I thought it was the problem I was having with my program but it appears to be unrelated. I fixed it in my local copy and made a pull request for it on github, but my other problem sill persists.

The problem is this: When you first bring the vessel into the full physics engine (i.e. put it on the launchpad). the KOS mod initializes each SCS part on the vessel by doing (among other things) the following two activities:

Hi! I'm an SCS CPU. Here is my initialization I'll be doing:

1 - My variables start off as null.

2 - Initialize all the variables that track my state, including the variable that keeps track of which of the volumes I can see is the one I've selected. (I can see more than one volume if I'm not the only SCS CPU on this vessel).

3 - If I'm brand new (not loaded from persistence file) such that I don't have a hard drive yet then make a new hard drive for myself.

The problem is that steps 2 and 3 need to happen in the opposite order. At the moment it initializes "which drive am I pointed at" the line right before it creates it's own local harddrive. So it's initializing the current selection to null.

At the moment the only way to avoid the bug you describe is to make sure that the very first thing you do on the disk is SWITCH TO 1 -even though 1 is meant to be the starting default Volume it isn't at the moment.

[Lewyn]

Hi there!

Why does this equal zero? Didn't I understand how LOCK is supposed to work or is this a bug?

declare var2.
lock var1 to 10*var2.

until 0 {
set var2 to altitude.
print var1.
}

Thanks!

Edited October 3, 2013 by Lewyn

[aNewHope]

Hi there!

Why does this equal zero? Didn't I understand how LOCK is supposed to work or is this a bug?

declare var2.
lock var1 to 10*var2.

until 0 {
set var2 to altitude.
print var1.
}

Thanks!

Yeah. I have the same problem. Somehow kOS doesn't care about locked variables, if you are in a loop. Its pretty annoying.

I also got the weird bug, that I can't work with some values. Whenever I try to use variables, created by trigonometric function, kOS freezes. Same thing with <IntakeAir>.

Hopefully this will get fixed soon.

[KevinLaity]

The problem is that steps 2 and 3 need to happen in the opposite order. At the moment it initializes "which drive am I pointed at" the line right before it creates it's own local harddrive. So it's initializing the current selection to null.

I wasn't able to replicate this but your logic sounds right, looks like somebody already made a pull request to swap these so I'll merge it and It'll be in the next release

[Motokid600]

So.. I take it kOS isn't too good with large rockets? Because im having trouble with this one. The rocket works just fine with manual control. But for some reason kOS puts the ship into a violent spin soon as it leaves the pad and just cant seem to control it at all. And on top of that I cannot get kOS to separate the liquid boosters before the first stage. It always waits for the stage their attatched to before they separate. So heres the code... ill post the craft if need be, but like I said it works just fine without kOS so I cant imagine its a problem there.

clearscreen.

print "10". wait 1.
print "9". wait 1.
print "8". wait 1.
print "7". wait 1.

stage.
print "Ignition Sequence Start.".
lock throttle to 0.25.
print "6".
wait 1.
lock throttle to 0.50.
print "5".
wait 1.
lock throttle to 0.75.
print "4".
wait 1.
lock throttle to 1.

print "3". wait 1.
print "2". wait 1.
print "1". wait 1.

lock steering to up + R(0,0,180).
stage.
print "Lift off of the Mars One Expedition!".

wait until stage:liquidfuel <1.
stage.
print "Liquid Booster separation.".

wait until stage:liquidfuel <1.
lock throttle to 0.
stage.
print "Stage One separation.".

wait 1.
lock throttle to 1.
print "Stage Two throttle up..".

wait until altitude > 10000.
lock steering to up + R(0,0,180) + R(0,-10,0).

wait until altitude > 14750.
lock steering to up + R(0,0,180) + R(0,-25,0).
print "Pitching program..".

wait until altitude > 20650.
lock steering to up + R(0,0,180) + R(0,-50,0).

wait until altitude > 30000.
lock steering to up + R(0,0,180) + R(0,-75,0).

wait until stage:liquidfuel <1.
lock throttle to 0.
stage.
print "Stage Two separation. Engine cut off.".

wait 3.
lock throttle to 1.
print "Stage Three ignition and throttle up.".

wait until altitude > 40000.
stage.
print "Fairing Separation.".

wait until altitude > 55000.
lock steering to up + R(0,0,180) + R(0,-90,0).

wait until apoapsis > 71500.
lock throttle to 0.
print "MECO.".

until 0 { wait 1. }.

Its crude, but it works great for all my rockets until now. I thought maybe the ship was rotated in the VAB so the "lock steering to up + R(0,0,180)." line might be trying to correct it, but that's not the case. So is there anything that could be causing this?

Heres a pic of the craft. For what its worth..

The kOS part is clipped inside. Could that be it?

And on top of that I cannot get kOS to separate the liquid boosters before the first stage.

This issue here is turning out to be the bigger problem. The boosters you see in that pic are liquid fuel and I need them to separate as they normally would. But

wait until stage:liquidfuel <1.
stage.
print "Liquid Booster separation.".

wait until stage:liquidfuel <1.
lock throttle to 0.
stage.
print "Stage One separation.".

doesn't do the trick. The boosters deplete and kOS waits for stage one to drain then separates. Any ideas?

Edited October 4, 2013 by Motokid600

[cfds]

Motokid, KSP itself means by "stage:liquidfuel" all fuel that is available to the engines that are active in the given stage, not the fuel that is in tanks that are separated with the next staging.

[Sma]

So.. I take it kOS isn't too good with large rockets? Because im having trouble with this one. The rocket works just fine with manual control. But for some reason kOS puts the ship into a violent spin soon as it leaves the pad and just cant seem to control it at all. And on top of that I cannot get kOS to separate the liquid boosters before the first stage. It always waits for the stage their attatched to before they separate. So heres the code... ill post the craft if need be, but like I said it works just fine without kOS so I cant imagine its a problem there.

...

Its crude, but it works great for all my rockets until now. I thought maybe the ship was rotated in the VAB so the "lock steering to up + R(0,0,180)." line might be trying to correct it, but that's not the case. So is there anything that could be causing this?

Heres a pic of the craft. For what its worth..

***PICTURE DELTED TO SAVE SPACE IN REPLY

The kOS part is clipped inside. Could that be it?

This issue here is turning out to be the bigger problem. The boosters you see in that pic are liquid fuel and I need them to separate as they normally would. But

...

doesn't do the trick. The boosters deplete and kOS waits for stage one to drain then separates. Any ideas?

About the rocket going "crazy" on launch with KOS that is usually the way it works for now. You could use

lock steering to up +R(0,180,180).

I think is what ive used, or maybe it was R(0,90,180) I forget which now and my laptop power supply is dead so I cant check my code, (borrowing my wifes laptop for now) and it should keep orientation as is on the navball and not go crazy, but when you change from that it'll rotate different directions, unless you only use up +R. Mostly I use the new heading method of launching, and in that case I have to lock steering as soon as I leave other wise if i change my pitch with heading it takes a strange route to get where i tell it to go. So at launch

lock steering to heading 90 by 90.

It'll rotate (roll I think), but once it's settled, locking to heading from then on the rocket shouldn't get too violent. It could also be due to too much or too little control authority, though being as you say it flies fine under manual control I wouldn't think so.

Also, I've found instead of doing

lock steering to up + R(0,0,180) + R(0,-10,0).

This works just as well, at least for me, and it'll save a little bit of space/memory

lock steering to up + R(0,-45,180).

or using heading

lock steering to heading 90 by 45.

. Of course thats working off of my memory so I may have the numbers mixed up.

As far as the booster problem goes, as cfds mentioned stage:liquidfuel works on all the liquid fuel in the current stage, so yeah it'll wait until its all gone meaning after the boosters and main stage are empty. What you have to do is put your boosters and main stage on separate stages, then in kos stage to activate the boosters (no throttle) grab the amount of fuel and set a variable with it, wait 1 second, stage grab that fuel and set another variable. So now you can subtract and basically if stage:liquid fuel < (totalfuel - booster fuel) stage. I posted a link to a post further back I made about how I handle asparagus staged rockets which also works for none asparagus given the aspCount is 1. Check it out and see if this will help:

http://forum.kerbalspaceprogram.com/threads/47399-kOS-Scriptable-Autopilot-System-0-7?p=666643#post666643

Edited October 4, 2013 by Sma

[Motokid600]

Ah thank you Sma that gives me something to try. The only other thing is the fact that those little liquid boosters are not asparagusly staged. They are on the pad so I can throttle up before release without loosing fuel ( I can get rid of this if it makes for a simpler code i just like it because it makes launches a bit smoother ) ,but once under way they don't have fuel lines going to the rocket ( main engine drains them in seconds ) So would the same still apply?

Edited October 4, 2013 by Motokid600

[Sma]

Hmm it might still work. Though if you setup your staging so the boosters stage first then the main stage then release the claps and throttle to 1 you shouldnt need the small tanks to replace 5he fuel. Most of my launches I have the throttle set after the clamps release, or the last thing before clamp release so its next to instantaneous with no fuel loss at least when using kos being as it goes from 0 to one in an instant. I could see using them for manual launch though.

[Izandral]

This mod looks really nice , gonna try it tonight , is there a page where i can get a list of all commands and variables , there seems to be missing a lot of info on the reference page on github.

Also is the program run on the craft itself ? I'm asking because i want to use this with remotetech to control craft automatically when they get to far and the delay to issue command becomes to great.

Also is there a way to check if the craft is connected to the remote network ? So i can execute some command if i ever lose contact ?

[Izandral]

when type a space in the command window the rocket stages, what do i do to fix this ?

Edited October 4, 2013 by Izandral

[Bizz Keryear]

I am not sure these were already mentioned in the topic, but they are now for sure. A mod that has mods, neat-o!

Instruments that are usable through kOS.

Navigation nodes that can be used through kOS.

This Candy made it finally into the Wiki.

So.. I take it kOS isn't too good with large rockets? Because im having trouble with this one. The rocket works just fine with manual control. But for some reason kOS puts the ship into a violent spin soon as it leaves the pad and just cant seem to control it at all.

I have made the experience that troubles with k-OS are linked to crafts. If a script works or not fairly depends on the craft. The cruise missile script didn't worked for my plane even though it were flying pretty stable (sas off and hand off controls and it flew a strait line, and it was also well controllable without sas) but with the script all it does were loopings. While the original missile missed the target about 6km (too far away, but it flew over it) but flew well.

So it would be a good idea to prived the craft file as well.

And on top of that I cannot get kOS to separate the liquid boosters before the first stage. It always waits for the stage their attatched to before they separate. So heres the code... ill post the craft if need be, but like I said it works just fine without kOS so I cant imagine its a problem there.

[...]

The boosters deplete and kOS waits for stage one to drain then separates. Any ideas?

As someone said: It depends not on the separation. To do it correctly you have to know how much fuel in all boosters are. And then separate the stage if that is missing from the initial amount of fuel. See in Space Computer how they done it in the asparagus staging. It is similar.

This mod looks really nice , gonna try it tonight , is there a page where i can get a list of all commands and variables , there seems to be missing a lot of info on the reference page on github.

Try the Wiki, its far more complete than the github pages.

Also is the program run on the craft itself ? I'm asking because i want to use this with remotetech to control craft automatically when they get to far and the delay to issue command becomes to great.

Yes. It is running in a part of the craft.

[Bizz Keryear]

when type a space in the command window the rocket stages, what do i do to fix this ?

Ah this is a known bug with RT.

It causes that keys are passed through to KSP even when in the K-OS window.

Unfortunately there is no fix (yet).

You have to ask RT for that.

[Motokid600]

The way I have the staging setup right now is Ignition>throttle up>release. Both the boosters and main engines are activated in the same stage. So Sma if I understand you right all I have to do is move the main engine activation up to the release stage then kOS will be able to differentiate between the two?

[Bizz Keryear]

The way I have the staging setup right now is Ignition>throttle up>release. Both the boosters and main engines are activated in the same stage. So Sma if I understand you right all I have to do is move the main engine activation up to the release stage then kOS will be able to differentiate between the two?

Sorry if I butt in, and I only will test it out yet, but I am pretty sure that wont solve your staging problem. Even if the main engines are fired later, as soon as you add them the fuel for them will be added to the stage fuel. That way your booster will only drop if the mains also out of fuel.

you might more something like that:

//pseudocode.
set total_fuel to <liquidfuel>.
set stage_fuel to total_fuel - // now add here the total liquid fuel that your booster have. you get that by multiplying the total amount of boosters and fuel in each one (and each fuel from VAB). and don't forget the dot.
when <liquidfuel> <= stage_fuel then {stage.}.

[Sma]

The way I have the staging setup right now is Ignition>throttle up>release. Both the boosters and main engines are activated in the same stage. So Sma if I understand you right all I have to do is move the main engine activation up to the release stage then kOS will be able to differentiate between the two?

Sort of...Basically you want your boosters and main engine(s) to be on different stages (but leave throttle at 0 until ready to release the clamps). When you stage (to activate the boosters) grab the amount of fuel and store it in a variable, then stage again (main engine(s) and boosters activated) and grab it with a different variable. Then after that you can set throttle to 1 or whatever you're using to get off the launcher and release the clamps (or release the clamps then throttle to 1, as long as it happens fast enough to get moving forward. The key part is to throttle up after activating the boosters and main engine separately. Hope that helps, I'm not always great at explaining things.

Sorry if I butt in, and I only will test it out yet, but I am pretty sure that wont solve your staging problem. Even if the main engines are fired later, as soon as you add them the fuel for them will be added to the stage fuel. That way your booster will only drop if the mains also out of fuel.

you might more something like that:

//pseudocode.
set total_fuel to <liquidfuel>.
set stage_fuel to total_fuel - // now add here the total liquid fuel that your booster have. you get that by multiplying the total amount of boosters and fuel in each one (and each fuel from VAB). and don't forget the dot.
when <liquidfuel> <= stage_fuel then {stage.}.

No problem, the more ideas the better, there is more than one way to kill kerbals I mean....solve problems. I didn't really meniton it in the post I linked to, but the code I posted there works (or should, I only tested it with 6 normal size boosters - 3 asparagus pairs, and I think either 2 or 4 rock-o-max (1 or 2 asparagus pairs, though 1 asparagus pair isn't really asparagus...i guess...) and it worked great, that way I didn't have to put in the amount of fuel from each booster. I just had to divide the liquidfuel variable I got before activating the main engine by the number of asparagus pairs. Hope that's not too confusing. Once I get my laptop power adapter replaced I can post a screenshot of my test staging and the section of code use to stage (both launch and to drop the boosters). If I had a better computer I'd record a video of it, though maybe I'll do a blog post about it instead. I guess I could do the blog post here on the forum as opposed to my "personal" ksp blog I've been neglecting, so more people have access to it (as it'll come up randomly in the list of blogs I guess).

Edited October 4, 2013 by Sma

[Motokid600]

Cool. I'll have to sit down later and figure out how to apply what you guys said. The solutions there I'm just not very savy at this coding thing as you can see. Thanks for taking the time to break it down it gives me something to work with. God where would I be without this thread? Lol not using kOS that for damn sure.

[Sma]

This mod looks really nice , gonna try it tonight , is there a page where i can get a list of all commands and variables , there seems to be missing a lot of info on the reference page on github.

Also is the program run on the craft itself ? I'm asking because i want to use this with remotetech to control craft automatically when they get to far and the delay to issue command becomes to great.

Also is there a way to check if the craft is connected to the remote network ? So i can execute some command if i ever lose contact ?

when type a space in the command window the rocket stages, what do i do to fix this ?

Bizz replied before I could, I was basically going to say the same thing though. I was using testing RT2 when I got KOS and found out the same problem. Unfortunately RT2 isn't currently being worked on until possibly after 0.22, and we'll have to see how in depth the stock comm network is when it comes out. For now I just removed RT2 as I tested it about as far as I could at the time. If the comm network in KSP is really basic I hope JDP and Cilph (and whoever else was working on it) continue working on RT2, with the ability to communicate with kOS. I can imagine setting up an orbit/landing program in kOS and setting up RT2 to run the programs once it gets to where it should be triggered(maybe a delay that says run this program in so many days, hours mins..it wouldnt really work to run the program and have the program commands on delay), just as it would in real life.

Edited October 4, 2013 by Sma

[Bizz Keryear]

Cool. I'll have to sit down later and figure out how to apply what you guys said. The solutions there I'm just not very savy at this coding thing as you can see. Thanks for taking the time to break it down it gives me something to work with. God where would I be without this thread? Lol not using kOS that for damn sure.

I've just tested it out ... and couldn't get my error. All seemed fine ... until I figured out yes the main engines also use fuel...

So all calculations are for naught if you don't apply fuel lines from your liquid booster to mains. You might not want this but its the only reliable way to know when your boosters are out of fuel.

Another way is to stage the booster manually.

Maybe someone else figures a way out to calculate how much fuel the mains consume.

And also while using

lock steering to up + R(0,0,180).
wait until altitude > 200.
lock steering to up.

I experienced a unstable flight.

While using

lock steering to up + R(0,0,180).
wait until altitude > 200.
lock steering to heading 90 by 90.

I had no problem.

Edit: Did someone else recognized that print at now works with variables?

Edited October 5, 2013 by Bizz Keryear
otherwise dbl post

[Sma]

I've just tested it out ... and couldn't get my error. All seemed fine ... until I figured out yes the main engines also use fuel...

So all calculations are for naught if you don't apply fuel lines from your liquid booster to mains. You might not want this but its the only reliable way to know when your boosters are out of fuel.

The code I use should work with/without fuel lines. I'll give it a try and see how it goes.

Update: You are right, it does have problems when not using fuel lines (with my code anyway). If I set aspCount to 1, it stages before the boosters are empty. If I set it to 0, it obviously doesn't stage. I'm sure there is someway to make it work though, I'm guessing it may have something to do with how I figure the pairing of boosters. I might try fixing it just for fun over the weekend.

And also while using

lock steering to up + R(0,0,180).
wait until altitude > 200.
lock steering to up.

I experienced a unstable flight.

While using

lock steering to up + R(0,0,180).
wait until altitude > 200.
lock steering to heading 90 by 90.

I had no problem.

Yeah, I think it's because it doesn't properly implement roll, at least thats what I can figure anyway. WHen I use heading 90 by 90 from launch, the rocket rolls so that north faces the left of the nav ball. From where I can use heading on other angles without a problem. How ever if I start with any of the other steering methods, or no steering method then use heading it gets really unstable until it finally gets to the designated steering.

Edit: Did someone else recognized that print at now works with variables?

Do you mean like:

set position to "(0,0)".
print "Hello World!" at position.
//or
set spX to 0.
set spY to 0.
print "Hello World!" at (spx,spy).

Edited October 5, 2013 by Sma